Re: Will mailing lists survive DMARC?

[Douglas Otis <[e-mail]>]

On Apr 29, 2014, at 10:56 AM, John Levine <[e-mail]> 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