OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Confused about smtpd_sender_restrictions and smtpd_recipient_restrictions

From: mouss (mlist.onlyfree.fr)
Date: Thu Oct 04 2007 - 15:40:59 CDT


GT4NE1 wrote:
> I'm going to implement some RBLs on my Postfix server and I'm confused
> about where to put them. Everywhere I read, it says to add them in
> smtpd_recipient_restrictions
>
> According to this page:
>
> http://www.postfix.org/SMTPD_ACCESS_README.html
>
> smtpd_sender_restrictions Optional Reject MAIL FROM information
> smtpd_recipient_restrictions Required Reject RCPT TO information
>
> Why don't I want RBLs in smtpd_sender_restrictions? I don't care
> about who the email is going to (smtpd_recipient_restrictions), just
> where it is coming from (smtpd_recipient_restrictions).
>
> Obviously I'm missing some part about how Postfix processes an email
> or something, because my logic it telling me to put it in
> smtpd_sender_restrictions.
>
> Can someone clue me into what I am missing?
>

in the default setup (smtpd_delay_reject=yes), all checks are done at
RCPT TO stage. you are thus free to move checks around. there are
advantages in putting all checks under recipient restrictions:
1- you only have one sequence of checks to understand.
2- when you need to whitelist a client for example, you don't need to
repeat the whitelisting check. here is an example:

smtpd_client_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_rbl_client ...

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination

if you put all checks under recipient restrictions, this becomes

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_rbl_client ...
        reject_unauth_destination

so permit_* is not repetead. and this is a very simple example. now
think of more elaborate examples and you'll see the benefits.

3- you have more freedom to order the checks. the example above is
better implemnted as

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination
        reject_rbl_client ...

now you don't do dns queries to DNSBLs in the case of a relay attempt.
if still not convinced, consider

smtpd_recipient_restrictions =
        reject_non_fqdn_sender
        reject_non_fqdn_recipient
        reject_unlisted_sender
        reject_unlisted_recipient
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination
        reject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_sender_domain
        check_sender_mx_access $sender_mx_access_map
        reject_rbl_client ...
        ...

now, the DNSBL check is avoided in the case of a broken helo or a bad
sender domain.

There are cases where some checks are better put under "other"
restrictions (any of client|helo|sender). This is when you want to
return an OK but not skip other checks. but let's keep things simple...