Philip Paeps:
> My system is configured with default SMTPUTF8 settings, i.e.:
>
> root@rincewind:~ # postconf -d | grep UTF8
> smtputf8_autodetect_classes = sendmail, verify
> smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
> strict_smtputf8 = no
> root@rincewind:~ # postconf -n | grep UTF8
> root@rincewind:~ # postconf compatibility_level
> compatibility_level = 2
>
> This works perfectly fine (probably because, sadly, SMTPUTF8 is still
> quite rare in the wild) except occasionally I'll get an NDR for a
> locally submitted message:
>
> SMTPUTF8 is required, but was not offered by host
>
> This happens when I "bounce"/"resend" a message with UTF8 in one of the
> headers. Pre-SMTPUTF8 Postfix would not care about UTF8 in e.g. From:
> or Subject: but in the new world order, such messages submitted locally
> bounce.
>
> I'm cool with that. The world needs to move on.
>
> Except ... I know that some parts of the world will take a while before
> they move on. I couldn't find anything in postconf(5) or in the mailing
> list archives about disabling SMTPUTF8 per destination.
The simplest solution is to not enable SMTPUTF8 auto-detection in
the Postfix sendmail command (smtputf8_autodetect_classes = verify).
That is the root cause of the problem, after all.
> If a per-destination safety net existed, I would likely consider
> setting ``smtputf8_autodetect_classes`` to all. If others feel
> the same, maybe it would advance adoption of SMTPUTF8 in the wild.
What should happen with TRANSIT EMAIL, after the Postfix SMTP server
has promised that it will deliver such email according to the rules
for SMTPUTF8?
> Prior art in Postfix is ``smtp_tls_policy_maps`` which allow
> overriding main.cf TLS settings per destination.
There is no promise that email received with TLS will be forwarded
with TLS. With SMTPUTF8 (and 8BITMIME), the receiving MTA actually
makes such a promise. The MTA is required to respect the promise
that it made when it announced SMTPUTF8 (or 8BITMIME) support, and
if it can't keep that promise, to return email as undeliverable.
Perhaps SMTPUTF8 autodetection could be more granular: UTF8 in the
envelope is definitely problematic for a receiver that does not
support SMTPUTF8, while UTF8 in a message header is less so.
Wietse
