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

ned+ietf@mauve.mrochek.com Thu, 17 April 2014 15:57 UTC

Return-Path: <ned+ietf@mauve.mrochek.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 177F51A01CD for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 08:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level:
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 yNPRuLNPCT7o for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 08:57:48 -0700 (PDT)
Received: from mauve.mrochek.com (unknown [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB14D1A011C for <ietf@ietf.org>; Thu, 17 Apr 2014 08:57:47 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6QWPB175C005OB3@mauve.mrochek.com> for ietf@ietf.org; Thu, 17 Apr 2014 08:52:42 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P6O0FD8M9S00004W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Thu, 17 Apr 2014 08:52:35 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01P6QWP7AI2G00004W@mauve.mrochek.com>
Date: Thu, 17 Apr 2014 08:46:53 -0700 (PDT)
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
In-reply-to: "Your message dated Thu, 17 Apr 2014 00:08:08 -0700" <833BDCD2-1157-4914-B385-C300AF33E2D4@gmail.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> <833BDCD2-1157-4914-B385-C300AF33E2D4@gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Lsid-soQhgBSyVPcL1T3SqlaPSY
Cc: ned+ietf@mauve.mrochek.com, 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 15:57:52 -0000

> On Apr 16, 2014, at 11:00 PM, ned+ietf@mauve.mrochek.com wrote:

> >> On Sat, Apr 12, 2014 at 4:35 PM, <ned+ietf@mauve.mrochek.com> 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.
> >
> > I was trying to be brief. Yes, I'm well aware that DKIM can be used in other
> > ways. This entire discussion is within the context of DMARC here. Do you
> > disagree that DMARC's use of DKIM and SPF assign additional semantics to header
> > and envelope from fields respectively?

> Murray is correct. DKIM does not create special From header field semantics. 

Actually, by requiring that the signature cover the From: field, it sort
of does. But that's beside the point. Again, I was talking about DMARC's 
use of DKIM, not DKIM usage in general.

> However, DMARC semantics are similar to those of ADSP while avoiding some
> shortcomings.
 
But both of them attach additional semantics to From:. (Not that they had
a choice; as I pointed out previously, in order to acheieve the stated
goal they have to attach the check to the identity users actually see.)

> ...

> >> Also: By "the IETF published a draft", are you talking about an RFC, or the
> >> DMARC base draft?
> >
> > The draft, of course.
> >
> >> 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.

> This disruption should be shared with the provider that has already
> enumerated 30,000 mailing-lists but made no effort to establish a means to
> verify these sources and to safely assert specific exceptions to DMARC
> alignment requirements. This ability is desperately needed before applying
> DMARC reject on user accounts.  I'll be happy to modify either ATP or ATPS to
> permit these exceptions without the need to alter mailing-list.

I'm by no means sure that ATP or ATPS is the right answer, but I certainly
agree that we need to at least try and address the situation that's been
created.

Sigh. We have a lot of work to do, don't we?

				Ned