Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC failure. In standard boolean logic is it an OR condition: IF SPF FAILS or DKIM FAILS Then Reject. I hope you can understand this technical implementation detail. — HLS > On Apr 14, 2023, at 5:44 PM, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > Hector, it sounds like you are saying that SPF is all we need, so scrap > DMARC. If it is something else please clarify. > > Doug > > On Fri, Apr 14, 2023, 4:44 PM Hector Santos > <hsantos=40isdg....@dmarc.ietf.org <mailto:40isdg....@dmarc.ietf.org>> wrote: >> >> >>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy <superu...@gmail.com >>> <mailto:superu...@gmail.com>> wrote: >>> >>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <ves...@tana.it >>> <mailto:ves...@tana.it>> wrote: >>>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: >>>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" >>>> > <superu...@gmail.com <mailto:superu...@gmail.com>> wrote: >>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <ves...@tana.it >>>> >> <mailto:ves...@tana.it>> wrote: >>>> >> >>>> >>> Heck, MLMs should start rejecting messages sent from domains that >>>> >>> publish a >>>> >>> blocking policy *when they fail authentication on entry*!! >>>> >> >>>> >> That's not enough to avoid the damage we're talking about. >>>> >>>> Agreed. Yet, it is a sane half-way between crazy rejecting always and >>>> completely ignoring ABUSE. >>> >>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection >>> of messages merely because they fail authentication on ingress. >> >> And respectfully, SPF always had a strong reject, hard fail policy concept >> since it's LMAP R&D upbringing — immediate rejection, 55z rejection code. >> >> Why Not? It was optimized. It served a purpose to address spoofs. Partial, >> Neutral and Unknown results were possible. That was suppose to be feed to a >> heuristics, highly subjective Reputation Engine. After exactly 20 years of >> data, SPF rejection rate is 6.3% of the incoming rejection reasons. >> https://winserver.com/public/spamstats.wct >> >>>> I agree there are better solutions, but they're not yet developed. As >>>> ugly as >>>> it may be, From: munging is the emerged solution. It is a _fact_. Now >>>> repeat >>>> again that the IETF standardized facts, not theories... >>> >>> Let's put the challenge back on you: Where's your evidence that From >>> munging is the emerged consensus solution that this working group should >>> standardize? Where is this _fact_? If we advance that as a Proposed >>> Standard, the community will quite reasonably ask why we think this is >>> true, and we're going to need to be able to answer them. If working group >>> consensus agrees, then away we go. >> >> As much as I am an original mail engineering purest (anyone here ever work >> with Fidonet?) and therefore consider it to be a fundamental taboo to >> destroy originating copyrighted authorship of anything, the MLS/MLM needs to >> evolve to handle the various 1::many broadcasting distributions under a new >> security umbrella. >> >> Because the current DMARCbis umbrella ist not providing 100% coverage, for >> the MLS./MLM, it needs to do one of two things; restrict >> subscription/submissions or strip the security and rewrite the copyrighting >> authorship, perpetuating a potential harm including legal. >> >> The latter is not preferred. The former would be normal part of a protocol >> complete algorithm. You would do the former always. It’s the easiest. No >> need to modify the MLS. Just the MLM low code provisional scripts. >> >> — >> HLS >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org <mailto:dmarc@ietf.org> >> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
