Viktor Dukhovni:
>
> > On Jan 25, 2017, at 4:26 PM, Wietse Venema wrote:
> >
> >> Even fancier would be dynamically adjusting the database encoding to
> >> UTF-8 when the client includes the "SMTPUTF8" ESMTP parameter in its
> >> "MAIL" command. Since, presumably, in that case all non-ASCII dat
> On Jan 25, 2017, at 4:26 PM, Wietse Venema wrote:
>
>> Even fancier would be dynamically adjusting the database encoding to
>> UTF-8 when the client includes the "SMTPUTF8" ESMTP parameter in its
>> "MAIL" command. Since, presumably, in that case all non-ASCII data
>> in the SMTP dialogue are
Viktor Dukhovni:
>
> > On Jan 25, 2017, at 3:19 PM, Andrew Sullivan
> > wrote:
> >
> > I am aware that the Postgres driver is currently hard-coded to LATIN1.
> > This, of course, causes problems with SMTPUTF8, since the email
> > addresses and so on could be in UTF8.
> >
> > I have a reason to
On Wed, Jan 25, 2017 at 03:31:36PM -0500, Viktor Dukhovni wrote:
>
> The reason for LATIN1 is that all raw octet strings are valid LATIN1,
> so whatever non-ASCII garbage comes down the wire, database lookups
> won't tempfail with query encoding errors. Absent mechanisms like
> SMTPUTF8 non-ASCII
> On Jan 25, 2017, at 3:19 PM, Andrew Sullivan wrote:
>
> I am aware that the Postgres driver is currently hard-coded to LATIN1.
> This, of course, causes problems with SMTPUTF8, since the email
> addresses and so on could be in UTF8.
>
> I have a reason to need the combination, and I'm wonderi
Hi,
I am aware that the Postgres driver is currently hard-coded to LATIN1.
This, of course, causes problems with SMTPUTF8, since the email
addresses and so on could be in UTF8.
I have a reason to need the combination, and I'm wondering whether
there is anything standing in the way of just changin
