Make postfix reject 8bit (non ASCII) 'mail from' address

[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ï[e-mail]>

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  [phone]
CH-4133 Pratteln                Fax  [phone]
Schweiz                         Web  http://www.imp.ch
______________________________________________________

[Dominic Raferd]

On Tue, 3 Sep 2019 at 07:52, Benoit Panizzon <[hidden email]> wrote:

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.

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.

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.

[Wietse Venema]

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

[Viktor Dukhovni]

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ï[e-mail]>
>
> 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.

[Benoit Panizzon]

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  [phone]
CH-4133 Pratteln                Fax  [phone]
Schweiz                         Web  http://www.imp.ch
______________________________________________________

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.

[Viktor Dukhovni]

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