Re: Yahoo breaks every mailing list in the world including the IETF's

Phillip Hallam-Baker <> Fri, 16 May 2014 14:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 89A621A0060 for <>; Fri, 16 May 2014 07:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OkxwW6XJMgSp for <>; Fri, 16 May 2014 07:17:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D68C81A002B for <>; Fri, 16 May 2014 07:17:34 -0700 (PDT)
Received: by with SMTP id f8so1032026wiw.8 for <>; Fri, 16 May 2014 07:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3kw4X3hsnWshcU/vbjQMwOpODX/QKvbezGekaNx2pKE=; b=TH308xuiSyaxMKKU36JNhMhLyDy2EEJpFtjNb+AybZ7FZwBwhDepKACp4qrxwxdODk LT1edueKmOR4raNKgJiT6SPtDyG16gBZ4qlSudyBudKksGOQRgJs+Yo8ByeggWqLAWUr npUd7vMk6tTreiPqPH0/+XkP4GYcgVE0H0TXnVoXZvz6evY1LKyYU+qC5YicBovLK1vV ehoDE5WlR8aAqLT7YPiPaA8LvgIgTALFuBc54D6CD/z41Ijjb5LjnSqnmazKMLo0Zoaj 9M869QA/akmKpokEPEIiXtBQPrVysSkQAc/+Z2k7hMZBkdYWhDWbTroFWH4OBv1TaSJ5 mf5g==
MIME-Version: 1.0
X-Received: by with SMTP id cx10mr14255297wjb.39.1400249846386; Fri, 16 May 2014 07:17:26 -0700 (PDT)
Received: by with HTTP; Fri, 16 May 2014 07:17:26 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 16 May 2014 10:17:26 -0400
X-Google-Sender-Auth: TlAaS6lz24LbDrFAxbqndxHLoHY
Message-ID: <>
Subject: Re: Yahoo breaks every mailing list in the world including the IETF's
From: Phillip Hallam-Baker <>
To: Eric Dynamic <>
Content-Type: text/plain; charset="UTF-8"
Cc: IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 May 2014 14:17:36 -0000

On Thu, May 15, 2014 at 5:12 PM, Eric Dynamic <> wrote:
> Responding to John Levine, Brian Carpenter, Sabahattin Gucukoglu and S
> Moonesamy:
> The Problem
> I have not read the DMARC protocol in detail, nor looked at any software
> provided for implementing it.
> What I have done is looked at the DNS record DMARC uses to "advertise" a
> site's DMARC policy,
> and the commentary surrounding that.
> >From what I can tell, DMARC is not a very clever protocol.
> What it appears to do, relative to a sending site X, is say
> "Sending site X uses SPF or DKIM or both or neither, in order for you the
> recipient to verify whether X
> actually sent the email you're currently inspecting."
> If that is ALL that DMARC does, I would suggest DMARC is a worthless
> protocol and that it should be
> suppressed and rescinded as an IETF-recognized protocol.
> Why? If a receiving site cares to combat spam, it will be using SPF and DKIM
> already; there is no
> point for an extra protocol on top to say simply "yes, I the sender did
> implement SPF and/or DKIM,
> so /you should/ proceed to use those methods to validate email claiming to
> come from my domain."

Well you don't understand the problem then.

The receiver can verify SPF or DKIM but has no way to know if the
reason that those marks are not present is because

1) The legitimate sender never uses them
2) The legitimate site sometimes does not use them
3) The legitimate site uses them but the mail went through a remailer
that stripped them
4) An authorized user of the legitimate site sent their mail another way
5) The mail was sent by a malicious actor

DMARC gives the receiver more information, that is all. Specifically
it allows cases 1 or 2 to be distinguished from 3, 4, 5.

That isn't breaking anything. Things will only break if recipients
behave cluelessly and fail to account for the possibilities 3, 4,5.

Now I for one don't actually care about 4. I know that many people in
the IETF think it is their right to send any mail they like from any
mail on the Internet without the domain name owner being involved. But
as with the folk who think that you can be part of a high technology
movement and use 1980s technology I laugh at them when their messages
get thrown into the bit bucket.

The general principle for interpreting DMARC records should be the following:

IF mail is sent from a domain that advertises DMARC policy, then the
message MUST either

* Have authentication from the purported sender establishing that it
is legitimate
* Have some other form of authentication that establishes it is not spam.

I don't think it an imposition for every mailing list to be required to

1) Use the standard indication that it is a mailing list remailer
-RFC2919 came out 13 years ago

2) Authenticate all its messages

And note that 2 is simply a corollary of the existing fact that that
if your messages are not authenticated then they are going in the bit

Now as with all security policy, there are two reasons people complain

1) They don't understand the purpose of the policy
2) They want to continue to do the thing the policy prohibits

So we have always had a lot of chatter about anti-spam technologies
that comes from spammers and scum that they pay to shill on lists.
Quite a few of the nastiest people on the old ASRG list were being
paid by spammers to disrupt.

But there are also people who want to be able to send mail from their
home connection without going through their employer's email relay.
Well tough nouggies. That is what the publishers of the DMARC policy
want to prevent so take it up with your employer or find a new
employer or do your IETF mail on another email account.

The fact that spammers pay people to disrupt anti-spam work makes that
type of effort incompatible with a consensus based standards process.
So I really don't fault people for going outside IETF when their work
has been disrupted.

The only way to proceed with work in a consensus based process that
might be subject to that type of obstruction is to keep open the
option of proceeding outside the consensus process if disruption

You have to be prepared to sometime bang the shoe on the table.

My understanding of the original decision to kill the IETF mail sender
authentication policy was that it was not being used. I therefore
backed the proposal to clear the ground for a proposal that might