Hi

I know this gets beaten to death on a regular basis, but sometimes I get in a 
muddle and I'd appreciate a sanity check.  Currently my main.cf looks like:

## SPAM STUFF and REJECT CODES ##
smtpd_recipient_restrictions = reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        permit_sasl_authenticated,
        reject_sender_login_mismatch,
        check_helo_access hash:/etc/postfix/helo_checks,
        check_sender_access hash:/etc/postfix/ip_whitelist,
        check_recipient_access hash:/etc/postfix/laxdomains,
        check_sender_access hash:/etc/postfix/backscatter
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
    permit_mynetworks,
        check_policy_service inet:127.0.0.1:10031,
        reject_unlisted_recipient,
        reject_unauth_destination,
        check_policy_service unix:private/policy-spf,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client blackholes.mail-abuse.org,
        reject_rbl_client tw.countries.nerd.dk,
        reject_rbl_client kr.countries.nerd.dk,
        reject_rbl_client cn.countries.nerd.dk,
        reject_rbl_client relays.mail-abuse.org,
        reject_rhsbl_sender dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_unknown_client,
        warn_if_reject,
                reject_rhsbl_client dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_rbl_client dnsbl.sorbs.net,
        warn_if_reject,
                reject_rbl_client dnsbl.njabl.org,
        warn_if_reject,
                reject_rbl_client dul.dnsbl.sorbs.net,
        permit


This stuff builds up over time and I find I can't always remember the rational 
for putting things in the order I put them.  One point of concern that I have 
is that when I added in the policy-spf the warnings were clear that it needs to 
go after reject_unauth_destination otherwise it turns the box into an open 
relay.  The same logic should apply to the policyd service, yes?  But yet there 
it is above reject_unauth_destination and the online but 
http://www.checkor.com/ and http://verify.abuse.net/cgi-bin/relaytest says I'm 
not an open relay, so I'm confused.

Looking over the list though, I propose:

## SPAM STUFF and REJECT CODES ##
smtpd_recipient_restrictions = reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_sender_login_mismatch,                   
# shouldn't this be before permit_sasl?
        permit_sasl_authenticated,
        check_helo_access hash:/etc/postfix/helo_checks,
        check_sender_access hash:/etc/postfix/ip_whitelist,
        check_recipient_access hash:/etc/postfix/laxdomains,    
#domains that don't want grey-listing and rigourous helo checking - would be 
better to put this after unknown_recipient_domain, yes?
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
        check_sender_access hash:/etc/postfix/backscatter               
# the other items will catch more and should therefore come first, yes?
    permit_mynetworks,
        reject_unlisted_recipient,
        reject_unauth_destination,
# does the order of reject_unlisted and reject_unauth matter?  Both are mysql 
lookups but domain should come before recipient, no?
     check_policy_service unix:private/policy-spf,
        check_policy_service inet:127.0.0.1:10031,
# makes sense to put the grey-listing after SPF verified hosts, yes?
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client blackholes.mail-abuse.org,
        reject_rbl_client tw.countries.nerd.dk,
        reject_rbl_client kr.countries.nerd.dk,
        reject_rbl_client cn.countries.nerd.dk,
        reject_rbl_client relays.mail-abuse.org,
        reject_rhsbl_sender dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_unknown_client,
        warn_if_reject,
                reject_rhsbl_client dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_rbl_client dnsbl.sorbs.net,
        warn_if_reject,
                reject_rbl_client dnsbl.njabl.org,
        warn_if_reject,
                reject_rbl_client dul.dnsbl.sorbs.net,
# can I group all the warn_if_rejects?
        Permit

I'd be grateful for comments/suggestions.  Are there newer/better RBLs I should 
be using?

Simon



Reply via email to