Return-Path: <dhc@dcrocker.net>
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 4BF223A0CD9
 for <dmarc@ietfa.amsl.com>; Tue, 28 Jul 2020 06:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
 autolearn=ham autolearn_force=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 nGIIAmrQKsdL for <dmarc@ietfa.amsl.com>;
 Tue, 28 Jul 2020 06:52:54 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 204C73A0C79
 for <dmarc@ietf.org>; Tue, 28 Jul 2020 06:52:54 -0700 (PDT)
Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net
 [108.226.162.63]) (authenticated bits=0)
 by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id
 06SDtT9d009892
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
 for <dmarc@ietf.org>; Tue, 28 Jul 2020 06:55:30 -0700
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
To: IETF DMARC WG <dmarc@ietf.org>
Message-ID: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net>
Date: Tue, 28 Jul 2020 06:52:47 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/hcGZBA28Jejy9XxtsFqNplZxUxQ>
Subject: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 28 Jul 2020 13:52:58 -0000

I am not a fan of splitting documents only for an abstract sense of 
cleanliness.  There needs to be justification of improved documentation 
'cleanliness' and/or useful removal of fate-sharing -- if separate fates 
are reasonably expected.


DMARC alignment validation is a basic, mechanical process that produces 
a yes/no response.  At that level, it's comparable to the nature of a 
DKIM validation, except for the From: field domain.

DMARC "policy" is fundamentally different.  It's not that its mechanism 
isn't "mechanical" but that its semantics produce more semantic and 
operational challenges.


I think that could reasonably make it worth strongly separating them 
into two different documents, no matter has small one of the documents 
might be.



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

