There has been some discussion regarding often violated third-party limitations of DMARC policy. A modified version of http://tools.ietf.org/html/rfc6541 where DMARC is used to signal ATPS support rather than inclusion of 'atps' tags within the DKIM signature can offer fewer use constraints.
The underlying goal of the ATPS hash was two-fold: 1) Ensure domain_queried + domain_authorized + additional overhead is deterministically ensured not to exceed the DNS maximum message size. Otherwise, extending the message size entails complex additional steps that may not work in all cases. Such handling adds complexity, especially when hashing must still be supported, but as an option. Options should be avoided if possible to afford greater simplicity. 2) Minimize the overhead to improve DNS caching. The ATPS effort predated DMARC. DMARC is no different, in that a DMARC query is needed at a higher rate than that needed an ATPS scheme that lacks DKIM signature 'atps' tag signaling. Since DMARC is where third-party policy is applied, adding a ATPS flag within the DMARC response offers a means to allow the DMARC (From header field) domain to permit specific exceptions. For example say some social network wishes to protect users messages using DMARC while allowing participation with various third-party relay services, such as well managed mailing-lists. ATPS provides a means for DMARC domains to make explicit exceptions and to react quickly when a problem is reported. DMARC will be confronting the same IESG evaluation overhead concerns that forced the unscalable inclusion of DKIM modifications where every third-party service provider is somehow expected to know whether they have been authorized by the From domain and to then change the nature of their signature. DMARC should have an easier time justifying the DNS overhead for every message when it can offer broader protection beyond just transactional messages. I would like to thank Murray for moving this concept forward. If those implementing DMARC think the ATPS concept can reduce inevitable issues caused by third-party relay services being used by various users, I would be happy to make the necessary changes to the existing rfc6541spec. Since this specification has not been able to overcome the IESG DKIM signature tag signaling requirement, backward compatibility is certainly not an issue. My employer does extensive work in this area. If there is interest, I might be able to prevail upon them to offer vetted ATPS hash lists to assist those wanting to provide less constrained use of their DMARC domains. Regards, Douglas Otis
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
