Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Dotzero
Sent: Thursday, October 22, 2020 7:37 AM
To: Brotman, Alex
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex
mailto:40comcast@dmarc.ietf.org>>
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.
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
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex 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 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
>
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: Jesse Thompson > Sent: Monday, October 19, 2020 9:51 AM > To: Brotman, Alex ; dmarc@ietf.org > Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports > > On 10/19/20 7:17 AM, Brotman, Alex wrote: > > 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. > > >> 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. > > Sent to where, postmaster? [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:sender-repo...@example.com; 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. > > Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
On 10/19/20 7:17 AM, Brotman, Alex wrote: > 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. >> 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. Sent to where, postmaster? Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
I think that could be reasonable. It could make reports noisy though?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Masaki Kase
Sent: Thursday, October 15, 2020 7:34 PM
To: Brotman, Alex
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
Hello Alex,
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?
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: k...@twofive25.com<mailto:k...@twofive25.com>
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.
k...@twofive25.com<mailto:k...@twofive25.com>
2020/10/15 3:17、Brotman, Alex
mailto:Alex_Brotman=40comcast@dmarc.ietf.org>>のメール:
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!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.
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
___
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!QWJauStjgpDV-zue3ZRr4QLtuz6W-O4wmtAOR47h41f0TnTpq73FyQqV0wWUUJ56T1gAYuu9ag$>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Jesse Thompson
> Sent: Wednesday, October 14, 2020 6:59 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
>
> On 10/14/20 1:17 PM, Brotman, Alex 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 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?
>
> 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.
> 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
[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
Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
Hello Alex,
> 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?
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: k...@twofive25.com
Tel: 03-5704-9948
Tel: 080-9805-0025
URL: https://www.twofive25.com
Masaki Kase
TwoFive, Inc.
k...@twofive25.com
> 2020/10/15 3:17、Brotman, Alex のメール:
>
> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
[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.
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
