Re: [dmarc-ietf] Signaling MLMs

[Hector Santos <[e-mail]>]

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