On Saturday, September 26, 2020 3:59:50 PM EDT Dave Crocker wrote: > On 9/26/2020 8:41 AM, Scott Kitterman wrote: > > On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: > >> Perhaps you have not noticed but the demonstrated field use of DMARC, to > >> date, tends to be contrary to the design, to the extent anyone thinks > >> that the design carries a mandate that receivers follow the directives > >> of the domain owners. > >> > >> So the text in the draft merely reflects real-world operational style. > > > > I think it's not nearly as clear as you seem to think. If the standard is > > users will not 100% do the right thing, then I agree that won't happen, > > but I don't think it's a reasonable standard. I think the standard ought > > to be that there is an overall tendency towards reduced risk. > > And there is no (or perhaps only minuscule) evidence that such a > tendency is demonstrated. > > Even the 'study' you cited uses the word 'slight'. > > The larger question is: where is the body of research and/or experience > that demonstrates the positive effect you are relying on? As far as I > know "trust indicators" have somewhere between a poor and a terrible > history. So to the extent you believe they are helpful, please produce > the body of work demonstrating it. > > My real point is that we /know/ there is a critical and demonstrably > useful -- actually, essential -- function performed by anti-abuse > filtering engines at receivers, independent of the end-user. Good ones > reduce incoming abuse down from roughly 95% of the stream to a tiny > percent. > > DMARC processing is included in some such engines' repertoire. > > The proposal adds to that, but based on the Sender: field, rather than > the From: field. > > > My claim is that this proposal is substantially at odds with the protocol > > as documented (#1). > > I disagree. > > Again, please clarify exactly how it is at odds and please explain in > detail what real-world processing of DMARC it impedes. > > > I think we agree that this proposal is at odds with DMARC as documented. > > We do not agree. > > Again, rather than making a broad claim, please provide actual detail to > substantiate your claim.
Since I've been directed to stop this discussion by one of the chairs, I guess we'll save it for last call. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
