Re: UTF8 problem

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Douglas McNaught" <doug(at)mcnaught(dot)org>
Cc: "Tino Wildenhain" <tino(at)wildenhain(dot)de>, "Alban Hertroys" <alban(at)magproductions(dot)nl>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: UTF8 problem
Date: 2006-06-08 14:08:26
Message-ID: 20060608160816.5773252@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2006-06-08 14:17:10 Re: new FAQ entry
Previous Message jqpx37 2006-06-08 14:05:54 Password for postgresql superuser?