Subject: [dmarc-ietf] What if... Sender:

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Jun 2020 11:49:11 -0700

Folks,

This note is partially triggered by Mike's note this morning, but isn't 
specifically responding to it.  Rather it tries to elaborate on a 
premise I've been implying but haven't been explicating:

      What if the rfc5322.Sender field were typically/always present?

      Or at least, what if it were always present for domains publishing
      DMARC records?

What if messages generally had Sender: fields, even when they are the 
same as the email address of the From: field?  So for such domains the 
From: really would only be the author information and the Sender: would 
be the operational handling/sending information.(*)

The thrust of my reference to making a separate Sender: field prevalent 
is an assumption that the patterns of evaluating email addresses could 
adapt to take advantage of the reliable distinction.  For one thing, it 
could clarify the nature of the information used for filtering. 
Currently we conflate 'handling agent' (or 'transmission agent') 
information with 'authoring agent' information.

This leads to statements about end-user effects that actually are 
fundamentally wrong, even as the use of supposed author address 
information is demonstrating filtering efficacy.  What would happen if 
filtering agents had an explicit distinction between 'author' and 
'sender'?

It might be claimed that they already do, since the DKIM d= field refers 
to a handling agent, rather than author, and is explicitly independent 
of any other message address information.

So, why isn't it reasonable, for example, to have DMARC publish a record 
declaring a requirement for a DKIM or SPF record, independent of From: 
field alignment?  That is, publish a record that says all mail by agents 
of that domain is always authenticated?

It's because the signature needs to be tied to a field that is already 
'interesting' and always present.  Otherwise there is no way to know 
what domain name to look for.  In practical terms, the only available 
choice has been From:.  First, it certainly has an interesting semantic 
-- but really semantic/s/ -- for the address, and second, it's always 
present.

So... what if DMARC's semantic were really for the Sender: field?  If a 
message has no separate Sender: field, then of course the domain in the 
From: field is used.

The would produce obvious possibilities:

    From: [email-masked]
    Sender: [email-masked]

and

    From: [email-masked]
    Sender: [email-masked]

where there might be a dmarc record for mlm.example.com

The modification to DMARC would be "look for Sender: and if it isn't 
present, look for From:.

Obviously, mlm.example.com might instead be badactor.example.com.

but we already have to deal with cousin domains, and DMARC does nothing 
about them.

So if Sender: wouldn't be as useful as From:, why not?

d/

(*)  Mike took exception to my using "processing" as a term for Sender:. 
  He's probably right and it might be worth some separate discussion to 
make sure there is useful and precise language to cover what the 
semantic of Sender: should/must represent.  There is a continuing 
problem in the industry that the word "sender" is used to cover all 
sorts of agents, from author, to originating MTA, to Mediating MTA. 
Should it be 'any agent that touches the message' or 'any agent the does 
a sending operation of the message' or 'the specific agent the posts the 
message into the mail handling system' or something else?
      Note that for mail going through a mediator, there are at least 
two entities qualifying for the 'posting' definition:  The author's 
originating MSA and the MLM's MSA.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Jun 2020 16:14:39 -0700

On 6/23/20 11:49 AM, Dave Crocker wrote:
> So... what if DMARC's semantic were really for the Sender: field?  If
> a message has no separate Sender: field, then of course the domain in
> the From: field is used.
>
> but we already have to deal with cousin domains, and DMARC does
> nothing about them.
>

This makes a lot of sense to me, assuming of course that the WG comes to
rough consensus that alignment specifically with the From: domain isn't
necessary. (My personal position is that it's not.)

I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
(IETF's current MLM usage may, as well). But that possible problem could
be avoided by inventing a new header field (I can't believe I'm
suggesting that), it could be DMARC-Sender: or something like that. If
we're going to avoid From: rewriting, we need to have something that
specifies where to retrieve the DMARC record from.

But as stated above, [DMARC-]Sender: could be badactor.example.com, so
it should be clear that DMARC is not going to prevent bad actors from
doing anything. It is still useful as a reporting mechanism to detect
unintended breakage of message authentication. But I can't think of a
reason that the policy mechanism is useful at all.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Jun 2020 21:19:58 -0700

> RFC 5322 Section 3.6.2, and this proposal might conflict with that

I don't think it conflicts at all. So it will help for you to explain 
your concern in detail.

d/

---

From: David I <[email-masked]>
Date: Wed, 24 Jun 2020 09:56:16 +0000

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Dave Crocker
> Sent: 23 June 2020 19:49
> To: IETF DMARC WG <[email-masked]>
> Subject: [dmarc-ietf] What if... Sender:
>
>  [...]

Hi Dave,
I don't think this allows some of the important automated filtering which alignment on 'From' does (putting the user-importance can of worms about From aside for a moment, though not conceding it).

Specifically, alignment on 'From' allows automated checks against addresses of known, trusted contacts from addressbooks - that an email is authenticated for the domain from the addressbook, and hence likely to actually be from the contact (similarly, it can be used for trusted/known-domains eg same-domain). This can be used for automated scoring/filtering to prevent a malicious (spear)phishing email from appearing in an inbox.

If the authentication is of a value which isn't related to the entry in the addressbook, I don't see how this kind of checking/filtering can be done, and so wouldn't be as useful. Unless there's a way I've missed?

David
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jun 2020 06:47:35 -0700

On 6/24/2020 2:56 AM, David I wrote:
> Specifically, alignment on 'From' allows automated checks against addresses of known, trusted contacts from addressbooks

So does alignment on Sender.  Yes, the addresses in From: vs. Sender: 
might be different, but that doesn't mean the same assessment mechanisms 
that can be used on a From: address can't also be used on a Sender: address.

> If the authentication is of a value which isn't related to the entry in the addressbook, I don't see how this kind of checking/filtering can be done, and so wouldn't be as useful. Unless there's a…

I suspect that very little -- if any -- of the current use of DMARC 
relies on an end-user's address book.

d/

-- 

Dave Crocker

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 24 Jun 2020 09:04:45 -0500

On 6/23/20 1:49 PM, [email-masked] wrote:
> So... what if DMARC's semantic were really for the Sender: field?  If a message has no separate Sender: field, then of course the domain in the From: field is used.

Wouldn't MUAs need to consistently display Sender?

Jesse

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jun 2020 07:07:29 -0700

> Wouldn't MUAs need to consistently display Sender?

They don't consistently display From:

More importantly, MUAs are essentially -- or completely -- irrelevant to 
the use of DMARC now.  I don't see why that should change.

Again:  end-user recipient decision-making is irrelevant to meaningful 
email abuse handling.

d/

---

From: Dotzero <[email-masked]>
Date: Wed, 24 Jun 2020 11:09:12 -0400

> the use of DMARC now.  I don't see why that should change.

Sender: is completely irrelevant to the use of DMARC now. If we were to
list all things irrelevant to DMARC now, it would be a very long list. As
you have mentioned many times in the past, the burden is on the person
making the assertion. You have not provided a compelling case that Sender:
would be a more useful value to validate on than From:. We have substantial
enough experience on the value of the use of From: and the only experience
with Sender: (SenderID) was in essence a failure.

> Again:  end-user recipient decision-making is irrelevant to meaningful

While this may in fact be true now, it may be a function of the
presentation of the information to the end user rather than the content of
the information itself. That being said, I agree that for purposes of
DMARCbis, this should be considered out of scope absent some compelling
data points.

Michael Hammer

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Jun 2020 11:22:27 -0400

On 6/24/2020 10:07 AM, Dave Crocker wrote:
> More importantly, MUAs are essentially -- or completely -- irrelevant
> to the use of DMARC now.  I don't see why that should change.
>

As a MUA developer, I am not sure this applies as much as it did in 
the past. Namely because of the different types of MUA which 
predominately fall into three category:

1) Store and forward, offline capable MUAs where all the possible 
"decision" data is pushed to the MUA in the RFC822/2822/5322 format. 
It uses POP3 for pickup and SMTP for sending. The presumption here was 
that the backend has filtered the mail as much as it could for the 
user with using both system-wide and per-user-account policies. 
Generally, when the user picks up mail with POP3, this stream did not 
include the Spam Box.

2) The Online MUA which doesn't get the possible decision data because 
the UI is rendered by the backend. The Reader is dumb. If it was text 
based, it might ANSI/VT100 to place fields on the screens. It could be 
a web-based interface, etc, overall, offline reader has no control 
over what is displayed.

3) The Hybrid, that combines elements both 1 and 2. Exchange did this, 
IMAP does this.

The MUA 1 and 3 could do its own display but not MUA 2. The MUA 1 and 
3 could do more with email abuse handling that was missing or not done 
by the backend when it passed the data to the MUA.

Unfortunately, we can't do anything legacy systems that were abandoned 
and not possible to upgrade. But with MUA 1 and 3 types still 
supported, what we need is technical guidance.  If we keep suggesting 
that this will never work, them of course, it will continue to be an 
unknown of whats possible.

Yes, it is common for us to believe the backend should be 
"responsible" to do the dirty filtering work. But what if they are not 
doing all the dirty work? all that is possible, for whatever reason, 
like the backend doesn't believe in ATPS?  There is absolutely no 
reason why an modern, advanced MUA could not explore ATPS to fill that 
need.

One simple display tibit:

["Message signed with an Authorized domain"].Color = green.
["Message signed with an Unauthorized domain"].Color = red.

Sure, people will suggest, the user will not read this.  Would that be 
all or some users?  Maybe the MUA developers performs an UI ergonomic 
survey behind one way mirrors or employed Telemetry to learn how users 
react. Maybe they will learn simple colorization is not working well 
and instead they find a Modal Popup window is getting the user's 
attention:

----------------WARNING!-------------------[X]-
| Message signed with an Unauthorized domain  |
|    [Continue Reading] [Move to junk box]    |
-----------------------------------------------

Sure, maybe the user doesn't want to be bothered with this, so he 
turned it off in the MUA's DKIM/DMARC options under the View | 
Preference section.

[X] Display Unauthorized DKIM signer warnings

With 40 years with no MUA guidance, of course, it will continue to be 
a status quo of no progress.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Jun 2020 11:38:36 -0400

> where there might be a dmarc record for mlm.example.com

This still presents the unsolved 3rd Party Signature (3PS) 
authorization concept again.  The problem has always been since Day 1, 
"Does goodplace.example authorized mlm.example.com to be a resigner on 
its behalf?"

> The modification to DMARC would be "look for Sender: and if it isn't

Doesn't solve the 3PS problem. Do you know how ATPS worked?   It works 
like this:

googleplace.example will create a DNS lookup record representing 
mlm.example.com.  The ATPS algorithm for the DNS record is:

base32(sha1(SIGNER-DOMAIN))._atps.example.com

So for this example, a DMARC extension tag "atps=1" is added to 
goodplace.example DMARC record, telling verifiers to test for ATPS 3rd 
party signers.  The zone node record will be (in MS DNS format)

6f4dvf2bygvf6zkq6kiktk53oajhfvhe._atps  TXT ("v=atps01; 
d=mlm.example.com;")

Now the 3rd party is authorized deterministically, and if we did this 
with the Signer Domain, which I presume would be mlm.example.com then 
the same ATPS record will apply and the verifier does not have to deal 
with the 5322.Sender header.

> but we already have to deal with cousin domains, and DMARC does

Well, there would not be any 1st party authorization for the 3rd party 
"badactor.example.com" so for restrictive DMARC records, it would be a 
highly detectable deviation of the experted norm offering a negative 
classification, i.e. rejection or quarantine.

> So if Sender: wouldn't be as useful as From:, why not?

Because we still do not have protocol that can test the assertion that 
the 3rd party Sender is authorized by the 1st party.  It is the same 
problem.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Jun 2020 18:31:35 +0200

> So if Sender: wouldn't be as useful as From:, why not?

I'm a bit skeptic.

The assertion that "DMARC protects the domain name in the address part
of the From:" would have to be dropped.  The requirement that From:
domain be "the identifier used for all message validation operations,
as it is the single identifier in the message likely to be visible to
the user" was among the founding intuitions of DMARC.  We used to
blame MUAs which don't display such datum...  Don't we risk to loose
design consistency with that move?

Sender: has a display name and an address, just like From:.  Don't we
risk to double phishing opportunities?

If Sender: and From: domains disagree, are both going to get reports?

Would that become v=DMARC2, or shall believers of strict From: have no
chance?  Modifying the protocol for such a minor issue as mailing
lists sounds a bit of an overkill.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jun 2020 10:18:57 -0700

On 6/24/2020 8:09 AM, Dotzero wrote:
> Sender: is completely irrelevant to the use of DMARC now.

Actually, I'm claiming it isn't.

Or rather, I'm claiming there is a failure to appreciate that it is 
really Sender information that is important, not author information.

The fact that DMARC only has to do with a domain name tells us that this 
is about an organizational actor and not a person.  My claim is that it 
is sufficient to focus on the operations actor rather than the author actor.

Again, note that RFC 733 (on up through RFC 5322) permit Sender: and 
From: to be conflated.  I'm suggesting making sure they are separated, 
and then adjusting the DMARC focus -- and especially discussion -- from 
author to operator. (Well, not so much adjusting the focus as correcting 
the error of thinking that it's the author that matters.)

> As you have mentioned many times in the past, the burden is on the 
> person making the assertion. You have not provided a compelling case 
> that Sender: would be a more useful value to validate on than From:. 
> We have substantial enough experience on the value of the use of From: 
> and the only experience with Sender: (SenderID) was in essence a failure.

We know that the use of From: causes some serious problems. Using 
Sender: would eliminate them.

I'm not clear why that seems an insufficient justification. (Unless 
there a demonstration that using Sender: rather than From: alters 
DMARC's observable -- rather than supposed -- efficacy.)

> presentation of the information to the end user rather than the 
> content of the information itself.

I think I don't understand what that means.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jun 2020 10:37:46 -0700

On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
> of the From:" would have to be dropped.
Of course. But why is that a 'problem' rather than just a fact?

An obvious challenge in this type of discussion is to distinguish 
surface issues from underlying issues. So for every observation like 
this, about documentation language, we need to ask a version of "so 
what?"  That is, how does it affect actual DMARC efficacy?

> The requirement that From:

Except that DMARC doesn't care about or use the MUA.  Which is why I 
keep claiming that referencing the MUA in DMARC discussions is a 
distraction.

> If Sender: and From: domains disagree, are both going to get reports?

Why would there be a DMARC report on From:?

> lists sounds a bit of an overkill.

I made a point of not trying to offer the specification details, yet, 
because those choices need to flow from an agreement on the basic 
conceptual change I'm suggesting.

(My personal view is that it won't be necessary to declare a version 
change, but really let's wait on discussing the details, pending 
agreement to consider use of Sender:.

d/

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Jun 2020 11:35:05 -0700

Quoting RFC 5322 Section 3.6.2:

> For example, if a secretary were to send a message for
>    another person, the mailbox of the secretary would appear in the
>    "Sender:" field and the mailbox of the actual author would appear in
>    the "From:" field.
and

> If the from
>    field contains more than one mailbox specification in the mailbox-
>    list, then the sender field, containing the field name "Sender" and a
>    single mailbox specification, MUST appear in the message.
In the latter example, the From: header field could contain addresses
from different domains, and the Sender: header field would indicate
which of them actually sent the message.

If either message in question goes to a mediator, the Sender address in
the original message would be lost and replaced by the email address of
the mediator, and the original information would be lost. I'm not sure
if that's a significant problem in practice, but pointing out the
possible conflict with currently specified usage.

Please explain why it is important that specifically the Sender: header
field be used for this.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jun 2020 11:52:27 -0700

> which of them actually sent the message.

Not 'which of them', but 'who'.  The point of the second quoted text is 
to mandate a separate Sender:, when the From: contains more than one 
address.  But it does not specify a different semantic for Sender:

> If either message in question goes to a mediator, the Sender address 
> in the original message would be lost and replaced by the email 
> address of the mediator, and the original information would be lost. 
> I'm not sure if that's a significant problem in practice, but pointing 
> out the possible conflict with currently specified usage.
>
One can indeed imagine a scenario where it matters, but no, it's not 
likely. In any event, the mediator is posting a new message and has a 
'right' to retain or modify whatever it wishes.

So if this is the 'conflict' you see, I'll disgree.  Rather:

      Replacing Sender: is vastly better than modifying From:.

      That's the entire motivation for my suggesting DMARC switch to 
Sender:.

> Please explain why it is important that specifically the Sender: 
> header field be used for this.
>
From: is demonstrably problematic.  Sender: isn't.

Sender: is a long-standing field, similar to From:, but without it's 
history of interesting MUA-level use that DMARC is well-established as 
creating problems for.

d/

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Jun 2020 12:24:48 -0700

> history of interesting MUA-level use that DMARC is well-established as
You have explained why Sender: is better than From: (which I agree with)
but not why specifically Sender needs to be used. I see the use of a
long-standing header field as being a disadvantage, not an advantage,
because of potential obscure uses we don't know about.

-Jim

---

From: David I <[email-masked]>
Date: Thu, 25 Jun 2020 08:54:06 +0000

> From: Dave Crocker <[email-masked]>
> Sent: 24 June 2020 14:48
> To: David I <[email-masked]>; IETF DMARC WG <[email-masked]>
> Subject: Re: [dmarc-ietf] What if... Sender:
>
> > Specifically, alignment on 'From' allows automated checks against
> > addresses of known, trusted contacts from addressbooks
>

Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit.

>
> > If the authentication is of a value which isn't related to the entry in the
> addressbook, I don't see how this kind of checking/filtering can be done, and
> so wouldn't be as useful. Unless there's a way I've missed?
>
> I suspect that very little -- if any -- of the current use of DMARC relies on an
> end-user's address book.

It's definitely the case that there are popular email services doing filtering/alerting based on addressbooks/known contacts, and I'm confident that DMARC's ability to force use of cousin/alternative domains makes this more effective.

David

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 25 Jun 2020 12:14:48 +0200

> what?"  That is, how does it affect actual DMARC efficacy?

That position changes DMARC substantially:

Frequently, an inbound message has one or more valid DKIM signatures,
and/or passes SPF, yet it fails DMARC; that is, the authenticated
domain(s) are not aligned with From:.  Now it's obvious that any of
those authenticated domain(s) could as well have set a Sender:
pointing to itself.  Hence, the net effect is equivalent to dropping
the alignment requirement.

> Why would there be a DMARC report on From:?

Reports are supposed to be consumed by the originator.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 06:36:02 -0700

> Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted contact, and the DMARC associated with the abused domain in…

Why is it useful in the From:?  Seriously.

Since the utility of DMARC has nothing to do with recipient end-user 
decision-making, why is DMARC's use of From: automatically better than 
having DMARC use Sender:?

Attackers do all sorts of bad things.  Some of those bad things don't 
actually matter.  They might be unauthorized, ill-intended, and even 
make you or me uncomfortable. But they don't actually have any effect on 
getting bad mail delivered to recipients nor an effect on those 
recipients.  Bad actors try all sorts of stuff.

So pointing out what an attacker might or will do doesn't end the 
argument.  What matters is the /effect/ of their actions, not the theory 
of their actions.

>> It's definitely the case that there are popular email services doing filtering/alerting based on addressbooks/known contacts, and I'm confident that DMARC's ability to force use of cousin/alternat…

I did not say that address books are not used in some filtering work.

I said that I doubted that it is relevant to DMARC use.  Feel free to 
document counter-examples.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 06:42:35 -0700

> the alignment requirement.

It's not.  Remember that the From: field is typically also the Sender: 
field.

Again:  The actual semantics of DMARC have to do with the organization's 
domain, not the author's mailbox.  So, really, DMARC concerns an 
operational identifier, not a content creator.

The suggestion, therefore, is to retain alignment, but move it to a 
field that has to do with operations, not content.

> Reports are supposed to be consumed by the originator.

You didn't actually answer my question.

Let's try a more complete question:

      If DMARC reports refer to the Sender: aligned domain, and reports 
refer to that, why is a report on the From: field also required?

d/

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Jun 2020 09:53:04 -0400

On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker <[email-masked]> wrote:

> Or rather, I'm claiming there is a failure to appreciate that it is really
> Sender information that is important, not author information.
>

Sender sends on behalf of. It ultimately is still about the From (author).
By your logic, if I walk into your bank and can identify myself as myself I
should be able to withdraw money from your bank account even though I have
shown no relationship between myself and yourself.

> is about an organizational actor and not a person.  My claim is that it is
> sufficient to focus on the operations actor rather than the author actor.
>
Organizations get to decide how individual users may use accounts belonging
to a domain controlled by the organization. This is ultimately why there is
such a pernicious problem with MLMs. IF one user at an organization
subscribes to a list, why would an organization undertake the risk of
allowing that MLM to be listed in it's SPF record or to DKIM sign with the
organizations private key. At the other end of the spectrum, if all or
almost all of the organizations users were subscribers to that MLM, the
organization might consider it.

> Again, note that RFC 733 (on up through RFC 5322) permit Sender: and From:
> to be conflated.  I'm suggesting making sure they are separated, and then
> adjusting the DMARC focus -- and especially discussion -- from author to
> operator. (Well, not so much adjusting the focus as correcting the error of
> thinking that it's the author that matters.)
>
>
> As you have mentioned many times in the past, the burden is on the person
> We know that the use of From: causes some serious problems.  Using Sender:
> would eliminate them.
>
> I'm not clear why that seems an insufficient justification.  (Unless there
> a demonstration that using Sender: rather than From: alters DMARC's
> observable -- rather than supposed -- efficacy.)
>
>
>
> the information itself.
> Brandenburg InternetWorkingbbiw.net
>
>

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Jun 2020 10:02:17 -0400

]ARGH! Accidentally hit send. I was going to continue with... It is
unlikely that an organization would do so even if all it's users were
subscribers because now any mail sent through the list is validated for the
organization. We go round and round because of a mismatch in granularity.
Ultimately, who gets to decide how an account may be used. It's clearly the
organization that controls the domain the user account belongs to. So what
is needed is a mechanism that enables a user at a domain (other than
subscribing) to show, through the domain owner, that the domain authorizes
the use of that account at a particular list. This is a different problem
space than DMARC and I don't believe it should be conflated with DMARC. It
would function at a more granular level and have a whole different set of
issues and opportunities. I don't know if it would be appropriate for this
group to take up or another group.

Michael Hammer

On Thu, Jun 25, 2020 at 9:53 AM Dotzero <[email-masked]> wrote:

> Organizations get to decide how individual users may use accounts
> belonging to a domain controlled by the organization. This is ultimately
> why there is such a pernicious problem with MLMs. IF one user at an
> organization subscribes to a list, why would an organization undertake the
> risk of allowing that MLM to be listed in it's SPF record or to DKIM sign
> with the organizations private key. At the other end of the spectrum, if
> all or almost all of the organizations users were subscribers to that MLM,
> the organization might consider it.
>
>
>> From: to be conflated.  I'm suggesting making sure they are separated, and
>> then adjusting the DMARC focus -- and especially discussion -- from author
>> to operator. (Well, not so much adjusting the focus as correcting the error
>> of thinking that it's the author that matters.)
>>
>>
>> there a demonstration that using Sender: rather than From: alters DMARC's

---

From: David I <[email-masked]>
Date: Thu, 25 Jun 2020 15:10:59 +0000

> Sent: 25 June 2020 14:36
> To: David I <[email-masked]>
> Cc: IETF DMARC WG <[email-masked]>
> > Without forcing alignment to 'From', an attacker can set their own 'Sender',
> set a 'From' they're not entitled to use that's of a trusted contact, and the
> DMARC associated with the abused domain in the 'From' has no effect and
> can't be used for filtering. So while you could so a similar filter on Sender, it
> wouldn't be as useful, and would provide less security benefit.
>

Because the claimed author is an important aspect of any kind of trust calculation on an email, human or automated. So an aligned, authenticated 'From' is a strong signal.

> decision-making,

I don't really understand this assertion. The DMARC spec suggests for p=quarantine that unauthenticated mail ends up in a spam folder. It's assumed that users are less likely to open and trust mail in their spam folder (though it's not 100% of course). So yes, the utility of DMARC has something to do with end-user decision making.

why is DMARC's use of From: automatically better than
> having DMARC use Sender:?

Because the From field is used by software to understand where an email came from, and apply UI, filters, and warnings. I'd be fine if both had to align - that would seem likely to work for the secretary usecase for Sender in RFC 5322, and intra-company mailing lists, but not the generic mailing list case.

>
> Attackers do all sorts of bad things.  Some of those bad things don't actually
> matter.  They might be unauthorized, ill-intended, and even make you or me
> uncomfortable. But they don't actually have any effect on getting bad mail
> delivered to recipients nor an effect on those recipients.  Bad actors try all
> sorts of stuff.

Agreed. It's possible for bad actors to compromise mailboxes to bypass current DMARC based filtering. So is DMARC pointless? No, because it increases the cost and complexity of the attack, which is a positive thing.

>
> So pointing out what an attacker might or will do doesn't end the argument.
> What matters is the /effect/ of their actions, not the theory of their actions.

The effect would be to phish people more successfully by evading the current DMARC checks on From alignment and filters/detections based on cousin domains.

> >> It's definitely the case that there are popular email services doing
> filtering/alerting based on addressbooks/known contacts, and I'm confident
> that DMARC's ability to force use of cousin/alternative domains makes this
> more effective.
>
> I said that I doubted that it is relevant to DMARC use.  Feel free to document
> counter-examples.

Not sure how to do that because it's an indirect effect. DMARC forces bad actors to cousin domains, and the filtering is on that. Will give it some thought.

David

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 08:17:26 -0700

On 6/24/2020 12:24 PM, Jim Fenton wrote:
> but not why specifically Sender needs to be used.

Existing practice is less risky than new practice.  The existence and 
semantics of Sender: has been around for 45 years.  Its semantics match 
what is

> I see the use of a

That line of logic means we should never modify or add to any existing 
practice.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 08:29:06 -0700

> Because the claimed author is an important aspect of any kind of trust calculation on an email, human or automated. So an aligned, authenticated 'From' is a strong signal.

1. Signal to what and how is it used for filtering?

2. Why isn't an aligned Sender: just as strong?

3. Arguably the actual semantics of an aligned From:, for DMARC, is for 
an aligned Sender:, since the semantics of DMARC concern the 
organization and not the author.  Remember that From: typically 
conflates both author and operator information.

> I don't really understand this assertion. The DMARC spec suggests for p=quarantine that unauthenticated mail ends up in a spam folder. It's assumed that users are less likely to open and trust mail…

Users open mail in the spam folder all the time.

> Because the From field is used by software to understand where an email came from, and apply UI, filters, and warnings.

1. "Warnings" have no reliable utility.

2. UI behavior is what From: field alignment is breaking, given the 
workarounds that MLMs have to do

3. Filtering engines use a wide array of information; there is nothing 
magical about their use of From.  Also note  item #3, from above.

> Agreed. It's possible for bad actors to compromise mailboxes to bypass current DMARC based filtering. So is DMARC pointless? No, because it increases the cost and complexity of the attack, which is…

I think you missed my point.  My point was that some of what attackers 
do doesn't matter.  It upsets us when we hear about their doing it, but 
it doesn't affect discoverability and it doesn't affect recipient 
behavior. We should worry about their actions that actually have a bad 
effect, not worry about actions we just don't like.

> The effect would be to phish people more successfully by evading the current DMARC checks on From alignment and filters/detections based on cousin domains.

Your claim of 'successfully' means you have objective data 
substantiating the successes.  Please circulate it to us.

d/

---

From: David I <[email-masked]>
Date: Thu, 25 Jun 2020 16:53:26 +0000

> Sent: 25 June 2020 16:29
> > Because the claimed author is an important aspect of any kind of trust
> calculation on an email, human or automated. So an aligned, authenticated
> 'From' is a strong signal.
>

Some form of algorithm that filters or otherwise protects users.

> 2. Why isn't an aligned Sender: just as strong?

Because it doesn't represent the author, which is who the user trusts (this may be inferred by software eg through previous conversations, addressbook presence etc)

> > Because the From field is used by software to understand where an email
> came from, and apply UI, filters, and warnings.
>

Insofar as humans can circumvent them, sure, they're not 100% reliable. And there are well-designed ones, and not. But they are a useful tool for software developers to help their users when they don't have sufficient evidence to simply destroy suspicious email.

> workarounds that MLMs have to do

MUAs have lots of options for how they want to display and differentiate messages (eg mailing lists) and support users. I'd love to see more creativity in that space.

> 3. Filtering engines use a wide array of information; there is nothing magical
> about their use of From.

Magical, no. A signal you can heavily weight and rely on, yes.

> > Agreed. It's possible for bad actors to compromise mailboxes to bypass
> current DMARC based filtering. So is DMARC pointless? No, because it
> increases the cost and complexity of the attack, which is a positive thing.
>
> I think you missed my point.  My point was that some of what attackers do
> doesn't matter.  It upsets us when we hear about their doing it, but it doesn't
> affect discoverability and it doesn't affect recipient behavior. We should
> worry about their actions that actually have a bad effect, not worry about
> actions we just don't like.

If I understand, then we agree that the goal is to stop bad things happening, not be the protocol police.

> argument.
> > The effect would be to phish people more successfully by evading the
> current DMARC checks on From alignment and filters/detections based on
> cousin domains.
>
> Your claim of 'successfully' means you have objective data substantiating the
> successes.  Please circulate it to us.

Clearly I can't have data about the impact of implementing your proposal, but I believe the above is a reasonable inference given what we know about today's world.

I think there is data out there showing that when current From-aligned DMARC is applied, that attempted spoofing of that domain drops (the inference being that it's because of DMARC From-aligned filtering). If not, I can probably find that kind of data.
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Jim Fenton <[email-masked]>
Date: Thu, 25 Jun 2020 10:14:36 -0700

On 6/25/20 8:17 AM, Dave Crocker wrote:
> semantics of Sender: has been around for 45 years.  Its semantics
> match what is
>
>
>> I see the use of a
We disagree. But I suggest we not bikeshed this any further until the WG
reaches rough consensus on whether DMARC binding specifically with the
From: domain is essential. Then we can decide what the "color" of the
header field should be.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2020 19:12:42 -0000

In article <[email-masked]>,
David I  <[email-masked]> wrote:
>Without forcing alignment to 'From', an attacker can set their own 'Sender', set a 'From' they're not entitled to use that's of a trusted
>contact, and the DMARC associated with the abused domain in the 'From' has no effect and can't be used for filtering. So while you could
>so a similar filter on Sender, it wouldn't be as useful, and would provide less security benefit.

It sounds like you're making the common mistake of confusing "DMARC
aligned" with "not phish" or "not spam". What would you do with a
DMARC aligned message with this From header?

  From: Security Alert <[email-masked]>

(The correct answer is bury it deep in the phish tank.  Crooks can
do DMARC alignment, too.)

Any sensible mail provider will do its usual reputation checks on the
validated identity, whichever header it is, and decide whether to
deliver the message or not. I believe that Dave's point is if you're
going to do that, validating the sender gives you useful flexibility
without a lot of loss of security.

On the other hand, if you're going to do that, why do you need DMARC
at all? You use the d= in valid DKIM signatures.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 17:10:57 -0400

> So if Sender: wouldn't be as useful as From:, why not?

I've tried to follow this thread.  I've no idea where to start to comment, so 
I went back to the beginning.

I would encourage people to review the working group charter.  I think dumping 
5322.From and aligning to something else is well outside of it.  Not saying we 
couldn't recharter, but I'm skeptical of the value of this entire thread.

I wasn't there at the creation of DMARC, but it seems likely that 5322.From 
alignment wasn't picked at random.  I don't think any amount of post-facto 
sophistry on IETF mailing lists will make that not true.

Before we even think about alternatives, I'd like to hear from someone who was 
involved in the original effort explain the rationale for alignment to 
5322.From and see a discussion on why that original rationale is now wrong 
(imagine I explain Chesterton's Fence here).

Also, why an email address at all (base on my reading of the thread)?  If some 
of the assertions being made are accurate, any random opaque identifier would 
do just as well.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 14:16:43 -0700

> couldn't recharter, but I'm skeptical of the value of this entire thread.

What is it about Item 1 in the charter that precludes this work?

What is it about Item 2 in the charter that precludes this work?

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 17:20:40 -0400

On Thursday, June 25, 2020 5:16:43 PM EDT Dave Crocker wrote:
> > I would encourage people to review the working group charter.  I think
> > dumping 5322.From and aligning to something else is well outside of it. 
> > Not saying we couldn't recharter, but I'm skeptical of the value of this
> > entire thread.

Even before you get to those:

> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and provide detailed justification
> for any non-interoperability.

In fact, the first sentence of the charter includes it in the definition of 
DMARC:

> Domain-based Message Authentication, Reporting & Conformance (DMARC)
> uses existing mail authentication technologies (SPF and DKIM) to
> extend validation to the RFC5322.From field.

This entire thread is about making something that's not DMARC.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Thu, 25 Jun 2020 15:05:55 -0700

> without a lot of loss of security.
I'm not sure what validating the sender (either) accomplishes.
> at all? You use the d= in valid DKIM signatures.
+1, although there's also the reporting piece of DMARC, which can be
used to alert the domain to authentication breakage and perhaps certain
types of abuse.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Jun 2020 18:10:57 -0400

> This entire thread is about making something that's not DMARC.

I agree, but I am willing to see an algorithm, not just subjective 
administration considerations.  The Sender is only added by one 
component in my mail framework, the list server, in fact, it adds two 
headers:

Sender:
Errors-To:

Which means, I suppose, "I'm your sender, but if you have any 
complaints, talk to Errors-to:"

Should they align?  and with 5322.From, how?

DMARC needs a 3rd party solution.  SPF has it because it allows you to 
authorize other IPs outside your own network.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 25 Jun 2020 15:18:21 -0700

The paragraph goes on to say:

> As the working group develops solutions
>    to deal with indirect mail flows, it will seek to maintain the
>    end-to-end nature of existing identifier fields in mail, in
>    particular avoiding solutions that require rewriting of originator
>    fields.
I interpret that "seek to" as of equal importance to the previous one.
But we're spending an awful lot of WG bandwidth discussing rewriting,
while Dave's "what if" proposal doesn't require any.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 22:33:58 +0000

>while Dave's "what if" proposal doesn't require any.

True, but I think it's on topic for a DMARC replacement working group, not this one.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 15:53:40 -0700

> True, but I think it's on topic for a DMARC replacement working group, not this one.

You have just crossed over from expressing a personal interpretation of 
the charter, to declaring your interpretation as correct, in spite of 
having a competing interpretation also having been expressed.

Please don't do that.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 22:58:52 +0000

>having a competing interpretation also having been expressed.

Why would I be expressing an interpretation of the charter that I didn't think is correct?  

Absent direction from the chairs, of course I'm going to operate on the basis of my interpretation (although I think it's less interpretation and more reading what's explicitly there, I'd imagine you would view it differently).

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jun 2020 16:04:43 -0700

> Why would I be expressing an interpretation of the charter that I didn't think is correct?

That's not what i said.

I mean that you are asserting a requirement as if it were established, 
based on your interpretation.  the requirement is not established and, 
of course, i believe it won't be.

> Absent direction from the chairs, of course I'm going to operate on the basis of my interpretation (although I think it's less interpretation and more reading what's explicitly there, I'd imagine y…

The point is needing to be more tentative.  Opinions are of course 
fine.  The state of being an opinion is transitive.  It flows onto any 
assertions made based on it.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 23:22:35 +0000

On June 25, 2020 11:04:43 PM UTC, Dave Crocker <[email-masked]> wrote:
>> Absent direction from the chairs, of course I'm going to operate on
>the basis of my interpretation (although I think it's less
>interpretation and more reading what's explicitly there, I'd imagine
>you would view it differently).
>

I think the bar to convince me that it's okay to throw away aligning to 5322.From is in scope for the working group is really high when the charter defines DMARC as "Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field".

So far, no one has presented any arguments to suggest an alternative view is correct.  I think what I think and I don't feel any need to be disingenuous about it.

That doesn't mean I won't change my mind later if someone makes a convincing argument that an alternative view is correct.  Don't confuse having a firm opinion with being unwilling to consider alternative views.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Jun 2020 23:18:13 -0400

The "Sender" vs "From"  discussion reminds me of SenderID and its 
companion RFC4407 protocol:

	Purported Responsible Address (PRA)
	https://tools.ietf.org/html/rfc4407

"This document defines a new identity associated with an e-mail 
message, called the Purported Responsible Address (PRA), which is 
determined by inspecting the header of the message. The PRA is 
designed to be the entity that (according to the header) most recently 
caused the message to be delivered."

Dave's proposal seems to suggest 5322.Sender would be the PRA of 
interest and serve more useful than 5322.From for the purposes of 
performing DKIM Policy lookups. If the 5322.Sender is missing, then 
for backward compatibility, the fallback is 5322.From.

I can see  engineering power if we can leverage the work already done 
in this regard. Dave's refocus with Sender can be validated with the 
PRA work.  It will also offer a great benefit with another 
SenderID/PRA companion RFC4405 SUBMITTER protocol.

     SMTP Service Extension for Indicating the Responsible
     Submitter of an E-Mail Message
     https://tools.ietf.org/html/rfc4407

Designed for SenderID to be processed at SMTP (without needing the 
payload) by passing the PRA to the SMTP client MAIL FROM command using 
the SUBMITTER keyword:

    C: MAIL FROM:<[email-masked]> SUBMITTER={PRA}

The good news, there is running code using the PRA/SUBMITTER Protocol 
and with 13+ years of empirical data, it showed:

    PRA is 5322.From for direct mail
    PRA is 5322.Sender for indirect mail.

I think Dave's proposal should get ample review.

However, the DKIM age-old problem still remains; how does the author 
domain authorize all this?  How does the author domain authorize the 
PRA? In addition, what is 5322.Sender's relationship with the DKIM 
signature signer domain?  Is there some alignment questions?

There would now four (4) identities in the DMARC process model;

5321.MAIL FROM: Reverse path domain
5322.From: domain (the first one)
5322.Sender: domain
5322.DKIM-Signature Signer domain (d=)

Actually 5 if we want to throw the client domain name (EHLO/HELO) into 
the pot.

While we can use the PRA for some "lookup," do we still need to tie it 
or bind it with the 5322.From?"

There is the ATPS, TPA, the ingress conditional that can use to make 
the bind which currently binds the signer domain with the author domain.

So those protocols will need to be updated as well.

On 6/25/2020 7:22 PM, Scott Kitterman wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: David I <[email-masked]>
Date: Fri, 26 Jun 2020 08:20:04 +0000

> From: dmarc <[email-masked]> On Behalf Of John Levine
> Sent: 25 June 2020 20:13
> To: [email-masked]
> In article
> <[email-masked]
> .PROD.OUTLOOK.COM>,
> >Without forcing alignment to 'From', an attacker can set their own
> >'Sender', set a 'From' they're not entitled to use that's of a trusted
> >contact, and the DMARC associated with the abused domain in the 'From'
> has no effect and can't be used for filtering. So while you could so a similar
> filter on Sender, it wouldn't be as useful, and would provide less security
> benefit.
>
> aligned" with "not phish" or "not spam". What would you do with a DMARC
> aligned message with this From header?
>
> (The correct answer is bury it deep in the phish tank.  Crooks can do DMARC
> alignment, too.)

Indeed, I would do that. I would also be grateful for the DMARC policy on paypal.com for forcing the attacker to use a cousin domain that can be easily detected as not legitimate, raising the cost to the attacker, and make the filtering easier/more accurate.

David

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2020 10:22:40 +0200

> It's not.  Remember that the From: field is typically also the Sender:

In a DMARC/sender scenario, From: and Sender: are aligned in direct
mail flows only.  Any intermediate actor, one, say, which adds an ARC
set would also set Sender:.  Indeed, DMARC/sender would likely get the
same level of usability as ARC; that is, require an omniscient mailbox
provider in order to effectively filter based on it.

> Again:  The actual semantics of DMARC have to do with the
> organization's domain, not the author's mailbox.  So, really, DMARC
> concerns an operational identifier, not a content creator.
> 

Exactly.  While From: is linked to the semantic content, Sender: can
be altered scot-free by any intermediate operator.  All the policies,
the aspf and adkim settings that an originator had devised will be
gone.  So will filtering by paramount domains or TLDs.  All those
moments will be lost in time, like tears in rain...

> refer to that, why is a report on the From: field also required?

An originator needs to check whether the DKIM signatures they apply
are robust enough to pass through indirect mail flows.

If you consider the originator's mark unimportant, perhaps because the
last hop's signature suffices, you're reinventing ARC.

Best
Ale
--

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 26 Jun 2020 11:41:58 GMT

Scott, Thank you!
>>I think the bar to convince me that it's okay to throw away aligning to 5322.From is in scope for the working group is really
>>high when the charter defines DMARC as "Domain-based Message Authentication, Reporting & Conformance (DMARC) uses 
>>existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field".

Two weeks ago, John  Levine reminded us that DMARC v1 was already deployed and this effort was to perfect the wording.   Suddenly, we have a small but powerful group insisting that we discard DMARC v1 and turn it into DMARC v2.   

This discussion has reviewed the success of DMARC v1, how it has limited a whole category of attacks and has helped with law enforcement takedowns.    But now John Levine wants me to prove that From alignment is important to "most of us", a term I used to include myself in the group that has benefited from DMARC v1.  Apparently historical results are not relevant.

The supporters of DMARC v2 can certainly navigate the IETF process, but I cannot imagine that Google and Paypal, who created DMARC v1, will jump on your bandwagon.  Nor can I imagine the US Government, which is requiring DMARC v1 rollout now, will jump on the v2 bandwagon based on the evidence presented in this discussion so far. 

I live with the knowledge that every day my mail stream is allowing through unwanted and potentially hostile content because the email filtering problem is so difficult.  I know that only one hostile message needs to penetrate to trigger an attack that destroys my organization.   It galls me that some of that criminal content comes from a billion-dollar U.S. company, which acts as  facilitator for the crooks.    "From" is the one identity in those messages that allows me to filter the utility company mail from the bank fraud email.   So, yes, FROM is very important to me.

I have pointed out that the mailing list problem can be largely solved with user-specific delivery options in the MLM, but that has so far been ignored.   However, to support any transition to DMARC v2, MLMs will need user-specific delivery options to distinguish those recipients that support the new design from those who do not.    So MLM readiness is not a small issue. 

DF

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Jun 2020 18:05:32 -0700

Emphatically hatless:

On Fri, Jun 26, 2020 at 4:42 AM Douglas E. Foster <
[email-masked]> wrote:

> Two weeks ago, John  Levine reminded us that DMARC v1 was already deployed
> and this effort was to perfect the wording.   Suddenly, we have a small but
> powerful group insisting that we discard DMARC v1 and turn it into DMARC
> v2.
>

"Perfect the wording" rather trivializes what I believe the charter charges
this working group with doing.  If you read it, I suggest you'll see that
this is a heavier lift than that.

This discussion has reviewed the success of DMARC v1, how it has limited a
> whole category of attacks and has helped with law enforcement takedowns.
>  But now John Levine wants me to prove that From alignment is important to
> "most of us", a term I used to include myself in the group that has
> benefited from DMARC v1.  Apparently historical results are not relevant.
>

This seems to me like a myopic synopsis of the discussion so far.  Remember
that while DMARC has lots of people thinking it's a huge step forward in
fighting fraud, there is also an audience that thinks it's been a serious
disruption and has caused more collateral damage than it is worth.  It has,
in particular, disrupted the work of the IETF itself.  It is therefore
reasonable, in my view, to review the premises on which the claimed success
was achieved.  (That's not to say claims of its success are flatly wrong,
but rather that, as with any other scientific endeavor, reviewing our
assumptions should always be on the table.)

The supporters of DMARC v2 can certainly navigate the IETF process, but I
> cannot imagine that Google and Paypal, who created DMARC v1, will jump on
> your bandwagon.  Nor can I imagine the US Government, which is requiring
> DMARC v1 rollout now, will jump on the v2 bandwagon based on the evidence
> presented in this discussion so far.
>

DMARC v1 was not the product of any standards process.  One could argue
that the damage it has caused is a result of the absence of such rigor.  I
don't know why, then, you would discard v2 so easily when it will by
definition be developed with what is probably a higher standard before it's
published.  I, similarly, cannot imagine the likes of Google and Paypal
dismissing out of hand a potentially improved version that actually has
more broad consensus and reduces damage (but, of course, I'm in no position
to speak for them).

I'd like us to take a run at actually doing the work before calling
conclusions like this.

I have pointed out that the mailing list problem can be largely solved with
> user-specific delivery options in the MLM, but that has so far been
> ignored.   However, to support any transition to DMARC v2, MLMs will need
> user-specific delivery options to distinguish those recipients that support
> the new design from those who do not.    So MLM readiness is not a small
> issue.
>

I suggest that specification of user delivery options don't belong in a
protocol document, except perhaps in an informative advisory appendix.  The
working group could choose to pursue an applicability statement alongside
the protocol document that defines DMARC v2, if that's a necessity.  It's
up to the chairs to determine whether consensus has been established to do
so; it's up to you, if you are in favor, to do the work to develop that
consensus.

-MSK