Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

From: Neil Anuskiewicz <[email-masked]>
Date: Sat, 1 Aug 2020 18:26:38 -0700

I looked at ~3.5 million domain names and here's some of what I found. This
data might be useful to the discussion. As for me, I'm lurking and learning.

Anyway, I looked at ~3.5 million domain names and here's some of what I
found:
FTSE DMARC Adoption
DMARC Policy 10/18/2019
No record 56%
none 34%
quarantine 1%
reject 9%

F500 DMARC Adoption
DMARC Policy 10/18/2019
no record 49%
none 37%
quarantine 4%
reject 9%
ASX DMARC Adoption
DMARC Policy 10/18/2019
no record 59%
none 33%
quarantine 1%
reject 7%

On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz <[email-masked]>
wrote:

> I looked at ~3.5 million domain names and here's some of what I found.
> This wasn't a random sample but perhaps this data will be useful in this
> discussion:
>
> FTSE DMARC Adoption
>
> Snapshot (10/18)
> No record 56%
> none 34%
> quarantine 1%
> reject 9%
> F500 DMARC Adoption
>
> Snapshot (10/18)
> no record 49%
> none 37%
> quarantine 4%
> reject 9%
>
> ASX DMARC Adoption
>
> Snapshot (10/18)
> no record 59%
> none 33%
> quarantine 1%
> reject 7%
>
> Thanks.
>
> Neil
> On Thu, Jul 30, 2020 at 6:02 PM Luis E. Muñoz <dmarc-ietf.org=
> [email-masked]> wrote:
>
>> On 30 Jul 2020, at 15:52, Jim Fenton wrote:
>>
>> There's an underlying assumption here that I don't agree with: that
>> DMARC adoption equates to the publication of a p=reject DMARC policy,
>> and that everyone (or at least all Fortune 500 companies) should be
>> doing that. p=reject should only be used when the usage patterns of the
>> domain support that policy. I'm more inclined to say that 85% of Fortune
>> 500 companies are savvy enough not to publish a policy that doesn't fit
>> their usage patterns.
>>
>> I am currently observing ~215.5 million domain names. Out of those, ~64
>> million have a seemingly *valid* SPF record and ~113 million with at
>> least one MX record.
>>
>> This is a current breakdown of the (valid) DMARC records I am observing
>> over the general domain population above. This amounts to an adoption rate
>> of ~1.7%.
>> p count
>> none 2715614
>> quarantine 238584
>> reject 726045
>>
>> It is interesting that roughly half of those are not taking advantage of
>> the reporting. Here are the counts for those with neither rua= nor ruf=
>> in the DMARC records:
>> p count
>> none 1092990
>> quarantine 107767
>> reject 307614
>>
>> I do not have a definitive list of Fortune 500 domain names, but I
>> compile a rolling list of domain names with most traffic using multiple
>> sources, which currently holds ~1.8 million unique domain names.
>>
>> The breakdown of DMARC records from that high-traffic population is shown
>> below, and it amounts to about 6.3%.
>> p count
>> none 79367
>> quarantine 18094
>> reject 15875
>>
>> For completeness, here is the same report, counting only those that have
>> neither rua= nor ruf= in the DMARC record. The ratio of *silent*
>> p=quarantine and p=reject seems around half as in the case of the
>> general population.
>> p count
>> none 32561
>> quarantine 4534
>> reject 2760
>>
>> It would seem that those high-traffic domains are ~5x more likely to
>> adopt DMARC. To me, these numbers speaks of thoughtful and deliberate
>> deployment that outpaces the general domain name registrations.
>>
>> That said, I cannot claim whether the list of high-traffic domains is
>> actually a good proxy for the domain portfolio of the Fortune 500 companies.
>>
>> Best regards
>>
>> -lem
>> _______________________________________________
>> dmarc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 02 Aug 2020 15:00:52 GMT

I have reviewed recent posts to this mailing list:   Submissions have come from 39 different people on 34 unique domains.   Of these, 11 have munged headers, indicating that they use an enforceable DMARC policy.   This is a much higher percentage than your general survey.

I wonder if this is typical  - are mailing list subscribers more likely to be on DMARC-enforcing domains than the general population?

Do the mailing list operators have data about what percentage of their subscribers (or percentage of unique domains) have DMARC policy enforcement in place?

DF

----------------------------------------
From: Neil Anuskiewicz <[email-masked]>
Sent: 8/1/20 9:27 PM
To: Luis E. Muñoz <dmarc-ietf.org=[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
I looked at ~3.5 million domain names and here's some of what I found. This data might be useful to the discussion. As for me, I'm lurking and learning.

Anyway, I looked at ~3.5 million domain names and here's some of what I found:

FTSE DMARC Adoption	  
 DMARC Policy	 10/18/2019	  
 No record	 56%	  
 none	 34%	  
 quarantine	 1%	  
 reject	 9%

F500 DMARC Adoption

 DMARC Policy	 10/18/2019	  
 no record	 49%	  
 none	 37%	  
 quarantine	 4%	  
 reject	 9%	 

ASX DMARC Adoption

 DMARC Policy	 10/18/2019	  
 no record	 59%	  
 none	 33%	  
 quarantine	 1%	  
 reject	 7%	 

On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz <[email-masked]> wrote:

I looked at ~3.5 million domain names and here's some of what I found.. This wasn't a random sample but perhaps this data will be useful in this discussion:

FTSE DMARC Adoption	  
  	 Snapshot (10/18)

 No record	 56%	  
 none	 34%	  
 quarantine	 1%	  
 reject	 9%	 

F500 DMARC Adoption	  	  
  	 Snapshot (10/18)

 no record	 49%	  
 none	 37%	  
 quarantine	 4%	  
 reject	 9%

ASX DMARC Adoption	  	  
  	 Snapshot (10/18)

 no record	 59%	  
 none	 33%	  
 quarantine	 1%	  
 reject	 7%	 

Thanks.

Neil
On Thu, Jul 30, 2020 at 6:02 PM Luis E. Muñoz <dmarc-ietf.org=[email-masked]> wrote:

I am currently observing ~215.5 million domain names. Out of those, ~64
million have a seemingly valid SPF record and ~113 million with at least one MX record.

This is a current breakdown of the (valid) DMARC records I am observing over the general domain population above. This amounts to an adoption rate of ~1.7%.
p	 count	 
	 none	 2715614	  
 quarantine	 238584	  
 reject	 726045	 

It is interesting that roughly half of those are not taking advantage of the reporting. Here are the counts for those with neither rua= nor ruf= in the DMARC records:
p	 count	 
	 none	 1092990	  
 quarantine	 107767	  
 reject	 307614	 

I do not have a definitive list of Fortune 500 domain names, but I compile a rolling list of domain names with most traffic using multiple sources, which currently holds ~1.8 million unique domain names.

The breakdown of DMARC records from that high-traffic population is shown below, and it amounts to about 6.3%.
p	 count	 
	 none	 79367	  
 quarantine	 18094	  
 reject	 15875	 

For completeness, here is the same report, counting only those that have neither rua= nor ruf= in the DMARC record. The ratio of silent p=quarantine and p=reject seems around half as in the case of the general population.
p	 count	 
	 none	 32561	  
 quarantine	 4534	  
 reject	 2760	 

It would seem that those high-traffic domains are ~5x more likely to adopt DMARC. To me, these numbers speaks of thoughtful and deliberate deployment that outpaces the general domain name registrations.

That said, I cannot claim whether the list of high-traffic domains is actually a good proxy for the domain portfolio of the Fortune 500 companies.

Best regards

-lem

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2020 12:57:56 -0400

>Do the mailing list operators have data about what percentage of their subscribers (or percentage of unique domains) have DMARC policy enforcement in place?

In my experience it completely depends on the list. I have a list of
folk dancers with a lot of old AOL and Yahoo addresses with DMARC
policies, and I have other lists where it's mostly gmail and
Hotmail/Outlook, without.

R's,
John

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 02 Aug 2020 18:55:09 GMT

Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you?    

If they would provide a way to register a mailing list and the servers from which it comes, and allow DMARC exceptions for traffic from those registered lists, your situation would be much easier? 

DF

----------------------------------------
From: "John Levine" <[email-masked]>
Sent: 8/2/20 12:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2020 14:57:23 -0400

> Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you?

No, it is fair to say that misuse of DMARC is the problem.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Aug 2020 14:22:36 -0700

On Sun, Aug 2, 2020 at 11:55 AM Douglas E. Foster <
[email-masked]> wrote:

> If they would provide a way to register a mailing list and the servers
> from which it comes, and allow DMARC exceptions for traffic from those
> registered lists, your situation would be much easier?
>

Ignoring for the moment the problems of scale with any "register your
lists" solution, I don't think users can reasonably be expected to keep
such a registration current if, say, the servers were to move.  Such a
migration would no longer be transparent, as it is today.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2020 17:24:39 -0400

>> registered lists, your situation would be much easier?

If large mail providers were willing to whitelist known mailing lists we 
wouldn't need ARC.

See previous messages for why that isn't sufficient.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sun, 2 Aug 2020 14:28:40 -0700

On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote:
> lists" solution, I don't think users can reasonably be expected to 
> keep such a registration current if, say, the servers were to move.  
> Such a migration would no longer be transparent, as it is today.

+1

When someone proposes a scheme, it will help for them to list who the 
relevant actors must be and what they must do and then deal with the 
question of scaling.  That is, how will it be possible for this to work 
at Internet scale?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 03 Aug 2020 00:43:56 GMT

Murray took server too literally.   I have expressed before that a system could do a sender authentication lookup on List-ID as easily as on From.   In this respect, it is similar to Dave's proposal, without the added complexity of additional identifiers.   So think "Registerd List-ID plus DKIM signature (or SPF, but DKIM seems both sufficient and preferable.)

I am not sure what "Internet Scale" means to you.   Most of the major recipients have bulk mailer registration systems.   It does not guarantee whitelisting, but it tends to produce that effect.   I have had occasion to register with most of them.   So "does not scale" is not obvious to me.

Even more to the point, check out this link:
https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto 

Verizon appears to be offering a service (probably for extra cost) which is based on:
(a) a well-defined mail stream from a known sender, and 
(b) a mailbox user identifying that mail stream as subscribed, and therefore desirable.

It appears that the target senders are retailers who want to ensure that their sale announcements are read before the sale is over.   It is an "Internet scale" application of the type of registration I was suggesting:   Well-identified senders, coupled with end-user endorsement, receive preferred treatment.

As to the transparency question, it should be clear that there will be no simple solution to the ML problem.  As long as mailing lists appear identical to a malicious spoofer, their only protection is their own sterling reputation.   But the only way to establish an acceptable reputation is to either register with the receiver directly, or register with the sender in a way that the receiver will honor.    Your proposal does nothing to distinguish mailing lists from malicious spoofers, so it does nothing to solve the problem.   Mailing lists either need to send using the ML domain as the From address, not modify the message, or establish a credible reputation.   There are no other possibilities on this side of FantasyLand.

DF 

----------------------------------------
From: Dave Crocker <[email-masked]>
Sent: 8/2/20 5:29 PM
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

+1

d/

---

From: Ken O'Driscoll <[email-masked]>
Date: Mon, 3 Aug 2020 13:56:52 +0100

On 03/08/2020 01:43, Douglas E. Foster wrote:
>
> I am not sure what "Internet Scale" means to you.   Most of the major
> recipients have bulk mailer registration systems.   It does not
> guarantee whitelisting, but it tends to produce that effect.   I have
> had occasion to register with most of them.   So "does not scale" is
> not obvious to me.

This is not correct. In the past some large providers did offer such
lists but these days most have moved away from that model for various
reasons. You'll still find someone offering such as service, and
pay-to-play is a thing too but none of this is a) widespread and b)
based on any type of standard - it's all proprietary. The same goes for
sender certification services such as ReturnPath.

"Internet Scale" means being able to scale to internet level of usage
and platform interoperability.  TCP/IP and DNS are good examples. Data
(e.g. lists of approved senders) maintained internally by individual
organisations can't scale to that level for the same reason that
organisations siloing their own DNS and routing information wouldn't
work. Interoperability.

Organisations publishing information (e.g. an SPF record) in their DNS
zone works because it's based on an existing internet scale
interoperable platform. While the "heavy lifting" of interpreting the
SPF record might be undertaken by a variety of different software and
system platforms, the mechanism is standardised based on the RFC. Again,
interoperability.

Ken.

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 04 Aug 2020 13:18:26 +0200

John R Levine skrev den 2020-08-02 23:24:

> If large mail providers were willing to whitelist known mailing lists
> we wouldn't need ARC.

if no one breaked dkim then we did not need arc

> See previous messages for why that isn't sufficient.

missing arc will not break spf dkim, but it preserves state of pass TO 
the maillists, but only if maillists run arc at the first stage of 
breaking dkim, i only know dovecot maillist that have solved it as it 
should be, i think others could do the same of not breaking dkim, or if 
need to, do a fully arc sealing

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 4 Aug 2020 08:21:01 -0700

This is a known issue with many calendaring frameworks. Besides the issue
of delegates who are sending on behalf of someone in another domain, most
calendaring systems send "forwarded" invitations by trying to resend in the
name of the event originator.

--Kurt

---

From: Jim Fenton <[email-masked]>
Date: Tue, 4 Aug 2020 08:33:35 -0700

> If large mail providers were willing to whitelist known mailing lists

And as has been pointed out (perhaps also by John), ARC still requires
an allowlist or some other way to determine who is allowed to make
authenticated changes to a message.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 4 Aug 2020 08:39:23 -0700

On 8/2/20 5:43 PM, Douglas E. Foster wrote:
> As to the transparency question, it should be clear that there will be
> no simple solution to the ML problem. 

Actually, there is: If your domain has users that use mailing lists,
don't publish 'reject' or 'quarantine' policies. Generally this means to
just use those policies for domains used for transactional email.

Unfortunately we seem to be focused on very complex technical solutions
to a misdeployment problem.

-Jim

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Aug 2020 12:10:52 -0400

> to a misdeployment problem.
There is another solution. Move users to a separate domain from the domain
your transactional mails are sent from. You can also put users on a
separate subdomain.

There are many ways for this to be addressed without coming up with complex
standards solutions.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 4 Aug 2020 18:52:26 +0200

> your transactional mails are sent from. You can also put users on a

Yet another solution would be to not use DMARC.  The status quo ante.

While p=none is a technically valid position, there seems to be a
demand of a mail infrastructure where spoofing is not allowed.

Best
Ale
--

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 5 Aug 2020 11:36:19 -0500

>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG, so that might be a good audience to validate the viewpoint that users' domains can't benefit from p=quarantine|reject.  Perhaps it should be included in a BCP?  Maybe it is, and I'm misremembering?  Granted, I've only been a member for a few years.  Maybe it was a common understanding years ago and no one talks about it anymore?

For example, when I was invited by the technical committee to present our strategy and challenges deploying DMARC for our institution, no one told me we were misdeploying.  The session was pretty well attended, and I don't think I put everyone to sleep.  Now I feel like my speech was counterproductive because I may have encouraged others to misdeploy DMARC too.

>> There is another solution. Move users to a separate domain from the domain

Long ago we put users on our org domain as a way to unify users (in a very decentralized institution) under a single domain identity, and that branding decision is not going to be undone, politically.  Any project to move users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually completes due to stragglers with very legitimate reasons to not give up sending from their old address.  

I think that end-users would rather see their list mail be rewritten than be told to change their identity.  I know that some people on this list think that the domain in the from header isn't commonly visible anymore, but the domain is extremely important to users' sense of identity.  

>> your transactional mails are sent from. You can also put users on a

To the idea of clean separation:  We only encourage (without DMARC there is no way to enforce) subdomains for transactional email despite "brand minded" people insisting on using the org domain (or just using it without asking).  Despite everyone having an address in the org domain, we still have many users using legacy subdomains, and some of those subdomains are mixed-use.  

DMARC is great for getting visibility on this "separation" problem.  It's not until we moved past p=none that we could get any sticks behind our carrots.  

What I'm saying is that mixed-use domains are common and they proliferated due to the lack of domain alignment enforcement prior to DMARC.  Even when there is intention by IT to separate the use cases, they need DMARC to get both the visibility and the manageability/enforcement.

I've observed other universities using their single org domain for everything, and they don't find out they have a problem until they try to implement DMARC.  It's easier for them to move the transactional email to subdomains than to move users.  That is, unless they just give up on the idea of DMARC altogether.

This might be a stretch, but I think the "DMARC is different for user vs transactional domains argument" dovetails with the need for sp to walk the domain tree.  If the assertion is that the domain with users is fundamentally different than domains used for transactional email, and most institutions use their org domain for their users, and subdomains are a mixed bag of varying use cases, then the org domain's DMARC policy isn't the best candidate for inheritance.  

> demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/

I don't think DHS got the memo about misdeploying DMARC, either.  I know that around 2018, the person maintaining the MLM for our astrophysics center had to scramble to implement header munging because of all of the .gov's publishing p=reject

Jesse

---

From: Dotzero <[email-masked]>
Date: Wed, 5 Aug 2020 15:52:15 -0400

On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson <jesse.thompson=
[email-masked]> wrote:

> I've never heard this misdeployment viewpoint in the context of M3AAWG, so
> that might be a good audience to validate the viewpoint that users' domains
> can't benefit from p=quarantine|reject.  Perhaps it should be included in a
> BCP?  Maybe it is, and I'm misremembering?  Granted, I've only been a
> member for a few years.  Maybe it was a common understanding years ago and
> no one talks about it anymore?
>

Not a knock on M3AAWG but many of the members are more interested in
deliverability than anti-abuse. The Sender side of M3AAWG is dominated by
ESPs rather than Brand Senders. I say this as the Founder and Chair of
Brand SIG for 10 years until I left my employer that was a member of M3AAWG.

>
> For example, when I was invited by the technical committee to present our
> strategy and challenges deploying DMARC for our institution, no one told me
> we were misdeploying.  The session was pretty well attended, and I don't
> think I put everyone to sleep.  Now I feel like my speech was
> counterproductive because I may have encouraged others to misdeploy DMARC
> too.
>

You were presenting what you did. It may or may not have been
counterproductive.

> Long ago we put users on our org domain as a way to unify users (in a very
> decentralized institution) under a single domain identity, and that
> branding decision is not going to be undone, politically.  Any project to
> move users from one domain identity to another is a huge lift; it takes a
> lot of time, effort, and never actually completes due to stragglers with
> very legitimate reasons to not give up sending from their old address.
>

I implemented for an Enterprise with large ecommerce/social sites and 20k
seats. The only people that were allowed to keep accounts on the primary
domains were people who directly supported the websites and they were not
allowed to use those accounts for anything other than supporting the
websites. They had accounts at the other domain just as all the other users.

>
> I think that end-users would rather see their list mail be rewritten than
> be told to change their identity.  I know that some people on this list
> think that the domain in the from header isn't commonly visible anymore,
> but the domain is extremely important to users' sense of identity.
>

Their identity at that organization is subject to the determinations of the
organization. It is amazing how quickly after a one time transition that
users get used to  their new "identity".

> To the idea of clean separation:  We only encourage (without DMARC there
> is no way to enforce) subdomains for transactional email despite "brand
> minded" people insisting on using the org domain (or just using it without
> asking).  Despite everyone having an address in the org domain, we still
> have many users using legacy subdomains, and some of those subdomains are
> mixed-use.
>

You need buy-in from senior management for any email authentication
efforts. When you add up the costs of customer support contacts for dealing
with fraudulent email claiming to be from your organization, reputation
damage, etc., management becomes more willing to buy into a comprehensive
strategy.

>
> DMARC is great for getting visibility on this "separation" problem.  It's
> not until we moved past p=none that we could get any sticks behind our
> carrots.
>
> What I'm saying is that mixed-use domains are common and they proliferated
> due to the lack of domain alignment enforcement prior to DMARC.  Even when
> there is intention by IT to separate the use cases, they need DMARC to get
> both the visibility and the manageability/enforcement.
>

If it is only IT pushing this, you are probably doomed to failure.

>
> I've observed other universities using their single org domain for
> everything, and they don't find out they have a problem until they try to
> implement DMARC.  It's easier for them to move the transactional email to
> subdomains than to move users.  That is, unless they just give up on the
> idea of DMARC altogether.
>

Organizations make choices based on perceived benefits and costs.

>
> This might be a stretch, but I think the "DMARC is different for user vs
> transactional domains argument" dovetails with the need for sp to walk the
> domain tree.  If the assertion is that the domain with users is
> fundamentally different than domains used for transactional email, and most
> institutions use their org domain for their users, and subdomains are a
> mixed bag of varying use cases, then the org domain's DMARC policy isn't
> the best candidate for inheritance.
>

The assumption was/is that the organizational domain most closely tracks
the risk for abuse and is therefore the one that most needs protection.
Therefore inheritance should be the rule rather than the exception. It also
means you don't have to walk the full tree. You only need to check the base
domain if the subdoain doesn't specify a policy.

> I don't think DHS got the memo about misdeploying DMARC, either.  I know
> that around 2018, the person maintaining the MLM for our astrophysics
> center had to scramble to implement header munging because of all of the
> .gov's publishing p=reject
>
> The .gov space has an interesting and long history with regard to email
authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP
(Executive Office of The President) to create and give training on email
authentication for .gov that was turned into a virtual training environment
that was available for all government employees. The specific impetus were
a series of incidents that included fake malicious White House ecards
purporting to be online Christmas cards that were sent to government
contractors and others. Required authentication for .gov domains moved
forward in fits and starts up to the point of the DHS mandate. DHS
approached the use of DMARC and authentication as a blunt one size fits all
instrument.

The reality is that the devil is always in the details.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 6 Aug 2020 10:16:07 +0200

On 2020-08-05 9:52 p.m., Dotzero wrote:
> Required authentication for .gov domains moved forward in fits and
> starts up to the point of the DHS mandate. DHS approached the use
> of DMARC and authentication as a blunt one size fits all
> instrument.

That makes sense!  If you look at email from a user POV, how can you
justify the fact that transactional mail is protected while ordinary
people's identities can be seized scot-free?

I think DHS interprets a general feeling.

> The reality is that the devil is always in the details.

Right, and we're the fairy godmother who gotta work them out.  With
From: rewriting, Author: Sender:, To:, and DKIM transforms we're well
into it, aren't we?

Best
Ale
--

---

From: Autumn Tyr-Salvia <[email-masked]>
Date: Fri, 7 Aug 2020 10:31:54 +0000

What I find very interesting about this email from Jesse, and Mike's response is that I hear these words coming from two very different experiences of deploying DMARC.

In my role doing onboarding at Agari, I have worked with many different organizations on their DMARC projects. I have worked with numerous corporate groups, as well as governmental organizations, nonprofits, and universities. Universities operate with a somewhat different set of expectations than other groups in ways that make DMARC additionally challenging.

Here are a few things I have learned implementing DMARC for multiple universities:

  *   Universities have a significantly higher degree of user and use case turnover than other organizations, by a lot. There are new students and staff every term, and many more of them will use their email address to send out email over various third party tools. In the corporate world, sure there are employees coming and going all the time, and new projects, but there is a much greater degree of stability in terms of systems sending out email.
  *   University IT has much less control over their users than corporate IT. In corporate IT, it is not unusual for IT leadership to make decisions on what applications will and will not be supported, and to have general support for this from the top. In higher education, IT teams seem to frequently be told that they must support whatever their users request, and have very little authority.
  *   Most universities serve a greater breadth of use cases than most other organizations. Consider an organization that is a fundraising nonprofit, scientific research group in multiple disciplines, hospital, mental health clinic, employer with HR tools, housing coordinator, childcare coordinator, gym, sports arena, transportation system, provider of continuing education to certified professionals, press agency, mailing list provider, forwarder, etc. all in one. There are a lot of niche tools that can send email in each of these different use cases, but universities are the only place I see so many of them all together.
  *   Universities are highly decentralized. It seems like every major school inside a university (school of public health, school of humanities, etc.) has its own policies and culture, and sometimes its own IT staff.
  *   Universities tend to have more legacy technology than other organizations (except government).

The reason I mention all this stuff is that I feel like some of what is being suggested here misses this reality.

Mike said, "You need buy-in from senior management for any email authentication efforts. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy." - in the higher education world, I don't see it working like this. IT staff can get enough buy-in to decide to work on DMARC as a project, but the costs of support contacts are likely spread out over multiple groups in a way that is very hard to quantify at a higher level, and even if they were to consider that, they would still be more likely to say that a comprehensive strategy is good and all, but it still matters more to them that good old Professor 1984 can still use his favorite application even though it doesn't conform to modern security standards.

I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to stop because it might make things a little inconvenient. Many universities do not attempt DMARC at all, so I think any work we can do to make it easier on them would encourage greater adoption.

Thanks,

Autumn Tyr-Salvia
[email-masked]
Agari Principal Customer Success Engineer

________________________________
From: dmarc <[email-masked]> on behalf of Dotzero <[email-masked]>
Sent: Wednesday, August 5, 2020 12:52 PM
To: Jesse Thompson <jesse.thompson=[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson <jesse.thompson=[email-masked]<mailto:[email-masked]>> wrote:
On 8/4/20 11:52 AM, Alessandro Vesely wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton <[email-masked]<mailto:[email-masked]>> wrote:

Not a knock on M3AAWG but many of the members are more interested in deliverability than anti-abuse. The Sender side of M3AAWG is dominated by ESPs rather than Brand Senders. I say this as the Founder and Chair of Brand SIG for 10 years until I left my employer that was a member of M3AAWG.

You were presenting what you did. It may or may not have been counterproductive.

I implemented for an Enterprise with large ecommerce/social sites and 20k seats. The only people that were allowed to keep accounts on the primary domains were people who directly supported the websites and they were not allowed to use those accounts for anything other than supporting the websites. They had accounts at the other domain just as all the other users.

Their identity at that organization is subject to the determinations of the organization. It is amazing how quickly after a one time transition that users get used to  their new "identity".

You need buy-in from senior management for any email authentication efforts. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy.

The assumption was/is that the organizational domain most closely tracks the risk for abuse and is therefore the one that most needs protection. Therefore inheritance should be the rule rather than the exception. It also means you don't have to walk the full tree. You only need to check the base domain if the subdoain doesn't specify a policy.

> demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyber.dhs.gov%2Fbod%2F18-01%2F&data=02%7C01%7Catyrsalvia%40agari.com%7Cd897635e2c654363de9608d839791b99%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637322539599239026&sdata=8hnuQvc7CtCUIyzbwMLcy5C4Jtypn969G%2BV6vAvkSG8%3D&reserved=0>

I don't think DHS got the memo about misdeploying DMARC, either.  I know that around 2018, the person maintaining the MLM for our astrophysics center had to scramble to implement header munging because of all of the ..gov's publishing p=reject

The .gov space has an interesting and long history with regard to email authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP (Executive Office of The President) to create and give training on email authentication for .gov that was turned into a virtual training environment that was available for all government employees. The specific impetus were a series of incidents that included fake malicious White House ecards purporting to be online Christmas cards that were sent to government contractors and others. Required authentication for .gov domains moved forward in fits and starts up to the point of the DHS mandate. DHS approached the use of DMARC and authentication as a blunt one size fits all instrument.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2020 15:12:16 -0400

In article <[email-masked]> you write:
>I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a
>more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to
>stop because it might make things a little inconvenient.

I was with you up until that sentence, since it trivializes the real
problems that overly strict DMARC policies cause.

Just yesterday I was sorting out a problem with people trying to
finish editing a revised IETF standard about real-time web
applications. Some of the authors' messages were disappearing,
apparently at random. I saw what the problem was, one of the authors
is at a big company whose IT department insists on p=reject (and has
blown off complaints from fairly senior people about the problems it
causes), the other uses an MIT alumni address that recently moved its
hosting to Microsoft without telling anyone that the new host enforces
DMARC policy while the old one didn't.

My guess is that MIT figured Microsoft will host this for free, that's
great, totally unaware that some of its users' mail would silently
break.

I told them as a workaround they needed to directly cc each other when
they send anything to the group list, but the whole thing is a
self-inflicted wound.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Aug 2020 16:16:02 -0700

On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster <
[email-masked]> wrote:

> Murray took server too literally.   I have expressed before that a system
> could do a sender authentication lookup on List-ID as easily as on From.
> In this respect, it is similar to Dave's proposal, without the added
> complexity of additional identifiers.   So think "Registerd List-ID plus
> DKIM signature (or SPF, but DKIM seems both sufficient and preferable.)
>

If we take "server" to mean a tuple made up of a List-ID value and a "d="
value from a validated DKIM signature, which I believe is what you're
saying here, the first occurrence of this necessarily has no internal value
(or history) attached to it.  That means the operator has to develop
meaning for it over time, which doesn't tell it how to handle the first N
such messages.  Err on the side of openness and you have a spam or attack
vector; err on the side of defense and you irritate your users by denying
them some list traffic until a reputation can develop.

And it's probably actually a three-tuple, with the third part being the
recipient.  Otherwise, I could register (or trigger the auto-registration
of) any two-tuple I want and thus intentionally let in my preferred list
streams, good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration
scheme, every time they get it wrong by entering the wrong data or failing
to even do it at all, you've got a failure mode to deal with, usually in
the form of user complaints which require other humans to resolve.  That
makes it relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain,
maybe to a new name, maybe both.  Every time that happens, the process has
to start over.  Naturally lists won't want to do this because of the
sterling reputations they've developed, but the pain reappears whenever the
process needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I
have a better idea.  I am saying there's multi-faceted pain in every
direction in this space, and this is no exception.  Whatever path we choose
to deploy here has to account for those choices and their side effects, and
the ways they might be gamed.

> recipients have bulk mailer registration systems.   It does not guarantee
> whitelisting, but it tends to produce that effect.   I have had occasion to
> register with most of them.   So "does not scale" is not obvious to me.
>

"Internet Scale" means millions or billions of users, like GMail or Yahoo
or AOL or Microsoft have.  Since they have the bulk of the inboxes, a
solution needs to at least consider that size of use case, or explain why
those cases don't need to be considered.

I've never seen this manual registration process to which you refer.  Where
can I find it, for example, on GMail?

Even more to the point, check out this link:
> It appears that the target senders are retailers who want to ensure that
> their sale announcements are read before the sale is over.   It is an
> "Internet scale" application of the type of registration I was suggesting:
>   Well-identified senders, coupled with end-user endorsement, receive
> preferred treatment.
>

Is there a technical description someplace of the mechanism behind what
they're doing?

As to the transparency question, it should be clear that there will be no
> simple solution to the ML problem.
>

Indeed.

[...] But the only way to establish an acceptable reputation is to either
> register with the receiver directly, or register with the sender in a way
> that the receiver will honor.
>

This needs to scale, from both ends:

1) If I as a new list operator want my list traffic to get accepted, how
could I possibly go about registering with all (or even most) mailbox
providers in a way they will trust?

2) If I as a mailbox provider want to give my users quality service and
also spam filtering, what way can I offer list operators to identify
themselves that can't be spoofed, and will only be exploited by good
actors?  Putting this burden on my users doesn't feel tenable.

-MSK

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 7 Aug 2020 19:24:20 -0500

> problems that overly strict DMARC policies cause.

Maybe Autumn was reflecting the reality that the industry has already trivialized DMARC problems for these "misdeployments".  

> great, totally unaware that some of its users' mail would silently

Customers of Microsoft don't like to call things bundled in an expensive package "free".

My peeve in recent years is that universities were essentially coerced (economically) into being the customers of Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a voice.

We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC.

We need spoofing protection for all of our domains without being told we're misdeploying.

We know that we need advanced local policy controls for DMARC enforcement and we don't want to be blamed when the vendor doesn't give us those controls (to your MIT example) 

> they send anything to the group list, but the whole thing is a

Maybe it was inflicted by the domain owner onto the person maintaining the mailing list.  (In my experience, this is where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.)

Again, I think MLM header munging is here to stay, and list recipients needs to get used to it (I'd like p=quarantine pct=0 be the default behavior so that domains choosing to misdeploy DMARC aren't second class).  

I'd like to see a way to un-munge mail from trusted intermediaries, but that sounds impractical.  

I think ARC has promise but it has some challenges that I hope can be overcome; notably a mechanism for the receiver to indicate trust to the intermediary (so that it knows it doesn't need to munge).

At that point, I can start to figure out how to deal with the mailbox-level forwarded mail for faculty/alumni/emeriti...

Jesse

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 08 Aug 2020 01:36:27 GMT

Murray, I  have most recently used this link at AOL/Yahoo:  https://postmaster.verizonmedia.com/sender-request 

I have considered using the more complete "Complaint Feedback Loop", https://postmaster.verizonmedia.com/cfl-request  but have never completed the process.

Maybe they are the last to offer this type of feature.  Or maybe my memory is imagining things   Now that you have pressed me, I cannot remember whether I have had success with other services or not.

My heart is not in prior registration either, but I was trying to lay out the next-best alternative for those who want an alternative to using the MLM domain identity.    

The goal of DMARC is to end spoofing, which requires everyone to send using their own domain, even when performing a favor for someone in another domain.   A recipient domain owner has the right to define the rules for getting into its network.    Those who want into that network should play by the rules of that network, whether the rules are liked or disliked. 

An incoming email is a take-it-or-leave-it proposition for most recipients.   My domain does not have the market power to alter sender behavior.   When I receive a spoofed message that the recipient actually wants, I end up creating an exception to allow the spoof.   Spoofing senders are counting on their ability to force me to do that.   However, Microsoft is powerful enough to engage in a standoff.    Those who want to send to Microsoft destinations will need to not violate DMARC.   I hope and expect that they will win this battle.

DMARC is not new.   Products that have not become DMARC-aware are as obsolete as WindowsXP.   Unfortunately, that does include a lot of products.

Over a year ago, I was about to recommend Proofpoint as our new email filtering vendor.   But the next morning I realized that their secure email service will spoof the identity of non-clients when they respond to a message from a client.   I had a real problem with a vendor promoting their ability to enforce DMARC on incoming mail, while also violating DMARC on their secure email service.   Then I saw that Cisco Ironport did the same thing.   I raised CIRT issues with both vendors, but nothing has changed.   Maybe Microsoft will be able to change their attitudes.
DF

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 8/7/20 7:16 PM
To: Doug Foster <[email-masked]>
Cc: Dave Crocker <[email-masked]>, IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster <[email-masked]> wrote:
Murray took server too literally.   I have expressed before that a system could do a sender authentication lookup on List-ID as easily as on From.   In this respect, it is similar to Dave's proposal, without the added complexity of additional identifiers.   So think "Registerd List-ID plus DKIM signature (or SPF, but DKIM seems both sufficient and preferable.)

If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it.  That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages.  Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop.

And it's probably actually a three-tuple, with the third part being the recipient.  Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve.  That makes it relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both.  Every time that happens, the process has to start over.  Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I have a better idea.  I am saying there's multi-faceted pain in every direction in this space, and this is no exception.  Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed.

"Internet Scale" means millions or billions of users, like GMail or Yahoo or AOL or Microsoft have.  Since they have the bulk of the inboxes, a solution needs to at least consider that size of use case, or explain why those cases don't need to be considered.

I've never seen this manual registration process to which you refer.  Where can I find it, for example, on GMail?

Is there a technical description someplace of the mechanism behind what they're doing?

As to the transparency question, it should be clear that there will be no simple solution to the ML problem.

Indeed.

[...] But the only way to establish an acceptable reputation is to either register with the receiver directly, or register with the sender in a way that the receiver will honor.

1) If I as a new list operator want my list traffic to get accepted, how could I possibly go about registering with all (or even most) mailbox providers in a way they will trust?

2) If I as a mailbox provider want to give my users quality service and also spam filtering, what way can I offer list operators to identify themselves that can't be spoofed, and will only be exploited by good actors?  Putting this burden on my users doesn't feel tenable.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2020 22:27:43 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

Complaint feedback loops just mean you say (perhaps with verification)
that you're the contact for this range of IPs or domain names, and if
a user presses the Junk button, the system can send you a copy of the
report. It's not whitelisting, and it only covers about the first
quarter inch of the long tail.

Some years back people kept asking Spamhaus to set up a whitelist, so
they hired me to do it. Technically it worked fine, but it soon became
apparent that the only people who were interested weren't people who
we'd want to whitelist. The good quality senders get their mail
delivered already, the terrible ones didn't bother, and all we heard
from were people who sometimes sent some spam along with the good mail
but assured us they were nice people. (Many universities fall into
this category.) I think you'll find that all of the existing whitelist
like things are a sideshow to the company's real business of
deliverability consulting.

For DMARC, it would be nice if there were a shared list of credible
forwarders, not to automatically accept their mail, but just to say
they're good enough that you can believe what's in their ARC seals
when you're doing the usual spam filtering. You can't just let people
sign themselves up for a list like that, since every dodgy bulk mailer
will figure this will get them an extra 2% delivery, and we've never
gotten past a vague hope that we could canvass people we know to make
a combined set of mailing lists hosts we know.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2020 22:32:59 -0400

>Customers of Microsoft don't like to call things bundled in an expensive package "free".

I have no idea what their pricing ie. My university uses Gmail for the
alumni service and I believe that actually is free.

>Maybe it was inflicted by the domain owner onto the person maintaining the mailing list.  (In my experience, this is
>where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.)

The IETF is entirely aware of DMARC, and their main mailing lists use
a version of my dmarc.fail hack. This one's off in a corner, on the list of things
to be cleaned up.

>My peeve in recent years is that universities were essentially coerced (economically) into being the customers of
>Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers
>need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a
>voice.

If it's not obvious, we do appreciate it.  Way too many of them say whew, we can blame the vendor
and not worry about it.

>We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC.

Yup.

>We need spoofing protection for all of our domains without being told we're misdeploying.

I would be interested to better undertstand the meaning of "need"
here. It is my impression that most people vastly overestimate how
much of a phish target they are. Paypal and big banks certainly are, 
other places, a lot less so.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Aug 2020 19:37:06 -0700

> other places, a lot less so.

I suspect the calculus is less in the pragmatic terms of asking how big 
this threat is and more in terms of wishing for some version of 
protection and thinking this helps to achieve it.

The degree to which so many folk embrace does not appear to have that 
much empirical basis, but rather a sense of feeling a need to do 
something and at first blush this seems to be something.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 8 Aug 2020 11:51:34 +0200

On 2020-08-08 4:27 a.m., John Levine wrote:
> but assured us they were nice people.

I'm not clear why that failed.  Personally, I was puzzled by the .com 
suffix, which somehow sounded like pay for being whitelisted.

> I think you'll find that all of the existing whitelist like things
> are a sideshow to the company's real business of deliverability
> consulting.

Of course whitelisting can easily become ESPs combat zone.

> when you're doing the usual spam filtering.

Trusted-forwarder.org still exists...[*]

Automatically accept is not the same as override DMARC policy.  The 
latter can cure some of MLM and non-MLM problems.

I proposed snd=rhswl.zone.example.  The difference w.r.t. 
trusted-forwarder.org is that some sites can start building their own 
right hand side whitelists (RHSWL).  Specifying the zone in the 
protocol makes it visible, so lazy admins can help themselves to 
quickly build their not-so-strict DMARC policy by using someone else's 
RHSWL.

Combining lists could also become possible, once there is a decent 
amount of them.  There is already An Architecture for Reputation 
Reporting, RFC 7070/3, which could support exchanging entries among 
similarly scoped RHSWLs.

> You can't just let people sign themselves up for a list like that,
> since every dodgy bulk mailer will figure this will get them an
> extra 2% delivery, and we've never gotten past a vague hope that we
> could canvass people we know to make a combined set of mailing
> lists hosts we know.

Seeking how to make that hope less vague should be a highly commended 
task.

Best
Ale
-- 

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 08 Aug 2020 18:05:08 GMT

The unifying principle is that we need a third-party authentication method, a need which is not adequately satisfied with SPF and DKIM.   The standard can support multiple options, such as the following

send3="method=ATPS,p=reject,sp=quarantine;  method=reputation,p=quarantine,dns=uri; method=RHSWL, sp=reject"

where:
"method=ATPS" means RFC 6541 third-party signatures, as suggested by Hector"method=reputation" means a trust service like trusted-forwarders.org, as suggested by John"method=RHSWL" means the whitelist system suggested by Alessandro
Usage:
If multiple methods are specified, the receiver checks all of the methods that it is willing and able to use.If p= is missing, the third-party authentication method is not supported for primary domains.If sp= is missing, the third-party verification method is not supported for subdomainsIf any method passes, the message passes.   No other checks need to be performed.   If all methods fail, the strictest policy is the recommendation action.If any third-party authorization method is supported, the DMARC policies should be p=none and sp=none, to avoid false positives by entities that do not know how to check the third-party method.
A domain could optionally advertise which third-party methods it is willing to check using a similar keyword structure:
verify3="method ATPS;  method=reputation; dns=uri; method=RHSWL".  
This would allow senders to limit third-party impersonation to those recipients that will accept the impersonation as legitimate.

It would be desirable for DMARC feedback reports to indicate which third-party methods were checked.   Updating the reporting specification might be more complex than specifying the verification method itself.

Do we move forward with an approach like this?

----------------------------------------
From: Alessandro Vesely <[email-masked]>
Sent: 8/8/20 5:52 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

Best
Ale
--

---

From: Hannu Aronsson <[email-masked]>
Date: Sun, 9 Aug 2020 13:28:49 +0300

Hello,

I have been lurking here around for a while and we have been working at M3AAWG for some time as well.

Today’s DMARC is breaking more and more email as it gets more widely and often overly strictly deployed.

I feel the major issue with DMARC is email forwarding in it’s many forms, in addition to mailing list issues. It would be preferable to try to do something that helps email survive as an open platform instead of bad workarounds. 

Transactional and person-to-person emails also should work reliably with DMARC (and similar things) when forwarded i.e. indirect delivery.

In M3AAWG discussions, we have identified many stakeholders who are seeing major issues with DMARC and SPF when forwarding email for various valid reasons, examples:

a) ISPs hosting user domains and email from to addresses in those domains is forwarded to external mailbox addresses. This is very common for smaller organizations.

b) Alumni and organization member addresses like alumni.harvard.edu, acm.org, iki.fi and many others that provide a “permanent” email address and forward email to user-specified mailbox provider addresses.

c) Users forwarding email themselves to another email address e.g. based on rules or forwarding to their mobile device address, or forwarding old ISP email to new ISP, etc.

d) Some mailing lists and smaller email distributions, too, which work just forward messages as they are to their members.

e) and of course the many users using these services, and senders trying to send to them.

So there may be many more stakeholders with DMARC issues than one might initially think about. DMARC is creating a lot of “the message did not get thru” issues for valid and real emails these days.

To be worth pushing further, DMARC needs to be compatible with with email forwarding i.e. indirect mail flows.

To try to clarify my thinking around this, I tried to put some thoughts into a practical proposal format so it would be easier to consider, comment and discuss and think about the practicalities around it.

Based on the discussion, it seems it might be more practical to try to make “small” improvements into DMARC. If we can find some useful way forward, we’re willing to work on an internet-draft for more formal commenting.

Background, in addition to the use cases above:

Because SPF fails with forwarded/indirect emails, and as DMARC today depends on SPF, it also fails in these use cases, especially when deployed overly strictly.

Normal email forwarding does not break DKIM as the messages are not changed. We have new tools available today that can help, specifically ARC.

We should aim to make DMARC compatible with these forwarding use cases, without losing the anti-abuse aims if possible.

Draft proposal for comments: 

When a DMARC recipient MTA is processing an incoming message,

1) If DKIM is valid, SPF results should be ignored. DKIM already proves the message is from the source it claims to be from, it doesn’t matter if it arrived via an indirect path.

2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC header chain as long as they have acceptable reputation and if a matching IP address is found there, consider the SPF check successful.

3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today, or probably we should recommend always putting failing messages somewhere where the user can search for the “lost messages” when needed, e.g. to the junk mailbox or quarantine.

If something like this was in place, forwarders and others would be highly motivated to implement ARC, helping senders and recipients who want to deploy DMARC or DMARC-like solutions.

ARC reputation:

ARC reputation has been discussed a lot and may be a major roadblock in going this way. I think the situation has changed now as DMARC issues become larger and affect more users, so people are more ready to do something about it now.

* Technically we should be able to simply use DNS-based IP allowlists to get reputation information for the ARC signing intermediaries.

* ARC allowlisting would allows MTA admins to choose suitable allowlists from free and paid options from various sources and vendors, just like they use blocklists today for email already. 

* We could probably even re-use existing email RBL allow/blocklists for this purpose, if you don’t trust some IP reputation as sender, you would not trust it for ARC either.

* Free options would be available so DMARC2 software and solutions could include default settings that already work out of the box for smaller organizations.  

* It seems possible to maintain semi-manual lists of “major trusted” forwarding services and have a suitable vetting process for that. At iki.fi we have looked at doing something like this, if it would help.

* Additionally people would offer various automated lists based on other analysis and methods.

* ARC reputation could at this time have become an additional service for email protection vendors to sell. Maybe before this was not viable earlier because ARC was not widely available yet, or the SPF/DMARC issue was not severe enough before?

* Mailbox service admins could add “trusted forwarding IPs” locally to help specific users with forwarding related issues. Today there doesn’t seem to be an easy options for mailbox service providers to help their users who have SPF/DMARC issues.

Yours,
  Hannu
-- 
Hannu Aronsson
[email-masked]

> Dave Crocker <[email-masked]> wrote 8.8.2020 5.37:
> I suspect the calculus is less in the pragmatic terms of asking how big this threat is and more in terms of wishing for some version of protection and thinking this helps to achieve it.
> 
> The degree to which so many folk embrace does not appear to have that much empirical basis, but rather a sense of feeling a need to do something and at first blush this seems to be something.

---

From: Hannu Aronsson <[email-masked]>
Date: Sun, 9 Aug 2020 18:11:16 +0300

Hello,

Quick correction: As DMARC requires only either DKIM or SPF which I had confused, this removes the need for the proposal point 1). Thanks for the off-list help received.

This seems to be mostly an SPF issue, but still remains when
- SPF used used alone without DMARC (not sure if relevant for this discussion, but it is a real-world problem) and 
- DMARC when DKIM is not used and it falls back to SPF
causing indirect emails to fail, especially with p=reject or -all settings or overly strict receiver deployments. 

For fixing the SPF issue a solution using ARC would be much preferable to the SRS (Sender Rewriting Scheme) workaround, because e.g. the messages would be unchanged, avoid problems with long email addresses or requiring databases, and DMARC strict From alignment issues, etc.

The other topics in the email, 
- forwarding use cases from M3AAWG discussions and 
- figuring out how we could get ARC reputation solution in place
are hopefully still interesting for this discussion.

Yours,
  Hannu

> On 9.8.2020, at 13:28+0300, Hannu Aronsson <[email-masked]> wrote:
> 
> Hello,
> 

--
[email-masked] https://www.haa.iki.fi

---

From: Tõnu Tammer <[email-masked]>
Date: Sun, 9 Aug 2020 19:54:27 +0300

Hi!

I keep reading the discussion and I am surprised how people express
views that current DMARC standard does not work. I am surprised that
technical people here express this view.

DMARC relies on SPF and DKIM. The latter is particularly important for
the mailing lists to ensure that DMARC works. And when I read the cases
it is clear that the issue is not of DMARC but of DKIM. RFC for DKIM
says very clearly in the introductory part that and I quote "Message
transit from author to recipient is through relays that typically make
no substantive change to the message content and thus preserve the DKIM
signature." If this is not the case, the relay is actually violating
DKIM standard.

The lists we manage, we have made sure they follow the RFC and there is
no issue of DKIM preservation. Some lists, however, have taken a
different approach and to make sure we have delivery there also, we've
looked at the elements which are used for DKIM calculation. We realise
that not including the content into hash calculation can have a drawback
but given that non-DKIM compliant lists do with content what they wish
anyway, it's not much of a drawback. At the same time, prevention
against spoofing and misuse is retained, which is the key for DMARC.

Tonu
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 9 Aug 2020 09:58:42 -0700

On 8/9/2020 9:54 AM, Tõnu Tammer wrote:
> "Message

However, a mailing list is not a 'relay'.  The term relay is meant to 
refer to an MTA.

Reviewing RFC 5598 might help.

d/

---

From: Jim Fenton <[email-masked]>
Date: Sun, 9 Aug 2020 21:48:19 -0700

>>> your transactional mails are sent from. You can also put users on a

You really don't want to move users; they would need to notify all of
their correspondents. Instead, leave the users where they are and move
the transactional mail to a different domain (or to a subdomain) and put
the restrictive policy there.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Aug 2020 10:41:10 +0200

On 2020-08-09 6:54 p.m., Tõnu Tammer wrote:
> it is clear that the issue is not of DMARC but of DKIM.

Indeed, one of the proposed workarounds, Recognized Transformations of 
Messages, addresses DKIM verification algorithm.  Yet, it is being 
discussed on this list rather than ietf-dkim.  I hope it becomes a WG 
draft soon.

> RFC for DKIM says very clearly in the introductory part that and I
> quote "Message transit from author to recipient is through relays
> that typically make no substantive change to the message content
> and thus preserve the DKIM signature." If this is not the case, the
> relay is actually violating DKIM standard.

As Dave said, MLMs may need to carry out some transformations while 
usual relays don't —except those which add **SPAM** subject tags or 
antivirus footers.

The l= tag is one of the early envisaged provisions to address footer 
additions.  It was deprecated because of the possibility to add 
malicious footers.  Of course, adding a footer /is/ a substantive change.

However tight we define recognized transformations, they have to allow 
the addition of a few lines and a URL.  Hence, they can be malicious. 
  Therefore, we need to differentiate two classes of domain owners, 
those who can afford such risk and those who want top strictness.

> no issue of DKIM preservation.

https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Turn_off_all_message_modifications

> Some lists, however, have taken a different approach and to make
> sure we have delivery there also, we've looked at the elements
> which are used for DKIM calculation. We realise that not including
> the content into hash calculation can have a drawback but given
> that non-DKIM compliant lists do with content what they wish 

That only works if you trust the MLM.  We cannot rely on trust, 
because there is no widespread common reputation system.  DMARC does 
provide for "trusted_forwarder" and "mailing_list" policy override types:

    However, before this action is taken, the Mail Receiver can consult
    external information to override the Domain Owner's policy.  For
    example, if the Mail Receiver knows that this particular email came
    from a known and trusted forwarder (that happens to break both SPF
    and DKIM), then the Mail Receiver may choose to ignore the Domain
    Owner's policy.

However, that kind of hush hush is not deterministic, since the 
protocol does not define the "external information".  Providing for a 
URL pointing to such external source might help.

Best
Ale
--

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 10 Aug 2020 10:57:40 GMT

>> URL pointing to such external source might help.

Even an external reputation system requires recipient participation.   That is why I suggested both a send3="parameters" clause to indicate sender support for third-party authorization and a verify3="parameters" clause to indicate recipient support for third-party authentication.    When both are visible to the non-domain message source, that source can have confidence that the message will be handled as authorized.

We have a very complete specification for ATSP signature delegation.   
Do we have a similar document for your RHSWL approach?
Do we have a similar document for lookup into a trusted-forwarders list, assuming a service like that can be revived?

If ATSP and RHSWL solve essentially the same problem, we need to do an analysis of which is more likely to succeed, and proceed with that winner.

Third-party lookup is a very different approach than ATSP, so they can supplement each other.

DF

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2020 13:24:11 -0400

In article <[email-masked]> you write:
>>Even an external reputation system requires recipient participation.   That is why I suggested both a send3="parameters" clause to
>indicate sender support for third-party authorization and a verify3="parameters" clause to indicate recipient support for third-party
>authentication.    When both are visible to the non-domain message source, that source can have confidence that the message will be
>handled as authorized.

We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.

The only third party reputation systems that anyone uses are DNSBLs
like Spamhaus that publish negative reputations, and even there you
can count the ones with non-trivial use on the fingers of one hand.

With this in mind, I cannot see any point in designing yet another
vouching or authorization scheme unless we have evidence that an
interesting fraction of the world's mail systems want to use it. I
don't see that, and honestly see no chance that we ever will.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Aug 2020 10:26:42 -0700

> We have had a lot of attempts at third-party authorization schemes
...

+1

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 10 Aug 2020 13:30:00 -0400

On Mon, Aug 10, 2020 at 1:24 PM John Levine <[email-masked]> wrote:

> >>Even an external reputation system requires recipient participation.
>  That is why I suggested both a send3="parameters" clause to
> >indicate sender support for third-party authorization and a
> verify3="parameters" clause to indicate recipient support for third-party
> >authentication.    When both are visible to the non-domain message
> source, that source can have confidence that the message will be
> >handled as authorized.
>
+1

Michael Hammer

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 15:17:17 -0700

> On Aug 7, 2020, at 12:12 PM, John Levine <[email-masked]> wrote:
> 

When mail breaks it’s more than an inconvenience. In business it can materially affect people’s livelihoods.

 I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at  p=none of the time unless there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take action if and only if there’s a problem. 

I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail.

---

From: "John R Levine" <[email-masked]>
Date: 12 Aug 2020 18:21:09 -0400

> I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at…

Completely agree.  I have 240,000 aggregate and 80,000 failure reports in 
my database and I'm still publishing p=none for all my domains that 
actually send mail.

Regards,

---

From: Autumn Tyr-Salvia <[email-masked]>
Date: Thu, 13 Aug 2020 08:58:54 +0000

"I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail."

-Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing.

Best,

Autumn Tyr-Salvia
[email-masked]

________________________________
From: Neil Anuskiewicz <[email-masked]>
Sent: Wednesday, August 12, 2020 3:17 PM
To: John Levine <[email-masked]>
Cc: [email-masked] <[email-masked]>; Autumn Tyr-Salvia <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Catyrsalvia%40agari.com%7C2388c4693f9a41d84d4308d83f0d7ab4%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637328674420006184&amp;sdata=u2xp7UMS7OHzkkyzHeoKa9Ri3w8v7sjJWvW%2BXuepmj4%3D&amp;reserved=0

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2020 11:03:47 -0400

> -Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by pe…

If they all talked to you first, we'd be having a very different 
discussion.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Aug 2020 17:21:28 -0700

On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker <[email-masked]> wrote:

> ....

I'm disappointed that the experiment never really got its day in court, but
the consensus is clear.  +1.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Aug 2020 18:44:39 -0700

On 8/13/2020 5:21 PM, Murray S. Kucherawy wrote:
> I'm disappointed that the experiment never really got its day in court, 
> but the consensus is clear.  +1.

30 years ago, there was a generally adventurous tone in the community. 
Things are a lot more cautious now.

I remember back then hearing various ideas or proposals and for many of 
them thinking "I've no idea whether that will be useful or successful 
but it sounds like something worth trying."  Not so much these days.  Alas.

d/

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2020 22:02:23 -0400

>but it sounds like something worth trying."  Not so much these days.  Alas.

I'm perfectly happy to try stuff but considering how concentrated the mail
business has gotten, unless a gorilla or two seems interested, "try" won't
really happen.

Also, we now have several more decades of experience about stuff that
seemed appealing but failed.  There's no shame in learning from experience.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Aug 2020 11:20:44 +0200

On 2020-08-10 7:24 p.m., John Levine wrote:
>> Even an external reputation system requires recipient
>> participation.   That is why I suggested both a
>> send3="parameters" clause to indicate sender support for
>> third-party authorization and a verify3="parameters" clause to
>> indicate recipient support for third-party authentication. When
>> both are visible to the non-domain message source, that source
>> can have confidence that the message will be handled as
>> authorized. >

We can either try and understand what was wrong in those schemes, or 
abandon authorization schemes forever.

Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent 
success.

PGP, GPG, and even personal CA certificates never became really 
popular, so we could have concluded that digital signature aren't 
worth considering for anti-spoof protocols.  Yet, someone thought 
about DKIM...

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 10:12:42 -0400

> worth considering for anti-spoof protocols.  Yet, someone thought

There is a little bit of history behind the impetus for SPF and DKIM. In
2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on
Email Authentication and SPAM. It also let it be known that if the private
sector didn't come up with solutions it was willing to move forward with
regulation. This helped drive activity for SPF, the merger of DK and IIM
to create DKIM and Microsoft's push for SenderID. Private sector folks did
not want to risk what government regulation might look like. At that time
there were also folks pushing for PGP, GPG, Personal Certificate and
S/MIME as  paths forward. Even with that, it took a while for industry
efforts to gain some sense of clarity. Notice that the general path forward
was basically domain based and not individual user/client based. There was
a debate within the DKIM effort regarding i= vs d= to the extent that at
one industry event people were walking around with little stickers on their
badges to indicate which they supported. I believe that was courtesy of
Dave Crocker.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Aug 2020 18:05:43 +0200

On 2020-08-14 4:12 p.m., Dotzero wrote:
>>>> authorized.

Thanks for that, I put a reference to your post on the wikipedia[*] 
(the original link to the FTC event expired sometimes in 2012).

Best
Ale
-- 

[*] https://en.wikipedia.org/wiki/Email_authentication#Rationale

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Aug 2020 08:47:25 -0700

On 8/14/2020 7:12 AM, Dotzero wrote:
>       At that time there were also folks pushing for PGP, GPG, 
> Personal Certificate and  S/MIME as  paths forward.

There was, by then, a long history of these failing to scale.

> Even with that, it took a while for industry efforts to gain some 
> sense of clarity. Notice that the general path forward was basically 
> domain based and not individual user/client based.

SPF and DomainKey were informal, spontaneous, private efforts. They 
established their viability long before reaching a standards venue.  So 
there was no 'policy' 'decision' to make this approach.

> There was a debate within the DKIM effort regarding i= vs d= to the 
> extent that at one industry event people were walking around with 
> little stickers on their badges to indicate which they supported. I 
> believe that was courtesy of Dave Crocker.

This was a follow-on issue after DKIM was initially published. We 
realized that the spec said that DKIM's goal was to provide an 
identifier, but then it didn't specify which one to use, the one in the 
i= parameter or the one in the d=.  (Note that neither of these was 
requirement to correlate with any other identifier in the message.

The IETF working group debate about this was intense and was not 
converging on a choice. One of the early arrivals to the meeting walked 
through the hotel's entrance, saw me, and said "d= or i=?" and I 
realized we could have some fun both promoting the issue at this 
industry trade event, and possibly get some constructive discussion.  
The meeting staff were helpful in provide sticky dots to use.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 16 Aug 2020 13:18:47 -0400

On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     .....

+1  and I want to give you credit for trying. Without you, I might 
have been long gone from the DKIM project WGs. So I thank you for 
keeping it interesting, but....

> but the consensus is clear.  +1.

Here I have to disagree. I don't ask anyone to agree with me but to 
understand my viewpoint as a long time participant and advocate of the 
DKIM Policy Model.  Early on, we had limited policy proponents. But 
not today.

I have a different viewpoint, a viewpoint that really that was blocked 
by the two controlling cogs who had DKIM interest else where, namely 
Levine, Crocker. Crocker has been more open ended. Not Levine. Since 
day 0, Levine never liked policy and to his credit, he admitted it as 
much. He killed SSP with the "poison pill" (crippled draft) ADSP 
replacement he knew would never make it pass LC.  Levine was always 
for the 3rd party trust/list signer idea - never a 1st party 
authorization. But he narrowed down the scope to the restrictive 
policy, removing any 3rd party consideration.  The same will most 
likely be true with DMARC with the same problems. Yet, why would any 
list developer deny new security options for list operations?  I never 
got that and that was before ADSP or even ATPS.  When it comes to 
DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say 
and I don't see that changing.  So now that we have the top three cogs 
DKIM agreeing, there is not much reason to even bother anymore when 
one of them is the AD. What is one to think at this point?  "Follow 
the Chieftain" syndrome?

Just consider, we are 15+ yrs into all this and nothing was 
accomplished with DKIM in regards to LIST systems.  DMARC, with the 
same exact problems as ADSP, snuck on via an informational status. 
Nothing wrong there, but it was pushed as a standard and ventures were 
started.  Who wins? who loses?

I believe it would be prudent for the AD to look at the reasons why 
the IETF has failed with this DKIM Project.  If a cog is not for ADSP 
but for DMARC with the same problems, then what is that to say about 
this process?  It has not been a fair process to say the least. A lot 
of wasted time, money and energy.  It has been a long 15+ yrs and has 
become very tiring. :-(

Despite the 3rd party authorization brush back, the concept has never 
gone away. It says a lot and it will never go away under the current 
DKIM POLICY model using the required hash bound Author Domain anchor 
as the forcing function for authorization.

At this point, I would suggest to give the new generation IETF mail 
developers a new chance at DKIM-based security.  Rewrite DKIM as v3.0 
as you guys want it for 3rd party trust.  Remove the Author Domain 
dependency so that the world can nip the Mail tampering bug opened 
with Levine's Rewrite crud.

I wouldn't worry about backward compatibility. Two different streams, 
only the newer one will matter.

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

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 16 Aug 2020 19:08:58 GMT

The reality is that IETF has mostly provided followership, not leadership, on matters of security.  This forum is replicating history.   As has been mentioned in the historical review, SPF, DKIM, and DMARC were independently successful projects, as was SSL.  IETF provided after-the-fact blessing.   It is time to follow the same model.

If there is an opportunity to accelerate DMARC adoption, I think it is in the area of third-party authentication, presumably based on ATSP.   To move the possibility forward, we need to move off this list.  The target audience for this capability will be organizations that are non-DMARC or DMARC p=none specifically because DKIM delegation is an obstacle.    I have no idea whether that category is a trivial or non-trivial group, so we would need to find out.  Major ESPs are successfully implementing DKIM scope delegation to comply with DMARC, so maybe it is not the issue.   DKIM delegation creates complexity which becomes an obstacle to new entrants, so big ESPs may like the status quo just fine.   These are all things need to be assessed, and are more important than writing a new specification.

Then, we need to expand the base of participants to include people who would be willing to implement the third-party authentication scheme after it is defined.   I think that list would need to look something like this:

A national government representative to ensure that any new proposal is not vetoed, A financial services industry representativeAn Email Service Provider industry representativeA large organization that is holding back on DMARC p=reject because DKIM delegation is an obstacle.One or more commercial product representativesI would love to have Verizon Media participate, but I have asked and had no response.
If you want to participate, send me a direct email.    More importantly, if you have connections with people who could play the role of influencers, reach out to them.

If there are other topics that would move DMARC forward, we can put them up for consideration.  If you want to discuss special treatment for mailing lists, you are specifically disinvited.

Doug Foster

----------------------------------------
From: hsantos=[email-masked]
Sent: 8/16/20 1:19 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 09:52:04 -0400

On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

>
> The reality is that IETF has mostly provided followership, not leadership,
> on matters of security.  This forum is replicating history.   As has been
> mentioned in the historical review, SPF, DKIM, and DMARC were independently
> successful projects, as was SSL.  IETF provided after-the-fact blessing.
> It is time to follow the same model.
>

Doug, as someone who has been involved in this space for decades, I think
you are sorely mistaken in your understanding of things. Many of the people
involved in the email authentication space interact with each other in
other places, both online and in person and have been doing so for a very
long time.
We don't always agree on the path forward but that is because we come from
different perspectives. IETF did not provide "after-the-fact" blessing. SPF
was experimental for a very long time. DMARC is still informational. One of
the mantras for IETF is "running code and rough consensus". There is
running code for DMARC but what we are lacking so far is rough consensus.

If there is an opportunity to accelerate DMARC adoption, I think it is in
> the area of third-party authentication, presumably based on ATSP.   To move
> the possibility forward, we need to move off this list.  The target
> audience for this capability will be organizations that are non-DMARC or
> DMARC p=none specifically because DKIM delegation is an obstacle.    I have
> no idea whether that category is a trivial or non-trivial group, so we
> would need to find out.  Major ESPs are successfully implementing DKIM
> scope delegation to comply with DMARC, so maybe it is not the issue.   DKIM
> delegation creates complexity which becomes an obstacle to new entrants, so
> big ESPs may like the status quo just fine.   These are all things need to
> be assessed, and are more important than writing a new specification.
>

You can move anywhere you want and write any specification you want but you
still have to attract meaningful interest and adoption in order for it to
become a standard.

>
> Then, we need to expand the base of participants to include people who
> would be willing to implement the third-party authentication scheme after
> it is defined.   I think that list would need to look something like this:
>
>
>    - A national government representative to ensure that any new proposal
>    is not vetoed,
>
> What? Which national government are you referring to? Do you understand
that the IETF is international in it's participation? If you are referring
to the U.S. Government, can you show me a single example of the government
vetoing a technical standard?

>
>    - A financial services industry representative
>    - An Email Service Provider industry representative
>    - A large organization that is holding back on DMARC p=reject because
>    DKIM delegation is an obstacle.
>    - One or more commercial product representatives
>    - I would love to have Verizon Media participate, but I have asked and
>    had no response.
>
> and why would you expect them to respond to you?

> If you want to participate, send me a direct email.    More importantly,
> if you have connections with people who could play the role of influencers,
> reach out to them.
>
> If there are other topics that would move DMARC forward, we can put them
> up for consideration.  If you want to discuss special treatment for mailing
> lists, you are specifically disinvited.
>
>
> Doug Foster
>

Or you could apply for M3AAWG membership where all of those constituencies
participate already.

I wish you luck in your endeavors but I think you are doomed to failure.

Michael Hammer

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 17 Aug 2020 17:52:03 -0500

On 8/13/20 10:03 AM, John R Levine wrote:
> If they all talked to you first, we'd be having a very different discussion.

With a complex organization the only way to get people to change is to publish a restrictive DMARC policy and then see who comes out of the woodwork sheepishly admitting that they've been ignoring us for years.  

Normal people sending email (especially those who are working with an ESP, most of which happily send email without any DMARC alignment) do not comprehend the notion that they should be using a subdomain for their transactional messages; even when we directly communicate this fact to them repeatedly.  They just don't understand the nuances of email.

Similarly, it's only way to find all of the old DMARC-unaware MLMs, most of which haven't been security-patched for years.  Forcing them to upgrade to a MLM that can munge the From is a back-door way to get them to patch, or reassess their commitment to running the list in the first place.

Enterprise IT/cybersecurity actually want to get better manageability on the email their institution emit.  Misdeploying DMARC provides that.  Publishing restrictive DMARC on user domains is not always a clueless IT decision.

Jesse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Aug 2020 16:21:33 -0700

> as the forcing function for authorization.

Since this bit is directed at the AD, I finally have to put that hat on.

I don't agree that DKIM has been a failure.  I believe it succeeds at
exactly what it purports to provide, but not more.

The industry in general, and the IETF in particular, have chosen not to
pursue widespread use of any kind of standards-based third party domain
signature policy or reputation system.  That's the obvious consensus, and
in my opinion the reasons for that fact are sound.  Both ATPS (individual
submission, experimental, February 2012) and the REPUTE series of documents
(working group, standards track, late 2013) saw nearly zero adoption after
publication even when free reference implementations were provided.  They
differ from basic DKIM in that they require non-trivial upkeep, and that
appears to be a step function inhibiting adoption among operators.

As to your assertion that this process has not been fair, I'm curious as to
why you say that.  There's nothing I can think of here other than DMARC
that didn't go through a consensus process.  That means concerns about all
of these topics were heard and discussed.  People's opinions that were in
the rough still got aired; I don't recall that anyone was silenced just for
dissenting.  As I said before, I'm disappointed that things like ATPS and
REPUTE never got a serious attempt, but that's not because they were
oppressed or sabotaged.  That's just the reality we're in.

If you can point to a discussion thread on the old DKIM list or any list
since then where procedure wasn't followed, that might be interesting.

I still agree that if we could figure out a way to do this third party
thing, it would go a long way toward resolving this whole problem space.
But in many years of trying, we haven't found a way to do it that scales,
is resistant to attack, is easy to implement and reason about, and is
likely to achieve any real momentum.  That appears to be a taller order
than one might think at first blush, fair or not.  ARC is the only thing
that has achieved consensus and appears to have a chance at non-trivial
levels of adoption.

I think the IETF did fail here in certain ways -- for example, by not being
more helpful to the industry many years ago when the second derivative of
spam and phishing was particularly acute -- but that rant is for another
day.

-MSK, ART AD

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 17 Aug 2020 18:39:16 -0500

> other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Need* would imply that domain-spoofing is more common than it is in reality.

Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances.  Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC).  To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: 

* Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed)

The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports.  It may show up in forensic reports, but it is easily lost in the noise.  (SPF macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage every ounce of their political influence to resist.  (It's really fun when your own users threaten lawsuits against you - that doesn't happen in Corporate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regardless!

Jesse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Aug 2020 17:45:41 -0700

On Mon, Aug 17, 2020 at 6:52 AM Dotzero <[email-masked]> wrote:

>> The reality is that IETF has mostly provided followership, not
>> leadership, on matters of security.  This forum is replicating history.
>> As has been mentioned in the historical review, SPF, DKIM, and DMARC were
>> independently successful projects, as was SSL.  IETF provided
>> after-the-fact blessing.   It is time to follow the same model.
>>
>

+1.  I would add that SPF and DMARC started outside of the IETF, but DKIM
was a synthesis within the IETF of two things (DomainKeys and IIM) that
started outside.  It underwent significant evolution in the IETF -- not
once, but twice.

This line of thinking also seems to ignore the troubled path that SPF took
to reach the standards track (as RFC 7208).

> participate already.

I was just going to say that.  And, at least the last time I went, most of
the same debates happened over there too.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 18:09:27 -0700

>  DKIM was a synthesis within the IETF of two things (DomainKeys and 
> IIM) that started outside.  It underwent significant evolution in the 
> IETF -- not once, but twice.

Actually, it wasn't.

The constituent parts were separately proposed, during the same initial 
IETF discussions, and the IETF said to go away and come back after 
reconciliation.  That work was done by an ad hoc industry team and there 
was a complete spec and initial implementations before the IETF was 
again approached.

https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says 
"pre-MASS"...)

The work in the IETF was a refinement of a complete, integrated spec.

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 21:15:40 -0400

On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker <[email-masked]> wrote:

>
>  DKIM was a synthesis within the IETF of two things (DomainKeys and IIM)
> that started outside.  It underwent significant evolution in the IETF --
> not once, but twice.
>
> Actually, it wasn't.
>
> was a complete spec and initial implementations before the IETF was again
> approached.
>
> Brandenburg InternetWorkingbbiw.net
>
> +1

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 Aug 2020 10:54:24 +0200

> (Sorry, I was on a much-needed vacation.)

Much *needed*?  Oh, well...

> Ok, that's fair, I should have realized that one was over-stated.  *Need* would imply that domain-spoofing is more common than it is in reality.

Yes, domain spoofing is common.  You don't need to be PayPal to be spoofed.  Then, one can say it's an innocuous kind of abuse.  Since you're not PayPal, it's just noise.  Yet, in a perfect word, I'd opt to avoid it.

> Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that…

Nice synthesis.  They believe DMARC works as advertised.  What does it take to believe that DMARC /could/ work as advertised?

> * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from…

This is a good idea even without DMARC concerns.

> * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed)

This sound just like an email-client configuration problem.  It shouldn't be so hard.

> The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports.

Why not?  If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only.  That doesn't tell which users misconfigured their client, but gives a good idea of the level of user education one has achieved.

It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization...

Best
Ale
--

---

From: Autumn Tyr-Salvia <[email-masked]>
Date: Tue, 18 Aug 2020 09:17:16 +0000

I have seen Jesse mention something along these lines a couple of times:

Is inheritance walking the domain tree a topic that has already been discussed ad nauseam? This seems like an interesting point of discussion, but I also haven't been participating on this list for ten years and don't want to get into it if this is a topic everyone is tired of or that has no possibility of change.

Thanks,

Autumn Tyr-Salvia
[email-masked]

________________________________
From: dmarc <[email-masked]> on behalf of Jesse Thompson <jesse.thompson=[email-masked]>
Sent: Monday, August 17, 2020 4:39 PM
To: John Levine <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

Jesse

_______________________________________________
dmarc mailing list
[email-masked]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Catyrsalvia%40agari.com%7C07fe631db10e49cfa46508d84306d0b9%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637333043846011888&amp;sdata=GEKpu8y3KvA7Zkt0VJmeKz4KPwvSay51cj5SDniQAUo%3D&amp;reserved=0

---

From: "John R Levine" <[email-masked]>
Date: 18 Aug 2020 12:39:43 -0400

> Is inheritance walking the domain tree a topic that has already been discussed ad nauseam? This seems like an interesting point of discussion, but I also haven't been participating on this list for…

We've spun our wheels a lot trying to figure out a better way to find the 
organizational domain than for everyone to download the Mozilla PSL, but 
not about changing it to a tree walk.

If we could come up with a better way for domains to publish their own 
boundaries (see https://github.com/jrlevine/bound) then that would be 
easy.

Regards,

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 18 Aug 2020 12:43:20 -0400

Speaking not as a chair...

I do think the tree walk deserves another look.   Years back when it was
brought up,
there was lots of talk of overloading resolvers. But as someone who spent
the past
several years looking at the DNS query data of good sized SaaS domains,
DMARC lookups
(or even DMARC NXDOMAINs) were on the low end of the spectrum.  Nowadays,
all web
properties point to CDNs, et al with 30 second TTLs.

tim

On Tue, Aug 18, 2020 at 12:39 PM John R Levine <[email-masked]> wrote:

> > * Departments sending transactional email - move them to dedicated
> subdomains (this is where really complex institutions would benefit from
> walking the domain tree instead of always inheriting from the org domain)
> >
> > Is inheritance walking the domain tree a topic that has already been
> discussed ad nauseam? This seems like an interesting point of discussion,
> but I also haven't been participating on this list for ten years and don't
> want to get into it if this is a topic everyone is tired of or that has no
> possibility of change.
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Aug 2020 09:43:33 -0700

On 8/18/2020 9:39 AM, John R Levine wrote:
> We've spun our wheels a lot trying to figure out a better way to find 
> the organizational domain than for everyone to download the Mozilla 
> PSL, but not about changing it to a tree walk.
>

And for completeness:

     DNS Perimeter Overlay

https://tools.ietf.org/id/draft-dcrocker-dns-perimeter-01.html

(John thinks it's the same as his, but it's not...)

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Aug 2020 09:48:45 -0700

On 8/18/2020 9:43 AM, Tim Wicinski wrote:
> I do think the tree walk deserves another look.   Years back when it 
> was brought up,
> there was lots of talk of overloading resolvers. But as someone who 
> spent the past
> several years looking at the DNS query data of good sized SaaS 
> domains, DMARC lookups
> (or even DMARC NXDOMAINs) were on the low end of the spectrum.  
> Nowadays, all web

To be entirely obvious:

badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com

produces a possible denial of service attack.  hence, no tree-walking.

d/

---

From: Seth Blank <[email-masked]>
Date: Tue, 18 Aug 2020 09:59:06 -0700

There is a ticket for tree walk: https://trac.ietf.org/trac/dmarc/ticket/68

Please hold the conversation until the chairs open that thread.

Seth, as Chair

-- 

*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: Jesse Thompson <[email-masked]>
Date: Tue, 18 Aug 2020 13:05:11 -0500

> Much *needed*?  Oh, well...

Anecdotally.  My family can attest, if that helps ;-)

> Yes, domain spoofing is common.  You don't need to be PayPal to be spoofed.  Then, one can say it's an innocuous kind of abuse.  Since you're not PayPal, it's just noise.  Yet, in a perfect word, I…

Yes, I just can't prove it to the extent that the people saying we're "misdeploying" DMARC would expect me to.  How do I tell the difference between a faculty member innocently using Gmail to send from their personal address within our domain vs. a bad actor doing the same to send spear phishing to a peer at another university?  In my mind, I should just assume that it's a problem, or is potentially a problem, so I'd rather nip it in the bud by deploying DMARC on domains used by users.

> Nice synthesis.  They believe DMARC works as advertised.  What does it take to believe that DMARC /could/ work as advertised?

It seems like we're close.  I am glad that you are pushing back (in the other thread) on the notion that DMARC shouldn't be useful for all types of domains.

> This is a good idea even without DMARC concerns.

Yes, and those departments that we have converted to subdomains seem to be happy with the result.  It usually takes some convincing, however.  People tend to have a strong preference to associate with the brand of the org domain (which is where we have our users).

> This sound just like an email-client configuration problem.  It shouldn't be so hard.

Gmail is the most common "client" allowing users to submit mail outside of our supported submission pathways.  In theory, Google could make some improvements to Gmailify (to support more OAuth scenarios) and actively transition their legacy users to reconfigure their Gmail settings to properly use our domain, but it's not a high priority for Google (paraphrasing Brandon; hopefully accurately)

It's not much different than people innocently using any random ESP to send newsletters from their personal address.  Because all of these "clients" allow non-authenticated submission of our domain, users have come to expect it to work and they don't want to be told otherwise.

> Why not?  If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only.  That doe…

Right, you only get metrics indicating a relative volume of users who may fall into various camps.  It is complicated when the domain is also used for transactional mail; which is something that happens entirely out of our control specifically because DMARC enforcement wasn't in place when email was invented.  

This is where the DMARC reporting analysis services come into play, since they do a good job at identifying the ESPs (from the raw data) that are sending the non-compliant mail.  But again, aggregate reports don't show the left hand side of the address, so they can't be used to identify specific users.  To get that, you need forensic reports, or use SPF macros; both options having their pitfalls.

> It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization...

Yes, aggregate reports are great at identifying which of our domains have successfully isolated transactional mail and have set up third-party authorization.  

If we see from aggregates that pharmacy.wisc.edu is using an ESP but have neglected setting up SPF/DKIM per the ESP's instructions, then we know who to reach out to and how to help them.  They're already on the right track, anyway.  That's the happy path.  There are many other scenarios.

Jesse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Aug 2020 11:13:51 -0700

> was a complete spec and initial implementations before the IETF was again
Yep, I still have the t-shirt.

> The work in the IETF was a refinement of a complete, integrated spec.
But it was quite a bit of refinement -- I would even say 'evolution" -- in
comparison to how little SPF and DMARC changed before publication.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Aug 2020 10:33:54 +0200

On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> The industry in general, and the IETF in particular, have chosen not 
> to pursue widespread use of any kind of standards-based third party 
> domain signature policy or reputation system.  That's the obvious 
> consensus, and in my opinion the reasons for that fact are sound.

Based (also) on the following quoted paragraphs, I wouldn't call this 
state of affairs a choice or a consensus.  It's just a series of failures.

> Both ATPS (individual submission, experimental, February 2012) and the 
> REPUTE series of documents (working group, standards track, late 2013) 
> saw nearly zero adoption after publication even when free reference 
> implementations were provided.  They differ from basic DKIM in that 
> they require non-trivial upkeep, and that appears to be a step 
> function inhibiting adoption among operators.
> 
> [...]  As I said before, I'm disappointed that things like ATPS and
> REPUTE never got a serious attempt, but that's not because they
> were oppressed or sabotaged. That's just the reality we're in.

We can still try again.  In particular, the non-trivial upkeep seems 
to be a valid diagnosis.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 19 Aug 2020 10:10:21 -0700

On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely <[email-masked]> wrote:

> > domain signature policy or reputation system. . .
>

Is there anything which has materially changed between 2012-13 and 2020
which would indicate that the anticipated results for such effort would be
any different?

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Aug 2020 11:37:27 -0700

> which would indicate that the anticipated results for such effort would be

+1.  If anyone has some kind of creativity in this space that they've been
hiding, now's the time.

-MSK

---

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 19 Aug 2020 21:18:29 GMT

My two cents.

1) What has changed since 2012 is DMARC, including the ability through DMARC to obtain feedback.  "New ATPS" would have to be implemented as a DMARC option, not a new thing.

2) A lot of organizations seem to be stick at p=none.   Maybe that means they want it that way.   Maybe it means that they are being courteous to mailing lists.   But maybe it means something about DMARC is too hard.   I am assuming that all of the problems with DMARC are related to third-party authorization, and something needs to be done to make it easier.

3) Delegation with an ATPS-type email entry seems functionally equivalent to DKIM scope delegation, with several benefits:
Easier and cheaper for the third-party to implement.   The third-party only needs to apply its own domain's signature.   Simpler means quicker implementation.  Private keys are never exchanged.

Third-party is only responsible for its own key.    A big organization like Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM keys, and that becomes an attractive target for attackers.  If a delegated DKIM key store is stolen from a third party, the attacker knows every domain that has been compromised.   If an ATPS-delegated third party has a corporate DKIM key stolen, the attacker knows that he has struck pay-dirt, but he does not have an immediate enumeration of compromised organizations.   That enumeration will require an additional data collection process, which might buy time for the affected organizations to take evasive measures.

An ATPS-type scope delegation could be designated for a specific user, which I assume will represents an application. ("SMTP address must be applicationname@vendordomain").   This information is something that the receiving system can enforce and report.   It is a weak enforcement tool, but limiting scope of delegation seems likely to satisfy some of the auditor concerns associated with any third-party delegation.  This is also a new ideas relative to the original ATPS.   Of course, a domain level delegation should also be an option for situations that the authorizing domain deems appropriate.  ("SMTP address must be *@vendordomain")

ATPS-type delegations could be given a pre-defined expire date (if specified with that feature).  This would be particularly appropriate where a third-party authorization is linked to a time-limited contract.   When the contract lapses, the authorization lapses, unless both the contract and the DNS entry are renewed.   This limits risk associated with the possibility of delegated-but-forgotten authorizations.   DKIM delegations are always good-til-cancelled (by removing the DNS public key).

Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS propagation.

DKIM delegation becomes impossible if the third-party is not cooperative.   ATPS-type delegation can be done unilaterally by the owning domain.    I am thinking of Proofpoint in particular.   They violate my DMARC policy when my users, who are non-clients, respond to a secure message from one of their clients.   Author self-copies arrive at my gateway looking like spoof, but I can fix this with local policy.   When my user uses reply-all to a message with many recipients, those other domains will see my p=reject, which may mean that messages are not delivered and my user does not know that it happened.   Maybe all those other domains will have a Proofpoint exception as well, impossible to say.   Maybe Proofpoint will begin header munging, but they have not done so yet.
So the big benefit for DKIM is the i= clause, but I think the sender-limiting potential with ATPS is superior to the impersonation-limiting capability of DKIM.   Besides, it seems generally agreed that i= has very limited use.   On all other risk-management concerns, an ATPS -type signature seems preferable.

Implementation obstacles and notes:

When a domain implements an ATPS signature, it must set the corresponding DMARC policy to p=none.  Otherwise, sites that are DMARC-aware but ATPS-blind will block ATPS-authoized transactions.   Consequently, this option will only interest organizations that are currently at p=none or that have no DMARC policy.

If a new feature such as ATPS is implemented, senders have a problem knowing whether their recipients understand it or not.   This dilemma would be helped if recipients published a DNS token to indicate that they understand the new feature.   Some will consider this inappropriate information disclosure, although I am currently having a hard time seeing the risk in the release of that information.    By and large, senders will want confidence that the new feature is widely deployed before they will begin depending on it for outbound delivery.    In the absence of recipient reporting, change may never happen.

Doug Foster

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 8/19/20 2:38 PM
To: "Kurt Andersen (b)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alessandro Vesely <[email-masked]>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) <[email-masked]> wrote:
On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely <[email-masked]> wrote:

Is there anything which has materially changed between 2012-13 and 2020 which would indicate that the anticipated results for such effort would be any different?

+1.  If anyone has some kind of creativity in this space that they've been hiding, now's the time.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 20 Aug 2020 10:58:39 +0200

Hi Tim and all,

I am wondering whether companies like Dmarcian could implement third-pary whitelisting.  As they receive and analyze DMARC aggregate reports on behalf of many mail sites, they probably are able to distinguish various level of authentication failures, from mailing lists to misaligned ESPs, to actual abusers.  In that case, they could maintain a whitelist tailored for any given client.  The client would set, say:

_dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:[email-masked]; snd=client-id.rhswl.dmarcian.com; [...]"

A receiver seeing a failed From: [email-masked], but an authenticated Sender: [email-masked] could check authorization by querying the following record:

example.com.client-id.rhswl.dmarcian.com IN A 127.0.0.2

If the record exists, the sender is authorized.  That way, a Dmarcian client can run for some time with p=none.  Meanwhile Dmarcian fills the client's whitelist based on misaligned authentications and the client's desiderata.  When the list is complete and receivers upgraded, the client can switch to p=reject or whatever they like.

Delivery would still lag in case, say, users subscribe to mailing lists not yet whitelisted, unless we make provisions for whitelisting requests to be submitted at subscription time.

For domain names longer than 200 octects (punycode), a whitelist may replace the domain name with a hash, á la ATPS.

The above setting overcomes the diagnosed non-trivial upkeep which prevented the diffusion of previous schemes.

Best
Ale

-------- Original Message --------
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
Date: Wed, 19 Aug 2020 21:18:29 GMT
From: Douglas E. Foster <fosterd=[email-masked]>
Reply-To: [email-masked]
To: [email-masked] <[email-masked]>

My two cents.

Third-party is only responsible for its own key.    A big organization like Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM keys, and that becomes an attractive target for attackers.  If a delegated DKIM key store is stolen from a third party, the attacker knows every domain that has been compromised.   If an ATPS-delegated third party has a corporate DKIM key stolen, the attacker knows that he has struck pay-dirt, but he does not have an immediate enumeration of compromised organizations..   That enumeration will require an additional data collection process, which might buy time for the affected organizations to take evasive measures.

Doug Foster

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Aug 2020 11:16:55 -0700

On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely <[email-masked]> wrote:

> I am wondering whether companies like Dmarcian could implement third-pary
> whitelisting.  As they receive and analyze DMARC aggregate reports on
> behalf of many mail sites, they probably are able to distinguish various
> level of authentication failures, from mailing lists to misaligned ESPs, to
> actual abusers.  In that case, they could maintain a whitelist tailored for
> any given client.  The client would set, say:
>
> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
> [email-masked]; snd=client-id.rhswl.dmarcian.com; [...]"
> [...]
>

Having spent a lot of time and energy building a DKIM-based reputation
system that (IMHO) showed promise, I made it available for people to try
for free.  There was no uptake, even after presenting its promising results
in places like M3AAWG.  Times may have changed, but in retrospect I think
there are too many "what-ifs" for add-ons of this nature to be seen as
feasible.  The issues seem to be:

- it has no hope of being universally accurate; participants have to accept
that false positives and false negatives will happen

- if it's perceived as effective, demand for this will skyrocket; the host
needs to be resilient to this

- participants have to trust the company providing the service to do so
reliably and honestly (e.g., no paying to be listed or get a reputation
boost)

- depending on failure modes, the host could become a DoS target; they need
to be resilient to this

- the "lag" to which you refer might be unacceptable in some situations;
participants need to be willing to tolerate this

- there will be demands for accuracy and timely responses; interfering with
someone's mail flow for whatever reason can draw unwanted legal attention
(e.g., MAPS)

I imagine large operators already have enough information to know where the
lists are, so for them this might be moot.  It's smaller operators without
the infrastructure to make such determinations in real time that need to
collaborate on something like this.

-MSK

---

From: Tim Draegen <[email-masked]>
Date: Thu, 20 Aug 2020 16:36:08 -0400

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely <[email-masked] <mailto:[email-masked]>> wrote:
> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:[email-masked] <mailto:[email-masked]>; snd=client-id.rhswl.dmarcian.com <http://client-id.rhswl.dmarcian.com/>; [...]"
> [...]
> 
> Having spent a lot of time and energy building a DKIM-based reputation system that (IMHO) showed promise, I made it available for people to try for free.  There was no uptake, even after presenting its promising results in places like M3AAWG.  Times may have changed, but in retrospect I think there are too many "what-ifs" for add-ons of this nature to be seen as feasible.  The issues seem to be:

Hi MSK, hi Ale,
I can second that MSK's DKIM-based reputation system is amazing. From where I sit, it's like a flying saucer that humans just haven't figured out how to fuel quite yet. I believe that fuel comes from widespread adoption of domain-based email authentication aka DMARC. The challenge of getting the email universe to embrace something like DMARC feels at times impossible, but the fact is it just takes a lot of coordination, dedication, and consistent levels of exercise to stay sane.

That said, Ale, I like the idea of a Domain Owner being able to share some sort of exception list for email flows that are recognized by the Domain Owner, but are still (for various reasons) beyond the ability of the Domain Owner to address. Something like, "I've got a vendor that will never send DMARC-compliant email on my behalf". It appeals to my fondness to be able to Just Fix Things without having to bother anyone. I don't think it would work, though, because it relies on email receivers having to widely implement new stuff, and it relies on Domain Owners accurately maintaining another thing. It's easier and more effective to get the vendor to do the right thing.

Oh, on 2nd read (I've been consumed with the non-IETF world for a few months and only took this up because Ale emailed me at work).. I think keying off of "Sender:" is a really bad idea. Multiple policy keys into a single piece of email has never made sense.

Third party authorization makes sense to me in theory as a tool for a very specific problem. In practice, people and organizations struggle to get first party authorization into place. Once they start to tackle their own first party authorization, the need for third party authorization tends to evaporate. What's left over? People that want to put together a list of authorized third parties but aren't quite ready to do their own first party auth?

From a receiver's perspective, it then looks like the first party has no idea what it is doing (which is the default anti-spam stance for all Internet mail), so then the receiver is now looking at a bunch of factors unrelated to first-party auth.. including any third party authorization. EG, the receiver notes that the email is authorized by a third-party - a newsletter company. "First party" authorization is NOT established, so the receiver has to process the email based on the strength of the newsletter company's reputation (among other things). So then why bother at all with the construct of "third party authorization"?

So I guess put me in the camp of not seeing utility in third party authorizations. Better to make the work that needs to be done as clear and as simple as possible.

=- Tim

---

From: Brandon Long <[email-masked]>
Date: Thu, 20 Aug 2020 14:00:53 -0700

On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen <[email-masked]> wrote:

> I can second that MSK's DKIM-based reputation system is amazing. From
> where I sit, it's like a flying saucer that humans just haven't figured out
> how to fuel quite yet. I believe that fuel comes from widespread adoption
> of domain-based email authentication aka DMARC. The challenge of getting
> the email universe to embrace something like DMARC feels at times
> impossible, but the fact is it just takes a lot of coordination,
> dedication, and consistent levels of exercise to stay sane.
>
> That said, Ale, I like the idea of a Domain Owner being able to share some
> sort of exception list for email flows that are recognized by the Domain
> Owner, but are still (for various reasons) beyond the ability of the Domain
> Owner to address. Something like, "I've got a vendor that will never send
> DMARC-compliant email on my behalf". It appeals to my fondness to be able
> to Just Fix Things without having to bother anyone. I don't think it would
> work, though, because it relies on email receivers having to widely
> implement new stuff, and it relies on Domain Owners accurately maintaining
> another thing. It's easier and more effective to get the vendor to do the
> right thing.
>
> Oh, on 2nd read (I've been consumed with the non-IETF world for a few
> months and only took this up because Ale emailed me at work).. I think
> keying off of "Sender:" is a really bad idea. Multiple policy keys into a
> single piece of email has never made sense.
> Third party authorization makes sense to me in theory as a tool for a very
> specific problem. In practice, people and organizations struggle to get
> first party authorization into place. Once they start to tackle their own
> first party authorization, the need for third party authorization tends to
> evaporate. What's left over? People that want to put together a list of
> authorized third parties but aren't quite ready to do their own first party
> auth?
>
> From a receiver's perspective, it then looks like the first party has no
> idea what it is doing (which is the default anti-spam stance for all
> Internet mail), so then the receiver is now looking at a bunch of factors
> unrelated to first-party auth.. including any third party authorization.
> EG, the receiver notes that the email is authorized by a third-party - a
> newsletter company. "First party" authorization is NOT established, so the
> receiver has to process the email based on the strength of the newsletter
> company's reputation (among other things). So then why bother at all with
> the construct of "third party authorization"?
>
> So I guess put me in the camp of not seeing utility in third party
> authorizations. Better to make the work that needs to be done as clear and
> as simple as possible.
>

I tend to agree with the negative stance on third party auth, but SPF
obviously has the include: statement which is third party auth at the most
basic level...
atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
because it wasn't all that useful, or if it was tied in folks minds to
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage
across thousands of "relays" etc, and I don't think they should be used for
that, but for a bunch of small to medium entities, it could be the thing
that makes higher p= possible.

Brandon

[1] I just looked atps again, but I might have missed something that makes
it less useful

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 20 Aug 2020 18:26:19 -0500

> Neither atps or spf include are really designed for large scale usage

That's my conclusion, as well.  I don't want to authorize every potential MLM to use all addresses in all of our domains cart blanch, even if I would otherwise trust them (e.g. their purported ARC results).

I *do* want to authorize our *own* MLM(s) to use our own domains for *internal* use... so I thought for a minute... maybe ATSP has merit for small scale usage, as an alternative to SPF include?  But no, I don't know if any MLM has a way to check to see if they are authorized via any mechanism, so they will continue to munge the From header for our DMARC-enabled domains anyway.  So, for this *internal* use case, maybe I'll just check the ARC result from the trusted MLM and replace the From header with the value of Reply-to/X-Original-From, and call it a day.

Jesse

---

From: Dotzero <[email-masked]>
Date: Thu, 20 Aug 2020 19:55:52 -0400

On Thursday, August 20, 2020, Jesse Thompson <jesse.thompson=
[email-masked]> wrote:

> That's my conclusion, as well.  I don't want to authorize every potential
> MLM to use all addresses in all of our domains cart blanch, even if I would
> otherwise trust them (e.g. their purported ARC results).
>
> I *do* want to authorize our *own* MLM(s) to use our own domains for
> *internal* use... so I thought for a minute... maybe ATSP has merit for
> small scale usage, as an alternative to SPF include?  But no, I don't know
> if any MLM has a way to check to see if they are authorized via any
> mechanism, so they will continue to munge the From header for our
> DMARC-enabled domains anyway.  So, for this *internal* use case, maybe I'll
> just check the ARC result from the trusted MLM and replace the From header
> with the value of Reply-to/X-Original-From, and call it a day.
>
> Jesse
>

This is why I proposed a tag that would have a value consisting of the
authorized intermediary domain. It would only be valid for that message.
Because the tag is signed separately from the rest of the message, it
should survive even if the intermediary modifies other parts of the
message. If the intermediary DKIM signs the modified message with their own
signature, that provides some assurance to the receiver.

I haven't seen enough favorable response to justify working on a detailed
submission to the group. I'm not an IETF standards wonk.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 21 Aug 2020 10:57:41 +0200

On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson <[email-masked]> wrote:
>> On 8/20/20 4:00 PM, [email-masked] wrote:
>> small scale usage, as an alternative to SPF include?

Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a rhswl zone which can be outsourced.

>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now.  From: rewriting is not going to stop on the next day.  We must tune aggregate reports so that MLMs can tell if it's still necessary.  It may take decades...  still better than ∞.

>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of operators.  And, in case, I'd adopt John's broad brush:  If I went so far as to whitelist the MLM, why should I take the burden to scrutinize the way it applied policies?  It seems more sound to allow my recipients to see the same messages as every other subscriber.

> signature, that provides some assurance to the receiver.

That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior.  AIUI, the sender recognizes that one of the recipients is an allowed mailing list, and adds that tag to that copy of the message.  It looks less outsourceable than an external whitelist.

Let me call weak signature this concept.  As it is very similar to dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as weak signatures can all be adopted concurrently.

> submission to the group. I'm not an IETF standards wonk.

I'd support weak signatures, in either embodiment.  I don't think it needs to be linked to the Sender: field.

Best
Ale
--

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 21 Aug 2020 11:04:20 GMT

Instead of immediately deciding which ideas can and cannot work, I suggest that we create an extension mechanism for DMARC and then let the market decide.  Perhaps someone will find traction for an idea that is useful to a subset of users even if it is not useful for every sender-receiver pair.

The extension mechanism could be as simple as an "add-ons=Y" clause in the DMARC record.

If a receiver has implemented ANY add-on method, this flag tells him to check all of the options that he supports.   Most likely this will require one or more additional DNS lookups to determine which add-on technique is supported by the sender.    The result of those lookups will determine if the sender and the receiver support any of the same techniques.   When there is a match on supported techniques, the logic for that technique is invoked.    But when the flag is absent, no resources are wasted on checking add-on methods that can only apply to a subset of all messages.

This approach separates the DMARC spec, which focuses on two specific authentication strategies, from add-on methods that invoke alternate authentication strategies, so that the DMARC specification can move forward.

It leaves room for all of the ideas mentioned so far, and for those that have not yet been suggested.   It also leaves room for a good-but-neglected idea to gain traction based on future events.

The details of those other implementations can be determined by private agreement or by RFC.

DF

Sent: 8/21/20 4:58 AM

Best
Ale
--

---

From: Jim Fenton <[email-masked]>
Date: Fri, 21 Aug 2020 12:23:57 -0700

> Normal people sending email (especially those who are working with an ESP, most of which happily send email without any DMARC alignment) do not comprehend the notion that they should be using a sub…
I thought the DMARC reporting mechanism was there to allow such
organizations to detect those behaviors and get them corrected without
actually causing the damage of a restrictive policy.

-Jim

---

From: Brandon Long <[email-masked]>
Date: Fri, 21 Aug 2020 14:05:03 -0700

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton <[email-masked]> wrote:

> > With a complex organization the only way to get people to change is to
> publish a restrictive DMARC policy and then see who comes out of the
> woodwork sheepishly admitting that they've been ignoring us for years.
> >
> > Normal people sending email (especially those who are working with an
> ESP, most of which happily send email without any DMARC alignment) do not
> comprehend the notion that they should be using a subdomain for their
> transactional messages; even when we directly communicate this fact to them
> repeatedly.  They just don't understand the nuances of email.
> >

One thing we've found useful in this case is controlling the organization
from spamming.

Which is to say that the org has a policy on approvals and what is allowed
to be sent marketing wise, in some parts of the world to comply with laws
on such topics,
or to be sure the entire org follows the principles and someone new doesn't
just poison the pool for everyone else.

There are always people who route around restrictions or sometimes don't
even bother to look for anything, they'll just hire a third party ESP and
spam away.

DMARC helps in this case to reduce the success of that and force them back
to internal compliance, which relieves the legal burden as well as the
negative impacts
on delivery and public perception.

For folks who just register a new domain name and spam anyways... yeah,
well, there are other consequences down the line and other anti-phishing
restrictions that
kick in at least on our inbound systems..

Brandon

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 21 Aug 2020 17:07:06 -0500

On 8/21/20 4:05 PM, Brandon Long wrote:
> 
> 
> On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:
> 
> One thing we've found useful in this case is controlling the organization from spamming.
> 
> Which is to say that the org has a policy on approvals and what is allowed to be sent marketing wise, in some parts of the world to comply with laws on such topics,
> or to be sure the entire org follows the principles and someone new doesn't just poison the pool for everyone else.
> 
> There are always people who route around restrictions or sometimes don't even bother to look for anything, they'll just hire a third party ESP and spam away.
> 
> DMARC helps in this case to reduce the success of that and force them back to internal compliance, which relieves the legal burden as well as the negative impacts
> For folks who just register a new domain name and spam anyways... yeah, well, there are other consequences down the line and other anti-phishing restrictions that

Right.  

Moving past p=none puts somewhat of a backstop on the internal compliance problem, which would otherwise continue indefinitely.  I've put them into a state where they have to get a subdomain and learn about DMARC.  

DMARC [aggregate] reports don't tell us *who* in our organization is perpetuating the problem, especially if their volume is low or not visible to the few DMARC reporters.  At some point you need to acknowledge that you will never have complete visibility.

Jesse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Aug 2020 08:13:20 -0700

> signature, that provides some assurance to the receiver.

You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

I'm pretty sure that got implemented too, but I can't recall now if it ever
shipped.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Aug 2020 08:20:39 -0700

> that makes higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was
conceptually useful at all.  Scale could come later if the initial
experiment had a positive result.  The industry, however, apparently didn't
even have appetite to try, so we may never know.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2020 13:24:03 -0400

In article <CAL0qLwaip0fzXpqnK=XTcEELZRat_gnjuEGZYj=[email-masked]> you write:
>I'm pretty sure that got implemented too, but I can't recall now if it ever shipped.

I don't think it ever did.  It has the scaling problem of every system that sends to mailing lists
having to decide what mail it's willing to have re-signed and what domain the second signature
will use.  Usually it's the domain name of the list except when it's not.

R's,
John

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 24 Aug 2020 22:34:31 GMT

Something seems inconsistent:

- The people who have implemented DMARC do not see any significant problems, and as a result they are not interested in a third-party authorization scheme.

- Yet adoption is very slow, especially for anything other than p=none

Are we to assume that mailing list compatibility explains the slow adoption?   If not, what other obstacles do we need to be considering?

DF

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 8/24/20 11:21 AM
To: Brandon Long <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>, Tim Draegen <[email-masked]>, Alessandro Vesely <[email-masked]>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon Long <[email-masked]> wrote:
I tend to agree with the negative stance on third party auth, but SPF obviously has the include: statement which is third party auth at the most basic level...atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed because it wasn't all that useful, or if it was tied in folks minds to adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage across thousands of "relays" etc, and I don't think they should be used for that, but for a bunch of small to medium entities, it could be the thing that makes higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was conceptually useful at all.  Scale could come later if the initial experiment had a positive result.  The industry, however, apparently didn't even have appetite to try, so we may never know.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Aug 2020 21:19:57 -0700

On Mon, Aug 24, 2020 at 3:34 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> - The people who have implemented DMARC do not see any significant
> problems, and as a result they are not interested in a third-party
> authorization scheme.
>

I suspect you are conflating disinterest with being unconvinced that it is
workable, at least in any of the forms in which it's been presented.

I implemented DMARC and, unless you've been missing my commentary, I am far
from "do not see any significant problems".

-MSK

---

From: Dotzero <[email-masked]>
Date: Tue, 25 Aug 2020 04:58:25 -0400

On Mon, Aug 24, 2020 at 6:34 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> Are we to assume that mailing list compatibility explains the slow
> adoption?   If not, what other obstacles do we need to be considering?
>
> DF
>

DMARC itself is easy to implement. It's getting control of your mail flows
that is the difficult part for most organizations interested in
implementing. I think the real issue for "slow adoption" is lack of
perceived need, until you believe your domain is being abused.  What is the
uptake for DNSSEC? For most IETF standards other than very core ones, the
long tail is indeed very long. My gut tells me, based on being in this
space a long time, that the overwhelming majority of people aren't thinking
about DMARC, let alone the "mailing list problem"/

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Aug 2020 11:03:41 +0200

On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote:
>>> If the intermediary DKIM signs the modified message with their own

Right.  The only practical implementation I see is that the sender has 
a list of recipient addresses that require weak signatures.  When it 
is about to send a message destined to a listed address, it can fork 
the message so that the weakly signed copy is sent to the (trusted) 
list address only.  Any direct copy is signed in full.

To configure that, a postmaster would need an application by the list. 
  Something saying "your users A, B, and C are subscribed to list X, 
please sign weakly".  The postmaster would then verify if A, B, and C 
are trusted users and if they confirm to be subscribed to X.  In that 
case, the address of X gets enlisted.  Would that scale?

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Tue, 25 Aug 2020 05:14:27 -0400

On Tue, Aug 25, 2020 at 5:03 AM Alessandro Vesely <[email-masked]> wrote:

> >> You mean like
> https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
> >>

Under my concept, all mail would still be signed in full. The weak
signature would be in addition to the full signature and the intermediary
would be expected to sign in full as well. If the original full signature
is broken you are left with the original "weak signature" which authorizes
the intermediary and the full signature of the intermediary.

I would expect there to be multiple potential approaches to identifying
acceptable intermediaries. One might be user self enrollment. For larger
organizations it might be intermediary application/approval. A 3rd approach
might be a trusted 3rd party providing lists of known intermediaries. This
would be separate from the core signing RFC, whether it is part of DMARC or
a separate document.

Michael Hammer.

---

From: Laura Atkins <[email-masked]>
Date: Tue, 25 Aug 2020 10:47:38 +0100

> On 24 Aug 2020, at 23:34, Douglas E. Foster <fosterd=[email-masked]> wrote:
> 

I don’t believe mailing list compatibility is a primary reason for slow adoption, although I do think it’s a contributing factor. To my mind the biggest obstacle to adoption of restrictive policies is the expense of implementation and the lack of return for that investment. 

Implementing DMARC, particularly for larger companies who want to do it correctly, is expensive and resource intensive. It is a multi-month process to identify all the legitimate sources of mail, create alignment or move vendors and set up the correct reporting mechanism. You can, and I do recommend, outsource this to one of the vendors who does this well. Not every company outsources or has the resources to do this correctly internally. A client from last year was told they had less than a week to go from no DMARC to p=reject. Unfortunately, the IT directive came with nothing more than a “publish v=DMARC1; p=reject in your DNS.” Client lost days worth of mail due to a lack of direct alignment even though they were using their own domains in SPF and DKIM. Checking now, client still isn’t collecting reports, but has backed down to p=quarantine. 

A restrictive DMARC record requires a large, up-front commitment of resources. It also requires ongoing resources for monitoring and understanding the reports and the ability to be able to address any problems that show up in the reports. 

For a lot of companies, the benefit to publishing restrictive DMARC policy is minor. It stops bad guys from directly forging their domain, but doesn’t stop your brand being phished or your executives from being spear phished using cousin domains or taking advantage of the 5322.from comment. It also disrupts normal business processes as we’ve been discussing on the list here. To borrow an example from John Levine, a restrictive DMARC policy is preventing employees at a large company from participating in industry specific mailing lists; participation which is part of their actual job. 

I believe a lot of the very slow adoption is folks inside companies looking at the cost of implementing restrictive DMARC records and the benefits to implementing restrictive DMARC records and deciding there just isn’t enough benefit to justify the expense. BIMI is an attempt to bring more benefit to the table, but I’m not sure even that is enough to justify the overall expense to a lot of corporations. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Dotzero <[email-masked]>
Date: Tue, 25 Aug 2020 09:07:53 -0400

On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins <[email-masked]>
wrote:

>
>
> On 24 Aug 2020, at 23:34, Douglas E. Foster <
> fosterd=[email-masked]> wrote:
>
> I don’t believe mailing list compatibility is a primary reason for slow
> adoption, although I do think it’s a contributing factor. To my mind the
> biggest obstacle to adoption of restrictive policies is the expense of
> implementation and the lack of return for that investment.
>
> Implementing DMARC, particularly for larger companies who want to do it
> correctly, is expensive and resource intensive. It is a multi-month process
> to identify all the legitimate sources of mail, create alignment or move
> vendors and set up the correct reporting mechanism. You can, and I do
> recommend, outsource this to one of the vendors who does this well. Not
> every company outsources or has the resources to do this correctly
> internally. A client from last year was told they had less than a week to
> go from no DMARC to p=reject. Unfortunately, the IT directive came with
> nothing more than a “publish v=DMARC1; p=reject in your DNS.” Client lost
> days worth of mail due to a lack of direct alignment even though they were
> using their own domains in SPF and DKIM. Checking now, client still isn’t
> collecting reports, but has backed down to p=quarantine.
>
> A restrictive DMARC record requires a large, up-front commitment of
> resources. It also requires ongoing resources for monitoring and
> understanding the reports and the ability to be able to address any
> problems that show up in the reports.
>
> For a lot of companies, the benefit to publishing restrictive DMARC policy
> is minor. It stops bad guys from directly forging their domain, but doesn’t
> stop your brand being phished or your executives from being spear phished
> using cousin domains or taking advantage of the 5322.from comment. It also
> disrupts normal business processes as we’ve been discussing on the list
> here. To borrow an example from John Levine, a restrictive DMARC policy is
> preventing employees at a large company from participating in industry
> specific mailing lists; participation which is part of their actual job.
>
> I believe a lot of the very slow adoption is folks inside companies
> looking at the cost of implementing restrictive DMARC records and the
> benefits to implementing restrictive DMARC records and deciding there just
> isn’t enough benefit to justify the expense. BIMI is an attempt to bring
> more benefit to the table, but I’m not sure even that is enough to justify
> the overall expense to a lot of corporations.
>
> laura
>

I agree with many of Laura's observations. One other issue is that DMARC
adoption is typically advocated by security and/or IT.  When put against
competing demands for resources and potential projects in an organization,
it often gets moved down the priority list... until the organization is
being abused in a way that they feel DMARC might help mitigate. Then there
is a rush to implement, often with painful outcomes.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 25 Aug 2020 12:22:19 -0400

> the intermediary and the full signature of the intermediary.

Take another look at my old draft.  Sounds like exactly the same plan.

> acceptable intermediaries.

The harder part is to decide which intermediary gets to re-sign which 
message at the time you apply the weak signature.

Regards,

---

From: Dotzero <[email-masked]>
Date: Tue, 25 Aug 2020 13:51:11 -0400

> Take another look at my old draft.  Sounds like exactly the same plan.

I will.

> message at the time you apply the weak signature.

It would have be the domain in the "To" field.  It wouldn't work with
random unknown intermediaries. It would address the MLM issue as long as
the MLM domain is the same as the "To" domain when the message was
originally sent. It could also presumably work for vanity domains if they
DKIM sign. It wouldn't work for forwards on the receiver side that the
sender is unaware of.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 25 Aug 2020 14:13:46 -0400

> DKIM sign. It wouldn't work for forwards on the receiver side that the

If the list is [email-masked], does the signature have to be 
d=lists.foo.org?  How about d=foo.org?

On the flip side, do you put a weak signature on all of your outgoing 
mail, which seems like a bad idea, or just mail that you expect to go 
through list modification?  In the latter case, how do you tell?  These 
are the scaling problems that I fear make this unworkable.

Regards,

---

From: Dotzero <[email-masked]>
Date: Tue, 25 Aug 2020 16:29:51 -0400

> d=lists.foo.org?  How about d=foo.org?

This is something that would have to be thought through and discussed. I
want to lean towards exact match but I could be convinced that the base
organization signature would be acceptable as a starting point. I would
recommend anyone coding this for signing to use a flag to easily switch
between the two. I'd recommend that any intermediary doing signing consider
using the CNAME approach so that all their lists can easily be signed with
an exact match signature. This is one of the areas where implementation and
operational considerations may differ from standards considerations.

> are the scaling problems that I fear make this unworkable.

I think only putting the weak signature on mail you expect to be modified
would be the way to go. As I indicated in my previous post, there are
multiple ways to address identifying which mail is likely to go through an
intermediary.  Large mail providers/data gatherers probably already have an
awareness in this space. Others could probably create lists which could be
checked realtime or updated/downloaded once or twice a day. Organizations
could also enable self registration of intermediary use by their users. It
might also be a combination of these approaches. I don't see this as an
issue that makes scaling unworkable. There are plenty of folks checking for
blocklists, how does this differ significantly either operationally or in
scale?

Michael Hammer

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Aug 2020 15:09:48 -0700

> d=lists.foo.org?  How about d=foo.org?
This seems like an analogous situation to the DKIM i= flag, where the
domain MUST be the same as, or a subdomain of, the value of the d= flag.
So I'd recommend allowing d=foo.org.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2020 22:39:48 -0400

>So I'd recommend allowing d=foo.org.

Well, OK, how about d=org?  This is the opposite of i=, superdomains rather than subdomains.

R's,
John

PS: I realize .org isn't likely to be signing anything, there are 25 TLDs with
top level MX or A records that plausibly could.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 26 Aug 2020 09:36:23 -0700

> Well, OK, how about d=org?  This is the opposite of i=, superdomains rather than subdomains.

I see it as being in the same direction as i=, because we're talking
about being able to sign with a superdomain of [whatever identifier] in
both cases. But it doesn't really matter.

In principle, d=org would work too. The identified domain (list domain,
i=, whatever) always has to trust all higher level domains: because they
delegate the DNS to the lower level, they could in principle add their
own selector records if they wanted to spoof the subdomain. But I
haven't ever heard of that being a problem.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 26 Aug 2020 18:58:20 +0200

On Tue 25/Aug/2020 20:13:46 +0200 John R Levine wrote:
> On the flip side, do you put a weak signature on all of your outgoing mail, 
> which seems like a bad idea, or just mail that you expect to go through list 
> modification?  In the latter case, how do you tell?  These are the scaling 
> problems that I fear make this unworkable.

https://tools.ietf.org/html/draft-levine-dkim-conditional-03#section-4.1 looks 
quizzical.  It says:

    A small sender that doesn't know which of its mail recipients are
    likely to be forwarders might put a weak signature on all outgoing
    mail, in the expectation that few of its users correspondents are
    likely to be malicious.

If a sender has no idea, what domain would it put in fs=, the recipient's 
domain?  That entails that a signing filter acts in an advanced SMTP step, 
where the connection to the MX is established and the receiving domain known.

Also, in the previous paragraph:

    A sender that expects a message to be forwarded might put both a
    conventional DKIM signature and a signature with a !fs tag that
    refers to the domain name of the expected forwarder.  That signature
    would typically be a "weak" signature that covers the From, To, Date,
    and Message-ID headers but does not cover the Subject header or the
    message body, so that it would remain valid even if a forwarder made
    changes typical of forwarders such as mailing lists.

I understand that nobody can prevent a sender to put a conventional DKIM 
signature, even if it expects the message to be forwarded.  However, if the 
scenario gets upgraded so as to consider that the sender /knows/ that the 
message is going to be forwarded, then the conventional signature is pretty 
useless, as forwarding will break it.  How about this:

    A sender that expects a message to be forwarded might well skip putting
    a conventional DKIM signature and put just a signature with a !fs tag that
    refers to the domain name of the expected forwarder.  That signature
    would typically be a "weak" signature that covers the From, Date, and
    Message-ID headers but does not cover the Subject, To, or Cc header fields,
    nor the message body.

(To: and Cc: are often reordered, which breaks signatures.)

Finally, IMHO the Security Consideration section should compare using !fs= 
versus plain weak signatures.  In particular, consider senders who carefully 
avoid to send out weak signatures except for trusted (forwarding) recipients. 
Would it be advisable to put both a plain weak signature and a signature with 
!fs=?  Plain weak signatures might be discarded by recipients with local 
policies about l=, while v=man signatures might be discarded by unupgraded 
verifiers.  Putting two signatures together is rather common in the presence of 
new features, e.g. those who use elliptic keys do so.  What is the difference 
between the risks brought on by each kind of weak signature?  Answering such 
question justifies the version change.

Best
Ale
--

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 26 Aug 2020 13:31:33 -0400

Are the weak signatures vulnerable to a replay attack?    I thought that one of the reasons that DKIM signatures included the whole body was to prevent the signature from being reused.

DF

From: dmarc [mailto:[email-masked]] On Behalf Of Dotzero
Sent: Tuesday, August 25, 2020 1:51 PM
To: John R Levine
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list

I will. 

It would have be the domain in the "To" field.  It wouldn't work with random unknown intermediaries. It would address the MLM issue as long as the MLM domain is the same as the "To" domain when the message was originally sent. It could also presumably work for vanity domains if they DKIM sign. It wouldn't work for forwards on the receiver side that the sender is unaware of.

Michael Hammer

---

From: Dotzero <[email-masked]>
Date: Wed, 26 Aug 2020 13:54:08 -0400

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=
[email-masked]> wrote:

> Are the weak signatures vulnerable to a replay attack?    I thought that
> one of the reasons that DKIM signatures included the whole body was to
> prevent the signature from being reused.
>
>
>
> DF
>

Not particularly vulnerable. The requirement is that you have the "weak
signature" plus the intermediary full DKIM signature. This let's the
validator/receiver know that the originating domain knew that the
intermediary might break the originating domains DKIM signature but the
validator/receiver would have the DKIM signature of the intermediary. The
"weak signature" is only validated against that specific message and
headers it signed and that specific intermediary. It's not a
generic/general signature.

Michael Hammer

---

From: Jim Fenton <[email-masked]>
Date: Wed, 26 Aug 2020 14:00:28 -0700

On 8/26/20 10:54 AM, Dotzero wrote:
>
>
> On Wed, Aug 26, 2020 at 1:32 PM Doug Foster
> <fosterd=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Are the weak signatures vulnerable to a replay attack?    I
>     thought that one of the reasons that DKIM signatures included the
>     whole body was to prevent the signature from being reused.
>
>      
>
>     DF
>
>
> Not particularly vulnerable. The requirement is that you have the
> "weak signature" plus the intermediary full DKIM signature. This let's
> the validator/receiver know that the originating domain knew that the
> intermediary might break the originating domains DKIM signature but
> the validator/receiver would have the DKIM signature of the
> intermediary. The "weak signature" is only validated against that
> specific message and headers it signed and that specific intermediary.
> It's not a generic/general signature.

It sounds like the weak signature is just a regular DKIM signature plus
the designation of the intermediary, and the "weak" part is that you
don't check the body hash against the body. Have I got that right?

-Jim

---

From: Dotzero <[email-masked]>
Date: Wed, 26 Aug 2020 17:32:10 -0400

On Wed, Aug 26, 2020 at 5:00 PM Jim Fenton <[email-masked]> wrote:

> the designation of the intermediary, and the "weak" part is that you don't
> check the body hash against the body. Have I got that right?
>
> -Jim
>
Not exactly. The intermediary can check the full DKIM signature. The
ultimate validator/receiver can check the full DKIM signature of the
intermediary plus the "small" signature (I'm not comfortable with the
phrase "weak signature") of the originator. If the original DKIM signature
gets broken by the known intermediary then you have a mechanism to identify
that the originator recognized the intermediary. This is not my preferred
approach but I'm trying to find something that works to accommodate the
various needs/wants expressed on the list. In my perfect world the
intermediary would change it's behavior but that isn't going to happen.
This is more straight forward than many of the other suggestions I've seen.
Hat tip to John for his original idea for this approach. I'd be interested
in seeing if any of the larger players (receivers) would be willing to
utilize this sort of approach. Also, if anyone (organization) would be
willing to provide a list of known intermediaries on some basis (whether
free or pay). If these two things are in place then it is certainly worth
exploring this approach in more detail.

Michael Hammer

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 29 Aug 2020 19:42:36 GMT

To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is computed.   The weak signature will not be unique because it will be computed on non-random content such as From, To, and Date.

However, the signature can only be used by the designated domain.   So the worst possible "misuse" would be for the designated domain to use the signature on other messages.   This seems unlikely, and the worst-case use is no different than what ATSP would authorize.   But the weak signature has less information leakage, since nothing is published in DNS about the signature technique.   So I agree that the approach is a good one for those who want to provide mailing-list authorization.

The remaining challenge is to communicate between recipient domains and mailing lists so that the list knows whether the recipient will honor the weak signature system.

Doug Foster

----------------------------------------
From: Jim Fenton <[email-masked]>
Sent: 8/26/20 5:01 PM
To: Dotzero <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/26/20 10:54 AM, Dotzero wrote:

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=[email-masked]> wrote:

DF

Not particularly vulnerable. The requirement is that you have the "weak signature" plus the intermediary full DKIM signature. This let's the validator/receiver know that the originating domain knew that the intermediary might break the originating domains DKIM signature but the validator/receiver would have the DKIM signature of the intermediary. The "weak signature" is only validated against that specific message and headers it signed and that specific intermediary. It's not a generic/general signature.

It sounds like the weak signature is just a regular DKIM signature plus the designation of the intermediary, and the "weak" part is that you don't check the body hash against the body. Have I got that right?

-Jim

---

From: Dotzero <[email-masked]>
Date: Sat, 29 Aug 2020 16:12:11 -0400

On Sat, Aug 29, 2020 at 3:43 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> To be unique, a signature needs a unique dataset from which the hash is
> computed.   The weak signature will not be unique because it will be
> computed on non-random content such as From, To, and Date.
>

There are additional ways of introducing complexity and randomness.

>
> However, the signature can only be used by the designated domain.   So the
> worst possible "misuse" would be for the designated domain to use the
> signature on other messages.   This seems unlikely, and the worst-case use
> is no different than what ATSP would authorize.   But the weak signature
> has less information leakage, since nothing is published in DNS about the
> signature technique.   So I agree that the approach is a good one for those
> who want to provide mailing-list authorization.
>
> The remaining challenge is to communicate between recipient domains and
> mailing lists so that the list knows whether the recipient will honor the
> weak signature system.
>
> Doug Foster
>
>
>
>
> ------------------------------
> *From*: Jim Fenton <[email-masked]>
> *Sent*: 8/26/20 5:01 PM
> *To*: Dotzero <[email-masked]>
> *Cc*: IETF DMARC WG <[email-masked]>
> *Subject*: Re: [dmarc-ietf] third party authorization, not, was
> non-mailing list

---

From: Jim Fenton <[email-masked]>
Date: Sat, 29 Aug 2020 16:11:03 -0700

On 8/29/20 12:42 PM, Douglas E. Foster wrote:
> To be unique, a signature needs a unique dataset from which the hash
> is computed.   The weak signature will not be unique because it will
> be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique,
even though it is not random. For that matter, DKIM signatures don't
include any random values either.

But what I was getting at is that the "weak" signature might not have to
be any different from any other DKIM signature (except possibly to
specify the authorized mediator). It's just that a verifier might fully
verify the mediator's signature, and verify the original signature but
not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to
the subject line, and that's usually signed.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Aug 2020 22:23:41 -0400

On 8/26/2020 5:00 PM, Jim Fenton wrote:
>>     thought that one of the reasons that DKIM signatures included
>>     the whole body was to prevent the signature from being reused.
>>
>>     DF
>>
>>
>> "weak signature" plus the intermediary full DKIM signature. This
>> let's the validator/receiver know that the originating domain knew
>> that the intermediary might break the originating domains DKIM
>> signature but the validator/receiver would have the DKIM signature
>> of the intermediary. The "weak signature" is only validated against
>> that specific message and headers it signed and that specific
>> intermediary. It's not a generic/general signature.
>
>
> It sounds like the weak signature is just a regular DKIM signature
> plus the designation of the intermediary, and the "weak" part is that
> you don't check the body hash against the body. Have I got that right?

Yes.

ATPS vs Conditional Signature

The end goal is technically the same. Author Domain authorizing a 3rd 
party signer.

The key difference is DNS. ATPS uses DNS to authorize the signer. 
Conditional signature has the extra tag to define an expected 3rd 
party signature by a 3rd party domain uplink.

For the signing code, there is no change for ATPS. Conditional 
requires significant signer code change.

For the verifying code, the DMARC verifier adds ATPS DNS lookup checks 
if 1st != 3rd party domains differ or it can also add conditional 
signatures checks.

We should ALLOW both to be explored.

For conditional, you don't need a DMARC tag extension.  The existence 
of the extra tag triggers the logic.

For ATPS RFC6541, it was designed to piggyback off ADSP. So ATPS will 
need to be updated to use DMARCbis.  The Domain sets the atps=y 
extension tag to trigger the logic.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 30 Aug 2020 10:47:29 +0200

On Sun 30/Aug/2020 01:11:03 +0200 Jim Fenton wrote:
> The one problem is that some mediators add things like [dmarc-ietf] to the 
> subject line, and that's usually signed.
> 

Multi-mailbox To: and Cc: are also usually signed and possibly reordered by 
mediators.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 30 Aug 2020 12:27:48 -0400

In article <[email-masked]> you write:
>not check to see if the body hash matches. ...

I just sent in a slightly refreshed version of my conditional signature draft
which says exactly that.

It's not very different from the orginal version I sent in over six years ago.

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

R's,
John

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 30 Aug 2020 18:37:38 GMT

This all looks workable to me, if it can gain support from senders, recipients, and mailing lists.

But as I have said before, the last part of the protocol needs to be a way for the mediator to know that the recipient will accept the message.   This could be because:
Recipient honors conditional signatures (or any other future third-party authorization system.)Recipient has whitelisted the mailing list, so DMARC will not be enforced against the list.Recipient does not enforce DMARC at all.
The first option is the most complicated, because it requires the list to change behavior based on both sender and recipient configuration.   The latter two only require knowledge of the recipient configuration, and could be implemented today.   But early in this discussion, John implied that recipient-specific tailoring of the From address is outside the capabilities of modern mailing lists.   To get IETF backing, the signalling between lists and recipients also needs to scale, which implies a high level of automation. 

Is there any way to solve this part of the problem?

DF

----------------------------------------
From: "John Levine" <[email-masked]>
Sent: 8/30/20 12:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 30 Aug 2020 22:32:21 -0700

On Sun, Aug 30, 2020 at 11:38 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> But as I have said before, the last part of the protocol needs to be a way
> for the mediator to know that the recipient will accept the message.   This
> could be because:
>
>    - Recipient honors conditional signatures (or any other future
>    third-party authorization system.)
>    - Recipient has whitelisted the mailing list, so DMARC will not be
>    enforced against the list.
>    - Recipient does not enforce DMARC at all.
>
> The first option is the most complicated, because it requires the list to
> change behavior based on both sender and recipient configuration.   The
> latter two only require knowledge of the recipient configuration, and could
> be implemented today.   But early in this discussion, John implied that
> recipient-specific tailoring of the From address is outside the
> capabilities of modern mailing lists.   To get IETF backing, the signalling
> between lists and recipients also needs to scale, which implies a high
> level of automation.
>

I'm not clear on why you think the first option is the most complicated.  I
think it's the simplest, since the entire thing is implemented at the DKIM
layer.  DMARC and the MLM don't even know any of this is happening.

I suspect the complicated part is the logic the author domain's signer
needs to use when deciding whether to affix the weaker signature, because
of the replay risk described in the draft.  If you want to be pure about
this, you need to know where all the lists are, which means either
discovering them or having your users register them.  At a large scale,
those aren't pragmatic, so you might do something like affix the weaker
signature only if the set of domains in the union of the To: and Cc: fields
(or perhaps the envelope recipients) is small, and avail yourself of the
semantics of the "x=" tag (also described in the draft).

Interesting.

Looking at my open source stuff, it seems I did a variant of the -03 draft,
where the tag was "cd" (probably for "conditional domain").  I vaguely
remember that discussion.  Wouldn't be hard to change one or the other.

-MSK