Hi, On Fri, Jul 07, 2006 at 05:15:11PM +0200, Martijn van Oosterhout wrote: > On Fri, Jul 07, 2006 at 03:48:00PM +0200, Marc Haber wrote: > > From what I understand, the correct way would be to use > > PQescapeStringConn, but that function needs an established connection, > > and exim performs string escape "early", way before the actual > > connection is established. > > I just downloaded the code and looked. Thank you very much. > The code never looks or checks the encoding of the database. This is > bad from a security point of view because that means you have no idea > how your queries are going to be interpreted. That's the way exim has always done it. > 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. > You could use UTF-8 but then postgres would complain if you pass any > strings that arn't valid UTF-8. They may or may not be desirable. Possible not desireable. > 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. > What about the configuration file? It probably can as well. 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. I'm going to point Philip to this thread. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
