On Apr 29, 2014, at 10:56 AM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
What changed is that two of the largest consumer mail providers had
huge security breaches where crooks stole user info including their
address books (both admit it, no conspiracizing needed) and used DMARC
as a sledgehammer to try and mitigate the damage. I don't think
anyone is opposed to mitigating damage, but these particular efforts
had the predictable side effect of dumping costs on unrelated third
parties which AOL and Yahoo have so far done nothing to address.
Yahoo's blog admits that they are affecting 30,000 other providers, so
they know this is not a trivial problem.
Dear John,
From our experience, similar security problems affect social websites due to
poor browser plugin vetting or poor cookie management. Being highly
balkanized, no equivalent DMARC policy will likely impact social websites since
damage to privacy or security seldom become public.
No cryptographic mailing-list token or a list of trustworthy mailing-lists by
outside vendors can remedy this problem due to liability risks. Companies that
deployed p=reject against user accounts neglected serious security issues for
years. In many cases, their services are on behalf of other ISPs.
Fortunately, gmail.com has not asserted p=reject.
Redirecting responsibility by using DKIM or SPF is at the crux and the basis
for DMARC. Neither of these schemes authenticate the domain introducing the
message and ignore intended recipients. This indirection has become endemic and
makes it difficult to scale for IPv6 or to permit valid third-party services.
One viable method agnostic to verification schemes is
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 (TPA). Yahoo and AOL
can compile their needed TPA exceptions. This scheme should scale better than
other extensions in use, especially DKIM or SPF.
There will be an effort made to better generalize the TPA expired draft.
http://tools.ietf.org/html/rfc6541 (ATPS) was hostile to existing mailing-list
services and, as such, could not be deployed. Nor was it more suitable for
high volume email services. An effort to change From header fields will have
users guessing which field indicates who authored the message and in the end
will provide no benefit.
Regards,
Douglas Otis