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

[Scott Kitterman <[e-mail]>]

On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
> On 9/25/2020 4:00 PM, Scott Kitterman wrote:
> > In my view the linkage between the identity in From to domains
> > authenticated by DKIM and SPF (d= and mail from) is a fundamental
> > property of DMARC.  If you change that, it's not DMARC anymore.
> 
> It doesn't change that.  It doesn't alter the current use of the From:
> field.
> 
> Mediators might, and so far people have thought that acceptable.
> 
> My suggestion is that you offer some detailed analysis of current
> security-related processing and specify how that will change to the worse.
> 
> The tendency for these topics is for people to make overly-terse,
> overly-broad assertions and conclusions, without any of the detail that
> permits validating the claim.

Sure it does, given what DMARC is.

I think the obligation to justify is on the advocate for change.  Having 
reviewed a large pile of messages from this list to try and catch up, I may 
have missed it, but I haven't seen any justification for this other than you 
claiming it's true:

   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.

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.  DMARC is based on an expectation that specific actions ought to be 
taken based on policy [1], which is totally different than what this draft 
proposes. Which, to circle back around, is why I don't think it would be DMARC 
anymore.

Scott K

[1] RFC 7489, Section 6.6.2, Step 6:

   6.  Apply policy.  Emails that fail the DMARC mechanism check are
       disposed of in accordance with the discovered DMARC policy of the
       Domain Owner.  See Section 6.3 for details.