Early Postfix versions evaluated SMTP access restrictions lists
as early as possible. The client restriction list was evaluated
before Postfix sent the "220 $
myhostname..." greeting banner to
the SMTP client, the helo restriction list was evaluated before
Postfix replied to the HELO (EHLO) command, the sender restriction
list was evaluated before Postfix replied to the MAIL FROM command,
and so on. This approach turned out to be difficult to use.
Current Postfix versions postpone the evaluation of client,
helo and sender restriction lists until the RCPT TO or ETRN command.
This behavior is controlled by the
smtpd_delay_reject parameter.
Restriction lists are still evaluated in the proper order of (client,
helo, etrn) or (client, helo, sender, recipient, data, or end-of-data)
restrictions.
When a restriction list (example: client) evaluates to REJECT or
DEFER the other restriction lists (example: helo, sender, etc.)
are skipped.
Around the time that
smtpd_delay_reject was introduced, Postfix
was also changed to support mixed restriction lists that combine
information about the client, helo, sender and recipient or etrn
command.
Benefits of delayed restriction evaluation, and of restriction
mixing:
-
Some SMTP clients do not expect a negative reply early in
the SMTP session. When the bad news is postponed until the RCPT TO
reply, the client goes away as it is supposed to, instead of hanging
around until a timeout happens, or worse, going into an endless
connect-reject-connect loop.
-
Postfix can log more useful information. For example, when
Postfix rejects a client name or address and delays the action
until the RCPT TO command, it can log the sender and the recipient
address. This is more useful than logging only the client hostname
and IP address and not knowing whose mail was being blocked.
-
Mixing is needed for complex whitelisting policies. For
example, in order to reject local sender addresses in mail from
non-local clients, you need to be able to mix restrictions on client
information with restrictions on sender information in the same
restriction list. Without this ability, many per-user access
restrictions would be impossible to express.
