Todd A. Jacobs wrote, at 01/21/2009 03:42 PM: > Based on the feedback that I've gotten, I've made the following changes: > > smtpd_client_restrictions = > check_recipient_mx_access hash:/etc/postfix/mx_access > check_recipient_access hash:/etc/postfix/recipient_access > check_client_access hash:/etc/postfix/domain_access > check_helo_access hash:/etc/postfix/helo_access > reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname > reject_unknown_helo_hostname > reject_unknown_sender_domain > reject_rbl_client zen.spamhaus.org > permit_mynetworks > reject_unauth_destination > check_policy_service inet:127.0.0.1:60000 > > Most of the suggestions were to put check_recipient_mx_access into > smtpd_recipient_restriction, but I'm concerned about how that will > impact the allow/deny order of the existing smtpd_client_restrictions I > have in place, and which seem to be working well.
Logically, it doesn't make sense to perform recipient checks before you know the recipient. > One of the things I don't want kiboshed is the rules that allow mail to > postmaster to go through even if other rules would disallow it. I also > don't want to check the hash tables twice if I don't have to, but > I don't know if there's really any performance penalty if I do. Because you're using the default smtpd_delay_reject = yes, smtpd_(client|helo|sender)_restrictions will all be evaluated at RCPT TO, so it's usually unnecessary to repeat restrictions. This is one reason people throw everything in smtpd_recipient_restrictions, in the order they want. Your configuration above risks being affected if you ever change smtpd_delay_reject to no.
