Re: [ietf-smtp] what's not a trace field

Alessandro Vesely <vesely@tana.it> Thu, 18 February 2021 15:58 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB03A13CC for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Feb 2021 07:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_DNSWL_MED=-2.3, 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 WkvBok1Isi-3 for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Feb 2021 07:58:33 -0800 (PST)
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 A5F193A13CB for <ietf-smtp@ietf.org>; Thu, 18 Feb 2021 07:58:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1613663910; bh=yds1FUFcS8EZ7xnq7J7feicYSynftCT4nfIha7RZe7w=; l=1043; h=To:References:From:Date:In-Reply-To; b=BZ2KFGO3rXoP1hIDKsE9V+cx0Dg303XecPkJ6WLYbx51bgNW2b9l5y3s2n5quJhs2 Cj8QghB5cDxnZfcDGruYf5NWhdh9OsjxLcL65KrY7V+z/1iWkKmsd+RSITcP6GkZfl TU+XY1fejmOpX+cGL3iWPFU5lUL8T0dxOaODPlIBMjCXY2AxAGdc7DCMc49fH
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.00000000602E8EA6.000034C2; Thu, 18 Feb 2021 16:58:30 +0100
To: dcrocker@bbiw.net, John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
References: <20210217225220.562696E1F35B@ary.qy> <5f987531-4d58-9dc0-54c0-845e60ac2ebe@dcrocker.net> <612894d1-89a9-eb77-20dc-1bdebe0a32e@taugh.com> <af165aa5-1858-f466-71e6-b9e8f1535e74@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <6cc4f874-7e00-ed48-b0c6-c2941a3b14e4@tana.it>
Date: Thu, 18 Feb 2021 16:58:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <af165aa5-1858-f466-71e6-b9e8f1535e74@dcrocker.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/FIPICSfdd4ZqVuL6a0Y6rXr0k1s>
Subject: Re: [ietf-smtp] what's not a trace field
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 15:58:35 -0000

On Thu 18/Feb/2021 03:56:02 +0100 Dave Crocker wrote:
> 
> I've reviewed your postings and do not find any definition of 'trace header 
> field'.  So there's nothing for the working group to consider.
> 
> Again, you appear to be insisting on inclusion of a term that has no consensus 
> definition -- nevermind one that has been published -- and no operational 
> effect on the draft.  (It's also not a wg draft.)


IMHO, SMTP identifies trace fields and Received:'s as it considers only the 
trace fields defined by SMTP.  Indeed, it provides for additional trace fields 
to be registered in the (then) future.

At any rate, a minimal improvement is as follows:

OLD:
    in a fashion similar to some fields specified in [SMTP],
    such as in Section 4.1.1.4.

NEW:
    in a fashion similar to the trace fields specified in
    Section 4.1.1.4 of [SMTP].


That doesn't imply that Delivered-To: /is/ a trace field.  Just that it should 
be treated in the same way.  (The trace attribute is not registered at IANA.)


Best
Ale
--