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.
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
