The compatibility_level mechanism is an excellent and very well designed
idea. But I must have misunderstood something - or there is an error.
Around christmas I upgraded from postfix 2.11 to 3.1.6 (Debian 9).
I let the system run with compatibility_level=0 for a couple of months.
I then checked the log file for occurrences of "using
backwards-compatible", which I thought would tell me where I depended on
obsolete default settings.
Apart from some "chroot=y" warnings (which I fixed), there were no such
entries.
So I recently set compatibility_level to 2.
Very soon after that I saw the following error (with domain names changed):
postfix/smtp[11021]: 3zw35550Qyz4FNxb:
to=<bs+example.com...@nuser.example.net>, orig_to=<a...@example.com>,
relay=127.0.0.1[127.0.0.1]:10027, delay=0.4, delays=0.39/0.01/0/0,
dsn=5.6.7, status=bounced (SMTPUTF8 is required, but was not offered
by host 127.0.0.1[127.0.0.1])
This was a message sent from a local CGI script using sendmail. Its
sender and recipient were in US-ASCII, but the subject line contained
(unencoded, standards-violating) ISO 8859-1 characters.
[127.0.0.1]:10027 is amavisd-new 2.10.1, which I believe should support
SMTPUTF8 (see
https://groups.google.com/forum/#!topic/mailing.postfix.users/rKdbrpw0nc8).
But that is not a postfix issue, so forget that.
What I do not understand, postfix-wise, is that I have seen no warnings
about "using backwards-compatible" default value of smtputf8_enable
during the period where I was using compatibility_level=0. The same CGI
script has undoubtedby sent several mails with ISO-8859-1 subject lines
during that period.
I have of course now set smtputf8_enable=no until I understand what is
going on, but I would like to understand why the compatibility_level
mechanism did not warn me about this problem.
Jesper Dybdal
--
Jesper Dybdal
http://www.dybdal.dk
