• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs Frequent email rejections with "SMTPUTF8 is required, but was not offered by host <hostname>"

Bitpalast

Plesk addicted!
Plesk Guru
Username: Peter Debik

TITLE

Frequent email rejections with "SMTPUTF8 is required, but was not offered by host <hostname>"

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Obsidian, latest MU
CentOS 7.9

PROBLEM DESCRIPTION

Since the latest Plesk Obisidian, an increasing number of emails that are mailed out through our servers are rejected by the recipient hosts with this error message:

SMTPUTF8 is required, but was not offered by host <hostname>

STEPS TO REPRODUCE

Send an email to a web.de or t-online.de account.

ACTUAL RESULT

Error message returned from the recipient's host.

EXPECTED RESULT

No error, delivery as usual.

ANY ADDITIONAL INFORMATION



YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
The problem originates in the "Third-Party Component Updates" that were done with the update to Obsidian 18.0.34. This installed Postfix 3.5.9, and in Postfix 3.5.x the default setting for the parameter smtputf8_enable is "yes" while many other providers don't support the UTF8 setting. So we could actually call it "advanced" over other provider's settings, and it might have been premature by me to file this as a bug.

It is probably not really a "bug". It's more an issue with a newer capability brought in by Postfix 3.5.9 that many other mail servers do not support. So probably with the update Plesk should have set the parameter
smtputf8_enable=no
after updating Postfix. But as the updates are through already, it is too late for this and the only viable solution is the manual edit of the Postfix main.cf file.
 
After upgrade to 18.0.35 there should be:

Code:
# postconf |grep utf8
smtputf8_autodetect_classes = sendmail, verify
smtputf8_enable = no
strict_smtputf8 = no
Problems with this approach:
  • other postfixes that want to send an SMTPUTF8-enabled mail won't be able to deliver to us because we don't announce SMTPUTF8 capability anymore
  • Outlook 2019 requires SMTPUTF8 when it encounters an IDN domainname and doesn't handle it well when the mailserver says it can't use that
I think it was a very bad design decision to introduce SMTPUTF8 without a possibility for conversion/fallback, making delivery fail if a message somewhere started as UTF8.
 
Back
Top