Hi Jorge,
To have SMTPUTF8 enabled in system it should be supported by all
components of mail system.
If you have LMTP as f.e. Dovecot which not yet production ready for
SMTPUTF8 (at least from my view, as it only got support of it couple of
months ago and I would not rush deploying it on Prod) and at same time
you have separated incoming/outgoing Postfix relays you can enable
SMTPUTF8 on outgoing relay, but hide SMTPUTF8 capability from incoming
postfix relay. I don't know which options you use in Postfix but
personally I faced issue with Postfix<->PostgresSQL with exactly turned
off SMTPUTF8 due to issues in postfix-postres client that with disabled
SMTPUTF8 due to unclear reason start to speak with PostgresSQL in ASCII
encoding and at same time tried to pass LATIN1 payload (aka äē) which
leading to breaking DB connection for a smtp worker and 4xx error,
leading to totally unstable handing system. Such issue not reproduce for
example in Postfix MySQL client, but personally for myself I faced
enough to better hide capability instead of disabling it, as Postfix not
fully validate if accepted payload SMTPUTF8 or not, and I saw on
practice senders (SendGrid is speak directly, and expect some other)
that doesn't honors SMTP capabilities provided by MX when doing
delivery, sending SMTPUTF8 payload even it was not announced by MX...
If we speak about milters, well you also have to be sure all they would
expect non-ASCII data coming to them, this is a blackbox usually
(especially for some older milters one) or hard debugging. For Rspamd
for example gladly SMTPUTF8 can be turned on and it by design fully UTF8
ready (because in terms of SMTP it's relatively fresh and well
maintained software), but out of the box it's turned off, at least right
now.
Rspamd is also another reason (in addition to bug with postfix-postgres
client) due to which I for myself prefer to not disable SMTPUTF8 but
hide it from capabilities, because if you get LATIN1 (aka äē) in milter
which even configured to support SMTPUTF8 - it will also works not
properly, as LATIN1 != UTF8. This way if somebody abuses (ignores MX
capabilities) and sends email with such data I at least able to scan it
for spam, log it and if it's just a from at least receive it.
Hope my answer would help you a bit :)
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 29/06/2025 14:23, Wietse Venema via Postfix-users wrote:
Jorge Bastos via Postfix-users:
Howdy,
Sometimes i have users that write the emails wrong, and the email client
stops sending with the default message from postfix "555 5.5.4
Unsupported option: SMTPUTF8".
Those clients are buggy. A client can request SMTPUTF8 only
if the server has announced SMTPUTF8 support (in EHLO).
What is your reason to disable SMTPUTF8? Did you read the SMTPUTF8
RFCs? With SMTPUTF8 turned off, you will not be able to receive
some legitimate email messages.
Wietse
_______________________________________________
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
