Dear List
We use Postfix / Dovecot on our email plattform. Lately I have started seeing more and more emails being accepted by postfix, but then rejected by the local delivery agent dovecot with: 500 5.5.2 Invalid command syntax (in reply to MAIL FROM command) Looking at the headers, I see that the envelope sender contains 8 bit characters, AFAIK against valid RFC. Example: <AloïsiaAbelrycoh@netfacilprovedor.com.br> We use Postfix 3 but have NOT enabled SMTPUTF8 support. It's also not advertised in the 'ehlo' reply. So I wonder, why is postfix accepting sender email addresses with invalid characters? I have tested with netcat, indeed 8bit chars are being accepted. We use MIMEDefang as a milter, so I could basically try filter 8bit sender there, but I would rather use the built in mechanisms of postfix, if such one exists. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ |
On Tue, 3 Sep 2019 at 07:52, Benoit Panizzon <[hidden email]> wrote: Dear List It is no longer against RFC to use international characters in email address, see RFC6530..3. Therefore Postfix 3+ supports SMTPUTF8 by default unless you *disable* it with smtputf8_enable = no. Bear in mind that you may reject legitimate incoming mail. |
In reply to this post by Benoit Panizzon
Benoit Panizzon:
> Dear List > > We use Postfix / Dovecot on our email plattform. > > Lately I have started seeing more and more emails being accepted by > postfix, but then rejected by the local delivery agent dovecot with: > > 500 5.5.2 Invalid command > syntax (in reply to MAIL FROM command) > > Looking at the headers, I see that the envelope sender contains 8 bit > characters, AFAIK against valid RFC. Example: > > <Alo?[hidden email]> > > We use Postfix 3 but have NOT enabled SMTPUTF8 support. It's also not > advertised in the 'ehlo' reply. With SMTPUTF8 turned off, Postfix does not enforce 7bit envelope addresses or headers. All you can enforce is strict_8bitmime=yes and strict_8bitmime_body=yes. As documented, this can reject legitimate mail from programs that don't understand MIME. With SMTPUTF8 turned on, you can enforce strict_smtputf8=yes which accepts UTF8 envelope addresses only if the client requests an SMTPUTF8 mail transaction. > So I wonder, why is postfix accepting sender email addresses with > invalid characters? I have tested with netcat, indeed 8bit chars are > being accepted. Because it is Postfix's job to deliver mail, not to force everyone else into RFC compliance. Wietse |
In reply to this post by Benoit Panizzon
On Tue, Sep 03, 2019 at 08:50:51AM +0200, Benoit Panizzon wrote:
> I see that the envelope sender contains 8 bit > characters, AFAIK against valid RFC. Example: > > <AloïsiaAbelrycoh@netfacilprovedor.com.br> > > We use MIMEDefang as a milter, so I could basically try filter 8bit > sender there, but I would rather use the built in mechanisms of > postfix, if such one exists. You can use "check_sender_access" in combination with a PCRE table: /[^[:ascii:]]/ REJECT 5.1.7 Malformed sender address BUT, you MUST be sure to remove that rule if/when you enable SMTPUTF8. Demo (uses "bash" inline file syntax): $ postmap -q - pcre:<( printf '%s\n%s\n%s\n%s\n' \ 'if /[^[:ascii:]]/' \ '/(.*)/ Non-ascii ${1}' \ 'endif' \ '/(.*)/ ASCII ${1}' ) << 'EOF' > виктор@example.org > [hidden email] EOF виктор@example.org Non-ascii виктор@example.org [hidden email] ASCII [hidden email] -- Viktor. |
Am Tue, 3 Sep 2019 09:33:52 -0400
Hi Viktor > You can use "check_sender_access" in combination with a PCRE table: > > /[^[:ascii:]]/ REJECT 5.1.7 Malformed sender address Thank you, that solves the issue of Postfix accepting such emails but dovecot then rejecting them causing 'double bounces'. > BUT, you MUST be sure to remove that rule if/when you enable SMTPUTF8. Yes sure, but first dovecot must also support SMTPUTF8 Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ |
In reply to this post by Viktor Dukhovni
On 3 Sep 2019, at 07:33, Viktor Dukhovni <[hidden email]> wrote:
> You can use "check_sender_access" in combination with a PCRE table: > > /[^[:ascii:]]/ REJECT 5.1.7 Malformed sender address That error message is wrong though. -- Always be sincere, even if you don't mean it. |
> On Sep 4, 2019, at 9:16 AM, @lbutlr <[hidden email]> wrote:
> > On 3 Sep 2019, at 07:33, Viktor Dukhovni <[hidden email]> wrote: >> You can use "check_sender_access" in combination with a PCRE table: >> >> /[^[:ascii:]]/ REJECT 5.1.7 Malformed sender address > > That error message is wrong though. If the MTA does not advertise SMTPUTF8, envelope addresses are required to be ASCII. A non-ASCII address is therefore malformed, but the OP is of course free to craft any text message of his choice. The important part is the "5.7.1" enhanced DSN status code, but perhaps better than: REJECT 5.7.1 ... would be (<https://tools.ietf.org/html/rfc5321#section-4.2.2>): 501 5.7.1 Invalid (non-ASCII) sender address -- Viktor. |
Free forum by Nabble | Edit this page |