Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin

Scott Kitterman <sklist@kitterman.com> Tue, 02 July 2013 03:41 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6F21F8D10 for <dmarc@ietfa.amsl.com>; Mon, 1 Jul 2013 20:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRTVaSH2Br1w for <dmarc@ietfa.amsl.com>; Mon, 1 Jul 2013 20:41:26 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6566D21F8C20 for <dmarc@ietf.org>; Mon, 1 Jul 2013 20:41:26 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A88D20E40EA; Mon, 1 Jul 2013 23:41:25 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372736485; bh=70dDjgSMktT4VdYeojv+Ynvs/x1YA+W6p5nfjMmWXus=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JaZQ4HtK7sSjR1OysOo16fHhfDro7SC3dOmssoePbDu07rWdSuVc5dIU70pDd2NDL YMeQ/owuimNekQmmiCfsdiq+6CnEqyICWYaFWP7SVHwxVljDg0d5x34LwsPfwzLd7/ iMAAUUc8miY0cKT6NwCBbgSTIN0h9DhsMj8lPTgs=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 722D420E407C; Mon, 1 Jul 2013 23:41:24 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Mon, 01 Jul 2013 23:41:24 -0400
Message-ID: <2386009.gcBsi9JlR4@scott-latitude-e6320>
User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; )
In-Reply-To: <51D23F1E.4090302@gmail.com>
References: <20130630221443.71098.qmail@joyce.lan> <6935780.Ol8a9WOpun@scott-latitude-e6320> <51D23F1E.4090302@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 03:41:31 -0000

On Monday, July 01, 2013 07:46:54 PM Dave Crocker wrote:
> On 7/1/2013 7:40 PM, Scott Kitterman wrote:
> > On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote:
> >> Let me repeat:  better writing; no technical changes.
> > 
> > I disagree.  I've been saying repeatedly that I think that the policy
> > overrides are a layering violation that should be removed.  They are bad
> > design.
> 
> Yes you have.
> 
> And where is the community constituency that supports that view?

How many experts on the policy mechanism DMARC wants to mess with are involved 
in the discussion?  So far, DMARC is pretty much a self-licking ice cream 
cone.  To claim the lack of broad community support for a particular change is 
a reason not to seek broad community review seems like a bit of a catch 22.

> > I'll add to that that having watched senders try to interpret XML reports
> > they receive from different providers and understand the subtleties
> > between them that while the mechanics of the XML schema are there, the
> > semantics are not clear enough to provide for interoperable
> > implementations.  Even among implementers who have worked together in
> > dmarc.org to develop the schema, there are inconsistencies.
> 
> Not sure what you are suggesting, as technical work, for the reporting
> mechanism.  I also missed the demonstration of community interest in
> those changes, ideally on this list.

Since this is the first time I've mentioned this particular point, it's not 
surprising there isn't much feedback on it.  You don't ask for anything here 
that wouldn't require time travel.

> > I don't think there is anything in the two issues about that would force
> > existing implementers to make changes, but I think that they are not
> > purely
> > editorial either.
> 
> Sorry for my confusion, but I don't know how to classify the changes
> that you seem to be calling for.

I'm' sorry too.

Scott K