------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.exim.org/show_bug.cgi?id=508 jasen Betts <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |ip.org Platform|Macintosh |All --- Comment #12 from jasen Betts <[email protected]> 2015-01-24 00:01:59 --- (In reply to comment #5) > So I think that the best approach would be to set the client_encoding based > upon the encoding of the E-mail being processed. dynamically setting the encoding is not the solution. _emails_ don't have _an_ encoding. mime body parts do, and it's not unusual, for different body parts of a multipart message to have different encodings. And what encoding gets used in the ACLS before DATA? Of you're storing an email body in a database you'll soon discover that you're forced to use BYTEA because not other format works > There are still cases where something may be not encoded entirely as it states > that it is - does Exim deal with this another way already? if it can't translate part of an otherwise valid RFC2047 header to a valide server encoding string it substitutes '?' for the bad part. (In reply to comment #6) > Reading between the lines somewhat, the referenced forcing of SQL_ASCII was > needed so that a consistent base for quoting rules was there. > Are quoting rules different for different encodings? Not so far as I recall, they do differ based on the standard_conforming_strings' setting. this feature was added in pg version 8.x in version 9 the default was changed. (In reply to comment #8) > On the quoting issue: the pgsql docs (eg. > http://www.postgresql.org/docs/8.4/static/libpq-exec.html section 30.3.4) > does say that the quoting required may change with the encoding; hence > the recommended interface is tied to a connection, and the alternate that is > notshould not be used for a client program that uses multiple connecti ons > (so we cannot). unfortunately setting the client_encoding to SQL_ASCII doesn't solve the whole problem as other connection parameters (eg: standard_conforming_strings) also effect how quoting should be performed. I thing the best approach is to not modify the connection, but leave it to the DBA to harmonise the settings. this has the potential to be a foot-gun, but it does allow interoperability where several databases with different server encodings are in use, > The problem for exim is that quoting is almost certainly needed before the > relevant connection is made, given the current handling of them and expansion > processing. We could potentially take a complete connection-spec (including > encoding) supplied with the quote operator, and match connections the same way > the lookup does. Undecorated quote expansions would use the default > connection/s set by pgsql_servers. you can specify several database connection strings and exim will try them in order. I think that happens after the query is escaped. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
