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

From: Autumn Tyr-Salvia <[email-masked]>
Date: Tue, 28 Jul 2020 06:54:02 +0000

Hello,

I recently had a conversation with Dave Crocker about proposed changes for DMARC, and mentioned a use case to him that is not well served by the current situation that is not a mailing list. He said it might be useful to share this to this list, so I'm writing it out here.

A customer of mine is a large financial services company. Like many in that field, they have acquired several other companies over the years, and now operate multiple different brands, which send email using different domains. While many companies like this maintain one primary domain for corporate email and others only for marketing purposes, this company maintains multiple distinct domains even for corporate workplace email.

The challenge is that they have many administrative assistants who send out meeting calendar invitations on behalf of the executives they support, and the executive and the assistant do not always use the same email domain. The resulting messages are not aligned, so they fail DMARC.

To put it another way:

  *   [email-masked] is organizing a meeting for [email-masked]
  *   [email-masked] sends out a calendar invite from their own messaging client, using [email-masked] in the From: field
  *   The resulting message uses [email-masked] in the friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.
  *   Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
  *   Messages like this are then rejected by receivers that validate DMARC results.

Whenever possible, they tell me they change the assistant's email domain to match the executives they support, but as people leave or change departments, they sometimes end up with assistants supporting executives across multiple different domains, so they can't ensure they always have the same domain.

Maybe the ultimate answer for this customer and others in a similar situation is simply that this is a use case that can no longer be supported due to evolving security needs, and yet if that's the case, I thought it would be helpful to share a real world scenario that is currently impacted that isn't part of the previously existing discussion around mailing lists.

Thanks,

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 09:36:37 +0200

On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:
> # The resulting message uses [email-masked] in the friendly From: 
> field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no 
> longer aligned for SPF.
> #

Heck, can't they DKIM sign?

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Tue, 28 Jul 2020 03:51:18 -0400

On Tue, Jul 28, 2020 at 2:54 AM Autumn Tyr-Salvia <atyrsalvia=
[email-masked]> wrote:

> Hello,
>
> I recently had a conversation with Dave Crocker about proposed changes for
> DMARC, and mentioned a use case to him that is not well served by the
> current situation that is not a mailing list. He said it might be useful to
> share this to this list, so I'm writing it out here.
>
> A customer of mine is a large financial services company. Like many in
> that field, they have acquired several other companies over the years, and
> now operate multiple different brands, which send email using different
> domains.. While many companies like this maintain one primary domain for
> corporate email and others only for marketing purposes, this company
> maintains multiple distinct domains even for corporate workplace email.
>
> The challenge is that they have many administrative assistants who send
> out meeting calendar invitations on behalf of the executives they support,
> and the executive and the assistant do not always use the same email
> domain. The resulting messages are not aligned, so they fail DMARC.
>
> To put it another way:
>
>    - [email-masked] is organizing a meeting for
>    [email-masked]
>    - [email-masked] sends out a calendar invite from their own
>    messaging client, using [email-masked] in the From: field
>    - The resulting message uses [email-masked] in the friendly
>    From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the
>    headers are no longer aligned for SPF.
>    - Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
>    - Messages like this are then rejected by receivers that validate
>    DMARC results.
>
> Whenever possible, they tell me they change the assistant's email domain
> to match the executives they support, but as people leave or change
> departments, they sometimes end up with assistants supporting executives
> across multiple different domains, so they can't ensure they always have
> the same domain.
>
> Maybe the ultimate answer for this customer and others in a similar
> situation is simply that this is a use case that can no longer be supported
> due to evolving security needs, and yet if that's the case, I thought it
> would be helpful to share a real world scenario that is currently impacted
> that isn't part of the previously existing discussion around mailing lists.
>

There are several solutions that come to mind fairly quickly considering
that this is a financial institution. Both involve a small amount of logic
and code.

The first is to DKIM sign with signatures for both domains. This involves a
relatively small amount of code and logic. Any of the MTAs I've worked with
could do this even if there are a large number of domains involved..

The second would be to always make the From and the MailFrom consistent
(keying off of the From email address) when passing through the outbound
MTAs.

Again, a little bit of logic and coding but if this is truly a significant
problem for them then it is worth the one time effort to implement either
or both of these solutions. I've done similar sorts of logic for outbound
mail on Ironport and Momentum (MessageSystems) MTAs. Any of the open source
MTAs can easily do the same. I don't view this as something a standard
needs to fix but rather something that this particular business needs to
address because they want to keep a certain business model and practices
but also want the benefits of a "p=reject" policy assertion.

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Tue, 28 Jul 2020 10:07:19 +0100

> On 28 Jul 2020, at 08:36, Alessandro Vesely <[email-masked]> wrote:
> 
>> # The resulting message uses [email-masked] in the friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.
>> #
> 

This really misses Autumn’s point. The issue she brings up may be unusual but it a lot more common than folks think. Banks, in particular, are a host of underlying problems related to DNS and security. I worked with a bank a few years back. It took 6 weeks to identify what continent the nameserver controlling DNS for the subdomain we were trying to authenticate lived on. Then there were weeks of approvals and security sign offs in order to get a DNS change made so we could correct a SPF record. 3 or 4 months to get an update done. For the record, my clients were part of the Canadian organization and the name servers handling their DNS were located in Australia. 

Autumn has presented a very real world scenario that demonstrates the overall complexity of mail management operationally. Your solution “sign with DKIM” has significant barriers to adoption. For instance, assume that there is code installed on the mailserver that will grab the 5322.from address and sign with the appropriate DKIM key. How many domains are involved? How many different mailservers? How long will this solution take to deploy? Banks do not move quickly and, for the obvious reasons, any changes to security require multiple reviews and assurances that the implications are understood.

The underlying belief with DMARC is that mail is simple, that companies are monoliths with only a few brands/domains, that it is possible to know exactly where every message will come from. These assumptions are not and have never been true. Inevitably, however, when these types of issues are pointed out, they’re dismissed with “solutions” that aren’t actually achievable or maintainable. DMARC proponents have repeatedly failed to pay attention to folks pointing out the actual operational challenges and thus have never addressed the issues in any way. This is, fundamentally, why only 15% of fortune 500 companies have adopted p=reject and why adoption rates are only increased by 5% last year. 

The indirect mail stream issue is real. But it is not the only barrier to getting to p=reject. The sooner folks start listening to the people who are presenting real issues where DMARC alignment can’t be achieved the sooner they’ll be able to address them. The problem with low DMARC adoption is that it does not adequately address how companies are using mail in ways that break the DMARC model. Almost a decade on, and proponents are still suggesting that email usage should change to comply with their model of how email works. This has not happened. Maybe proponents need to think harder about why. 

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: "Douglas E. Foster" <[email-masked]>
Date: Tue, 28 Jul 2020 15:09:02 GMT

Calender invites are a known issue, and the issue is mentioned in RFC 7960.

The exact scenario is:
User A creates a meeting and invites User B who is in a different email domain.User B forwards the invite to User C, who is in a different administrative domain than User B.  The invite is sent using User A as the sender, so the invite fails DMARC tests.
The problem does not occur if User A extends the invite to User C.
The problem does not occur if User B and User C are in the same administrative domain,on the assumption that DMARC is not checked or enforced on messages that are internal to the administrative domain.

For invitations that are relayed across administrative boundaries within the organization, email filtering exceptions should work around the problem.  If not, the organization needs a different email filtering product.

For invitations that are relayed outside the organization, the policy of the receiving domain will determine whether the message is blocked or allowed.  I would expect that most DMARC enforcers have encountered this problem and have developed a workaround to it.

Or course, this WG or a spinoff could investigate ways for cooperating MUAs, to send invites that do not encounter this problem.

As Laura Atkins said, DMARC implementation is not easy.  Nonetheless, deployment is slowly increasing, not decreasing.    It seems unlikely that DMARC enforcement will go away.

----------------------------------------
From: atyrsalvia=[email-masked]
Sent: 7/28/20 2:54 AM
To: "[email-masked]" <[email-masked]>
Subject: [dmarc-ietf] non-mailing list use case for differing header domains
Hello,

A customer of mine is a large financial services company. Like many in that field, they have acquired several other companies over the years, and now operate multiple different brands, which send email using different domains.. While many companies like this maintain one primary domain for corporate email and others only for marketing purposes, this company maintains multiple distinct domains even for corporate workplace email. 

To put it another way:
[email-masked] is organizing a meeting for [email-masked]@firstbrand.com sends out a calendar invite from their own messaging client, using [email-masked] in the From: fieldThe resulting message uses [email-masked] in the friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.Both firstbrand.com and secondbrand.com are set to DMARC p=reject.Messages like this are then rejected by receivers that validate DMARC results.

Thanks,

Autumn Tyr-Salvia
[email-masked]

---

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

On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote:
>> On 28 Jul 2020, at 08:36, Alessandro Vesely <[email-masked] wrote:

>>> # The resulting message uses [email-masked] in the friendly
>>> headers are no longer aligned for SPF. >>> #
>>
> This really misses Autumn’s point. [...]
> 
> Autumn has presented a very real world scenario that demonstrates the
> overall complexity of mail management operationally. Your solution “sign
> with DKIM” has significant barriers to adoption. For instance, assume that
> there is code installed on the mailserver that will grab the 5322.from
> address and sign with the appropriate DKIM key. How many domains are
> involved? How many different mailservers? How long will this solution take
> to deploy? Banks do not move quickly and, for the obvious reasons, any
> changes to security require multiple reviews and assurances that the
> implications are understood.

If the bank delegates a subdomain to each trusted subsidiary, each subsidiary 
could manage their keys on their local DNS and email servers.  If the bank can 
afford "relaxed" DKIM alignment, they can sign with d=local-branch.bank.example 
and From: [email-masked].  What's the risk of doing so?

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Tue, 28 Jul 2020 16:22:41 +0100

> On 28 Jul 2020, at 16:14, Alessandro Vesely <[email-masked]> wrote:
> 
>>>> From: field, but firstbrand.com  in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF. >>> #
>>> 
> If the bank delegates a subdomain to each trusted subsidiary, each subsidiary could manage their keys on their local DNS and email servers.  If the bank can afford "relaxed" DKIM alignment, they can sign with d=local-branch.bank.example and From: [email-masked].  What's the risk of doing so?

That does not address the problem Autumn brought up at all. 

laura 

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 17:59:17 +0200

On Tue 28/Jul/2020 17:22:41 +0200 Laura Atkins wrote:
>> On 28 Jul 2020, at 16:14, Alessandro Vesely wrote:
>>>> On 28 Jul 2020, at 08:36, Alessandro Vesely wrote:
>>>>> # The resulting message uses [email-masked] in the
>>>>> friendly From: field, but firstbrand.com <http://firstbrand.com>  in
>>>>> the SMTP MAIL FROM domain, so the headers are no longer aligned for
>>>>> SPF. >>>>
>> If the bank delegates a subdomain to each trusted subsidiary, each
>> subsidiary could manage their keys on their local DNS and email servers.
>> If the bank can afford "relaxed" DKIM alignment, they can sign with 
>> d=local-branch.bank.example and From: [email-masked]. What's
>> the risk of doing so? >

I understood the problem is the lack of agility.  Delegation to smaller domains 
using local servers would solve it, wouldn't it?  Even with many domains...

What am I missing?

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Jul 2020 12:05:07 -0400

On 7/28/2020 5:07 AM, Laura Atkins wrote:
>
> The indirect mail stream issue is real. But it is not the only barrier
> to getting to p=reject. The sooner folks start listening to the people
> who are presenting real issues where DMARC alignment can’t be achieved
> the sooner they’ll be able to address them. The problem with low DMARC
> adoption is that it does not adequately address how companies are
> using mail in ways that break the DMARC model. Almost a decade on, and
> proponents are still suggesting that email usage should change to
> comply with their model of how email works. This has not happened.
> Maybe proponents need to think harder about why.

Well said.

It has always been how do we scale a "Lightweight Author::Signer 
Authorization Protocol" or LASAP methodology.  Examples of LASAP are:

ATPS
TPA
Conditional Signatures

SPF offers 3rd party (associated, authorized) IP addresses and does 
not have this problem (administration aside).  The DKIM Policy Model 
since ADSP lacked the ability to authorize 3rd party domains. DMARC 
did not address the problem and reason ADSP was abandoned. Hence the 
on-going dilemma.

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

---

From: "Doug Foster" <[email-masked]>
Date: Tue, 28 Jul 2020 13:19:50 -0400

Hector, I do not understand this comment:

"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma."

Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key.    But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer.

The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request.

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2020 13:37:16 -0400

In article <[email-masked]> you write:
>  *   [email-masked] sends out a calendar invite from their own messaging client, using
>[email-masked] in the From: field
>  *   The resulting message uses [email-masked] in the friendly From: field, but firstbrand.com in the
>SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.

This sounds like an excellent use case for Dave's draft-crocker-dmarc-sender proposal.

The canonical example of different From and Sender is exactly this:
Sender is an assistant working for and sending mail for From.

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 28 Jul 2020 14:52:33 -0500

On 7/28/20 10:59 AM, Alessandro Vesely wrote:
> I understood the problem is the lack of agility.  Delegation to smaller domains using local servers would solve it, wouldn't it?  Even with many domains...
> 
> What am I missing?

It's assuming there are local servers in the mix, which is becoming less common with the shift to the cloud.  e.g, I am fairly certain that O365 doesn't have the DKIM flexibility you're talking about.

Jesse

---

From: Todd Herr <[email-masked]>
Date: Tue, 28 Jul 2020 16:13:40 -0400

On Tue, Jul 28, 2020 at 1:37 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]>
> you write:
> >To put it another way:
> >
> >  *   The resulting message uses [email-masked] in the
> friendly From: field, but firstbrand.com in the
This is also precisely the situation I asked about during the session on
Dave's sender proposal.

Using the Sender header and the "snd" bits in the DMARC policy for
firstbrand.com, DMARC would pass for the Sender domain and fail for the
>From domain.

Which verdict gets applied to the message?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

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

---

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

On 7/28/2020 1:13 PM, Todd Herr wrote:
>
> On Tue, Jul 28, 2020 at 1:37 PM John Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> This is also precisely the situation I asked about during the session 
> on Dave's sender proposal.

And it is exactly the reason RFC 733 defined two different header fields.

> firstbrand.com <http://firstbrand.com>, DMARC would pass for the 
> Sender domain and fail for the From domain.
>

DMARC is written with the view that receivers will follow the directive 
in the domain owner's DMARC record, but really the receiver has complete 
discretion, and many receivers exercise that interpretive freedom.

So the answer to your question needs to be: the receiver needs to juggle 
these bits of information and decide what action to take. It's what they 
do, anyhow.

This isn't something that has a simple, obvious answer that is always 
correct.  So leave it as a matter of receiver discretion. Especially 
since that's what it actually is.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2020 16:30:47 -0400

> Which verdict gets applied to the message?

I believe the reasoanble answer is both, and the filtering engine 
evaluates both based on their reputations.

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

---

From: Todd Herr <[email-masked]>
Date: Tue, 28 Jul 2020 16:58:28 -0400

> evaluates both based on their reputations.
Two responses, two different but equally valid answers, the other (Dave's)
being "receiver discretion", which *could* be an umbrella term to include
John's answer, but would certainly also include other applications of rules
for this scenario.

Note that I'm not at all opposed to the idea put forth in
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ but I do
believe that there will have to evolve a very limited set of known and
expected possibilities for how such messages will be handled, or else wails
will be wailed, teeth will be gnashed, and garments will be rent,
especially among those trying to do the right thing when sending email and
the deliverability people they employ.

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jul 2020 14:08:40 -0700

On 7/28/2020 1:58 PM, Todd Herr wrote:
> but I do believe that there will have to evolve a very limited set of 
> known and expected possibilities for how such messages will be 
> handled, or else wails will be wailed, teeth will be gnashed, and 
> garments will be rent, especially among those trying to do the right 
> thing when sending email and the deliverability people they employ.

Here is another case of two different answers:

1. What is done with a validated DKIM signature?  The answer is 
essentially:  lots of different things that are not specified in any 
standards document but that receivers find useful.  That's the same, 
benign answer that should be applied here.

2. There are always wails wailed, teeth gnashed, and garments rent (or 
purchased).  Worrying about that isn't ever helpful.  So don't.

d/

ps. I thought my previous answer and John's were essentially the same, 
but am fine having his treated as a subordinate case of mine.  And 
that's a view I'm fine having be applicable pretty much any time.

---

From: Autumn Tyr-Salvia <[email-masked]>
Date: Tue, 28 Jul 2020 21:11:12 +0000

To Todd's point, I think the answer on which policy would be applied at least needs to be predictable. If one receiver chooses one policy and a different receiver chooses the other policy, that is going to make it significantly more complicated for complex organizations to implement a DMARC p=reject or even p=quarantine policy.

Thanks,

Autumn Tyr-Salvia
[email-masked]

________________________________
From: dmarc <[email-masked]> on behalf of Todd Herr <todd.herr=[email-masked]>
Sent: Tuesday, July 28, 2020 1:58 PM
To: John R Levine <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains

On Tue, Jul 28, 2020 at 4:30 PM John R Levine <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, 28 Jul 2020, Todd Herr wrote:
> firstbrand.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffirstbrand.com%2F&data=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245&sdata=1AHw64v72T7eJ%2BNrnkkUsSnky%2F1H2CqV3tA1t1X0FvM%3D&reserved=0>, DMARC would pass for the Sender domain and fail for the
> From domain.
>

Two responses, two different but equally valid answers, the other (Dave's) being "receiver discretion", which *could* be an umbrella term to include John's answer, but would certainly also include other applications of rules for this scenario.

Note that I'm not at all opposed to the idea put forth in https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-crocker-dmarc-sender%2F&data=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245&sdata=6Z2zUXQD8CB14mF9Tw9bNDVb7k5dyqUAez%2BJ%2B8TPYUs%3D&reserved=0> but I do believe that there will have to evolve a very limited set of known and expected possibilities for how such messages will be handled, or else wails will be wailed, teeth will be gnashed, and garments will be rent, especially among those trying to do the right thing when sending email and the deliverability people they employ.

--

Todd Herr | Sr. Technical Program Manager
e: [email-masked]<mailto:[email-masked]>
p: 703.220.4153

[https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL]

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: Todd Herr <[email-masked]>
Date: Tue, 28 Jul 2020 17:15:23 -0400

On Tue, Jul 28, 2020 at 5:11 PM Autumn Tyr-Salvia <atyrsalvia=
[email-masked]> wrote:

> To Todd's point, I think the answer on which policy would be applied at
> least needs to be predictable. If one receiver chooses one policy and a
> different receiver chooses the other policy, that is going to make it
> significantly more complicated for complex organizations to implement a
> DMARC p=reject or even p=quarantine policy.
>
>
Yes, yes it very much will.

--

---

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

On 7/28/2020 2:11 PM, Autumn Tyr-Salvia wrote:
> To Todd's point, I think the answer on which policy would be applied 
> at least needs to be predictable. If one receiver chooses one policy 
> and a different receiver chooses the other policy, that is going to 
> make it significantly more complicated for complex organizations to 
> implement a DMARC p=reject or even p=quarantine policy. 

I'll suggest that this needs to be less a normative specification and 
more a best practices write-up.  First, as I've noted, receivers will do 
whatever they want.  Second is that I believe we don't yet know the 
better answers.  (And so, really, I don't mean a BCP, but rather a 
'considerations' doc.)

d/

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2020 17:23:24 -0400

> DMARC p=reject or even p=quarantine policy.

But it's not predictable now.  Some receivers follow p=reject all the 
time, some follow it sometimes, some follow it never (me.)

I think that in practice the situations where someone else is going to 
resign your mail with a Sender DMARC policy are narrow enough that most IT 
departments wouldn't even notice.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2020 18:54:46 -0400

> John's answer, but would certainly also include other applications of rules

I think Dave and I are agreeing here.  Assume I mean reputation in a very 
broad sense.

> the deliverability people they employ.

I said to Autumn, I expect the number of people sending mail with Sender 
DMARC will be so small that the deliverability people won't notice.  And, 
of course, receivers will continue to do as they d* please, same as we've 
done for 40 years.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Jul 2020 10:49:49 +0200

> Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key.    But to obtain that authorization from the s…

It is difficult, even for smallish domains, to get a complete list of MLMs which legitimately distribute messages From: their users.

> The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request.

Right, a possible approach is to outsource trust.  If you lookup my SPF record[*] you can see an example.

Best
Ale
-- 

[*] "v=spf1 +ip4:62.94.243.226 ?exists:%{ir}.list.dnswl.org -all"

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Jul 2020 10:54:05 +0200

On Tue 28/Jul/2020 23:23:24 +0200 John R Levine wrote, quoting Autumn:
>> To Todd's point, I think the answer on which policy would be applied at least 
>> needs to be predictable. If one receiver chooses one policy and a different 
>> receiver chooses the other policy, that is going to make it significantly 
>> more complicated for complex organizations to implement a DMARC p=reject or 
>> even p=quarantine policy.
> 
> But it's not predictable now.  Some receivers follow p=reject all the time, 
> some follow it sometimes, some follow it never (me.)

I follow it sometimes, but it would be easier to follow it always.  If it were 
set up correctly, the latter would also be more reliable.

To suggest disposition, I'd add an "snd=" tag in the From: domain's DMARC 
record, having one of the following values:

*none*: Sender: field shall not be considered for messages From: this domain. 
This should be the default, for compatibility with existing settings.

*any*: Accept messages forwarded by any Sender:, provided it validates.

*/reputation domain/*: Supply a domain to be looked up for Sender: reputation. 
If Sender: validates and has a positive reputation, then accept the message.

> I think that in practice the situations where someone else is going to resign 
> your mail with a Sender DMARC policy are narrow enough that most IT departments 
> wouldn't even notice.

Except if setting Sender: to the next trash domain becomes an attack path for 
phishing.

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Wed, 29 Jul 2020 11:54:44 +0100

> On 28 Jul 2020, at 23:54, John R Levine <[email-masked]> wrote:
> 
> I think Dave and I are agreeing here.  Assume I mean reputation in a very broad sense.
> 
> I said to Autumn, I expect the number of people sending mail with Sender DMARC will be so small that the deliverability people won't notice.  And, of course, receivers will continue to do as they d* please, same as we've done for 40 years.

I’m not sure why deliverability people are even mentioned here. The problems with DMARC primarily affect one-to-one or one-to-few mails, not bulk mails. The breakage DMARC causes doesn’t really affect marketing, newsletters or anything else sent through automated systems. I mean, yeah, some folks aren’t going to get their bulk mails because of DMARC failures but mail fails all the times for lots of different reasons. 

DMARC broke how a lot of people and corporations use email as a communication medium and I, for one, welcome the attempts to finally address the fallout. I think if these issues are addressed more comprehensively you’ll see a much bigger adoption for DMARC, particularly among larger companies. 

laura 

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

---

From: Todd Herr <[email-masked]>
Date: Wed, 29 Jul 2020 08:46:44 -0400

On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins <[email-masked]>
wrote:

>
> I’m not sure why deliverability people are even mentioned here. The
> problems with DMARC primarily affect one-to-one or one-to-few mails, not
> bulk mails. The breakage DMARC causes doesn’t really affect marketing,
> newsletters or anything else sent through automated systems. I mean, yeah,
> some folks aren’t going to get their bulk mails because of DMARC failures
> but mail fails all the times for lots of different reasons.
>
>
>
Perhaps Autumn's use case and its mention of a bank that can't do DKIM
signing lead me down a path that may never be followed.

Where my mind went was to a place where an ESP was employed by a brand to
send mail, either bulk or transactional (or both), and such mail was sent
with the ESP domain as the domain in the "Sender:" field and the brand's
domain as the domain in the "From:" field (or vice versa), with each domain
publishing DMARC records. In such a scenario, it's possible that
conflicting DMARC validation results could occur, leading to the concern
over how such things might be handled.

If this is not a possible use case for these header fields, then please
accept my apologies for bringing deliverability into the discussion.

--

---

From: Laura Atkins <[email-masked]>
Date: Wed, 29 Jul 2020 15:11:55 +0100

> On 29 Jul 2020, at 13:46, Todd Herr <todd.herr=[email-masked]> wrote:
> 
> 
> 
> On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Perhaps Autumn's use case and its mention of a bank that can't do DKIM signing lead me down a path that may never be followed.

I don’t think the bank is sending mail that isn’t DKIM signed, I think DKIM signatures have the same inherent alignment failure of SPF - where the admin assistant sends out a MTA for their business unit/domain but uses the From: address of an executive of a different business unit. That MTA signs for the domain it is supposed to sign for. Possible my assumption was incorrect. 
 
> Where my mind went was to a place where an ESP was employed by a brand to send mail, either bulk or transactional (or both), and such mail was sent with the ESP domain as the domain in the "Sender:" field and the brand's domain as the domain in the "From:" field (or vice versa), with each domain publishing DMARC records. In such a scenario, it's possible that conflicting DMARC validation results could occur, leading to the concern over how such things might be handled.

There will possibly be places where folks will choose to use Sender for ESPs, but most ESPs are currently willing and able to provide alignment for their customers. I can’t really see the ESP wanting to step into the sender role here particularly when their customers are already aligned. I can also envision a situation where the ESP doesn’t want to be the sender because that may impact their legal liability and responsibilities. 

Longer term, though, this could actually be really beneficial for companies who are using ESPs but can’t, for whatever reason, align their mail at the ESP. The ESP can step in as “sender” (where sender is [email-masked]) and have that DMARC align. Right now it’s not an issue as there is no delivery hit for sending mail without a DMARC policy statement. But, if we ever get to the point where p=quarantine or p=reject is required for delivery, the ESP can handle that for their customers using the Sender: header. 

On the other hand, this would solve the problem where so many small business owners and ad hoc groups got shut out of using ESPs when Yahoo! sprung p=reject on the world. The ESP could use the Sender: field and it doesn’t matter that the mail wouldn’t align with Yahoo. I do remember hearing at one point some of the big commercial groups were including ESP outbounds in their SPF records to compensate, so this would be less overhead. 

Need to think about that a little bit because I can see some potential attack vectors. 

> If this is not a possible use case for these header fields, then please accept my apologies for bringing deliverability into the discussion.

I hadn’t thought about this for ESP mediated mail. But you have made me think a little harder about it. 

laura 

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

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Jul 2020 13:34:48 -0400

> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma."

SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.

The problem we have with DMARC was the same with SSP which was 
replaced by ADSP which attempted to ignore the problem. Generally, as 
it often done with ambiguous issues in the IETF, we ignore it, we make 
it out of scope, we keep it open ended, etc.  It just wasn't resolved 
and ADSP was abandoned but returned as DMARC but it also kept the same 
3rd party ignorance as ADSP did.   If this issue is not resolved for 
DMARC, I see an interesting situation during DMARCBis Last Call 
explaining how we abandoned ADSP for having problem XYZ and then 
reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ.

> The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request.

This issue is not about the known, but the unknown. We don't have an 
issue with proactive authorization and whitelisting methods.

I've been in this DKIM project for 15+ years, and to me, the goal has 
also been to find a reasonable, scalable deterministic protocol that 
will handle unsolicited, unknown 3rd party domain signers. Not 
necessarily unknown in a bad sense, unknown that you don't know 
anything about them. So you ask the author, "Hey, is this 3rd party 
signer ok?"

SPF allows 3rd party IP declarations.  DKIM POLICY model does not 
offer this capability.

We have DKIM Policy extension proposals like ATPS (RFC6541) that 
offers a deterministic method to associate the author domain with 3rd 
party signer domains.   This authorization is defined by the 
Originating, Author Domain.

Look at my DMARC record for my isdg.net domain:

v=DMARC1; p=reject; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];

The atps=y tells an ATPS compliant receiver that if it sees a 3rd 
party domain signature:

   Author Domain IS NOT EQUAL TO Signer Domain

Then it can do a ATPS look:

    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net

So if I wanted to authorized bayviewphysicians.com to be able to sign 
for me, I would go to the wizard 
https://secure.winserver.com/public/wcdmarc,  enter your domain in the 
list of authorized signers, click Zone Record and I get a record I can 
add to my isdg.net zone:

e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; 
d=bayviewphysicians.com;")

So anyone out there can see that I authorized bayviewphysicians.com to 
sign for isdg.net

It is really sample.

Whether we can "coerce" receivers to honor any of this is a different 
situation.  In general, all you can do create a PROTOCOL that makes 
good engineering sense and usable by the IETF community. If not, then 
generally systems will ignore it.

---

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 29 Jul 2020 21:00:45 GMT

On the issue of spoofing, only two security postures are possible in the incoming mail gateway:
We allow spoofing by default, then block problematic spoofing as detected, on a case-by-case basis.We disallow spoofing by default, then allow desired mail as needed, on a case-by-case basis.
Only the second security posture is credible in a security audit.   DMARC v1 is the most effective tool for implementing that security posture.   The proposed "new" DMARC returns us to the first security posture.

Incoming email can be divided into these categories:
Messages that have confirmed identitiesMessages that appear to be spoofing but actually contain desired content from valued senders.Messages that appear to be spoofing and are unwanted.Messages where spoofing cannot be evaluated.
Security posture 2 will be associated with these policies:
Message category 1 will be allowed or blocked on other criteria.    In particular, confirmed identity allows preferred message handling to be implemented safely.Message category 2 will be handled through the receiving organization's exception process.   Message category 3 will always be blocked.    Message category 4 may be reviewed, as time permits, to determine a local policy which moves it into category 1 or 3. 
If there are category 2 problem cannot be solved between a recipient user and his email security team, we need to document when and why this is happening, 

However, the expectation is that senders in category 2 and 4 will have incentive to move into category 1 over time.   To the extent that this has not happened, it is a great misfortune.

An excess of category 2 messages can contribute to an organization choosing to delay or abandon implementation of security posture 2.   This increases their risk.   Indirectly, category 2 messages serve to facilitate the dirty work of category 3 messages, in exactly the same way that a large enough crowd can become an enabler for looters and arsonists.

DF

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 30 Jul 2020 11:39:59 +0100

On 29/07/2020 18:34, Hector Santos wrote:
> The atps=y [...]

That works at a domain-controlled level.  But people sign up for,
and write to, mailinglists on an individual level.  Mismatch.
-- 
Cheers,
  Jeremy

---

From: Ken O'Driscoll <[email-masked]>
Date: Thu, 30 Jul 2020 12:57:14 +0100

> and write to, mailinglists on an individual level.  Mismatch.

To be fair, this thread is specifically about a non-MLM use case at an
organisational level. But, I believe that any improvements to how DMARC
might handle use cases like mailing lists will likely have to be at the
domain-controlled level for there to be any chance of widespread adoption.

>From experience, the type of organisations that are deploying DMARC (in
p=reject) are not interested in allowing individual senders to delegate
which third-parties can send on their behalf. Banks etc. don't care
about mailing lists, most have HR policies that prevent employees from
interacting on external discussion groups so it's not on the radar.
However,  the use case presented in this thread - executive assistants
sending on behalf of multiple DMARC protected brand domains - is not
that uncommon and I think a policy solution to that would be warmly
welcomed.

Ken.

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Jul 2020 08:50:17 -0400

On 7/30/2020 6:39 AM, Jeremy Harris wrote:
>> It is really [simple.]

Very true. The authoring domain will need to have a way to add ATPS 
records defining who has explicit authorizing to sign/resign on behalf 
of the authorizing domain.   This will immediately help resolve a 
number of the scenarios for Authorized Third Party Signatures.

The individual user mailing list issue continues because of the use of 
restrictive domains in a public arena where there are no controls. 
There are two ways to deal with this:

1) Domain Organization policy. Does it allow its domain users to 
freely use their corporate, company domains in a public professional 
environment?

2) The MLM supported of a DKIM+DMARC+ATPS will restrict domains that 
it can not resign.

The MLM needs to be updated to support restrictive DKIM Policy domains.

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Jul 2020 08:51:18 -0400

> that uncommon and I think a policy solution to that would be warmly

+1

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 30 Jul 2020 12:23:27 -0500

On 7/29/20 12:34 PM, Hector Santos wrote:
> The problem we have with DMARC was the same with SSP which was replaced by ADSP which attempted to ignore the problem. Generally, as it often done with ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep it open ended, etc.  It just wasn't resolved and ADSP was abandoned but returned as DMARC but it also kept the same 3rd party ignorance as ADSP did.   If this issue is not resolved for DMARC, I see an interesting situation during DMARCBis Last Call explaining how we abandoned ADSP for having problem XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ.
> 
> This issue is not about the known, but the unknown. We don't have an issue with proactive authorization and whitelisting methods.
> 
> I've been in this DKIM project for 15+ years, and to me, the goal has also been to find a reasonable, scalable deterministic protocol that will handle unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a bad sense, unknown that you don't know anything about them. So you ask the author, "Hey, is this 3rd party signer ok?"
> 
> SPF allows 3rd party IP declarations.  DKIM POLICY model does not offer this capability.
> 
> We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a deterministic method to associate the author domain with 3rd party signer domains.   This authorization is defined by the Originating, Author Domain.
> 
> v=DMARC1; p=reject; atps=y; rua=mailto:[email-masked]; ruf=mailto:[email-masked];
> 
> The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain signature:
> 
> So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your domain in the list of authorized signers, click Zone Record and I get a record I can add to my isdg.net zone:
> 
> e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; d=bayviewphysicians.com;")
> 
> So anyone out there can see that I authorized bayviewphysicians.com to sign for isdg.net
> 
> It is really sample.
> 
> Whether we can "coerce" receivers to honor any of this is a different situation.  In general, all you can do create a PROTOCOL that makes good engineering sense and usable by the IETF community. If not, then generally systems will ignore it.

I admittedly know nothing about ATPS, but I think its fundamental problem is that it authorizes 3rd parties at the domain level and that makes it not much better than SPF, just different.  

Email domains that have more than a few users don't want to authorize every potential 3rd party (converges quickly to all of them, for large/complex organizations) to sign as every user/address in the domain.  Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put every 3rd party into our domains' SPF records.  I'd essentially be authorizing most of the [legitimate] internet to use the domains.

Ironically, you'll notice some domains actually doing this via SPF record flattening and macros specifically because they do not even want to attempt to solve the 3rd party authorization problem (look at umich.edu).

On the other hand, something like ATPS might be a partial solution for the MLM header munging problem, at least for intra-organizational email leveraging 3rd party platforms.  e.g. If I authorize only mlm.wisc.edu (and not every subdomain, so aspf=r is not an option) to send as wisc.edu (and potentially all of our ~480 domains which aren't all subdomains of wisc.edu), then the MLM platform should know that it doesn't need to rewrite the From header for messages from users in those domains.

It's kind of the inverse of the ARC dillemma.  ARC is missing a mechanism to tell an Intermediary if it will be safe to *not* rewrite the From header, and the lack of having a mechanism to convey historical or intended trust means that Intermediaries will always need to munge all email, by default.

Jesse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Jul 2020 12:47:39 -0700

On Thu, Jul 30, 2020 at 10:26 AM Jesse Thompson <jesse.thompson=
[email-masked]> wrote:

> I admittedly know nothing about ATPS, but I think its fundamental problem
> is that it authorizes 3rd parties at the domain level and that makes it not
> much better than SPF, just different.
>

Translated into IETF-ese: "I have not read your document but I do have an
opinion about it..."   ;-)

Seriously though, yes, that's correct.  Note that its status is
Experimental; the goal was to see if this was a useful thing to implement
and upon which to iterate if the experiment yielded positive results.  But
I think there were only ever about two implementations.

Email domains that have more than a few users don't want to authorize every
> potential 3rd party (converges quickly to all of them, for large/complex
> organizations) to sign as every user/address in the domain.  Even if SPF
> didn't have the 10 DNS lookup limitation, I would not choose put every 3rd
> party into our domains' SPF records.  I'd essentially be authorizing most
> of the [legitimate] internet to use the domains.
>

Yes, it has this scaling problem.  Had it been shown to be effective at
dealing with the indirect mail flows issues that DMARC forced to be
front-and-center a few years later, I imagine we could've revised ATPS to
be more scalable.

-MSK

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 30 Jul 2020 15:44:20 -0500

On 7/30/20 2:47 PM, [email-masked] wrote:
> Translated into IETF-ese: "I have not read your document but I do have an opinion about it..."   ;-)

Yeah, Dave sent me that feedback too.  I was just trying to make it clear that I only have $0.02 to give, rather than trying to sound like I'm an expert on ATSP.  I'll avoid the cliche next time.

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 30 Jul 2020 15:46:37 -0500

On 7/30/20 2:47 PM, [email-masked] wrote:
> Yes, it has this scaling problem.  Had it been shown to be effective at dealing with the indirect mail flows issues that DMARC forced to be front-and-center a few years later, I imagine we could've revised ATPS to be more scalable.

I almost suggested that an address-level authorization mechanism would be useful, but that seems un-scalable for manageability reasons.

Jesse

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Jul 2020 15:52:58 -0700

On 7/28/20 2:07 AM, Laura Atkins wrote:
> The underlying belief with DMARC is that mail is simple, that
> companies are monoliths with only a few brands/domains, that it is
> possible to know exactly where every message will come from. These
> assumptions are not and have never been true. Inevitably, however,
> when these types of issues are pointed out, they’re dismissed with
> “solutions” that aren’t actually achievable or maintainable. DMARC
> proponents have repeatedly failed to pay attention to folks pointing
> out the actual operational challenges and thus have never addressed
> the issues in any way. This is, fundamentally, why only 15% of fortune
> 500 companies have adopted p=reject and why adoption rates are only
> increased by 5% last year. 
>

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.

As RFC 7489 says, "DMARC is designed to prevent bad actors from sending
mail that claims to come from legitimate senders, particularly senders
of transactional email (official mail that is about business
transactions)." If the statistic were instead, "only 15% of domains used
exclusively for transactional email publish p=reject," I'd agree that's
a statistic that should be improved.

-Jim

---

From: "Luis E. Muñoz" <[email-masked]>
Date: Thu, 30 Jul 2020 18:01:54 -0700

> 500 companies are savvy enough not to publish a policy that doesn't 

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: Alessandro Vesely <[email-masked]>
Date: Fri, 31 Jul 2020 10:06:04 +0200

On Wed 29/Jul/2020 19:34:48 +0200 Hector Santos wrote:
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
>> domains. DMARC did not address the problem and reason ADSP was abandoned. 
>> Hence the on-going dilemma."
>>
> 
> [...]
> 
> We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a 
> deterministic method to associate the author domain with 3rd party signer 
> domains.   This authorization is defined by the Originating, Author Domain.
> 
> So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I 
> would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your 
> domain in the list of authorized signers, click Zone Record and I get a record 
> I can add to my isdg.net zone:
> 

Isn't that overly complicated?  Why SHA1?  An alternative method to authorize 
3rd parties is RHSWLs, see my previous post[*].  By comparison with the above 
quote, assume we have:

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

The DMARC record at example.com:

     v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:[email-masked];

The snd=lst.rhswl.example tells a compliant receiver that if it sees a 3rd 
party authentication (either SPF or DKIM) of the Sender domain:, where:

     From: domain IS NOT EQUAL TO Sender: domain

Then it can do a right-hand side whitelist lookup:

     example.net.lst.rhswl.example

If the record exists, then example.net is authorized to send on behalf of 
example.com.

Features:

* Absence of cryptographic stuff (sha1) makes it simpler.

* A multi-domain bank (Autumn's example) can easily build its own RHSWL 
containing all and only their domains, e.g.:

   firstbrand.com.lst.mainbrand.com  IN A 127.0.0.2
   secondbrand.com.lst.mainbrand.com IN A 127.0.0.2

* Large free-email domains can build their own RHSWL so as to avoid the MLM 
problem.

* Lazy mail domains can easily point to a public RHSWL which lists almost all 
the legitimate Internet.

* Strictly transactional domains can still keep snd=none (the default).

* Experimenting domains can have p=none; snd=lst.in-progress.example; while 
they monitor aggregate reports to see how their list is doing.

Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/jQlUhE-ijiWeb1CybKy6367eVn8

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 Jul 2020 12:57:52 -0400

On 7/31/2020 4:06 AM, Alessandro Vesely wrote:
>> hector wrote:

> Isn't that overly complicated?

I don't think so, but sure, it is not 100% "Low Code."  A hash 
"calculator" is needed.

> Why SHA1?

The intent was for a lightweight hashing that won't produce long 
hashing tags or labels or subdomains. Whats the maximum length of a 
domain?

But mainly because Murray's ATPS was based off Doug Otis's TPA-LABEL 
which used the same hashing algorithm.

   DKIM Third-Party Authorization Label
   https://tools.ietf.org/html/draft-otis-dkim-tpa-label-06

Doug provided a portable C-based TPA-Label calculator source code in 
Appendix B.

ATPS was the "simpler" version of TPA-Label. TPA-label was a little 
complex for a period when it was extremely challenging in the DKIM WG 
to get a Author::Signer relationship endorsed. Remember, we were 
dealing with push back even the 1st party DNS lookup policy.

There was general agreement TPA-Label offer more scalability. ATPS was 
just simpler to plug and play, explore and test the proof of concept 
and that it did.

> An alternative method to authorize 3rd parties is RHSWLs,

Let me (re)state I believe in a "Black Box" functional design and 
engineering.  I am not stuck on ATPS.  It is about the functional 
methodology for an Author::Signer association, a "Lightweight Signer 
Authorization Protocol" or LSAP.  We had the same with LMAP 
"Lightweight MTA Authorization Protocol."  Maybe LSAP can do for 
DMARC, what LMAP did for SPF.  But imo, we need to get consensus with 
a LSAP methodology.  With consensus, a specific method can be worked out.

> see my previous post[*].  By
> comparison with the above quote, assume we have:
>
> The snd=lst.rhswl.example tells a compliant receiver that if it sees a
> 3rd party authentication (either SPF or DKIM) of the Sender domain:,
> where:
>
> If the record exists, then example.net is authorized to send on behalf
> of example.com.

Sure, again, imo, we need a BLACK BOX "LSAP" methodology to be work 
out. see below.

> * A multi-domain bank (Autumn's example) can easily build its own
> RHSWL containing all and only their domains, e.g.:
>
> * Large free-email domains can build their own RHSWL so as to avoid
> the MLM problem.
>
> * Lazy mail domains can easily point to a public RHSWL which lists
> almost all the legitimate Internet.
>
> * Experimenting domains can have p=none; snd=lst.in-progress.example;
> while they monitor aggregate reports to see how their list is doing.

Do you have a I-D? If not, why not write up the draft proposal so it 
can better reviewed and maybe even explored?

Based on discussions, it sounds this LSAP model would include author, 
signer, sender identities:

     Authorized := LSAP(Author, Signer, Sender)

This was the same idea with LMAP for SPF.

     Authorized := LMAP(IP, Domain)

In SPF, the LMAP function is called Check_Host() with arguments:

    <ip>     - the IP address of the SMTP client that is emitting
               the mail, either IPv4 or IPv6.

    <domain> - the domain that provides the sought-after authorization
               information; initially, the domain portion of the
               "MAIL FROM" or "HELO" identity.

    <sender> - the "MAIL FROM" or "HELO" identity.

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 31 Jul 2020 13:10:58 -0500

> 500 companies are savvy enough not to publish a policy that doesn't fit

I think you're right, and isn't the market indicating that there is demand for DMARC designed for other usage patterns?  e.g. Would the CEO of any of those fortune 500 companies like the idea of their personal address being spoofed?

Jesse

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2020 15:30:40 -0400

In article <[email-masked]> you write:
>I think you're right, and isn't the market indicating that there is demand for DMARC designed for other usage patterns?  e.g.
>Would the CEO of any of those fortune 500 companies like the idea of their personal address being spoofed?

I dunno. Would they like the idea of mail their assistants send out
for them being silently discarded because it's falsely tagged as being
"spoofed"?

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 31 Jul 2020 15:32:30 -0500

On 7/31/20 2:30 PM, John Levine wrote:
> I dunno.

Well, they are probably unaware when the spoofing occurs (ignorance is bliss), but I know from experience that they (people important enough to complain top-down through management) don't like being the victim of backscatter floods as a result of spoofed return-paths.  

Same for list bombing (which seems to be increasingly weaponized against our VIPs).  It isn't spoofing but list bombing seems to create a similar amount of consternation when I tell them that there's not much that can be done to prevent or mitigate it.

> Would they like the idea of mail their assistants send out for them being silently discarded because it's falsely tagged as being "spoofed"?

That's the dilemma.  They also don't like their address being changed by mailing lists, but that's what we're stuck with giving them.

I think they want their IT staff to deploy an email system and policies that work the way they would expect.  They want their organization to be seen as secure, so they don't want to be on the Buzzfeed list of Fortune 500 companies that have neglected to secure their domains with DMARC.

Jesse

---

From: "John R Levine" <[email-masked]>
Date: 31 Jul 2020 16:42:04 -0400

> I think they want their IT staff to deploy an email system and policies that work the way they would expect.  They want their organization to be seen as secure, so they don't want to be on the Buzz…

Well, that's the problem, isn't it?  If your expectations for e-mail are 
shaped by experience with paper mail and you don't realize how different 
an organization's internal highly controlled mail system is from e-mail on 
the outside, you're inevitably going to be surprised, sometimes 
unpleasantly.

I would like for us to avoid the Yes Minister Tautology: We must do 
something, this is something, therefore we must do this.

Regards,