Dear Brandon,
See comments inline:
On May 12, 2014, at 12:30 PM, Brandon Long <[email protected]> wrote:
> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis <[email protected]> wrote:
>
> On May 11, 2014, at 12:47 PM, Gabriel Iovino <[email protected]>
> 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. The exception list is something the Author-Domain feedback
processing should be able to handle with negligible effort.
DMARC Author-Domain responding to a single DNS transaction for non-aligned
domains provides two important benefits. TPA helps curb the growth of "abuse"
feedback that cooperating receivers might wish to provide. Secondly, TPA also
prevents disrupting the tens of thousands of legitimate services that might be
sending on behalf of their client and properly indicate their relationship in
the Sender header field. Of course, TPA is also able to check the List-ID to
better ensure the origination of the message. In any case, only sources that
authenticate will be granted exceptions. This could be described as a type of
federation. Think of this as circling the wagons in response to overwhelming
problems.
Regards,
Douglas Otis
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
