Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
Jim Fenton <fenton@bluepopcorn.net> Fri, 02 March 2018 18:45 UTC
Return-Path: <fenton@bluepopcorn.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AAC12E8CD for <uta@ietfa.amsl.com>; Fri, 2 Mar 2018 10:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 xQ_fZdqxhSAA for <uta@ietfa.amsl.com>; Fri, 2 Mar 2018 10:45:08 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 83D4012E8D2 for <uta@ietf.org>; Fri, 2 Mar 2018 10:45:07 -0800 (PST)
Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w22Ij5ZA002398 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Fri, 2 Mar 2018 10:45:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1520016306; bh=5ZcP7yAKhQ7pUY0K1xgY59DRHHVMhD13nD+oKXzagEI=; h=Subject:To:References:From:Date:In-Reply-To; b=a5rZehw/vQKBXqVoJKsh1PHHWyR60x80F7DwnMtF5oPzBHlt6xkeQLa+82reKTB/r E/B+CKmM47czKE9WU9pXGU2VM6iHRAmH5Zzb91Uy48wkc2nifwJItq3nWTyMQhePBb YVcNdfHQIiXOQxkGjWUpWY3nFOYFpCIozPV7rlPo=
To: uta@ietf.org
References: <03d601d3aadb$1833bd00$489b3700$@smyslov.net> <e65d33c4-7156-ce55-65b7-b62bd91fb029@bluepopcorn.net> <033301d3b21e$e5aefd90$b10cf8b0$@gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <fb4d7550-bc69-0826-72d4-ed5b40ac3c73@bluepopcorn.net>
Date: Fri, 02 Mar 2018 10:45:00 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <033301d3b21e$e5aefd90$b10cf8b0$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/gTQ7rKOLq_qd5N6ZXYeTAIPN4hw>
Subject: Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2018 18:45:18 -0000
On 3/2/18 4:06 AM, Valery Smyslov wrote: > Hi Jim, > > just one comment: > >> Section 5.3 paragraph 3: "MUST match the value found in the filename" >> but the value in the filename is only a recommendation (section 5.1). I >> continue to lean toward not depending on values in other than the >> message body (single source of truth). > I believe that this section describes how the "TLS-Report-Submitter" is filled in > by sender, not how it is checked by the receiver. Section 5.6. already states > that the report body is the only authoritative source for receiver. > I agree that the current wording is a confusing and can be improved. For example: > > When constructed the "TLS-Report-Submitter" value MUST match the value in the > filename (if it is present there) and the [RFC5321] domain from the "contact-info" from the > report body. These message headers MUST be included and should allow > for easy searching for all reports submitted by a report domain or a > particular submitter, for example in IMAP [RFC3501]: My opinion is that since section 5.6 effectively says the filename (and therefore the TLS-Report-Submitter) doesn't matter because only the body is authoritative, the MUST requirements are excessive. I do see the value of the TLS-Report-Submitter header field as a convenience feature for the IMAP search usage that was mentioned, so I would say that it SHOULD match the body. I agree with Viktor's comment that the filename should be treated as an opaque string. Setting specific requirements for it only makes the protocol more brittle, and as he points out, how and whether the filename is used is implementation-dependent anyway. -Jim
- [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Valery Smyslov
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Jim Fenton
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Valery Smyslov
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Valery Smyslov
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Valery Smyslov
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Viktor Dukhovni
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Viktor Dukhovni
- Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC Jim Fenton