On 4/14/15 10:47 AM, Murray S. Kucherawy wrote: > On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink <tz...@exchange.microsoft.com> > wrote: > >> 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. > ...and remove entries when one of them stops using a mailing list. And for > all we know this might happen with such scale that it begins to affect DNS > caching of other useful data. >> That's what we mean when we say it doesn't scale.
I have a fair amount of experience with this approach, since we published more than 1 billion resource records having 300 second TTLs without issue. DNS scales as will the scheme being proposed. Often these zones are limited to queries from MTAs given their own resolvers. What is being currently described represents orders of magnitude smaller deployments. It represents work that everyone wants to avoid. Clearly they don't care about third-party services and don't think email should have ever accommodated the role of Sender. > Right. And since the largest problem is with the largest operators > (because they have the biggest impact), a solution they aren't likely to > adopt is probably a waste of precious working group resources. > > It's not "marketing" to decide to abandon a protocol that nobody will > actually use. Rather, it's a highly pragmatic engineering (and working > group) decision. The problem we currently have today was born out of pragmatic reactions by the largest providers. Lets not waste time on measures unable to safely repair the damage, even when it means the community as a group must now carry the burden forced upon them. I don't think anyone has seriously considered the complexity related to publishing easily exploited DKIM signatures as if malefactors won't exploit such quick fixes published on mailing-lists. In the meantime, I'll soon post another alternative for dealing with DMARC. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
