I think that could be reasonable. It could make reports noisy though? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Masaki Kase Sent: Thursday, October 15, 2020 7:34 PM To: Brotman, Alex <Alex_Brotman=40comcast....@dmarc.ietf.org> 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 <Alex_Brotman=40comcast....@dmarc.ietf.org<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
