behavior when connecting client triggers several errors

[Fourhundred Thecat]

Hello,

lets say a client connects and triggers several errors. For instance:

   EHLO asdf
   ....
   mail from: [hidden email]
   250 2.1.0 Ok
   rcpt to: [hidden email]
   504 5.5.2 <asdf>: Helo command rejected: need fully-qualified hostname

why did the "Helo command rejected" come not immediately after the wrong
EHLO ? Why did postfix wait until failed relay, to report ehlo?

And even worse, the client tries to relay mail, but no "relay access
denied" is being logged.

I am much more interested in "relay access denied", than non-FQDN ehlo.

Does postfix have some priorities which errors it logs preferentially?

thanks,

[Matus UHLAR - fantomas]

On 14.01.21 11:27, Fourhundred Thecat wrote:

>lets say a client connects and triggers several errors. For instance:
>
>  EHLO asdf
>  ....
>  mail from: [hidden email]
>  250 2.1.0 Ok
>  rcpt to: [hidden email]
>  504 5.5.2 <asdf>: Helo command rejected: need fully-qualified hostname
>
>why did the "Helo command rejected" come not immediately after the wrong
>EHLO ? Why did postfix wait until failed relay, to report ehlo?

to log all parameters, like mail from: and rcpt to:
Helps much when digging logs why was someone's mail refused.

>And even worse, the client tries to relay mail, but no "relay access
>denied" is being logged.

the mail can only be rejected with one error. The first error is used.

>I am much more interested in "relay access denied", than non-FQDN ehlo.

you can disable the helo checks. I don't recommend that.
I usually allow both relaying and simple helo strings for authenticated
mail.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.

[Bill Cole-3]

On 14 Jan 2021, at 7:53, Matus UHLAR - fantomas wrote:

> On 14.01.21 11:27, Fourhundred Thecat wrote:
>> lets say a client connects and triggers several errors. For instance:
>>
>>  EHLO asdf
>>  ....
>>  mail from: [hidden email]
>>  250 2.1.0 Ok
>>  rcpt to: [hidden email]
>>  504 5.5.2 <asdf>: Helo command rejected: need fully-qualified
>> hostname
>>
>> why did the "Helo command rejected" come not immediately after the
>> wrong
>> EHLO ? Why did postfix wait until failed relay, to report ehlo?
>
> to log all parameters, like mail from: and rcpt to:
> Helps much when digging logs why was someone's mail refused.

Also, technically, because smtpd_delay_reject is "yes" which is the
default in recent versions of Postfix.

The rationale for smtpd_delay_reject is both to allow for logging of
sender and recipient(s) and to reject mail at a point (RCPT) where all
generally well-behaved senders will recognize it as an unconditional
permanent failure. Historically some MTAs responded to 5xx replies
before RCPT by retrying, which isn't what you want.

>> And even worse, the client tries to relay mail, but no "relay access
>> denied" is being logged.
>
> the mail can only be rejected with one error. The first error is used.
>
>> I am much more interested in "relay access denied", than non-FQDN
>> ehlo.
>
> you can disable the helo checks. I don't recommend that.

Rather than disabling helo checks, it is possible to put them in
smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual
relay restrictions, so that the first error hit is the unauthorized
relay.

Note that because helo checks are usually extremely fast (e.g. checking
a string for a '.') it may be better on extremely performance-sensitive
systems to keep helo checks in smtpd_helo_restrictions so that those
cheap rejections are done without going through the slower work that may
be required for nuanced relay restrictions, such as full-circle DNS
lookups.

> I usually allow both relaying and simple helo strings for
> authenticated
> mail.

Authentication is best reserved for submission services (ports 465 and
587,) not inbound (port 25) SMTP.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

[Viktor Dukhovni]

On Thu, Jan 14, 2021 at 10:14:49AM -0500, Bill Cole wrote:

> > to log all parameters, like mail from: and rcpt to:
> > Helps much when digging logs why was someone's mail refused.
>
> Also, technically, because smtpd_delay_reject is "yes" which is the
> default in recent versions of Postfix.

Not just "recent", every stable release (starting with 1.0):

    https://github.com/vdukhovni/postfix/blame/master/postfix/src/global/mail_params.h#L2406-L2408

on by default since 19990510.

> > you can disable the helo checks. I don't recommend that.
>
> Rather than disabling helo checks, it is possible to put them in
> smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual
> relay restrictions, so that the first error hit is the unauthorized
> relay.

Unfortunately, smtpd_recipient_restrictions runs *before*
smtpd_relay_restrictions (in recent Postfix releases), and there was
some discussion of making that configurable, but I forget where that
ended up...  I agree that one would naively expect the relay checks
to run first, and the current behaviour (though "safer" in some
sense) is surprising.

--
    Viktor.

[Wietse Venema]

Viktor Dukhovni:

> > Rather than disabling helo checks, it is possible to put them in
> > smtpd_recipient_restrictions or smtpd_relay_restrictions *AFTER* actual
> > relay restrictions, so that the first error hit is the unauthorized
> > relay.
>
> Unfortunately, smtpd_recipient_restrictions runs *before*
> smtpd_relay_restrictions (in recent Postfix releases), and there was
> some discussion of making that configurable, but I forget where that
> ended up...  I agree that one would naively expect the relay checks
> to run first, and the current behaviour (though "safer" in some
> sense) is surprising.

We could gate this with "compatibility_level = 3.6" which is already
being used for some TLS-related breaking changes.

Strawman:

    smtpd_relay_before_recipient_restictions =
        ${ {$compatibility_level} <level {3.6} ? {no} : {yes} }

The weird '<level' operator is needed because we're switching
compatibility_level settings from 1, 2, ... to settings that match
the Postfix version that introduces the breaking change.

With the old '<' operator, 3.10 would be smaller than 3.9 which
is undesirable.

        Wietse

[Viktor Dukhovni]

On Thu, Jan 14, 2021 at 11:40:34AM -0500, Wietse Venema wrote:

> > Unfortunately, smtpd_recipient_restrictions runs *before*
> > smtpd_relay_restrictions (in recent Postfix releases), and there was
> > some discussion of making that configurable, but I forget where that
> > ended up...  I agree that one would naively expect the relay checks
> > to run first, and the current behaviour (though "safer" in some
> > sense) is surprising.
>
> We could gate this with "compatibility_level = 3.6" which is already
> being used for some TLS-related breaking changes.
>
> Strawman:
>
>     smtpd_relay_before_recipient_restictions =
>         ${ {$compatibility_level} <level {3.6} ? {no} : {yes} }

Yes, that seems quite reasonable.

Note to the reader, there is no typo there, the correct syntax is
as written above with "{$compatibility_level}" and not what you'd
typically see in shell scripts, etc. "${compatibility_level}".

The reason is that per postconf(5):

    http://www.postfix.org/postconf.5.html

    The expression "${name?{value1}:{value2}}" is replaced with "value1"
    when "$name" is non-empty, and with "value2" when "$name" is empty.
    The "{}" is required for "value1", optional for "value2". The
    parameter name must contain only characters from the set
    [a-zA-Z0-9_]. This form is supported with Postfix versions >= 3.0.
 
    The first item inside "${...}" may be a relational expression of the
    form: "{value3} == {value4}". Besides the "==" (equality) operator
    Postfix supports "!=" (inequality), "<", "<=", ">=", and ">". The
    comparison is numerical when both operands are all digits, otherwise
    the comparison is lexicographical. These forms are supported with
    Postfix versions >= 3.0.

[ The HTML manpage displays unicode glyphs for "<=" and ">=", but these
  are not supported in that form. ]

--
    Viktor.