From nobody Mon Aug 2 12:18:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7F3A17AE for ; Mon, 2 Aug 2021 12:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=fastmail.fm header.b=ANexw8Vm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FUTo6ldZ 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 n_WmKz0O1UcC for ; Mon, 2 Aug 2021 12:18:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD03D3A17B0 for ; Mon, 2 Aug 2021 12:18:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0F0335C0175; Mon, 2 Aug 2021 15:18:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 02 Aug 2021 15:18:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:content-transfer-encoding:from:mime-version:subject :message-id:references:in-reply-to:to:date; s=fm3; bh=iKsAYBj7pX VLyed92ArgEJdSFaviEiVQgGnBOshTq/I=; b=ANexw8VmeSGKsrXlqcVUo4nnQP cwcK99Bfxo8IiCSIdYxPmIYeiEuQS4fO/JsmRSbrxRzKdEnGBYohr5GwQJNP78+L GERCnTTUW8x8l0IJ1lLDRCYpN5AYvC/YX4IzHSVfVUvy8lZtsi4GjxLgb2kFGiIr vj3Z9lhEX6n03f5PPiXjh3FF3kFTUR56iDutofgbyk2GFS5mcJ4AuRcHNxdZB86I IIceoziAy79kOZwSZl2iAjO47FaOaUCN3w/qvbGjRPToCd2EvBepyAg7s8VPbpkC YuOUyeIRvN6wz9q9PqEzWoQE5Rgvc0/U7dZh6jusGkAtqHuZat9hyRjjbUGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=iKsAYBj7pXVLyed92ArgEJdSFaviEiVQgGnBOshTq /I=; b=FUTo6ldZv2TJZuuHwdhXP9UJytNRrieuxl3qbkquk8c/RekhsecWZd51O ly15ASRZuPC3njG2SzSjImhJEaTrOxbYDdJs95w/YFiG3OMog0ZBRQWC3YclP5oX u0ePkrjhzYZIrYRXC25CoE/2D1AILssImyNZ8XDYAmJqht+dTkRfOmrCL42TYTob dn9IG/3AjV8VxGkykfex1BBXznu18nMGV9E+FIR7TzrVSgOBhmLi8CBSAkHnPsbq oT+aVbBHcNLjsCBFXhc2PjD42BrE/8w7VMDowIsBRMgCOjpA2xiEwbXHVqQRLMK3 FHTxO6kb4Mea2AcHj66AqwS2y5c+w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtgffhggfukfhfjgfvfffosehtqh hmtdhhtdejnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhn ihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeekheevjeeuge ehhfehudehgffgvdethfdvvddufeekhfelhfdtgfegffevffetteenucffohhmrghinhep ihgrnhgrrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhf mh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Aug 2021 15:18:47 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Alexey Melnikov Mime-Version: 1.0 (1.0) Message-Id: <9FA3223C-A663-481C-9E97-E4E82ADBD02D@fastmail.fm> References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> In-Reply-To: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> To: emailcore@ietf.org Date: Mon, 2 Aug 2021 20:18:45 +0100 X-Mailer: iPad Mail (18F72) Archived-At: Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 19:18:55 -0000 Dear all, Looking through this thread I don=E2=80=99t see any obvious conclusion or co= nsensus. Possible options to move forward: 1) Postpone this ticket till later (after rfc5321bis/rfc5322bis are done), a= s suggestions to alter existing IANA Header Fields registry is not going to b= e feasible as is, as needs coordination with other users of the Header Field= s registry. I think this will take months. It might be worth doing eventuall= y, but I don=E2=80=99t have enough patience to drive this at the moment. (Th= is option might end up being =E2=80=9Cno change=E2=80=9D.) 2) Carry on and try to produce some example entries under the latest proposa= l (see below). Hopefully this will clarify the intent. 3) Scale down the proposal to only register trace header fields. Information= about MSA/MTA/MDA would probably go, but can be added as a comment. Anybody would like to speak in favour options #2 or #3? Best Regards, Alexey > On 23 Jul 2021, at 13:22, Alexey Melnikov wrot= e: >=20 > =EF=BB=BFDear WG participants, >=20 > I would like to get closure on this ticket, which was briefly discussed on= the mailing list and also during IETF 109 & 110. Below is a updated strawma= n text: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Add to the IANA Considerations of rfc5321bis: >=20 > IANA is requested to create a new subregistry for email header fields that= can be added to a message header section by a MSA/MTA/MDA. The new subregis= try would show whether a header field can be added by a "message submission"= , =E2=80=9Crelay=E2=80=9D, =E2=80=9Cdelivery=E2=80=9D system or some combina= tion of them. Headers appearing in this subregistry SHOULD also be registere= d in > (= whether it is registered as a Permanent Message Header Field Name or as a Pr= ovisional Message Header Field Name). The registration template has the foll= owing fields: >=20 > 1) Name of the header field name >=20 > 2) Can be added by an MSA? >=20 > 3) Can be added by an MTA? >=20 > 4) Can be added by an MDA? >=20 > 5) Optional reference field that points to one or more document describing= the header field. >=20 > 6) Optional comment >=20 > Registration policy for this new subregistry is =E2=80=9CExpert Review=E2=80= =9D. Designated Experts should only check correctness of the information in t= he registration template without passing any judgement on usuability of a sp= ecific header field being registered. >=20 > Updates to existing entries undergo the same process as registration of ne= w header fields. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Let me know your thoughts. >=20 >=20 > Best Regards, >=20 > Alexey >=20 >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Mon Aug 2 17:00:54 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235F13A2202 for ; Mon, 2 Aug 2021 17:00:45 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 EqWYyeEtrvZr for ; Mon, 2 Aug 2021 17:00:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 91CE23A21D8 for ; Mon, 2 Aug 2021 17:00:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S24XW6DJQ800F39C@mauve.mrochek.com> for emailcore@ietf.org; Mon, 2 Aug 2021 16:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1627948536; bh=Bs2s8cn3jt3WbxOAgHjahUAB4SaKtaxWIsmW8SX/Gfc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=VpVQyoztdHYQXsZAouYKB4h2TGqpu3i5CBOBRzudvj9ayZzhDZkfsG1FWXBIOedXy ZuKcg+e/eR0G5nPb0rt8JO1HfCzLzXUbyKnIiZBBoF9wQgUjcsrawfN3xli/6+7u1Z hg6PTzLzXJbWv2ORSu5GCukMDjkjkDeijyJBWBHY= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Mon, 2 Aug 2021 16:55:34 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S24XW4Y5P6005PTU@mauve.mrochek.com> Date: Mon, 02 Aug 2021 16:44:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 02 Aug 2021 20:18:45 +0100" <9FA3223C-A663-481C-9E97-E4E82ADBD02D@fastmail.fm> References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> <9FA3223C-A663-481C-9E97-E4E82ADBD02D@fastmail.fm> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 00:00:45 -0000 > Dear all, > Looking through this thread I don’t see any obvious conclusion or consensus. I disagree with this assessment. I think there's consensus that creating a separate header field registry just to document this piece of information is a bad idea. I also predict that if you ask the question directly, there's a consensus that this doesn't belong in RFC 5321bis. I don't think there's a consensus on anything else. This leaves us with three paths forward: (1) Abandon the idea of gathering this information somewhere entirely. (2) Recast the idea as an optional additional information item to be gathered as part of registering header fields. Note that this can be presented as a separate table on the web page if having an email-specific column in the current table is deemed to be too confusing. (3) Your (3). Your (3) actually brings up an additional point - it's arguably more important to note whether or not a given field is a trace field in the registry than it is to document where it's supposed to be inserted. Right now tracking down all the trace fields is a real PITA. Ned > Possible options to move forward: > 1) Postpone this ticket till later (after rfc5321bis/rfc5322bis are done), as suggestions to alter existing IANA Header Fields registry is not going to be feasible as is, as needs coordination with other users of the Header Fields registry. I think this will take months. It might be worth doing eventually, but I don’t have enough patience to drive this at the moment. (This option might end up being “no change”.) > 2) Carry on and try to produce some example entries under the latest proposal (see below). Hopefully this will clarify the intent. > 3) Scale down the proposal to only register trace header fields. Information about MSA/MTA/MDA would probably go, but can be added as a comment. > Anybody would like to speak in favour options #2 or #3? > Best Regards, > Alexey > > On 23 Jul 2021, at 13:22, Alexey Melnikov wrote: > > > > Dear WG participants, > > > > I would like to get closure on this ticket, which was briefly discussed on the mailing list and also during IETF 109 & 110. Below is a updated strawman text: > > > > =============== > > > > Add to the IANA Considerations of rfc5321bis: > > > > IANA is requested to create a new subregistry for email header fields that can be added to a message header section by a MSA/MTA/MDA. The new subregistry would show whether a header field can be added by a "message submission", “relay”, “delivery” system or some combination of them. Headers appearing in this subregistry SHOULD also be registered in > (whether it is registered as a Permanent Message Header Field Name or as a Provisional Message Header Field Name). The registration template has the following fields: > > > > 1) Name of the header field name > > > > 2) Can be added by an MSA? > > > > 3) Can be added by an MTA? > > > > 4) Can be added by an MDA? > > > > 5) Optional reference field that points to one or more document describing the header field. > > > > 6) Optional comment > > > > Registration policy for this new subregistry is “Expert Review”. Designated Experts should only check correctness of the information in the registration template without passing any judgement on usuability of a specific header field being registered. > > > > Updates to existing entries undergo the same process as registration of new header fields. > > > > =============== > > > > Let me know your thoughts. > > > > > > Best Regards, > > > > Alexey > > > > > > -- > > Emailcore mailing list > > Emailcore@ietf.org > > https://www.ietf.org/mailman/listinfo/emailcore > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Thu Aug 5 09:38:37 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21F83A18C6 for ; Thu, 5 Aug 2021 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=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 (2048-bit key) header.d=fastmail.fm header.b=w/JIrUKB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o8MDHd4S 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 q0hQuhFZVWqH for ; Thu, 5 Aug 2021 09:38:29 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836AC3A18C4 for ; Thu, 5 Aug 2021 09:38:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 748335C007B; Thu, 5 Aug 2021 12:38:28 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Thu, 05 Aug 2021 12:38:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=f6S61 a6KKb5Kyy0w0nKzG5D8nvftKst3i4j74whbauY=; b=w/JIrUKBaDhNhmP7XyJbb tLxse3CXMB+z2pEhdMW/4SZR8da95wOUqv6oqynYDg3Jta7INL+FZRYJOQLLsOKV U0kjCtxeWbJxSJiIGX3iw3VBG0POVGQm4g3m+8gh0tr1eED8ZMlxILyVkmoovZKp s+JrQmUZ3Ea84OKN6VAPcHgml5Seo8zF/k9FS1DGnlwRBA0d/BZ0etJ7ApdG99OB u3gnJWKNia/VVUZPMQI1f0uz4HvUr/IvDo46sp1La0gcxORYx6jSB6bzoBOliPJi 5I8VpfPb08CoQMi99vCtiHK6PxmhBedCvjXW+3YrYb50ywI/wIKVAzdzPeB8Jx28 A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=f6S61a6KKb5Kyy0w0nKzG5D8nvftKst3i4j74whba uY=; b=o8MDHd4SrzSX8xcf4dDhO6mfFKAltEhZi8meE9kVAWYPIvPofu5Z57GzF tp9jsFd1ONkQtP93pjSkTrD3Y4VEYcCrj7RAwG2rUKr4YXG3EWa2qV1tNT6PkM/b ngvgc6s3LrimJj7X+Xg6vM6HJxtSi90JqpP15wT6VU8v1bmkm/fL7J6EqE8jY673 /Us9NouRqtAXo9C4q2RaJT5rf+iqYk3XPFIkRNIOkPMfY1bjpABnUh51bZq6pBdv GQje8wz1t7zOBbuke+O1E8T+e1HAL7pALqsoZZBa34jCJ47mQnVPHjNmTECrA3cT 5avqVw6qGi5g9vUHFePrHOtZ16j1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieelgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeegtddtheekvdekgedtteelteetkeeitefgudev iefggeetteetjeeigedtuddtudenucffohhmrghinhepihgrnhgrrdhorhhgpdhivghtfh drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 320242180064; Thu, 5 Aug 2021 12:38:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-551-g8030b8c701-fm-20210804.001-g8030b8c7 Mime-Version: 1.0 Message-Id: <79f62ea5-4c19-4a1d-8465-08ea34bebc63@www.fastmail.com> In-Reply-To: <01S24XW4Y5P6005PTU@mauve.mrochek.com> References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> <9FA3223C-A663-481C-9E97-E4E82ADBD02D@fastmail.fm> <01S24XW4Y5P6005PTU@mauve.mrochek.com> Date: Thu, 05 Aug 2021 17:38:07 +0100 From: "Alexey Melnikov" To: "Ned Freed" Cc: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=238=3A_Need_a_registry_of_header_f?= =?utf-8?q?ields_that_are_Ok_to_add_after_submission?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:38:35 -0000 Hi Ned, On Tue, Aug 3, 2021, at 12:44 AM, Ned Freed wrote: > > Dear all, >=20 > > Looking through this thread I don=E2=80=99t see any obvious conclusi= on or consensus. >=20 > I disagree with this assessment. I think there's consensus that creati= ng a > separate header field registry just to document this piece of informat= ion is a > bad idea. I also predict that if you ask the question directly, there'= s a > consensus that this doesn't belong in RFC 5321bis. >=20 > I don't think there's a consensus on anything else. Fair enough. > This leaves us with three paths forward: >=20 > (1) Abandon the idea of gathering this information somewhere entirely.= >=20 > (2) Recast the idea as an optional additional information item to be > gathered as part of registering header fields. Note that this can = be > presented as a separate table on the web page if having an email-s= pecific > column in the current table is deemed to be too confusing. Right, I offered my choice (1) as your #2, possibly falling back to your= #1. My apologies for not separating them properly. > (3) Your (3). >=20 > Your (3) actually brings up an additional point - it's arguably more > important to note whether or not a given field is a trace field in the= =20 > registry than it is to document where it's supposed to be inserted. Ri= ght > now tracking down all the trace fields is a real PITA. Right. I am happy to see if we can get consensus around (3), irrespectiv= e of which document includes it. After that we can decide on the documen= t. Best Regards, Alexey >=20 > Ned >=20 >=20 > > Possible options to move forward: >=20 > > 1) Postpone this ticket till later (after rfc5321bis/rfc5322bis are = done), as suggestions to alter existing IANA Header Fields registry is n= ot going to be feasible as is, as needs coordination with other users of= the Header Fields registry. I think this will take months. It might be = worth doing eventually, but I don=E2=80=99t have enough patience to driv= e this at the moment. (This option might end up being =E2=80=9Cno change= =E2=80=9D.) >=20 > > 2) Carry on and try to produce some example entries under the latest= proposal (see below). Hopefully this will clarify the intent. >=20 > > 3) Scale down the proposal to only register trace header fields. Inf= ormation about MSA/MTA/MDA would probably go, but can be added as a comm= ent. >=20 > > Anybody would like to speak in favour options #2 or #3? >=20 > > Best Regards, > > Alexey >=20 > > > On 23 Jul 2021, at 13:22, Alexey Melnikov wrote: > > > > > > =EF=BB=BFDear WG participants, > > > > > > I would like to get closure on this ticket, which was briefly disc= ussed on the mailing list and also during IETF 109 & 110. Below is a upd= ated strawman text: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Add to the IANA Considerations of rfc5321bis: > > > > > > IANA is requested to create a new subregistry for email header fie= lds that can be added to a message header section by a MSA/MTA/MDA. The = new subregistry would show whether a header field can be added by a "mes= sage submission", =E2=80=9Crelay=E2=80=9D, =E2=80=9Cdelivery=E2=80=9D sy= stem or some combination of them. Headers appearing in this subregistry = SHOULD also be registered in > (whether it is registered as a Permanent = Message Header Field Name or as a Provisional Message Header Field Name)= . The registration template has the following fields: > > > > > > 1) Name of the header field name > > > > > > 2) Can be added by an MSA? > > > > > > 3) Can be added by an MTA? > > > > > > 4) Can be added by an MDA? > > > > > > 5) Optional reference field that points to one or more document de= scribing the header field. > > > > > > 6) Optional comment > > > > > > Registration policy for this new subregistry is =E2=80=9CExpert Re= view=E2=80=9D. Designated Experts should only check correctness of the i= nformation in the registration template without passing any judgement on= usuability of a specific header field being registered. > > > > > > Updates to existing entries undergo the same process as registrati= on of new header fields. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Let me know your thoughts. > > > > > > > > > Best Regards, > > > > > > Alexey > > > > > > > > > -- > > > Emailcore mailing list > > > Emailcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/emailcore >=20 > > -- > > Emailcore mailing list > > Emailcore@ietf.org > > https://www.ietf.org/mailman/listinfo/emailcore >=20 >=20 From nobody Thu Aug 5 09:47:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C53A1921 for ; Thu, 5 Aug 2021 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=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 (2048-bit key) header.d=fastmail.fm header.b=wfJjEPcq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SUu5R7df 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 3JelV46DrrO9 for ; Thu, 5 Aug 2021 09:47:40 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6B93A192B for ; Thu, 5 Aug 2021 09:47:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EA0475C005F for ; Thu, 5 Aug 2021 12:47:38 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Thu, 05 Aug 2021 12:47:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm3; bh=zPBQRnSXVNVb3pYjXHx8OYFW4q uPFP+/HN1cTlVlacs=; b=wfJjEPcqqOtiWUDXdEzArsBDmQWob0S1O7TU7MPEVK W98PhOFP0ods4J4FHODLo34Y69hUrit0gXmyiSkYMZ6t4cR0S+ImQog3tgTtoREg hEjZPmHAbs6+/bGGqpfjL3GLQd4ZKVVOxBlMqwkbK6/rslK6H5oBImOu18va/Vbt kswtqz3qfVxK0lqUJk0Vx1r10jFQqTK3Z2Sfo6I1vohsAA7UTkVwYQXKrLYYY+ih yhdy6Ku2s10E7jR8yVJXVTVTgNpc2+aauLwt5TbdWRHeSwy+cAg4jfFwkzzzDE8q gvlWuaHXqRfrktfmDmAl4tRu0MymuyoCGBgI+TOchpzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zPBQRn SXVNVb3pYjXHx8OYFW4quPFP+/HN1cTlVlacs=; b=SUu5R7dfEnukEZrL7OQt68 cwJo9yWcf4oGKvgfwpQhjQxXn9rrea9s/i72NLHKZy1pAmYGGyHmUX7OlIuYspby bGTWHaBq4XVyinZ2cFe83efQjhHXAvps214y5wTXTlBlUOYz2A6YTez8bpwBgSPq a1Hh4cMJ0Dxy9BXm5MAjb41/nscY2WY6eClvNgI44wF+4K53B2p4U6rHwo3dzajZ sXt209OV9f4csvnJ6mtvPU7T583DtK5agtakUr2fwkbpZRYJntY3pE/2p8FqSIQs d+Bx0lHDezfxKTeuv1DImg0ZQLIjD5nucoyubqxdpi1VP80noQwFOImJhBgp+epQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieelgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepfeegudekve egiefhleduhfelfeeigffhuddtheffhfevheeitedvleevuefhhffhnecuffhomhgrihhn pehirghnrgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A1782180064; Thu, 5 Aug 2021 12:47:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-551-g8030b8c701-fm-20210804.001-g8030b8c7 Mime-Version: 1.0 Message-Id: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> Date: Thu, 05 Aug 2021 17:47:17 +0100 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:47:52 -0000 Dear WG participants, Based on our recent struggles to agree on a more generic IANA registry f= or header fields added by MSAs/MTAs/MDAs, I propose the following altern= ative. The new proposal is to create a registry of trace header fields o= nly. Proposed text (document to include it is TBD): IANA is requested to create a new registry for trace header fields [rfc5= 322bis]. Header fields appearing in this registry SHOULD also be registe= red in (whether they are registered as Permanent Message Header Field N= ames or as Provisional Message Header Field Names). The registration tem= plate has the following fields: 1) Name of the trace header field 2) Optional reference field that points to one or more document describi= ng the header field. 3) Optional comment Registration policy for this new subregistry is =E2=80=9CExpert Review=E2= =80=9D. Designated Experts should only check correctness of the informat= ion in the registration template without passing any judgement on usuabi= lity of a specific trace header field being registered. Updates to existing entries undergo the same process as registration of = new trace header fields. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Does this look agreeable to people? Best Regards, Alexey From nobody Thu Aug 5 10:36:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47DA3A1AFE for ; Thu, 5 Aug 2021 10:36:18 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 aAAjHeQjoj6R for ; Thu, 5 Aug 2021 10:36:13 -0700 (PDT) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6F13A1AFC for ; Thu, 5 Aug 2021 10:36:13 -0700 (PDT) Received: (qmail 9979 invoked from network); 5 Aug 2021 17:36:12 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (a0ddf198-f613-11eb-9c3e-63f8822b9bc3); Thu, 05 Aug 2021 10:36:12 -0700 To: emailcore@ietf.org References: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <68348476-b7cb-b854-7df0-47592c6c62ec@linuxmagic.com> Date: Thu, 5 Aug 2021 10:36:12 -0700 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: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: a0ddf198-f613-11eb-9c3e-63f8822b9bc3 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 17:36:19 -0000 On 2021-08-05 9:47 a.m., Alexey Melnikov wrote: > Dear WG participants, > Based on our recent struggles to agree on a more generic IANA registry for header fields added by MSAs/MTAs/MDAs, I propose the following alternative. The new proposal is to create a registry of trace header fields only. > > Proposed text (document to include it is TBD): > > IANA is requested to create a new registry for trace header fields [rfc5322bis]. Header fields appearing in this registry SHOULD also be registered in (whether they are registered as Permanent Message Header Field Names or as Provisional Message Header Field Names). The registration template has the following fields: > > 1) Name of the trace header field > > 2) Optional reference field that points to one or more document describing the header field. > > 3) Optional comment > > Registration policy for this new subregistry is “Expert Review”. Designated Experts should only check correctness of the information in the registration template without passing any judgement on usuability of a specific trace header field being registered. > > Updates to existing entries undergo the same process as registration of new trace header fields. > > =============== > > Does this look agreeable to people? > > > Best Regards, > Alexey > You know the selection/criteria of "Expert Review" will be controversial I am sure... However, speaking of 'trace' fields, I do think that some resources be included on this topic, to get it in RFC, NOT to add non-trace headers in 'trace order'.. Couldn't help but look at the headers of the email you just sent.. (comments welcome) Return-Path: Delivered-To: michael@linuxmagic.com Received: (qmail 7435 invoked from network); 5 Aug 2021 16:47:57 -0000 Received: from mail.ietf.org (HELO mail.ietf.org) (4.31.198.44) by fe3.cityemail.com with (DHE-RSA-AES256-GCM-SHA384 encrypted) SMTP (e2b84f0c-f60c-11eb-97ce-f31d7c51c7e3); Thu, 05 Aug 2021 09:47:57 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A629C3A1941 for ; Thu, 5 Aug 2021 09:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1628182076; bh=OqWf1ujkBNhxWI03krOoe1Yk9MAdSUXDhYjgD4+rdvU=; h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=cbtdWshhHllJJq8LVMoovZmf9PM9uQDqgLa5m7VA4aBsipaFa55H1zEkyQTn4UoUG WB5DQCnX2sCqa+ddhm7FL4d0GAv/3QOIRzvjsng7Tn+emssqiuqWV1s5oCm9tmiDjh 0/HHSHctBjuELe7gzd5tsNwOutNeHLwugC1DmdsQ= ** Why are DKIM headers added in the middle of the trace headers? X-Mailbox-Line: From emailcore-bounces@ietf.org Thu Aug 5 09:47:54 2021 ** Why/What is this line, and in the middle of trace headers. Should it not be inserted end of headers? Or at least after trace headers? Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC53A18F6; Thu, 5 Aug 2021 09:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1628182074; bh=OqWf1ujkBNhxWI03krOoe1Yk9MAdSUXDhYjgD4+rdvU=; h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=PZnc2z6nZK6Cgt1W3LsjQ2Pln/8759vP2rtJLBST+ZJ8bL6ehyHLM21R8IgDJbDFa xlYELv144OUvXjZrZF9Aej+GvrnKmpkGSx+CIKjwVWobeSA9XDDrcurRm7pELmTVc7 /3qIV6JmjyLf1dbZsLIMuQseLttQ4PUIOZcSlGw8= More DKIM embedded in trace.. X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Is X-Original-To a trace header? I get that the Delivered-To is.. Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C53A1921 for ; Thu, 5 Aug 2021 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=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 (2048-bit key) header.d=fastmail.fm header.b=wfJjEPcq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SUu5R7df I get that many systems in the email flow may do 'scanning' but they should not be putting all these headers in the middle of trace headers should they? 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 3JelV46DrrO9 for ; Thu, 5 Aug 2021 09:47:40 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6B93A192B for ; Thu, 5 Aug 2021 09:47:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EA0475C005F for ; Thu, 5 Aug 2021 12:47:38 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Thu, 05 Aug 2021 12:47:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm3; bh=zPBQRnSXVNVb3pYjXHx8OYFW4q uPFP+/HN1cTlVlacs=; b=wfJjEPcqqOtiWUDXdEzArsBDmQWob0S1O7TU7MPEVK W98PhOFP0ods4J4FHODLo34Y69hUrit0gXmyiSkYMZ6t4cR0S+ImQog3tgTtoREg hEjZPmHAbs6+/bGGqpfjL3GLQd4ZKVVOxBlMqwkbK6/rslK6H5oBImOu18va/Vbt kswtqz3qfVxK0lqUJk0Vx1r10jFQqTK3Z2Sfo6I1vohsAA7UTkVwYQXKrLYYY+ih yhdy6Ku2s10E7jR8yVJXVTVTgNpc2+aauLwt5TbdWRHeSwy+cAg4jfFwkzzzDE8q gvlWuaHXqRfrktfmDmAl4tRu0MymuyoCGBgI+TOchpzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zPBQRn SXVNVb3pYjXHx8OYFW4quPFP+/HN1cTlVlacs=; b=SUu5R7dfEnukEZrL7OQt68 cwJo9yWcf4oGKvgfwpQhjQxXn9rrea9s/i72NLHKZy1pAmYGGyHmUX7OlIuYspby bGTWHaBq4XVyinZ2cFe83efQjhHXAvps214y5wTXTlBlUOYz2A6YTez8bpwBgSPq a1Hh4cMJ0Dxy9BXm5MAjb41/nscY2WY6eClvNgI44wF+4K53B2p4U6rHwo3dzajZ sXt209OV9f4csvnJ6mtvPU7T583DtK5agtakUr2fwkbpZRYJntY3pE/2p8FqSIQs d+Bx0lHDezfxKTeuv1DImg0ZQLIjD5nucoyubqxdpi1VP80noQwFOImJhBgp+epQ == Another DKIM header in the middle of trace headers? X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieelgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepfeegudekve egiefhleduhfelfeeigffhuddtheffhfevheeitedvleevuefhhffhnecuffhomhgrihhn pehirghnrgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Are the above Trace headers? Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A1782180064; Thu, 5 Aug 2021 12:47:38 -0400 (EDT) Trace Headers maybe should be more explicitly discussed, as being at the top of the email, and no other headers that are NOT trace headers should be inserted at the top of the message. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Thu Aug 5 10:38:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC473A1B0E for ; Thu, 5 Aug 2021 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.com 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 xSCkkswi1MDB for ; Thu, 5 Aug 2021 10:37:59 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453053A1B0C for ; Thu, 5 Aug 2021 10:37:59 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id n17so9955731lft.13 for ; Thu, 05 Aug 2021 10:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYqFXt0Xt2YE64n/33Y/jEigJU1XCtiVZk6CE8Z4IN8=; b=VdRXuoiBtgR/DiBOMjgjGE/zeMzpnoPnh2oxFUFpOgmpfIoSNbS20cRKoXgXWG/x05 h508EnpZFIn7cks62ytYPxmXVw/MVt4OgXJcVSts2NKSGyCpJhvjIrXzrZhvEXF+tLFU zKEKKAJnLkRy5UhfImq2OXgy2SL/LIWr9QufkMGh8R9svwHHkn/c7EQN0CiWq/DeaDBN 7oQ6w1tvjQtflcp/IvFnHj9QUsalXVD4z8Ir/X/JpfBvIU2HXlCx7SE6Yb+5pPeq07Dh 0gdjd7vUdcMpnyvV1mQI/zoy1PEjGBENVhGT3i8qL2e2ijmjEFf9OkAmkgBTXL1Mh0wz hm2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XYqFXt0Xt2YE64n/33Y/jEigJU1XCtiVZk6CE8Z4IN8=; b=mTtHI0VKAM38FmMOQQ51Ko3i/RgVbrNYqMpjmNzXCu0x6GK7AmTpKVkLf6HgUuxmq4 vg1MglzHZowxmYoPhvFHPVKKzSarRucgtwcb9ti0s1iTNtTT1IpOE0QbdnlnCuRn07Xp 13CW8KF8mZXRvD3SvTknS+ZfMkyd1hPhm3tETqywQWITHSZ2XJEEnSsiQysDmIRtU0Ip DKnkYEq7jSD6stNvf6kDqGOKKovzYpwtx0mEyx40DTXwSfQ80FDJ7FdqsPaPxk9W1YGU KogIyfaWkEGFoVI3Qx2fQHEatlWmRoSa8cg5GcR/fVLHcvuBsqYN6CBMaALkWA6UaukQ f3Pg== X-Gm-Message-State: AOAM532/gFUSwg2Wb76ve7n0u4+1ljix2xijwalPzE5bCggdnpwAITUV lyre9KCH1qz9aUybfOU7Wen6hW89igCgKBEunLZKAZZPcV4= X-Google-Smtp-Source: ABdhPJwZtfN1eYb/jkHeT0dz5iJbKJIqKQpDFX2RE6y69sTH6HiGwkn8vZqBPbLSFUa0jSlCnUQYTQ09ElIJiVi03l0= X-Received: by 2002:a05:6512:2618:: with SMTP id bt24mr4616345lfb.180.1628185076128; Thu, 05 Aug 2021 10:37:56 -0700 (PDT) MIME-Version: 1.0 References: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> <68348476-b7cb-b854-7df0-47592c6c62ec@linuxmagic.com> In-Reply-To: <68348476-b7cb-b854-7df0-47592c6c62ec@linuxmagic.com> From: Tim Wicinski Date: Thu, 5 Aug 2021 13:37:45 -0400 Message-ID: To: Michael Peddemors Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000175ffd05c8d361f8" Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 17:38:04 -0000 --000000000000175ffd05c8d361f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 5, 2021 at 1:36 PM Michael Peddemors wrote: > On 2021-08-05 9:47 a.m., Alexey Melnikov wrote: > > Dear WG participants, > > Based on our recent struggles to agree on a more generic IANA registry > for header fields added by MSAs/MTAs/MDAs, I propose the following > alternative. The new proposal is to create a registry of trace header > fields only. > > > > Proposed text (document to include it is TBD): > > > > IANA is requested to create a new registry for trace header fields > [rfc5322bis]. Header fields appearing in this registry SHOULD also be > registered in < > https://www.iana.org/assignments/message-headers/message-headers.xhtml> > (whether they are registered as Permanent Message Header Field Names or a= s > Provisional Message Header Field Names). The registration template has th= e > following fields: > > > > 1) Name of the trace header field > > > > 2) Optional reference field that points to one or more document > describing the header field. > > > > 3) Optional comment > > > > Registration policy for this new subregistry is =E2=80=9CExpert Review= =E2=80=9D. > Designated Experts should only check correctness of the information in th= e > registration template without passing any judgement on usuability of a > specific trace header field being registered. > > > > Updates to existing entries undergo the same process as registration of > new trace header fields. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Does this look agreeable to people? > > > > > > Best Regards, > > Alexey > > > > You know the selection/criteria of "Expert Review" will be controversial > I am sure... > > I have been told by IANA that there should always be > 1 expert reviewer. YMMV tim --000000000000175ffd05c8d361f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 5, 2021 at 1:36 PM Michael Peddem= ors <michael@linuxmagic.com> wrote:
On = 2021-08-05 9:47 a.m., Alexey Melnikov wrote:
> Dear WG participants,
> Based on our recent struggles to agree on a more generic IANA registry= for header fields added by MSAs/MTAs/MDAs, I propose the following alterna= tive. The new proposal is to create a registry of trace header fields only.=
>
> Proposed text (document to include it is TBD):
>
> IANA is requested to create a new registry for trace header fields [rf= c5322bis]. Header fields appearing in this registry SHOULD also be register= ed in <https://www.iana.org= /assignments/message-headers/message-headers.xhtml> (whether they ar= e registered as Permanent Message Header Field Names or as Provisional Mess= age Header Field Names). The registration template has the following fields= :
>
> 1) Name of the trace header field
>
> 2) Optional reference field that points to one or more document descri= bing the header field.
>
> 3) Optional comment
>
> Registration policy for this new subregistry is =E2=80=9CExpert Review= =E2=80=9D. Designated Experts should only check correctness of the informat= ion in the registration template without passing any judgement on usuabilit= y of a specific trace header field being registered.
>
> Updates to existing entries undergo the same process as registration o= f new trace header fields.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Does this look agreeable to people?
>
>
> Best Regards,
> Alexey
>

You know the selection/criteria of "Expert Review" will be contro= versial
I am sure...


I have been told by IANA that there shoul= d always be > 1 expert reviewer.=C2=A0 YMMV

tim
--000000000000175ffd05c8d361f8-- From nobody Thu Aug 5 11:07:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A313A1C45 for ; Thu, 5 Aug 2021 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 1zkF1vmV6k61 for ; Thu, 5 Aug 2021 11:06:30 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227C33A1C05 for ; Thu, 5 Aug 2021 11:06:28 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 58DC65273; Thu, 5 Aug 2021 20:06:21 +0200 (CEST) Date: Thu, 5 Aug 2021 20:06:21 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210805180621.GA26014@hjp.at> References: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> <68348476-b7cb-b854-7df0-47592c6c62ec@linuxmagic.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <68348476-b7cb-b854-7df0-47592c6c62ec@linuxmagic.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 18:06:45 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-08-05 10:36:12 -0700, Michael Peddemors wrote: > Couldn't help but look at the headers of the email you just sent.. (comme= nts > welcome) >=20 > Return-Path: > Delivered-To: michael@linuxmagic.com > Received: (qmail 7435 invoked from network); 5 Aug 2021 16:47:57 -0000 > Received: from mail.ietf.org (HELO mail.ietf.org) (4.31.198.44) > by fe3.cityemail.com with (DHE-RSA-AES256-GCM-SHA384 encrypted) SMTP > (e2b84f0c-f60c-11eb-97ce-f31d7c51c7e3); Thu, 05 Aug 2021 09:47:57 -0700 > Received: from ietfa.amsl.com (localhost [IPv6:::1]) > by ietfa.amsl.com (Postfix) with ESMTP id A629C3A1941 > for ; Thu, 5 Aug 2021 09:47:56 -0700 (PDT) >=20 > DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; = s=3Dietf1; > t=3D1628182076; bh=3DOqWf1ujkBNhxWI03krOoe1Yk9MAdSUXDhYjgD4+rdvU=3D; > h=3DDate:From:To:Subject:List-Id:List-Unsubscribe:List-Archive: > List-Post:List-Help:List-Subscribe; > b=3DcbtdWshhHllJJq8LVMoovZmf9PM9uQDqgLa5m7VA4aBsipaFa55H1zEkyQTn4UoUG > WB5DQCnX2sCqa+ddhm7FL4d0GAv/3QOIRzvjsng7Tn+emssqiuqWV1s5oCm9tmiDjh > 0/HHSHctBjuELe7gzd5tsNwOutNeHLwugC1DmdsQ=3D >=20 > ** Why are DKIM headers added in the middle of the trace headers? Were they added in the middle? Or were the prepended and then other systems prepended their own trace headers? I strongly suspect the latter and I think this is the right thing to do. > X-Mailbox-Line: From emailcore-bounces@ietf.org Thu Aug 5 09:47:54 2021 >=20 > ** Why/What is this line, It looks like the line that the mbox mailbox format uses to signal the start of a new mail. Presumably the mailing list software gets the mail including this start line and preserves it as an X header. > and in the middle of trace headers. Should it not be inserted end of > headers? Or at least after trace headers? No, definitely not. Please always, always, always prepend new headers. Never append them. If some headers are appended and some prepended, it is impossible to tell which headers were added by which system. If headers are always prepended, it is trivial: | Some: headers here | Received: from B by C | More; headers here | Received: from A by B | Even: more headers here All the headers between "Received: from B by C" and "Received: from A by B" were added by system B. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmEMKJIACgkQ8g5IURL+ KF2TjRAAk0apTGB92zDqv8OOxFvlJU37miRpACPLe08bvfturmQxo5rqOAtXKJVL aFNCro5KJtguyDBrSxz6xWxBQojvubXBo00jxJYjLsSi7mTcsJsrxSl+6gAlGQn5 nTdNI02daXFanzvSikL3XOUYFG9rpQVFVcbNORY8A87Hd6lAq/1bC17D2Za0nHe/ EsDs6Bwz1TKAbeAUhQ9zsYxCbgG7gsHXsQomiLJQeC4AMGF4JCxdTzk79qa0gwHI KHXezRVRzDDq5h1aTYoshtcw/UbsxAhauv7cdZChrf+lgxkNBPCA7YZFAmayczXQ WD1RRNekVn2i+UxwojWYWt4yAgiQR12RDucT1755dH5asxCdOuFtLbzKApj+atmC DX71TW9enRAcl8cxgUdNmTUWehMTrTwAo8TMpI9i/ZmejiwHnyHD+Q1nBOz0lPb+ XulrndMQb1WWVpcE5DKqPD7NTZvrzUKAJcvkdiRC7BOQS29xTc0+iCWYsqegc/HZ HnBcw8wnSnpwQS3VxJ+gloP1sbcjvOM9f53vkHQXxct+qNzcKj8CFVMSnjMtKsD8 QoCr/d7PNNWaJBceFOeO2oZc3o/jeOq6hBqOw2THUY7ls/i4fOOmZAKm27Yqsfz9 LO7mWj9LCreK6y5XSUcUny7opX8J4yfzgVUIF1z8z6WWKeC5vXg= =FaUz -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From nobody Thu Aug 5 12:59:37 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BC83A20A0 for ; Thu, 5 Aug 2021 12:59:35 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=sBQ7c2NX; dkim=pass (2048-bit key) header.d=taugh.com header.b=iek+2XI1 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 jmJ5OwlZ7TBe for ; Thu, 5 Aug 2021 12:59:29 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 865663A209A for ; Thu, 5 Aug 2021 12:59:29 -0700 (PDT) Received: (qmail 58527 invoked from network); 5 Aug 2021 19:59:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e49d.610c431f.k2108; bh=7+7euVuW1lswB8ABhUUfEiKUoeeBlQjYnFYsBy7ghzA=; b=sBQ7c2NXRNN/7AEpVoeCFBdktzsAC2mKK4Q3P6MlWtVGA2aFbPcmiI3A/0YlM04LbWdp+HW6qJVJwv2o7/xPnkHdLAZVEzxP9rR/llnrDU8TtJOEcTxzvvSCWakd32pd25gDnGpBPggPI+4eMz8tXiv/IAX9CVMmwhrfuD2x+7FOubmEai4IJmnWTyGL9+nKOnYAJBcef2dz4NSe95F5y8RjO5ZfFKPa0gNT+55gBAl210CTmKI4dX2rXw7s/6QLrLSTDSwkaTsHjDzv0eyw97SirC1ovptny+4B7Fevro+ufHBxYJkOTLANyWjC4UEGdctYuGB3Bti/qxtUOuLo0w== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e49d.610c431f.k2108; bh=7+7euVuW1lswB8ABhUUfEiKUoeeBlQjYnFYsBy7ghzA=; b=iek+2XI1VkD9ufcJ/s0vjW9M/WPJ7F7fTF/oZTfME3E0S5AZ59rTMRb+iJ9HRviVAQtgwG3fFHbpVJeYdVIuvHBETeEFvjLoQV3lFAcEV3fOr3cxzrOzFG6Elaot5hl/h68xgcXK/HVP69fWcB2zgWqZoU/Kj28yKdV6+crO2Jqa73xYG/DODFmYBSLJKUvNw5iR0QxPHs5FQCBH6YZREGUgPotQq9HiT1a06bdmPRZUdlACiGSErAlhPPZRskH1Vd+xjg1TiOCLpcFmgP3pUQjzHWQd2IoRP+kyMQpe52NfQ5aWc9Kg4StTkN/p9ZmOVG+8jHl8U5Pg8RT3UEmO/Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Aug 2021 19:59:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 010ED259CD83; Thu, 5 Aug 2021 15:59:25 -0400 (EDT) Date: 5 Aug 2021 15:59:25 -0400 Message-Id: <20210805195926.010ED259CD83@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: aamelnikov@fastmail.fm In-Reply-To: <79f62ea5-4c19-4a1d-8465-08ea34bebc63@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=238=3A_Need_a_registry_of_header_f?= =?utf-8?q?ields_that_are_Ok_to_add_after_submission?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 19:59:35 -0000 It appears that Alexey Melnikov said: >> Your (3) actually brings up an additional point - it's arguably more >> important to note whether or not a given field is a trace field in the >> registry than it is to document where it's supposed to be inserted. Right >> now tracking down all the trace fields is a real PITA. > >Right. I am happy to see if we can get consensus around (3), irrespective of which document includes it. After that we can decide on the document. Sounds good to me. My inclination is to update RFC 3864 and add "mail trace" as a value in the Protocol column of the existing Message Headers registry. R's, John From nobody Thu Aug 5 13:01:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7893A20B1 for ; Thu, 5 Aug 2021 13:01:24 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=M3dgSDps; dkim=pass (2048-bit key) header.d=taugh.com header.b=QY4hkzYG 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 aYqxa24pZLrc for ; Thu, 5 Aug 2021 13:01:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9D86E3A20AB for ; Thu, 5 Aug 2021 13:01:18 -0700 (PDT) Received: (qmail 58793 invoked from network); 5 Aug 2021 20:01:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e5a4.610c438c.k2108; bh=qIAxxV0YEoR8hBXI/Xfj7r42zLeRRxdfPxa7OVCNwJU=; b=M3dgSDpsQA8bnJzN2n+uh5CuSRCoWjgTzuBNZZUHbY4HfSXfQy68rOBBmPksDZdaotnGUVbtE3heJkVyo7k4VouMyATPy//nsVwYiYJJn6l3RtRT7WOAAH8d0/HIpI3OELE/ywExC8Ru/m15zvoegilqMYYNWdPW7EOG5/0C+MjTjBgJ04wZ+J+diQ6wWivXZsAk8FWocjZqbbtxQxbMtoQz3sD5Hetdmcbb3/AExC8H5VQQnhVCrf0DvWluG7Ly3bVGqhR93MuYcF92jjnm5YcnrGNpCQ/XiUUryULCETiD6SLJbKzCn5N0jUAuYGQfEaLVj1SsbovnzcnTPHG4GA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e5a4.610c438c.k2108; bh=qIAxxV0YEoR8hBXI/Xfj7r42zLeRRxdfPxa7OVCNwJU=; b=QY4hkzYGHFZCQuoF7X7OLcfCWQw9XfuXHQoXpQvJljSaYbq636sLvIxuVF9BXJOeueg0v8JErjHogF/v0pLupI/sF+tTT/UgT/msuS6SqZiIN4eX3kBp4j91tSdVsLdAI4A2vP6W6CKHKrqmnQBhStpPmEH4BlmQYsfxP4vSCNQujzkQta6/rtupL4ezWRajQqq9iQkqArR1/c41mwTXpnfs1+n3ACHluXTVxFCP7kOErr5howWb8eqLUhwtew1U7zUR1wTThH4l6g+zaKtHYRUU1f6eh+Fon8XXxw1nFkUaFLO9uR4Hjd3IK+u09AdPUN3Qcm3Odvh+7GGqaNJb4A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Aug 2021 20:01:15 -0000 Received: by ary.qy (Postfix, from userid 501) id 197CF259CDBF; Thu, 5 Aug 2021 16:01:14 -0400 (EDT) Date: 5 Aug 2021 16:01:14 -0400 Message-Id: <20210805200115.197CF259CDBF@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: aamelnikov@fastmail.fm In-Reply-To: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:01:25 -0000 It appears that Alexey Melnikov said: >Dear WG participants, >Based on our recent struggles to agree on a more generic IANA registry for header fields added by MSAs/MTAs/MDAs, I propose the following alternative. The new >proposal is to create a registry of trace header fields only. > >Proposed text (document to include it is TBD): > >IANA is requested to create a new registry for trace header fields [rfc5322bis]. Header fields appearing in this registry SHOULD also be registered in > (whether they are registered as Permanent Message Header Field Names or as Provisional >Message Header Field Names). The registration template has the following fields: >Does this look agreeable to people? I'd still rather update the existing registry to add "mail trace" as a protocol value. R's, John From nobody Thu Aug 5 13:22:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5413A0603 for ; Thu, 5 Aug 2021 13:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_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 WbCMTbkJNAkQ for ; Thu, 5 Aug 2021 13:22:21 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 44D613A060A for ; Thu, 5 Aug 2021 13:22:21 -0700 (PDT) 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 D45EF101925; Thu, 5 Aug 2021 20:22:19 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-105-161-178.trex.outbound.svc.cluster.local [100.105.161.178]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 74275101E5B; Thu, 5 Aug 2021 20:22:18 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.105.161.178 (trex/6.3.3); Thu, 05 Aug 2021 20:22:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cold-Irritate: 03b1d59f1680a238_1628194939361_1968593297 X-MC-Loop-Signature: 1628194939361:2515318425 X-MC-Ingress-Time: 1628194939360 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 8EA1910E9E4A; Thu, 5 Aug 2021 20:22:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628194937; bh=7vXdydODEnvCoj780/shS8BS/Xv3s1xmEVEP+CA8YRs=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=aA+bsdGv9ES7gEReejKK6GkcPsQ9uODkVUh11EdV0DzdHdh0nQxGt3zZgrn+dkIkt p/KDJbJRpVHPm87+iDdGREXpvrmfumaW32SCUI4dmscTU4C90+ZGf6SeO3iBdbla6u FahRs6tz1jinT9BuL/8uTuJbwhr+FR+IPOfkQUTCUGw+6JSepoYbU3ksfh7oTmrO3N 1vw0R4BHVhuN0333UfxryRwF4C1MVziy5jPdUn6V2WRIDUkTmPP1Jt9GLR7Z/1+SAm nx3/No2ZDxPHHGPgaz1hdkks1/JMxh7d4QyzR5yYH7P04yQkBqoXY+2EIMkrsgJ0kG KGuIbxhoe74ag== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <699766b2-a5dd-618d-4c0c-a18976ad4e8b@dcrocker.net> Date: Thu, 5 Aug 2021 13:22:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <4c68cf7b-804b-4cb0-be08-815ed69769bb@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:22:27 -0000 On 8/5/2021 9:47 AM, Alexey Melnikov wrote: > The new proposal is to create a registry of trace header fields only. Just for clarity and precision, what are the pointers to: 1. A technical definition of 'trace' header field, that distinguishes one, unamiguously, from other header fields? 2. A specification of the creation/handling/disposition differences for trace header fields, distinguishing them from other header fields? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 5 13:37:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFF23A081B for ; Thu, 5 Aug 2021 13:37:46 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=cKcHOj5H; dkim=pass (2048-bit key) header.d=taugh.com header.b=D7YKj1Hc 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 wTdwcXqz_3Y7 for ; Thu, 5 Aug 2021 13:37:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9A1DB3A0812 for ; Thu, 5 Aug 2021 13:37:40 -0700 (PDT) Received: (qmail 63581 invoked from network); 5 Aug 2021 20:37:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=f85a.610c4c12.k2108; bh=3gvzQKuTCXD5Th9UCzEeuBcXCfIvRf8I0GEunL0q1vI=; b=cKcHOj5HEDI6Wq9g8jGvOTYXt2RCNJodtAHOSZcoWH+xrPE5W5DzPfWHwCrv16fjZ79MtYm/1WJGiXxPX3Yn063jQatMNcJ4DtMTqG/vFeMeUB9zv78o5TwzXSZJz5zYZsfH44M8ej3ODSkarwdKQ9sscN1OenrNMwP21tD7IqM8QkgFbukcIXcVGUHUEwA5+bXbfQq24JgwJWOiLOVGrDfNDR32DshnTqyIa6byPtBLY7+snv9yTQsUZoxfvQpH1NpRiuExxX9dDm+PNEXDKR3+P1LR/hVh/jEjBBhn2VBi3pJT17SdjuNvfEudbWONQlcsvZghjWTrYPsY4PpAkw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=f85a.610c4c12.k2108; bh=3gvzQKuTCXD5Th9UCzEeuBcXCfIvRf8I0GEunL0q1vI=; b=D7YKj1HcLKl71wM4gLd1iDzt67cfAJi+6My5i44k56/bGuCIBlz4Wdgylkv8PRJJ6HrOWGunVRokf7BHYcBH3pvoJCYnpxSskHhRtiHX/N360WPFNf1MqOzKsg30a968EzaPuw5eRJBPHgI0RN/JA2x9yn8d94okp5sqY1YVrRFDX9qgToYGJbZXmgB73ar8sTDihyQl8Z2IRBVpknGvhAAgwmeXjkuekkA41GszOsiUS2+D/mEWv4jFzEmTwm+A0zK12OMKE0VGpAvYic1RSdwMnae7phGbOvVnAzucV6EJ5gmxYSd7/w9KA/Bbpia1d/WaaJv8xpiMZIySzadIew== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Aug 2021 20:37:38 -0000 Received: by ary.qy (Postfix, from userid 501) id A513B259D5A1; Thu, 5 Aug 2021 16:37:35 -0400 (EDT) Date: 5 Aug 2021 16:37:35 -0400 Message-Id: <20210805203737.A513B259D5A1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <699766b2-a5dd-618d-4c0c-a18976ad4e8b@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:37:46 -0000 It appears that Dave Crocker said: >On 8/5/2021 9:47 AM, Alexey Melnikov wrote: >> The new proposal is to create a registry of trace header fields only. > >Just for clarity and precision, what are the pointers to: > >1. A technical definition of 'trace' header field, that distinguishes >one, unamiguously, from other header fields? > >2. A specification of the creation/handling/disposition differences for >trace header fields, distinguishing them from other header fields? See section 3.6.7 of rfc5322bis and ticket 7. R's, John From nobody Thu Aug 5 14:42:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80653A1038 for ; Thu, 5 Aug 2021 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 WhRAlwSIx9Bd for ; Thu, 5 Aug 2021 14:42:34 -0700 (PDT) Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (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 2E4AF3A1043 for ; Thu, 5 Aug 2021 14:41:24 -0700 (PDT) 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 13164362272; Thu, 5 Aug 2021 21:41:24 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-96-11-182.trex-nlb.outbound.svc.cluster.local [100.96.11.182]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 62AA83623A1; Thu, 5 Aug 2021 21:41:23 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.11.182 (trex/6.3.3); Thu, 05 Aug 2021 21:41:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Trouble-Bubble: 08d81ff33f7b9e05_1628199683805_291863482 X-MC-Loop-Signature: 1628199683805:784829647 X-MC-Ingress-Time: 1628199683805 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 6E2E531364B6; Thu, 5 Aug 2021 21:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628199682; bh=W4ODSdpk/BsUTNnLdJjoVhxL+l3frFQ9Ud7cwH7sVAE=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=ALj6+7j3w0B+YLRwdluYfb+7Vhy60qsqs0WhERetwSUEk0nZNOIWZngYj2C3M8XOK L7jgiQXC6PHKffqRK/nd1KCzkkS2PbzwUnX+61sc8RpdDtRdwknCMdqZq31Y7zR/JF Qa/tvHDMhGjArihhbdRBa+IfCv5+EWWtEw0MCkxP/GJRF43gBl49hoPDPGv01bO5UR EswE2Af1jAzwO2Mi0oET0qbXsSgzcM7ILS5N+kESPqxlyg9AyXrMPxAE++M1XRztBz GjeeK+y8pdWkKhESQnwShCo1RoS8O2ea2TiIOs63TLPHF2IzsCzZFoP5Y49yZCWNGb wC5uKUbSyJt/w== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org References: <20210805203737.A513B259D5A1@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> Date: Thu, 5 Aug 2021 14:41:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210805203737.A513B259D5A1@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 21:42:43 -0000 On 8/5/2021 1:37 PM, John Levine wrote: > It appears that Dave Crocker said: >> On 8/5/2021 9:47 AM, Alexey Melnikov wrote: >>> The new proposal is to create a registry of trace header fields only. >> >> Just for clarity and precision, what are the pointers to: >> >> 1. A technical definition of 'trace' header field, that distinguishes >> one, unamiguously, from other header fields? >> >> 2. A specification of the creation/handling/disposition differences for >> trace header fields, distinguishing them from other header fields? > > See section 3.6.7 of rfc5322bis and ticket 7. 3.6.7: There are details about specific fields. The only text describing the class of fields is: >> The trace fields document actions taken as a message moves through the transport system. Ticket 7: Ned - >> Going back to RFC 822, we have this definition: >> >> Trace information is used to provide an audit trail of mes- >> sage handling. In addition, it indicates a route back to the >> sender of the message. The Ticket then documents an extended discussion that does not seem to converge, especially with regard to my two questions. So the apparent answers to my two questions are No and No. In practical terms, this reduces to: "A trace field is anything we declare a trace field. There are no inherent or common technical characteristics or semantics." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 5 23:58:54 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471643A21C0 for ; Thu, 5 Aug 2021 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 5DnxiL06O8-G for ; Thu, 5 Aug 2021 23:58:47 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A719B3A21C4 for ; Thu, 5 Aug 2021 23:58:46 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 066BA5282; Fri, 6 Aug 2021 08:58:43 +0200 (CEST) Date: Fri, 6 Aug 2021 08:58:42 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210806065842.GA23520@hjp.at> References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 06:58:52 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-08-05 14:41:20 -0700, Dave Crocker wrote: > In practical terms, this reduces to: >=20 > "A trace field is anything we declare a trace field. There are no > inherent or common technical characteristics or semantics." I offer a different view: "Any field added after initial submission is a trace field." I agree with the second sentence. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmEM3Z4ACgkQ8g5IURL+ KF24hQ//bUQzBNHwITLsu69LszZuU8iDzWwpIMDGXVxo9B+usbo+LONfauNWe7zr 8YcaMUXZ9s+q5sB1zGqepxcC9CiDFLTHeR8XGuzxmaL7BmHHgbe2KVDixdlikLsM rcJb4gKWlRr2KsVQUOnJBp4qTJNGo5R2YN5fa0w4utj411eJzpCtSVb2bTSoe/n9 2y7FNM5GLHi8dTDKZbvIcFOR2IQIFdnvSer4AUO2hwL/PtH+T0IpU87Kbc6BRHMI oETr0+wan/B8K9VwAQL/1MVTx5vP/e2iDso/kGSkYbLLjMO/fr1OmudgZJzzg91B MTw3LAUsiIJDDt/LzfUKeMNLQpeP4lLfhgLsaDv5opUqQOfd+QKzCbQOQNHGM978 86SOANAyWfNGg8fJcrFB4Z86F3KrBPqqeUQIr2wtl7NDEgKRXG1+j6NRJBXHcnGQ TZSKwJImjESfk18e5go/nSVzy+RIm4aLo23z4A+urJstkFzcj98qNyxjK/bwcIRa dcrH40P7/QcZWass11BR6VloBxmDQeD69dWymTNi7N/TpmtCxYkgQamLzVpbMK6Y 3Dho2J1C6ETVAyeja+2EKS/2LbqpDIkJio1B2Zvd9Cr3xQdvMsHGMOqTVw8astdJ 10xR9fIr5+uy+H62l7WLEYH1sNsIvvgloAnSnR5efwm1M8lmezc= =orZi -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From nobody Fri Aug 6 06:18:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD653A2C88 for ; Fri, 6 Aug 2021 06:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 sdRVXKCuuFzv for ; Fri, 6 Aug 2021 06:18:12 -0700 (PDT) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (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 789FD3A2C86 for ; Fri, 6 Aug 2021 06:18:11 -0700 (PDT) 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 43C6B6419ED for ; Fri, 6 Aug 2021 13:18:09 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-96-16-104.trex.outbound.svc.cluster.local [100.96.16.104]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 6DB186416B1 for ; Fri, 6 Aug 2021 13:18:08 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.104 (trex/6.3.3); Fri, 06 Aug 2021 13:18:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Company-White: 5e541fba2834cb6a_1628255888763_3786085478 X-MC-Loop-Signature: 1628255888762:2507982981 X-MC-Ingress-Time: 1628255888762 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id A3A8031364BA for ; Fri, 6 Aug 2021 13:18:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628255882; bh=6J1TGGcGQemvJ9ny2/1LzsjuoiSSzfN+tEg0pWq55LU=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=Yt84/KYZhVLl8LgYty8Tjw3YJ+oE+u1LOozwmY5+hVOkP8d9iobpWMAJthmGv7k9D 3QWyAVt/X15aWLwB1FODhpZdHiOa8M4Peu0/2Hxz345vTONV7pslcufGdhU6mu29kI dkt442yI6sH1LxwFwReohtOPQ882jKzd9lXwZCS8Ab7bWsKqWK+GQ7Z+/1q49aTnmz TGJhlkMeBOmq6P/7GOsYvVZ/JM+Gr68yK4LaqwBzCShd0/V/EKJGjs5QpUjG5pn9G3 PWT+4lQU7xlRkA+KBXlDd73EiY4X3LSYxK68dRr3gprk2UfSdPLjdxIX/vIirmGeYJ cZTG79lIsWT4Q== Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 6 Aug 2021 06:18:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210806065842.GA23520@hjp.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 13:18:17 -0000 >> In practical terms, this reduces to: >> >> "A trace field is anything we declare a trace field. There are no >> inherent or common technical characteristics or semantics." > > I offer a different view: > > "Any field added after initial submission is a trace field." > > I agree with the second sentence. Here's the thing: Recently, there was an extended group focus on debating that a new proposed field had to be labeled a trace field. If there are no common syntactic or semantic characteristics to such a field, then was is the functional benefit in assigning the label of 'trace' to it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 6 07:04:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0D3A2E69 for ; Fri, 6 Aug 2021 07:04:42 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=jQpLiY8Z; dkim=pass (2048-bit key) header.d=taugh.com header.b=GD6ZywZ6 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 S40CUYyazGQn for ; Fri, 6 Aug 2021 07:04:37 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D071F3A2E70 for ; Fri, 6 Aug 2021 07:04:36 -0700 (PDT) Received: (qmail 85680 invoked from network); 6 Aug 2021 14:04:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14ead.610d4171.k2108; bh=plGDbaYy8kcrvqcwEYgOIgKkWXX+wba/LHYJd2lhEBk=; b=jQpLiY8Z7xCLxPqGvUtyzZkJHvQQByixOxUwiFqOLgehJ2tNd1Ze4QbO5EUPZahwMvKThF/LrvxU9f3XXsf0HNRp96z1YkOn7fR322b2G+CsUi1KI53p6Hxazf4+/pJDtwSA8me8HvyCf6M8VTUruP1dT+IcTAf5xPwOTAg27W/j2Oy1BqmzkAu448q7rCehi0BpBXLxdE3nuIXO/xMeQocxXIRWve/2+a3dDj4ElIcWGo8MYrgJ9kVkV9FfTwiEoq0XRtDF+12VjLzTTD5cYzQDSxqiH6Fio6YiOXrSzrskTiQYypm+JmKKd8mFG/XUpr6PRxSuCnvu9tbds16WJw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14ead.610d4171.k2108; bh=plGDbaYy8kcrvqcwEYgOIgKkWXX+wba/LHYJd2lhEBk=; b=GD6ZywZ6YRdIihO4z3Ul5wZNQP0UPhoMP0KjJJfCOl9+6k3qCfk6+VDqQ6MCbw69LidUIditDMyRG1yAW2UwvlgoSBIUKnyeY5Omt8ZbC/SUX9XqtBpto99cKwcaVTVvQK0eO3crwU2LEUM7OJSZ3KUp6N8lVXVKfFWO7AmkIZ0opMY19RQW0Ik0ZQUD3YiMRlASS6dbSK60UQOF/K3pal4iePF2CRbopsq74jmFiCSqR/hnXs2WJNkapX6C8OilW8aVJpN68QPcf7yP4DgWrrQPaFJ2k/M9d92ZG5J5NxyHdyWejxursgK4rPVekrsuqeShK2hRFt2VLFCs+irjXw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Aug 2021 14:04:32 -0000 Received: by ary.qy (Postfix, from userid 501) id 7F50925A63DB; Fri, 6 Aug 2021 10:04:30 -0400 (EDT) Date: 6 Aug 2021 10:04:30 -0400 Message-Id: <20210806140431.7F50925A63DB@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: hjp@hjp.at In-Reply-To: <20210806065842.GA23520@hjp.at> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 14:04:43 -0000 It appears that Peter J. Holzer said: >-=-=-=-=-=- > >On 2021-08-05 14:41:20 -0700, Dave Crocker wrote: >> In practical terms, this reduces to: >> >> "A trace field is anything we declare a trace field. There are no >> inherent or common technical characteristics or semantics." > >I offer a different view: > >"Any field added after initial submission is a trace field." > >I agree with the second sentence. I don't. A lot of delivery agents add stuff related to spam and malware filtering with names like X-Spam-Status. I wouldn't call them trace fields. In practice, I think most of us agree which headers are trace headers even if we have trouble writing down what the Platonian ideal of a trace header is. R's. John From nobody Fri Aug 6 07:09:02 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED143A2E8E; Fri, 6 Aug 2021 07:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <162825894034.10257.12517437941573328203@ietfa.amsl.com> Date: Fri, 06 Aug 2021 07:09:00 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-as-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 14:09:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Applicability Statement for IETF Core Email Protocols Authors : John C Klensin Kenneth Murchison E Sam Filename : draft-ietf-emailcore-as-03.txt Pages : 9 Date : 2021-08-06 Abstract: Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-as-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 6 07:10:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD03A2EB5 for ; Fri, 6 Aug 2021 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 ewJpLtVZmyxt for ; Fri, 6 Aug 2021 07:10:34 -0700 (PDT) Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (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 B3B9B3A2E48 for ; Fri, 6 Aug 2021 07:10:32 -0700 (PDT) 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 7C8F6642854; Fri, 6 Aug 2021 14:10:31 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-101-162-78.trex.outbound.svc.cluster.local [100.101.162.78]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 109D7642298; Fri, 6 Aug 2021 14:10:30 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.78 (trex/6.3.3); Fri, 06 Aug 2021 14:10:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Lyrical-Hook: 22b65dd40e4364d2_1628259030981_2995926128 X-MC-Loop-Signature: 1628259030981:1365981406 X-MC-Ingress-Time: 1628259030981 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 26DCF31285DE; Fri, 6 Aug 2021 14:10:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628259029; bh=oKqHgKsv5wF+bcdL2uUZvFHLjK2jlvfW441/RJ/SJXk=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=er+nhk2scUNJnIjz4xMQ/u+yexqLWy0bLRNc9PlaLTE/89WljslfQfdKW49ZJEjz0 MT4SNUdTwZSxuvmPIKLiw986/DIOx26qm0A0G1A544eyADOKYct/6thh+qoAHOEK5M YHtu+kts5UBSQzFKRW7/opwnSHe1NnUOQteCTNPCP3UqMcpRx8oPKnbggrEXCuyQqg sfURvb8KADNGWsBgMvo0Q3IddIgPOeRKoBtXO4fXxGUG++PC0MIAfoh9lp5+3LkExO jaJyv/n6twUtxUSN0xkRed5ARd0oPNPDreBdW+SZ8zptKfY7BqVnQOkwbYujVlz2aP 68mVDbQub6x5Q== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: hjp@hjp.at References: <20210806140431.7F50925A63DB@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <39020a42-8d12-a2af-f856-b51f36884b4d@dcrocker.net> Date: Fri, 6 Aug 2021 07:10:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210806140431.7F50925A63DB@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 14:10:39 -0000 On 8/6/2021 7:04 AM, John Levine wrote: > In practice, I think most of us agree which headers are trace headers even if we have > trouble writing down what the Platonian ideal of a trace header is. So a trace field is whatever a group of folk decide to call a trace field. It has no consistent, defineable characteristics. Which goes to the point that the label is arbitrary and carries no clear semantics or syntax. Which means that vigorous concern for whether a field is labeled as a trace field has no operational benefit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 6 07:31:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5FF3A3112 for ; Fri, 6 Aug 2021 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 LBdsrVVz14nU for ; Fri, 6 Aug 2021 07:31:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 83E673A3103 for ; Fri, 6 Aug 2021 07:31:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S29ZAUUTQ800CH0K@mauve.mrochek.com> for emailcore@ietf.org; Fri, 6 Aug 2021 07:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1628260178; bh=zboFGzcGRvaYwp41m3APQho9sSAUO4/T2H15URlfybE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=m77HKcDSDGG3fYJUNTHfWNzyp1Eexd6c4zX1l80+0NVbCBZlk0cx9Mn1JBjO51lAG PcA2aWabzcAK1knHrxm3iiWRNJOlR1/LgDm44wC91LFbWf3SimB0g30klajXWpy+D9 wX50zxnL1d6g80WxXEyRKavB4r6pnw4KIZ/F6pvE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Fri, 6 Aug 2021 07:29:36 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S29ZATCWLK005PTU@mauve.mrochek.com> Date: Fri, 06 Aug 2021 07:05:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Aug 2021 06:18:01 -0700" References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 14:31:51 -0000 > >> In practical terms, this reduces to: > >> > >> "A trace field is anything we declare a trace field. There are no > >> inherent or common technical characteristics or semantics." > > > > I offer a different view: > > > > "Any field added after initial submission is a trace field." > > > > I agree with the second sentence. > Here's the thing: > Recently, there was an extended group focus on debating that a new > proposed field had to be labeled a trace field. > If there are no common syntactic or semantic characteristics to such a > field, then was is the functional benefit in assigning the label of > 'trace' to it? There most definitely are common semantics. A trace field is used to record information about the current message tranfer operation, and as such is not a normal MUA->MUA communication field. Among other things, this means that MUAs shouldn't be generating them, and even more importantly, should not be re-introducing them when copy stuff from an existing message to a new one. And since there are some very badly written MUAs out there, submission servers would to well to take note of any trace fields an MUA seeks to introduce. Another one: Since MUAs aren't supposed to be generating them, they should never contain message content. This means auditing systems barred from storing message content can record them. The common security considerations are also significant. Trace fields can expose internal details about how the MHS is structured within an ADMD, and as such may require special processing by security gateways. The issues with Received: are well known, but Delivered-to: specifically can expose details of the mailing list expansion process, which can include internal sublist expansion points, use of which can bypass access checks and content scanning. (Yes, the use of sublists is security by obscurity, but that doesn't mean it's not done.) This is one thing X.400 got right: Trace fields are part of the message envelope, not something that's conflated with message content. In fact X.400 goes so far as to distinguish between internal and external trace information. Internal trace information is supposed to be removed when a message leaves an ADMD. (The way they separated things has some issues, but that's hardly surprising given when all this was designed.) Delivered-to: definitely qualifies as a trace field, and should be labeled as such. Ned From nobody Fri Aug 6 08:36:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68093A3361 for ; Fri, 6 Aug 2021 08:36:38 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=aQmmp9v2; dkim=pass (2048-bit key) header.d=taugh.com header.b=kdV+7sdJ 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 aTJ1kO8UZ3IO for ; Fri, 6 Aug 2021 08:36:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 50E983A338E for ; Fri, 6 Aug 2021 08:36:33 -0700 (PDT) Received: (qmail 2045 invoked from network); 6 Aug 2021 15:36:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7fa.610d56fe.k2108; bh=deGsjgTEqhz7ZsA/MVJvMQGltyK2aLXOWCyaKfGfrXg=; b=aQmmp9v2JWIxOgWwfCn2montZLkvnY1JFcJ6IXoEZgIaKzOZdOrrqgTWsAZNx7PZB/CGu2NatrL7Y10XCAqUeiMTkUKtfB1i6Ro0BVYwRKYQXAwZcTIixRr9YWa45oepsvqxRwx1ljFX6IJf1+cwAq9FufRCfJ8l5n6Ep4h9kz/oi7riYwq0Gpr/FnRBeFBgHlxJxmzCPtySoglnIPZb0qaXvY0RSbFUBdHin9UyUuI8RbO7ie48W7uvTikdHTmVRBFVJP65Xx/RYAFxZzOv8dSyZpIQ2l5XllPhBZQXs5nf6GUfQvkAEcNptBTYLeVBOqJ5xAyqyO4vKLY16KZIVw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7fa.610d56fe.k2108; bh=deGsjgTEqhz7ZsA/MVJvMQGltyK2aLXOWCyaKfGfrXg=; b=kdV+7sdJjQRyTW1KCBoZgyIS1oS9kp6zL73t8X3uwII4IrBdu6iJ1k0g2rpyBDI/ffNq7Xh9m3i//mfzq7wqqpqjNLDI7f5hcVDx1AbvqMHQguoPFixCUVAODMgmX3Q/pr+8bQnpBVrXZPgQB+JvH4McH4H5zrUZjLHZOcPO+GSrqUYz6eNc5WXz0tNygOrnIrZVnyICIguTVpYoey50cLlcBmBXi5BSLzyl1p7V9AkrLl/8Xcf7vUGvPH4n24EElaVmPm6LtKLGBunKpJvUcZ4ZZEQnoii7OfV+tGfXycsBUe3g65NPWCrkDp9CqnEAjh2j1rN6ANo+DTjLnhstiQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Aug 2021 15:36:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 7A49725A74A1; Fri, 6 Aug 2021 11:36:27 -0400 (EDT) Date: 6 Aug 2021 11:36:27 -0400 Message-Id: <20210806153629.7A49725A74A1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01S29ZATCWLK005PTU@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 15:36:39 -0000 It appears that Ned Freed said: >Delivered-to: definitely qualifies as a trace field, and should be labeled >as such. At the risk of poking the hornet's nest, do you mean Delivered-To with an envelope address or with a loop breaking token, or doesn't it matter? I can't immediately think of a reason why they wouldn't both be trace headers. R's, John From nobody Fri Aug 6 08:43:23 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770643A3395 for ; Fri, 6 Aug 2021 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 vMRgvKq9Fwm5 for ; Fri, 6 Aug 2021 08:43:16 -0700 (PDT) Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) (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 1E6013A3397 for ; Fri, 6 Aug 2021 08:43:15 -0700 (PDT) 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 9A490920B81; Fri, 6 Aug 2021 15:43:13 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 6CB729208DA; Fri, 6 Aug 2021 15:43:12 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.100.96.105 (trex/6.3.3); Fri, 06 Aug 2021 15:43:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Macabre-Slimy: 1d44490c5198a2d7_1628264593396_3600587790 X-MC-Loop-Signature: 1628264593396:3110932789 X-MC-Ingress-Time: 1628264593396 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 46F9510E9E4F; Fri, 6 Aug 2021 15:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628264590; bh=eF0BGQ2aTAEnY8RfsFePr/sEyHYjkAq/9Fy/r6A1ass=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=ishlU2XWqtkg6vEgVD9zlfQ6ZqqEEtAajiIgVqr7hU6wwPU16nGGzmia2wtvOPllf yC/doT4vHy33TSNlGrAy6lmLMvoZth7Rm2rAuyAoVRdLhoRKmbX5KRQB0MHyyDgK9U 7VNOwIXgmOpJms3rRCuRKxofn0hiQl2qQMMR40JUY5iZXtOucCMq1G2jXSZJtW2+tM pVmJ98KyGY0Dam9Pyl3aoeOgpslJzzIaOhtQcYE8MMwpS2tv21+foKqhGGU+TDWMTn FrmvZXfXsLMv7pslbXq3Rt0tqihqUrXUh5hQZ+oODxndSQkPvAlc2miW3Adl90GfOA rbmmIty3jNfpQ== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: ned.freed@mrochek.com References: <20210806153629.7A49725A74A1@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8a920d97-6500-c8d1-338e-7a5ed0e0625b@dcrocker.net> Date: Fri, 6 Aug 2021 08:43:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210806153629.7A49725A74A1@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 15:43:22 -0000 > At the risk of poking the hornet's nest, do you mean Delivered-To with an envelope address > or with a loop breaking token, or doesn't it matter? John, In spite of your confident and repeated claims, you have yet to provide any actual evidence that these are different. But that's over on the SMTP mailing list, so perhaps such matters of fact aren't relevant here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 6 09:25:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBCE3A0138 for ; Fri, 6 Aug 2021 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 izHKuPqLO92r for ; Fri, 6 Aug 2021 09:25:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545D33A012A for ; Fri, 6 Aug 2021 09:25:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mC2eb-000BOS-5M; Fri, 06 Aug 2021 12:25:01 -0400 Date: Fri, 06 Aug 2021 12:24:55 -0400 From: John C Klensin To: Ned Freed cc: emailcore@ietf.org Message-ID: <973BBD9E91EB9A745A321A59@PSB> In-Reply-To: <01S29ZATCWLK005PTU@mauve.mrochek.com> References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> <01S29ZATCWLK005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 16:25:10 -0000 FWIW, I strongly agree with Ned's analysis, including the comment about X.400 and its layered envelope. I also, fwiw, agree with the suggestions (by John Levine and others) that it would probably create much less short-term, and perhaps even long-term, confusion if we added "Main trace" or some such thing to the existing registry rather than create a new one. If _we_ don't have strong consensus about what trace fields are or are not, it is unreasonable to expect that random people looking for things in registries will know where to look if we split trace fields out. Additional comment: I don't want to open this can of worms, much less start a long discussion or subject Pete and myself to the actual extra work of making a change, but this and other recent discussions on the topic make it increasingly clear to me that, insofar as trace fields are inserted as part of the transport function, we should have defined their application, syntax, and semantics in 2821/5321 rather than putting them into 2822/5322 because they are syntactically header fields. Among other things, breaking things down that way would have made for an extremely simple and clear definition, e.g., if a [transit] MTA (or maybe a gateway) put something in, it is a trace field and, if not... Of course, it isn't quite that simple given intermediate systems that attempt to do validation or malware-checking and then document their actions, but 5321bis/5322bis don't talk about that, at least so far. best, john --On Friday, August 6, 2021 07:05 -0700 Ned Freed wrote: > >> >> In practical terms, this reduces to: >> >> >> >> "A trace field is anything we declare a trace field. >> >> There are no inherent or common technical >> >> characteristics or semantics." >> > >> > I offer a different view: >> > >> > "Any field added after initial submission is a trace field." >> > >> > I agree with the second sentence. > > >> Here's the thing: > >> Recently, there was an extended group focus on debating that >> a new proposed field had to be labeled a trace field. > >> If there are no common syntactic or semantic characteristics >> to such a field, then was is the functional benefit in >> assigning the label of 'trace' to it? > > There most definitely are common semantics. A trace field is > used to record > information about the current message tranfer operation, and > as such is not a > normal MUA->MUA communication field. Among other things, this > means that MUAs > shouldn't be generating them, and even more importantly, > should not be > re-introducing them when copy stuff from an existing message > to a new one. And > since there are some very badly written MUAs out there, > submission servers > would to well to take note of any trace fields an MUA seeks to > introduce. > > Another one: Since MUAs aren't supposed to be generating them, > they should > never contain message content. This means auditing systems > barred from storing > message content can record them. > > The common security considerations are also significant. Trace > fields can > expose internal details about how the MHS is structured within > an ADMD, and as > such may require special processing by security gateways. The > issues with > Received: are well known, but Delivered-to: specifically can > expose details of > the mailing list expansion process, which can include internal > sublist > expansion points, use of which can bypass access checks and > content scanning. > (Yes, the use of sublists is security by obscurity, but that > doesn't mean it's > not done.) > > This is one thing X.400 got right: Trace fields are part of > the message > envelope, not something that's conflated with message content. > In fact X.400 > goes so far as to distinguish between internal and external > trace information. > Internal trace information is supposed to be removed when a > message leaves an > ADMD. (The way they separated things has some issues, but > that's hardly > surprising given when all this was designed.) > > Delivered-to: definitely qualifies as a trace field, and > should be labeled > as such. > > Ned From nobody Fri Aug 6 11:22:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4013A0E14 for ; Fri, 6 Aug 2021 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=servicenow.com header.b=rJdh1sa7; dkim=pass (1024-bit key) header.d=servicenow.onmicrosoft.com header.b=edyNRxTH 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 5KXjOFqF0cYq for ; Fri, 6 Aug 2021 11:22:13 -0700 (PDT) Received: from mx0a-0017dd01.pphosted.com (mx0b-0017dd01.pphosted.com [67.231.157.3]) (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 9BD093A0DFB for ; Fri, 6 Aug 2021 11:22:13 -0700 (PDT) Received: from pps.filterd (m0047391.ppops.net [127.0.0.1]) by mx0b-0017dd01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 176IKp65024108 for ; Fri, 6 Aug 2021 11:22:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=servicenow.com; h=from : to : subject : date : message-id : content-type : mime-version; s=MAY-2020; bh=OYls4+tdpKSDT9Bfx8bIUVWkz46OOK7wIpTVkQ3/oSU=; b=rJdh1sa7t8zWep7PywgmWjPVgSlh5AcGUdn7hZc4xmGPQzyvSt/D1SHriE51nVE7pVsy M+E55fc9y2g4k+44bwJEHfXQET8pPu8dY7H5Ndg0aeFPSYv6d3C/8bY9/g9PCoCIEARt hvWTvgRlbADbTGclUZTd4SIR9RHh4A5uszpzWWUyEnxoLK5B3C1RShi1DXBYWgL+UjnA 2TPE5oQeGDcHYZrS6cEV2c9Sm4hTkU8sRKD/0MwLnIQbfEznVP1gOEaSRjnHFJviD9AO MUvLtpmzCAbVPgCGqUXZUglgqDFxbADFfg8dnnawCNZ0hc/LJYF6wT+jj2iMR/fIFjq2 iw== Authentication-Results: Servicenow.com; spf=pass smtp.mailfrom=tom.perrine@servicenow.com Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0b-0017dd01.pphosted.com with ESMTP id 3a98vdgefp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 06 Aug 2021 11:22:12 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ECO+assiOo3H+iVlFZGoFOPVTRwmpnfCIoDY5DQEujUde+88VRRfS0EKe1gQpB+CkGpw4FWWCv/Y38jrRTbq3f1knEpknCsBWD6TmuuxKWJEGmfGcq4S0JyROormgK0E4hLeG2kTVRnR1HCHW1wRqoYmg9lGZx63gKutK9w2BbwPNUBC6JOVJdzYOeUG4hLYAgZ1eUi7FPw2VjFjnJAv27KGcQZXGgh3NU2TUXR9rO047ugfHmnzPL6IvKi9tDHsvueNcH5RH3D3IJ8Em9TW280RWlixE2cCfLQVCQXDvMdQA8Ht1IvE6P9MtCGgmE+JpCIiPk0zMNhcP1nuv8mnkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYls4+tdpKSDT9Bfx8bIUVWkz46OOK7wIpTVkQ3/oSU=; b=m7ZLNv9dslcn562fwQwOpgc1s3TbPE+14u7NLVx5Q2azPaszZZniJlPvLjYNBpa5QSO+BlX/2DbeHkgIW20uo0QRhjw4m0ZmR9OUSkX+Cc0LfFoCdMy+mABJlURnSXgrYYLikCIiTs/fAyUO8QjfKQt9GValDUB/sD8RczJ/RYrTuKUgzu8FBvqgoLlsy/JYInyfQaX2rY0Fh70rOTWknC5z0SoQufYIE85SiRwSEg2k6ax2hG3uW2HuD0hJHF10u4FLdimJynmKPRrZCKGkFdjDQ4sNoHAoCBksvn/XeD+OFRqIRLa4qmrqS3X6b+BRRvWh7eitG4zWxiXdblwqAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=servicenow.com; dmarc=pass action=none header.from=servicenow.com; dkim=pass header.d=servicenow.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=servicenow.onmicrosoft.com; s=selector2-servicenow-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYls4+tdpKSDT9Bfx8bIUVWkz46OOK7wIpTVkQ3/oSU=; b=edyNRxTHyCDSvhhxs36EIDMegTbWgIIhS7B2IarCT5zAzfIuwiCuJ9ec7ZJ574T2EERAUluqEFnaqm61g88ZUzn1zcVwhTU0my9gWhIwcYb8gXNJDHdVSffXeR6emlLyYYeZXedjekxi4NiM7i5H3VcFyXvpIGPUkMaZsYh5cxA= Received: from SJ0PR08MB6815.namprd08.prod.outlook.com (2603:10b6:a03:2d2::10) by BYAPR08MB4661.namprd08.prod.outlook.com (2603:10b6:a03:46::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16; Fri, 6 Aug 2021 18:22:10 +0000 Received: from SJ0PR08MB6815.namprd08.prod.outlook.com ([fe80::615e:b6bc:9fd9:3f86]) by SJ0PR08MB6815.namprd08.prod.outlook.com ([fe80::615e:b6bc:9fd9:3f86%5]) with mapi id 15.20.4394.019; Fri, 6 Aug 2021 18:22:10 +0000 From: Tom Perrine To: "emailcore@ietf.org" Thread-Topic: "Trace" headers and header pre-pending? Thread-Index: AQHXiu/4FBQ4y+8Kr0GrfDBKVx94/w== Date: Fri, 6 Aug 2021 18:22:10 +0000 Message-ID: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=servicenow.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36c17836-40b9-43d2-b8f1-08d959071b02 x-ms-traffictypediagnostic: BYAPR08MB4661: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wyMwC5jcPq1NW/KMJ2BYLj8d6JXwIH3Z9p3K8+AAElOvyh9NmYceE7eC6M7nu2PDgzMajRRpsZ4ackHiE0G0+0ET5BAIVRVaLKzGcS/6gjneyGg+gTOxt8CJ8BA9Oc+5kuiSwrVrrehi7trcia7o8FyC9KRWpmeii+J62rPKPCxiHst5JwcS8ghPlQ1zey2dmQn6bkND3BcID8RRDMtxmjEputvKgdmmI1tEiDZasqJwhhw6sLHwq/tdA2vWDk2DedCTSGmDWlNvYxCdAJielelckgBvQuN/eoI8Ke6K6QUzGoU/+HKqy2/53D1rOBVIpDNMP85CfFfMkiiX3+pcWIBDoCMZsvRq+Tpb1ox3YLxBGAE5P6pL6C5YxJj1nrJAZ8520rILWpy7XLr2Hz4e7xImGm6EqKQHix4mtcSlq1AersIrwRelB6KlUz0M9gigmHJuujXefaMPLMQFJ7iprw1U06li7IH/erytQx/YJ4q1bFJvgXFPP1MyxfOMaaZRrPaHWsLARbuAm21JjyLCgM6YVXXZbdP3eOzIgWuArp2GEn03Nvnt58Vo5muwvhykQaRv2U9wuLJUJXKsQBESGdDIEg9eFqCnvmioTGPP5dZINqLO6DLWeZLRvHwXxoErI0Ue/BV/nTZnO50UIunsv18bDisUsPQrM0wW4qb63GHRyCMsh7Drb+XvboRjAI1ZsquZnZZCsP+0KUSgMiRmyJIn7AQfFnoRIPTvb8uQH6nUTXG/GizvNcICqQghEbhx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR08MB6815.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(6506007)(76116006)(66446008)(6916009)(316002)(33656002)(4744005)(478600001)(8676002)(86362001)(5660300002)(38100700002)(186003)(71200400001)(6486002)(26005)(44832011)(2616005)(36756003)(6512007)(122000001)(38070700005)(8936002)(66946007)(66476007)(66556008)(2906002)(64756008)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?K3p3OUZmK3ZYTzhxNkE5MVBHeHJNZHJyWGJmRXVRQVBBUS9FSDFSNU9CMVFV?= =?utf-8?B?M2tvN1dIMk43Rno5VXh5NzRuZ2F2WlF6TmVTYktlYWE0ZVlmd3RYSnVaMnp6?= =?utf-8?B?QTM1RTExdTR5dEpuWmpqZC9GMVpHQWhyM1Y4cUhUOWFDMmkydkdkK2R2KzIv?= =?utf-8?B?U1ZRUnNEdEJJVE1LUUV1OE5yL0FtaGk2NXZtOEZSbGRDbTd5M0F0V0s4OEI4?= =?utf-8?B?OXEyMGp4bUtncTYrY2VBMy95czB5OEtqQnpyeFJ3d3Q4K2JLOStNbmZqd1Er?= =?utf-8?B?N3JRZk55MFZaMUV4RHpEaVRyV25SUm56MjZ1eElMUCtMS2JGU1l3d3hSUytk?= =?utf-8?B?MjRCcXVFalR3a1RNRUgxUGFIajNkcGREa0NTR29QdDhwN0pHUFhqR2ZpVEpZ?= =?utf-8?B?dFA4SWxZQ04veU41dzU2cDFzRmNSU2hDOXdHVjN6dm9jZnFSa0ZlRzY5SWNS?= =?utf-8?B?b2pHN2wvT1JJbEdrTjA2NU9CT3o2dFZkQ1Y2TmFMUWxiZ3FiRGhXeXd6aTVQ?= =?utf-8?B?a1lYKzFaZS9iQnRySVdUNlVCZnNSRDVXV2ljY212ZGRuMzVlMnZjVDZpOGZX?= =?utf-8?B?L1ZQd01ENklvdENRUjZlTjNkRFdBK0pkdzlkR1hVRmt1dFlaMVhydjNJcVFl?= =?utf-8?B?citMMHluZmttQ2xHeHFic3FyUlhpNXNzcFE2UzBtTWhobjVFc1NyazdVajF4?= =?utf-8?B?TStySU1XMklGdGs2UVhNRkM1RWJRelNXRVplb1VtUU5vRWVVUmx0bFNpMXlU?= =?utf-8?B?Q3hZVENwM1JGYjVnMnMrU2FJSUE0THpYem5kbVhkZTErS3grcWZubjNFRTF3?= =?utf-8?B?Mm5QVFBTalBrUTZMelZCeU1wd1lucG5seHJMNk50UmExMW5hUVRmYWhIaVhj?= =?utf-8?B?MTljY3Z5S1pFOVhnU2pTNUUrb2FvSEdvU2tqblhoaFNhVDRtSTRTVm1TbTho?= =?utf-8?B?TXNMUDFBdllFNWRmNUtmNWZxbUxkSEx2R1prME1wSHY1ZVFKWmVWd2xSR1dk?= =?utf-8?B?YzA3OXo5aWk3bXFWL3A4MjRtUHhtMEI3M3hqNGxGSW16RmhiUTFRRGdQRUt0?= =?utf-8?B?WGpyRXgyclZndE1GZTgvQ1RWY0sxSitEblVhdFdqR3ppbnYwbEZOblh6R2xT?= =?utf-8?B?M3N5Q05CV0huUVd4dTdhV09SRnRTSXJlcHNJZlFlckYwMlpaWTVlM3laSVNB?= =?utf-8?B?ZEtMc2xzTzVUY3NRS3dIU1VrNVM4NFFaMjdYTHMvajBWMFlNSitZbGx6cmdB?= =?utf-8?B?REh0Z1NKZUpycVhrdC9QUjZ2SzFSVEh3UFpPaGlPQUZwemo3bWVTSmNRT2JV?= =?utf-8?B?bGxSaW5IY1dCWTFxajJEWXBqZDVsUm1aVnVIZmgyWE5BbnRlcTNhVHZ3eXRZ?= =?utf-8?B?TGNzYjYwUVVKY2tERVdJOW5KMFpyUCtvdGpmTktiakpEWk93Y1h1cWRzTFNo?= =?utf-8?B?T3lVQmFlblNlMW5lZGFERzBSTE9rdFhWWllIa21Vbk1CbG5aZW40d3Uzcjd6?= =?utf-8?B?Z2RoT0pmQno1K1J6azg1RDV6UkFrbmJ0R0hFZkF4YkFUVExjN3YwbTYrYndJ?= =?utf-8?B?dVI3bEgzNUdPeVdkNE1kSkdSall6WkY2Y3VDNHlzOGFSeUI4QnFDZ3A2SEJR?= =?utf-8?B?Slpxb3Fwb1ZFbmpMY2N2YUphMEpVNThUdGFOaEtHaDRYVDNVSkZPZWRoT2ll?= =?utf-8?B?SW91bVNiZVFiYlNVRDZJTUErclUxbnpuQkdRaUpIUEl6SkV2YWRaenVEY296?= =?utf-8?B?aTZqR0FqVEJ4QS9ZM0VwbnFhN2hsajM4LzNqWk1GQldKbnpMQmFHRUtLM1Fh?= =?utf-8?B?SUFOTkRaNkVwTUdtTG90QT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4552B392B208419BBAB15331DD0D438Eservicenowcom_" MIME-Version: 1.0 X-OriginatorOrg: servicenow.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR08MB6815.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36c17836-40b9-43d2-b8f1-08d959071b02 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2021 18:22:10.1635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8bcff170-9979-491e-8683-d8ced0850bad X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iTvtGPcRWW0tV4FcsALFlYn0aCSSiKDjH7rTxPETZ7ux0ZJTvAH/w78Tdsg3Tea0WeoZ5nuiUjUy7+00/CQtToH4TdPlegvh4P4z3tBOf58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4661 X-Proofpoint-ORIG-GUID: oh1OWj8tz6STheKbL8EEjrnhBANlhjdA X-Proofpoint-GUID: oh1OWj8tz6STheKbL8EEjrnhBANlhjdA X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 include:spf-0017dd01.pphosted.com include:spf.protection.outlook.com ip4:70.34.48.120 ip4:192.35.250.0/26 ip4:204.92.21.125 include:allegiancetech.com include:_spfinc1.servicenow.com include:spf.afas.online ~all X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-06_06:2021-08-06, 2021-08-06 signatures=0 Archived-At: Subject: [Emailcore] "Trace" headers and header pre-pending? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 18:22:18 -0000 --_000_4552B392B208419BBAB15331DD0D438Eservicenowcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2V0dGluZyBhc2lkZSBhbnkgZGVmaW5pdGlvbiBvZiB3aGF0IGNvbnN0aXR1dGVzIGEgdHJhY2Ut cmVsYXRlZCBoZWFkZXIsIG9yIHdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGEgZGVmaW5lZCBsaXN0 IG9mIHRoZW0uDQoNCkkgaGF2ZW7igJl0IGZvdW5kIGEgcGxhY2UgeWV0IHdoZXJlIOKAnGZvcndh cmRpbmcgc3lzdGVtcyBNVVNUL1NIT1VMRCBwcmVwZW5kIGFueSBhZGRlZCBoZWFkZXJzIGluc3Rl YWQgb2YgaW5zZXJ0aW5nIHRoZW0gYmV0d2VlbiBhbHJlYWR5IHByZXNlbnQgaGVhZGVyc+KAnSBv ciBzaW1pbGFyIGxhbmd1YWdlLiBUaGlzIGlzIGJlaW5nIGRpc2N1c3NlZCBvdmVyIGluIHRoZSBt YWlsb3BzIG1haWxpbmcgbGlzdCBhcyBhIHByYWN0aWNhbCBpc3N1ZS4NCg0KRGlkIEkgbWlzcyB0 aGlzIGluIGFuIFJGQyBvciBkcmFmdD8gSXMgbWFraW5nIHRoaXMgcHJlc2NyaXB0aXZlIHdvcnRo d2hpbGU/IElmIHNvIFNIT1VMRCBvciBNVVNUPw0KDQpNb3N0IGZvcndhcmRlcnMgc2VlbSB0byBk byB0aGlzLCBidXQgc29tZSBhcmUgYXBwYXJlbnRseSBvYnNlcnZlZCB0byBub3QgcHJlcGVuZCBh bmQgdG8gaW5zZXJ0IGhlYWRlcnMgaW4gdGhlIG1pZGRsZS4NCg0KDQpSZWdhcmRzLA0KVG9tIFBl cnJpbmUNCg0KDQoNCg== --_000_4552B392B208419BBAB15331DD0D438Eservicenowcom_ Content-Type: text/html; charset="utf-8" Content-ID: <2D58A09AAE5BC64CA0DA4D7B00781221@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ill1IEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxAWXUgR290aGljIjsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNldHRpbmcgYXNpZGUgYW55IGRl ZmluaXRpb24gb2Ygd2hhdCBjb25zdGl0dXRlcyBhIHRyYWNlLXJlbGF0ZWQgaGVhZGVyLCBvciB3 aGV0aGVyIHRoZXJlIHNob3VsZCBiZSBhIGRlZmluZWQgbGlzdCBvZiB0aGVtLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGhhdmVu4oCZdCBmb3VuZCBhIHBsYWNlIHlldCB3aGVyZSDigJxmb3J3 YXJkaW5nIHN5c3RlbXMgTVVTVC9TSE9VTEQgcHJlcGVuZCBhbnkgYWRkZWQgaGVhZGVycyBpbnN0 ZWFkIG9mIGluc2VydGluZyB0aGVtIGJldHdlZW4gYWxyZWFkeSBwcmVzZW50IGhlYWRlcnPigJ0g b3Igc2ltaWxhciBsYW5ndWFnZS4gVGhpcyBpcyBiZWluZyBkaXNjdXNzZWQgb3ZlciBpbiB0aGUg bWFpbG9wcyBtYWlsaW5nIGxpc3QgYXMgYSBwcmFjdGljYWwNCiBpc3N1ZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGlkIEkgbWlzcyB0aGlzIGluIGFuIFJGQyBvciBkcmFmdD8gSXMgbWFraW5n IHRoaXMgcHJlc2NyaXB0aXZlIHdvcnRod2hpbGU/IElmIHNvIFNIT1VMRCBvciBNVVNUPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3N0IGZvcndhcmRlcnMgc2VlbSB0byBkbyB0aGlzLCBidXQg c29tZSBhcmUgYXBwYXJlbnRseSBvYnNlcnZlZCB0byBub3QgcHJlcGVuZCBhbmQgdG8gaW5zZXJ0 IGhlYWRlcnMgaW4gdGhlIG1pZGRsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9tIFBlcnJpbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4552B392B208419BBAB15331DD0D438Eservicenowcom_-- From nobody Fri Aug 6 11:34:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1C3A0EE3 for ; Fri, 6 Aug 2021 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 uLLJOoMKNk6i for ; Fri, 6 Aug 2021 11:33:54 -0700 (PDT) Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (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 7965C3A0EE8 for ; Fri, 6 Aug 2021 11:33:54 -0700 (PDT) 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 3FBD710201F; Fri, 6 Aug 2021 18:33:53 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-104.trex.outbound.svc.cluster.local [100.96.16.104]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3B44A101F02; Fri, 6 Aug 2021 18:33:52 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.104 (trex/6.3.3); Fri, 06 Aug 2021 18:33:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Army-Quick: 313d10b325ee7b29_1628274832621_3366781587 X-MC-Loop-Signature: 1628274832621:2186217846 X-MC-Ingress-Time: 1628274832621 Received: from [192.168.0.112] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id C41E710E9E57; Fri, 6 Aug 2021 18:33:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1628274829; bh=jn+I9gt77h6bzUFJrpIzWiwAwcm9NgMNv8ZG78EBLQU=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=PaBQdJEIKfVNY4AcuRyPhlEB80pUY7XAZlV8x2RdB+wh7WnKibqXpdZSC7NyIwMGC qqQemIa1lDoKxMysrdLP5gm9nD9J5Re0kQNZwsLzK9LXtzT60s6Bs2OHERT2Z7DkU5 uv7lPCHseevbrq9oeJJXMbZCeJSZAjuIUmzt0yr/OIn8Z1CLQ6nCB1XSxyKAD9BHik 7KVpL2oBn1q2Q7ud3z7z0Ab23/3VOmM7KCEPwJrQfroz1uI0PD8ZuowaXgPeDBl0rW 3mnF4MCcR/GuQjMD1Gilj9CAwTrsO4pb+orouVkfe2BfuA6onTlDorD1l1KlkNSaq7 CdJaiVafRWZ6w== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: emailcore@ietf.org References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> <01S29ZATCWLK005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 6 Aug 2021 11:33:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <01S29ZATCWLK005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 18:34:00 -0000 On 8/6/2021 7:05 AM, Ned Freed wrote: > There most definitely are common semantics. A trace field is used to > record information about the current message tranfer operation, and > as such is not a normal MUA->MUA communication field. So, a mailing list should not add any trace information? > Among other > things, this means that MUAs shouldn't be generating them, and even > more importantly, should not be re-introducing them when copy stuff > from an existing message to a new one. And since there are some very > badly written MUAs out there, submission servers would to well to > take note of any trace fields an MUA seeks to introduce. So a message that transit a mailing list should have all handling information, which was produced in getting the message into that list's inbox? The recommendation is that all handling sequence information involving a sequence of delivery/post activities, should be lost? d/ ps. As for common semantic, I think what you've described is a common type of activity in their production and in their handling, but no specific semantic associated with it them. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 6 13:32:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD693A1604 for ; Fri, 6 Aug 2021 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 j4xzXQYSYgB3 for ; Fri, 6 Aug 2021 13:32:04 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E403A15F4 for ; Fri, 6 Aug 2021 13:32:03 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id B52A35287; Fri, 6 Aug 2021 22:32:01 +0200 (CEST) Date: Fri, 6 Aug 2021 22:32:01 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210806203201.GA20038@hjp.at> References: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] "Trace" headers and header pre-pending? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 20:32:18 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-08-06 18:22:10 +0000, Tom Perrine wrote: > Setting aside any definition of what constitutes a trace-related header, = or > whether there should be a defined list of them. >=20 > I haven=E2=80=99t found a place yet where =E2=80=9Cforwarding systems MUS= T/SHOULD prepend any > added headers instead of inserting them between already present headers= =E2=80=9D or > similar language. This is being discussed over in the mailops mailing lis= t as a > practical issue. I don't think there is such a requirement in general. There is a requirement that "trace headers" (whatever they are, apart =66rom the two explicitely mentioned in RFC 5322) are prepended, and another for the resent-headers (which also need to be added as a block). There is language in RFC 5322 which suggests that the trace headers should form a contiguous block at the start of the mail (which would mean that any non-trace header should be inserted after the trace headers, i.e. somewhere in the middle). I think this is a bad idea. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmENnDwACgkQ8g5IURL+ KF3m0BAAnqTXxrL01ptdaIsysoxYOdsCV1IVkf1FX8EO6UBQswyzGfuDAB91LD9i +sIhbO0G9QEf0Mw5id2G7WMsrkOOkSWdQo8LWVvhMyOL4Wyujtmx98Ct1tImTpcm aFxVzH8BsBo6DwbCB81zks0HLy07Yh2ORkEIwTNLNA8A0WrWshD9Adh/1bYK06GM Aan65ghpCl8fQ8hazSQNqwHBbDewZhqdvkGPYhFR0nlrwFkWy4GDvKOSS7rvzy88 4YH25p39G+D3snQTlqlze1JWTaDIOukiqZzNcN70aNskVig3qP9qSlmMlFL81RVM uaYGyhyxnaNbASQVMyo7q4uISBKNGXhmVq/USUQlHJsj4NgW7mdDIoycbXr9IX5R o4fZvBcjA0omstBvLFvp/egdnd5HIm/NbU1o+MYH4qB38tymAykZKfTanp3PQ8YH NBEotb/Mb+GrOO7gDgHuXwwC5QujmSIUA+JP7r6dLEcfjjIk12+iWjNQu5q0XogZ BndKR8Mp6z6D5EIMXpdvWbwcLrdPLz2wIX7YqHHd8rIHBffYn+J8wEaVJNwQaj8/ bBolnyuEB8kIEzGDmRvDPsoun4aYDBFRcLz3ftti+9K5cIrNu8VoENUW0+PfZYSo wQyQJGr6w1MojBHhGiNM9xyyZ0yWK79BYFqUhix4Orhs/NDGpVY= =EfiM -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From nobody Fri Aug 6 13:54:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D953A16F4 for ; Fri, 6 Aug 2021 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 whDWmnpAe3J5 for ; Fri, 6 Aug 2021 13:53:55 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D973A16F0 for ; Fri, 6 Aug 2021 13:53:55 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 725575287; Fri, 6 Aug 2021 22:53:52 +0200 (CEST) Date: Fri, 6 Aug 2021 22:53:52 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210806205352.GA25317@hjp.at> References: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> <20210806203201.GA20038@hjp.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20210806203201.GA20038@hjp.at> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] "Trace" headers and header pre-pending? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 20:54:00 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-08-06 22:32:01 +0200, Peter J. Holzer wrote: > On 2021-08-06 18:22:10 +0000, Tom Perrine wrote: > > Setting aside any definition of what constitutes a trace-related header= , or > > whether there should be a defined list of them. > >=20 > > I haven=E2=80=99t found a place yet where =E2=80=9Cforwarding systems M= UST/SHOULD prepend any > > added headers instead of inserting them between already present headers= =E2=80=9D or > > similar language. This is being discussed over in the mailops mailing l= ist as a > > practical issue. >=20 > I don't think there is such a requirement in general. >=20 > There is a requirement that "trace headers" (whatever they are, apart > from the two explicitely mentioned in RFC 5322) are prepended, and > another for the resent-headers (which also need to be added as a block). >=20 > There is language in RFC 5322 which suggests that the trace headers > should form a contiguous block at the start of the mail (which would > mean that any non-trace header should be inserted after the trace > headers, i.e. somewhere in the middle). I think this is a bad idea. More specifically: The syntax allows optional-fields and resent-* interspersed between trace headers but not the other fields defined in the RFC (orig-date, =66rom, sender, etc.). But the text in 3.6 says: | More importantly, the trace header fields and resent header fields | MUST NOT be reordered, and SHOULD be kept in blocks prepended to the | message. which suggests to me that all the trace headers should be kept together in a single block. It could be read as "1 or more blocks of trace headers interspersed with 0 or more blocks of resent-headers", too, which would be more consistent with the grammar. In any case it doesn't accont for the optional-fields which are also allowed by the grammar. There is also a sentence in 4.5: | Also, the interpretation of trace fields and resent fields that do | not occur in blocks prepended to the message is unspecified as well. So when is a trace header not "prepended"? If it occurs after an "X-Spam-Score" header? Or only if it occurs after a "Subject" header? hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmENoVsACgkQ8g5IURL+ KF3w8RAAhQyhyu6LiGT8heQVHlvhpOKZ2mSpCqynvY6rviUXpZB5sOuKV2/JJR0z +z8UZsuIpluTXmXDxdYhmDpsKmCGsxzaBv0/WhL0ruD/O1DyKjTfpt6FzBk5Ja6t M7nEGftjlxV6HwCKFgmiw+yO1laXiekgsX4xvwvBkTFo2E0Cy0fwTb2WKmlQDgAa wr0BFvXioGsiZm8c3wyDDTBxQsKLNYHtQL0Mye7m8a5sIUYjbxOY7JYGWF6tNbYW mopib+qIyoKykioJxFiaMdQ/VEPmKJOcPJQPYPAgkN1FLD5diUPdq8TIv7HvDEJ/ jUzqQt//Uk0VU7fDhAgJx3qT9h+FEYD0vQnpxiUGvxbEUTmMazrC4lplW36cm7iH bRo422/OKKB75I1HngpEtiy0MJx2PahS57QYGFzDLIOktzSGkN05MpqJpL4ND+lq 7XF9RoHk+8GNSDF8s676/15apry9HISFcAeXO7gaQ90hre0g5AX90LW92H3WgFjl O8ou4fxT6+uVKpMgP6bpbVqd9xiysSJkYHR/nkRhB3NZM2NIV6wMZza2YQrzaZ8b 4ldyLHgJOgsLU7XfVph+TLW5l3VqjwlSQ+GI/ipMb0VZt8T/FTViZ+eyGXtTGH/L ZeF+l1zytm43vkMenVei9nWud63AGL/UWSA0PBUo+IVT6aKbC1M= =D2+1 -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From nobody Fri Aug 6 14:05:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941B3A1780 for ; Fri, 6 Aug 2021 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 tiz8yrhIWMYZ for ; Fri, 6 Aug 2021 14:05:15 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179E23A177D for ; Fri, 6 Aug 2021 14:05:14 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id EAB105287; Fri, 6 Aug 2021 23:05:11 +0200 (CEST) Date: Fri, 6 Aug 2021 23:05:11 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210806210511.GB25317@hjp.at> References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> <01S29ZATCWLK005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 21:05:20 -0000 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-08-06 11:33:46 -0700, Dave Crocker wrote: > On 8/6/2021 7:05 AM, Ned Freed wrote: > > There most definitely are common semantics. A trace field is used to > > record information about the current message tranfer operation, and > > as such is not a normal MUA->MUA communication field. >=20 > So, a mailing list should not add any trace information? Quite. Of course one could argue that a mailing list is not a "normal" MUA, but some kind of hybrid between user agent and MHS agent. > > Among other things, this means that MUAs shouldn't be generating > > them, and even more importantly, should not be re-introducing them > > when copy stuff from an existing message to a new one. And since > > there are some very badly written MUAs out there, submission servers > > would to well to take note of any trace fields an MUA seeks to > > introduce. >=20 > So a message that transit a mailing list should have all handling > information, which was produced in getting the message into that list's > inbox? The recommendation is that all handling sequence information > involving a sequence of delivery/post activities, should be lost? Some mailing lists might do this for privacy reasons. But I don't think this should be a general requirement, and more importantly, such a requirement would be contrary to current practice. Most (all?) mailing lists I have subscribed do NOT discard any headers, certainly not Received headers. Also, when I resend a mail using mutt's "bounce" function, all headers are preserved. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --jho1yZJdad60DJr+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmENpAMACgkQ8g5IURL+ KF2wAQ/+NTN5gOLNqi0DcdLptAnQx2fygXGMEW8uPBJFCE6/RZioUvogBY306Ppt Us6x3PT1TW1PPs+HpSxMEZMG2ByWCDCRwdWA+Fd5z1X2xMytK4lZbvl7h6OVuMNW /C162OUN0cCxfYqNj2sfvcUwZ1pb7BELiKZLSDgpfGmkh/lU3cEMgEzRducjmLcR 8MawjJewbDDko8XE3fJlsjfY83L57NewvHfpx2/O5Ld54v+eln0R3Nw4/dHrsauZ bHhs+Gv52IEsVzaUB8X1KHLRIP50jFF1rDMyKoAfA8rgIytEdUUuullkXVPmT2vP AsgE/nrHL7a3xpjJvkBVUa46rDZwPelbzqn1yUROYlWHiX5lcwWhQZGinyjKpZOC xkIR34gjeszaK7j5X7UrnzJU6fV1ODSlaqx5B5DAVNTMyB+RM+HthkeAcZMRgW8P 3+GAp00p0JQzmzF2g86zVS81NBPSopwOwjAksEJyYSIb/Wz/Jce8Wm+xMZELQBdP k05Iqr6RJN8AMhPKwiQ1yAuzWpvOl5EcEe8AhWgSLowQ0TuN1j0N3UrX86wa5V+s 01u3uW9XXCwUOlvJZY5AwEK+NsJ0kBWNE7L9Xdh1IXFPKCtwPUNJiA6lYOQ9YMug 6jp8VUxDj1EQkveU7biOxfjfY1+iN+Dp1IZADRPTPcgrYVvNXvo= =Wkgm -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- From nobody Fri Aug 6 21:28:38 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0583A28A6 for ; Fri, 6 Aug 2021 21:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 PP2Co0NmV6b2 for ; Fri, 6 Aug 2021 21:28:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 02AA63A28A3 for ; Fri, 6 Aug 2021 21:28:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S2ASFLAB1S00HMZK@mauve.mrochek.com> for emailcore@ietf.org; Fri, 6 Aug 2021 21:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1628310206; bh=8szb64Fz9If/VbzNL4ibcyd5K6k/Y+5jGNgy+8UoCmc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=faYr7dzwdGPecXleehA/LAOxSgfJJddJkwnbLmAlcH47v+pZzGPnvDNLY/RHGC2E7 Q6D1ZZ5VVX8kUSc0Mts0xb5eetO3SlIvsmad7CgDZ7NbcuakKhUaFcFCafudozmS6K PSVBofW5/ZCJro2XaCP9BQpjNpXqQmGUXYSm/fSI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Fri, 6 Aug 2021 21:23:23 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01S2ASFIR1X0005PTU@mauve.mrochek.com> Date: Fri, 06 Aug 2021 21:04:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Aug 2021 11:33:46 -0700" References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> <01S29ZATCWLK005PTU@mauve.mrochek.com> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 04:28:37 -0000 > On 8/6/2021 7:05 AM, Ned Freed wrote: > > There most definitely are common semantics. A trace field is used to > > record information about the current message tranfer operation, and > > as such is not a normal MUA->MUA communication field. > So, a mailing list should not add any trace information? Nothing I said implies that. Mail is delivered to the list processor. That would generate a Delivered-to:, assuming of course that Delivered-to:'s are being generated. The list expands and reintroduces the message to the transport, an operation which could add whatever trace information the list thinks is appropriate, although a Delivered-to: field is clearly not something that would be added at this pint. This could happen multiple times when sublists are involved. > > Among other > > things, this means that MUAs shouldn't be generating them, and even > > more importantly, should not be re-introducing them when copy stuff > > from an existing message to a new one. And since there are some very > > badly written MUAs out there, submission servers would to well to > > take note of any trace fields an MUA seeks to introduce. > So a message that transit a mailing list should have all handling > information, which was produced in getting the message into that list's > inbox? The majority of list processors receive mail directly from the MDA. There's no inbox involved. And before you say that I'm talking about implementation rather than architecture, let me remind you that you yourself have agreed that there's a path from the MDA to the MTA missing from RFC 5598. If that's no longer agreed to, then we have a very very big problem indeed. > The recommendation is that all handling sequence information > involving a sequence of delivery/post activities, should be lost? Nope. And again, nothing I said implied that. > ps. As for common semantic, I think what you've described is a common > type of activity in their production and in their handling, but no > specific semantic associated with it them. Then I suggest you reread what I wrote, because you have clearly have not understood it. Ned From nobody Fri Aug 6 23:57:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6534F3A2CE9 for ; Fri, 6 Aug 2021 23:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.com 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 yZmmqx-sDzVy for ; Fri, 6 Aug 2021 23:57:38 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42873A2D40 for ; Fri, 6 Aug 2021 23:57:33 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id h2so3047226lji.6 for ; Fri, 06 Aug 2021 23:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YMFdYcKDdwM+FIBSU8KgzD4Ce5BxBDoKGUDqtESxU6o=; b=rZUViCiW4+pGx9WiJIvqZVT25w1DCuEl4WRbXLQ1NKd19BWAzgDh1P/nHNlxJKiox7 t5TShtTUPKTWIm0TdThB8bIOub8uJ2TXTuNPLrBybjeMuLXCWJrtAER+q6JfqmduHngk vaFdTfkfG9RWhZROHLXDHG4ZfAmGruA1UjvzhKlhYGFUs3Qp3XlJUoc6yxpGsGrTb5As 4p5fuEPwd15ps1ZoLH6YVvU8haC1TtpX7nQNDIA5J9XYJGV4pZkGqlkb9znFyN2hEvm0 3b1eroY7botyjqvV1HmtfheNBANmy9l/nkrYb3itGNkqZIX8dkDhofe7g4s8j/DofNJE FjuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YMFdYcKDdwM+FIBSU8KgzD4Ce5BxBDoKGUDqtESxU6o=; b=ZATB+R6K8BMTJVmUncmQF5MWtArnhrCwSmlVodM96o3BTj7NxgzcPVvRTEOM8tNjtJ 3wtHoseqOc00INpPcqDy3pozLBW6F4MVa/OOFaqxgqQhmLY6vDGI8LRpz3XxwMtT6CB5 XqlxMLl/LrLpUr03Bmn3Zx8NbOcfDjeIzLGw4G8KJiivpjewtsXZ/3LW/UPqy1JZ3mWz k5FRvT4TU0JLFGqdaZu+X5SzIn5HzYnUjp71X2xnQdAte+rqUMd68tTWGdnqC3ua0rS3 ijYpfAFwyB8r4HHSZl8mdCbVTD88BeqGcxq2isxvvwaOEQwh4A1RZquB+1dKwNJTyMLa R+BQ== X-Gm-Message-State: AOAM532HFTvu5Dn0CP3iXD0Lx2ocIKvCdYGOyvALc4nKy+IsogDYRgHr P1psMMKc8uwa5gUDrzKYCUBdSCUFND7n+7kph6dXvF6ayzk= X-Google-Smtp-Source: ABdhPJz4Wkyh8m+v++F2G/fhToU6Ds7oMQb3mzE2XM624xOUOnsCkjhUtVp4hIhrkaFKKEt0Xj9EH0HSNfO3NeyCXYY= X-Received: by 2002:a2e:a54f:: with SMTP id e15mr8911112ljn.101.1628319450424; Fri, 06 Aug 2021 23:57:30 -0700 (PDT) MIME-Version: 1.0 References: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> <20210806203201.GA20038@hjp.at> <20210806205352.GA25317@hjp.at> In-Reply-To: <20210806205352.GA25317@hjp.at> From: Francesco Gennai Date: Sat, 7 Aug 2021 08:57:17 +0200 Message-ID: To: "Peter J. Holzer" Cc: emailcore@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] "Trace" headers and header pre-pending? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 06:57:43 -0000 On Fri, Aug 6, 2021 at 10:54 PM Peter J. Holzer wrote: > > On 2021-08-06 22:32:01 +0200, Peter J. Holzer wrote: > > On 2021-08-06 18:22:10 +0000, Tom Perrine wrote: > > > Setting aside any definition of what constitutes a trace-related head= er, or > > > whether there should be a defined list of them. > > > > > > I haven=E2=80=99t found a place yet where =E2=80=9Cforwarding systems= MUST/SHOULD prepend any > > > added headers instead of inserting them between already present heade= rs=E2=80=9D or > > > similar language. This is being discussed over in the mailops mailing= list as a > > > practical issue. > > > > I don't think there is such a requirement in general. > > > > There is a requirement that "trace headers" (whatever they are, apart > > from the two explicitely mentioned in RFC 5322) are prepended, and > > another for the resent-headers (which also need to be added as a block)= . > > > > There is language in RFC 5322 which suggests that the trace headers > > should form a contiguous block at the start of the mail (which would > > mean that any non-trace header should be inserted after the trace > > headers, i.e. somewhere in the middle). I think this is a bad idea. > > More specifically: > > The syntax allows optional-fields and resent-* interspersed between > trace headers but not the other fields defined in the RFC (orig-date, > from, sender, etc.). > > But the text in 3.6 says: > > | More importantly, the trace header fields and resent header fields > | MUST NOT be reordered, and SHOULD be kept in blocks prepended to the > | message. > > which suggests to me that all the trace headers should be kept together > in a single block. It could be read as "1 or more blocks of trace > headers interspersed with 0 or more blocks of resent-headers", too, > which would be more consistent with the grammar. In any case it doesn't > accont for the optional-fields which are also allowed by the grammar. > > There is also a sentence in 4.5: > > | Also, the interpretation of trace fields and resent fields that do > | not occur in blocks prepended to the message is unspecified as well. > > So when is a trace header not "prepended"? If it occurs after an > "X-Spam-Score" header? Or only if it occurs after a "Subject" header? Prepended is not appended. You just add the new trace header to the top of the current block of header= s. Francesco > hp > > -- > _ | Peter J. Holzer | Story must make more sense than reality. > |_|_) | | > | | | hjp@hjp.at | -- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Sat Aug 7 03:56:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1803A3629 for ; Sat, 7 Aug 2021 03:56:44 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 nyNbf94P1RM8 for ; Sat, 7 Aug 2021 03:56:39 -0700 (PDT) Received: from smtp-clients2.isti.cnr.it (smtp-clients2.isti.cnr.it [146.48.28.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CAB3A3628 for ; Sat, 7 Aug 2021 03:56:39 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (Authenticated sender: gennai) by smtp-clients2.isti.cnr.it (Postfix) with ESMTPSA id A397BB0825 for ; Sat, 7 Aug 2021 12:56:35 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at smtp-out.isti.cnr.it Received: by mail-lf1-f47.google.com with SMTP id z2so6593757lft.1 for ; Sat, 07 Aug 2021 03:56:35 -0700 (PDT) X-Gm-Message-State: AOAM533k/4TMt4182xEUmi7t0+CiZ5dKow7LTTD7hluX3sTAn4RND2EO e0hy9Yq7wiB9NGb64BmU6qmdR8CXuSbTi6bPhQU= X-Google-Smtp-Source: ABdhPJyVrwxYBGmESwKhEiuLuW3zTmNeOEkTDtXTuz3IiAk4+ogJhuHxFVUBl4864kqdhZ14wcxWpHGkU2RMgA4wK5A= X-Received: by 2002:a05:6512:22c4:: with SMTP id g4mr11107071lfu.287.1628333794889; Sat, 07 Aug 2021 03:56:34 -0700 (PDT) MIME-Version: 1.0 References: <4552B392-B208-419B-BAB1-5331DD0D438E@servicenow.com> <20210806203201.GA20038@hjp.at> <20210806205352.GA25317@hjp.at> In-Reply-To: <20210806205352.GA25317@hjp.at> From: Francesco Gennai Date: Sat, 7 Aug 2021 12:56:22 +0200 X-Gmail-Original-Message-ID: Message-ID: To: emailcore@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] "Trace" headers and header pre-pending? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 10:56:45 -0000 On Fri, Aug 6, 2021 at 10:54 PM Peter J. Holzer wrote: > > On 2021-08-06 22:32:01 +0200, Peter J. Holzer wrote: > > On 2021-08-06 18:22:10 +0000, Tom Perrine wrote: > > > Setting aside any definition of what constitutes a trace-related head= er, or > > > whether there should be a defined list of them. > > > > > > I haven=E2=80=99t found a place yet where =E2=80=9Cforwarding systems= MUST/SHOULD prepend any > > > added headers instead of inserting them between already present heade= rs=E2=80=9D or > > > similar language. This is being discussed over in the mailops mailing= list as a > > > practical issue. > > > > I don't think there is such a requirement in general. > > > > There is a requirement that "trace headers" (whatever they are, apart > > from the two explicitely mentioned in RFC 5322) are prepended, and > > another for the resent-headers (which also need to be added as a block)= . > > > > There is language in RFC 5322 which suggests that the trace headers > > should form a contiguous block at the start of the mail (which would > > mean that any non-trace header should be inserted after the trace > > headers, i.e. somewhere in the middle). I think this is a bad idea. > > More specifically: > > The syntax allows optional-fields and resent-* interspersed between > trace headers but not the other fields defined in the RFC (orig-date, > from, sender, etc.). > > But the text in 3.6 says: > > | More importantly, the trace header fields and resent header fields > | MUST NOT be reordered, and SHOULD be kept in blocks prepended to the > | message. > > which suggests to me that all the trace headers should be kept together > in a single block. It could be read as "1 or more blocks of trace > headers interspersed with 0 or more blocks of resent-headers", too, > which would be more consistent with the grammar. In any case it doesn't > accont for the optional-fields which are also allowed by the grammar. > > There is also a sentence in 4.5: > > | Also, the interpretation of trace fields and resent fields that do > | not occur in blocks prepended to the message is unspecified as well. > > So when is a trace header not "prepended"? If it occurs after an > "X-Spam-Score" header? Or only if it occurs after a "Subject" header? Prepended is not appended. You just add the new trace header to the top of the current block of header= s. Francesco > hp > > -- > _ | Peter J. Holzer | Story must make more sense than reality. > |_|_) | | > | | | hjp@hjp.at | -- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Sat Aug 7 07:44:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1730D3A3CE3 for ; Sat, 7 Aug 2021 07:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 wWXVp3BrBsZB for ; Sat, 7 Aug 2021 07:44:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 AAC583A3CE5 for ; Sat, 7 Aug 2021 07:44:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S2BDXMKMA800EXP4@mauve.mrochek.com> for emailcore@ietf.org; Sat, 7 Aug 2021 07:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1628347180; bh=czB1d03tQXCxzE826RHCYWYDhejhOG10y1IMk17KC6E=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=QKXoPD4CWfaqpIYJ5f42Avmy9FH1/2MWPBjN0e78GAEtyNGunW1POKLXPCJDbXQ6s BrbCWwPYRqZqtDMpd3ROB/VtuiAtI7Ht2sLMTko4peT93O7CXW4uCfUwYgATunMOgv suo4P9gIkuLKiTAEjmsakJSStrzsN36Vvfn0dQQw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Sat, 7 Aug 2021 07:39:36 -0700 (PDT) Cc: Dave Crocker , emailcore@ietf.org, Ned Freed Message-id: <01S2BDXJS6KK005PTU@mauve.mrochek.com> Date: Sat, 07 Aug 2021 07:22:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 06 Aug 2021 21:04:26 -0700 (PDT)" <01S2ASFIR1X0005PTU@mauve.mrochek.com> References: <20210805203737.A513B259D5A1@ary.qy> <557117b0-892f-6958-60f1-22e932a55a3e@dcrocker.net> <20210806065842.GA23520@hjp.at> <01S29ZATCWLK005PTU@mauve.mrochek.com> <01S2ASFIR1X0005PTU@mauve.mrochek.com> To: Ned Freed Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 14:44:48 -0000 > > On 8/6/2021 7:05 AM, Ned Freed wrote: > > > There most definitely are common semantics. A trace field is used to > > > record information about the current message tranfer operation, and > > > as such is not a normal MUA->MUA communication field. > > So, a mailing list should not add any trace information? > Nothing I said implies that. Mail is delivered to the list processor. That > would generate a Delivered-to:, assuming of course that Delivered-to:'s are > being generated. > The list expands and reintroduces the message to the transport, an operation > which could add whatever trace information the list thinks is appropriate, > although a Delivered-to: field is clearly not something that would be added > at this pint. > This could happen multiple times when sublists are involved. On further reflection, it's actually the case that a mailing list doesn't add trace information. It may preserve existing trace information (or not), but it doesn't add it. A mailing list may also change the content of a message (or not). But that's not the same as trace information. It's actions may cause trace information to be added, as described above, but the list itself isn't doing that. Ned From nobody Mon Aug 9 01:39:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3281B3A0976 for ; Mon, 9 Aug 2021 01:39:55 -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 xfqrknSZTTkE for ; Mon, 9 Aug 2021 01:39:50 -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 F2A793A0978 for ; Mon, 9 Aug 2021 01:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1628498384; bh=dgSumeh0OED/+VRr+zQronqY4qgedzXliv4G5evRyaI=; l=2094; h=To:References:From:Date:In-Reply-To; b=BsXdojRWLXwGzmJraC/s71TjZr9FVVpk0b/T2AX+iRoWyZOeE2pfLmDwcQPhBb8u/ jl3ZXB7kA9FyIzCLuytUs7tr6/cLF87cQ/HwKPkrvEQ/GYlK1pccdnP4a2qZPTrFFY p7/Z1PnDI9zBRaDTG31Hg4ArKXMu9fcWSZS2UErMc+lkI8mlRuR7b96VokoVa Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.103] ([5.170.160.3]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC008.000000006110E9CF.0000471D; Mon, 09 Aug 2021 10:39:43 +0200 To: emailcore@ietf.org References: <20210806140431.7F50925A63DB@ary.qy> From: Alessandro Vesely Message-ID: Date: Mon, 9 Aug 2021 10:39:40 +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: <20210806140431.7F50925A63DB@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 08:39:55 -0000 On Fri 06/Aug/2021 16:04:30 +0200 John Levine wrote: > It appears that Peter J. Holzer said: >> On 2021-08-05 14:41:20 -0700, Dave Crocker wrote: >>> In practical terms, this reduces to: >>> >>> "A trace field is anything we declare a trace field. There are no >>> inherent or common technical characteristics or semantics." >> >> I offer a different view: >> >> "Any field added after initial submission is a trace field." +1, except for some of the fields added after delivery. Scripting tools like Sieve, which allow to modify the header, often offer append as an alternative to prepend. >> I agree with the second sentence. > > I don't. A lot of delivery agents add stuff related to spam and malware filtering > with names like X-Spam-Status. I wouldn't call them trace fields. Why not? The mailing list software makes decisions, possibly spread over coordinated agents, based on X-Spam-Status:. Semantically, it looks very similar to Authentication-Results:, which is considered to be a trace field, according to RFC 8601. > In practice, I think most of us agree which headers are trace headers even if we have > trouble writing down what the Platonian ideal of a trace header is. The description Peter gave upthread is dynamic rather than semantic, but it seems to capture the essence: Please always, always, always prepend new headers. Never append them. If some headers are appended and some prepended, it is impossible to tell which headers were added by which system. If headers are always prepended, it is trivial. John K. reworded it about like so: if a [transit] MTA (or maybe a gateway) put something in, it is a trace field and, if not... Validations, like A-R, as they are integral parts of the transmission mechanisms, have to be trace fields as well. Given this "dynamical" concept, the production in rfc5322bis which starts with: fields = *(trace can be considered a tautological definition, saved for the fact that post-delivery scripts may subvert that order. Best Ale -- From nobody Tue Aug 10 16:18:15 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5EC3A20A6 for ; Tue, 10 Aug 2021 16:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 Z3Co6nxEluL4 for ; Tue, 10 Aug 2021 16:18:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 271C13A20A3 for ; Tue, 10 Aug 2021 16:18:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S2G2R4FB8G00JNEQ@mauve.mrochek.com> for emailcore@ietf.org; Tue, 10 Aug 2021 16:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1628637181; bh=jjU1E9PTn6W68HdJkxtuYSgYtcjLE0OmE7IgRT5tNkM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=A6rAse8/uZx3Y+8YGRskujwtx18XT8GMKKCsBZN1actfQkCBld6dBMfFnOCuZigFr 17FsDxFRihvurSHICF83tp8daBJ+CS36ypebtHIdXRVtZSx6zal32GkNPBrd5/O2ZW vgYfBBAltsuzVe6aKLNQ1z8v9/j3zQEmkKNEflu4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S2FFWLYTWW005PTU@mauve.mrochek.com>; Tue, 10 Aug 2021 16:12:58 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S2G2R1M54W005PTU@mauve.mrochek.com> Date: Tue, 10 Aug 2021 15:46:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Aug 2021 10:39:40 +0200" References: <20210806140431.7F50925A63DB@ary.qy> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 23:18:13 -0000 > On Fri 06/Aug/2021 16:04:30 +0200 John Levine wrote: > > It appears that Peter J. Holzer said: > >> On 2021-08-05 14:41:20 -0700, Dave Crocker wrote: > >>> In practical terms, this reduces to: > >>> > >>> "A trace field is anything we declare a trace field. There are no > >>> inherent or common technical characteristics or semantics." > >> > >> I offer a different view: > >> > >> "Any field added after initial submission is a trace field." > +1, except for some of the fields added after delivery. Scripting > tools like Sieve, which allow to modify the header, often offer append > as an alternative to prepend. First, saying "*after* initial submission" is incorrect, because initial submission itself routinely adds trace fields. Second, "*anything* after initial submission" is incorrect, because as you say it includes all kinds of random stuff. An even better example is mailing lists, which exercise MUA authority and routinely muck around with From:/To:/Cc:/Subject:. And when you include submission and exclude stuff done after delivery, you're left with what's already in RFC 5322bis: The trace fields document actions taken as a message moves through the transport system. > >> I agree with the second sentence. > > > > I don't. A lot of delivery agents add stuff related to spam and malware filtering > > with names like X-Spam-Status. I wouldn't call them trace fields. To be honest I'm not sure what a lot of these fields are, what purpose they serve, or why they are being added to messages. If the message is undergoing final delivery, then OK, I can understand why you might want to document what your spam filter thought. (And note that RFC 5598 specifically allows for MDA actions that are both inside (hMDA) and outside (rMDA) the MHS.) But when the message is going right back out to some place that likely doesn't understand whatever bizarre nonsense usually shows up in these fields? All it does is bloat up messages - I've seen it double or even triple the size of many messages - for no good purpose. And often as not they are appended, not prepended, making it impossible to determine the context in which the evaluation was made. > Why not? The mailing list software makes decisions, possibly spread > over coordinated agents, based on X-Spam-Status:. Semantically, it > looks very similar to Authentication-Results:, which is considered to > be a trace field, according to RFC 8601. Some do, many, if not most, do not. And as I noted above, fields used to communicate between the MDA and MUA do not have to be trace fields. As such, I fail to see the relevance of any of this. Why are we trying to divine the intent of someone who took advantage of RFC 5322 extensiblity and RFC 5598 flexibility to insert X-X-Large-Spam-Mess:? Ned From nobody Wed Aug 18 12:19:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C013A185F for ; Wed, 18 Aug 2021 12:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 2DvzCtr0x2ll for ; Wed, 18 Aug 2021 12:19:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8973A1860 for ; Wed, 18 Aug 2021 12:19:21 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mGR5s-000LRy-Nt for emailcore@ietf.org; Wed, 18 Aug 2021 15:19:20 -0400 Date: Wed, 18 Aug 2021 15:19:14 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <9641DF4E499078E21A8EAFA6@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] Thje Recived header filed and the "for" clause X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 19:19:29 -0000 Hi There has been a recent and moderately long discussion on ietf-smtp about the "for" clause and when and how to apply it. It was spawned by (and from) the discussion there of draft-crocker-email-deliveredto, but turned into a discussion of issues that are applicable (and IMO significant) here. IMO, the most complete message covering the discussion is one today from Ned Freed [1]. There seems to be tentative agreement --so far at least among Ned, Viktor, and myself-- that some work is needed, most likely in both 5321bis and the A/S. Issues with FOR have already been called out in 5321bis -- see G.14 -- but no ticket has been assigned. I will add a bit of text there to reflect the discussions of the last few days, but it is probably time to get a ticket assigned. best, john p.s. BTW, my apologies for not getting draft-ietf-emailcore-rfc5321bis-04 posted right after the IETF meeting as I had expected and promised. I've been fighting some vision problems that have seriously slowed my ability to read and edit and distracted by an unrelated IETF issue as well as some unrelated things. The former should stabilize by the end of next week and I should have a better estimate of when I will be able to make progress. [1] https://mailarchive.ietf.org/arch/msg/ietf-smtp/hMkwHT-6bi_AwYIxbFJBX5pqjiA From nobody Mon Aug 23 03:44:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9616D3A005F for ; Mon, 23 Aug 2021 03:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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=fastmail.fm header.b=gUnfZBef; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Oy5oHkWe 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 Rqu2_mLFGzZR for ; Mon, 23 Aug 2021 03:44:27 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07003A005B for ; Mon, 23 Aug 2021 03:44:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 367C55C017F; Mon, 23 Aug 2021 06:44:26 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Mon, 23 Aug 2021 06:44:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=3OSZ3kIMlmCLThL7576c8iH34HoUbaB 4LR7lh25bjF0=; b=gUnfZBefO7UOApfHuZBbghmQfqQdmSYiaQuq/+EUiTLdhk8 dYJ5Jttixu1nZY+yKzj6gDFIK0qhuGCfp0hv6qAbOlKZMLZjwG/bx546beBz/Tuk q7rlzoJdUld6zLqe2Z7bIXgVBzQqsunyvTcvchVvuzSSQFieFHv+NDCRRV1zdg3k OuZd0Ac1UrccWc6Q+GjJECSiLsH2AYVnd82vzIvjR4yffRYf4iIQibwGzLfRx+Ep U4Q3BI8Cdoh75mWiw+324wYznyPkXskdNP6heoVlXfv5cpfLIv5dfjh3KTXU3h3P yae94ZsGdiJWSHo9l8lweXcn4U7I1f7wtrPMhOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3OSZ3k IMlmCLThL7576c8iH34HoUbaB4LR7lh25bjF0=; b=Oy5oHkWeb1moQK0jy0+D6j 54OpDeLXrJQOwRb9F0vO7I9uG9K0/9g3p+3ejVi+Lsnh0Jbhc5lD71i7qWpopx2O 7SBHGAS+Vs8CNZeAeRojpwXrcPxCAd4wTnvq4CHEHuA39EzZxec9wF+2Royks8O9 dzm8eDcCIVNlaW9SpGFjKAtRgvTQLdXftlxSG6dtJXkzxgJA6Gs4h3ulHWKxIRhx iqMrGFWudwkodqJIdCOmgzfh1S/15zUmWl7FliA9VrHd5LHoCtKRVMIqNAZec4R0 xe8CZy3cRl5vxLgM+5V046CkgX4eIZMQZ2Z3Tj9GRMajl5p+E8BJFdwSRgWtSJQw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddthedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelffdtgf fhveeuudeihfffjeelgfdtudfhvdettdehfeettdfhgefhfeeigfegffenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 267702180066; Mon, 23 Aug 2021 06:44:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1118-g75eff666e5-fm-20210816.002-g75eff666 Mime-Version: 1.0 Message-Id: In-Reply-To: <9641DF4E499078E21A8EAFA6@PSB> References: <9641DF4E499078E21A8EAFA6@PSB> Date: Mon, 23 Aug 2021 11:44:04 +0100 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Thje Recived header filed and the "for" clause X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 10:44:34 -0000 Hi John, On Wed, Aug 18, 2021, at 8:19 PM, John C Klensin wrote: > Hi > > There has been a recent and moderately long discussion on > ietf-smtp about the "for" clause and when and how to apply it. > It was spawned by (and from) the discussion there of > draft-crocker-email-deliveredto, but turned into a discussion of > issues that are applicable (and IMO significant) here. IMO, the > most complete message covering the discussion is one today from > Ned Freed [1]. > > There seems to be tentative agreement --so far at least among > Ned, Viktor, and myself-- that some work is needed, most likely > in both 5321bis and the A/S. > > Issues with FOR have already been called out in 5321bis -- see > G.14 -- but no ticket has been assigned. I will add a bit of > text there to reflect the discussions of the last few days, but > it is probably time to get a ticket assigned. You are right, I missed creating ticket for this. I've added . Best Regards, Alexey > > best, > john > > p.s. BTW, my apologies for not getting > draft-ietf-emailcore-rfc5321bis-04 posted right after the IETF > meeting as I had expected and promised. I've been fighting some > vision problems that have seriously slowed my ability to read > and edit and distracted by an unrelated IETF issue as well as > some unrelated things. The former should stabilize by the end > of next week and I should have a better estimate of when I will > be able to make progress. > > > > > [1] > https://mailarchive.ietf.org/arch/msg/ietf-smtp/hMkwHT-6bi_AwYIxbFJBX5pqjiA > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore >