02.12.2024 02:04, Wietse Venema via Postfix-users :
Wietse Venema via Postfix-users:
The cleanup_out_header() function autodetects that a header needs
SMTPUTF8, including headers added with a header_checks PREPEND
action, but that function is not called for headers that are generated
by Postfix or added with a Milter request, because there was no
need prior to SMTPUTF8.
This is not going to be a one-line fix.
The quick fix, for SMTP UTF8 autodetection with GECOS info, can be
a one-line fix. With this, Postfix should request:
MAIL FROM<addr> ... SMTPUTF8
And the debian server should accept the message.
Can you try this patch? Encoding with RFC 2047 will take more time.
This become more interesting. And actually it *is* more interesting.
With detected SMTPUTF8 on submission entry, the mail is properly marked
as SMTPUTF8. The remote still rejects it (only relevant parts):
Dec 02 15:19:13 isrv postfix/smtp[31214]: <
mailly.debian.org[82.195.75.114]:25: 250-mailly.debian.org Hello isrv.corpit.ru
[86.62.121.231]
Dec 02 15:19:13 isrv postfix/smtp[31214]: <
mailly.debian.org[82.195.75.114]:25: 250-SMTPUTF8
Dec 02 15:19:13 isrv postfix/smtp[31214]: > mailly.debian.org[82.195.75.114]:25: MAIL
FROM:<m...@corpit.ru> SIZE=494 SMTPUTF8
Dec 02 15:19:13 isrv postfix/smtp[31214]: >
mailly.debian.org[82.195.75.114]:25: .
Dec 02 15:19:13 isrv postfix/smtp[31214]: <
mailly.debian.org[82.195.75.114]:25: 550 improper use of 8-bit data in message
header: message rejected
So this time, SMTPUTF8 is actually requested by postfix, while remote
exim still does not like it. Okay, *that* might be exim issue.
Now, the BOUNCE is sent to a dovecot server, and now the BOUNCE gets
dropped by postfix:
Dec 02 15:19:13 isrv postfix/lmtp[31220]: 8641BBC1EF: to=<m...@corpit.ru>, \
relay=mbox.tls.msk.ru[192.168.177.2]:24, delay=0.02, delays=0/0.01/0/0,
dsn=5.6.7, \
status=bounced (SMTPUTF8 is required, but was not offered by host
mbox.tls.msk.ru[192.168.177.2])
so now it's the bounce which is *also* marked as requiring SMTPUTF8.
I'm not sure this is right or not, - the bounce itself hopefully should
not include non-7bit headers in this case.
So basically, this change makes the situation worse in practice: there's
less chance to have a bounce delivered after the patch, since SMTPUTF8
flag also propagates to the bounce itself, but some systems don't accept
such emails.
But what's more interesting is: I'm submitting initial message from
another null-client mailserver (while the log above is from a mailhub) -
because that's where my GECOS field includes 8bit chars. The settings
wrt utf8 are identical on both. And obviously, I'm patching the internal
null-client postfix (where cleanup is involved during initial message
submission).
With or without this patch, the message content is identical, but the
envelope is different. But postfix on mailhub is *not* patched. And
it looks like it doesn't detect that a message requires SMTPUTF8 looking
at the message *contents* which it receives. It is only when the smtp
client *tells* the message requires SMTPUTF8, postfix believes it. But
postfix itself does not detect such situation - when the headers contains
unencoded 8bit data. So if postfix smtpd is supposed to *detect* (as
opposed to being told) that the message requires SMTPUTF8, this detection
does not actually work, it looks like. But I'm not sure if smtpd is
supposed to detect this.
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
