Quantcast

Disabling SMTPUTF8 per destination

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Disabling SMTPUTF8 per destination

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.

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.

Prior art in Postfix is ``smtp_tls_policy_maps`` which allow overriding
main.cf TLS settings per destination.

Any views?  Does a per-destination override exist and did I miss it in
the documentation and the archives?  Has this been discussed before?

Thanks.
Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling SMTPUTF8 per destination

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling SMTPUTF8 per destination

Philip Paeps
On 2017-04-10 09:51:42 (-0400), Wietse Venema <[hidden email]> wrote:

> Philip Paeps:
> > My system is configured with default SMTPUTF8 settings [...]
> >
> > 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.

That had occurred to me but it happens rarely enough that I've not been
too bothered (it pretty much only happens when I bounce Asian spam to
spamcop.net).  When it does happen, it reminds me to check if anything
new is happening in the world of SMTPUTF8. :)

If it starts bothering me, I'll do as you suggest.

> > 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?

Argh.  I see what you mean.  I hadn't considered mail in transit.  I was
thinking only of mail coming in through submission (which, come to think
of it, is actually also in transit).  I should think before writing
email rather than during.

> > 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.

You are correct of course.  I had forgotten that the SMTPUTF8 promise
applies to the entire message and all headers not simply the envelope.

> 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.

An option to accept/forward a message that arrives with SMTPUTF8 but
only has UTF8 in the message headers but not the envelope to a nexthop
that does not support SMTPUTF8 would only "fix" the problem for that one
nexthop and still violates the end-to-end promise of SMTPUTF8.  We can't
(always) know that the nexthop configured like this is the final
destination for the message.

The more I think about this, the more I realise that an option like this
would create a lot more problems than it solves.

The rest of the world just needs to adopt SMTPUTF8. :-)

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Loading...