Postfix spuriously checks SPF policy for authenticated, submitting mail clients

Question

I am running Postfix 3.8.1 on Ubuntu 23.10. 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. However, Postfix spuriously does so for authenticated MUAs and SPF fails (because the MUA is not listed as a permitted mail server).

I have the feeling as if Postfix simply ignores the special rules for MUAs, but I do not find my configuration error.

My master.cnf

# ==========================================================================
# 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.

My main.cf

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

smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=no

The idea is that in step mua_relay_restrictions authenticated clients are unconditionally permitted and everything else rejected. This means for authenticated clients access control should stop there. This is also the reason why there is only smtpd_recipient_restrictions for clients on port 25 and no corresponding mua_recipient_restriction, because Postfix should never reach that point.

However, if I use a mail client to send submit a mail via my Postfix mail server to another mail box of mine (hosted externally), I see the following logs on my mail server:

postfix/submission/smtpd[515502]: Anonymous TLS connection established from pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-sign>
policyd-spf[515508]: : prepend Received-SPF: Softfail (mailfrom) identity=mailfrom; client-ip=217.236.242.123; helo=my-touchpad.localnet; [email protected]; receiver=other-domain.tld

That SPF has to fail is obvious. The MUA is a client (my-touchpad.localnet) on a dial-up line (pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]) which is not listed by the SPF policy for my-domain.tld. Of course, it isn't because the SPF policy only lists the mail server itself.

However, I wonder why Postfix executed that check in the first place. Checking SPF is only part of smtpd_recipient_restrictions which is not supposed to be applied to authenticated MUAs.

Answer 1

Checking SPF is only part of smtpd_recipient_restrictions which is not supposed to be applied to authenticated MUAs.

This is a false assumption. The smtpd_recipient_restrictions would only do that if it was configured to permit authenticated MUAs before checking for the SPF policy, e.g.,

smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  check_policy_service unix:private/policyd-spf,
  permit

Because...

Restrictions are applied in the order as specified; the first restriction that matches wins.

You currently have a global setting for all smtpd instances including submission that checks for the SPF and permits any message passing the SPF check:

smtpd_recipient_restrictions =
  check_policy_service unix:private/policyd-spf,
  permit

In order to not apply this for authenticated MUAs, this parameter should be different for submission, which is achieved by overriding the parameter in master.cf:

submission inet n       -       y       -       -       smtpd
  . . .
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Or, if you follow your pattern of having custom variables (i.e. not a Postfix Configuration Parameter) defined as mua_*_restrictions in your main.cf and using them as variables in master.cf, you would have:

• in main.cf:

  mua_recipient_restrictions =
     permit_sasl_authenticated,
     reject
  

• in master.cf:

  submission inet n       -       y       -       -       smtpd
     . . .
     -o smtpd_recipient_restrictions=$mua_recipient_restrictions
  

Answer 2

I do not see any -o smtpd_recipient_restrictions=$mua_recipient_restrictions line in your master.cf that would override your main.cf global default.

which is not supposed to be applied to authenticated MUAs

The thing you think was not supposed to be applied, is not configured exclusively for the port 25 instance. Since you put it in main.cf, it serves as the default for both. Postfix is applying the same recipient restriction class for both smtpd instances (that serving MX role, and that handling authenticated submission), because you modified the global default and did not change it back for that special submission service.

You can (not the only solution, but seems like a consistent and readable way of getting where you want) override it just as you did with the other restriction classes.

mua_recipient_restrictions = permit_sasl_authenticated, reject