> Hey, > Thanks for the reply > > On 2024-06-27 16:43, Brandon Long wrote: > > > > > At least in the past, some other types of auth failures at MS would result > > in an SPF specific bounce message, including DKIM issues when they broke > > signatures and tried to forward. I have no idea if this is still the > > case. > > > > Perhaps, but this failure isn't at MS, but from MS at our servers. > > For whatever reason, contrary to it's configuration and usual tested > > behaviour, our own server is for some reason rejecting email from this > > specific source when the sender SPF record should indicate a softfail, > > which we accept and lable. The behaviour would make sense based on the > > hostname in the helo, but there is definately a clear From header for these > > messages so if I'm understanding what you and Adam are saying correctly > > that hostname should not come into it. Which is what I would have > > thought. > > Intersting about why those IPs wouldn't be in the range, it still seems like > this shouldn't be happening based on our configuration unless there is some > other reason the helo record might be checked. > > I'm still trying to figure out why our servers would be behaving so > differently when receiving email from this specific source than it does for > all other SPF softfails. > > Thank you > Ted > easyDNS Technologies > > > > > > > > > > > > The other thing you ask, if there is no sender (ie a bounce from <>), you > > do spf based on the helo domain. > > > > Oh, another thing some people may do when forwarding from shared > > infrastructure is to forward through outbound servers deliberately not > > covered by the IP range, so forwarded messages don't acquire SPF auth via > > forwarding. > > > > > > > > Brandon > > > > > > > > > > > > On Thu, Jun 27, 2024 at 11:53 AM Ted Smith via mailop <mailop@mailop.org> > > wrote: > > > > > > > > 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 > > >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
