Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

"Rolf E. Sonneveld" <> Mon, 14 April 2014 20:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B24441A0643 for <>; Mon, 14 Apr 2014 13:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 21ISWpDFUhuR for <>; Mon, 14 Apr 2014 13:54:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5DFFA1A0574 for <>; Mon, 14 Apr 2014 13:54:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3g72BR0HmPz1L8g4; Mon, 14 Apr 2014 22:54:23 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 3g72BQ5nFcz1L8cK; Mon, 14 Apr 2014 22:54:22 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89237122EAB; Mon, 14 Apr 2014 22:54:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id KhQ3FbPmiHww; Mon, 14 Apr 2014 22:54:17 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id CE5D0122E8C; Mon, 14 Apr 2014 22:54:16 +0200 (CEST)
Message-ID: <>
Date: Mon, 14 Apr 2014 22:54:16 +0200
From: "Rolf E. Sonneveld" <>
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" <>, "" <>
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090508010002030103000205"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=2009; t=1397508863; bh=pHOxCxi+zLzeHhZH80Cf43yZb9GB9Upx6WBfrarc2o4=; h=Message-ID:Date:From:To:Subject:From; b=JD32VvITdVLT9mKPu5M6Vmyy9ywYTsIWFwTfcEPC3EPKCPU9NLyb1Akf9XX9hL2Qf qwx2Gk3fO3Xc5g2cHvy+QgTgmzvubGy51OqKMAHHMdWBPChB1aReaAKN5VV4qPWgM1 W1EKo+Xrn5d6e5YJ4NOXCeL8kp4oIvH+kGRSk5wE=
DKIM-Filter: OpenDKIM Filter v2.8.2 3g72BR0HmPz1L8g4
Cc: ietf <>
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: Mon, 14 Apr 2014 20:54:31 -0000

On 04/14/2014 07:53 PM, Murray S. Kucherawy wrote:
> On Sat, Apr 12, 2014 at 4:35 PM, < 
> <>> wrote:
>     The underlying technical issue is that the two technologies DMARC
>     is built on -
>     DKIM and SPF - both attach additional/restrictive semantics to
>     longstanding mail
>     system fields. (Broadly speaking, From: for DKIM and MAIL FROM for
>     SPF.)
> Something's amiss here.  What new semantics does DKIM attach to 
> From:?  As far as I know, it only requires that the field be signed.  
> It doesn't require that it be interpreted in a particular way or that 
> it contain any particular value.
>     It goes on to discuss the use of p=reject with domains that only send
>     transactional. AFAICT there is no discussion of when *not* to use
>     p=reject, and
>     why. Nor, for that matter is there substantive discussion of
>     mailing_list,
>     and why it's not a general solution to the problems caused by
>     p=reject.
> Yes, that's useful advice for a future revision.
>     Like it or not, the IETF published a draft that defines certain
>     mechanisms
>     which, if used improperly by a large provider, cause serious
>     problems for a
>     large number of people. The text describing the consequences of
>     the use of
>     those mechansisms in the drafts is, IMO, entirely inadequate.
> It's the same document that was posted on other web sites for some 
> time, and was in use by a number of operators (including Yahoo) long 
> before it went into the datatracker.
> As it's only a draft, there's ample opportunity to make such improvements.
> Also: By "the IETF published a draft", are you talking about an RFC, 
> or the DMARC base draft?  It seems extreme to lay blame on the IETF in 
> general merely for having an open mechanism by which to post a draft 
> for all to see and discuss.  A "Request For Comment", as it were.  Are 
> you suggesting that process should be closed or moderated somehow?
>     And it's not like we didn't know. As others have pointed out, this
>     issue
>     existed in the earlier ADSP proposal. It was given insufficient
>     attention there
>     as well.
> As with any draft, its content is only as good as its contributions 
> and the reviews it got.
>     Of course the IETF can fall back on the usual excuses, including,
>     but not
>     limited to:
>         Yahoo, of all ISPs, should have known better
>         We don't tell people what to do
>         It was just a draft
>         It was never intended to be a standard
>         We're not the Internet Protocol Police
>         etc.
>     I'm sorry, but this time none of these dogs are hunting for me. An
>     attractive
>     nuisance is an attractive nuisance, and this is what the IETF has,
>     albeit with
>     the best of intentions, managed to create.
> I would add to this that, by its ultimate inaction in the face of a 
> protracted period of abuse and attempts by participants to solve that 
> problem within its procedures, the IETF has abdicated any authority it 
> may have had.

This might have been true if:

1. Yahoo _did_ solve the abuse problem and
2. the decision making process within a closed industry consortium with 
maybe less than 20 members, representing immense commercial power, could 
be compared to the process of consensus, that's being used within IETF.

Ad 1. Yahoo only solved some of the problem, for some time and only for 
themselves. But we have seen that bad guys have adapted faster than 
anyone else to new technologies:
- 90% of all mail agents show the display-name in the From field and 
with the current move towards mobile devices this percentage will likely 
further increase;
- Yahoo doesn't use the From:From construct to enable receivers to 
detect use of multiple From: fields;
- developments like EAI will help bad guys to find lookalike 
domains/cousin domains [1], [2]
Ad 2. I assume this doesn't need further explanation.