Hello all, I am running Postfix 3.8.1. Postfix serves port 25 for incoming mail from other MTAs and port 587 for authenticated MUAs.
Postfix is supposed to check SPF for mails from other MTAs on port 25, but not for mails from authenticated MUAs on port 587. To this end, there is a SPF check inside „recipient_restrictions“, but authenticated clients are already permitted by an early „permit_sasl_authenticated“ inside „relay_restrictions“. According to my understanding, Postfix should stop evaluation of the access rules as soon as a final decision has been made. I thought, Postfix evaluates 1. client restrictions 2. helo restrictions 3. sender restrictions 4. recipient restrictions 5. relay restrictions 6. data restrictions 7. end-of-data restrictions in that order until either a final PERMIT, DENY or DEFER is found. But even though step 4 permits authenticated clients, step 5 performs the SPF check even for authenticated clients. Maybe someone could shed some light on what is happening here and where I am erring. My `master.cnf` (essential entries only) ``` # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (no) (never) (100) # ========================================================================== smtp inet n - y - - smtpd submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o cleanup_service_name=header_cleanup -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_relay_restrictions=$mua_relay_restrictions header_cleanup unix n - - - 0 cleanup -o header_checks=regexp:/etc/postfix/submission_header_cleanup.cf ``` The idea of the configuration above is that smtpd on port 587 (submission) should use some special configuration for the access rules. My `main.cf` (again, essential entries only) ``` smtpd_delay_reject = yes smtpd_client_restrictions = reject_unauth_pipelining, reject_unknown_client_hostname mua_client_restrictions = reject_unauth_pipelining smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname mua_helo_restrictions = reject_invalid_helo_hostname strict_rfc821_envelopes = yes smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain mua_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain reject_plaintext_session, reject_sender_login_mismatch smtpd_relay_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination mua_relay_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_sasl_authenticated, reject smtpd_recipient_restrictions = check_policy_service unix:private/policyd-spf, permit policyd-spf_time_limit = 3600 ``` The idea is that `mua_relay_restrictions` unconditionally permits authenticated clients and rejects everything else. This means for authenticated clients access control should stop there. This is also the reason why `smtpd_recipient_restrictions` exists only for clients on port 25 and there is no corresponding `mua_recipient_restriction`, because Postfix should never reach that point. But my logs show that Postfix also evaluates `smtpd_recipient_restrictions` for authenticated clients which have already been accepted by a previous `mua_relay_restrictions` and the SPF check fails. I can work around the issue, if I add an extra ``` mua_recipient_restrictions = permit_sasl_authenticated, reject ``` to `main.cf` and add `-o smtpd_recipient_restrictions=$mua_recipient_restrictions` to `master.cf`. Why is this necessary to prevent the spurious SPF check for authenticated clients? Bests, Matthias _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
