Hello, I just wanted to provide a feedback with the resolution to our problem.
Your hint Wietse was the key ;) "Simplify the configuration: place check_policy_service at the start of your rules." The problem was in the location of the "check_policy_service unix:private/policyd-spf" in our Postfix configuration... we located it at the very bottom of the "smtpd_recipient_restrictions", so incoming emails where never evaluated by the check, except some... smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/mynetworks3.cidr, reject_unauth_pipelining, check_sender_access hash:/etc/postfix/acl-1-from, check_recipient_access hash:/etc/postfix/acl-1-to, check_sender_access regexp:/etc/postfix/acl-2-from, check_sender_access hash:/etc/postfix/fromreg, check_recipient_access hash:/etc/postfix/toreg, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, # check_policy_service inet:127.0.0.1:10023, check_policy_service inet:127.0.0.1:10022, check_policy_service unix:private/policyd-spf So after locating it a bit higher, now all incoming emails are processed by the policy and therefore the correspondent SPF header is added to the emails. Thank you very much for your help and regards, eNeKuX Sent: Tuesday, June 07, 2016 at 4:23 PM From: "Wietse Venema" <wie...@porcupine.org> To: "Postfix users" <postfix-users@postfix.org> Subject: Re: Problems with SPF policy service (pypolicyd-spf) Wietse Venema: > Have you looked in the MAILLOG file for warning/error/fatal/panic > messages as a result of doing these experiments? Postfix does not > silently drop requests. Simplify the configuration: place check_policy_service at the start of your rules. How do you measure the number of check_policy_service requests? Note that syslog etc. may drop records when events are logged at a high rate. Wietse
