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
