Issue SMTPUTF8 is required, but was not offered by host

[DerDanilo]

We receive many postmaster mails from foreign mailservers with the following message:

"SMTPUTF8 is required, but was not offered by host"

Postfix, Dovecot

Server1: Standard Setup on Debian Stretch
Server2: Standard Setup on Ubuntu 18

When can we expect a fix?
Both systems are clean and no messing around with any config files.
I do not have the time to fill the long bug report.

Thanks in advance!

 

[ChristophRo]

Please see Postfix Backwards-Compatibility Safety Net

You need to edit /etc/postfix/main.cf and either

a) adjust the "compatibility_level" parameter
b) or set/add smtputf8_enable=no

 

[DerDanilo]

Thanks for your reply.
I know how to solve this manually but editing the main.cf ist not useful, since Plesk will change the file through updates or other config changes.

Hence I am looking for a permanent solution. We cannot be the only customer having this issue.
The main problem ist with many big freemail providers since they don't seem to mantain their systems regularly. Since this behaviour won't change we need a permanent solution.

@plesk Team
An official solution would be good.

 

[ChristophRo]

Editing the main.cf is the official solution, as postfix does not know/support any other way.
Yes, Plesk does also make changes in this file, in case you configure something mail-related in the web-UI, but all your manual changes are preserved.

 

[DerDanilo]

If others are searching for a soluton the following may work for them.

postconf smtputf8_enable=no
postfix reload

But I'd still expect a solution from the Plesk team since this this problem cannot just be found with our customers (95% Germany).

 

[Monty]

BTW: Plesk does not come with its own version of Postfix. It merely installs the version of Postfix that is available from your OS vendor's repositories.

So if your OS comes with Postfix 3.x then smtputf8 will be enabled, as this is the default value for Postfix 3.x
But if your OS comes with Postfix 2.x then smtputf8 will be disabled.

So it's basically the job of your OS to deliver sane defaults for Postfix.

But yes I agree, it would be nice if there was a Plesk option to deal with such things

 

[IgorG]

Please vote for this feature here Allow to manage SMTPUTF8 over Plesk Mailserver Settings

 

[sweetp]

Ive also been caught out by this.
+1 for an Plesk solution

 

[mow]

With smtputf8_enable=no, however, SMTPUTF8 support won't be announced in the EHLO response, and thus, other servers will run into the above problem when trying to send to us. What happened to be liberal in what you accept?

 

[Bitpalast]

This issue has been seen here lately, probably since the 18.0.34 update with Posteo and T-Online account, but it might not be limited to them. Not sure whether this needs to be fixed on Plesk systems or on their infrastructure. To me the error message appears to be caused by a lack of UTF8 support on the receivers' end.

 

[Bitpalast]

Reported as a bug here:

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

Username: Peter Debik TITLE Frequent email rejections with "SMTPUTF8 is required, but was not offered by host " PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE Obsidian, latest MU CentOS 7.9 PROBLEM DESCRIPTION Since the latest Plesk Obisidian, an increasing number of emails that...

talk.plesk.com

 

[Bitpalast]

@kumarOraja Yes, the solution provided is correct. Actually, it is persistent, because in the Postfix main.cf Plesk only changes values that are controllable in the Plesk user surface. All other entries are kept as they are.

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

 

[Jan_Holler]

this line looks like this for me:

smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}

 

[tkalfaoglu]

Just as a followup, we need to set the compatibility_level to 1 to avoid this issue?

 

[mow]

Just as a followup, we need to set the compatibility_level to 1 to avoid this issue?

I have compatibility_level = 2 and smtputf8_enable = no.
If you don't have smtputf8_enable = no set explicitly, compatibility_level needs to be 0 for smtputf8_enable to be set to no automatically, as shown in the post above yours.

 

[tkalfaoglu]

Today I heard from a customer that Yahoo mail throws up when it encounters smtputf8 mails. so I had to disable it again

This is the mail system at host kalfaoglu.net.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own text from the attached returned message.

The mail system

<[email protected]>: SMTPUTF8 is required, but was not offered by host
mta6.am0.yahoodns.net[98.136.96.77]

 

[arnt]

Some confusion here...

Advertising SMTPUTF8 tells other servers that this server accepts UTF8 addresses, and promises to forward messages that require that only to servers that accept it, and promises to bounce the email if the recipient servers don't accept it. The software that composes and sends an email message can declare that SMTPUTF8 is required for this message, which typically happens when at least one to/from/cc address requires it.

Yahoo error message says "the sender of this message says this message requires that, but I don't support that". Disabling SMTPUTF8 is a heavyhanded reaction, it means you won't send such messages to anyone — neither to Yahoo nor to sites that can handle it.

I'm a bit surprised to see such messages in connection with Plesk, and would be very interested in tracking down the problem for one or a few messages. I can sign NDAs.

 

[mow]

Advertising SMTPUTF8 tells other servers that this server accepts UTF8 addresses, and promises to forward messages that require that only to servers that accept it, and promises to bounce the email if the recipient servers don't accept it. The software that composes and sends an email message can declare that SMTPUTF8 is required for this message, which typically happens when at least one to/from/cc address requires it.

Yeah, but that is an incredibly stupid way to implement UTF8 compatibility, because ...

Yahoo error message says "the sender of this message says this message requires that, but I don't support that". Disabling SMTPUTF8 is a heavyhanded reaction, it means you won't send such messages to anyone — neither to Yahoo nor to sites that can handle it.

... this is unavoidable as that is exactly what the above mentioned promise requires.
Designing such a protocol extension without a fallback / conversion can only lead to a network split between the servers that do resp. don't support this feature, and it violates the "be liberal in what you accept, be conservative in what you send" principle.

 

[arnt]

It does lead to a network split, but I wouldn't say cause… I first saw this in South India, where there are several communities of a hundred million people who can can read and write but cannot read/write latin letters. These people were split from the network of ASCII-based email already. SMTPUTF8 makes the gap visible in email, but the gap was there in the human world. (The other designs that were discussed weren't really different, BTW. SMTPUTF8 splits the world between servers that can forward non-ASCII stuff and servers that can't, and between messages that require that support and messages that don't. The other candidate designs had similar traits.)

 

[arnt]

A separate message. My job involves finding and fixing interoperation problems.

Based on this thread, I suspect that there's a bug somewhere in the vicinity of Plesk that leads to some messages being labelled as "this message requires SMTPUTF8" even though there's no really good reason to do that. I'd like to locate the source of those message and fix that bug. If anyone sees the problem, I'd be grateful for a pointer or any relevant data.