> 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. -- Terry -----Original Message----- From: dmarc [mailto:[email protected]] On Behalf Of Hector Santos Sent: Tuesday, April 14, 2015 10:00 AM To: [email protected] Subject: [dmarc-ietf] Publishing and Registration Concerns On 4/14/2015 11:30 AM, Scott Kitterman wrote: > > There's a big difference between needing to know the outbound architecture of > your own sending (as is needed by SPF and DMARC) and needing to know which of > all the places you send mail are mediators. Sure, but first, from a protocol standpoint, it doesn't/shouldn't matter, its the same. Either the ADID publishes the information or not. Second, not every list/email application is the same, so yes, some will know and some will not. Many SPF larger domains do not know their outbound MTA, so they include many INCLUDE statements and many still have a relaxed policy. Its not causing a reject but it is waste in DNS traffic. We can't use a "scale" argument here when you have a already high wasteful scale issue with SPF. Just look at google.com. How many includes and its all for a softfail? Talk about waste. Yet, at times, I suppose most of the time, it works, with a PASS result to skip the remaining test. > You seem to think keeping a list of mediators like mailing lists is feasible > and offer a way to do it. I don't have an opinion on how good the method is > because I don't there is no way keeping a list can be done regardless of how > you store it. Its not that I believe its feasible, but that not unfeasible as well. Its all doable. We did it. The protocol is the same whether a particular site believes it can use it or not. For our signer engine, I can see it doing a @FS=SDID signature because for MLS, it makes the mail with a meta header "SIGN-THIS" telling the outbound signing engine a specific set of signing rules, i.e. like use l=0, don't hash bind the subject line, IOW, make the stream weaker. So it could be done for our product, but its code change and its weaker too. The receiver still needs to do more work. So think of the "Scaling" at all ends. For non-compliant (@FS=) receivers, we just double their verification work load, an extra DNS Key lookup, all for nothing. At scale, is that a problem? > Also, for large providers like (for example) Google Groups, you wouldn't want > to authorize them at the domain level since it's a mix of high quality wanted > groups and spam groups. You'd have to do it at the individual mail box level > to make it workable. This only amplifies my concern about scalability. We need to differentiate what we need by "scale" and everyone is different. For one of many examples, you are presuming a need for Google Groups. I don't need it, nor expect it and there will be millions of private operations domains who don't care for it either. In other words, lets not use marketing decisions to put up barriers to the general IETF technical protocol requirement to include the authorization for the ADID != SDID condition. Google is just one company and is it causing very very high waste with its soft SPF policy. This high scale, redundant waste didn't stop most people from using SPF. One day, Google will change it to -ALL perhaps. On the other hand for other companies, Yes, I believe it is very feasible and manageable. -- HLS _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
