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=<>, orig_to=<>, relay=[]: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[])

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.

[]:10027 is amavisd-new 2.10.1, which I believe should support SMTPUTF8 (see!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

Reply via email to