Re: [dmarc-ietf] DMARC policy overrides

Franck Martin <fmartin@linkedin.com> Tue, 02 July 2013 22:22 UTC

Return-Path: <prvs=888df1167=fmartin@linkedin.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 99BC211E8107 for <dmarc@ietfa.amsl.com>; Tue, 2 Jul 2013 15:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.165
X-Spam-Level:
X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 J73KP28trm+w for <dmarc@ietfa.amsl.com>; Tue, 2 Jul 2013 15:22:15 -0700 (PDT)
Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91D11E8105 for <dmarc@ietf.org>; Tue, 2 Jul 2013 15:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372803735; x=1404339735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qUtFrk9CFyfqpGmM+ExFNr+UcVOgw1A2lwpTLfgH848=; b=kX/sbDQ5slC4Zgurx7BiihWqzMQTrUBXZHZuoAn/9c2+rrnWDk+a2186 Y5MN3iFlf+9wPk0KZogxD1A+oYX+hjiWMlG4cr6Ta9Ijo89yyNye8Nmwt n3Rm0qWQdE5KeaHOLxJquBG3iVv1K7yoeRRDbhFBcbPxB/ZE4NKMRHCCx M=;
X-IronPort-AV: E=Sophos;i="4.87,983,1363158000"; d="scan'208";a="52920424"
Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Jul 2013 15:21:57 -0700
Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 15:21:57 -0700
From: Franck Martin <fmartin@linkedin.com>
To: Scott Kitterman <sklist@kitterman.com>
Thread-Topic: [dmarc-ietf] DMARC policy overrides
Thread-Index: AQHOd1Qt4G/x1dE5/0mSwEkA7nXYtZlSPUuAgAAS0gCAAASYgIAADzqAgAAH8IA=
Date: Tue, 02 Jul 2013 22:21:56 +0000
Message-ID: <77426B543150464AA3F30DF1A91365DE53A1279D@ESV4-MBX02.linkedin.biz>
References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <CAL0qLwbYYEjrnnQby9iMFOz1Vm-Azcbu2vVXigMauED+mUwSHw@mail.gmail.com> <51D33F23.8050502@gmail.com> <1458562.mnNGVq3FHH@scott-latitude-e6320>
In-Reply-To: <1458562.mnNGVq3FHH@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.46.254]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4A136E076878E7409A9F7361823D4270@linkedin.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] DMARC policy overrides
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 22:22:19 -0000

On Jul 2, 2013, at 2:53 PM, Scott Kitterman <sklist@kitterman.com>
 wrote:

> On Tuesday, July 02, 2013 01:59:15 PM Dave Crocker wrote:
>> On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote:
>>> It seems to me that prose which spells this out, including the costs of
>>> the "override" (namely processing through to the end of DATA), is
>>> potentially a fine compromise.
>> 
>> Since the horse is possible still having some spasms, whether alive or
>> not, I'll beat it some more:  My comments are about language, not
>> technical details.  My concern is that the language many folk are using
>> can lead to misunderstanding what is inside or outside the spec.
>> 
>>> I also think it's necessary to consider some current realities.  In an
>>> architecture such as the one I use, filters operate serially on the
>>> data.  The SPF module runs ahead of DKIM, which in turn runs ahead of
>>> DMARC.  If the SPF module decides to act on a "-all" and reject the
>>> message, DMARC and DKIM simply can't happen.  DMARC, by saying SHOULD
>>> over SPF, is attempting to require that the SPF module change what it's
>>> doing.  That means, at least in my local example, that DMARC is not a
>>> pure overlay atop SPF and DKIM.
>> 
>> Right. It's not.
>> 
>> As for DMARC 'replacing' some SPF portions, yeah, it's doing that.
>> 
>> If someone thinks the text is not sufficiently clear about what is
>> specified to do or why, we know how to fix that.  As for /whether/ to do
>> it, again, one can choose to live within DMARC or...
> 
> Ah, so DMARC is what it's defined as, so by definition any suggestion that it 
> should be changed is incorrect.  Got it.  Glad we cleared that up.
> 

Scott,

There are more than 20 people that developed this spec, we reached consensus on this is the best path and we deployed it and we have not seen it should be done otherwise. Any suggestion that it should be changed is not incorrect, it needs more support than the 20 people or so behind it... 

As Barry said, review the current spec, build support and the spec will be changed.

It seems I'm flogging a dead horse here.