From nobody Thu Nov 4 13:45: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 44B673A0958 for ; Thu, 4 Nov 2021 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 1UOft0J3HE6c for ; Thu, 4 Nov 2021 13:45:47 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AD6833A0953 for ; Thu, 4 Nov 2021 13:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1636058742; d=isode.com; s=june2016; i=@isode.com; bh=zyMhgyqHleVUYrL2n8NiIvaSELzuPGozA06swhsxsyM=; 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=j6gBntGx3fXmn9FXlv+X6l6WpAD002MQMfPAR1N5NclkdMpkqtrbhoWZqcho8DYLHh9ZeK 5LvzeY4OU+he50xv1iCbh3geojnWGhcC7+YhiJ4nKy+jxo2RtqRWZbOCOG70GpDxmYOfn9 ZlHtOdln0C/vxaKU4g9a8QbDfa4XITg=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 4 Nov 2021 20:45:42 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> Date: Thu, 4 Nov 2021 20:45:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 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 #17: G.7.10. Further clarifications needed to deprecated source routes? 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 Nov 2021 20:45:51 -0000 Dear EMAILCORE WG participants, I've started writing some suggestions about how to resolve this ticket,=20 but the number of changes is potentially huge. So before I send a long=20 email with suggestions, I would like to poll the WG about directions in=20 regards to resolving this ticket. Background: RFC 5321 says that source routes are deprecated since 1989,=20 yet at the same time servers must accept them and there are various=20 SHOULDs about whether they can be ignored or rejected by servers, and=20 about when clients can generate them. It also talks about using source=20 routing to work around temporary DNS problems and for mail system debugging. So my question is, whether the document a) should be stripped of all mentioning of handling of source routes in=20 text and ABNF, other than to specify their historical use in RFC 821 and=20 point to RFC 821 for implementations that want to implement them for=20 backward compatibility; =C2=A0or b) allow source routing in ABNF, but strengthen existing text to MUST=20 NOT be used; =C2=A0or c) make various parts of the document consistent in regards to allowing=20 source routing only for "working around temporary DSN problems" and mail=20 system debugging. Don't use the word "deprecated" when describing source=20 routing, because basically this is not true in the 2 cases listed above ? Maybe I missed some other alternatives. Opionions? Best Regards, Alexey From nobody Thu Nov 4 14:09: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 0FBE63A0A69 for ; Thu, 4 Nov 2021 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 dF2-BhAHXXHO for ; Thu, 4 Nov 2021 14:09:02 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE913A0A66 for ; Thu, 4 Nov 2021 14:09:02 -0700 (PDT) Received: (qmail 385633 invoked from network); 4 Nov 2021 21:09:00 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (6e69902c-3db3-11ec-a4cc-530e9c1fed16); Thu, 04 Nov 2021 14:09:00 -0700 To: emailcore@ietf.org References: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <1c4d4bb5-e167-bb14-a4e4-3e6f95c51466@linuxmagic.com> Date: Thu, 4 Nov 2021 14:09:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 6e69902c-3db3-11ec-a4cc-530e9c1fed16 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 #17: G.7.10. Further clarifications needed to deprecated source routes? 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 Nov 2021 21:09:07 -0000 On 2021-11-04 1:45 p.m., Alexey Melnikov wrote: > a) should be stripped of all mentioning of handling of source routes in > text and ABNF, other than to specify their historical use in RFC 821 and > point to RFC 821 for implementations that want to implement them for > backward compatibility; +1 Unless of course, an argument can be made for a real world need to continue this. Given the current state of email, and restrictions placed on accepted inbound traffic, it is highly doubtful that such mail can be uniformly delivered at all any more.. Bag it and tag it ;) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Thu Nov 4 16:16:36 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 E83F63A0864 for ; Thu, 4 Nov 2021 16:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdiRYjE5JKtR for ; Thu, 4 Nov 2021 16:16:30 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 4F8543A0860 for ; Thu, 4 Nov 2021 16:16:30 -0700 (PDT) Received: from smtpclient.apple (unknown [63.88.3.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 6A310BABF0 for ; Thu, 4 Nov 2021 19:16:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Viktor Dukhovni In-Reply-To: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> Date: Thu, 4 Nov 2021 19:16:27 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <0E675116-119B-4EFB-A1A8-CB6C0FE9BF61@dukhovni.org> References: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Emailcore] Ticket #17: G.7.10. Further clarifications needed to deprecated source routes? 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 Nov 2021 23:16:35 -0000 > On 4 Nov 2021, at 4:45 pm, Alexey Melnikov = wrote: >=20 > So my question is, whether the document >=20 > a) should be stripped of all mentioning of handling of source routes = in text and ABNF, other than to specify their historical use in RFC 821 = and point to RFC 821 for implementations that want to implement them for = backward compatibility; +1 for "a)". Postfix ignores RFC821 source routes. Instead, Postfix by default = recognises legacy Sendmail-compatible source route formats: "user%remote.example"@local.example "remote.example!user"@local.example only from clients allowed to relay, refusing the recipient address = otherwise: http://www.postfix.org/postconf.5.html#allow_percent_hack http://www.postfix.org/postconf.5.html#swap_bangpath Neither of the legacy Sendmail-compatible source-route forms overlap = with the legacy source route syntax in the RFC. One important reason to handle these forms is to not become an indirect open relay when forwarding such recipient addresses as-is to internal systems that may treat them source routes. --=20 Viktor. From nobody Thu Nov 4 17:19:09 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 458643A0857 for ; Thu, 4 Nov 2021 17:19:07 -0700 (PDT) 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=FD/KxvkZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=GDsbjIQi 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 h4TTmGOrOFRk for ; Thu, 4 Nov 2021 17:19:02 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511653A0855 for ; Thu, 4 Nov 2021 17:19:02 -0700 (PDT) Received: (qmail 37941 invoked from network); 5 Nov 2021 00:18:58 -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=9433.61847872.k2111; bh=yu9FdL6VXqYqai5tDdRYDeCsMiysQGYfdFPTpWzZm7I=; b=FD/KxvkZO4snPocoK9dZ1VV1h7KvOevF5+XX8/4H5mIByXH+pKInZtl9ixdXh+r6xgLwGHSZLVVgUcN6L9WE+4/oTTW5QPlCBCj1ax04ItBAgHCO8H6xL8Stxg+yN+GxGTI6+RZw5mr1RIo62IFD2P1ndj7WWK2FOHQCEXrTg2NbKjZbaTWKFsfLQ7FR0w0bKTOrFAdjE+d8BbdaK/ehGn9I/W7SmslpHmCNeMxX30xLl+KGRH+cPxaUHUmx1auDlhHJWM6gKdFx2adA9aGNM7XnQiIttx7vlR2xWnbJy6KNP6cfmNP0G/ZGMeLRCVNxzj3SilsL9UriMmc+QNZ2qw== 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=9433.61847872.k2111; bh=yu9FdL6VXqYqai5tDdRYDeCsMiysQGYfdFPTpWzZm7I=; b=GDsbjIQi/H0dGuFIg88bJqk6jIkpl8R8ojysCTVzL9zvF1a+BGMqWOhMbT5AMLgxylzLjIl7xvo7mau5RyhK2EodT5DrLPymKM+/wjyAI6QwOMfbDOXB8wLnIq96zkPrT/HVgeut3BwpweT+u0wbaad9awDL7ktILPNUL2zHmMxk43RINPBIGrfckAwgKDmYjpPe/MQgBuCewISwatcIMW8vwrDBUiBqu/HaYBzS5/iBiVoZ0WnVYPrCAg3IMcpn6iAoDwmaWeJirEUhEEKaeiCMBjLBn39Ap7STQPBvG5Uc7hxTzzwzRXgkGlxNQgmXC39Wu0atNJMAKMIPe+UF/Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Nov 2021 00:18:58 -0000 Received: by ary.qy (Postfix, from userid 501) id 453762F87F23; Thu, 4 Nov 2021 20:18:56 -0400 (EDT) Date: 4 Nov 2021 20:18:56 -0400 Message-Id: <20211105001857.453762F87F23@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: <4971c87d-2d72-8211-1a69-351821c4a925@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 #17: G.7.10. Further clarifications needed to deprecated source routes? 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, 05 Nov 2021 00:19:07 -0000 It appears that Alexey Melnikov said: >a) should be stripped of all mentioning of handling of source routes in >text and ABNF, other than to specify their historical use in RFC 821 and >point to RFC 821 for implementations that want to implement them for >backward compatibility; How many MTAs still recognize them? I just checked Gmail, AOLhoo, and Hotmail/Outlook and none of them do. At this point source routes deserve at most a historical footnote. R's, John From nobody Thu Nov 4 19:53:59 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 220973A09E8 for ; Thu, 4 Nov 2021 19:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm8oYWsRwG0Z for ; Thu, 4 Nov 2021 19:53:53 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 E68C73A09E5 for ; Thu, 4 Nov 2021 19:53:52 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 337A0BB235 for ; Thu, 4 Nov 2021 22:53:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Viktor Dukhovni In-Reply-To: <0E675116-119B-4EFB-A1A8-CB6C0FE9BF61@dukhovni.org> Date: Thu, 4 Nov 2021 22:53:49 -0400 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <6F86CB7D-4A5E-4D0D-8D84-7720C7A87ED1@dukhovni.org> References: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> <0E675116-119B-4EFB-A1A8-CB6C0FE9BF61@dukhovni.org> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Emailcore] Ticket #17: G.7.10. Further clarifications needed to deprecated source routes? 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, 05 Nov 2021 02:53:58 -0000 > On 4 Nov 2021, at 7:16 pm, Viktor Dukhovni wrote: > > Postfix ignores RFC821 source routes. The above is perhaps unclear, in Postfix RFC821 source routes are recognised and discarded: RCPT TO:<@somehop...:localpart@domain> is treated as though it were simply: RCPT TO: This at least makes sure they don't get passed along to any downstream systems that still support them. However I suspect we don't need any ink spent on the topic in the standard, the historical syntax can be found in earlier RFCs. -- Viktor. From nobody Fri Nov 5 04:29:36 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 1D9513A0D35 for ; Fri, 5 Nov 2021 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 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=-3.33, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=sH22jfkW; dkim=pass (1152-bit key) header.d=tana.it header.b=AN0crYTC 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 F6tGDXffTetj for ; Fri, 5 Nov 2021 04:29:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D52E3A0D32 for ; Fri, 5 Nov 2021 04:29:25 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1636111760; bh=ux5k0Zs129QCyxPARGERT89RCIHGVLJdmSki3yqEwtQ=; l=423; h=Subject:To:References:From:Date:In-Reply-To; b=sH22jfkWo/EryeIx/TlHF7XQptnu09in8AGXqInz5K/mEOs8Xl28co/PPrZZ2SRA+ /LvwrIHdGU7o5cgoQRvCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1636111760; bh=ux5k0Zs129QCyxPARGERT89RCIHGVLJdmSki3yqEwtQ=; l=423; h=To:References:From:Date:In-Reply-To; b=AN0crYTCaQj9EwjdQJBJ5BR8N0FOYSl2yK4O3h/T/6tbA47Sr4vuYkxrRrNb4UJfW jRRDcuVE5tvOUHS+VBdxkD7oZJCnCR+4gfoF5Z11LpUEuo4g1eRS0+WGOICTirRme0 /VMl1w5Ks+8XxG0vMSNbc9hkzz51o86f5KQ4yxuiPEGpHMKTrXimYSB7p+hJa 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 00000000005DC042.0000000061851590.00003F3F; Fri, 05 Nov 2021 12:29:20 +0100 To: emailcore@ietf.org References: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> From: Alessandro Vesely Message-ID: <13f016a7-6656-72d7-eb5f-13d261b6fcf1@tana.it> Date: Fri, 5 Nov 2021 12:29:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <4971c87d-2d72-8211-1a69-351821c4a925@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #17: G.7.10. Further clarifications needed to deprecated source routes? 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, 05 Nov 2021 11:29:34 -0000 On Thu 04/Nov/2021 21:45:43 +0100 Alexey Melnikov wrote: > > a) should be stripped of all mentioning of handling of source routes in text > and ABNF, other than to specify their historical use in RFC 821 and point to > RFC 821 for implementations that want to implement them for backward > compatibility; +1 for (a). The other options either waste ink (b) or will never work in practice (c). Best Ale -- From nobody Fri Nov 5 07:26:14 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 2F4C43A0DD2 for ; Fri, 5 Nov 2021 07:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 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=-3.33, 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=oUHfqVgO; dkim=pass (2048-bit key) header.d=wizmail.org header.b=QF3CA7H3 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 9LPIS7hH4VvF for ; Fri, 5 Nov 2021 07:26:07 -0700 (PDT) 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 8B2673A0DD5 for ; Fri, 5 Nov 2021 07:26:06 -0700 (PDT) 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:From:References:To:Subject:MIME-Version:Date:Message-ID: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=V5skSX9YqNUvUp46IzaGClxvsHJnoS/gVJr6pEJHmdY=; b=oUHfqVgOv9fsj+/SBVgLeqE2Hf p6v0PnOUzsOP5qjSB2DQ+yOg1CoQC2w3gjYXBR5+uPVTFoCXlnLKanh/ioCg==; 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:From: References:To:Subject:MIME-Version:Date:Message-ID: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=V5skSX9YqNUvUp46IzaGClxvsHJnoS/gVJr6pEJHmdY=; b=QF3CA7H3kAdORI8drMyvLuIF/R 2YwQAkczuAQSUqTLwh/GWnFPfGJJ0skvYy923j/WDtaG6JNJ2CR6p17TsKFbXtLxv6bY8Nb0fXklq 2lJ+zJviAnRamEzwZiPnIS/1xU7L69Qf9h1mfEBKC4hjX0N3tpHdzpYFc1/pFlorHxTilkz6zXbim IzGS88VmQ5uV2R0UxujcTVr2pln9KQ1znJkzwaig9fILI9mmRkT9otmDTUz8g7PA+rBWgr+HntYh4 htnd6W9SqWcybf5tB2M3TPCRUpwNcF06O1SAMZwUK+RCpHglAcH+IsP+qNMkz3iojVppR2m+YUHgd MFnRGchQ==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.101) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1mj0AN-006AM5-0T for emailcore@ietf.org (return-path ); Fri, 05 Nov 2021 14:26:03 +0000 Message-ID: <11a14f05-8554-da36-42cc-7995f57f4915@wizmail.org> Date: Fri, 5 Nov 2021 14:26:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-GB To: emailcore@ietf.org References: <20211105001857.453762F87F23@ary.qy> From: Jeremy Harris In-Reply-To: <20211105001857.453762F87F23@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #17: G.7.10. Further clarifications needed to deprecated source routes? 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, 05 Nov 2021 14:26:13 -0000 On 05/11/2021 00:18, John Levine wrote: > How many MTAs still recognize them? I just checked Gmail, AOLhoo, and Hotmail/Outlook > and none of them do. The support in Exim is not enabled as default; there is a config option to do so. -- Cheers, Jeremy From nobody Sun Nov 7 21:10:59 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 11BE83A0B08; Sun, 7 Nov 2021 21:10:57 -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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <163634825699.16120.16554116507073741230@ietfa.amsl.com> Date: Sun, 07 Nov 2021 21:10:57 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-06.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: Mon, 08 Nov 2021 05:10:57 -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-06.txt Pages : 120 Date : 2021-11-07 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. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title. // JcK 20211029 Note in Draft: Adjusted in version -06. Decided the // details belong in either the Introduction or the A/S, not the // Abstract. And it makes the Abstract a tad shorter, which is good. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 7 21:24: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 E6E4D3A0C85 for ; Sun, 7 Nov 2021 21:24:55 -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 Q_xkJdS8U20E for ; Sun, 7 Nov 2021 21:24:52 -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 CAB0C3A0C82 for ; Sun, 7 Nov 2021 21:24:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mjx9H-000JOi-5N for emailcore@ietf.org; Mon, 08 Nov 2021 00:24:51 -0500 Date: Mon, 08 Nov 2021 00:24:45 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <2956D9745848841F0E6AB8A4@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-06 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 Nov 2021 05:24:56 -0000 Hi. Per discussions with the co-chairs and on the mailing list, -06 has been posted. See Appendix H.3.10 for a summary of changes. A major change mentioned there is that after strong comments/ advice from Carsten Bormann and help from John Levine, the source has been converted from xml2rfc v2 to v3 and tuned a bit. That has resulted in some major improvements as compared to bug-induced problems in v2, including having the Index reference sections, not pages, but also to be sorted such that all upper case characters are considered to precede lower case ones rather than being equivalent (I believe that is a bug, but don't know if it was intentional). It has also resulted in some changes, such as mapping what appeared earlier as [[CREFnn: ...text... ]] into // ...text... Those types of changes are a little hostile to trying to understand diffs, but it probably had to happen sooner or later. See you all Wednesday, I hope. best, john From nobody Sun Nov 7 22:36:23 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8DB3A0D85 for ; Sun, 7 Nov 2021 22:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 94Hk_RTocRL6 for ; Sun, 7 Nov 2021 22:36:16 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410129.outbound.protection.outlook.com [40.107.141.129]) (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 AB6F03A0D81 for ; Sun, 7 Nov 2021 22:36:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lTXfD0lMrMBQANqAbpH/OSw+WvJmQdowh6bHE3LgryISCkFx3y0PFdad779bRzyWjA84rwyiQL3cTJGRno/BkPY7iX16VB34su+CrEZlhD5PxiYqJYI5JoKLR6oBaajaq7bekU28qFJYjphSmDeI+AYfQmuFh7PtCRKBrJp2eC2rapmWFexgkm1Uboe+ARx/+HlLRnRVIALu/RFF5/AdRlpflx4VdxZUW0wBB/uAIGCc6hmMkncBfd8u+bcNkjSsl1lYtbhQ3NW6svqPCTHwZLqrwuaWAirYQ6bqWMHNQPN3g9nsVWMUfktvbzPPb32AIc9rEoAT6qiqax89sbYVdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BTXAq9YPIJzTtY5ziVaRQdhaKu3WT+MR9apKYo9hZPg=; b=eK2PPWu79AzbxPLahNqRO8TojkXA1ZY6I5CvhgT0PlQEjsdeMill8Z/Ud3VJI1vYQ2P1eGYbU96Dkm4bcT4+k90m8GvpFPh0FSumF6daV51+YJVwxiumse/oWbffETLScAvGj0/H5HHYOzqJJN8ttLcVXBtqKi9jdTBt+MeV3Ixr7kboIhZLGLkNq9iT2ydq87AcLACe404aDnJOAQope2h5k+9YSKnKqk+3s/FpcjojC8ROPVNk6CqNO01bF89Wb6LSAjWp8MvpArEh59SKhVtp/h0hMtwRTPFQsacL7L5c6vBM7tfqtu/8qwxq7Q0nOgp1Ri2W0+YyGl2ijpRmfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BTXAq9YPIJzTtY5ziVaRQdhaKu3WT+MR9apKYo9hZPg=; b=NotVMYQVz1ZqqqR0JclyfV/VuyC1oGp4YX+7fUvlCwl6ZabeKjgj4WEnNQ1UJbMkvV92LlUZc2RzxO78Nf/1XEYCaoRuBUJJm+whf5sPlKEh7oOI9FgOd6FsAWw04sVmNH1YUjdQ4Sa5CT44vFoxPojtQzP5ZVmtyDPsaQ8FY+I= Authentication-Results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB2314.jpnprd01.prod.outlook.com (2603:1096:404:10::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Mon, 8 Nov 2021 06:36:14 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::348d:f2c7:d58f:35f3]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::348d:f2c7:d58f:35f3%6]) with mapi id 15.20.4669.016; Mon, 8 Nov 2021 06:36:14 +0000 Message-ID: <772e2595-2d9a-ba47-e14b-c124f1a72644@it.aoyama.ac.jp> Date: Mon, 8 Nov 2021 15:36:13 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: John C Klensin , emailcore@ietf.org References: <2956D9745848841F0E6AB8A4@PSB> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <2956D9745848841F0E6AB8A4@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0035.jpnprd01.prod.outlook.com (2603:1096:404:28::23) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [133.2.210.39] (133.2.210.39) by TYAPR01CA0035.jpnprd01.prod.outlook.com (2603:1096:404:28::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10 via Frontend Transport; Mon, 8 Nov 2021 06:36:13 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 64a25e2d-7203-4604-024e-08d9a2820f8c X-MS-TrafficTypeDiagnostic: TY2PR01MB2314: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: g8yXB0fGwXVgwOGSTDsSuyag1k34O5JUPJN3EC6JyvfePxVxd+uKRQ/gf99syhDSE4lzajyI/5069IA2WTPb36LJJ16oCe+Nli9IEjRGncNGhT70/VkjDX3EdqoKtayfVXIT6QGxpKT7Wsm/odNk67ZjTOX2ngXliFcchbJEBGCQxlSCmgWwC9eUmYglwUAQQWzCpdQIAaR4ZcxHDStFZzqkJOYS8vTWWEm9r2u83Ipcqe5+J2GIgGW1EYnGtuuhJEV2X0HQHbjL4kk5INt5J7kK0YnPV9IvJ1viHsH9H4ZjVY8ekukJuX3AJuF6EMCkm1h6lX94C5qBFMA4pygafxjFYnPzPyCF4U4FwHzhrz9mzkKrRajpn0lc3YqBeFcYlgZrg4kyoIE1+pi51+4lUKXtzRerATHc+o/+eWTCkZSuD9RKDbd50zblLD4mJpoXydyIH4MtAnwtztGptqdq1TfHufLV+Uq7v5Dlayk5f6iHyA3aU2DFeouc2DWlt8NXIyyaJByFc/WfAo5yY3wzKoa8Y0O0O97K4T7prOdHd1Ggzm57jBy6SQQj9UxETQR+7Wboqo030N2PxA9vjS4hK76bTMnwfBhuenL95VnSNCWyu87AG8NoeIePyu7CYDio3aBZRLWy5B6z/sDFEwTboiptgaFSXRfvYrp+n8ecr/TuFfFIfIVX5KmCbNoa9+duU74R5ABrXByb0DrCQ/9ak89fClxVNe2aclz8ZFBOugmZUf4klZZcIiJJtJ7tYgS6amuKEr7G8JeE8xstn9/UlVO+REH2RB11I6NWF1X2Pk4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39850400004)(366004)(396003)(346002)(53546011)(186003)(31696002)(8936002)(38350700002)(38100700002)(316002)(6706004)(786003)(16576012)(4744005)(86362001)(8676002)(956004)(2616005)(508600001)(36916002)(6486002)(52116002)(66946007)(66556008)(66476007)(26005)(2906002)(31686004)(5660300002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z3RvQ1JUVkt5SmFJM0FhZGcrekMzdzdoTnJTUU9XOFhWTU5wUi9LOE9oZ3pl?= =?utf-8?B?djV5bXpSZVRPajBWaGlURzNNbTcvQWg4N3U0WnRPZElEWE80Mno2d0F5V3RJ?= =?utf-8?B?WXdSTnc1Wk5ydnpyWDhzYUdjeUh2WlE4UVBNM1Z5djRRTUFqMEpSdkZ4MDNV?= =?utf-8?B?YVFyRVd6QlB2NCtuTklIZnZ1THNKM2s1SldEQldjV2NOMWNDVjNVZFpqQ3VX?= =?utf-8?B?WDlCSklEcXhKdWh6UStQR3NIUnBiQjNzaEJTU0FlNzgxTWtaZUpPckIwY3dQ?= =?utf-8?B?M1ZEWm1WK1pXRVpZUEQ3U05US1hrTDlKNUk2SDk0ZEhqTVZkYmlIaGhxdEM4?= =?utf-8?B?aWZiazR4ekprL2drZ2hma01kR0tSaVJMaEx5cVBVVStzZG4yTWFCa0hEL09V?= =?utf-8?B?LzVkd2VTdzlSK1VidHFidTRTZG80SXk2OW8zOGVNZmlCN3A1WVBGSHRPUFlE?= =?utf-8?B?OXlEWm52aUE0bVNZN0hvaHNrcnhCWTVOenFVTDBWOVovNWYyYzFNcjc4TlFE?= =?utf-8?B?bk1BbjE3YmVQYjBKZTlxcmNNYTI1cGJIeXNTKzdZcHdtQUQxVHBGSUNNbDdK?= =?utf-8?B?eWxDWVBndEF0R0VuaFpBVXUyQ2E3SWl5TTdUNzNxYlgwMFJjNGRyb1pDcDI4?= =?utf-8?B?bTYyL1d0UC9sNWJITDdWbFZLUFlHTXZlaWFMRVB3aEdRTTZJL0FBb3VRaDhZ?= =?utf-8?B?S2pWR09uSUVKdURaOVEyWHNWbW1vMGFCbHU3eXRudURZSUltbyt5S0pxak5t?= =?utf-8?B?aVczWFNiRkFGNjRPK29HbngzandZOTVNNVdYMnZybkErb0dBQjZwY0wzNXV0?= =?utf-8?B?QStPZC96R0FCdGlMeVRqRFhRUDhLbHRCZkk3NHRMcTRrNEQxdmFOZUVtTlZh?= =?utf-8?B?V3IwZTdsRFJDWnMzd0loRXQvM0tvVXBhR3hTbk5GQU14Z2xObEVQSUFuOVpM?= =?utf-8?B?MklQdG1pZFdvUnNrV2FqN2doNVN1dnZNOEFQOE9XT3QyT2Y1UmV6eW5Ba2lm?= =?utf-8?B?MERvZ0Q3Qmlwdnp0cElINnJIR3FuZXlBcWVleG1sSkVVZmlLQnBNeVV2VktU?= =?utf-8?B?LzBiZ2tMZ3FqMEF4VHkxOEFLMjMyVnpNa29uZWlNbDVNeStZTzBUenNsdzVB?= =?utf-8?B?RXVTRU5KNXIxMkRORUFDMFk1aFFGdnZmb0ZtMWdZS2VnWFl1eklKTVdyRU03?= =?utf-8?B?RVpxTDFCcWJZdjV4MFV4blVBYWhsREM4dnJvMnVmTm1LT3NDd3JveVR5U24w?= =?utf-8?B?TEFGN0dlZU04dG1GLzBURDFpLzg5SVlkUnVFRG5RaGs4UWZaWnNMU2UyTHhB?= =?utf-8?B?QmNmcW9KcStVc2EvaWtHbG1ocDRnQk5lbGI3SzJpdGZKREsybEd1YzN1RTJK?= =?utf-8?B?WGgrdzRMZFRVR3JGZVRCUXJZcTdZbTZqMmtRZnFRREZWRkxlK2UvZXZRNGM3?= =?utf-8?B?MzNiM3Q1ejlLdGYyMFdPeE1zZmQ3c2V5WmV1U2R6dTNDbzJrZ1l6RktjRFZG?= =?utf-8?B?UDJJY3NySFE4anVQZXN3NU5Uc3FrSkZsbXhWUmZlSHB0dDhvUmVUVUJkYXJJ?= =?utf-8?B?M3FKVDdsaFQxb1d0a3puaVpNZHVrUDIySDNpUUpGbW91RDdGNzg1bUpGWUdE?= =?utf-8?B?L2dkb3lTUEZUSm1NV2c5VmNwSS9rZTJ2akN1TDNIYytrbzZaSGJ3R3hhOVA4?= =?utf-8?B?WXRPbytaSTF1WmxjcGN4Wld3Mk1JdnFsSjl3TVNvZ3AwZG1KdlZSRElPdG1p?= =?utf-8?B?VXJ5aFROMkVaNk5MRUhSN1hEU1QwaEhvcFM0UjRPZTBvaWo0UUV5a0lNdDUv?= =?utf-8?B?dnpxbXA3WmNGb0kyL0pUZmRvaDd3clA4ZkhyNHF6L1ZTOGZqZVVuRUJRVlJ5?= =?utf-8?B?WVhaQU8xQU4rVE5FZ0pZOGVjQlJLZWduVnRjV3VxWFNuMTUyclhHeTBLdnBl?= =?utf-8?B?TDdQclJPN3llbExqSFJtTVg5Y2hVajRLa3dNRzhhVi9HRE9qeU0zUEpiTHVF?= =?utf-8?B?b2tCcXdpd0ZZTWRuaStFWlFxNnUvTnZVTnFqQ09DdysxeDJWWUd2WHAyZ0RC?= =?utf-8?B?MCtNYmFQaXk0c2Z1a0R4bS92WjZ2bmZrWldBWGtpM0Zza2Uwd09KL0hzUTlZ?= =?utf-8?B?M3NIV0VLQURiVGxHU3VqcWN6VnBUNDRjb2lUaEF4cnNVTGJqZmJqWm9SM2NR?= =?utf-8?Q?1DPpPjijINiPViaBRaJxMGM=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 64a25e2d-7203-4604-024e-08d9a2820f8c X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2021 06:36:14.0804 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IZ5ZQa/zHdBniJzWQZBE+ztQf7/YFSL0d9qm1xLllifwIfkikYGWmRIX/hJdNicOWMrgQUqzQ/BNFngBfzZaow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2314 Archived-At: Subject: Re: [Emailcore] draft-ietf-emailcore-rfc5321bis-06 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 Nov 2021 06:36:21 -0000 On 2021-11-08 14:24, John C Klensin wrote: > That has resulted in some major improvements as compared to > bug-induced problems in v2, including having the Index reference > sections, not pages, but also to be sorted such that all upper > case characters are considered to precede lower case ones rather > than being equivalent (I believe that is a bug, but don't know > if it was intentional). Even if it was intentional (which I hope not), it's clearly a bug. Regards, Martin. From nobody Mon Nov 8 04:33: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 CEE5D3A0E1C for ; Mon, 8 Nov 2021 04:33:21 -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=dO5bnpzd; dkim=pass (2048-bit key) header.d=taugh.com header.b=WT5WuO1Z 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 SBpT3NQU6oqG for ; Mon, 8 Nov 2021 04:33:16 -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 47FEB3A0DEB for ; Mon, 8 Nov 2021 04:33:15 -0800 (PST) Received: (qmail 46869 invoked from network); 8 Nov 2021 12:33: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:mime-version:content-type:content-transfer-encoding:cleverness; s=b712.6189190a.k2111; bh=I910sy0Z3/S3Rck0QezTAkFnsQjSY4Qu5KfshhLHKOQ=; b=dO5bnpzdK7tqS8hgBvBG2izdB+LUUfuy0j9NfWioAEPPKP654Ip4drWe/Lsl4Kc10UA7WSVRFb8X2f07WSBYRLxVj1V/F81gR3Zr12Ttk8cmNec3IBEwzfNlNu+JNjbWNTleRQcmxhGxIFWYghgClhrxVAWUUcMdonJOo9lWMLLdQz0FCo1isIzv29VV6v6PXq++P6xWL6jHCl7P0YKc0PKbzdhMKSXcNZuAnfHntIUF76j+22IYMNnXJ5in4+iVGIlLWuie2ve98vZi0gwEoc2f5ZHvZTygEl9G4PcV90kG6qb12edTt58pmmKExXWgPmsoweeLiY+f7zvVJJkt3A== 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=b712.6189190a.k2111; bh=I910sy0Z3/S3Rck0QezTAkFnsQjSY4Qu5KfshhLHKOQ=; b=WT5WuO1ZNTZ154SuDkN9HFZifHPLM+aXvouJNdFIeBCTwzi04Zzl4D1bJrkFBttOv4HvCddsg7X4rc3gQr6Yn2fIvAsIWN+PYntVNv5BcCZUr8zN/mwH9bgkGcWQgO1DX3kyM1m92nQHzumf4zTuNTUbAHvgzUrxHoldPOG2HubBTIQTW548Gzbyhi7CC+6smEuzqviWuFEbcT3H7dkT0rsDaxIQ15+Kg0mTQW0k7nJ60hqRLSFdvJDZgWda56DwskmBSqsvKCqjeXWZ8a2mc3zYAfw3T2zSr18ImWI6Ii+TOft/YS8PtB9PKKLp7bRonpJxNPk0h+aBBXfmGGP6SQ== 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; 08 Nov 2021 12:33:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 4B4C22FAE6B9; Mon, 8 Nov 2021 07:33:11 -0500 (EST) Date: 8 Nov 2021 07:33:11 -0500 Message-Id: <20211108123313.4B4C22FAE6B9@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: duerst@it.aoyama.ac.jp In-Reply-To: <772e2595-2d9a-ba47-e14b-c124f1a72644@it.aoyama.ac.jp> 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] draft-ietf-emailcore-rfc5321bis-06 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 Nov 2021 12:33:22 -0000 It appears that Martin J. Dürst said: >On 2021-11-08 14:24, John C Klensin wrote: > >> That has resulted in some major improvements as compared to >> bug-induced problems in v2, including having the Index reference >> sections, not pages, but also to be sorted such that all upper >> case characters are considered to precede lower case ones rather >> than being equivalent (I believe that is a bug, but don't know >> if it was intentional). > >Even if it was intentional (which I hope not), it's clearly a bug. It's what RFC 7991 says, but I think that is a typo: When the prep tool is creating index content, it collects the items in a case-sensitive fashion for both the item and subitem level. https://trac.ietf.org/trac/xml2rfc/ticket/680 R's, John From nobody Mon Nov 8 05:04:18 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 B92483A0F61 for ; Mon, 8 Nov 2021 05:04:17 -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 tV-7LzpoNfu7 for ; Mon, 8 Nov 2021 05:04:13 -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 E01E33A0F48 for ; Mon, 8 Nov 2021 05:04:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mk4Jm-000K56-V3; Mon, 08 Nov 2021 08:04:10 -0500 Date: Mon, 08 Nov 2021 08:04:04 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org cc: duerst@it.aoyama.ac.jp Message-ID: In-Reply-To: <20211108123313.4B4C22FAE6B9@ary.qy> References: <20211108123313.4B4C22FAE6B9@ary.qy> 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] draft-ietf-emailcore-rfc5321bis-06 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 Nov 2021 13:04:18 -0000 --On Monday, November 8, 2021 07:33 -0500 John Levine wrote: > It appears that Martin J. D=C3=BCrst = said: >> On 2021-11-08 14:24, John C Klensin wrote: >>=20 >>> That has resulted in some major improvements as compared to >>> bug-induced problems in v2, including having the Index >>> reference sections, not pages, but also to be sorted such >>> that all upper case characters are considered to precede >>> lower case ones rather than being equivalent (I believe that >>> is a bug, but don't know if it was intentional). >>=20 >> Even if it was intentional (which I hope not), it's clearly a >> bug. >=20 > It's what RFC 7991 says, but I think that is a typo: >=20 > When the prep tool is creating index content, it collects > the items in a case-sensitive fashion for both the item and > subitem level. >=20 > https://trac.ietf.org/trac/xml2rfc/ticket/680 John, Agreed -- I didn't have time to do the research and check 7991 last night, but if feels to me like this is not the only thing in that doc that turn out to be problems once we look carefully at the outputs of the implementations. Inany event, thanks for generating the ticket. john From nobody Mon Nov 8 09:40:09 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 5D1B93A0062 for ; Mon, 8 Nov 2021 09:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 PP55C1AhHUht for ; Mon, 8 Nov 2021 09:40:03 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 C7C1B3A0045 for ; Mon, 8 Nov 2021 09:40:02 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id n15so16197354qkp.12 for ; Mon, 08 Nov 2021 09:40:02 -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=rNkD+FpJ/qf08M6unQsUvBNDU4mm4d+hf64DC2JlBbM=; b=YZoPbg9rZVXNTfrbxthbAcwbc1bUhVJR32cGfIbJNsUWNQ3fCo5v0elR1sFkMJnJS/ cDKT5lSJ8Gol1ULeU2k1d4pyb/AQYZfh/oE7k/SfwW4VRsvhUa1LqAzjkNZdKVp2BXj8 iCWWG0j794WhZNxPogK/tWeTHE+fS1DUa5LGh+4gyk6X3i6ctKR7eZovCRIZEJ1CICJV h0PKVZTHat1Q2OHFBqL/D67vCQFreop5PULj/gnyrnmv48+s2zXsjXfCoNJqIjJFmXNk hQ23IyWNeNpcMRT5xeyb0UtPN/XTg4mqetOT45HGZOUaeEhiR/phYoCMfVaqpYZaVGF4 /Npg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rNkD+FpJ/qf08M6unQsUvBNDU4mm4d+hf64DC2JlBbM=; b=pYnRVhqVh1OO2zOW5pYRgbVceiqOiGWTdmNO4+a6BEvhpBWaf+INSiy/S1VIagN6kq zOsFH2b3kFSgGz4kp3yFD27o3YsmU2nKfQWURb3vND8GpOIltkv0qrWe/y9eWvdJK+gT 1xIoWn3YjgFmOGOfwyuhMVcCwQII25rR+hugl8W/OGTfOZ1Qosij6BU8S9ktejrSAE0K FDyQx7z48jQxhVVideAzcvyB4l995CpgtZ2YJQ1InAydY3106K40QWAbac8/XrEynO7a nkfH1wZnWXWwYoPHJMFCreHhXUfUOLP2GaoDTeAHySQnQ3GlF0U9cVv6un9lLMW7I8tF Ybrw== X-Gm-Message-State: AOAM533cQZVGU984aFp4WIjfeD4PWbYSxpw+jY+blHl/lU4CmBMA9GpM HpmBgKHmNsLlaPTODWFvjLgFYECxtBBH3ezNGTMVnjkq3BE= X-Google-Smtp-Source: ABdhPJzQQNlOFZLPc54CKXsj9OWM/K7nx2ymLSqnRi6PxJLJcg/hcyXHwmMa0hW0h+UjIZnlUuMMhRxQirvSUogQ0MM= X-Received: by 2002:a05:620a:1192:: with SMTP id b18mr667535qkk.393.1636393200950; Mon, 08 Nov 2021 09:40:00 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Mon, 8 Nov 2021 12:39:45 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000074c2cd05d04a7bb9" Archived-At: Subject: [Emailcore] Seeking Scribe for Wednesday's Session 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 Nov 2021 17:40:07 -0000 --00000000000074c2cd05d04a7bb9 Content-Type: text/plain; charset="UTF-8" Greetings. Rather than spending a few minutes during the session on Wednesday asking for someone to take notes, I've decided to start the process early. Does anyone want to volunteer to be the note-taker during the session on Wednesday? Thanks. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 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. --00000000000074c2cd05d04a7bb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

Rather than spending a few minut= es during the session on Wednesday asking for someone to take notes, I'= ve decided to start the process early.

Does anyone want to volunteer to = be the note-taker during the session on Wednesday?

Thanks.
--

Todd Herr | Technical Director, Standards and Ecosyst= em
m: 703.220.4153

This email and all data transmitted w= ith it contains confidential and/or proprietary information intended solely= for the use of individual(s) authorized to receive it. If you are not an i= ntended and authorized recipient you are hereby notified of any use, disclo= sure, copying or distribution of the information included in this transmiss= ion is prohibited and may be unlawful. Please immediately notify the sender= by replying to this email and then delete it from your system.

--00000000000074c2cd05d04a7bb9-- From nobody Tue Nov 16 09:33:39 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 79D143A089D; Tue, 16 Nov 2021 09:33:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163708401440.27207.14017394341852598446@ietfa.amsl.com> Date: Tue, 16 Nov 2021 09:33:34 -0800 Archived-At: Subject: [Emailcore] Revision of core Email specifications (emailcore) WG Virtual Meeting: 2021-12-09 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: Tue, 16 Nov 2021 17:33:35 -0000 The Revision of core Email specifications (emailcore) WG will hold a virtual interim meeting on 2021-12-09 from 17:00 to 18:00 Europe/London (17:00 to 18:00 UTC). Agenda: Discussion about tickets related to terminology and to finish a few other remaining issues on rfc5321bis. Information about remote participation: https://us06web.zoom.us/j/89359071984?pwd=ZXZSOVBtc0RPWUl1RjhUUGlRZzZQQT09 From nobody Wed Nov 17 08:59: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 273D63A0E26 for ; Wed, 17 Nov 2021 08:59:31 -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 (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 Jaozucj1XxXo for ; Wed, 17 Nov 2021 08:59:26 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8813A0E27 for ; Wed, 17 Nov 2021 08:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637168364; d=isode.com; s=june2016; i=@isode.com; bh=qkIoVoR4O5WRuNLUHyp87ldLCQet2ekr4UMm1aTjHmU=; 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=pBhdjR07GuJ4hkUu07FuY2+/poF3RjvSv2Fzq3WhyUFR5lYQHHt30Qj1DQ22AQR6dJiEW+ 7cxojEzz/M+lPH2rsYtb8v0PEl3kZ4qafckdCCokhDSaw2Q2AIpVTcVdypzZEPGYHvtgqM KE8baFc2d9x3xtPsgycyMFscTA8bAJg=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Nov 2021 16:59:24 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <6ce394dd-9b42-cd6e-3c17-93245efa30d7@isode.com> Date: Wed, 17 Nov 2021 16:59:25 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 To: emailcore@ietf.org From: Alexey Melnikov MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------uaOL8iXDbRpNdLTGWqsU4TY4" Archived-At: Subject: [Emailcore] Closing tickets: #52, #34 and soon #53 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 Nov 2021 16:59:31 -0000 This is a multi-part message in MIME format. --------------uaOL8iXDbRpNdLTGWqsU4TY4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Text for the following tickets was implemented in rfc5321bis-06, so I am going to close them: Ticket #34: Erratum 1820: "forwarding" is used instead of "list" Ticket #52: G.7.14. Abstract Update Text for the following ticket was agreed and a draft proposal appears in 06: Ticket #53: G.7.15 Informative References to MIME and/or Message Submission I will close it once 07 is published to fully implement it. For more details see Best Regards, Alexey --------------uaOL8iXDbRpNdLTGWqsU4TY4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi,

Text for the following tickets was implemented in rfc5321bis-06, so I am going to close them:


Ticket #34: Erratum 1820: "forwarding" is used instead of "list"

Ticket #52: G.7.14. Abstract Update


Text for the following ticket was agreed and a draft proposal appears in 06:

Ticket #53: G.7.15 Informative References to MIME and/or Message Submission

I will close it once 07 is published to fully implement it.

For more details see <https://datatracker.ietf.org/meeting/112/materials/slides-112-emailcore-chairs-slides-03.pdf>


Best Regards,

Alexey

--------------uaOL8iXDbRpNdLTGWqsU4TY4-- From nobody Thu Nov 18 01:38: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 182433A083E for ; Thu, 18 Nov 2021 01:38:17 -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_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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=FjNd24Kf; dkim=pass (1152-bit key) header.d=tana.it header.b=AoeDa+Yd 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 s25Oiz5FNGpO for ; Thu, 18 Nov 2021 01:38: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 D9D823A0929 for ; Thu, 18 Nov 2021 01:37:32 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1637228247; bh=szpBUCT1TMYLJ2GaneScOl95p/ig5YJTcFvkaLJGTRc=; l=759; h=Subject:To:References:From:Date:In-Reply-To; b=FjNd24KfnmE2B9pcxVi4FnGgQHt+031enU2NBXzPKWTywXZEPgtixsJ3AwNZbcVSU ymPZ8kmH2HAjUb57ok2DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1637228247; bh=szpBUCT1TMYLJ2GaneScOl95p/ig5YJTcFvkaLJGTRc=; l=759; h=To:References:From:Date:In-Reply-To; b=AoeDa+Yd5dvqYVrdO7My9/2o+y5Rg/TlKgPh8PYbHc8QCufjkUzb7Qovuf4bmXZ11 DMONwZtMXbJTFsSgKHgptKTVna+Yv8C1DIt6BMpVOe8Ra7dvscwb4oP/TmMTaYTKg+ GklE+GMfFjNBnZWjMtuKplbdlQUAlxIPiiC9eBtFT0o8vfYCs86B9dcZf2dAr 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 00000000005DC033.0000000061961ED7.00002A6C; Thu, 18 Nov 2021 10:37:27 +0100 To: emailcore@ietf.org References: <6ce394dd-9b42-cd6e-3c17-93245efa30d7@isode.com> From: Alessandro Vesely Message-ID: <60ee58f1-28f5-7050-b605-53c58a9e0647@tana.it> Date: Thu, 18 Nov 2021 10:37:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <6ce394dd-9b42-cd6e-3c17-93245efa30d7@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Forwarding, was Closing tickets: ... #34 ... 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 Nov 2021 09:38:17 -0000 Hi all, On Wed 17/Nov/2021 17:59:25 +0100 Alexey Melnikov wrote: > Text for the following tickets was implemented in rfc5321bis-06, so I am going > to close them: > > > Ticket #34: Erratum 1820: "forwarding" is used instead of "list" As the reporter of erratum 1820 in July 2009, I'm happy it has finally been addressed. It reminds me of the doubts about the term "forwarding" that have been bewildering my mind ever since: * Why isn't Section 3.9 called "Forwarding" rather than Aliases and Lists? * Why isn't section 3.4 a subsection of 3.9, then? * Why doesn't it use the phrase "email address portability"? * Doesn't the lost paragraph of 4.4.1 ([JcK/Alexey 20211104]) belong here as well? * Hmm... Doubtfully Ale -- From nobody Wed Nov 24 05: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 E74B63A048D for ; Wed, 24 Nov 2021 05:07:12 -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, 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 EbdyEOIbhjbn for ; Wed, 24 Nov 2021 05:07:08 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0233A03EE for ; Wed, 24 Nov 2021 05:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637759223; d=isode.com; s=june2016; i=@isode.com; bh=9UHHYuqQ8u5FAOYRxaf5Qum9lAFRUZCaM9nRJg+urLo=; 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=kxS+NRKzE+vCn8cyqIgtt7Gspt/7nlCIElG4xUGz7tWn+oNjQFY9wwZZPMVIBJNGUCbO2/ +NUQLt2UTobzE3OoqVj/1tkiz86X5H/lkiVpu+0Yo93p9pUckZAg7EQdUR7ZkzO+6VFDDd 94g/pkbd+fXBjHdwnjqDWTqX6Sn2unc=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Nov 2021 13:07:03 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4b7ad9c2-1ce6-6e6c-293d-ea0953c7e996@isode.com> Date: Wed, 24 Nov 2021 13:07:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 To: emailcore@ietf.org From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #17: proposed changes to remove source routes 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 Nov 2021 13:07:17 -0000 Hi all, I've listened to the EMAILCORE session recording from IETF 112 and below=20 is my best suggestion on how to resolve this ticket: 1) The last sentence of Section 2.1. (Basic Structure): =C2=A0=C2=A0=C2=A0 Explicit "source" routing (see Section 5 and Appendix C = and=20 Appendix F.2) SHOULD NOT be used. Suggestion: at the discretion of the editor: either delete the whole=20 sentence (might not be needed in this section) or reword it to make it=20 clear that thee feature is deprecated: =C2=A0=C2=A0=C2=A0 Explicit "source" routing (see Appendix F.2) MUST NOT be= used. 2) 5th paragraph of Section 3.3. (Mail Transactions): =C2=A0=C2=A0=C2=A0 Historically, the was permitted to contai= n more than =C2=A0=C2=A0=C2=A0 just a mailbox; however, contemporary systems SHOULD NOT= use source =C2=A0=C2=A0=C2=A0 routing (see Appendix C). Suggested replacement: =C2=A0=C2=A0=C2=A0 Historically, the was permitted to contai= n more than =C2=A0=C2=A0=C2=A0 just a mailbox; however, source routing is now deprecate= d (see=20 Appendix F.2). 3) 9th paragraph of Section 3.3. (Mail Transactions): =C2=A0=C2=A0=C2=A0 The can contain more than just a mailbox. =C2=A0=C2=A0=C2=A0 Historically, the was permitted to contai= n a source =C2=A0=C2=A0=C2=A0 routing list of hosts and the destination mailbox; howev= er, =C2=A0=C2=A0=C2=A0 contemporary SMTP clients SHOULD NOT utilize source rout= es (see =C2=A0=C2=A0=C2=A0 Appendix C).=C2=A0 Servers MUST be prepared to encounter= a list of source =C2=A0=C2=A0=C2=A0 routes in the forward-path, but they SHOULD ignore the r= outes or MAY =C2=A0=C2=A0=C2=A0 decline to support the relaying they imply.=C2=A0 Simila= rly, servers MAY =C2=A0=C2=A0=C2=A0 decline to accept mail that is destined for other hosts = or systems. =C2=A0=C2=A0=C2=A0 These restrictions make a server useless as a relay for = clients that =C2=A0=C2=A0=C2=A0 do not support full SMTP functionality. Suggestion: either drop the beginning of this paragraph (up to this=20 point) or replace it with something like this if the historic note is=20 desirable: =C2=A0=C2=A0=C2=A0 Historically, the was permitted to contai= n a source =C2=A0=C2=A0=C2=A0 routing list of hosts and the destination mailbox; howev= er, =C2=A0=C2=A0=C2=A0 source routes (see Appendix F.2) are now deprecated. The remainder of the paragraph probably need to be tweaked a bit: =C2=A0=C2=A0=C2=A0 Consequently, restricted- =C2=A0=C2=A0=C2=A0 capability clients MUST NOT assume that any SMTP server = on the =C2=A0=C2=A0=C2=A0 Internet can be used as their mail processing (relaying)= site.=C2=A0 If a =C2=A0=C2=A0=C2=A0 RCPT command appears without a previous MAIL command, th= e server MUST =C2=A0=C2=A0=C2=A0 return a 503 "Bad sequence of commands" response.=C2=A0 = The optional =C2=A0=C2=A0=C2=A0 are associated with negotiated SMTP se= rvice =C2=A0=C2=A0=C2=A0 extensions (see Section 2.2). I would drop "Consequently" above, but the rest is probably Ok as is. 4) Section 3.6.1. (Source Routes and Relaying) Suggestion to drop the whole section. It is not referenced anywhere else=20 anyway. 5) 2nd and 3rd paragraphs of Section 4.1.1.3 (RECIPIENT (RCPT)): =C2=A0=C2=A0=C2=A0 The forward-path normally consists of the required desti= nation =C2=A0 =C2=A0 mailbox.=C2=A0 Sending systems SHOULD NOT generate the option= al list of =C2=A0=C2=A0=C2=A0 hosts known as a source route.=C2=A0 Receiving systems M= UST recognize =C2=A0=C2=A0=C2=A0 source route syntax but SHOULD strip off the source rout= e =C2=A0=C2=A0=C2=A0 specification and utilize the domain name associated wit= h the mailbox =C2=A0 =C2=A0 as if the source route had not been provided. =C2=A0=C2=A0=C2=A0 Similarly, relay hosts SHOULD strip or ignore source rou= tes, and =C2=A0 =C2=A0 names MUST NOT be copied into the reverse-path.=C2=A0 When ma= il reaches =C2=A0=C2=A0=C2=A0 its ultimate destination (the forward-path contains only= a =C2=A0=C2=A0=C2=A0 destination mailbox), the SMTP server inserts it into th= e destination =C2=A0=C2=A0=C2=A0 mailbox in accordance with its host mail conventions. Suggested replacement (single paragraph): =C2=A0=C2=A0=C2=A0 The forward-path consists of the required destination =C2=A0 =C2=A0 mailbox.=C2=A0=C2=A0 When mail reaches =C2=A0=C2=A0=C2=A0 its ultimate destination, the SMTP server inserts it int= o the=20 destination =C2=A0=C2=A0=C2=A0 mailbox in accordance with its host mail conventions. 6) Section 4.1.2.=C2=A0 Command Argument Syntax 2nd sentence of the 1st paragraph: =C2=A0=C2=A0 Some of the productions given below are used only in conjuncti= on with =C2=A0=C2=A0 source routes as described in Appendix C. Suggestion: remove. =C2=A0=C2=A0=C2=A0 Path =3D "<" [ A-d-l ":" ] Mailbox ">" Suggestion: =C2=A0=C2=A0=C2=A0 Path =3D "<" Mailbox ">" And finally: =C2=A0=C2=A0 A-d-l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D At-domain *( "," At-domain ) =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 ; Note that this form, the so-called "source =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 ; route", MUST BE accepted, SHOULD NOT be =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 ; generated, and SHOULD be ignored. Suggestion: remove. 7) In Section 6.1.=C2=A0 Reliable Delivery and Replies by Email Last sentence of the 2nd paragraph: =C2=A0=C2=A0 If the address is an explicit source route, it MUST be strippe= d down to =C2=A0=C2=A0 its final hop. And the following paragraph: =C2=A0=C2=A0 For example, suppose that an error notification must be sent f= or a =C2=A0=C2=A0 message that arrived with: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAIL FROM:<@a,@b:user@d> =C2=A0=C2=A0 The notification message MUST be sent using: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RCPT TO: Suggestion: delete both, unless a reference to RFC 821 is desired here. 8) Appendix C.=C2=A0 Source Routes Suggestion to delete the appendix. Appendix F.2 is a better place,=20 because Appendix F is "Deprecated Features of RFC 821". Some text from Appendix C cane be used for Appendix F.2 rewrite. 9) Appendix F.2 Source Routing Replace text with a pointer to RFC 821. Best Regards, Alexey From nobody Wed Nov 24 05:28: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 A82213A043F for ; Wed, 24 Nov 2021 05:28:06 -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, 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 8lHwORy4IosX for ; Wed, 24 Nov 2021 05:28:04 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 199683A043D for ; Wed, 24 Nov 2021 05:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637760482; d=isode.com; s=june2016; i=@isode.com; bh=ivwPs4Z0w7AXFYoiWP9nVkStk85HaKCsBJi4pVEFwWA=; 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=XuDRPm7sRxJ1Cv+pg4NGnAG16Z+xiQjB3aNrnyFoRqIw+cQLOtF3skJaNCPZj1MLUKFBcG NXVBvvweLST/W8u7Vg2awzazL1S6UWUIbswAlDDcBPP4AYaGdEVCvAjTlnpynxKER3TAPY CC0uSQulSGtSG5hwJPW4kVZWMOQutnQ=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Nov 2021 13:28:02 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: Date: Wed, 24 Nov 2021 13:28:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 To: emailcore@ietf.org, John C Klensin From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings 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 Nov 2021 13:28:07 -0000 Hi all, Based on IETF 112 discussion I suggest the following changes to address=20 this ticket: In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the=20 ABNF syntax reads: =C2=A0=C2=A0 While the above definition for Local-part is relatively permis= sive, =C2=A0=C2=A0 for maximum interoperability, a host that expects to receive m= ail =C2=A0=C2=A0 SHOULD avoid defining mailboxes where the Local-part requires = (or =C2=A0=C2=A0 uses) the Quoted-string form or where the Local-part is case- =C2=A0=C2=A0 sensitive. For any purposes that require generating or compari= ng =C2=A0=C2=A0 Local-parts (e.g., to specific mailbox names), all quoted form= s MUST =C2=A0=C2=A0 be treated as equivalent, and the sending system SHOULD transm= it the =C2=A0=C2=A0 form that uses the minimum quoting possible. Suggestion to add to the end of the above paragraph: =C2=A0=C2=A0 For example, the following 3 Local-parts are semantically equi= valent =C2=A0=C2=A0 and must compare equal: "ab cd ef", "ab\ cd ef" and "ab\ \cd e= f". =C2=A0=C2=A0 Similarly, "fred" and fred must compare equal. White space red= uction =C2=A0=C2=A0 MUST NOT be applied to Local-part by intermediate systems. (John, I think your were not quite happy with "semantically equivalent",=20 but "syntactically equivalent" is not right here, as all these forms and=20 not syntactically the same. I am happy for you to come up with better=20 wording.) In Section "4.1.2. Command Argument Syntax", the 3rd paragraph after the=20 ABNF: =C2=A0=C2=A0 Note that the backslash, "\", is a quote character, which is u= sed to =C2=A0=C2=A0 indicate that the next character is to be used literally (inst= ead of =C2=A0=C2=A0 its normal interpretation). For example, "Joe\,Smith" indicate= s a =C2=A0=C2=A0 single nine-character user name string with the comma being th= e =C2=A0=C2=A0 fourth character of that string. Suggestion to move it before the 1st paragraph after the ABNF (so that=20 it introduces \ escape character). Best Regards, Alexey From nobody Wed Nov 24 06:42: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 A62393A07B1 for ; Wed, 24 Nov 2021 06:42:36 -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 HGdvZiuoK0Z4 for ; Wed, 24 Nov 2021 06:42:32 -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 211B33A07AF for ; Wed, 24 Nov 2021 06:42:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6JLJ5CY0000MC42@mauve.mrochek.com> for emailcore@ietf.org; Wed, 24 Nov 2021 06:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1637764647; bh=cbuiHjNf0Rxqagv6/Nbdn4C68gi63aorSgAr0Ih9530=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=bWo2zXNho7prqJriPkiU/5oFh6BHG8Ec8iivYF1hwLK5KeDRbsTbuhknQhgtYv2L3 iopWg8O9sACHCJcglsROWizSJBgID5tg3OcOEM8CC/+LKkp099vp/GBkhuqqpOEWHO +/qoo5E7Qu9uTzeh+hiL4y/MfHMuAmMNuZ++PP0Q= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6FNRL78ZK005PTU@mauve.mrochek.com>; Wed, 24 Nov 2021 06:37:25 -0800 (PST) Cc: emailcore@ietf.org, John C Klensin Message-id: <01S6JLJ2W2KM005PTU@mauve.mrochek.com> Date: Wed, 24 Nov 2021 06:29:08 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 24 Nov 2021 13:28:02 +0000" References: To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings 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 Nov 2021 14:42:37 -0000 > Hi all, > Based on IETF 112 discussion I suggest the following changes to address > this ticket: > In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the > ABNF syntax reads: >    While the above definition for Local-part is relatively permissive, >    for maximum interoperability, a host that expects to receive mail >    SHOULD avoid defining mailboxes where the Local-part requires (or >    uses) the Quoted-string form or where the Local-part is case- >    sensitive. For any purposes that require generating or comparing >    Local-parts (e.g., to specific mailbox names), all quoted forms MUST >    be treated as equivalent, and the sending system SHOULD transmit the >    form that uses the minimum quoting possible. > Suggestion to add to the end of the above paragraph: >    For example, the following 3 Local-parts are semantically equivalent >    and must compare equal: "ab cd ef", "ab\ cd ef" and "ab\ \cd ef". >    Similarly, "fred" and fred must compare equal. White space reduction >    MUST NOT be applied to Local-part by intermediate systems. OK... So what, exactly, is white space reduction? AFAICT the term doesn't appear elsewhere in the document. Clearly it's a bad thing because systems MUST NOT do it, so I think we need to be really clear as to what it is. If it refers to compressing whitespace out of local parts, then yes, I can agree that intermediate systems should not be doing that.. But if canonicalization from "fred" to fred is included, then (a) You need a different term, and (b) I'm not sure prohibiting submission servers - which are intermediate sytems - is necessarily a good idea. > (John, I think your were not quite happy with "semantically equivalent", > but "syntactically equivalent" is not right here, as all these forms and > not syntactically the same. I am happy for you to come up with better > wording.) I think "semantically equivalent" is about as good as it gets. Ned From nobody Wed Nov 24 06:52: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 2265E3A07A2 for ; Wed, 24 Nov 2021 06:52:27 -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 HVBlh3qCuuDe for ; Wed, 24 Nov 2021 06:52:24 -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 211963A07A0 for ; Wed, 24 Nov 2021 06:52:24 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6JLVECVJK00KKT2@mauve.mrochek.com> for emailcore@ietf.org; Wed, 24 Nov 2021 06:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1637765240; bh=Ra8sak6TJgW5z+8MvrPdCP6HFqsJ2bsTNzx7gSknBhI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=qXtMUJkqElvM6IaNDswGv1W9ZeabA94mpASA+Y1ALokm9Dv5vwxBaGNU2XazxAZxv WBoo+Ulb+OrLa10zcMsGBWmz4W177L0q3FmNkS1zsnC6JAhwVYQRfHETzggmhT4Q6g iq9jnS9QUWAIgkSl6THOi6mLJsj0QxvT0Q6cM0jg= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6FNRL78ZK005PTU@mauve.mrochek.com>; Wed, 24 Nov 2021 06:47:18 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01S6JLVCXT32005PTU@mauve.mrochek.com> Date: Wed, 24 Nov 2021 06:42:34 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 24 Nov 2021 13:07:02 +0000" <4b7ad9c2-1ce6-6e6c-293d-ea0953c7e996@isode.com> References: <4b7ad9c2-1ce6-6e6c-293d-ea0953c7e996@isode.com> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #17: proposed changes to remove source routes 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 Nov 2021 14:52:27 -0000 Comments inline. > Hi all, > I've listened to the EMAILCORE session recording from IETF 112 and below > is my best suggestion on how to resolve this ticket: > 1) The last sentence of Section 2.1. (Basic Structure): >     Explicit "source" routing (see Section 5 and Appendix C and > Appendix F.2) SHOULD NOT be used. > Suggestion: at the discretion of the editor: either delete the whole > sentence (might not be needed in this section) or reword it to make it > clear that thee feature is deprecated: >     Explicit "source" routing (see Appendix F.2) MUST NOT be used. I think dropping the whole sentence is better. Less is more here. > 2) 5th paragraph of Section 3.3. (Mail Transactions): >     Historically, the was permitted to contain more than >     just a mailbox; however, contemporary systems SHOULD NOT use source >     routing (see Appendix C). > Suggested replacement: >     Historically, the was permitted to contain more than >     just a mailbox; however, source routing is now deprecated (see > Appendix F.2). WFM. > 3) 9th paragraph of Section 3.3. (Mail Transactions): >     The can contain more than just a mailbox. >     Historically, the was permitted to contain a source >     routing list of hosts and the destination mailbox; however, >     contemporary SMTP clients SHOULD NOT utilize source routes (see >     Appendix C).  Servers MUST be prepared to encounter a list of source >     routes in the forward-path, but they SHOULD ignore the routes or MAY >     decline to support the relaying they imply.  Similarly, servers MAY >     decline to accept mail that is destined for other hosts or systems. >     These restrictions make a server useless as a relay for clients that >     do not support full SMTP functionality. > Suggestion: either drop the beginning of this paragraph (up to this > point) or replace it with something like this if the historic note is > desirable: >     Historically, the was permitted to contain a source >     routing list of hosts and the destination mailbox; however, >     source routes (see Appendix F.2) are now deprecated. WFM. > The remainder of the paragraph probably need to be tweaked a bit: >     Consequently, restricted- >     capability clients MUST NOT assume that any SMTP server on the >     Internet can be used as their mail processing (relaying) site.  If a >     RCPT command appears without a previous MAIL command, the server MUST >     return a 503 "Bad sequence of commands" response.  The optional >     are associated with negotiated SMTP service >     extensions (see Section 2.2). > I would drop "Consequently" above, but the rest is probably Ok as is. WFM. > 4) Section 3.6.1. (Source Routes and Relaying) > Suggestion to drop the whole section. It is not referenced anywhere else > anyway. Strongly agree. > 5) 2nd and 3rd paragraphs of Section 4.1.1.3 (RECIPIENT (RCPT)): >     The forward-path normally consists of the required destination >     mailbox.  Sending systems SHOULD NOT generate the optional list of >     hosts known as a source route.  Receiving systems MUST recognize >     source route syntax but SHOULD strip off the source route >     specification and utilize the domain name associated with the mailbox >     as if the source route had not been provided. >     Similarly, relay hosts SHOULD strip or ignore source routes, and >     names MUST NOT be copied into the reverse-path.  When mail reaches >     its ultimate destination (the forward-path contains only a >     destination mailbox), the SMTP server inserts it into the destination >     mailbox in accordance with its host mail conventions. > Suggested replacement (single paragraph): >     The forward-path consists of the required destination >     mailbox.   When mail reaches >     its ultimate destination, the SMTP server inserts it into the > destination >     mailbox in accordance with its host mail conventions. WFM. > 6) Section 4.1.2.  Command Argument Syntax > 2nd sentence of the 1st paragraph: >    Some of the productions given below are used only in conjunction with >    source routes as described in Appendix C. > Suggestion: remove. >     Path = "<" [ A-d-l ":" ] Mailbox ">" > Suggestion: >     Path = "<" Mailbox ">" > And finally: >    A-d-l          = At-domain *( "," At-domain ) >                   ; Note that this form, the so-called "source >                   ; route", MUST BE accepted, SHOULD NOT be >                   ; generated, and SHOULD be ignored. > Suggestion: remove. All of this seems fine. > 7) In Section 6.1.  Reliable Delivery and Replies by Email > Last sentence of the 2nd paragraph: >    If the address is an explicit source route, it MUST be stripped down to >    its final hop. > And the following paragraph: >    For example, suppose that an error notification must be sent for a >    message that arrived with: >       MAIL FROM:<@a,@b:user@d> >    The notification message MUST be sent using: >       RCPT TO: > Suggestion: delete both, unless a reference to RFC 821 is desired here. WFM. > 8) Appendix C.  Source Routes > Suggestion to delete the appendix. Appendix F.2 is a better place, > because Appendix F is "Deprecated Features of RFC 821". Dropping it is better, because this is really about how to use source routes, and we don't need to talk about that. > Some text from Appendix C cane be used for Appendix F.2 rewrite. > 9) Appendix F.2 Source Routing > Replace text with a pointer to RFC 821. I think keeping the first paragraph makes sense, but the second and third definitely need to go. Ned > Best Regards, > Alexey > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Wed Nov 24 06:54: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 DF5433A07B7 for ; Wed, 24 Nov 2021 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 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=-1.852, 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 YdiGOWzf8ZPW for ; Wed, 24 Nov 2021 06:54:04 -0800 (PST) Received: from cornsilk.ash.relay.mailchannels.net (cornsilk.ash.relay.mailchannels.net [23.83.222.40]) (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 EAE073A07A2 for ; Wed, 24 Nov 2021 06:54:00 -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 DF8768C1373 for ; Wed, 24 Nov 2021 14:53:55 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 853F48C10C0 for ; Wed, 24 Nov 2021 14:53:53 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.120.81.154 (trex/6.4.3); Wed, 24 Nov 2021 14:53:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Suffer-Battle: 119c55ab570e0246_1637765634432_2085578701 X-MC-Loop-Signature: 1637765634432:2295217721 X-MC-Ingress-Time: 1637765634431 Received: from [192.168.0.109] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4HzkXv6CgPz7bYZY for ; Wed, 24 Nov 2021 14:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1637765631; bh=xtHNflgejzZjy3zydAWKThHTiXiLvRwxbULwhGbwdnw=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=CHWfdmvhVCLyxxIg0mKmwCXd6ZTQeegrSGHSdmh3uM9FtqdbjJxuxRWc3hD+NZ9mB u1LbXWU/gov3z5SNPtoIDspp+k7Tw772N+DYQZ59msYrjME3pfm32UrPsvmUeGV6gW Tt+0smf7RyYQUMAbC1biTzocZ+iZ7LLNmpTBVWt9qH4dmVMCi0gbOfO8p65dNDkxUn /my9FzUz1MtiZ/LO1tqQqZ/FQo4GE9Tm/iPtlaZJeIAH9vTWHquCwagVhJ6llhFxku f2jFie05p7HFG5pqu5ejJjBou9vyxe3Pb1/4JfqN8hNWxLr/adrZpJpa3ljQ0SomhY 5HZbytcfCSG8g== Message-ID: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> Date: Wed, 24 Nov 2021 06:53:50 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings 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 Nov 2021 14:54:10 -0000 On 11/24/2021 5:28 AM, Alexey Melnikov wrote: > Hi all, > > Based on IETF 112 discussion I suggest the following changes to address > this ticket: > > In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the > ABNF syntax reads: > >    While the above definition for Local-part is relatively permissive, >    for maximum interoperability, a host that expects to receive mail >    SHOULD avoid defining mailboxes where the Local-part requires (or >    uses) the Quoted-string form or where the Local-part is case- >    sensitive. For any purposes that require generating or comparing >    Local-parts (e.g., to specific mailbox names), all quoted forms MUST >    be treated as equivalent, and the sending system SHOULD transmit the >    form that uses the minimum quoting possible. 1. The concept of 'expects to receive mail' seems a bit odd. It implies that we support the circulation of email addresses that don't work. If there is a benefit in having an Internet standard for email that defines an email address that isn't valid, what is it? Otherwise, I suggest dropping this qualifier. 2. The 'SHOULD' language could be simpler and more direct. So, perhaps: For maximum interoperability, a Local-part SHOULD NOT be defined using the Quoted-string form and SHOULD NOT have a Local-part that is case-dependent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Nov 28 17:43: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 052433A05C7 for ; Sun, 28 Nov 2021 17:43:27 -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 A7S7NzlzC8W0 for ; Sun, 28 Nov 2021 17:43:22 -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 646733A0768 for ; Sun, 28 Nov 2021 17:43:21 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mrVhP-000LVJ-7Z; Sun, 28 Nov 2021 20:43:19 -0500 Date: Sun, 28 Nov 2021 20:43:12 -0500 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org Message-ID: <5F41652C92E018BA75BBC57B@PSB> In-Reply-To: References: 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 #21: G.9. Revisiting Quoted Strings 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, 29 Nov 2021 01:43:38 -0000 --On Wednesday, November 24, 2021 13:28 +0000 Alexey Melnikov wrote: > Hi all, >=20 > Based on IETF 112 discussion I suggest the following changes > to address this ticket: >=20 > In Section "4.1.2. Command Argument Syntax", the 1st paragraph > after the ABNF syntax reads: >=20 > =C2=A0=C2=A0 While the above definition for Local-part is = relatively > permissive, > =C2=A0=C2=A0 for maximum interoperability, a host that = expects to > receive mail > =C2=A0=C2=A0 SHOULD avoid defining mailboxes where the = Local-part > requires (or > =C2=A0=C2=A0 uses) the Quoted-string form or where the = Local-part is > case- > =C2=A0=C2=A0 sensitive. For any purposes that require = generating or > comparing > =C2=A0=C2=A0 Local-parts (e.g., to specific mailbox names), = all > quoted forms MUST > =C2=A0=C2=A0 be treated as equivalent, and the sending system = SHOULD > transmit the > =C2=A0=C2=A0 form that uses the minimum quoting possible. > Suggestion to add to the end of the above paragraph: >=20 > =C2=A0=C2=A0 For example, the following 3 Local-parts are > semantically equivalent > =C2=A0=C2=A0 and must compare equal: "ab cd ef", "ab\ cd ef" = and "ab\ > \cd ef". > =C2=A0=C2=A0 Similarly, "fred" and fred must compare equal. = White > space reduction > =C2=A0=C2=A0 MUST NOT be applied to Local-part by = intermediate > systems. >=20 > (John, I think your were not quite happy with "semantically > equivalent", but "syntactically equivalent" is not right here, > as all these forms and not syntactically the same. I am happy > for you to come up with better wording.) Above added as written except, for consistency, I believe the first "must" should be a "MUST" and have tentatively made that change. My only suggestion for better wording is to not qualify "equivalent" at all, e.g., to just say "local-parts are equivalent and..." or even "local-parts are equivalent under the quoting rules and..." =20 > In Section "4.1.2. Command Argument Syntax", the 3rd paragraph > after the ABNF: >=20 > =C2=A0=C2=A0 Note that the backslash, "\", is a quote = character, > which is used to > =C2=A0=C2=A0 indicate that the next character is to be used = literally > (instead of > =C2=A0=C2=A0 its normal interpretation). For example, = "Joe\,Smith" > indicates a > =C2=A0=C2=A0 single nine-character user name string with the = comma > being the > =C2=A0=C2=A0 fourth character of that string. >=20 > Suggestion to move it before the 1st paragraph after the ABNF > (so that it introduces \ escape character). Done. >=20 > Best Regards, >=20 > Alexey >=20 From nobody Sun Nov 28 19:23: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 CFF9A3A0B4F for ; Sun, 28 Nov 2021 19:23:18 -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 HLprtNaaBwMb for ; Sun, 28 Nov 2021 19:23:14 -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 0ACA93A0B4D for ; Sun, 28 Nov 2021 19:23:13 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mrXG2-000LcB-1E; Sun, 28 Nov 2021 22:23:10 -0500 Date: Sun, 28 Nov 2021 22:23:05 -0500 From: John C Klensin To: Ned Freed , Alexey Melnikov cc: emailcore@ietf.org Message-ID: <9D9E819E1D5523CEC90C74D0@PSB> In-Reply-To: <01S6JLVCXT32005PTU@mauve.mrochek.com> References: <4b7ad9c2-1ce6-6e6c-293d-ea0953c7e996@isode.com> <01S6JLVCXT32005PTU@mauve.mrochek.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 #17: proposed changes to remove source routes 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, 29 Nov 2021 03:23:19 -0000 --On Wednesday, November 24, 2021 06:42 -0800 Ned Freed wrote: > Comments inline. >=20 >> Hi all, >=20 >> I've listened to the EMAILCORE session recording from IETF >> 112 and below is my best suggestion on how to resolve this >> ticket: >=20 >> 1) The last sentence of Section 2.1. (Basic Structure): >=20 >> =C2=A0=C2=A0=C2=A0 Explicit "source" routing (see Section 5 = and Appendix >> C and Appendix F.2) SHOULD NOT be used. >=20 >> Suggestion: at the discretion of the editor: either delete >> the whole sentence (might not be needed in this section) or >> reword it to make it clear that thee feature is deprecated: >=20 >> =C2=A0=C2=A0=C2=A0 Explicit "source" routing (see Appendix = F.2) MUST NOT >> be used. >=20 > I think dropping the whole sentence is better. Less is more > here. Done. >> 2) 5th paragraph of Section 3.3. (Mail Transactions): >=20 >> =C2=A0=C2=A0=C2=A0 Historically, the was = permitted to >> contain more than =C2=A0=C2=A0=C2=A0 just a mailbox; = however, >> contemporary systems SHOULD NOT use source = =C2=A0=C2=A0=C2=A0 routing >> (see Appendix C). >=20 >> Suggested replacement: >=20 >> =C2=A0=C2=A0=C2=A0 Historically, the was = permitted to >> contain more than =C2=A0=C2=A0=C2=A0 just a mailbox; = however, source >> routing is now deprecated (see Appendix F.2). >=20 > WFM. Done. >> 3) 9th paragraph of Section 3.3. (Mail Transactions): >=20 >> =C2=A0=C2=A0=C2=A0 The can contain more than = just a >> mailbox. =C2=A0=C2=A0=C2=A0 Historically, the = was >> permitted to contain a source =C2=A0=C2=A0=C2=A0 routing = list of hosts >> and the destination mailbox; however, =C2=A0=C2=A0=C2=A0 = contemporary >> SMTP clients SHOULD NOT utilize source routes (see = =C2=A0=C2=A0=C2=A0 >> Appendix C).=C2=A0 Servers MUST be prepared to encounter a = list >> of source =C2=A0=C2=A0=C2=A0 routes in the forward-path, but = they SHOULD >> ignore the routes or MAY =C2=A0=C2=A0=C2=A0 decline to = support the >> relaying they imply.=C2=A0 Similarly, servers MAY = =C2=A0=C2=A0=C2=A0 decline >> to accept mail that is destined for other hosts or systems. >> =C2=A0=C2=A0=C2=A0 These restrictions make a server useless = as a relay >> for clients that =C2=A0=C2=A0=C2=A0 do not support full SMTP >> functionality. >=20 >> Suggestion: either drop the beginning of this paragraph (up >> to this point) or replace it with something like this if the >> historic note is desirable: >=20 >> =C2=A0=C2=A0=C2=A0 Historically, the was = permitted to >> contain a source =C2=A0=C2=A0=C2=A0 routing list of hosts = and the >> destination mailbox; however, =C2=A0=C2=A0=C2=A0 source = routes (see >> Appendix F.2) are now deprecated. >=20 > WFM. >=20 >> The remainder of the paragraph probably need to be tweaked a >> bit: >=20 >> =C2=A0=C2=A0=C2=A0 Consequently, restricted- >> =C2=A0=C2=A0=C2=A0 capability clients MUST NOT assume that = any SMTP >> server on the =C2=A0=C2=A0=C2=A0 Internet can be used as = their mail >> processing (relaying) site.=C2=A0 If a =C2=A0=C2=A0=C2=A0 = RCPT command >> appears without a previous MAIL command, the server MUST >> =C2=A0=C2=A0=C2=A0 return a 503 "Bad sequence of commands" = response.=C2=A0 >> The optional =C2=A0=C2=A0=C2=A0 are = associated with >> negotiated SMTP service =C2=A0=C2=A0=C2=A0 extensions (see = Section 2.2). >=20 >> I would drop "Consequently" above, but the rest is probably >> Ok as is. >=20 > WFM. Done. >> 4) Section 3.6.1. (Source Routes and Relaying) >=20 >> Suggestion to drop the whole section. It is not referenced >> anywhere else anyway. >=20 > Strongly agree. Done >> 5) 2nd and 3rd paragraphs of Section 4.1.1.3 (RECIPIENT >> (RCPT)): >=20 >> =C2=A0=C2=A0=C2=A0 The forward-path normally consists of the = required >> destination =C2=A0 =C2=A0 mailbox.=C2=A0 Sending systems = SHOULD NOT >> generate the optional list of =C2=A0=C2=A0=C2=A0 hosts known = as a source >> route.=C2=A0 Receiving systems MUST recognize = =C2=A0=C2=A0=C2=A0 source >> route syntax but SHOULD strip off the source route = =C2=A0=C2=A0=C2=A0 >> specification and utilize the domain name associated with >> the mailbox =C2=A0 =C2=A0 as if the source route had not = been >> provided. >=20 >> =C2=A0=C2=A0=C2=A0 Similarly, relay hosts SHOULD strip or = ignore source >> routes, and =C2=A0 =C2=A0 names MUST NOT be copied into the >> reverse-path.=C2=A0 When mail reaches =C2=A0=C2=A0=C2=A0 its = ultimate >> destination (the forward-path contains only a = =C2=A0=C2=A0=C2=A0 >> destination mailbox), the SMTP server inserts it into the >> destination =C2=A0=C2=A0=C2=A0 mailbox in accordance with = its host mail >> conventions. >=20 >> Suggested replacement (single paragraph): >=20 >> =C2=A0=C2=A0=C2=A0 The forward-path consists of the required = destination >> =C2=A0 =C2=A0 mailbox.=C2=A0=C2=A0 When mail reaches >> =C2=A0=C2=A0=C2=A0 its ultimate destination, the SMTP server = inserts it >> into the destination >> =C2=A0=C2=A0=C2=A0 mailbox in accordance with its host mail = conventions. >=20 > WFM. I have put this in but have some issues with it. See CREF after that text. >=20 >> 6) Section 4.1.2.=C2=A0 Command Argument Syntax >=20 >> 2nd sentence of the 1st paragraph: >> =C2=A0=C2=A0 Some of the productions given below are used = only in >> conjunction with =C2=A0=C2=A0 source routes as described in = Appendix >> C. >=20 >> Suggestion: remove. >=20 >> =C2=A0=C2=A0=C2=A0 Path =3D "<" [ A-d-l ":" ] Mailbox ">" >=20 >> Suggestion: >=20 >> =C2=A0=C2=A0=C2=A0 Path =3D "<" Mailbox ">" >=20 >> And finally: >=20 >> =C2=A0=C2=A0 = A-d-l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D = At-domain *( "," At-domain ) >> = =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 ; Note that this form, >> the so-called "source = =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 ; >> route", MUST BE accepted, SHOULD NOT be >> = =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 ; generated, and SHOULD >> be ignored. >=20 >> Suggestion: remove. >=20 > All of this seems fine. Done. We probably need to review whether Appendix F.2 (the remaining discussion of source routing) needs the syntax we just removed. b >> 7) In Section 6.1.=C2=A0 Reliable Delivery and Replies by = Email >=20 >> Last sentence of the 2nd paragraph: >=20 >> =C2=A0=C2=A0 If the address is an explicit source route, it = MUST be >> stripped down to =C2=A0=C2=A0 its final hop. >=20 >> And the following paragraph: >=20 >> =C2=A0=C2=A0 For example, suppose that an error notification = must be >> sent for a =C2=A0=C2=A0 message that arrived with: >=20 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAIL FROM:<@a,@b:user@d> >=20 >> =C2=A0=C2=A0 The notification message MUST be sent using: >=20 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RCPT TO: >=20 >> Suggestion: delete both, unless a reference to RFC 821 is >> desired here. >=20 > WFM. Done. Again, we may need to do some rewriting on F.2, but whatever we have to say should probably be there. >> 8) Appendix C.=C2=A0 Source Routes >=20 >> Suggestion to delete the appendix. Appendix F.2 is a better >> place, because Appendix F is "Deprecated Features of RFC = 821". >=20 > Dropping it is better, because this is really about how to use > source > routes, and we don't need to talk about that. Agreed and... >> Some text from Appendix C cane be used for Appendix F.2 >> rewrite. This is where I was headed above. Appendix is going to need to be rewriten. >> 9) Appendix F.2 Source Routing >=20 >> Replace text with a pointer to RFC 821. >=20 > I think keeping the first paragraph makes sense, but the > second and third definitely need to go. I need to take a careful look at this before making a recommendation. Up to the chairs as to whether I do that before posting -07, but it won't be within the next several days. In particular, while I don't think I've seen one of these turkeys in the wild in this century and gather from the list discussion that none of the rest of you have either, some of the text we just took out makes suggestions about appropriate reply codes if they are encountered -- suggestions that are, for obvious reasons, not present in RFC 821. So I'm a little reluctant to throw information away, leaving the implementer with no guidance at all other than that they are deprecated and, if one shows up or a use case arises, they are are on their own with not even suggestions to treat them as syntax errors. best, john From nobody Tue Nov 30 07:49: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 D3F3D3A13C2 for ; Tue, 30 Nov 2021 07:49:00 -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 KSER4BPId-Ol for ; Tue, 30 Nov 2021 07:48:55 -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 D06A63A13BE for ; Tue, 30 Nov 2021 07:48:51 -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 17AA18817BB for ; Tue, 30 Nov 2021 15:48:49 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 44DA28813A9 for ; Tue, 30 Nov 2021 15:48:45 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (gcp-us-central1-a-smtpout1.hostinger.io [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.100.11.72 (trex/6.4.3); Tue, 30 Nov 2021 15:48:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Tasty-Scare: 25eb58560ba59d86_1638287328870_2865409480 X-MC-Loop-Signature: 1638287328870:3255033692 X-MC-Ingress-Time: 1638287328870 Received: from [192.168.0.101] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4J3RTS1hc7z2d9b8 for ; Tue, 30 Nov 2021 15:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638287324; bh=J1/KFOnLLHArngDxZrBAYwVNWWYZpNMwd+Id3UOksV8=; h=Date:Subject:Reply-To:References:From:To:In-Reply-To; b=rLuKrUjnzNSlq8cGZPIU0EcBK65NpEfUConzquBvPuPleILjy6N0Fz9py20PRZ1uo sw08M4NlosZMq7e3T2MxVkFlZlK69d9rz/SFXP3ZkeiFwhq7LCVngqYKTldzzWDDtG IEThdNJtTiE64SvEsongNBbhT1VpgfJbuShG10ewsF6BEv/JqB+QG2DrVmlQFjGZRf LjqPmcoDG6iq+CNXtY2Ka+yPfPomW346W7v26oTTAX0xYGKRXX49a6/fbz4FYAvEEm W/tgVhC9Joctxl9NhZFqpqRZipWACUh8ctXSVKl+2N1jsuaKnDBWDDbNxfjzRzirnL 8h+SeerEUJFzw== Message-ID: Date: Tue, 30 Nov 2021 07:48:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US Reply-To: dcrocker@bbiw.net References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> From: Dave Crocker To: "emailcore@ietf.org" Organization: Brandenburg InternetWorking In-Reply-To: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> X-Forwarded-Message-Id: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] Fwd: Ticket #21: G.9. Revisiting Quoted Strings 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, 30 Nov 2021 15:49:01 -0000 Haven't seen a response to this... -------- Forwarded Message -------- Subject: Re: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings Date: Wed, 24 Nov 2021 06:53:50 -0800 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: emailcore@ietf.org On 11/24/2021 5:28 AM, Alexey Melnikov wrote: > Hi all, > > Based on IETF 112 discussion I suggest the following changes to address > this ticket: > > In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the > ABNF syntax reads: > >    While the above definition for Local-part is relatively permissive, >    for maximum interoperability, a host that expects to receive mail >    SHOULD avoid defining mailboxes where the Local-part requires (or >    uses) the Quoted-string form or where the Local-part is case- >    sensitive. For any purposes that require generating or comparing >    Local-parts (e.g., to specific mailbox names), all quoted forms MUST >    be treated as equivalent, and the sending system SHOULD transmit the >    form that uses the minimum quoting possible. 1. The concept of 'expects to receive mail' seems a bit odd. It implies that we support the circulation of email addresses that don't work. If there is a benefit in having an Internet standard for email that defines an email address that isn't valid, what is it? Otherwise, I suggest dropping this qualifier. 2. The 'SHOULD' language could be simpler and more direct. So, perhaps: For maximum interoperability, a Local-part SHOULD NOT be defined using the Quoted-string form and SHOULD NOT have a Local-part that is case-dependent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Emailcore mailing list Emailcore@ietf.org https://www.ietf.org/mailman/listinfo/emailcore -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 30 09:50: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 81FB13A145A for ; Tue, 30 Nov 2021 09:50: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 dX30YZxmhpI9 for ; Tue, 30 Nov 2021 09:50:47 -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 9F1C03A1454 for ; Tue, 30 Nov 2021 09:50:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6S5UNAO1S00K7XV@mauve.mrochek.com> for emailcore@ietf.org; Tue, 30 Nov 2021 09:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1638294343; bh=m7u7i+hpj6xCkhqsrKGitQCAp9pniPqUPvbM3FmploM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ebzSaG8u203aviJTx2H8oqW2aKMP4xKFAnM916ArHizU+HUEHAeZyTS2P1IMosfWg VPJVXoHincS10AEwSIWMljQuU2cQu0CflY+JEFj/zW3qn7b96TNuw1mmFPGBk56HR8 EUfuVevkOso5lPWgBzv688CZrVWZA86vd4nB5VLw= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6R5W06CK000D1OX@mauve.mrochek.com>; Tue, 30 Nov 2021 09:45:41 -0800 (PST) Cc: "emailcore@ietf.org" Message-id: <01S6S5UKW87U00D1OX@mauve.mrochek.com> Date: Tue, 30 Nov 2021 07:59:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 30 Nov 2021 07:48:43 -0800" References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Fwd: Ticket #21: G.9. Revisiting Quoted Strings 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, 30 Nov 2021 17:50:53 -0000 > Haven't seen a response to this... > -------- Forwarded Message -------- > Subject: Re: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings > Date: Wed, 24 Nov 2021 06:53:50 -0800 > From: Dave Crocker > Reply-To: dcrocker@bbiw.net > Organization: Brandenburg InternetWorking > To: emailcore@ietf.org > On 11/24/2021 5:28 AM, Alexey Melnikov wrote: > > Hi all, > > > > Based on IETF 112 discussion I suggest the following changes to address > > this ticket: > > > > In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the > > ABNF syntax reads: > > > >    While the above definition for Local-part is relatively permissive, > >    for maximum interoperability, a host that expects to receive mail > >    SHOULD avoid defining mailboxes where the Local-part requires (or > >    uses) the Quoted-string form or where the Local-part is case- > >    sensitive. For any purposes that require generating or comparing > >    Local-parts (e.g., to specific mailbox names), all quoted forms MUST > >    be treated as equivalent, and the sending system SHOULD transmit the > >    form that uses the minimum quoting possible. > 1. The concept of 'expects to receive mail' seems a bit odd. It implies > that we support the circulation of email addresses that don't work. If > there is a benefit in having an Internet standard for email that defines > an email address that isn't valid, what is it? Otherwise, I suggest > dropping this qualifier. > 2. The 'SHOULD' language could be simpler and more direct. > So, perhaps: > For maximum interoperability, a Local-part SHOULD NOT be defined > using the Quoted-string form and SHOULD NOT have a Local-part that > is case-dependent. While I agree that the "expects to receive mail" phrase is odd and could stand to be replaced, this isn't the right text because it elides over the issue of quote equivalency. The original text appears to have been constructed with this in mind. My suggestion would be a smaller change along the lines of: While the above definition for Local-part is relatively permissive, for maximum interoperability, a mailbox SHOULD NOT be defined whose Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted    be treated as equivalent, and the sending system SHOULD transmit the    form that uses the minimum quoting possible. And FWIW, we absolutely do support the circulation of addresses that intentionally do not work. It's not like we have a choice: Non-replyable messages are quite common; the fact that we don't provide a standardized way to indicate such notwithstanding. Ned From nobody Tue Nov 30 11:10: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 7D3263A14CB for ; Tue, 30 Nov 2021 11:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 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=-1.852, 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 W-KnVSG7GbJN for ; Tue, 30 Nov 2021 11:10:50 -0800 (PST) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 441873A14D6 for ; Tue, 30 Nov 2021 11:10:49 -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 A03F5861F3E; Tue, 30 Nov 2021 19:10:47 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 69066861BB3; Tue, 30 Nov 2021 19:10:46 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.109.250.6 (trex/6.4.3); Tue, 30 Nov 2021 19:10:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shelf-Duck: 17ccdf776a214437_1638299447425_2562038245 X-MC-Loop-Signature: 1638299447425:3757851898 X-MC-Ingress-Time: 1638299447425 Received: from [192.168.0.101] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4J3WyW6Gysz7c0WD; Tue, 30 Nov 2021 19:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638299445; bh=EryrrIgeSvnZ+pijTT1pc7Dido4vuTLKaZrN726DJTM=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To; b=bRNj1Wt/BVNS38y6UHq6LDYD+K2yfo89Nn0JBBuNF+OSCoeEZcjHPiM4HGk7iS3YI hiywVRHsEhHJFp41sQ53mABkxMCuWYG0NAq7k1Wyzmf4cYfNaNMpuDlQDGoIV5V6sw aSU3F+w0MtYo6Y8aMYF4y3/rstKtxAHArSN2RfekzqK3hP+2r3KOK3KgTE18ZT6KD+ 2ShuJa26Hp8EY7EG3Lf/rTNl/tM6kNwk6mhAzZiO+Qn8XEpVRZTncYH4qDkNG537F3 SabXAYZx4SpwBwnXBIiytSMSw+d+++2rcZPGwusYdSo6YEsY5sds3D2KKp1xDFVfoG +eNN3Pjx68ixw== Message-ID: Date: Tue, 30 Nov 2021 11:10:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Ned Freed Cc: "emailcore@ietf.org" References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> <01S6S5UKW87U00D1OX@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <01S6S5UKW87U00D1OX@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Fwd: Ticket #21: G.9. Revisiting Quoted Strings 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, 30 Nov 2021 19:10:56 -0000 On 11/30/2021 7:59 AM, Ned Freed wrote: >> -0800 From: Dave Crocker Reply-To: >> dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: >> emailcore@ietf.org > >> On 11/24/2021 5:28 AM, Alexey Melnikov wrote: >>> While the above definition for Local-part is relatively >>> permissive, for maximum interoperability, a host that expects to >>> receive mail SHOULD avoid defining mailboxes where the Local-part >>> requires (or uses) the Quoted-string form or where the Local-part >>> is case- sensitive. For any purposes that require generating or >>> comparing Local-parts (e.g., to specific mailbox names), all >>> quoted forms >> MUST >>> be treated as equivalent, and the sending system SHOULD transmit >>> >> the >>> form that uses the minimum quoting possible. > >> 1. The concept of 'expects to receive mail' seems a bit odd. It >> implies that we support the circulation of email addresses that >> don't work. If there is a benefit in having an Internet standard >> for email that defines an email address that isn't valid, what is >> it? Otherwise, I suggest dropping this qualifier. > >> 2. The 'SHOULD' language could be simpler and more direct. > >> So, perhaps: > >> For maximum interoperability, a Local-part SHOULD NOT be defined >> using the Quoted-string form and SHOULD NOT have a Local-part that >> is case-dependent. > > While I agree that the "expects to receive mail" phrase is odd and > could stand to be replaced, this isn't the right text because it > elides over the issue of quote equivalency. The original text appears > to have been constructed with this in mind. My suggestion would be a > smaller change along the lines of: > > While the above definition for Local-part is relatively permissive, > for maximum interoperability, a mailbox SHOULD NOT be defined whose > Local-part requires (or uses) the Quoted-string form or where the > Local-part is case-sensitive. For any purposes that require > generating or comparing Local-parts (e.g., to specific mailbox > names), all quoted be treated as equivalent, and the sending system > SHOULD transmit the form that uses the minimum quoting possible. Almost wfm. A few editorial changes suggested... 1. The 'whose' and 'where' probably should be changed to use the same word, and since this isn't a person and it isn't a location, I'll suggest 'with'. 2. singular vs. plural -- I've come to believe that specification language tends to be simpler and clearer when sentences are made to refer to singular case, when reasonable. 3. The 'For any purpose" sentence reads at least awkwardly. In addition, I am not sure it means to tread quoting as equivalent when /generating/ a Local-part. 3. small typos fixed 4. ... > And FWIW, we absolutely do support the circulation of addresses that > intentionally do not work. It's not like we have a choice: > Non-replyable messages are quite common; the fact that we don't > provide a standardized way to indicate such notwithstanding. My concern is with the idea that syntactic differences might provide a signal about utility of the email address. The issue, then, is with the focus of the language. Embedding the operational concept of intentionally not-working, into this sort of deep, definition specification, is the problem. It isn't needed and I think it is ill-advised. Hence I'm glad that your version removed that potential distraction So... While the above definition for Local-part is relatively permissive, for maximum interoperability, a mailbox SHOULD NOT be defined with Local-part requiring (or using) the Quoted-string form or with the Local-part being case-sensitive. Further, when comparing a Local-part (e.g., to a specific mailbox name), all quoting SHOULD be treated as equivalent. A sending system SHOULD transmit the form that uses the minimum quoting possible. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net