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