Subject: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 14 Oct 2020 18:17:22 +0000

During a session at M3AAWG50, one of the other participants proposed an idea where a sender could optionally send reports to a domain holder when they send messages on behalf of that domain.

Let's consider the idea that example.com has properly created SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.  And example.com has permitted ESP-A to deliver messages on their behalf, and they're properly setup in the SPF, and properly sign with DKIM.  ESP-B has no such authorization, but some entity has asked that ESP-B send messages on behalf of example.com, but is targeting a mailbox provider who does not support DMARC, nor send reports.  Both entities participate in this "Senders DMARC", and now example.com knows that ESP-A is acting properly, while ESP-B may need some contact to understand more about what is going on.  I'd suggest that the policy be separate from the receiving policy ("p=" and "ps=" (policy-senders) for example, though, that may also lend itself to "psp="), but residing in the same DNS TXT record.

This would not be meant just for ESPs, but also for MBPs/ISPs as well.

Does this sound like a reasonable idea?  Report overload?  Not a helpful data set for a domain holder?

Thank you for your time.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 14 Oct 2020 17:58:51 -0500

> Does this sound like a reasonable idea?  Report overload?  Not a helpful data set for a domain holder?

I would assume that any additional information sent to domain owners would be useful for identifying ESPs using a domain without permission or mis-configuration/drift.  It also sends a positive signal that the ESP is acting more responsibly than the ESPs that don't send the reports, which could be seen as good for business.

Permission:  Currently, with the reports we get, we already have a very good picture of which ESPs are using our domains, and we don't know why.  So, in order to make this idea more than a lateral change, I'd want to see information about who the ESP's "customer" is (or some customer ID we can reference), since with a large institution it's currently hard to figure out who these people are without drinking from the forensics firehose and inferring.  Domains that have a quarantine|reject DMARC policy would expect ESPs to not send mail as that domain unless authorized, but they've probably succumbed to the fact that it happens anyway.  So, in these respects, the idea would be an improvement especially for domains that are at p=none during the inventory phase of their DMARC deployment to help them identify who within their organization is using which ESPs.

Mis-configuration/drift:  I assume that the ESP would have to maintain a record of prior properly configured SPF/DKIM setups.  From there, the ESP could send reports indicating that something needs to be updated in the domain's DNS records.  Is that what you're suggesting?  That seems like a positive, since I assume that ESPs' customers have a hard time relaying technical information to their DNS admins.

Other scenarios, which I don't think this idea has much benefit:

1) The recipients are all local and there is a prearranged local override, and the domain owner doesn't want to authorize the ESP to use the domain in other contexts via DMARC

2) Domains that have very broken DMARC/SPF/DKIM probably aren't paying attention to the reports anyway

3) Domains that don't have a DMARC record 

4) Domains like gmail.com who can't/won't authorize every ESP at the domain-wide level.  This also applies to the org domain at large institutions, which is typically the domain that houses users, which also happens to be the domain that users want to use as a customer of an ESP.

* Could we publish something that says:  ESPs: please don't try to use this domain :-) 

Hope this helps!  It sounded like a great session.

Jesse

---

From: Masaki Kase <[email-masked]>
Date: Fri, 16 Oct 2020 08:33:33 +0900

Hello Alex,

> Does this sound like a reasonable idea?  Report overload?  Not a helpful data set for a domain holder?

With the perspective of MBPs, I imagined these 3 things:

(a) Identify the E/U’s IP address
The MBPs can receive aggregate reports and can easily identify E/U’s IP addresses. I wonder that information would be useful for EAC issues.

(b) Gather the MSAs information
Some MSAs will overwrite RFC5322.From before sending and others won’t. In the latter cases, DMARC results might be reported as “dmarc=fail” but MBPs can make sure these MSA’ behavoir or specification via aggregate reports. Hopefully, MBPs may allow to use 3rd party DKIM signatures to save the messages.

(c) Leverage “comment" field on XML
If MSAs overwrote RFC5322.From the aggregate reports could imply it, for example using “comment” or generating new field.

Best regards,

--
加瀬　正樹
  株式会社TwoFive
  103-0027 東京都中央区日本橋3-1-4 画廊ビル3F
  Mail: [email-masked]
  Tel: 03-5704-9948
  Tel: 080-9805-0025
  URL: https://www.twofive25.com

Masaki Kase
TwoFive, Inc.
[email-masked]

> 2020/10/15 3:17、Brotman, Alex <Alex_Brotman=[email-masked]>のメール:
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 19 Oct 2020 12:17:21 +0000

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Jesse Thompson
> Sent: Wednesday, October 14, 2020 6:59 PM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
>
> > During a session at M3AAWG50, one of the other participants proposed an
> idea where a sender could optionally send reports to a domain holder when
> they send messages on behalf of that domain.
> >
> > Let's consider the idea that example.com has properly created
> SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.
> And example.com has permitted ESP-A to deliver messages on their behalf,
> and they're properly setup in the SPF, and properly sign with DKIM.  ESP-B
> has no such authorization, but some entity has asked that ESP-B send
> messages on behalf of example.com, but is targeting a mailbox provider who
> does not support DMARC, nor send reports.  Both entities participate in this
> "Senders DMARC", and now example.com knows that ESP-A is acting
> properly, while ESP-B may need some contact to understand more about
> what is going on.  I'd suggest that the policy be separate from the receiving
> policy ("p=" and "ps=" (policy-senders) for example, though, that may also
> lend itself to "psp="), but residing in the same DNS TXT record.
> >
> I would assume that any additional information sent to domain owners
> would be useful for identifying ESPs using a domain without permission or
> mis-configuration/drift.  It also sends a positive signal that the ESP is acting
> more responsibly than the ESPs that don't send the reports, which could be
> seen as good for business.
>
> Permission:  Currently, with the reports we get, we already have a very good
> picture of which ESPs are using our domains, and we don't know why.  So, in
> order to make this idea more than a lateral change, I'd want to see
> information about who the ESP's "customer" is (or some customer ID we can
> reference), since with a large institution it's currently hard to figure out who
> these people are without drinking from the forensics firehose and inferring.
> Domains that have a quarantine|reject DMARC policy would expect ESPs to
> not send mail as that domain unless authorized, but they've probably
> succumbed to the fact that it happens anyway.  So, in these respects, the
> idea would be an improvement especially for domains that are at p=none
> during the inventory phase of their DMARC deployment to help them
> identify who within their organization is using which ESPs.
[Brotman, Alexander]

Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP address).  Tell the domain who is the entity responsible for attempting this delivery?  This might need to be a hash of some sort.

>
> Mis-configuration/drift:  I assume that the ESP would have to maintain a
> record of prior properly configured SPF/DKIM setups.  From there, the ESP
> could send reports indicating that something needs to be updated in the
> domain's DNS records.  Is that what you're suggesting?  That seems like a
> positive, since I assume that ESPs' customers have a hard time relaying
> technical information to their DNS admins.
>
[Brotman, Alexander]

I think this sort of data would benefit both the domain holder, but as you suggested, also the ESP.  They could aggregate their own data to show drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS guys change things that the MarComm team doesn't know about, believing they're doing the proper thing.

> 1) The recipients are all local and there is a prearranged local override, and
> the domain owner doesn't want to authorize the ESP to use the domain in
> other contexts via DMARC
>
[Brotman, Alexander]

Perhaps not, but as you alluded above, the ESP could potentially use the data to understand more about their platform.

> 3) Domains that don't have a DMARC record
[Brotman, Alexander]

It might be possible, depending how this were created, to have a "Senders DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful to the domain.

>
> 4) Domains like gmail.com who can't/won't authorize every ESP at the
> domain-wide level.  This also applies to the org domain at large institutions,
> which is typically the domain that houses users, which also happens to be the
> domain that users want to use as a customer of an ESP.
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!QcpORx5hkGoLGAIubf00VCePDChJAiXUA1dPAK64CV9ffw
> di6bRkdDFOss0mMsK_Dzh9b-CSbg$

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 19 Oct 2020 12:19:23 +0000

I think that could be reasonable.  It could make reports noisy though?

From: dmarc <[email-masked]> On Behalf Of Masaki Kase
Sent: Thursday, October 15, 2020 7:34 PM
To: Brotman, Alex <Alex_Brotman=[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

Hello Alex,

Best regards,

--
加瀬　正樹
  株式会社TwoFive
  103-0027 東京都中央区日本橋3-1-4 画廊ビル3F
  Mail: [email-masked]<mailto:[email-masked]>
  Tel: 03-5704-9948
  Tel: 080-9805-0025
  URL: https://www.twofive25.com<https://urldefense.com/v3/__https:/www.twofive25.com__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1h09MC26Q$>

Masaki Kase
TwoFive, Inc.
[email-masked]<mailto:[email-masked]>

2020/10/15 3:17、Brotman, Alex <Alex_Brotman=[email-masked]<mailto:Alex_Brotman=[email-masked]>>のメール:

Let's consider the idea that example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1jGHafzOg$> has properly created SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.  And example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1jGHafzOg$> has permitted ESP-A to deliver messages on their behalf, and they're properly setup in the SPF, and properly sign with DKIM.  ESP-B has no such authorization, but some entity has asked that ESP-B send messages on behalf of example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1jGHafzOg$>, but is targeting a mailbox provider who does not support DMARC, nor send reports.  Both entities participate in this "Senders DMARC", and now example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1jGHafzOg$> knows that ESP-A is acting properly, while ESP-B may need some contact to understand more about what is going on.  I'd suggest that the policy be separate from the receiving policy ("p=" and "ps=" (policy-senders) for example, though, that may also lend itself to "psp="), but residing in the same DNS TXT record.

Thank you for your time.

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1gAYuu9ag$>

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 19 Oct 2020 08:50:35 -0500

> I think this sort of data would benefit both the domain holder, but as you suggested, also the ESP.  They could aggregate their own data to show drift/misconfiguration.  And yes, as you also sugges…

ESPs who hash/obscure the customer ID may want to consider a special support portal for mailop->ESP questions.  It would be frustrating to be sent to front-line agents and given the stiff arm.

> It might be possible, depending how this were created, to have a "Senders DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful to the domain.

Sent to where, postmaster?

Jesse

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 19 Oct 2020 14:59:25 +0000

> From: Jesse Thompson <jesse.thompson=[email-masked]>
> Sent: Monday, October 19, 2020 9:51 AM
> To: Brotman, Alex <[email-masked]>; [email-masked]
> > Sure, I think Masaki Kase is suggesting roughly the same thing (along with
> IP address).  Tell the domain who is the entity responsible for attempting this
> delivery?  This might need to be a hash of some sort.
>
> > I think this sort of data would benefit both the domain holder, but as you
> suggested, also the ESP.  They could aggregate their own data to show
> drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS
> guys change things that the MarComm team doesn't know about, believing
> they're doing the proper thing.
>
> ESPs who hash/obscure the customer ID may want to consider a special
> support portal for mailop->ESP questions.  It would be frustrating to be sent
> to front-line agents and given the stiff arm.
>
[Brotman, Alexander]

There are likely a few ways to address supporting a hashed sender, but yes, something to consider.

> > It might be possible, depending how this were created, to have a "Senders
> DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful
> to the domain.
>
[Brotman, Alexander]

If you didn’t' want a regular DMARC policy, you still might be able to do something akin to:

_dmarc.example.com TXT "v=DMARC1 ; ps=none ; srua=mailto:[email-masked]"

So the senders maybe should not take action if the dkim/spf were not going to pass, and sender reports of such data would be send to the address specified.  They would not be creating DMARC policy for receivers at that point.

---

From: Dotzero <[email-masked]>
Date: Thu, 22 Oct 2020 07:36:43 -0400

On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.  And
> example.com has permitted ESP-A to deliver messages on their behalf, and
> they're properly setup in the SPF, and properly sign with DKIM.  ESP-B has
> no such authorization, but some entity has asked that ESP-B send messages
> on behalf of example.com, but is targeting a mailbox provider who does
> not support DMARC, nor send reports.  Both entities participate in this
> "Senders DMARC", and now example.com knows that ESP-A is acting properly,
> while ESP-B may need some contact to understand more about what is going
> on.  I'd suggest that the policy be separate from the receiving policy
> ("p=" and "ps=" (policy-senders) for example, though, that may also lend
> itself to "psp="), but residing in the same DNS TXT record.
>

In the example you give, wouldn't ESP B be just a wee bit suspicious and
see HUGE red flags that a non-validating receiver is targeted for mail
purporting to be from a domain publishing p=reject? If they were unsure and
concerned enough to want to send reports then why wouldn't they be
concerned enough to reach out to the domain owner/administrator without
such a report scheme? or to reject the customer? (Oh, leaving money on the
table, the horror!)

Either the mailstream involved is malicious, or it is not. If it's
malicious, I would expect (and have experienced) reports coming in from end
users (recipients) to customer service, abuse@, postmaster@, etc. very
quickly. This would typically be much faster than once a day automated
reports from the ESP, etc. If it's not malicious, the juice may not be
worth the squeeze.

I believe - no, know - that domains paying attention to existing reports,
logs, inbound mail to role accounts, etc. have no pressing need for
something like this. Domains not paying attention to these things are
unlikely to pay attention to these proposed reports anyways.

Michael Hammer

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 22 Oct 2020 15:22:23 +0000

From: Dotzero <[email-masked]>
Sent: Thursday, October 22, 2020 7:37 AM
To: Brotman, Alex <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex <Alex_Brotman=[email-masked]<mailto:[email-masked]>> wrote:
During a session at M3AAWG50, one of the other participants proposed an idea where a sender could optionally send reports to a domain holder when they send messages on behalf of that domain.

Let's consider the idea that example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!WRpPnINZy1oCa-DsduZY1K-8pVTWjxqRoYHuzmEMtZrT6017-LkA0grlBpECdpXgq_2D$> has properly created SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.  And example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!WRpPnINZy1oCa-DsduZY1K-8pVTWjxqRoYHuzmEMtZrT6017-LkA0grlBpECdpXgq_2D$> has permitted ESP-A to deliver messages on their behalf, and they're properly setup in the SPF, and properly sign with DKIM.  ESP-B has no such authorization, but some entity has asked that ESP-B send messages on behalf of example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!WRpPnINZy1oCa-DsduZY1K-8pVTWjxqRoYHuzmEMtZrT6017-LkA0grlBpECdpXgq_2D$>, but is targeting a mailbox provider who does not support DMARC, nor send reports.  Both entities participate in this "Senders DMARC", and now example.com<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!WRpPnINZy1oCa-DsduZY1K-8pVTWjxqRoYHuzmEMtZrT6017-LkA0grlBpECdpXgq_2D$> knows that ESP-A is acting properly, while ESP-B may need some contact to understand more about what is going on.  I'd suggest that the policy be separate from the receiving policy ("p=" and "ps=" (policy-senders) for example, though, that may also lend itself to "psp="), but residing in the same DNS TXT record.

Thank you for your time.

In the example you give, wouldn't ESP B be just a wee bit suspicious and see HUGE red flags that a non-validating receiver is targeted for mail purporting to be from a domain publishing p=reject? If they were unsure and concerned enough to want to send reports then why wouldn't they be concerned enough to reach out to the domain owner/administrator without such a report scheme? or to reject the customer? (Oh, leaving money on the table, the horror!)
[Brotman, Alexander]

That’s putting the onus on the ESP for the analysis, instead of the party that has a vested interest, the domain owner.  The reports would be automated to the domain holder.

Either the mailstream involved is malicious, or it is not. If it's malicious, I would expect (and have experienced) reports coming in from end users (recipients) to customer service, abuse@, postmaster@, etc. very quickly. This would typically be much faster than once a day automated reports from the ESP, etc. If it's not malicious, the juice may not be worth the squeeze.
I believe - no, know - that domains paying attention to existing reports, logs, inbound mail to role accounts, etc. have no pressing need for something like this. Domains not paying attention to these things are unlikely to pay attention to these proposed reports anyways.
[Brotman, Alexander]

I don’t necessarily agree.  It’s quite possible that the reports could go to an aggregator that could send a report with big red flags.  Which Postmaster gets the reports? The domain holder or the ESP, or both?  You’re relying on the recipient of the (potentially) objectionable material to know that postmaster@ even exists.  Spam reports are great as well, but this may not be a case of fraudulent messages, just a rogue marketing department.

Michael Hammer