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

[Scott Kitterman <[e-mail]>]

On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote:
> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
> > On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
> > I think the obligation to justify is on the advocate for change.
> 
> That means you are demanding I prove  negative.  Which, of course, is an
> impossible assignment.
> 
> Rather, the obligation is on the person claiming the affirmative, which
> in this case means the claim that this proposal somehow 'breaks' or
> otherwise hurts DMARC.

I suspect we are going to continue to disagree on this, but I think it's a 
very odd claim that your assertions should be assumed to be correct.

> >      Because the current email protection behavior involves the
> >     
> >     RFC5322.From field, and pertain to the human author, it is common to
> >     think that the issue, in protecting the field's content, is behavior
> >     of the human recipient.  However there is no indication that the
> >     enforced values in the RFC5322.From field alter end-user behavior.
> >     In fact there is a long train of indication that it does not.
> >    
> >    Rather, the meaningful protections actually operate at the level of
> >    
> >     the receiving system's mail filtering engine, which decides on the
> >     dispostion of received mail.
> > 
> > Please provide references for your long train of indications, speaking of
> > making overly broad assumptions.  If that's accurate, I'd like to
> > understand the data that tells us that.
> 
> I'm not going to do that, because there's a long history of that work
> being ignored, in spite of it being reviewed repeatedly in thse and
> related fora over the years.  It's gotten tiresome to have people
> claiming an effect that they lacks evidence for, and the data to the
> contrary that they are somehow unaware of.
> 
> Again, the real requirement is focus on the affirmative.
> 
> In this case, an affirmative claim that end-users are relevant to the
> efficacy of DMARC.  I don't recall seeing any research results
> validating such a view, but perhaps I missed it.
> 
> Well, ok, here's one that shows lack of efficacy, and it's a big one: 
> EV-certs
> 
> /Google to bury indicator for Extended Validation certs in Chrome
> because users barely took notice/
> 
> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_cer
> tificates/
> 
> "The reason is simple. "Through our own research as well as a survey of
> prior academic work, the Chrome Security UX team has determined that the
> EV UI does not protect users as intended... users do not appear to make
> secure choice..."
> 
> > If this is just an input into an algorithm, then your assertion that you
> > are only providing another input is supportable, but that's contrary to
> > the DMARC design.
> 
> 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.

Somewhat related to your example, these things aren't always entirely 
straightforward:

https://emilymstark.com/2020/07/14/debunking-the-users-always-click-yes-myth.html

However, I suspect we are not going to agree on that either.

Relative to the does this proposal change DMARC question, based on your 
feedback, I think we actually mostly agree.

Any protocol exists in at least two variants:

1.  As documented in specifications such as RFCs

2.  As used in the real world.

Ideally those would be identical, but they never are.

My claim is that this proposal is substantially at odds with the protocol as 
documented (#1).  If I understand your position correctly, you are claiming 
that your proposal is aligned to the protocol as actually used (#2).

Is that correct?

Assuming that it does for a moment to save a round trip on emails:

I think we agree that this proposal is at odds with DMARC as documented.  Is 
it correct that you believe the WG can/should ignore that and focus on DMARC 
as it is used operationally?

Scott K