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

From: Tim Wicinski <[email-masked]>
Date: Fri, 25 Sep 2020 10:01:05 -0400

All

This call for adoption ended a few weeks ago, I have been recalcitrant in
following up.   The chairs feel
there is enough consensus to adopt this work in DMARC.   While there were
issues raised, the chairs feel
they can be addressed through the document process.

thanks
tim

On Mon, Aug 24, 2020 at 2:00 AM Hector Santos <hsantos=
[email-masked]> wrote:

> On 8/21/2020 3:09 PM, Jim Fenton wrote:
>
> > On 8/15/20 3:53 PM, John Levine wrote:
> >> Assurances that are provided by ADSP are generally obtained out of band
> in the
> >> real Internet, and not through ADSP.  Current deployment of ADSP is not
> >> recommended.
>
> > Is that not exactly the same situation with DMARC, except that the
> > policy in question now is "reject" rather than "discardable"? Yes,
> > it's just a keyword, but it reflects the semantics of the expected
> > action as well.
> >
> > -Jim
>
> No one was expected to follow a reject, so it was said, until it did
> happen.  SPF pushed
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 25 Sep 2020 14:59:42 -0400

Dave Crocker reminded me that we were going to adopt this document as
Experimental. I was remiss in not mentioning that.

Even though the WG adopted this document, it was said during the call that
the WG may not be able to come to a consensus to move the document
forward.   Adoption does not mean published (see: ARC Usage).

tim

On Fri, Sep 25, 2020 at 10:01 AM Tim Wicinski <[email-masked]> wrote:

>> >> Assurances that are provided by ADSP are generally obtained out of
>> band in the

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Sep 2020 16:46:54 -0400

I'm sorry this came up during a period when I wasn't following the list.  
Having caught up recently, I completely agree with the allusions to Sender ID.  
I don't think this his helpful.  If something like this is going to be 
standardized, it shouldn't be called DMARC because it's not.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Sep 2020 14:25:38 -0700

On 9/25/2020 1:46 PM, Scott Kitterman wrote:
>   If something like this is going to be

That was cryptic. Please elaborate on your concerns.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Sep 2020 19:00:04 -0400

> That was cryptic. Please elaborate on your concerns.

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.

Clearer?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Sep 2020 16:05:22 -0700

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

d/

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Sep 2020 19:21:22 -0400

On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker 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.
> 

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.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Sep 2020 20:03:51 -0700

On 9/25/2020 4:21 PM, Scott Kitterman 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.

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

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Sep 2020 12:31:41 +0200

On Sat 26/Sep/2020 05:03:51 +0200 Dave Crocker wrote:
> 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/
> 
> "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..."

A pointer to a better aimed report circulated on this list:
*End-to-End Measurements of Email Spoofing Attacks*
https://www.usenix.org/conference/usenixsecurity18/presentation/hu

They say:

    Our phishing experiment shows that security indicators
    have a positive impact on reducing risky user actions,
    but cannot eliminate the risk.

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

Some organizations are very careful at setting DMARC policies.  Paypal is a classic example, as they don't allow protected transactional domains to be casually used by humans.  Such organizations need to be able to explicitly opt out of the Sender experiment.  Other organizations may want to opt in, possibly allowing a limited class of mediators.

The real word bond is something along the lines of /I tell you how to discard phishing, how you protect your users is up to you/.  Some receivers focus more on MTA filtering, other focus on security indicators.  Both actions depend on the DMARC policy published at the From: domain.  If the From: domain participates in the Sender experiment, then the policy at Sender: may be relevant as well.

Best
Ale
--

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 26 Sep 2020 08:55:33 -0400

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 <[email-masked]>
Sent: 9/25/20 11:04 PM
To: Scott Kitterman <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
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.

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.

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.

Google to bury indicator for Extended Validation certs in Chrome because users barely took notice

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

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Sep 2020 06:06:54 -0700

> A pointer to a better aimed report circulated on this list:

An unrefereed presentation (not paper) about a single experiment is 
better than a summary of an industry-wide effort that failed?

And the presentation cited SMTP Mail From, as if that were the important 
field to protect. (And it doesn't even mention DKIM.)

Also, the researchers appear not to know about the issue of co-variates. 
(eg, 21% of their subjects had graduate degrees...)

And, for the current discussion, there's the troublesome summary the 
they give about their own study:

> 1. Warning only slightly lowers the click rate
> 2. The absolute click rate is still high

The key words there are "slightly" and "still high".  Prompting the 
question of why anyone would think this study serves as demonstrating 
strong support for the role of end-users in abuse protection?

All of which demonstrates a basic problem with efforts to discuss 
human-related work: difficulties in understanding how to evaluate 
research and research patterns, with a tendency to instead lean on 
confirmation bias.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Sep 2020 06:42:47 -0700

On 9/26/2020 5:55 AM, Douglas E. Foster wrote:
> but you apparently choose not to hear. 

that's an ad hominem.

Chairs?

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 26 Sep 2020 11:41:41 -0400

> in this case means the claim that this proposal somehow 'breaks' or

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.

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

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

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 26 Sep 2020 12:33:19 -0400

And here we were getting along so well!

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical
points, and you are
welcome to have your own opinion on whether he chooses to hear or not.  But
those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care
about this issue. That's
a good thing.

For the record, I'm a DNS person.  I see most problems as being solved with
more DNS, or less DNS.
I will say that I have had "passionate discussions" with Mr Crocker on
several issues and I found that
it was not that he did not listen, but figuring out how to better explain
my point of view.
Surprisingly to many, he does listen.

Whether this work is in scope for DMARC or not, I would plead guilty for
not considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until
it is not in scope.
These types of discussions I was leaning on Seth, Alexey and of course
Murray the AD.

thanks for listening.
tim

On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> 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 <[email-masked]>
> *Sent*: 9/25/20 11:04 PM
> *To*: Scott Kitterman <[email-masked]>
> *Cc*: IETF DMARC WG <[email-masked]>
> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the
> RFC5322.Sender Header Field
>
> 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.
>
>
> 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.
>
> efficacy of DMARC.  I don't recall seeing any research results validating
> such a view, but perhaps I missed it.
>
> *Google to bury indicator for Extended Validation certs in Chrome because
> users barely took notice*
>
>
> 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..."
>
>
> 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.
>
> Brandenburg InternetWorkingbbiw.net
>

---

From: "John Levine" <[email-masked]>
Date: 26 Sep 2020 13:19:07 -0400

>> but you apparently choose not to hear. 

I thought he was already in everone's kill file.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Sep 2020 10:24:23 -0700

> I thought he was already in everone's kill file.

John, That's also an ad homen.

d/

---

From: "John R Levine" <[email-masked]>
Date: 26 Sep 2020 13:45:32 -0400

On Sat, 26 Sep 2020, John Levine wrote:

> [ something ]

My apologies, that wasn't supposed to go to the list.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 26 Sep 2020 15:07:43 -0400

My apology, Dave, for letting my frustration get the best of me.   

Doug Foster

From: Tim Wicinski <[email-masked]>
Sent: 9/26/20 12:33 PM
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical points, and you are
welcome to have your own opinion on whether he chooses to hear or not.  But those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care about this issue. That's 
a good thing.   

For the record, I'm a DNS person.  I see most problems as being solved with more DNS, or less DNS. 
I will say that I have had "passionate discussions" with Mr Crocker on several issues and I found that
it was not that he did not listen, but figuring out how to better explain my point of view. 
Surprisingly to many, he does listen.   

Whether this work is in scope for DMARC or not, I would plead guilty for not considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until it is not in scope.  
These types of discussions I was leaning on Seth, Alexey and of course Murray the AD. 

thanks for listening. 
tim

On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster <fosterd=[email-masked]> wrote:

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Seth Blank <[email-masked]>
Date: Sat, 26 Sep 2020 12:56:44 -0700

Thank you, everyone, for backing off the personal attacks and apologizing.

Now let's get back to the technical merits of the open tickets, please--
we'd like to close the current 3 out and open the next batch early next
week.

On Sat, Sep 26, 2020 at 12:08 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> *From*: Tim Wicinski <[email-masked]>
> *Sent*: 9/26/20 12:33 PM
> *To*: [email-masked]
> *Cc*: "[email-masked]" <[email-masked]>
>> 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.
>>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Sep 2020 12:59:50 -0700

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

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

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 26 Sep 2020 17:22:37 -0400

On Saturday, September 26, 2020 3:59:50 PM EDT Dave Crocker wrote:
> > 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.
> 
> > My claim is that this proposal is substantially at odds with the protocol
> > as documented (#1).
> 
> I disagree.
> 

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

---

From: [email-masked]
Date: Sat, 26 Sep 2020 15:21:00 -0700 (PDT)

> ...

> EV UI does not protect users as intended... users do not appear to make

To be fair, this is looking at positive security indicators, not negative
ones. But there are plenty of other studies looking at the more general
case. Here's one that seems relevant to DMARC:

   Do Security Toolbars Actually Prevent Phishing Attacks?
   https://dl.acm.org/doi/pdf/10.1145/1124772.1124863

   Abstract:

   Security toolbars in a web browser show security-related
   information about a website to help users detect phishing
   attacks. Because the toolbars are designed for humans to
   use, they should be evaluated for usability - that is, whether
   these toolbars really prevent users from being tricked into
   providing personal information. We conducted two user
   studies of three security toolbars and other browser security
   indicators and found them all ineffective at preventing
   phishing attacks. Even though subjects were asked to pay
   attention to the toolbar, many failed to look at it; others
   disregarded or explained away the toolbars' warnings if the
   content of web pages looked legitimate. We found that
   many subjects do not understand phishing attacks or realize
   how sophisticated such attacks can be. 

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 26 Sep 2020 18:50:17 -0400

> we'd like to close the current 3 out and open the next batch early next

Is the context in terms of the protocol specified by RFC 7489?

That may sound like a silly question, but I think fundamentally if "DMARC" is 
just an input to a filter or if "DMARC" is a protocol to reject/quarantine 
email that meets certain policy criteria makes a big difference in how some of 
these questions are addressed.

If I'm going to dive into details, I want to first make sure I understand the 
context.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Sat, 26 Sep 2020 16:23:09 -0700

> Is the context in terms of the protocol specified by RFC 7489?

Yes.

> these questions are addressed.

The goal of DMARCbis is to take the independent stream informational RFC
7489 and drive it to an IETF stream standards track document that
represents IETF consensus. So this work is explicitly around DMARC as a
protocol that describes how a domain owner transmits its policy for mail
that does not authenticate to a mail receiver.

Further, our charter takes the usefulness of DMARC in its current form as
table stakes, and (to paraphrase) primarily focuses our discussion around
addressing limitations or operational concerns of the protocol.

One of the primary limitations of DMARC is when mail transits through a
forwarder that breaks authentication. For DMARC to go standards track, this
issue must be addressed. Currently ARC is the approved experiment from
Phase 2 of our Charter.

Seth, as Chair

---

From: Hector Santos <[email-masked]>
Date: Sat, 26 Sep 2020 23:30:33 -0400

On 9/26/2020 7:23 PM, Seth Blank wrote:
>
> The goal of DMARCbis is to take the independent stream informational
> RFC 7489 and drive it to an IETF stream standards track document that
> represents IETF consensus. So this work is explicitly around DMARC as
> a protocol that describes how a domain owner transmits its policy for
> mail that does not authenticate to a mail receiver.
>
> Further, our charter takes the usefulness of DMARC in its current form
> as table stakes, and (to paraphrase) primarily focuses our discussion
> around addressing limitations or operational concerns of the protocol.
>
> One of the primary limitations of DMARC is when mail transits through
> a forwarder that breaks authentication. For DMARC to go standards
> track, this issue must be addressed. Currently ARC is the approved
> experiment from Phase 2 of our Charter.
>
> Seth, as Chair

Thanks for the summary. Are any of authorized third party proposals on 
the table?

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 27 Sep 2020 11:20:45 +0200

On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:
> An unrefereed presentation (not paper) about a single experiment is better than 
> a summary of an industry-wide effort that failed?

I meant aimed at email rather than web browsing.

> And, for the current discussion, there's the troublesome summary the they give 
> about their own study:
> 
> The key words there are "slightly" and "still high".

"If one person eats a chicken and another person doesn't eat anything, on 
average they both ate half a chicken".  That's how statistics distorts reality. 
  I'm sure there are users who watch authentication results, and usually take 
no bait.  For them,  "slightly" and "still high" don't hold.

And, there's increasing activity about anti-phish employee training.  As a 
consequence, the importance of visual hints is bound to increase.

> Prompting the question of why anyone would think this study serves as
> demonstrating strong support for the role of end-users in abuse protection?

That wasn't the goal of the presentation, AFAIUI.

At any rate, I don't think that demeaning users can be a long term strategy 
toward a more evolved society.  Albeit it may work 99% of times, delegating 
decisions to a security manager is a limitation.  It is possible, at least in 
theory, that a message is considered a phish by some but not by others.  In 
illiberal countries that's all the more likely.

> All of which demonstrates a basic problem with efforts to discuss human-related 
> work: difficulties in understanding how to evaluate research and research 
> patterns, with a tendency to instead lean on confirmation bias.

That's why it is important to enable each and every soul to exert their own 
judgements.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 06:06:24 -0700

> I meant aimed at email rather than web browsing.

So?

If you think the industry-wide experiment that focused on signalling a 
trust indicator and failed is less relevant than a small, single, 
unrefereed paper about a preliminary and poorly-design research project 
is somehow less relevant, please explain.

> "If one person eats a chicken and another person doesn't eat anything, 
> on average they both ate half a chicken".  That's how statistics 
> distorts reality. 

The fact that you think this statement is somehow meaningful suggests a 
rejection of an entire, established field of study based on not 
understanding it.

> I'm sure there are users who watch authentication 
> results, and usually take no bait.  For them,  "slightly" and "still 
> high" don't hold.

Except that individual cases are not the basis for establishing 
industry-wide practice.  Industry-wide behaviors are.

An occasional example simply isn't relevant.  That's the difference that 
legitimate statistical analysis provides.

> 
> And, there's increasing activity about anti-phish employee training.  As 
> a consequence, the importance of visual hints is bound to increase.

Excellent.  So that means you can point to studies that show how 
effective such training is.  Because the general sense is in the 
anti-abuse community is that it has little effect.  But if you know of 
studies to the contrary, it would very useful to hear about them.

> That wasn't the goal of the presentation, AFAIUI.

However it /was/ the apparent reason it was cited.

> 
> At any rate, I don't think that demeaning users can be a long term 
> strategy toward a more evolved society.  Albeit it may work 99% of 
> times, delegating decisions to a security manager is a limitation.  It 
> is possible, at least in theory, that a message is considered a phish by 
> some but not by others.  In illiberal countries that's all the more likely.
> 
> 
> That's why it is important to enable each and every soul to exert their 
> own judgements.

Actually, it's not.

d/

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2020 13:16:11 -0400

>standardized, it shouldn't be called DMARC because it's not.

We (the generic we) seem to have a fundamendal disconnect about what
DMARC is for.

One group appears to believe it's about what users see in their inbox,
to ensure that the address on the From: line matches the actual
author.

The other group appears to believe it's a filtering signal that mail
systems mix into the filtering process they apply between the time the
mail arrives at the MX and the time the users sees it.

I suppose both are right to some extent, but they have very different
implications for the design.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 10:25:53 -0700

> implications for the design.

Except they aren't both right.

We know that it is used by filtering engines.

There is no evidence it is used by end-users. And there is a pretty long 
history indicating such information is NOT used by end users.

d/

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 27 Sep 2020 13:48:02 -0400

I'm confused.    

I thought we all agreed that From represents the author who is responsible for the content, and consequently it had importance to both the filtering process and the user.   I thought the issue at hand was that DMARC-induced header munging made the From address into something different then the address which best represents the author.   So it seemed like we had a lot to agree on.

Also, I thought a trust indicator was a statement like 
"The From Address is DMARC-verified", 
rather than 
"This message is from user@domain"

Which leads me to several questions
- Does the research support the idea that the From address is a trust indicator?   
- Is so, does it show that the only purpose of the From address is as a trust indicator?
- If "From" has purposes other than as a trust indicator, does it matter whether the value is correct or not?
- If it is true that the From address serves no purpose to the user, then is header munging really a problem?

DF

Sent: 9/27/20 1:26 PM
To: [email-masked]

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 27 Sep 2020 14:22:58 -0400

> to ensure that the address on the From: line matches the actual

Speaking at least for myself, not quite.  I think it's more about what users 
don't see than what they see.  I think most everyone agrees DMARC is to 
support filtering, I think the question is about how.

DMARC defines a policy set with the goal that receivers will act on that 
policy.  Specifically that receivers will reject/quarantine mail that fails 
DMARC for domains that have published such restrictive policies.

The approach defined is mechanical, not statistical.  I think that's the key 
difference.  Is it about specific policy enforcement, or is it just one more 
token for a bayesian network?

> mail arrives at the MX and the time the users sees it.

This seems to me to be an odd view because no RFC is needed to use From and 
it's relationship to either DKIM signing domain or SPF validated Mail From.  
Feeding data into an algorithm has no interoperability requirements.

That doesn't mean one can't use the data this way, because anyone can that 
wants to can.  That doesn't make it the specified protocol.

> implications for the design.

Agreed.  Maybe it would help if someone who takes the latter view would 

>        Domain Owner.  See Section 6.3 for details.

I don't think that says "then toss the results into your classifier".

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 20:44:11 -0700

> it's relationship to either DKIM signing domain or SPF validated Mail From.

The DKIM d= value establishes no relationship with any other identifer, 
such as the From: field.  At all.  None.

DMARC establishes the relationship. DMARC does other things, but for the 
above suggested alternative, this is the functional difference that 
requires DMARC.

To reiterate: Among currently published specifications, without DMARC 
there is no relationship between DKIM's d= value and the rfc5322.From 
domain name.

> wants to can.  That doesn't make it the specified protocol.

It's not clear what your point is.  It's clear you believe it's a 
fundamental point, but I'm not understanding it's import.

> ...  Maybe it would help if someone who takes the latter view would

The issue is not what it says -- though it worth considering whether 
that's what it /should/ say.

The issue is how receivers actually /use/ DMARC.

There has always be a tension about how to write these statements 
seeking to affect receiver behavior.  The natural tendency is to write 
language of simple directives, such as Step 6 -- after all, that's 
common language for basic protocol behavior.

However Step 6 moves from protocol into policy.  It is based on the myth 
that receivers will blindly follow the instructions that are provided by 
sites with which the receiver has no relationship, never mind a 
contractual one.

The reality is that Step 6 results in a mandate that often produces 
unacceptable results.

Receivers, having their own quality assurance models, immediately 
adapted their actions to their own operating criteria, rather than 
following the simple, blind directives of  random DMARC publishers.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 27 Sep 2020 23:53:33 -0400

> following the simple, blind directives of  random DMARC publishers.

So we agree that you claim DMARC practice is in variance with what is specified 
and we should base the update to the specification on the usage you have 
claimed is popular?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 20:58:40 -0700

> and we should base the update to the specification on the usage you have

Depends on the analysis of that behavior, but it's silly to ignore the 
behavior and pretend Step 6 is what will (always) be done.

Protocol specification revision efforts pay attention to established 
practice.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Sep 2020 14:02:41 +0200

On Sun 27/Sep/2020 15:06:24 +0200 Dave Crocker wrote:
>>> An unrefereed presentation (not paper) about a single experiment is better 
>>> than a summary of an industry-wide effort that failed?
>>
>>
> If you think the industry-wide experiment that focused on signalling a trust 
> indicator and failed is less relevant than a small, single, unrefereed paper 
> about a preliminary and poorly-design research project is somehow less 
> relevant, please explain.

I think an industry-wide experiment on petrol consumption has nothing to do 
with email protocols, however refereed.  Web browsing has a minor share with 
email, as some people use browsers instead of MUAs.  Browser security concerns 
are rather oriented toward shopping and EV certificates, than email phishing.

>>> And, for the current discussion, there's the troublesome summary the they 
>>> give about their own study:
>>>
> rejection of an entire, established field of study based on not understanding it.

Statistics can easily be misused.  Distinguishing a cluster of overweight 
people from starving communities doesn't reject statistics as a whole.

> Except that individual cases are not the basis for establishing industry-wide 
> practice.  Industry-wide behaviors are.
> 

The statistical aspect of email is that it is mostly spam, at varying shades of 
gray.  Meaningful messages can be regarded as occasional exceptions in this 
respect.  Nevertheless, they are important.

> Excellent.  So that means you can point to studies that show how effective such 
> training is.  Because the general sense is in the anti-abuse community is that 
> it has little effect.  But if you know of studies to the contrary, it would 
> very useful to hear about them.

Google Scholar shows me 83 results about anti-phish training effectiveness. 
Just talking about human-oriented solutions for phishing entails that users 
need to interpret visual cues.  Hence visual cues have some effect, however little.

Discarding the importance of of users judgement provides for a skewed vision.

Filtering out obvious spam can be considered a favor to users, to keep their 
mailboxes cleaner.  Yet, a deterministic protocol which determines what to 
reject and what to quarantine would relieve MX operators from the 
responsibility of arbitrary filtering based on obscure secrets.

> However it /was/ the apparent reason it was cited.

Yup.

>>> human-related work: difficulties in understanding how to evaluate research 
>>> and research patterns, with a tendency to instead lean on confirmation bias.
>>
>>

Why have elections at all if the result can be forecast before the votes are 
counted?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Sep 2020 08:29:06 -0400

On Sunday, September 27, 2020 11:58:40 PM EDT Dave Crocker wrote:
> > So we agree that you claim DMARC practice is in variance with what is
> > specified and we should base the update to the specification on the usage
> > you have claimed is popular?
> 

I haven't said anything about what we should do going forward.  I'm trying to 
establish where we are.

I never suggested it will always be done, so let's leave the straw men aside.

To clarify:

It's your suggestion that the established practice is not aligned to the 
current specification.  Specifically you believe that the policy action in step 
6 is used only rarely.

Is that correct?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Sep 2020 08:38:00 -0400

> there is no relationship between DKIM's d= value and the rfc5322.From

I just realized I neglected to respond to this part of your mail.

Right, but my mail server, my rules.  I don't need the IETF's permission to 
make such an association if I find it's a useful token for my analysis.  The 
only thing that requires any kind of formal connection is the connection to 
policy.

If you argue yourself out of the connection to policy, you've argued yourself 
out of DMARC entirely.  In order to generate the data for my classifier, it's 
entirely unnecessary to even look up the DMARC record (it might be useful as 
additional data for a more nuanced analysis, but it not needed to determine 
the relationship between rfc5322.From and DKIM d= or rfc5321.MailFrom).

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 28 Sep 2020 08:35:58 -0700

> I don't think that says "then toss the results into your classifier".

You completely ignored section 6.7 (Policy Enforcement Considerations)
which states:

> Final disposition of a message is always a matter of local policy.

Local policy could be considered "the output of some classifier" or other
mechanics left to the invention of the receiver.

This is a part of the documented DMARC spec, not a change.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Sep 2020 10:46:05 -0700

On 9/28/2020 8:35 AM, Kurt Andersen (b) wrote:
> Local policy could be considered "the output of some classifier" or 
> other mechanics left to the invention of the receiver.
>
drat.  yes.

I was far too distracted by the word 'disposed of'.  given that it is 
related to 'disposition' there's nothing semantically wrong with its use.

but given that 'disposing of' the message is a domain owner goal, 
frequently, perhaps changing "disposed of" to "processed" would be less 
inviting of misunderstanding? robustness against reasonable 
misunderstanding is helpful... (I could even squeeze in a reference to 
the Postel rule, applied to specification writing.)

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer,Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 28 Sep 2020 10:52:58 -0700

On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker <[email-masked]> wrote:

> . . .given that 'disposing of' the message is a domain owner goal,
> inviting of misunderstanding?
>

Yes, I think that, at least in American English usage, "disposal" tends to
have a bit of a pejorative connotation.  Consider that in the context of
people who have to deal with truckloads of UCE and other bulk email and the
negative association becomes even stronger.

+1 to adjusting the terminology to be less biased.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Sep 2020 20:32:58 -0400

> This is a part of the documented DMARC spec, not a change.

Yes and that would be equally true even if RFC 7489 were silent on the matter.  
Receiver always gets to decide and there's no way DMARC could pretend to 
mandate delivery and not get laughed out of the room.

It's part of the documented specification, but so is 6.6.2(6).  I think that's 
there to make it clear there's no attempt at a delivery mandate.  There's no 
interoperability or protocol associated with it.  My view is that using local 
policy to override the 6.6.2(d) domain owner policy for disposition of 
messages that do not pass DMARC checks is in the spirit of the thing, but 
pretending like DMARC policy doesn't exist is not.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Sep 2020 17:54:05 -0700

On 9/28/2020 5:32 PM, Scott Kitterman wrote:
> but

Claims of pretending seem to be popular just now.  the problem seems to 
be adequately explaing  the pretending.

So to contribute the response portion of this ritual:

    1. No one is pretending anything.

    2. Since you believe otherwise, please document it.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Sep 2020 23:58:17 -0400

What we are supposed to be working on right now is:

> Review and refinement of the DMARC specification.

I don't think elimination of policy considerations is a mere refinement.  I 
think the burden lies with the one trying to create a change in the protocol.  
That's not me, so I don't think there's anything more to say on this.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Sep 2020 09:40:13 -0400

On 9/27/2020 11:44 PM, Dave Crocker wrote:
> The DKIM d= value establishes no relationship with any other
> identifer, such as the From: field.  At all.  None.

DKIM has a single signature binding requirement, the 5322.From

> DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no 
enforcement on it nor any indication that they are related when they 
not the same (the missing link). But if they are the same domain, then 
they are viewed as self-signed and 100% related.

But who cares? A blind receiver will not know the actual relationship 
until it sees your DMARC record, if any, and we chose that to be based 
off the 5322.From domain -- the anchor field.

The DKIM POLICY augmented (add-on) technologies published (via DNS) a 
protocol expectation for a direct or indirect relationship.  DMARC 
describes a specific rule for a direct relationship. SSP had its 
rules, DSAP had its rules, and ADSP had its rules. But all of them had 
one thing in common -- an option to publish a public policy describing 
a direct and exclusive 1 to 1 relationship and a strong action is 
authorized when there is a deviation.  That was always the power of 
all this and why we are still here 15+ years.  Without it, imo, we 
would not be here. SPF would not be here if it didn't have a -ALL 
policy with strong authorization to reject with no questions asked.

> there is no relationship between DKIM's d= value and the rfc5322.From

To give you credit, you have been preaching this for at least a decade 
or more, always trying to establish non-binding relationship when the 
fact is, it is already burned into the DKIM protocol - the only header 
you MUST bind is 5322.From.  So how can it be said there is no strong 
relationship between the two identities embedded in the DKIM protocol? 
  You might be seeing this from a 3rd party list service where it 
doesn't wish to care what domains are using. It doesn't care.  It 
doesn't honor DMARC domains with restrictive policies.

DKIM policy protocol was always about providing the "authorizing" and 
"enforcement" protocol to act/respond to negative deviations from the 
published expectation for the published DKIM Mail policy.  If the 
publisher makes a public statement "I expect you to see XYZ"  But the 
receiver sees ABC, the DKIM Policy provides the receiver guidance as 
to what action is suggested.  In the case of  DMARC, we have:

p=reject (you can permanently reject)
p=quarantine (accept but put into spam box)
p=none (maybe you shouldn't judge based on DMARC deviations)

The problem, in my view, it is protocol incomplete. There are other 
scenarios not covered by the DMARC protocol syntax and language. We 
need an extended language for Domain Owners to communicate with DMARC 
processors in dealing with the deviation is a 3rd party signer domain.

So I need to see how using Sender fits into the equation. What can the 
DMARC domain owner "describe" via the 5322.From policy statement that 
says

"Please look at the Sender address using Dave's protocol steps before 
looking at the Author address"

Example, maybe using a tag.

DMARC p=reject sender=1

This offers backward compatibility. This could tell the receiver to 
consider using Dave's Sender protocol for DMARC before falling back to 
DMARC original logic. Don't try to ram Sender down DmarcBis's throat 
without some extended switch. If you want to explore an extension, a 
tag such as sender=1 could be used to trigger the a newer exploratory 
logic.

BTW, what are those steps? can it be outlined in itemized steps?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 10:26:21 -0700

On 9/29/2020 6:40 AM, Hector Santos wrote:
> not the same (the missing link). 

Absolutely not.  Please re-read the DKIM specification more carefully.  
It is quite explicit that it is doing not doing this.

To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.

> But if they are the same domain, then they are viewed as self-signed 
> and 100% related.

Not based on the DKIM specification.

To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.

> The DKIM POLICY

DKIM has no construct that qualifies as 'policy'.

To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.

d/

---

From: Dotzero <[email-masked]>
Date: Tue, 29 Sep 2020 13:30:45 -0400

> need to point to the documentation that supports that view.

Even though Dave and I may disagree on other things, he is 100% correct on
the above. This is one of the reasons we came up with DMARC.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Sep 2020 19:46:31 +0200

On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote:
>> DKIM binds the signer d= domain and the from.domain with no enforcement on it 
>> nor any indication that they are related when they not the same (the missing 
>> link). 
> 
> 
> Absolutely not.  Please re-read the DKIM specification more carefully. It is 
> quite explicit that it is doing not doing this.

I think that by "binding" Hector meant this:

5.4.  Determine the Header Fields to Sign

    The From header field MUST be signed (that is, included in the "h="
    tag of the resulting DKIM-Signature header field).
                        https://tools.ietf.org/html/rfc6376#section-3.4

The spec doesn't say why, but obviously holds that the From: domain is a 
specially meaningful one.  There are various other passages, for example:

    The order in which Verifiers try DKIM-Signature header fields is not
    defined; Verifiers MAY try signatures in any order they like.  For
    example, one implementation might try the signatures in textual
    order, whereas another might try signatures by identities that match
    the contents of the From header field before trying other signatures.
                        https://tools.ietf.org/html/rfc6376#section-8.15

(I think this can be an answer to part [2] of ticket #38.)

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 10:56:14 -0700

On 9/29/2020 10:46 AM, Alessandro Vesely wrote:
>> Absolutely not.  Please re-read the DKIM specification more 
>> carefully. It is quite explicit that it is doing not doing this.
>
>
> The spec doesn't say why, but obviously holds that the From: domain is 
> a specially meaningful one.  There are various other passages, for 
> example:

Sigh,  yes. It has caused this misunderstanding, from the start.

It was imposed on the working group by an IETF Area Director and was 
agreed to as an expedient.

But, sigh, no. It does not carry any of the semantic import being 
claimed in the current discussion.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 13:23:20 -0700

> claimed in the current discussion. 

I meant to also include:

Section 3.11:

> To the extent that a receiver attempts to intuit any structured
>     semantics for either of the identifiers, this is a heuristic function
>     that is outside the scope of DKIM's specification and semantics.
>
>     Hence, it is relegated to a higher-level service, such as a delivery-
>     handling filter that integrates a variety of inputs and performs
>     heuristic analysis of them.
>
>        INFORMATIVE DISCUSSION: This document does not require the value
>        of the SDID or AUID to match an identifier in any other message
>        header field.  This requirement is, instead, an Assessor policy
>        issue.

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Sep 2020 18:41:19 -0400

> need to point to the documentation that supports that view.

It began with the theory, and first implementation DomainKeys and its 
built-in policy tag "o=". Followed by DKIM early drafts with its 
enhanced signature and extended policy tag "o=" formerly known as SSP 
when separated from DKIM to create DKIM-BASE and ADSP as WG proposed 
standard work items, ADSP poisoned, returns as DMARC, since then.

Since the very beginning, my implementation, one of the better 
implementations of DKIM in the market, algorithmically and 
programmatically, follow the DKIM-BASE, DKIM-POLICY process model 
which binds, at a minimum, the RFC5322.From header, with a signer 
domain with an inherent and implicit and explicit intent and reason 
for this association.

Per the abstract, my experience suggest the question has never been 
answered, nor the association separated from the original concept.

Do you have an algorithm that replaces the current one?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 15:54:11 -0700

> Do you have an algorithm that replaces the current one? 

I've no idea what any of your note has to do with the DKIM protocol 
specification.

By way of a small example, DKIM does not have o=.

But really, nothing in your note concerns the published and approved 
specification.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 16:06:58 -0700

d/

---

From: Brandon Long <[email-masked]>
Date: Tue, 29 Sep 2020 17:54:41 -0700

Lacks backward compatibility:
If we adopt the Sender header as a method to work around DMARC, it is
obviously a simpler thing to do than ARC, doesn't provide quite as much
(but what it provides may be sufficient)... but still suffers from one of
the main issues with ARC, which is that it requires widespread adoption to
replace some of the other workarounds.

Ie, a mailing list that adopts the Sender header still won't know when it
can do that over rewriting.

Shouldn't be separate as defined:
The Sender header proposal is also an adjunct directly to DMARC itself,
changing the existing dmarc policy evaluation in a direct way.  I don't
think that should be done by a separate spec, if we do decide to, it should
be part of the DMARC spec itself, especially so we can explore all the ways
that it changes the existing spec.  I agree with others who have said that
adding this makes DMARC not DMARC, though I'm willing to explore that in
more depth.  I understand Dave's points regarding user level signals, but I
think alignment benefits in other ways.

If you instead wanted to add it as a separate thing, I don't think it
should be couched as overriding DMARC like it does, but as the same way we
expected ARC to override DMARC, as a well defined local policy override.

Really bad third party signing:
I've objected in the past to various third party signing approaches as
being non-starters for high value domains.  Google does not use SPF's
include mechanism, and is not going to list hundreds of possible third
parties as "ok" for signing to cover all possible mailing lists that are
employees work on.

In some sense, the Sender override is basically third party signing without
any actual relationship... which is both good and bad.  It's bad in that
anyone can now send a phishing message... but I guess anyone could have
before as well.  It's bad in that we wouldn't say "yes, this is fine" for
any specific sender... but now we're more at the whim of the receivers.

It's good in that maybe it standardizes a kind of local policy override.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 29 Sep 2020 19:00:59 -0700

Another issue, I think we should investigate how various systems display
(or not) the Sender header.  My understanding was that Outlook in
particular displayed it, and so encouraging it's widespread use could have
unexpected consequences.

It may be that it already displays it in a way that makes sense in the way
it's used, I think Gmail's display of Sender is (it'll add a "via sender
address" in some circumstances, which seems compatible).

Brandon

On Tue, Sep 29, 2020 at 5:54 PM Brandon Long <[email-masked]> wrote:

> In some sense, the Sender override is basically third party signing
> without any actual relationship... which is both good and bad.  It's bad in
> that anyone can now send a phishing message... but I guess anyone could
> have before as well.  It's bad in that we wouldn't say "yes, this is fine"
> for any specific sender... but now we're more at the whim of the receivers.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 29 Sep 2020 21:26:31 -0700

> think alignment benefits in other ways.

The intended status of the document is Experimental.  My assumption from
that is that we (the community at large) should go try this and see if it's
effective.  If it is, it's up for consideration to be folded into the
DMARCbis work.

This is the method proposed for the PSD document as well, and it has the
same status.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Sep 2020 06:34:22 -0700

On 9/29/2020 5:54 PM, Brandon Long wrote:
> Ie, a mailing list that adopts the Sender header still won't know when 
> it can do that over rewriting.

That's correct.  It won't.  But no alternative does, either.

>  I agree with others who have said that adding this makes DMARC not 
> DMARC,

As with so many comments, from quite a few people, it's a good catch 
phrase, but it does not come with any technical detail to give it 
substance and credibility.

So the fact that I disagree with the assertion, about what adding this 
feature does, highlights disagreement, rather than understanding.

So, please explain what DMARC is -- yes, I know that sounds silly, but 
it appears to be necessary for this discussion -- and how the proposal 
makes it not DMARC. That's a request for technical detail, not quick 
opinion.

I'll put this meta-problem a bit differently:  People are locked into 
very narrow and mechanical views of the DMARC work.  We need, instead, 
to be thinking in pragmatic terms of threats, mitigations, effects and 
side-effects, and we need to be doing this with technical detail, not 
facile catch phrases.

> though I'm willing to explore that in more depth.  I understand Dave's 
> points regarding user level signals, but I think alignment benefits in 
> other ways.

Please enumerate those.

> should be couched as overriding DMARC like it does, but as the same 
> way we expected ARC to override DMARC, as a well defined local policy 
> override.

The word "override" does not appear in my draft.  Nor should it. Nor 
should it appear in these discussions.  Its use is a fundamental 
misrepresentation of what DMARC does.

If you are going to the grocery and I say you should buy healthy food 
and you come back with tasty, unhealthy food, did you "override" me?

If I am a passenger and you are driving and I say turn left here and you 
don't, did you "override" me?

The answer in both cases is no.  Advice was offered and ignored. There 
was no "override" of the advice.

That's DMARC.  The receiver has no obligation, nor even an expectation, 
of following the domain owner's request.  So "override" fundamentally 
misrepresents the role and authority of the domain owner (and of the 
receiver).

> parties as "ok" for signing to cover all possible mailing lists that 
> are employees work on.

What does Google see as the long-term role and use of ARC?

Isn't it to allow From: field DMARC failure but still permit delivery of 
the message?

> without any actual relationship...

From: field re-writing is also a form of third-party 'override'. It's 
merely uglier, with significant recipient side-effects.

That is, it seeks to give the recipient -- the actual user -- something 
akin to what they would have gotten from the original From: field, but 
in a way that breaks assorted recipient handling benefits.

BY THE WAY...

It appears you are working from the original version of the 
specification and not the current one.

The current one treats the Sender: field enhancement as an ADDITION, not 
an ALTERNATIVE.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Sep 2020 22:12:38 -0400

> I've no idea what any of your note has to do with the DKIM protocol

wow.

> By way of a small example, DKIM does not have o=.

Right, you were instrumental in attempting to "separate" policy from 
DKIM to create DKIM-BASE, a success, it allowed progress to be made 
with DKIM, but it never separated the signer::author identity 
association primarily because, once again, DKIM-BASE is still 
inherently bound to the 5322.From field.  You never separated the DKIM 
anchor identity and it was stated many times, until then, we will 
always have the signer::author relationship and policy protocols based 
on this relationship.

Until it is changed, DKIM will always have this self-signed 
signer::author relationship. That goes back to DomainKeys with o=, 
early DKIM with o=, removed in DKIM-BASE as you gracefully pointed out 
but it moved to ADSP (now DMARC).

> But really, nothing in your note concerns the published and approved

Published and approved, yet seeking further comments.  From I had 
already read and understood from the start, all in once sentence:

Extract 5322.Sender, if found, use this for DMARC lookup, if not 
found, fall back to 5322.From

Correct? Anything else?

The only systems that this will work with is compliant downlink 
receivers.  Non-compliant receivers are still a problem.  At the end 
of the day, the Mailing List Server (MLS) still needs to support DMARC 
on the inbound side.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Sep 2020 19:28:43 -0700

>> I've no idea what any of your note has to do with the DKIM protocol

I'll stop now.  As far as I can tell, this really has nothing to do with 
the existing DKIM specification, nor really anything to do with DMARC.

Perhaps others on the list can find something to work with, here, but I 
give up.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Sep 2020 19:37:15 -0700

Hector, please constrain your comments to the technical matters at hand,
not the actions of others.

This thread is veering towards ad hominem attacks which will not be
tolerated.

Seth, as Chair

--

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Sep 2020 23:05:36 -0400

Seth, Selectively quoting of comments and not answering any technical 
comments or questions should also not be tolerated. It waste people 
time especially which rudely told we lack substance and credibility. 
This damages people's reputation when he torts engineers in these IETF 
forums.

Did you say anything to him? Should that be tolerated?

I'm trying my best to participate without the snide remarks and 
reputation hurting remarks. I take it very personal because I have 
seen how it can
hurt people.  He should stop doing that.

-- 
Hector Santos, CTO/CEO
Santronics Software, Inc.
https://secure.santronics.com
https://twitter.com/hectorsantos

On 9/30/2020 10:37 PM, Seth Blank wrote:
> Hector, please constrain your comments to the technical matters at
> hand, not the actions of others.
>
> On Wed, Sep 30, 2020 at 7:12 PM Hector Santos
> <hsantos=[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     [email-masked] <mailto:[email-masked]>
> *Seth Blank*| VP, Standards and New Technologies
> *e:[email-masked] <mailto:[email-masked]>
> *p:*415.273.8818
>
>
> This email and all data transmitted with it contains confidential
> and/or proprietary information intended solely for the use of
> individual(s) authorized to receive it. If you are not an intended and
> authorized recipient you are hereby notified of any use, disclosure,
> copying or distribution of the information included in this
> transmission is prohibited and may be unlawful. Please immediately
> notify the sender by replying to this email and then delete it from
> your system.
>
>
>

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Sep 2020 21:37:38 -0700

Hector, the chairs hear your frustration, thank you for not escalating
further, and would be happy to speak with you off list on the matter.

--