On 6/10/2013 1:49 PM, Phil Daws wrote: > Hello, > > Postscreen (Postfix 2.10) is working very well indeed but I am having an > issue with understanding where a policy check should be implemented. main.cf > looks like: > > smtpd_relay_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_policy_service inet:127.0.0.1:10031, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unlisted_recipient, > permit > postscreen_cache_map = memcache:/etc/postfix/postscreen/memcache.cf > postscreen_greet_action = enforce > postscreen_dnsbl_sites = > sip.invaluement.local,sip24.invaluement.local,zen.spamhaus.org,bl.spamcop.net,bl.mailspike.net > postscreen_dnsbl_threshold = 1 > postscreen_dnsbl_action = enforce > postscreen_access_list = > permit_mynetworks,cidr:/etc/postfix/postscreen/access.cidr > > and in master.cf I have: > > smtp inet n - n - 1 postscreen > smtpd pass - - n - - smtpd > tlsproxy unix - - n - 0 tlsproxy > dnsblog unix - - n - 0 dnsblog > > Yet when I SASL authenticate the policy service does not appear to be > triggered; as I am trying to limit number of emails sent by SASL username.
You've put check_policy_service AFTER permit_sasl_authenticated. First match wins, so the policy never gets called for authenticated clients. Depending on your needs, you can put your check_policy_service in smtpd_data_restrictions or smtpd_sender_restrictions by itself. smtpd_sender_restrictions = check_policy_service inet:127.0.0.1:10031 It's also common for there to be overrides for the submission service in master.cf that change the options you've set in main.cf. > > I thought that if the Postscreen checks were successfully passed then the > connection would then flow through to a SMTP (smtpd) server process. Is that > correct ? Should I move the smtpd_recipient_restrictions into master.cf ? Hopefully SASL and postscreen have no interaction -- postscreen should be configured for only port 25, and SASL should only be on submission. Using postscreen + SASL on port 25 is guaranteed to cause headaches -- users may be rejected by postscreen before they ever get a chance to authenticate. If you must offer SASL on port 25, don't use postscreen. -- Noel Jones > > A little baffled at the moment. > > Thank you. > > Phil >
