|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: mouss (mlist.only
free.fr)
Date: Thu Oct 04 2007 - 15:40:59 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]