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
