On May 22, 2014, at 2:03 PM, Rolf E. Sonneveld <r.e.sonnev...@sonnection.nl> wrote:
> Hi, Doug, > > On 05/22/2014 10:21 PM, Douglas Otis wrote: >> Dear Brandon, >> See comments inline: >> >> On May 12, 2014, at 12:30 PM, Brandon Long <bl...@google.com> wrote: >> >>> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis <doug.mtv...@gmail.com> >>> wrote: >>> >>> On May 11, 2014, at 12:47 PM, Gabriel Iovino <giov...@people.ops-trust.net> >>> wrote: >>> >>> > Greetings, >>> > >>> > Last week I was having a conversation with a familiar person on this >>> > mailing list and I was expressing my disappointment with the >>> > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was >>> > encouraged to share these thoughts on this list. >>> > >>> > I believe email is already broken[3][4][5][6] and DMARC "p=reject" >>> > moves us towards a position where email is "less" broken. Will there >>> > be some bumps[7] along the road? Sure but a few bumps are no reason to >>> > leave email in it's current state. >>> > >>> > I applaud Yahoo and AOL for taking the first few punches and I look >>> > forward to the day when Google and Microsoft follow their lead. >>> > >>> > Thank you for all the hard work you have done to improve the state of >>> > email! >>> > >>> > Gabriel Iovino >>> >>> Dear Gabriel, >>> >>> While email is generally abused, DMARC's intent was to better protect >>> transactional email which Yahoo may put in jeopardy. There will be a >>> forthcoming draft to allow Author-Domains a means to request restrictive >>> policies against normal user email accounts without disrupting very >>> legitimate communications. The draft places the burden of mitigating >>> disruption on those making the requests. Otherwise, it won't be too much >>> longer before even DMARC is ignored when misapplied against user accounts. >>> >>> Where can we learn more about this? >> >> An update is pending recovery of xml.resource.org/public/rfc/bibxml/. You >> don't miss it until it is gone. :^( I should have been more proactive about >> transferring reference content. >> >>> Yahoo has suffered from a lack of security permitting millions of their >>> users accounts to be compromised. A better approach would not use DMARC, >>> but would federate third-party services they can see their customers >>> employ. The federation of email, much like that of XMPP, would be an >>> effective means to exclude bad actors without breaking mailing-list and >>> other third-party email services. As it is now, it seems Yahoo only >>> protects their own mailing-list operations which really does not warrant a >>> basis for applauding such efforts. >>> >>> I feel that there is a theory that has gone around as to why AOL and Yahoo! >>> have done this, but I don't know as there has been any proof of that or >>> acknowledgement. For one, the level of hijacking we see, and the level of >>> spam I personally receive that has at least a From name of someone I know, >>> lead me to question that theory. >> >> I have notified several friends that their accounts were compromised. Most >> did not like having to change their password. >> >>> Also, unless you know otherwise, my understanding was that Yahoo Groups >>> didn't have any mitigation of DMARC policies until recently, and they >>> implemented the same (and only currently useful) mitigation of re-writing >>> the From header, and did so well after yahoo.com went to REJECT. >> >> Rewriting the From header field in itself is disruptive. This prevents >> review of prior conversations from an individual. Often you might remember >> who said something without recalling some of the details. >> >>> Also... federation across millions of servers? That seems... unlikely. >> >> Federation simply means sending servers authenticate their domain and allow >> receivers to decide whether they wish to disallow messaging from unknown >> domains. That feature is sorely missing from SMTP. In this case, it only >> comes into play for third-party servers used by users of the Author-Domain >> asserting a DMARC policy request. The scale of this is likely to be in the >> area of about 30K. > > This number of 30K has been first mentioned by Yahoo! and after that it has > been mentioned a couple of times by various people, but I have yet to see any > proof that this figure is correct. Apart from this, quoting your own mail, > you mention "[...] tens of thousands of legitimate services that might be > sending on behalf of their client [...]". Although I think TPA may have its > use for specific author/sender combinations [1], it definitely is not the > answer to the current problems, introduced by Yahoo! and AOL, when they > activated 'p=reject'. It simply will not scale enough and it remains to be > seen that the too-big-to-ignore ESPs will spend time and money on the use of > TPA, as they have their own mailing-list-like fora, which provide them > revenues. Not to mention the privacy aspects of TPA... Dear Rolf, I strongly disagree with the assumption TPA does not scale to levels needed by AOL or Yahoo. Not having TPA declare the exceptions needed, both receiving and then offering feedback will likely to involve greater levels of network resources. TPA is structured to ensure it can be supported by a single DNS transaction. This allows for effective caching so perhaps only one out of 10 queries sees an authoritative response. Can that be said for any other email protocol? DMARC is looking only at alignments from whatever method is used to validated the domain? Imagine a future where SMTP is federated using DANE. ;-) > /rolf > > [1] My company DKIM-signs mail on behalf of some customers, a proper TPA > standard that is implemented by many/most/all verifiers, would make this kind > of setup more transparent. I fully agree. Proper TPA implementations would enable major improvements to email integrity and reliability. Received good feedback indicating the draft needs major improvement. sigh. One comment was on the improvement to abstract, where I am told it now needs to be much shorter. :-( Regards, Douglas Otis
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
