Context

I have an OpenLDAP server (osixia/openldap with the postfix-book.schema added manually - seems like the version from your repository is a bit different, but this shouldn't change anything regarding this issue), with a user called uid=momarqua and [email protected]. The filters in docker-compose.yml are set as follows:

LDAP_QUERY_FILTER_USER: (&(mail=%s)(mailEnabled=TRUE))
LDAP_QUERY_FILTER_GROUP: (&(mailGroupMember=%s)(mailEnabled=TRUE))
LDAP_QUERY_FILTER_ALIAS: (&(mailAlias=%s)(mailEnabled=TRUE))
LDAP_QUERY_FILTER_DOMAIN: (&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))
DOVECOT_USER_FILTER: (&(objectClass=PostfixBookMailAccount)(|(mail=%u)(mailalias=%u)(uid=%n)))
DOVECOT_PASS_FILTER: (&(objectClass=PostfixBookMailAccount)(|(mail=%u)(mailalias=%u)(uid=%n)))
DOVECOT_PASS_ATTRS: uid=user,userPassword=password
SASLAUTHD_LDAP_FILTER: (&(|(mail=%U)(mailalias=%U)(uid=%U))(mailEnabled=TRUE))

I can receive emails without issues, I can send emails without issues, but as soon as I set SPOOF_PROTECTION=1, an error occurs.

Expected Behavior

I should be able to send email as [email protected], or at least as any of [email protected], [email protected] or [email protected], obviously given that I change the mail attribute in LDAP to the corresponding address.

Actual Behavior

I get the following error message:

Dec 14 21:52:07 mail postfix/submission/smtpd[1751]: NOQUEUE: reject: RCPT from
port-1-2-3-4.dynamic.as20676.net[1.2.3.4]: 553 5.7.1 <moritz.marquardt@obelix.
example.org>: Sender address rejected: not owned by user [email protected];
from=<[email protected]> to=<[email protected]> proto=ESMTP
helo=<[10.0.0.130]>

Possible Fix

The workaround I'm using is to just disable SPOOF_PROTECTION, which obviously isn't a fix at all.

Steps to Reproduce

TBD

Your Environment

• Amount of RAM available: 24 GB (~20 GB free)
• Mailserver version used: tvial/docker-mailserver:latest pulled on 2019-12-15
• Docker version used: 18.09.6, build 481bc77
• Environment settings relevant to the config: see Context above
• Any relevant stack traces ("Full trace" preferred): see Actual Behaviour above
• Also see Spoof failure with valid account and sender address #892 for a similar issue from 2018