Viktor Dukhovni:
> On Fri, Aug 24, 2018 at 04:54:32PM -0400, Wietse Venema wrote:
> > Even more relevant for the $Subject: several Postfix lookup tables
> > already block non-UTF8 queries when smtputf8 mode is turned
> > off (dict_ldap.c, dict_sqlite.c):
> >
> > /*
> > * Don't frustrate future attempts to make Postfix UTF-8 transparent.
> > */
> > if ((dict->flags & DICT_FLAG_UTF8_ACTIVE) == 0
> > && !valid_utf8_string(name, strlen(name))) {
> > if (msg_verbose)
> > msg_info("%s: %s: Skipping lookup of non-UTF-8 key '%s'",
> > myname, dict_ldap->parser->name, name);
> > return (0);
> > }
> > ...
> > I think that we should by default extend this to all lookup tables
> > and do away with that LATIN1 hack. That would also address the
> > problem that underlies the original request. No need for signaling
> > the request encoding!
>
> If the Postgres dictionary client-encoding changes from LATIN1 to
> UTF8, at what layer do you want to convert "unspecified" non-ASCII
> lookup keys UTF8 (by encoding each non-ASCII byte to 2 UTF-8 bytes)?
There is NO such conversion.
For the past four 3-4 years, Postfix has enforced that a query can
be only well-formed UTF-8 for LDAP and SQLite tables EVEN IF STMPUTF8
mode is turned off. And no-one has complained. I am arguing to
extend this filter to the other tables, possibly with backwards
compatibility.
There never was legitimate use of non-UTF8 in envelopes and headers.
It is a dying cause, therefore let's not extend its miserable life
by adding complexity to Postfix.
Wietse
