On Sun, Dec 15, 2019 at 11:12:21PM -0500, John C Klensin wrote:
[ On the ietf general list ]
[...] and, while the specification arguably permits it, accepting the
EHLO and then rejecting the mail transaction only after processing the
MAIL and at least one RCPT command is probably at least in bad taste.
FWIW, that particular feature has some careful reasoning behind it:
smtpd_delay_reject (default: yes)
Wait until the RCPT TO command before evaluating
$smtpd_client_restrictions, $smtpd_helo_restrictions and
$smtpd_sender_restrictions, or wait until the ETRN command
before evaluating $smtpd_client_restrictions and
This feature is turned on by default because some clients
apparently mis-behave when the Postfix SMTP server rejects
commands before RCPT TO.
The default setting has one major benefit: it allows Postfix to
log recipient address information when rejecting a client
name/address or sender address, so that it is possible to find
out whose mail is being rejected.
When an SMTP server returns 5XX in either the greeting or in response to
EHLO, some clients treat that as a connection setup failure, not a
permanent message delivery failure, and move on to the next MX host, and
perhaps ultimately defer and retry the message:
smtp_skip_5xx_greeting (default: yes)
Skip remote SMTP servers that greet with a 5XX status code.
By default, the Postfix SMTP client moves on the next mail
exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix
should bounce the mail immediately.
The reason for that was that at least at the time, various Microsoft
SMTP servers woul return 5XX greetings under transient high load.
Consequently, Postfix itself is one of the clients that treats
5XX as temporary failures in greetings (though not in EHLO).
Thus client-IP access control rules that would naïvely run at "CONNECT",
are by default deferred to RCPT TO, along with the rules that restrict
"EHLO" and "MAIL".
ietf-smtp mailing list