Re: [dmarc-ietf] Another minor contradiction in the draft specification
Scott Kitterman <sklist@kitterman.com> Thu, 18 April 2013 22:34 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 17A7421F90FC for <dmarc@ietfa.amsl.com>; Thu, 18 Apr 2013 15:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 Lv4IZYmcXFJe for <dmarc@ietfa.amsl.com>; Thu, 18 Apr 2013 15:34:36 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5538A21F90BB for <dmarc@ietf.org>; Thu, 18 Apr 2013 15:34:33 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B644D20E40D4; Thu, 18 Apr 2013 18:34:32 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366324472; bh=VF0l5KK7wNLL9G98F8LWmUjL57fPVlOrT5AEL/cuWjE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=akj5vK2COhWBXax57QEg8ulyFV8Z7LJgbYTj8LXDk95c4T4xzqI2GNfqPPtc/5LfW sQhpe/oCJYXEUWB9LlpRD0Or96uWA+giMIJa0u2lxdExyvpdILxb7GgzwMNu+tQ0yx xvzJ6zNjkFicu4W5agUW6+C5mXLJPj1BNLCrHeyk=
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 9814D20E4090; Thu, 18 Apr 2013 18:34:32 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Thu, 18 Apr 2013 18:34:31 -0400
Message-ID: <4572267.kM8dzXsS3G@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <36F7F4EB73874D229804122178606BB6@fgsr.local>
References: <36F7F4EB73874D229804122178606BB6@fgsr.local>
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] Another minor contradiction in the draft specification
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: Thu, 18 Apr 2013 22:34:37 -0000
On Thursday, April 18, 2013 11:49:35 PM J. Gomez wrote: > Hello all. > > The DMARC Requirement #7 in Section 3.4 reads: > > Message disposition requests via DMARC override those requested > by any other public mechanism. > > The old draft in its pre-IETF track ( > http://dmarc.org/draft-dmarc-base-00-02.txt ) said in the fourth paragraph > in Section 7: > > DMARC-compliant Mail Receivers MUST disregard any mail directive > discovered as part of an authentication mechanism (e.g., ADSP, SPF) > where a DMARC policy is also discovered. {R7} > > However, now the current DMARC draft ( > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > ) says in that same spot: > > DMARC-compliant Mail Receivers SHOULD disregard any mail directive > discovered as part of an authentication mechanism (e.g., ADSP, SPF) > where a DMARC policy is also discovered that specifies a policy other > than "none". {R7} > > It can be argued that both MUST and SHOULD fall into {R7}, but it is dubious > that excepting the policy of "p=none" from being subjected to either that > MUST or SHOULD makes it also fall into {R7}. The new text effectively > excepts "p=none" from Requirement #7, but Requirement #7 does not seem to > allow for that. If there's no DMARC policy (none), there's nothing to override. The change is a welcome improvement in the spec. Under the old version it wasn't possible to publish DMARC records for testing without affecting existing processing. Scott K
- [dmarc-ietf] Another minor contradiction in the d… J. Gomez
- Re: [dmarc-ietf] Another minor contradiction in t… Scott Kitterman
- Re: [dmarc-ietf] Another minor contradiction in t… Murray S. Kucherawy