By now the reader may wonder why we need smtpd client, helo
or sender restrictions, when their evaluation is postponed until
the RCPT TO or ETRN command. Some people recommend placing ALL the
access restrictions in the
smtpd_recipient_restrictions list.
Unfortunately, this can result in too permissive access. How is
this possible?
The purpose of the
smtpd_recipient_restrictions feature is to
control how Postfix replies to the RCPT TO command. If the restriction
list evaluates to REJECT or DEFER, the recipient address is rejected;
no surprises here. If the result is PERMIT, then the recipient
address is accepted. And this is where surprises can happen.
Here is an example that shows when a PERMIT result can result
in too much access permission:
1 /etc/postfix/
main.cf:
2
smtpd_recipient_restrictions =
3
permit_mynetworks
4
check_helo_access hash:/etc/postfix/helo_access
5
reject_unknown_helo_hostname
6
reject_unauth_destination
7
8 /etc/postfix/helo_access:
9 localhost.localdomain PERMIT
Line 5 rejects mail from hosts that don't specify a proper
hostname in the HELO command (with Postfix < 2.3, specify
reject_unknown_hostname). Lines 4 and 9 make an exception to
allow mail from some machine that announces itself with "HELO
localhost.localdomain".
The problem with this configuration is that
smtpd_recipient_restrictions evaluates to PERMIT for EVERY host
that announces itself as "localhost.localdomain", making Postfix
an open relay for all such hosts.
In order to avoid surprises like these with
smtpd_recipient_restrictions, you should place non-recipient
restrictions AFTER the
reject_unauth_destination restriction, not
before. In the above example, the HELO based restrictions should
be placed AFTER
reject_unauth_destination, or better, the HELO
based restrictions should be placed under
smtpd_helo_restrictions
where they can do no harm.
