Re: The compatibility_level mechanism

2018-03-12 Thread Jesper Dybdal 

On 2018-03-12 12:12, Wietse Venema wrote:

Whereas compatibility is
easy to check for features that are implemented in one place,
smtputf8 affects a lot of programs. One would have to enable it
under the covers, but not enforce it.


Thanks for the explanation.  I'll be more careful the next time I 
increment compatibility_level.


--
Jesper Dybdal
http://www.dybdal.dk

Re: The compatibility_level mechanism

2018-03-12 Thread Wietse Venema 
Jesper Dybdal:
> 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.? 

With compatibility_level=0, Postfix always accepts mail with a
non-ascii header or address localpart. Whereas compatibility is
easy to check for features that are implemented in one place,
smtputf8 affects a lot of programs. One would have to enable it 
under the covers, but not enforce it.

Wietse

The compatibility_level mechanism

2018-03-11 Thread Jesper Dybdal 
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