On 4/14/15 10:12 AM, Terry Zink wrote: >> On the other hand for other companies, Yes, I believe it is very feasible >> and >> manageable. > So, maybe I'm missing something here on the idea of TPA and registration of > mailing lists (in DNS), and mentioning Google Groups and how they can figure > it out... but not every emailer controls the DNS of the domains they relay > email from. Google certainly owns gmail.com, and Microsoft owns outlook.com > and Hotmail.com, and Yahoo own yahoo.com, so conceivably they could authorize > and auto-publish something. > > But there's no way Google Apps and Microsoft's Office 365 (for example) can > publish DNS entries for all of its small, medium, and large businesses that > use its service and subscribe to mailing lists, because many times those > companies don't control the DNS for their customers. They'd (we'd) have to > get customers to update their DNS entries for every mailing list they use if > we don't have access to their DNS. Getting customers to update their DNS is > almost as pleasant as getting my teeth cleaned. > > That's what we mean when we say it doesn't scale. Dear Terry,
TPA-Label operates within its own sub-domain. This sub-domain can be delegated or use DNAME. This means this information can be handled by an organization dedicated to detecting and preventing third-party abuse. In essence, a role likely to entail sending notices to domains and ensuring problems are corrected or having their third-party provisions retracted. A function that Yahoo and AOL dumped on everyone else by (ab)using DMARC. How is the scaling issue really worse than the changes currently required for SPF? In fact, SPF often entails more DNS transactions per use. Initially I argued for APL RR rather than TXT. People were impatient and wanted something quickly kludged into every registrar system. This impatience resulted in a sizable overhead with many unused active macro script and policy features due to high error rates and why DMARC uses the logical OR of DKIM and SPF. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
