On 2017-04-10 09:51:42 (-0400), Wietse Venema <wie...@porcupine.org> 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
