From nobody Mon Feb 8 07:40:28 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 B9B723A0E8D for ; Mon, 8 Feb 2021 07:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=oheHgS5U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sAul9LVR 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 dqUqHzJ3m63W for ; Mon, 8 Feb 2021 07:40:23 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22653A0E88 for ; Mon, 8 Feb 2021 07:40:23 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E58777BE for ; Mon, 8 Feb 2021 10:40:22 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Mon, 08 Feb 2021 10:40:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=sIRyCGH7TJOAfMI/ApY4hlV4j0CzV4A/5yMHh0lDje4=; b=oheHgS5U e7OSU7F2nZwCmDY4KInuKIq4K7LOmXHwEilx8p2Ujq4Qv3Eb+hmwALkz5apjhCrq W7Rl6iqHaYjjjTkvCvI+YigUqt5VJWvLZsViISiZfBhREPd7aXKrYN60RyurkrNF f6h88lQI5Jfr26WDr+ZQAp3Ja50dmeBDKCQWSammwIBXehDdqtO/ro+LqJxoD69R pzoPYrPPvehVkXZr5PQzBQ86qeak6SAMqmmB4lZIH3OjD/FUen+zgh7z7AeP2qhc QZR6gt6gpewqaGMGfjvhU0XvP7t+0wKIK0j1PMrDdlzIOTcXHseufABFLd4eh1Zj 2ZsvNPkMpFit8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=sIRyCGH7TJOAfMI/ApY4hlV4j0CzV 4A/5yMHh0lDje4=; b=sAul9LVR27Zoru5cxXNRFXTW0aW6a+ohbAG0FrnGnpP9f TrnqfFxPlbGyXBBnNVcUiWmxCR4w3T8lf5QTmPXu+BTvzUsCy4VUwgGhAG1obSve t52FyjTH6X8p6rAui6qtRTvGYd9oeBDw9nMmyi9myWi/5XFf9HJOoI0+zYgzJjEL A8ZKpXvn4gOnH9YDgSODgrIT/qUSs/qiDZxh/IgIiMd6xeP+elGUrt0jrpMHYl/x 0LmDPf73X+j8JhAUfXkORi9xELcA1tAfsLEiz39eLtY4CYtWZrcI+lSn2L12K07Q GxCCkU4RXzgMXdWFngGkqVEFlYBn/2xVFWqkzrSuA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheefgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre erjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepffeifedvfeejhe dvveehgeelkeetudevueeiteeuuedvjefhieeigedvjeegieeinecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrg hsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22CA36B4005F; Mon, 8 Feb 2021 10:40:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: <890020c9-092a-46be-9eda-6b5aa822b8a1@www.fastmail.com> Date: Mon, 08 Feb 2021 15:40:01 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: [Emailcore] =?utf-8?q?Confirming_resolution_for_ticket_=2326=3A_?= =?utf-8?q?Erratum_1543=3A_Wrong_reply_code_in_Section_3=2E8?= 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, 08 Feb 2021 15:40:27 -0000 Dear WG, This is just to confirm the change that was already applied to the document: Section 3.8 says: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly. It should say: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 421 response had been received and act accordingly. Notes: SMTP clients are told to act as though a 451 response ("Requested action aborted: local error in processing") had been received when context clearly indicates that a 421 response ("Service not available, closing transmission channel") was intended. ----------- If there are no objections to this change, this ticket will be closed in 2 weeks (February 22nd). Best Regards, Alexey From nobody Mon Feb 8 09:26:34 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 6B5BD3A187D; Thu, 4 Feb 2021 13:46:18 -0800 (PST) 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, 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 FtK2QKEIbYsS; Thu, 4 Feb 2021 13:46:16 -0800 (PST) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (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 70B553A187E; Thu, 4 Feb 2021 13:46:13 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CD51B9221C4; Thu, 4 Feb 2021 21:46:12 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-18-11.trex.outbound.svc.cluster.local [100.96.18.11]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id A7C9D922487; Thu, 4 Feb 2021 21:46:11 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.18.11 (trex/6.0.2); Thu, 04 Feb 2021 21:46:12 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Lyrical-Troubled: 20d7372d5fa262c8_1612475172476_1437124273 X-MC-Loop-Signature: 1612475172476:3987560617 X-MC-Ingress-Time: 1612475172476 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 6532931A38CA; Thu, 4 Feb 2021 21:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1612475169; bh=ZmdjzlqWptZtYeMtu1lJVg6s5g//zGRTAVlkxvBMc6I=; h=Subject:References:To:Reply-To:From:Date:In-Reply-To; b=PZLwBZJ9Ycv+WAZ6SwHc2CbvhIOLYwYz6pADq2Olb9jtMaQc8b5ttZEbm8m3Y+Vqy GBr3gSrTv7VlY9c7e7zftqBe/P5ttPnoTJOceTfgadNbLtvKg9aHGjMViYqAc2s+sP GfpfrNs4ORBPq715nvPPFlyvDdlmT+AFGFWbaRJv9ktTYKI7EU6ytt+8OmkhrxRFmL fbPDWOsj5pCuI/8BjY+nIdyRqB5NyXKYE2NHN1jQ8iK+kHZrLTcbyhJlNe7qjW8anr OzmAf2dj7d4S3eRZi/tS9qZbRT/WX2Hc4rrF5j7lDgbzfDrZF/y9g1ggdHjKAPQfxt FbO71ZfWNIjRA== References: <161237978029.17564.1671203014287258223@ietfa.amsl.com> To: ietf-smtp Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking X-Forwarded-Message-Id: <161237978029.17564.1671203014287258223@ietfa.amsl.com> Message-ID: Date: Thu, 4 Feb 2021 13:46:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <161237978029.17564.1671203014287258223@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 08 Feb 2021 09:26:34 -0800 Subject: [Emailcore] Fwd: New Version Notification for draft-crocker-email-deliveredto-00.txt 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, 04 Feb 2021 21:46:19 -0000 G'day SMTP folk, This draft was prompted by discussion in the emailcore wg, but is outside the scope of the wg charter. So the spec is being pursued as AD-sponsored. The SMTP mailing list is cited in the draft as the discussion venue. (emailcore has been bcc'd.) d/ -------- Forwarded Message -------- Subject: New Version Notification for draft-crocker-email-deliveredto-00.txt Date: Wed, 03 Feb 2021 11:16:20 -0800 From: internet-drafts@ietf.org To: Dave Crocker A new version of I-D, draft-crocker-email-deliveredto-00.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-crocker-email-deliveredto Revision: 00 Title: Delivered-To Email Header Field Document date: 2021-02-03 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-crocker-email-deliveredto-00.txt Status: https://datatracker.ietf.org/doc/draft-crocker-email-deliveredto/ Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-email-deliveredto Htmlized: https://tools.ietf.org/html/draft-crocker-email-deliveredto-00 Abstract: The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the author. The address used by the mail transport service is provided separately, through an envelope SMTP "RCPT TO" command. Before final delivery, handling can entail a sequence of addresses that lead to the recipient. It can be helpful for a message to have a common way to record each delivery in such a sequence, and to include each address used for that recipient. This specification defines a header field for this information. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Feb 12 16:37:24 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 BACDA3A1168; Fri, 12 Feb 2021 16:33:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641074.31337.10516702801221096526@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:30 -0800 Archived-At: Subject: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:39 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. emailcore Session 1 (1:00 requested) Wednesday, 10 March 2021, Session I 1300-1500 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/emailcore.ics Request Information: --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: extra jmap dmarc uta Technology Overlap: calext dispatch secdispatch Key Participant Conflict: gendispatch wpack People who must be present: Alexey Melnikov Barry Leiba Dr. John C. Klensin Pete Resnick Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 12 16:53:08 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 2C5AA3A1CC2; Fri, 12 Feb 2021 16:53:02 -0800 (PST) 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 Y1V7xUqlpsdJ; Fri, 12 Feb 2021 16:53:00 -0800 (PST) Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (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 488523A1CC8; Fri, 12 Feb 2021 16:49:50 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D8A5A7E3343; Sat, 13 Feb 2021 00:49:48 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-13-34.trex.outbound.svc.cluster.local [100.96.13.34]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 546A07E25A3; Sat, 13 Feb 2021 00:49:47 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.13.34 (trex/6.1.1); Sat, 13 Feb 2021 00:49:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shade-Cure: 07b31703056cb164_1613177388642_1595226690 X-MC-Loop-Signature: 1613177388642:826757111 X-MC-Ingress-Time: 1613177388642 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 705A8333EFAC; Sat, 13 Feb 2021 00:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613177385; bh=LbfSFUDkVLq2QD9VXo36TZFwWfZR8sHkZNbMsl2DTEQ=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=NLT06ldm+BYx5zwuj8QP/GJrvWFlzYOhkpwhp69mxaQiy0enD5ote+2EDxwpPH1Dm Y5KouF+a9WYSHtbQkpTaW3ZPIgh0eY5SQ2CX84DyBpbDa4Ih12a+8fd9xZsK73xbpz XS6D2dnZ8r3ceZYx+HmI/vrFKPJjeiQQ7+qgo/JAqCQCJrCRjg+ocopmsapxZwdyJY AwmAi/f6qT4QFhfGnzT4q80MG+m6/FkIGkm4Z2/9NslWS5wYsY8mFkCbC5sqtcghqT F+i3UiJfX9vja0kRxRh4RELJIixpknwjPfbzzRv4VV2RM1PPziy8deX+oYmHH+ESCa xDBcSdqKgIVKQ== Reply-To: dcrocker@bbiw.net To: IETF Secretariat , alexey.melnikov@isode.com, emailcore-chairs@ietf.org Cc: emailcore@ietf.org, barryleiba@computer.org References: <161317641074.31337.10516702801221096526@ietfa.amsl.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> Date: Fri, 12 Feb 2021 16:49:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <161317641074.31337.10516702801221096526@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 00:53:07 -0000 On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: > Wednesday, 10 March 2021, Session I 1300-1500 timezone? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Feb 12 17:25:34 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 EE3713A1170 for ; Fri, 12 Feb 2021 17:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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.249, 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=DMNX9e7R; dkim=pass (2048-bit key) header.d=taugh.com header.b=CBrSVOcp 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 T_1g2DpXzGXs for ; Fri, 12 Feb 2021 17:25:31 -0800 (PST) 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 1E0493A0F35 for ; Fri, 12 Feb 2021 17:25:30 -0800 (PST) Received: (qmail 89353 invoked from network); 13 Feb 2021 01:25:29 -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=15d05.60272a89.k2102; bh=HeMn+gc1DOaaHBOjAEFFj6PXrLBYtUCv0yB8Pd47QYw=; b=DMNX9e7R08E6iFQlj1Lx8IoiUl+UmFoHrswxI8O/Ow/v+K71VO1U2xAX7QuBAm3Vr1g1/UL4/CvYLCuoeLf9DLgAFDOINYNVzTNGjFHEwov8MkghAh1Nq4gF3JYjoeDmRZs0aqOh87jVpjG3h7eLBPn7u7Ir3mP5qSmIOZFfAIBTltUrZ8kuO66oXKMEpUyzbbbbI51bWgpZxZKciFhhsN8+aoH/tw2g/3I7j/vGqJg8XqbYyaxxKg0+Ane5FCv737DDEbgzQN2Gyzr8pK5DPpwTYC7wJvT2gpolx91a07K13WEiC3igtfa9d5JN1+n4yNNY4B420guCK8R/Glqmvg== 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=15d05.60272a89.k2102; bh=HeMn+gc1DOaaHBOjAEFFj6PXrLBYtUCv0yB8Pd47QYw=; b=CBrSVOcpgotrS7DqRL/TQeixL8zDGN2e9hw+/Ll4jD7FsnVp50iq/m4wHY90/UgKVjU487XQb89ixHM9M/plhVxWDa7FvwL8xmx83503In8cNvU3kFiaPNvxb39phUCCO1m/ALwxjPpxhGrjQ5FaQIgqP5fCPnlFlQfiTtOO6j6aSR+BxY4xWPd2uW/NkX4zpFVco/x4OwLfM2/F3rS72adCuahgWdHDYoUFxEfLK6Z1F7unAKLBDhhaK/alCFMOPrn2r1ezsi9VvNJDlUqzM73dm2HBU6G/7FSL/GUu9a4c578Qn08Xe31fbwyZRmOD/wkAode4eKWFCdNQ9/fjxQ== 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; 13 Feb 2021 01:25:29 -0000 Received: by ary.qy (Postfix, from userid 501) id D81996DDD4B3; Fri, 12 Feb 2021 20:25:28 -0500 (EST) Date: 12 Feb 2021 20:25:28 -0500 Message-Id: <20210213012528.D81996DDD4B3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <174eb7b8-edba-4905-a747-3f79411a3e5a@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] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 01:25:33 -0000 In article <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> you write: >On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: >> Wednesday, 10 March 2021, Session I 1300-1500 > >timezone? Local time. Why do you ask? R's, John PS: 4 AM for you From nobody Fri Feb 12 17:32:52 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 A09D63A1182 for ; Fri, 12 Feb 2021 17:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lMMjtHs-Oixr for ; Fri, 12 Feb 2021 17:32:48 -0800 (PST) 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 C27C83A1180 for ; Fri, 12 Feb 2021 17:32:48 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6B8C7E243B; Sat, 13 Feb 2021 01:32:47 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-13-34.trex.outbound.svc.cluster.local [100.96.13.34]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id A893D7E2565; Sat, 13 Feb 2021 01:32:46 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.13.34 (trex/6.1.1); Sat, 13 Feb 2021 01:32:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shoe-Snatch: 6627015432b830c1_1613179967518_2937325459 X-MC-Loop-Signature: 1613179967518:1963387843 X-MC-Ingress-Time: 1613179967518 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 4B37331A0C6E; Sat, 13 Feb 2021 01:32:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613179965; bh=zpTn04kO3Xja+Syjr05lzzOYYCRbwgEv7OrcaxYZkLE=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=MhaJFfvAPtfEkWAWi5Nao1+AsclpEnYYrONFCmgUtcbweal3/xsn+uUQ2mYjuZFrI E+T/KlFpHKXxyUdsmKjHeocP9XjeizFR5wNhaCE+t3WXV9iE+4mqLQ76pJtwgrkTWV VZVo5Qqcv2qVYc6J1lj30MS06jX/UrPD+7Ak7Z3MkzVmsJBiUv1TTDjIX/4g1y6dnS 6kFwPhOvstxv//yKFlUtXjfdg/3gaCv1jUMKZq6/TIpY08Cr572feARrmni+3kWctS k53XLPglpGfEp06kI0+0hzRoKqz8mAKmhjBwqmrBU8/vsIwGcuCG1jy77LrF55yeP+ lg1l8CIsx8mDQ== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: dcrocker@bbiw.net References: <20210213012528.D81996DDD4B3@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> Date: Fri, 12 Feb 2021 17:32:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210213012528.D81996DDD4B3@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 01:32:51 -0000 On 2/12/2021 5:25 PM, John Levine wrote: > In article <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> you write: >> On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: >>> Wednesday, 10 March 2021, Session I 1300-1500 >> >> timezone? > > Local time. Why do you ask? > > R's, > John > > PS: 4 AM for you Seems like a pattern. Is there an explicit IESG policy to be unfriendly to folk in the US? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Feb 12 18:29: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 2332C3A1233 for ; Fri, 12 Feb 2021 18:29:14 -0800 (PST) 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 lCVk0wOv20pH for ; Fri, 12 Feb 2021 18:29:12 -0800 (PST) Received: from bsa2.jck.com (ns.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 5B7803A1232 for ; Fri, 12 Feb 2021 18:29:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lAkgG-000FSC-4v; Fri, 12 Feb 2021 21:29:08 -0500 Date: Fri, 12 Feb 2021 21:29:01 -0500 From: John C Klensin To: dcrocker@bbiw.net, John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> 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] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 02:29:14 -0000 --On Friday, February 12, 2021 17:32 -0800 Dave Crocker wrote: > On 2/12/2021 5:25 PM, John Levine wrote: >> In article >> <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> you write: >>> On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: >>>> Wednesday, 10 March 2021, Session I 1300-1500 >>> >>> timezone? >> >> Local time. Why do you ask? >> >> R's, >> John >> >> PS: 4 AM for you > > > Seems like a pattern. Is there an explicit IESG policy to be > unfriendly to folk in the US? Does feel like it... and maybe moving from "unfriendly" to "very unfriendly" depending on where in the US one is. But probably better discussed in manycouches/SHMOO or the IETF list than here. john From nobody Fri Feb 12 18:39:29 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 885943A1256 for ; Fri, 12 Feb 2021 18:39:26 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=jGLOFVAM; dkim=pass (2048-bit key) header.d=taugh.com header.b=TpfBsSCY 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 muGOnALFPgl8 for ; Fri, 12 Feb 2021 18:39:25 -0800 (PST) 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 BCC573A1254 for ; Fri, 12 Feb 2021 18:39:24 -0800 (PST) Received: (qmail 485 invoked from network); 13 Feb 2021 02:39:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=1e3.60273bdb.k2102; bh=hfQd+x1U8vG9aw7D6xXH88qTnsyC0cdWDoHKhDL/cF0=; b=jGLOFVAM7iYwF0uZ8Wf9Beg1RbXYdEdOj3uTEybMjche3SXZLnIcHb1SF+8PwZbPPZDbAI7EgoHOgZeqAUSifa9Q01OWhPfjc3XStV8XY11tCfPIdwOQMh8ltOE10cSq1MPz7zT9i8TVLFvsNSKvTZMoeTCXPcueSBuuTcwZqhR0KIjC4CU4sjXl+BSLmxYoVW24x5twmUyCMe+Gx0qfCUPhHbcl6mXk9s3S7rBa9QzM3RnHyIaPZDHuIVpiAFQiRGSOgjkS9/q7QZ+rt8iIqIdMSUtWWQdpZLCCCL6HMNcDivk/YN/eAVCdkSeqATG+qSii2AWWJg3NGOUppWpZWg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=1e3.60273bdb.k2102; bh=hfQd+x1U8vG9aw7D6xXH88qTnsyC0cdWDoHKhDL/cF0=; b=TpfBsSCYiHb7kFp/yNiSHGmCrZWTiHFC+ixkMEznt8YY7JglltTJX/eDOZjXzH9rgDn2sMN6warcvgIf7jBG21URnr1SEZQXsBfdlm+T3eHs06xf6tVIY3Npdgf94by1EWODl6zNl5Uz4yx0VJfzzhH8oI+dDSA5bzQKJkLpJRNqVb+Trqj5rTGYAsa+VlOlPYOt0cLp2+CMykYI3jTWE/6VkrEKKEERbpJxvAP2nZplcOklHRGNi21H2EHZcL+VppRFqEvPrEjsBEI2tKARf3FD08Iv5wWrNcxe34nBsL6mkTZoeesMG2PJeG7UuCIGTOs6QPzrtcrIZL6efiJsYg== 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; 13 Feb 2021 02:39:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 4BDCA6DDF9BA; Fri, 12 Feb 2021 21:39:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id D5EB16DDF99C; Fri, 12 Feb 2021 21:39:21 -0500 (EST) Date: 12 Feb 2021 21:39:21 -0500 Message-ID: <811838d8-b6c1-2c7c-ce2f-96df5afc99c@taugh.com> From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org In-Reply-To: <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 02:39:27 -0000 > Seems like a pattern. Is there an explicit IESG policy to be unfriendly to > folk in the US? For anyone who hasn't been paying attention, the online meetings are scheduled in the same time zone that the physical meeting would have been Prague. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Feb 12 19:46:22 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 A26303A0B20; Fri, 12 Feb 2021 19:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 D7BXq3Apwllf; Fri, 12 Feb 2021 19:46:19 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 05A973A0B13; Fri, 12 Feb 2021 19:46:18 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id b2so2399253lfq.0; Fri, 12 Feb 2021 19:46:18 -0800 (PST) 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=sANkhlUePNeZIwqJxIzbOdLQdWVdzyYrtkALZ2gPvwA=; b=dhtEERvPMQsN3UraI05KlbxSufPG/crW7prSFUY5+DLNJoDQIdbQ3dCMA6guYz1yIt 61PRtK0ca6HTuZUKLOny7CLjOGOsREor/wNs1rpYwFkDMwE8eh27XzGMqkiFtfkj01pq ntaftq8Ac4hZ5qyG+7Hk5Mtl6OY8VGMrJ5aal4hS/CU/6nGutO/4ZwT/HZD8UQeEVlwS SlGVIy60EFVSt8pq2YP9cGZWcIU1qye5CEbRHvoUZNGHaNCyEVC9jmCYlexTkXyGS9N3 652HMB0sJjpJLIohPFLF+Q50+ERkbiyMT+DQHAYbGbhs1ra8tBRjhiSk0b8P6yN+ko/l OONw== X-Gm-Message-State: AOAM533UuBWBonH1oxvFgO8UlrtG+xPU2WpfdCvgeaujHypmITeZMpvJ mL7ukYXB4joNHI7Nvfcb7y/HWdW0gOEIEcLJtrAL2DeG4qI= X-Google-Smtp-Source: ABdhPJykgDc7/m6+lcBziKgEs0VF//b1ndu/+9xHYB8TZqIErlPCxL9/qKa9LXZbyKV2XF4f4gQh6pPAcejXF3iBLlU= X-Received: by 2002:ac2:4daf:: with SMTP id h15mr3352466lfe.295.1613187977022; Fri, 12 Feb 2021 19:46:17 -0800 (PST) MIME-Version: 1.0 References: <161317641074.31337.10516702801221096526@ietfa.amsl.com> <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> In-Reply-To: <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> From: Barry Leiba Date: Fri, 12 Feb 2021 22:46:06 -0500 Message-ID: To: dcrocker@bbiw.net Cc: IETF Secretariat , alexey.melnikov@isode.com, emailcore@ietf.org, emailcore-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000053914c05bb2f984e" Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 03:46:21 -0000 --00000000000053914c05bb2f984e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable According to the agenda page: https://datatracker.ietf.org/meeting/110/agenda/ ...times on the text agenda are Prague times, UTC+1. These =E2=80=9Csessio= n has been scheduled=E2=80=9D messages follow the text agenda. Barry On Fri, Feb 12, 2021 at 7:50 PM Dave Crocker wrote: > On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: > > Wednesday, 10 March 2021, Session I 1300-1500 > > timezone? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --00000000000053914c05bb2f984e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
According to the agenda page:

..= .times on the text agenda are Prague times, UTC+1.=C2=A0 These =E2=80=9Cses= sion has been scheduled=E2=80=9D messages follow the text agenda.

Barry

On Fri, Feb 12, 2021 at= 7:50 PM Dave Crocker <dhc@dcrocker.= net> wrote:
On 2/12/2021 4:3= 3 PM, "IETF Secretariat" wrote:
>=C2=A0 =C2=A0 =C2=A0 Wednesday, 10 March 2021, Session I 1300-1500

timezone?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--00000000000053914c05bb2f984e-- From nobody Fri Feb 12 21:11: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 EF1273A0D98 for ; Fri, 12 Feb 2021 21:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jtDAd5ROlhQA for ; Fri, 12 Feb 2021 21:11:18 -0800 (PST) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (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 E88193A0D97 for ; Fri, 12 Feb 2021 21:11:17 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A5E9F401FDB for ; Sat, 13 Feb 2021 05:11:16 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-18-18.trex.outbound.svc.cluster.local [100.96.18.18]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id C297E4021B6 for ; Sat, 13 Feb 2021 05:11:15 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.18.18 (trex/6.1.1); Sat, 13 Feb 2021 05:11:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Wide-Eyed-Squirrel: 50565d0e3957645d_1613193076300_2257820842 X-MC-Loop-Signature: 1613193076300:2391548954 X-MC-Ingress-Time: 1613193076300 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id D1F7F22661D0 for ; Sat, 13 Feb 2021 05:11:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613193074; bh=E8O60IXZBwweGhup/Rp8kVIoH3rN9O+2tmyyZuuddik=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=kRRn5B8hZmzKfwh77/rojEko+DhA+dRxRmJw47OqO6UJ/DrKBGkAQM8AE1eKuvuGK 4SYb6HmkbmlpCzuaeVLCTE9yeuA/RNPx3Bt0C2OcMAn2oZQSzm8xGD9U0wsT+Xeot9 psZ3m3PLE04YiuYKLRgsakc55Sjskdoq3G9XPElnOVZUGGXjjkdb4rkFeTbz9Z6lnk 6y9pZD6AkjA0x231zlc6uqcl758LABTMWYL9P6Q8pAj6QAjk5q29y6EgIy36aRin/R 9H7NaCzSF8WqO1q+cfEToy4E4PREhsIVJxmxgjiRyHdv8MCrKgtbB41PzW6wP3nukc uw7vMgr+gL4fw== Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> <811838d8-b6c1-2c7c-ce2f-96df5afc99c@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <3581df10-6a60-308d-6c45-54a3f0cea7aa@dcrocker.net> Date: Fri, 12 Feb 2021 21:11:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <811838d8-b6c1-2c7c-ce2f-96df5afc99c@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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, 13 Feb 2021 05:11:20 -0000 On 2/12/2021 6:39 PM, John R Levine wrote: > For anyone who hasn't been paying attention, the online meetings are > scheduled in the same time zone that the physical meeting would have > been Prague. Were there a large concentration of IETF participants located in or near that timezone, that choice would make sense. Given that there is, at best, a minimum of participants there, the pretense of matching a venue merely serves to maximize inconvenience for actual participants. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Feb 13 16:23: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 6480D3A1104 for ; Sat, 13 Feb 2021 16:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmailteam.com header.b=DHOaW7OG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BNdLTfg8 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 kZtoESBJZzMi for ; Sat, 13 Feb 2021 16:23:08 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673B13A10D6 for ; Sat, 13 Feb 2021 16:23:08 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 260A87D8 for ; Sat, 13 Feb 2021 19:23:06 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sat, 13 Feb 2021 19:23:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=dnVOXOV rh7SbIdohC4aHnCCKMUJjSgx99AWq6FGtcc4=; b=DHOaW7OGW8qWzCol/Fvwlfl 1qETz/J4+Db3nwEb8EF2zOXqG28wIWHcs5rjPGW9ByJAXWc3h3d653cGf96Nx3+t k8i0ohBGchlcaI18kh6+JyVdsPGwIQ/dsqn7+++63NGwOqkTJ1NnVoPTJ3zk/n0e P83v3mqNlFnLqrsJ5oAmqr/y504gTWmFKyDwKpavdQa0h6ecGxdlIC4NN7lbJHpZ 9JRrkQr5bkx5NNXG2mggwF+AnfN9qfH6RuyMP1JrKbP6WxZwfnYjbM3+YHUjf7sg F93XlO3BiGRkgIsL/XceDf3fiLP5Hg/XJdVkPqY8MmNA4+eXn4+MRSIulSsbCIA= = 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=fm2; bh=dnVOXO Vrh7SbIdohC4aHnCCKMUJjSgx99AWq6FGtcc4=; b=BNdLTfg8jiS95AkJa/qUhy fRUoRGpZ6xbUiC0Vc/qA+tg53VVOZahHFsh2GfTTpE7ShEoqmSy5JmRg74P1I/Q+ adsPDoNAFv4BQcZqJXMGUAh7Lm+deHkjIJf14hEwOzQRXFRj3t6EXawHO+EAG/0M XX80g0Hv5iuJeVyltoWGBXXXa6IyAdZxB3hT5NIfcKy5zyqmgGsEhgMHISHuwycH T+IN5h8Cbpjfqti3+Ms48sMMMSVrV5jvNG42dQXM7QwpAFtQJCtX4OvNvXDUMd6I SYeDhxq7tUMnxt2EHoeJpZeNaBMEMW5mIvoNN384+jfTh/6wByIHp0rH88pzrCRQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieeggddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepjeeileekteduhf euieevjeeiveduheevvedvgeekieevffefheeuueffuddtieeinecuffhomhgrihhnpegs sghifidrnhgvthdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9906036005C; Sat, 13 Feb 2021 19:23:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <9e2dc89f-8d0d-4a7e-91f4-d3d288c1a88c@beta.fastmail.com> In-Reply-To: <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> Date: Sun, 14 Feb 2021 11:22:43 +1100 From: "Bron Gondwana" To: emailcore@ietf.org Content-Type: multipart/alternative; boundary=eefd9c21099b45f8a04107ed621916cd Archived-At: Subject: Re: [Emailcore] =?utf-8?q?emailcore_-_Requested_session_has_been_sch?= =?utf-8?q?eduled_for_IETF_110?= 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: Sun, 14 Feb 2021 00:23:10 -0000 --eefd9c21099b45f8a04107ed621916cd Content-Type: text/plain I think it's more about being unfriendly to Australians. The entire meeting is during my normal sleeping hours. Bron. On Sat, Feb 13, 2021, at 12:32, Dave Crocker wrote: > On 2/12/2021 5:25 PM, John Levine wrote: > > In article <174eb7b8-edba-4905-a747-3f79411a3e5a@dcrocker.net> you write: > >> On 2/12/2021 4:33 PM, "IETF Secretariat" wrote: > >>> Wednesday, 10 March 2021, Session I 1300-1500 > >> > >> timezone? > > > > Local time. Why do you ask? > > > > R's, > > John > > > > PS: 4 AM for you > > > Seems like a pattern. Is there an explicit IESG policy to be unfriendly > to folk in the US? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --eefd9c21099b45f8a04107ed621916cd Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I think it's more about being unfriendly to Australians. T= he entire meeting is during my normal sleeping hours.

Bro= n.

On Sat, Feb 13,= 2021, at 12:32, Dave Crocker wrote:
On 2/12/2021 5:25= PM, John Levine wrote:
>> On 2/12/202= 1 4:33 PM, "IETF Secretariat" wrote:
>>>       Wednesday, 10 M= arch 2021, Session I 1300-1500
>>
>> timezone?=
> 
> Local time.  Why do you ask?
> 
> R's,
&= gt; John
> 
=
> PS: 4 AM for you

<= br>
Seems like a pattern.  I= s there an explicit IESG policy to be unfriendly 
to folk in the US?

d/
=

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- = ;
Emailcore mailing list
<= /div>
<= a href=3D"https://www.ietf.org/mailman/listinfo/emailcore">https://www.i= etf.org/mailman/listinfo/emailcore


<= /div>
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
=
  brong@fastmailteam.com

--eefd9c21099b45f8a04107ed621916cd-- From nobody Sat Feb 13 16: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 2F5223A11CD for ; Sat, 13 Feb 2021 16:32:18 -0800 (PST) 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 L0orbSlce3xJ for ; Sat, 13 Feb 2021 16:32:16 -0800 (PST) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 4EF8F3A11CC for ; Sat, 13 Feb 2021 16:32:16 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0C15B6816E8; Sun, 14 Feb 2021 00:32:15 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-17-27.trex.outbound.svc.cluster.local [100.96.17.27]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 17AFB681503; Sun, 14 Feb 2021 00:32:13 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.17.27 (trex/6.1.1); Sun, 14 Feb 2021 00:32:14 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Zesty-Drop: 11d40ade28b2d4b9_1613262734742_2124246240 X-MC-Loop-Signature: 1613262734742:4090586080 X-MC-Ingress-Time: 1613262734742 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id D10AB333EFAC; Sun, 14 Feb 2021 00:32:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613262732; bh=ualiIfbGo1IdxRXO1Ob5HvF8lBB95JHfBmXP9Hv6v6E=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=oMfkQQ7KUWWBE8th/roMaNBbaM4QRhtnIZlCtExFUO2dgQ667MOTo/qTk4px7yZzI rHQst1QDdbOGHXI8e90dmlZHKk51fRXuOhedZ5IdodA/e+AZFiXdQgDn/G46RF5DuS Y2aYAkSjbKzrgzQ1gScv778PDJSKoivnH7XrKlDsqaL4dB41x24I5kjDLfPoD4hRAW aIkPcm5F3RG9Q26nFFO5Zc2O6Y4ZYkqa3br5pY5g+lcc3nHndI9mqngdXfh3yMQM6H DBMD70jX/F5emi1JFj95f2U4gneMHCCfqhaW3UvlrJJ2gcS8wxb/sor5QxrYciRig1 UVys/7CbdDCXA== Reply-To: dcrocker@bbiw.net To: Bron Gondwana , emailcore@ietf.org References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> <9e2dc89f-8d0d-4a7e-91f4-d3d288c1a88c@beta.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <799436d1-647f-c040-8db7-3d060d8cb20b@dcrocker.net> Date: Sat, 13 Feb 2021 16:32:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <9e2dc89f-8d0d-4a7e-91f4-d3d288c1a88c@beta.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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: Sun, 14 Feb 2021 00:32:18 -0000 On 2/13/2021 4:22 PM, Bron Gondwana wrote: > I think it's more about being unfriendly to Australians. The entire > meeting is during my normal sleeping hours. staying up late is easier than getting up really early. harumph. oh the other hand, maybe there's a class action suit we could jointly file? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Feb 13 21:55: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 C1FA43A1503 for ; Sat, 13 Feb 2021 21:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=qGxv0Xn8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FV84nY+5 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 YCFEvWe3GGPn for ; Sat, 13 Feb 2021 21:55:16 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 0ED6F3A1502 for ; Sat, 13 Feb 2021 21:55:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 11845A7C for ; Sun, 14 Feb 2021 00:55:14 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sun, 14 Feb 2021 00:55:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=f2N5JlF loC5s65PzLjkiGrNfUZEBGM11FoNNXWjpZi4=; b=qGxv0Xn8lIwIQywXXQ5U93m KOnFXqnUx5N/JzZ3hm3sGOcT/P+PQJan7o/2B2fNFVhQV7hDAskTBOh3BytEN/Qh 0khvW+P4x9hHaXMtU+LWpHcg+A0wWXGNtVaGS91dVOaIMtjCldlLLl8exvJG0J8L f2WL08BnfwQaSi94las98lXCp/Hlb27qDbK/6vdWl4W1rc+JwCK2hdSPcHq13bHR soZtGCxb4+t+oFeuh3W0iEaYhiizzJf3CCiRjNo/evfw77uCYT/Bvmbz5dNmAIN2 N3BlI++0AJ4Wa9q7VuhEfODlPQnMg701kfZARa9Ux6UN0mtDVbGPdtw865sS6jw= = 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=fm2; bh=f2N5Jl FloC5s65PzLjkiGrNfUZEBGM11FoNNXWjpZi4=; b=FV84nY+5K2q68btorGbYN9 EIwhBtvmZp3/CkTQF0KRBq1njz5G9rOH5J7v4Hu9brnJG1cvsXxmVqXLtxmWNAmS smopymQGfEkeH7XuehsbwddjdmtOoTYqjjQJy0KFvGwV3MyXlmQ8O7X4tY5WrM57 IABLm3DXZn4DRR3EagPBjROB+TYtZA9unA65Vyf6gjAHmqC+jsoky3fAmmG3DWnA JF3Q5GlRi1nlSj1LYlTPwo7P+gMqPZ1OTdt/lVzmCOPwB0STCsK7HliTkV3DhRx7 Q1uRwtHRg7GcHMkKWslruoxjZNHoouJ13Mdfag1gX2/ePQX1JkpNOPueeTxtK9Tw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieeggdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepjeeileekteduhf euieevjeeiveduheevvedvgeekieevffefheeuueffuddtieeinecuffhomhgrihhnpegs sghifidrnhgvthdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 31B6836005C; Sun, 14 Feb 2021 00:55:13 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <1c0f6fbf-8df8-451c-b22c-99ca20441cbc@dogfood.fastmail.com> In-Reply-To: <799436d1-647f-c040-8db7-3d060d8cb20b@dcrocker.net> References: <20210213012528.D81996DDD4B3@ary.qy> <1ee52dcc-21dd-091d-ad5c-c3924fdfb833@dcrocker.net> <9e2dc89f-8d0d-4a7e-91f4-d3d288c1a88c@beta.fastmail.com> <799436d1-647f-c040-8db7-3d060d8cb20b@dcrocker.net> Date: Sun, 14 Feb 2021 16:54:51 +1100 From: "Bron Gondwana" To: emailcore@ietf.org Content-Type: multipart/alternative; boundary=72f7727cf09842a2b3429d6015bd972f Archived-At: Subject: Re: [Emailcore] =?utf-8?q?emailcore_-_Requested_session_has_been_sch?= =?utf-8?q?eduled_for_IETF_110?= 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: Sun, 14 Feb 2021 05:55:18 -0000 --72f7727cf09842a2b3429d6015bd972f Content-Type: text/plain Well, the next one is supposedly in San Francisco, so I'll join the class action with Europeans for that one. Probably too late to file for this time. Bron. On Sun, Feb 14, 2021, at 11:32, Dave Crocker wrote: > On 2/13/2021 4:22 PM, Bron Gondwana wrote: > > I think it's more about being unfriendly to Australians. The entire > > meeting is during my normal sleeping hours. > > staying up late is easier than getting up really early. > > harumph. > > oh the other hand, maybe there's a class action suit we could jointly file? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --72f7727cf09842a2b3429d6015bd972f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Well, the next one is supposedly in San Francisco, so I'll= join the class action with Europeans for that one.  Probably too l= ate to file for this time.
Bron.

On Sun= , Feb 14, 2021, at 11:32, Dave Crocker wrote:
On 2/13/20= 21 4:22 PM, Bron Gondwana wrote:
> I think it's more about being unfriendly to Australians. The en= tire 
> meeting is du= ring my normal sleeping hours.

staying up late is easier = than getting up really early.

harumph.

oh = the other hand, maybe there's a class action suit we could jointly file?=

d/

=
-- 
Dave Crocker
Br= andenburg InternetWorking
bbi= w.net

-- 
Emailcore mailing list

--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmail= team.com


--72f7727cf09842a2b3429d6015bd972f-- From nobody Sun Feb 14 06:33:43 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 3AF233A0D3E for ; Sun, 14 Feb 2021 06:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=J9W7yoe4; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZirrcuMk 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 nAlGtMyjr2DP for ; Sun, 14 Feb 2021 06:33:39 -0800 (PST) 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 DF6C83A0D3C for ; Sun, 14 Feb 2021 06:33:38 -0800 (PST) Received: (qmail 62344 invoked from network); 14 Feb 2021 14:33:37 -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=f385.602934c1.k2102; bh=KPfcBDxnWJ0XCp67uHtZ4HAkB5+h/PFWWXK2swJzQpk=; b=J9W7yoe4BsDReT0Zbzya/pvkc790/ta4F0ttWRhh6mTQP6eG1AALjCl8FmF6yFu+MZaLCkHml2FbzKfzjEAnDn3jAadJ4SPLqoypp2vVUob8hzhmJSdMvbUtAX3dXZoABx6ZOb2hALtv8wF7+hQjQacTwl2bwxwvSFvFzDCvPDRmvM8oiXDTu8cIcYpgsME+Xhwb8BKaNHG4EoHP7r7OwHOXEMsFFQ45Q8v52Gg4CzmyQtS0PicDU9foN6Eo5gXr/5H26RbZEJnNlLooSgNQ75TyQ/fktoULZXzJHopseS817M9pwjKMn9hqUp9jf2vIOQqHwxw0UzQVmLWAQ1u7Tg== 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=f385.602934c1.k2102; bh=KPfcBDxnWJ0XCp67uHtZ4HAkB5+h/PFWWXK2swJzQpk=; b=ZirrcuMkSi+cUm9PdJHmAawdk/vD6U3uxLinZXDIAqVLQgVhouGqUYFv8ZpZ6GP1mXKFASMj4WSV2xl9Est3/wBmK07dycoEsDGQHO/MazDisPKoTM4n1XNXBdivlQUNWPc0ptXU0tvn4kuB1mfuCaJiV6qiZno1eyl5gNC/Fd37Am1h3vENahrpg5lGUW5qar6XLjNk514LR9HZl/m3lHqsjENZB3nKd6jNTgMP0a3hRlbnt41IIa6AswRR8SYFBKPwfn2mTsKdsF6KQF2ZGoAJRKup6m3vwwAq9F8VaKdwhQoknEkEYa1dC9LU0mB5Phe/G1bRU7RgJI8fEgD9CQ== 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; 14 Feb 2021 14:33:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 4ADFA6DF264A; Sun, 14 Feb 2021 09:33:34 -0500 (EST) Date: 14 Feb 2021 09:33:34 -0500 Message-Id: <20210214143336.4ADFA6DF264A@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: brong@fastmailteam.com In-Reply-To: <1c0f6fbf-8df8-451c-b22c-99ca20441cbc@dogfood.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?emailcore_-_Requested_session_has_been_sch?= =?utf-8?q?eduled_for_IETF_110?= 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: Sun, 14 Feb 2021 14:33:41 -0000 In article <1c0f6fbf-8df8-451c-b22c-99ca20441cbc@dogfood.fastmail.com> you write: >-=-=-=-=-=- > >Well, the next one is supposedly in San Francisco, so I'll join the class action with Europeans for that one. >Probably too late to file for this time. Sounds like we should send you one of these things: https://joyresolve.com/products/barisieur-black-coffee-alarm-brewer Helpfully, John From nobody Sun Feb 14 13:36:24 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 CF98F3A0C3B for ; Sun, 14 Feb 2021 13:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=EB3nQMdg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sm55PVXM 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 ZwI6QeHmOb8m for ; Sun, 14 Feb 2021 13:36:21 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 677353A1043 for ; Sun, 14 Feb 2021 13:35:40 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 28800917; Sun, 14 Feb 2021 16:35:39 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sun, 14 Feb 2021 16:35:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=afDV zEs0qbEZd+Zie+YdKY7FKSoKkcEtdv4TJYmyvek=; b=EB3nQMdgonr+zJbzp2uW pBH0V1ZIOm7UnYufXd7UnENqWdE/anGg3M4CY8lE3brNDfOe5AaPT4EdqajT3YUF LDpzCRBgGK6EYgZmX96xMnWkWqsvn0WLdDBwpOiLXPEV6uvGVWTfWHVzZ3ABfUSL s+XUI6umZdv1jOufYPa7skt2KbCczGEep3gVF0K0f7SjrQ9cyEKtClh4gUXIo7U0 lm9bphR5UA4V4gPZoi+XboIGRA3c2SBSSoqmAm/jpgeWlDCkAmgVHZS1LvGNVXOb eVbxUszBxSfyqvahhqu1oxZiVwF3rm4MUGnkx2jBAb4GZcNA+9lEaxxHixQC9gaP HQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=afDVzE s0qbEZd+Zie+YdKY7FKSoKkcEtdv4TJYmyvek=; b=Sm55PVXM7ObCCUyAR1New2 d3kvF8LIus4DLJyKJq+3GR784dfLGeqa//JVxCn+34I0BtnopbSLFBjtF71AA8DR rc77+1N7WpYikiVDYEu5As6V5iwSfWToodNRCiRJ3olnwaQ3xlxqyCxTwDSs5gFe igB927tm4MqdA8eT8MLF8YOEPKKtd/eu5868fxHl7i7edfj4b205cX0hlzkLgoHn bV8Uhs5DzQQKL9Ltfi9rjcNeBF1xkcWxuyMa1vy8hY+uOnGRe/cbOXNMYMJUHiFW 9om0ScGOQyUovtquyKJlhoxy5zY5kKHxvtNxg0AKhVLBAUNsieNSOEvPdyDuWqpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieehgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepgfefleevgffhteeihfdvfffggfeigefhkeeljeffleeh gfeigeevffevffefgfejnecuffhomhgrihhnpehjohihrhgvshholhhvvgdrtghomhdpih gvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 675D836005C; Sun, 14 Feb 2021 16:35:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <8d5eae28-e8b7-46a3-8d6d-7cd265b1c9d8@dogfood.fastmail.com> In-Reply-To: <20210214143336.4ADFA6DF264A@ary.qy> References: <20210214143336.4ADFA6DF264A@ary.qy> Date: Mon, 15 Feb 2021 08:35:18 +1100 From: "Bron Gondwana" To: emailcore@ietf.org Cc: "John Levine" Content-Type: multipart/alternative; boundary=7229b6d9cbeb43468239fe8a6bba0a09 Archived-At: Subject: Re: [Emailcore] =?utf-8?q?emailcore_-_Requested_session_has_been_sch?= =?utf-8?q?eduled_for_IETF_110?= 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: Sun, 14 Feb 2021 21:36:23 -0000 --7229b6d9cbeb43468239fe8a6bba0a09 Content-Type: text/plain I mean... my internal selfish little voice says "sure, send me stuff" - but my espresso maker is perfectly good and quite fast. It's more that my already bad sleep habits take a bit of a hammering when I have to try to force a timezone change without the hours in a plane and different daylight patterns. No good answers to this one! Bron. On Mon, Feb 15, 2021, at 01:33, John Levine wrote: > In article <1c0f6fbf-8df8-451c-b22c-99ca20441cbc@dogfood.fastmail.com> you write: > >-=-=-=-=-=- > > > >Well, the next one is supposedly in San Francisco, so I'll join the class action with Europeans for that one. > >Probably too late to file for this time. > > Sounds like we should send you one of these things: > > https://joyresolve.com/products/barisieur-black-coffee-alarm-brewer > > Helpfully, > John > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --7229b6d9cbeb43468239fe8a6bba0a09 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I mean... my internal selfish little voice says "sure, sen= d me stuff" - but my espresso maker is perfectly good and quite fast.

It's more that my already bad sleep habits take a bit of a = hammering when I have to try to force a timezone change without the hour= s in a plane and different daylight patterns.

No good ans= wers to this one!

<= div style=3D"font-family:Arial;">Bron.

On Mon, Feb 15, 2021, at 01:33, John Levine wro= te:
>-=3D-=3D-=3D-=3D-=3D-
>
>Well, = the next one is supposedly in San Francisco, so I'll join the class acti= on with Europeans for that one. 
>Probably too late to file for this time.

Sou= nds like we should send you one of these things:


Helpfully,
John<= br>

-- 
Email= core mailing list


--
  Bron Gondwana, CEO, Fast= mail Pty Ltd
  brong@fastmailteam= .com


--7229b6d9cbeb43468239fe8a6bba0a09-- From nobody Sun Feb 14 14:36:32 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 F1B613A0CBA for ; Sun, 14 Feb 2021 14:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[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 s9rPsrHUC7Hl for ; Sun, 14 Feb 2021 14:36:29 -0800 (PST) Received: from olivedrab.birch.relay.mailchannels.net (olivedrab.birch.relay.mailchannels.net [23.83.209.135]) (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 0E4CA3A0CB9 for ; Sun, 14 Feb 2021 14:36:28 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E9D72921A66; Sun, 14 Feb 2021 22:36:27 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-18-18.trex.outbound.svc.cluster.local [100.96.18.18]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 94285921FCD; Sun, 14 Feb 2021 22:36:26 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.18.18 (trex/6.1.1); Sun, 14 Feb 2021 22:36:27 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Turn-Battle: 21f0f02034529187_1613342187422_216120069 X-MC-Loop-Signature: 1613342187422:237668983 X-MC-Ingress-Time: 1613342187422 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id B0CAC32220A9; Sun, 14 Feb 2021 22:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613342184; bh=x/gE32PeSeXVsdmy2M+ICB/Efj8kcreYxJSxoSOczu4=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=VRR7PQyTub+q5cJ46O+NSf5yWj7c4mnYNLTUsB3J35ArM+wzd5HrqJ5Y/FU8+ElDx 3Kj1y0CMz+YszuCwfGwfVlOh6yxNcgkigaRH8uLZHuGWvVtZYy+Dyq7rOAtcVpFlsM pir9EO2FEcW/YTZ1dWnOWitkA7grWhcalaBIldYJ4oASNoahC8DBeeY9i9I+alfkz1 tHIC1hzBovLSWiqHtrEqGdgKL2TIL1D5sCvamoMzQKxOXwWU7Y4dsbpYT8TSwjGn+B 4pKTnPObiW8mNGosVugXpfh6vSW4/0gFGT9NmLuQB44oMy2e0uKz6Vq/JkZzksbvWW gon1JWZNXblYQ== Reply-To: dcrocker@bbiw.net To: Bron Gondwana , emailcore@ietf.org Cc: John Levine References: <20210214143336.4ADFA6DF264A@ary.qy> <8d5eae28-e8b7-46a3-8d6d-7cd265b1c9d8@dogfood.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9d13b60f-408d-4b0c-92ce-d7475bb0a780@dcrocker.net> Date: Sun, 14 Feb 2021 14:36:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <8d5eae28-e8b7-46a3-8d6d-7cd265b1c9d8@dogfood.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] emailcore - Requested session has been scheduled for IETF 110 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: Sun, 14 Feb 2021 22:36:31 -0000 On 2/14/2021 1:35 PM, Bron Gondwana wrote: > It's more that my already bad sleep habits take a bit of a hammering > when I have to try to force a timezone change without the hours in a > plane and different daylight patterns. > > No good answers to this one! I 'travel' 2 or 3 days beforehand, to readjust my internal clock. If the change is major, it's done incrementally, over as much as a week, to reduce the traumatic effect. (In contrast with regularly doing graveyard shifts, during college, in the last 10 years, I've noticed quite a large change in how my body is affected by time shifts. It's all part of discovering that aging means inhabiting quite a different body.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Feb 14 17:07:22 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 8D47C3A0ED3 for ; Sun, 14 Feb 2021 17:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 PE7lnNH4nIir for ; Sun, 14 Feb 2021 17:07:19 -0800 (PST) Received: from bsa2.jck.com (ns.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 526793A0ED2 for ; Sun, 14 Feb 2021 17:07:19 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lBSM9-0001i9-OQ for emailcore@ietf.org; Sun, 14 Feb 2021 20:07:17 -0500 Date: Sun, 14 Feb 2021 20:07:11 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: 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] "Beginning of the ..." in RFC 5321 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, 15 Feb 2021 01:07:21 -0000 Hi. I just noticed that the first paragraph of Section 4.4 of RFC 5321 (and 5321bis) contains the phrase "at the beginning of the message content" while the fifth full paragraph of that section (starting "When the delivery SMTP server makes the "final delivery...") uses "at the beginning of the mail data...". That is correct given Section 2.3.9, which explicitly says that "message content" and "mail data" are used interchangeably (and hence that they are equivalent). It occurs to me that a causal reader, seeing the two in the same section, might assume that they were different, that "message content" referred to the material after the message header fields, and then get badly confused. The "minimal changes" principle requires not looking for places to change. On that principle, this is probably best left alone. However, if someone sees enough possibility of confusion to justify changing 4.4 and the several other places where "message content" appears and then adjusting 2.3.9, this would be a good time to ask that a ticket be opened. One of the places that might be changed is the sixth paragraph of Section 2.4 (starting "8-bit message content transmission..."), which is arguably not completely clear that 8BITMIME does not allow non-ASCII characters in header fields. If anyone is uncomfortable about that (whether we get rid of "message content" terminology or not), again, ask that a ticket be opened and, ideally, suggest text. FWIW, if we wanted to make a comment about SMTPUTF8, that paragraph would probably be the right place to put it because doing so would make the distinction perfectly clear. john (picking nits before someone else gets to them) From nobody Mon Feb 15 03:49:51 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 0C4363A11BE for ; Mon, 15 Feb 2021 03:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 QYKOVHxfi7wc for ; Mon, 15 Feb 2021 03:49:47 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AD33A11BD for ; Mon, 15 Feb 2021 03:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1613389785; bh=vH3KCtXos2DoGDwUsWqCswcLOeSa++qxBk7PppzRKOQ=; l=3798; h=To:References:From:Date:In-Reply-To; b=BOXls1JDe//edZYPSxhNClFyY+iNcbW2W4E2ES3P18gfrXIS2dcvm23uyfCdN6fQr 9WLgNfHItSO7BYJ/Ho0nv/m9/R/FglN15F88nVhfzZ94htR2brIo7fciXzvuoCVar6 HptK7S9WL/RWXJQccBklidxdwrDak9t9A2zp/1f8qJrU5yY4hslrDhJDb+gtT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC028.00000000602A5FD9.000043E4; Mon, 15 Feb 2021 12:49:45 +0100 To: John C Klensin , emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Mon, 15 Feb 2021 12:49:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] "Beginning of the ..." in RFC 5321 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, 15 Feb 2021 11:49:49 -0000 On Mon 15/Feb/2021 02:07:11 +0100 John C Klensin wrote: > > I just noticed that the first paragraph of Section 4.4 of RFC > 5321 (and 5321bis) contains the phrase "at the beginning of the > message content" while the fifth full paragraph of that section > (starting "When the delivery SMTP server makes the "final > delivery...") uses "at the beginning of the mail data...". I think both terms are very clear. "Mail data" obviously refers to the DATA command, while "message content" is the perfect companion of terms like "message envelope", "message header", and "message body". > That is correct given Section 2.3.9, which explicitly says that > "message content" and "mail data" are used interchangeably (and > hence that they are equivalent). It occurs to me that a causal > reader, seeing the two in the same section, might assume that > they were different, that "message content" referred to the > material after the message header fields, and then get badly > confused. Section 2.3.9 seems to imply that the message content has to consist of a header and a body. That becomes contradictory with having "carefully avoided imposing any requirement that an MTA (or SMTP sender or receiver) inspect and evaluate, or even know how to parse, message headers", as you wrote[*]. If that principle is useful, it should be reaffirmed here. The last paragraph of Section 2.3.1 is confusing. I propose changing it: OLD: The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section consists of a collection of header fields, each consisting of a header name, a colon, and data, structured as in the message format specification (RFC 5322 [11]); the body, if structured, is defined according to MIME (RFC 2045 [24]). The content is textual in nature, expressed using the US-ASCII repertoire [2]. Although SMTP extensions (such as "8BITMIME", RFC 6152 [47]) may relax this restriction for the content body, the content header fields are always encoded using the US-ASCII repertoire. Two MIME extensions (RFC 2047 [25] and RFC 2231 [28]) define an algorithm for representing header values outside the US- ASCII repertoire, while still encoding them using the US-ASCII repertoire. NEW: The SMTP content, also known as message content or mail data, is sent in the SMTP DATA protocol unit and usually has two parts: the header and the body. [*] https://mailarchive.ietf.org/arch/msg/emailcore/RgPrJD7X9vtlxyIUZ6bfQ-_31F0/ > The "minimal changes" principle requires not looking for places > to change. On that principle, this is probably best left alone. > However, if someone sees enough possibility of confusion to > justify changing 4.4 and the several other places where "message > content" appears and then adjusting 2.3.9, this would be a good > time to ask that a ticket be opened. I think that text is good as is. > One of the places that might be changed is the sixth paragraph > of Section 2.4 (starting "8-bit message content > transmission..."), which is arguably not completely clear that > 8BITMIME does not allow non-ASCII characters in header fields. > If anyone is uncomfortable about that (whether we get rid of > "message content" terminology or not), again, ask that a ticket > be opened and, ideally, suggest text. FWIW, if we wanted to > make a comment about SMTPUTF8, that paragraph would probably be > the right place to put it because doing so would make the > distinction perfectly clear. Yes please! Given that the spec mentions 8BITMIME, mentioning also SMTPUTF8 is absolutely deserved. Also in the examples D.1 - D.4. Best Ale -- From nobody Mon Feb 15 05:42: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 58A6F3A0A22 for ; Mon, 15 Feb 2021 05:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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=jGC2XjPX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iZY8hd6O 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 lnSNaKAOo8fz for ; Mon, 15 Feb 2021 05:42:12 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4B43A0A1C for ; Mon, 15 Feb 2021 05:42:12 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5D00D5C00B6 for ; Mon, 15 Feb 2021 08:42:11 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Mon, 15 Feb 2021 08:42:11 -0500 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:content-transfer-encoding; s=fm2; bh=perDn nTcT/L8+D9YgRynfKLfcpbg68beG47rxJrj0CM=; b=jGC2XjPXs5D/SjS68n0RX 4aXpihybYyJdiAm60Y5ZlwjMCZCozHluYADg5YnKGyxTMyF3nfuP74/wKqdSFhah Rbk1mNOJ4sGDeMN26HLMRmuL/rHdpOpljQX9y5l+OF2rUh3wmaly8Y6oNnvjlnQ2 M+d5lRznu6BBLG+kWOkiJuaRdHOKKt6OMQr/DWipI4WhvTQjt5qN/4VbntxAJ9qy Z3NTthzQwljsNG72AROYDRl3VfZrVbh2QuG5QQZ4jm7MJGFmKmrWsJ0vZu4EeJUK EHzjqe/Hg3Icwj5OCZw8YI8IoyXUHYqMs1NT1GwaNbzN7Qk4OESnDKyjN8vLKIzj A== 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=fm2; bh=perDnnTcT/L8+D9YgRynfKLfcpbg68beG47rxJrj0 CM=; b=iZY8hd6OsD8MSU+XU6xyIdUA5Gf0elcwJP8MVlimfwESIzhSkMfF8kly0 UdL/tK5FZbTMkbq8Mn1t/L0Ynsk0CECuJiIAZrTtXmJiavFToBNMfQKLIi4m/QJQ IIvG2IeOT0GwH8c4eN4yJBFy29dQDCtj9/V3UDWazTmbax4DIg6c0aOoaTUjfWVM kwY2S309PTHeIQ7D3qp0tvbvyP41mOPUJt06vUdGRfX6myrfcppY2N0WUCHi5atH SMvvXrFQEhxe+UadsDjlQqi7labFV9AOWj33Rx2OJfmWuyrMEDqxxyuPRxyrrwoX 1xiA5fEX5PvaOZoJF1Xm9D3u/JnHg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieekgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelieffle euueefkeeljeefieehgeejtddvtdduffeufeevveeftdefkeeuudevffenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED3C36B4005F; Mon, 15 Feb 2021 08:42:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 15 Feb 2021 13:41:50 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=235=3A_G=2E5=2E_Remove_or_deprecat?= =?utf-8?q?e_the_work-around_from_code_552_to_452=3F?= 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, 15 Feb 2021 13:42:13 -0000 Hi, On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote: > Hi all, >=20 > The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code)=20= > currently says: >=20 > =C2=A0=C2=A0 RFC 821 [3] incorrectly listed the error where an SMTP s= erver > =C2=A0=C2=A0 exhausts its implementation limit on the number of RCPT = commands > =C2=A0=C2=A0 ("too many recipients") as having reply code 552.=C2=A0 = The correct reply > =C2=A0=C2=A0 code for this condition is 452.=C2=A0 Clients SHOULD tre= at a 552 code in > =C2=A0=C2=A0 this case as a temporary, rather than permanent, failure= so the logic > =C2=A0=C2=A0 below works. >=20 > John noted that this suggestion may have outlived its usefulness > and/or be inconsistent with current practice. Should it be removed > and/or explicitly deprecated? I did a bit of digging and it doesn't look like Sendmail emits 552 or tr= eats it as 442 if received from other MTA. Postfix code has this commented out with a note that this workaround cre= ates more problems than it solves, due to other meaning of 552. Do people have information about other MTAs (not necessarily open source= ) on this topic? Best Regards, Alexey From nobody Mon Feb 15 15:26:39 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 B987F3A12F2 for ; Mon, 15 Feb 2021 15:26:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=n+fXlNfX; dkim=pass (2048-bit key) header.d=wizmail.org header.b=iWDpS2xl 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 SEoyrU5ZprEz for ; Mon, 15 Feb 2021 15:26:36 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 94B9F3A12EF for ; Mon, 15 Feb 2021 15:26:35 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=sscMKHC4z9JvZn4Gmp32UpVo4bDF6MJbr8gpeE8iQ18=; b=n+fXlNfX01MYyybfCb/VXkt+mf xP8Y6kmf+4UwGxHEV7BoZ3P02QaWEQc/S/Ch1BMnYg/wli4HiXroTqskkeDw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=sscMKHC4z9JvZn4Gmp32UpVo4bDF6MJbr8gpeE8iQ18=; b=iWDpS2xlDZntUGdqRomaMmhrRg lF4SAUV0gUwcTtPb6krLToqGlBcVCCeuo1jFHa4bbVZmN26bciAfW+VpSx0zmUaIMRvTFekK8RCm1 cq6fGP3rVWDGlvvPcX6jQDqVWVqHYpVdw9c6kcZI5SKPRVsSOxj5+KUTOIZlS4SrHBPMYge2HiL0m dmsIBqgGTK2ifGtWwRGoQ5aq6taCntzs48s632gG6H0B5TMeBiqB7hywdQQ8JPhQoF/uk4c8mQxg3 uQK8LIK6BUnRcFKgw+hQ8XD7yhIdGxTz6jvZSfOxx7Rznkb92Vnqe0i9Fruf8sESId2D+47hBCA9b 3pJb/jlA==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.114) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lBnGD-003gOh-NV for emailcore@ietf.org (return-path ); Mon, 15 Feb 2021 23:26:33 +0000 To: emailcore@ietf.org References: From: Jeremy Harris Message-ID: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> Date: Mon, 15 Feb 2021 23:26:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 15 Feb 2021 23:26:39 -0000 On 15/02/2021 13:41, Alexey Melnikov wrote: >> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) >> currently says: >> >>    RFC 821 [3] incorrectly listed the error where an SMTP server >>    exhausts its implementation limit on the number of RCPT commands >>    ("too many recipients") as having reply code 552.  The correct reply >>    code for this condition is 452.  Clients SHOULD treat a 552 code in >>    this case as a temporary, rather than permanent, failure so the logic >>    below works. >> >> John noted that this suggestion may have outlived its usefulness >> and/or be inconsistent with current practice. Should it be removed >> and/or explicitly deprecated? > > I did a bit of digging and it doesn't look like Sendmail emits 552 or treats it as 442 if received from other MTA. > Postfix code has this commented out with a note that this workaround creates more problems than it solves, due to other meaning of 552. > > Do people have information about other MTAs (not necessarily open source) on this topic? Exim: As a server, there is a configuration option (default: 452) for too-many-recipients. The documentation describing it doesn't mention standards. 553 is emitted for other conditions. As a client, there is no special handling for a 552; the initial 5 is taken as for any other 5xx. -- Cheers, Jeremy From nobody Mon Feb 15 15:37: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 5287B3A130F for ; Mon, 15 Feb 2021 15:37:37 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=B8rTrMZb; dkim=pass (2048-bit key) header.d=wizmail.org header.b=A0AzdNUG 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 8eNksxvycz87 for ; Mon, 15 Feb 2021 15:37:35 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 A33AD3A130E for ; Mon, 15 Feb 2021 15:37:35 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=jvveImtKHtvW7vc3OYUN41yl/tvNdbo6OV01VRUo4zs=; b=B8rTrMZb406iF8P1tN6K5o8G2t F94mAB1b8a8/UDD7b08KA7YYeN23hMoPZJwdOr1t2RSC0bAfeRQaE2xguPAA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=jvveImtKHtvW7vc3OYUN41yl/tvNdbo6OV01VRUo4zs=; b=A0AzdNUGkZQWInc1udixVbNKrB dyUhwkPlUsPbAZE2UVzECTjV394kRS2pdrfL3Jsebn+hXgUALYeJ6RwDmsz+5jDGyCBuo6YFWDx/f z8dtl8W8hemeVVGCN//6RvjBuRRnSd3MKQ78dHHbHq/S59pVba3G6gSanVolG6f45oHtudGaVY6Nx DYpZLJd2DHNhFdAtXXsLZCt83KtxObwrkbcSecXqj+e+iBuKrNwkwbZh88+J1dW3rKDtQWyPuMrnp Uy872QrZ8T5IzlNyklzKB/buap5t5lbcdYBXC3DRqoft5hlj1YRQbZfjx8fvkpfwRVzljmRWrLgBM UVQXAxHw==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.114) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lBnQr-003ggW-Dl for emailcore@ietf.org (return-path ); Mon, 15 Feb 2021 23:37:33 +0000 To: emailcore@ietf.org References: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> From: Jeremy Harris Message-ID: <83d59ca4-a5e0-9c04-5261-490f3bf4b88c@wizmail.org> Date: Mon, 15 Feb 2021 23:37:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 15 Feb 2021 23:37:37 -0000 On 15/02/2021 23:26, Jeremy Harris wrote: >  553 is emitted for other conditions. 552, sorry. -- Cheers, Jeremy From nobody Mon Feb 15 15:40:11 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 B8A743A1316 for ; Mon, 15 Feb 2021 15:40:10 -0800 (PST) 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 aCzpcUm2QuPg for ; Mon, 15 Feb 2021 15:40:09 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 548643A1315 for ; Mon, 15 Feb 2021 15:40:09 -0800 (PST) Received: (qmail 2772 invoked from network); 15 Feb 2021 23:40:08 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (2373d630-6fe7-11eb-8201-4fbc89049f4a); Mon, 15 Feb 2021 15:40:08 -0800 To: emailcore@ietf.org References: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <5dd9b4f9-ea33-f4e3-5eef-76ef0ec99171@linuxmagic.com> Date: Mon, 15 Feb 2021 15:40:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 2373d630-6fe7-11eb-8201-4fbc89049f4a 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 #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 15 Feb 2021 23:40:11 -0000 On 2021-02-15 3:26 p.m., Jeremy Harris wrote: > On 15/02/2021 13:41, Alexey Melnikov wrote: >>> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) >>> currently says: >>> >>>      RFC 821 [3] incorrectly listed the error where an SMTP server >>>      exhausts its implementation limit on the number of RCPT commands >>>      ("too many recipients") as having reply code 552.  The correct >>> reply >>>      code for this condition is 452.  Clients SHOULD treat a 552 code in >>>      this case as a temporary, rather than permanent, failure so the >>> logic >>>      below works. >>> >>> John noted that this suggestion may have outlived its usefulness >>> and/or be inconsistent with current practice. Should it be removed >>> and/or explicitly deprecated? >> >> I did a bit of digging and it doesn't look like Sendmail emits 552 or >> treats it as 442 if received from other MTA. >> Postfix code has this commented out with a note that this workaround >> creates more problems than it solves, due to other meaning of 552. >> >> Do people have information about other MTAs (not necessarily open >> source) on this topic? > > Exim: > >  As a server, there is a configuration option (default: 452) >  for too-many-recipients. >  The documentation describing it doesn't mention standards. >  553 is emitted for other conditions. > >  As a client, there is no special handling for a 552; the initial >  5 is taken as for any other 5xx. Hmmm.. why should this be a temporary failure? lmprintf("550 Too many invalid user RCPT's sent. Exiting.\r\n"); Permanent failure seems to be the proper response, otherwise an email client MAY foolishly keep trying to send to the whole list again and again.. And of course, another MTA may as well, when we KNOW it will fail the next time and the next time.. Sorry, someone will have to enlighten me.. However, it should be noted.. there 'could' be alternate cases, where for instance, in environments with rate limiters, it could be different for authenticated connections (outbound rate limiters) vs inbound rate limiting (MTA->MTA) vs system capabilities (Max memory limits etc triggered by too many RCPTS) I don't think even in MTA-MTA traffic we want it treated as a temporary error, why keep trying to perform an action that will not succeed. -- "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 Mon Feb 15 15:46:25 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 AA5E73A1324 for ; Mon, 15 Feb 2021 15:46:23 -0800 (PST) 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 sd4s_V6drdto for ; Mon, 15 Feb 2021 15:46:22 -0800 (PST) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1DC3A1322 for ; Mon, 15 Feb 2021 15:46:22 -0800 (PST) Received: (qmail 16276 invoked from network); 15 Feb 2021 23:46:20 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (013adb94-6fe8-11eb-be95-df3a31a7bb2f); Mon, 15 Feb 2021 15:46:20 -0800 To: emailcore@ietf.org References: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> <5dd9b4f9-ea33-f4e3-5eef-76ef0ec99171@linuxmagic.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Mon, 15 Feb 2021 15:46:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5dd9b4f9-ea33-f4e3-5eef-76ef0ec99171@linuxmagic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 013adb94-6fe8-11eb-be95-df3a31a7bb2f 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 #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 15 Feb 2021 23:46:24 -0000 On 2021-02-15 3:40 p.m., Michael Peddemors wrote: > On 2021-02-15 3:26 p.m., Jeremy Harris wrote: >> On 15/02/2021 13:41, Alexey Melnikov wrote: >>>> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) >>>> currently says: >>>> >>>>      RFC 821 [3] incorrectly listed the error where an SMTP server >>>>      exhausts its implementation limit on the number of RCPT commands >>>>      ("too many recipients") as having reply code 552.  The correct >>>> reply >>>>      code for this condition is 452.  Clients SHOULD treat a 552 >>>> code in >>>>      this case as a temporary, rather than permanent, failure so the >>>> logic >>>>      below works. >>>> >>>> John noted that this suggestion may have outlived its usefulness >>>> and/or be inconsistent with current practice. Should it be removed >>>> and/or explicitly deprecated? >>> >>> I did a bit of digging and it doesn't look like Sendmail emits 552 or >>> treats it as 442 if received from other MTA. >>> Postfix code has this commented out with a note that this workaround >>> creates more problems than it solves, due to other meaning of 552. >>> >>> Do people have information about other MTAs (not necessarily open >>> source) on this topic? >> >> Exim: >> >>   As a server, there is a configuration option (default: 452) >>   for too-many-recipients. >>   The documentation describing it doesn't mention standards. >>   553 is emitted for other conditions. >> >>   As a client, there is no special handling for a 552; the initial >>   5 is taken as for any other 5xx. > > Hmmm.. why should this be a temporary failure? > >  lmprintf("550 Too many invalid user RCPT's sent. Exiting.\r\n"); > > Permanent failure seems to be the proper response, otherwise an email > client MAY foolishly keep trying to send to the whole list again and > again.. > > And of course, another MTA may as well, when we KNOW it will fail the > next time and the next time.. > > Sorry, someone will have to enlighten me.. > > However, it should be noted.. there 'could' be alternate cases, where > for instance, in environments with rate limiters, it could be different > for authenticated connections (outbound rate limiters) vs inbound rate > limiting (MTA->MTA) vs system capabilities (Max memory limits etc > triggered by too many RCPTS) > > I don't think even in MTA-MTA traffic we want it treated as a temporary > error, why keep trying to perform an action that will not succeed. Oh, to avoid confusion.. MagicMail SMTP returns.. rcpt_checks/max_rcpts.c: return "452 Too many recipients (#4.5.3.1)"; However, the question remains.. why should it be temporary? We have always just done this according to RFC, but it doesn't seem logical, as the remote client/MTA will just queue up that batch for retry, no? -- "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 Tue Feb 16 05:20:10 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 082DE3A0C3B for ; Tue, 16 Feb 2021 05:20:09 -0800 (PST) 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=valimail.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 p0Wmknik45LR for ; Tue, 16 Feb 2021 05:20:07 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D7D853A0BC5 for ; Tue, 16 Feb 2021 05:20:06 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id t62so9289604qke.7 for ; Tue, 16 Feb 2021 05:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Zs8IZU0uNDIOC07p9M+PDrh56J/e2+/03fGIKMT2MvY=; b=eVHvW1UIEN9rub85hzsfhddLL7LuO0ihy1YgN8VJ2BSV9UXXWJBbvptGaa6NZ3L6SW qVNcY/zhSkIP6B657GVf7bhbMkCREwaZEobAtdcIOX8DxgPpBHHXkkI5vl3Gl7O8vYiI A4pHDqOQw9uwObFdWlvv8y5AyqDPxWBXcQSb+xLrPkagqSxqnnDdTjz8ec4+/L5ukLVi 8ROc/zWvpq+25DCA4NHGBV1VdJJPtI3Sc0Un1yArBitrdrhdqvRLWlWUfsczKK/kDprv iHqxVliB6IBiucunfAqC+e7JJCwYBiRZSEnL5yZYcNXznc5vcRnMuJuDq5cumvBmWFmA amfA== 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; bh=Zs8IZU0uNDIOC07p9M+PDrh56J/e2+/03fGIKMT2MvY=; b=t6DqDgi2yMStx+xIntGJtuY5ngVsN40zhGIGZG59jTwFl0U0wHjRVagdQpD5Df3FyI ee/g5kkIFMUXJ+POuQdG8h4HZodbw3jaPE94n4RNwaTSepQs6dB9skQCX+QTJzXmtNP7 Nbbl7+nLvK9IEEJr71zzu0aLkBmuAvMGmXqY6uef2RQj6e9aIqdLcGv0p2IrIc4g7WLJ 1UakJEmYmiwIgDJYRKwx3pMnpDu7/xKT7F2OHGc5OZST1Kb1a/YUw/Bo5YimFhrGPoXL Mz+uxB56gO17XNkmVurf8OfIRPgjxhNxYFCokTBODgq9Q2fA7MOshFO245xaaQ5KIkVa dKlQ== X-Gm-Message-State: AOAM532xIGzjNKzkoTLvz+ZFIqjCsPHZYhM3z2tzdfcGySNqbRmsD2hf JwGW0ZfEcv0ES46zJWCb+CQGFAjp/Y0Ny44jX8966OPv27E= X-Google-Smtp-Source: ABdhPJyvbB01Z9vDYj8fqW/56bb7H02dtM8CxYfn4Uh7Dvs+/BF3D6+Y0oIeyLmhr/qr12g4Rj2B3d+llGzofwqIzL0= X-Received: by 2002:a37:78f:: with SMTP id 137mr19566117qkh.208.1613481605462; Tue, 16 Feb 2021 05:20:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Tue, 16 Feb 2021 08:19:49 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2105e05bb73f5c9" Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 16 Feb 2021 13:20:09 -0000 --000000000000f2105e05bb73f5c9 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 15, 2021 at 8:42 AM Alexey Melnikov wrote: > Hi, > > On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote: > > Hi all, > > > > The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) > > currently says: > > > > RFC 821 [3] incorrectly listed the error where an SMTP server > > exhausts its implementation limit on the number of RCPT commands > > ("too many recipients") as having reply code 552. The correct reply > > code for this condition is 452. Clients SHOULD treat a 552 code in > > this case as a temporary, rather than permanent, failure so the logic > > below works. > > > > John noted that this suggestion may have outlived its usefulness > > and/or be inconsistent with current practice. Should it be removed > > and/or explicitly deprecated? > > I did a bit of digging and it doesn't look like Sendmail emits 552 or > treats it as 442 if received from other MTA. > Postfix code has this commented out with a note that this workaround > creates more problems than it solves, due to other meaning of 552. > > Do people have information about other MTAs (not necessarily open source) > on this topic? > > I've reached out to a few large mailbox providers and a couple of commercial MTA vendors on this question. Still collecting answers, but hope to post results here by the end of the week. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* ` This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f2105e05bb73f5c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 15, 2021 at 8:42 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
=
Hi,

On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote:
> Hi all,
>
> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) > currently says:
>
>=C2=A0 =C2=A0=C2=A0 RFC 821 [3] incorrectly listed the error where an S= MTP server
>=C2=A0 =C2=A0=C2=A0 exhausts its implementation limit on the number of = RCPT commands
>=C2=A0 =C2=A0=C2=A0 ("too many recipients") as having reply c= ode 552.=C2=A0 The correct reply
>=C2=A0 =C2=A0=C2=A0 code for this condition is 452.=C2=A0 Clients SHOUL= D treat a 552 code in
>=C2=A0 =C2=A0=C2=A0 this case as a temporary, rather than permanent, fa= ilure so the logic
>=C2=A0 =C2=A0=C2=A0 below works.
>
> John noted that this suggestion may have outlived its usefulness
> and/or be inconsistent with current practice. Should it be removed
> and/or explicitly deprecated?

I did a bit of digging and it doesn't look like Sendmail emits 552 or t= reats it as 442 if received from other MTA.
Postfix code has this commented out with a note that this workaround create= s more problems than it solves, due to other meaning of 552.

Do people have information about other MTAs (not necessarily open source) o= n this topic?


I've reached out to a few large mailbox provi= ders and a couple of commercial MTA vendors on this question. Still collect= ing answers, but hope to post results here by the end of the week.
--

Todd Herr | Sr. Technical Program Manager
<= div style=3D"text-align:left">e:= todd.herr@valimail.com
p:
=

=

`

This email and all data transmitted with it contains confidential= and/or proprietary information intended solely for the use of individual(s= ) authorized to receive it. If you are not an intended and authorized recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--000000000000f2105e05bb73f5c9-- From nobody Tue Feb 16 06:09:55 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 CD5593A0D13 for ; Tue, 16 Feb 2021 06:09:53 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=i39/sQWG; dkim=pass (2048-bit key) header.d=wizmail.org header.b=dBLw9MJs 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 xF-NxiRz-KxZ for ; Tue, 16 Feb 2021 06:09:51 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 C06B03A0D10 for ; Tue, 16 Feb 2021 06:09:51 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=gIQhHHdbX1hnRXuEktsKFDuAi9+0i9PJycGjVwcSAx4=; b=i39/sQWGT4LA9czCrOgIZoaxAW zRAFHmBQMm0ahWLw4ONIsn5R0PkL/IX/sFC0Xg2z1EbUAAZrPDjB7JxzkRBw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=gIQhHHdbX1hnRXuEktsKFDuAi9+0i9PJycGjVwcSAx4=; b=dBLw9MJsqRB1K1cy2aLE8AqWxT v7EfTUhFTxw/jNmKnl9aAf8kWKix4MbtzOcRL680uCWjxm3h267yz312xdG8hXH7Ql5HR3Nfi07Mt 6P/z3oVtnJ7w7qLGP6OgDo/QaTc//UqI8n4MPu1QrBcWtKBaq/eegfcJ7HrivjnlWqEehxQCm8Qth sXNkBoYlySlRdPtP69tRiTTAFuf+YD3KeoYcXcgKh0ihf7UJfipOasWq3UlV1E3tYk30W7kw4Sokp C/oP+3etWj2wt3cPZb6kuWFh92R7sB5zfNkx1ADdx+Brt9LHWQrS6rVjsTpAMATq2ga8UqgT0uXDx WWBhwFRw==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.114) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lC12z-003xYY-LE for emailcore@ietf.org (return-path ); Tue, 16 Feb 2021 14:09:49 +0000 To: emailcore@ietf.org References: <8874dfd9-eff4-017b-da16-81db965e8f6d@wizmail.org> <5dd9b4f9-ea33-f4e3-5eef-76ef0ec99171@linuxmagic.com> From: Jeremy Harris Message-ID: Date: Tue, 16 Feb 2021 14:09:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? 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, 16 Feb 2021 14:09:54 -0000 On 15/02/2021 23:46, Michael Peddemors wrote: > Oh, to avoid confusion.. MagicMail SMTP returns.. > > rcpt_checks/max_rcpts.c:    return "452 Too many recipients (#4.5.3.1)"; > > However, the question remains.. why should it be temporary? We have always just done this according to RFC, but it doesn't seem logical, as the remote client/MTA will just queue up that batch for retry, no? It depends what command is being responded to. It it was a RCPT command, after several such had been accepted, a 4xx should mean that the accepted batch are still ok for DATA, and the remainders will need to go as a separate transaction. Even as a response to end-of-data it's not totally unreasonable - I might imagine, say, a disk-space check failing *because of* the number of accepted recipients. Unusual, and I don't know if any MTA in existence does that, but possible. On the other side of the coin, I can imaging anti-spam configured MTA deliberately permanently-rejecting an entire message because it regards the attempted number of RCPT commands as excessive. So, both 4xx and 5xx are reasonable and should mean what they mean for other "xx". -- Cheers, Jeremy From nobody Tue Feb 16 16:49:13 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 2E5373A1371 for ; Tue, 16 Feb 2021 16:49:11 -0800 (PST) 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 v7Pit0P4eIGT for ; Tue, 16 Feb 2021 16:49:09 -0800 (PST) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id 12FD53A134A for ; Tue, 16 Feb 2021 16:49:08 -0800 (PST) Received: (qmail 8425 invoked from network); 17 Feb 2021 00:49:07 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (f0dd6820-70b9-11eb-b47f-8345dd4cb17f); Tue, 16 Feb 2021 16:49:07 -0800 To: mailop@mailop.org, emailcore@ietf.org References: <20210215210721.0EAAC6E00D92@ary.qy> <4325e1e8-1568-04a2-2173-f6b071040c05@tana.it> <922b1547-c6de-ea63-36fd-102223a68d0f@rspamd.com> <79c6aad1-a89f-0ba2-44e7-a737551acd55@linuxmagic.com> <8ec70e21-d998-49d7-66bc-3349c3e5b9d4@rspamd.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <84c3f284-a5ad-508d-f96a-be7455404ddf@linuxmagic.com> Date: Tue, 16 Feb 2021 16:49:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8ec70e21-d998-49d7-66bc-3349c3e5b9d4@rspamd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: f0dd6820-70b9-11eb-b47f-8345dd4cb17f 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] [mailop] Spamhaus Public Mirror Error Return Code Update 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, 17 Feb 2021 00:49:11 -0000 On 2021-02-16 4:26 p.m., Vsevolod Stakhov via mailop wrote: > On 16/02/2021 21:25, Michael Peddemors via mailop wrote: >> FYI, you might want to check your outbound spam filter ;) >> >> X-Spam: Yes >> >> One thing to note, and maybe should be something to actually take up >> with RFC's, but wonder if flags like this should some how become trace >> headers.. >> >> Eg, which system put that header into the header list.. >> >> Especially now that inbound, outbound, and in transit systems and MTA's, >> may actually be involved.. >> >> Or better yet, if a system flags a message as spam, should you allow it >> out the door? >> >> Looking at the headers, have to 'guess' that it was inserted by .. >> >> Received: from mail.highsecure.ru > > Yes, that's because of DBL listing of some of the urls quoted by myself > in the reply. I have a mail system configured to mark both inbound and > outbound flows mainly for testing purposes. Normally Rspamd removes this > header for outbound traffic but it could be useful to keep X-Spam header > for the mailing lists traffic (and that's the reason why this is > configured so in my mail system, well, apart from my laziness to make it > properly via Rspamd settings). Anyway, thank you for pointing that out! > > I would strongly support any standards around mail trace headers for > spam, as they are very common and very different in the email flows. We > use several regular expressions to use those headers > (https://github.com/rspamd/rspamd/blob/master/rules/regexp/upstream_spam_filters.lua) > but this list is very far from being complete. > > Apparently, any standard would reduce and simplify (likely) this > processing, especially if there is a way to check if this header is > genuine - e.g. ed25519 signatures are fairly cheap and they are > deterministic, meaning that a single signature might be reused for the > same input + keypair for both signing and verification so caching might > make it even cheaper for popular values and domains. > _______________________________________________ Yeah, we have a pretty long list of 'upstream_spam_filters' as well, maybe it would be worth while to find a location to put a definitive list that everyone can contribute to.. but to reiterate, I don't have a solution, but whatever convention(s) that we come up with, it should be something that can 'show' which mail processing system added the header, and thus by making it a 'trace header' (adding it in order) might make sense. I don't think we have to check if it is genuine, I mean who would forge a 'This is spam' header, let's not make it too complex. But really this work on standards for 'flagging' a message in transit, should probably be taken up in the IETF, or at least M3AAWG could come up with some recommendations to get it start. But one form of 'flag' could be 'I consider this to be spam'. However, I should point out, because of the many different systems that flag a message as spam, some upstream spam filters are more trust worthy than others, eg not all messages flagged as spam, would we reject, some "we" (as in MTA operators) might just filter to the spam folder, or weight more heavily in scoring etc.. If that is beneficial, then maybe standardized on a single naming convention might not be best. And of course, there is the case where a header COULD be forged, eg a 'this is not spam' flag, but I think everyone would ignore that. And then the case where if everyone used the same flag, if I believed my spam filter was more accurate than others, I would have to strip that header, so I could make the decision on whether to add that. Which makes another case for having it a trace header, where each transiting MTA can make their own determination. (Currently of course, we have to strip message header flags incoming that normally only our own systems would insert at delivery time, before we do our own evaluation) -- "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 Tue Feb 16 21:57:46 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 AA2443A153F for ; Tue, 16 Feb 2021 21:57:45 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 pxqYl3FcAk5J for ; Tue, 16 Feb 2021 21:57:43 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 65E023A153E for ; Tue, 16 Feb 2021 21:57:43 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id t15so4190960ual.6 for ; Tue, 16 Feb 2021 21:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2xI/5mm/UmLsJip69XVJqVA0w3g7MUfrPXrtl2XoW8A=; b=apj2FVoywYOR4QyfXyOQ6MITfgYaFmgvJrIjsRDBXAR5OrIsjRd+bj14oSqZrEkB+x ouSsdhUr8ISz+VLF2ND2OTwelW3yiOzFOrHYfTdHKTgsQvfP7HmXnbJhNiOi/nTEKB6Z tKOhg02H0BlZl4fOqe2kbQWMAlVK3IrUGnRkk81K7GDETEN1elIMSLdy3g1FziHZ1X7I xliepeR0LWU6ojPo3ajLmAf2vtzibvd9q5HLjPzG2k0uY1b34tfAZdggzH3FfJgIuOSF vW9TFmrDE7/fzYIt8JuyDks1Nq+jY1B3KNPAbPJ+pYBR59GiMYh8PlnQ1IHpEiNWtVbx ep9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2xI/5mm/UmLsJip69XVJqVA0w3g7MUfrPXrtl2XoW8A=; b=TzuRqP1dghwEwEfkntw1jv+DAKOWwDps1r3PHdEpYm3vzx6tBdgJcqwM5MlVwNP+lv 1qsMpHcAxxnx3eGM7KnFOdICJBbYyHJc1ziGtvK9k/j+C2V94ArVI5D98wfUQnMxQJzE idJ5BUB8PMfP6AvHkJ2UnYNNzNTpWY8HfbsT+Y5NmDreH4dRtS6/Wq1Cv07jw3HCgFy0 mJ9xl66NS3Ojl7f1uziUiXYC1QdnxRurbnzbtIXZnvUJfbF16QICKgCK7dhgTeQc4nHL 5cHEwYs97NlvtZ5sbWPMCfmJEGOhDHxJdA05/gyY3RJyiRwk2a96filFHCDvfHT0YIe0 9X4A== X-Gm-Message-State: AOAM531XYvV9PjZfUEmUnzX7cG+zlstHseItN3rSZL3CEx/f47GL/ZMw Ez/Ll5bceyGK3Rg4eIh2PXkxoHdZfPNO1zVWOAw8IKH4P7g= X-Google-Smtp-Source: ABdhPJxC9Pn8hk5p8hgIbeJwkYKWBlUjb6FEyCkoEdPXNneehzhy+zlL2wX0x3ep7hmx4biPadXLHN3KZ9RNVhf6P3k= X-Received: by 2002:ab0:539b:: with SMTP id k27mr3051447uaa.76.1613541461880; Tue, 16 Feb 2021 21:57:41 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 16 Feb 2021 21:57:29 -0800 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa708a05bb81e5f9" Archived-At: Subject: [Emailcore] Another document about trace 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: Wed, 17 Feb 2021 05:57:46 -0000 --000000000000aa708a05bb81e5f9 Content-Type: text/plain; charset="UTF-8" As I'm getting caught up on this thread, I was reminded of RFC 6729 which augmented trace fields to optionally include details about why there might be a large time gap between two trace fields. Its choice of language was to refer to "Received" as typically "the" trace field. I don't know if that helps either way here. Notably, that came after RFC 5451, the original version of RFC 8601, which also marks Authentication-Results as a "trace field". I can say that as I wrote both of those documents, my understanding of "trace field" was that the placement of such fields is significant, and thus their handling by MTAs was constrained. I also didn't notice the ambiguities in 5321/5322 back when I worked on either one. I'm assuming when Alexey (I think it was him) says "fix this in emailcore", his proposal is that we fix the ambiguities Dave identified in 5321/5322 regarding the term "trace field" to match the general use that has been claimed in 5451 and its successors (there have been three), consistent also with 6729 and any other RFC that made use of the term. If my assumption is correct, could Delivered-To reference 5321bis/5322bis normatively, and then also use the term, which will render them all consistent on publication? -MSK --000000000000aa708a05bb81e5f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I'm getting caught up on this thread, I was re= minded of RFC 6729 which augmented trace fields to optionally include detai= ls about why there might be a large time gap between two trace fields.=C2= =A0 Its choice of language was to refer to "Received" as typicall= y "the" trace field.=C2=A0 I don't know if that helps either = way here.

Notably, that came after RFC 5451, t= he original version of RFC 8601, which also marks Authentication-Results as= a "trace field".

I can say that as I wr= ote both of those documents, my understanding of "trace field" wa= s that the placement of such fields is significant, and thus their handling= by MTAs was constrained.=C2=A0 I also didn't notice the ambiguities in= 5321/5322 back when I worked on either one.

I= 'm assuming when Alexey (I think it was him) says "fix this in ema= ilcore", his proposal is that we fix the ambiguities Dave identified i= n 5321/5322 regarding the term "trace field" to match the general= use that has been claimed in 5451 and its successors (there have been thre= e), consistent also with 6729 and any other RFC that made use of the term.= =C2=A0 If my assumption is correct, could Delivered-To reference 5321bis/53= 22bis normatively, and then also use the term, which will render them all c= onsistent on publication?

-MSK
--000000000000aa708a05bb81e5f9-- From nobody Wed Feb 17 03:25:03 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 A9FA83A192C for ; Wed, 17 Feb 2021 03:25:01 -0800 (PST) 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=TNbETxj/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vylgMWl/ 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 HxuSUOPIG_ER for ; Wed, 17 Feb 2021 03:25:00 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA453A1906 for ; Wed, 17 Feb 2021 03:25:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EFFED5C01BC for ; Wed, 17 Feb 2021 06:24:56 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Wed, 17 Feb 2021 06:24:56 -0500 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:content-transfer-encoding; s=fm2; bh=By5do OxVIqQu4z31oyYIFU6rxW7iw1i4sJ8stiGxHlo=; b=TNbETxj/5GvVhA0DcU3/M ZQVvh7jTsq/8Klgjr49hM8LT6QmblXa/Gfq4jSqRvdJkaj71np3IF3afufE8lFVJ d80ercfRVdCxqllmDiCZBU8jFn8jt3dQk3ZzTt00orYBKk3nRiZUDoM5XYy8WWsf SAOZ+6gHACkSmalqusp4LU6twMDfJ0bITa1E2EXqDyveYQ48+ioLDroI+RuUz712 sIN+BCJStDVy6hyWW9z+ZraDoGUrGzGv1fPTR6wWIBSnvCDcHGDnYcyw5u/fuKPS 9RtOqhoerhZzX3/Qpv/Mleqhpv5Ma9BZq66TI36kqyFMO9JY/efH8jEQK6GS9r3e g== 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=fm2; bh=By5doOxVIqQu4z31oyYIFU6rxW7iw1i4sJ8stiGxH lo=; b=vylgMWl/jIRa+6FDOvx+6szGVLVm0Ix8hgu8WTHSZ1oOz8OyCAHF1wrqS Jl/75i8/wwnXuWWN2fUeKx7g3Gq9e87Q+AZPUbV4TP5aoLGh5sQtw0wovKRjxe7y cu1Y/ay8jrfHQSLsdk3WmM0tuYbGFJ1f3fSpQt1YRuRlWqXYHPQvon0Ne2+B7Kv4 KHbCz+zahYweB3qNvCie4Q00RBkeLmAzUyq9+oFK/mmaLWAb/SUspfDywjdlrHdz 4je6IjrZtwV4pHzlns1rMCkiSzJjD09WVTKC37Gb7suWDxMh20J1widFTf+ZH0qT zBQNLGroeVCOob4Q/9LSMCDzDTP/A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjedvgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelveejfe evhfdvfeeftdegfeduveekkeejgfffgfeffeeiheelleefgfegfeeuvdenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8224F6B4005F; Wed, 17 Feb 2021 06:24:56 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <42419b06-ae5a-48e0-6f95-ab3cec66b13a@isode.com> References: <42419b06-ae5a-48e0-6f95-ab3cec66b13a@isode.com> Date: Wed, 17 Feb 2021 11:24:35 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?CALL_FOR_FEEDBACK=3A_Ticket_=2318=3A_G=2E7?= =?utf-8?q?=2E11=2E_Should_1yz_Be_Revisited=3F?= 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, 17 Feb 2021 11:25:02 -0000 Hi all, As there were no proposals in the Internet Draft form, I am closing this= ticket. Best Regards, Alexey On Tue, Jan 19, 2021, at 2:48 PM, Alexey Melnikov wrote: > Dear EMAILCORE participants, >=20 > I would like to start 4 weeks feedback period (ending on February 16th= =20 > 2021) on the following issue (*): >=20 > =C2=A0 RFC 5321 depreciated the "positive preliminary reply" response= code > =C2=A0 category with first digit "1", so that the first digit of vali= d SMTP > =C2=A0 response codes must be 2, 3, 4, or 5. It has been suggested (s= ee > =C2=A0 mail from Hector Santos with Subject "SMTP Reply code 1yz Posi= tive > =C2=A0 Preliminary reply", March 5, 2020 12:56 -0500, on the SMTP lis= t) that > =C2=A0 these codes should be reinstated to deal with some situations = that > =C2=A0 became more plausible after 5321 was published. Do we need to = take > =C2=A0 this back up? >=20 > Unless there is credible proposal in the form of a draft within 4 week= s,=20 > I propose this issue is to be resolved as "no change required". If you= =20 > have feedback one way or another, please send this in this thread. >=20 >=20 > Best Regards, >=20 > Alexey, as a co-chair >=20 > (*) I would usually ask for 2 weeks, but this issue might possibly=20 > requires writing a draft, so giving it a bit more time. >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > From nobody Wed Feb 17 07:06:10 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 852333A1A31 for ; Wed, 17 Feb 2021 07:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 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_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 bBOG8Tgilxtb for ; Wed, 17 Feb 2021 07:06:04 -0800 (PST) Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) (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 89A503A1ABD for ; Wed, 17 Feb 2021 07:06:02 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 21484543693; Wed, 17 Feb 2021 15:06:01 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-133-14.trex.outbound.svc.cluster.local [100.96.133.14]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1E11F543171; Wed, 17 Feb 2021 15:05:59 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.133.14 (trex/6.1.1); Wed, 17 Feb 2021 15:06:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Robust-Soft: 15902b4c68980e29_1613574360807_1207597977 X-MC-Loop-Signature: 1613574360807:104551536 X-MC-Ingress-Time: 1613574360807 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id E3D5831A123B; Wed, 17 Feb 2021 15:05:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1613574358; bh=i3VLRFKLIFKi/+Bt27WG7CoVsq6IXPrhB0QX9F+wZpU=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=FsaMq4sHT1ARgu84HLlE/yfHvD+C44vbTePoS5Yy30bmGndQOT0UTtlTubo9nDokR tyST3hu9H9dxfZPgch87OhzP/8f8WtDLVGG9rOrYnAGuDN7MpST+aOup9SYCKbNrow I6lv5H/WOl011udg/ivlR2a3Kgl42cJn+3QMqjsbneIA7qY6AFxscezMsnLjjwPAhj ARjUigUrafUUkPr7xPc/akdlGJVOQHha6DhmBgrH+v39MtK3IgwMge/ZWI7+kVBe4H TtZVHv3ie4wXpwA4VhL1txsyVT+qSuD5nl1Ngkia4FhfG2zuZhPOUedANnWilcQROz R8rJcEWiVeEWQ== Reply-To: dcrocker@bbiw.net To: "Murray S. Kucherawy" , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8b6305d8-cb49-1c45-b351-0346030b8534@dcrocker.net> Date: Wed, 17 Feb 2021 07:05:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Another document about trace 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: Wed, 17 Feb 2021 15:06:09 -0000 On 2/16/2021 9:57 PM, Murray S. Kucherawy wrote: > If my assumption is correct, could Delivered-To reference > 5321bis/5322bis normatively, and then also use the term, which will > render them all consistent on publication? The Delivered-To draft I submitted does not contain the term, but added the ordering requirement directly. This decouples the document from whatever timeline emailcore is on. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Feb 17 22:07:22 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 90A2D3A0AE6 for ; Wed, 17 Feb 2021 22:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 jiibAtiEVA2A for ; Wed, 17 Feb 2021 22:07:18 -0800 (PST) Received: from bsa2.jck.com (ns.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 E7F843A0AE5 for ; Wed, 17 Feb 2021 22:07:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lCcT6-000JQB-LR for emailcore@ietf.org; Thu, 18 Feb 2021 01:07:16 -0500 Date: Thu, 18 Feb 2021 01:07:10 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: 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] Updating 1123 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, 18 Feb 2021 06:07:21 -0000 Hi. I just noticed that 5321bis indicates that it updates RFC 1123. I think that is just a carryover from RFC 5321 and can be deleted. Does anyone see a reason why it should be retained? If I don't hear from anyone by the time I start generating and posting -02 (assume circa 24 hours from now) I'm going to take it out -- it can always be put back later if someone finds something and I don't think this is worth a ticket. Of course, the WG Chairs can overrule me on the ticket bit should they choose to do so. john (obviously as editor) From nobody Thu Feb 18 08:44:16 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 94C663A147F for ; Thu, 18 Feb 2021 08:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s4AD93t8gUC for ; Thu, 18 Feb 2021 08:44:10 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B40D3A1449 for ; Thu, 18 Feb 2021 08:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1613666643; bh=aD0KPgl8qRzWeuD0tK94IGm5ZEDOPH6PTV7epYCfMjs=; l=1521; h=To:References:From:Date:In-Reply-To; b=A+en+OkPkwD1JlWmdBPzhi+Px2rZsVUppwPyfHhBsc/OV8OWoY99U/M/4LKUEUphI k924ijUloQJutd0Qgw55/pSxwNadIcx3mHoFLzzxo1rOJvfH+y5qOr9mrVt2PER/rj 7f+XExXPna/FvWhhX1HvTkK2jn/cI56QKf8lILzMC7Wv6bS9avkOnIgrADNhw Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.00000000602E9953.00003A26; Thu, 18 Feb 2021 17:44:03 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Thu, 18 Feb 2021 17:44:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Updating 1123 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, 18 Feb 2021 16:44:15 -0000 On Thu 18/Feb/2021 07:07:10 +0100 John C Klensin wrote: > > I just noticed that 5321bis indicates that it updates RFC 1123. > I think that is just a carryover from RFC 5321 and can be > deleted. Does anyone see a reason why it should be retained? When 5321 is obsoleted, those updates will be lost? > If I don't hear from anyone by the time I start generating and > posting -02 (assume circa 24 hours from now) I'm going to take > it out -- it can always be put back later if someone finds > something and I don't think this is worth a ticket. I read various places that seem to imply that the update should be carried over from RFC 5321: updates RFC 1123 (replacing the mail transport materials of RFC 1123) It also includes some additional material from RFC 1123 that required amplification. Indeed, browsing RFC 1123 I found a few ones: Section 5.2.17 Domain Literals: RFC-822 Section 6.2.3 (doesn't have IPv6), 5.3.1.1 Sending Strategy (the I-D has some additional text), 5.3.1.2 Receiving strategy (ditto), 5.3.2 Timeouts in SMTP (albeit the number of minutes look the same), 5.3.3 Reliable Mail Receipt (Section 6.1 of the I-D has "MUST be stripped down"), 5.3.4 Reliable Mail Transmission (Section 5.1 of the I-D provides more details), 5.3.6 Mailing Lists and Aliases (we can hopefully clarify forwarding)... I agree there should be a Section or an Appendix that collects those updates, for those coming from RFC 1123 looking for what is updated. Best Ale -- From nobody Sat Feb 20 22:33:15 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 344943A152D; Sat, 20 Feb 2021 22:33:09 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <161388918916.21456.4351429958410243029@ietfa.amsl.com> Date: Sat, 20 Feb 2021 22:33:09 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-02.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: Sun, 21 Feb 2021 06:33:09 -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 : Simple Mail Transfer Protocol Author : John C. Klensin Filename : draft-ietf-emailcore-rfc5321bis-02.txt Pages : 112 Date : 2021-02-20 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces the earlier version with the same title in RFC 5321. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 (Message Submission) as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emailcore-rfc5321bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 20 22:48: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 B290E3A1553 for ; Sat, 20 Feb 2021 22:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8m0beUOx6DEn for ; Sat, 20 Feb 2021 22:48:51 -0800 (PST) Received: from bsa2.jck.com (ns.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 976E23A156B for ; Sat, 20 Feb 2021 22:48:51 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lDiXy-000AfG-E1 for emailcore@ietf.org; Sun, 21 Feb 2021 01:48:50 -0500 Date: Sun, 21 Feb 2021 01:48:44 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: 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] draft-ietf-emailcore-rfc5321bis-02 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: Sun, 21 Feb 2021 06:48:53 -0000 Hi. As promised (or, depending on your perspective, threatened), this has been posted containing (I hope) all resolved tickets to date, updated references, removal of "Updates: 1123", and several other small changes including some cosmetic or editorial ones. Of course, Appendix G has been updated. I have removed a few CREFs that were associated with the closed tickets or that seemed to have outlives their usefulness. There are several more that just note changes that were made and sometimes when and why. I'm going to start taking those out with -03 unless directed otherwise by the WG Co-chairs, so this would be a good time to look through them and comment if any should either be retained for a while or identify issues that should be turned into tickets. In addition, two of those, specifically CREF24 and CREF32 in this version, are warnings about things (and people's names) not yet captured. I think I've gotten all of those (except for adding Todd to the acknowledgments) and correcting an obvious editorial glitch there). If people know of others, please call my attention to them. happy reading. john From nobody Mon Feb 22 07:31:02 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 65A5F3A083E for ; Mon, 22 Feb 2021 07:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 JzGuymq1LU7K for ; Mon, 22 Feb 2021 07:30:58 -0800 (PST) Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com [66.111.4.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F763A05AC for ; Mon, 22 Feb 2021 07:30:57 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 6DFA11940A2F for ; Mon, 22 Feb 2021 10:30:55 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Mon, 22 Feb 2021 10:30:55 -0500 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=fm2; bh=APm/GULDzNIvsqPZLFz/sxGIvpN0GFTpe7u3MCTVj F0=; b=ioHThR3KQrjn54qktAy5oCrEYJricRDhPe3LYKnltDjO43+o5fZcqU0+Q j/hT/ZiHuuiLXoC9jBql07j1uRpMsr3EflH9mSizgReD8Z8ZJBDqoIS5t2Kn0peL 8/OCyCkV61jGGgHq7TPvAeMCltnuTzHoySlisMCcfZjnGLnRdWGIiSmtPxITPjYz 11EfKBPiYhiVdvbHC4uWdKvasF7zjwLHg56Mpg5viQyBe59n2DCfAiAKo2TLMspK GSOIoyQRQ7vIFnkxCXWyFVJIjtOR0oAenXEbxB39/aP/oNGvxHg1/OJzI3CpJQLu 1f+6bjLyZnFNAPfxn+N6MidaLadqw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeefgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorghlvgig vgihrdhmvghlnhhikhhovhesihhsohguvgdrtghomheqnecuggftrfgrthhtvghrnhepgf ehfeegudeivdefvdeuieejteekuefgudehteejudfguedtudekhffgveelfeejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvgigvgihrd hmvghlnhhikhhovhesihhsohguvgdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2195B6B4005F; Mon, 22 Feb 2021 10:30:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <665b2486-1ee6-4c65-aca6-5862456cc232@www.fastmail.com> In-Reply-To: <01RS3I8I4F10005PTU@mauve.mrochek.com> References: <0cc7e71d-e12c-a990-d628-749699e7a495@isode.com> <01RS3I8I4F10005PTU@mauve.mrochek.com> Date: Mon, 22 Feb 2021 15:30:32 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Emailcore] =?utf-8?q?Ticket_=2341_=28was_Ticket_=239=3A_G=2E7?= =?utf-8?q?=2E3=2E_Resolvable_FQDN_in_SMTP_and_private_domain_names=29?= 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, 22 Feb 2021 15:31:01 -0000 On Tue, Nov 17, 2020, at 7:24 AM, Ned Freed wrote: > > Dear WG participants, >=20 > > Another rfc5321bis issue for your consideration: >=20 > > In Section 2.3.5 ("Domain Names"): > > =C2=A0=C2=A0=C2=A0 Only resolvable, fully-qualified domain names (F= QDNs) are permitted > > when domain names are used in SMTP. >=20 > > John's Note (as the editor): does "in the public DNS" or equivalent = need > > to be added to "resolvable"??? >=20 > > My personal opinion: I don't think we should require "in the public > > DNS", as as SMTP works just fine with split horizon or private DNS s= ervers. >=20 > Agreed. While it can be convenient to perform DNS validity checks of t= he > domains in addresses in some contexts - or even more limited stuff lik= e > checking for valid TLDs - it should not be an SMTP requirement. Requir= ements > like these lead to implementations imposing restrictions that are diff= icult > to remove - and there are cases where you want to remove them. I split this issue into a separate ticket #41. I intend to close it in a= week, unless there are some objections. From nobody Mon Feb 22 09:03: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 85E413A1DDD for ; Mon, 22 Feb 2021 09:03:38 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=isode.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 XG6tnayqkoeB for ; Mon, 22 Feb 2021 09:03:36 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BE8BA3A1DDC for ; Mon, 22 Feb 2021 09:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1614013415; d=isode.com; s=june2016; i=@isode.com; bh=goEtAXbwFkyCVJSOItdT+GPOExw+x001vMX9ofvN3Jc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=CRZ4ohBlCcg8Jh4nPU3Xt2xyho0IgIAADrqHJ/jAf55T/xCdC/Gagyt7F5GgW8jvK82DuI 5S4rHcQE3gX1jtkAUrKVNpom0G+uE1VFTW0+B69nx0gocke8YGL0ZZkxov0dvGjzlARVGy O3GNZkkOiUFM0rvwPT53LqA8+DvWUoY=; Received: from [192.168.1.222] (host31-49-142-74.range31-49.btcentralplus.com [31.49.142.74]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 22 Feb 2021 17:03:34 +0000 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> Date: Mon, 22 Feb 2021 17:03:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 17:03:39 -0000 Hi all, I didn't realize until John Klensin pointed out that this affects both=20 rfc5321bis and rfc5322bis. So below I extracted pretty much all text=20 related to trace header fields and in some cases I provide my strawman=20 proposals on how to update them: rfc5322bis: >3.6.=C2=A0 Field Definitions > >=C2=A0=C2=A0 More importantly, the trace header fields and resent >=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be kept in bl= ocks >=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 and 3.6.7 = for more >=C2=A0=C2=A0 information. I think the above gives important characteristics of the trace header=20 fields and the above text looks fine to me. >3.6.7.=C2=A0 Trace Fields > >=C2=A0=C2=A0 The trace fields are a group of header fields consisting of a= n >=C2=A0=C2=A0 optional "Return-Path:" field, and one or more "Received:" fi= elds. I think this needs to be updated to make it clear that other header=20 fields can be designated as "trace header fields". For example: =C2=A0=C2=A0 The trace fields are a group of header fields consisting of an =C2=A0=C2=A0 optional "Return-Path:" field, one or more "Received:" fields =C2=A0=C2=A0 and other header fields specified in other specifications. >=C2=A0=C2=A0 The "Return-Path:" header field contains a pair of angle brac= kets >=C2=A0=C2=A0 that enclose an optional addr-spec.=C2=A0 The "Received:" fie= ld contains a >=C2=A0=C2=A0 (possibly empty) list of tokens followed by a semicolon and a= date- >=C2=A0=C2=A0 time specification.=C2=A0 Each token must be a word, angle-ad= dr, addr- >=C2=A0=C2=A0 spec, or a domain.=C2=A0 Further restrictions are applied to = the syntax of >=C2=A0=C2=A0 the trace fields by specifications that provide for their use= , such >=C2=A0=C2=A0 as [I-D.klensin-rfc5321bis]. > >=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =3D=C2=A0=C2=A0 [return] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*received Again, I think ABNF needs to be clear that other header fields can=20 appear in between Return-Path and Received, for example: =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D=C2=A0=C2=A0 [return] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *trace-extension-f= ield =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*received =C2=A0 trace-extension-field =3D optional-field >=C2=A0=C2=A0 A full discussion of the Internet mail use of trace fields is > =C2=A0 contained in [I-D.klensin-rfc5321bis]. >=C2=A0=C2=A0 For the purposes of this >=C2=A0=C2=A0 specification, the trace fields are strictly informational, a= nd any >=C2=A0=C2=A0 formal interpretation of them is outside of the scope of this >=C2=A0=C2=A0 document. >Appendix B.=C2=A0 Differences from Earlier Specifications >The following are changes from [RFC2822]. >=C2=A0=C2=A0 12.=C2=A0 Allowed optional-field to appear within trace infor= mation. It doesn't look like this actually happened or maybe this was altered in=20 RFC 5322. rfc5321bis: >3.7.2.=C2=A0 Received Lines in Gatewaying > >=C2=A0=C2=A0 "Received:" header fields of messages originating from other >=C2=A0=C2=A0 environments may not conform exactly to this specification.= =C2=A0 However, >=C2=A0=C2=A0 the most important use of Received: lines is for debugging ma= il >=C2=A0=C2=A0 faults, and this debugging can be severely hampered by well-m= eaning >=C2=A0=C2=A0 gateways that try to "fix" a Received: line.=C2=A0 As another= consequence >=C2=A0=C2=A0 of trace header fields arising in non-SMTP environments, rece= iving >=C2=A0=C2=A0 systems MUST NOT reject mail based on the format of a trace h= eader >=C2=A0=C2=A0 field and SHOULD be extremely robust in the light of unexpect= ed >=C2=A0=C2=A0 information or formats in those header fields. This talks about purpose of trace header fields and this text looks fine=20 to me. >4.1.1.4.=C2=A0 DATA (DATA) > >=C2=A0=C2=A0 When the SMTP server accepts a message either for relaying or= for >=C2=A0=C2=A0 final delivery, it inserts a trace record (also referred to So this introduces "trace record", which is different from "trace header=20 fields", as it only related to Received. >=C2=A0=C2=A0 interchangeably as a "time stamp line" or "Received" line) at= the top >=C2=A0=C2=A0 of the mail data.=C2=A0 This trace record indicates the ident= ity of the >=C2=A0=C2=A0 host that sent the message, the identity of the host that rec= eived >=C2=A0=C2=A0 the message (and is inserting this time stamp), and the date = and time >=C2=A0=C2=A0 the message was received. >4.4.=C2=A0 Trace Information > >=C2=A0=C2=A0 When an SMTP server receives a message for delivery or furthe= r >=C2=A0=C2=A0 processing, it MUST insert trace (often referred to as "time = stamp" I suggest to add "record" after "trace" to match the above definition. >=C2=A0=C2=A0 or "Received" information) beginning of the message content, = as >=C2=A0=C2=A0 discussed in Section 4.1.1.4. >6.4.=C2=A0 Compensating for Irregularities > >=C2=A0=C2=A0 In all cases, properly operating clients supplying correct >=C2=A0=C2=A0 information are preferred to corrections by the SMTP server.= =C2=A0 In all >=C2=A0=C2=A0 cases, documentation SHOULD be provided in trace header field= s and/or >=C2=A0=C2=A0 header field comments for actions performed by the servers. This looks fine to me. >7.6.=C2=A0 Information Disclosure in Trace Fields > >=C2=A0=C2=A0 In some circumstances, such as when mail originates from with= in a LAN >=C2=A0=C2=A0 whose hosts are not directly on the public Internet, trace >=C2=A0=C2=A0 ("Received") header fields produced in conformance with this >=C2=A0=C2=A0 specification may disclose host names and similar information= that >=C2=A0=C2=A0 would not normally be available. I think the above is largely correct, but I suggest inserting "e.g."=20 before "Received" in 'trace ("Received") header fields' to make it clear=20 that this is not a full list of trace header fields. >8.=C2=A0 IANA Considerations > >=C2=A0=C2=A0 In addition, if additional trace header fields (i.e., in addi= tion to >=C2=A0=C2=A0 Return-path and Received) are ever created, those trace field= s MUST >=C2=A0=C2=A0 be added to the IANA registry established by BCP 90 (RFC 3864= ) [8] >=C2=A0=C2=A0 for use with RFC 5322 [11]. I think the above is fine. We also talked about a separate registry for=20 trace header fields in the A/S document. Best Regards, Alexey From nobody Mon Feb 22 10:09:39 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 C961A3A1EAF for ; Mon, 22 Feb 2021 10:09:37 -0800 (PST) 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 sAUmChM9dQbj for ; Mon, 22 Feb 2021 10:09:36 -0800 (PST) Received: from bsa2.jck.com (ns.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 CBFFC3A1EB4 for ; Mon, 22 Feb 2021 10:09:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lEFeI-000Iou-6o; Mon, 22 Feb 2021 13:09:34 -0500 Date: Mon, 22 Feb 2021 13:09:28 -0500 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: <8D80F62EB84782FA2C9295E6@PSB> In-Reply-To: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 #7: Better definition 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, 22 Feb 2021 18:09:38 -0000 Alexey, I think this is about right. =20 As editor: I wonder (it would take some research to figure it out) where "trace record" entered the vocabulary. Noting that "trace" does not appear to occur at all in 821, I suspect it is just a potentially confusing artifact of the document-merging process or the editor of 2821 having an attack of stupid inconsistency rather than the distinction you are making. From that perspective, while it would require more work, an alternative would be to remove that term, use "trace header field" throughout, and reword the relevant paragraphs to make it clear that "Received:" is not the only such field. In addition, the boundary between what information about those fields is included in 5321bis versus 5322bis is a bit arbitrary and may not be quite right. I wonder if it would be worthwhile for the WG to review those choices and made suggestions that might reduce having potentially conflicting descriptions in two different documents. The latter practice is, as Dave Crocker recently pointed out, an invitation to confusion. On the other hand, if we start tampering with that boundary, we might easily make things worse. I'm happy to do whatever the WG decides about the above as long as I get clear instructions. john --On Monday, February 22, 2021 17:03 +0000 Alexey Melnikov wrote: > Hi all, >=20 > I didn't realize until John Klensin pointed out that this > affects both rfc5321bis and rfc5322bis. So below I extracted > pretty much all text related to trace header fields and in > some cases I provide my strawman proposals on how to update > them: >=20 > rfc5322bis: >=20 > >3.6.=C2=A0 Field Definitions > > > >=C2=A0=C2=A0 More importantly, the trace header fields and = resent > >=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD = be kept > in blocks > >=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections = 3.6.6 and > 3.6.7 for more > >=C2=A0=C2=A0 information. >=20 > I think the above gives important characteristics of the trace > header fields and the above text looks fine to me. >=20 >=20 > >3.6.7.=C2=A0 Trace Fields > > > >=C2=A0=C2=A0 The trace fields are a group of header fields > consisting of an > >=C2=A0=C2=A0 optional "Return-Path:" field, and one or more > "Received:" fields. >=20 > I think this needs to be updated to make it clear that other > header fields can be designated as "trace header fields". For > example: >=20 > =C2=A0=C2=A0 The trace fields are a group of header fields = consisting > of an > =C2=A0=C2=A0 optional "Return-Path:" field, one or more = "Received:" > fields > =C2=A0=C2=A0 and other header fields specified in other > specifications. >=20 > >=C2=A0=C2=A0 The "Return-Path:" header field contains a pair = of > angle brackets > >=C2=A0=C2=A0 that enclose an optional addr-spec.=C2=A0 The = "Received:" > field contains a > >=C2=A0=C2=A0 (possibly empty) list of tokens followed by a = semicolon > and a date- > >=C2=A0=C2=A0 time specification.=C2=A0 Each token must be a = word, > angle-addr, addr- > >=C2=A0=C2=A0 spec, or a domain.=C2=A0 Further restrictions = are applied > to the syntax of > >=C2=A0=C2=A0 the trace fields by specifications that provide = for > their use, such > >=C2=A0=C2=A0 as [I-D.klensin-rfc5321bis]. > > > >=C2=A0=C2=A0 = trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D=C2=A0=C2=A0 [return] > = >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 1*received >=20 > Again, I think ABNF needs to be clear that other header fields > can appear in between Return-Path and Received, for example: >=20 > =C2=A0=C2=A0 = trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D=C2=A0=C2=A0 [return] > = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= > *trace-extension-field > = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 1*received >=20 > =C2=A0 trace-extension-field =3D optional-field >=20 > >=C2=A0=C2=A0 A full discussion of the Internet mail use of = trace > fields is > > =C2=A0 contained in [I-D.klensin-rfc5321bis]. > >=C2=A0=C2=A0 For the purposes of this > >=C2=A0=C2=A0 specification, the trace fields are strictly > informational, and any > >=C2=A0=C2=A0 formal interpretation of them is outside of the = scope > of this > >=C2=A0=C2=A0 document. >=20 > >Appendix B.=C2=A0 Differences from Earlier Specifications >=20 > >The following are changes from [RFC2822]. >=20 > >=C2=A0=C2=A0 12.=C2=A0 Allowed optional-field to appear = within trace > information. >=20 > It doesn't look like this actually happened or maybe this was > altered in RFC 5322. >=20 >=20 > rfc5321bis: >=20 > >3.7.2.=C2=A0 Received Lines in Gatewaying > > > >=C2=A0=C2=A0 "Received:" header fields of messages = originating from > other > >=C2=A0=C2=A0 environments may not conform exactly to this > specification.=C2=A0 However, > >=C2=A0=C2=A0 the most important use of Received: lines is = for > debugging mail > >=C2=A0=C2=A0 faults, and this debugging can be severely = hampered by > well-meaning > >=C2=A0=C2=A0 gateways that try to "fix" a Received: = line.=C2=A0 As > another consequence > >=C2=A0=C2=A0 of trace header fields arising in non-SMTP > environments, receiving > >=C2=A0=C2=A0 systems MUST NOT reject mail based on the = format of a > trace header > >=C2=A0=C2=A0 field and SHOULD be extremely robust in the = light of > unexpected > >=C2=A0=C2=A0 information or formats in those header fields. >=20 > This talks about purpose of trace header fields and this text > looks fine to me. >=20 > >4.1.1.4.=C2=A0 DATA (DATA) > > > >=C2=A0=C2=A0 When the SMTP server accepts a message either = for > relaying or for > >=C2=A0=C2=A0 final delivery, it inserts a trace record (also > referred to >=20 > So this introduces "trace record", which is different from > "trace header fields", as it only related to Received. >=20 > >=C2=A0=C2=A0 interchangeably as a "time stamp line" or = "Received" > line) at the top > >=C2=A0=C2=A0 of the mail data.=C2=A0 This trace record = indicates the > identity of the > >=C2=A0=C2=A0 host that sent the message, the identity of the = host > that received > >=C2=A0=C2=A0 the message (and is inserting this time stamp), = and the > date and time > >=C2=A0=C2=A0 the message was received. >=20 > >4.4.=C2=A0 Trace Information > > > >=C2=A0=C2=A0 When an SMTP server receives a message for = delivery or > further > >=C2=A0=C2=A0 processing, it MUST insert trace (often = referred to as > "time stamp" >=20 > I suggest to add "record" after "trace" to match the above > definition. >=20 > >=C2=A0=C2=A0 or "Received" information) beginning of the = message > content, as > >=C2=A0=C2=A0 discussed in Section 4.1.1.4. >=20 > >6.4.=C2=A0 Compensating for Irregularities > > > >=C2=A0=C2=A0 In all cases, properly operating clients = supplying > correct > >=C2=A0=C2=A0 information are preferred to corrections by the = SMTP > server.=C2=A0 In all > >=C2=A0=C2=A0 cases, documentation SHOULD be provided in = trace header > fields and/or > >=C2=A0=C2=A0 header field comments for actions performed by = the > servers. >=20 > This looks fine to me. >=20 > >7.6.=C2=A0 Information Disclosure in Trace Fields > > > >=C2=A0=C2=A0 In some circumstances, such as when mail = originates > from within a LAN > >=C2=A0=C2=A0 whose hosts are not directly on the public = Internet, > trace > >=C2=A0=C2=A0 ("Received") header fields produced in = conformance with > this > >=C2=A0=C2=A0 specification may disclose host names and = similar > information that > >=C2=A0=C2=A0 would not normally be available. >=20 > I think the above is largely correct, but I suggest inserting > "e.g." before "Received" in 'trace ("Received") header fields' > to make it clear that this is not a full list of trace header > fields. >=20 >=20 > >8.=C2=A0 IANA Considerations > > > >=C2=A0=C2=A0 In addition, if additional trace header fields = (i.e., > in addition to > >=C2=A0=C2=A0 Return-path and Received) are ever created, = those trace > fields MUST > >=C2=A0=C2=A0 be added to the IANA registry established by = BCP 90 > (RFC 3864) [8] > >=C2=A0=C2=A0 for use with RFC 5322 [11]. >=20 > I think the above is fine. We also talked about a separate > registry for trace header fields in the A/S document. >=20 > Best Regards, >=20 > Alexey From nobody Mon Feb 22 11:42:42 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 9246A3A1F57 for ; Mon, 22 Feb 2021 11:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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.25, 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=iobCs7xg; dkim=pass (2048-bit key) header.d=taugh.com header.b=P3J8FXHm 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 v9_sWHDmySw9 for ; Mon, 22 Feb 2021 11:42:37 -0800 (PST) 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 2BA053A201E for ; Mon, 22 Feb 2021 11:42:28 -0800 (PST) Received: (qmail 67223 invoked from network); 22 Feb 2021 19:42: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=10695.60340923.k2102; bh=P4ASoTNrSoFoZ/30a84cE8WvtOKUkIQIgjoT2oab2Cw=; b=iobCs7xgidD62/vVOJJeMgY9JbIGv1YuWHPhLRE4zwhp1o2MIyrnao9o1CtpQCJB2Gd5OIx95ehJuhnTRU23elq1K7mrZQ5pl6ixCtLL+hUk7ru00qaW5HWBwuNVr0+86yA+1Jd0BX+905weleGLI2aR3AvfaHNWBr8fYA0FPt0H4ABQaY+2mqxQLW+tXf8G+72oYJ1ZsdL5kzt4YJgOqai0fb/Av4a/hjQ5E303SPb7LHFS98DsGUhWUPMwvRn4OWfuGAjLC6ikoypsVrsx4mDs0QfyguTG4N/3zlKeRQh9T3RDpwscsfGbaDnCSeptUROwvMMSdr7LWsZSF450Mg== 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=10695.60340923.k2102; bh=P4ASoTNrSoFoZ/30a84cE8WvtOKUkIQIgjoT2oab2Cw=; b=P3J8FXHm2wrcZyKmttvNv+x+XrWZYL3uU4hXKcPXAkazsgCINOixKDMqH5az3qTxYy7pOr/bptRnLRYDPdNWXYLu7hJbB/8qPo91bbLXnYTnrAKTnSTKTYa6+TSd3yYXFXJe/8lZ8bSISasuxAfiV+X2XKQMF9yLthizJZkOyV545GLQ4ru3DI5dqB1qa8fB3unl3JwcmWrixv9x5ofAaKVNAOMmW+paDxPttSgvpR473is5LL+l4z3p39nL2hMvTU0+MTLlwk+m1OG0+AxW7h6Ms+jv3XGe9o00SqSqWpu2C2/ofnA679Vzfhy4BljK6p7tQNNHl8+EX7Obclallw== 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; 22 Feb 2021 19:42:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 890486E7C605; Mon, 22 Feb 2021 14:42:26 -0500 (EST) Date: 22 Feb 2021 14:42:26 -0500 Message-Id: <20210222194226.890486E7C605@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.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 #7: Better definition 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, 22 Feb 2021 19:42:41 -0000 In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> you write: >Hi all, > >I didn't realize until John Klensin pointed out that this affects both >rfc5321bis and rfc5322bis. So below I extracted pretty much all text >related to trace header fields and in some cases I provide my strawman >proposals on how to update them: > >rfc5322bis: > > >3.6.  Field Definitions > > > >   More importantly, the trace header fields and resent > >   header fields MUST NOT be reordered, and SHOULD be kept in blocks > >   prepended to the message.  See sections 3.6.6 and 3.6.7 for more > >   information. > >I think the above gives important characteristics of the trace header >fields and the above text looks fine to me. If we want to interoperate well, I think that SHOULD is a MUST. Also, how about saying they SHOULD NOT be deleted. It'd be a MUST NOT except that there is a special case for Authentication-Results. >Again, I think ABNF needs to be clear that other header fields can >appear in between Return-Path and Received, for example: > >    trace           =   [return] >                        *trace-extension-field >                        1*received > >   trace-extension-field = optional-field Wouldn't that mean that the extension fields are all above the received? How about this:    trace           =   [return]                        1*(received / trace-extension-field) > >8.  IANA Considerations > > > >   In addition, if additional trace header fields (i.e., in addition to > >   Return-path and Received) are ever created, those trace fields MUST > >   be added to the IANA registry established by BCP 90 (RFC 3864) [8] > >   for use with RFC 5322 [11]. > >I think the above is fine. We also talked about a separate registry for >trace header fields in the A/S document. Is it a separate registry or a new column in the existing registry? It doesn't seem like a great idea to have two registries where one is supposed to be a subset of the other. R's, John From nobody Mon Feb 22 12:20:16 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 6C0233A1070 for ; Mon, 22 Feb 2021 12:20:14 -0800 (PST) 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 473Z_hGVlfqa for ; Mon, 22 Feb 2021 12:20:12 -0800 (PST) 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 E70A33A0DA1 for ; Mon, 22 Feb 2021 12:20:11 -0800 (PST) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 52DE04532; Mon, 22 Feb 2021 21:20:09 +0100 (CET) Date: Mon, 22 Feb 2021 21:20:09 +0100 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210222202009.GA12620@hjp.at> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> <20210222194226.890486E7C605@ary.qy> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20210222194226.890486E7C605@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 20:20:14 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-22 14:42:26 -0500, John Levine wrote: > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> you write: > >I didn't realize until John Klensin pointed out that this affects both= =20 > >rfc5321bis and rfc5322bis. So below I extracted pretty much all text=20 > >related to trace header fields and in some cases I provide my strawman= =20 > >proposals on how to update them: > > > >rfc5322bis: > > > > >3.6.=A0 Field Definitions > > > > > >=A0=A0 More importantly, the trace header fields and resent > > >=A0=A0 header fields MUST NOT be reordered, and SHOULD be kept in bloc= ks > > >=A0=A0 prepended to the message.=A0 See sections 3.6.6 and 3.6.7 for m= ore > > >=A0=A0 information. > > > >I think the above gives important characteristics of the trace header=20 > >fields and the above text looks fine to me. I'm a bit worried that someone might read a "MUST be kept in blocks prepended to the message" as a mandate to move existing trace fields to the front.=20 For example, suppose system D receives this message: Unknown-Field: 42 Received; from B by C Delivered-To: x@B Received: from A by B Received: by A Subject: Example ... Instead of just prepending its Received field, making it Received: from C by D Unknown-Field: 42 Received; from B by C Delivered-To: x@B Received: from A by B Received: by A Subject: Example ... it pulls the recognized trace headers to the front, like this: Received: from C by D Received; from B by C Delivered-To: x@B Received: from A by B Received: by A Unknown-Field: 42 Subject: Example ... I don't think that would be a good idea. I think an MTA should just never reorder existing headers (whether they are trace headers or not) and just prepends any headers it wants to add. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmA0EfQACgkQ8g5IURL+ KF0P7g/+PnQha+WQf+goXW2Hnxl6dDCydNTdgJW9mSBBVNDMHbOgWSFV017+l4DM 6i2ODv+7m5eJEnumdbVNbYKSEfR/fArDZmJ0wtAsDYDiZlE3H+nGvFj1urYAOeie lj1nrU8k4TFlDKJa4J1BZVv+90qFJGPrecvldXPQqsZISxxKyLD/hx2ogU11u8Vf ays3RZ3GhkHL1uwSKWVLV8XjGfs/X9781KAPU6DJCIWfyK3i16KhijDX1vL3yb1t eJg6ebC1DliZhVfdHUgc4b3kadc9Oga8S3sD1WMnXXwUPlQC7iYB7blwGwW4EvuI SrcMaxn1od+pjufWtZis9c4U+zujcet/fq3IwyXuIGHa6euP9PY6N8sgDsD4Uzsl tMoatd7ETvg6xRqNtPTfZJ3rC/Y7ZiTzXqbwLg5kq6Q+aVN3mhMeOIN3ufO0pI0L m2YJE/xw4VjKTWAWMrhGvZDeH7GZ729cvmgXN9mpB9x+7wdXDMTeFxAvdlH2LzmT PZRicjakVrbuG8B2vvGJmWCkF49Fwp3AUw0yvIQQfIeSCravjiVUu6I6Zu8ziigO xkIflNuJMXVfWdXZYqfITf+nQAvkFeyHbe8/tthDTadRjI4WfegcfvUioysPcTN7 D1z+csL6UOQgMLYR8wDA6RbHBvteA4Gh/o1tuGBDOQHtBSOyPyA= =6+95 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From nobody Mon Feb 22 13:04:08 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 9D0863A1FFA for ; Mon, 22 Feb 2021 13:04:05 -0800 (PST) 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 I8tNCL25mcsD for ; Mon, 22 Feb 2021 13:04:03 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EA33A1FF7 for ; Mon, 22 Feb 2021 13:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 0C05CD760D9F; Mon, 22 Feb 2021 15:04:02 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrKyFXqOAeg1; Mon, 22 Feb 2021 15:04:00 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 70079D760D96; Mon, 22 Feb 2021 15:04:00 -0600 (CST) From: Pete Resnick To: John C Klensin Cc: Alexey Melnikov , emailcore@ietf.org Date: Mon, 22 Feb 2021 15:04:00 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: <895D6566-CCD7-4836-9946-074BD69C816C@episteme.net> In-Reply-To: <8D80F62EB84782FA2C9295E6@PSB> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> <8D80F62EB84782FA2C9295E6@PSB> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 21:04:06 -0000 I think this is going in an OK direction, though changing ABNF always makes me a bit queasy. I'll read over the messages and see if I can come up with the 5322bis proposal. On one below question: On 22 Feb 2021, at 12:09, John C Klensin wrote: > As editor: I wonder (it would take some research to figure it > out) where "trace record" entered the vocabulary. It appears in 822. See section 4.3. https://tools.ietf.org/html/rfc822#section-4.3 pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Feb 22 13:32:16 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 523523A206D for ; Mon, 22 Feb 2021 13:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NRPBonQXyFaU for ; Mon, 22 Feb 2021 13:32:12 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D66A3A206B for ; Mon, 22 Feb 2021 13:32:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 8651BD7619AC; Mon, 22 Feb 2021 15:32:11 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXXQfdIuzz8g; Mon, 22 Feb 2021 15:32:09 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 95220D7619A1; Mon, 22 Feb 2021 15:32:09 -0600 (CST) From: Pete Resnick To: "John Levine" Cc: emailcore@ietf.org, alexey.melnikov@isode.com Date: Mon, 22 Feb 2021 15:32:08 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> In-Reply-To: <20210222194226.890486E7C605@ary.qy> References: <20210222194226.890486E7C605@ary.qy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_26B04373-C43D-438D-8700-3B0CBCE2A699_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 21:32:14 -0000 --=_MailMate_26B04373-C43D-438D-8700-3B0CBCE2A699_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Combining some answers to John L. and Alexey regarding the 5322bis chagnes... On 22 Feb 2021, at 13:42, John Levine wrote: > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> Alexey > Melnikov writes: >> >>> 3.6.  Field Definitions >>> >>>    More importantly, the trace header fields and resent >>>    header fields MUST NOT be reordered, and SHOULD be kept in >>> blocks >>>    prepended to the message.  See sections 3.6.6 and 3.6.7 for >>> more >>>    information. >> >> I think the above gives important characteristics of the trace header >> fields and the above text looks fine to me. > > If we want to interoperate well, I think that SHOULD is a MUST. I can go spelunking in the DRUMS archive if needed, but my memory is that the reason for the SHOULD was that we knew that certain implementations did not (and could not) keep things in prepended blocks and we didn't want the MUST to indicate that as a receiver you could so strongly depend on them being kept together. > Also, > how about saying they SHOULD NOT be deleted. It'd be a MUST NOT > except > that there is a special case for Authentication-Results. All of the "don't change/delete" requirements are in 5321bis; we never had any in x22. I'm inclined to keep it that way. >> 3.6.7. Trace Fields >> >> The trace fields are a group of header fields consisting of an >> optional "Return-Path:" field, and one or more "Received:" fields. > > I think this needs to be updated to make it clear that other header > fields can be designated as "trace header fields". For example: > > The trace fields are a group of header fields consisting of an > optional "Return-Path:" field, one or more "Received:" fields > and other header fields specified in other specifications. Yeah, I'll wordsmith that a bit, but I will do something like the above. >> Again, I think ABNF needs to be clear that other header fields can >> appear in between Return-Path and Received, for example: >> >>    trace           =   [return] >>                        *trace-extension-field >>                        1*received >> >>   trace-extension-field = optional-field > > Wouldn't that mean that the extension fields are all above the > received? How about this: > >    trace           =   [return] >                        1*(received / > trace-extension-field) Yes, and if I do that, I'll remove the extra optional-field at the top of the overall fields syntax in 3.6. >> Appendix B. Differences from Earlier Specifications >> >> The following are changes from [RFC2822]. >> >> 12. Allowed optional-field to appear within trace information. >> >> It doesn't look like this actually happened or maybe this was altered >> in RFC 5322. It did. I just put it in in 3.6 instead of in 3.6.7. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_26B04373-C43D-438D-8700-3B0CBCE2A699_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Combining some answers to John L. and Alexey regarding th= e 5322bis chagnes...

On 22 Feb 2021, at 13:42, John Levine wrote:

In article 3c4d9d6e-4bf1-c0ed-e924-2cf56750= 5581@isode.com Alexey Melnikov writes:

3.6.=C2=A0 Field Definitions

=C2=A0=C2=A0 More importantly, the trace header fields an= d resent
=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be kept in b= locks
=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 and 3.6.7= for more
=C2=A0=C2=A0 information.

I think the above gives important characteristics of the = trace header
fields and the above text looks fine to me.

If we want to interoperate well, I think that SHOULD is a= MUST.

I can go spelunking in the DRUMS archive if needed, but m= y memory is that the reason for the SHOULD was that we knew that certain = implementations did not (and could not) keep things in prepended blocks a= nd we didn't want the MUST to indicate that as a receiver you could so st= rongly depend on them being kept together.

Also,
how about saying they SHOULD NOT be deleted. It'd be a MUST NOT except that there is a special case for Authentication-Results.

All of the "don't change/delete" requirements are in 5321= bis; we never had any in x22. I'm inclined to keep it that way.

3.6.7. Trace Fields

The trace fields are a group of header fields consisting = of an
optional "Return-Path:" field, and one or more "Received:" fields.

I think this needs to be updated to make it clear that ot= her header fields can be designated as "trace header fields". For example= :

The trace fields are a group of header fields consisting = of an
optional "Return-Path:" field, one or more "Received:" fields
and other header fields specified in other specifications.

Yeah, I'll wordsmith that a bit, but I will do something = like the above.

Again, I think ABNF needs to be clear that other header f= ields can
appear in between Return-Path and Received, for example:

=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trace-exten= sion-field
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1received<= /p>

=C2=A0 trace-extension-field =3D optional-field

Wouldn't that mean that the extension fields are all abov= e the received? How about this:

=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*(received / t= race-extension-field)

Yes, and if I do that, I'll remove the extra optional-fie= ld at the top of the overall fields syntax in 3.6.

Appendix B. Differences from Earlier Specifications

The following are changes from [RFC2822].

  1. Allowed optional-field to appear within trace information.

It doesn't look like this actually happened or maybe this= was altered in RFC 5322.

It did. I just put it in in 3.6 instead of in 3.6.7.

pr

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_26B04373-C43D-438D-8700-3B0CBCE2A699_=-- From nobody Mon Feb 22 14:13: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 167563A20E8 for ; Mon, 22 Feb 2021 14:13:05 -0800 (PST) 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 CCsBNwmqQRSz for ; Mon, 22 Feb 2021 14:13:03 -0800 (PST) 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 9EFA83A20E6 for ; Mon, 22 Feb 2021 14:13:03 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lEJRs-000JgJ-Rn; Mon, 22 Feb 2021 17:13:00 -0500 Date: Mon, 22 Feb 2021 17:12:55 -0500 From: John C Klensin To: Pete Resnick cc: Alexey Melnikov , emailcore@ietf.org Message-ID: <65B73881F26DDCB683FB858E@PSB> In-Reply-To: <895D6566-CCD7-4836-9946-074BD69C816C@episteme.net> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> <8D80F62EB84782FA2C9295E6@PSB> <895D6566-CCD7-4836-9946-074BD69C816C@episteme.net> 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 #7: Better definition 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, 22 Feb 2021 22:13:05 -0000 --On Monday, February 22, 2021 15:04 -0600 Pete Resnick wrote: > I think this is going in an OK direction, though changing ABNF > always makes me a bit queasy. I'll read over the messages and > see if I can come up with the 5322bis proposal. On one below > question: > > On 22 Feb 2021, at 12:09, John C Klensin wrote: > >> As editor: I wonder (it would take some research to figure it >> out) where "trace record" entered the vocabulary. > > It appears in 822. See section 4.3. > https://tools.ietf.org/html/rfc822#section-4.3 Sorry. Knew that. I meant to say "entered the SMTP vocabulary", but, thinking about it further, I assume the answer to my question is "when we were trying to harmonize vocabulary between proto-2822 and proto-2821". However "trace record" does not appear in 822 or 2822, so I have to guess that either I had the distinction that Alexey detected in mind and had completely forgotten it, or I messed up. Either way the question now is what to do going forward. thanks, john From nobody Mon Feb 22 14:48:08 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 EBF1C3A226C for ; Mon, 22 Feb 2021 14:47:59 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=kKZE4oH3; dkim=pass (2048-bit key) header.d=taugh.com header.b=gFRkmLss 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 t5V-k9BzsrQd for ; Mon, 22 Feb 2021 14:47:58 -0800 (PST) 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 88CF03A228B for ; Mon, 22 Feb 2021 14:47:20 -0800 (PST) Received: (qmail 16422 invoked from network); 22 Feb 2021 22:47:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=4024.60343475.k2102; bh=y6mKPWkHMXDH05q9IchTjVZ+l5YPyDCQ7+e9oFhQhbI=; b=kKZE4oH3m+KXyu4bcdX5meRoBolBQhmYps8uGu1iKUiczrcymPNbsEYgVNEvs/QyuFzVr0nrx+QFG7PLwBWaEAaPWZ246dpg1hd/eBxZ7T9tq6XdKQdxhxmv+wphEwx79POpXERJNV/B5WJ8+Hgzib3Bkjh4nvTLsTmV+q7nfN0i/PDGoXqc6KVxsuMhWbZuOqDJjeycna0MZbn66tHucVfrk9RwP0AvBoOW2tKCvIQAcNrw6zZS3JZnPxFe/S3ntIEgJvrS3npocttp9Fpyx6n1gh2J+pgBH7yr7LFhnay58F54I5w1oFqUtVklhkSKJDEtx4pG0HS4njeSHLLPPQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=4024.60343475.k2102; bh=y6mKPWkHMXDH05q9IchTjVZ+l5YPyDCQ7+e9oFhQhbI=; b=gFRkmLssNB0zv//xSbi4SZPv1LZ2Io3qS0gpe+BIh3OncvCzQ08vzRRfg/LI91vfocKgDflCh9fS9DaCSaicq4rgtvv6NTYw+Nw8lt7P3IVlekcpNvIRbLPQ0blr/ScgF/vpuJZhIyXJU/ON9acbV+4ORoqyHxYz9sfYl4coscfvPv6I5vKxjTjev0qQUYt3VBTaEeNe6v8IRxhExwcHwW1U8eye+tN32ysb1AQlpremKq8Lt+KSdEcbakGv2D1VQSu0b8jL18NClYqivki2ndk8JdcpUV4lSvtkqJtS6yYoiYnuKmBSI+A1BB4lMoyi8JFBHdzO52wOsNwTlm8JlQ== 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; 22 Feb 2021 22:47:17 -0000 Received: by ary.qy (Postfix, from userid 501) id D19456E7D875; Mon, 22 Feb 2021 17:47:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 993666E7D857; Mon, 22 Feb 2021 17:47:16 -0500 (EST) Date: 22 Feb 2021 17:47:16 -0500 Message-ID: <39e55852-453-b9d0-5577-7bc6989e5e3f@taugh.com> From: "John R Levine" To: "Pete Resnick" Cc: emailcore@ietf.org In-Reply-To: <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-467298168-1614034036=:33730" Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 22:48:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-467298168-1614034036=:33730 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> If we want to interoperate well, I think that SHOULD is a MUST. > > I can go spelunking in the DRUMS archive if needed, but my memory is that the > reason for the SHOULD was that we knew that certain implementations did not > (and could not) keep things in prepended blocks and we didn't want the MUST > to indicate that as a receiver you could so strongly depend on them being > kept together. That sounds vaguely familiar. We need a 2119 word for "do this but don't count on other people reading the spec." >>    trace           =   [return] >>                        1*(received / trace-extension-field) > > Yes, and if I do that, I'll remove the extra optional-field at the top of the > overall fields syntax in 3.6. OK. That is not exactly equivalent since it allows a trace block consisting of just, say, Authentication-Results with no Received, but I don't think that is wrong. By the way I noticed the reference to errata 2950. The errata is wrong, the resent-fields are indeed optional, and we someday we should update the ABNF spec to make it clear that ABNF can and often does provide multiple parses of the same valid input which is not a bug and does not cause problems for practical parsers. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-467298168-1614034036=:33730-- From nobody Mon Feb 22 15:38:03 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 CAD493A24B1 for ; Mon, 22 Feb 2021 15:37:52 -0800 (PST) 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 zHWM_9yIUtId for ; Mon, 22 Feb 2021 15:37:50 -0800 (PST) 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 853EA3A24C3 for ; Mon, 22 Feb 2021 15:36:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RVVY2HKUSG00DH9C@mauve.mrochek.com> for emailcore@ietf.org; Mon, 22 Feb 2021 15:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1614036701; bh=LewW5JvCzyFW/Sz4uzEFQnfx/Ca84pWpRgmasS1c6es=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=f/CUMEiQjqiD6jBW7t3qoY5UXm3V0g+vdUfysqjlll+2H3tkP1LjM+Dar1tiB1JkP wb4iB6NVzEGhYmtcvp4e7ujHKcsdxE0vT05if1qkuORemsEdnC7ruZ/oPeD6Gyl21U BmoNRMANhDIL9LykP/CmUTeFyfZNSeN2E/6fMhA4= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed; markup=markdown Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RVQNM60R7K005PTU@mauve.mrochek.com>; Mon, 22 Feb 2021 15:31:38 -0800 (PST) Cc: John Levine , emailcore@ietf.org, alexey.melnikov@isode.com Message-id: <01RVVY2FPQZ8005PTU@mauve.mrochek.com> Date: Mon, 22 Feb 2021 13:51:25 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 22 Feb 2021 15:32:08 -0600" <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> To: Pete Resnick Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 22 Feb 2021 23:37:59 -0000 > Combining some answers to John L. and Alexey regarding the 5322bis > chagnes... > On 22 Feb 2021, at 13:42, John Levine wrote: > > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> Alexey > > Melnikov writes: > >> > >>> 3.6.  Field Definitions > >>> > >>>    More importantly, the trace header fields and resent > >>>    header fields MUST NOT be reordered, and SHOULD be kept in > >>> blocks > >>>    prepended to the message.  See sections 3.6.6 and 3.6.7 for > >>> more > >>>    information. > >> > >> I think the above gives important characteristics of the trace header > >> fields and the above text looks fine to me. I'm afraid it does nothing of the sort. Required handling is not the same as describing what constitutes a trace field. I suppose you might be able to work back from the handling to likely uses, but that's not how this should work. So a definition is needed. And as it happens, there was one in RFC 822 section 4.3: Trace information is used to provide an audit trail of message handling. In addition, it indicates a route back to the sender of the message. For some reason this bit of text didn't make it into 2822. I don't recall any discussion of it, and I don't have time to search the archives for a reason why it was dropped - assuming it was even decided on the list. Regardless of cause, this definition or something similar needs to be restored. I also note that Received: and the concept of trace was introduced in RFC 822; it is not in RFC 733. This parallels the evolution of similar text in the development of the X.400 standards: FIPS PUB 98 doesn't provide any trace facilities at all, by DEC's Message Router (AFAIK the first and perhaps only implementation more or less based on that document) does support trace fields. And by the time X.400 proper rolled around we have this text in X.411: 12.2.1.1.1.3 Trace-information This argument documents the actions taken on the message (or probe or report) by each MD through which the message (or probe or report) passes as it is transferred through the MTS (see 12.3.1). It shall be generated by each MD through which the message (or probe or report) passes. 12.2.1.1.1.4 Internal-trace-information This argument documents the actions taken on the message (or probe or report) by each MTA through which the message (or probe or report) passes as it is transferred within an MD (see 12.3.1). It shall be generated by each MTA through which the message (or probe or report) passes within an MD. As a matter of local policy, an MTA may (but is not required to) remove internal-trace-information relating to other MDs when performing delivery, or when transferring to another MD, or on receiving from another MD. I've often wished that the two types of trace information had made it over to the Internet side of things, so that calls for all Received: lines to be removed in the interests of not revealing internal network structure could be met more easily. Of course it's much too late for that, but it might be interested to document for each header field containing trace information whether it's generated by MSAs, MTAs, MDAs, or some combination of the three. There's probably additional text in the IFIP documents and possibly in GOSIP; unfortunately that material is in some box or file I can't locate. However, I think this gives us enough to work with. I actually prefer the X.400 text to what's in RFC 822; the "actions taken" idea in particular strikes me as both more general and less formal than "audit trail". So how about a definition along the lines of: Trace information documents actions taken on the message by MSAs, MTAs and MDAs. It is provided by an extensible set of header fields. And then move onto the requirements, current set of fields, and so on. > > If we want to interoperate well, I think that SHOULD is a MUST. > I can go spelunking in the DRUMS archive if needed, but my memory is > that the reason for the SHOULD was that we knew that certain > implementations did not (and could not) keep things in prepended blocks > and we didn't want the MUST to indicate that as a receiver you could so > strongly depend on them being kept together. I believe that's correct. > > Also, > > how about saying they SHOULD NOT be deleted. It'd be a MUST NOT > > except > > that there is a special case for Authentication-Results. > All of the "don't change/delete" requirements are in 5321bis; we never > had any in x22. I'm inclined to keep it that way. Agreed. > >> 3.6.7. Trace Fields > >> > >> The trace fields are a group of header fields consisting of an > >> optional "Return-Path:" field, and one or more "Received:" fields. > > > > I think this needs to be updated to make it clear that other header > > fields can be designated as "trace header fields". For example: > > > > The trace fields are a group of header fields consisting of an > > optional "Return-Path:" field, one or more "Received:" fields > > and other header fields specified in other specifications. > Yeah, I'll wordsmith that a bit, but I will do something like the above. Again, you need an actual definition. Suggestions above., > >> Again, I think ABNF needs to be clear that other header fields can > >> appear in between Return-Path and Received, for example: > >> > >>    trace           =   [return] > >>                        *trace-extension-field > >>                        1*received > >> > >>   trace-extension-field = optional-field > > > > Wouldn't that mean that the extension fields are all above the > > received? How about this: > > > >    trace           =   [return] > >                        1*(received / > > trace-extension-field) > Yes, and if I do that, I'll remove the extra optional-field at the top > of the overall fields syntax in 3.6. FWIW, I strongly prefer new fields to messing around with Received:. Yes, I'm aware that this means that some agents may require an update to their list of fields, but IMO messing around with Received: parsing is a bigger problem. Ned From nobody Tue Feb 23 03:39: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 AAFF13A2A14 for ; Tue, 23 Feb 2021 03:39:51 -0800 (PST) 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 mP58JGq4JB-E for ; Tue, 23 Feb 2021 03:39:49 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72263A146A for ; Tue, 23 Feb 2021 03:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1614080385; bh=49+hHPtgz716M3omXBq26zGJl33sCAAA1qKTkwbWp7o=; l=2784; h=To:References:From:Date:In-Reply-To; b=Buqj3RTjwUm6ivHGBWaVCPENYuI2nJHBAeJlBB5cWcUK1THBJYOarxHyxpxc0S54J nYjbA1Pf0hwxE/gRY1fNE8R82GdxYFX+T3APQwVEdCLDU+I7wx4NcCJBh6KBF8y+Dd MIKVZVlpeL720MGzkuiYaYRXxAL1OzWQezWzEwWIb/iGKjC/7xhMwzDqf4Xow Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C6.000000006034E981.00004FE0; Tue, 23 Feb 2021 12:39:45 +0100 To: emailcore@ietf.org References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> From: Alessandro Vesely Message-ID: Date: Tue, 23 Feb 2021 12:39:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 11:39:52 -0000 On Mon 22/Feb/2021 22:32:08 +0100 Pete Resnick wrote: > Combining some answers to John L. and Alexey regarding the 5322bis chagnes... > [...] >>> Again, I think ABNF needs to be clear that other header fields can >>> appear in between Return-Path and Received, for example: >>> >>>    trace           =   [return] >>>                        *trace-extension-field >>>                        1*received >>> >>>   trace-extension-field = optional-field >> >> Wouldn't that mean that the extension fields are all above the received?  How >> about this: >> >>     trace           =   [return] >>                         1*(received / trace-extension-field) > > Yes, and if I do that, I'll remove the extra optional-field at the top of the > overall fields syntax in 3.6. That ABNF seems to imply there must be at least one Received:. Why then does the table in Section 3.6 show a Min number of 0 trace? I agree with Peter's worries about mandating the initial block. The optional-field allowed more leeway, as the optional field could happen to be whatever, not necessarily a trace field. Indeed, the requirement to collect all trace fields at the top of the header lest the message be syntactically bad is a recipe for trouble. The practice to collect trace fields at the top comes from the fact that it is convenient to write down one's 2 cents and then copy the rest without even parsing it. But a mail filter can add a header field holding information that semantically does not make it a trace field. Even then, it is more natural to write added fields near the top of the header. Doing so is also better for debugging and forensic analysis, as it is possible to deduce at what stage a given field was added. For example, consider a DKIM filter which tries and reverts a mailing list's From: munging. It records its findings in a trace field, Authentication-Results:. In addition, if the reversion succeeds, it adds an Original-From: field, formatted like From:. Semantically equivalent to From:, and eventually swappable with it, the latter is definitely not a trace field. Should it be added downward, possibly near to the real From:, or isn't it more self-explanatory to add it near the corresponding Authentication-Results:? Could we relax the header syntax? For example: trace = [return] *top-field top-field = received / trace-extension-field / prowl-field Where prowl-field can actually be any field, possibly resulting from Sieve or any other email filtering. That syntax still conveys that trace fields tend to gather near the top of the header, but doesn't require a strict order. Best Ale -- From nobody Tue Feb 23 05:40:16 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 0F4803A2B35 for ; Tue, 23 Feb 2021 05:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 HmH_Pu4RYeYU for ; Tue, 23 Feb 2021 05:40:12 -0800 (PST) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E903A1345 for ; Tue, 23 Feb 2021 05:40:12 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 65D22194114C; Tue, 23 Feb 2021 08:40:11 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 08:40:11 -0500 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=fm2; bh=DWIifKYbxuKl2bgGi7uJdOcnCpn4VKisJV2DWv1gZ cQ=; b=gOaUZYL00AeHhzwxQcZ6TYQsnagZEFVWFjUhBfJE6s8xNrVKuhBy436Yv pH80yu4e46BNOP9qmjdhIsnMKc0W/qeazVWWWaR8iacKEvVCXaOpHUZEVZJje0LK rwOLCFLRSjPLwUqqt7Aj69kSYq5r3BRdjJoz15/0MqMG8G4VxbuQBkuNp1zLy2pR zUii2BrfthdJbmM1gCwzeDpt7Euzwir1VQIT7v+H6Qw5Xic0fZhkYX0UVU/olrwU 4AtezqcNC+GxvIvUH0Lnr/95enxD0jLiu0/+QJPVnN5oU5gt7HsC4Wkjf7dfDNA4 n9qtd0cTynOtuNmnYbl9BiaHJvJHg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpefgheefgeduiedvfedvueeijeetkeeugfdu heetjedugfeutddukefhgfevleefjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F12B86B4005F; Tue, 23 Feb 2021 08:40:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <20210222194226.890486E7C605@ary.qy> References: <20210222194226.890486E7C605@ary.qy> Date: Tue, 23 Feb 2021 13:39:49 +0000 From: "Alexey Melnikov" To: "John R Levine" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 13:40:14 -0000 On Mon, Feb 22, 2021, at 7:42 PM, John Levine wrote: > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> you write:= > >Hi all, > > > >I didn't realize until John Klensin pointed out that this affects bot= h=20 > >rfc5321bis and rfc5322bis. So below I extracted pretty much all text=20= > >related to trace header fields and in some cases I provide my strawma= n=20 > >proposals on how to update them: > > > >rfc5322bis: > > > > >3.6.=C2=A0 Field Definitions > > > > > >=C2=A0=C2=A0 More importantly, the trace header fields and resent > > >=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be kep= t in blocks > > >=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 and= 3.6.7 for more > > >=C2=A0=C2=A0 information. > > > >I think the above gives important characteristics of the trace header= =20 > >fields and the above text looks fine to me. >=20 > If we want to interoperate well, I think that SHOULD is a MUST. Also,= > how about saying they SHOULD NOT be deleted. It'd be a MUST NOT excep= t > that there is a special case for Authentication-Results. >=20 > >Again, I think ABNF needs to be clear that other header fields can=20= > >appear in between Return-Path and Received, for example: > > > > =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D=C2=A0=C2=A0 [return] > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *trace-e= xtension-field > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*receiv= ed > > > > =C2=A0 trace-extension-field =3D optional-field >=20 > Wouldn't that mean that the extension fields are all above the=20 > received? How about this: >=20 > =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D=C2=A0=C2=A0 [return] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*(recei= ved / trace-extension-field) Works for me. > > >8.=C2=A0 IANA Considerations > > > > > >=C2=A0=C2=A0 In addition, if additional trace header fields (i.e., = in addition to > > >=C2=A0=C2=A0 Return-path and Received) are ever created, those trac= e fields MUST > > >=C2=A0=C2=A0 be added to the IANA registry established by BCP 90 (R= FC 3864) [8] > > >=C2=A0=C2=A0 for use with RFC 5322 [11]. > > > >I think the above is fine. We also talked about a separate registry f= or=20 > >trace header fields in the A/S document. >=20 > Is it a separate registry or a new column in the existing registry? I= t=20 > doesn't > seem like a great idea to have two registries where one is supposed to= =20 > be a subset > of the other. I don't think adding a new column will work, because this registry is al= so used by NNTP and HTTP folks. We could however ask IANA to check the s= econd registry for consistency with the first. I believe they have other= registries with similar requirements. Anyway, this is a part of ticket = #8, so let's defer this discussion until we get to that ticket. Best Regards, Alexey From nobody Tue Feb 23 05:46:58 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 04B5F3A2B4B for ; Tue, 23 Feb 2021 05:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_BLOCKED=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=b9Xu+Znn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pcstW4yk 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 THDUsKClwGY5 for ; Tue, 23 Feb 2021 05:46:56 -0800 (PST) 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 1635E3A2B48 for ; Tue, 23 Feb 2021 05:46:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ECFC05C0102; Tue, 23 Feb 2021 08:46:54 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Tue, 23 Feb 2021 08:46:54 -0500 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; s=fm2; bh=+lxzb2+6B6KnBc/l2TMV3M/gZLY3gr4 /JuVa1n6VvYg=; b=b9Xu+ZnnSbH3yNIrhSwTLROIoX79+ciHjccyI5XzpfSzOII /FZ131JNUhWYC894Go5Ay9wUO7pvuyPDSvgvoNwmGeR1WdfYGdwIuYCWb5OyCvm/ mURg/IRENK6x2ILe+DMI7DzeBCjNWaEACEOcKxZXeDkntBse6mm0HI/VnVbvJLt7 nPmQk0HqqR4i43f2qWcAy2+N0Ix1PAUxKDIXlEcmHYQkuR2odtV5jKB5NIw1gUEJ eiGlANOQFUngrHGRF1FZSFJISyDEr/67km4PSTygGDicXSVoNYbVY533HB80TBC8 HFqZF4hlAS8I1o8P6+O+BW2hFLD1te8waomtHhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=+lxzb2 +6B6KnBc/l2TMV3M/gZLY3gr4/JuVa1n6VvYg=; b=pcstW4ykWuJZoZcw5R3cyG 9gHeSacSOuNK8SHL/PUsubKVpwIoJLLGTWcps8aE6mYyGUwh2B37oEPymI9k5qbG nfJa/QOMMY8MAIBCG42ywE/fNf9HFwuTLTzpj6UINGMP6DsKi05WC7BfbAT9XEbh Vc4hQNKgEvjvP4CUIw7RcrHX6RmAQXkLp9fHMDtvjJ10PUOsDHSDryaADysjWl3+ TNTHdRLb9g3dX2bZlHlp/F2owPt9VN9zZPpT4ktUdyR8bxOSx16CtsSu4S9F04N5 SrnqSoJnJBUYIMmf9GVy3uV/183FswdwAKVSLfaxhOOx6Ai3sBgM5ZLC3foMbROw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefgefgiedujeegtdeludfguddvgfetfeeitdevtedu keefgeetgfehueeivdfgieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EDFFD6B4005F; Tue, 23 Feb 2021 08:46:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <56caf8ca-2bc1-4930-b962-41b9418d846d@www.fastmail.com> In-Reply-To: <39e55852-453-b9d0-5577-7bc6989e5e3f@taugh.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <39e55852-453-b9d0-5577-7bc6989e5e3f@taugh.com> Date: Tue, 23 Feb 2021 13:46:32 +0000 From: "Alexey Melnikov" To: "John R Levine" , "Pete Resnick" Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary=495bfa3964cf467280eecea671f1aecb Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 13:46:58 -0000 --495bfa3964cf467280eecea671f1aecb Content-Type: text/plain On Mon, Feb 22, 2021, at 10:47 PM, John R Levine wrote: > >> trace = [return] > >> 1*(received / trace-extension-field) > > > > Yes, and if I do that, I'll remove the extra optional-field at the top of the > > overall fields syntax in 3.6. > > OK. That is not exactly equivalent since it allows a trace block > consisting of just, say, Authentication-Results with no Received, but I > don't think that is wrong. I think this is Ok. Another thought about removing optional-field at the top of the overall fields syntax in 3.6: Does removing it has implication that anything at the top of the header has to be a trace header field or a resent block? If this is too restrictive, then leaving 3.6 syntax as it is is probably the best. --495bfa3964cf467280eecea671f1aecb Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Feb 22,= 2021, at 10:47 PM, John R Levine wrote:
>>     trace &nb= sp;         =3D   [ret= urn]
>>        &n= bsp;           &n= bsp;    1*(received / trace-extension-field)
>
> Yes, and if I do that, I'll remove the extra o= ptional-field at the top of the 
> overall fields = syntax in 3.6.

OK.  That is not exactl= y equivalent since it allows a trace block 
consistin= g of just, say, Authentication-Results with no Received, but I 
=
don't think that is wrong.

I think this is Ok.

Another thought= about removing optional-field at the top of the overall fields syn= tax in 3.6: Does removing it has implication that anything at the top of= the header has to be a trace header field or a resent block? If this is= too restrictive, then leaving 3.6 syntax as it is is probably the best.=



--495bfa3964cf467280eecea671f1aecb-- From nobody Tue Feb 23 05:53:16 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 C10BA3A2B67 for ; Tue, 23 Feb 2021 05:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 U2KtgWoAJZSh for ; Tue, 23 Feb 2021 05:53:11 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71033A2B60 for ; Tue, 23 Feb 2021 05:53:11 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id EB05A194080D; Tue, 23 Feb 2021 08:53:10 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 08:53:10 -0500 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=fm2; bh=gpWB5wlqS5BA/51CeiiyiAdmcez/iGOxtl+QDyX1g rk=; b=cNXsgSh5tXO0fMiCjJEW6hodkaI8G7TeRfMvKzmBiwHwMrxCcuWlRYGJA XJ8DcNP0DuESDviYofFVrq7HblGTMHXSzLA4rau5xxaryn7qS3kWhRPtOV1rqiLM ETrK6rLBn9jI+hnpMfd9+GMFdgyR9GFSBRi5ge6ZamIE1dX1naS4+XilyebplkAo UnLquj3iUAxpp5rMiag2YYZmFVcmFz/1i1Q9O2x1E+vGyepoyTMfchAL/EcZtBEn XT7YnTOpQj0iQyZ6eBiTMW527Nm3635Os+QNXMqmm8ZKU4XPLd4WzGFZhs4zbp0x Slb/PEwa0+LhdhrelO1nxzDw5+71A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpeeuudekieehgfeitdefheegjeeguedvieef feevtdeifeduuedtteekgfevtedtieenucffohhmrghinhepihgvthhfrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvgigvgih rdhmvghlnhhikhhovhesihhsohguvgdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 24DA96B4005F; Tue, 23 Feb 2021 08:53:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <01RVVY2FPQZ8005PTU@mauve.mrochek.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> Date: Tue, 23 Feb 2021 13:52:48 +0000 From: "Alexey Melnikov" To: "Ned Freed" , "Pete Resnick" Cc: emailcore@ietf.org, "John R Levine" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 13:53:14 -0000 On Mon, Feb 22, 2021, at 9:51 PM, Ned Freed wrote: > > Combining some answers to John L. and Alexey regarding the 5322bis > > chagnes... >=20 > > On 22 Feb 2021, at 13:42, John Levine wrote: >=20 > > > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> Alexey= > > > Melnikov writes: > > >> > > >>> 3.6.=C2=A0 Field Definitions > > >>> > > >>> =C2=A0=C2=A0 More importantly, the trace header fields and resen= t > > >>> =C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be = kept in > > >>> blocks > > >>> =C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 = and 3.6.7 for > > >>> more > > >>> =C2=A0=C2=A0 information. > > >> > > >> I think the above gives important characteristics of the trace he= ader > > >> fields and the above text looks fine to me. >=20 > I'm afraid it does nothing of the sort. Required handling is not the s= ame > as describing what constitutes a trace field. I suppose you might be a= ble > to work back from the handling to likely uses, but that's not how this= > should work. >=20 > So a definition is needed. Yes, you are right. > And as it happens, there was one in RFC 822 > section 4.3: >=20 > Trace information is used to provide an audit trail of message=20= > handling. In addition, it indicates a route back to the > sender of the message. >=20 > For some reason this bit of text didn't make it into 2822. I don't rec= all any > discussion of it, and I don't have time to search the archives for a r= eason why > it was dropped - assuming it was even decided on the list. >=20 > Regardless of cause, this definition or something similar needs to be = restored. >=20 > I also note that Received: and the concept of trace was introduced in = RFC 822; > it is not in RFC 733. This parallels the evolution of similar text in = the > development of the X.400 standards: FIPS PUB 98 doesn't provide any tr= ace > facilities at all, by DEC's Message Router (AFAIK the first and perhap= s only > implementation more or less based on that document) does support trace= fields. > And by the time X.400 proper rolled around we have this text in X.411:= =20 >=20 > 12.2.1.1.1.3 Trace-information >=20 > This argument documents the actions taken on the message (or probe o= r report) > by each MD through which the message (or probe or report) passes as = it is > transferred through the MTS (see 12.3.1). It shall be generated by e= ach MD > through which the message (or probe or report) passes. >=20 > 12.2.1.1.1.4 Internal-trace-information >=20 > This argument documents the actions taken on the message (or probe o= r report) > by each MTA through which the message (or probe or report) passes as= it is > transferred within an MD (see 12.3.1). It shall be generated by each= MTA > through which the message (or probe or report) passes within an MD. > As a matter of local policy, an MTA may (but is not required to) rem= ove > internal-trace-information relating to other MDs when performing del= ivery, or > when transferring to another MD, or on receiving from another MD. >=20 > I've often wished that the two types of trace information had made it = over to > the Internet side of things, so that calls for all Received: lines to = be > removed in the interests of not revealing internal network structure c= ould be > met more easily. Of course it's much too late for that, but it might b= e > interested to document for each header field containing trace informat= ion > whether it's generated by MSAs, MTAs, MDAs, or some combination of the= three. >=20 > There's probably additional text in the IFIP documents and possibly in= GOSIP; > unfortunately that material is in some box or file I can't locate. >=20 > However, I think this gives us enough to work with. I actually prefer = the > X.400 text to what's in RFC 822; the "actions taken" idea in particula= r > strikes me as both more general and less formal than "audit trail". So= > how about a definition along the lines of: >=20 > Trace information documents actions taken on the message by MSAs, MT= As and > MDAs. It is provided by an extensible set of header fields. I like it. > And then move onto the requirements, current set of fields, and so on.= >=20 > > > If we want to interoperate well, I think that SHOULD is a MUST. >=20 > > I can go spelunking in the DRUMS archive if needed, but my memory is= > > that the reason for the SHOULD was that we knew that certain > > implementations did not (and could not) keep things in prepended blo= cks > > and we didn't want the MUST to indicate that as a receiver you could= so > > strongly depend on them being kept together. >=20 > I believe that's correct. >=20 > > > Also, > > > how about saying they SHOULD NOT be deleted. It'd be a MUST NOT > > > except > > > that there is a special case for Authentication-Results. >=20 > > All of the "don't change/delete" requirements are in 5321bis; we nev= er > > had any in x22. I'm inclined to keep it that way. >=20 > Agreed. >=20 > > >> 3.6.7. Trace Fields > > >> > > >> The trace fields are a group of header fields consisting of an > > >> optional "Return-Path:" field, and one or more "Received:" fiel= ds. > > > > > > I think this needs to be updated to make it clear that other heade= r > > > fields can be designated as "trace header fields". For example: > > > > > > The trace fields are a group of header fields consisting of an > > > optional "Return-Path:" field, one or more "Received:" fields > > > and other header fields specified in other specifications. >=20 > > Yeah, I'll wordsmith that a bit, but I will do something like the ab= ove. >=20 > Again, you need an actual definition. Suggestions above., Works for me. > > >> Again, I think ABNF needs to be clear that other header fields ca= n > > >> appear in between Return-Path and Received, for example: > > >> > > >> =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return] > > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *trac= e-extension-field > > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*rec= eived > > >> > > >> =C2=A0 trace-extension-field =3D optional-field > > > > > > Wouldn't that mean that the extension fields are all above the > > > received? How about this: > > > > > > =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return] > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*(re= ceived / > > > trace-extension-field) >=20 > > Yes, and if I do that, I'll remove the extra optional-field at the t= op > > of the overall fields syntax in 3.6. >=20 > FWIW, I strongly prefer new fields to messing around with Received:. Y= es, I'm > aware that this means that some agents may require an update to their = list of > fields, but IMO messing around with Received: parsing is a bigger prob= lem. >=20 > Ned >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > From nobody Tue Feb 23 05:56: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 89FE03A2B71 for ; Tue, 23 Feb 2021 05:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=aWxEBKrf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gukrTWFy 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 n4VjjNpplWFJ for ; Tue, 23 Feb 2021 05:56:31 -0800 (PST) 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 B7DF33A2B6D for ; Tue, 23 Feb 2021 05:56:31 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1B59A5C0074; Tue, 23 Feb 2021 08:56:31 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Tue, 23 Feb 2021 08:56:31 -0500 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=fm2; bh=YjrMFK6GeJJYIXr3u2hu5+H5dE8SvLR NB7PbUX29Tx0=; b=aWxEBKrfFtsqoWNC4TEWZQ4I+THFhnaeP0Sko2p3uRlnbBM YlfqoNJE2KY2IoyVTKOHza4iL1pC6XaI9TSNzxgNmJe6OG4/IkP8E51Ikuupiwaf UOP36SGfYsgA3TGxt/Bxbxib2IK4QzNi5gzDNtIJ0E37t5p86eJDxvylsxT4aJup JarmYR6F9zzNjI2Hf4tRki23OWMUoMiKu19lCkY6TBh7ZC7LcDJ8Y8eK2maeTmXM 97WSU3vqyLyv4KEd9GSkwjQC+1qLzB8TA+N3FSBgPZxNWnD/ATTY8RaDD4sB9kUu GtKfO5BPyfQ8aWzb1NlwWQRNOKoIYZS8PBmMhCg== 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=fm2; bh=YjrMFK 6GeJJYIXr3u2hu5+H5dE8SvLRNB7PbUX29Tx0=; b=gukrTWFycScrm+eLGtOqpY 2QVSIY1Bn5GG8tOLCz8mg+VMDFDoQhhUFlTM9Ou5Y+B9WlnQvWkpfgGtjEcZwRIL tRTLNj/16ONI/ap9Cr+0X4gjMEYILqhPWP1jLfEXT1fXfxWLkilwbN7h0t9GAtFk mGxrSNlZUTUALyAUUVwFpjD9NGaC6bdUCR6NsgI6ccf+DGBd2cMQEC6Zg6O6yGVZ mSFDxpRXUZ5RKJz5R/pTvyoTCYveYFJZag5YxoCYg2cYGpGbLuI3fit5sp9ybIpl 0AdVZ39MhOOUurRCQeTnGsbBikHKD5WTgh5zoajB741WhWEV9iR0kHNx4DGH76gg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepfeeggfeiud ejgedtledugfduvdfgteefiedtveetudekfeegtefgheeuiedvgfeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvse hfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 871536B4005F; Tue, 23 Feb 2021 08:56:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <20210222202009.GA12620@hjp.at> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> <20210222194226.890486E7C605@ary.qy> <20210222202009.GA12620@hjp.at> Date: Tue, 23 Feb 2021 13:56:10 +0000 From: "Alexey Melnikov" To: "Peter J. Holzer" , emailcore@ietf.org Content-Type: multipart/alternative; boundary=3cc4fd93434d43ffa172754ffe096980 Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 13:56:34 -0000 --3cc4fd93434d43ffa172754ffe096980 Content-Type: text/plain Hi Peter, On Mon, Feb 22, 2021, at 8:20 PM, Peter J. Holzer wrote: > On 2021-02-22 14:42:26 -0500, John Levine wrote: > > In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> you write: > > >I didn't realize until John Klensin pointed out that this affects both > > >rfc5321bis and rfc5322bis. So below I extracted pretty much all text > > >related to trace header fields and in some cases I provide my strawman > > >proposals on how to update them: > > > > > >rfc5322bis: > > > > > > >3.6. Field Definitions > > > > > > > > More importantly, the trace header fields and resent > > > > header fields MUST NOT be reordered, and SHOULD be kept in blocks > > > > prepended to the message. See sections 3.6.6 and 3.6.7 for more > > > > information. > > > > > >I think the above gives important characteristics of the trace header > > >fields and the above text looks fine to me. > > I'm a bit worried that someone might read a "MUST be kept in blocks > prepended to the message" as a mandate to move existing trace fields to > the front. > > For example, suppose system D receives this message: > > Unknown-Field: 42 > Received; from B by C > Delivered-To: x@B > Received: from A by B > Received: by A > Subject: Example > ... > > Instead of just prepending its Received field, making it > > Received: from C by D > Unknown-Field: 42 > Received; from B by C > Delivered-To: x@B > Received: from A by B > Received: by A > Subject: Example > ... > > it pulls the recognized trace headers to the front, like this: > > Received: from C by D > Received; from B by C > Delivered-To: x@B > Received: from A by B > Received: by A > Unknown-Field: 42 > Subject: Example > ... > > > I don't think that would be a good idea. I think an MTA should just > never reorder existing headers (whether they are trace headers or not) > and just prepends any headers it wants to add. I generally agree that not reordering is the only sane way. However I am not sure whether we can tighten the requirement in rfc5322bis. Best Regards, Alexey --3cc4fd93434d43ffa172754ffe096980 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Peter,
=

On Mon, Feb 22, 2021, at 8:20 PM, Peter J. Holzer wr= ote:
On 202= 1-02-22 14:42:26 -0500, John Levine wrote:
> In article= <3= c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> you write:
> >I didn't realize until John Klensin pointed out that thi= s affects both 
> >rfc5321bis and rfc5322bis. S= o below I extracted pretty much all text 
> >re= lated to trace header fields and in some cases I provide my strawman&nbs= p;
> >proposals on how to update them:
> >
> >rfc5322bis:
> >
> > >3.6.  Field Definitions
>= ; > >
> > >   More importantly, t= he trace header fields and resent
> > > &nbs= p; header fields MUST NOT be reordered, and SHOULD be kept in blocks
=
> > >   prepended to the message.  Se= e sections 3.6.6 and 3.6.7 for more
> > > &n= bsp; information.
> >
> >I think= the above gives important characteristics of the trace header 
=
> >fields and the above text looks fine to me.

I'm a bit worried that someone might read a "MUST b= e kept in blocks
prepended to the message" as a mandate to= move existing trace fields to
the front. 
<= div>
For example, suppose system D receives this message:<= br>

    Unknown-Field: 42
    Received; from B by C
 &nb= sp;  Delivered-To: x@B
    Received: f= rom A by B
    Received: by A
    Subject: Example
    ..= .

Instead of just prepending its Received f= ield, making it

    Received= : from C by D
    Unknown-Field: 42
    Received; from B by C
 &nbs= p;  Delivered-To: x@B
    Received: fr= om A by B
    Received: by A
=     Subject: Example
    ...=

it pulls the recognized trace headers to t= he front, like this:

    Rec= eived: from C by D
    Received; from B by = C
    Delivered-To: x@B
 = ;   Received: from A by B
    Rec= eived: by A
    Unknown-Field: 42
=
    Subject: Example
   = ; ...


I don't think that wou= ld be a good idea. I think an MTA should just
never reorde= r existing headers (whether they are trace headers or not)
and just prepends any headers it wants to add.
I generally agree that not reordering is the only sane way. However I= am not sure whether we can tighten the requirement in rfc5322bis.

Best Regards,
Alexey

--3cc4fd93434d43ffa172754ffe096980-- From nobody Tue Feb 23 06:13:55 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 5C77C3A2A24 for ; Tue, 23 Feb 2021 06:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 RxWbG2vK7qNv for ; Tue, 23 Feb 2021 06:13:49 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5423A2B9E for ; Tue, 23 Feb 2021 06:13:49 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 9BB701940851; Tue, 23 Feb 2021 09:13:48 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 09:13:48 -0500 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=fm2; bh=LcHILcxIx4IpmMXrugctONhA5JHonngkE7RGK2ZfA BM=; b=s5yZAkvvUw8eYlmTEtH53bQo1l4MgxEtwESOyPlqlD0xDrkpC3JpdYtk3 vGoyqIM92SFvw4ADJa8aUqlPbVWJhMERnsxm12EuHflqfk0MIQfSNFMrvwAd9qvw xbpz03tajWx3KV4FAUgp4LpawxTda0HB9/9zNaY+koikc/bzTRzYQb/9PzB4EQJB 4iSrHeJwTsjogytS3+KrL/qQ/L0eaQe6ITwq0XcEKjsBfYwpQNp3wasnLMJiKz/5 TKpq8bdNEdzN25vFAgzUovZU5JNV+EAbbZG3Ig14PASz7Z2U/P+G3P+Rb8cstnLn KvJBu4JbeSlFrxAdJhWSX1pZHDxxg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorghlvgig vgihrdhmvghlnhhikhhovhesihhsohguvgdrtghomheqnecuggftrfgrthhtvghrnhepue dukeeihefgiedtfeehgeejgeeuvdeifeefvedtieefudeutdetkefgveettdeinecuffho mhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B92466B4005F; Tue, 23 Feb 2021 09:13:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <8D80F62EB84782FA2C9295E6@PSB> References: <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> <8D80F62EB84782FA2C9295E6@PSB> Date: Tue, 23 Feb 2021 14:13:27 +0000 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 14:13:53 -0000 Hi John, On Mon, Feb 22, 2021, at 6:09 PM, John C Klensin wrote: > Alexey, >=20 > I think this is about right. =20 >=20 > As editor: I wonder (it would take some research to figure it > out) where "trace record" entered the vocabulary. Noting that > "trace" does not appear to occur at all in 821, I suspect it is > just a potentially confusing artifact of the document-merging > process or the editor of 2821 having an attack of stupid > inconsistency rather than the distinction you are making. From > that perspective, while it would require more work, an > alternative would be to remove that term, use "trace header > field" throughout, and reword the relevant paragraphs to make it > clear that "Received:" is not the only such field. I saw Pete's reply, but I am happy with either change. > In addition, the boundary between what information about those > fields is included in 5321bis versus 5322bis is a bit arbitrary > and may not be quite right. I wonder if it would be worthwhile > for the WG to review those choices and made suggestions that > might reduce having potentially conflicting descriptions in two > different documents. The latter practice is, as Dave Crocker > recently pointed out, an invitation to confusion. On the other > hand, if we start tampering with that boundary, we might easily > make things worse. Right. I think having a definition of trace header fields in rfc5322bis = makes sense, as there is already a section there. I don't have strong fe= elings about moving text between documents. Best Regards, Alexey (as a participant) > I'm happy to do whatever the WG decides about the above as long > as I get clear instructions. >=20 > john >=20 >=20 > --On Monday, February 22, 2021 17:03 +0000 Alexey Melnikov > wrote: >=20 > > Hi all, > >=20 > > I didn't realize until John Klensin pointed out that this > > affects both rfc5321bis and rfc5322bis. So below I extracted > > pretty much all text related to trace header fields and in > > some cases I provide my strawman proposals on how to update > > them: > >=20 > > rfc5322bis: > >=20 > > >3.6.=C2=A0 Field Definitions > > > > > >=C2=A0=C2=A0 More importantly, the trace header fields and resent > > >=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be ke= pt > > in blocks > > >=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 an= d > > 3.6.7 for more > > >=C2=A0=C2=A0 information. > >=20 > > I think the above gives important characteristics of the trace > > header fields and the above text looks fine to me. > >=20 > >=20 > > >3.6.7.=C2=A0 Trace Fields > > > > > >=C2=A0=C2=A0 The trace fields are a group of header fields > > consisting of an > > >=C2=A0=C2=A0 optional "Return-Path:" field, and one or more > > "Received:" fields. > >=20 > > I think this needs to be updated to make it clear that other > > header fields can be designated as "trace header fields". For > > example: > >=20 > > =C2=A0=C2=A0 The trace fields are a group of header fields consisti= ng > > of an > > =C2=A0=C2=A0 optional "Return-Path:" field, one or more "Received:"= > > fields > > =C2=A0=C2=A0 and other header fields specified in other > > specifications. > >=20 > > >=C2=A0=C2=A0 The "Return-Path:" header field contains a pair of > > angle brackets > > >=C2=A0=C2=A0 that enclose an optional addr-spec.=C2=A0 The "Receiv= ed:" > > field contains a > > >=C2=A0=C2=A0 (possibly empty) list of tokens followed by a semicol= on > > and a date- > > >=C2=A0=C2=A0 time specification.=C2=A0 Each token must be a word, > > angle-addr, addr- > > >=C2=A0=C2=A0 spec, or a domain.=C2=A0 Further restrictions are app= lied > > to the syntax of > > >=C2=A0=C2=A0 the trace fields by specifications that provide for > > their use, such > > >=C2=A0=C2=A0 as [I-D.klensin-rfc5321bis]. > > > > > >=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return] > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*rec= eived > >=20 > > Again, I think ABNF needs to be clear that other header fields > > can appear in between Return-Path and Received, for example: > >=20 > > =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D=C2=A0=C2=A0 [return] > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > *trace-extension-field > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*receiv= ed > >=20 > > =C2=A0 trace-extension-field =3D optional-field > >=20 > > >=C2=A0=C2=A0 A full discussion of the Internet mail use of trace > > fields is > > > =C2=A0 contained in [I-D.klensin-rfc5321bis]. > > >=C2=A0=C2=A0 For the purposes of this > > >=C2=A0=C2=A0 specification, the trace fields are strictly > > informational, and any > > >=C2=A0=C2=A0 formal interpretation of them is outside of the scope= > > of this > > >=C2=A0=C2=A0 document. > >=20 > > >Appendix B.=C2=A0 Differences from Earlier Specifications > >=20 > > >The following are changes from [RFC2822]. > >=20 > > >=C2=A0=C2=A0 12.=C2=A0 Allowed optional-field to appear within tra= ce > > information. > >=20 > > It doesn't look like this actually happened or maybe this was > > altered in RFC 5322. > >=20 > >=20 > > rfc5321bis: > >=20 > > >3.7.2.=C2=A0 Received Lines in Gatewaying > > > > > >=C2=A0=C2=A0 "Received:" header fields of messages originating fro= m > > other > > >=C2=A0=C2=A0 environments may not conform exactly to this > > specification.=C2=A0 However, > > >=C2=A0=C2=A0 the most important use of Received: lines is for > > debugging mail > > >=C2=A0=C2=A0 faults, and this debugging can be severely hampered b= y > > well-meaning > > >=C2=A0=C2=A0 gateways that try to "fix" a Received: line.=C2=A0 As= > > another consequence > > >=C2=A0=C2=A0 of trace header fields arising in non-SMTP > > environments, receiving > > >=C2=A0=C2=A0 systems MUST NOT reject mail based on the format of a= > > trace header > > >=C2=A0=C2=A0 field and SHOULD be extremely robust in the light of > > unexpected > > >=C2=A0=C2=A0 information or formats in those header fields. > >=20 > > This talks about purpose of trace header fields and this text > > looks fine to me. > >=20 > > >4.1.1.4.=C2=A0 DATA (DATA) > > > > > >=C2=A0=C2=A0 When the SMTP server accepts a message either for > > relaying or for > > >=C2=A0=C2=A0 final delivery, it inserts a trace record (also > > referred to > >=20 > > So this introduces "trace record", which is different from > > "trace header fields", as it only related to Received. > >=20 > > >=C2=A0=C2=A0 interchangeably as a "time stamp line" or "Received" > > line) at the top > > >=C2=A0=C2=A0 of the mail data.=C2=A0 This trace record indicates t= he > > identity of the > > >=C2=A0=C2=A0 host that sent the message, the identity of the host > > that received > > >=C2=A0=C2=A0 the message (and is inserting this time stamp), and t= he > > date and time > > >=C2=A0=C2=A0 the message was received. > >=20 > > >4.4.=C2=A0 Trace Information > > > > > >=C2=A0=C2=A0 When an SMTP server receives a message for delivery o= r > > further > > >=C2=A0=C2=A0 processing, it MUST insert trace (often referred to a= s > > "time stamp" > >=20 > > I suggest to add "record" after "trace" to match the above > > definition. > >=20 > > >=C2=A0=C2=A0 or "Received" information) beginning of the message > > content, as > > >=C2=A0=C2=A0 discussed in Section 4.1.1.4. > >=20 > > >6.4.=C2=A0 Compensating for Irregularities > > > > > >=C2=A0=C2=A0 In all cases, properly operating clients supplying > > correct > > >=C2=A0=C2=A0 information are preferred to corrections by the SMTP > > server.=C2=A0 In all > > >=C2=A0=C2=A0 cases, documentation SHOULD be provided in trace head= er > > fields and/or > > >=C2=A0=C2=A0 header field comments for actions performed by the > > servers. > >=20 > > This looks fine to me. > >=20 > > >7.6.=C2=A0 Information Disclosure in Trace Fields > > > > > >=C2=A0=C2=A0 In some circumstances, such as when mail originates > > from within a LAN > > >=C2=A0=C2=A0 whose hosts are not directly on the public Internet, > > trace > > >=C2=A0=C2=A0 ("Received") header fields produced in conformance wi= th > > this > > >=C2=A0=C2=A0 specification may disclose host names and similar > > information that > > >=C2=A0=C2=A0 would not normally be available. > >=20 > > I think the above is largely correct, but I suggest inserting > > "e.g." before "Received" in 'trace ("Received") header fields' > > to make it clear that this is not a full list of trace header > > fields. > >=20 > >=20 > > >8.=C2=A0 IANA Considerations > > > > > >=C2=A0=C2=A0 In addition, if additional trace header fields (i.e.,= > > in addition to > > >=C2=A0=C2=A0 Return-path and Received) are ever created, those tra= ce > > fields MUST > > >=C2=A0=C2=A0 be added to the IANA registry established by BCP 90 > > (RFC 3864) [8] > > >=C2=A0=C2=A0 for use with RFC 5322 [11]. > >=20 > > I think the above is fine. We also talked about a separate > > registry for trace header fields in the A/S document. > >=20 > > Best Regards, > >=20 > > Alexey >=20 >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > From nobody Tue Feb 23 08:21:49 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 493F43A07F7 for ; Tue, 23 Feb 2021 08:21:47 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=DLXQN5Pg; dkim=pass (2048-bit key) header.d=taugh.com header.b=lXYzOw/1 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 cdaTBrFpv-KK for ; Tue, 23 Feb 2021 08:21:45 -0800 (PST) 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 8C38C3A07C0 for ; Tue, 23 Feb 2021 08:21:44 -0800 (PST) Received: (qmail 51841 invoked from network); 23 Feb 2021 16:21:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=ca7e.60352b97.k2102; bh=BOg6bueWWbv5DJ72gJS1AdDAPUQOZ8MimwK79K85t+A=; b=DLXQN5PgSJNCA63m42/cCzw+gkk4KIslQC/wV6524p1VlHVBlDLgwRmZMGxV/xrjjoJ9+djqfowN/gXNtrG7pPgnkxmiEQRS81493jfsy8eWS3Gvu3HBBKSZ/5RNEZkwEzvYMOPdMrnz2JpndN3/FEI5ufmx4NG/9hQVOafxV7TMEyCs3nZIvJzmltekc7a1lv5p+7dHDWYVrjC/J17gDo1XZCJ2P3aNtrsk1F002Efz4XDrWMAZJGF5kurHeUxqBGq9Lq4FcRMgU1WRlFF6V2wGnBmwhCLr9B04xho7mANxYJ7nMAbn4/lAs002mTULyVKDs4AcI1adCG9L6jdBvw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=ca7e.60352b97.k2102; bh=BOg6bueWWbv5DJ72gJS1AdDAPUQOZ8MimwK79K85t+A=; b=lXYzOw/1VV47VWSwxzwYnoxJ7kYUoqyRi5NB9bhjzvcuZ1Kil7BGSspIEoeZYiE7TdqsMjIDRjOuUHm3nNZvwUeql57p4sBjwo3lgZL52kcz0spiOHGKteN2Y2BohD4sSPkNXdZzZps+xrvT8Y0j2vPyHUSCVWsr/5zIgHOosYcoWRqh1D1DeJEd/jBIMyYo+cVHWPT1htduz9rjogTvjT0lejtoUtuBZnNpSTZ0DYN7xHxwtDS59wgpmV6rBeKI6ci/md+PmWSONqha1Ex38VV24GfAOKr8anrBDnO1Os/IGXs4vL7q3rdQI/85wNqQsd1HeLAkdovzP0SQGPBqQg== 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; 23 Feb 2021 16:21:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 6DDDC6E91E25; Tue, 23 Feb 2021 11:21:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 2FD346E91E07; Tue, 23 Feb 2021 11:21:42 -0500 (EST) Date: 23 Feb 2021 11:21:42 -0500 Message-ID: From: "John R Levine" To: "Alexey Melnikov" , emailcore@ietf.org In-Reply-To: References: <20210222194226.890486E7C605@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 16:21:47 -0000 >> Is it a separate registry or a new column in the existing registry? It doesn't >> seem like a great idea to have two registries where one is supposed to be a subset >> of the other. > > I don't think adding a new column will work, because this registry is also used by NNTP and HTTP folks. We could however ask IANA to check the second registry for consistency with the first. I believe they have other registries with similar requirements. Anyway, this is a part of ticket #8, so let's defer this discussion until we get to that ticket. There's already a column for which protocol, so I'd say the "trace" column only applies to mail headers. Or maybe change the protocol column so it has both mail and mailtrace. Anything that IANA can handle is fine with me but having done my PhD in databases, schemas with two manually maintained tables that are supposed to match up make my stomach hurt. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS: The netnews Path header actts a lot like a trace header but we can burn that bridge later. From nobody Tue Feb 23 09:29:26 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 7A30E3A0C38 for ; Tue, 23 Feb 2021 09:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 OjRD2b3-vzOf for ; Tue, 23 Feb 2021 09:29:22 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED2B3A0CAE for ; Tue, 23 Feb 2021 09:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 4D6ADD78B254; Tue, 23 Feb 2021 11:29:17 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-t8jGj0WsjS; Tue, 23 Feb 2021 11:29:15 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 9083BD78B249; Tue, 23 Feb 2021 11:29:14 -0600 (CST) From: Pete Resnick To: Ned Freed Cc: John Levine , emailcore@ietf.org, alexey.melnikov@isode.com Date: Tue, 23 Feb 2021 11:29:12 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> In-Reply-To: <01RVVY2FPQZ8005PTU@mauve.mrochek.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4C55E9E9-96F4-45EF-9E11-D6F1F5BE5BA3_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 17:29:25 -0000 --=_MailMate_4C55E9E9-96F4-45EF-9E11-D6F1F5BE5BA3_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 22 Feb 2021, at 15:51, Ned Freed wrote: >>> In article <3c4d9d6e-4bf1-c0ed-e924-2cf567505581@isode.com> Alexey >>> Melnikov writes: >>>> >>>>> 3.6.  Field Definitions >>>>> >>>>>    More importantly, the trace header fields and resent >>>>>    header fields MUST NOT be reordered, and SHOULD be kept in >>>>> blocks >>>>>    prepended to the message.  See sections 3.6.6 and 3.6.7 for >>>>> more >>>>>    information. >>>> >>>> I think the above gives important characteristics of the trace >>>> header >>>> fields and the above text looks fine to me. > > I'm afraid it does nothing of the sort. Required handling is not the > same > as describing what constitutes a trace field. I suppose you might be > able > to work back from the handling to likely uses, but that's not how this > should work. Well, it does give some characteristics, but I agree, it doesn't give a full definition. > So a definition is needed. And as it happens, there was one in RFC 822 > section 4.3: > > Trace information is used to provide an audit trail of message > handling. In addition, it indicates a route back to the > sender of the message. > > For some reason this bit of text didn't make it into 2822. I don't > recall any > discussion of it, and I don't have time to search the archives for a > reason why > it was dropped - assuming it was even decided on the list. > > Regardless of cause, this definition or something similar needs to be > restored. Again without spelunking, I believe I know what happened: We decided that we were going to move all of the semantics of trace into 2821 so that 2822 didn't have to repeat (potentially slightly different) text from 2821. So what we were left with was the specification of the syntax in 2822 and left any other discussion to 2821. We can certainly undo that decision, but I'm not totally convinced we need to. > I've often wished that the two types of trace information had made it > over to > the Internet side of things, so that calls for all Received: lines to > be > removed in the interests of not revealing internal network structure > could be > met more easily. Of course it's much too late for that, but it might > be > interested to document for each header field containing trace > information > whether it's generated by MSAs, MTAs, MDAs, or some combination of the > three. That says to me that it may still be appropriate to let documents other than xx22 document the semantics of the trace fields. > Trace information documents actions taken on the message by MSAs, > MTAs and > MDAs. It is provided by an extensible set of header fields. I think something along those lines is probably safe to put in xx22. > And then move onto the requirements, current set of fields, and so on. I think that might be best left for another document. >> On 22 Feb 2021, at 13:42, John Levine wrote: >>>> Again, I think ABNF needs to be clear that other header fields can >>>> appear in between Return-Path and Received, for example: >>>> >>>>    trace           =   [return] >>>>                        *trace-extension-field >>>>                        1*received >>>> >>>>   trace-extension-field = optional-field >>> >>> Wouldn't that mean that the extension fields are all above the >>> received? How about this: >>> >>>    trace           =   [return] >>>                        1*(received / >>> trace-extension-field) >> >> Yes, and if I do that, I'll remove the extra optional-field at the >> top >> of the overall fields syntax in 3.6. > > FWIW, I strongly prefer new fields to messing around with Received:. > Yes, I'm > aware that this means that some agents may require an update to their > list of > fields, but IMO messing around with Received: parsing is a bigger > problem. I'm not sure I understand this last comment. There is no suggestion to mess around with Received:. The proposal is to move optional-field into the definition of trace in 3.6.7 rather than have it in the overall fields syntax at the top of 3.6. Did I miss something? pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_4C55E9E9-96F4-45EF-9E11-D6F1F5BE5BA3_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 22 Feb 2021, at 15:51, Ned Freed wrote:

In article 3c4d9d6e-4bf1-c0ed-e924-2cf56750= 5581@isode.com Alexey
Melnikov writes:

3.6.=C2=A0 Field Definitions

=C2=A0=C2=A0 More importantly, the trace header fields an= d resent
=C2=A0=C2=A0 header fields MUST NOT be reordered, and SHOULD be kept in blocks
=C2=A0=C2=A0 prepended to the message.=C2=A0 See sections 3.6.6 and 3.6.7= for
more
=C2=A0=C2=A0 information.

I think the above gives important characteristics of the = trace header
fields and the above text looks fine to me.

I'm afraid it does nothing of the sort. Required handling= is not the same
as describing what constitutes a trace field. I suppose you might be able=
to work back from the handling to likely uses, but that's not how this should work.

Well, it does give some characteristics, but I agree, it = doesn't give a full definition.

So a definition is needed. And as it happens, there was o= ne in RFC 822
section 4.3:

Trace information=
 is used to provide an audit trail of  message     handling.   In  additi=
on,  it indicates a route back to the
sender of the message.

For some reason this bit of text didn't make it into 2822= =2E I don't recall any
discussion of it, and I don't have time to search the archives for a reas= on why
it was dropped - assuming it was even decided on the list.

Regardless of cause, this definition or something similar= needs to be restored.

Again without spelunking, I believe I know what happened:= We decided that we were going to move all of the semantics of trace into= 2821 so that 2822 didn't have to repeat (potentially slightly different)= text from 2821. So what we were left with was the specification of the s= yntax in 2822 and left any other discussion to 2821. We can certainly und= o that decision, but I'm not totally convinced we need to.

I've often wished that the two types of trace information= had made it over to
the Internet side of things, so that calls for all Received: lines to be<= br> removed in the interests of not revealing internal network structure coul= d be
met more easily. Of course it's much too late for that, but it might be interested to document for each header field containing trace information=
whether it's generated by MSAs, MTAs, MDAs, or some combination of the th= ree.

That says to me that it may still be appropriate to let d= ocuments other than xx22 document the semantics of the trace fields.

Trace information documents actions taken on the message = by MSAs, MTAs and
MDAs. It is provided by an extensible set of header fields.

I think something along those lines is probably safe to p= ut in xx22.

And then move onto the requirements, current set of field= s, and so on.

I think that might be best left for another document.

=

On 22 Feb 2021, at 13:42, John Levine wrote:

Again, I think ABNF needs to be clear that other header f= ields can
appear in between Return-Path and Received, for example:

=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trace-exten= sion-field
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1received<= /p>

=C2=A0 trace-extension-field =3D optional-field

Wouldn't that mean that the extension fields are all abov= e the
received? How about this:

=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*(received / trace-extension-field)

Yes, and if I do that, I'll remove the extra optional-fie= ld at the top
of the overall fields syntax in 3.6.

FWIW, I strongly prefer new fields to messing around with= Received:. Yes, I'm
aware that this means that some agents may require an update to their lis= t of
fields, but IMO messing around with Received: parsing is a bigger problem= =2E

I'm not sure I understand this last comment. There is no = suggestion to mess around with Received:. The proposal is to move optiona= l-field into the definition of trace in 3.6.7 rather than have it in the = overall fields syntax at the top of 3.6. Did I miss something?

pr

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_4C55E9E9-96F4-45EF-9E11-D6F1F5BE5BA3_=-- From nobody Tue Feb 23 09:34:47 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 156A63A0C67 for ; Tue, 23 Feb 2021 09:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NImWWq38ve6Z for ; Tue, 23 Feb 2021 09:34:43 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D056A3A0C5D for ; Tue, 23 Feb 2021 09:34:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id DB3D0D78B456; Tue, 23 Feb 2021 11:34:42 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXnAuf9L1o0J; Tue, 23 Feb 2021 11:34:41 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id E489BD78B438; Tue, 23 Feb 2021 11:34:40 -0600 (CST) From: Pete Resnick To: Alessandro Vesely Cc: emailcore@ietf.org Date: Tue, 23 Feb 2021 11:34:39 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> In-Reply-To: References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_DAFA8A67-68BA-4237-ABE4-9DC53E2B5650_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 17:34:46 -0000 --=_MailMate_DAFA8A67-68BA-4237-ABE4-9DC53E2B5650_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: > On Mon 22/Feb/2021 22:32:08 +0100 Pete Resnick wrote: >> Combining some answers to John L. and Alexey regarding the 5322bis >> chagnes... >> [...] >>>> Again, I think ABNF needs to be clear that other header fields can >>>> appear in between Return-Path and Received, for example: >>>> >>>>    trace           =   [return] >>>>                        *trace-extension-field >>>>                        1*received >>>> >>>>   trace-extension-field = optional-field >>> >>> Wouldn't that mean that the extension fields are all above the >>> received?  How about this: >>> >>>     trace           =   [return] >>>                         1*(received / >>> trace-extension-field) >> >> Yes, and if I do that, I'll remove the extra optional-field at the >> top of the overall fields syntax in 3.6. > > > That ABNF seems to imply there must be at least one Received:. Why > then does the table in Section 3.6 show a Min number of 0 trace? Because the entire trace block is optional according to the ABNF right above that table in 3.6. > I agree with Peter's worries about mandating the initial block. The > optional-field allowed more leeway, as the optional field could happen > to be whatever, not necessarily a trace field. Indeed, the > requirement to collect all trace fields at the top of the header lest > the message be syntactically bad is a recipe for trouble. But optional-field is permitted at the bottom of the ABNF of fields in 3.6, which would allow it to be used for something that is not a trace field. (That is, optional-field appears twice in the 3.6 syntax.) > The practice to collect trace fields at the top comes from the fact > that it is convenient to write down one's 2 cents and then copy the > rest without even parsing it. But a mail filter can add a header > field holding information that semantically does not make it a trace > field. Even then, it is more natural to write added fields near the > top of the header. Doing so is also better for debugging and forensic > analysis, as it is possible to deduce at what stage a given field was > added. > > For example, consider a DKIM filter which tries and reverts a mailing > list's From: munging. It records its findings in a trace field, > Authentication-Results:. In addition, if the reversion succeeds, it > adds an Original-From: field, formatted like From:. Semantically > equivalent to From:, and eventually swappable with it, the latter is > definitely not a trace field. Should it be added downward, possibly > near to the real From:, or isn't it more self-explanatory to add it > near the corresponding Authentication-Results:? > > Could we relax the header syntax? For example: > > trace = [return] > *top-field > > top-field = received / > trace-extension-field / > prowl-field > > Where prowl-field can actually be any field, possibly resulting from > Sieve or any other email filtering. That syntax still conveys that > trace fields tend to gather near the top of the header, but doesn't > require a strict order. Review the ABNF at the top of 3.6 and see if you can't express what you want to. Otherwise, I think things are best left alone except for moving the first occurrence of optional-field out of 3.6 and putting an optional-field (or trace-extension-field) into 3.6.7. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_DAFA8A67-68BA-4237-ABE4-9DC53E2B5650_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 23 Feb 2021, at 5:39, Alessandro Vesely wrote:

On Mon 22/Feb/2021 22:32:08 +0100 Pete Resnick wrote:

=

Combining some answers to John L. and Alexey regarding th= e 5322bis chagnes...
[...]

Again, I think ABNF needs to be clear that other header f= ields can
appear in between Return-Path and Received, for example:

=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trace-exten= sion-field
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1received<= /p>

=C2=A0 trace-extension-field =3D optional-field

Wouldn't that mean that the extension fields are all abov= e the received?=C2=A0 How about this:

=C2=A0=C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D=C2=A0=C2=A0 [return]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*(receiv= ed / trace-extension-field)

Yes, and if I do that, I'll remove the extra optional-fie= ld at the top of the overall fields syntax in 3.6.

That ABNF seems to imply there must be at least one Recei= ved:. Why then does the table in Section 3.6 show a Min number of 0 trac= e?

Because the entire trace block is optional according to t= he ABNF right above that table in 3.6.

I agree with Peter's worries about mandating the initial = block. The optional-field allowed more leeway, as the optional field cou= ld happen to be whatever, not necessarily a trace field. Indeed, the req= uirement to collect all trace fields at the top of the header lest the me= ssage be syntactically bad is a recipe for trouble.

But optional-field is permitted at the bottom of the ABNF= of fields in 3.6, which would allow it to be used for something that is = not a trace field. (That is, optional-field appears twice in the 3.6 synt= ax.)

The practice to collect trace fields at the top comes fro= m the fact that it is convenient to write down one's 2 cents and then cop= y the rest without even parsing it. But a mail filter can add a header f= ield holding information that semantically does not make it a trace field= =2E Even then, it is more natural to write added fields near the top of = the header. Doing so is also better for debugging and forensic analysis,= as it is possible to deduce at what stage a given field was added.

For example, consider a DKIM filter which tries and rever= ts a mailing list's From: munging. It records its findings in a trace fi= eld, Authentication-Results:. In addition, if the reversion succeeds, it= adds an Original-From: field, formatted like From:. Semantically equiva= lent to From:, and eventually swappable with it, the latter is definitely= not a trace field. Should it be added downward, possibly near to the rea= l From:, or isn't it more self-explanatory to add it near the correspondi= ng Authentication-Results:?

Could we relax the header syntax? For example:

trace     =3D [re=
turn]
            *top-field

top-field =3D received /
            trace-extension-field /
            prowl-field

Where prowl-field can actually be any field, possibly res= ulting from Sieve or any other email filtering. That syntax still convey= s that trace fields tend to gather near the top of the header, but doesn'= t require a strict order.

Review the ABNF at the top of 3.6 and see if you can't ex= press what you want to. Otherwise, I think things are best left alone exc= ept for moving the first occurrence of optional-field out of 3.6 and putt= ing an optional-field (or trace-extension-field) into 3.6.7.

pr

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_DAFA8A67-68BA-4237-ABE4-9DC53E2B5650_=-- From nobody Tue Feb 23 09:45:22 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 B78F23A0C99 for ; Tue, 23 Feb 2021 09:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 BwIJJqK8eIu6 for ; Tue, 23 Feb 2021 09:45:19 -0800 (PST) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590EE3A0C80 for ; Tue, 23 Feb 2021 09:45:19 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 32AB71940C36; Tue, 23 Feb 2021 12:45:18 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 12:45:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=okWC+O am7j3bAkLZJYr77qb/BeE/UAoHUP1sVZ1u2rY=; b=LSAiZ+ogQ5CyicfQm2G/aN U/a42OJnksCq94q7k1bDQCIvje9siy+ehfZa6a3UToq4kQ0Y8XXSxjvm4ot/RkW4 uvrhaE8ivXLjfoBm4beZwdgtNvySpNWyOz+diJGCnX4zK4cjKRfh5ES80e9/O19O yyw4IJAFBVs7ohl/PTO6VksNRFuNh08llq3W7x81j0WWtXiEBjVDliuahSw9nwfT 8LFALSOdmr8L17311pWDKYCI/+Due+LVoJDAY8Olv5tEHV9+VYozT3wzIQTllzF6 uYX8A4OIxzo3vELtz/FWHAqOhok8aF1PdKYR0BSPIJbTsMgGU0l9Bh8buwxHsKIw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpeeiheetkedvgfeileeuleffhfdthfeifedv ueehjefggeehveffhfdvkeefudfhieenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E9D936B4005F; Tue, 23 Feb 2021 12:45:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <00fcca77-4aa9-4662-9aaa-e85f3888a744@www.fastmail.com> In-Reply-To: <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> Date: Tue, 23 Feb 2021 17:44:56 +0000 From: "Alexey Melnikov" To: "Pete Resnick" Cc: emailcore@ietf.org, "Ned Freed" Content-Type: multipart/alternative; boundary=601a639bc9024074a634c01bb7a50a2f Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 17:45:21 -0000 --601a639bc9024074a634c01bb7a50a2f Content-Type: text/plain Pete, On Tue, Feb 23, 2021, at 5:29 PM, Pete Resnick wrote: > On 22 Feb 2021, at 15:51, Ned Freed wrote: [snip] >> Trace information documents actions taken on the message by MSAs, MTAs and >> MDAs. It is provided by an extensible set of header fields. > I think something along those lines is probably safe to put in xx22. Can you please advise where to add this text in xx22? (I am not yet convinced that adding this to xx22 is the best course of action, but happy to be proven wrong.) Thank you, Alexey --601a639bc9024074a634c01bb7a50a2f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Pete,

On Tue, Feb 23, 2021, at 5:29 PM, Pete Resnick wrote:

= On 22 Feb 2021, at 15:51, Ned Freed wrote:

 [snip]

Trace information documents actions taken on= the message by MSAs, MTAs and
MDAs. It is provided by an= extensible set of header fields.

I think something along those lines is probably safe to put in xx= 22.

Can you please advise where to = add this text in xx22? (I am not yet convinced that adding this to xx22 = is the best course of action, but happy to be proven wrong.)

Thank you,
Alexey
--601a639bc9024074a634c01bb7a50a2f-- From nobody Tue Feb 23 10:06:04 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 85D363A0CEA for ; Tue, 23 Feb 2021 10:06:01 -0800 (PST) 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 B7YevydCxC-m for ; Tue, 23 Feb 2021 10:05:59 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A743A0CEB for ; Tue, 23 Feb 2021 10:05:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 1E6ABD78C771; Tue, 23 Feb 2021 12:05:59 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLroQR4mguhv; Tue, 23 Feb 2021 12:05:58 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id D8692D78C762; Tue, 23 Feb 2021 12:05:57 -0600 (CST) From: Pete Resnick To: "Alexey Melnikov" Cc: emailcore@ietf.org, Ned Freed Date: Tue, 23 Feb 2021 12:05:57 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: <00fcca77-4aa9-4662-9aaa-e85f3888a744@www.fastmail.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> <00fcca77-4aa9-4662-9aaa-e85f3888a744@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 18:06:02 -0000 On 23 Feb 2021, at 11:44, Alexey Melnikov wrote: > On Tue, Feb 23, 2021, at 5:29 PM, Pete Resnick wrote: >> On 22 Feb 2021, at 15:51, Ned Freed wrote: > >>> Trace information documents actions taken on the message by MSAs, >>> MTAs and >>> MDAs. It is provided by an extensible set of header fields. > >> I think something along those lines is probably safe to put in xx22. > > Can you please advise where to add this text in xx22? (I am not yet > convinced that adding this to xx22 is the best course of action, but > happy to be proven wrong.) Here's a shot at the entire set of changes for 3.6.7. (Remember that the way xx22 is structured, you get a syntactic description, then the ABNF, and finally a semantic description.) The trace fields are a group of header fields consisting of an optional "Return-Path:" field, and one or more "Received:" fields or other fields (indicated by "optional-field" below) that are defined by other specifications as belonging within the trace fields grouping. The "Return-Path:" header field contains a pair of angle brackets that enclose an optional addr-spec. The "Received:" field contains a (possibly empty) list of tokens followed by a semicolon and a date- time specification. Each token must be a word, angle-addr, addr- spec, or a domain. Further restrictions are applied to the syntax of the trace fields by specifications that provide for their use, such as [I-D.klensin-rfc5321bis]. trace = [return] 1*(received / optional-field) return = "Return-Path:" path CRLF path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) received = "Received:" [1*received-token / CFWS] ";" date-time CRLF received-token = word / angle-addr / addr-spec / domain The trace fields document actions taken as a message moves through the transport system. A full discussion of the Internet mail use of the "Return-Path:" and "Received:" trace fields is contained in [I-D.klensin-rfc5321bis]; other specifications describe the use of other fields that are to be interpreted as trace fields. For the purposes of this specification, the trace fields are strictly informational, and any formal interpretation of them is outside of the scope of this document. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Feb 23 10:14: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 A830A3A0D2D for ; Tue, 23 Feb 2021 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 rAez90AYB-lq for ; Tue, 23 Feb 2021 10:14:15 -0800 (PST) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275D53A0D2A for ; Tue, 23 Feb 2021 10:14:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 46E571940F86; Tue, 23 Feb 2021 13:14:14 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 13:14:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=ntpr1y JIG4A0/pgDDuGNmgZ0E1DQf46vLnfETQN1R4E=; b=QM0qecpTppl9rjDkE8QHkl rHb9+GMyDmYsvyAyWs8mSqP8ei/1VlZ2eq5bUQZsZbTLOmnUw5y4oD1A3Dxi1bXs N73uqzeMgTMpNt2YdKNflGSy4mWFUiqEt8iWc/PIIF3lXzS8rc5sl+NizQHyVEE6 RUbYSTX7akUzU8zPMid+avtmW4ceuFujgC7kE+4uRwDoZpznY2iQZoStLT6kb12A aPdkiQ6RGo3TkiFIpEE4kJMdh7H7PKo7X++mw677F7tsxbBZ6iew3GFPCuam8zuC ihKj6aI+j0GFlXf9zybJpIZ3BkmTLrKyX6Zjc6sY0XIALEmafYvsodGELrFouXgg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpedtveettdetgeegudfgjeethfegffelhfdu ieeutddufffhgeelffejffefhfekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 37F236B4005F; Tue, 23 Feb 2021 13:14:13 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <7943b8f1-568e-48dc-8c01-72a837777ce6@www.fastmail.com> In-Reply-To: References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> <00fcca77-4aa9-4662-9aaa-e85f3888a744@www.fastmail.com> Date: Tue, 23 Feb 2021 18:13:52 +0000 From: "Alexey Melnikov" To: "Pete Resnick" Cc: emailcore@ietf.org, "Ned Freed" Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 18:14:17 -0000 On Tue, Feb 23, 2021, at 6:05 PM, Pete Resnick wrote: > On 23 Feb 2021, at 11:44, Alexey Melnikov wrote: > > > On Tue, Feb 23, 2021, at 5:29 PM, Pete Resnick wrote: > >> On 22 Feb 2021, at 15:51, Ned Freed wrote: > > > >>> Trace information documents actions taken on the message by MSAs, > >>> MTAs and > >>> MDAs. It is provided by an extensible set of header fields. > > > >> I think something along those lines is probably safe to put in xx22. > > > > Can you please advise where to add this text in xx22? (I am not yet > > convinced that adding this to xx22 is the best course of action, but > > happy to be proven wrong.) > > Here's a shot at the entire set of changes for 3.6.7. (Remember that the > way xx22 is structured, you get a syntactic description, then the ABNF, > and finally a semantic description.) > > The trace fields are a group of header fields consisting of an > optional > "Return-Path:" field, and one or more "Received:" fields or other > fields > (indicated by "optional-field" below) that are defined by other > specifications as belonging within the trace fields grouping. The > "Return-Path:" header field contains a pair of angle brackets that > enclose > an optional addr-spec. The "Received:" field contains a (possibly > empty) > list of tokens followed by a semicolon and a date- time > specification. > Each token must be a word, angle-addr, addr- spec, or a domain. > Further > restrictions are applied to the syntax of the trace fields by > specifications that provide for their use, such as > [I-D.klensin-rfc5321bis]. > > trace = [return] > 1*(received / optional-field) > > return = "Return-Path:" path CRLF > > path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) > > received = "Received:" > [1*received-token / CFWS] ";" date-time CRLF > > received-token = word / angle-addr / addr-spec / domain > > The trace fields document actions taken as a message moves through > the > transport system. A full discussion of the Internet mail use of the > "Return-Path:" and "Received:" trace fields is contained in > [I-D.klensin-rfc5321bis]; other specifications describe the use of > other > fields that are to be interpreted as trace fields. For the purposes > of > this specification, the trace fields are strictly informational, and > any > formal interpretation of them is outside of the scope of this > document. Works for me! From nobody Tue Feb 23 10:57: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 7AB053A0E95 for ; Tue, 23 Feb 2021 10:57:17 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=pnbm9aNZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=bZK6MLkP 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 AdTUTUr4i_8G for ; Tue, 23 Feb 2021 10:57:15 -0800 (PST) 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 594F33A0E94 for ; Tue, 23 Feb 2021 10:57:15 -0800 (PST) Received: (qmail 89847 invoked from network); 23 Feb 2021 18:57:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=15ef5.6035500a.k2102; bh=2Yymy801Oe92eJhzyq1cY7h19BNQm159k9uEas8VoGg=; b=pnbm9aNZQCaE6J8qSL3dNDurNcPHoG5nvu5e7Zj/TUU6W2/ZOYZwQsK0WNjD8JjmIPriQTAdzfssUwjkSl5ZHhv1fj2+4t17Ms+hvSAeVtTTqnI5JspkLLCIWneWowoHTId9IKT+cyzDI5W52xiVsbfjzBDKFoO9j4c8FvTiTHr3LNQ3XzinW0Bt65khH7xFY0j8d4nE8rH7m812onzU/KF7PMBHTkdVUX0mVLiGx/No97OMj+Hwir7pGVRnhj+88t/QDd2wz4Ia7BHhQk3mIhRuJKULxWx2jqC6puUYUG5xTq7aXzFQUP8Yn3SJVRWNcq7OwRL3mLob0jQg/vnrBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=15ef5.6035500a.k2102; bh=2Yymy801Oe92eJhzyq1cY7h19BNQm159k9uEas8VoGg=; b=bZK6MLkP7AN0pVb3LOzNgLpKlqJlkdFJ8vvSC8krAlYxFeGCKDTTiqot0krQzWiN2FvapfD2og4uk5CKbjM0tX5BMCXZN+dk68pCgxu/QPEqD8GWnWzcYkMcGMMmjMgPHoAkTtR5k8INNMHjvL0ZXPIHcqYiqhgYoghVb2VSSy/divuNQs/a2xKgWGkOY78ZWmMk51fCf9R2ALXYqfdYSJxD6U+rcUaGptYWrTk5a8vJj3Yzze2hhJjfD7hObJWHI5x/6C0YvdCtmlGmbDFStAcpSlsZ3apGBRFdG4JQo021rQiOL54yT3GHe13ldJJmdqCzTkuNcpY10+CkCDaKwg== 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; 23 Feb 2021 18:57:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 5C4F46E954DA; Tue, 23 Feb 2021 13:57:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id B9A896E954BC; Tue, 23 Feb 2021 13:57:12 -0500 (EST) Date: 23 Feb 2021 13:57:12 -0500 Message-ID: <85bd6990-ac75-1d95-873a-cf6d3298da80@taugh.com> From: "John R Levine" To: "Pete Resnick" , "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 18:57:18 -0000 On Tue, 23 Feb 2021, Pete Resnick wrote: >> FWIW, I strongly prefer new fields to messing around with Received:. Yes, I'm >> aware that this means that some agents may require an update to their list of >> fields, but IMO messing around with Received: parsing is a bigger problem. > > I'm not sure I understand this last comment. There is no suggestion to mess > around with Received:. The proposal is to move optional-field into the > definition of trace in 3.6.7 rather than have it in the overall fields syntax > at the top of 3.6. Did I miss something? I'm not Ned but if I were, I would probably have meant that when we want to add new trace info, we should add new header fields rather than adding new clauses to received headers. For example, here's the Received line on the message I'm replying to, which shoehorns port numbers and TLS into the Received header in ways that are OK in 5322 but not 5321. Received: from episteme.net (episteme.net [216.169.5.102]) by mail1.iecc.com ([64.57.183.56]) with ESMTPS via TCP (port 38756/25) id 670930065 tls TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD; 23 Feb 2021 17:29:19 -0000 It is my impression that MTAs other than ones from Redmond WA currently comply pretty well with 5321, give or take shoehorning like the above. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Feb 23 10:58:55 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 461F03A0D76 for ; Tue, 23 Feb 2021 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 0kCBZeion2oB for ; Tue, 23 Feb 2021 10:58:51 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801123A0EA1 for ; Tue, 23 Feb 2021 10:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1614106728; bh=ZM44cKYJBg5QZQOIoNjCUvMwDOBhkuGZoI8yzz/0ZzY=; l=5073; h=To:References:From:Date:In-Reply-To; b=CB1tU1o/+ZmU7mIMwkd44hCQ1iwGjSXGSNF6hUYtBW0E9pTjn0UrDgiVlJI6I4Rn6 aX3UEy8IZQEcKULxznw8D9I2DoAPmWWxrEgZnBQnT8Gp75/1btB/CIVMvwcn202Z/k LlnadfatNz8wgE5z7XAlqh/Hf3pGH2L20z+s0dOxurvQ/mkv00qgX6k21gcNy Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.0000000060355068.000002C1; Tue, 23 Feb 2021 19:58:48 +0100 To: Pete Resnick , emailcore@ietf.org References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> From: Alessandro Vesely Message-ID: <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> Date: Tue, 23 Feb 2021 19:58:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 18:58:53 -0000 On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote: > On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: >> On Mon 22/Feb/2021 22:32:08 +0100 Pete Resnick wrote: >>> Combining some answers to John L. and Alexey regarding the 5322bis chagnes... >>> [...] >>>>> Again, I think ABNF needs to be clear that other header fields can >>>>> appear in between Return-Path and Received, for example: >>>>> >>>>>    trace           =   [return] >>>>>                        *trace-extension-field >>>>>                        1*received >>>>> >>>>>   trace-extension-field = optional-field >>>> >>>> Wouldn't that mean that the extension fields are all above the received? >>>> How about this: >>>> >>>>     trace           =   [return] >>>>                         1*(received / trace-extension-field) >>> >>> Yes, and if I do that, I'll remove the extra optional-field at the top of >>> the overall fields syntax in 3.6. >> >> That ABNF seems to imply there must be at least one Received:.  Why then does >> the table in Section 3.6 show a Min number of 0 trace? > > Because the entire trace block is optional according to the ABNF right above > that table in 3.6. Ugh, that way you cannot have a lone Return-Path:? >> I agree with Peter's worries about mandating the initial block.  The >> optional-field allowed more leeway, as the optional field could happen to be >> whatever, not necessarily a trace field.  Indeed, the requirement to collect >> all trace fields at the top of the header lest the message be syntactically >> bad is a recipe for trouble. > > But optional-field is permitted at the bottom of the ABNF of fields in 3.6, > which would allow it to be used for something that is not a trace field. (That > is, optional-field appears twice in the 3.6 syntax.) optional-field is a poor choice, as it is restricted to header fields not specified in the I-D. That includes fields specified in other RFCs as well as unspecified fields. Consider RFC 5293, where the *addheader* Sieve action is described like so: By default, the header field is inserted at the beginning of the existing message header. If the optional flag ":last" is specified, it is appended at the end. >> The practice to collect trace fields at the top comes from the fact that it >> is convenient to write down one's 2 cents and then copy the rest without even >> parsing it.  But a mail filter can add a header field holding information >> that semantically does not make it a trace field.  Even then, it is more >> natural to write added fields near the top of the header.  Doing so is also >> better for debugging and forensic analysis, as it is possible to deduce at >> what stage a given field was added. >> >> For example, consider a DKIM filter which tries and reverts a mailing list's >> From: munging.  It records its findings in a trace field, >> Authentication-Results:.  In addition, if the reversion succeeds, it adds an >> Original-From: field, formatted like From:.  Semantically equivalent to >> From:, and eventually swappable with it, the latter is definitely not a trace >> field. Should it be added downward, possibly near to the real From:, or isn't >> it more self-explanatory to add it near the corresponding >> Authentication-Results:? >> >> Could we relax the header syntax?  For example: >> >>     trace     = [return] >>                 *top-field >> >>     top-field = received / >>                 trace-extension-field / >>                 prowl-field >> >> Where prowl-field can actually be any field, possibly resulting from Sieve or >> any other email filtering.  That syntax still conveys that trace fields tend >> to gather near the top of the header, but doesn't require a strict order. > > Review the ABNF at the top of 3.6 and see if you can't express what you want > to. Otherwise, I think things are best left alone except for moving the first > occurrence of optional-field out of 3.6 and putting an optional-field (or > trace-extension-field) into 3.6.7. You're right, I mismatched trace with top. I gather we want to define trace by its semantics and convey that it inhabits the top of the header, but not exclusively. Yet, the term optional-field excludes orig-date, from, and the like, which might happen to be thrown there by filter actions. Perhaps the grammar could be expressed something like the following: fields = *(trace *resent-field / prowl-field) *(elemental-field / optional-field) resent-field = resent-date / resent-from / resent-sender / resent-to / resent-cc / resent-bcc / resent-msg-id elemental-field = orig-date / from / sender / reply-to / to / cc / bcc / message-id / in-reply-to / references / subject / comments / keywords prowl-field = elemental-field / optional-field Best Ale -- From nobody Tue Feb 23 12:10:41 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 80C843A08B0 for ; Tue, 23 Feb 2021 12:10:39 -0800 (PST) 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=valimail.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 K6ulWgGMXplZ for ; Tue, 23 Feb 2021 12:10:37 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 7DB7F3A089C for ; Tue, 23 Feb 2021 12:10:37 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id f17so12856174qth.7 for ; Tue, 23 Feb 2021 12:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=0jmlNm/2J+bwxWap5wUuRt7Rp+ajN2J9tXdiAEeqHJ8=; b=RexW6LCHDzhfBiTqE1GuFDgvHR0ViGGE/w2BohqGzmqYB7EgSQPe6YHDfnC5LOGXrH 9Xj4jsNKgQ+4TLZCy+kQ3zSztEybAHlNYrCpxBgagT/nXnx/msZy5J+ZOU83Hm4L5cvx yOTjpZhzpeCGSapizyZw5iBMg9Toj7aftMhUVGsq1RjcOp21oMEKKJGNULZP0wOTVkjE vJVCas99+y7sq1/NusYUt8NPK3eai0OmEbumh46P7uOBWvN55fGt4YPGgNHtC991IChr Ac/cwIRYfl9nNTxaUymUxAhu6jg2+yRkTOWAd4vel9cvQCBV8SUYEZYbsIezrlzl2Wba Gcvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0jmlNm/2J+bwxWap5wUuRt7Rp+ajN2J9tXdiAEeqHJ8=; b=NqJ6H1Kcv6j/f3LK7LSfyHWGHXoy0iaOURZzlgtq2w33bGo/CQbOu8Dv9dZapAZIs6 WvT7nPgMGRKR5EcZUNoaTqwn/W0bOntUqpMwf0LdEfN6npiotgclfRoy0QQpIruxpqwH B12iyfULfYaF6kF8PhTQWFef/YzWLxAnE9WbXOhI5ho2ly/3PLRGPfndhJ4AYzv2j4qo yqVWJJt83BP6WOy3KgXKuPVjfEHQQ9W0V5y9LoPdUYz6rtVzn8rW53Q9shfTAeZamqyt fYDuDIn9vMYQlED4d41nbkGTljqpnFY25Slj37DFPt0anbPxdtC+2Y6TPlWFS0BSsh++ iIiA== X-Gm-Message-State: AOAM531t/3whW6t2wIktD+pVeMErnETE899JgWWhSr3FPAuN24Fuqm4S N+Q9vrkr4c5WRQfQBBq6dsC8a1BZ3kyRlazNtHJF8NrXAAXEyQ== X-Google-Smtp-Source: ABdhPJyIFLFbcvrWMRGT9LbnBG4iICtp6ODRhIRvV1vgij/b41Hggi27lDe98SbLM71sohd1Ra20aASmabal3fapNgc= X-Received: by 2002:aed:39c8:: with SMTP id m66mr9146309qte.298.1614111036069; Tue, 23 Feb 2021 12:10:36 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Tue, 23 Feb 2021 15:10:20 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000eeef9505bc068221" Archived-At: Subject: [Emailcore] Ticket #16: G.7.12. Review Timeout Specifications 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, 23 Feb 2021 20:10:40 -0000 --000000000000eeef9505bc068221 Content-Type: text/plain; charset="UTF-8" Greetings. Seeking to begin discussion of the subject ticket. Alexey originally opened the ticket with the following text: RFC 5321 (and its predecessors going back to 821) specify minimum periods for client and server to wait before timing out. Are those intervals still appropriate in a world of faster processors and faster networks? Should they be updated and revised? Or should more qualifying language be added? There is a comment already in the ticket attributed to Hector: On a related note (maybe another issue?), only a few mailers sit after an DATA transaction holding the socket until something else comes in to start a new transaction. We had this discussion before, many years ago, and I decided to knock them out with a shorter timeout (PostDataTimeoutSecs? =35 secs) after a DATA transaction because they were taking up resources setting there doing nothing for an extended time. In other words, we discussed the Timeout values and they are fine, but I felt the 5 mins was too long after the DATA transaction when certain mailers sit there and not send anything. I believe this is a permission concept to allow a client to just hold a server session, socket, process, resources, etc. When there are incoming loads limits, it doesn't help to have one client to hold a line. Section 4.5.3.2 in 5321 currently contains this text as introduction to the sub-sections specifying each recommendation: Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows: Hatless, I am in the camp that believes that it's certainly worth asking those with current extensive experience with busy mail-relay hosts for their input on the matter, and so I'll see if I can't get them to join in the discussion. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* ` This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000eeef9505bc068221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

Seeking to begin di= scussion of the subject ticket.

Alexey originall= y opened the ticket with the following text:

RFC 5321=C2=A0(and its predecessors going back to 821) specif= y minimum periods for client and server to wait before timing out. Are thos= e intervals still appropriate in a world of faster processors and faster ne= tworks? Should they be updated and revised? Or should more qualifying langu= age be added?

There is a comment already in the t= icket attributed to Hector:

On a related no= te (maybe another issue?), only a few mailers sit after
=
an = DATA transaction holding the socket until something else comes in
to start a new transaction. We had this discussion before, many year= s
ago, and I decided to knock them out with a shorter timeo= ut
(PostDataTimeoutSecs?=3D35 secs) after a DATA transaction because they<= /div>
time. In other words, we discussed the Timeout values and they = are
fine, but I felt the 5 mins was too long after the DATA= transaction
when certain mailers sit there and not send an= ything. I believe this
is a permission concept to allow a c= lient to just hold a server
session, socket, process, resou= rces, etc. When there are incoming
loads limits, it doesn't help to have one cl= ient to hold a line.=

=
Section 4.5.3.2 in 5321 currently contains this text as introduct= ion to the sub-sections specifying each recommendation:

Based on extensive experience with busy mail-relay hosts, the minimum<= span class=3D"gmail_default" style=3D""> per-command timeout values SHOULD be as follows:=

Hatless, I am in the camp that believes = that it's certainly worth asking those with current extensive experienc= e with busy mail-relay hosts for their input on the matter, and so I'll= see if I can't get them to join in the discussion.

= --

Todd Herr | Sr. Technical Program Mana= ger
p:

`

This email and all data transmit= ted with it contains confidential and/or proprietary information intended s= olely for the use of individual(s) authorized to receive it. If you are not= an intended and authorized recipient you are hereby notified of any use, d= isclosure, copying or distribution of the information included in this tran= smission is prohibited and may be unlawful. Please immediately notify the s= ender by replying to this email and then delete it from your system.=

--000000000000eeef9505bc068221-- From nobody Tue Feb 23 12:41:57 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 9BE893A0B55 for ; Tue, 23 Feb 2021 12:41:54 -0800 (PST) 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 mLCijOrFUJFZ for ; Tue, 23 Feb 2021 12:41:50 -0800 (PST) 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 456943A0B58 for ; Tue, 23 Feb 2021 12:41:50 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RVX68Y80VK00EVMM@mauve.mrochek.com> for emailcore@ietf.org; Tue, 23 Feb 2021 12:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1614112605; bh=FEL0Vzg0edM+niT8IeIY6c7QxhpfVOax0h3oTXLPd0A=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=MMPvp0Rpm5Jp7ZTPsyqrt0RtHXTnV1M4IJSP7KLrmiWRLOBW1m0jqgXJBHiQTcMYz KuJLr1ETt5NuH82poVZGCIZbipjOWfX0uTPRPuT3w+BT4VLJUH4c75oubiBrLmUAWn KlhEzbULia1UywqkFjexuj+fnMbBo+eKpkYqgqvI= 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 <01RVQNM60R7K005PTU@mauve.mrochek.com>; Tue, 23 Feb 2021 12:36:39 -0800 (PST) Cc: Pete Resnick , Ned Freed , emailcore@ietf.org Message-id: <01RVX68TWESW005PTU@mauve.mrochek.com> Date: Tue, 23 Feb 2021 12:08:18 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 23 Feb 2021 13:57:12 -0500" <85bd6990-ac75-1d95-873a-cf6d3298da80@taugh.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> <85bd6990-ac75-1d95-873a-cf6d3298da80@taugh.com> To: John R Levine Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 20:41:55 -0000 > On Tue, 23 Feb 2021, Pete Resnick wrote: > >> FWIW, I strongly prefer new fields to messing around with Received:. Yes, I'm > >> aware that this means that some agents may require an update to their list of > >> fields, but IMO messing around with Received: parsing is a bigger problem. > > > > I'm not sure I understand this last comment. There is no suggestion to mess > > around with Received:. The proposal is to move optional-field into the > > definition of trace in 3.6.7 rather than have it in the overall fields syntax > > at the top of 3.6. Did I miss something? > I'm not Ned but if I were, Be happy you're not ;-) ;-) > I would probably have meant that when we want > to add new trace info, we should add new header fields rather than adding > new clauses to received headers. Exactly what I meant. Sorry for being unclear. > For example, here's the Received line on > the message I'm replying to, which shoehorns port numbers and TLS > into the Received header in ways that are OK in 5322 but not 5321. > Received: from episteme.net (episteme.net [216.169.5.102]) > by mail1.iecc.com ([64.57.183.56]) > with ESMTPS via TCP (port 38756/25) id 670930065 > tls TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD; 23 Feb 2021 17:29:19 -0000 Maybe I'm reading it wrong, but there may be another problem here... The TLS clause falls under the Additional-Registered-Clauses syntax in 5321: Additional-Registered-Clauses = CFWS Atom FWS String Which leads us to: String = Atom / Quoted-string Atom = 1*atext And atext don't include period. Which means TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD should be quoted, and that takes you into interesting territory... Not sure I've ever seen a quoted clause parameter in a Received: field in the wild. RFC 5322, on the other hand, has: received = "Received:" *received-token ";" date-time CRLF received-token = word / angle-addr / addr-spec / domain And this takes us to (since word, like String, won't work): domain = dot-atom / domain-literal / obs-domain dot-atom-text = 1*atext *("." 1*atext) Which works syntactically, although TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD is a pretty strange domain name... > It is my impression that MTAs other than ones from Redmond WA currently > comply pretty well with 5321, give or take shoehorning like the above. I think that's to some extent because people don't push the boundaries too much. When you it's pretty easy to get lost in the syntax. Ned From nobody Tue Feb 23 12:49:26 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 28F9D3A03C9 for ; Tue, 23 Feb 2021 12:49:24 -0800 (PST) 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 (2048-bit key) header.d=iecc.com header.b=Ne5zlcMV; dkim=pass (2048-bit key) header.d=taugh.com header.b=C8Sll+d1 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 0KVSBIVv-Qnm for ; Tue, 23 Feb 2021 12:49:22 -0800 (PST) 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 F0E533A0121 for ; Tue, 23 Feb 2021 12:48:51 -0800 (PST) Received: (qmail 15360 invoked from network); 23 Feb 2021 20:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3bfe.60356a31.k2102; bh=qW3JJbzosab8xSrqkNt5c9e8T0ygDJIUYfWytE0PjyQ=; b=Ne5zlcMVSjDZaNqyZwrREWuxg1NRAk/U8lg9EZruU62/YqySFqQ1DecC8RYZS8WISijSpmDNIMQeiQ6CmzXmB1AOMASe8d9A7JgcQNk0FP7YTEWBh+6jtsiYyj9d7tIkKzgZUgPNpr5OCSC40sCu8AT0/3qSQWscPE6rGq/aFQe+V1sMlRakqlcciVfwxCX1KUMtsWdrdU3WTCtkvujSL0gNcijpbXRhR8EHprN1RXlmXSCrnZeF7KqvfDgzsHbisfvAZyTgnwISsfdfo5tx1294XFcBws08jNmjHu3EZ6+cssVo3ICHD8jAVhquEa0QIWA5o3RoWtrpDw2YpEEnPQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3bfe.60356a31.k2102; bh=qW3JJbzosab8xSrqkNt5c9e8T0ygDJIUYfWytE0PjyQ=; b=C8Sll+d1ch+tl3ZXjE5ZhOkyJ0dK+ODB6RTEbUrr9c5HDWnQXggIACjawqL8rImyrTcqHQFQvPswNARVHXhOkvXHo+BEex7FAfpfwit11XmLF+mvoSaJVKIh2grqlOUfy96BrP9c03jhwBBZpIViSdZsG9NJIOKYu9/K8k2dvGiB8T+UPmEsJvHMVYDRXcwgZBsH7XOFZIHCaNRF1H/j56rno6INte9ClUxXoTvfJp9gSGlEqEYXhH4ra3S9qpEKL3/JAv3+07r2vHW+3/tKjMXeiTwE+6/WWOPx7swmHRGh5R2uJqrCXYv20uaEmTtGck0Tzlv4lzfiaeAfAY3bMA== 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; 23 Feb 2021 20:48:49 -0000 Received: by ary.qy (Postfix, from userid 501) id D12916E97929; Tue, 23 Feb 2021 15:48:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 885156E9790B; Tue, 23 Feb 2021 15:48:48 -0500 (EST) Date: 23 Feb 2021 15:48:48 -0500 Message-ID: <594414b9-92e1-b353-b97a-db5ba5d35d17@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <01RVX68TWESW005PTU@mauve.mrochek.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> <85bd6990-ac75-1d95-873a-cf6d3298da80@taugh.com> <01RVX68TWESW005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 20:49:24 -0000 On Tue, 23 Feb 2021, Ned Freed wrote: > > Maybe I'm reading it wrong, but there may be another problem here... > The TLS clause falls under the Additional-Registered-Clauses syntax > in 5321: > > Additional-Registered-Clauses = CFWS Atom FWS String > > Which leads us to: > > String = Atom / Quoted-string > Atom = 1*atext > > And atext don't include period. Which means TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD > should be quoted, and that takes you into interesting territory... Not sure > I've ever seen a quoted clause parameter in a Received: field in the wild. You're right, it hadn't occurred to me that the string might contain a dot. I have code that turns forbidden characters in the TLS string to underscores so it does that to dots now, too. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Feb 23 13:14:03 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 33AB73A0BDC for ; Tue, 23 Feb 2021 13:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 qIW8LaQEZviK for ; Tue, 23 Feb 2021 13:13:59 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4B03A0BD7 for ; Tue, 23 Feb 2021 13:13:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 375D2D79378B; Tue, 23 Feb 2021 15:13:58 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps7Hk4RUtwYX; Tue, 23 Feb 2021 15:13:57 -0600 (CST) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 1B193D79377E; Tue, 23 Feb 2021 15:13:57 -0600 (CST) From: Pete Resnick To: Alessandro Vesely Cc: emailcore@ietf.org Date: Tue, 23 Feb 2021 15:13:56 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_16C1A426-2F34-4577-AF67-FCC571354748_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 21:14:01 -0000 --=_MailMate_16C1A426-2F34-4577-AF67-FCC571354748_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: > On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote: > >> On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: >> >>> That ABNF seems to imply there must be at least one Received:.  Why >>> then does the table in Section 3.6 show a Min number of 0 trace? >> >> Because the entire trace block is optional according to the ABNF >> right above that table in 3.6. > > Ugh, that way you cannot have a lone Return-Path:? No. Is there a reason to ever have one? >> But optional-field is permitted at the bottom of the ABNF of fields >> in 3.6, which would allow it to be used for something that is not a >> trace field. (That is, optional-field appears twice in the 3.6 >> syntax.) > > optional-field is a poor choice, as it is restricted to header fields > not specified in the I-D. That includes fields specified in other > RFCs as well as unspecified fields. > > Consider RFC 5293, where the *addheader* Sieve action is described > like so: > > By default, the header field is inserted at the beginning of the > existing message header. If the optional flag ":last" is > specified, > it is appended at the end. So you're saying that you want it to be syntactically OK (that is, in the ABNF) to add one of the non-trace fields at the top of the message? There's already a discussion of this at the beginning of 3.6 saying, "It is important to note that the header fields are not guaranteed to be in a particular order." I'd really rather not change the syntax any more that strictly necessary. >>> The practice to collect trace fields at the top comes from the fact >>> that it is convenient to write down one's 2 cents and then copy the >>> rest without even parsing it. Indeed, not just convenient, but that it's often been damaging to go mucking around in the contents of the message. 5321 talks about this. >>> But a mail filter can add a header field holding information that >>> semantically does not make it a trace field.  Even then, it is more >>> natural to write added fields near the top of the header.  Doing so >>> is also better for debugging and forensic analysis, as it is >>> possible to deduce at what stage a given field was added. I'd like to see more examples, because rewriting From: and inserting Original-From: seems more like the gatewaying function that 5321 talks about. >> Review the ABNF at the top of 3.6 and see if you can't express what >> you want to. Otherwise, I think things are best left alone except for >> moving the first occurrence of optional-field out of 3.6 and putting >> an optional-field (or trace-extension-field) into 3.6.7. > > > You're right, I mismatched trace with top. I gather we want to define > trace by its semantics and convey that it inhabits the top of the > header, but not exclusively. I think the "not exclusively" is the part that there is controversy about. > Yet, the term optional-field excludes orig-date, from, and the like, > which might happen to be thrown there by filter actions. Are these filter actions part of submission or delivery? I'm not sure there's any need to update the syntax to allow for those at the top of the message. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_16C1A426-2F34-4577-AF67-FCC571354748_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 23 Feb 2021, at 12:58, Alessandro Vesely wrote:

On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote:

=

On 23 Feb 2021, at 5:39, Alessandro Vesely wrote:

That ABNF seems to imply there must be at least one Recei= ved:.=C2=A0 Why then does the table in Section 3.6 show a Min number of 0= trace?

Because the entire trace block is optional according to t= he ABNF right above that table in 3.6.

Ugh, that way you cannot have a lone Return-Path:?

No. Is there a reason to ever have one?

But optional-field is permitted at the bottom of the ABNF= of fields in 3.6, which would allow it to be used for something that is = not a trace field. (That is, optional-field appears twice in the 3.6 synt= ax.)

optional-field is a poor choice, as it is restricted to h= eader fields not specified in the I-D. That includes fields specified in= other RFCs as well as unspecified fields.

Consider RFC 5293, where the addheader Sieve act= ion is described like so:

By default, the header field is inserted at the beginning= of the
existing message header. If the optional flag ":last" is specified,
it is appended at the end.

So you're saying that you want it to be syntactically OK = (that is, in the ABNF) to add one of the non-trace fields at the top of t= he message? There's already a discussion of this at the beginning of 3.6 = saying, "It is important to note that the header fields are not guarantee= d to be in a particular order." I'd really rather not change the syntax a= ny more that strictly necessary.

The practice to collect trace fields at the top comes fro= m the fact that it is convenient to write down one's 2 cents and then cop= y the rest without even parsing it.

Indeed, not just convenient, but that it's often been dam= aging to go mucking around in the contents of the message. 5321 talks abo= ut this.

But a mail filter can add a header field holding informat= ion that semantically does not make it a trace field.=C2=A0 Even then, it= is more natural to write added fields near the top of the header.=C2=A0 = Doing so is also better for debugging and forensic analysis, as it is pos= sible to deduce at what stage a given field was added.

I'd like to see more examples, because rewriting From: an= d inserting Original-From: seems more like the gatewaying function that 5= 321 talks about.

Review the ABNF at the top of 3.6 and see if you can't ex= press what you want to. Otherwise, I think things are best left alone exc= ept for moving the first occurrence of optional-field out of 3.6 and putt= ing an optional-field (or trace-extension-field) into 3.6.7.

You're right, I mismatched trace with top. I gather we w= ant to define trace by its semantics and convey that it inhabits the top = of the header, but not exclusively.

I think the "not exclusively" is the part that there is c= ontroversy about.

Yet, the term optional-field excludes orig-date, from, an= d the like, which might happen to be thrown there by filter actions.

Are these filter actions part of submission or delivery? = I'm not sure there's any need to update the syntax to allow for those at = the top of the message.

pr

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_16C1A426-2F34-4577-AF67-FCC571354748_=-- From nobody Tue Feb 23 14:36:47 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 E2B0B3A0E50 for ; Tue, 23 Feb 2021 14:36:39 -0800 (PST) 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 L69x6UNV9faz for ; Tue, 23 Feb 2021 14:36:38 -0800 (PST) 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 C0EDF3A0E09 for ; Tue, 23 Feb 2021 14:36:38 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RVXA9BS9K000DIG0@mauve.mrochek.com> for emailcore@ietf.org; Tue, 23 Feb 2021 14:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1614119495; bh=INMdB8PZEK74bflcZcQklLxIsruMP0Q7I6sVMrZK+Q8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=qklSxoKkv/3Pqi2szlOfL9nJ7u6ZSlFyBl61LUKwfFGmhKupRxyFbzLjXhQiLCR/Z UXrKxK84Vms8s0uXmP26MYSigqk7RZ78Sk6HC9dzggo8xb6hsWNZqW2kshmye3M9Db r1Jxd/1rLZmLENOLOkIvjkaOq51TqRaV72Klg92A= 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 <01RVQNM60R7K005PTU@mauve.mrochek.com>; Tue, 23 Feb 2021 14:31:32 -0800 (PST) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RVXA998Q1S005PTU@mauve.mrochek.com> Date: Tue, 23 Feb 2021 14:31:02 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 23 Feb 2021 15:48:48 -0500" <594414b9-92e1-b353-b97a-db5ba5d35d17@taugh.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <01RVVY2FPQZ8005PTU@mauve.mrochek.com> <9702C863-735E-49B4-8904-1DD7B3F6A544@episteme.net> <85bd6990-ac75-1d95-873a-cf6d3298da80@taugh.com> <01RVX68TWESW005PTU@mauve.mrochek.com> <594414b9-92e1-b353-b97a-db5ba5d35d17@taugh.com> To: John R Levine Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 23 Feb 2021 22:36:45 -0000 > On Tue, 23 Feb 2021, Ned Freed wrote: > > > > Maybe I'm reading it wrong, but there may be another problem here... > > The TLS clause falls under the Additional-Registered-Clauses syntax > > in 5321: > > > > Additional-Registered-Clauses = CFWS Atom FWS String > > > > Which leads us to: > > > > String = Atom / Quoted-string > > Atom = 1*atext > > > > And atext don't include period. Which means TLS1.2_ECDHE_RSA_AES_256_GCM_AEAD > > should be quoted, and that takes you into interesting territory... Not sure > > I've ever seen a quoted clause parameter in a Received: field in the wild. > You're right, it hadn't occurred to me that the string might contain a > dot. I have code that turns forbidden characters in the TLS string to > underscores so it does that to dots now, too. is-atext-char-p is your friend. Ned From nobody Wed Feb 24 04:09:57 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 76A573A14F7 for ; Wed, 24 Feb 2021 04:09:50 -0800 (PST) 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 0Yioe4U62F1K for ; Wed, 24 Feb 2021 04:09:48 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC85E3A14CB for ; Wed, 24 Feb 2021 04:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1614168583; bh=5oYQyE1XG0jrIzIaUZYwlZ5ksSYp1nDv5b9CMjh/MGI=; l=4716; h=To:References:From:Date:In-Reply-To; b=AMep+nqjhVCtsb2zQgxjW/NDQVH24R3H+I8lGGfDbObf8yqdgnjyMuEZBIpBJ+mK6 7EXATHBB6O7go/pFJ4xS1TBPvWiMoTZl8Q+nmkNLjouYIolkyHUsfB1NgJsg1q+nLG z+sIHGBUPxXFF+loBQ/+b4anehb3BYo8RrtTGHA0zNRfXvKJGpN3XRacyxhSS Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0E1.0000000060364207.000024B7; Wed, 24 Feb 2021 13:09:43 +0100 To: Pete Resnick , emailcore@ietf.org References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> From: Alessandro Vesely Message-ID: <657e6552-ea4b-41da-ab72-b1b4c9d834a8@tana.it> Date: Wed, 24 Feb 2021 13:09:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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: Wed, 24 Feb 2021 12:09:57 -0000 On Tue 23/Feb/2021 22:13:56 +0100 Pete Resnick wrote: > On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: >> On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote: >>> On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: >>> >>>> That ABNF seems to imply there must be at least one Received:.  Why then >>>> does the table in Section 3.6 show a Min number of 0 trace? >>> >>> Because the entire trace block is optional according to the ABNF right above >>> that table in 3.6. >> >> Ugh, that way you cannot have a lone Return-Path:? > > No. Is there a reason to ever have one? You mean if there's a Return-Path then the message must have been Received? Hmm... yeah, that makes sense. >>> But optional-field is permitted at the bottom of the ABNF of fields in 3.6, >>> which would allow it to be used for something that is not a trace field. >>> (That is, optional-field appears twice in the 3.6 syntax.) >> >> optional-field is a poor choice, as it is restricted to header fields not >> specified in the I-D.  That includes fields specified in other RFCs as well >> as unspecified fields. >> >> Consider RFC 5293, where the *addheader* Sieve action is described like so: >> >>    By default, the header field is inserted at the beginning of the >>    existing message header.  If the optional flag ":last" is specified, >>    it is appended at the end. > > So you're saying that you want it to be syntactically OK (that is, in the ABNF) > to add one of the non-trace fields at the top of the message? If possible, it wouldn't be bad. > There's already a discussion of this at the beginning of 3.6 saying, "It is > important to note that the header fields are not guaranteed to be in a > particular order." I'd really rather not change the syntax any more that > strictly necessary. The order of fields is all what the external parentheses are about. Dropping the ")*(" in the middle would be a minimal change, byte-wise, wouldn't it? It sounds like something of a nuisance to present a syntax by noting that it is not actual. >>>> But a mail filter can add a header field holding information that >>>> semantically does not make it a trace field.  Even then, it is more natural >>>> to write added fields near the top of the header.  Doing so is also better >>>> for debugging and forensic analysis, as it is possible to deduce at what >>>> stage a given field was added. > > I'd like to see more examples, because rewriting From: and inserting > Original-From: seems more like the gatewaying function that 5321 talks about. I don't think there's a gateway role. Email filters are not firewalls interposed between client and server. They're server extensions, rather on the MDA side of the SMTP server. OTOH, one might consider the DMARC-compliant SMTP transmission from a MLM to a subscriber's MX as a sort of foreign environment that requires From: rewriting. Restoring the original value of From: would then resume the previous state of affairs, just before delivery. >>> Review the ABNF at the top of 3.6 and see if you can't express what you want >>> to. Otherwise, I think things are best left alone except for moving the >>> first occurrence of optional-field out of 3.6 and putting an optional-field >>> (or trace-extension-field) into 3.6.7. >> >> You're right, I mismatched trace with top.  I gather we want to define trace >> by its semantics and convey that it inhabits the top of the header, but not >> exclusively. > > I think the "not exclusively" is the part that there is controversy about. Exactly. >> Yet, the term optional-field excludes orig-date, from, and the like, which >> might happen to be thrown there by filter actions. > > Are these filter actions part of submission or delivery? I'm not sure there's > any need to update the syntax to allow for those at the top of the message. The above From: restoration occurs on delivery, after any possible forwarding. I image most Sieve recipes also apply on or after receiving. Submission filters are different. Albeit they can add signatures or change encoding, in addition to MSA proper actions like setting Message-Id: and Date:, or adding the domain to addresses that miss it, their actions typically respect the correct order and type of header fields. Stored messages can still be moved by gateways à la fetchmail, which may re-inject them via SMTP. Thus, syntax transgressions that occur only after delivery are not bound to remain confined in a given mailbox. Is it worth to consider that elemental fields found at the top of the header are likely to be somewhat apocryphal? Best Ale -- From nobody Thu Feb 25 20:06:17 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 9114F3A09BE for ; Thu, 25 Feb 2021 20:06:15 -0800 (PST) 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, 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=isdg.net header.b=E7LidPY/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Ih1sPlRg 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 39EU3hvPn-An for ; Thu, 25 Feb 2021 20:06:12 -0800 (PST) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (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 B04203A09BD for ; Thu, 25 Feb 2021 20:06:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=703; t=1614312363; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=OtcMhZmuoC5rglgL7ISZ0AuN0Kkn n5XZOVRQXvdIqU4=; b=E7LidPY/vndyMpVcEaByjLh4RgsKnuDCOaQyUYMLTZKd awKufFNf2uASGm2W5vJjLD2LMDSc1YGP5SZHDx4U5u/bQGRzFtIh4wZiv6oOpArU LhZ0QvqFfvDxyZj35ZS2AT8iF15m02Z0+O7TeVFZEU9usGMqw+GGk3j9GulR7Tw= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 25 Feb 2021 23:06:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2640546492.1.2412; Thu, 25 Feb 2021 23:06:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=703; t=1614312298; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OtcMhZm uoC5rglgL7ISZ0AuN0Kknn5XZOVRQXvdIqU4=; b=Ih1sPlRgHEDj7XFioDfgDFi 0Hp6LvC410eE20vXjYbZYSwmUB7aH94/PONzRq8/trvfdGhF0VKYxu/FCUHda4i+ QtVz5Wb2pS8bZmW+vidJ4DnW+Jn2/GMA9K09c7y2NmbsGsL8Sf6FR0zDn6sIrW3K mLaBrO0Nd4aY8qdkFRwQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 25 Feb 2021 23:04:58 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3324225815.1.26924; Thu, 25 Feb 2021 23:04:56 -0500 Message-ID: <603873AC.70105@isdg.net> Date: Thu, 25 Feb 2021 23:06:04 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Pete Resnick , Alessandro Vesely CC: emailcore@ietf.org References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 26 Feb 2021 04:06:16 -0000 On 2/23/2021 4:13 PM, Pete Resnick wrote: > > On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: > > Ugh, that way you cannot have a lone Return-Path:? > > No. Is there a reason to ever have one? > Only if the backend wanted to give MUAs SPF power. From UUCP "From " stripping design, the move to SMTP and stripping Return-Path carried on, once final destination was determined. Either the router did it or the gateway. However, it was long felt SPF was best done at the backend. The MUA could repeat the process by reading the SPF trace field "Received-SPF" or "Authentication-Result", if provided. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Feb 28 19:04:04 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 187C73A1377 for ; Sun, 28 Feb 2021 19:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 nxoXnuQ6pyJ4 for ; Sun, 28 Feb 2021 19:04:00 -0800 (PST) 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 CF7A33A137A for ; Sun, 28 Feb 2021 19:04:00 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RW2JPU220000D6T1@mauve.mrochek.com> for emailcore@ietf.org; Sat, 27 Feb 2021 08:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1614445016; bh=JDuOYGHBA1MM6FVrQw0A+Mn676WBzt7P23LWDM5hns4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=bjhRsFWDJDyVkERuZaQO9FDiEuq6sTm50lj8fabbNZqCvKpkRLZ7RTm8hAtnqtSMs F1ShgL/OnwdrDGz2IOqcvNUehRYi4XSuKASWsE9uFcvZsRbMoOT+cSOYXNW9EYyal+ A/Km9ZicO5N8mBPBO5vizUEdmRKLeN3y7qhxoIjo= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed; markup=markdown Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RVQNM60R7K005PTU@mauve.mrochek.com>; Sat, 27 Feb 2021 08:56:54 -0800 (PST) Cc: Alessandro Vesely , emailcore@ietf.org Message-id: <01RW2JPR8LJK005PTU@mauve.mrochek.com> Date: Sat, 27 Feb 2021 08:48:41 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 23 Feb 2021 15:13:56 -0600" References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> To: Pete Resnick Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition 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, 01 Mar 2021 03:04:02 -0000 > On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: > > On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote: > > > >> On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: > >> > >>> That ABNF seems to imply there must be at least one Received:.  Why > >>> then does the table in Section 3.6 show a Min number of 0 trace? > >> > >> Because the entire trace block is optional according to the ABNF > >> right above that table in 3.6. > > > > Ugh, that way you cannot have a lone Return-Path:? > No. Is there a reason to ever have one? I can think of at least two: (1) IMAP APPEND of a (possibly draft) message (thus no Received: fields) where you want to say what the MAIL FROM was/is/should be. (2) Message has had all Received: fields removed for security reasons. (And please don't bother telling me this is a bad idea, because you'd be barking up the wrong tree. A large number of security reviewers say otherwise, and when the choice is between no Received: fields and no deployment, guess what wins.) > >> But optional-field is permitted at the bottom of the ABNF of fields > >> in 3.6, which would allow it to be used for something that is not a > >> trace field. (That is, optional-field appears twice in the 3.6 > >> syntax.) > > > > optional-field is a poor choice, as it is restricted to header fields > > not specified in the I-D. That includes fields specified in other > > RFCs as well as unspecified fields. > > > > Consider RFC 5293, where the *addheader* Sieve action is described > > like so: > > > > By default, the header field is inserted at the beginning of the > > existing message header. If the optional flag ":last" is > > specified, > > it is appended at the end. > So you're saying that you want it to be syntactically OK (that is, in > the ABNF) to add one of the non-trace fields at the top of the message? > There's already a discussion of this at the beginning of 3.6 saying, "It > is important to note that the header fields are not guaranteed to be in > a particular order." I'd really rather not change the syntax any more > that strictly necessary. > >>> The practice to collect trace fields at the top comes from the fact > >>> that it is convenient to write down one's 2 cents and then copy the > >>> rest without even parsing it. > Indeed, not just convenient, but that it's often been damaging to go > mucking around in the contents of the message. 5321 talks about this. True, but let's keep in mind that RFC 5321 is about message transport, and RFC 5322 applies more broadly. User agents muck around with the content of messages all the time. It's kind of what they are for... ned From nobody Sun Feb 28 19:33:33 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 D49453A13D0 for ; Sun, 28 Feb 2021 19:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=tOjJHbe4; dkim=pass (2048-bit key) header.d=taugh.com header.b=Ibz9uvtU 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 TcI9RcNzIVpL for ; Sun, 28 Feb 2021 19:33:28 -0800 (PST) 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 A38DE3A13CC for ; Sun, 28 Feb 2021 19:33:28 -0800 (PST) Received: (qmail 68802 invoked from network); 1 Mar 2021 03:33:23 -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=10cc0.603c6083.k2102; bh=fvDqWSsEkl727WJuoa9lxELJfaV9PbOZ0KLUKv4AV/U=; b=tOjJHbe4frlMMunwGaSQMLYwiyjryS3FHhvNO6/QVAzBCuVtUR0BPkeDxtx96dKmHsjDWpthFZvkoZrkPh1HENN502Jit/rIB/MBEXyodI3PoFHSO8hBewPtf4+aFZxCrOw2w8Yv9fD7QumxQ24MLT4H7533g/cTlHLOZ6Xusuc9CGtv8zohpHv2L+2Nvs1ua020AkFbtbdmJORtzosZx5omWy8LWO8TZ7UaVS7vItuIepBcpp/GM0P9HDfF69FtLYRHF+fhqU9H4FKu696bhp8rwaE0Y48SpTOu+wrJGWdS6rcV654ig59doqyByeEt7rCApH1FXrAU7jaAOUg/qw== 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=10cc0.603c6083.k2102; bh=fvDqWSsEkl727WJuoa9lxELJfaV9PbOZ0KLUKv4AV/U=; b=Ibz9uvtUSb4OUoG1wB8RDeKmFRiujqu36+Aw0g/KJGjUO3xD48lQVJFgcN2KrgdNJDn2yThLqEjNb6OspUY61uJnKkaMOywgku0RmhzjdfEV0ke/u4kT82UbTQbEBIps1ZEpMJDk63sZjRkss2j808aHdwj8Ou9XNhpDxtgzYNBcm+LqRBwM4XxMR+XC4R1o27KHdciAvK24Emmpo+Q6GGQ0JrR/YByJq74yHC20GaSaKdsv3rFxQ+Yz8CFqH7u1vNRKDFwG3iXDFHKs3l45Cb2mMmNhV4FpgSKpjV17ify1ja1I2dskdAvWuyXpSzKft/y+EAPDaDgmcRX/1ncy3g== 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; 01 Mar 2021 03:33:23 -0000 Received: by ary.qy (Postfix, from userid 501) id C1F766F35E4E; Sun, 28 Feb 2021 22:33:22 -0500 (EST) Date: 28 Feb 2021 22:33:22 -0500 Message-Id: <20210301033322.C1F766F35E4E@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01RW2JPR8LJK005PTU@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 #7: Better definition 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, 01 Mar 2021 03:33:32 -0000 In article <01RW2JPR8LJK005PTU@mauve.mrochek.com> you write: >> > Ugh, that way you cannot have a lone Return-Path:? > >> No. Is there a reason to ever have one? > >I can think of at least two: > >(1) IMAP APPEND of a (possibly draft) message (thus no Received: fields) where > you want to say what the MAIL FROM was/is/should be. > >(2) Message has had all Received: fields removed for security reasons. (And > please don't bother telling me this is a bad idea, because you'd be > barking up the wrong tree. A large number of security reviewers say > otherwise, and when the choice is between no Received: fields and > no deployment, guess what wins.) (3) Message is delivered on the same MTA where it originated, and it was originated by something like an internal sendmail program so it doesn't go through a submission server.