------- 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 <eximbugzilla@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eximbugzilla@???-
| |ip.org
Platform|Macintosh |All
--- Comment #12 from jasen Betts <eximbugzilla@???> 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
