Douglas McNaught wrote:
> I would think it would (at least potentially) vary with each message.
> The dbmail software should really set client_encoding based on the
> Content-Transfer-Encoding header in the message (or whatever it's
> called).
That would be the "charset" parameter of the Content-Type header,
Content-Transfer-Encoding having a different purpose.
Anyway, doing this would be quite risky, just look for example at
the security hole refered to as CVE-2006-2313.
dbmail authors are aware of the issue, it's quite clearly explained
here:
http://mailman.fastxs.net/pipermail/dbmail-dev/2005-November/007656.html
On the other hand they had a bug filed here:
http://www.dbmail.org/mantis/view.php?id=218
where a user reports the same problem than the OP,
and for which the analysis is pretty strange, pretending that
UNICODE shouldn't be used with pg<8.1 :)
IMHO they fail to draw the proper conclusion, which is that
either the raw mail should be stored as either as a binary object,
or as a text field in a database with SQL_ASCII encoding, in both
cases providing the level of transparency that they need by design,
their purpose being to store and retrieve the mail, not to check its
its contents.
--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org