I’m getting SPF validation failures for emails sent locally through email_administrator.py to a local account (user@my.domain), including the status check notices. Mail from/to external means don’t have that issue. MIAB (git 1699ab8c02) runs with public IPv6 and private IPv4 (10.x.x.x behind NAT).
The log shows
“postfix/smtpd: connect from unknown[10.x.x.x]”
[…]
“postfix/smtpd: client=unknown[10.x.x.x]”
[…]
“opendmarc: SPF(mailfrom): my.domain fail”
The email has
“Authentication-Results: my.domain; spf=fail smtp.mailfrom=my.domain”
“Received: from my.domain (unknown [10.x.x.x])”
and “5.0 SPF_FAIL SPF check failed” in the spamassassin section
This wasn’t an issue in (potentially much) older Mail-in-a-Box versions, they seem to have kept the originating IP as 127.0.0.1, but the current versions substitutes the IP with 10.x.x.x (same as $PRIVATE_IP) somewhere between email_administrator.py and the SPF check. The old version didn’t have any “Authentication-Results” headers in the email either.
I’m not quite sure where to fix this. Other topics suggest adjusting spamassassin to counteract this, but I believe the local mails are taking the wrong path earlier and shouldn’t encounter SPF validation to start with.
This might be a bug in MIAB, not sure if there is a different root cause. I verified with strace that the python script connects to 127.0.0.1:25, so it’s unclear why postfix resolves to the 10.x.x.x ip.
So you send externaly only via IPV6? And your SPF with IPV6 is OK?
Did you check the headers when you send externally. Send yourself an email to a gmail account. I doubt that SPF = pass , for external messages as well.
I’m using NAT for IPv4, so it can send and receive on it as well. DNAT (port forward) for incoming, SNAT for outgoing. This is all due to using containers (incus) on a rented server which has 1 IPv4 but a routed /64 IPv6.
I don’t have any issues sending to gmail, but I added _smtp._tls records specifically for them to debug another issue (I changed my email hostname and the mta-sts record was still in their cache with the old values, 7 day TTL…).