Slightly 'off-thread' but want to point out that the idea of 'soft-fail'
is not universal..
Personally, we believe that if someone advertises a HARD FAIL, it should
be rejected in the SMTP transaction.. And SOFT FAIL, if from a source
that especially vulnerable to forgeries, and/or targeted in the wild,
and especially risky for the recipient (eg Banks, Package Delivery,
Government institutions etc) then it still should be rejected before the
recipient ever sees it and falls victim. However, that decision can't
be universal..
We implemented KSF (Known Sender Forgery) based on the advertised SPF
records, implemented in the SMTP layer.. but for specific use cases.
Eg, WideSpread forgeries in the wild, Sensitive Source, High RIsk
Usually, a single forgery of a domain with a proper and valid SPF record
+ a HARD FAIL, is enough to warrant KSF addition. Many forgeries with a
SOFT FAIL, is also enough to warrant a KSF addition.
This is because while we CAN assume that the person writing the SPF
record intended us to behave this way, far too many SPF records exist
out there that don't meet the criteria, and are simply what people put
in by default to keep operators like Google happy..
Of course, all the remote forwarding tends to break, and cause back
scatter, but that is a different problem, dealt with by stopping remote
forwarding or doing sender rewrites.
But the whole point of the SPF efforts have been so that domain owners
can make a 'declaration' of where email related to their domain comes
from, and we should honour that.
Not sure if this helps the conversation or not.
On 2024-06-27 11:50, Ted Smith via mailop 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
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
