On 1/25/2013 4:29 AM, Jamie Paul Griffin wrote: > * Noel Jones <njo...@megan.vbhcs.org> [2013-01-23 12:37:28 -0600]: > >> On 1/23/2013 12:30 PM, Tom Tucker wrote: >>> >>> I think I got it. The ordering is critical. Thanks >>> >>> >>> smtpd_recipient_restrictions = >>> check_recipient_access hash:/etc/postfix/relay_domains # >>> This will allow clients missing PTR records the ability to relay locally >>> reject_unknown_reverse_client_hostname # Reject all other >>> clients missing PTR records from sending externally >>> reject_unknown_recipient_domain >>> reject_non_fqdn_sender >>> reject_non_fqdn_helo_hostname >>> reject_invalid_helo_hostname >>> reject_unknown_helo_hostname >>> reject_unlisted_recipient >>> permit_mynetworks # Permit all other mail traffic both >>> internally and externally >>> reject_unauth_destination >>> >>> >>> /etc/postfix/relay_domains >>> mydomain.com <http://mydomain.com> OK >>> myotherdomain.com <http://myotherdomain.com> OK >> >> >> >> The above disables all your UCE controls. > > Wouldn't it be better to put $reject_unauth_destination closer to > the top of the restriction class: i.e. after $check_recipient_access? > and then $permit_mynetworks after that? > > Like so: > > smtpd_recipient_restrictions = > check_recipient_access hash:/etc/postfix/relay_domains, > reject_unauth_destination, > permit_mynetworks, > ... > > Jamie >
Generally yes. In this particular case -- a host not connected to the internet with very unusual requirements -- no, it works as intended already and that change would "break" it. This particular case could be simplified to: permit_auth_destination reject_unknown_reverse_client_hostname permit_mynetworks reject This is not a useful example for 99%+ of users, except maybe as an exercise in the importance of restriction order to meet specific requirements. -- Noel Jones
