From nobody Mon Feb 15 10:02:28 2021 Return-Path: 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 08E173A0E68 for ; Mon, 15 Feb 2021 10:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.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 cXIC9jz7lXWD for ; Mon, 15 Feb 2021 10:02:24 -0800 (PST) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 F40FB3A0E78 for ; Mon, 15 Feb 2021 10:02:23 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 98CF71E4098 for ; Mon, 15 Feb 2021 18:02:22 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-13-34.trex.outbound.svc.cluster.local [100.96.13.34]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 9F1921E4071 for ; Mon, 15 Feb 2021 18:02:20 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.13.34 (trex/6.1.1); Mon, 15 Feb 2021 18:02:22 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Keen-Interest: 1c27bba83007e29b_1613412142188_4083211865 X-MC-Loop-Signature: 1613412142188:3943870607 X-MC-Ingress-Time: 1613412142187 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 12DF422661C6 for ; Mon, 15 Feb 2021 18:02:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613412137; bh=2r/JD4upMN+00nOVRIn4kMa0+/AkerILUnA13a4mg9Y=; h=Reply-To:To:From:Subject:Date; b=S565R40TsPq3vMofe+QeI1Wy0MeR6OnE4BVoy6bri00At95/ToItq1xQBunOA65NS fqcFtnvmh776ujv3mibDTIDj/gjeidcJBvrGzv4mOnfXghFfRHtmUHN0I7D2ZAN0PR VeLbuWWN8rVlodrpopCT1mg9VCMWc+kxz+ADjbVssYm6vz3wRq6zAqYIbcfSnZvRmo ASmGkL3pILnkKsIpwN1Ytu4Jpa/vj/6Up4sXrmXBvriAqx6d7SOCi/xBZRuUhy3YeR lHLorVHQ0ZbneXTKzro1JV2CAEEGy8vh9i2JSijul+rLcM+aiPbP3Br4WVplYE++/V CpC3D6dOQhgYA== Reply-To: dcrocker@bbiw.net To: ietf-smtp From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0bc4b7fa-d461-6307-c28e-7d048e4a8b2d@dcrocker.net> Date: Mon, 15 Feb 2021 10:02:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [ietf-smtp] To trace field or not to 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\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 18:02:26 -0000 The discussion has uncovered quite a range of issues with the term 'trace header field'. For example, by my reading, RFC 5321 has conflicting use of the term. Generally, I think that I and others, have been using the term rather casually and not in conformance with its actual specification. On review of the deliveredto draft, I do not see anything that actually requires linkage to the trace construct. Whether the definition and use of the term needs fixing is worthy of emailcore consideration, but it is outside the scope of the deliveredto effort. So I've revised the relevant draft text, to decouple from explicit trace linkage. Here is the previous text:
This specification defines the "Delivered-To" trace header field, for annotating a delivery event and the address to which delivery was effected. A sequence of deliveries, such as when a message goes through multiple mailing lists, SHOULD be recorded with a series of Delivered-To: header fields. As with other trace information, each additional Delivered-To header field MUST be placed at the 'top' of the current message, per Section 4.1.1.4. Here is the revised text:
This specification defines the "Delivered-To" header field, for annotating a delivery event and the individual address to which delivery has been effected. A sequence of deliveries, such as when a message goes through multiple mailing lists, SHOULD be recorded with a series of Delivered-To: header fields. As with some other information, each additional Delivered-To: header field MUST be placed at the current 'top' of the message -- as the first header field, in a fashion for similar to some fields specified in , such as in Section 4.1.1.4. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net