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

["Douglas E. Foster" <[e-mail]>]

The problems with your proposal have been well documented, but you apparently choose not to hear.   The single paragraph that Scott quoted has multiple problems within it.

The group has considered other and better technical proposals (conditional signatures, ATSP, RHSWL), but they have all been dropped because the group did not believe that Domain Owners would have any desire to implement them, and because Mailing List Operators would have no way of knowing which mailing lists had implemented the new feature.

If you have solutions to these problems, please put them forward.   Otherwise, why are we dragging this back up?

----------------------------------------

From: Dave Crocker <[e-mail]>
Sent: 9/25/20 11:04 PM
To: Scott Kitterman <[e-mail]>
Cc: IETF DMARC WG <[e-mail]>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

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.

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_certificates/

"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.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net