On 12/12/2018 8:21 PM, Scott Kitterman wrote:
If we extend DMARC with PSD and no limitations on PSO
participation, then those considerations will apply to every domain that does
not participate in DMARC (because the PSO can now get the data
Scott,
Thanks for the clarification.
Now I understand the nature of the privacy concern:
(Public) registries that publish a DMARC record will get email
traffic reports of their customers who do not publish DMARC
records.
This does indeed seem a new attack surface, since the other powers of
the registry mostly fall under denial of service rather than traffic
analysis.
So the provisions of Section 6.1 in the -psd draft are meant to ensure
that entries in the PSD registry are limited to any registry that:
adequately describes PSD policy to require domain owners to use DMARC
or that all domain owners are part of a single organization with the
PSO.
I suspect that this will have cases that prove rather more challenging
to the Expert Reviewer than one might expect -- definition of 'single
organization' can get sticky in some cases -- but still, the nature of
the requirement is clear: ensure that registry policy is documented and
targets DMARC usage explicitly.
(Small point: Given this purpose for the registry, it's probably
important for the registry's policy document to be publicly available,
but that's not stated as required.)
Hmmm...
Let me suggest a much easier hack, which differs in utility mostly by
being post hoc rather than the current draft's pre-hoc mechanism:
Require the registry to publish another DNS record, in its _dmarc
node, which a) asserts either than DMARC is required or that the subtree
is part of a single organization, and b) contain a URL to the
documentation for this.
A query for the DMARC record of the registry will also deliver this
information record. (This might be the first case in which the problem
of getting 'other' TXT records is actually a feature and not a problem...)
That makes the information public, while avoiding the considerable
overhead and problems of a new registry -- nevermind one that needs
real-time querying.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
