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

John C Klensin <john-ietf@jck.com> Thu, 17 April 2014 07:57 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F771A0011 for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 00:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.872
X-Spam-Level:
X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSreUDTz0sWS for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 00:57:38 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3275A1A0100 for <ietf@ietf.org>; Thu, 17 Apr 2014 00:57:34 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WahCI-000A8s-Hk; Thu, 17 Apr 2014 03:57:26 -0400
Date: Thu, 17 Apr 2014 03:57:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: ned+ietf@mauve.mrochek.com, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
Message-ID: <6EF4DECC078B08C89F163155@JcK-HP8200.jck.com>
In-Reply-To: <01P6QCMYYMJ000004W@mauve.mrochek.com>
References: <53499A5E.9020805@meetinghouse.net> <5349A261.9040500@dcrocker.net> <5349AE35.2000908@meetinghouse.net> <5349BCDA.7080701@gmail.com> <01P6L9JZF5SC00004W@mauve.mrochek.com> <CAL0qLwZr=wVX6eD+yGVOaxkSy5fJbuAErTshOG+2BywUvkDfAA@mail.gmail.com> <01P6QCMYYMJ000004W@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/MPerzicgaIiBhdhkVjeL5BtE-oc
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 07:57:42 -0000

--On Wednesday, April 16, 2014 23:00 -0700
ned+ietf@mauve.mrochek.com wrote:

>> 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. 
> 
> You may think it extreme. I don't. I think the IETF's politics
> have led to  it inching closer to moral hazard territory for a
> long time, and with this incident it has stepped in it.

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.  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.

>> Are you suggesting that
>> process should be closed or moderated somehow?
> 
> 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.

>...
>> 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.
> 
> That may be your assessment. Given subsequent comments from
> other people,  mine is now that this effort was looking for a
> rubber stamp, didn't like it when that didn't happen, and
> proceeded to skirt around the edges of the process.

> With disasterous results.

Exactly.

I'm also concerned that several of these efforts represent back
door approaches to deprecating multi-hop email.  Certainly many
things are more convenient in a single hop environment.  They
would become even more convenient if all email were to be
handled by a small oligarchy of providers.  To the degree to
which one simultaneously believes in openness and privacy, those
would be very sad outcomes.

    john