On Sun, Jul 09, 2006 at 06:16:48PM +0200, Marc Haber wrote:
> > I'd suggest adding a PQsetClientEncoding(conn, "Latin1") right after
> > you establish a connection. I'm not sure if Exim has any kind of
> > declaration about what encoding strings have internally.
>
> No, it does not.
That's your fundamental problem. You cannot safely quote strings if you
do not know the encoding of the string you're escaping. That's
fundamentally what this bug is about.
> > SQL_ASCII may also be an option (assign no special meaning to
> > characters at all), but I'm less sure of that. Can email address
> > contain multibyte characters? I didn't think so...
>
> E-Mail addreses themselves can't, but the "comment" field of an
> address can.
But no validation is done on these strings, ofcourse.
> > What about the configuration file?
>
> It probably can as well.
Ditto.
I'd suggest forcing the client_encoding to SQL_ASCII. That way
multibyte characters will simply get dumped into the strings in the
backend. But at least there won't be any issues with the server
misinterpreting your string.
It may be worthwhile allowing the user to set the encoding, but that
just opens the issue up again, because then you actually have to
validate the strings are the encoding you think they are.
>
> Please note that exim is so flexible that it is possible to implement
> mail spool storage in an SQL database. In this case, we'd write data
> which originated in an untrusted source to the database, not knowing
> about encoding at all.
That will work just fine, as long as the database encoding is
SQL_ASCII, in which case there is no problem... What we're talking
about here is invalidly coded UTF-8 and things like SJIS.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.