Hello,
I'm the systems administrator working with the mailsystem in question,
and wanted to add some details to this.
We are on the receiving end of the email transaction, I've checked and
tested our spf configuration, using postfix-policyd-spf-python, and for
all my tests I see us properly accepting and adding headers to the email
on a softfail. I've noth been able to replicate any rejections. The
cases where we are seeing the email rejected when the senders SPF
indicates a softfail occure with email forwarded through servers within
outbound.protection.outlook.com. These are emails where a client is
using outlook for mailforwarding to an email account hosted with us. An
example log is below, client indentifying info redaced of course.
Jun 27 17:33:58 ezm03-pco postfix/smtpd[224404]: NOQUEUE: reject: RCPT
from mail-mw2nam12rlnn2057.outbound.protection.outlook.com[40.95.45.57]:
550 5.7.23 <f...@provisionsales.com>: Recipient address rejected:
Message rejected due to: SPF fail - not authorized. Please see
http://www.openspf.net/Why?s=helo;id=nam12-mw2-obe.outbound.protection.outlook.com;ip=40.95.45.57;r=REDACTED;
from=<REDACTED> to=<REDACTED> proto=ESMTP
helo=<NAM12-MW2-obe.outbound.protection.outlook.com>
now, when you check for an SPF record based on the helo name, you find
the following
;; ANSWER SECTION:
NAM12-MW2-obe.outbound.protection.outlook.com. 3600 IN TXT "v=spf1
include:spf.protection.outlook.com -all"
So there we have the hard fail, and when you check that include:
;; ANSWER SECTION:
spf.protection.outlook.com. 521 IN TXT "v=spf1 ip4:40.92.0.0/15
ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17
ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49
ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51
ip6:2a01:111:f403:f000::/52 -all"
you see that the IP listed in the log, 40.95.45.57, is not included in
the ranges within that list. That conbined with the hard fail indicated
could account for the rejection of the message, except that I don't
understand why the SPF check would be done for the helo hostname of the
forwarding server, and why that result would take precidence over the
SPF result for the actual sender domain.
Since SPF is supposed to verify that the senders, why would
postfix-policyd-spf-python be looking up the SPF record for the helo
hostname of the forwarding mailserver and determining what to do based
on that? If my explanation is correct there is clearly something I'm
missing about SPF enforcement, or is there some other possible
explanation I'm unaware of?
Thank you
Ted
easyDNS Technologies
On 2024-06-27 11:27, Mark E. Jeftovic via mailop wrote:
Been debugging an email forwarding problem, it's basically that the
forwarder doesn't use SRS or ARC
That would be an SPF fail, but the sender domains are ~all
Why the hard bounce?
* Sender address: ~all
* The forwarded address has -all
* Receiving server rejecting with notice about sender address SPF fail
Is the final destination server somehow taking the -all from the
intermediary address SPF?
What is it about this I'm not getting?
- mark
--
Mark E. Jeftovic <mar...@easydns.com>
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
