Somebody always claims something (was Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists)

Dave Crocker <> Sun, 20 April 2014 20:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EFA771A0032 for <>; Sun, 20 Apr 2014 13:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VTyXR1Wgy9kP for <>; Sun, 20 Apr 2014 13:55:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C07B1A0023 for <>; Sun, 20 Apr 2014 13:55:07 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s3KKswmC016248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 20 Apr 2014 13:55:01 -0700
Message-ID: <>
Date: Sun, 20 Apr 2014 13:52:51 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: John C Klensin <>,, "Murray S. Kucherawy" <>
Subject: Somebody always claims something (was Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists)
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 20 Apr 2014 13:55:01 -0700 (PDT)
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: Sun, 20 Apr 2014 20:55:09 -0000

On 4/17/2014 12:57 AM, John C Klensin wrote:
> Indeed.  We have had warnings about where the ability of anyone
> to post anything and then claim IETF approval in external
> contexts without any fear of meaningful pushback would lead for
> a long time.  It hasn't been significantly damaging before
> because (i) we have been lucky and (ii) attempts to manipulate
> the mechanisms have come from outsiders, not insiders.  With
> DMARC, the ability to claim IETF responsibility when that is
> handy and that the IETF has no control when _that_ is handy have
> now been utilized by insiders.

We are constantly confusing someone's attempted effect with their actual 

We need to stop giving other people control over the IETF that way.

Merely by making a claim, the get us to we scurry into fearful action, 
believing we have to prevent such claims.  We are allowing them to 
conduct a denial of service attack on us.  Or rather, by us on ourselves.

 >  That comes after a history of
> the less effective approach of bringing specs into IETF WGs and
> then claiming that fundamentals cannot be changed because they
> were developed by experts in another forum.  As I think Ned
> suggested, the ADSP issue and how it was handled should have
> been another warning sign.  And, with Yahoo's move and its
> consequences (whether they anticipated them or not), we also ran
> out of luck.

With some regularity, over the decades, a large vendor or provider has 
applied a standard -- or modified it -- in a way other than it was 
designed to cover.

>> What I suggested is that we need to have a serious discussion
>> of what, if anything can be done to ameliorate the damage in
>> this case. Others have suggested that we also need to look at
>> how to prevent this from happening in the future. I concur.
> agreed.

The IETF has no leverage for preventing the independent and 
consequential actions of a large player in the market.

> I'm also concerned that several of these efforts represent back
> door approaches to deprecating multi-hop email.

Well, that's a substantive point.  And unfortunately I agree with the 
concern.  In fact, it has been impressive to see how readily some 
industry folk dismiss concerns about more complex uses of email, such as 
multi-administration handling of mail in transit.

One /can/ imagine the IETF producing a BCP about the consequences of 
applying it's technologies in various ways that change email's utility.


Dave Crocker
Brandenburg InternetWorking