Sstrhsrtj

I am running a Postfix server which uses Dovecot LMTP for mail delivery. I am doing this because it plays well with sieve.

However, I have gotten some email lately with Unicode in the subject line.

This mail is received OK by Postfix, which clearly supports SMTPUTF8 - however, it dies when it gets to LMTP:

<me@myhost> (expanded from <meother@mhost>): SMTPUTF8 is required, but
was not offered by host myhost[public/lmtp]


I read in the Postfix SMTPUTF8 documentation that,

When a message is received with the SMTPUTF8 request, Postfix will deliver the message to a non-SMTPUTF8 SMTP or LMTP server ONLY if:

No message header value contains UTF-8.

The envelope sender address contains no UTF-8,

No envelope recipient address for that specific SMTP/LMTP delivery transaction contains UTF-8.

NOTE: Recipients in other email delivery transactions for that same message may still contain UTF-8.

Otherwise, Postfix will return the recipient(s) for that email delivery transaction as undeliverable. The delivery status notification message will be an SMTPUTF8 message. It will therefore be subject to the same restrictions as email that is received with the SMTPUTF8 request.

-- http://www.postfix.org/SMTPUTF8_README.html#detecting

The relevant part is "Postfix will deliver ... to a non-SMTPUTF8 ... LMTP server ONLY if ... [there is no UTF8 in the message]".

This is awkwardly-worded, but the implication is that Postfix will only pass UTF8 mail along to a downstream server if it supports UTF8.

Because I am receiving UTF8 mail, Postfix is refusing to deliver it to Dovecot LMTP.

Which brings me to a couple of questions:

• Does Dovecot LMTP support SMTPUTF8? (It appears not: http://www.dovecot.org/list/dovecot/2013-January/thread.html#87756)


• Does Postfix have a "soft fail" mode for this, whereby it can queue the mail for later delivery, bypass LMTP, or do something more intelligent than falling over?

TL;DR: See Summing up!

I regularly also get emails with UTF-8 chars in the Subject: line. Never so far any within other headers.

While a 'soft-fail'-mode in postfix is unknown to me, you may setup another smtp transport and filtering bounces through it as a kind of failsafe-mode. However, I would have yet to complete this setup myself. As of now, the bounces are sticking to the queue as undeliverable until expiry. At least they don't just get returned back to sender and I've got an eye on the sticky members of the queue. On the other hand, I am reluctant to go down further that road, now that the following method works for me(tm):

The working solution (in the case of UTF-8 chars in Subject: only) was to just disable postfix' smtputf8_enable feature which is nowadays defaulting to "yes" (using an up-to-date debian, that is). In main.cf add:

smtputf8_enable = no

Fiddling about with smtputf8_autodetect_classes was inconclusive.

The email msgs featuring the UTF-8 Subject: line are now being processed by postfix and saved by dovecot without any problems.

The solution might look counterintuitive, especially regarding the slighty awkwardly-worded postfix documentation (as you already mentioned).

The latest update about SMTPUTF8 support in dovecot seems to be the one you are referencing. Some place else I recall seeing a post the SMTPUTF8 in dovecot won't be implemented anytime soon if at all [citation needed]. Not sure whether this was an authoritative statement or not.

Another comment about dovecot and SMTPUTF8 can be found here (including your reference and this SE question): https://dovecot.org/list/dovecot/2016-November/106029.html
Together with this next post it seems the topic stalled at roughly end of 2016: https://dovecot.org/list/dovecot/2016-September/105474.html

Summing up: today, if you don't need SMTPUTF8 support in headers other than the Subject: header, you might get away with just disabling smtputf8_enable in postfix' main.cf and be happy as-is.

HTH