Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Scott Kitterman <[e-mail]>]

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