On 3/27/2013 7:18 PM, Matthew Hall wrote: > I altered the restrictions according to the new advice: > > relay_restrictions - removed
there's no reason to remove the safety net. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination Yes, these are repeated in smtpd_recipient_restrictions. That's why this is called a safety net -- to protect against accidents in smtpd_recipient_restrictions. No, executing these extra commands this will not slow down postfix. Your smtpd_recipient_restrictions look great, but I will mention list.dsbl.org is dead and unlikely to return; probably best to remove that line instead of just commenting it out. -- Noel Jones > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > check_client_access hash:/etc/postfix/client_checks, > check_client_access pcre:/etc/postfix/client_checks.pcre, > check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, > check_helo_access hash:/etc/postfix/helo_checks, > check_sender_access hash:/etc/postfix/sender_checks, > check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, > reject_unknown_sender_domain, > reject_rbl_client zen.spamhaus.org, > # reject_rbl_client cbl.abuseat.org, > # reject_rbl_client list.dsbl.org, > # reject_rbl_client sbl.spamhaus.org, > # reject_rbl_client pbl.spamhaus.org > permit > > Now, with everything in one list, all of the trivial RFC-ish checks > come first, then client access (to allow whitelisting), then > fqrdns.pcre, then special HELO, From, and To checks, then we go to the > more expensive ones that use DNS. > > Does this make more sense than what I did before? Or am I still off base. > > Thanks for your help. > > Matthew. >
