Re: [dmarc-ietf] Trac #6 - Normative filename construction

Alessandro Vesely <vesely@tana.it> Fri, 13 August 2021 17:17 UTC

Return-Path: <vesely@tana.it>
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 3EDDA3A1FD0 for <dmarc@ietfa.amsl.com>; Fri, 13 Aug 2021 10:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 NJvIfFe4eC9E for <dmarc@ietfa.amsl.com>; Fri, 13 Aug 2021 10:17:20 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 6C1373A1FCE for <dmarc@ietf.org>; Fri, 13 Aug 2021 10:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1628875034; bh=VzCqprVScHjwlgBsk1VSigNL2yXSDPVddHn6Ze7Ru94=; l=883; h=To:References:From:Date:In-Reply-To; b=AtCpAYW1acWXS5A0RI1DqDoKkNZ8+oqrXySudLKIlAc3oqaoBSKCMs7dJ2is8eiGl dN9TFA/tj3hjWPsz3FSM1v3Mh2HefGh8LlnB7cVUALPMO1YcchHTfw8gfaJ/qL9rxB SH9LQFOmOdD+bTordsExOWV/BGJPBxLyTZECklKBEHkbzKceha1Jge1oYTcpi
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [192.168.1.103] ([2.198.14.129]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000006116A91A.000002F9; Fri, 13 Aug 2021 19:17:14 +0200
To: dmarc@ietf.org
References: <MN2PR11MB4351F0CB15A7B1AF231060E1F7F99@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <26ca66b1-0fd0-e8cb-a593-f934c6952f38@tana.it>
Date: Fri, 13 Aug 2021 19:17:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB4351F0CB15A7B1AF231060E1F7F99@MN2PR11MB4351.namprd11.prod.outlook.com>
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/8L1ME2ct4etpSKlIdnYawlISsw8>
Subject: Re: [dmarc-ietf] Trac #6 - Normative filename construction
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: Fri, 13 Aug 2021 17:17:26 -0000

On Thu 12/Aug/2021 22:26:57 +0200 Brotman, Alex wrote:
> https://trac.ietf.org/trac/dmarc/ticket/6
> 
> Folks,
> 
> I'd like to get a bit of feedback on this one. I realized I'd changed this to a SHOULD, which doesn't really address the "fuzzy" complaint.  Seems like the proper thing to do is make this a MUST, though I'd be interested in opposing thoughts.  Instead of "The filename SHOULD be constructed using the following ABNF:", it would be convert to a "MUST be constructed".


I'd raise to MUST the media type, but leave the filename at SHOULD. 
The MUST can be limited to the components, so that the same content 
results in identical filenames.

I'm not sure the filename is required for interoperability.  Do report 
consumers rely on the filename or on the values contained in it?  What 
do they trust if they differ?  (Do they even compare them?)


Best
Ale
--