On 4/16/2023 8:43 PM, Neil Anuskiewicz wrote:
Hector, respecfully, I disagree with several of your points.
* You seemes to be saying that when spf fails then usually dkim
fails, too. I’ve seen first hand that’s nit true.
Yes, most of the times. The exceptions are the true forwards. It's
easily resolved. Have the user prepare to pick up the mail.
* you seemed to be placing too much weight on the value of spf
hardfail. Even 10 years ago, few receivers rejected on an spf hardfail.
I was one of the early adopters among aol.com and others to promote
hard fails early on because it was quite evident most of the time it
was a complete waste of DNS calls when its softfail or especially
neutral or NXDOMAIN.
All of my wcSMTP customers benefited from the integrated
wcDKIM/wcDMARC add-on.
As of today, after 20 years of daily data collection, SPF offers 6.3%
of the INCOMING total rejection rates. It was a slow climb. None are
forwarding problems.
I'm pretty sure a huge set of transport outgoing logs of forwarded
mail were 55z due to SPF hardfail policies. Not the only one.
Some do but it’s not at all reliable. DMARC is accepted by most as
the new policy layer. It’s where policy should be handled. The OR
logic is in part to get away from the policy layer that breaks
fairly easily (e.g., forwarding). SPF is important but given a
choice between authenticating with just aligned SPF or just aligned
DKIM, I’d choose DKIM.
Gmail rejects forwards. Its users MUST POP to pick up there mail now.
Could you provide a citation for the following claim:
“Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if
available would also fail. So the payoff is high to short-circuit
and lowered when you needless transfer a potential large and harmful
payload.”
I’m skeptical and I’d imagine some others are too so a cite would go
a long way. Thanks.
I have 20 years of collected daily stats here:
https://winserver.com/public/spamstats.wct
By the way, the #1 rejection method is the CBV - Call Back Verifier.
Comes from the Modem Caller ID days where you check the client's ID.
Check out the stats!!
SPF started as an IP::DOMAIN association. In started during MARID.
The early 2000 emergency IETF working group to help address the spoof
problem to the tune of $13B dollars in the industry. Yes, I remember
the news number. :-)
I've implemented many of the LMAP IP::DOMAIN proposed; DMP, RMX and
SPF was somewhat of a blend. I was there with this. Did you know
Microsoft still has their early version of SenderID in XML format? It
came with a _ep. subdomain, so please do a DNS TXT up for _ep.hotmail.com
"<ep xmlns='http://ms.net/1'
testing='true'><out><m><indirect>list1._ep.hotmail.com</indirect><indirec
t>list2._ep.hotmail.com</indirect><indirect>list3._ep.hotmail.com</indirect></m></out></ep>"
Since day one. I was there.
DKIM came with a ADID::SDID association (author, signer) and that was
defined via policy, starting with SSP, reduced to ADSP and replaced as
DMARC with the same ADSP problems. But Levine did not believe anyone
would honor the hard policies. He was wrong, right?
The problem since day one was that we can't resolve the 3rd party
association, the ADID::SDID authorization missing piece.
Anyway, there are far too much waste in electronic mail, ADSP/DMARC
and this quest to resolve its issues, creating more junk, ARC, is not
getting anywhere.
Hence, until I have more confidence in whats being developed, I will
always go the route of optimization and in this case, SPF hard
failures are rejected before the DATA payload. Any forwarded issue is
resolved by the originator fixing issues, the MDA whitelisting, or
prepare the user to POP3 pick up the mail. Everyone happy now.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
