On Fri, Apr 14, 2023 at 5:55 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote:
> 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. > You have it absolutely backwards. DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it passes. Michael Hammer > 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> wrote: > >> >> >> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy <superu...@gmail.com> >> wrote: >> >> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <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> wrote: >>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <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 >> https://www.ietf.org/mailman/listinfo/dmarc >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
