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

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Jul 2020 20:20:27 -0700

FYI,

I've posted an initial draft for having DMARC use the Sender: field:

      https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Doug Foster" <[email-masked]>
Date: Mon, 13 Jul 2020 10:46:33 -0400

Let's clarify the purpose of DMARC and the problem of MLM edits:

Modifying in-transit messages is a threat vector for both sender and
recipient.
The ability to constructively modify a message is also the ability to
maliciously modify a message.
And the ability to maliciously modify a message is also the ability to
create a new message which looks like a forwarded message.
In this respect, a content-editing MLM is indistinguishable from a
content-fabricating spammer.

Senders do not want to be misrepresented, and do not want their good
reputation to be exploited by those with a negative reputation.
Recipients do not want to be misled.
Consequently, sender and recipient agree to enforce DMARC policy, to prevent
this from happening.   If a message is altered in transit, or forged in its
entirety, the message will be rejected.

There are very few ways to fix this:
- MLM must gain the trust of the sender and recipient, so that it can be
distinguished by a spammer.
- Sender and recipient must be duped into accepting content that they do not
want.

RFC 7960 is worded to suggest that DMARC is to blame for the problem.   The
real problem is that MLMs have made their operating practices dependent on
weak security.   

Santa Claus could run into the same problem:   At least in the USA, he comes
down chimneys, because they are unsecured and his intentions are only good.
If criminals figure out how to enter and exit through the chimney,
homeowners will start placing locked grates on top of the chimney.  Given
the choice between "both criminals and Santa" or "neither criminals nor
Santa", most homeowners would be willing to give up Santa.  Of course, Santa
could ask for a key, which would create a key management nightmare.   Or he
could ring the doorbell, show credentials, and wait to be admitted.

The MLMs are like Santa.  They are trying to do a good thing.   But the
criminals want to use the same weaknesses that the MLMs want to use.   Given
the choice between "both" and "neither", DMARC-enforcing domains are
choosing neither.   Inducing or coercing them to use "both" mode is an
incorrect solution to the MLM problem.

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, July 12, 2020 11:20 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

FYI,

d/

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2020 09:32:13 -0700

> Let's clarify the purpose of DMARC and the problem of MLM edits:

Thanks for the response.  What confusion about DMARC is there, that you 
felt needed clarifying, and how does it relate to the details of this 
proposal?

Also, in terms of threats, how does my proposal make them different from 
what is already considered acceptable?  In particular, the current 
actions by Mediators that rewrite the From: field is, apparently, 
considered acceptable.

> Modifying in-transit messages is a threat vector for both sender and

Technically, they are not 'in transit'.  In basic email terms, they've 
been delivered and then re-posted.

Also, since mailing lists have been in operation for about 45 years, and 
since they are such a threat, perhaps you can point to some documented 
abuses by them?

Lastly, I apologize, but I could not discern any specific substance in 
your note that relates to the substance of my draft. Please clarify.

d/

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Jul 2020 13:15:53 -0400

Before more review,just to confirm:

1) draft-crocker-dmarc-author

A proposed new 5322.Author header?  Is is required to be hash bound to 
DKIM signature? Will be make it a MUST NOT modified NOR rewrite it?

2) draft-crocker-dmarc-sender

A proposal to somehow shift DMARC to DNS UP the sender domain for 
DMARC policy?  Does this mean the Sender header is now required to be 
hash bound to the signature?

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2020 10:21:49 -0700

On 7/13/2020 10:15 AM, Hector Santos wrote:
> A proposed new 5322.Author header? 

Yes.

> Is is required to be hash bound to DKIM signature? 

No. In fact the DKIM requirement to include From: in the set of 
hash-bound text was a last-minute imposition by an area director, rather 
than a functional need set by the working group or larger community.

That said, of course I'd expect signers to choose to include it.

> Will be make it a MUST NOT modified NOR rewrite it?

No idea where this would be mandated or why.

> DMARC policy? 

"DNS UP"?

It's a proposal to have DMARC use the Sender: field, in preference to 
the From: field.

> Does this mean the Sender header is now required to be hash bound to 
> the signature?

cf, above, about the nature of the requirements.  Again, it would make 
sense to bind it, but mandating is a separate issue.

d/

---

From: Joseph Brennan <[email-masked]>
Date: Mon, 13 Jul 2020 14:28:17 -0400

> > 2) draft-crocker-dmarc-sender

This is an elegant solution. It puts the burden of change-- creating a
Sender field in all cases, and a variant DMARC record-- on the domain
owner who wants to send mail and use DMARC rules. The use of Sender
complies with RFC 5322, since it is optional whether to create Sender
when it is the same address as From.

With this implemented, developers of mailing list software can stop
figuring out which way to violate RFC 5322 in order to make mail
deliverable, and developers of clients do not have to create and
display a new Author field. Big win, for widespread acceptance, I
would say.

-- 
Joseph Brennan
Lead, Email and Systems Applications

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Jul 2020 11:52:25 +0200

> display a new Author field. Big win, for widespread acceptance, I

And phishers can also send mail From: fm.bank and Sender: regleissei.icu.  To 
publish a DMARC policy would avail Farmers & Merchants nothing, then.

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 08:30:08 -0400

On 7/13/2020 1:21 PM, Dave Crocker wrote:
> hash-bound text was a last-minute imposition by an area director,
> rather than a functional need set by the working group or larger
> community.

No disrespect, but I was an active participant in the DKIM WG and I 
don't remember this to be the case.

Since DomainKeys, the 822.From was required to be hash bound to the 
signature. I recall this being carried on to DKIM and we did debate 
the merits of the binding requirement as the sole anchor and immutable 
object that remains with email.

https://tools.ietf.org/html/rfc4870#section-3.3

and it did not change with DKIM followed up:

https://tools.ietf.org/html/draft-allman-dkim-base-01#section-5.4

That has never changed.  Let us keep in mind the fact DomainKeys and 
the follow up DKIM work, both had a built-in policy component based on 
the 5322.From anchor identity since the 5322.From identity was a 
hashing requirement.  The original APIs for DKIM and Domainkey had 
SSP/ADSP lookup functionality.

822.From was selected because this header is not expected to be 
legitimately modified or removed in transit.  In fact, the signer has 
a SHOULD NOT hash a header that could be modified or removed. This 
proposal will continue to perpetuate the idea that 5322.From MAY be 
modified.

Yes, I do recall that advocates (mostly you and Levine) were against 
the 1st party Author Domain dependency requirement preferring instead 
a 3rd party sender, 3rd party signer authorization and trust model.

> That said, of course I'd expect signers to choose to include it.

I don't see how this can be escape.  Something has to be sacred in 
email and right now, it is 5322.From which is not expected to be 
modified. Cracking open this door will have its consequences.

> No idea where this would be mandated or why.

Because of the policy component.  We are here because the original 
design model aspect to bind an immutable object like 822.From is once 
again being questioned by these proposals by the same folks who never 
wanted it in the first place.

> It's a proposal to have DMARC use the Sender: field, in preference to

Ok.

> sense to bind it, but mandating is a separate issue.

I am not closed to either proposals but I don't see we can "safely" 
have it both ways.  You need triggers and variant logics for backward 
compatibility and also for enforcement.

We have the logic in place to resolve this issue. The List Systems 
need to be updated. Bottom line.

If we are asking developers, signers, verifiers and resigners to 
"change" then it should consider what are the current change 
"requirements" versus anything new to perhaps simplify it, scale it, 
but most importantly resolve the all important 3rd party signers 
authorization issue.

We spent 15+ IETF-MAN years in all this and we now going back to the 
1st party vs 3rd party signer design model.  Does the DKIM Service 
Architecture still applicable?

https://tools.ietf.org/html/rfc5585

I believe it was settled that a DKIM Policy as a function of the 
5322.From Author domain, the legitimate copyright holder of the 
self-signed signature, was a good thing to do to maintain a strong 
original integrity of the email.  We knew the list integrity change 
issue was a problem.  We said "make them resign" and they began to do 
so.  We also knew restrictive policies will cause a list distribution 
problem with downlink verifying receivers primarily because we didn't 
have a 3rd party resigner authorization protocol.

This is where we left it, never to go away, and its back again.

How do resolve this without re-inventing email and introducing new 
headers?

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 09:16:16 -0400

> display a new Author field. Big win, for widespread acceptance, I

Sender: is already set by most MLM, if not all.  Error-to: is also set 
for compatibility reasons.

The proposal for policies to depend on Sender with a From fallback 
does not resolve the 3rd party authorization problem.

We currently have two identities:

- ADID Author Domain (5322.From) Identity
- SDID Signer Domain (5322.DKIM-Signature d=) Identity.

We also have the well-defined and recognize distinction:

- 1st party where ADID is equal to SDID
- 3rd party where ADID is NOT equal to SDID

The ideal DKIM model is to do a:

- 1st party, no problem, with the self-signed signature.  No need to 
do a DNS-LOOKUP if ADID is equal to SDID. However, there were 
consideration for a NO MAIL policy.  It was determined we can do this 
a null public key.

- 3rd party, Policy lookup based on ADID to determine if SDID is a 
legitimate resigner.  We have no protocol for this.

Adding Sender (lets give it an acronym SRDID) to the mix does not 
change the authorization problem. Under these resigner conditions, the 
SDID=SRDID would be expected to be the same domain this making SRDID 
redundant.

One way to do this is with the ADID adding a SDRID or SDID DNS record 
which is how ATPS "Authorized Third Party Signer" works.

Another way is use a non-DNS based conditional signature idea.

There is also TPA. Supposedly, it scales better than ATPS as a DNS 
record lookup proposal.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 06:41:52 -0700

On 7/14/2020 2:52 AM, Alessandro Vesely wrote:
> And phishers can also send mail From: fm.bank and Sender: 
> regleissei.icu.  To publish a DMARC policy would avail Farmers & 
> Merchants nothing, then.

If regleissei.icu publishes a DMARC record and indicates support for use 
of Sender:, per the proposal, please explain exactly what bad things 
will happen, in the case you offer.

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 10:45:25 -0400

Dave,

Take a look at how DomainKeys considered the "Sender" header. It may 
help your proposal for Sender.

Specifically, regarding the "h=" tag:

     If present, this tag MUST include the header that was used to
     identify the sending domain, i.e., the "From:" or "Sender:"
     header; thus, this tag can never contain an empty value.

and also section 3.1 "Determining the Sending Address of an Email"

https://tools.ietf.org/html/rfc4870#section-3.1

where there is a protocol language regarding From: and Sender:

---

From: "John Levine" <[email-masked]>
Date: 14 Jul 2020 15:39:09 -0000

In article <[email-masked]>,
>will happen, in the case you offer.

It makes the assessment process quadratically more complicated. Now
the question is both whether this from regleissei.icu, but what do we
know about its relationship with fm.bank.

Admittedly, since a lot of MUAs display neither From nor Sender
address, it's not clear how much this matters.

R's,
John
-- 
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: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 08:55:05 -0700

> https://tools.ietf.org/html/rfc4870#section-3.3

Many thanks for citing DomainKeys.  I'd completely forgotten that it 
specified essentially the same as I am proposing:

>
>       3.1 <https://tools.ietf.org/html/rfc4870#section-3.1>.
>       Determining the Sending Address of an Email
>
> ...
>
>     In the first instance, the most visible address is clearly theRFC  <https://tools.ietf.org/html/rfc2822>
>     2822  <https://tools.ietf.org/html/rfc2822>  "From:" address [RFC2822  <https://tools.ietf.org/html/rfc2822>].  Therefore, a conforming email MUST
>     contain a single "From:" header from which an email address with a
>     domain name can be extracted.
>
>     A conforming email MAY contain a singleRFC 2822  <https://tools.ietf.org/html/rfc2822>  "Sender:" header
>     from which an email address with a domain name can be extracted.
>
>     If the email has a valid "From:" and a valid "Sender:" header, then
>     the signer MUST use the sending address in the "Sender:" header.
>
>     If the email has a valid "From:" and no "Sender:" header, then the
>     signer MUST use the first sending address in the "From:" header.

> and it did not change with DKIM followed up:

DKIM eliminated use of the 822.sender field.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 09:09:02 -0700

On 7/14/2020 8:39 AM, John Levine wrote:
>>> regleissei.icu.Â  To publish a DMARC policy would avail Farmers &
>>> Merchants nothing, then.

What is, or is not, displayed is irrelevant, since that has nothing to 
do with meaningful protection.

Analysis by the filtering subsystem is quite another and more important 
matter.

So I'll rephrase my question:

      Please compare and contrast how analysis is done now versus how it 
would be done with this proposal, and what dangers are created or made 
worse as a result of this proposal.

d/

---

From: "Doug Foster" <[email-masked]>
Date: Tue, 14 Jul 2020 12:41:18 -0400

Is not the whole point of your proposal to allow the MLM to authenticate the message based on the MLM domain signature alone, while presenting the document as originating from another domain?
That is the very behavior that DMARC is trying to prevent.

But since MLM editing is so important to you and others, it would be helpful if someone would document:

- what changes need to be made by an MLM?
- what objective is achieved by those changes?
- why MLM editing is the best way to achieve those objectives?
- what impact would occur if the MLM stopped editing and had to pursue those objectives with other measures?

We  cannot adequately address a requirement that has not been defined.

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Tuesday, July 14, 2020 12:09 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

On 7/14/2020 8:39 AM, John Levine wrote:
>> If regleissei.icu publishes a DMARC record and indicates support for 
>> use of Sender:, per the proposal, please explain exactly what bad 
>> things will happen, in the case you offer.

What is, or is not, displayed is irrelevant, since that has nothing to do with meaningful protection.

Analysis by the filtering subsystem is quite another and more important matter.

      Please compare and contrast how analysis is done now versus how it would be done with this proposal, and what dangers are created or made worse as a result of this proposal.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Jul 2020 19:25:06 +0200

On 14/07/2020 15:41, Dave Crocker wrote:
> If regleissei.icu publishes a DMARC record and indicates support for use of 
> Sender:, per the proposal, please explain exactly what bad things will happen, 
> in the case you offer.

Fm.bank, Farmers & Merchants State Bank in Archbold, Ohio, is one of the early 
dot-bank switchers.  _dmarc.bank doesn't yet exist, but it's planned, AFAIK.

Regleissei.icu was one of the many light footprint domains spammers used.  A 
year ago it had all DMARC, SPF, DKIM and whatever records.  Now it's gone.

At mine, I ban the whole .ico TLD.  However, life is not always easy.

I can enable DMARC on all .bank, and tell users to painstakingly check From:, 
and if they get phished I can tell them they're morons.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 10:30:42 -0700

...
> I can enable DMARC on all .bank, and tell users to painstakingly check 
> From:, and if they get phished I can tell them they're morons. 

Forgive me, but I do not understand how your note, in any way, responded 
to the substance of my query.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Jul 2020 19:42:03 +0200

On 14/07/2020 19:30, Dave Crocker wrote:
>>> Sender:, per the proposal, please explain exactly what bad things will 
>>> happen, in the case you offer.
> ...
> Forgive me, but I do not understand how your note, in any way, responded to the 
> substance of my query.

The bad thing is that _dmarc.fm.bank looses the effect of stopping phishing 
attempts, as the Sender: domain would override.  It keeps the ability to 
generate feedback about authentic messages, though.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 10:48:52 -0700

On 7/14/2020 10:42 AM, Alessandro Vesely wrote:
>> Forgive me, but I do not understand how your note, in any way, 
>> responded to the substance of my query.
> The bad thing is that _dmarc.fm.bank looses the effect of stopping 
> phishing attempts, as the Sender: domain would override.  It keeps the 
> ability to generate feedback about authentic messages, though.

One more time...

DMARC does not stop phishing attempts.

So rather than asserting a sweeping conclusion as you've offered, please 
explain that specific bad effects that will ensue.

I'm asking for substantive, technical and operational detail. Not broad, 
vague conclusions.

d/

---

From: Jim Fenton <[email-masked]>
Date: Tue, 14 Jul 2020 10:56:22 -0700

> Analysis by the filtering subsystem is quite another and more

Not specific to Dave's comment above, I'm really struggling to
understand what problem(s) we're trying to solve. The answers I get back
say something about "defending brand identity", which is a marketing,
not a technical consideration.

IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the
technical requirements. I am NOT volunteering to do this.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Jul 2020 20:00:56 +0200

On 14/07/2020 19:48, Dave Crocker wrote:
>>> Forgive me, but I do not understand how your note, in any way, responded to 
>>> the substance of my query.

Uh?

    DMARC is designed to prevent bad actors from sending mail that claims
    to come from legitimate senders, particularly senders of
    transactional email (official mail that is about business
    transactions).  One of the primary uses of this kind of spoofed mail
    is phishing (enticing users to provide information by pretending to
    be the legitimate service requesting the information).  Thus, DMARC
    is significantly informed by ongoing efforts to enact large-scale,
    Internet-wide anti-phishing measures.
                          https://tools.ietf.org/html/rfc7489#section-2.4

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 11:41:39 -0700

On 7/14/2020 10:56 AM, Jim Fenton wrote:
> Not specific to Dave's comment above,

Since this is a larger question and, as you note, not specific to my 
drafts, please post it under a separate Subject and thread, rather that 
confuse the focus of the current thread.

d/

---

From: "Doug Foster" <[email-masked]>
Date: Tue, 14 Jul 2020 16:17:47 -0400

This is a beautiful proposal if one assumes that domain owners will want to
change.    Since we do not have them well represented in this discussion, it
is a conclusion that needs to be tested.

I have pressed Dave on the issue of how good ML domains are to be
distinguished from criminal domains, a request which has not been answered.
We know that, after an edit, the only signature that can be valid is the
signature of the editor's domain.

The recipient domain can therefore be presented with two similar messages:
- a well-formed message that is signed by the good MLM domain and purports
to be on behalf of BigBank domain
- a well-formed message that is signed by a criminal domain and purports to
be on behalf of BigBank domain

Dave apparently assumes that the recipient system can reliably assign
reputation to the two messages based on the signature domain.    This might
be sufficient if the recipient domain had a reliable domain reputation
system.    As soon as one is invented, deployed, and universally trusted, we
can embrace his proposal.

Without another way to distinguish good MLMs from bad guys, I do not
understand how rearranging headers adds anything other than obfuscation.

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Joseph Brennan
Sent: Monday, July 13, 2020 2:28 PM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

This is an elegant solution. It puts the burden of change-- creating a
Sender field in all cases, and a variant DMARC record-- on the domain owner
who wants to send mail and use DMARC rules. The use of Sender complies with
RFC 5322, since it is optional whether to create Sender when it is the same
address as From.

With this implemented, developers of mailing list software can stop figuring
out which way to violate RFC 5322 in order to make mail deliverable, and
developers of clients do not have to create and display a new Author field.
Big win, for widespread acceptance, I would say.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 13:23:44 -0700

> understand how rearranging headers adds anything other than obfuscation.

I'll claim that this change does not meaningful change any of the threat 
vectors or protections against them that are currently in place.

Note, for example, that we already have mailing lists disabling DMARC 
protection on the From field, in a way that distorts the original 
information but actually also still retains it.  There do not seem to be 
any complaints about the handling resulting from such mail.

Rather, this proposal cleans up the email human factors while retaining 
the intended domain name protection.

d/

ps. I was really struck by being pointed to the DomainKeys RFC and 
re-discovering that it actually specified the use of 822.sender for 
exactly the use I've proposed.  I'd completely forgotten that Delaney 
did that.

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 20:29:58 -0400

> technical requirements. I am NOT volunteering to do this.

We will reach the same conclusions.  But if we simply remove RFC5016, 
Section 5.3 Item 10, then things will become very interesting:

   10. SSP MUST NOT provide a mechanism that impugns the existence of
       non-first party signatures in a message.  A corollary of this
       requirement is that the protocol MUST NOT link practices of first
       party signers with the practices of third party signers.

        INFORMATIVE NOTE: the main thrust of this requirement is that
        practices should only be published for that which the publisher
        has control, and should not meddle in what is ultimately the
        local policy of the receiver.

       Refs: Deployment Consideration, Section 4.3.

I was totally flabbergasted when this last item #10 was added. This 
was the "DKIM Policy Killer" and we have not recovered.  The irony now 
is the third party signer impugning on the 1st party policies.

1st Party Policies Matters! <g>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 Jul 2020 09:47:56 +0200

On 14/07/2020 22:23, Dave Crocker wrote:
> protection on the From field, in a way that distorts the original information 
> but actually also still retains it.  There do not seem to be any complaints 
> about the handling resulting from such mail.

Right.  I complain about MLMs _not disabling_ DMARC protection.

> Rather, this proposal cleans up the email human factors while retaining the 
> intended domain name protection.

While it's true that header munging miseducates users, this relief is worse 
than the pain itself.  It does not, in fact, retain domain protection.

> re-discovering that it actually specified the use of 822.sender for exactly the 
> use I've proposed.  I'd completely forgotten that Delaney did that.

I agree that sender signatures are more important than others.  My DKIM/DMARC 
filter sorts them after author's signatures, but before any other 3rd party's 
ones.  That ordering is reflected in DMARC reports.

Perhaps we could formalize Sender:'s role by inventing some kind of p=some, 
which requires Sender: alignment.  The From: domain has to remain the consumer 
of aggregate reports.  That way it can learn which senders redistribute its mail.

Best
Ale
--

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Wed, 15 Jul 2020 11:25:40 +0200

Alessandro Vesely <[email-masked]> writes:

> Perhaps we could formalize Sender:'s role by inventing some kind of
> p=some, which requires Sender: alignment.  The From: domain has to
> remain the consumer of aggregate reports.  That way it can learn which
> senders redistribute its mail.

This proposal seems spot on.

Some domain owners believe they have a magic switch called p=reject that
prevents unauthorized third parties from sending mail with From: field
that has their @domain. This is not so, and mailing lists are one of the
reasons why major email providers do not respect their policy.

I have switched the domains I control from p=quarantine to p=none. I
would use "p=sender-quarantine" or even "p=sender-reject" if it was
available. At the other end of the spectrum, domains which never ever
participate in mailing lists or mail forwarding need some kind of
"p=reject-yes-really-I-mean-it", to stop recipients from ignoring the
policy.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 15 Jul 2020 10:53:31 +0100

On 15/07/2020 10:25, Benny Lyne Amorsen wrote:
>  At the other end of the spectrum, domains which never ever

The domain owner doesn't know.  It's his users that want to sign up
for, and send to, MLs.   Who should be in control?
-- 
Cheers,
  Jeremy

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Wed, 15 Jul 2020 14:16:33 +0200

> for, and send to, MLs.   Who should be in control?

The domain owner is already (mostly) in control. They will generally
have authority over the email servers, which allows e.g. blocking all
mail with a mailing list header.

If the users do not like that policy, they will have to vote with their
feet and send mail from a different domain. I do not imagine that any of
the major "free" email domains will post "p=reject-yes-I-really-mean-it"
policies, so it is not a terrible hardship.

I checked a few of the major free email domains, they post p=none at
present. When that is the case and when they apply their own judgement
to p=reject and p=quarantine, what is the actual value of current DMARC?

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 15 Jul 2020 10:33:41 -0400

Gmail specifies quarantine.

Verizon.com, aol.com, and yahoo.com (common ownership) specify reject,
reject, and quarantine respectively.

Microsoft (live and Hotmail) specify none.

Embarqmail specifies none.

Which services did you check?

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Benny Lyne Amorsen
Sent: Wednesday, July 15, 2020 8:17 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

> for, and send to, MLs.   Who should be in control?

The domain owner is already (mostly) in control. They will generally have
authority over the email servers, which allows e.g. blocking all mail with a
mailing list header.

If the users do not like that policy, they will have to vote with their feet
and send mail from a different domain. I do not imagine that any of the
major "free" email domains will post "p=reject-yes-I-really-mean-it"
policies, so it is not a terrible hardship.

I checked a few of the major free email domains, they post p=none at
present. When that is the case and when they apply their own judgement to
p=reject and p=quarantine, what is the actual value of current DMARC?

---

From: "John Levine" <[email-masked]>
Date: 15 Jul 2020 10:46:25 -0400

>Gmail specifies quarantine.

No.  sp= is not the same as p=

$ host -t txt _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:[email-masked]"

>reject, and quarantine respectively.

No:

$ host -t txt _dmarc.verizon.com
_dmarc.verizon.com descriptive text "v=DMARC1; p=quarantine; sp=none; rua=mailto:[email-masked]; ruf=mailto:[email-masked]; rf=afrf; pct=100"

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email-masked];"

AOL and Yahoo both published p=reject after they had large security
breaches that let crooks steal their users' address books, and then
started sending spam to their users with return addresses of the
recipients' friends, leading to many complains and support calls. They
use DMARC to outsource the cost of their security failures to
unwilling mail admins all over the world.

Verizon.net has p=reject while verizon.com has p=quarantine.

The former is for their ISP customers, with mail hosted by Yahoo.
The latter is their corporate with mail handled by Proofpoint.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Mon, 20 Jul 2020 15:46:52 -0700

>From the abstract:
   "This affects end-to-end behavior of email, between the author and the
   final recipients, because mail from the same author is not treated
   the same, depending on what path it followed."

The mail from the same "author" is not treated the same because the message
has been modified in an unknown way.
It's not the path that matters.

As for the changes suggested, the draft doesn't speak to the intermediary
problem directly, but presumably you mean that an MLM would
replace the Sender: header with itself, and then DKIM sign as itself.  In
fact, any originator could generate "original" mail (in the sense of the
old days of email greeting cards and "share via email" web forms) with a
>From of anything as long as the Sender has an aligned signature.
And publishing the special record allows any originator to override the
existing policy provisions that DMARC provides.

This seems like third-party authentication without any authorization.

This proposal seems equivalent to removing alignment from DMARC, since the
message can now be signed by anyone as long as they put
another little bit in dns and another header on the message.

Changing the trust anchor also won't help the forwarding problem.  Imagine
that an anti-phishing filter learns what "good" mail from random.bank
looks like and associates that with their domain as a trust anchor.  As
soon as you forward it through another service which switches that anchor,
now you're
limited to knowledge of what goes through that anchor.  Maybe that's ok.

OTOH, if part of the benefit of DMARC is the policy hammer, do you lose
that benefit because anyone can override it?

Another way I'd think of this is that DMARC says "there's one true source
of this email"... and adding Sender into now brings in multiple concepts of
who
the source is.  I think this makes the problem a lot more like the
discussions we've had over having multiple From address domains on the
message, which
wins?  Now others are talking about p=no-I-really-mean-it again.

Your draft also implies that adding a Sender header changes where the
report goes, even on auth failure.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Mon, 20 Jul 2020 15:51:34 -0700

On Mon, Jul 20, 2020 at 3:46 PM Brandon Long <[email-masked]> wrote:

> The mail from the same "author" is not treated the same because the
> message has been modified in an unknown way.

I guess SPF is "path" and dkim is "content", but I think my distinction
still stands.

> limited to knowledge of what goes through that anchor.  Maybe that's ok.

For example, if you receive the message via forward, does the trust anchor
become your forwarder?  That seems like the opposite of what you want.

> report goes, even on auth failure.

Another thing, there are definitely domains which host mailing lists and
original content (ie, any GSuite domain for one), is there are a problem
with using the "mediator" version
of DMARC on every record?

Brandon

Brandon