On Jun 6, 2014, at 10:50 AM, Murray S. Kucherawy <superu...@gmail.com> wrote:
> To answer Stephen's question, I'm guessing you're referring to ATPS (RFC > 6541), use of CNAME to point to an externally-posted key, and a key exchange > where an operator give a third party a signing key. If there are others, I'd > like to know what they are. > > All three would require the Yahoo!s and AOLs of the world to grant signing > keys, signing key aliases, or ATPS records to every domain that might re-send > their mail. There are some obvious issues with such solutions: (a) users > will have to register every list to which they subscribe and wish to post; > (b) they will have to automate DNS updates because every new entry into that > registry will require a new DNS entry; and (c) if any of those third parties > gets compromised, it's a big problem for the domain trying to protect itself. > If any bit of this fails (and I suspect (a) is actually the bigger problem), > they don't work. Dear Murray, Unlike ATPS, TPA-Label does not expect users to register which lists they use. TPA-Label avoids transparent authorization techniques such as the exchange of private key information which ensures all involved domains remain apparent. Publishing public keys as belonging to a domain not controlling the corresponding private key puts that domain at unreasonable risk. Nor does TPA-Label require specific cooperation of third-party services. Many of these third-party services are offered without renumeration. Services involved can be obtained via DMARC feedback compared against lists of outbound domains. ATPS created several unnecessary deployment problems not found in TPA-Label. Updating the TPA-Label zone should be automated to better permit abuse mitigation. For this feature, TPA-Label allows such zone generation to be maintained as a service by a different entity when needed. DMARC seeks cooperation of receivers to assist in protecting their recipients by way of message rejection together with domain feedback for alignment failures. Reject when appropriate has several advantages. It helps retain the integrity of email delivery. It clearly signals to the sender a message is not wanted which should escalate to a better review when frequent. For such requests to remain honored, domains making DMARC requests MUST offer information that ensures: 1) Legitimate and compliant use of email is not disrupted. 2) Users' private exchanges being found in DMARC feedback is minimized to the greatest extent possible. 3) At least Sender header fields should be able to offer alignments, perhaps by way of a TPA-Label specific exception. To help improve the present state of trust, Original-Authentication-Results (OAR) will be added as an optional authorization requirement. This option might help mend fences following events of abuse. TPA-Label is akin to a highly extensible SPF based on validated domains rather than IP address lists. Whether it is understood by those deploying DMARC, most mitigation of email abuse occurs as a result of automated zone generation. TPA-Label has a significant advantage over that of real-time block lists, it unblocks. As such, it should be less afflicted by DDoS attack. Regards, Douglas Otis
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
