From nobody Wed Dec 1 10:33:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB93A0A3E for ; Wed, 1 Dec 2021 10:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XPUDyTZ3yhf for ; Wed, 1 Dec 2021 10:33:18 -0800 (PST) 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 B6B253A09E2 for ; Wed, 1 Dec 2021 10:33:12 -0800 (PST) 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 C99B3ED96F for ; Wed, 1 Dec 2021 13:33:10 -0500 (EST) 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: Date: Wed, 1 Dec 2021 13:33:07 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <7D34A64D-0A9D-422A-8B0B-76902209CE40@dukhovni.org> References: To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) 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, 01 Dec 2021 18:33:26 -0000 > On 24 Nov 2021, at 8:28 am, Alexey Melnikov = wrote: >=20 > In Section "4.1.2. Command Argument Syntax", the 3rd paragraph after = the ABNF: >=20 > Note that the backslash, "\", is a quote character, which is used to > indicate that the next character is to be used literally (instead of > its normal interpretation). For example, "Joe\,Smith" indicates a > single nine-character user name string with the comma being the > fourth character of that string. The above does not strike me as a good example, because quoted string "Joe,Smith" needs no <\> to make the <,> an ordinary character. The normal interpretation of <,> in a quoted string is just literal. A better example would be either "...\"..." or "...\\...", because otherwise inside quotes almost nothing else needs escaping. Since quoted-pairs occur only inside quoted-strings, suggesting that commas need escaping looks more confusing than useful. --=20 Viktor. From nobody Thu Dec 2 02:53: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 556D83A103B for ; Thu, 2 Dec 2021 02:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=mkLjxoxD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FviIv8XX 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 3gZcRY7pSYYI for ; Thu, 2 Dec 2021 02:53:20 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EF53A1037 for ; Thu, 2 Dec 2021 02:53:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6F90E32009DB; Thu, 2 Dec 2021 05:53:16 -0500 (EST) Received: from imap42 ([10.202.2.92]) by compute4.internal (MEProxy); Thu, 02 Dec 2021 05:53:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=HWvj9lxnCR7UOPFdMPtB3p22gahSSbw PupKfXr5Zjek=; b=mkLjxoxDu6T1XXw7+43FQ7rHsN8ih5PpcGPv56nrMgfuWjn uzUwu10NZYo2YXP3ON77ICy+pus8HHXriQfOeC4q9PRVqOYmbvFxcbPRfrzEkxid FNJiaOoO/9ahIkVBwxRrtznOEVJiiWS+rfKLOrH8a+NG6P6kTuybu8dAzZ5lYgGC xG1X3Qw6GTCkdtr50sM+qsMUNmi/wfLu+qx5BS+IKHxQW0z13QufAS8cv270QpHk 4TFhVaOu6bOWUxcNJiEm2hjhTDPtHVfAXanlCXtwUZNglWFvZeQaD1CsY+MQ9Kiw LR9yhVE/FvS0tBTmTdKDbrpBfGKC962riJrIZMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HWvj9l xnCR7UOPFdMPtB3p22gahSSbwPupKfXr5Zjek=; b=FviIv8XXt+Fbt3eTghXbrk NmAryViFbqlaUahqdmZnwT9SDEdigc2oRt3QbLA9vCxECNlP5pgVa0nTDo13WluV cLffim0Rs5xXdRPEtT1fH9qX8TwK63RJS/nUE2WnVsLowPDeq3R4Pysr614kZN0i TuMjozdsTMiH6XcQ5TlxVvPIwFpKVfORjBeMxE75Ti23UVgZiqjYS+xJp1Bc6SlM xS0RAZ/X5yVb2gLMvLYUshofKAjmBmgSWU611/NckvNYyfnJMxUoCNCtR+EPgb7Z Xa1TuoHIpLlP7oDs4mXs16SrRtwa+7bKlJhLecIxF4PE9wr98azvuSRzd7k/BFTQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrieehgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfekiefg udfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E3792180078; Thu, 2 Dec 2021 05:53:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> In-Reply-To: References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> <01S6S5UKW87U00D1OX@mauve.mrochek.com> Date: Thu, 02 Dec 2021 10:52:54 +0000 From: "Alexey Melnikov" To: "Dave Crocker" , "Ned Freed" Cc: "emailcore@ietf.org" Content-Type: text/plain 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: Thu, 02 Dec 2021 10:53:26 -0000 Hi Dave/Ned, Catching up with this thread: On Tue, Nov 30, 2021, at 7:10 PM, Dave Crocker wrote: > 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. This is almost fine with me, except for one SHOULD. The "SHOULD be treated as equivalent" text is wrong (too weak), it has to be "MUST be treated as equivalent" as per the rest of this ticket. So with that in mind hopefully the last version: 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 MUST be treated as equivalent. A sending system SHOULD transmit the form that uses the minimum quoting possible. Best Regards, Alexey From nobody Thu Dec 2 07:28:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC73A07D0 for ; Thu, 2 Dec 2021 07:28:11 -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 DE77xvSbtZdt for ; Thu, 2 Dec 2021 07:28:06 -0800 (PST) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F2E3A0115 for ; Thu, 2 Dec 2021 07:28:05 -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 B56226229AD; Thu, 2 Dec 2021 15:28:01 +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 459A862281A; Thu, 2 Dec 2021 15:27:58 +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.105.57.104 (trex/6.4.3); Thu, 02 Dec 2021 15:28:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Thread-Drop: 3935ca766cf51b27_1638458881269_2040467901 X-MC-Loop-Signature: 1638458881269:1237795330 X-MC-Ingress-Time: 1638458881269 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 4J4fwT4SSdz2YsPw; Thu, 2 Dec 2021 15:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638458877; bh=KKkc4uUiyvpFOjKoBqjEL9u3bgLggZyusRXbzCT+r+I=; h=Date:Subject:To:Cc:References:From:Reply-To:In-Reply-To; b=G/XdZn2dzfArONMmvBVZfm/z1pc7gYNl9osDTdr9nwEkDsrIAkl8UBgLrY9kzGLcp eMu8Lk9yNunQMKbJ7qaes6pxjqHexJH+QhDk179GOAiKg7iF1Si1slnBZv9MuXljTT PURnCai8KSifCXSh1OxshErN2e1MKl/99+I5FdHCGqhQUpMJn4qu/8TS4PvFWsd5We jorCCfpVsfAbGs5kdt1FoyyVTSdTows2NsR5DckBugx9Pxf2/lb1lI2fRumBQ6/Let 3U2KOinmWLosEn+oq4/yv3uvHHlSxA2TNCqzJTjsYkqMYHws+xJM8RYHK56p4TtxD5 LDvTHeGih6QSQ== Message-ID: Date: Thu, 2 Dec 2021 07:27:49 -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 To: Alexey Melnikov , Ned Freed Cc: "emailcore@ietf.org" References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> <01S6S5UKW87U00D1OX@mauve.mrochek.com> <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.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: Thu, 02 Dec 2021 15:28:11 -0000 On 12/2/2021 2:52 AM, Alexey Melnikov wrote: > This is almost fine with me, except for one SHOULD. The "SHOULD be treated as equivalent" text is wrong (too weak), it has to be "MUST be treated as equivalent" as per the rest of this ticket. So with that in mind hopefully the last version: ahh. yes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 2 07:36:05 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 CF5553A118A for ; Thu, 2 Dec 2021 07:36:03 -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 8iEm2HqlkFRo for ; Thu, 2 Dec 2021 07:35:59 -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 25C9B3A1189 for ; Thu, 2 Dec 2021 07:35:58 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6UTQ5FIXS00K880@mauve.mrochek.com> for emailcore@ietf.org; Thu, 2 Dec 2021 07:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1638459053; bh=1w/gWT81erpXv5eh/hLm/FJ/cgTz+CqJcBMSeIn4MfE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=hTX2CnaN7iUN75KEaSjPmw2j6Hmk+hFI38kFSPlr7nPr70nG/ZZPFPkwWni1TyaSc 0+n8Qz9ZoOBNkOtmaQUqUVk6vxbKaQgdd7/HsPM/CVJZXxGiKs2lJH82+266FSuE/q BaFzRnhPwxWdFNXoY4ZQNnkb9GhGFWM/60/Oj5iM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S6SMLIX0XS005PTU@mauve.mrochek.com>; Thu, 2 Dec 2021 07:30:50 -0800 (PST) Cc: Dave Crocker , Ned Freed , "emailcore@ietf.org" Message-id: <01S6UTQ2IM5W005PTU@mauve.mrochek.com> Date: Thu, 02 Dec 2021 07:27:00 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Dec 2021 10:52:54 +0000" <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> <01S6S5UKW87U00D1OX@mauve.mrochek.com> <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> To: Alexey Melnikov 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: Thu, 02 Dec 2021 15:36:04 -0000 Comments inline. > Hi Dave/Ned, > Catching up with this thread: > On Tue, Nov 30, 2021, at 7:10 PM, Dave Crocker wrote: > > 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'. Agreed. > > 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. WFM. > > 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. This was just an observation on my part: While I think the non-replyble address issue is real, this is absolutely not the time or place to address it. > > 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 Good. > > 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. > This is almost fine with me, except for one SHOULD. The "SHOULD be treated as > equivalent" text is wrong (too weak), it has to be "MUST be treated as > equivalent" as per the rest of this ticket. So with that in mind hopefully the > last version: Good point. > 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 MUST be treated as > equivalent. A sending system SHOULD transmit the form that uses the > minimum quoting possible. I like it. Ned From nobody Thu Dec 2 09:34: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 20A2B3A12DB for ; Thu, 2 Dec 2021 09:34:30 -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 u8iZmcz_tXKj for ; Thu, 2 Dec 2021 09:34:25 -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 21B803A12D7 for ; Thu, 2 Dec 2021 09:34:23 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mspyL-0003TJ-FZ; Thu, 02 Dec 2021 12:34:17 -0500 Date: Thu, 02 Dec 2021 12:34:11 -0500 From: John C Klensin To: Alexey Melnikov , Dave Crocker , Ned Freed cc: emailcore@ietf.org Message-ID: <51E7776E7B6BEFDDEA284AAE@PSB> In-Reply-To: <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> References: <7164a311-c92b-df1b-b671-3bcadfe898b3@dcrocker.net> <01S6S5UKW87U00D1OX@mauve.mrochek.com> <1ae05872-d02a-41ff-9425-02ae886acfa3@www.fastmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false 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: Thu, 02 Dec 2021 17:34:30 -0000 --On Thursday, December 2, 2021 10:52 +0000 Alexey Melnikov wrote: > Hi Dave/Ned, > > Catching up with this thread: > > On Tue, Nov 30, 2021, at 7:10 PM, Dave Crocker wrote: >> 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 >... > This is almost fine with me, except for one SHOULD. The > "SHOULD be treated as equivalent" text is wrong (too weak), it > has to be "MUST be treated as equivalent" as per the rest of > this ticket. So with that in mind hopefully the last version: > > 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 MUST be treated as > equivalent. A sending system SHOULD transmit the form that > uses the minimum quoting possible. I can live with this and have spliced it into -07. That is subject to further discussion, of course, but I hope to post -07 today or tomorrow and am unlikely to fuss with this further before it goes up. However, I am (as individual, not as editor) a little queasy about dropping the, admittedly awkward, "expects to receive mail" terminology entirely. The problem starts with and , pieces of RFC 821 syntax that were not harmonized with the corresponding mail header syntax until at least RFC 2821/5322 (and maybe later -- I vaguely remember some additional tweaks in 5321/5322). It was clearly understood then, and remains true today, that the name of the as transmitted over the network was necessarily the same, or even similar to, that actual name of the "mailbox" file (or directory) in the relevant host. Whether we preserve the distinction I/we were trying to make in 5321 we may want to be a bit more clear in the above that we are stalking about a piece of syntax, the abstract address of the mailbox on, and facing, the Internet, and not the name by which that object would be recognized on the local system. And, if the local system allows getting mail to that object without going through SMTP, we presumably don't care. This is probably less of an issue now than if was before we explicitly introduced Submission Servers, but we should not discard the hint about a distinction without giving it a few minutes of collective thought. best, john From nobody Fri Dec 3 21:09:52 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 0BA6D3A07FF; Fri, 3 Dec 2021 21:09:49 -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.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <163859458886.18502.1599498152651918720@ietfa.amsl.com> Date: Fri, 03 Dec 2021 21:09:48 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-07.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: Sat, 04 Dec 2021 05:09:49 -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-07.txt Pages : 120 Date : 2021-12-03 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Dec 6 10:23:17 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5598D3A0CDB for ; Mon, 6 Dec 2021 10:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=comcast.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 n6HYOF0DbD8X for ; Mon, 6 Dec 2021 10:23:11 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 8305E3A0CE7 for ; Mon, 6 Dec 2021 10:23:11 -0800 (PST) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1B6HEm1n002855 for ; Mon, 6 Dec 2021 13:23:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=AQQgTxOUV8afHMfNIZEoGjD9+EagApRT8+ZypjkVDEI=; b=U/4XrsV5dWJQ408tm2SQEirjdsiWP0ECG3PCkCyevAZNzXGNMce1Bm+8n9nbRfmJSMMP dmvAOGtCR0hc2YO9gfjMRSjdGt8M6DAmFakQn6qzCXSqnAgNpboj8g3XzLofzLnfgZRI hlQ3FnALV53PU8O30fjpfJ79vb4F2Cw3MpVgJGAXrNKD8o0R9cDAW7qY0yyo6DSi2+bI fGT3/AjNi+XOTuKgYUpE2X6Pgl0nmm+ymkuOm6QQ1w5K+0RwnOrLKFZr10YpyayvHn1X AQrOahiJrGJmVhgM8XturY+2GHiKn7IjCrkUDGpf+huM8XGlLbUFGYpUF4eeTF+1DJYp cw== Received: from pacdcexop04.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 3csjj0u37p-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 06 Dec 2021 13:23:10 -0500 Received: from PACDCEXOP01.cable.comcast.com (24.40.1.148) by PACDCEXOP04.cable.comcast.com (24.40.1.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 6 Dec 2021 13:23:06 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEXOP01.cable.comcast.com (24.40.1.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 6 Dec 2021 13:23:06 -0500 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.44) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Mon, 6 Dec 2021 13:23:11 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL1PR11MB5528.namprd11.prod.outlook.com (2603:10b6:208:314::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20; Mon, 6 Dec 2021 18:22:53 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b%5]) with mapi id 15.20.4755.022; Mon, 6 Dec 2021 18:22:53 +0000 From: "Brotman, Alex" To: "emailcore@ietf.org" Thread-Topic: 3.1 - Session Initiation Thread-Index: Adfqy6WNTpxPuWH9S7qrRXqABSFSjg== Date: Mon, 6 Dec 2021 18:22:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70e5e157-64cb-4f3c-2647-08d9b8e56b49 x-ms-traffictypediagnostic: BL1PR11MB5528:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +5HVVoOCXwf+3fzL6ZTALHomxKY+6aJ67pWdtFnz5rB0wdKyKozcsD8pHxIxkfyynWGwYR00/8fIV+cB+YU2OmfJHCiK5tTH7lKRG9XoOoaWnmDIhlBWoE3A+j0lS/PNjjpvVJtiiM2e/nmzl23n5XsOxoR1dokY43h4hD83y+gi7yxsqYn92OxpwdBhAcXUn7SAauipzZFWsUOqMz0CANIdXueC2Msp04gtojyg3DVS2pWCPZDKpC9jM8mPJXbXgrUkRhoKM9Ys7USsmEojpUtWwbXDTBBaVePzbbxFuZbLaszSgM8/7I8P3qbDrmNNE0uYU4krV+xXfJ/3fUbr1OHgzhROThp+o+xTrVwwsG+x4XGT/nzqJudJFg2mVFGtK4Bv++DmRnxgtFMkFJB+wNJGdn2J6yewEthXCOWQqU06dsITTx+MEBkX+opEImD6UJ8f0nAOL4A7e3irAzj/XzzRmxvqCnOXmOoH3ov85v6g0CwE81e7GUuugTE5wJ4PeFkBJ0jCfx1+pdZAmSyJm7Hb5Unpt4Fj2EfrU9x3OWbgp1FytkZ53VbOZtNHGILz3fixonoxxgiWa53i+Vm9E8qp8/WhBma6oDoOCW5wjJW5WobgTx/UXbfs/aFR/J1nLvEGlwKN3kaHfdBjlsS6osl4654ODTpExRzxzHbXFfVP0CLx8RzLK2H34T3b9Fybn6PnDel1zGk9qhWAZ4nwrg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(33656002)(5660300002)(6916009)(4744005)(8936002)(66946007)(64756008)(6506007)(8676002)(9686003)(7696005)(55016003)(38070700005)(66446008)(66556008)(66476007)(86362001)(508600001)(82960400001)(316002)(52536014)(186003)(2906002)(38100700002)(71200400001)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?X7DA+AcLOYXy06NjuMVGWHfxacE/kkaAjgDUGUzRN1TmPIsinzkgn2la0sjo?= =?us-ascii?Q?+U6pcu7ARCGys6QvT2J9YADT2uB9TLvsCKwfTVLyhAFypCHIvtS/V8Y0zJjs?= =?us-ascii?Q?PqhpRrM384NaAzs41eAaD1r4j95QTumo4IsuSDBF5EDqGOSio3p7l3BN2rWy?= =?us-ascii?Q?kyI3ewDIIHlcRYf+CgiBkBjrJL35QQQSOTDhSVBH0V6uffNsjndb8Hzv2hMD?= =?us-ascii?Q?O1+0OAvlgmg2M0mVojl4O7nyTuwg/Gtd7GC8qvw7KhG0qbsTxOSQ/K0WuX4/?= =?us-ascii?Q?2Ki89jzFD45UMRL3SV9PX/1QvR7eOgJ3k+7tzOkB7eLlpXB3cd4T3kCoFdDV?= =?us-ascii?Q?F7sKx6VtU/i6f/SzCUVa8la01XAGP7b19jk3zkwgsDh64Hyb8ifrr7jVhYXI?= =?us-ascii?Q?he3qBSvtO9plOmGhtsdBpGr+L77SNOuTlGJ+SPGrUI+ROvrF5L/FYm1AyVJA?= =?us-ascii?Q?EVoWyDlfGK/IfUfgC+q/7QF6SdaCFSgWAiYbGzDYr8/TxMKroDSJGRBtYLTn?= =?us-ascii?Q?Hy5m/LbKt0oC69nXHc1sREL93FxC3Jp1/kkCRIuRa2O+wI1T5aM0+RiNFe4D?= =?us-ascii?Q?juGK9EhPQiz3StCp3ZbGJTeRf3O86PY5rk5EkWxNwz22yWUrmhDvtIy3WStg?= =?us-ascii?Q?ojw5d3SjZndmK1uogeqeMqldRgMOHmxPTBFOKw8R8fnKlAHS8lPWOKd4fpvl?= =?us-ascii?Q?bzkq9FbPmjcSoci/Ri5Kct0BPbxXeHaL+tz+sFsqbLVPcRWw4THJIaFQo16W?= =?us-ascii?Q?1gnmymSQ0A9FD2anpvNzG6cY1xgmZiwo4eFIKcgSgjS6jGTolLaa8ObDitFJ?= =?us-ascii?Q?9AuwjO+bP7hk5xGvWlFH481hp/bFR3NyCajI5m2BbqoO+GqEUilnebxGwTu/?= =?us-ascii?Q?UaUrAybV01fRI9kXmrq3sONNfD8SMgosqDvDmQ6QkzKGlRWIBS6/Yihqix83?= =?us-ascii?Q?As6Lq/aTj/MrFuR9jUB6K/M+MlsGVw0QKJCBWAHdx7UJf9G/Y6ESsI6/OLFF?= =?us-ascii?Q?JkrMQwcfCNuBtQMZQXcJc/2UU9h5Cq6n7KSFH2xwi6YafsQWuF7hQJCIytqc?= =?us-ascii?Q?ofLa0+Rhpx0q81F2Ck06670fjmPr0SyANQzdPkPLiaQtLTsFbHcrL6HQ+cgE?= =?us-ascii?Q?ANixrF1bgpUN7gkhNf5kjOkVRKWkuTZwTNNf8DdXemhU6lMP9EOYYKvq6qS1?= =?us-ascii?Q?qKwLkcKnNG16tIC8tyvnkHK/kJlbzjTbU2k4RbGv8i5pwLSJCq5SNlB2GmNZ?= =?us-ascii?Q?yTx9psPCeevbINnUM5u4hdfnHHreREtAowm3jq0qiQWFhjgsX7lUZPockIFC?= =?us-ascii?Q?rE6wmLlfnDdSAAKVNutjwA/PxQUIPEAGIj5Jy5eJQX3SlDH/vSoe06Jd5y08?= =?us-ascii?Q?+I8pjc8oejyHiQryJguqodfPgleuwGnfworIkFlulaquh+vqprtu1hRdXQJo?= =?us-ascii?Q?InGkewLaWhJSYRAYGdftvORTahDw+UZ+MIAR5xTWvd+qt1eK43KwJD4NK40B?= =?us-ascii?Q?wbMSeTa9epTGBB5O3+KJUTYFy/L/HDPTEoxNquFLDCnspPUd508hHqz8gvNN?= =?us-ascii?Q?jeMWH5DX08MbKofwY/TkG9JE/NKYsL4R1qsB6DHSJ2I2NNmqgiSRNC02fH9g?= =?us-ascii?Q?reg6pims3gAm3aB/nI+dS03lR4mkzyt3EdASTHg1F9jxA7K0SSd5YyzzWM50?= =?us-ascii?Q?Ur2BsKbkHflSCbEQTqbbCvxOqRCtoj2AXlP3QIYfGgrFBx4NMDtwKNmfrwFI?= =?us-ascii?Q?J20kU7EQbQ=3D=3D?= arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oKty92Hn9cFjE/opXJRU2N/Trn23YUqiQ7pyVaI6XMvB6mGz4j/vspBJYSjO8FUadlw1dU+S7cAFaYFHZqZuy6NdI88WZi13ZT9FEZ5IvZ9pklho3m7PZPDG4mE1A06np1wIkvli89vJVyY2g9/z1M2gFzgcW/2HQawbJh5niw/RW6QbEVqNISVJdsmWKmkzNPh2W/z0TakgdB10t5gAHWpPCkq0vSDjvh60h0Jsp2rANt321yslCnvpBKpZKU+Vwe2Y0a5K4RBH5kMVaeaxAYLfizfdWpIjfTG9ozbZOgrGtEjyf6fwc7AlLshfi7JtWw3vM78PRwDt8KXiu8jYVg== 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=GPZ0nqn1s0Ol4fKJ4nDwPszIhOOX6kpki9doyqTfVU0=; b=LCwZ7pDsJxz441tjN5a1zfCcM/u0cfGJO7CFP2jdGeKt0qOkBuONBe1n7cGrImFqpKx5ZYzJvH/DDlZJIj7nE5ydRnAY+XboD1oW4kRjnt1rPJrF70zQ4MVoWyvH6CiIn3X6B6dTvm/sr+wS3hu/B+5JXramNVrdHDyIO04KH+7sGEyd9Po6zSIz+0Kc+LT+OlDaWJ9Xq4eP6EnNjO3MnfgCjVA10OEnTDKFWOw9S3c07s0/TY8Ig4sk/ws7EoZjiZvHcHDHJKPoZWuY2w6wM+7UbItXaMFEDZEl4SjOfKhR7ujroXfiTP0Ot/3C24ITQMIytRyRpQKKLXP9yCIdVA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 70e5e157-64cb-4f3c-2647-08d9b8e56b49 x-ms-exchange-crosstenant-originalarrivaltime: 06 Dec 2021 18:22:53.2863 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 7rkJohljQDjvflz5Q1SBl5QdLVwerjDuEh1KXlMj08TJpRE3OpuVz0NBqJxflwdegOlCW+RzXWaLWzrH1jvEUms9vzVVXb7tNMb6pgGsoNk= x-ms-exchange-transport-crosstenantheadersstamped: BL1PR11MB5528 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWZ X-Proofpoint-ORIG-GUID: V38JXbO7WZGYwTwJCq9e7tyZsr3i9j7y X-Proofpoint-GUID: V38JXbO7WZGYwTwJCq9e7tyZsr3i9j7y X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-06_07,2021-12-06_02,2021-12-02_01 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Emailcore] 3.1 - Session Initiation 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, 06 Dec 2021 18:23:16 -0000 >From 3.1: "A server taking this approach MUST still wait for the client to = send a QUIT (see Section 4.1.1.10) before closing the connection and SHOULD= respond to any intervening commands with "503 bad sequence of commands". I feel like this may not match reality as it exists today. From a receiver= side, this could allow an attacker to hold open sessions for a quite a bit= of time. Many mail systems do not allow a session to progress once they b= elieve the sending IP is abusive or there may be some other trouble on the = system (over some internal queue level, etc). While it may not match real-= world experiences, I'm not sure we want to change this or endorse this, but= thought it worth mentioning. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Mon Dec 6 14:36: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 6663A3A0A34; Mon, 6 Dec 2021 14:36:51 -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 kB17rn4M7XMq; Mon, 6 Dec 2021 14:36:47 -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 D20EA3A0A26; Mon, 6 Dec 2021 14:36:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muMb9-000Bts-Vc; Mon, 06 Dec 2021 17:36:39 -0500 Date: Mon, 06 Dec 2021 17:36:34 -0500 From: John C Klensin To: "Brotman, Alex" cc: emailcore@ietf.org Message-ID: <3A918DA629A649FD51227719@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] 3.1 - Session Initiation 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, 06 Dec 2021 22:36:52 -0000 --On Monday, December 6, 2021 18:22 +0000 "Brotman, Alex" wrote: >> From 3.1: "A server taking this approach MUST still wait for >> the client to send a QUIT (see Section 4.1.1.10) before >> closing the connection and SHOULD respond to any intervening >> commands with "503 bad sequence of commands". > > I feel like this may not match reality as it exists today. > From a receiver side, this could allow an attacker to hold > open sessions for a quite a bit of time. Many mail systems do > not allow a session to progress once they believe the sending > IP is abusive or there may be some other trouble on the system > (over some internal queue level, etc). While it may not match > real-world experiences, I'm not sure we want to change this or > endorse this, but thought it worth mentioning. Alex, Definitely worth mentioning. Please have a[nother] look at Sections 6 and 7, especially 7.8, and see if that is helpful vis-a-vis the text and situation you describe. Would a cross-reference be useful and, if so, pointing where? Do we need additional text somewhere? In general, Section 7.8 was intended to allow exceptions to any rule if the exception is needed to resist an attack. Seems to me that why you are talking about falls into that category. best, john From nobody Tue Dec 7 06:08:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8293A164B for ; Tue, 7 Dec 2021 06:08:48 -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 fogl806edNU8 for ; Tue, 7 Dec 2021 06:08:43 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CA0FB3A1650 for ; Tue, 7 Dec 2021 06:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1638886118; d=isode.com; s=june2016; i=@isode.com; bh=GjgUklVo9W5yOeRxoNGLrP8sH11DIrpET0IVnMNwZlE=; 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=NESuIOozgt8z2Hg9U39OHU2zEitl4xmoSJYQg93Wy1clwNZDiVf/TIhmlKl2Rj2M55q2Lc ER0smzwQTQjEAxqVHpKxRkLjXiGcsiSLTwq0U/fl0WAjv3c79UsN/bOkQG3V0ZxY4n+jZu 5GmHgZkZVd5k61vJayxua5EH7E80yTQ=; Received: from [192.168.1.222] (host31-49-219-12.range31-49.btcentralplus.com [31.49.219.12]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Dec 2021 14:08:37 +0000 Message-ID: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> Date: Tue, 7 Dec 2021 14:08:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 To: emailcore@ietf.org From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Draft agenda for the Interim meeting this Thursday 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, 07 Dec 2021 14:08:49 -0000 Dear WG participants, Chairs are hoping to see you on Thursday. Below is a tentative list of tickets that we will be discussing: Followup on remaining issues related to #17 (Deprecated Source Routes) https://trac.ietf.org/trac/emailcore/ticket/17 #9 (G.7.3. Definition of domain name in Section 2.3.5) https://trac.ietf.org/trac/emailcore/ticket/9 #15 (G.7.9. Discussion of 'blind' copies and RCPT) https://trac.ietf.org/trac/emailcore/ticket/15 #3 (G.3. Meaning of "MTA" and Related Terminolog) https://trac.ietf.org/trac/emailcore/ticket/3 #12 (G.7.5. Improve description/definition of mailing lists, aliases, and forwarding) https://trac.ietf.org/trac/emailcore/ticket/12 #4 (Exploders seem to be prohibited from adding List-* header fields) https://trac.ietf.org/trac/emailcore/ticket/4 Best Regards, Alexey From nobody Tue Dec 7 07:46:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A693A0992 for ; Tue, 7 Dec 2021 07:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 SHggZ6G4lxfJ for ; Tue, 7 Dec 2021 07:46:18 -0800 (PST) Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1523A16E1 for ; Tue, 7 Dec 2021 07:45:38 -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 F1B6DE011F for ; Tue, 7 Dec 2021 15:45:28 +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 1E255E006F for ; Tue, 7 Dec 2021 15:45:27 +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.124.138.122 (trex/6.4.3); Tue, 07 Dec 2021 15:45:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Squirrel-Battle: 34b021246dd27c5e_1638891928623_482087378 X-MC-Loop-Signature: 1638891928623:1093062634 X-MC-Ingress-Time: 1638891928622 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 4J7l4Q1W5Bz7bbb6 for ; Tue, 7 Dec 2021 15:45:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638891926; bh=ZYYoss3Vhd0QdBZe9r5oQwu5K4XV3ehs5qdI8OdthQM=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=Mkm6RIdnlzOAXlmNH+QGMc2zg6L8FAgDOHZUQMRN2pGBUKbIRSJetB/D/Uyk8T+2P W1kZ4ac1aQ1TIMUA0J6/bjz0UcPW5l3fyUvAiBsSkSVVp8QSrjSBuukbFKEcfx1d7k pl0GUekuH/OC3G+Z4LqRm0ICwo+KUHc8Y2ENdL3qeQD8yAWWXiIEn54MRkJjnWk0Yo H0zjGEhaZ1GlBDV+Jt65hqjY338k0JLFv537G19J3OmqpxzuF+qUnSHZ7Rcvhj7tEP xi2cGzyi8jBWicoxex5qHPOXPbZfoLPbtGAeonoiId4SMEzybovrLi955ATwGYoorA 7Z+WkxmWMrsww== Message-ID: Date: Tue, 7 Dec 2021 07:45:23 -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: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] Domain name 'resolution' - Re: Draft agenda for the Interim meeting this Thursday 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, 07 Dec 2021 15:46:25 -0000 On 12/7/2021 6:08 AM, Alexey Melnikov wrote: > #9 (G.7.3. Definition of domain name in Section 2.3.5) > https://trac.ietf.org/trac/emailcore/ticket/9 Should SMTP, as a 'standard', cover operation within private environments that are relatively or completely independent of the 'public' Internet. That is, does the work of the IETF only pertain to the global operation of the Internet. Or do the protocol specification have applicability to private use? And why? A benefit of at least trying to cover private use is that it will tend to make a specification cleaner and more distinct as a component of technology. And given how challenging it can be to properly separate things into discrete components(*), perspectives that facilitate making these separations are likely to be helpful, even for specifying things that operate in that public space. At the least, it ought to press folk to think harder about what is essential and what isn't. And why. In the case of domain names, there are really two separate activities. One is registration of a name and the other is querying a name. In the case of the term "fully qualified domain name" there might be a third, namely syntax. The benefit of an FQDN is eliminating concern for the way to interpret the string. There's no need to wonder about adding to it, to move it from relative to absolute. The benefit of requiring global registration is a guarantee that there will not be any name collisions, even if a name does not resolve in a query. The benefit of requiring that the name be globally resolveable is...? Consider unresolveable.example.com, where for example.com the name does not resolve in the public DNS, but example.com does. Perhaps it resolves in a private DNS that example.com operates internally. Perhaps not. How is this relevant to the specification of the protocol SMTP, as opposed to the global Internet email service? Should the SMTP specification prohibit either of these cases? If so, why? And for that matter, what does it mean for the SMTP specification to make that prohibition, since example. com can choose to ignore it and will otherwise still obtain full SMTP functionality? A requirement for public resolveability seems obviously essential for operation of the public Internet email service. It does /not/ seem essential for the definition of an email transport protocol. That is a fundamental challenge when doing a protocol specification: separating technology specification from service specification. Conflating the two tends to create messy, confused documentation that suffers in both tasks. d/ (*) Tussle in Cyberspace: Defining Tomorrow's Internet http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.pdf -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 7 08:13:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381733A0AA0 for ; Tue, 7 Dec 2021 08:13:15 -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 mwhml0tAQRsw for ; Tue, 7 Dec 2021 08:13:10 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF363A0A9C for ; Tue, 7 Dec 2021 08:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1638893588; d=isode.com; s=june2016; i=@isode.com; bh=xBXHTbFvJMjCE+j3y0L3MO7HBFuNfnw9fqYOSH596lU=; 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=eC11EhzMQE7ua9n2gyRnQT8un+fbX12ZlFSwUnWo+9bgxhXav6i3GJ3XmhakHgiobL0L/l eERSoldHK7gPG4h1OPMpH8zv/PB8iFSXwyesye6kNy7kNbnhIOzKBd1hQbxdzxBnUSscsc aDimuT2F5x1QNfFgVI4YQi+5p7M0dUI=; Received: from [192.168.1.222] (host31-49-219-12.range31-49.btcentralplus.com [31.49.219.12]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Dec 2021 16:13:08 +0000 Message-ID: Date: Tue, 7 Dec 2021 16:12:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 To: emailcore@ietf.org From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] EMAILCORE Interim date/time and access info 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, 07 Dec 2021 16:13:15 -0000 Hi all, The virtual 1 hour interim meeting is at 17:00 UTC on Thursday, December 9th 2021. We will be using Zoom: https://us06web.zoom.us/j/89359071984?pwd=ZXZSOVBtc0RPWUl1RjhUUGlRZzZQQT09 When you login you will see that it is hosted by "Kingston Chiropractic & Wellness Centre", so don't be surprised ;-). Slides (not yet uploaded) and agenda can be seen at . I've uploaded minutes from IETF 112 by mistake, so disregard these. There is no delete button in the datatracker, so I will replace them with proper ones after the session. Best Regards, Alexey From nobody Tue Dec 7 08:21:26 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54943A1712 for ; Tue, 7 Dec 2021 08:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 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_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 0NKX_yarwuYY for ; Tue, 7 Dec 2021 08:21:18 -0800 (PST) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (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 019473A1711 for ; Tue, 7 Dec 2021 08:21:17 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0E23934228C for ; Tue, 7 Dec 2021 16:21:16 +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 6027F3422A5 for ; Tue, 7 Dec 2021 16:21:15 +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.112.64.102 (trex/6.4.3); Tue, 07 Dec 2021 16:21:15 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Interest-Grain: 66d2b65c389cd228_1638894075740_2496641194 X-MC-Loop-Signature: 1638894075740:4150633983 X-MC-Ingress-Time: 1638894075740 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 4J7lsk3YB2z2YsNM for ; Tue, 7 Dec 2021 16:21:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638894074; bh=d8EvPTSS2H2cUQ6vf7DmKfQA3iX5K4Qqi9P02Q9WDNQ=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=FDM5otGqLwGu41ke22zyRp5+9WurvSLDNFNdxocS0Btu4bWTbh4yP6J8CLJsz25p7 ITZGucqaA8A8F9v5uqvGUd9hUtBGLRF0FeYxpHUjcHuuXHKCM2/iQYXXtVGxvyrFEf dKj+ua3ygYq9lfwbq1wvZEO40OuCK0P7cYzqb36H+uG+VkQG3K9/h1LPO3gZiT1Vs0 4x15wy3QjidSlnWcY9mz6Bn5IrrHtWHZP/F96X3jBwkKQx0/78xC0CzJbzeQ4OYcQG swMAk5Gh6h3spWfJSnBUQCfpoy/RR9Gn4jIBqk+Ea/32tcf2lm7YZ5yeu/+W2BogIZ UjsxwlZWKabXg== Message-ID: <68dfba26-f630-6330-0ce8-43f18f99a0da@dcrocker.net> Date: Tue, 7 Dec 2021 08:21:13 -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: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] MTA - Re: Draft agenda for the Interim meeting this Thursday 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, 07 Dec 2021 16:21:24 -0000 On 12/7/2021 6:08 AM, Alexey Melnikov wrote: > #3 (G.3. Meaning of "MTA" and Related Terminolog) > https://trac.ietf.org/trac/emailcore/ticket/3 > G.3. Meaning of "MTA" and Related Terminology > > A terminology issue has come up about what the term "MTA" actually > refers to, a question that became at least slightly more complicated > when we formalized RFC 6409 Submission Servers. There's probably a really good reason to ignore the IETF-approved definition in RFC 5598, rather than just incorporating it by reference. What exactly is that reason? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 7 08:45:22 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52903A177E for ; Tue, 7 Dec 2021 08:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 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_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FEQCnd0clnJy for ; Tue, 7 Dec 2021 08:45:14 -0800 (PST) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (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 384D23A1779 for ; Tue, 7 Dec 2021 08:45:13 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5B3D4E16DE for ; Tue, 7 Dec 2021 16:45:11 +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 D06BFE0CC9 for ; Tue, 7 Dec 2021 16:45:09 +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.127.242.132 (trex/6.4.3); Tue, 07 Dec 2021 16:45:11 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Rock-Keen: 4c54cb913752711d_1638895511034_3500364393 X-MC-Loop-Signature: 1638895511034:3099355988 X-MC-Ingress-Time: 1638895511034 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 4J7mPJ6ykHz2c2g5 for ; Tue, 7 Dec 2021 16:45:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1638895509; bh=9p0aidBHiM9hXwDGWqdjC8Eahxh2ApXCXWxdK/hNJsU=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=EGUje4rSlr6lpqGx3G3p3VGAs/t1bVf3dWioavsygz9PDJJGmGj//rr20ZcGECYHr cI4mqED5RDuaHPkkQ23Jsm6OI3hFRjx9gDG1NH0x0lnteS4foqVwetAHKR1O1QhtRC Y2/E/eIrX+1U4JJMxUTdGdTiTIZZ/rw2icKLG/I8f/rPK1OhOHtFjL5riNj2aS9FJG R28nSXZQbDOjNLBDS0jTu/OfzorhX2y3RGM9zca5vlsoXT+7Yj8yggtYb7xRjd6/Ya m/IQla8VgCt7Sm+Ydh91rAXWGrl8ZmgNeW3TE9KmvfIiZFDuSVkvtqGTuZoWKm9VjN 9+QMzveD+95SQ== Message-ID: Date: Tue, 7 Dec 2021 08:45:08 -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: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Lists, aliases, forwarded - Re: Draft agenda for the Interim meeting this Thursday 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, 07 Dec 2021 16:45:20 -0000 On 12/7/2021 6:08 AM, Alexey Melnikov wrote: > > #12 (G.7.5. Improve description/definition of mailing lists, aliases, > and forwarding) > https://trac.ietf.org/trac/emailcore/ticket/12 There's probably a really good reason to ignore the IETF-approved definitions in RFC 5598, rather than just incorporating it by reference. What exactly is that reason? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 7 20:54: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 C73163A09B7 for ; Tue, 7 Dec 2021 20:54:16 -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 wrzxLKc2qT6l for ; Tue, 7 Dec 2021 20:54:11 -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 AACEB3A09B6 for ; Tue, 7 Dec 2021 20:54:11 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muoy1-000EDb-6P; Tue, 07 Dec 2021 23:54:09 -0500 Date: Tue, 07 Dec 2021 23:54:02 -0500 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <2B1303FB027EA882DB57F75C@PSB> In-Reply-To: <68dfba26-f630-6330-0ce8-43f18f99a0da@dcrocker.net> References: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> <68dfba26-f630-6330-0ce8-43f18f99a0da@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] MTA - Re: Draft agenda for the Interim meeting this Thursday 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, 08 Dec 2021 04:54:17 -0000 Because Thursday is getting close and no one else has responded, I am reluctantly doing so. Inline below... --On Tuesday, December 7, 2021 08:21 -0800 Dave Crocker wrote: > On 12/7/2021 6:08 AM, Alexey Melnikov wrote: >> # 3 (G.3. Meaning of "MTA" and Related Terminolog) >> https://trac.ietf.org/trac/emailcore/ticket/3 > > >> G.3. Meaning of "MTA" and Related Terminology >> >> A terminology issue has come up about what the term "MTA" >> actually refers to, a question that became at least >> slightly more complicated when we formalized RFC 6409 >> Submission Servers. > > > There's probably a really good reason to ignore the > IETF-approved definition in RFC 5598, rather than just > incorporating it by reference. > > What exactly is that reason? I am aware of two reasons: (1) The IETF did not "approve" that definition or other definitions in that document. What was approved was the document's publication as a model and a history. I should not have to do this, but I call your attention particularly to the "Status" section that follows the Abstract and the statement "It does not specify an Internet standard of any kind." If the IETF had agreed on that model description and terminology and that it was intended to be treated as normative, 5598 should have been published as a BCP or on Standards Track, presumably updating 5321, 5322, and possibly 4409 and other documents in the process. (2) IIR, there are other inconsistencies between the vocabulary and terminology of RFC 5598 and that of RFC 5321. If we decide to treat 5598 as authoritative and to adjust 5321 to match it, it seems to me that consistency would dictate that we change other terminology in 5321 to match. That is precisely the type of cosmetic, error-prone, change I think we should not try to make ... and that I believe you have argued as strongly as I have for not making. AFAIK, nothing procedural prevents you from trying to convince the IESG and the community that the 5598 should be reclassified to BCP or Standards Track and, as part of that change, making its terminology authoritative and normative. This WG should not be implicitly making such a change via some sort of tacit assumption or by accepting a claim that it already has that status. john From nobody Wed Dec 8 14:41:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E143A07B3 for ; Wed, 8 Dec 2021 14:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 XxXGccBSGm6B for ; Wed, 8 Dec 2021 14:41:28 -0800 (PST) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 1E21E3A07B1 for ; Wed, 8 Dec 2021 14:41:27 -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 30B272C10A4; Wed, 8 Dec 2021 22:41:26 +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 6DE972C124D; Wed, 8 Dec 2021 22:41:22 +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.127.242.165 (trex/6.4.3); Wed, 08 Dec 2021 22:41:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Attack-Tart: 0e07cf836f6a9d0f_1639003285895_981091833 X-MC-Loop-Signature: 1639003285894:3315000183 X-MC-Ingress-Time: 1639003285894 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 4J8XFr3hpfz2c2gJ; Wed, 8 Dec 2021 22:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639003281; bh=q3GmC5qXhKq6HiFd9hKc2x782AKoB7b/DSXpcCwBG1k=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=CeXV9XmeRKqmaJLM9UPYnOF/D/XTPcMf9XquwdR4Qr3kBAnk+EHtPyikDJEZ7srfk zT/AnN7FlwGOuRgrySz1ULF9yh+pa6Ser4UN3IKndbpdmcxyJVHj7+bJjX+pszY1ku dIe1jR187MWRLN0lfF4DX84dKOdZcIyD6cp44Q17fLk/FBAsEXPoZ7O2/TJ3Xon3u0 vhpBE7MWrrKrDoxC+nCEsn9CXz11o1fk7xB2N5/PcFsMFMCHdcdeBQcCDmG4yu+QR3 0Y7uRkb0TZ4AHtTjZ2GJe1SMBwoMHCTDu0BbT4+nedSVbdcETdhqmhfOlMN6vT/5QH DmhDJD95ddlew== Message-ID: <4211193e-ca51-2f5e-1052-4e0d0dddf137@dcrocker.net> Date: Wed, 8 Dec 2021 14:41:19 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John C Klensin , emailcore@ietf.org References: <5536f96e-e662-201f-a28c-e64bbe8b4a71@isode.com> <68dfba26-f630-6330-0ce8-43f18f99a0da@dcrocker.net> <2B1303FB027EA882DB57F75C@PSB> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <2B1303FB027EA882DB57F75C@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MTA - Re: Draft agenda for the Interim meeting this Thursday 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, 08 Dec 2021 22:41:34 -0000 On 12/7/2021 8:54 PM, John C Klensin wrote: > --On Tuesday, December 7, 2021 08:21 -0800 Dave Crocker > wrote: > >> On 12/7/2021 6:08 AM, Alexey Melnikov wrote: >>> # 3 (G.3. Meaning of "MTA" and Related Terminolog) >>> https://trac.ietf.org/trac/emailcore/ticket/3 >> >>> G.3. Meaning of "MTA" and Related Terminology >>> >>> A terminology issue has come up about what the term "MTA" >>> actually refers to, a question that became at least >>> slightly more complicated when we formalized RFC 6409 >>> Submission Servers. >> >> There's probably a really good reason to ignore the >> IETF-approved definition in RFC 5598, rather than just >> incorporating it by reference. >> >> What exactly is that reason? > > I am aware of two reasons: > > (1) The IETF did not "approve" that definition or other > definitions in that document. What was approved was the > document's publication as a model and a history. Since the document has only a brief history section and is clearly not significantly a history document, your assertion about that is factually wrong. And 'model' is only a component of the document's effort, which is listed as covering: > * Capturing refinements to the email model > * Clarifying functional roles for the architectural components > * Clarifying identity-related issues, across the email service > * Defining terminology for architectural components and their > interactions So you are oddly selective about the nature of the document. Perhaps you missed that last bullet? > I should not > have to do this, but I call your attention particularly to the > "Status" section that follows the Abstract and the statement "It > does not specify an Internet standard of any kind." If the IETF > had agreed on that model description and terminology and that it > was intended to be treated as normative, 5598 should have been > published as a BCP or on Standards Track, presumably updating > 5321, 5322, and possibly 4409 and other documents in the > process. Your 'If" is false. First, it missed that there was quite good rough consensus among IETF email folk for standardization. Second, the IESG comments are strongly positive about the content. Third, perhaps you can point to some documentation about IESG reasoning for RFC 5598? The IESG ballot record provides no example of the constrained usage view you cite. And while it has a number of statements preferring Informational, only one offers something of an explanation. It's probably also worth noting that, so far: 6 Standards track RFCs have made normative reference to it 1 BCP RFC has made normative reference to it 4 Experimental RFsC has made normative reference to it and if my counting is correct: 24 RFCs have made informative reference to it. So it might be worth considering the substance of the material at issue, rather than invoking questionable process points. Somehow you neglected to consider the substance of that material, rather than the process surrounding it. > (2) IIR, there are other inconsistencies between the vocabulary > and terminology of RFC 5598 and that of RFC 5321. If we decide > to treat 5598 as authoritative and to adjust 5321 to match it, > it seems to me that consistency would dictate that we change > other terminology in 5321 to match. That is precisely the > type of cosmetic, error-prone, change I think we should not try > to make ... and that I believe you have argued as strongly as I > have for not making. My questions are focused on specific items already on the table. They seek to use existing work that represents extensive IETF development effort and review, rather than having the working group re-litigate basic material. I offered nothing implying or intending to expand the scope of work. So your comments about expanded scope are yours, not mine, and for what it's worth, I see no requirement to expand that scope. As such, introducing that expansion, as part of my query, is a distraction. To be clear, your "If we decide to treat 5598 as authoritative and to adjust 5321 to match it," goes quite far beyond the scope of my query and beyond the items I've raised questions about. Also, it's quite odd to consider definitions to be cosmetic. > AFAIK, nothing procedural prevents you from trying to convince > the IESG and the community that the 5598 should be reclassified > to BCP or Standards Track and, as part of that change, making > its terminology authoritative and normative. This WG should not > be implicitly making such a change via some sort of tacit > assumption or by accepting a claim that it already has that > status. Thanks for suggesting work I might consider. I hadn't thought of doing that. And it certainly has nothing to do with the working group's current activities. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 9 05:58: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 5B4733A0CC7 for ; Thu, 9 Dec 2021 05:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=comcast.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 ZRE0tVvOv8wg for ; Thu, 9 Dec 2021 05:58:15 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 8A8953A0CB7 for ; Thu, 9 Dec 2021 05:58:15 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1B9DP03D002859; Thu, 9 Dec 2021 08:58:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=mmBumi2SrDiqBlHBjA7LGRKcY5CgsBLysZJdOev7Qgo=; b=5ouJkjEx7ICOAcZA30PIs+EK34XTbGqBrEdvdPEQRWR3dt5SyFeyLc53uzfgcq/P9wH9 jjI6KsODrMgG/oo/tZcyOvrKh+iGy1Ea7pEURd053VnUC2uYOqZCg/Ort6eDMpxM+s2k OayghVvoryvCOUP8w1POifsOAwfYfuiP3Hn1qwBS1WkARpy3otktaHb7+qPO0onFWPcc d+zutW0JYMbdbn6yY400k+OsJdT8avqLUiJOY32Q1gIUSfwkGGIsOBFo5XAAdI5h2WO/ DbzZwbur+/h8u9ie+t0Qm6CDhdl8ALbbO126MKelKxuvllO3eytVZ94mWmLwnlTCCxy4 iQ== Received: from copdcexc39.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 3cu2brycya-17 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Dec 2021 08:58:14 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc39.cable.comcast.com (147.191.125.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Thu, 9 Dec 2021 06:58:06 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20 via Frontend Transport; Thu, 9 Dec 2021 06:58:05 -0700 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.43) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Thu, 9 Dec 2021 06:57:59 -0700 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB2977.namprd11.prod.outlook.com (2603:10b6:208:7d::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Thu, 9 Dec 2021 13:57:56 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b%5]) with mapi id 15.20.4755.024; Thu, 9 Dec 2021 13:57:56 +0000 From: "Brotman, Alex" To: John C Klensin CC: "emailcore@ietf.org" Thread-Topic: [Emailcore] 3.1 - Session Initiation Thread-Index: Adfqy6WNTpxPuWH9S7qrRXqABSFSjgAJhNMAAISbznA= Date: Thu, 9 Dec 2021 13:57:56 +0000 Message-ID: References: <3A918DA629A649FD51227719@PSB> In-Reply-To: <3A918DA629A649FD51227719@PSB> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 531a4164-7fa6-451a-760e-08d9bb1be701 x-ms-traffictypediagnostic: BL0PR11MB2977:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fCgGLq7bLAdr4tFiwEzRboN+jHNeewoBoLWC+CRqp/ejFhPuJ0OmO9PJlQ1k0YB0h+IBg3UHl8Z9CuPbUrYInVu87tPYk4xT2JodLQQ8LM/eYaqUkY94AXRhcgHXIRSz97ADXnlsdOwsDiExrfAmcwupr+P4nlDWVuM5o9URXZmYZ6/Z3+ng1aSNEj9HbR/7miuAD0EoNX0hNcL2UgE01f/uyjT6y1G5hvravPq5R36fJyK0C+lqsexvCRbxp5QAFlir24g2ZMwxxFGMd1rjQPxxbkuMqulDSvluv8HinV7xUQuYxrykt5u1+LSAj0BvghNSWVqRttVJH8MVS6PFZxiaNS0pJHl/734PX/Ur7vubYpFwfdpLbh40Qv2T7sqStlVoZTLQSoeHQtuhJXK6xurXD4207MC6SQs9waqx8NxDqfkOOH2xybzPMubPnxezInKTjXgxA0zWbwHDlQqsiVvPIiCxOhibX8iN+RordTX3H4ldh8b0LIDClj74yGagdeZd/9bH4vdTYpwkeVjLNWG89eMmXrKwR6jOXeBpIuyTw75rUi2mVkZsMp0VqhHtJh8exfMWwDvXfoEr66D88bw2l4kk/kT/OE6yOE+xBypGrNXBIg+lk5gSI+fIbGfEzWRda0lJ4FFpzUPzVZucT6I76kh2qMtYOw/wZJqR+ulxelOhuEWgFJ/x/0E0eivCV3P3oA98OHoLjUEd/cVY+w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(66946007)(4326008)(55016003)(8936002)(6916009)(86362001)(76116006)(508600001)(33656002)(8676002)(38070700005)(7696005)(66476007)(316002)(83380400001)(52536014)(71200400001)(6506007)(122000001)(38100700002)(53546011)(66446008)(5660300002)(66556008)(186003)(9686003)(64756008)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?A8pX31yOUbX30lpz2IZ4sN/NP2HSZiypTbEw5tgqDn+1pWAElq7XI1/yho/H?= =?us-ascii?Q?7xu3qHChV6bT5xdq5c4+JBriws9hQFjkVWK/tZR6b3jiEDdjaOaG6UplO04Q?= =?us-ascii?Q?h9qmUZSP55HXTF1LoBUVdebQ9jhTbOgrLCp6S71jYnh+ocAFmXm1XjUq0TSG?= =?us-ascii?Q?wjlkfh3yn2msWCSdOP8r2kPJ7ILhkX0cGC2wlDOWzThikkwJtgTk92oXDq47?= =?us-ascii?Q?0IuXShP+ywi6S+flUmbmAbqOIkm3nlEW8R7FCrugUeVA6es4/k1R76d3j6j/?= =?us-ascii?Q?2zX04aLR12Pl/IYE0JvbOlNx0M7s2F+EeM3ruxB8geZzCy40gmZccgnxy2E/?= =?us-ascii?Q?jcqQt/u/tdKJggATlTSaVZL1I5lbBguj1709a3/vknat1j8Rr81Yb7NxX7WI?= =?us-ascii?Q?16t4cjRUrBcQ8r0TsGnkfsG9VdKNx08OZLgCXXeJL8oAJkrN5mQc9uS44XpR?= =?us-ascii?Q?5qHR6UEDOHpgiPPm+zbzNfmFN01ciq5kOlw6b7RPC3cVrmbh4PYVNgAVPTwY?= =?us-ascii?Q?4PSpM1pn39YBHrrvXPQ00B4GiqUcCqYADSo9avuhosXc6VrhZJXFx0DAfuCD?= =?us-ascii?Q?UReUdg2f7nyO07sRyYHy3CMo3g1uwfcIM3O0NjlRIbuWG2bgHDjEvQHvWLy6?= =?us-ascii?Q?D5H6EDcc9xl8rIguS+zW1/w89hnaqQ8wIs8okAzJWKrJRWvphcsk392bX+Cj?= =?us-ascii?Q?9yikIwvwG8VEoCwU/nIUqHWqhfDl2CK9blS3dTRnvVbBvuIbxdW+V0pOnWK/?= =?us-ascii?Q?RH4TGXGdC2hToM9t3YD8Yex6fv9OBlGcKoFrjIFEVFyr6C1mdaOBOxNTPen2?= =?us-ascii?Q?OA14pSvYVGR2mpTM/Gv4imB/IafBPyMtXzSddrGHEdDyrh6qavvkrrigBOMx?= =?us-ascii?Q?Q9yYTeJc1l1jkNFckLDSSeyZi6LvhczaWw7a0x64Susoq7+nI8lCit9lMBvi?= =?us-ascii?Q?76SxwjC8avTQfW+saXlUHz+cxCbsMLa2gF3Xogb1qLHoACHDJ/FeyUNvCpPN?= =?us-ascii?Q?T4bWGCgAIEdMTLpMfKaa8H1Wn8Z5BDMFql6G7NY5LONen2h6O/Ew4JqME58h?= =?us-ascii?Q?cKzcdEmq0jJcGfOF7MylaHYusM95djWYJYJyAsgjLT84MPrL/xD/sZZmV2Xj?= =?us-ascii?Q?L3bcwJoLexl1misC3sDOrQpi4iaRGtSg+jbsR9YEIqwI4EMQ7tQyumtax/M0?= =?us-ascii?Q?hnWs8YheSD9tBZedakqBMMEAW1waIzMJG04iOoAhXpg++LR6fDn4kSZZrUok?= =?us-ascii?Q?GLlENyHvEA/qzVp/9ZEfR2PBnMhe1PORChXnkwEtUSFb7sidvsL9yXU+lv61?= =?us-ascii?Q?PBCs8jvmpWTF8qfYA1kltXkQgO9Mml1pxvtx4darx/Cfgb3Q0dg4N+Q2GYdO?= =?us-ascii?Q?gnJbXxGYhnaT3VrOn+gL+UhG7hnsRXYdCfZsiPIc33yYsaUbRtmxS/zjoSFu?= =?us-ascii?Q?anVf/ukCLIpDrPB6xuDXUi2J83ua8b2ob320bHcUOHRy6LYjM67DDi9U7W2A?= =?us-ascii?Q?TnRYjtMIDIcnGxGKtS5HOdJR1rstIB6gtgpKBHqqS+eGYjLgL6ZnLyF60bW0?= =?us-ascii?Q?pfMQBg34Zdd8UZo6+9OUmOEi9kZYT/CBDdxBX5JxVy835ZbKrcD22hTndGEc?= =?us-ascii?Q?9zLeU6pslnR1ifB4HewV+atFbA99eY8HR6DD8kwxDEtcF293TWaUiNl1Hsh6?= =?us-ascii?Q?YnsFjjgeHPurF+CHRN2x4JgdNkNdfzKU/GOKa2F7YNTms/iRGDnb2lFDFGy+?= =?us-ascii?Q?VsQD9NT7Tw=3D=3D?= arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bbt1fAK6Am/5J1FhKfQTj250YcE1+vUC+9+TcBzZGv4UjxA6d0g0AFm/Psuwtb9HUqysLOLq3kmufOeQztXGHjuv4reQQY5MO5vfGUEI+7gXG4ABlyeo4NlOoeOUEGPsbcfogriglbp7RItquyYgeV+pWv6OHNV6jrQa4u8BJAsXkqOKewV6jI6+IZhVOWJqa9uG2cijfM9u17cMit5r07R8vfIE+dBtH2gLuZGNTymmUjQ+y3g7b9hKiizQ0heVUzj1gWjdcA6REvpzz899sH/mpVE6zcFKceMPoM0OAhnQAy4M+gytp5wUH5YUbP2mqcB70CcwWtAcmPMiF7jgIw== 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=sGeS9xga6RlBc+awobTg2u9U81nuk4TChSkIwjPSzOk=; b=BmBs7wLGMRw37AlvxEIq0DG7uvGh/Zqxk3TnspKuof9sjq5waUP/YipZdsvucUlv6+SaGc3HSPcQGN7wYxBqQuvGXMGWsCmnUf9W7RXiH4Aq+ulAggm1YUlUhW3m5Bu8W20rK6PFcjxqapc33gIA1tcSm+SzDyYXAup0YKTqJfKOixoBrRlOTwa3V2bi5WlDKsunCSLBbrTuPUt4pbEW/LfQirltiyMdBId/A2dU77rbfwIVg1yx2fMVsc2m1NzSeee73vM3hEQ0eRL4Psiwpg0DNmeRtnWoqSPm2RFmmWMGn40o3gJYL/Iblf3PloK/hjDT5sWSVFbgA3JIbC9EGQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 531a4164-7fa6-451a-760e-08d9bb1be701 x-ms-exchange-crosstenant-originalarrivaltime: 09 Dec 2021 13:57:56.3310 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: k3WnDWOYaPBlral5S7qKonNJSUeNujZ6+Ofq2LUMOD4F9OmmbPX0+QQzKOLVWkQmFFLUME7T2HC6HIqfKDOzdky3e8XP01SR2MxPoy6+BfA= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB2977 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWC X-Proofpoint-GUID: oSd7YjEJ8enxXvx6iW1Y4eF4sFbIDYr0 X-Proofpoint-ORIG-GUID: oSd7YjEJ8enxXvx6iW1Y4eF4sFbIDYr0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-09_06,2021-12-08_01,2021-12-02_01 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Emailcore] 3.1 - Session Initiation 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, 09 Dec 2021 13:58:20 -0000 Thanks for the pointer. I was in the middle of reading 06 when you release= d 07. Thought I should send in the note before I started anew. My apologi= es. Perhaps in the introduction for section 3 for a note to suggest that sectio= n 7 contains deviations that may be more optimal for some situations. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: John C Klensin > Sent: Monday, December 6, 2021 5:37 PM > To: Brotman, Alex > Cc: emailcore@ietf.org > Subject: Re: [Emailcore] 3.1 - Session Initiation > > > > --On Monday, December 6, 2021 18:22 +0000 "Brotman, Alex" > wrote: > > >> From 3.1: "A server taking this approach MUST still wait for the > >> client to send a QUIT (see Section 4.1.1.10) before closing the > >> connection and SHOULD respond to any intervening commands with "503 > >> bad sequence of commands". > > > > I feel like this may not match reality as it exists today. > > From a receiver side, this could allow an attacker to hold open > > sessions for a quite a bit of time. Many mail systems do not allow a > > session to progress once they believe the sending IP is abusive or > > there may be some other trouble on the system (over some internal > > queue level, etc). While it may not match real-world experiences, I'm > > not sure we want to change this or endorse this, but thought it worth > > mentioning. > > Alex, > > Definitely worth mentioning. Please have a[nother] look at Sections 6 an= d 7, > especially 7.8, and see if that is helpful vis-a-vis the text and situati= on you > describe. Would a cross-reference be useful and, if so, pointing where? = Do > we need additional text somewhere? > > In general, Section 7.8 was intended to allow exceptions to any rule if t= he > exception is needed to resist an attack. Seems to me that why you are > talking about falls into that category. > > best, > john From nobody Thu Dec 9 11:54:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16163A0C46 for ; Thu, 9 Dec 2021 11:54:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=0xmackenzie-io.20210112.gappssmtp.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 tqaAd7cpjzXN for ; Thu, 9 Dec 2021 11:54:42 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 7ECA63A0C44 for ; Thu, 9 Dec 2021 11:54:42 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id y68so16379145ybe.1 for ; Thu, 09 Dec 2021 11:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=0xmackenzie-io.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=TykUCcJchOqC4MP8r7NrhAIU8lU3AsH24G6I1pCdF+c=; b=6dN6ul794pFpaLCN/P9uJRIDEfClp9x48xSFIl/Hs3aPb0lHrsqW8ATjAiDN2YPXow WKiaOr/SXvg6/s/xak70mHTucCUNIe9MzGNaCpxk/7V3Gez/MHWaNavO/JY9/E9x5H5Y H6ktF1wUHEsLzPA8bSh3wdRlaKYi/EOjaWj2QkotLAoQcqG/2wNE8a34S1aieRqwiYd+ FdoyJsD7Edjvn6aiLsuSDAg6BUKFB13KFifaAmx5MWaAMfy+kV5GDrnqET/km8P9dOxq WC8ytM+4hRNDDH9VQLNgDpLxD2rcKHuuw/a50H9ICn6ViXb69yc77uqzxv+kLqNkkmB9 N/5Q== 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=TykUCcJchOqC4MP8r7NrhAIU8lU3AsH24G6I1pCdF+c=; b=TYFG6X9G59FWpilNSiqsiQOZbJr0jwkE+dUgGhWpwuhiF8p5P8ojN5QG8KbIsLPtom ONH61KJSx9PluD5qTOJNhkBQGUQQEw0cAYD7HV+F3MHpUuWbrYxMMlpNpjf8HlR0sqf8 sr4C8dwPskympBq3lLYUEC/9m7BaPH3WivV+lZljLI60Rs1D3q4ZFevbczj5fTKVZJuX wBqxYEUE5wpYaDRZiAr3p9gwJLTNeI42LKtpTOt8zvM1o4F7hG119bukMtL31d9FGZzs 5E+jzoOkgKJKUaHJ/A7J/m9M8hbhppIrXftyhEhiNlhi+UFpqpFVkDiEr4wYgGhOn8rN W4/Q== X-Gm-Message-State: AOAM531P6yv2/GtJzfK6xw3xRQZGuC8VEg0BRqTb0d/YDgIXQfjIqeTt gadRTNcNl3y9tHQOAjcnWiwRnsyWG9wQC+7n5Zb4NBzfdA8QZQ== X-Google-Smtp-Source: ABdhPJwqBkyFf+ADSsuCOYKK9WG68A2eCmtGPNuHAl1D4m4zyMx0nIbYqSKuxeWKTBP78a0i3w8kfCwKQ8V7M4p9Fao= X-Received: by 2002:a25:42d7:: with SMTP id p206mr8896871yba.765.1639079680972; Thu, 09 Dec 2021 11:54:40 -0800 (PST) MIME-Version: 1.0 From: Mark Mackenzie Date: Thu, 9 Dec 2021 13:54:30 -0600 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000024ac4e05d2bbfadf" Archived-At: Subject: [Emailcore] Reflecting on the correctness of examples 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, 09 Dec 2021 19:54:44 -0000 --00000000000024ac4e05d2bbfadf Content-Type: text/plain; charset="UTF-8" After our meeting today, I was reflecting on the correctness of the examples. I've seen instances in implementations of other RFCs where examples are interpreted more as the "truth" than the surrounding text. Therefore, I think it serves best to update the examples to remove the source routing from the examples. In general we should understand that many readers will focus more on examples than we perhaps would like. It was great meeting everyone today! Regards, Mark Mackenzie --00000000000024ac4e05d2bbfadf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After our meeting today, I was reflecting on the corr= ectness of the examples. I've seen instances in implementations of othe= r RFCs where=C2=A0 examples are interpreted more as the "truth" t= han the surrounding text. Therefore, I think it serves best to update the e= xamples to remove the source routing from the examples.

=
In general we should understand that many readers will focus mor= e on examples than we perhaps would like.

It was g= reat meeting everyone today!

Regards,
Ma= rk Mackenzie
--00000000000024ac4e05d2bbfadf-- From nobody Thu Dec 9 13:43: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 0A4533A100F for ; Thu, 9 Dec 2021 13:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0HEezVcShN3R for ; Thu, 9 Dec 2021 13:43:12 -0800 (PST) Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) (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 5CDFF3A1010 for ; Thu, 9 Dec 2021 13:43:11 -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 0E9B86C0F57 for ; Thu, 9 Dec 2021 21:43:10 +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 617906C11C1 for ; Thu, 9 Dec 2021 21:43:09 +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.105.57.109 (trex/6.4.3); Thu, 09 Dec 2021 21:43:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Left-Wiry: 3e8eb064620f7494_1639086189812_3734032242 X-MC-Loop-Signature: 1639086189811:3020421389 X-MC-Ingress-Time: 1639086189811 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 4J96wD3zx5z7bYZc for ; Thu, 9 Dec 2021 21:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639086188; bh=aUSi3JbCtANUE2P0wyBjR2cc4kHLaOyGDUANTykJ+/g=; h=Date:From:To:Reply-To:Subject; b=QBUdMxPFEHFj70wAwdk3gDfT/jgQlvmLgHeS2zbHJgMelMKe0d/Z1DwMEKBOkHFG3 EIfg56r4N9he8WKKoKwP4HXgGzBbp62HD2ukNqjhYQvwMBNFMMsuhKU4i6Ny5UmbOB MT8UK2Kauz5XC1BNa7gzIy8/CcZYhPCkA8+DaO7IYH8K8c4tuWZbfwN9qC8URLx2Yk xASq2pbEqD2fcaZOTWW7KDH6N9/mQoYG3Lw/K2GFcLX9s5X7yoqRLnHmWt8xxifpwz HWbXqpOa8sFOLzgRRNCRIZ8fgeo6sRS4Yk+JpqXKnDI6ub3pV2B6pR/ERfUQ3CEEq1 YL8IskxtDD0Zg== Message-ID: <6e536c04-bf86-2c7c-398f-87774ce5f9fa@dcrocker.net> Date: Thu, 9 Dec 2021 13:43:07 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US From: Dave Crocker To: "emailcore@ietf.org" Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] Scope of submission/delivery and address alteration 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, 09 Dec 2021 21:43:18 -0000 Folks, From today's session... There is a pure point of debate about the boundary that defines delivery.  I'd like to see whether we can get any convergence on it. My simplistic view is that when the SMTP sequence is no longer processing the address in a RCPT-TO, then either the message has been delivered or it has been subject to a delivery failure. Assuming my understanding is correct, the other side of this debate sees some modifications to the RCPT-TO as being before delivery. I don't understand the logic behind that, other than based on particular implementation choices, which strikes me as pretty arbitrary. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 9 19:00: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 108883A186A for ; Thu, 9 Dec 2021 19:00:17 -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=q0su4hrS; dkim=pass (2048-bit key) header.d=taugh.com header.b=nR79LlLn 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 6llVVZuDLmNa for ; Thu, 9 Dec 2021 19:00:11 -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 7B3503A1869 for ; Thu, 9 Dec 2021 19:00:11 -0800 (PST) Received: (qmail 34124 invoked from network); 10 Dec 2021 03:00:08 -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=854a.61b2c2b8.k2112; bh=GJbZxVO14sgJMKTWBE8wI7eWDILBI1t4/4FHB6PHPmY=; b=q0su4hrS1BsAAGuVLYoLBQWJBNZY6oIexULybzQQn/UcJjGi2V5EfydhLwPLlcR3Mkj5vhWl+1QD1LMMua7qnG0OwaM56uGIareCQRvEPcMTyfaMiRu61CE/gJkII+bfotu5XQFhoJ+q6lNwxBlj1tr5K/jxfjU6ic3iGjL+CJKYH22pv+S95iiAffTQxywx0tIGnPFSH5UlqLwz6JE8kqSnTCv7QEqpAuAEPZoj4fteV5ROVEuvFyBL4hxtp1m/fHrDGciUMlWSmk8UM/FYFagCZLMpyW9Z70EwcCfOpE1naFSmQtFWKEglLQ2AxdoPnVVfN7OhEk7LQuEdJUJ9Ew== 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=854a.61b2c2b8.k2112; bh=GJbZxVO14sgJMKTWBE8wI7eWDILBI1t4/4FHB6PHPmY=; b=nR79LlLnZmb4p3HUoa1mg/C50MkgEix/K74cMFjcTtZ4263y8f8EL4STXk54Rhehs4y1R4YHIwFLwibYtmhs3C06TcWuzxj9bGP+5eV9q2QPaS3dPkSqXcxXxt/NrtmDt3a7kPQda/eAGV3d0K+lXbfm/0AEa6vHtfBXU30kwYaRjUTAlqeKXUH+D8nHHHJmL/McvbWueIzvYskJCPpJvnVITgwfNk8pQNp6rFCXwIXWlBXue03l81t/C81KMNUJj/Gjnwe/cEZegr8/2KjZRJHtdSJGzSektIM6r1stOu236rsctlFjA88K+h4ZcArD3h+ZXdMc3SBk1wir6AJbNw== 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; 10 Dec 2021 03:00:08 -0000 Received: by ary.qy (Postfix, from userid 501) id CF7FD3136232; Thu, 9 Dec 2021 22:00:07 -0500 (EST) Date: 9 Dec 2021 22:00:07 -0500 Message-Id: <20211210030007.CF7FD3136232@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <6e536c04-bf86-2c7c-398f-87774ce5f9fa@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 03:00:17 -0000 It appears that Dave Crocker said: >Assuming my understanding is correct, the other side of this debate sees >some modifications to the RCPT-TO as being before delivery. > >I don't understand the logic behind that, other than based on particular >implementation choices, which strikes me as pretty arbitrary. Well, we're supposed to be doing engineering, balancing theory and practice to see what actually works. I think that when a secondary MX forwards a message to a primary without changing the envelope or changing the message other than adding trace headers, that's a relay, and the intermediate step is not a delivery. If a message passes through a mailing list that adds a tag to the subject line and a footer to the body, replaces the envelope bounce address, and sends the message to a whole bunch of people, that was a delivery and resubmission. In between, it gets kind of grey. My inclination is to say that if the only change is to change the recipient address and maybe to add a few trace headers (like received and authentication-results, that's a relay, more than that is a delivery. Someone said "what if it only adds a List-ID"? I don't see that as a very interesting question since in reality anything that adds a List-ID is likely to do a lot more than that, at least to some of the messages it handles. R's, John From nobody Thu Dec 9 19:14:10 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2D53A18A0 for ; Thu, 9 Dec 2021 19:14:09 -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 wyWsIpRhfXyh for ; Thu, 9 Dec 2021 19:14:04 -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 B70133A18A2 for ; Thu, 9 Dec 2021 19:14:02 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mvWMC-000INQ-Dc; Thu, 09 Dec 2021 22:14:00 -0500 Date: Thu, 09 Dec 2021 22:13:54 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org cc: dcrocker@bbiw.net Message-ID: <7BF81F6823ACA5B4A293FEAC@PSB> In-Reply-To: <20211210030007.CF7FD3136232@ary.qy> References: <20211210030007.CF7FD3136232@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 03:14:10 -0000 --On Thursday, December 9, 2021 22:00 -0500 John Levine wrote: > It appears that Dave Crocker said: >> Assuming my understanding is correct, the other side of this >> debate sees some modifications to the RCPT-TO as being >> before delivery. >> >> I don't understand the logic behind that, other than based on >> particular implementation choices, which strikes me as >> pretty arbitrary. > > Well, we're supposed to be doing engineering, balancing theory > and practice to see what actually works. > > I think that when a secondary MX forwards a message to a > primary without changing the envelope or changing the message > other than adding trace headers, that's a relay, and the > intermediate step is not a delivery. > > If a message passes through a mailing list that adds a tag to > the subject line and a footer to the body, replaces the > envelope bounce address, and sends the message to a whole > bunch of people, that was a delivery and resubmission. > > In between, it gets kind of grey. My inclination is to say > that if the only change is to change the recipient address and > maybe to add a few trace headers (like received and > authentication-results, that's a relay, more than that is a > delivery. > > Someone said "what if it only adds a List-ID"? I don't see > that as a very interesting question since in reality anything > that adds a List-ID is likely to do a lot more than that, at > least to some of the messages it handles. FWIW, your analysis is consistent with what I (and probably "we", because this was discussed) thought we were saying when 5321 was written. If, either because I blew it or because our ways of looking at things have evolved, that isn't clear, we should certainly try to fix it. But I'm at least mildly resistant to trying to develop or apply an alternate theory that would collapse the situations together ... if only because I have doubts that we'd get it right, especially with a reasonable level of time and effort. The only area where the spec may (I'd have to go back and study it) disagree with your "only change" in the gray area is that I think (again without checking) that the text allows, and may encourage, changing the backward-pointing address too. john From nobody Thu Dec 9 19:43:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86D93A191F for ; Thu, 9 Dec 2021 19:42:58 -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 suqSQoXbKm34 for ; Thu, 9 Dec 2021 19:42:53 -0800 (PST) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (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 8FE263A191D for ; Thu, 9 Dec 2021 19:42:53 -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 9E8896218E7; Fri, 10 Dec 2021 03:42:52 +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 EDD5162175A; Fri, 10 Dec 2021 03:42:51 +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.105.57.109 (trex/6.4.3); Fri, 10 Dec 2021 03:42:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Decisive-Print: 333670304f652df1_1639107772376_579417181 X-MC-Loop-Signature: 1639107772376:4262651229 X-MC-Ingress-Time: 1639107772376 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 4J9GvG0Nczz2YsQy; Fri, 10 Dec 2021 03:42:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639107771; bh=G4U6m+Csu20un9jU7kXM/1bV8hY9xY5RIqbT7tVPkJ4=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=eIfi0PJEu+DUMoVhC7WT4/fPmvekNaGa+E7fAf6l/WcMgbcHHE3kjQ7YCftTuk+R0 1oJX3bxWVVIiKEkQ7v6HeG3o+EMML9zXVkRYxqAykw62eoV9mJRJOiN60aaGGE4bl+ 3sPtXyVIouHMbRZ4MtNwGbpFPlwh9//OKEVrrhr2P6qUwMWtextg4Zo6Y1uSVmL/r6 fC2se/mYBrw3m3oXSaPAtY/uXBtmuI8JF4Ieu9eqCa7awI55pu5UjgdtayJQA6H6ub /SZHTtuO6my2D1iOtCQFV98euMIR4Y5rcc41pdbEursct4jq3XuKAu0EgmObRCCkQv Jw5hgLwA2MuDg== Message-ID: <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> Date: Thu, 9 Dec 2021 19:42:48 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John Levine , emailcore@ietf.org References: <20211210030007.CF7FD3136232@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211210030007.CF7FD3136232@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 03:42:59 -0000 On 12/9/2021 7:00 PM, John Levine wrote: > In between, it gets kind of grey. My inclination is to say that if the > only change is to change the recipient address and maybe to add a few > trace headers (like received and authentication-results, that's a > relay, more than that is a delivery. So, this defines a choice, based on some actions. I think it's consistent with the 'alias is different from mailing list' view being espoused. But my question was about the /logic/ for this choice. In functional and/or architectural terms, what makes that good to include in the SMTP layer, versus some things deemed outside of that layer, such as mailing lists? Is it just arbitrary, based on some historical implementation choices, or is there an architectural basis? By way of seeding this a bit, please note that the view I'm pushing is quite simple: when the SMTP layer is done processing the address in RCPT-TO, then it is delivered (or failed). Though it is outside the scope of this narrow topic, it might be worth at least noting that the higher-level 'end to end' email activity, between author and recipient, which goes through mailing lists and is viewed as having multiple submissions and deliveries, has a higher-level version of submission/delivery, but we don't have distinctive language for that, other than sometimes say 'final' delivery. Still, I think there is a shared -- if implicit -- view of it. It is easy to say "relaying is movement until processing of the address in RCPT-To is complete and the act of completion has either delivery of failure. Revising that simple model to include address transformation of RCPT-TO is at least odd, given that we still need the upper-level model for mailing lists, which also must deal with that 'transformation'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 9 20:10: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 432893A0798 for ; Thu, 9 Dec 2021 20:10:57 -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=szaxuQDF; dkim=pass (2048-bit key) header.d=taugh.com header.b=MuZmAfLg 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 G4Xc6UO6u7Ew for ; Thu, 9 Dec 2021 20:10:51 -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 AA6443A0794 for ; Thu, 9 Dec 2021 20:10:51 -0800 (PST) Received: (qmail 41790 invoked from network); 10 Dec 2021 04:10:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=a33c.61b2d349.k2112; bh=oU3w7jvE2xVYZ/3sKMg6+nOgg933YPGLLyYBJhFJnHk=; b=szaxuQDFa53uTuVKw14C+Kk6NO48Fl6hgiqCw80DvLQukiHXP5jTszAWJLHu+vnVytOjZhSk7x1vpJNSuIjkR2LOOmiLwfPpVcagZxipmbHH+8BM2i7HVY9MpbMRtBT2WBaZv/IK6lpiX5O8CYdENxCUEa5KhSKN3kfAMQTcpsb9ippR2b+tt58leJFPJad6nz0sgJ/3kvU5M51VjN1StlbLvVtaRntVnYYq5Q7tB86M4jY+46ah/94iPnzWGwSOhMhnSuXqxUqa0In1kxE9CU9AEagAdA6WTaXol9dKv1KHf4jCpvdXGtjBAyWuZEGyHmgc3yNcVV83WjD48mmMHg== 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=a33c.61b2d349.k2112; bh=oU3w7jvE2xVYZ/3sKMg6+nOgg933YPGLLyYBJhFJnHk=; b=MuZmAfLg77l7N+0168krxYh7qZDCH2Lkchwe1s8TnIdgQFGPRMN0CF7r0/0MmRY8lPPDu4yB+gaZucWdcYCvSc4LPSUQR8HniYJeBP+0WvCoX/0NYCiMNZ5yUwKuW5dNy/MbIfKKtlwcGiEIoipqYuWRWSSpcqygLVQzml5Rniux38FOZWrp/Wd2wqbXVca530DcmaWsPPswIezLgSkG+oeM9BSbdGU2gO9P76Q8ftwzbop/zjHR0n0Z6dsRYiYzTLac/cug82Cf4adK3aOITGoduJd7t+kh8taKvQIsHd7oQC4T1AmStjnxhfmPEhIwMLsoBgBYKN2A6rc7OgUpFQ== 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; 10 Dec 2021 04:10:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 6903931379A8; Thu, 9 Dec 2021 23:10:48 -0500 (EST) Date: 9 Dec 2021 23:10:48 -0500 Message-Id: <20211210041048.6903931379A8@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 04:10:57 -0000 It appears that Dave Crocker said: >On 12/9/2021 7:00 PM, John Levine wrote: >> In between, it gets kind of grey. My inclination is to say that if the >> only change is to change the recipient address and maybe to add a few >> trace headers (like received and authentication-results, that's a >> relay, more than that is a delivery. > >So, this defines a choice, based on some actions. I think it's >consistent with the 'alias is different from mailing list' view being >espoused. > >But my question was about the /logic/ for this choice. It reflects reality. If we could rewind back to 1980 and redo this from scratch, there's all sorts of stuff we'd do differently. >By way of seeding this a bit, please note that the view I'm pushing is >quite simple: when the SMTP layer is done processing the address in >RCPT-TO, then it is delivered (or failed). Yes, I understand that is the proposal. But I don't think it matches the way that mail systems work. R's, John From nobody Thu Dec 9 20:36:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA313A0818 for ; Thu, 9 Dec 2021 20:36:55 -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 5W5MJTpF2u8q for ; Thu, 9 Dec 2021 20:36:50 -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 8E27F3A0817 for ; Thu, 9 Dec 2021 20:36:50 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mvXeI-000IeL-1K; Thu, 09 Dec 2021 23:36:46 -0500 Date: Thu, 09 Dec 2021 23:36:40 -0500 From: John C Klensin To: dcrocker@bbiw.net, John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] Editorial/procedural comment (was:Re: Scope of submission/delivery and address alteration) 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, 10 Dec 2021 04:36:55 -0000 --On Thursday, December 9, 2021 19:42 -0800 Dave Crocker wrote: > On 12/9/2021 7:00 PM, John Levine wrote: >> In between, it gets kind of grey. My inclination is to say >> that if the only change is to change the recipient address >> and maybe to add a few trace headers (like received and >> authentication-results, that's a relay, more than that is a >> delivery. > > > So, this defines a choice, based on some actions. I think > it's consistent with the 'alias is different from mailing > list' view being espoused. >... Hi. An observation, editor's hat firmly in place and with the current discussion only as an example (there are other examples) .... Due to decisions made in DRUMS (pre-2821) and not altered significant in YAM (pre-5321), 5321 is a rather complex document, containing a good deal of text that is interconnected and sometimes even redundant. As a handy example, the seemingly simple tasks of cleaning source routes out of the body of the text, including figuring out just what that meant in practice, has taken two iterations of the I-D already and will take at least one more. Even if we had comprehensive agreement on a principle like "as soon as an RCPT field is changed, it isn't SMTP any more" (and I don't think that has been proposed), correcting all of the text that would be affected would be a significant piece of work. That work would necessarily include (as was pointed out on the call), figuring out how to sort out the rewriting implied by the 251 ("forwarding to...") reply code and implications for the VRFY and EXPN commands). So, without judging the answer for this case or any of the others that might arise, I hope we can regularly ask ourselves, and that the co-chairs will insist that we ask, whether any particular change to what is presented and/or how it is presented are important enough to be worth the effort. That question is not just about the editorial effort. It is also the effort to review what has been changed and what has not to be sure we haven't left loose ends or created ambiguity or uncertainty. In that context, "important enough" may include questions of WG energy and commitment levels, schedules, etc., as well as evaluations of more substantive questions. It might not be that way in a more perfect world, but we need to face the reality and need to make pragmatic decisions in this one. Again, that is not a comment on the particular thread that inspired this note and I have not reached a personal conclusion about my preferences about what we should change if anything (independent of what I've already said about substance in my personal capacity). But I do think it is important to get the question in front of us. best, john From nobody Thu Dec 9 21:06:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5563A0929 for ; Thu, 9 Dec 2021 21:06:01 -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 2BDlhDZiI8_W for ; Thu, 9 Dec 2021 21:05:56 -0800 (PST) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73683A0926 for ; Thu, 9 Dec 2021 21:05:56 -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 2286F3415A2 for ; Fri, 10 Dec 2021 05:05:55 +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 9FEE13415FB for ; Fri, 10 Dec 2021 05:05:46 +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.99.149.17 (trex/6.4.3); Fri, 10 Dec 2021 05:05:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Ski-Industry: 68aa6b1a5d8427f0_1639112754800_1140605395 X-MC-Loop-Signature: 1639112754800:2492369819 X-MC-Ingress-Time: 1639112754800 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 4J9Jkx66Qwz2YsNH for ; Fri, 10 Dec 2021 05:05:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639112745; bh=1pWgRp/3gRmShDpgKxLRgqSSVKdp8K1Si7i4qrMZnaA=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=o/meHTfslFYGYGB1iNo9wb3HXnA7wMJsN5vFm8d59f6bHBsZe3wbKey3NbBq9dk7l /0jrGefyZ3//LKJJjqWjjPlIcZxU25AkTvzPp5GgpbbSohKenE4P10HbYdVb/k5629 TZl29HvP/2qW4t9Al6Zkgi73MMAgTHCFYmLZMaXsFOZReqRMrYibOqk9MX7267/NbV WJ665MO3ce4pKz0VRHanPJv0cm6X5HT1TNTdclcLkpIO7C6+ri5AKYh49qPofN4NwC 8YQBMMbSwGLc1hzKSKS26dJVdxD6UpRs3LbHXl/GjQU/tULgapaIn1dmqIwcfsbVr7 5EszIeg1PjobA== Message-ID: <799f0d85-b4ba-ac03-5a00-1b3b140bbc8b@dcrocker.net> Date: Thu, 9 Dec 2021 21:05:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211210041048.6903931379A8@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211210041048.6903931379A8@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 05:06:02 -0000 On 12/9/2021 8:10 PM, John Levine wrote: > It appears that Dave Crocker said: >> On 12/9/2021 7:00 PM, John Levine wrote: >>> In between, it gets kind of grey. My inclination is to say that if the >>> only change is to change the recipient address and maybe to add a few >>> trace headers (like received and authentication-results, that's a >>> relay, more than that is a delivery. >> >> So, this defines a choice, based on some actions. I think it's >> consistent with the 'alias is different from mailing list' view being >> espoused. >> >> But my question was about the /logic/ for this choice. > > It reflects reality. It reflects an implementation reality -- and not one that is required. Which is why it's not the same thing as a networking architectural reality. Note that there is nothing from choosing to implement these bits of functionality is very different places. Ned noted they can/do put mailing lists into the SMTP functionality. >> By way of seeding this a bit, please note that the view I'm pushing is >> quite simple: when the SMTP layer is done processing the address in >> RCPT-TO, then it is delivered (or failed). > > Yes, I understand that is the proposal. But I don't think it matches > the way that mail systems work. Is it really that difficult to distinguish between email abstractions and common -- but not inherent -- email implementation? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Dec 10 06:11:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22E3A0FCF for ; Fri, 10 Dec 2021 06:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 97St7bOmFSMb for ; Fri, 10 Dec 2021 06:10:59 -0800 (PST) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806313A0FCC for ; Fri, 10 Dec 2021 06:10:57 -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 77595521F03 for ; Fri, 10 Dec 2021 14:10:56 +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 BACF6521F11 for ; Fri, 10 Dec 2021 14:10:55 +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.127.242.170 (trex/6.4.3); Fri, 10 Dec 2021 14:10:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Abortive-Decisive: 1ed280b0379f3e0b_1639145456076_3406187922 X-MC-Loop-Signature: 1639145456076:188103813 X-MC-Ingress-Time: 1639145456075 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 4J9Xqy6Rllz2c2fw for ; Fri, 10 Dec 2021 14:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639145455; bh=cfFfUGZQx2gdBV33og7Enko61c3nzB7gUCW2sS3pTzI=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=dXHRnqI0MVNevR+6uyQ0tkUAi7XLyBY2AmveGpO+w3W9eKS+vR4C3d1BTvvashKdb jTKX3VLY5najuh30Dbikz27PJizW9F6bA/GCswXmcr0yiyr7hYmjpmB03L4Pz6RyKu NGd+b9HJWK9GLRJjGsG9NH4TE+xgg54EzV/bgn/3Vo3VX9tRPLYAP3WscYbABR4Uuu yM5E9zvRWHzCMWN3K0NdUujbKoeeb8ocMJPbpEXXnqVxk83FcZCo49H70mcRatdL4m PItW9DBqzx41ZCP/HYov6pRbzs17PR4tScN3m/mLFWppPo6MTQkVE3LsTXFshiBKCd /dCtwjOubp33g== Message-ID: Date: Fri, 10 Dec 2021 06:10:52 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Editorial/procedural comment (was:Re: Scope of submission/delivery and address alteration) 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, 10 Dec 2021 14:11:05 -0000 On 12/9/2021 8:36 PM, John C Klensin wrote: > As a handy example, the seemingly > simple tasks of cleaning source routes out of the body of the > text, including figuring out just what that meant in practice, > has taken two iterations of the I-D already and will take at > least one more. Even if we had comprehensive agreement on a > principle like "as soon as an RCPT field is changed, it isn't > SMTP any more" (and I don't think that has been proposed), Gosh. I thought it had. > correcting all of the text that would be affected would be a > significant piece of work. That work would necessarily include > (as was pointed out on the call), figuring out how to sort out > the rewriting implied by the 251 ("forwarding to...") reply code > and implications for the VRFY and EXPN commands). While there is an obvious and reasonable basis for considering the 'forwarding' text to be related to the 'alias' text, the document in fact makes no connection. So no, the work would not necessarily include dealing with forwarding. 'alias' is a term used with some frequency in the document, but I believe it never has normative effect. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Dec 10 07:18: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 8DCD13A07D5 for ; Fri, 10 Dec 2021 07:18:54 -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 2zoJneeEbSLR for ; Fri, 10 Dec 2021 07:18:50 -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 488393A07D3 for ; Fri, 10 Dec 2021 07:18:50 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mvhfb-000JRi-GD; Fri, 10 Dec 2021 10:18:47 -0500 Date: Fri, 10 Dec 2021 10:18:41 -0500 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <3A7C843BDE4C01C1809C3A22@PSB> In-Reply-To: References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Editorial/procedural comment (was:Re: Scope of submission/delivery and address alteration) 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, 10 Dec 2021 15:18:55 -0000 --On Friday, December 10, 2021 06:10 -0800 Dave Crocker wrote: > On 12/9/2021 8:36 PM, John C Klensin wrote: >> As a handy example, the seemingly >> simple tasks of cleaning source routes out of the body of the >> text, including figuring out just what that meant in practice, >> has taken two iterations of the I-D already and will take at >> least one more. Even if we had comprehensive agreement on a >> principle like "as soon as an RCPT field is changed, it isn't >> SMTP any more" (and I don't think that has been proposed), > > Gosh. I thought it had. >... If that was what you intended, it was not sufficiently clear to me. I therefore opted to make a more general comment rather than attributing to you and getting flamed for being wrong because you were suggesting something more subtle. In any event, I think the more substantive part of the message is more important. john From nobody Fri Dec 10 12:37:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C23A077E for ; Fri, 10 Dec 2021 12:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxMIrWUoeS3Y for ; Fri, 10 Dec 2021 12:37:45 -0800 (PST) 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 8CBD43A078E for ; Fri, 10 Dec 2021 12:37:45 -0800 (PST) Received: from smtpclient.apple (unknown [192.168.1.149]) (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 42032F3888 for ; Fri, 10 Dec 2021 15:37:44 -0500 (EST) 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: <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> Date: Fri, 10 Dec 2021 15:37:43 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <0B5C8D87-D6B7-4D5B-8CBD-F59D4A25E2E0@dukhovni.org> References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration 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, 10 Dec 2021 20:37:50 -0000 > On 9 Dec 2021, at 10:42 pm, Dave Crocker wrote: >=20 > It is easy to say "relaying is movement until processing of the = address in RCPT-To is complete and the act of completion has either = delivery of failure. >=20 > Revising that simple model to include address transformation of = RCPT-TO is at least odd, given that we still need the upper-level model = for mailing lists, which also must deal with that 'transformation'. Many real-world email systems present a public abstraction of the recipient mailbox as: Publc.User@admd.example where that address is transformed at edge to something along the lines of: internal-uid@store1.admd.example and sent there via SMTP or LMTP for delivery. The message is still *inbound* and not being relayed from a recipient managed by the receiving organisation to some other organisation or other recipient. Rather, all that's happening is a NAT-like translation to an internal representation of the same recipient's address. In this not uncommon scenario, the operator view is that the receiving edge system is not performing "delivery", though it may in some cases be the authoritative place where "@admd.example" addresses are processed and disposed of, with subsequent internal hops seeing only the internal address. In some cases the transformation to "canonicalise" the localpart to the preferred address of a recipient whose mailbox is associated with multiple addresses, and the canonical address is then forwarded via SMTP (or sometimes LMTP) to the mailstore. What constitutes delivery to the originally requested recipient and what constitutes redirection to someone else or resubmission is not an easy distinction to make. :-( For purposes of adding or not adding "Delivered-To" loop-breaker header, Postfix assumes that handoff to the "local" delivery agent is "delivery" and by default handoff to an "smtp" transport is not. But the administrator can override this on a transport-by-transport basis, labelling some instances of "smtp" as representing "delivery". We don't know in advance, and the choice is left to the operator. --=20 Viktor. From nobody Sat Dec 11 12:05:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B23A088A for ; Sat, 11 Dec 2021 12:05:10 -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 LBpyHSDVbyfg for ; Sat, 11 Dec 2021 12:05:05 -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 5C04F3A0878 for ; Sat, 11 Dec 2021 12:05:04 -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 DAC52341120; Sat, 11 Dec 2021 20:05:02 +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 BBFA03414E2; Sat, 11 Dec 2021 20:05:01 +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.99.149.56 (trex/6.4.3); Sat, 11 Dec 2021 20:05:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Little-Invention: 75e429c6647df18d_1639253102626_2864229454 X-MC-Loop-Signature: 1639253102626:2023676554 X-MC-Ingress-Time: 1639253102626 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 4JBJf35p5Qz7bQV3; Sat, 11 Dec 2021 20:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639253101; bh=sEN4ejHmyiPRK39S9sW7Rd/vSDm4rb9Ui1wZTCOue4E=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=OFBOXmiPNqZS2i7DIfrqIfr57T+fTLzkJ9cb4gNX0Mfar/nsNAjdMqA4HyprKcXNv 0S2/fbpTqeCtlnf/IUa+3ShNm8FFbrCMYqUkwblUhWxTYFYMEhNelSG7M6jrUmO4et kDmyNTNfkp9aI2HwwfVVfkR4hXj+9EZyzZARpqVwwP9i4HFS/5zj7FRh69noXKAgaX 0luc9/o996Ds3MU9QRN8B2zRYHk2XTjn9AEwvzy1z9jx5dfedqzMjsuk5FO8D9C54U ZH1BCScYAKZJ5Q29nNHfLRsViZ0iBfC+JEUvSQ4HqOdzQ2+TS5DLTt1YaYWEqMh/nx X3thpV1N/nzPg== Message-ID: Date: Sat, 11 Dec 2021 12:04:58 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org, Viktor Dukhovni References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> <0B5C8D87-D6B7-4D5B-8CBD-F59D4A25E2E0@dukhovni.org> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <0B5C8D87-D6B7-4D5B-8CBD-F59D4A25E2E0@dukhovni.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 20:05:11 -0000 On 12/10/2021 12:37 PM, Viktor Dukhovni wrote: >> On 9 Dec 2021, at 10:42 pm, Dave Crocker wrote: >> It is easy to say "relaying is movement until processing of the >> address in RCPT-To is complete and the act of completion has either >> delivery of failure. >> Revising that simple model to include address transformation of >> RCPT-TO is at least odd, given that we still need the upper-level model >> for mailing lists, which also must deal with that 'transformation'. > > Many real-world email systems present a public abstraction of the > recipient mailbox as: > Publc.User@admd.example > > where that address is transformed at edge to something along > the lines of: > > internal-uid@store1.admd.example > > and sent there via SMTP or LMTP for delivery. The message > is still *inbound* and not being relayed from a recipient > managed by the receiving organisation to some other organisation > or other recipient. Rather, all that's happening is a NAT-like > translation to an internal representation of the same recipient's > address. In other words, it reaches the specified address, and local processing decides to continue things with a fresh address. That description isn't any different than for a mailing list. > What constitutes delivery to the originally requested recipient and > what constitutes redirection to someone else or resubmission is not > an easy distinction to make. :-( On the other hand, it's quite simple to note that, in terms of abstract architecture, they are exactly the same. The problem is trying to treat what is really the same functionality as different because we think of the two as serving different purpose or because we commonly make implementation choices that are different, though that isn't required. > For purposes of adding or not adding "Delivered-To" loop-breaker > header, Postfix assumes that handoff to the "local" delivery agent > is "delivery" and by default handoff to an "smtp" transport is not. Yet adding a Delivered-To in both cases is entirely reasonable, privacy concerns notwithstanding. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Dec 11 13:07: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 CA0DF3A07BA for ; Sat, 11 Dec 2021 13:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 4ZpuGOsPSPKy for ; Sat, 11 Dec 2021 13:07:20 -0800 (PST) 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 091673A07BC for ; Sat, 11 Dec 2021 13:07:19 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1BCAEF410E; Sat, 11 Dec 2021 16:07:17 -0500 (EST) Date: Sat, 11 Dec 2021 16:07:17 -0500 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> <0B5C8D87-D6B7-4D5B-8CBD-F59D4A25E2E0@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 21:07:23 -0000 On Sat, Dec 11, 2021 at 12:04:58PM -0800, Dave Crocker wrote: > > The message is still *inbound* and not being relayed from a > > recipient managed by the receiving organisation to some other > > organisation or other recipient. Rather, all that's happening is a > > NAT-like translation to an internal representation of the same > > recipient's address. > > In other words, it reaches the specified address, and local processing > decides to continue things with a fresh address. That's one take, another take is that the message is continuing on its way to the originally requested recipient's mailbox, but to reach that mailbox a local representation of its SMTP address is substituted. > That description isn't any different than for a mailing list. Well, mailing lists, such as this one, are in fact rather different, in that they replace the envelope sender, add "Sender" and "List-" headers, ... But sure, much simpler historical 1-to-many forwarding via Sendmail aliases for redirecting mail to someone else has an implementation that is essentially identical to rewriting a recipient's address to an internal form, but I'd argue that semantically they're not the same. > > What constitutes delivery to the originally requested recipient and > > what constitutes redirection to someone else or resubmission is not > > an easy distinction to make. :-( > > On the other hand, it's quite simple to note that, in terms of abstract > architecture, they are exactly the same. We strive to make things as simple as possible, but no simpler. > The problem is trying to treat what is really the same functionality as > different because we think of the two as serving different purpose or > because we commonly make implementation choices that are different, > though that isn't required. The operator's view is rather different. If the edge system supports "recipient extensions" (user+extension@admd.example), but the mailstore does not, one might at the edge drop the extension from the envelope recipient address (while preserving it in headers): user+extension@admd.example -> user@admd.example and then relay the truncated localpart the mailstore. You'd argue this constitutes a delivery, and, yes, there's some mathematical elegance to this strictly logical viewpoint, but I don't it is a fair reflection of operational reality. > > For purposes of adding or not adding "Delivered-To" loop-breaker > > header, Postfix assumes that handoff to the "local" delivery agent > > is "delivery" and by default handoff to an "smtp" transport is not. > > Yet adding a Delivered-To in both cases is entirely reasonable, privacy > concerns notwithstanding. Well, for that we'd need to also have the envelope split to one recipient per transaction, as otherwise we'd leak "Bcc" addresses. The local delivery agent does exactly that, always delivers one recipient at a time, but SMTP keeps groups of recipients with the same nexthop bundled together (up to the destination recipient limit). To add "Delivered-To" to SMTP one needs to conjure up an SMTP transport with the recipient limit set to 1, and set the flags to signal that this transport is performing "delivery". Anyway, the question at hand really has no right answer, we're looking at it from incompatible perspectives, each leads to a different conclusion. The perspectives aren't right or wrong, they just "are". -- Viktor. From nobody Sat Dec 11 14:56:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA75E3A085A for ; Sat, 11 Dec 2021 14:56:42 -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=u7jOuZK/; dkim=pass (2048-bit key) header.d=taugh.com header.b=fHtqCWsp 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 PA92CZqn_cp1 for ; Sat, 11 Dec 2021 14:56:38 -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 EF7573A05AA for ; Sat, 11 Dec 2021 14:56:37 -0800 (PST) Received: (qmail 32831 invoked from network); 11 Dec 2021 22:56:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=803c.61b52ca2.k2112; bh=a1JJP4CRAs46uryB7hiR/++mCaILxO84wNuBY3rzX4s=; b=u7jOuZK/b+D/siCY/9JKE22gPs3L3vVjz5gi9IeYmy20+Mme7yJFngykPtUHys4GYu4dQGQ+PvXNZdGPsPna/F4Y6bgFr6eOydaENLQodJNxMRBUjetF6Bos69d3eJdl2n4rXqj/UWn03mZLSqoOCYxixMseuLSqUsEP9XLIvrVRT8Jt2wBUC+G42hlgAOSpt5tXuW/X6N+Garg0HLC7Lyg95mRWlGH0LaVwwFnOkgBkyMugl+/Op5oDVK/7Ak33kEcHp8m4v3C4hD7SDFzSD6juRHn8J85TcnE61NTjJCQhuLH9dHVDX6zhfEAy55vu9Y5f1UbfW/Ht9yY4QeZ4Zw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=803c.61b52ca2.k2112; bh=a1JJP4CRAs46uryB7hiR/++mCaILxO84wNuBY3rzX4s=; b=fHtqCWspUr/hC5tI7azT8pxCccE5aFldGMOdWLzd0RxEt7oLdBhZc0YzqSGU469+GYZhvk+EVfBg19sswztiaACZnzKueExno8UoXqdb2ft9t6/FwShjthlZEeY8X2HwUVuyDPom+/1Uj4Ocqmz4pi2nIRqO9F8LKz/nL7A/U8HnBPH39bJ69MEUqYeeO60MXZbuLM7q+Ht5SRIpXZ+2TvVTia1OMCEJCnssCOWjsXaTeBo7Hsd4TvOzIddI+ApLE3nmGicySKFMGb143C210fNoFxJnBFE6e6RNOPQcy22kDKqS6PLnO3r8mIw6pQO3/1kFLKVSAh3uSVFGJAmRbg== 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; 11 Dec 2021 22:56:33 -0000 Received: by ary.qy (Postfix, from userid 501) id 21AA0314E8CD; Sat, 11 Dec 2021 17:56:32 -0500 (EST) Date: 11 Dec 2021 17:56:32 -0500 Message-Id: <20211211225633.21AA0314E8CD@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: 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] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 22:56:43 -0000 It appears that Viktor Dukhovni said: >Well, mailing lists, such as this one, are in fact rather different, in >that they replace the envelope sender, add "Sender" and "List-" headers, >... But sure, much simpler historical 1-to-many forwarding via Sendmail >aliases for redirecting mail to someone else has an implementation that >is essentially identical to rewriting a recipient's address to an >internal form, but I'd argue that semantically they're not the same. It seems to me that the way people use mail has changed from 20 or 30 years ago and it would be a good idea to make our definitions try to match the practice. Back in the olden days, long haul networks were slow and expensive, so people went to considerable effort to avoid sending multiple copies of messages. A site would often have an exploder that took one copy of an incoming list message and passed it along to the local users who subscribed. LISTSERV had a fancy sublist feature to manage those remotely. But these days, mail uses such a small part of network bandwidth that nobody cares and it common for a list to send each recipient a separate lightly customized copy of a message. Even for lists that don't, nobody cares whether they are sent individually or the MTA consolidates copies to a recipient MX. I see a handful of remaining uses for local exploders. The main use seems to be role accounts so postmaster@foo goes to mary, or sales@foo goes to beth, jane, and fred. There is definitely the local rewriting tht Viktor described. There may be some technical similarities between the local rewriting and mailing lists, but the semantics are quite different and I don't think we'd do anyone a favor by continuting to conflate them. R's, John From nobody Sat Dec 11 15:34: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 082E43A08BD for ; Sat, 11 Dec 2021 15:34:13 -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 UPdE4l10QVkj for ; Sat, 11 Dec 2021 15:34:08 -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 0DCCD3A08B9 for ; Sat, 11 Dec 2021 15:34:07 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mwBsT-0000S8-Rc; Sat, 11 Dec 2021 18:34:05 -0500 Date: Sat, 11 Dec 2021 18:34:00 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <504B78E118C05C53D8B92F6A@PSB> In-Reply-To: <20211211225633.21AA0314E8CD@ary.qy> References: <20211211225633.21AA0314E8CD@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 23:34:13 -0000 --On Saturday, December 11, 2021 17:56 -0500 John Levine wrote: > It appears that Viktor Dukhovni said: >> Well, mailing lists, such as this one, are in fact rather >> different, in that they replace the envelope sender, add >> "Sender" and "List-" headers, ... But sure, much simpler >> historical 1-to-many forwarding via Sendmail aliases for >> redirecting mail to someone else has an implementation that >> is essentially identical to rewriting a recipient's address >> to an internal form, but I'd argue that semantically they're >> not the same. > > It seems to me that the way people use mail has changed from > 20 or 30 years ago and it would be a good idea to make our > definitions try to match the practice. > > Back in the olden days, long haul networks were slow and > expensive, so people went to considerable effort to avoid > sending multiple copies of messages. A site would often have > an exploder that took one copy of an incoming list message and > passed it along to the local users who subscribed. LISTSERV > had a fancy sublist feature to manage those remotely. > > But these days, mail uses such a small part of network > bandwidth that nobody cares and it common for a list to send > each recipient a separate lightly customized copy of a > message. Even for lists that don't, nobody cares whether they > are sent individually or the MTA consolidates copies to a > recipient MX. > > I see a handful of remaining uses for local exploders. The > main use seems to be role accounts so postmaster@foo goes to > mary, or sales@foo goes to beth, jane, and fred. There is > definitely the local rewriting tht Viktor described. > > There may be some technical similarities between the local > rewriting and mailing lists, but the semantics are quite > different and I don't think we'd do anyone a favor by > continuting to conflate them. John, I think I agree, with two qualifications/ thoughts: (1) Whether it has done so well or poorly, the SMTP specs have tried to keep what I think are those two approaches separate from many years (back at least to 2821 and probably longer). Are you suggesting changing anything at this point and, if so, would be be substantive or, e.g., better explanation and better examples? (2) Very similar arguments about the evolution of the network can be used to suggest that relays, MX records, etc., are much less important then they were in, e.g., early 1976 when RFC 974 was published. If one ignores transitions between private networks or networks not running TCP/IP and the public Internet and possibly does a bit of handwaving around what X.400 called ADMDs, we are doing far less relaying now than was the case 30 or 35 years ago. Concentrating only on connections between endpoints, removing all of those inconvenient relay stuff from 5321 and putting it into a "rare cases" appendix or separate document, would simplify the core SMTP specification considerably. Now, AFAICT, no one has proposed going that far (and I certainly would not). But a little thought about where we would draw the line if we start taking things out because they are obsolete or less important than they were 20 or 30 years ago might help clarify some recent discussions. best, john From nobody Sat Dec 11 18:17:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6073A074D for ; Sat, 11 Dec 2021 18:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Zt6r3ySv; dkim=pass (2048-bit key) header.d=taugh.com header.b=R2nqIxru 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 TCQQL2ySOT7y for ; Sat, 11 Dec 2021 18:17:20 -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 2F2873A074B for ; Sat, 11 Dec 2021 18:17:19 -0800 (PST) Received: (qmail 59966 invoked from network); 12 Dec 2021 02:17:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=ea3a.61b55bad.k2112; bh=Pyl5HwKioduRX1MwJR5cJHg9pEYyTIZGSGUP4pOpm2Q=; b=Zt6r3ySvovmabqlMby7wEYbJCw0Z8evCvnWW/9qMiMdReeIwtFP6DcXGU+LcMGcro8QqYbfODSNhvsi/8w3O2qYlk4S8zp0J/HbrM8RwpOnsaMRRI8FZKMDLtcwkoEqiktdcAWMs0scZ1E/enZLzK4/IovFJY2rAnL5qOjiLShSV2F4yTTa8kJ0mMZ10Pa9knjqyrMccLuuRcGeMKh6C90z6U/fuT2IwWBtlzUIXOLnvK2MZ48/emA/5hao/Up1Le7f3oUia6cUjBBKIUMIgUm07dYYQffhExjcNChX1H7bOLwKE2I5SirNlqjLDZl/b1HpUcxjyewogdVxnyeLopA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=ea3a.61b55bad.k2112; bh=Pyl5HwKioduRX1MwJR5cJHg9pEYyTIZGSGUP4pOpm2Q=; b=R2nqIxruBZoicjyhbM6HsvAVFYM7QOZZgxA9ED32kPwoWWNK3tedzPODWB+0udY5EiImWtC7oMvHM0jmjmwsANrsa20p57B44R0WW9wklc2om2f+dzPq4qI76mWmpXeoA4BFcyDooCPk0uPdmDuMm7CP+4M4DfmIDlDq9+LnKuUkKrh5x/2XtwW9nlwy1QycqLG/m93zxtEVrKNjqzY8RRhhdHUROnEsuHoNiIzGt2BXA6OFsPqL0pwc7+TV5VnHBOqeBCfT9Li5X317Nl8l4DP3y/lTZSWftiORgWueOXAu3BNrA0x2+EgbtXpzSdOHjHYNBq8zjPTbDN4nfzlEcA== 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; 12 Dec 2021 02:17:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 81334314FC5B; Sat, 11 Dec 2021 21:17:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 033B4314FC3D; Sat, 11 Dec 2021 21:17:15 -0500 (EST) Date: 11 Dec 2021 21:17:14 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <504B78E118C05C53D8B92F6A@PSB> References: <20211211225633.21AA0314E8CD@ary.qy> <504B78E118C05C53D8B92F6A@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2021 02:17:25 -0000 > (1) Whether it has done so well or poorly, the SMTP specs have > tried to keep what I think are those two approaches separate > from many years (back at least to 2821 and probably longer). > Are you suggesting changing anything at this point and, if so, > would be be substantive or, e.g., better explanation and better > examples? I think just the latter. In 5321 section 3.9, I would shorten the discussion and say that aliases that just change the envelope are typically used for address management, such as sending mail addressed to role accounts to the individuals who handle it, to rewrite addresses when a mail system's internal address structure is different from the externally visible structure. I'd take out "exploders". For mailing lists, I'd shorten it a lot and say that most lists make enough changes to the mail they process that they are in practice MUAs that rewrite and remail the messages. > (2) Very similar arguments about the evolution of the network > can be used to suggest that relays, MX records, etc., are much > less important then they were in, e.g., early 1976 when RFC 974 > was published. I suppose, but large mail systems still use multiple MXes, e.g. $ host -t mx gmail.com gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com. gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com. gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com. gmail.com mail is handled by 5 gmail-smtp-in.l.google.com. gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com. $ host -t mx yahoo.com yahoo.com mail is handled by 1 mta7.am0.yahoodns.net. yahoo.com mail is handled by 1 mta6.am0.yahoodns.net. yahoo.com mail is handled by 1 mta5.am0.yahoodns.net. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Dec 11 18:52: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 BD0FC3A079F for ; Sat, 11 Dec 2021 18:52:54 -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 1m6IMQFeAAQ7 for ; Sat, 11 Dec 2021 18:52:50 -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 51D913A079E for ; Sat, 11 Dec 2021 18:52:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mwEyj-0000gn-Sk; Sat, 11 Dec 2021 21:52:45 -0500 Date: Sat, 11 Dec 2021 21:52:39 -0500 From: John C Klensin To: John R Levine , emailcore@ietf.org Message-ID: In-Reply-To: References: <20211211225633.21AA0314E8CD@ary.qy> <504B78E118C05C53D8B92F6A@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: Re: [Emailcore] Scope of submission/delivery and address alteration X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2021 02:52:55 -0000 --On Saturday, December 11, 2021 21:17 -0500 John R Levine wrote: >> (1) Whether it has done so well or poorly, the SMTP specs have >> tried to keep what I think are those two approaches separate >> from many years (back at least to 2821 and probably longer). >> Are you suggesting changing anything at this point and, if so, >> would be be substantive or, e.g., better explanation and >> better examples? > > I think just the latter. In 5321 section 3.9, I would shorten > the discussion and say that aliases that just change the > envelope are typically used for address management, such as > sending mail addressed to role accounts to the individuals who > handle it, to rewrite addresses when a mail system's internal > address structure is different from the externally visible > structure. I'd take out "exploders". > > For mailing lists, I'd shorten it a lot and say that most > lists make enough changes to the mail they process that they > are in practice MUAs that rewrite and remail the messages. If there is general agreement (aka "rough consensus") for this, it works for me and would, I think, make things quite a bit more clear to a contemporary reader. >> (2) Very similar arguments about the evolution of the network >> can be used to suggest that relays, MX records, etc., are much >> less important then they were in, e.g., early 1976 when RFC >> 974 was published. > > I suppose, but large mail systems still use multiple MXes, e.g. > > $ host -t mx gmail.com > gmail.com mail is handled by 10 > alt1.gmail-smtp-in.l.google.com. > gmail.com mail is handled by 20 > alt2.gmail-smtp-in.l.google.com. > gmail.com mail is handled by 40 > alt4.gmail-smtp-in.l.google.com. > gmail.com mail is handled by 5 gmail-smtp-in.l.google.com. > gmail.com mail is handled by 30 > alt3.gmail-smtp-in.l.google.com. > > $ host -t mx yahoo.com > yahoo.com mail is handled by 1 mta7.am0.yahoodns.net. > yahoo.com mail is handled by 1 mta6.am0.yahoodns.net. > yahoo.com mail is handled by 1 mta5.am0.yahoodns.net. Good counterexample. Thanks. john From nobody Mon Dec 13 09:14:23 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 96D853A090F; Mon, 13 Dec 2021 09:14:21 -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.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163941566144.7349.7415484735807341835@ietfa.amsl.com> Date: Mon, 13 Dec 2021 09:14:21 -0800 Archived-At: Subject: [Emailcore] Revision of core Email specifications (emailcore) WG Virtual Meeting: 2022-01-21 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, 13 Dec 2021 17:14:22 -0000 The Revision of core Email specifications (emailcore) WG will hold a virtual interim meeting on 2022-01-21 from 17:00 to 18:30 Europe/London (17:00 to 18:30 UTC). Agenda: To finish discussion about aliases vs mailing lists, and other terminology topics. Information about remote participation: https://us06web.zoom.us/j/89359071984?pwd=ZXZSOVBtc0RPWUl1RjhUUGlRZzZQQT09 From nobody Tue Dec 14 12:19:25 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9C3A08BE for ; Tue, 14 Dec 2021 12:19:24 -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 AFnDG5GPtEWX for ; Tue, 14 Dec 2021 12:19:19 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6923A08B9 for ; Tue, 14 Dec 2021 12:19:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxEGY-0008su-ME for emailcore@ietf.org; Tue, 14 Dec 2021 15:19:14 -0500 Date: Tue, 14 Dec 2021 15:19:08 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <16CA9B793AF5DAC997461808@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] forwarding, aliases, and mailing lists 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, 14 Dec 2021 20:19:24 -0000 Hi. (Editor hat on) I have been rereading the discussion on this topic, thinking about the interim meeting discussion, and studying RFC 5321 vis-a-vis. I now think that several of the comments result from unnecessary separation of related materials in 5321, especially materials in sections 3.4 and 3.9. I therefore propose to consolidate those two sections, removing redundant material and clarifying definitions. That leads to two questions: (1) Is doing that generally acceptable? If it is not, I don't want to do the work, in part because it would probably be hard to undo. Note, fwiw, that this is one of the types of changes we avoided in constructing 2821 and 5321, so one consideration of its acceptability is whether people are willing to do a careful review. If it is controversial, the change won't be made (and no other change will be made on this topic) in rfc5321bis-08, probably lowering the odds of our being finished by March. (2) As I read the text and review other notes, it appears that we may have made a historical distinction between an "alias" and "forwarding". The latter appears to have been about substituting and using a different address within a host or administrative domain; the latter to an entirely different system. If there is any text in 5321 that requires that one input address be replaced by one output address, I have not yet been able to find it. One of the suggestions made during the interim was that we get rid of the distinction and use only one term (I think with the assumption that "forwarded" was not used elsewhere than in 3.9). Are we confident that we want to eliminate the distinction? Or that we do not? Awaiting comments or instructions... john From nobody Tue Dec 14 20:19: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 9DF903A07B7 for ; Tue, 14 Dec 2021 20:19:30 -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=LOvCKIFV; dkim=pass (2048-bit key) header.d=taugh.com header.b=EStzo50H 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 Xn4LI6jCyP6u for ; Tue, 14 Dec 2021 20:19:26 -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 BBE7C3A07C1 for ; Tue, 14 Dec 2021 20:19:25 -0800 (PST) Received: (qmail 79390 invoked from network); 15 Dec 2021 04:19:22 -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=1361b.61b96cca.k2112; bh=58dYIK0RL4adF1tI5fMduCJ3EE4WUbC2mF7O+nFyg5w=; b=LOvCKIFVtxF5Krj1aSg4Oy1u68dqOCXBzgWZUcRqr/OfG996oyq20uoujp5mgJsZfUBsRVoLtO+Xpg9knqBiqqwCPNXB+ux48rQbl9Frg25mTk/KxVbDpT2y/K/Y87r2tSGLvkZpskKxdkqWvG2hg7e6Vt0WktGTjZbCGO7KX+j4bB2MmrFGtMqZTlT/gi2x0ZrOSN3bqQ9wHBXl+Ws9ipBAbfBw5w/ShjVgwKBqvCWr/ZYbtAwJUaIIX3Xtj9vibGNonZ9EbWGooAiaJa+t5pdxkoTINPtof+KW2fMebjtD8y/D1XrnYJ4UyYJyuws7FR8uUZJJ/Sb7f7Iiuk5fRg== 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=1361b.61b96cca.k2112; bh=58dYIK0RL4adF1tI5fMduCJ3EE4WUbC2mF7O+nFyg5w=; b=EStzo50HeJC+5u8CUa2doQGhg56TmFaJeCwWyR71COAjz6arAhsneVRxVRE5QAGO1SagEKdha9hvShRPhYEqm9AbMBH4KOZrsfm2JnM/Pc9S5xjXPV5Ky4/ziPhANyBJuCHk7y2TKWsPQv/TDSb6pvGpnV1oYJa3VJnEQSrF8V+Ov4JCosdEKRKM5l3VdN82x0q4YmjZHtCp0Y0H3KCUZ84360J0w0gwQee3youO/s1IrjzuZ8i6Gb+r/DuKbsMN8hY/8LDzKO5t5VdmoxI3pKQy2/faGgQ6M3tvtbydb/jAXLqrNB+bb4q1k8T55G0vyKhxJ9Ve9Ohc75HN6noiCw== 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; 15 Dec 2021 04:19:22 -0000 Received: by ary.qy (Postfix, from userid 501) id E6899325AEF2; Tue, 14 Dec 2021 23:19:21 -0500 (EST) Date: 14 Dec 2021 23:19:21 -0500 Message-Id: <20211215041921.E6899325AEF2@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <16CA9B793AF5DAC997461808@PSB> 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] forwarding, aliases, and mailing lists 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, 15 Dec 2021 04:19:31 -0000 It appears that John C Klensin said: >I therefore propose to consolidate those two sections, removing >redundant material and clarifying definitions. >(1) Is doing that generally acceptable? OK by me. >(2) As I read the text and review other notes, it appears that >we may have made a historical distinction between an "alias" and >"forwarding". The latter appears to have been about >substituting and using a different address within a host or >administrative domain; the latter to an entirely different >system. ... While you're at it, you should look at section 7.4 about the 251 and 551 response codes. I believe that a very long time ago, the idea was that forwarding was for people who had moved, was intended to be temporary with 251 and 551 response codes to tell senders to update their address books, while aliases were for role accounts and local nicknames. Dunno if that ever actually worked but it sure doesn't work now, and I see no reason to preserve the distinction. R's, John From nobody Wed Dec 15 05:35:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64343A077E for ; Wed, 15 Dec 2021 05:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaWWAP_3KCNo for ; Wed, 15 Dec 2021 05:35:32 -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 B9F5E3A0412 for ; Wed, 15 Dec 2021 05:35:32 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxURP-000B4X-6l; Wed, 15 Dec 2021 08:35:31 -0500 Date: Wed, 15 Dec 2021 08:35:25 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <008E613693F5A086A2FF1B5E@PSB> In-Reply-To: <20211215041921.E6899325AEF2@ary.qy> References: <20211215041921.E6899325AEF2@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] forwarding, aliases, and mailing lists 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, 15 Dec 2021 13:35:44 -0000 --On Tuesday, December 14, 2021 23:19 -0500 John Levine wrote: > It appears that John C Klensin said: >... >> (2) As I read the text and review other notes, it appears >> that we may have made a historical distinction between an >> "alias" and "forwarding". The latter appears to have been >> about substituting and using a different address within a >> host or administrative domain; the latter to an entirely >> different system. ... > > While you're at it, you should look at section 7.4 about > the 251 and 551 response codes. > > I believe that a very long time ago, the idea was that > forwarding was for people who had moved, was intended to be > temporary with 251 and 551 response codes to tell senders to > update their address books, while aliases were for role > accounts and local nicknames. Dunno if that ever actually > worked but it sure doesn't work now, and I see no reason to > preserve the distinction. IIR, at one time --long ago and before we became nearly as sensitive about disclosures of privacy-related things-- the stuff about updating address books was heavily used (in at least some parts of the Internet) and worked. And, yes, that was the distinction I was referring to. I can certainly clarify that and put in a cross-reference or two whether we consolidate the two subsections or not. thanks, john From nobody Wed Dec 15 09:12:31 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 87F373A0772 for ; Wed, 15 Dec 2021 09:12:29 -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 8-BjbjGfm1Vn for ; Wed, 15 Dec 2021 09:12:24 -0800 (PST) Received: from azure.dogwood.relay.mailchannels.net (azure.dogwood.relay.mailchannels.net [23.83.211.7]) (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 869AB3A0770 for ; Wed, 15 Dec 2021 09:12:21 -0800 (PST) Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 02420885B39; Wed, 15 Dec 2021 17:04:12 +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 9BED1889D1B; Wed, 15 Dec 2021 17:03:45 +0000 (UTC) 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.82 (trex/6.4.3); Wed, 15 Dec 2021 17:04:11 +0000 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 4JDhR32LZwz2bkwQ; Wed, 15 Dec 2021 17:03:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639587824; bh=VPB9bhQTOtU3hgC9CRaClvpegQwNpFtQl2I13At0210=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=UIs+qwlxQjIPgH52ohYyEH3p/Ph7JaH5/q0GvIFWErX7F0brs3auP39Xil3yh1RzT MoiekYnJH54MxIqJZ/mj66cYW8Do3kH5pN1U2qw5Oj4/mNqHJ86XtYOI78XZoQAsjZ 8Q6PpSk39Z+Zf8kxgxSJ7tO/vE6SNi1bzSbazNtsu4KULMmEAWBRbPNB9+rY+LEvpP 7aCC/PGj6iktpxO1+lUE6kOCdUWbYfX1sKL8/Cm7erwey/k2NBABr+Hrx/iccZOKgP wfBtHYOo3k9KWgeYeGUktRp6NtYQRFMIA58yb7Z2C+0v44Uf6RZjN3JZ91hX9YY87A HDkR0WmA26ocQ== Message-ID: <1fc698ed-62c4-d4f7-0562-128918bdb66a@dcrocker.net> Date: Wed, 15 Dec 2021 09:03:41 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org, Viktor Dukhovni References: <20211210030007.CF7FD3136232@ary.qy> <36e403f2-d060-98e4-bd22-161d8c3dddd0@dcrocker.net> <0B5C8D87-D6B7-4D5B-8CBD-F59D4A25E2E0@dukhovni.org> 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: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 15 Dec 2021 17:12:30 -0000 On 12/11/2021 1:07 PM, Viktor Dukhovni wrote: > On Sat, Dec 11, 2021 at 12:04:58PM -0800, Dave Crocker wrote: > >>> The message is still *inbound* and not being relayed from a >>> recipient managed by the receiving organisation to some other >>> organisation or other recipient. Rather, all that's happening is a >>> NAT-like translation to an internal representation of the same >>> recipient's address. >> >> In other words, it reaches the specified address, and local processing >> decides to continue things with a fresh address. > > That's one take, another take is that the message is continuing on its > way to the originally requested recipient's mailbox, but to reach that > mailbox a local representation of its SMTP address is substituted. Viktor, Thanks for responding on this key issue. It's likely your view is shared by others, though it would be good to hear from them too. In an effort to distinguish 'architecture' from 'implementation', there should be abstract, functional differences that distinguish architectural modules, where those differences are independent of implementation choices. That is, 'this is the way we've been running it' is implementation. Whereas "there is a natural functional split here" is more architectural, especially when alternative implementation choices are reasonable. A useful reference for this kind of thinking is the classic: Tussle in Cyberspace: Defining Tomorrow's Internet http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.pdf Here are some issues with the view you've offered, where the challenge should be to reconcile these issues thoughtfully, rather than just dismiss them: 1. The author specifies a particular address. The only information the email service has, about the author's 'intent', is that address. A protocol specification that attempts to claim and use deeper 'knowledge' about an author's intent has wandered into metaphysics, since it is relying on information that is not in the message or its envelope. When a receiving system changes that address, it is known to represent the 'intent' of the receiving system, not of the author. At the least, the view you offer requires quite a different and more-detailed, and possibly more nuanced definition of 'delivery' than we've been using for about 50 years. Note that simply saying something like "until the message has reached the address specified in RCTP-TO" is far simpler, far easier to understand, technically reasonable and functionally sufficient. 2. The description you give also seems to match the behavior of email transiting a mailing list. In fact it is arguably more suited to act of sending to a mailing list than to an individual address, since it is a lot more likely -- but only likely, not certain -- that the author knows they are sending to a mailing list and, therefore, that they are expecting the message to continue on, beyond the specified address. In contrast it is unlikely the author knows that the address they are using will get changed. If the claim is that mailing lists are different, what is the technical specification of that difference and what are the architectural features that justify that choice of distinguishing features? (Hint: "We've implemented this way" is a statement about implementation, not network architecture.) 3. Given the equivalence between alias and mailing list, is the intent, here, to also include mailing list processing into the architectural definition of an MTA? That would mean that any MTA along the path can replace the value of the RCPT-TO if it feels like it, since we offer no technical specification for these behaviors. Pretty much the same dilemma applies if the feature is allowed to any MDA. 4. An underlying point seems to be the view that changing only RCTP-TO is architecturally different than making changes to the message header or body. The obvious question is why and how? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 15 10:01:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088213A0745 for ; Wed, 15 Dec 2021 10:01:00 -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 C3eiVyVMOngr for ; Wed, 15 Dec 2021 10:00:54 -0800 (PST) Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) (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 836353A06E7 for ; Wed, 15 Dec 2021 10:00:54 -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 F388D20DA3; Wed, 15 Dec 2021 17:25:40 +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 5C34520DB3; Wed, 15 Dec 2021 17:25:40 +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.121.9.210 (trex/6.4.3); Wed, 15 Dec 2021 17:25:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Spot-Minister: 1eb6edc6768ddac3_1639589140730_351424517 X-MC-Loop-Signature: 1639589140730:783660831 X-MC-Ingress-Time: 1639589140730 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 4JDhwL3NC4z7Y4l3; Wed, 15 Dec 2021 17:25:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639589139; bh=QTHA4yNUZKgsNk9PtPuP5V0lQTaqXPMJWWayo/SlkRg=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=ZDTse3n0ArG034cFH3jvbN67r7sZ6Tkf5h2qAj9k4CoLKb10MpXLaOG/fd3PDsf1C zvk6hqeydvL0RyjKbRYVwyrP3z4B/pIzS2w876yLyymt5yTb6XbPsg74FRXeWbV5+K fgLSXvM2reZDedfVxSlBpdzAxcm12gP4vrGMZLdlfUgwDM0VJdOIHYJA/AFTRQ5ufY eVtAF6XThgEZfk2gfQl9lwEKNp18CyAmThLOus297yEmGDGMgPyuKY9hKwR+UbZ3t7 wmHQD2Wnp89MxKC8GfTzyi1CDislq6A3kYYUIq3dQ3VmySt7gnntInaXIYv8S4ACEz g8uxQDkLPq+0Q== Message-ID: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> Date: Wed, 15 Dec 2021 09:25:36 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Alessandro Vesely , 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 18:01:00 -0000 A domain name that is registered through the ICANN hierarchy of registries is 'valid'. What your effort, here, does is to bring back 'resolvability', which I assume is what you really mean by 'validity'. d/ On 7/13/2021 4:27 AM, Alessandro Vesely wrote: > On Fri 09/Jul/2021 21:24:47 +0200 Todd Herr wrote: >> >> I propose the following as a strawman... >> >> Change the above paragraph to read as follows: >> >>     An SMTP server MAY verify that the domain name argument in the EHLO >>     command has an address record matching the IP address of the client. > > > I'd make that even more abstract, for example: > >     An SMTP server MAY verify the validity of the domain name argument in >     the EHLO command. > > Domain name to IP, IP to PTR name, SPF, and more are different > verification criteria, sometimes overlapping and sometimes not. > > >> And include the following text in the Applicability Statement: >> >>   [snip text to be discussed at A/S time] > > > Best > Ale -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 15 10:41:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B293D3A0C50 for ; Wed, 15 Dec 2021 10:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 rQeHs2CyWxct for ; Wed, 15 Dec 2021 10:40:56 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC363A0C4B for ; Wed, 15 Dec 2021 10:40:56 -0800 (PST) Received: (qmail 2196422 invoked from network); 15 Dec 2021 18:40:55 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (8960a7ba-5dd6-11ec-8f31-8312e537a5f1); Wed, 15 Dec 2021 10:40:55 -0800 To: emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Wed, 15 Dec 2021 10:40:55 -0800 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: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 8960a7ba-5dd6-11ec-8f31-8312e537a5f1 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 18:41:02 -0000 An industry standard, and MAAWG recommendation, the domain portion in the PTR and in the email MAIL FROM should not only be resolvable, but should have an accompanying URL publicly accessible, so inquiries related to those domains can find a contact for the operators. As far as EHLO is concerned, there are STILL cases where the domain in the EHLO is an internal domain, representing the name of the server, according to internal requirements. EG, there should not yet be a constraint that would prevent the use of 'mail-unit-3.seattledatacenter.ibm' if all servers at IBM used an internal TLD of .ibm. The PTR is there to check validity of the exit node. EHLO is meant for a different historical purpose IMHO. I don't think IETF should by policy require broad sweeping industry changes in practice. IMHO.. The EHLO value is valuable, no matter how a company names it's internal servers.. EHLO/HELO means .. 'Hi, I am named this' effectively. IP should of course NOT be used, as that is the lack of an identifying name for the server initiating the connection. On 2021-12-15 9:25 a.m., Dave Crocker wrote: > A domain name that is registered through the ICANN hierarchy of > registries is 'valid'. > > What your effort, here, does is to bring back 'resolvability', which I > assume is what you really mean by 'validity'. > > d/ > > > > On 7/13/2021 4:27 AM, Alessandro Vesely wrote: >> On Fri 09/Jul/2021 21:24:47 +0200 Todd Herr wrote: >>> >>> I propose the following as a strawman... >>> >>> Change the above paragraph to read as follows: >>> >>>     An SMTP server MAY verify that the domain name argument in the EHLO >>>     command has an address record matching the IP address of the client. >> >> >> I'd make that even more abstract, for example: >> >>      An SMTP server MAY verify the validity of the domain name >> argument in >>      the EHLO command. >> >> Domain name to IP, IP to PTR name, SPF, and more are different >> verification criteria, sometimes overlapping and sometimes not. >> >> >>> And include the following text in the Applicability Statement: >>> >>>   [snip text to be discussed at A/S time] >> >> >> Best >> Ale > > -- "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 Wed Dec 15 11:04:05 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 3E1993A0EAA for ; Wed, 15 Dec 2021 11:04:02 -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=ALrVN6Jq; dkim=pass (2048-bit key) header.d=taugh.com header.b=KJOqq94V 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 0aT7QgHjqTYB for ; Wed, 15 Dec 2021 11:03:57 -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 ADA043A0EA9 for ; Wed, 15 Dec 2021 11:03:56 -0800 (PST) Received: (qmail 14408 invoked from network); 15 Dec 2021 19:03:53 -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=3845.61ba3c19.k2112; bh=5Nv6AaI9zfMX8tFtN7XMePGpbr3iAlE7rnRstF4LxrM=; b=ALrVN6Jq8NMz2Yb0Ux5EAIXYP+xAMKacTp6eIJktIlFR3SylnQdbbdexTlkaeQju+3qIauOEwS1il5bQaPfA5TrGQQAjI2TlxbsNPhiUIZa6bpIi4xp6/yd9emvPm0uQNAVUSqMjJ8+QY6JzZEASHW7lxp/ikDBo6w5NZFxh5iNaUP2t4VNNyU/Rn5/eG8R4zjdra5AzJOgPzcxjK7TFpdDdlnx5ROOpI7M1Rhau7ND4At/8Ym0mJdC/sgjLHmgtTmkIbnU6OC6Gb5/1EZLp5UVlcTURkTXGm9hcugoNuh41/PzyfuSFVIw43HavD8yRw35VHC61b0kt90bUaJGfVg== 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=3845.61ba3c19.k2112; bh=5Nv6AaI9zfMX8tFtN7XMePGpbr3iAlE7rnRstF4LxrM=; b=KJOqq94VET4f5pU3kWEpyLdTOZZjbNGw7CwHLLQVN+Bu/F9p3U2DhXDulcyGwzyozC2HKMyyuZEwyZpnteFAYbijtx9je23mMEaLd5kmiunXUyv2zunmS57uurK6DAeHFCc9o7rfyvFvn2JW8uSLoSKrgJlz1J4yx5ZJoIrcafOjjvppAFjgQHSeWgwpgQZ2C42TuQcLE7skQ55kYiaL4cit2WPVf0YAw2JjKn8LQZB7Hm3mmQDSHTbbLA2fLMRO4O869sl2fcboqr8OvULn4vk8nwPsCj1aDQJDrp/VFjDMpiUxm6y37ZKmX6+lx7wyYoS9i0GhWwUZobTvHOS4CQ== 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; 15 Dec 2021 19:03:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 850D3326104C; Wed, 15 Dec 2021 14:03:51 -0500 (EST) Date: 15 Dec 2021 14:03:51 -0500 Message-Id: <20211215190352.850D3326104C@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <1fc698ed-62c4-d4f7-0562-128918bdb66a@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 15 Dec 2021 19:04:03 -0000 It appears that Dave Crocker said: >When a receiving system changes that address, it is known to represent >the 'intent' of the receiving system, not of the author. ... >Note that simply saying something like "until the message has reached >the address specified in RCPT-TO" is far simpler, far easier to >understand, technically reasonable and functionally sufficient. Every mail system I've ever used treats upper and lower case equivalently. So if you send a message to JOHNL@IECC.COM, it goes into the mailbox for johnl@iecc.com. How many deliveries is that? Many mail systems allow subadddresses, so mail for bob+ext or bob-ext usually goes into the mailbox for bob. How many deliveries is that? Some systems, notably Gmail, ignore dots in the mailbox so mail to joeblow123, joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same mailbox. How many deliveries is each of those? R's, John From nobody Wed Dec 15 11:06:00 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 A09D63A0EDE for ; Wed, 15 Dec 2021 11:05:33 -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=Jrh6OmnV; dkim=pass (2048-bit key) header.d=taugh.com header.b=jcm6zaf9 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 6bxVhmvajrIi for ; Wed, 15 Dec 2021 11:05:27 -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 8E52A3A0ED0 for ; Wed, 15 Dec 2021 11:05:27 -0800 (PST) Received: (qmail 14940 invoked from network); 15 Dec 2021 19:05:24 -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=3a5a.61ba3c74.k2112; bh=5mjM3s5q3PLOAb6iERDcefhX2VnErv1KjHwnWO4GyUw=; b=Jrh6OmnVcZAM73nKjAZV1OUpQAwWdAUkfvXKEwv9eTSR0NiubZQGZjm9bD/r9ZSHFWOymVfdGQAl8+WXHGvKcqA1Jou0fMCQGX2eYF413FGiCYhNOHics8zBoiGDtEQnf9FYK7xr762og4ASkMIFgtPcZSvqS6fJtR6uZAZx5LF2tMQgbG9IdpBA2THZm2sHQDfRiavCnilITfDqvlHaU2cgk55AUG5MT/559MJjn2scvBT6/1eeyzZtlCbtbmPJgwx0+aS4BTrKx7itRg+pftNb3/rCbk0+FUnzSgzyp4b+HVbXME/g/vycCsLMa3xI5J7/LshEvC5hHex1FwLCYA== 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=3a5a.61ba3c74.k2112; bh=5mjM3s5q3PLOAb6iERDcefhX2VnErv1KjHwnWO4GyUw=; b=jcm6zaf9Gg85o5NE9G07hNtz2G5ULBN4BHF+rl85RrT/qoYB3QgocrDtVTGVqrnDi2Z22AxBj2S4wKpMMHiEPpnj8D+0xbJ4bIX0tGVSY0ukbaofm0kBDx4/wyF5ViMztCH1NJbWfvs7vuAoLYYI4sQD9QfM648F6hh6nt3NcoC509TXVvX5FlZhtezWygaRLhj4/rncZF1NwW9wgdzktI+1zfHgsKf10siQcCGGBZJEtfIIJgIbegF1uQuaqgX73lp9XDTAZEc5lQXw1p+FRHa9N6Yg9sI8QF2ttGW30Nn6RZuo09lrZ8AjMlfUM3pM+7bzTjmgdPze3B8/pwCX9g== 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; 15 Dec 2021 19:05:24 -0000 Received: by ary.qy (Postfix, from userid 501) id DE8C03261081; Wed, 15 Dec 2021 14:05:23 -0500 (EST) Date: 15 Dec 2021 14:05:23 -0500 Message-Id: <20211215190523.DE8C03261081@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: michael@linuxmagic.com In-Reply-To: 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 19:05:58 -0000 It appears that Michael Peddemors said: >An industry standard, and MAAWG recommendation, the domain portion in >the PTR and in the email MAIL FROM should not only be resolvable, So far so good. >but should have an accompanying URL publicly accessible, so inquiries >related to those domains can find a contact for the operators. Nope. R's, John, abuse@no.sp.am (try it) From nobody Wed Dec 15 11:07:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E733A0EB7 for ; Wed, 15 Dec 2021 11:07:37 -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=qvpy2sno; dkim=pass (2048-bit key) header.d=taugh.com header.b=R1koamOp 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 bIxhi-Y6ctzK for ; Wed, 15 Dec 2021 11:07:32 -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 E46F73A0EEF for ; Wed, 15 Dec 2021 11:07:31 -0800 (PST) Received: (qmail 15477 invoked from network); 15 Dec 2021 19:07:28 -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=3c73.61ba3cf0.k2112; bh=yoHwyjFXRLjZdpJw2T38Va0b3q1WQbV5q4m4JUIriZk=; b=qvpy2snoyQOcU/xYQaFjJNWt36JU4Zepc2c/zvt4VVjUFS64/21SULiOQjbhfwvc2V+CYiiIN1/eiFBd39t6ck9L5xZKhUJJEdoazDlEoMMQ6cvXPbsvrGy9SQ58HDV3Pt06A9y0xGdJBLrAC9/KoLtxUEuZ4UCRGF8qCRmQ9YJ41fOCidvJY8HmU07vzlXqaZr/tFkHG2A5mlERRl8TA4whASY16tNHrlo4GIr67u5vFVJ+BgG2LMeyUT5fwBrjCVwAqYvq4d+oupFzGMN2rTxpQz7M7LvXe4pGuVPtLgJdBfUvyX98gAbn54cVWe1AINLosGVThRh6k1YCnDZNIg== 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=3c73.61ba3cf0.k2112; bh=yoHwyjFXRLjZdpJw2T38Va0b3q1WQbV5q4m4JUIriZk=; b=R1koamOp/+DRmxrzfaWFIn+l5/FrAKY8DsViQvvCFskT6hIBevefCAo1dwUPWHxJUTniMo89nWVOkyJJ8EKpcTj6+XVVNv3MsBwstztrBTkD4Of/3AQWIgHRO5ARo/NeNqioJW29yolcvmZhq57uVFzxgroV3sipdjOMbp0tMLCdpnPxAzzQvVR1nhMFCh/HEYQeXl4smCgAcA2RolCm34r57xeNWQYaGkFdyOMonPqPklh/JzERA3qe8fAJqyLWOl1FDEyA8ryGbY4+09z5MQNbTZYo3pr2wuxuM/qCS5rP3aZyXUv+gYbhEGv66zgtGtWhgIAKttBw5vsaJhs+gA== 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; 15 Dec 2021 19:07:28 -0000 Received: by ary.qy (Postfix, from userid 501) id C363D32610B5; Wed, 15 Dec 2021 14:07:27 -0500 (EST) Date: 15 Dec 2021 14:07:27 -0500 Message-Id: <20211215190727.C363D32610B5@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 19:07:46 -0000 It appears that Dave Crocker said: >A domain name that is registered through the ICANN hierarchy of >registries is 'valid'. > >What your effort, here, does is to bring back 'resolvability', which I >assume is what you really mean by 'validity'. I have no idea what he means. If the domain publishes an SPF -all record, is that domain valid? The check for A/AAAA/MX is pretty common so if that's the intent, say so. R's, John PS: I think most ccTLDs would say IANA hierarchy, not ICANN. From nobody Wed Dec 15 11:17:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC13B3A0121 for ; Wed, 15 Dec 2021 11:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 JiyATKGbaKBu for ; Wed, 15 Dec 2021 11:16:59 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 090A03A0115 for ; Wed, 15 Dec 2021 11:16:54 -0800 (PST) Received: (qmail 2259193 invoked from network); 15 Dec 2021 19:16:54 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (902f57da-5ddb-11ec-b88f-d3a387348620); Wed, 15 Dec 2021 11:16:54 -0800 To: emailcore@ietf.org References: <20211215190523.DE8C03261081@ary.qy> Cc: John Levine From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Wed, 15 Dec 2021 11:16:53 -0800 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: <20211215190523.DE8C03261081@ary.qy> 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: 902f57da-5ddb-11ec-b88f-d3a387348620 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 19:17:05 -0000 On 2021-12-15 11:05 a.m., John Levine wrote: > It appears that Michael Peddemors said: >> An industry standard, and MAAWG recommendation, the domain portion in >> the PTR and in the email MAIL FROM should not only be resolvable, > > So far so good. > >> but should have an accompanying URL publicly accessible, so inquiries >> related to those domains can find a contact for the operators. > > Nope. > > R's, > John, abuse@no.sp.am (try it) > Hey, you can do anything you want, but be aware that reputation companies will treat it with much more suspicion if.. http://sp.am/ .. doesn't exist, but at least you have a clear 'whois' record. Problem is the general public doesn't read or know anything about 'whois', so who do they contact? -- "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 Wed Dec 15 12:08:00 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 EEC093A0C10 for ; Wed, 15 Dec 2021 12:07:56 -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 vbPBjMBtPVuS for ; Wed, 15 Dec 2021 12:07:52 -0800 (PST) Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) (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 ACDB43A0C09 for ; Wed, 15 Dec 2021 12:07:50 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D353F6C29A9; Wed, 15 Dec 2021 20:07: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 E61036C2388; Wed, 15 Dec 2021 20:07:47 +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.105.57.85 (trex/6.4.3); Wed, 15 Dec 2021 20:07:49 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cellar-Chief: 29a46e3c25bf8f2a_1639598868408_2817832836 X-MC-Loop-Signature: 1639598868408:2847720513 X-MC-Ingress-Time: 1639598868408 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 4JDmWP6NXFz2bmDw; Wed, 15 Dec 2021 20:07:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639598867; bh=S1LwiksKV3oYvKdB0vc9qSBao4mzLP+45KBfGc3RpgE=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=qJg0Rs4vtzgr77/Le0FA2zdaSXg6TOeUxoStu1yjeeCtCjrDHulUlQg6hsWf3wzc0 Hrp+frxLqbptb4KZ4f1u5z1BpoMyZmIzEL0K1YOjq9ndj4Ojk2ut49hmOmR4V0F8uw RZj6G0iAo2xBw3J4gVysLE3bHItonqzNxVsp7yXWLBaiQmD34FzE2XuNhQdJAVrw7z O6jda7KzOjVz4hfSuYs+lJc4oabJS3n4NWd11onviYQy5hvoOst5S6+eWESLUkXVFU xWgS7/bdJodopEl4+y1SaraTIHjqt9U2l1a44frTPpqB52jOmiMI2PQZG5S9JYk3J7 zGarXDmrzqomQ== Message-ID: <0c0429cf-fe00-4fec-0332-814a8d43429e@dcrocker.net> Date: Wed, 15 Dec 2021 12:07:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John Levine , emailcore@ietf.org References: <20211215190727.C363D32610B5@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211215190727.C363D32610B5@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 20:07:57 -0000 On 12/15/2021 11:07 AM, John Levine wrote: > It appears that Dave Crocker said: >> A domain name that is registered through the ICANN hierarchy of >> registries is 'valid'. >> >> What your effort, here, does is to bring back 'resolvability', which I >> assume is what you really mean by 'validity'. > I have no idea what he means. If the domain publishes an SPF -all record, > is that domain valid? And yet, your next sentence demonstrates that you did. > The check for A/AAAA/MX is pretty common so if that's the intent, say so. To the extent there is a desire to have text here make reference to all of the possible mechanics for demonstrating 'validity', perhaps. It might be safer, for the long term, to use text that describes the semantics of validity, rather than the mechanics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 15 12:29: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 2B7EF3A0E02 for ; Wed, 15 Dec 2021 12:29:37 -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 r2NykwXMnVBl for ; Wed, 15 Dec 2021 12:29:33 -0800 (PST) Received: from veps.esmtp.org (veps.esmtp.org [155.138.203.148]) (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 607B53A0E2A for ; Wed, 15 Dec 2021 12:29:31 -0800 (PST) Received: from veps.esmtp.org (localhost. [127.0.0.1]) by veps.esmtp.org (MeTA1-1.1.Alpha16.1) with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) id S0000000000014E3E00; Wed, 15 Dec 2021 20:29:29 +0000 Received: (from ca@localhost) by veps.esmtp.org (8.16.1/8.12.10.Beta0/Submit) id 1BFKTRIM076980 for emailcore@ietf.org; Wed, 15 Dec 2021 20:29:27 GMT Date: Wed, 15 Dec 2021 20:29:27 +0000 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20211215202927.GA66874@veps.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 20:29:39 -0000 On Wed, Dec 15, 2021, Michael Peddemors wrote: > An industry standard, and MAAWG recommendation, the domain portion in the PTR > and in the email MAIL FROM should not only be resolvable, but should have an > accompanying URL publicly accessible, so inquiries related to those domains "industry standard"? Those are the companies who don't care about RFCs and make up there own rules? Please let's follow the rules for RFCs -- which define the e-mail addresses for contacts -- without requiring some web stuff. -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. From nobody Wed Dec 15 13:12:52 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBD3A1071 for ; Wed, 15 Dec 2021 13:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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, 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=mVmELZJ4; dkim=pass (2048-bit key) header.d=wizmail.org header.b=O3Sn9led 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 Pci8Vzx0o76z for ; Wed, 15 Dec 2021 13:12:44 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9D43A1074 for ; Wed, 15 Dec 2021 13:12:43 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To: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=DBxmv9rZYF/Ob2MmGpopGMs1vye7Alu7/H5imgjPGoY=; b=mVmELZJ4PjvJ5oYzBkgPhveA9p MrgsAMgNAwG9ZjTHb21Ej0WetYhHHDLIe1Silv8IMgKRUT1thsyzSeru+YAw==; 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=DBxmv9rZYF/Ob2MmGpopGMs1vye7Alu7/H5imgjPGoY=; b=O3Sn9ledfb+cZeJ2WeRVt9RWzW W6HGmsQjaoDv4jaRjpBWL3dN1Hn7kkme4qJkgn4xTQgFfQZWhzbWCIa4KMSyMP5GzQOp0kGaOA2Dt DoEHml3LWam615XJnkrRjx1KBt7YkghrZBhwy6u+JDLzucKBcPRAjW6UyaSP3/1SECaAPbGNJZQ/z rCgkLUfUpO1OnmFEdd7pnCytP0RfCLE0hJ++y8orRUnkcSAvUadtaBIIQNf6A/0X732adEVJ3D371 NkRbyMnTs+t9E5xSy7DuM/RhiWYJWASdYwfvxMqW8gN4DxQ/sndmeL3KXZQV7MMZxoCerypQEgF1G wbEkKGEw==; 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.104) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1mxbZn-005rRL-1m for emailcore@ietf.org (return-path ); Wed, 15 Dec 2021 21:12:39 +0000 Message-ID: Date: Wed, 15 Dec 2021 21:12:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-GB To: emailcore@ietf.org References: <20211215190523.DE8C03261081@ary.qy> From: Jeremy Harris In-Reply-To: <20211215190523.DE8C03261081@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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 21:12:50 -0000 On 15/12/2021 19:05, John Levine wrote: > It appears that Michael Peddemors said: >> An industry standard, and MAAWG recommendation, the domain portion in >> the PTR and in the email MAIL FROM should not only be resolvable, > > So far so good. > >> but should have an accompanying URL publicly accessible, so inquiries >> related to those domains can find a contact for the operators. > > Nope. Agreed. SMTP should not depend on HTTP nor any of the lines of development starting there, including URLs. -- Cheers, Jeremy From nobody Wed Dec 15 14:45: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 E720F3A077D for ; Wed, 15 Dec 2021 14:45:36 -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=g2QWNwNh; dkim=pass (2048-bit key) header.d=taugh.com header.b=NgNmZHJn 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 p12sVtie1BJl for ; Wed, 15 Dec 2021 14:45:31 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570433A0773 for ; Wed, 15 Dec 2021 14:45:31 -0800 (PST) Received: (qmail 55805 invoked from network); 15 Dec 2021 22:45:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d9fb.61ba7009.k2112; bh=+C+/7SAmsNTgb+mdmYpuQ7eSkylVBWhXOArSBa9CPZw=; b=g2QWNwNhibXuwdDgbfZ7qe6LoVGlDOiihLSqn9P46ILX4tF/fSBxibTC7qbnRMb5gpnWQas3uecjzXa8hRUHeYpRQpmQr8Ta8kmC6k/gzH2GilGAW1z+NHpxiZLlg5h3stm4GYpUaKJKqFXVoLwi++9GBgLe55iyDQKHGCL7bZAyOajjRV3+CM3ISoN5f0E+J2z7C0eisJGyqdx/JXN0piPJx6VRKZ2L1wqXiZ0rwCFRfbsEM1h604zrtDlPeBVuj0Y8Etblj16IUcySnMwexqYM0Tt50kjx91LlkXx2j9br+Er+qVEhfYwm6yyXysgqFr8eYBOmCCLchmFoWKNq1Q== 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=d9fb.61ba7009.k2112; bh=+C+/7SAmsNTgb+mdmYpuQ7eSkylVBWhXOArSBa9CPZw=; b=NgNmZHJncajMg5TgIIF0ky7V0ZM8375khGegQ9AkojkbW8F8CIcq7DgiLdKi5qKNx01OVieHgGrcXfWxpw3CNkGUwT/pjFYEh46eCFVIWVwvN9wkjXAGA2HRtR3UlebPBOtA5jzQIHPzzU2umFt57/jM15OF003tWyxKq3rV2hTfq5liRvcXvpBB4oIfALAFt74OFzkqboCaV0L9PfJJCUKbJqlcuRbtnsfjE1sn0NaTYZPbO6P9UxM2ASAWDo13S0ssTn8WHTABewKSDQLY9PsCeV9DeojrLPp/2qwYK5zC7zkmFW+9qPdxgyM2ORfJE1IlD+Gq8EAVZafM7E++nA== 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; 15 Dec 2021 22:45:28 -0000 Received: by ary.qy (Postfix, from userid 501) id AFB933263A09; Wed, 15 Dec 2021 17:45:27 -0500 (EST) Date: 15 Dec 2021 17:45:27 -0500 Message-Id: <20211215224527.AFB933263A09@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <0c0429cf-fe00-4fec-0332-814a8d43429e@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 22:45:37 -0000 It appears that Dave Crocker said: >And yet, your next sentence demonstrates that you did. > >> The check for A/AAAA/MX is pretty common so if that's the intent, say so. Uh, no, that sentence means what it says. >To the extent there is a desire to have text here make reference to all >of the possible mechanics for demonstrating 'validity', perhaps. It >might be safer, for the long term, to use text that describes the >semantics of validity, rather than the mechanics. Well, OK. Send text, keeping in mind that a fair amount of SMTP happens behind firewalls, split horizon DNS, and all of the other duct tape that glues parts of the Internet together. R's, John From nobody Wed Dec 15 14:54:15 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5058B3A0834 for ; Wed, 15 Dec 2021 14:54: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=episteme.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 dSHOKrh1Q8Id for ; Wed, 15 Dec 2021 14:54:07 -0800 (PST) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14EA3A081C for ; Wed, 15 Dec 2021 14:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1639608845; bh=I1LbXHO62O8h+ovX0V7Lu/9570pbD8HIoiuo2Y8CmE8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=fe759Mrw6GofnDKw/1Xg6tMj/gOroGrXPI0rtPu+fioY5zFGbQExlsdR/8PQjyhE6 5Fs0ifaq2D/Gd02AEO3MhaoAneoQ9kJxkDhmDZp9Dbo1gx07pznK8iokYs4+tAYsWH Au/RQrOb+RdD8MH+CCE+qLR6a6Bb0f4Tgud3j2pE= From: Pete Resnick To: John Levine Cc: emailcore@ietf.org, dcrocker@bbiw.net Date: Wed, 15 Dec 2021 16:54:04 -0600 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: <20211215190352.850D3326104C@ary.qy> References: <20211215190352.850D3326104C@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 15 Dec 2021 22:54:13 -0000 On 15 Dec 2021, at 13:03, John Levine wrote: > It appears that Dave Crocker said: >> When a receiving system changes that address, it is known to >> represent >> the 'intent' of the receiving system, not of the author. ... > >> Note that simply saying something like "until the message has reached >> the address specified in RCPT-TO" is far simpler, far easier to >> understand, technically reasonable and functionally sufficient. > > Every mail system I've ever used treats upper and lower case > equivalently. > So if you send a message to JOHNL@IECC.COM, it goes into the mailbox > for > johnl@iecc.com. How many deliveries is that? > > Many mail systems allow subadddresses, so mail for bob+ext or bob-ext > usually > goes into the mailbox for bob. How many deliveries is that? > > Some systems, notably Gmail, ignore dots in the mailbox so mail to > joeblow123, > joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same mailbox. > How many > deliveries is each of those? I think the reference to the 251 response you made in reply to John is also an interesting example: If you take a look at RFC 821, section 3.2 on forwarding, it seems that the intention was that returning 251 and rewriting the RCPT-TO was clearly part of the SMTP architecture and not itself an act of delivery. If the entity that is returning SMTP responses can in protocol tell the other end of the SMTP transaction that it is changing the RCPT-TO and what it is being changed to, that sounds like its part of the SMTP architecture. I agree with Dave that it is certainly a simpler architecture to have the message reaching the RCPT-TO be the point of delivery (I might even go further and say that the message reaching a server that peeks at the left-hand-side and acts on it is the point of delivery), and it might even be the best architecture. However, I'm not convinced that's the architecture we've been using since 821. There seems to be a distinction at an architectural level between "really truly delivered and resent" and "simply redirected within the SMTP process". I know user-level "Resend a message that has been delivered to my Inbox" is clearly the former, though even putting it that way probably begs the question. I'm pretty sure that mailing lists that muck with the DATA portion of the message beyond trace fields are also the former. I'm pretty sure that actions worthy of a 251 response (what might be implemented as a system-level alias file) are the latter. I'm not at all sure what to call user-level redirects to other addresses (e.g., .forward files). But this does seem to be an issue of a not-perfectly-clean architecture, not just implementation choices. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Wed Dec 15 14:56:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35493A0886 for ; Wed, 15 Dec 2021 14:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo6DJJuzuMs2 for ; Wed, 15 Dec 2021 14:56:50 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 EF1C43A0878 for ; Wed, 15 Dec 2021 14:56:49 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id m6so34209830lfu.1 for ; Wed, 15 Dec 2021 14:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EOtrWbKI84VxEDcWPN6b6IqtAVm66ntAJTetVQ/YdoE=; b=YreonLcj6QQuQdn7L1rXo4y0lKtouZndPCLAkrGU8jUqODy/Xv6q8wkEW324QAPd0V g5rwrfJLChFXVLR55ADXbj2V5MjmkSCSq1JNd6dEFFXh69TM0fT5kqqVU2U8d2mg9xiI E3NEbFSq0bYx/jJI6l+14nxgHW4u/7I1BI1tlG7nrAQ4Cd9yHpwsyuguLJNpasW+HGhP WXzhbbMewpTyvIS/9NbWBbs4tpBIUTBuYZcltmmDvDdCTh5b54PTdQ01PdZJj4g/LNYc J2q7bD56R+YtbBKj5hsddDylG7pXSZIeybrw3s6HOaseqDkAV+8kSdzr5AC3yGWBIqAx suNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EOtrWbKI84VxEDcWPN6b6IqtAVm66ntAJTetVQ/YdoE=; b=MJKDFffjh4CU8qGPvE168W5gh3gn2HfiicumMk+HC+JRWpAvd2XL/fQm3BA6HrZtcQ gltus7TXZwwVtUClvLMVFayPxp/6uzW+W4ZWPR/5WF8pG/+C2mbAtSeDWXQhpZGhpaTO lqKipF+8XfblW8JVHoZz1NSZvFna+PZFzTueddc8Cwbl1uIi8BoKYCDyfFBS2pMag+Xm m5h6TPLNcfccN8k58tUTIKx1V638nMSA5XFppVxBFj/Cv4ZISpoyQPE4PSJ3dExMWplC dsZGyKuLsldeFxB3qz7E5uPSKiqmuTSDSCVOntQwPmOx9ERGm+GlJ85rwRhPNK2z3IWc Y5RQ== X-Gm-Message-State: AOAM531OuPqciSulL8WKiL34gn4VvL0z5OXkS8xxF01T2H/kbbezj8Ly 3PMuSUtQ9ZuR7quvev9EgM/t0UWm04gdFXNQF3laViWA X-Google-Smtp-Source: ABdhPJyfOuZ3c8K6wcIPTo4LqVwElUphM4FekVBpxLdovx56gBO/9nwN7gcp7jjFBcjTLRJjTuU/glAw2jzCprKV/yI= X-Received: by 2002:ac2:5d67:: with SMTP id h7mr11850753lft.493.1639609007441; Wed, 15 Dec 2021 14:56:47 -0800 (PST) MIME-Version: 1.0 References: <0c0429cf-fe00-4fec-0332-814a8d43429e@dcrocker.net> <20211215224527.AFB933263A09@ary.qy> In-Reply-To: <20211215224527.AFB933263A09@ary.qy> From: Tim Wicinski Date: Wed, 15 Dec 2021 17:56:36 -0500 Message-ID: To: John Levine Cc: emailcore@ietf.org, Dave Crocker Content-Type: multipart/alternative; boundary="000000000000758dfc05d337381d" Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 22:56:55 -0000 --000000000000758dfc05d337381d Content-Type: text/plain; charset="UTF-8" On Wed, Dec 15, 2021 at 5:45 PM John Levine wrote: > It appears that Dave Crocker said: > >And yet, your next sentence demonstrates that you did. > > > >> The check for A/AAAA/MX is pretty common so if that's the intent, say > so. > > Uh, no, that sentence means what it says. > > >To the extent there is a desire to have text here make reference to all > >of the possible mechanics for demonstrating 'validity', perhaps. It > >might be safer, for the long term, to use text that describes the > >semantics of validity, rather than the mechanics. > > Well, OK. Send text, keeping in mind that a fair amount of SMTP happens > behind firewalls, split horizon DNS, and all of the other duct tape that > glues parts of the Internet together. > > So this helps me, John. I see a lot of things during my day jobs, and receive a lot of email from broken servers with invalid names on some internal network that nobody should be forced to see. It's email that should never escape into the Internet, but there is an expectation of internal delivery. I'm not advocating a position, only thinking the requirement should be more semantic. tim --000000000000758dfc05d337381d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 15, 2021 at 5:45 PM John Levine &= lt;johnl@taugh.com= > wrote:
It a= ppears that Dave Crocker=C2=A0 <dcrocker@bbiw.net> said:
>And yet, your next sentence demonstrates that you did.
>
>> The check for A/AAAA/MX is pretty common so if that's the inte= nt, say so.

Uh, no, that sentence means what it says.

>To the extent there is a desire to have text here make reference to all=
>of the possible mechanics for demonstrating 'validity', perhaps= .=C2=A0 It
>might be safer, for the long term, to use text that describes the
>semantics of validity, rather than the mechanics.

Well, OK.=C2=A0 Send text, keeping in mind that a fair amount of SMTP happe= ns
behind firewalls, split horizon DNS, and all of the other duct tape that glues parts of the Internet together.


So this helps me= , John.=C2=A0 I see a lot of things during my day jobs, and receive
a lot of email f= rom broken servers with invalid names on some internal network that
nobody should be= forced to see.=C2=A0 It's email that should never escape into the Inte= rnet,
but= there is an expectation of internal delivery.=C2=A0 =C2=A0=C2=A0

I'm not advocating= a position, only thinking the requirement should be more semantic.

tim
=C2=A0
--000000000000758dfc05d337381d-- From nobody Wed Dec 15 15:38:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D383A07F5 for ; Wed, 15 Dec 2021 15:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WgaasNW7xVhO for ; Wed, 15 Dec 2021 15:38:08 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 D28213A080B for ; Wed, 15 Dec 2021 15:38:07 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 057CA16057; Thu, 16 Dec 2021 00:38:03 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id A039525E7; Thu, 16 Dec 2021 00:38:01 +0100 (CET) Date: Thu, 16 Dec 2021 00:38:01 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Jeremy Harris Cc: emailcore@ietf.org Message-ID: <20211215233801.xLwPM%steffen@sdaoden.eu> In-Reply-To: References: <20211215190523.DE8C03261081@ary.qy> Mail-Followup-To: Jeremy Harris , emailcore@ietf.org User-Agent: s-nail v14.9.23-185-gd075240d0d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 15 Dec 2021 23:38:13 -0000 Jeremy Harris wrote in : |On 15/12/2021 19:05, John Levine wrote: |> It appears that Michael Peddemors said: |>> An industry standard, and MAAWG recommendation, the domain portion in |>> the PTR and in the email MAIL FROM should not only be resolvable, |> |> So far so good. |> |>> but should have an accompanying URL publicly accessible, so inquiries |>> related to those domains can find a contact for the operators. |> |> Nope. | |Agreed. SMTP should not depend on HTTP nor any of the lines |of development starting there, including URLs. You know i struggle with OAuth authentification that not only uses JSON for key/value pairs etc., but may also upgrade to HTTP/2 or even QUIC, and not even the cURL library (just let me say: !, please) implements these themselve but uses external libraries which themselve (!) use external libraries for the QUIC case. All that nothing but a pity. That is to say, how adorable this protocol was designed to still scale after decades, the ugliness produced by other participants of IETF soils it whatever you do. (I have my spoiler week.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Dec 15 16:41: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 4463B3A0E91; Wed, 15 Dec 2021 16:41: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 mGHJZ4FhxBJH; Wed, 15 Dec 2021 16:41: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 78F1A3A0E3A; Wed, 15 Dec 2021 16:41:13 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxepa-000CN4-37; Wed, 15 Dec 2021 19:41:10 -0500 Date: Wed, 15 Dec 2021 19:41:04 -0500 From: John C Klensin To: Pete Resnick , John Levine cc: emailcore@ietf.org, dcrocker@bbiw.net Message-ID: In-Reply-To: References: <20211215190352.850D3326104C@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 16 Dec 2021 00:41:18 -0000 --On Wednesday, December 15, 2021 16:54 -0600 Pete Resnick wrote: > On 15 Dec 2021, at 13:03, John Levine wrote: > >> It appears that Dave Crocker said: >>> When a receiving system changes that address, it is known to >>> represent >>> the 'intent' of the receiving system, not of the author. ... >> >>> Note that simply saying something like "until the message >>> has reached the address specified in RCPT-TO" is far >>> simpler, far easier to understand, technically reasonable >>> and functionally sufficient. >> >> Every mail system I've ever used treats upper and lower case >> equivalently. >> So if you send a message to JOHNL@IECC.COM, it goes into the >> mailbox for >> johnl@iecc.com. How many deliveries is that? >> >> Many mail systems allow subadddresses, so mail for bob+ext or >> bob-ext usually >> goes into the mailbox for bob. How many deliveries is that? >> >> Some systems, notably Gmail, ignore dots in the mailbox so >> mail to joeblow123, >> joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same >> mailbox. How many >> deliveries is each of those? > > I think the reference to the 251 response you made in reply to > John is also an interesting example: If you take a look at RFC > 821, section 3.2 on forwarding, it seems that the intention > was that returning 251 and rewriting the RCPT-TO was clearly > part of the SMTP architecture and not itself an act of > delivery. If the entity that is returning SMTP responses can > in protocol tell the other end of the SMTP transaction that it > is changing the RCPT-TO and what it is being changed to, that > sounds like its part of the SMTP architecture. > > I agree with Dave that it is certainly a simpler architecture > to have the message reaching the RCPT-TO be the point of > delivery (I might even go further and say that the message > reaching a server that peeks at the left-hand-side and acts on > it is the point of delivery), and it might even be the best > architecture. However, I'm not convinced that's the > architecture we've been using since 821. There seems to be a > distinction at an architectural level between "really truly > delivered and resent" and "simply redirected within the SMTP > process". I know user-level "Resend a message that has been > delivered to my Inbox" is clearly the former, though even > putting it that way probably begs the question. I'm pretty > sure that mailing lists that muck with the DATA portion of the > message beyond trace fields are also the former. I'm pretty > sure that actions worthy of a 251 response (what might be > implemented as a system-level alias file) are the latter. I'm > not at all sure what to call user-level redirects to other > addresses (e.g., .forward files). But this does seem to be an > issue of a not-perfectly-clean architecture, not just > implementation choices. Without, at the moment, taking more of a position on this than I already have, let me make a procedural observation that builds on Pete's comment. There is an SMTP architecture and fundamental protocol design that goes back to 821. There have only been two significant changes made to it since 1992: the introduction of MX-based mail routing with RFC 975 and the extension model (including the replacement of HELO by EHLO) with RFC 1425. No amount of wishing it were different, second-guessing decisions made nearly 40 years ago, or publication of descriptions that do not explicitly change SMTP (e.g., by standards track updating of 2821 or 5321) changes that. If there are features that never worked or interoperated as intended, we can remove them. If others have not stood the test of time, we can denounce them and/or recommend against their use -- that is what applicability statements are about, whether in a separate document or inline in 5321bis. However -- and I believe RFC 6410 and 2026 are clear about this -- if we are going to start adding or changing features or redefining the model, it is back to Proposed Standard and I thought we had general agreement we were not going to make (or even consider) changes that would require that. If I'm wrong about that, I hope we can address that topic rather than picking at issues that would push that boundary. best, john From nobody Wed Dec 15 22:57:46 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CF3A0B3E for ; Wed, 15 Dec 2021 22:57:45 -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 ro5vaAS8639i for ; Wed, 15 Dec 2021 22:57:40 -0800 (PST) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 664093A0B2E for ; Wed, 15 Dec 2021 22:57:39 -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 96BF49214E1 for ; Thu, 16 Dec 2021 06:57:38 +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 958B89213F8 for ; Thu, 16 Dec 2021 06:57:37 +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.97.65.154 (trex/6.4.3); Thu, 16 Dec 2021 06:57:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Tangy-Thoughtful: 4b4dda4b3b643d0c_1639637858399_1610300564 X-MC-Loop-Signature: 1639637858399:3951580854 X-MC-Ingress-Time: 1639637858399 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 4JF2xD5G9Nz7bQV0 for ; Thu, 16 Dec 2021 06:57:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639637856; bh=AfOQcP75IMGzxyNQ4bWTIlTdC+AHj+5kiYavnmIwfn0=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=Jz9MmXqsO/j1YERGdeJBYy+bioa/K9KoWfnUQsytGxR8zwINo7DmofaPXA7IdDO5N c6E4KxrBQgyYqDr4MDyqti3mPLdHuidQWcHVVlxvNU9W1J+6Jo3f9qamMcqrcVTf27 VkfFJOluou1h+7q5/uXaMDz/K9E9eCQGqwI19XBtymjsECqwy3Rgp5I7oJJL+ws6zr dYk/1qvUpWDppqJKIKJDBzN1hEpUjMKRQ+Zw2GKqJIwqtiavZ1jprsCcSXbp0U7sJ+ dZyJnR+K2UQ9vIuYm8lD/wyuixkHyDeG2ClqM7UGdbDr31Jri/mgdFodAX5+tCVtEW pi+5k3ozMMWMg== Message-ID: <810789c5-79e5-147d-057e-c7045d438e50@dcrocker.net> Date: Wed, 15 Dec 2021 22:57:34 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211215224527.AFB933263A09@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211215224527.AFB933263A09@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 06:57:45 -0000 On 12/15/2021 2:45 PM, John Levine wrote: >> To the extent there is a desire to have text here make reference to all >> of the possible mechanics for demonstrating 'validity', perhaps. It >> might be safer, for the long term, to use text that describes the >> semantics of validity, rather than the mechanics. > Well, OK. Send text, keeping in mind that a fair amount of SMTP happens > behind firewalls, split horizon DNS, and all of the other duct tape that > glues parts of the Internet together. Thanks for the work assignment, but there are least 3 problems with it: 1. I really don't know what semantics you guys think is appropriate. So the task is on you guys. 2. I thought the agreement during the Interim was to dump validity (or whatever it should be called) testing, and while it's fine for the mailing list discussion to reverse meeting 'decisions', I have missed the list discussion that makes the compelling case for the test, in the protocol specification. 3. I've grown increasingly clear that there is a difference between a protocol specification and a service, or operations, specification, and that it is important for documents to be careful about making this distinction.(*) Also a validity/whatever test is not needed for basic email transfer functionality; so it's an service/operations requirement not a protocol requirement. It makes pretty obvious sense to have some sort of testing across the open Internet, as part of the public email service. It is less clear that it is needed in other operational environments. d/ (*) DANE did quite a good demonstration of this, by requiring use of DNSSec. It is an operational requirement, rather than a protocol requirement, and the one sentence in the DANE spec that requires it imposed a massive barrier to adoption of DANE. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 04:11: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 4AF9C3A0E21 for ; Thu, 16 Dec 2021 04:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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_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=MBdIqsI0; dkim=pass (1152-bit key) header.d=tana.it header.b=BwNOLmTI 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 TjT4Aw_aonUc for ; Thu, 16 Dec 2021 04:11:15 -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 373B03A0E20 for ; Thu, 16 Dec 2021 04:11:13 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1639656667; bh=DLqRMaCjqTrev3H6g1o++sE0Y9ZXLHb+8KfGPiCKQ90=; h=Subject:To:References:From:Date:In-Reply-To; b=MBdIqsI0H+EDV1gWNyqg2PZi1tuLYZFexEmpPCfQcY4WA4lHBUbpq996rfSmbjntq XazjpMqpEbswD4cS8abDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1639656667; bh=DLqRMaCjqTrev3H6g1o++sE0Y9ZXLHb+8KfGPiCKQ90=; h=To:References:From:Date:In-Reply-To; b=BwNOLmTI3+dkMqdJayz/nU+dnmczbihSEXk3TNl4fKJ+bAaQ493p4eVx4PyO+ZGTW CKl39DzvL1pGx9MKhqESr0K+fWRFw7TyAgof5R3vXgHDmb9qqXV73TL8gFvYrllQEt +QjlMNXkWnRhSjDZphQWvwS/xy/7UG5BMTulrA/yJRFFCHFSUCpPdiXvI47ny 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 00000000005DC076.0000000061BB2CDB.00004111; Thu, 16 Dec 2021 13:11:07 +0100 To: dcrocker@bbiw.net, emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Thu, 16 Dec 2021 13:11:06 +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: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 12:11:23 -0000 On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: (reordered for readability) > On 7/13/2021 4:27 AM, Alessandro Vesely wrote: >> On Fri 09/Jul/2021 21:24:47 +0200 Todd Herr wrote: >>> >>> I propose the following as a strawman... >>> >>> Change the above paragraph to read as follows: >>> >>>     An SMTP server MAY verify that the domain name argument in the EHLO >>>     command has an address record matching the IP address of the client. >> >> I'd make that even more abstract, for example: >> >>      An SMTP server MAY verify the validity of the domain name argument in >>      the EHLO command. >> >> Domain name to IP, IP to PTR name, SPF, and more are different verification >> criteria, sometimes overlapping and sometimes not. > > A domain name that is registered through the ICANN hierarchy of registries is > 'valid'. Isn't that overly restrictive? > What your effort, here, does is to bring back 'resolvability', which I assume > is what you really mean by 'validity'. My intention was the opposite. By replacing 'resolvability' (and matching IP) with an abstract 'validity' the semantic remains open. Which validity criteria to use is entirely in the ambit of the receiving SMTP server. The point is that such validity judgment can be made using the given domain name argument. The A/S can give multiple examples of validations in the public Internet. Best Ale -- From nobody Thu Dec 16 07:21:05 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 9D8033A1009 for ; Thu, 16 Dec 2021 07:21:03 -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 NaSS4Alkl10g for ; Thu, 16 Dec 2021 07:20:58 -0800 (PST) Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C023A100B for ; Thu, 16 Dec 2021 07:20:57 -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 129CD1205F8; Thu, 16 Dec 2021 15:20:56 +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 6AACA120590; Thu, 16 Dec 2021 15:20:55 +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.118.248.87 (trex/6.4.3); Thu, 16 Dec 2021 15:20:55 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Whispering-Coil: 6f398cb178136636_1639668055847_2875497322 X-MC-Loop-Signature: 1639668055847:735210564 X-MC-Ingress-Time: 1639668055846 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 4JFG5x3qzKz7bQV3; Thu, 16 Dec 2021 15:20:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639668054; bh=dmW3eW++GLpXWBF8bcnVw9wBmwB1cnPo4Y3lbp7qlaI=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=hYjyGbTVJ9OMH5I4PwWWV/MrlhE1IKx3nIOohHOHUEqHBnr7qDWSIJkpQ6swi0lab xTqpbcPShPFTXOnzAB7Fn+EnBB9T7/82ZtKcplfnQxZlERQ4ZR+QadjHYR96SdXdAU DU5nbAih1ly4EbPWOFbzBSggl14582CoBYcx04arcnYKgwF82yLZoUnIiGw/ieS21/ QSMwnf8Ohcd7jZp/ciTg22njD0HaTLqjisjA/kjacWkTqbuViMe3QH0rLR7/zTqX8W +QOk74FhVwGSqo2eDWtkogqxg4PALKPjdRZaXhPZDx5gg4ezmxwETe/fVMDsXaeiDt zZS9ET/xHUQ4w== Message-ID: Date: Thu, 16 Dec 2021 07:20:52 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Alessandro Vesely , emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 15:21:04 -0000 On 12/16/2021 4:11 AM, Alessandro Vesely wrote: > On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: (reordered for > readability) >> >> A domain name that is registered through the ICANN hierarchy of >> registries is 'valid'. > > > Isn't that overly restrictive? To answer that requires first seeing what alternative you have in mind. >> What your effort, here, does is to bring back 'resolvability', which I >> assume is what you really mean by 'validity'. > > > My intention was the opposite.  By replacing 'resolvability' (and > matching IP) with an abstract 'validity' the semantic remains open. A specification that has an 'open' semantic is not specifying anything a normative protocol detail that is meaningful. (literally) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 08:55:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CEA3A1209 for ; Thu, 16 Dec 2021 08:55:41 -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=rFidjxe4; dkim=pass (2048-bit key) header.d=taugh.com header.b=i9GyXRgM 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 hCMJOFgSrqxS for ; Thu, 16 Dec 2021 08:55:36 -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 6AA2B3A1208 for ; Thu, 16 Dec 2021 08:55:36 -0800 (PST) Received: (qmail 99857 invoked from network); 16 Dec 2021 16:55:34 -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=1860f.61bb6f86.k2112; bh=a65VM9e5GwB8YUM76Pqh/sv36jhlEtMqGmVwAypSumc=; b=rFidjxe4Pd1sfqhlcXbXENSZa+ftjTFhRJjE1jktoCWtSQP4uj23YZek6xjdKlWQvfJoDHZ/caSQvfAIT9/MxYf5Uny74f7JVUSisxtPjO2UvWiR99zeH6hdZ3Cdq1zzjQXj2WE9264UQuPk4vEAakLp4mA0O8BIo5fJ2qosU10k0IlS5C6hWCA0/dXrpbpcNlFaMym98wJ3QzNjIDGAJU7V+AK4Ugb/i0ALb0WnjVwMFuLX1Bdb+P8iR0jHYE5THvxGe5wkSs2lwfOriyWswJZUeMAEX/bhZNZsKB/TFgtBx+XEPOLafdOMlwdhUbymzD+M/teu9aIii25bDTaveg== 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=1860f.61bb6f86.k2112; bh=a65VM9e5GwB8YUM76Pqh/sv36jhlEtMqGmVwAypSumc=; b=i9GyXRgMAZp794Em0rTnGO9xkbEeVPNCgIE1rS4apn/onr06OFHLvbyLE+eUzfM8oH48ZZenwwOlhXIzFUPmTrx2kpT6v1yTd928QHb+OGuTrZD0RfR015IEuoNfJRXQu+/fONqZwU6VtU+wOYQoxdqUnegCw4dZCBUOUdEHX1PG1y6V2BhyuEmnWaBY/e6wq68b5mPn4s2nCtMOj9mGgSbvU7zKQ3dopv8/ZxYKJQZ/eZs07y/BXxSaXdGB6OWRlIldzXRlrENzaKFqbCPQ8crHDVpRss/E+nOftssRs3TPlJnGG+cHEPuoIPOo7Fahcw2hxrmn4yWoba4x9XFF2A== 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; 16 Dec 2021 16:55:33 -0000 Received: by ary.qy (Postfix, from userid 501) id 2CAD332713F2; Thu, 16 Dec 2021 11:55:32 -0500 (EST) Date: 16 Dec 2021 11:55:32 -0500 Message-Id: <20211216165533.2CAD332713F2@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <810789c5-79e5-147d-057e-c7045d438e50@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 16:55:42 -0000 It appears that Dave Crocker said: >2. I thought the agreement during the Interim was to dump validity (or >whatever it should be called) testing, and while it's fine for the >mailing list discussion to reverse meeting 'decisions', I have missed >the list discussion that makes the compelling case for the test, in the >protocol specification. We seem to have been talking past each other. I'm with you, validity testing of the EHLO doesn't work well enough to standardize. I'd go as far as saying that the EHLO argument SHOULD be a domain name that has an A or AAAA that points to the host issuing the command if such a domain name exists, but specifically not say to do if it's not. R's, John From nobody Thu Dec 16 09:40: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 CA7093A0834 for ; Thu, 16 Dec 2021 09:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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_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=udcYSGol; dkim=pass (1152-bit key) header.d=tana.it header.b=CNCz1r07 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 4CxNDU9QTQIr for ; Thu, 16 Dec 2021 09:40:13 -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 A8BBF3A0831 for ; Thu, 16 Dec 2021 09:40:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1639676406; bh=g9mk7le26mwcw33YDfHiZk+/mQYb88UmW784JclBf9M=; h=Subject:To:References:From:Date:In-Reply-To; b=udcYSGoltHmHAAEv4H1dGGrr4B8TIROtc6iOQIGUS+WYoUlYjuXyFpk8vsrdSXpUb 1auqdhkMr4Y79QSj3qeBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1639676406; bh=g9mk7le26mwcw33YDfHiZk+/mQYb88UmW784JclBf9M=; h=To:References:From:Date:In-Reply-To; b=CNCz1r07Y3YPo1iBcBn0MDUvm/kCnSQOY1mv2+8Cmr59dyqaos6vKR3B7kVa6f9PI NTSPfTm4nYpMHfBiDY20540xgP3Koj0qAeOWVu8uyOGNNNIPKfhL6FetZaxvQTxbWV AVA7SwrGK5lnxyBrUrHLd5SmwlHCQuSzygBC9uORTG3iBQJtFJdJEMwh6NwAY 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 00000000005DC083.0000000061BB79F6.00001E10; Thu, 16 Dec 2021 18:40:06 +0100 To: dcrocker@bbiw.net, emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> From: Alessandro Vesely Message-ID: <51640ce4-974e-c461-ca2b-d6fabff813a6@tana.it> Date: Thu, 16 Dec 2021 18:40:05 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 17:40:21 -0000 On Thu 16/Dec/2021 16:20:52 +0100 Dave Crocker wrote: > On 12/16/2021 4:11 AM, Alessandro Vesely wrote: >> On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: >>> >>> A domain name that is registered through the ICANN hierarchy of registries >>> is 'valid'. >> >> Isn't that overly restrictive? > > To answer that requires first seeing what alternative you have in mind. SMTP, as a protocol, can be used between internal hosts; where "internal" stands for non-registered and/or not publicly accessible. They must still be considered valid by the server they connect to. >>> What your effort, here, does is to bring back 'resolvability', which I >>> assume is what you really mean by 'validity'. >> >> >> My intention was the opposite.  By replacing 'resolvability' (and matching >> IP) with an abstract 'validity' the semantic remains open. > > A specification that has an 'open' semantic is not specifying anything a > normative protocol detail that is meaningful.  (literally) Uh... I beg your pardon, perhaps I should have said an open mechanism. The semantic meaning is that the EHLO argument had better be good because the server will check it. Missing details can be specified afterwards, without modifying the core protocol. These are mechanisms, such as like looking up PTR or TXT records, each of which, in turn, has its own semantic. Hence the confusion. An immediate consequence of such specification, whether open or limited to the correspondence with the IP address of the client, is to say what action should a server take if the argument is invalid. Best Ale -- From nobody Thu Dec 16 11:19:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C153A0FD5 for ; Thu, 16 Dec 2021 11:19:03 -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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bbiw.net header.b=fgy9QtWV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O66DnKgs 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 1XM0c5GPpndE for ; Thu, 16 Dec 2021 11:18:58 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE103A0FF8 for ; Thu, 16 Dec 2021 11:18:58 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 389C4320167D for ; Thu, 16 Dec 2021 14:18:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Dec 2021 14:18:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= message-id:date:mime-version:from:to:subject:content-type :content-transfer-encoding; s=fm3; bh=yABO0FmCYr7DbDkOBoxKIGp25F P06g8/UuuvtJb65MM=; b=fgy9QtWVoBBA4gvj+bE0teHTzjZVvG5sTNysm0AUu8 5N3CpnlZ7gWrYLsK/30yWYLopBxKAv8NNFAIi1z4OGC8OnOuvIB1BDMDLzmAzs6Q 0S7prqC1NM3oLTt3GpRi/zi4zDV2JcTY/5EZk3SA7zR0QxUsWlE+I6rlZr+Eebhm 9cMfVZwIKCkUzc9gwXiMGQpJ3Oc2++MAw4qarACEJE4IlnttgERACZYafUhrgBif XunynLUzHidrp7yGYM3wsXnCASO4R/LQsAs9FA9uRzJRa8Z++2xQMmvSjmUDf1ql MGr226tzJR9qIgi9aGRFIohgfl9TL03fgeZJmW4Wl3bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yABO0F mCYr7DbDkOBoxKIGp25FP06g8/UuuvtJb65MM=; b=O66DnKgszwDCMzHCpUMk/s o1TnV8WucPqD+xY+24nI6HKEaIPihUqT3WXpwTwqLJLsZOI/LJrvtQGGn1DZy1nN hc3eOSxoJWWQ/WJ5jYaPrgIb4T+n48Ps2CGyrvh12/LGJFjZzj3p8oVa5dRPx6Up yZX8ujKnHZIivuaBmeVTf+uwczRbV8pfd/+pxgHSj7jUAePSBn3TWW3BlA5f+BUa H9X9IQCe7h7ECtHFdaGA8N9pcWyfYf6kIKDUp1YtcOA2Ut1P50cC0wRfqOtO1tX+ K/f2seyXrhMkLDkcYlzaUpj4z8DRPz1i8TUKrv9bU1TL4UQWtDkOlcFc0pKqw9mQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleeggdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfhffvufhotgfgsehtkeertddtfeejnecuhfhrohhmpeffrghvvgcu vehrohgtkhgvrhcuoegutghrohgtkhgvrhessggsihifrdhnvghtqeenucggtffrrghtth gvrhhnpeefudduvdejfeejueeiueffvdfgieeiffdvgfeuueefleekleejteetffegkeek veenucffohhmrghinhepsggsihifrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepuggtrhhotghkvghrsegssghifidrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 16 Dec 2021 14:18:55 -0500 (EST) Message-ID: Date: Thu, 16 Dec 2021 11:18:53 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US From: Dave Crocker To: EmailCore WG Organization: Brandenburg InternetWorking Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] Postal mail 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, 16 Dec 2021 19:19:04 -0000 When postal mail iis 'delivered', it is dropped at the destination.  What is done to it after that is /after/ delivery. Someone at the destination might look at the envelope and decide to give it to a different house member.  They might decide to forward it, unopened, to someone else.  But again, from the perspective of the postal handling service, this is after delivery. Registered mail even documents this point. If someone is going to claim that the Post Office did not actually deliver the mail and, for example, it is not 'delivered' until it is placed into the recipient's mailbox -- as opposed to the household mailbox -- they need to explain this carefully. It will then be quite helpful for them to explain why and how Internet Mail justifies a different model. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 11:20: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 CD5D83A100B for ; Thu, 16 Dec 2021 11:20:15 -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 DgBeo_UEwiHt for ; Thu, 16 Dec 2021 11:20:10 -0800 (PST) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD753A1009 for ; Thu, 16 Dec 2021 11:20:09 -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 74098120482 for ; Thu, 16 Dec 2021 19:20:08 +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 0A6951207AB for ; Thu, 16 Dec 2021 19:20:04 +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.106.199.151 (trex/6.4.3); Thu, 16 Dec 2021 19:20:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cooing-Keen: 0ec0b9d21e49ae40_1639682408229_3766121455 X-MC-Loop-Signature: 1639682408229:2749729642 X-MC-Ingress-Time: 1639682408229 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 4JFMPw0v1lz2YsQy for ; Thu, 16 Dec 2021 19:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639682404; bh=sDkKJ/9WYu6uq43OxNawZig9DYSeQ5zI38EYw3gs5Wg=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=dyZApVzc9br+47htdtapmDDqTLYwKoYXT+2k7uEgnqh94+HOo5URcFUWcsdW7+LNK f2f/SKrpjkzjSSJmKKwZPE7IlM6JmdtqLsgi67RgHkmZa5Vc9w4jCFiK8M7TavG+WY zS9ix4LSn9F6MAibLmaRpCIiotllCx+52dT1GZSo6TwdbjTMn8WgXBMk+WWYIE1Ugv o7zHxReV7Fgx7V4N1ui92FveQaPvHBmjZgPCAcQa6mgOod4TjMHqsbo1e9++2Y0ogg v0Ita1dj0Ld9PYssJRm8jSTNHYtUreYo2Gru2m5PeTkf3B0/R20ftgVW+eVkb9iMlb vXa12XlXoCB+A== Message-ID: Date: Thu, 16 Dec 2021 11:20:03 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211216165533.2CAD332713F2@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211216165533.2CAD332713F2@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 16 Dec 2021 19:20:16 -0000 On 12/16/2021 8:55 AM, John Levine wrote: > I'm with you, validity > testing of the EHLO doesn't work well enough to standardize. I'm pretty sure I said nothing at all like that. I don't even have a guess how one could develop that interpretation of what I posted. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 11:23: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 73E843A103C for ; Thu, 16 Dec 2021 11:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 IEeocID3isA3 for ; Thu, 16 Dec 2021 11:23:11 -0800 (PST) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 37B183A1039 for ; Thu, 16 Dec 2021 11:23:10 -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 822AD821519 for ; Thu, 16 Dec 2021 19:23:08 +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 D9165822BE4 for ; Thu, 16 Dec 2021 19:23:07 +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.114.196.210 (trex/6.4.3); Thu, 16 Dec 2021 19:23:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Interest-Oafish: 7dccdc6e11cacab6_1639682588387_862997316 X-MC-Loop-Signature: 1639682588387:3075096331 X-MC-Ingress-Time: 1639682588386 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 4JFMTR0Y0Mz7bYZV for ; Thu, 16 Dec 2021 19:23:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639682587; bh=KMEzW8I6ppQsQ2kO1AO4qO+zwyWvVL8Y8+lvMKjv4nc=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=bMNwCFkktP33nvGCFNnwUDKKJWAVFZ8qRsKg2NKrd2FxPqlrBbmmZ7tIrjzHxCj1b Wp3pifLwJiA+0HD8N99h/1LsZZbW8abQwaWz7DnAh4o07DRX8jCUttc+DxHLBa95dm igOslTyvjKXtZzgBgjcyseUsr2Ac0gSHA9onqV6i7D5pGigqeB94DdAaStSIKTeUU8 cLPShZ4Ank5V4AqVQ7NoPVPNQUtmlvGSios8FL53Ec9XxwXfOxOQvCZmikW0jI1XzY Xq5Wdv5FDWfVmROJc47Wnh4J4wE0ZXSISE9d+brdKbq86YojJsAv6qpLHsTjdKF4k/ EUmWiovaKXIDQ== Message-ID: <5b1c9fcd-228c-5c88-1c65-2c42576a874e@dcrocker.net> Date: Thu, 16 Dec 2021 11:23:06 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211215190352.850D3326104C@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <20211215190352.850D3326104C@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 16 Dec 2021 19:23:17 -0000 On 12/15/2021 11:03 AM, John Levine wrote: > It appears that Dave Crocker said: >> When a receiving system changes that address, it is known to represent >> the 'intent' of the receiving system, not of the author. ... > >> Note that simply saying something like "until the message has reached >> the address specified in RCPT-TO" is far simpler, far easier to >> understand, technically reasonable and functionally sufficient. > > Every mail system I've ever used treats upper and lower case equivalently. > So if you send a message to JOHNL@IECC.COM, it goes into the mailbox for > johnl@iecc.com. How many deliveries is that? > > Many mail systems allow subadddresses, so mail for bob+ext or bob-ext usually > goes into the mailbox for bob. How many deliveries is that? > > Some systems, notably Gmail, ignore dots in the mailbox so mail to joeblow123, > joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same mailbox. How many > deliveries is each of those? Presumably, you think that the act of handing the message to a localo process that changes the address does not represent delivery. 1. Please explain very carefully, especially in terms that relate to the global email service. 2. Assuming my 'presumably' is correct, it isn't clear how you would characterize these examples. Possibly 'aliasing'? So aliasing is now an MTA function? Again, please explain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 12:09: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 EA3C33A11DE for ; Thu, 16 Dec 2021 12:09:12 -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=A7brX62U; dkim=pass (2048-bit key) header.d=taugh.com header.b=atMQN7P+ 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 kAMj3X56F_PK for ; Thu, 16 Dec 2021 12:09:07 -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 692D03A11DB for ; Thu, 16 Dec 2021 12:09:06 -0800 (PST) Received: (qmail 42323 invoked from network); 16 Dec 2021 20:09:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=a551.61bb9ce0.k2112; bh=0v3J0yVAYnmTxSWnRu7AsYOt64O5Di9I0jPy/8mIYZk=; b=A7brX62Uoc69CQXNyfgwCtAnF0yhKYtjz0inz3V0V1QWb0/ogbNHX+X6+4AMnGhrR4+L85nWahJzS8CsqxOpSEi/cAGax7iW2dxHHKCtlZ6sQRLEu4rekeIjmzTzsvcNhqJFLpBqIKtt1mFI1PTuEmv78xDbFC7EPjYDct2l1gcaLT4hj7njtljYjrWCnvvgeTFr5G24+8Mk04YNlSYKUjwA+Cb7e4rXQJs+x88fSZziheeCc93d++aC+BZUPm/jUJpfQF72+Bn5D9oeMssBkTe2YWjVE4Htscg8oz/192VBWRimiGTvq3ubXUfAw2QOnD3ChrriMthvZoIR/Pjtyw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=a551.61bb9ce0.k2112; bh=0v3J0yVAYnmTxSWnRu7AsYOt64O5Di9I0jPy/8mIYZk=; b=atMQN7P+EiD0aC5k6LaYw2LJ0Sjw9MJhDehcLg1beJdA+Pslj5ZT0T2BXLume0VPkHxiKIY98xSF7Xt7S4zNH+JuESJ0nScV9EHT/1bSU6PFL7ojMwtWsEreEsDtewxzEG37v4ZmhxfzhPpNPfG3umJwFnPH7fH1MnhipS8UmiSZsDm6A1Sqc4IDxb0c+s+GlrBQZx5oFZXfCWI9TeztDN2xDc62oiLaIsvBdCsb6al6PoEOhHw1ZdyI+ObE86UvsPVqVvbD+gjgT6KvDgU7r7G+FSgWwLw9CMzuHu4Olj/ujQBJitNZKBHbWJGJb5eP2l3MdQLwQo95+0g8tmbrvA== 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; 16 Dec 2021 20:09:04 -0000 Received: by ary.qy (Postfix, from userid 501) id B97DD32734B2; Thu, 16 Dec 2021 15:09:03 -0500 (EST) Date: 16 Dec 2021 15:09:03 -0500 Message-Id: <20211216200903.B97DD32734B2@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: 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] Postal mail is just like e-mail? 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, 16 Dec 2021 20:09:13 -0000 It appears that Dave Crocker said: >It will then be quite helpful for them to explain why and how Internet >Mail justifies a different model. If I have filed a forwarding order with the PO, they slap a yellow sticker on mail addressed to me and send it to the new addreess, all within the postal system, without it ever touching the original mailbox. I can report that a fair amount of local aliasing happens within the PO. For example, my local post office moved to a new building and they had to change some of the PO box numbers, including mine. Nonetheless, if someone sends mail to the old box, it goes into my new box. Also, I get a daily newspaper addressed to my house, but if the paper arrives after the carrier has left, they usually put it in my box so I can get it the same day. I was under the impression that people stopped saying that paper mail was the model for e-mail around 1980, but if not, I'm glad to see that we agree that forwarding and local aliasing are an integral part of the service. R's, John From nobody Thu Dec 16 12:15:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E563A11F7 for ; Thu, 16 Dec 2021 12:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 jFRtKhD3K13r for ; Thu, 16 Dec 2021 12:15:43 -0800 (PST) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0BB3A11FB for ; Thu, 16 Dec 2021 12:15:21 -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 0254B6C2AA8 for ; Thu, 16 Dec 2021 20:15:20 +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 6E8A66C102A for ; Thu, 16 Dec 2021 20:15:19 +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.109.250.15 (trex/6.4.3); Thu, 16 Dec 2021 20:15:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Illegal-Keen: 14b4110b6e9f307e_1639685719788_2532543955 X-MC-Loop-Signature: 1639685719788:3151993252 X-MC-Ingress-Time: 1639685719788 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 4JFNdf4099z2c2gL for ; Thu, 16 Dec 2021 20:15:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639685718; bh=9yNljapNNSlWiiq49g1OE1hRvJ1ZiqjEt32MXplTPgE=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=Z2+yW9a7eD/E7qC9o827N2MeRkXNd+0m8o0cgQkHtaPoIEHhZbqNhCSibH8lX53/0 LXVeyzJu4SdBQrqez8xhY8Fks9ATXnVbnSS2KeHVernDPL3GZj+XCqmVf5o7lohbU7 EqFlPPC/lhRR2dB3SOMJGSva5+yNtQIRxEjHBFtdHd1RLmPNRPHtsD+6/4Ya8Dt96p 0w9pkJ60/1kh0oVYa4P51zSqmQumql7zqm8z/hIvnhPvn7jWWr8T3EKTZsyWcaA+7m RlyCB9hqbDUajiMsLtDzxpTMtXDaSAkBKHXeIQeflPdId6BkzM64ucBy/v/rSlVpKW 2TEPrtgNzO9Cw== Message-ID: <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> Date: Thu, 16 Dec 2021 12:15:17 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org References: <20211216200903.B97DD32734B2@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <20211216200903.B97DD32734B2@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 16 Dec 2021 20:15:48 -0000 On 12/16/2021 12:09 PM, John Levine wrote: > It appears that Dave Crocker said: >> It will then be quite helpful for them to explain why and how Internet >> Mail justifies a different model. > > If I have filed a forwarding order with the PO, they slap a yellow sticker > on mail addressed to me and send it to the new addreess, all within the > postal system, without it ever touching the original mailbox. Ahh. So you do see aliasing as an MTA function. Interesting. A problem with that is that forwarding order, with them, is part of the independent transfer service, whereas the reality in email is that it is a function at the recipient destination. Not the last hop before the recipient's address, as with the post office, but actually /at/ the recipient address. Quite a different ball of formal and administrative responsibility. > I was under the impression that people stopped saying that paper mail was the > model for e-mail around 1980, but if not, I'm glad to see that we agree > that forwarding and local aliasing are an integral part of the service. Interesting claim. I don't recall it being true then or since. Perhaps you can document your view. Failing that, perhaps you can explain how your reference is relevant to the point I was/am seeking to make about architectural distinctions? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 12:57:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0B3A0403 for ; Thu, 16 Dec 2021 12:57:32 -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=IUMXqWyF; dkim=pass (2048-bit key) header.d=taugh.com header.b=X6EvpF+0 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 d0nTcXqhLtqI for ; Thu, 16 Dec 2021 12:57:26 -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 9BAC33A03F8 for ; Thu, 16 Dec 2021 12:57:26 -0800 (PST) Received: (qmail 51536 invoked from network); 16 Dec 2021 20:57:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c94e.61bba833.k2112; bh=HkGW/ugY6cSQGX5F9B2OdhF3In0MogQCULhiHA6/oNU=; b=IUMXqWyFECiA8nJV0JGOspnYovmpddubgyKVvXSCghuIYXmCuE+XJwKbhxVvgTffgAEMbRIl5rct/q+zpEc3srIArNt57oaiaNGfE0rlCaNfmETq8naAqEfirsOvacmKHMKbOhSTecAG69bTxw/fgkJbIYJqSYJKzCHWqML5OVaH4n/HFrkIDdksZZbnRoe5qAdmNFKe2vMybm0hoVBArAyZWuTruGcLs/fKRSlOsQSxjjRAGC3FeuR2FX/DVSsRyubQsAbeaCNDQb2x4L7SSt+wJY+A3yeOySVax+HiNXaRaK8d1PrXeacoehrn/u0gyLSiAVJDEwcLcJfk+1vIiA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c94e.61bba833.k2112; bh=HkGW/ugY6cSQGX5F9B2OdhF3In0MogQCULhiHA6/oNU=; b=X6EvpF+0aQmYIRr8/LHo9e89K4U7YEQFRjK6zUQcjmc3V3wsEq8VMXaz7cNhaOiDA386yvFTwH6UrV++JRj3qrnsP3ZXrgHRzxq5dpSRYZGQmU5TdCgxpxTY0yxGsCcVNplonZJQwwdRsHKui+gqCSaL2h/nUmqaj6s4z3sFNSGDegv2sxAPuedQJ5vcMURZPCtEdxzWlPV4ZT6UNhw4wQak38QV0Gx5WT8SWa+dJ8srEDGwbVvVGh2gzsvQhPVVxsWCWDBMZ21rsHrqRPj6QZyQ3mwhxjLeRI4tU6m9WLwIgqikun58ZrySL3h0YuNkWvTxkGnE2mWvTuMnjQAs6w== 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; 16 Dec 2021 20:57:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 723E33273D44; Thu, 16 Dec 2021 15:57:20 -0500 (EST) Date: 16 Dec 2021 15:57:20 -0500 Message-Id: <20211216205722.723E33273D44@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 16 Dec 2021 20:57:32 -0000 It appears that Dave Crocker said: >On 12/16/2021 12:09 PM, John Levine wrote: >> It appears that Dave Crocker said: >>> It will then be quite helpful for them to explain why and how Internet >>> Mail justifies a different model. >> >> If I have filed a forwarding order with the PO, they slap a yellow sticker >> on mail addressed to me and send it to the new addreess, all within the >> postal system, without it ever touching the original mailbox. > >Ahh. So you do see aliasing as an MTA function. Interesting. > >A problem with that is that forwarding order, with them, is part of the >independent transfer service, Sorry, but I have no idea what you mean by "independent transfer service" and I don't think I want to know. Among the many reasons that postal mail is not a useful model for e-mail is that postal mail is run by a small set of organizations with formal relationships based on contract and treaty, while e-mail is a large set of organizations with no relation at all, just shared software protocols. As I'm sure you remember, attempts like Goodmail to overlay a contract scheme on top of e-mail have all been failures. Barring some persuasive argument that we've been wrong for 40 years about the irrelevance of postal mail, I don't plan to argue about this any more. R's, John From nobody Thu Dec 16 13:07:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646C63A076F for ; Thu, 16 Dec 2021 13:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgb6ZEaKsSnn for ; Thu, 16 Dec 2021 13:07:09 -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 654323A076C for ; Thu, 16 Dec 2021 13:07:09 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxxxz-000EEH-SE; Thu, 16 Dec 2021 16:07:07 -0500 Date: Thu, 16 Dec 2021 16:07:02 -0500 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <869C0AEF21A9FFA3DFB3476A@PSB> In-Reply-To: <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> References: <20211216200903.B97DD32734B2@ary.qy> <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 16 Dec 2021 21:07:15 -0000 --On Thursday, December 16, 2021 12:15 -0800 Dave Crocker wrote: > On 12/16/2021 12:09 PM, John Levine wrote: >> It appears that Dave Crocker said: >>> It will then be quite helpful for them to explain why and >>> how Internet Mail justifies a different model. >> >> If I have filed a forwarding order with the PO, they slap a >> yellow sticker on mail addressed to me and send it to the new >> addreess, all within the postal system, without it ever >> touching the original mailbox. > > Ahh. So you do see aliasing as an MTA function. Interesting. > > A problem with that is that forwarding order, with them, is > part of the independent transfer service, whereas the reality > in email is that it is a function at the recipient > destination. Not the last hop before the recipient's address, > as with the post office, but actually /at/ the recipient > address. Dave, I may just not understand the distinction you are trying to make but, if I were to move to California next week and file a change of address notification with the postal service, and you then sent mail to me, that letter would get all the way across the country to New England, to one of two regional sorting facilities, before being rerouted to California. Whether it would get to my local post office (about three blocks away), to the facility at which letters are sorted into bags for handling by carriers (about a mile away), or one of the regional facilities or some subsidiary of it, might depend on which of my Cambridge addresses you sent it to, exactly how the mail piece was addressed, and whether the mail piece was handled as a letter or a small parcel. It also might depend on the time of year. If, instead of sending a message to me, you sent it to the New Hampshire address of a colleague who recently moved to the West Coast, most of the above would be different, not just because of the difference in states/ locations but because his address was part of a rural delivery service rather than the conventional more urban ones (and you couldn't tell his was rural delivery by looking at the address although sometimes you still can). All of those choices about routing and where the change of address would be noticed, the sticker affixed, and rerouting would occur would be out of both your control as sender and mine (or my colleague's) as the ultimate recipient. Different countries might do things differently. Or not. I don't see that as significantly different from what we do with Internet mail. The analogy gets even stronger if someone is using an email address of the form user@example.com at a company but that address is rewritten to a location-dependent one, e.g., user@seattle.example.com by some process associated with the servers for example.com. And, if that user changes locations, how soon incoming messages will be rewritten to, e.g., user@austin.example.com by that central management system or whether they will go to Seattle for a while and be rewritten/forwarded there (and where messages will be rejected if that user leaves the company entirely) will differ from company to company with the one thing in common being that the envelope is never opened and, with the exception of trace fields, the headers are never opened or affected. We make some of that work within our models by handwaving about "ADMD"s -- a concept that, as you know, came from X.400 and was not part of our vocabulary when 821/822 were written -- but, again, I see little if any significant difference from the postal model. > Quite a different ball of formal and administrative > responsibility. I don't see the distinction you are trying to make as clear, much less important to what we should do with 5321bis/5322bis. >... best, john From nobody Thu Dec 16 13:13:47 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8863A0812 for ; Thu, 16 Dec 2021 13:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 yl03jq-YiNjK for ; Thu, 16 Dec 2021 13:13:39 -0800 (PST) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9E63A080C for ; Thu, 16 Dec 2021 13:13:38 -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 53884622001 for ; Thu, 16 Dec 2021 21:13:37 +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 AA405622902 for ; Thu, 16 Dec 2021 21:13:36 +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.109.250.15 (trex/6.4.3); Thu, 16 Dec 2021 21:13:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Occur-Spill: 3957cd231904d6a6_1639689217116_1502520846 X-MC-Loop-Signature: 1639689217115:2295591588 X-MC-Ingress-Time: 1639689217115 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 4JFPwv65Zfz2c2fy for ; Thu, 16 Dec 2021 21:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639689215; bh=47bR3nJUHjBRpUwm2NKB3N62FQtFknoAU5fZCyisygs=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=hS1Ew58q/K50b7I1EtKctxxIINMOoUCs58WYVf0Q9QFFUAYcr8j6uNPejIz6SuHgM BZeHFBGvmq8QdHJTmjPl5hFrh/Z3ftMCYfceueiU8BknE2+/TeS/P7vm7GN7OOoHZ5 DAHyajKDktox9rzHz5N8VQjDZ4/lkLUWeluBSDttWa8av/hQN3kB2OiRDZcCnxWZuI shjXZ9VoDTC0VismCs3F77gjbl6BuB1c1rHD+Ty3RrX1e5XLOYnN/WW+t8/PUyuaHu bkF3Ia6Z17p3qrzCzbXau3heCFmuzHaF7nc+EG37pvji2MevMaBTQ5+0Aovz4vuQRu 5UqE1Xbkml15A== Message-ID: Date: Thu, 16 Dec 2021 13:13:35 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: emailcore@ietf.org References: <20211215190352.850D3326104C@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 16 Dec 2021 21:13:46 -0000 On 12/15/2021 4:41 PM, John C Klensin wrote: > There is an SMTP architecture and > fundamental protocol design that goes back to 821. There have > only been two significant changes made to it since 1992: the > introduction of MX-based mail routing with RFC 975 and the > extension model (including the replacement of HELO by EHLO) with > RFC 1425. No amount of wishing it were different, > second-guessing decisions made nearly 40 years ago, or > publication of descriptions that do not explicitly change SMTP Perhaps you can point to the second-guessing or wishing? It isn't clear what you are referring to. In any event, there is quite a bit of functional -- and, arguably, architectural -- enhancement buried in SMTP extensions. I'm also surprised at discounting the MSA/MDA enhancement that is well-adopted within Internet Mail, including the use of SMTP for the independent function -- ie, as a different service -- of submission. For reference, the UA/MTA model was developed at around the same time as SMTP and 822. I was active in IFIP WG 6.5, where is was produced and so we were well aware of its emergence. It was based on the emergence of MTA-like architectural splits at Xerox Park, DEC, Berkeley's Delivermail and UDel's MMDF. It's not mentioned in 821 or 822, but it arguably didn't need to be. In any event, there are many changes that have been done, over time. So references that seem to suggest a kind of historical rigidity are both odd and wrong. Specific concerns for WG charter and for barriers to full standard are an entirely different, and far more pragmatic -- and specific -- matter. Of course. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 14:58:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619E23A0E91 for ; Thu, 16 Dec 2021 14:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 Q9CzbayHYnlT for ; Thu, 16 Dec 2021 14:58:23 -0800 (PST) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431473A0E89 for ; Thu, 16 Dec 2021 14:58:22 -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 7698D921CE7 for ; Thu, 16 Dec 2021 22:58:21 +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 DAB4C921CA0 for ; Thu, 16 Dec 2021 22:58:20 +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.109.250.15 (trex/6.4.3); Thu, 16 Dec 2021 22:58:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cold-Wide-Eyed: 78a9dd1d3500283e_1639695501242_1705420312 X-MC-Loop-Signature: 1639695501242:1673779100 X-MC-Ingress-Time: 1639695501242 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 4JFSFl6dxDz2blnq for ; Thu, 16 Dec 2021 22:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639695500; bh=/mPj/4MEdXyrvpEilOtqTzZyp8oPoAFDVsSdeADNCeA=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=nlmk1yg9fokv0lzviTMbsZ1W7l6S76+OFaPDFmZ4OpjxhrCarbOX3jJg/7/W8kiUV 1AeFSKtfTsS9/w4ruZaPvK4h5M1QXrWL8GB6C0bFqtc7YkLO/PR3d/wJOGusYsrM4t IHOo2X+VLjpxR9CnA1x6ZUaIuh4zn7BY0jtWp20I+XHbuYSzEVDKib/CknCjeUbpbt PDol4FEKnS6ukB5kseTbvEXsH6IWIEqF2cUnWoCYuhdtROyZAy28vwcpyVZ1vj9zuD rfASCy87qNMrpx1YG1yQhP7MuKGt1CrSetNTK+7LEOAe6qwGYUWFcySSVI91HCJICF gJmgsc3OSaPOA== Message-ID: <6f0c68fc-7c93-85be-8dcc-1d41f75c3bc8@dcrocker.net> Date: Thu, 16 Dec 2021 14:58:19 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org References: <20211216205722.723E33273D44@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: <20211216205722.723E33273D44@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 16 Dec 2021 22:58:29 -0000 On 12/16/2021 12:57 PM, John Levine wrote: > It appears that Dave Crocker said: >> On 12/16/2021 12:09 PM, John Levine wrote: >>> It appears that Dave Crocker said: >>>> It will then be quite helpful for them to explain why and how Internet >>>> Mail justifies a different model. >>> >>> If I have filed a forwarding order with the PO, they slap a yellow sticker >>> on mail addressed to me and send it to the new addreess, all within the >>> postal system, without it ever touching the original mailbox. >> >> Ahh. So you do see aliasing as an MTA function. Interesting. >> >> A problem with that is that forwarding order, with them, is part of the >> independent transfer service, > > Sorry, but I have no idea what you mean by "independent transfer service" and I > don't think I want to know. Seems to be a pattern. And yet the distinction between 'part of the transit' versus 'part of the source' (originating) or 'part of the destination' (receiving) matter quite a bit here. The nature of their responsibilities and authorizations vary enormously. > Among the many reasons that postal mail is not a useful model for e-mail is > that postal mail is run by a small set of organizations with formal relationships > based on contract and treaty, while e-mail is a large set of organizations with > no relation at all, just shared software protocols. All of that is very nice, but doesn't attend to the specifics, here, absent your created specific linkages. > As I'm sure you remember, attempts like Goodmail to overlay a contract scheme > on top of e-mail have all been failures. Goodmail had nothing to do with independent transfer services, like postal mail. It had to do with independent reputation certification of the author. Quite a different thing. And for all intents and purposes, none of the email reputation startups succeeded, no matter the model they offered. So this is another reference that turns out to be irrelevant to the current case. > Barring some persuasive argument that we've been wrong for 40 years about the > irrelevance of postal mail, I don't plan to argue about this any more. Excellent. Does that mean you'll try to respond to the substance, instead? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 16 16:01:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C943A0126 for ; Thu, 16 Dec 2021 16:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 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=-1.852, 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=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 hewDDpR-SPs3 for ; Thu, 16 Dec 2021 16:01:20 -0800 (PST) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on20705.outbound.protection.outlook.com [IPv6:2a01:111:f403:700c::705]) (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 C28533A011F for ; Thu, 16 Dec 2021 16:01:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WaRBPLpRj93Db5vt+JCisRPLOCHISRgnZZt61YZ6i7WkryTw4RpKIMgsgh83tZVE7xEWH1lRJoUItK7+8JLAiDUouAUMpeOHi8RQThq7k68StyuHh2T8wnI2+7WrW+BXpXDvcUBjBUWbgOyBX+OcgOY6OsyhWeEROMnx+yUTqJ5gbCRBWXzpYqBnubuebpoY/6ZdlTQcZzDRCJ00B3DOB3HK/1lpes0XdGoAVQh0/jUL8tsuWqAneu6rIQ3xOs1cbRu+27x9b4GUQeAkz0bc4TX3OkQl885VmFEpqf3X/n+shscCdN/PztQWR7G7WCc3IQxbyyP5ISlKyo7UZ/YbCQ== 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=EGdJCzmgv3PYidtMkF25KXxr6nyH1jBlWwwO4GtVKZc=; b=Qy+XJ02sdj2hPpbkZkq+lhDQiHrg2OtrsavN2/M8rhHeJ156yorTUnrq2W5sX4wscFaAuIoGuZpmUwBhaHwxzxgfpObaehOkmAx1su8NJ3Xc3l06zzxj7spdK33RwYg2NB5BrRfnjhlT3gyrnfUpyWA3asCxBFnf5GqFUy0/RMkd8UBPeIa88cDAaUydxhFTLaoWmxpxz9ZQwaxGaVOCb5xvPaBk/be63qkRnyb5WS1Z8U4pbaAdne739GRuBLo4Ay0W0AOMLf15b6B6tD2szK/WZob7l1x8sZQu6J5v31yYtRVETwRNtFcLbwrPaAUwv1XekMizBDhcXO383UCB1A== 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=EGdJCzmgv3PYidtMkF25KXxr6nyH1jBlWwwO4GtVKZc=; b=UNzUbThrcPB8HO+XfoDZWfaNaB2JT+6ZuXAEOYBM9VTMd7z9wi6RbhVIybuZ1LwtBP+Cyk6fkuVDha6kbkJb3azgn5HHh0NQdAmw8mE7sLR/WHfhILrkgyuwwpDiEbHWTL1cWIqH86yFo7o1aRPwx17V6tA8e+XOAlmpFzk6mjI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB3852.jpnprd01.prod.outlook.com (2603:1096:404:e0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Fri, 17 Dec 2021 00:01:08 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%6]) with mapi id 15.20.4755.022; Fri, 17 Dec 2021 00:01:08 +0000 Message-ID: Date: Fri, 17 Dec 2021 09:01:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John C Klensin , dcrocker@bbiw.net, emailcore@ietf.org References: <20211216200903.B97DD32734B2@ary.qy> <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> <869C0AEF21A9FFA3DFB3476A@PSB> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <869C0AEF21A9FFA3DFB3476A@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0087.jpnprd01.prod.outlook.com (2603:1096:404:2c::27) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [192.168.1.6] (223.218.110.25) by TYAPR01CA0087.jpnprd01.prod.outlook.com (2603:1096:404:2c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Fri, 17 Dec 2021 00:01:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7f276cb7-2973-4b06-1c66-08d9c0f053d9 X-MS-TrafficTypeDiagnostic: TY2PR01MB3852:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f1hh/TY9WlzisjXJ/BYTTLKq4o+krUuNbV++4Yea7b7VD02KmIHegGseE7S4aDDMrMrH3u/I5Gk30hCGWTew204K/IOTgm5/OW2veP/7bxUOJqFFEVP1p89QBCXytCYmwk3z2H5/oRg19U6vaAVJ/cPe8tGjEf8EBmXyfdLiag7+EopLrJ0iWlUWZOFQ+6GCk7M9eKFHd4qKOc0YnUVLiNHkq3jkvABgGB4K/c6D5eh+gK2NQAVtQIiT3zh1tEBCuijnEJRuYUIKATF+C0nb7fhB2EFqI7KA4BnejuDetgUVhNwuutOgdGrIEnuEeQMxsePZCadTpy2RJT0daB5TAhx9zOxiyKb9dG2b/5mdyPMD85xM0mluMGG2tGQJhyljy80KGZmrEiujmnoThTjvGjIaKM07OYbkXD999zp99Vz1JjBgpw040GMO9nbk6UIeudA499R3of24V2mfG6MUohxDApS0gXugekZBqq0NguW1kF9VGt236U+/hpAa9VDj2ERM39PbjKjxVNQeTuLHquukKdNzD0Q5CZpqjYn679uCo+tVMbRdnBZTOhoQTBDW6BrAs7bMP+NEifCbfvK8VQueHQYBtVBh6/tc3+WWQEMnJwsZVD+/8Js/q3I4K0oYoKQqJ2hyIW7JPcBfnLjPqt2Aqh4pXsEb9J8v4Kwa20qdu0HsFQKQ6XGvJWnsL3rDCHdIgszMg0Lrr5oBx/1J7468SkekkCjYP6C82ac3IaPDts3Ho+OmBs7b6gSZVgTmTCt7oK7AOJPhlx/WEy9KtA== 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)(39850400004)(346002)(136003)(396003)(366004)(8676002)(26005)(52116002)(2906002)(186003)(786003)(6486002)(53546011)(86362001)(31686004)(38100700002)(8936002)(38350700002)(5660300002)(16576012)(316002)(36916002)(4001150100001)(31696002)(508600001)(83380400001)(66556008)(66476007)(2616005)(66946007)(66574015)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bjRuVmZORVBjVGwvRHpJeGY3SFhZOEplU1pMRGhMUm1aWEhuMUV3VmF4b1NN?= =?utf-8?B?U1ZrclF3ZUZKMlBEVVN5U283c0d6MG9nbWwxZTJSWHZMcTFLUkVDRnZaVUhr?= =?utf-8?B?Y1Q3aWhwMC9UZnBZYmxvU25CN3pXZmVXTjBHRktGSENBQXc2UXZSSFd0Y2tG?= =?utf-8?B?QkVFLzBkT25lZFdmNFMyKzdjUkVQMEkzd0FqdDFldUQxNkU4b1dTSnphaXVR?= =?utf-8?B?YXpyQlBXb05oZmY0TWNiSHgrejBkS09WTk9IZW5UTnVXU0JlTktJTkR5WmNo?= =?utf-8?B?S0J3YXRtQnpEMlo5dVI4MHBvU2hkMCsvMy9oOG9ZZ2dwWW5IQjY4ZXB6WkRQ?= =?utf-8?B?KzRyeEZrNExKUTZmUllOdTg5N2RNL0c5ZXI5UC8vZFNadG85dHZpbTNEM1Q4?= =?utf-8?B?OXBzRExBTWNKNnF6T05pR0VYTGxrYWJUWjBtZXZSVHZpcUZ5Yk5PTmZpb0x3?= =?utf-8?B?SG84dGE3QWZDTWNFZFpUTVdZbTF6Y0tFK3ZPVUtrU2FKeVI0QmZyRWwvK0pk?= =?utf-8?B?eG1FT2RTdk8zWG40czY2Y2ppWTRMUkJBNDk0NCtwdVhqUSt1d0QyV0RmdDJH?= =?utf-8?B?eDlVTU5UOERqSFA2OW85RHJLb0QzYVJCZmVxZEszRG1zQXQ4L09zWnlkWVhi?= =?utf-8?B?RUQ0eVRvOHZ0WEhZeFBkeWJZeDdnd09VMGxXOGpRWWdneERRbmh0RU9Xdm8x?= =?utf-8?B?VytjSlF5VGJsZ2JWdEdQWk9nS0lKZXFXQkZ5U0xSMGIyUjJzUEwrRWhscVFP?= =?utf-8?B?T1Nmd0Q2WU9vcStUQlVXTjdRanZBSFdtV3dCQUJWQm40Y0dMN3IzRnRtTjNw?= =?utf-8?B?NEp3RlZpMG5qRVZ6WDd3VlNQczZWRXFRZ2oycktROG0yVlJMa2JFOGFlOE9V?= =?utf-8?B?T2o3UjNwZU1rdVZQZ3NCeENld0JLc0tNMlhpMk91MnlJVjJGMW1mN0k1eXp2?= =?utf-8?B?NjlhMkFxcmhVOEFKeEdjVEg0MmQ2MnVOWjlBUVgxT2xsZXd5aFhmUmJVZmk0?= =?utf-8?B?bDJ5TDNaNVNzLzlZTmc4K3UzV3NwQ1NJVUt5TXhvYVo4Uko2aTNBSzU2NWFC?= =?utf-8?B?Vm50Qlpla3pRMzk2dnpHSW41NVpiTmp6ZmNmVXJVVDIyTEZ3UFVJek9ST0lX?= =?utf-8?B?RjFCeEhiTFNnRjB5YzhJSmtyeDhVMjY2alB5M3NDdVc3S3ZPenhNYklFemVI?= =?utf-8?B?NEVsOXdJZUhsUXQ1LzRYaEFoK1JSSWk0MWFIb3VETCtBVVlHbVBnaW9iUmVL?= =?utf-8?B?NVlTbXlFdGFmSXJVS3pERVhjclg1MjZ5M1NlcGludW11NENZM1hZNmI0N2tN?= =?utf-8?B?M3NhTHM5bzhLZk5rK3pQbkFWWWMwRE9Hb29hTW9wN29HYTFpQjB4dlpYNk1q?= =?utf-8?B?RTNsQTd6a0xGY1BuNUM3U3ptZmZyMmFrbzZEdTIwb1FiRVJDd2NWSVRrNjNS?= =?utf-8?B?QTY2RU5Qd3VHQWVjakY0R3VWQlFpQkdwdHZINkZUSlNiOC90Y0YySVdRN0xV?= =?utf-8?B?UnFBQmpYRWtaMlVNT3VKdXAvN1hnZnlnbEE4aWFXTnk2K0tXMThJb2ZXd3B3?= =?utf-8?B?SU1KT3BSejJMcEJuMnovS2tvaWRMRlRrVkJIeTZEVW40aXRDU3E4Yytjd1h0?= =?utf-8?B?aVE0aCtaeHBucWp1eGFmcFNBbml3UlFpcG1JOStva2FtdDhqYjJsdEs4ejdz?= =?utf-8?B?ZHhBSHAxSHRheERyRm1KY2pVemlad3VVcWZzeWJ2Mkt5UnM5bzFmQUVZM1Zt?= =?utf-8?B?QWJ3WVJyZVUwK0ZjNWR5VEhLT0dOSTJrYytuaGNoakJKaEpqQVhXc0podEZG?= =?utf-8?B?SzBvUGwvZzlyQWc2dVMrY3ljZlZ5by9ybzhCS3JHYktMc1kyZ00ycTNQWjVT?= =?utf-8?B?eGxkR2h5Q0dMUG15SlRpeTdvSEJSZVgwQVdOUFB6NWdFRDZoTVJaTnlFWHc1?= =?utf-8?B?ZGhhd1UxejQ5YTlaMEUrb3QvY2lobTZTclpHOTZzbjhoS1UrdEpzTm8yMGpt?= =?utf-8?B?L2wva21oSXkreS9HTzFaUFFmNVFMVHU3SVo0ZU9rMEZlNEphVStYRzMxdXhF?= =?utf-8?B?LzgrOExYNmtJbCtmSTk4c29ZaUdFNm1scHlZN242UEhkeERHMThZclBlRVdV?= =?utf-8?B?STQ5NU90TFFwcTFZbTJQOXA4SWhtYmJIZ3JnRmZhUVYyQ2Y3RTBvVVRkWkc1?= =?utf-8?Q?q4d2Z+aCAJ5XPiiwiNQqlnk=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 7f276cb7-2973-4b06-1c66-08d9c0f053d9 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2021 00:01:08.3400 (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: OTCEZPMc7gT+5XUO+pB9ZyStuwy5D8v87yNpa3wvo3eKdmuJIVLDjF4xz/HZovS4gH+prndU9FOivEc0NStq8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3852 Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 17 Dec 2021 00:01:26 -0000 Reading the thread with quite some interest, it seems as if Dave is equating organizations that handle email (like example.com) to households in the postal system, but John K. (and probably John L.) is equating them to independent postal systems. Given that an SMTP connection (e.g. between a.foo.com and b.bar.org) is essentially just a handover (such as it may happen in the postal system between countries, or between different sub-units of a country's postal system) and not a system in and by itself, John's view seems more appropriate to me. The email system would then have (way) more independent "postal services" than the snail mail system. That is unless we count organizations and households as independent systems, which at least in the case of companies with their internal mail-handling infrastructure may well be justified. Also, Dave gave registered mail as an example. In the postal system, receipt of registered mail is confirmed at the household door. I (and in my I guess most email users) have little practical experience with Mail Disposition Notifications (RFC 8098). However, the choices there (displayed/deleted/dispatched/processed) suggest that an MDN from a recipient after forwarding/aliasing is at least an option, and probably the most desirable one. This would put delivery at that point. Anyway, all that's assuming the analogies help. I think the IETF way as I know it would be to go back to actual protocol consequences (architecture is just hot air if it doesn't change what's happening "on the ground"), and to actual proposals for textual changes. Regards, Martin. On 2021-12-17 06:07, John C Klensin wrote: > > > --On Thursday, December 16, 2021 12:15 -0800 Dave Crocker > wrote: > >> On 12/16/2021 12:09 PM, John Levine wrote: >>> It appears that Dave Crocker said: >>>> It will then be quite helpful for them to explain why and >>>> how Internet Mail justifies a different model. >>> >>> If I have filed a forwarding order with the PO, they slap a >>> yellow sticker on mail addressed to me and send it to the new >>> addreess, all within the postal system, without it ever >>> touching the original mailbox. >> >> Ahh. So you do see aliasing as an MTA function. Interesting. >> >> A problem with that is that forwarding order, with them, is >> part of the independent transfer service, whereas the reality >> in email is that it is a function at the recipient >> destination. Not the last hop before the recipient's address, >> as with the post office, but actually /at/ the recipient >> address. > > Dave, > > I may just not understand the distinction you are trying to make > but, if I were to move to California next week and file a change > of address notification with the postal service, and you then > sent mail to me, that letter would get all the way across the > country to New England, to one of two regional sorting > facilities, before being rerouted to California. Whether it > would get to my local post office (about three blocks away), to > the facility at which letters are sorted into bags for handling > by carriers (about a mile away), or one of the regional > facilities or some subsidiary of it, might depend on which of my > Cambridge addresses you sent it to, exactly how the mail piece > was addressed, and whether the mail piece was handled as a > letter or a small parcel. It also might depend on the time of > year. If, instead of sending a message to me, you sent it to > the New Hampshire address of a colleague who recently moved to > the West Coast, most of the above would be different, not just > because of the difference in states/ locations but because his > address was part of a rural delivery service rather than the > conventional more urban ones (and you couldn't tell his was > rural delivery by looking at the address although sometimes you > still can). > > All of those choices about routing and where the change of > address would be noticed, the sticker affixed, and rerouting > would occur would be out of both your control as sender and mine > (or my colleague's) as the ultimate recipient. > > Different countries might do things differently. Or not. > > I don't see that as significantly different from what we do with > Internet mail. The analogy gets even stronger if someone is > using an email address of the form user@example.com at a company > but that address is rewritten to a location-dependent one, e.g., > user@seattle.example.com by some process associated with the > servers for example.com. And, if that user changes locations, > how soon incoming messages will be rewritten to, e.g., > user@austin.example.com by that central management system or > whether they will go to Seattle for a while and be > rewritten/forwarded there (and where messages will be rejected > if that user leaves the company entirely) will differ from > company to company with the one thing in common being that the > envelope is never opened and, with the exception of trace > fields, the headers are never opened or affected. > > We make some of that work within our models by handwaving about > "ADMD"s -- a concept that, as you know, came from X.400 and was > not part of our vocabulary when 821/822 were written -- but, > again, I see little if any significant difference from the > postal model. > >> Quite a different ball of formal and administrative >> responsibility. > > I don't see the distinction you are trying to make as clear, > much less important to what we should do with 5321bis/5322bis. > >> ... > > best, > john > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Fri Dec 17 10:01:47 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709203A0412 for ; Fri, 17 Dec 2021 10:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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_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=Y32Z3MQG; dkim=pass (1152-bit key) header.d=tana.it header.b=AO0Dx/Om 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 brpUZzLwKwYF for ; Fri, 17 Dec 2021 10:01:38 -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 D627E3A040C for ; Fri, 17 Dec 2021 10:01:37 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1639764088; bh=7kgzOOzMn1i8JywcJ5MIKkvP4IbZCIt0fqoYWr2a8a4=; h=Subject:To:References:From:Date:In-Reply-To; b=Y32Z3MQGC2FZwjuTe7B9vKHyZbGyFrU0dOcHHBfxcoV0h+rwD4HDc9ajLpH/7WPmE 84pSV75FNzhQ8MQxlHyBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1639764088; bh=7kgzOOzMn1i8JywcJ5MIKkvP4IbZCIt0fqoYWr2a8a4=; h=To:References:From:Date:In-Reply-To; b=AO0Dx/OmgshK9GlHRV+9HrWWRQQo8HVCSMOW8q6HycdGXrZ/MZgeDbo318WsIjh5R iF0WarPYfH6IpcRxBLnxm/b9LD+i+LdQhsZ3ihwPamaoI2WO6cvpxQnOfmWv2D76eP T5enTtG1lJ9Y9/hhjx2Z8++UJgIPKH2iGLU/sf+NJ790vqGLM8DeCEGTxvm7H 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.0000000061BCD078.00000504; Fri, 17 Dec 2021 19:01:28 +0100 To: emailcore@ietf.org References: <20211215190352.850D3326104C@ary.qy> <5b1c9fcd-228c-5c88-1c65-2c42576a874e@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Fri, 17 Dec 2021 19:01:27 +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: <5b1c9fcd-228c-5c88-1c65-2c42576a874e@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Addressing scope & level / Author intent (was: Re: Scope of submission/delivery and address alteration) 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, 17 Dec 2021 18:01:46 -0000 On Thu 16/Dec/2021 20:23:06 +0100 Dave Crocker wrote: > On 12/15/2021 11:03 AM, John Levine wrote: >> It appears that Dave Crocker  said: >> >>> When a receiving system changes that address, it is known to represent >>> the 'intent' of the receiving system, not of the author. ... Considering the author's intention is a sharp discriminant. However, I'd argue that the intent of the author was to reach a real person (or function) rather than a syntactically defined mailbox. Mailing lists are neatly different. When I write to a ML I intend to reach a community. The MLM provides both the community cohesive definition as well as the logistics. It's role is missing in snail mail, unless you consider newspapers and magazines which used to publish readers' comments, and possibly related replies. >> Some systems, notably Gmail, ignore dots in the mailbox so mail to joeblow123, >> joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same mailbox.  How many >> deliveries is each of those? > > Presumably, you think that the act of handing the message to a local process > that changes the address does not represent delivery. That's right, it doesn't. It has to, otherwise neither changing address nor functional addresses would be possible. If we admit email address portability, even dot-forward files and similar rewriting are to be considered part of the protocol. I'd tend to distinguish internal from foreign aliasing though, because of all the authentication/ reputation issues that concern the latter. Best Ale -- From nobody Fri Dec 17 15:04:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66463A0B6E for ; Fri, 17 Dec 2021 15:04:49 -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 ZOXEMckFiAMI for ; Fri, 17 Dec 2021 15:04:44 -0800 (PST) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 4AA653A0B6F for ; Fri, 17 Dec 2021 15:04:43 -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 9F43C9212D0; Fri, 17 Dec 2021 23:04:42 +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 C189A92211D; Fri, 17 Dec 2021 23:04:41 +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.109.250.15 (trex/6.4.3); Fri, 17 Dec 2021 23:04:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Supply-Glossy: 3dc92388470b1553_1639782282370_2717394232 X-MC-Loop-Signature: 1639782282370:792511803 X-MC-Ingress-Time: 1639782282370 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 4JG4Lb6PQ3z2YsNF; Fri, 17 Dec 2021 23:04:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639782281; bh=5DTj/hZv9iGUwIZZ794xCuY4Tfl0uH+g+GV/ELm0rVk=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=UYy4aQn+Oqu/YUisnTGTU9/QrJriHeQwc2pOvBCEfXUB6y1NgkCJ6IMd4iVMcAplG 5InADHK50TJ1vYe4nn4fQlztAcTIHifbT3lHAziVwETGHiw9AL/LcrFk6GRNFDVpWZ RHMIK3X3Iqoktlm+Fh3KZsJULzHysca/nAflfEcCkYWP2JCkoTH8X+lsmnF4f3XvVk teXATRlYIqyXf1oHr0twI0tYNOpRLd7bpyrMkh6KoA/D8ln7dnvSEJWO9wbSAh77lN 0Syh85xCwOonobV6DWe70V9CijHCb1KDsnSC4AdIcgTMW7mR9ekETOfmFDOrUlAfm1 HhYi6K/IEoPAA== Message-ID: Date: Fri, 17 Dec 2021 15:04:38 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , emailcore@ietf.org References: <20211216200903.B97DD32734B2@ary.qy> <259dcf1b-9f1f-af75-15a2-e0cb3db9c674@dcrocker.net> <869C0AEF21A9FFA3DFB3476A@PSB> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Postal mail is just like e-mail? 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, 17 Dec 2021 23:04:50 -0000 Hi Martin, On 12/16/2021 4:01 PM, Martin J. Dürst wrote: > Reading the thread with quite some interest, it seems as if Dave is > equating organizations that handle email (like example.com) to > households in the postal system, but John K. (and probably John L.) is > equating them to independent postal systems. More specifically, my point is that: 1. The end system is a distinct authority from the handling systems earlier in the transit sequence. 2. Internet mail specifications distinguish between who is expected to treat the LHS string as opaque and who is expected to process it -- except perhaps for some error conditions -- where that last system in the sequence is the only one to do LHS process and is identified in the RHS domain name. 3. Aliases and mailing list managers reside within the authority of that last system. The postal model I offered matches all these details. The one John offered does not. Instead he offered one that I believe has no equivalent in Internet Mail specifications. That it might occur in the wild is nice but irrelevant, since we are talking about our specs, not the full range of what happens in the wild. John's model essentially puts aliasing in the MTA. Mine does not. (We can debate whether it is in the MDA vs. a post-delivery, user-level process, as a separate matter.) > Given that an SMTP connection (e.g. between a.foo.com and b.bar.org) is > essentially just a handover (such as it may happen in the postal system > between countries, or between different sub-units of a country's postal > system) and not a system in and by itself, John's view seems more > appropriate to me. Please reconsider a bit further, given my above points. > The email system would then have (way) more > independent "postal services" than the snail mail system. It does. But how does that matter, for this topic? > That is unless > we count organizations and households as independent systems, which at > least in the case of companies with their internal mail-handling > infrastructure may well be justified. Exactly. Because in the Internet Mail model, they are indeed independent services. (RFC 5598, invokes the ADMD term to emphasize this essential point. > Also, Dave gave registered mail as an example. In the postal system, > receipt of registered mail is confirmed at the household door. I cited Registered mail because it documents the steps. However general the semantics apply to all postal mail. The post office delivers to a physical address, not to person. I am still getting mail for my house's previous owner, from 35 years ago. (The mechanism John cited is exceptional.) Email is handed to the RHS domain name's handling service, without regard to the LHS value. John's example was for something that happens before that. But aliasing and mailing lists happen after it. As does the Postal example I cited. When the post office transfers the mail to the household, it is considered delivered. If someone in the household does something other than get it to the person named in the first line, that is /after/ 'initial' delivery and IMO it is quite reasonable to call completion of that re-routing a second delivery. > I (and in> my I guess most email users) have little practical experience with Mail > Disposition Notifications (RFC 8098). However, the choices there > (displayed/deleted/dispatched/processed) suggest that an MDN from a > recipient after forwarding/aliasing is at least an option, and probably > the most desirable one. This would put delivery at that point. MDN is a user-level process, not a handling/transfer service process. The difference is fundamental. And the difference in their names is relevant: DSN (RFC 3464) refers to delivery, and is part of the infrastructure effort. MDN (RFC 8098) refers to disposition. Note RFC 8098's second sentence in its first paragraph: "An MDN can be used to notify the sender of a message of any of several conditions that may occur after successful delivery, such as display of the message contents, printing of the message, deletion (without display) of the message, or the recipient's refusal to provide MDNs." Use of the word 'after' is key. The RFC's Section 4 (Timeline of Events) is also especially enlightening. RFC 3464 cites 'delivery': '"delivered" indicates that the message was successfully delivered to the recipient address specified by the sender, which includes "delivery" to a mailing list exploder.' And as much as some folk want to claim a major difference between aliases and mailing lists, please note the language in this other DSN action-value: '"expanded" indicates that the message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. An action-value of "expanded" differs from "delivered" in that "expanded" is not a terminal state.' (There is more to consider in that text, and I hope that discussion here can progress with enough substance to engage on its finer points.) > I think the IETF way as I know it would be to go back to actual protocol > consequences (architecture is just hot air if it doesn't change what's > happening "on the ground"), and to actual proposals for textual changes. Agreed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Dec 18 08:20:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AC83A1016 for ; Sat, 18 Dec 2021 08:20:01 -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 fZC8PzH-IZge for ; Sat, 18 Dec 2021 08:19:55 -0800 (PST) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 38A603A0644 for ; Sat, 18 Dec 2021 08:19:54 -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 D0344622685; Sat, 18 Dec 2021 16:19:53 +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 212A862255E; Sat, 18 Dec 2021 16:19:53 +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.114.196.210 (trex/6.4.3); Sat, 18 Dec 2021 16:19:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Arch-Arithmetic: 7881dd9c7a8d4ed4_1639844393615_2922910204 X-MC-Loop-Signature: 1639844393615:1905169972 X-MC-Ingress-Time: 1639844393615 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 4JGWK31nQrz2blnl; Sat, 18 Dec 2021 16:19:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1639844392; bh=B8C0d9fY1yfMXHu3JO/dB409VonDZXpj7UkHpgot3FM=; h=Date:Subject:To:References:From:Reply-To:In-Reply-To; b=NdQUCKjIgixbT9r9NtBSVV0SKH/I68wqa89IyJvSdtu7fbX6V4vYUz1lVj700kxYW +kbJCLflsCopkgM5hI7rbK8Oun7Bb7BDxMo30MZ6X9gZVKA6ZdSWCRaebX+Z+PswSC 7kK5Owh2CaH050XoiPOXfvJhddurCql34AIhNxw2iwX/9gnuC3Jp7O40cViuORLkNf n6FGsV+rz24w9E0kb+h0Id6GgdCYlht3HFXAPpMjdIqNvA+kkaL+wwXB+yKPOXu+mf w3rY2HNRR1eB5MJxArG2rg8sLFejZl+JeF4Q8lyo0pfA8BzlXOBWVjmDGB5HjVthn+ PzHocigIMnXxw== Message-ID: <19c20aa5-70af-d223-702e-d6838c95c36d@dcrocker.net> Date: Sat, 18 Dec 2021 08:19:50 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Alessandro Vesely , emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> <51640ce4-974e-c461-ca2b-d6fabff813a6@tana.it> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <51640ce4-974e-c461-ca2b-d6fabff813a6@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 16:20:02 -0000 On 12/16/2021 9:40 AM, Alessandro Vesely wrote: > On Thu 16/Dec/2021 16:20:52 +0100 Dave Crocker wrote: >> On 12/16/2021 4:11 AM, Alessandro Vesely wrote: >>> On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: >>>> >>>> A domain name that is registered through the ICANN hierarchy of >>>> registries is 'valid'. >>> >>> Isn't that overly restrictive? >> >> To answer that requires first seeing what alternative you have in mind. > > SMTP, as a protocol, can be used between internal hosts; where > "internal" stands for non-registered and/or not publicly accessible. > They must still be considered valid by the server they connect to. Given split DNS, and even host.txt, operation within an enterprise does not require use of non-registered names. (Just to be clear, putting a name in host.txt is a kind of registration.) So while it is possible to allow for 'internal' operation that does not require names to be registered, it isn't required. It's a specification choice. In any event, my intent has been to press for clarity and precision in the specification. The details of what all that clarity and precision says is a matter for working group agreement. My own inclination, at this point, is to move details about domain name testing to an applicability statement, or the like, and to keep it out of the protocol specification. This allows a clean protocol doc to be applied to different environments that have different operational requirements and constraints. >>>> What your effort, here, does is to bring back 'resolvability', which >>>> I assume is what you really mean by 'validity'. >>> >>> >>> My intention was the opposite.  By replacing 'resolvability' (and >>> matching IP) with an abstract 'validity' the semantic remains open. >> >> A specification that has an 'open' semantic is not specifying anything >> a normative protocol detail that is meaningful.  (literally) > > > Uh... I beg your pardon, perhaps I should have said an open mechanism. > The semantic meaning is that the EHLO argument had better be good > because the server will check it. And my point is that the semantic for 'good' needs to be precisely statement and operationally meaningful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Dec 18 10:02:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481E23A1083 for ; Sat, 18 Dec 2021 10:02:33 -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 orxDcyEdxDJl for ; Sat, 18 Dec 2021 10:02:30 -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 1E73C3A1082 for ; Sat, 18 Dec 2021 10:02:28 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mye2G-000IWx-0C; Sat, 18 Dec 2021 13:02:20 -0500 Date: Sat, 18 Dec 2021 13:02:14 -0500 From: John C Klensin To: dcrocker@bbiw.net, Alessandro Vesely , emailcore@ietf.org Message-ID: <77C7A2B80D556DD736739583@PSB> In-Reply-To: <19c20aa5-70af-d223-702e-d6838c95c36d@dcrocker.net> References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> <51640ce4-974e-c461-ca2b-d6fabff813a6@tana.it> <19c20aa5-70af-d223-702e-d6838c95c36d@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 18:02:34 -0000 --On Saturday, December 18, 2021 08:19 -0800 Dave Crocker wrote: >... > In any event, my intent has been to press for clarity and > precision in the specification. The details of what all that > clarity and precision says is a matter for working group > agreement. > > My own inclination, at this point, is to move details about > domain name testing to an applicability statement, or the > like, and to keep it out of the protocol specification. This > allows a clean protocol doc to be applied to different > environments that have different operational requirements and > constraints. >... For information and commenting on the above only, I should probably state my personal preference/rule as editor. It is, of course, subject to interpretations and decisions by the WG Chairs. It also reflects my personal view of the types of changes it is appropriate to make when going to Internet Standard -- a view on which I will defer to any WG consensus as long as that consensus does not conflict with clear statements in the relevant BCPs. RFC 5321 was an IETF consensus document that came out of a WG with a much higher level of activity and much broader participation than this one has exhibited (at least so far). It built on a long operational and consensus history, including that developed in other high-participation WGs, not only about the narrowly interpreted protocol specification but of what was appropriately covered and included (or not). That suggests to me that there should be fairly clear agreement about any changes in definitions or scope and that, if there is significant controversy about some potential change, we should just leave things alone. Doing things that way not only preserves the earlier consensus, but adheres to a principle that drove 5321 and 2821 (fwiw, several times over my objections) to avoid making changes that might inadvertently introduce errors or new sources of confusion. One implication is that, while it makes me personally uncomfortable because, like Dave in his statement above, I generally have a strong preference for clarity and precision, there are places in which 5321 (and its predecessors) are a bit vague but where we need to examine whether the vagueness may have served the community well and whether removing it might either unintentionally create problems for now-conforming implementations or require considerable explanation that we might not get quite right. What we might do in an/the applicability statement to clarify preferences or offer guidance are separate matters; this note is addressed to 5321bis and its content only. In a way, that is a rather verbose way to say "if it isn't clearly broken, let's err on the side of not trying to fix it". It is also a way of saying "let's get this done rather than spending large amounts of time on aesthetic preferences, including document reorganization". Again, those are preferences and editor's guidelines that don't count if there is consensus, even if rough, announced by the co-chairs using the usual procedures. I note that the recent and pending changes to clean up source routes are examples of ones that had that level of consensus. Just my opinion. john From nobody Sun Dec 19 20:06: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 7EF713A0DD3 for ; Sun, 19 Dec 2021 20:06:16 -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 rwee6QTsr6n2 for ; Sun, 19 Dec 2021 20:06:11 -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 126993A0DD1 for ; Sun, 19 Dec 2021 20:06:09 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mz9w8-000LU5-Fx for emailcore@ietf.org; Sun, 19 Dec 2021 23:06:08 -0500 Date: Sun, 19 Dec 2021 23:06:02 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <069AE2C3D9DC4195DB34D183@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========546E96C4CA2B32A83807==========" 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] rfc5321bis draft appendix F.2 (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, 20 Dec 2021 04:06:17 -0000 --==========546E96C4CA2B32A83807========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. I'm still feeling a bit vague about how much material about source routes should be removed completely as distinct from more thoroughly deprecating them and consolidating discussion into the appendix (F.2 in draft-ietf-emailcore-rfc5321bis-07). As part of getting -08 together, I've eliminated (I hope) all discussion of them except for cross references to the appendix and consolidated material, including material from the former Appendix C, into that appendix. I have retained some informative material in that appendix to facilitate discussion and because it is more easily removed or rewritten than put back in if prematurely removed. The current working version of Appendix F.2 is attached. Comments and suggestions welcome. However, please don't spend time on formatting. I know it leaves something to be desired; either I or the RFC Editor will sort that out after we have final text. Plan and schedule FYI: draft-ietf-emailcore-rfc5321bis-08 is intended to incorporate changes discussed and generally agreed during the 9 December interim meeting. It includes some things that appeared to be settled during the interim but about which there has been further discussion so the changes should be considered tentative. It is unlikely that, except for an updated version of the attached, additional discussion since the interim will be reflected until -09. Assuming that there is at least some discussion of the attached material and that I hear from the co-chairs about the summary of changes I sent them, I expect to get -08 posted a bit before the end of the year. best, john --==========546E96C4CA2B32A83807========== Content-Type: text/plain; charset=utf-8; name="rfc5321bis-appendix-F2-20211219.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfc5321bis-appendix-F2-20211219.txt"; size=3313 F.2. Source Routing RFC 821 utilized the concept of explicit source routing to = get mail from one host to another via a series of relays. Source = routes could appear in either the or to show = the hosts through which mail would be routed to reach the = destination. The requirement to utilize source routes in regular mail = traffic was eliminated by the introduction of the domain name system "MX" = record by RFC 974 in early 1986 and the last significant = justification for them was eliminated by the introduction, in RFC 1123, of a = clear requirement that addresses following an "@" must all be = fully- qualified domain names. Issues involving local aliases for = mailboxes were addressed by the introduction of a separate = specification for mail submission [41]. Consequently, there are no remaining justifications for the use of source routes other than = support for very old SMTP clients. Even use in mail system debugging is = unlikely to work because almost all contemporary systems either ignore = or reject them. Historically, for relay purposes, the forward-path may have = been a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, = TWO, and THREE MUST be fully-qualified domain names. This form was = used to emphasize the distinction between an address and a route. = The mailbox (here, JOE@THREE) is an absolute address, and the = route is information about how to get there. The two concepts should = not be confused. SMTP servers SHOULD continue to accept source route syntax as specified in this appendix. If they do so, they SHOULD = ignore the routes and utilize only the target domain in the address. If = they do utilize the source route, the message MUST be sent to the = first domain shown in the address. In particular, a server MUST = NOT guess at shortcuts within the source route. SMTP clients SHOULD = NOT attempt to utilize explicit source routing. If source routes appear in mail received by an SMTP server = contrary to the requirements and recommendations in this = specification, RFC 821 and the text below should be consulted for the mechanisms = for constructing and updating the forward-path. A server that is = reached by means of a source route (e.g., its domain name appears = first in the list in the forward-path) MUST remove its domain name = from any forward-paths in which that domain name appears before = forwarding the message and MAY remove all other source routing information. = Any source route information in the reverse-path SHOULD be = removed by servers conforming to this specification. The following information is provided for historical = information only, so that the source route syntax and application can be understood if needed. Syntax: The original form of the production in Section 4.1.2 = was: Path =3D "<" [ A-d-l ":" ] Mailbox ">" A-d-l =3D At-domain *( "," At-domain ) At-domain =3D "@" Domain For example, suppose that a delivery service notification = must be sent for a message that arrived with: MAIL FROM:<@a.example,@b.example:user@d.example> The notification message MUST be sent using: RCPT TO: --==========546E96C4CA2B32A83807==========-- From nobody Mon Dec 20 01:50:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7763A0796 for ; Mon, 20 Dec 2021 01:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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_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=W3e1TKUO; dkim=pass (1152-bit key) header.d=tana.it header.b=Ac8PrZEn 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 1KC_DokGGi2d for ; Mon, 20 Dec 2021 01:50:05 -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 419223A079D for ; Mon, 20 Dec 2021 01:50:04 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1639993495; bh=GbRtSxnA9IFo4cIOvQbmc/pqm0BH2j/hZaJ89y5Vkbs=; h=Subject:To:References:From:Date:In-Reply-To; b=W3e1TKUOH5F3ZGlqnLPGq/iGAWE+G2G/zcMWoGESTO3gbRgRkDTG0tkep3SRo6Bxa q2sK704p2MUZs02Czp1BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1639993495; bh=GbRtSxnA9IFo4cIOvQbmc/pqm0BH2j/hZaJ89y5Vkbs=; h=To:References:From:Date:In-Reply-To; b=Ac8PrZEnW+c3sUFIxvfvW3XrYsjnAcHaSyeZzpFB1e7HhS+wyiigB6kJLACCsV7PA eNUEPPwiazn6ynlH3n7QH1GpsiPVxjLF0Fg9uD/NsKSESHLnHFuKj1IfIGm1/hZPD0 DPK1ShYxG+KX2GrjbQxCKO4XK+GK1rp8ggTfIwN9t7HYY8SVr280sJF/Vk2j/ 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 00000000005DC0DD.0000000061C05097.00001835; Mon, 20 Dec 2021 10:44:55 +0100 To: dcrocker@bbiw.net, emailcore@ietf.org References: <52834ec3-0fd2-c1e0-2d0d-2112dcd4f179@dcrocker.net> <51640ce4-974e-c461-ca2b-d6fabff813a6@tana.it> <19c20aa5-70af-d223-702e-d6838c95c36d@dcrocker.net> From: Alessandro Vesely Message-ID: <11ded34d-d800-1397-0da6-795a6add56fd@tana.it> Date: Mon, 20 Dec 2021 10:44:53 +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: <19c20aa5-70af-d223-702e-d6838c95c36d@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 20 Dec 2021 09:50:12 -0000 On Sat 18/Dec/2021 17:19:50 +0100 Dave Crocker wrote: > On 12/16/2021 9:40 AM, Alessandro Vesely wrote: >> On Thu 16/Dec/2021 16:20:52 +0100 Dave Crocker wrote: >>> On 12/16/2021 4:11 AM, Alessandro Vesely wrote: >>>> On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: > > [...] > > My own inclination, at this point, is to move details about domain name testing > to an applicability statement, or the like, and to keep it out of the protocol > specification.  This allows a clean protocol doc to be applied to different > environments that have different operational requirements and constraints. +1 to move details to the A/S. >>>>> What your effort, here, does is to bring back 'resolvability', which I >>>>> assume is what you really mean by 'validity'. >>>> >>>> My intention was the opposite.  By replacing 'resolvability' (and matching >>>> IP) with an abstract 'validity' the semantic remains open. >>> >>> A specification that has an 'open' semantic is not specifying anything a >>> normative protocol detail that is meaningful.  (literally) >> >> Uh... I beg your pardon, perhaps I should have said an open mechanism. The >> semantic meaning is that the EHLO argument had better be good because the >> server will check it. > > And my point is that the semantic for 'good' needs to be precisely stated > and operationally meaningful. How can we square stating that point precisely and moving details to the A/S? IMHO, SMTP has to be a completely stated, self standing protocol even without the A/S which specifies the details. OTOH, the very meaning of good can even evolve with time. Best Ale -- From nobody Fri Dec 31 11:45:24 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3C23A0D16; Fri, 31 Dec 2021 11:45:21 -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.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <164097992107.31560.12624361935662902651@ietfa.amsl.com> Date: Fri, 31 Dec 2021 11:45:21 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-08.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2021 19:45:22 -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-08.txt Pages : 123 Date : 2021-12-31 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Dec 31 12:01: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 1A7D33A0D50 for ; Fri, 31 Dec 2021 12:01:57 -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 3rDtwgRsjjM7 for ; Fri, 31 Dec 2021 12:01: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 0CF723A0D53 for ; Fri, 31 Dec 2021 12:01:48 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n3O5y-00016P-8D for emailcore@ietf.org; Fri, 31 Dec 2021 15:01:46 -0500 Date: Fri, 31 Dec 2021 15:01:40 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-08 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, 31 Dec 2021 20:01:57 -0000 EMAILCORE WG participants, As promised, I have just posted draft-ietf-emailcore-rfc5321bis-08. With the exception of an attempt to consolidate and clarify the discussion and "domain name" and their usage, changes here reflect discussion and agreement during the December 9 interim that have not been reopened (and apparently left unresolved) on the mailing list. See Appendix H.3.12 for details. In the process of doing the revision, I've discovered a few small additional possible issues and done some rewriting, as discussed below. I have not added them to Appendix G because they may be trivial and not worth fixing. If people feel as if they are issues, open a ticket and I'll pick them up in Appendix G in -09. They are: (1) This is mostly just a heads-up for people suggesting new text, but "host name" (with "primary" in front of, whatever that means, is [still] defined in Section 2.3.5 as "a domain name that resolves to an address RR". As I have understood it, that means no labels with CNAME records and no labels with only MX and no A RRs. We should be careful about accidentally introducing the use of "host" or "host name" elsewhere. Presumably, if there were DNS records of example.com. IN A 1.2.3.4 example2.com. IN A 1.2.3.4 and example.net. IN A 1.2.3.4 (rather than using CNAMEs) one could talk about that host as having one of those names as the "primary host name", but I can find no support in RFC 1034 or any of its successors for that. Or, if we means that restriction to address RRs to apply only to "primary host names" (by some definition that does not appear to be in 5321bis or referenced from it), does that usage require clarification? If it is relevant, note that RFC 1034 talks about "hosts" frequently but in ways that I believe always refers to things with addresses and does not define "host name". It does use the term "host name" but, AFAICT, only for things that could have been defined as hosts in the then-current HOSTS.TXT spec (RFCs 952 and 953), again implying things that have addresses with no indirection, and in the context of the preferred syntax (Section 3.5, which affects their syntax, not their definition). Section 5.2.1 talks specifically about "translating between host names and addresses" but nowhere does there appear to be text implying mapping between a host name and anything else. There is more, but you see the point. Section 3.3 of RFC 1034 also rather specifically discusses the syntax of mailbox naming. And 1034 uses "primary" in the context of names only to equate "primary name" with "canonical name" and in opposition to "alias" in the discussion in Section 3.6.2. I have not checked the host table specs. It is entirely possible that they talk about a "primary name" or "primary host name" to distinguish the first name on the line from aliases to its right, but, if we need to depend on unreferenced text from those specs in 2022, we are in serious trouble. RFC 1123 does not appear to change any of the above. However, Section 2.2 says "Host domain names MUST be translated to IP addresses..." which reinforces the above. And RFC 8499 identifies (but does not fix) the confusion, explaining that "host name" can also refer to the preferred name syntax (or not) or the leftmost label in an FQDN. And the only context in which is uses "primary" is in reference to an authoritative server. In other words, 8499 does not help. Neither RFC 2821 nor 5321 update 1034 and I don't see anything in what we have discussed that would require it, but we should be quite careful about tampering that things that might affect that text. Conclusion: it is not clear what information or restrictions "primary host name" provides that "host name" does not. Perhaps we should have dropped "primary" in RFC 2821 or 5321. At this point, while the text might be more clear with it, probably fear of making seemingly trivial changes that might increase confusion or cause unintended consequences argue against making a change... and I'm kicking myself for the time wasted doing the research. Again, if you disagree, say something and open a ticket. (2) Section 2.3.11 says "address normally consists of user and domain specifications". Given other things we have tightened up and the submission server cases, "normally" may be a source of confusion. Should it be dropped or the phrase changed to "except in the special case of 'postmaster' (Section 2.3.5) an address consists of user and domain specifications..." ? (3) "Domain" is defined in 4.1.2 as Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Section 2.3.5 clearly says "one or more components" and then goes on to say "This makes the requirement, described in more detail below, that only fully-qualified domain names appear in SMTP transactions on the public Internet, particularly important where top-level domains are involved." but does not spell out any issues with those names -- the sentence was apparently intended to avoid a historical problem in which single-label FQDNs have been confused with abbreviated names (which 5321bis no longer addresses). They have also, IIR, caused considerable discussion within ICANN as to whether they should be permitted in the root. However, 2.3.5 also said "Local nicknames or unqualified names MUST NOT be used", which either prohibited single-label FQDNs or contradicts other text in the section. That sentence has been removed from -08. Should something further be said about this? That sentence put back in but "unqualified names" dropped from it? FWIW, my current guess is that the answer is "yes, more is needed" but in the A/S, not 5321bis. (4) While Section 5.1 has been fairly significantly overhauled, it may still be confusing and may need more work. It appears to me as if there was an attempt to distinguish between an SMTP sender /client acting as a relay and something else, but the only odd case I can identify would arise with an SMTP server that identifies itself in an MX record for the original mailbox domain and then decides to process the message by some non-SMTP mechanism (e.g., forwarding direct by LMTP or some other means) or to start rewriting addresses. If that is the issue, it isn't really "Locating the Target Host" (the title of 5.1) in the usual sense and the relevant text should probably be somewhere else. As you have probably inferred from the above, I strongly suggest careful reading of the new (-08) versions of Section 2.3.5 and 5.1. Happy New Year! john