From nobody Sat Oct 3 16:49:44 2020 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 40C2F3A09D7 for ; Sat, 3 Oct 2020 16:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s7G9RxrORx4m for ; Sat, 3 Oct 2020 16:49:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 236D13A09D6 for ; Sat, 3 Oct 2020 16:49:41 -0700 (PDT) Received: from [169.254.4.146] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 3 Oct 2020 16:49:40 -0700 From: "Randall Gellens" To: "John Levine" Cc: emailcore@ietf.org, jgh@wizmail.org Date: Sat, 03 Oct 2020 16:49:40 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> In-Reply-To: <20200928204857.A46B222A27E5@ary.qy> References: <20200928204857.A46B222A27E5@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] EHLO domain validation requirement in RFC 5321 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 23:49:42 -0000 On 28 Sep 2020, at 13:48, John Levine wrote: > In article <0f13f954-ab6b-e60b-8f12-6a9492d3a325@wizmail.org> you > write: >> On 28/09/2020 18:56, Alessandro Vesely wrote: >>> The wording in Section 4.1.4 needs to be changed so as to >>> distinguish >>> submission[*] from server to server relaying.  As for the latter, >>> there >>> seems to be consensus on "SHOULD NOT": >> >> Side issue: should the standard point out that a local MTA >> transmitting >> to a "smarthost MTA" counts, at least in some senses, as submission? > > Take a look at RFC 6409 which I don't think we're planning to update. > > Its section 3 describes the differences between submission and SMTP > relay. If the client is authenticated somehow (SMTP AUTH or known > local IP range) that sure sounds like submission to me. > > There's also other criteria, submission usually cleans up the message > and adds missing headers, and allows relay to non-local addresses. The stuff about cleaning up messages and adding missing headers was based on the environment in the late '90s, when email clients tended to be awful and sites used sendmail to add or replace Date and other header fields. The earliest impetus for separating submission and relay was to stop sendmail "fixing" messages that weren't submission. Of course, once email became popular, authenticating submission and prohibiting receipt of non-local messages became crucial. I don't know that cleaning up submitted messages is still done much. From nobody Sat Oct 3 17:59:53 2020 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 326203A0A56 for ; Sat, 3 Oct 2020 17:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=xX7Ng3QX; dkim=pass (2048-bit key) header.d=taugh.com header.b=jzJYPW6j 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 5ieGXdUHkCwF for ; Sat, 3 Oct 2020 17:59:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274923A0A55 for ; Sat, 3 Oct 2020 17:59:48 -0700 (PDT) Received: (qmail 52705 invoked from network); 4 Oct 2020 00:59:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=cddf.5f791e83.k2010; i=johnl-iecc.com@submit.iecc.com; bh=ShgTzDeSTiw3v2d5v42+kdejdTQbCPC32PDMHEez/W0=; b=xX7Ng3QXUjWnA3Tj3bPys6ofmuy6f+9vGzNzO3BQi14JE4LmXC2n/NTjA98W/I1z/TtOVpJqB6Jm74/5l/7iX7uEErtct2tcJCr/6GbrCzl+grBzc+thuaZyOCMfYvRC5LusSkV0vGqd0/5fmSDLWWpHVR5DngExT9O7TJaDSbAYwap/KYV+wE/N14XIVy1mj0dJ06Cc/ek9M+CwCPlL3TxIgZN8IhrbTCXwkIj2KnBZg/EfFexv1Go0JS14BkKhIv19oweyFsiwh+PsW7EA7rpGyV5VdRG0uZzOpuWiWenxDh/kyK74D0ibYA7xHmzh5eDvYWVPK5v8ejatGy+2rw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=cddf.5f791e83.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=ShgTzDeSTiw3v2d5v42+kdejdTQbCPC32PDMHEez/W0=; b=jzJYPW6jXO+aZy4IDuUTIXprSeq8bh4Uxipq5DLmk7Wc1YI1zXEin9s5MCNHx1fP+uFwaADbrzGuFx8tPVUAeOb6fCjIIaYLiGpogYmeB8827LZRd/gJXX8JKotVUysqq1x8tVfgunXSJMZ7+0Th8i3DfiFPU76mG+Q4JCO/bNPg5n6LI94mOzIiisd+JCos8kVlXbnfzx1dRsH5I/krJ0vt7DUHD+FjtUDtfJN8x8Ic5NVzyrQ1b9KZwelndig8rmTyxEUqy5gibbc/Zja0pbjGo3DrAdCbYrNOkIadkQFgJVSx5OV/Y9WzCXI+4t5MiK+Rku8qpln609/+h3P9ug== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 04 Oct 2020 00:59:47 -0000 Date: 3 Oct 2020 20:59:47 -0400 Message-ID: From: "John R Levine" To: "Randall Gellens" Cc: emailcore@ietf.org In-Reply-To: <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] EHLO domain validation requirement in RFC 5321 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 00:59:51 -0000 On Sat, 3 Oct 2020, Randall Gellens wrote: >> There's also other criteria, submission usually cleans up the message >> and adds missing headers, and allows relay to non-local addresses. > > The stuff about cleaning up messages and adding missing headers was > based on the environment in the late '90s, when email clients tended to > be awful and sites used sendmail to add or replace Date and other header > fields. ... > I don't know that cleaning up submitted messages is still done much. It definitely is. Look for example at the "cleanup" daemon in Postfix. You are right that many desktop or phone MUAs do a better job of composing mail than they used to, but that just means that the cleanup process should leave headers alone if they is already OK. But there's plenty of mail sent by primitive MUAs like my printer when it runs out of paper, which needs a lot of cleanup. There's plenty of cleanup that is overenthusiastic, e.g., Office 365 will always put in its own Message-ID on submitted, replacing any that's already there which is a pain. 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 Oct 3 20:04:26 2020 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 21FB53A0AC7 for ; Sat, 3 Oct 2020 20:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.995, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcnGePx0fIGy for ; Sat, 3 Oct 2020 20:04:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AC1F03A0AC6 for ; Sat, 3 Oct 2020 20:04:21 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 3 Oct 2020 20:04:21 -0700 From: "Randall Gellens" To: "John R Levine" Cc: emailcore@ietf.org Date: Sat, 03 Oct 2020 20:04:20 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <4600F86D-94E1-4CBA-BBBD-FA2B373C78EE@randy.pensive.org> In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] EHLO domain validation requirement in RFC 5321 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 03:04:26 -0000 Thanks, I hadn't realized that (my printer just beeps and causes the Mac print utility to display up a caution symbol). --Randall On 3 Oct 2020, at 17:59, John R Levine wrote: > On Sat, 3 Oct 2020, Randall Gellens wrote: >>> There's also other criteria, submission usually cleans up the >>> message >>> and adds missing headers, and allows relay to non-local addresses. >> >> The stuff about cleaning up messages and adding missing headers was >> based on the environment in the late '90s, when email clients tended >> to be awful and sites used sendmail to add or replace Date and other >> header fields. ... >> I don't know that cleaning up submitted messages is still done >> much. > > It definitely is. Look for example at the "cleanup" daemon in > Postfix. > > You are right that many desktop or phone MUAs do a better job of > composing mail than they used to, but that just means that the cleanup > process should leave headers alone if they is already OK. But there's > plenty of mail sent by primitive MUAs like my printer when it runs out > of paper, which needs a lot of cleanup. > > There's plenty of cleanup that is overenthusiastic, e.g., Office 365 > will always put in its own Message-ID on submitted, replacing any > that's already there which is a pain. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > https://jl.ly From nobody Sun Oct 4 10:00:21 2020 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 0C4D03A08C5 for ; Sun, 4 Oct 2020 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgkAtXQ3iuhT for ; Sun, 4 Oct 2020 10:00:19 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF76E3A08C1 for ; Sun, 4 Oct 2020 10:00:18 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kP7M0-000D8i-CE; Sun, 04 Oct 2020 12:59:20 -0400 Date: Sun, 04 Oct 2020 12:59:00 -0400 From: John C Klensin To: John R Levine , Randall Gellens cc: emailcore@ietf.org Message-ID: <49B191CD3053A15C9AD7F973@JcK-HP5> In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> 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 Archived-At: Subject: Re: [Emailcore] EHLO domain validation requirement in RFC 5321 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 17:00:20 -0000 --On Saturday, 03 October, 2020 20:59 -0400 John R Levine wrote: >... > You are right that many desktop or phone MUAs do a better job > of composing mail than they used to, but that just means that > the cleanup process should leave headers alone if they is > already OK. But there's plenty of mail sent by primitive MUAs > like my printer when it runs out of paper, which needs a lot > of cleanup. But that is an example of an imbedded application using email as a notification mechanism. To the extent to which we really mean "agent for a human" when we say "MUA", there isn't one in there. Perhaps we should be talking about "MGA" ("mail gremlin agent"). And, without knowing anything about your printer or its manufacturer, I'd think the odds of its email interface being "fixed" any time soon, no matter what the IETF says, are slim to none. Randy may disagree, but this is one of the key reasons why I thought that strengthening the "Submission server" distinction was important although, in some ways, it just strengthens the language of 2821/5321 about what was permitted to escape onto the public Internet. And, for that reason, it isn't clear that this discussion, or at least this part of it, justifies any change in 5321bis. > There's plenty of cleanup that is overenthusiastic, e.g., > Office 365 will always put in its own Message-ID on submitted, > replacing any that's already there which is a pain. And, depending on the role Office 365 is playing when it does that, it isn't "overenthusiastic". It is, instead, a flat-out violation of the standard with nasty interoperability implications under some circumstances. Not the only one, unfortunately. And, were we to put in any language that authorized it (not that anyone has suggested doing so), it would take us a step closer to saying "the real email standards are whatever the handful of largest mail service providers say they are, everyone else needs to conform if they want their mail to reliability reach people, and the IETF should get out of the business lest our work become an expensive and time-consuming exercise in futility". best, john From nobody Sun Oct 4 10:52:56 2020 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 B07133A09B0 for ; Sun, 4 Oct 2020 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=BntPwVaq; dkim=pass (2048-bit key) header.d=taugh.com header.b=Fcqde0Vo 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 uGlt83jE3p_m for ; Sun, 4 Oct 2020 10:52:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC913A0966 for ; Sun, 4 Oct 2020 10:52:45 -0700 (PDT) Received: (qmail 60582 invoked from network); 4 Oct 2020 17:52:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=eca4.5f7a0beb.k2010; i=johnl-iecc.com@submit.iecc.com; bh=3d+cFXeXPsysa3FK4jAwEBD8BWWcFlXPA7BrJJnMLOE=; b=BntPwVaqbXfMG3ML2BNZJJWqcYMUlt9mCz+tbWHM4iIFXiXLIYE4bM+Evhijr1usHeddOqAyyG+XqZrT5WnUHmTKL9W29E+sGrVILnv4hD/nv+tesmyroA0H2seZsXmWjG34/h/1M4/JuLis4ijUKBTts5jjl12IEKFY6Y8zA/451xnpsFInfmtTgwqARiJW0aVOxZjL1rB5aUC1Zidj73zfvl6X8KSugaFpr6LRSBznhkv/T5+CCK7Mt6cRSJJVlwP68nkhHisKs10iqwsM42ihnNvOU7K1tfVpLTWk7eWt7yWDi98N7xh7KOEy6T95RX89vURF4SET2m6pr4jG9g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=eca4.5f7a0beb.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=3d+cFXeXPsysa3FK4jAwEBD8BWWcFlXPA7BrJJnMLOE=; b=Fcqde0VoznlTMeKsAseg4+2gAFZ5RAdG9nXzppIG+gaE33GmMd9qEfocUlFe5DGwa0d8DFwE2gNvgGgekDg0iZ+sIYkUNIYh0Ntsl0hKTZd6jYAT9+2SRYSffKm+/as7ZxByzeHWJPJKOI1d2p5HNvL4dhgjolS75X+gPFcIzUIIcOPMu/bXK57h5Xod4e2SeBUnEXOMVbrKV5nvr5dJep7jgFPoxRjznZgsn4NMoFfyXn1dMoI1VpoamripSfqr+HN3qqrBAro2i3LXGjVF87Up4dYL9/fW7if6KVLkeagsOCSVrb6rTM+d9AqtsthgCvSKgeASYOGCImBAP7unqA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 04 Oct 2020 17:52:43 -0000 Date: 4 Oct 2020 13:52:43 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" , "Randall Gellens" Cc: emailcore@ietf.org In-Reply-To: <49B191CD3053A15C9AD7F973@JcK-HP5> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 17:52:55 -0000 I'm not entirely sure what your point is but I don't think we disagree. Message cleanup on submission remains useful, but once that happens, SMTP relay should only add trace headers and otherwise not mess with the message. (Not sure what the formal status of 8/7 MIME downcoding is but I doubt it's very common any more other than by accidental inertia.) I also agree that it would be useful to emphasize that submission is different and it's not what this document is about. The O365 message ID's were replaced during authenticated port 587 submission so it was annoying but not obviously wrong. On the other hand, the syntax of the Received: headers it adds is totally wrong. R's, John > --On Saturday, 03 October, 2020 20:59 -0400 John R Levine > wrote: >> You are right that many desktop or phone MUAs do a better job >> of composing mail than they used to, but that just means that >> the cleanup process should leave headers alone if they is >> already OK. But there's plenty of mail sent by primitive MUAs >> like my printer when it runs out of paper, which needs a lot >> of cleanup. > > But that is an example of an imbedded application using email as > a notification mechanism. To the extent to which we really mean > "agent for a human" when we say "MUA", there isn't one in there. > Perhaps we should be talking about "MGA" ("mail gremlin agent"). > And, without knowing anything about your printer or its > manufacturer, I'd think the odds of its email interface being > "fixed" any time soon, no matter what the IETF says, are slim to > none. > > Randy may disagree, but this is one of the key reasons why I > thought that strengthening the "Submission server" distinction > was important although, in some ways, it just strengthens the > language of 2821/5321 about what was permitted to escape onto > the public Internet. And, for that reason, it isn't clear that > this discussion, or at least this part of it, justifies any > change in 5321bis. > >> There's plenty of cleanup that is overenthusiastic, e.g., >> Office 365 will always put in its own Message-ID on submitted, >> replacing any that's already there which is a pain. > > And, depending on the role Office 365 is playing when it does > that, it isn't "overenthusiastic". It is, instead, a flat-out > violation of the standard with nasty interoperability > implications under some circumstances. Not the only one, > unfortunately. And, were we to put in any language that > authorized it (not that anyone has suggested doing so), it would > take us a step closer to saying "the real email standards are > whatever the handful of largest mail service providers say they > are, everyone else needs to conform if they want their mail to > reliability reach people, and the IETF should get out of the > business lest our work become an expensive and time-consuming > exercise in futility". > > best, > john > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Oct 4 12:16:15 2020 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 036EC3A09C3 for ; Sun, 4 Oct 2020 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Gtf5WtLKq3Oz for ; Sun, 4 Oct 2020 12:16:12 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F63A09C1 for ; Sun, 4 Oct 2020 12:16:12 -0700 (PDT) Received: from [169.254.152.43] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 4 Oct 2020 12:16:11 -0700 From: "Randall Gellens" To: "John R Levine" Cc: "John C Klensin" , emailcore@ietf.org Date: Sun, 04 Oct 2020 12:16:11 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 19:16:14 -0000 I agree with both of you. I agree that it would be helpful to say very clearly that message alteration (aside from Received header fields) is for message submission only. There's an argument to be made for combining the SMTP and Submission documents, but I think the cost outweighs the benefit. --Randall On 4 Oct 2020, at 10:52, John R Levine wrote: > I'm not entirely sure what your point is but I don't think we > disagree. > > Message cleanup on submission remains useful, but once that happens, > SMTP relay should only add trace headers and otherwise not mess with > the message. (Not sure what the formal status of 8/7 MIME downcoding > is but I doubt it's very common any more other than by accidental > inertia.) > > I also agree that it would be useful to emphasize that submission is > different and it's not what this document is about. > > The O365 message ID's were replaced during authenticated port 587 > submission so it was annoying but not obviously wrong. On the other > hand, the syntax of the Received: headers it adds is totally wrong. > > R's, > John > > >> --On Saturday, 03 October, 2020 20:59 -0400 John R Levine >> wrote: >>> You are right that many desktop or phone MUAs do a better job >>> of composing mail than they used to, but that just means that >>> the cleanup process should leave headers alone if they is >>> already OK. But there's plenty of mail sent by primitive MUAs >>> like my printer when it runs out of paper, which needs a lot >>> of cleanup. >> >> But that is an example of an imbedded application using email as >> a notification mechanism. To the extent to which we really mean >> "agent for a human" when we say "MUA", there isn't one in there. >> Perhaps we should be talking about "MGA" ("mail gremlin agent"). >> And, without knowing anything about your printer or its >> manufacturer, I'd think the odds of its email interface being >> "fixed" any time soon, no matter what the IETF says, are slim to >> none. >> >> Randy may disagree, but this is one of the key reasons why I >> thought that strengthening the "Submission server" distinction >> was important although, in some ways, it just strengthens the >> language of 2821/5321 about what was permitted to escape onto >> the public Internet. And, for that reason, it isn't clear that >> this discussion, or at least this part of it, justifies any >> change in 5321bis. >> >>> There's plenty of cleanup that is overenthusiastic, e.g., >>> Office 365 will always put in its own Message-ID on submitted, >>> replacing any that's already there which is a pain. >> >> And, depending on the role Office 365 is playing when it does >> that, it isn't "overenthusiastic". It is, instead, a flat-out >> violation of the standard with nasty interoperability >> implications under some circumstances. Not the only one, >> unfortunately. And, were we to put in any language that >> authorized it (not that anyone has suggested doing so), it would >> take us a step closer to saying "the real email standards are >> whatever the handful of largest mail service providers say they >> are, everyone else needs to conform if they want their mail to >> reliability reach people, and the IETF should get out of the >> business lest our work become an expensive and time-consuming >> exercise in futility". >> >> best, >> john >> >> > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > https://jl.ly From nobody Sun Oct 4 12:34:05 2020 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 BD0193A09C0 for ; Sun, 4 Oct 2020 12:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 hKjNoyYYCiBJ for ; Sun, 4 Oct 2020 12:34:02 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 CC7AE3A09C9 for ; Sun, 4 Oct 2020 12:34:02 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 094JbDrP018768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 4 Oct 2020 12:37:13 -0700 Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 4 Oct 2020 12:33:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 19:34:05 -0000 On 10/4/2020 12:16 PM, Randall Gellens wrote: > I agree that it would be helpful to say very clearly that message > alteration (aside from Received header fields) is for message submission > only. fwiw... https://tools.ietf.org/html/rfc5598 > 4.3.1. Mail Submission Agent (MSA) > > A Mail Submission Agent (MSA) accepts the message submitted by the > aMUA and enforces the policies of the hosting ADMD and the > requirements of Internet standards. An MSA represents an unusual > functional dichotomy. It represents the interests of the Author > (aMUA) during message posting, to facilitate posting success; it also > represents the interests of the MHS. In the architecture, these > responsibilities are modeled, as shown in Figure 5, by dividing the > MSA into two sub-components, aMSA and hMSA, respectively. Transfer > of responsibility for a single message, from an Author's environment > to the MHS, is called "posting". In Figure 5, it is marked as the > (S) transition, within the MSA. > > The hMSA takes transit responsibility for a message that conforms to > the relevant Internet standards and to local site policies. It > rejects messages that are not in conformance. The MSA performs final > message preparation for submission and effects the transfer of > responsibility to the MHS, via the hMSA. The amount of preparation > depends upon the local implementations. Examples of aMSA tasks > include adding header fields, such as Date: and Message-ID:, and > modifying portions of the message from local notations to Internet > standards, such as expanding an address to its formal IMF > representation. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 4 14:50:07 2020 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 703F43A0A34 for ; Sun, 4 Oct 2020 14:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNcFFpHj5oVW for ; Sun, 4 Oct 2020 14:50:04 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596513A0A2E for ; Sun, 4 Oct 2020 14:50:04 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kPBsP-000DgD-R5; Sun, 04 Oct 2020 17:49:05 -0400 Date: Sun, 04 Oct 2020 17:48:45 -0400 From: John C Klensin To: Randall Gellens , John R Levine cc: emailcore@ietf.org Message-ID: <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> 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 Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 21:50:05 -0000 --On Sunday, 04 October, 2020 12:16 -0700 Randall Gellens wrote: > I agree with both of you. I agree that it would be helpful to > say very clearly that message alteration (aside from Received > header fields) is for message submission only. Yes. And John and I are in agreement about that, whether most of the rest of my earlier message is relevant or not. The part that is, and that I hope all of us are in agreement about, is that saying much more on this subject is potential material for the A/S, rather than a 5321bis topic, except as noted below. > There's an argument to be made for combining the SMTP and > Submission documents, but I think the cost outweighs the > benefit. Well, at this stage in the game, I think even trying would create more confusion. What I think would be reasonable to do, especially since 6409 is at Internet Standard, would be to look at the text of 5321 that circles around the submission issue and see if it could be reasonably replaced by a sentence or short paragraph that explains that those issues are covered in 6409 (and maybe its potential successors). Someone to do the research as to what might be removed and suggested text to replace it would be appreciated. john From nobody Sun Oct 4 14:54:18 2020 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 A4C0C3A0A35 for ; Sun, 4 Oct 2020 14:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 zx3Zgcjjwn7d for ; Sun, 4 Oct 2020 14:54:15 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 A55AB3A0A34 for ; Sun, 4 Oct 2020 14:54:15 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 094LvQsl005371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Oct 2020 14:57:26 -0700 Reply-To: dcrocker@bbiw.net To: Randall Gellens Cc: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> Date: Sun, 4 Oct 2020 14:54:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 21:54:17 -0000 On 10/4/2020 12:16 PM, Randall Gellens wrote: > There's an argument to be made for combining the SMTP and Submission > documents, but I think the cost outweighs the benefit. There's a stronger argument against. Submission and relaying are fundamentally different in role and authority. At a minimum, submissions agents have local authority to mess with the message in way that would be entirely inappropriate for a relay. That they share protocol constructs is mostly distracting from the major differences in their architectural role. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 4 15:04:28 2020 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 4AE9E3A0A40 for ; Sun, 4 Oct 2020 15:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WJxPA0cGcHiP for ; Sun, 4 Oct 2020 15:04:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8A00F3A0A3F for ; Sun, 4 Oct 2020 15:04:25 -0700 (PDT) Received: from [169.254.192.81] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 4 Oct 2020 15:04:25 -0700 From: "Randall Gellens" To: "John C Klensin" Cc: "John R Levine" , emailcore@ietf.org Date: Sun, 04 Oct 2020 15:04:24 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 22:04:27 -0000 On 4 Oct 2020, at 14:48, John C Klensin wrote: > --On Sunday, 04 October, 2020 12:16 -0700 Randall Gellens > wrote: > >> I agree with both of you. I agree that it would be helpful to >> say very clearly that message alteration (aside from Received >> header fields) is for message submission only. > > Yes. And John and I are in agreement about that, whether most > of the rest of my earlier message is relevant or not. The part > that is, and that I hope all of us are in agreement about, is > that saying much more on this subject is potential material for > the A/S, rather than a 5321bis topic, except as noted below. > >> There's an argument to be made for combining the SMTP and >> Submission documents, but I think the cost outweighs the >> benefit. > > Well, at this stage in the game, I think even trying would > create more confusion. What I think would be reasonable to do, > especially since 6409 is at Internet Standard, would be to look > at the text of 5321 that circles around the submission issue and > see if it could be reasonably replaced by a sentence or short > paragraph that explains that those issues are covered in 6409 > (and maybe its potential successors). I agree. > Someone to do the > research as to what might be removed and suggested text to > replace it would be appreciated. I'm not in a position to volunteer much time right now (racing to finish a large project) but if someone is still needed in a month or so, let me know. --Randall From nobody Sun Oct 4 16:53:53 2020 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 BB5AF3A0AA4 for ; Sun, 4 Oct 2020 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2pumOsRZOr7R for ; Sun, 4 Oct 2020 16:53:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BA81C3A0AA3 for ; Sun, 4 Oct 2020 16:53:50 -0700 (PDT) Received: from [169.254.192.81] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 4 Oct 2020 16:53:50 -0700 From: "Randall Gellens" To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Sun, 04 Oct 2020 16:53:49 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 04 Oct 2020 23:53:52 -0000 On 4 Oct 2020, at 14:54, Dave Crocker wrote: > On 10/4/2020 12:16 PM, Randall Gellens wrote: >> There's an argument to be made for combining the SMTP and Submission >> documents, but I think the cost outweighs the benefit. > > > There's a stronger argument against. > > Submission and relaying are fundamentally different in role and > authority. At a minimum, submissions agents have local authority to > mess with the message in way that would be entirely inappropriate for > a relay. > > That they share protocol constructs is mostly distracting from the > major differences in their architectural role. Sure, but our documents tend to be protocol-focused, not architecture-focused. If we were doing email from scratch (ha!), we'd probably have one document that describes the basic protocol and the roles of submission client, submission server, relay client, and relay server. At any rate, I'm not proposing that we do it, so it's more of a bar chat or interminable conference hotel elevator ride at dinnertime debate. --Randall From nobody Sun Oct 4 18:39:51 2020 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 A74333A0AFE for ; Sun, 4 Oct 2020 18:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 k3l_85347tGP for ; Sun, 4 Oct 2020 18:39:49 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 976353A0AFD for ; Sun, 4 Oct 2020 18:39:49 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0951h0QC007719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Oct 2020 18:43:00 -0700 To: Randall Gellens Cc: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 4 Oct 2020 18:39:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 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] submission cleanup, not EHLO domain validation 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, 05 Oct 2020 01:39:51 -0000 On 10/4/2020 4:53 PM, Randall Gellens wrote: > Sure, but our documents tend to be protocol-focused, not > architecture-focused.  If we were doing email from scratch (ha!), we'd > probably have one document that describes the basic protocol and the > roles of submission client, submission server, relay client, and relay > server. In fact there are quite a few architecture documents, independent of the protocol components. The order of development varies, of course. Obvious example: RFC 5598. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 4 18:49:02 2020 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 0E5B33A0B03 for ; Sun, 4 Oct 2020 18:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.995, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq54fVd_pMyP for ; Sun, 4 Oct 2020 18:48:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 295283A0B02 for ; Sun, 4 Oct 2020 18:48:58 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 4 Oct 2020 18:48:57 -0700 From: "Randall Gellens" To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Sun, 04 Oct 2020 18:48:56 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <7B50A170-3322-40E4-ABCA-76C53FD6959F@randy.pensive.org> In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 05 Oct 2020 01:49:00 -0000 On 4 Oct 2020, at 18:39, Dave Crocker wrote: > On 10/4/2020 4:53 PM, Randall Gellens wrote: >> Sure, but our documents tend to be protocol-focused, not >> architecture-focused.  If we were doing email from scratch (ha!), >> we'd probably have one document that describes the basic protocol and >> the roles of submission client, submission server, relay client, and >> relay server. > > In fact there are quite a few architecture documents, independent of > the protocol components. The order of development varies, of course. > Obvious example: RFC 5598. I never doubted the existence of architectural documents. I'd wager that there are far more protocol RFCs than architecture. From nobody Tue Oct 6 04:10:55 2020 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 5962E3A11B6 for ; Tue, 6 Oct 2020 04:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 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, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=nYFo2J4r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H/RHkuAa 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 j7jyn-F0-6-D for ; Tue, 6 Oct 2020 04:10:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256193A0ED9 for ; Tue, 6 Oct 2020 04:10:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 66C9A5C0136 for ; Tue, 6 Oct 2020 07:10:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 06 Oct 2020 07:10:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=I Nxxy3ImNv4flhEauTnIS+3cXmtpAxFrjm2L4VlR4hU=; b=nYFo2J4rOW75tHKx3 87g+7BSklqEKi5s8RVqgY3rSVmANShjTP9ICmO9Ca9eePKmleUci1BlV5i8I9WBD v+uN4wL/HSjR1rErOJKTdEEacutdOqL3T+DwH+XalMUufCZQcq2gWWAqi9z/jpTP ckg22+WA1Zzm1gnqQNZum/BhR0JZRVUSukPOZOK+npDYW7uhCHcLXGqokuDQknJs j8xUt2m3xDKXePtfFBjuuH/LZOfYRlFORvABMs3YSJCjmit5jmNOF+pKiUwiPimw NviwH6HLo3rTTLQvnKhRrE6ao9pNh04B9xYTPamQkDhxDBrwHUNjNFgtZiewnyzO H6FLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=INxxy3ImNv4flhEauTnIS+3cXmtpAxFrjm2L4VlR4 hU=; b=H/RHkuAasZ2fwHDYFXqPqk+i3zqOiCGduB+lIifqn/2ud7cCbACsOs8ul zEvw7Cj4gndYlWK+n7SYADwUO12INDZrAW+15mw+IBmWUYOPnr4JtvdWPqtnFr+k yPK0HwvJ3ds6tgnHWZAdogJn03TcLwXTWkgreoKRbDDtfrjH91GeBTZNVA222pQp EMa1cxwWxJT90qHFUFnpBlEPNw8fFt42sljhRtH5jOrEXOQNEVHUE2abq08HVrZT iPTw9qjQJLIQ7S71RXN3J01guyeWL0N6l+zCnSGaOpd5gersUuf5J7b6Oh0R5jTy YG2FlcEpupUPybdY6ObnmOYcyQr7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeeggdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepjeekgffhudejge fffffgtddtffeuhfehhfekudeivdeludevtdefleekgfefgeejnecukfhppeefuddrgeel rddugedvrddujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: from [192.168.1.222] (host31-49-142-17.range31-49.btcentralplus.com [31.49.142.17]) by mail.messagingengine.com (Postfix) with ESMTPA id CDFD93064684 for ; Tue, 6 Oct 2020 07:10:50 -0400 (EDT) To: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> From: Alexey Melnikov Message-ID: Date: Tue, 6 Oct 2020 12:08:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <9cfb6dc9-c9ef-12ac-1c11-efc1c99cc05e@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 06 Oct 2020 11:10:54 -0000 Hi all, On 04/10/2020 22:54, Dave Crocker wrote: > On 10/4/2020 12:16 PM, Randall Gellens wrote: >> There's an argument to be made for combining the SMTP and Submission >> documents, but I think the cost outweighs the benefit. > > There's a stronger argument against. > > Submission and relaying are fundamentally different in role and > authority.  At a minimum, submissions agents have local authority to > mess with the message in way that would be entirely inappropriate for > a relay. I think based on this thread we will leave SMTP Submission and rfc5321bis as separate documents. Best Regards, Alexey From nobody Tue Oct 6 06:36:17 2020 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 161653A09BD; Tue, 6 Oct 2020 06:36:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <160199137004.11748.6110207622526713133@ietfa.amsl.com> Date: Tue, 06 Oct 2020 06:36:10 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-00.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: Tue, 06 Oct 2020 13:36:11 -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-00.txt Pages : 108 Date : 2020-10-06 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces the earlier version with the same title in RFC 5321. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emailcore-rfc5321bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 6 06:36:32 2020 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 00EC63A148D; Tue, 6 Oct 2020 06:36:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <160199138297.13169.16022394439041847504@ietfa.amsl.com> Date: Tue, 06 Oct 2020 06:36:22 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-as-00.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: Tue, 06 Oct 2020 13:36:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Applicability Statement for IETF Core Email Protocols Author : John C Klensin Filename : draft-ietf-emailcore-as-00.txt Pages : 6 Date : 2020-10-06 Abstract: Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emailcore-as-00 https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-as-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 6 07:47:57 2020 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 AA8E63A0A8C for ; Tue, 6 Oct 2020 07:47:55 -0700 (PDT) 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 mesQnxN2r0FK for ; Tue, 6 Oct 2020 07:47:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08AA3A0A87 for ; Tue, 6 Oct 2020 07:47:53 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kPoFq-000BB1-06 for emailcore@ietf.org; Tue, 06 Oct 2020 10:47:50 -0400 Date: Tue, 06 Oct 2020 10:47:43 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <191CF57E2BF6D19D8FE3B495@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis and draft-ietf-emailcore-as-00 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, 06 Oct 2020 14:47:56 -0000 Hi. Having seen no discussion on the WG list that seemed to argue for changing the plan laid out by the co-Chairs, I have posted draft-ietf-emailcore-rfc5321bis and draft-ietf-emailcore-as-00. In addition to the change of filename and other bits associated with turning it into a WG draft, the former contains (relative to draft-klensin-rfc5321bis-03) additions to Appendix G to reflect the ietf-smtp list discussion of quoted strings in addresses (mailbox local-parts) and some additional words about email insecurity and TLS to that section of the appendix. There are no substantive differences between draft-klensin-email-core-as-00 and draft-ietf-emailcore-as-00, just the change of date, filename, and associated details. Anyone interested (or even willing after offering your arm to be twisted) in becoming editor, or lead editor and pen-holder, for that document should approach the WG Chairs. john From nobody Tue Oct 6 10:28:04 2020 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 78F783A0E58; Tue, 6 Oct 2020 10:28:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <160200528245.32425.2250633164754152213@ietfa.amsl.com> Date: Tue, 06 Oct 2020 10:28:02 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-00.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: Tue, 06 Oct 2020 17:28:02 -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 : Internet Message Format Author : Peter W. Resnick Filename : draft-ietf-emailcore-rfc5322bis-00.txt Pages : 56 Date : 2020-10-06 Abstract: This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/ There is also an HTML version available at: https://www.ietf.org/id/draft-ietf-emailcore-rfc5322bis-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 6 12:49:27 2020 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 80C0C3A0E11; Tue, 6 Oct 2020 12:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 (1024-bit key) header.d=sonnection.nl 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 d_2uO5MXL5ba; Tue, 6 Oct 2020 12:49:24 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D59E3A0E0A; Tue, 6 Oct 2020 12:49:20 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 4C5Shs6xHPz2qF13; Tue, 6 Oct 2020 21:49:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx10.mailtransaction.com 4C5Shs6xHPz2qF13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1602013758; bh=XFCA2FS6H0dwpVh3PSsWOx3P8cnmuN7EPT98pcgfFw8=; h=Subject:To:From:Message-ID:Date:From; b=Pxu21IArC4cKa2dxVn98ZFr0/etP//0xj5KAkG331Le9m+bWZwgqH0RqnGCReMwpx VPyj8rejCrioirb+3tWAsT1GcS+xfm6+Ji6l6K0DRMZBHxymUu6DSBgdpOyEotIcZL dWZK6ax8Xs8o/ag3GDxGhPomWzkQBjeyXkHDQyR0= Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx24.mailtransaction.com (Postfix) with ESMTPS id 4C5Shs5g7Bz1tp3h; Tue, 6 Oct 2020 21:49:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 539454223AF; Tue, 6 Oct 2020 21:49:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id u7V9hFyxgr3A; Tue, 6 Oct 2020 21:49:17 +0200 (CEST) Received: from [192.168.40.49] (cat.sonnection.nl [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 3548F4223AD; Tue, 6 Oct 2020 21:49:17 +0200 (CEST) To: emailcore@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <160199137004.11748.6110207622526713133@ietfa.amsl.com> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: <3d2f4bc3-71b4-376b-9dab-34d2cb323de7@sonnection.nl> Date: Tue, 6 Oct 2020 21:49:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <160199137004.11748.6110207622526713133@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-00.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 19:49:27 -0000 Thanks John. Has someone already reserved the RFC numbers 9021 and 9022 for this work? :-) Or maybe even better: 8821 and 8822? /rolf On 06/10/2020 15:36, internet-drafts@ietf.org wrote: > 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-00.txt > Pages : 108 > Date : 2020-10-06 > > Abstract: > This document is a specification of the basic protocol for Internet > electronic mail transport. It consolidates, updates, and clarifies > several previous documents, making all or parts of most of them > obsolete. It covers the SMTP extension mechanisms and best practices > for the contemporary Internet, but does not provide details about > particular extensions. Although SMTP was designed as a mail > transport and delivery protocol, this specification also contains > information that is important to its use as a "mail submission" > protocol for "split-UA" (User Agent) mail reading systems and mobile > environments. This document replaces the earlier version with the > same title in RFC 5321. > [[CREF1: Note in Draft: Except for the last sentence, the above is > unchanged from 5321 and may need adjusting in the light of RFC 6409 > as an Internet Standard.]] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-emailcore-rfc5321bis-00 > https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Tue Oct 6 14:06:42 2020 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 D29B43A14E4 for ; Tue, 6 Oct 2020 14:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvVEaDsksP-b for ; Tue, 6 Oct 2020 14:06:39 -0700 (PDT) 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 61BA43A14E3 for ; Tue, 6 Oct 2020 14:06:39 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kPuAI-000BmH-M9; Tue, 06 Oct 2020 17:06:30 -0400 Date: Tue, 06 Oct 2020 17:06:24 -0400 From: John C Klensin To: "Rolf E. Sonneveld" cc: emailcore@ietf.org, rfc-editor@rfc-editor.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-00.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:06:41 -0000 Rolf, (copying RFC Editor) Certainly would be nice. If we can do this on the schedule I think the Co-chairs and ADs are anticipating, and the big block of numbers between 8820 and 8874 is not already taken, that would be very elegant. Either way, reserving the next number in sequence for the proposed A/S would also be helpful. john --On Tuesday, October 6, 2020 21:49 +0200 "Rolf E. Sonneveld" wrote: > Thanks John. > > Has someone already reserved the RFC numbers 9021 and 9022 for > this work? :-) Or maybe even better: 8821 and 8822? > > /rolf > > On 06/10/2020 15:36, internet-drafts@ietf.org wrote: >> 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-00.txt >> Pages : 108 >> Date : 2020-10-06 >> >> Abstract: >> This document is a specification of the basic protocol >> for Internet electronic mail transport. It consolidates, >> updates, and clarifies several previous documents, making >> all or parts of most of them obsolete. It covers the >> SMTP extension mechanisms and best practices for the >> contemporary Internet, but does not provide details about >> particular extensions. Although SMTP was designed as a >> mail transport and delivery protocol, this specification >> also contains information that is important to its use as >> a "mail submission" protocol for "split-UA" (User Agent) >> mail reading systems and mobile environments. This >> document replaces the earlier version with the same title >> in RFC 5321. >> [[CREF1: Note in Draft: Except for the last sentence, the >> above is unchanged from 5321 and may need adjusting in >> the light of RFC 6409 as an Internet Standard.]] >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321 >> bis/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-emailcore-rfc5321bis-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rf >> c5321bis-00 >> >> >> Please note that it may take a couple of minutes from the >> time of submission until the htmlized version and diff are >> available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> From nobody Wed Oct 7 07:18:09 2020 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 953493A0A4A for ; Wed, 7 Oct 2020 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Xybxzq/h; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=NuVGJYfS 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 kMG1H9Nfepvx for ; Wed, 7 Oct 2020 07:18:05 -0700 (PDT) Received: from mail.winserver.com (unknown [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD473A0DD6 for ; Wed, 7 Oct 2020 07:17:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2751; t=1602080275; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=t7DxCG+YuKT44TxyOaR7JciDcBE=; b=Xybxzq/htmWa25Cy4XflPR2K1X8+34R+rhXrzZiolgcfY2P2Vi35m664F8U0X6 1Y8P9Ab7anjf5Izr8k0MZ5rofbt3rpHf0RYq9+5KY+fMwyUUEw0pRu/9u/6SalOo vZF0hN2jgLAptAzyjQDiUHtXt6lTVdzshNnSkFNYY2WQo= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 07 Oct 2020 10:17:55 -0400 Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_SELECTOR_DNS_PERM_FAILURE) header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=dkim-fail policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4110345465.1171.2236; Wed, 07 Oct 2020 10:17:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2751; t=1602080030; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0baBXut Z5PKjQhY0oKOJnKyqc5OeIcY9XYywVALvWHI=; b=NuVGJYfScUsH+DtCWs+8mdn EzJp7o4mMPGywlaqaH7NGSvzOSS2/5jRBWhZdP4KxUoN0da9Rqe16TJOvgQJfR3L Rl1wNu3dhq60VyRQbdSxlgeoIlQGZsCx58He4V5ggCBDFXeMb9p3onDLSa/Z2OKH DeI1y4H7eCaxM1vozs3M= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 07 Oct 2020 10:13:50 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3977270015.1.14428; Wed, 07 Oct 2020 10:13:50 -0400 Message-ID: <5F7DCE07.4020609@isdg.net> Date: Wed, 07 Oct 2020 10:17:43 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org CC: Pete Resnick References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> In-Reply-To: <160200528245.32425.2250633164754152213@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Minimum requirements, Line Limits and using the term "visible" 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, 07 Oct 2020 14:18:08 -0000 On 10/6/2020 1:28 PM, internet-drafts@ietf.org wrote:> > 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 : Internet Message Format > Author : Peter W. Resnick > Filename : draft-ietf-emailcore-rfc5322bis-00.txt > Pages : 56 > Date : 2020-10-06 > Thanks Peter for your work with RFC5322bis. I have allocated some review time for the RFC5322bis and RFC5321bis drafts. Some quick notes with my initial read of RFC5322bis. 1) IMF is a 20 yr+ technology with millions of operations and countless thousands of people who have some level of technical relationship with it. I am not advocating any big change but I think a summary section "Minimum Requirements" section would be very useful to technical readers and implementators already familiar with SMTP and IMF and seek only a summary outline. If you search for words like requirements, minimum, not much there. Search for "require" and you get closer to the 3.6. Field Definitions table which reads at a minimum, the Date: and From: are required to have one only one field instance. I may also suggest it make help to make a compatibility note here that previous specs, namely, RFC822 required the "To: or CC:" field and some receiver MAY add the To: at reception which matches the RFC5321 RCPT TO: field entered during the transport. 2) Line Limits I think section "2.1.1. Line Length Limits", when read thoroughly and with some technical experience, explains the difference between the 998 and 78 character lines. But for a newer person, you have to pause to think about it. Maybe using terms like physical or protocol vs display and indicate device implementation examples can help: Protocol Line limit: MUST be 998 or less in transport and storage. Display Line limit: For text-based terminal display compatibility, consider 78 characters displays. For GUI-based displays, wider display capabilities are available. For mobile devices, smaller screen widths are a challenge for MUA developers since 78 characters may still be too wide. 3) Printable vs Visible I noticed the change from "printable" to "visible" US-ASCII characters in various sections. What's the key difference, the key idea with this change? Is the idea is that we are not encouraging print outs? What about the Visually Impaired? Why even have this attribute? Imo, it should be taking for granted that its need to be "readable" US-ASCII characters understood by all devices, printers, SFI "Speech Friendly Interface" software and eyeballs. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Oct 7 09:56:29 2020 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 6CA313A0C7E for ; Wed, 7 Oct 2020 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxSP7b5dz4gX for ; Wed, 7 Oct 2020 09:56:25 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2673A0B59 for ; Wed, 7 Oct 2020 09:56:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 0EE8CC025204; Wed, 7 Oct 2020 11:56:19 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C19fgB4nMn74; Wed, 7 Oct 2020 11:56:17 -0500 (CDT) Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 52E14C0251ED; Wed, 7 Oct 2020 11:56:17 -0500 (CDT) From: "Pete Resnick" To: "Hector Santos" Cc: emailcore@ietf.org Date: Wed, 07 Oct 2020 11:56:16 -0500 X-Mailer: MailMate (1.13.2r5723) Message-ID: <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> In-Reply-To: <5F7DCE07.4020609@isdg.net> References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Minimum requirements, Line Limits and using the term "visible" 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, 07 Oct 2020 16:56:27 -0000 On 7 Oct 2020, at 9:17, Hector Santos wrote: > Thanks Peter for your work with RFC5322bis. > > I have allocated some review time for the RFC5322bis and RFC5321bis > drafts. Some quick notes with my initial read of RFC5322bis. I appreciate your kind words, and thanks for the review. > 1) IMF is a 20 yr+ technology with millions of operations and > countless thousands of people who have some level of technical > relationship with it. I am not advocating any big change but I think a > summary section "Minimum Requirements" section would be very useful to > technical readers and implementators already familiar with SMTP and > IMF and seek only a summary outline. If you search for words like > requirements, minimum, not much there. Search for "require" and you > get closer to the 3.6. Field Definitions table which reads at a > minimum, the Date: and From: are required to have one only one field > instance. I may also suggest it make help to make a compatibility note > here that previous specs, namely, RFC822 required the "To: or CC:" > field and some receiver MAY add the To: at reception which matches the > RFC5321 RCPT TO: field entered during the transport. I'd suggest that this kind of "advice to implementers" and other such explanation is really best suited to the AS document. As a general rule, we don't do "conformance requirements" in the IETF (though we do see it on occasion), but we do like to tell people how best to use a technical specification in their implementation, and that kind of info is well-suited for an AS. (Note that I'm using AS in the RFC 2026 section 3.2 sense, which is a bit different than what is commonly meant by "applicability statement".) > 2) Line Limits > > I think section "2.1.1. Line Length Limits", when read thoroughly and > with some technical experience, explains the difference between the > 998 and 78 character lines. But for a newer person, you have to pause > to think about it. Maybe using terms like physical or protocol vs > display and indicate device implementation examples can help: > > Protocol Line limit: MUST be 998 or less in transport and storage. > > Display Line limit: For text-based terminal display compatibility, > consider 78 characters displays. For GUI-based displays, wider display > capabilities are available. For mobile devices, smaller screen widths > are a challenge for MUA developers since 78 characters may still be > too wide. This is one where I feel like people seemed to have gotten this right given the current text, so I don't think we should change the document unless we believe that people have messed this up. We can always add some explanatory text to the AS. I think lots of things in the "helpful advice to new folks" could work well in there. > 3) Printable vs Visible > > I noticed the change from "printable" to "visible" US-ASCII characters > in various sections. What's the key difference, the key idea with > this change? Is the idea is that we are not encouraging print outs? > What about the Visually Impaired? Why even have this attribute? Imo, > it should be taking for granted that its need to be "readable" > US-ASCII characters understood by all devices, printers, SFI "Speech > Friendly Interface" software and eyeballs. This actually comes from erratum 4692, where it was pointed out that the normal definition of "printable character" includes whitespace, which is not what we wanted to represent in those terminals. RFC 5234 uses the term "visible" (see the definition of VCHAR) for all of the non-whitespace printable characters, so I went with that. I take your point about the term being potentially problematic, but it is the current technical terminology in use. I defer to others as to whether we want to address this. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Wed Oct 7 12:43:41 2020 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 6B8093A0A22 for ; Wed, 7 Oct 2020 12:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Boof_6kFs2Mm for ; Wed, 7 Oct 2020 12:43:36 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 A91AA3A0A1C for ; Wed, 7 Oct 2020 12:43:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQIZS6ZV2O00AGJ3@mauve.mrochek.com> for emailcore@ietf.org; Wed, 7 Oct 2020 12:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602099512; bh=VHxN6/8Kwa3TDWFEENbvW2gMH+RiJGiyiYBo5bzD/EU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=YsY35K3Fol+puqNGzNsEry8kb4YvCko3NiUMJiOuFaBNi7mAEpO/XlaFLfZhEWJDJ qH8Y/N/dsDInwY2mghpGJ7MHCRQo2zEisWvrI58oARMYuM/dbM8SZ7TRYMQkIfnhNb lTNm0BwxVph7hMjcKKYfKx6qIM/anEk4jXmS2mEw= 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 <01RQ0J6W8U3K005PTU@mauve.mrochek.com>; Wed, 7 Oct 2020 12:38:30 -0700 (PDT) Cc: Randall Gellens , John R Levine , emailcore@ietf.org Message-id: <01RQIZS4SAY6005PTU@mauve.mrochek.com> Date: Wed, 07 Oct 2020 12:17:21 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 04 Oct 2020 17:48:45 -0400" <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> To: John C Klensin Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 07 Oct 2020 19:43:38 -0000 John Klensin wrote: > --On Sunday, 04 October, 2020 12:16 -0700 Randall Gellens > wrote: > > I agree with both of you. I agree that it would be helpful to > > say very clearly that message alteration (aside from Received > > header fields) is for message submission only. So adding Authentication-Results: is forbidden? Original recipient information? Return path? There are many fields that get added after submission and before final delivery. And not all of them really qualify as "trace" IMO. Moreover, making a list of these fields is a hopeless task, since all it takes is one more document to outdate the list. I see two possible solutions: (1) Craft some text saying something like, "Only add fields specified as OK to be added in other specifications." (2) Create a registry. I kind of like the idea of a registory, but it is a fair bit more work. > Yes. And John and I are in agreement about that, whether most > of the rest of my earlier message is relevant or not. The part > that is, and that I hope all of us are in agreement about, is > that saying much more on this subject is potential material for > the A/S, rather than a 5321bis topic, except as noted below. > > There's an argument to be made for combining the SMTP and > > Submission documents, but I think the cost outweighs the > > benefit. > Well, at this stage in the game, I think even trying would > create more confusion. What I think would be reasonable to do, > especially since 6409 is at Internet Standard, would be to look > at the text of 5321 that circles around the submission issue and > see if it could be reasonably replaced by a sentence or short > paragraph that explains that those issues are covered in 6409 > (and maybe its potential successors). Someone to do the > research as to what might be removed and suggested text to > replace it would be appreciated. Any attempt to incorporate 6409 would almost certainly be met with the desire for further "clarifications" of that document. And trying to come up any sort of list of the things submit agents should be doing or not doing is orders of magnitude more difficult than the relay case, and goes out of date even faster. Ned From nobody Wed Oct 7 13:05:56 2020 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 936283A0B6B for ; Wed, 7 Oct 2020 13:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=QEt5EaHI; dkim=pass (2048-bit key) header.d=taugh.com header.b=Ev+DzTgG 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 xkA2NoN-A5oB for ; Wed, 7 Oct 2020 13:05:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C333A09E1 for ; Wed, 7 Oct 2020 13:05:50 -0700 (PDT) Received: (qmail 15925 invoked from network); 7 Oct 2020 20:05:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3e26.5f7e1f9d.k2010; i=johnl-iecc.com@submit.iecc.com; bh=E1IbDGPLJqXMr1PVdP6AX480B4GZrKb61RLlCK4wX90=; b=QEt5EaHITux0Zg8MaOcsIHFiWbIekk4JrvZL9TmHDSXMpRfXk1iRy9vzmLR53cAebRi3dirBPXrnEsna4bEEyFbPkmIjnQbrsrEjOkDN9eCfar+lWDSEWdX+AP84hZwurWzg/9rSWFzqxVi2G+3YGldcrmHiSWEQakbjOFAf73H+zB31WggkIKBqZIBgOW8CbC4LQhEGDaaVwXFpM2yFcVweQjEd9hJWuxGrTehceBVI7tSxjnPlP2o/5E32pZaQ3BeCgQtDVfVkqIV9HID03DbCArzha6Pu8QwF7Cz/2IA1VUYZZj/k1jNRdfhrH5FxfY5z8iKrLH3yeKfFRvjZHQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3e26.5f7e1f9d.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=E1IbDGPLJqXMr1PVdP6AX480B4GZrKb61RLlCK4wX90=; b=Ev+DzTgGlR52IMM/Exlg7sVsMfjS8KHc3dgMsYcSLRztYdph/b3l8emksK04rLA1cP7C5olhpk8HkLiWhfEfXuS+D2erOnhf4oKrsbh0XbQj3Nmpihx4KeE6/lVhhMyM2u082xysbRM7vg64umpng9L7Acwuu9TpKbEzQXhZa4LBT3W4dXCmW+TtRXtuoraOMUbZiV9XkhtV1rwA9LV62pn+RvljldNcC0A+WaV9MtJA+CciUC8U5eQTEvvBfaIQUFm7RKTVgJY/AqWbeLbXMks7983EmjJkLTH+EJ19D1fR4Ny5VfIKZkgVkvXMEPLcIWj5Q5jtCO+T6fIR6WX4mA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 07 Oct 2020 20:05:49 -0000 Date: 7 Oct 2020 16:05:49 -0400 Message-ID: <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <01RQIZS4SAY6005PTU@mauve.mrochek.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 07 Oct 2020 20:05:54 -0000 On Wed, 7 Oct 2020, Ned Freed wrote: > I see two possible solutions: > > (1) Craft some text saying something like, "Only add fields specified as OK > to be added in other specifications." > > (2) Create a registry. > > I kind of like the idea of a registry, but it is a fair bit more work. Sounds like a new column or two in the existing Message Headers registry, with options like "trace", "add once", and "add multiple". Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Oct 7 13:46:26 2020 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 474EF3A139A for ; Wed, 7 Oct 2020 13:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=yuQXmTTN; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZDOCrZRq 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 4XssBlXvdRhP for ; Wed, 7 Oct 2020 13:46:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAB93A1398 for ; Wed, 7 Oct 2020 13:46:22 -0700 (PDT) Received: (qmail 22205 invoked from network); 7 Oct 2020 20:46:20 -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; s=56bb.5f7e291c.k2010; bh=WozHVRJBBFuYn2tv5xoiWKCLKAVVMBva7ytjGVxqVi0=; b=yuQXmTTNsUK76v05RkV9o10IDJHAorORHHbKmWAgWfkrqExP/Qe9DOkiPkyD1eqBhnG9j16wa8jtG0uVNMdYwihcDbGGI/zDDSfQCDeC8ph8zQcW0vUJkPEUaSkI6gJU/anh8Y/S488KpPEYVqycJ4Fr1HOm8dyr5WRhIvE76q52pwj7PpNge4SonKBp5P53ouQFI4f9q6EyYijSGHbnuRgx00M+kyxAfcumgy8EDC2BiXAspXZXcNLA4FQd3Psknt8LJ9QPHh9ylaiRJnvOZ2bLgqF/hB5Dy3IcWOQZxjm6g9XqEbKTq+uyEvIpf/RRhzNZ5uzY46NVByjyHvFujw== 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; s=56bb.5f7e291c.k2010; bh=WozHVRJBBFuYn2tv5xoiWKCLKAVVMBva7ytjGVxqVi0=; b=ZDOCrZRqx9OGjir2mW/y/hzDtEI0gLnNSnQNyCIXMGVS4TJSD4qLSL+tCK6YnZy3fjRmiADuNqh72CXHdyw2zNz0/3SI5GPrbRednvgz1qCLEXwV5hKwe872SwXVLi/JjtByEY0GpjB4cbSNhW4QDlpVnvl2h/T3te93SPWrpsT9beEYrknp31rpFCHiuby+En+D3Fx5WhDVnUQujp70ldmPRq+SkTi7rpHM7iitm90Xb93zZdOdbuUbE2syhJNzL692cjZfIlfIvqMTithfABfZHO1Yint+EGMmOhceKpqybvHKaKk/0iDJ2UJSleRpNSSh0hfU40HAdQfO1yI0SA== 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; 07 Oct 2020 20:46:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 243722312B5C; Wed, 7 Oct 2020 16:46:18 -0400 (EDT) Date: 7 Oct 2020 16:46:18 -0400 Message-Id: <20201007204619.243722312B5C@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <160200528245.32425.2250633164754152213@ietfa.amsl.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] erratum 2950, I-D Action: draft-ietf-emailcore-rfc5322bis-00.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 20:46:24 -0000 In article <160200528245.32425.2250633164754152213@ietfa.amsl.com> you write: > Title : Internet Message Format > Author : Peter W. Resnick > Filename : draft-ietf-emailcore-rfc5322bis-00.txt > Pages : 56 > Date : 2020-10-06 In the interest of moving things along, I see a question about whether we should change the "fields" ABNF per erratum 2950. That one's easy: no. The author of the erratum misunderstands how ABNF works. In particular there is no promise that ABNF will produce a unique parse for any valid string, only that it will match every valid string. From nobody Wed Oct 7 15:28:27 2020 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 04C853A145F for ; Wed, 7 Oct 2020 15:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xoUgo2DMmzz for ; Wed, 7 Oct 2020 15:28:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B883A145D for ; Wed, 7 Oct 2020 15:28:23 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kQHup-000Exo-4x; Wed, 07 Oct 2020 18:28:07 -0400 Date: Wed, 07 Oct 2020 18:28:02 -0400 From: John C Klensin To: Ned Freed cc: Randall Gellens , John R Levine , emailcore@ietf.org Message-ID: In-Reply-To: <01RQIZS4SAY6005PTU@mauve.mrochek.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 07 Oct 2020 22:28:25 -0000 --On Wednesday, October 7, 2020 12:17 -0700 Ned Freed wrote: > John Klensin wrote: > >> --On Sunday, 04 October, 2020 12:16 -0700 Randall Gellens >> wrote: > >> > I agree with both of you. I agree that it would be helpful >> > to say very clearly that message alteration (aside from >> > Received header fields) is for message submission only. > > So adding Authentication-Results: is forbidden? Original > recipient information? Return path? I should have said something closer to "message alteration in transit other than trace fields" or, to be a little more precise, "message alteration in transit from the initiating MUA or, if one is in use, the Submission server (acting as an SMTP client) or gateway at the boundary of the public Internet to the delivery MTA or gateway from the public Internet to some other system". I'm not certain what "original recipient information is" but assume it is probably covered by that reformulation. Return-path is added by the delivery MTA. And, if something other than the delivery server adds information about Authentication-Results, I don't see any reason why that should not be sufficiently distrusted to be a security problem. Does that come closer? Sorry for being sloppy. > There are many fields that get added after submission and > before final delivery. And not all of them really qualify as > "trace" IMO. At the risk of being a little bit of a purist here, I may have missed a good example but I haven't seen anything added to the headers by intermediate relays that seems like a good idea, things like Authentication-Results notwithstanding. One could get around most of the problem by, e.g., introducing ex-X.400 ADMD terminology, trying to insist that anything listed in an MX record be part of the same ADMD as the delivery server, and then rewriting the above so that "delivery MTA" reads something like "same ADMD as the destination system" but I have doubts about whether we could get that right. > Moreover, making a list of these fields is a hopeless task, > since all it takes is one more document to outdate the list. Yes. > I see two possible solutions: > > (1) Craft some text saying something like, "Only add fields > specified as OK to be added in other specifications." > > (2) Create a registry. > > I kind of like the idea of a registory, but it is a fair bit > more work. Noting John Levine's comment (without agreeing or disagreeing), are you thinking about some sort of FCFS or DE-type registry or requiring that the IETF do a serious review and grant permission? >... >> > There's an argument to be made for combining the SMTP and >> > Submission documents, but I think the cost outweighs the >> > benefit. > >> Well, at this stage in the game, I think even trying would >> create more confusion. What I think would be reasonable to >> do, especially since 6409 is at Internet Standard, would be >> to look at the text of 5321 that circles around the >> submission issue and see if it could be reasonably replaced >> by a sentence or short paragraph that explains that those >> issues are covered in 6409 (and maybe its potential >> successors). Someone to do the research as to what might be >> removed and suggested text to replace it would be appreciated. > > Any attempt to incorporate 6409 would almost certainly be met > with the desire for further "clarifications" of that document. Agreed. I was just suggesting a pointer and maybe removing some text from 5321bis. > And trying to come up any sort of list of the things submit > agents should be doing or not doing is orders of magnitude > more difficult than the relay case, and goes out of date even > faster. Indeed. john From nobody Wed Oct 7 15:43:27 2020 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 B45F43A1483 for ; Wed, 7 Oct 2020 15:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ukJaimhE; dkim=pass (2048-bit key) header.d=taugh.com header.b=FaNs1Qow 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 WTEjYySdCaso for ; Wed, 7 Oct 2020 15:43:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0053A1482 for ; Wed, 7 Oct 2020 15:43:22 -0700 (PDT) Received: (qmail 48744 invoked from network); 7 Oct 2020 22:43:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=be66.5f7e4489.k2010; i=johnl-iecc.com@submit.iecc.com; bh=tX6YFdc4+lm4U1CtIAgF7y0blAMlqzNiEMiDyjRoSxg=; b=ukJaimhEM6WTL7toX5XuBb/RdR9qD+DuMCoNSBzIXYoqtasBRnVvw4kqd/sukrC5PDOyqbbBf6eACvNfQeoO/Qt+U9UbTKM8dGJbO6de+xxNF3Rjfmtk/KuwH1o//SHiQYq397chRjc/qKwWHkEvClmOlWuaDli1eh34vSTvWo6gidxMG7iVtA+orOrcJeWi+m3Masf/bzt6FTVbceoM2g6mwPZlUKsNqoxL9w5b2T3wK2Guew3vM9mxkcp6Yvbnv4EZEURv3G6Cg943hHqYCPXa4yT5rJnTvIYzUhoH+zLg/7HIvieCLpj9MH/oBIgG4kKHUIE8nihKbXs4CDCcOQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=be66.5f7e4489.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=tX6YFdc4+lm4U1CtIAgF7y0blAMlqzNiEMiDyjRoSxg=; b=FaNs1QowJJnOW53u8DWxDCPV/pTePP+vR4rJTT/mkYFrc1fvRYJOrPWZYn+vjAC1Nd2n3dbpbmQPGTB6R0iiQ10LJGSPllQBaboM7JR0NOklKwO29istS/h4HF8yIqdVKXjw59fgk/w44fPN62dpGVOWkaG5RfOE4J7Ki4oEWC4klvEyHBLELD2i8fehtxw0Wk//ohpiEWmfaeTXR1y/1LCo0PDDGWujfYJPF7+4luV8OsTAQaRZwzjl6byM8MbgNQ/2+rhttQFx+jpP9vVQDmazrnZ/3316zTn6U98QhV+FJ2zrsT6fO/pNuhm+D58yTYs8ELpuaPTYt3XlQ4v+nA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 07 Oct 2020 22:43:20 -0000 Date: 7 Oct 2020 18:43:20 -0400 Message-ID: <34789dac-6fe2-dea5-5f28-a444f24b9813@taugh.com> From: "John R Levine" To: "John C Klensin" , "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 07 Oct 2020 22:43:25 -0000 On Wed, 7 Oct 2020, John C Klensin wrote: >> before final delivery. And not all of them really qualify as >> "trace" IMO. > > At the risk of being a little bit of a purist here, I may have > missed a good example but I haven't seen anything added to the > headers by intermediate relays that seems like a good idea, > things like Authentication-Results notwithstanding. A-R actually is a trace field, no problem there. Given that we already have a header registry, it seems that we're a large fraction of the way there already. 5322 already describes what trace headers are and which non-trace headers can occur more than once. It'd probably be adequate to say not to delete any headers without specific permission*, and to observe the limits about number of headers with the same name when deciding whether to add a non-trace header to a message in transit, R's, John * - there's a special case about deleting multiple authentication-results From nobody Wed Oct 7 16:07:52 2020 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 D3C173A14CD for ; Wed, 7 Oct 2020 16:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZk1n6onvKZA for ; Wed, 7 Oct 2020 16:07:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDC53A1491 for ; Wed, 7 Oct 2020 16:07:49 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kQIWy-000F0v-AM; Wed, 07 Oct 2020 19:07:32 -0400 Date: Wed, 07 Oct 2020 19:07:27 -0400 From: John C Klensin To: Pete Resnick , Hector Santos cc: emailcore@ietf.org Message-ID: <315955E3972DA7B0DEE75CA6@PSB> In-Reply-To: <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Minimum requirements, Line Limits and using the term "visible" 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, 07 Oct 2020 23:07:51 -0000 --On Wednesday, October 7, 2020 11:56 -0500 Pete Resnick wrote: >> 3) Printable vs Visible >> >> I noticed the change from "printable" to "visible" US-ASCII >> characters in various sections. What's the key difference, >> the key idea with this change? Is the idea is that we are >> not encouraging print outs? What about the Visually >> Impaired? Why even have this attribute? Imo, it should be >> taking for granted that its need to be "readable" US-ASCII >> characters understood by all devices, printers, SFI "Speech >> Friendly Interface" software and eyeballs. > > This actually comes from erratum 4692, where it was pointed > out that the normal definition of "printable character" > includes whitespace, which is not what we wanted to represent > in those terminals. RFC 5234 uses the term "visible" (see the > definition of VCHAR) for all of the non-whitespace printable > characters, so I went with that. I take your point about the > term being potentially problematic, but it is the current > technical terminology in use. I defer to others as to whether > we want to address this. FWIW, and being fairly sure I don't want to get into the middle of this, the terms typically used in the coded character set and computer-based typography literature are: * printable character (which, as you point out, usually includes spacing characters [1] (for ASCII, SP, HT, and sometimes VT, CR, and/or LF but, once one escapes the ASCII repertoire, things get much more complicated)) * graphic character (or maybe character component) (no spacing characters/code points, even zero-width ones). "visible character" is, AFAIK, an invention of RFC 2234 and it (and 4234 and 5234) all say "visible (printing) characters" and do so in a comment, not a normative definition. That does nothing to strengthen the case for "visible" even if one believes that "printing" or "printable" are wrong. Hence, and given the above, describing it as the "current technical terminology in use" is something of a stretch. While I think we are agreed that we don't want to go down the path toward incorporating the specifications for non-ASCII addresses or headers in 5321bis/ 5322bis (although I think we should discuss the possible appropriateness of some informative references), I think we should avoid making any changes to 5321 or 5322 that would either require adjustments in RFC 6530-6531 or associated documents or make them more confusing, at least without _strong_ justification. I don't know whether "visible" would, but note that there seems to be some interest in narrowing the permitted code points in mailbox local-parts (which interacts a bit with the question of quoted strings there) and, if we start refining those rules, we may have to go at least partway down that path. john [1] I wonder if "whitespace" is appropriate any more. Is there such a thing as "blackspace" (or "brownspace", "redspace", "yellowspace", or "greenspace") and does its existence or not make one or the other inappropriate? From nobody Wed Oct 7 16:32:43 2020 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 783B23A14E5 for ; Wed, 7 Oct 2020 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiBnFiMo_Q7b for ; Wed, 7 Oct 2020 16:32:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CBC3A14E4 for ; Wed, 7 Oct 2020 16:32:39 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kQIv1-000F2e-W7; Wed, 07 Oct 2020 19:32:24 -0400 Date: Wed, 07 Oct 2020 19:32:18 -0400 From: John C Klensin To: John R Levine , Ned Freed cc: emailcore@ietf.org Message-ID: <8770A1CEAF3BB328F2F054BE@PSB> In-Reply-To: <34789dac-6fe2-dea5-5f28-a444f24b9813@taugh.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <34789dac-6fe2-dea5-5f28-a444f24b9813@taugh.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 07 Oct 2020 23:32:41 -0000 --On Wednesday, October 7, 2020 18:43 -0400 John R Levine wrote: >... > 5322 already describes what trace headers are and which > non-trace headers can occur more than once. It'd probably be > adequate to say not to delete any headers without specific > permission*, and to observe the limits about number of headers > with the same name when deciding whether to add a non-trace > header to a message in transit, Be a tad careful here. Except for gateways, I believe there still is no actual requirement in 5321 that the message body (absent extensions, defined as whatever follows DATA up that CRLF.CRLF) conform to 5322 other than that it not be screwed up by having Trace Fields inserted. And, while neither the CREF in Section 3.9 nor Appendix G.7.5 call it out, Section 3.9 of 5321 and the current version of 5321bis says "...the message header section (RFC 5322 [11]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected." which makes some obvious current practice non-conforming. Do we change it to a SHOULD and point to the A/S? john From nobody Thu Oct 8 03:44:15 2020 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 7DAB93A0ABB for ; Thu, 8 Oct 2020 03:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyrPfvxUtJAE for ; Thu, 8 Oct 2020 03:44:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD8F3A0820 for ; Thu, 8 Oct 2020 03:44:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQJV8QGIAO005PDW@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Oct 2020 03:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602153547; bh=9jkCjJQE4bE10fqVer09v5JM/GG1wvZWItUPB/E8y78=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=eRLfdU02hHxasbvSTEF3f6IMlATJ4MsRBAdA5gdaXG9Uk98Kc0oV4X/svm2fB4pQT l1JSY5+7l6ae1ENpCKSP1AwSXg5GGdv618+KrFgXpV5WhvVg9wckRxdzGmGWp9rUR/ Il/lVMi+SZG5f5iUT2lT8EtuakZ1jH7rvbZCI5m8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQ0J6W8U3K005PTU@mauve.mrochek.com>; Thu, 8 Oct 2020 03:39:04 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RQJV8NY1F0005PTU@mauve.mrochek.com> Date: Thu, 08 Oct 2020 03:20:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 07 Oct 2020 16:05:49 -0400" <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> To: John R Levine Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 10:44:13 -0000 > On Wed, 7 Oct 2020, Ned Freed wrote: > > I see two possible solutions: > > > > (1) Craft some text saying something like, "Only add fields specified as OK > > to be added in other specifications." > > > > (2) Create a registry. > > > > I kind of like the idea of a registry, but it is a fair bit more work. > Sounds like a new column or two in the existing Message Headers registry, > with options like "trace", "add once", and "add multiple". That sounds like the right way to handle it, but this is just a registration organization detail. The hard part is writing the text explinaing the criteria for giving agents permission to add a field to a message as it transits the infrastructure. Of course one way to do it is to say that only trace fields can be added. Which simplifies the registration issue but puts the onus on the documents under revision to define what a trace field is. And this turns out to be harder than I thought, because there's no actual definition of a trace field in either RFC 5321 or RFC 5322. They simply list Return-Path: and Received: as the trace fields and stop. Going back to RFC 822, we have this definition: Trace information is used to provide an audit trail of mes- sage handling. In addition, it indicates a route back to the sender of the message. It's a starting point, I guess, but only that. Now that I've researched this, I think we need to have a better definition of trace field, irrespective of what we end up with in regards to message modification. For one thing, the definition in RFC 822 calls into question the legitimacy of classifying Authentication-Restuls as a trace field. All of the other fields I'm aware of that warranr this status are either added at a specified point during message processing (final delivery) or contain a timestamp. A-R pesses neither property, instead depending on location alone - which doesn't really fit with the notion of an audit trail, at least not as I understand it. There's also the issue that neither RFC 8098 nor RFC 3461 say that Original-Recipient is a trace field, but I guess this can be fixed with a registration update, once that's possible. Ned From nobody Thu Oct 8 03:44:19 2020 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 8EA2F3A0820 for ; Thu, 8 Oct 2020 03:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm_Q1lhCZtrb for ; Thu, 8 Oct 2020 03:44:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E563A0AB9 for ; Thu, 8 Oct 2020 03:44:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQJVCXBE0W00B5QF@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Oct 2020 03:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602153750; bh=fRpNXUzZWM+fo9zt2/7mjndHimKNtsYd5KtBYjSRwWk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gnsyjqWAZiRvnfaxK6qk0jdz9cGW3xVcqGev/hKrpZPIc8Ni6U9wf9cpDDDKH1OC2 OaJMUhk3B33e+j1XTdmDTnA2EaDqRDQwLZ6cqNgd07weDn/7DIAY8GL8fYgZou7Uew L1e2NyF++Zew2I2gV63AwzVcOKm1d+sLdnPMQ9xw= 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 <01RQ0J6W8U3K005PTU@mauve.mrochek.com>; Thu, 8 Oct 2020 03:42:27 -0700 (PDT) Cc: Ned Freed , Randall Gellens , John R Levine , emailcore@ietf.org Message-id: <01RQJVCUVBSS005PTU@mauve.mrochek.com> Date: Thu, 08 Oct 2020 03:40:15 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 07 Oct 2020 18:28:02 -0400" References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> To: John C Klensin Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 10:44:13 -0000 John Klensin wrote: > > I see two possible solutions: > > > > (1) Craft some text saying something like, "Only add fields > > specified as OK to be added in other specifications." > > > > (2) Create a registry. > > > > I kind of like the idea of a registory, but it is a fair bit > > more work. > Noting John Levine's comment (without agreeing or disagreeing), > are you thinking about some sort of FCFS or DE-type registry or > requiring that the IETF do a serious review and grant permission? Another issue that would have to be addessed, but as I noted in my previous response, there's the even more fundamental issue of the critieria for declaring something a trace field. > >... > >> > There's an argument to be made for combining the SMTP and > >> > Submission documents, but I think the cost outweighs the > >> > benefit. > > > >> Well, at this stage in the game, I think even trying would > >> create more confusion. What I think would be reasonable to > >> do, especially since 6409 is at Internet Standard, would be > >> to look at the text of 5321 that circles around the > >> submission issue and see if it could be reasonably replaced > >> by a sentence or short paragraph that explains that those > >> issues are covered in 6409 (and maybe its potential > >> successors). Someone to do the research as to what might be > >> removed and suggested text to replace it would be appreciated. > > > > Any attempt to incorporate 6409 would almost certainly be met > > with the desire for further "clarifications" of that document. > Agreed. I was just suggesting a pointer and maybe removing some > text from 5321bis. Not sure I'd remove anything, but a pointer would be good. Ned From nobody Thu Oct 8 06:33:46 2020 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 BCBC63A0B80 for ; Thu, 8 Oct 2020 06:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRBGyiOZ_3Ix for ; Thu, 8 Oct 2020 06:33:44 -0700 (PDT) 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 0C9333A0E01 for ; Thu, 8 Oct 2020 06:33:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kQW2n-000Gil-Hl; Thu, 08 Oct 2020 09:33:17 -0400 Date: Thu, 08 Oct 2020 09:33:11 -0400 From: John C Klensin To: Ned Freed cc: Randall Gellens , John R Levine , emailcore@ietf.org Message-ID: <8682DA24974769ED107EF52F@PSB> In-Reply-To: <01RQJVCUVBSS005PTU@mauve.mrochek.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <01RQJVCUVBSS005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 13:33:46 -0000 --On Thursday, October 8, 2020 03:40 -0700 Ned Freed wrote: > John Klensin wrote: > >> > I see two possible solutions: >> > >> > (1) Craft some text saying something like, "Only add fields >> > specified as OK to be added in other specifications." >> > >> > (2) Create a registry. >> > >> > I kind of like the idea of a registory, but it is a fair bit >> > more work. > >> Noting John Levine's comment (without agreeing or >> disagreeing), are you thinking about some sort of FCFS or >> DE-type registry or requiring that the IETF do a serious >> review and grant permission? > > Another issue that would have to be addessed, but as I noted > in my previous response, there's the even more fundamental > issue of the critieria for declaring something a trace field. Yes. I can't remember whether we deliberately dropped the text you quoted from 822 or whether it got lost in the "what belongs in *21 versus *22" discussion/ transition. The argument (going forward) for putting it in the former is a view that trace fields are added in transit or the very beginning of delivery so we should be defining them for those who put them in. For the latter, that some are added earlier or later. For example, is "X-Original-MUA-Name" a trace field? Certainly it is trace information (and/or free advertising) in the usual sense. I suppose we need to have a definition to decide where it belongs but predict that getting consensus on one won't be easy. I think some saying about opening cans of worms might be in order here. >> > ... >> >> > There's an argument to be made for combining the SMTP and >> >> > Submission documents, but I think the cost outweighs the >> >> > benefit. >> > >> >> Well, at this stage in the game, I think even trying would >> >> create more confusion. What I think would be reasonable >> >> to do, especially since 6409 is at Internet Standard, >> >> would be to look at the text of 5321 that circles around >> >> the submission issue and see if it could be reasonably >> >> replaced by a sentence or short paragraph that explains >> >> that those issues are covered in 6409 (and maybe its >> >> potential successors). Someone to do the research as to >> >> what might be removed and suggested text to replace it >> >> would be appreciated. >> > >> > Any attempt to incorporate 6409 would almost certainly be >> > met with the desire for further "clarifications" of that >> > document. > >> Agreed. I was just suggesting a pointer and maybe removing >> some text from 5321bis. > > Not sure I'd remove anything, but a pointer would be good. Yeah. I've got a mild desire to try to remove anything from 5321bis that appears elsewhere, especially if it appears in more details and with better explanation, incorporating it by reference. I'm not sure we will find such text about submission in 5321 and, unless someone else wants to do the research, I'll probably lose interest.... and I'll probably get over the desire if the first two or three paragraphs proposed for removal turn out to be controversial. john From nobody Thu Oct 8 08:18:37 2020 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 15D233A0A4A for ; Thu, 8 Oct 2020 08:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 1GQcWxP7D5ab for ; Thu, 8 Oct 2020 08:18:29 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 EEFC13A09A3 for ; Thu, 8 Oct 2020 08:18:13 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 098FLQLq019517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 8 Oct 2020 08:21:26 -0700 Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <01RQJVCUVBSS005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 8 Oct 2020 08:18:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <01RQJVCUVBSS005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 15:18:32 -0000 On 10/8/2020 3:40 AM, Ned Freed wrote: > Another issue that would have to be addessed, but as I noted in my > previous response, there's the even more fundamental issue of the critieria > for declaring something a trace field. Does it help to use the word "handling" rather than "trace" d/ ps. In looking at this thread and considering the kinds of legitimate changes being contemplated, I fear that dealing with such issues puts the reasonableness of seeking full standard at risk. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 8 08:21:18 2020 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 6B3BD3A0AD6 for ; Thu, 8 Oct 2020 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BKXDSR1UJLF for ; Thu, 8 Oct 2020 08:20:45 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 2B8EA3A09AC for ; Thu, 8 Oct 2020 08:20:45 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 098FNvrf019791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 8 Oct 2020 08:23:57 -0700 Reply-To: dcrocker@bbiw.net Cc: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <01RQJVCUVBSS005PTU@mauve.mrochek.com> <8682DA24974769ED107EF52F@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <54e96af3-bcd6-8624-fc42-0648c8029dbd@dcrocker.net> Date: Thu, 8 Oct 2020 08:20:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <8682DA24974769ED107EF52F@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 15:21:17 -0000 On 10/8/2020 6:33 AM, John C Klensin wrote: >>> Agreed. I was just suggesting a pointer and maybe removing >>> some text from 5321bis. >> Not sure I'd remove anything, but a pointer would be good. > Yeah. I've got a mild desire to try to remove anything from > 5321bis that appears elsewhere, especially if it appears in more > details and with better explanation, incorporating it by > reference. +10 > I'm not sure we will find such text about submission > in 5321 and, unless someone else wants to do the research, I'll > probably lose interest.... and I'll probably get over the desire > if the first two or three paragraphs proposed for removal turn > out to be controversial. IMO 5321biss should specify nothing about submission. It should be /only/ an MTA specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 8 09:52:31 2020 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 1CA173A0E72 for ; Thu, 8 Oct 2020 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pA4LcVAc_xAd for ; Thu, 8 Oct 2020 09:52:28 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 163533A0AF1 for ; Thu, 8 Oct 2020 09:52:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQK84CAM800099O7@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Oct 2020 09:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602175645; bh=hfWluD+nHQuvPmQMgrD3/m1wQY+8nFRIP5MmqTH1dEE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=DIIz+jD7U8y4nnuOnyoL024ANZwY3o8XfyDnBLjMYHPrnDas+l+y5o41oSVEbvXng LfX19Dhs5MTdPPko3m8/N3mQ6QJgT6CEUO5aMGXhHmvn0LJ7f+JbwxJTc4aYZbB4AE vglTzGTxgjF323eOgEG3vsXIMsMJ1SdzbbzYTnUI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQ0J6W8U3K005PTU@mauve.mrochek.com>; Thu, 8 Oct 2020 09:47:22 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RQK849RXT8005PTU@mauve.mrochek.com> Date: Thu, 08 Oct 2020 09:41:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Oct 2020 08:18:06 -0700" References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <01RQJVCUVBSS005PTU@mauve.mrochek.com> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 16:52:29 -0000 > On 10/8/2020 3:40 AM, Ned Freed wrote: > > Another issue that would have to be addessed, but as I noted in my > > previous response, there's the even more fundamental issue of the critieria > > for declaring something a trace field. > Does it help to use the word "handling" rather than "trace" Maybe a little. The problem is we now have other specifications talking about trace fields. Dealing with that substantially increases the cost of any wording change. I don't think the benefits measure up to the costs. > d/ > ps. In looking at this thread and considering the kinds of legitimate > changes being contemplated, I fear that dealing with such issues puts > the reasonableness of seeking full standard at risk. Part of it boils down to how much do we want to try and put limits on the things intermediaries can do. If we truly want to do this, then yes, it does have status implications. That said, now that the issue of a lack of any real specificity as to what a trace field is has come up, and we have a history of other specifications creating them, I really don't think we can avoid defining them. Full standards aren't supposed to leave this sort of thing unspecified. Ned From nobody Thu Oct 8 10:25:28 2020 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 1752F3A0B16 for ; Thu, 8 Oct 2020 10:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=YJvgX0Zc; dkim=pass (2048-bit key) header.d=taugh.com header.b=G5js3Yik 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 cKC-d_-tMwBN for ; Thu, 8 Oct 2020 10:25:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3E03A091A for ; Thu, 8 Oct 2020 10:25:23 -0700 (PDT) Received: (qmail 4663 invoked from network); 8 Oct 2020 17:25: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:references:mime-version:content-type; s=1234.5f7f4b82.k2010; i=johnl-iecc.com@submit.iecc.com; bh=flSkVuGDMal1psD+D+/pVyA1TidfcuECEUNX5ZZjOUE=; b=YJvgX0ZcmgawVkZOXc2cZuYAaZNlw9E5cEHfM1B77hzecC3xEjNzQNEl4Kc8ZDhaqv9elRW1fKnYyfn2aoXQMJsI8JNwv3/t4VDXdHXfBZxz0trR2xaHwRececwnvBn41Fu35WV9TK5l0JeuoYpFIYPqOqTDQhZdXoTzliRIs5hrYlxRCzH7NQub2pPlnUYMmXXhpEP4/iK6Q/ogxCilvlgf/PePbnCMuFT6FycyMI4j5rI7fgekwp/3HZq1xd7bDvHx13SWZcrAhmRZHbhY8I7TSNj8nECBY1aWjMYtVAVG0oqxD5ix3HsBYFdcjNAbLVjkyGrLfJ2cmlG0hGchyw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=1234.5f7f4b82.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=flSkVuGDMal1psD+D+/pVyA1TidfcuECEUNX5ZZjOUE=; b=G5js3YikZXBn5cy8wBVkI1DWrhkgyVApqrSoLNE/zi5TPZFZWvbffbMQfGIOCXZk7jtKLUlrylwyYWMEMo7hogj6HAxH3NEWu4o3SkoQAkC7jYS7NI9HCBLFS8wieOEy57c/BUw5f4OOzPJhhFBj9Mr59HtJcgfcuv4jc0vDlvxV71bOqaTn7kJwJenw8bhhrxKfQwzAPff+6NR6Acr6AjxzjPn6+p9eheUmWCMVaNbq0Yb/IrzmooBeM6J1H4oPszlkWAkkGZRP7QrAEgXRP7lTa92otu23BpyXjJNi+oIk9hI6dVCfKbJ+pra0/sYmLjWZcpIrUR0ulbQQEXGFMA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 08 Oct 2020 17:25:21 -0000 Date: 8 Oct 2020 13:25:21 -0400 Message-ID: <82ba266-874e-4563-e65-8fea1d9afad@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <01RQJV8NY1F0005PTU@mauve.mrochek.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> <01RQJV8NY1F0005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 17:25:26 -0000 On Thu, 8 Oct 2020, Ned Freed wrote: > That sounds like the right way to handle it, but this is just a > registration organization detail. The hard part is writing the text > explinaing the criteria for giving agents permission to add a field to a > message as it transits the infrastructure. Given that mail systems add headers with wild abandon, it would be nice to have some guardrails to point to. We might have to distinguish between headers added in final delivery and those added during relay, since there's a lot more of the former but they matter less. I'm also wondering how much work it's worth to try to catalog existing practice. For example, "Delivered-To" has been a widely used trace header at least since qmail came out in 1998, it's used as an example in RFCs 5293, 7681, and 8904, but it's not in any registry. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Oct 8 11:02:57 2020 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 9447E3A0BA5 for ; Thu, 8 Oct 2020 11:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 3b2LQN8HqcI8 for ; Thu, 8 Oct 2020 11:02:54 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 9409A3A0B39 for ; Thu, 8 Oct 2020 11:02:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQKAKOCZ0W002B2Q@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Oct 2020 10:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602179871; bh=KkL0aAzXUffrlfdRkekzoGu5FU2R+xNMcLJ1v5nXW0w=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AvbYDotMAkaJLB6YOCRDP5ZbBY0GgpKgiqwpKiVbiNnZVgkz1nUyPzhgdxVda1ukv +vOLLjPYOPHEvseAcBxNUoZBLF9rC6rRkgKY1RlFt25NoiIhuGAtUcA873eWtNqhoz FnOhfmylagWuzMm12XVy51HfR8IPu0Q4F8cRgmO0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQ0J6W8U3K005PTU@mauve.mrochek.com>; Thu, 8 Oct 2020 10:57:48 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RQKAKLT8XI005PTU@mauve.mrochek.com> Date: Thu, 08 Oct 2020 10:53:21 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Oct 2020 13:25:21 -0400" <82ba266-874e-4563-e65-8fea1d9afad@taugh.com> References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> <01RQJV8NY1F0005PTU@mauve.mrochek.com> <82ba266-874e-4563-e65-8fea1d9afad@taugh.com> To: John R Levine Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 18:02:56 -0000 > On Thu, 8 Oct 2020, Ned Freed wrote: > > That sounds like the right way to handle it, but this is just a > > registration organization detail. The hard part is writing the text > > explinaing the criteria for giving agents permission to add a field to a > > message as it transits the infrastructure. > Given that mail systems add headers with wild abandon, it would be nice to > have some guardrails to point to. We might have to distinguish between > headers added in final delivery and those added during relay, since > there's a lot more of the former but they matter less. Agreed. But as previously noted, there may be a process cost. Right now I'm thinking it's worth it, if only to try and rein in the behavior of spam filters. Dunno about you, but I think the ones that add many Kbs to messages are truly out of control. > I'm also wondering how much work it's worth to try to catalog existing > practice. For example, "Delivered-To" has been a widely used trace header > at least since qmail came out in 1998, it's used as an example in RFCs > 5293, 7681, and 8904, but it's not in any registry. Seems like a case that needs registration. On the opposite end, clearly trying to catalog X--- is a waste of time. Beyond that, there's room for negotiation. Ned From nobody Thu Oct 8 12:13:09 2020 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 097C83A0C47 for ; Thu, 8 Oct 2020 12:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 YinRRdpGlyqC for ; Thu, 8 Oct 2020 12:13:07 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 1CFF53A0C45 for ; Thu, 8 Oct 2020 12:13:07 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 098JGJ5m014371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 8 Oct 2020 12:16:19 -0700 Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <56cbe338-8bd5-f3dd-3029-a5060dbd0fa@taugh.com> <01RQJV8NY1F0005PTU@mauve.mrochek.com> <82ba266-874e-4563-e65-8fea1d9afad@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1f9d71f3-4e9c-24f5-665d-d3a85535963c@dcrocker.net> Date: Thu, 8 Oct 2020 12:13:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <82ba266-874e-4563-e65-8fea1d9afad@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 19:13:08 -0000 On 10/8/2020 10:25 AM, John R Levine wrote: > it would be nice to have some guardrails to point to.  We might have to > distinguish between headers added in final delivery and those added > during relay, since there's a lot more of the former but they matter less. The wild abandon includes lack of clarity about role. Having a registry that distinguishes among submission, transfer, and delivery roles could helpful. (hope spring eternal, even during the Fall.) I'd suggest separation of the registry creation effort from the registry populating effort, so that the latter is out of the critical path and can even be done in increments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 8 15:19:44 2020 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 B69E43A0FCB for ; Thu, 8 Oct 2020 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ttQrcIVM; dkim=pass (2048-bit key) header.d=taugh.com header.b=KYR1SvZP 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 Z3OWFIfzpQIX for ; Thu, 8 Oct 2020 15:19:32 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D49F3A0FB6 for ; Thu, 8 Oct 2020 15:19:32 -0700 (PDT) Received: (qmail 59781 invoked from network); 8 Oct 2020 22:19:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e983.5f7f9072.k2010; bh=k+w+fQY9KGSwiV/opJpcLc2r10XO30lR76qi4DtwQ3A=; b=ttQrcIVMvRBBFe7B5p2ab8s3Gmv09FN1r4cShF9NYS3qbRoKMH0avrc7++6nJ1QqGK4bRDkbi123iDZYGg9NqmRKtGCLBx0EWbw+hpybCXZpap5BzMXIy7O60KMQr36cKZuK4ALTgPkh8SaokLkIKm5yQTlIzpgXTYmArz01s4wqEoC7oF1AJbHvuGAFC1Q7BKk0vv2lp5SD1pvkbk/sMT+J8luHWQUKbDrYNjEnJLVdf8Umw/VGHXJMEBYwmmdzP+A7f6XtC3XGpUEMxsNpovcvg1b6ZRthNTDAGdI4D+LPk7605MNrIk1C+ikKnHycZBUCOdLttuTaj6+RP/fh5A== 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; s=e983.5f7f9072.k2010; bh=k+w+fQY9KGSwiV/opJpcLc2r10XO30lR76qi4DtwQ3A=; b=KYR1SvZPmQZGuEuSReggwRgw3+oxqZ5k6ybVvKG4Wqa6yKnKkPLSneC/tDgw5mXFehj/76eSy5E9BrN1+N975w6FVY5C/jkYALVYu4FWBWzjBMp/SOFnqjVmno+ez/JckWCqqXLUWjH98NWu6PmWMu3N5QpqF0/xI9QrjN8yx7YCLFEGZl0CzeKaz/GaxACrF2hfOp3htzc/p3tUYeWrR8V8Y2ySEu+dSvu9oQEg2F4KQypbOvjytpcDYgwYSd0kILfrZUb82bCWCEv9chbR17mgtaP3DX+a/VaLkyHK3KqO5NDwlNylfBlYcyCVALAFSjzRLX6uSLWiCDQoAXVAQA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Oct 2020 22:19:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 6AA182321256; Thu, 8 Oct 2020 18:19:28 -0400 (EDT) Date: 8 Oct 2020 18:19:28 -0400 Message-Id: <20201008221929.6AA182321256@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <1f9d71f3-4e9c-24f5-665d-d3a85535963c@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 22:19:42 -0000 In article <1f9d71f3-4e9c-24f5-665d-d3a85535963c@dcrocker.net> you write: >The wild abandon includes lack of clarity about role. > >Having a registry that distinguishes among submission, transfer, and >delivery roles could helpful. (hope spring eternal, even during the Fall.) Good points. >I'd suggest separation of the registry creation effort from the registry >populating effort, so that the latter is out of the critical path and >can even be done in increments. We already have a header registry, shared among mail, usenet news and http. I hope we don't invent another one. R's, John From nobody Thu Oct 8 15:31:26 2020 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 979B93A0F6B for ; Thu, 8 Oct 2020 15:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bbiw.net header.b=HGDGpx39; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Stw+TiJU 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 3akBBFtOKiik for ; Thu, 8 Oct 2020 15:31:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF733A0F2B for ; Thu, 8 Oct 2020 15:31:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3DAD55C0059; Thu, 8 Oct 2020 18:31:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 08 Oct 2020 18:31:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=y I6PLfUqYBLeajVXgFzFm1F5g8Qv2rhXJB06KVqxBoE=; b=HGDGpx39ORHaafW5m a0dshWGi69VQ/4lyG8uZt5C4reW47Q45gsPzi9LFBnnaUvbSDcqB7aJ+TGM3OLWv yWVZQgqg080b3bTk1iH2SI2zXpb13hc/2KXOVkRHjbXUo+7NSO/KitER5MffCX/N YM1OoBm55hgJSoiqJm+VQj3bU/jK7u9jUkx7Bjec3TEnJHbN+trpMZrbf36PoCZy EgZTcrK+GZndL1yMOSPf3I7VVRAVaR0ZtvpjKVS7o3996WXpZf3CpI48gDCq0DcX EzXEDyMGvLSPTEUTLi3D+7TEWu1h3PvJM/dXILpKG2GT5yqTjLzusAIAtUg4vMpJ lVNsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=yI6PLfUqYBLeajVXgFzFm1F5g8Qv2rhXJB06KVqxB oE=; b=Stw+TiJUo7yO9WHAkODGHwexGkAPMoemkry10SvUTcllbre6Wp3sxGfR+ 7l/I4wRvhMmsFNCUlZBZZfOGHizuVJqfctR5rDBp3bSWHmsR5et32CBKU9G79YmU T88NAUnrqM1aTfdlZTy/9kqa/URrFn3SoMHHvixwobFmx2UDnm9HJi4ksNQxVEvD 4LC3v26mce4kqSVfC0qiMiBmfaA5oCKA6UDTkzciZxPdZWRDAxqlJsq37ZIgycb8 HyESIHepIy436+4xvuwDs/JGicQ+yb5MrArULJSZCaPopqXpH9/MjHA14ecd3OzG PoBDK3s20KA+kdScmW17FM48GbOLA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrhedtgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepffgrvhgv ucevrhhotghkvghruceouggtrhhotghkvghrsegssghifidrnhgvtheqnecuggftrfgrth htvghrnhepiefhvdeugfejkefftdfhleevleetveefgeetfeegteejjedujeeugeehfeeh gfeinecuffhomhgrihhnpegssghifidrnhgvthenucfkphepvdegrddufedtrdeivddrud ekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu tghrohgtkhgvrhessggsihifrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 424653064684; Thu, 8 Oct 2020 18:31:20 -0400 (EDT) To: John Levine , emailcore@ietf.org References: <20201008221929.6AA182321256@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 8 Oct 2020 15:31:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20201008221929.6AA182321256@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 22:31:25 -0000 On 10/8/2020 3:19 PM, John Levine wrote: > We already have a header registry, shared among mail, usenet news and > http. I hope we don't invent another one. Some of the discussion, and I think my own suggestion of functional roles, would be amenable to adding columns to the existing table, I suspect. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 8 15:37:04 2020 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 79DE73A0F85 for ; Thu, 8 Oct 2020 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Hf1ipPu5; dkim=pass (2048-bit key) header.d=taugh.com header.b=gLG2/uuU 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 Xz5UEecDjhlL for ; Thu, 8 Oct 2020 15:37:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8153A0F87 for ; Thu, 8 Oct 2020 15:37:00 -0700 (PDT) Received: (qmail 63841 invoked from network); 8 Oct 2020 22:36:59 -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=f95f.5f7f948b.k2010; i=johnl-iecc.com@submit.iecc.com; bh=Iclh8K4BZEr7pQ8RnNkBFEqpDW8rViopl2998XeCKWE=; b=Hf1ipPu5SJLBhWblqAfefENkjnisuijs7rHcnBxfLLFtj7EF/ep6nagnikIGg5524gilnZvHPp40STKKEx9J3Ddqf6zBIxdYFyhKyUFtp9un/YNz1opML9PqdA0B2Ese+pbC5lMSWRCmu5H8Z4G6f/aMslVhYxtNlVpCOdLFUQSSDmmhgFMQIoqE0TbVAQtsC8BSbaeklbyfiLDQ+CYJ5+MjeJCAi9o/KG9BfjkU6iX6f4BevGO+nV2iOnVNkfooUaG2NiO4+hReUdBHT0OZr22eLojmzk2M7wjgVIKgGIH9WV2DF9XNVrOhBZILbgBK0fMbrFIhyB3aJbCfVZsZCA== 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=f95f.5f7f948b.k2010; olt=johnl-iecc.com@submit.iecc.com; bh=Iclh8K4BZEr7pQ8RnNkBFEqpDW8rViopl2998XeCKWE=; b=gLG2/uuUgKcd94AMbvA2vgixMDk2MHCEz6bQWvqHj8a+C9dSAFDaU2ZHk2KSKaV6/hBwadcfFLBt5U7ElJMxin1Rzz6r5+t0kvENgJ9BqtGt18U5nIs0s3bHqX1DD+UFgRO3y7yiCMiriDm7XGeD6L1NJGQl8NFA2qb+JGLi9SkeyK4Fxau6y3pueUk/kQ9LX14YA1Zb9axwkPcCseE6KXhAB3Nr7KZ4CQyDvHWCZj0IBNS8bHNmtptfVu3bBKoh5iliALuK73qFKwfAKMf3pAGfIqa3RKRWN95kI1suQVEo70jf6PWaHrgG3VrnYL9UyVpXynTnPlv+Zw6jgushww== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 08 Oct 2020 22:36:59 -0000 Date: 8 Oct 2020 18:36:59 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" , "John Levine" , emailcore@ietf.org In-Reply-To: References: <20201008221929.6AA182321256@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 08 Oct 2020 22:37:02 -0000 >> We already have a header registry, shared among mail, usenet news and >> http. I hope we don't invent another one. > > Some of the discussion, and I think my own suggestion of functional roles, > would be amenable to adding columns to the existing table, I suspect. Yes, that's what I was assuming. I suppose at some point we should loop in Graham Klyne, the designated expert for the existing registry. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Oct 9 07:35:01 2020 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 60CF13A08AF for ; Fri, 9 Oct 2020 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=AZUxHxM+; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AHcWqFUt 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 CZThtRKXvnQn for ; Fri, 9 Oct 2020 07:34:56 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB383A0112 for ; Fri, 9 Oct 2020 07:34:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4740; t=1602254090; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Xo4XJyYcmqXe7ySh94MAziFp6Pc=; b=AZUxHxM+Z1scswymy4sCkZiPNyP3/X0ki9OPI0FETsR6mHuqmFBBbE3FzmatqZ 0L+sIl9N9Ms1OG84ZZY4N7mF9MA6WBTD3NVljh1JiRFeNHGnIDRkoUewhNUj4fa0 0LeU+N/9gIf+Ne3l9ompC+4uzGLS6Lu2IO7sQh8B5T9BM= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 09 Oct 2020 10:34:50 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4284167972.1.580; Fri, 09 Oct 2020 10:34:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4740; t=1602253854; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IS6HGCl edkabZLDnNox1FyUgZtudHTbvbE8u6qEdDFw=; b=AHcWqFUtPJaK4SrklcM0r8E yPz2HDztKWzr4H47DVAatnEso1hGy35lHFoQ1Q2m4lfrpf/dgErkTq7SM0meZMxJ j85WFKUj0WFJlXCJAqlWjfKjIM0yJ0wKAjSkVzXy+H4g+RpT6sXTz+DaTsnHMMDy l4DA+kXaAm1lBWqyVS40= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 09 Oct 2020 10:30:54 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4151092796.1.18136; Fri, 09 Oct 2020 10:30:53 -0400 Message-ID: <5F80750C.3000808@isdg.net> Date: Fri, 09 Oct 2020 10:34:52 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: John C Klensin , Pete Resnick CC: emailcore@ietf.org References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> <315955E3972DA7B0DEE75CA6@PSB> In-Reply-To: <315955E3972DA7B0DEE75CA6@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Minimum requirements, Line Limits and using the term "visible" 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, 09 Oct 2020 14:34:59 -0000 On 10/7/2020 7:07 PM, John C Klensin wrote: > FWIW, and being fairly sure I don't want to get into the middle > of this, the terms typically used in the coded character set and > computer-based typography literature are: > > * printable character (which, as you point out, usually > includes spacing characters [1] (for ASCII, SP, HT, and > sometimes VT, CR, and/or LF but, once one escapes the > ASCII repertoire, things get much more complicated)) > > * graphic character (or maybe character component) (no > spacing characters/code points, even zero-width ones). > > "visible character" is, AFAIK, an invention of RFC 2234 and it > (and 4234 and 5234) all say "visible (printing) characters" and > do so in a comment, not a normative definition. That does > nothing to strengthen the case for "visible" even if one > believes that "printing" or "printable" are wrong. Hence, and > given the above, describing it as the "current technical > terminology in use" is something of a stretch. > > While I think we are agreed that we don't want to go down the > path toward incorporating the specifications for non-ASCII > addresses or headers in 5321bis/ 5322bis (although I think we > should discuss the possible appropriateness of some informative > references), I think we should avoid making any changes to 5321 > or 5322 that would either require adjustments in RFC 6530-6531 > or associated documents or make them more confusing, at least > without _strong_ justification. I don't know whether "visible" > would, but note that there seems to be some interest in > narrowing the permitted code points in mailbox local-parts > (which interacts a bit with the question of quoted strings > there) and, if we start refining those rules, we may have to go > at least partway down that path. (I must stress this is just input bits for synergism). My philosophy, having written at least 5-6 MUAs since the 80s; 1) What is important is that field data is #1 "readable." Iow, whether carbon or silicon, it is interpreted and understood the same way. There are number of times that a print or visible character is not readable. It may be understood by all silicons, but maybe not by all carbons. I can see where the former would be the focus when only considering the BIS work for MTA and MDA (port 25, non-auth), but not MSA (port 587, auth), the Transport and the IMF data. But consider, I don't think our MTAs and MDAs are performing OCR with the "visible" US-ASCII field data to determine their value. But even with screen readers, it needs to be "readable" US-ASCII first in order to electronically perform text to speech. 2) SFI "Speech Friendly Interfacing" was always a *strong* and never neglected consideration for my MUA work. There are important W3C Web Accessibility Initiative (WAI) resources at https://www.w3.org/WAI/ to help with modern SFI/WAI design considerations. RFC5322bis should consider an "Awareness" section on this topic, perhaps highlighting the key RFC5322bis fields that SHOULD be SFI/WAI compatible, obviously the main mail headers (From, to, date, subject) that are normally "visible", i.e. displayed but not always readable. For me, imeo, using "Printable" was better than the new "Visible" in bis but when considered for correctness, I would think "readable" is the key intention for both automation and human eyeballs. I agree, this is not something to waste time a lot of time on, but i don't think 'visible" would be quite correct for a modern 2020 version of RFC5322BIS codification. I agree with Klensin in this regard. > [1] I wonder if "whitespace" is appropriate any more. Is there > such a thing as "blackspace" (or "brownspace", "redspace", > "yellowspace", or "greenspace") and does its existence or not > make one or the other inappropriate? For my product lines, I have penciled in new documentation and reference guide work to clean up terms like "white/black list" terminologies in the mail system. RFC5322Bis does not need to worry about these common mail filtering terms, nor mail filtering in general. For WhiteSpace, it is something to consider, fun discussion on alternatives, but how much change? Tough one. I think 'whitespace" isn't related to a color but just relates to two specific characters that produce a "visible" and "printable" blank space. Consider when reading mail in Dark Mode or any other fore/back ground text color profile, the "blank" space could have a white, black green, yellow, blue, etc, background color. So maybe the alternative to whitespace is "blank space?" Tough one. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sat Oct 10 03:57:49 2020 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 648C13A13C7 for ; Sat, 10 Oct 2020 03:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmYpqs7V4Az1 for ; Sat, 10 Oct 2020 03:57:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C41E3A13C9 for ; Sat, 10 Oct 2020 03:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602327461; bh=QR0JSN0mur/w+6mUobfzIsR5buJ2jkZA9SFRKY7jxFc=; l=1805; h=To:References:From:Date:In-Reply-To; b=DL7ZhwmVQvqxYlRLy7wLpvLi7Ycwn7Z2nRJ85g5+LL1x7KYa1XNhiL62XCiDr0cdz X2iZLaXeEtdNrPZ+Rco4Gsv3wAU0v1Sv6qfF8o9S1RKo2tUAcGdBG56Zf4urp141SD 8TrP4pvEpBxBM6UQhfVO+KFqYc4/YWGqVavdsP0McjMnwhoRlXReTQDZYTcJL Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005F8193A3.000034D0; Sat, 10 Oct 2020 12:57:39 +0200 To: emailcore@ietf.org References: <20200928204857.A46B222A27E5@ary.qy> <4F1EBFEE-1C5C-4A85-A826-216D19E6AD5D@randy.pensive.org> <49B191CD3053A15C9AD7F973@JcK-HP5> <5A3FDAE5ADA34DF90DEF6164@JcK-HP5> <01RQIZS4SAY6005PTU@mauve.mrochek.com> <34789dac-6fe2-dea5-5f28-a444f24b9813@taugh.com> <8770A1CEAF3BB328F2F054BE@PSB> From: Alessandro Vesely Message-ID: <96209ddb-0299-47b1-ac56-fb584942ba21@tana.it> Date: Sat, 10 Oct 2020 12:57:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8770A1CEAF3BB328F2F054BE@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 10 Oct 2020 10:57:47 -0000 On Thu 08/Oct/2020 01:32:18 +0200 John C Klensin wrote: > --On Wednesday, October 7, 2020 18:43 -0400 John R Levine wrote: > >>... >> 5322 already describes what trace headers are and which >> non-trace headers can occur more than once. It'd probably be >> adequate to say not to delete any headers without specific >> permission*, and to observe the limits about number of headers >> with the same name when deciding whether to add a non-trace >> header to a message in transit, > > Be a tad careful here. Except for gateways, I believe there > still is no actual requirement in 5321 that the message body > (absent extensions, defined as whatever follows DATA up that > CRLF.CRLF) conform to 5322 other than that it not be screwed up > by having Trace Fields inserted. And, while neither the CREF in > Section 3.9 nor Appendix G.7.5 call it out, Section 3.9 of 5321 > and the current version of 5321bis says > > "...the message header section (RFC 5322 [11]) MUST be > left unchanged; in particular, the "From" field of the > header section is unaffected." > > which makes some obvious current practice non-conforming. Do we > change it to a SHOULD and point to the A/S? From: doesn't seem to be a trace field, definitely. But then, the last paragraph of Section 3.9 assimilates such mailing lists to MUAs[*], so setting message "ownership" is part of their job.[†] OTOH, in some cases of external aliasing, the backward-pointing address has to be modified. For example, if the final destination must not be disclosed by unexpected bounces. Best Ale -- [*] MUA is not the right term in that context, since no human user is involved. [†] There is also a step in between, where the modifications are so stylized as to be programmatically reversible. From nobody Sun Oct 11 02:07:00 2020 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 1D1263A0FA8 for ; Sun, 11 Oct 2020 02:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKKAqoqDQ6h6 for ; Sun, 11 Oct 2020 02:06:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91D43A0FA4 for ; Sun, 11 Oct 2020 02:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602407213; bh=warbvKazQsb73nAIXpvkNfBOp4Owxj3bXNOGRsTb9aQ=; l=1112; h=To:References:From:Date:In-Reply-To; b=CTdfXwi3+UDuYmtQQaHW/etZzKI8f8QAqyHaaw9TC7xiZdi1qQgnMNlX80uJ2Bxhr od5bngkWZLK2egJ0PM5NSfnGgHREcNL+eoEOxbc1Ng/66czvU47CHzCpMThjwU11NM pOtkXiyzCQU0Hs8pJKoYGjo+iofEQwwO2+Ib8z1LdHd7OrWjN5f7mYmb/u1Rr Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC0B4.000000005F82CB2D.0000573A; Sun, 11 Oct 2020 11:06:53 +0200 To: emailcore@ietf.org References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> <315955E3972DA7B0DEE75CA6@PSB> <5F80750C.3000808@isdg.net> From: Alessandro Vesely Message-ID: Date: Sun, 11 Oct 2020 11:06:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5F80750C.3000808@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Color supremacism 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, 11 Oct 2020 09:06:59 -0000 On Fri 09/Oct/2020 16:34:52 +0200 Hector Santos wrote: > On 10/7/2020 7:07 PM, John C Klensin wrote: > >> [1] I wonder if "whitespace" is appropriate any more.  Is there >> such a thing as "blackspace" (or "brownspace", "redspace", >> "yellowspace", or "greenspace") and does its existence or not >> make one or the other inappropriate? > > [...] > > I think 'whitespace" isn't related to a color but just relates to two specific > characters that produce a "visible" and "printable" blank space.  Consider when > reading mail in Dark Mode or any other fore/back ground text color profile, the > "blank" space could have a white, black green, yellow, blue, etc, background > color. So maybe the alternative to whitespace is "blank space?"  Tough one. Oh Gosh... Could we please stick to well established terms without trying to be overly correct, especially since it is obvious that no racist meaning is involved? Thanks. BTW, a production rule in "Command Argument Syntax" (Section 4.1.2 of rfc5321bis) has a "blackslash". As an exception, that may be fixed... Best Ale -- From nobody Sun Oct 11 08:06:59 2020 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 2958E3A0E56 for ; Sun, 11 Oct 2020 08:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Dfg7TuS7; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=mmCBMvQB 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 oIAFRkdarFG0 for ; Sun, 11 Oct 2020 08:06:55 -0700 (PDT) Received: from mail.winserver.com (unknown [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B65C3A0E54 for ; Sun, 11 Oct 2020 08:06:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1810; t=1602428805; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=67NJH8guAHnXj1LVSEY/VU/OhLY=; b=Dfg7TuS7+VwpiNpqD3SDJBfhEyIcUj4oE3tSA32KsrnRW6mRasJa8LEo45bG/6 l1EtCpTu5HIkEDrS/k5vu6kS6zrTR2A6H8k3jJyCKiyryBrXAsIjZt5vQVDx/ILl NHFCVfiYXIGkTq9DFjMFLiZ2Cgs/XpjD02T3EGn4M5KyA= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sun, 11 Oct 2020 11:06:44 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 163913684.14568.2292; Sun, 11 Oct 2020 11:06:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1810; t=1602428564; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=K1T0dPE BLl1/mGj2GxVaWhFzkqlVYLOhmfBmPILZQyw=; b=mmCBMvQB+yO7tW6x/g8fZMx uYgbuzIF9e8vnM7UB4BzJ8rRmQ3trnZRkqzDEQ7jHZVtxwh7Fa5pn9MPjOJziCIf PKe9DD8Lq5YSjVUnISb2+IPB756gjf4rT8m4lZ3J9U40mLUz1NBTuE69J6Nt9eB3 kxGqVph+kSK//srb3Asg= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sun, 11 Oct 2020 11:02:44 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 30836329.1.17644; Sun, 11 Oct 2020 11:02:43 -0400 Message-ID: <5F831F7F.1050807@isdg.net> Date: Sun, 11 Oct 2020 11:06:39 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> <315955E3972DA7B0DEE75CA6@PSB> <5F80750C.3000808@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] alternative for whitespace term? 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, 11 Oct 2020 15:06:57 -0000 On 10/11/2020 5:06 AM, Alessandro Vesely wrote: > On Fri 09/Oct/2020 16:34:52 +0200 Hector Santos wrote: >> On 10/7/2020 7:07 PM, John C Klensin wrote: >> >>> [1] I wonder if "whitespace" is appropriate any more. Is there >>> such a thing as "blackspace" (or "brownspace", "redspace", >>> "yellowspace", or "greenspace") and does its existence or not >>> make one or the other inappropriate? >> >> [...] >> >> I think 'whitespace" isn't related to a color but just relates to >> two specific characters that produce a "visible" and "printable" >> blank space. Consider when reading mail in Dark Mode or any other >> fore/back ground text color profile, the "blank" space could have a >> white, black green, yellow, blue, etc, background color. So maybe >> the alternative to whitespace is "blank space?" Tough one. > > > Oh Gosh... Could we please stick to well established terms without > trying to be overly correct, especially since it is obvious that no > racist meaning is involved? Thanks. Thanks? I get the point but lets realize it is this exact position that is considered problematic. It is not currently the general sentiment to just "ignore" as many in the industry are aware of the sensitive nature of such technical terms and have or planning to do address such terms like black/white listing, master/slave. https://en.wikipedia.org/wiki/Blacklisting#Computing That said, I do believe RFC5322bis and RFC5321bis are ok in this case. "WhiteSpace" is not a filtering concept. I don't think it needs to change. > BTW, a production rule in "Command Argument Syntax" (Section 4.1.2 of > rfc5321bis) has a "blackslash". As an exception, that may be fixed... For Klensin... -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Oct 11 11:04:56 2020 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 66A5E3A0F15 for ; Sun, 11 Oct 2020 11:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQSeQTHT30oY for ; Sun, 11 Oct 2020 11:04:52 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966C83A0F14 for ; Sun, 11 Oct 2020 11:04:52 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kRfiC-0000hg-E6; Sun, 11 Oct 2020 14:04:48 -0400 Date: Sun, 11 Oct 2020 14:04:41 -0400 From: John C Klensin To: Alessandro Vesely cc: emailcore@ietf.org Message-ID: <27EAA3050CFC624C4B9957B8@PSB> In-Reply-To: References: <160200528245.32425.2250633164754152213@ietfa.amsl.com> <5F7DCE07.4020609@isdg.net> <5B3A8E81-6ED7-4221-A472-17CAF97195D1@episteme.net> <315955E3972DA7B0DEE75CA6@PSB> <5F80750C.3000808@isdg.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Color supremacism 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, 11 Oct 2020 18:04:54 -0000 --On Sunday, October 11, 2020 11:06 +0200 Alessandro Vesely wrote: > On Fri 09/Oct/2020 16:34:52 +0200 Hector Santos wrote: >> On 10/7/2020 7:07 PM, John C Klensin wrote: >>=20 >>> [1] I wonder if "whitespace" is appropriate any more.=C2=A0 = Is >>> there such a thing as "blackspace" (or "brownspace", >>> "redspace", "yellowspace", or "greenspace") and does its >>> existence or not make one or the other inappropriate? >>=20 >> [...] >>=20 >> I think 'whitespace" isn't related to a color but just >> relates to two specific characters that produce a "visible" >> and "printable" blank space.=C2=A0 Consider when reading = mail in >> Dark Mode or any other fore/back ground text color profile, >> the "blank" space could have a white, black green, yellow, >> blue, etc, background color. So maybe the alternative to >> whitespace is "blank space?"=C2=A0 Tough one. =20 > Oh Gosh... Could we please stick to well established terms > without trying to be overly correct, especially since it is > obvious that no racist meaning is involved? Thanks. Sorry... I had intended my comment to be humorous, cynical, or worse, not to take us down a path in which the seriously considered making changes. For better or worse, "whitespace" is very well-established term of art and trying to change it in this one document would have consequences far more severe than any damage I can imagine. If we were to go down that path, we would also have the opportunity to debate whether U+2422 or U+2423 should be treated as space charcaters. Or, we we really wanted to talk about "black" and "white" we could discuss the status of U+25A0 and U+25A1. I think even starting to discuss such things leads rapidly to insanity. Without speaking for others, I'm got little extra sanity to spare. > BTW, a production rule in "Command Argument Syntax" (Section > 4.1.2 of rfc5321bis) has a "blackslash". As an exception, > that may be fixed... Arggh. Simple typographical error. I can't even guess why it got past me, past the RFC Editor, and past everyone who has read this document over the years. In any event, fixed in the working copy of 5321bis -- I do not intend to re-port just for that issue unless the WG Chairs tell me to do so, but it will be corrected in the next version to be posted. Thanks for the careful reading. john From nobody Tue Oct 13 03:17:50 2020 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 943B53A0F14 for ; Tue, 13 Oct 2020 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=frZyO9YV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cyJOtHZ2 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 Y9lYpAMUPvw8 for ; Tue, 13 Oct 2020 03:17:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CDF3A0F0F for ; Tue, 13 Oct 2020 03:17:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A0F425C0042 for ; Tue, 13 Oct 2020 06:17:47 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 13 Oct 2020 06:17:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=pvZ2egFSLqnv3+TwNfZmktOk5tAyIxp CHwp44Y3eEQQ=; b=frZyO9YVEFRQS1Nhq0Z6rAEX9rTg2Jz4uigSwIWmz2HROX0 so7laha+IWugKCvr9nEJ4nzPhtjcoMKT/tBgBc/MvdcA9ayEmHroM1ImrfvBRFTk wzxlWKbLCcUzN7jpnwwFan3CsuQlRNwr3hFwpK3nCSZ310nuyzM3Zk8aTqP/wI20 pm9lZCziUbJ2Yo4n7ButilrP56aadbgzYZY05HwT2WhENv8yo8/gzpFem6WnZBVv U6+x9tOMZRA63aunCP8phJ8p3pwVAskZQfVO5Z6KODh3GQsPDVvk0wiQ9n3FrINX jVoWI+PJD5FFOF/vuACl9QuU5ftV5FBPNKH8Adg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pvZ2eg FSLqnv3+TwNfZmktOk5tAyIxpCHwp44Y3eEQQ=; b=cyJOtHZ2BIdKbCMnJsNJFC dS3roKnpKTa6tvD+7Op+u0+S0nSu3XvwP+ZvLDlf3eTCuHsFaJde/az95ZRmI5rt T2nCWprh4sr1DSFmbSMuyj89PRtvrJ6FvFBTOJueNaMBuckY1lWN9dC4kWM4Pgle b8gTdmrGwFOtdZ2MYqwH5jgMYHdKS/GosWhpJhKJ0ZSl/ITPJHilJwIlbBCGxr9o pQRNXCXvtwy+g6cFb55SlNDepUExgwEedSPucFVSFX6ar93VDT+hzXd/wDB/iWIE R0qhxgtxYgPAUpQw/unE+PhvnTHRglFNDhbLM9A/Z5Vvf1ECdaxX8YwxcHd6cSSg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheelgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnheplefftdfghf evueduiefhffejlefgtdduhfdvtedtheeftedthfeghfefiefggeffnecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41601660069; Tue, 13 Oct 2020 06:17:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-407-g461656c-fm-20201004.001-g461656c6 Mime-Version: 1.0 Message-Id: <6136f961-ff4b-44eb-a473-7116febc4bdd@www.fastmail.com> In-Reply-To: References: <20201008221929.6AA182321256@ary.qy> Date: Tue, 13 Oct 2020 11:17:27 +0100 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] submission cleanup, not EHLO domain validation 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, 13 Oct 2020 10:17:50 -0000 I have created 2 related tickets in trac based on this discussion: "Better definition for trace header fields": https://trac.ietf.org/trac/emailcore/ticket/7 "Need a registry of header fields that are Ok to add after submission": https://trac.ietf.org/trac/emailcore/ticket/8 I hope I captured most of relevant points in comments in the tickets. From nobody Wed Oct 14 02:27:50 2020 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 588163A142C for ; Wed, 14 Oct 2020 02:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYS1aNLwVXSB for ; Wed, 14 Oct 2020 02:27:47 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 445163A1428 for ; Wed, 14 Oct 2020 02:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1602667666; d=isode.com; s=june2016; i=@isode.com; bh=1HOfkCYAtoq9YorA9KoaDKjajkN2ELrwRu6QZ9pkBTQ=; 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=HrfzSJcdI/2VtorkTS6fDyi1Cf2TEpyNXwWfwuHT8FzXZXgSt9nnMCo9U0gQJfDYAS/WkH oiewEHqrtxw9FtuyrCvxrmWEaeT/0Hsxo74q6w1y0Mdlm1Fzw/AZM3MVv2KFsZRBrZtPLT orCmodAHpC9ugzYuNm0vWfTKBjOoY5c=; Received: from [192.168.1.79] (109-252-81-41.nat.spd-mgts.ru [109.252.81.41]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 14 Oct 2020 10:27:45 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> Date: Wed, 14 Oct 2020 10:27:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #2: Repeated Use of 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, 14 Oct 2020 09:27:48 -0000 Dear WG participants, I would like to start resolving issues raised against rfc5321bis and=20 hopefully the ticket below is an easy one: =C2=A0 While the specification says that an SMTP client's sending EHLO agai= n =C2=A0 after it has been issued (starting an SMTP session and treats it as =C2=A0 if RSET had been sent (closing the session) followed by EHLO, there =C2=A0 are apparently applications, at least some of them involving setting =C2=A0 up of secure connections, in which the second EHLO is required and =C2=A0 does not imply RSET. Does the specification need to be adjusted to =C2=A0 reflect or call out those cases? I would like to hear more about such applications. I also checked the text of RFC 3207 (SMTP STARTTLS command) and I think=20 it is quite clear that recommendations in RFC 3207 are consistent with=20 repeated EHLO being treated as RSET. Please send your thoughts on this subject. Best Regards, Alexey, as co-chair From nobody Wed Oct 14 13:53:08 2020 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 CD5913A067A for ; Wed, 14 Oct 2020 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=R+YrAcpq; dkim=pass (2048-bit key) header.d=taugh.com header.b=lYPwGSb4 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 NA70ZX6Oq1Ui for ; Wed, 14 Oct 2020 13:53:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4211A3A1066 for ; Wed, 14 Oct 2020 13:53:04 -0700 (PDT) Received: (qmail 800 invoked from network); 14 Oct 2020 20:53:03 -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; s=31e.5f87652f.k2010; bh=46Ofaf0YZKFgmp8YbAgIGyN9bs7MEdlnjIPGX/VTIfI=; b=R+YrAcpq2lkKtfKCMwppmHgswQdVihNkWZXgQ64iYpm9VQA1lsNcyQrQ1/BmdtvEdjGn8qTf5SaoC61uNlAsSCq6fzUQROFC3E7dDw1GpVcC/kSSrSdcEYUYVMdqJUkGvOQuKccG33WsC67nwKVpb39N2l3sNC6T8vNdXKQK1jGBOcBnScECgO8dIrzYbXcLmj2toy1nQUL6yRA6IijtEz+FW47tGuNu5ybSiz7DF2VWQSo24mLUC4ZmGVUIkq8sU7DibiQAfnuUdsPndtzIztoc5A0FV2/NRajlUYUVlipIoHrjlVTLoQPxFm9sJJMcxqX+r0Wtt58y3cnhexirGw== 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; s=31e.5f87652f.k2010; bh=46Ofaf0YZKFgmp8YbAgIGyN9bs7MEdlnjIPGX/VTIfI=; b=lYPwGSb4fTNZzEI78eKcxHBPeMMPf+EMVKMokW7Da7D5U4I+BxnBAAeyadGfYuUEpC7oi8TH5XzC8F8dfmjEsNemwp6fOubIKynMO991KKeee6ltsneYh5jCTbAkn7NBSQmBcU4Mx/V6f/BfcuQgnv6vY0wQOOus0cIonybBhOhkKzVLgJMN8PpZ1BTz4V0PmNe1jWiIN0Z1izI5Mw5fnLESN7n16Qp/8qdG2nsBWN+Ln6HCvf/6nAXUOl1GtTy+39Rw8l+FIkdIAULi/3oQjj7e6MmoCzW8T+/wKl/Ctq3Gxxh4TTNsEhgDZnDUFNhMTH8xSqvi8XpJa5rs2EVdYw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Oct 2020 20:53:02 -0000 Received: by ary.qy (Postfix, from userid 501) id 6810A2370E39; Wed, 14 Oct 2020 16:53:01 -0400 (EDT) Date: 14 Oct 2020 16:53:01 -0400 Message-Id: <20201014205302.6810A2370E39@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 14 Oct 2020 20:53:06 -0000 In article <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> you write: >   there are apparently applications, at least some of them involving setting >   up of secure connections, in which the second EHLO is required and >   does not imply RSET. That's really hard to believe. The second EHLO is certainly necessary to see what features are only available with TLS, but it's hard to imagine a situation where you'd do a STARTTLS in the middle of a transaction and RSET would make a difference. Perhaps your informant is unclear about what RSET means. R's, John From nobody Thu Oct 15 01:44:16 2020 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 05D793A1371 for ; Thu, 15 Oct 2020 01:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0_gkpjPVW-5 for ; Thu, 15 Oct 2020 01:44:14 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009CA3A1370 for ; Thu, 15 Oct 2020 01:44:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 23A9C194119C; Thu, 15 Oct 2020 04:44:13 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Thu, 15 Oct 2020 04:44:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=BGy+MQZlS3ASkiR9zGrIDeXNj5wQeKlJyOI3Uf9xs 5E=; b=EMK2mUsT5DYL+v7dR1uBpUK/rj/fa1/LR/RGGDeqDF1FFmV/lL/eqvP2d 2Yi4o21dY13alNGKwwz4A24GoNScqWcf49RX2ziVI8RcVhEYichiqNC9mRfREmnW baKYGnBChW2OTpzPKk2Qn6Pp9GGxsvP8IwOnpznamcKwaFP1lOP68WGyee74iky5 l2UnMow/FAUqPo8WVKr1vfUMm+Nhv12fNDpmhmsxDQrZdEfnFY+1C2/R4wcsI0FF 9weBpLVnDt/DP5hOWUCDhh7ffuy4cZxRcivZYuOpghFOiiRXNMTxVromk0/h4jtn QZ9x9T67Kzx/znj6J+PFHXHKtAaeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieefgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpefgheefgeduiedvfedvueeijeetkeeugfdu heetjedugfeutddukefhgfevleefjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F0CF5660069; Thu, 15 Oct 2020 04:44:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> In-Reply-To: <20201014205302.6810A2370E39@ary.qy> References: <20201014205302.6810A2370E39@ary.qy> Date: Thu, 15 Oct 2020 09:43:51 +0100 From: "Alexey Melnikov" To: "John R Levine" , "John C Klensin" Cc: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 08:44:15 -0000 On Wed, Oct 14, 2020, at 9:53 PM, John Levine wrote: > In article <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> you write:= > > =C2=A0 there are apparently applications, at least some of them invo= lving setting > > =C2=A0 up of secure connections, in which the second EHLO is require= d and > > =C2=A0 does not imply RSET. >=20 > That's really hard to believe. The second EHLO is certainly necessary > to see what features are only available with TLS, but it's hard to > imagine a situation where you'd do a STARTTLS in the middle of a > transaction and RSET would make a difference. >=20 > Perhaps your informant is unclear about what RSET means. I will redirect this question to John Klensin, as the wording from ticke= t is from him. John? From nobody Thu Oct 15 04:29:45 2020 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 028B43A13BD for ; Thu, 15 Oct 2020 04:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH3WK-A11Rdo for ; Thu, 15 Oct 2020 04:29:42 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD5A3A13BC for ; Thu, 15 Oct 2020 04:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602761379; bh=2GD0scxu+Ld4owgSxqJvlVAPwNVSdcMWKMIsijSs+cQ=; l=942; h=To:References:From:Date:In-Reply-To; b=DgR6dfG/vpCGXKymDuFEOn90FOWgZ/dRstpQF4YPvts+RxfZ6gEQq9YzmAYcICQ7v feD8yg4gAD1gUlOOnPgMecIw5/uB1XPjRfGqyGQHRofQNH/tlrzff+7AQHh3HybjqV 2pblHdoxIsV+hi7SgMPSpJmzBBOE+QOmUuCLmVnxkyUvWyYl+waUmbyg1iChs Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC08B.000000005F8832A3.00004AB9; Thu, 15 Oct 2020 13:29:39 +0200 To: emailcore@ietf.org References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> From: Alessandro Vesely Message-ID: <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> Date: Thu, 15 Oct 2020 13:29:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 11:29:44 -0000 On Wed 14/Oct/2020 11:27:44 +0200 Alexey Melnikov wrote: > Dear WG participants, > > I would like to start resolving issues raised against rfc5321bis and hopefully > the ticket below is an easy one: > >   While the specification says that an SMTP client's sending EHLO again >   after it has been issued (starting an SMTP session and treats it as >   if RSET had been sent (closing the session) followed by EHLO, there >   are apparently applications, at least some of them involving setting >   up of secure connections, in which the second EHLO is required and >   does not imply RSET. Does the specification need to be adjusted to >   reflect or call out those cases? > The errata that Tony Hansen prepared against RFC 3207 in 2009[*] was apparently never posted, although there was rough consensus at the time. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/ietf-smtp/uAjEHFQcwJDsomiNplhwIMULjD8/ From nobody Thu Oct 15 05:11:08 2020 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 B82383A13DE for ; Thu, 15 Oct 2020 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MbrJuYdD; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=pzkVXDdK 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 TINJkWbHYYLN for ; Thu, 15 Oct 2020 05:11:02 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7743A13DF for ; Thu, 15 Oct 2020 05:11:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2332; t=1602763858; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=+hewN89cNGtFHJuPuI/aYkjcQ2c=; b=MbrJuYdDrbd9CkmOAWsUCIUmV6a6lidqgCsA1ORCq/vMFN7LgGBpIXDglfVfe7 cdpQlTfF6GABJcZRu3M6ZXZep+w17maQ8SmdWSoxdWDZYVfR6tSyaK4VcVrN71wo DymDfWC1DyaxziYJOzvMXFx3gTd1rM+geUkLqcuJMJq+4= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 15 Oct 2020 08:10:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 498964035.1.3256; Thu, 15 Oct 2020 08:10:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2332; t=1602763612; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=D64m/+p yfXwNodyjWULyu9vF1yM1PdSXM8xTcQLcfns=; b=pzkVXDdKWLwKaC3HHb1u9ZS 3JmW093ZAVRKF73WpgyyFsu30cRk1O2B2Amdi8L77rjOcBsG4A+Amz1VUA2gZ6x1 cGbq7kM0UVBsoow0JeNUHWYQXhZ5uET0jWrYF+mqpIVAfKQhH77w3hh4aUNapNuY +BtT/N3f5+DCmOxzlveQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 15 Oct 2020 08:06:52 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 365883750.1.15112; Thu, 15 Oct 2020 08:06:51 -0400 Message-ID: <5F883C53.8020909@isdg.net> Date: Thu, 15 Oct 2020 08:10:59 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Alexey Melnikov , emailcore@ietf.org References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> In-Reply-To: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 12:11:08 -0000 On 10/14/2020 5:27 AM, Alexey Melnikov wrote: > Dear WG participants, > > I would like to start resolving issues raised against rfc5321bis and > hopefully the ticket below is an easy one: > > While the specification says that an SMTP client's sending EHLO again > after it has been issued (starting an SMTP session and treats it as > if RSET had been sent (closing the session) followed by EHLO, there > are apparently applications, at least some of them involving setting > up of secure connections, in which the second EHLO is required and > does not imply RSET. Does the specification need to be adjusted to > reflect or call out those cases? > > I would like to hear more about such applications. > > I also checked the text of RFC 3207 (SMTP STARTTLS command) and I > think it is quite clear that recommendations in RFC 3207 are > consistent with repeated EHLO being treated as RSET. > > Please send your thoughts on this subject. I do not think our smtp "resets" the TLS channel once established. The ESMTP Auth credentials is not going to get reset. In wcSMTP, the RSET is used for starting a new mail transaction, clears MAIL FROM and RCPT TO(s) fields, clears any temp file/storage. The secured channel and credentials are not lost. For the wcSMTP state machine: - for the client side, it is coded to issue the 2nd EHLO after establishing STARTTLS - for the receiver side, reviewing it now, it appears to be relaxed on the requiring the 2nd EHLO from the client after STARTTLS. I don't recall ever viewing EHLO/HELO as a "reset" concept. The specs does say: A client SMTP SHOULD start an SMTP session by issuing the EHLO command. But defined a "session?" Section 3.1 declares it as: An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message. which I agree with. A session could be the connection itself and the HELO/EHLO is adding the machine domain name bit which we historically have no confident in its correctness and therefore have the "MUST NOT reject on basis." But under wcSMTP ESMTP AUTH conditions (port 587), the EHLO ip-literal check is skipped because port 587 expects ESMTP AUTH to follow. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Oct 15 06:04:16 2020 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 A842A3A1412 for ; Thu, 15 Oct 2020 06:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYsfpA3T6JSp for ; Thu, 15 Oct 2020 06:04:12 -0700 (PDT) Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com [66.111.4.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FF83A1418 for ; Thu, 15 Oct 2020 06:04:11 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 6AFC319403B9; Thu, 15 Oct 2020 09:04:10 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Thu, 15 Oct 2020 09:04:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dZxNee FrNR73cQ5uwnGsLT9HZNbglTGrwiyQtLlGi/Y=; b=LF41hhbECQy2FZlBRBxgGA J9thEQW8kexjtMmusccE+a84fMjKqZMBYARfvGU6QibINjuVp17m1HJTTetlZhsH HHESBuAPNTHzLlbxqPaMnJoNEN9fDY+mbya6aTAE6uRns82i4BF6GJC82dlmq9YH TghramJTyxJ0dZqV2S9vE78Wu1PdIYNg8wisZcU9Hr/cdIIP1Oq1UtXyW/Wue1AE D89KDA3nYUSPmz+d3FZD7sEnu8Y3xUww5qB0j00YxjMEME84eBwGq+Tlo7+ruv0M UNY9poEH+MwWQG6icppERuz9RQ3PBeG6uT+rVpd9hY9ZLzzfOsOd3agjPNyD0OpA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieefgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorghlvgigvgihrdhmvghlnhhikhhovhesihhsohguvg drtghomheqnecuggftrfgrthhtvghrnheptdevtedtteeggedugfejtefhgefflefhudei uedtudffhfegleffjefffefhkeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvgigvgihrdhmvghlnhhikhhovhesihhsohguvgdrtgho mh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14232660069; Thu, 15 Oct 2020 09:04:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: In-Reply-To: <5F883C53.8020909@isdg.net> References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <5F883C53.8020909@isdg.net> Date: Thu, 15 Oct 2020 14:03:47 +0100 From: "Alexey Melnikov" To: "Hector Santos" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 13:04:14 -0000 Hi Hector, (Speaking as a participant and an SMTP server implementor) On Thu, Oct 15, 2020, at 1:10 PM, Hector Santos wrote: > On 10/14/2020 5:27 AM, Alexey Melnikov wrote: > > Dear WG participants, > > > > I would like to start resolving issues raised against rfc5321bis and > > hopefully the ticket below is an easy one: > > > > While the specification says that an SMTP client's sending EHLO again > > after it has been issued (starting an SMTP session and treats it as > > if RSET had been sent (closing the session) followed by EHLO, there > > are apparently applications, at least some of them involving setting > > up of secure connections, in which the second EHLO is required and > > does not imply RSET. Does the specification need to be adjusted to > > reflect or call out those cases? > > > > I would like to hear more about such applications. > > > > I also checked the text of RFC 3207 (SMTP STARTTLS command) and I > > think it is quite clear that recommendations in RFC 3207 are > > consistent with repeated EHLO being treated as RSET. > > > > Please send your thoughts on this subject. > > I do not think our smtp "resets" the TLS channel once established. The > ESMTP Auth credentials is not going to get reset. Right, TLS state and ESMTP Auth state are property of the SMTP connection and can't be reset on the connection. So this is the expected behaviour. > In wcSMTP, the > RSET is used for starting a new mail transaction, clears MAIL FROM and > RCPT TO(s) fields, clears any temp file/storage. The secured channel > and credentials are not lost. Correct. This is as expected (and agrees with my understanding of how RSET works. > For the wcSMTP state machine: > > - for the client side, it is coded to issue the 2nd EHLO after > establishing STARTTLS > > - for the receiver side, reviewing it now, it appears to be relaxed on > the requiring the 2nd EHLO from the client after STARTTLS. > > I don't recall ever viewing EHLO/HELO as a "reset" concept. Section 4.1.4 of RFC 5321 says: An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands. So this is quite clear to me that EHLO clears superset of state cleared by RSET. Text in Section 4.1.1.5 of RFC 5321 reinforces this: Since EHLO implies some additional processing and response by the server, RSET will normally be more efficient than reissuing that command, even though the formal semantics are the same. > The specs does say: > > A client SMTP SHOULD start an SMTP session by issuing the EHLO > command. > > But defined a "session?" Section 3.1 declares it as: > > An SMTP session is initiated when a client opens a connection to a > server and the server responds with an opening message. > > which I agree with. A session could be the connection itself and the > HELO/EHLO is adding the machine domain name bit which we historically > have no confident in its correctness and therefore have the "MUST NOT > reject on basis." But under wcSMTP ESMTP AUTH conditions (port 587), > the EHLO ip-literal check is skipped because port 587 expects ESMTP > AUTH to follow. Best Regards, Alexey From nobody Thu Oct 15 06:07:27 2020 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 CF4223A1405 for ; Thu, 15 Oct 2020 06:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Zwp1AV/n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=laBmLlky 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 pbMGcdXBgNQL for ; Thu, 15 Oct 2020 06:07:24 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE3C3A13EB for ; Thu, 15 Oct 2020 06:07:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6BCA85C0196; Thu, 15 Oct 2020 09:07:23 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 15 Oct 2020 09:07:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=bqwW3 zolBuiUkk9jav9RFnwoV4kOd93jzWJoq6CcPQE=; b=Zwp1AV/nZ6+fSsy97kM9l Kn9IwzcfGM2pqw7ZpgQ158m4lVNF4r0DDDvFOgqtlH7BvAmdk8UBJ64HzhMhaeuf oNIgBB3lop7J+Ke08ehj1L2vJiUnMysf+ikpqR3UtNcHS4H8lJ/TAFZnC1M6/mny aFuYgsKBIVvpbpgwz8kN9XPVWbS6lBREvKJSX6sYuI+1phfm9kryAj+4JH7jjeLE 3SyLeWzMKLu8FStS3+5eUN68EvX6WGSLnGD0CKYXIPkQFj4AujSbSdq1SOOBvMIp Ab7Qh5GE3bbPARCpv9weZhqfQIwsvYdI1HNHjgeCJ5qreILlNvBq8viNmcETrC2g g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=bqwW3zolBuiUkk9jav9RFnwoV4kOd93jzWJoq6CcP QE=; b=laBmLlky8XxrYyMkupO6VIoawzi7eql7ltqSjcNW/E6eEVpH63qncBRQV kxQEJb54P5C6F5Lb0U+rgRbH/HTbNxUI6pspDIKi+Zo1KLZOZK9TgKDH4es21UnV I1GBoOc1+HLx4f9HTm2ZAl/WcuMXeLFLFJ+hsnBO+78jxrfp2vR0OXgO8e4MX3lo faClZD5DC7dgtutDHbKQ1OrVKDjn/QxSgqBNRAhSzxKYT3Zx4vGZUwXhbnD/eYD7 rsdP1O80jZQUbnwQ6bWUbAa9zwJLnBTinNNlaZ6x/notxHSe4A38oi0dFJJ+Y6Tf bFzgnA9q5vKyvnf87chJJ41XxqNSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieefgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepleevjeefvefhvdeffedtgeefudevkeekjefgfffg feefieehleelfefggeefuedvnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhho vhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4B8A7660069; Thu, 15 Oct 2020 09:07:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> In-Reply-To: <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> Date: Thu, 15 Oct 2020 14:07:00 +0100 From: "Alexey Melnikov" To: "Alessandro Vesely" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 13:07:26 -0000 Hi Alessandro, On Thu, Oct 15, 2020, at 12:29 PM, Alessandro Vesely wrote: > On Wed 14/Oct/2020 11:27:44 +0200 Alexey Melnikov wrote: > > Dear WG participants, > >=20 > > I would like to start resolving issues raised against rfc5321bis and= hopefully=20 > > the ticket below is an easy one: > >=20 > > =C2=A0 While the specification says that an SMTP client's sending E= HLO again > > =C2=A0 after it has been issued (starting an SMTP session and treat= s it as > > =C2=A0 if RSET had been sent (closing the session) followed by EHLO= , there > > =C2=A0 are apparently applications, at least some of them involving= setting > > =C2=A0 up of secure connections, in which the second EHLO is requir= ed and > > =C2=A0 does not imply RSET. Does the specification need to be adjus= ted to > > =C2=A0 reflect or call out those cases? > >=20 >=20 > The errata that Tony Hansen prepared against RFC 3207 in 2009[*] was=20= > apparently never posted, although there was rough consensus at the tim= e. This is a very good point and something that should be addressed if/when= RFC 3207 is revised. However it is not clear to me that Tony's proposed changes have any impl= ication on this issue. So if you disagree with this statement, can you e= laborate about why you think otherwise? > --=20 >=20 > [*] https://mailarchive.ietf.org/arch/msg/ietf-smtp/uAjEHFQcwJDsomiNpl= hwIMULjD8/ From nobody Thu Oct 15 08:02:39 2020 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 B0E413A047D for ; Thu, 15 Oct 2020 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSGzrDo6kEJr for ; Thu, 15 Oct 2020 08:02:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624B13A044A for ; Thu, 15 Oct 2020 08:02:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kT4lz-00014d-9z; Thu, 15 Oct 2020 11:02:31 -0400 Date: Thu, 15 Oct 2020 11:02:26 -0400 From: John C Klensin To: Alexey Melnikov , John R Levine cc: emailcore@ietf.org Message-ID: In-Reply-To: <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> References: <20201014205302.6810A2370E39@ary.qy> <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 15:02:38 -0000 --On Thursday, October 15, 2020 09:43 +0100 Alexey Melnikov wrote: > On Wed, Oct 14, 2020, at 9:53 PM, John Levine wrote: >> In article <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> >> you write: >> > =C2=A0 there are apparently applications, at least some of = them >> > involving setting =C2=A0 up of secure connections, in which = the >> > second EHLO is required and =C2=A0 does not imply RSET. >>=20 >> That's really hard to believe. The second EHLO is certainly >> necessary to see what features are only available with TLS, >> but it's hard to imagine a situation where you'd do a >> STARTTLS in the middle of a transaction and RSET would make a >> difference. >>=20 >> Perhaps your informant is unclear about what RSET means. >=20 > I will redirect this question to John Klensin, as the wording > from ticket is from him. John? Sorry. I can't help much. Referring people to the introduction to Appendix G of draft-ietf-emailcore-rfc5321bis-00, that issue came up in the ietf-smtp mailing list discussion that started circa December 2019. In my judgment, it got enough interest to justify adding it to what because the Appendix G list (as subsection G.2) but my threshold of how much interest that required was deliberately very low and did not require documentation of any specific case of an alleged problem. The subsection was my summary of the issue as presented. I assume I got it right, but it is not impossible that I completely misunderstood what was going on (a disclaimer that applies to every entry in Appendix G). As editor, I have no opinion about how the WG should dispose of any of those subsections. I am just looking forward to removing them as they are resolved and they, and the reasons for removing them, are recorded in the tracker. Also as editor:=20 (1) Alexey, it would be helpful to me, and maybe others, that, as you transcribe subsections of Appendix H or G, you identify the relevant subsection number with them. Also please remember that, especially if you are looking for things to do that ought to be easy, the WG needs to verify every one of the errata in Appendix H, subsection H.1, and all of the changes in subsection H.2ff to be sure they are what is wanted. (2) For all of the items in Appendix G, I believe the WG charter requires that we examine that question of whether a change is consistent with the requirements for moving to Internet Standard rather than looping back to Proposed. Using this case only as an example, my interpretation of those requirements is that, unless we decided that a specification that requires that EHLO not imply RSET is somehow confirming to a specification that seems rather clear on the subject, whether or not there are examples out there in which that is the expected behavior is irrelevant. Instead, the question (on purely procedural grounds) is whether there are conforming implementations (either client or server) out there that depend on not needing to issue a RSET before a new EHLO when resetting the state is needed. If there are not, then changing this requirement is dropping an unused feature. If there are, then this topic is out of scope for the WG except possibly for a discussion in the A/S (either "don't do that" or "we know there are cases that violate the SMTP spec and it would be good for everyone wanting EHOO to imply RSET to send the RSET (and undergo the extra turnaround) first"). best, john From nobody Thu Oct 15 08:31:54 2020 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 7A99D3A083F for ; Thu, 15 Oct 2020 08:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zBYi4lpNbbO for ; Thu, 15 Oct 2020 08:31:51 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5643A082C for ; Thu, 15 Oct 2020 08:31:51 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kT5EG-00019H-IX; Thu, 15 Oct 2020 11:31:44 -0400 Date: Thu, 15 Oct 2020 11:31:39 -0400 From: John C Klensin To: Alexey Melnikov , Hector Santos , Alessandro Vesely cc: emailcore@ietf.org Message-ID: <91847F0B88D3497859EF45BC@PSB> In-Reply-To: References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <5F883C53.8020909@isdg.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 #2: Repeated Use of 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, 15 Oct 2020 15:31:53 -0000 --On Thursday, October 15, 2020 14:03 +0100 Alexey Melnikov wrote: > Hi Hector, > > (Speaking as a participant and an SMTP server implementor) > > On Thu, Oct 15, 2020, at 1:10 PM, Hector Santos wrote: >> On 10/14/2020 5:27 AM, Alexey Melnikov wrote: >> > Dear WG participants, >> > >> > I would like to start resolving issues raised against >> > rfc5321bis and hopefully the ticket below is an easy one: >> > >> > While the specification says that an SMTP client's >> > sending EHLO again after it has been issued (starting an >> > SMTP session and treats it as if RSET had been sent >> > (closing the session) followed by EHLO, there are >> > apparently applications, at least some of them involving >> > setting up of secure connections, in which the second >> > EHLO is required and does not imply RSET. Does the >> > specification need to be adjusted to reflect or call out >> > those cases? >> > >> > I would like to hear more about such applications. >> > >> > I also checked the text of RFC 3207 (SMTP STARTTLS command) >> > and I think it is quite clear that recommendations in RFC >> > 3207 are consistent with repeated EHLO being treated as >> > RSET. >> > >> > Please send your thoughts on this subject. >> >> I do not think our smtp "resets" the TLS channel once >> established. The ESMTP Auth credentials is not going to get >> reset. > > Right, TLS state and ESMTP Auth state are property of the SMTP > connection and can't be reset on the connection. So this is > the expected behaviour. Editor hat off; personal comment only: First of all, if that is what is wanted, then what is needed in 5321bis is a clarification to exactly what RSET resets and exactly what EHLO in an established SMTP session/ connection does. If we were really careful, that could be done as a clarification but (i) It is not what whomever proposed what became G.2 asked for -- no problem for me, but we should be clear about it. (ii) What is now the third paragraph of Section 1.1 notwithstanding, we removed all of the text that was intended to support use of SMTP over non-TCP transports with 2821. If any part of the above can be read to imply that, once a TLS tunnel or authentication state is established, SMTP is not really running over TCP but over some intermediate layer that redefines the connection, we'd better be _really_ careful about how we make the changes. Having just skimmed through at least part of the relevant text, it isn't going to be easy and I'd predict the editor would insist on proposed text and specific changes. (iiii) In particular, if RFC 3207 is going to be read (with or without proposed errata) as changing the EHLO and/or RSET definitions of 2821, there had better be a Proposed Standard update to it that makes that change to 5321, it better have been around for more than six months, and we (or the IESG) had best be ready to move it to Internet Standard or open community discussion on the downref. Similar comments apply any ESMTP extension that does not have specific text in it modifying the RFC 2821/5321 definitions of EHLO, RSET, or both. john From nobody Thu Oct 15 08:45:04 2020 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 959C33A0880 for ; Thu, 15 Oct 2020 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR7EZNW86r3T for ; Thu, 15 Oct 2020 08:44:57 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6467A3A0895 for ; Thu, 15 Oct 2020 08:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1602776696; d=isode.com; s=june2016; i=@isode.com; bh=JsTJRGyhv8N9twGiyJVgRY6nh0u9CwWcwDtn+0WeMfs=; 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=fey/72GAgDadP8G597rHllE1crCDxjfwr+HEQumcukifq3JQh1PQ7BHinTbRX2ETWTpAVG +exLvBEKcrlhYL+kuDHCah19LQarso2k5vG4pp6UrifNpjeLvks0fKBIT523NIu/zoQ0uP aWxSBRdi6fIEXicXZjtYIHsvpbX9sEc=; Received: from [192.168.1.79] (109-252-80-53.nat.spd-mgts.ru [109.252.80.53]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 15 Oct 2020 16:44:56 +0100 To: John C Klensin Cc: emailcore@ietf.org References: <20201014205302.6810A2370E39@ary.qy> <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> From: Alexey Melnikov Message-ID: <27911bb5-ecbb-dea9-c3e6-a67cecb336c6@isode.com> Date: Thu, 15 Oct 2020 16:44:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Emailcore] Issue tracking 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, 15 Oct 2020 15:44:59 -0000 Hi John, I changed the subject as we are discussing general procedural stuff. On 15/10/2020 16:02, John C Klensin wrote: > As editor, I have no opinion about how the WG should dispose of > any of those subsections. I am just looking forward to removing > them as they are resolved and they, and the reasons for removing > them, are recorded in the tracker. At least that makes two of us. > Also as editor: > > (1) Alexey, it would be helpful to me, and maybe others, that, > as you transcribe subsections of Appendix H or G, you identify > the relevant subsection number with them. Noted. I was borderline on this and I should have included them. I will update tickets in trac. > Also please remember > that, especially if you are looking for things to do that ought > to be easy, the WG needs to verify every one of the errata in > Appendix H, subsection H.1, and all of the changes in subsection > H.2ff to be sure they are what is wanted. Sure, we can do that. I was thinking about doing them all at once (sort of last calls), but doing them one by one is fine with me. Best Regards, Alexey From nobody Thu Oct 15 09:00:26 2020 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 D4A483A08BB for ; Thu, 15 Oct 2020 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=sm6u6W+h; dkim=pass (2048-bit key) header.d=wizmail.org header.b=TTNWhC+V 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 yRTiY3ASR4b9 for ; Thu, 15 Oct 2020 09:00:23 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8ABA3A08B6 for ; Thu, 15 Oct 2020 09:00:22 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=lCkY3bEIE9xGpJ51f57cu10LCrWTxsdvJRAkmdcguRw=; b=sm6u6W+hxd89yPTHan0voBL4p2 /tuLk3P+30bmaDYHBPCCCSYjqz6QQfQDzHYGgzi3/XblU6YF+/Cr6a3o7JBg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=lCkY3bEIE9xGpJ51f57cu10LCrWTxsdvJRAkmdcguRw=; b=TTNWhC+VwnN61+NtihU7bcif1W 8N8bdV3rCTv8FoMyqEUKUuswv3PQUQtX71Pp9flEIQedY+7WAqgduOKzf/bl4gMU10S1w5KZe6Dvv fL6ReMQ92dgDso0MLirfOKoMgiylSJr5KsxXUQRUEWPfneOLUDT24fHes7PuFBr2lqfk8QNNtTASt 6Te20c2UUgnLuSMsNFYl/icJQc1LjKi+mRt83SJwUVt+QBTGb9UpcucL7ESEWubgd4wFPQRTwc+Jp VdzUJU+hIuiCBuywmPX7MnYL5ys7gqWg8myEZzEPyZz1B7gQZtFALMS9yOAq+zfftSWCdRekFOR6e 5lEMcs9A==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.107) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kT5fv-00ENLE-7l for emailcore@ietf.org (return-path ); Thu, 15 Oct 2020 16:00:19 +0000 To: emailcore@ietf.org References: <20201014205302.6810A2370E39@ary.qy> <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> From: Jeremy Harris Message-ID: <1232458e-eb12-e62b-fb20-3cb98796b4d2@wizmail.org> Date: Thu, 15 Oct 2020 17:00:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 16:00:25 -0000 On 15/10/2020 16:02, John C Klensin wrote: > the question (on purely procedural > grounds) is whether there are conforming implementations (either > client or server) out there that depend on not needing to issue > a RSET before a new EHLO when resetting the state is needed. Not sure what counts as "needing to", but I see code in Exim that does issue a non-first EHLO without a preceding RST. -- Cheers, Jeremy From nobody Thu Oct 15 09:15:21 2020 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 CCE5A3A08C1 for ; Thu, 15 Oct 2020 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7_Z-0J55SUV for ; Thu, 15 Oct 2020 09:15:18 -0700 (PDT) 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 8D6463A08C0 for ; Thu, 15 Oct 2020 09:15:18 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kT5uO-0001O9-RO; Thu, 15 Oct 2020 12:15:16 -0400 Date: Thu, 15 Oct 2020 12:15:11 -0400 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org Message-ID: In-Reply-To: <27911bb5-ecbb-dea9-c3e6-a67cecb336c6@isode.com> References: <20201014205302.6810A2370E39@ary.qy> <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> <27911bb5-ecbb-dea9-c3e6-a67cecb336c6@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Issue tracking 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, 15 Oct 2020 16:15:20 -0000 --On Thursday, October 15, 2020 16:44 +0100 Alexey Melnikov wrote: >> Also please remember >> that, especially if you are looking for things to do that >> ought to be easy, the WG needs to verify every one of the >> errata in Appendix H, subsection H.1, and all of the changes >> in subsection H.2ff to be sure they are what is wanted. > > Sure, we can do that. I was thinking about doing them all at > once (sort of last calls), but doing them one by one is fine > with me. All at once works for me. From my standpoint, completely up to you as to whether we do that early or late although I can see some small advantages to stabilizing as much of the document as possible as early as possible. thanks, john From nobody Thu Oct 15 09:59:03 2020 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 486CC3A0CE4 for ; Thu, 15 Oct 2020 09:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3b6PZ7WdVuu for ; Thu, 15 Oct 2020 09:58:54 -0700 (PDT) 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 C17EF3A0CE6 for ; Thu, 15 Oct 2020 09:58:49 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kT6aV-0001if-Bw; Thu, 15 Oct 2020 12:58:47 -0400 Date: Thu, 15 Oct 2020 12:58:42 -0400 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: <1C1ADB5A63FF622622BEF328@PSB> In-Reply-To: <1232458e-eb12-e62b-fb20-3cb98796b4d2@wizmail.org> References: <20201014205302.6810A2370E39@ary.qy> <71f41086-8e83-449a-80e3-30ac3a312e44@www.fastmail.com> <1232458e-eb12-e62b-fb20-3cb98796b4d2@wizmail.org> 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 #2: Repeated Use of 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, 15 Oct 2020 16:59:02 -0000 --On Thursday, October 15, 2020 17:00 +0100 Jeremy Harris wrote: > On 15/10/2020 16:02, John C Klensin wrote: >> the question (on purely procedural >> grounds) is whether there are conforming implementations >> (either client or server) out there that depend on not >> needing to issue a RSET before a new EHLO when resetting the >> state is needed. > > Not sure what counts as "needing to", but I see code > in Exim that does issue a non-first EHLO without a > preceding RST. "Needing to" was poor wording. The questions should have been (1) is someone doing it? to which your answer is "yes" and (2) if the code doesn't believe it clears whatever RSET would have cleared, what does it assume carries over. I think that, in retrospect, what 5321 should have said is not that an in-session EHLO implies RSE but that it subsumes RSET's function, clearing the mail transaction state as well as the session state to (almost) back to when the 220 was received. That was certainly the intent. More probably needs to be done but that specific change would be very easy to make if the WG agrees. john From nobody Thu Oct 15 10:53:02 2020 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 797593A0BFA for ; Thu, 15 Oct 2020 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1gkpe0yENRP for ; Thu, 15 Oct 2020 10:53:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33263A0BE6 for ; Thu, 15 Oct 2020 10:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602784375; bh=6endHTYoNeNgNE5IMxsnuKAazcBUuZLGJBAR2EkFPVo=; l=3129; h=To:References:From:Date:In-Reply-To; b=B2YymlhZALrmZiYQT+qO4Ka/ltnn9+8U2+ToliVj6x4n4BLws7lcqJa2suZXBSNsL /ggWOFR13x5FoRIYwdKqjhUkr1g5y2My2Y4QqmddcJkK3P7dOTtHZcTVXvputfWdOD 9BHUYd2WgGQVVwmJ9k2v4JK5Kd9rPPd8SW3VYV/4XtPh4kYVSMqQGf28cFCks Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC08B.000000005F888C77.00007452; Thu, 15 Oct 2020 19:52:55 +0200 To: Alexey Melnikov , emailcore@ietf.org References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> From: Alessandro Vesely Message-ID: <503aef36-7345-5920-d6c5-5baa7e1cc212@tana.it> Date: Thu, 15 Oct 2020 19:52:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 17:53:02 -0000 On Thu 15/Oct/2020 15:07:00 +0200 Alexey Melnikov wrote: > On Thu, Oct 15, 2020, at 12:29 PM, Alessandro Vesely wrote: >> On Wed 14/Oct/2020 11:27:44 +0200 Alexey Melnikov wrote: >>> Dear WG participants, >>> >>> I would like to start resolving issues raised against rfc5321bis and hopefully >>> the ticket below is an easy one: >>> >>>   While the specification says that an SMTP client's sending EHLO again >>>   after it has been issued (starting an SMTP session and treats it as >>>   if RSET had been sent (closing the session) followed by EHLO, there >>>   are apparently applications, at least some of them involving setting >>>   up of secure connections, in which the second EHLO is required and >>>   does not imply RSET. Does the specification need to be adjusted to >>>   reflect or call out those cases? >>> >> >> The errata that Tony Hansen prepared against RFC 3207 in 2009[*] was >> apparently never posted, although there was rough consensus at the time. > > This is a very good point and something that should be addressed if/when RFC 3207 is revised. > However it is not clear to me that Tony's proposed changes have any implication on this issue. So if you disagree with this statement, can you elaborate about why you think otherwise? I think neither RFC 3207 nor Tony's non-posted errata modify any of RSET and EHLO. I sent that reference as I wasn't able to recall which discussion triggered John's note. Now I got that it was a much more recent proposal to somehow recommend using STARTTLS. However, also in light of Tony's errata, that proposal does still imply RSET for the second EHLO. A possible clarification could say that a new EHLO entails RSET only if it is issued in the middle of a transaction —which is not a customary way to abort a mail transaction: OLD: An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands. NEW: An EHLO command MAY be issued by a client later in the session. If it is issued after a transaction begins the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands. For example, AIUI: C: MAIL FROM:<> S: 250 Ok. C: RCPT TO: S: 250 Ok. C: EHLO mta.example.org S: 250-mail.example.com Ok. S: 250-AUTH LOGIN CRAM-MD5 CRAM-SHA1 S: 250-... S: 250 WHATEVER C: RCPT TO: S: 503 Bad sequence of commands Could the client continue the transaction in case EHLO was rejected? If it could, RSET+EHLO wouldn't be equivalent to just EHLO. Best Ale -- From nobody Thu Oct 15 11:09:42 2020 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 9633F3A0DAD for ; Thu, 15 Oct 2020 11:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=R1i55uWD; dkim=pass (2048-bit key) header.d=taugh.com header.b=HLtnEu6Y 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 FD0f8Z-sSJHC for ; Thu, 15 Oct 2020 11:09:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045F23A0DAB for ; Thu, 15 Oct 2020 11:09:38 -0700 (PDT) Received: (qmail 92016 invoked from network); 15 Oct 2020 18:09:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1676e.5f889061.k2010; bh=DSjYYz9LCX7GGA9sG4PR1dgVfcAGTUQ3iX56/7b5hEY=; b=R1i55uWDROp8JVzDRiUzPNJuUzMv6EPCzk3ikq6S5X0dygADu3QKywdnRpsKbCX36YtHBYCBt/9b4rW5s7GmA86KkU3IzyUSRV/0Ggorq7rzBIdDjAQuWER6o7V0sQdGQuMzhmk9ygQoMe7xsB0RvUFhLS0KeEFFUhKOdtVQ+cxmzFB5pZuejoHRZvwWlaQ5grNwJ3iJrnBxMa03b9jF+ZNhi2SJ8/BpIDp48hXtNcH7swvlpBLwfY2Gyp9Ujrj3r26bMPYDA+7zt0rJhprkmkyPOBQy1W8XtvvZBK6Q9BAEGLAvl1QmHxejAqOKW3bPtXLSQfXd1RmOR5pAWVd03A== 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; s=1676e.5f889061.k2010; bh=DSjYYz9LCX7GGA9sG4PR1dgVfcAGTUQ3iX56/7b5hEY=; b=HLtnEu6YEvMDZQzVYs04OqQ+Yw24nrbyFdNxeyyl860Kxw+Zo5NCcEfuUnzISN8+plZmeeIF9uGZz7R7hf6Eg7N7vqZsW5PBSiWLyagNqZIk9CqTjfSQYQe4SyWOc9ZxVhQ4gB+PI1UDG11Ubx+LEc0VQEkvkt6sgW2a0k4JSydSRr45o5zKXApf9CR/jwe13qIgL7/SNmMfm2OYHfxSVZlxxMYQZKGftY8OXWDAMq0mFoKs9ojV/4PVXd6+QFTwfV68hgFP4lNHt7I9tTU0Lx/6+ZSa8TFqLZ7SSgNCENTbT+GD6GnaU0u+xgNJTlZN3jWhRVSm9HM/BU87T6JDKg== 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 Oct 2020 18:09:36 -0000 Received: by ary.qy (Postfix, from userid 501) id DBE31237B8C7; Thu, 15 Oct 2020 14:09:35 -0400 (EDT) Date: 15 Oct 2020 14:09:35 -0400 Message-Id: <20201015180935.DBE31237B8C7@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <1C1ADB5A63FF622622BEF328@PSB> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 18:09:41 -0000 In article <1C1ADB5A63FF622622BEF328@PSB> you write: >I think that, in retrospect, what 5321 should have said is not >that an in-session EHLO implies RSET but that it subsumes RSET's >function, clearing the mail transaction state as well as the >session state to (almost) back to when the 220 was received. >That was certainly the intent. More probably needs to be done >but that specific change would be very easy to make if the WG >agrees. That sounds correct to me. RFC 3207 sec 4.2 says that after STARTTLS "The server MUST discard any knowledge obtained from the client," which sounds like it also does what RSET does. R's, John From nobody Thu Oct 15 12:27:47 2020 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 CF1BB3A135A for ; Thu, 15 Oct 2020 12:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdV6H_FXuqQS for ; Thu, 15 Oct 2020 12:27:37 -0700 (PDT) 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 D803D3A1353 for ; Thu, 15 Oct 2020 12:27:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kT8uT-00027x-Cy; Thu, 15 Oct 2020 15:27:33 -0400 Date: Thu, 15 Oct 2020 15:27:28 -0400 From: John C Klensin To: Alessandro Vesely , Alexey Melnikov cc: emailcore@ietf.org Message-ID: <25DA1A273F168B5F7496C359@PSB> In-Reply-To: <503aef36-7345-5920-d6c5-5baa7e1cc212@tana.it> References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> <503aef36-7345-5920-d6c5-5baa7e1cc212@tana.it> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 15 Oct 2020 19:27:46 -0000 --On Thursday, October 15, 2020 19:52 +0200 Alessandro Vesely wrote: > I think neither RFC 3207 nor Tony's non-posted errata modify > any of RSET and EHLO. I sent that reference as I wasn't able > to recall which discussion triggered John's note. Now I got > that it was a much more recent proposal to somehow recommend > using STARTTLS. However, also in light of Tony's errata, that > proposal does still imply RSET for the second EHLO. >=20 > A possible clarification could say that a new EHLO entails > RSET only if it is issued in the middle of a transaction > =E2=80=94which is not a customary way to abort a mail = transaction: Keeping in mind that I am reluctant to make any changes that are not necessary and then to make them as narrowly as possible (I will, of course, do what the WG tells me to do while warning of the risk of unintended side-effects from larger changes)... It seems to me that there are only three places where an EHLO can be issued, at least barring some rather strange extensions: (1) Immediately after another EHLO and before MAIL or other negotiations. In this case, there is no mail transaction and, whatever it might mean, RSET is essentially a NOOP. If the server responds with a 5yz reply, I have no idea what the client would do then (just as I have no idea what a client should do it if sends RSET and gets back 5yz), but all of the scenarios I can think of in either case lead to its either sending QUIT or being very uncertain about just what state it is in (so uncertain that I don't think we should try to specify the behavior). If I were writing a client to deal specifically to do with getting a 5yz code after sending either EHLO or RSET, I'd conclude that the server didn't want to talk with me any more and send QUIT with only question being whether I requeued the message or returned it to the sender [1]. (2) After the MAIL command and before either QUIT or RSET. This is, IMO, the only actual interesting case. But, while I now think the text could use some clarification (see earlier note), I think any interpretation other than "clear both the mail transaction and any state information associated with the mail session" leads quickly into silly states. Remembering that nothing in the spec says that, if two different EHLO commands have to get exactly the same response from the server, think about what it would mean if you were partway through a mail transaction, had issued commands that take advantage of extensions the server offered in response to the initial EHLO command, and then sent a new one that got a response that didn't include some of those options. As I said, silly state. (3) After a RSET but before a new MAIL command or QUIT. Odd, but not problematic especially wrt RSET. Ultimately (and this is more or less the clarification I suggested), it would have been reasonable to define a second EHLO as implying QUIT without the request to close and disconnect things at the TCP level as in relation to RSET. But we didn't and, especially given concerns about TLS and the like, I think it would be unwise to go in that direction now. > OLD: > An EHLO command MAY be issued by a client later in the > session. If > it is issued after the session begins and the EHLO command > is > acceptable to the SMTP server, the SMTP server MUST clear > all buffers > and reset the state exactly as if a RSET command had been > issued. In > other words, the sequence of RSET followed immediately by > EHLO is > redundant, but not harmful other than in the performance > cost of > executing unnecessary commands. >=20 > NEW: > An EHLO command MAY be issued by a client later in the > session. If > it is issued after a transaction begins the SMTP server > MUST clear > all buffers and reset the state exactly as if a RSET > command had been > issued. In other words, the sequence of RSET followed > immediately by > EHLO is redundant, but not harmful other than in the > performance cost > of executing unnecessary commands. I am not certain what that accomplishes other than to try to make the case in which the client sends the second EHLO command and gets back a 5yz reply (3yz and 4yz responses make no sense at all). But that case is already covered by more generic text about what clients are expected to do when they get back an unexpected 5yz code -- more or less, they cannot send messages and, unless they have a new plan, they need to send QUIT or RSET. The language circles around a bit to allow issuing multiple RCPT commands even if some of them are rejected, but that is very different from this case. > For example, AIUI: >=20 > C: MAIL FROM:<> > S: 250 Ok. > C: RCPT TO: > S: 250 Ok. > C: EHLO mta.example.org > S: 250-mail.example.com Ok. > S: 250-AUTH LOGIN CRAM-MD5 CRAM-SHA1 > S: 250-... > S: 250 WHATEVER > C: RCPT TO: > S: 503 Bad sequence of commands >=20 > Could the client continue the transaction in case EHLO was > rejected? If it could, RSET+EHLO wouldn't be equivalent to > just EHLO. It can't, at least without getting onto a (very) silly state. Consider: C: EHLO mta.example.org S: 250-mail.example.com Ok. S: 250-AUTH LOGIN CRAM-MD5 CRAM-SHA1 S: 250-... S: 250 WHATEVER C: MAIL FROM: S: 250 Ok. C: RCPT TO: S: 250 Ok. C: EHLO mta.example.org S: 250-mail.example.com Ok. S: 250-AUTH xyz CRAM-MD5 CRAM-SHA1 (because once the client does something=20 (weird, I want an authenticated identity) S: 250-... S: 250 WHATEVER C: RCPT TO: S: 5yz No acceptable authentication So you could, but, if you really want to send a second EHLO, you need to be prepared for the offering of extensions to change and that means resending every command that might (or might choose to not) exercise those options... especially if you don't want to encourage servers to respond to a second EHLO with=20 5yz Do not know why you are doing this unless 5yz-it is a new form of DoS attack so go away or 5yz-try a new transaction (much) later. best, john From nobody Fri Oct 16 01:32:36 2020 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 800F13A0DE6 for ; Fri, 16 Oct 2020 01:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=iTDoOVHE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mv3/u9W7 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 sqR14xD28sTx for ; Fri, 16 Oct 2020 01:32:33 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B14D3A0DE4 for ; Fri, 16 Oct 2020 01:32:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3E48410C1; Fri, 16 Oct 2020 04:32:32 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Fri, 16 Oct 2020 04:32:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=+imWQ7rREO1/YcakmFrYSZD2pJRu1r7 NnZOX64Hcx00=; b=iTDoOVHEPn5sAdYKUzN+Bmw0qwxxY1MdvzUCdSFpdFzEPt1 SsdyHguobqYRgLwrsmIEqlw7QGNgJspK/oZ41nqY4PSt0YENe1WqnjFJF1tB9IeA IY64Y7OhtyA602xBbXPdA1m9vLV1OiDx/6CTXMGR5jnUWGWo5VU7UR69/huXmzxB erEcBUijrXl4xf6Luys4zjRZYwtPxIlFCB6AP2G2JZl7XgEzPdZZWHE87q43FpCj JvIUv6aJz8UjOzSDJwx8VCxVzeB78ISw/lSiosivd1TmN0PxsodFDrhuCK8jEb8n zWR8wyfjvQ4IflFSCeWZL47eOJrUvNNuMllLFvw== 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=+imWQ7 rREO1/YcakmFrYSZD2pJRu1r7NnZOX64Hcx00=; b=mv3/u9W7CU799BsdG0B8kE 4x2bdjh1t9Lih9R2fMZsQjKtWcoM9nQkxUPhd0P+vGtNTq5DeGjaDFzv1M5Jo4EB C5h3IpvgiRn1fkF8n7S+3u7T6sHSxdybdNIBbeyYMIkmwz25PGNOFLgylxKTg1K4 XC5Tdqy5kWID/9eoYwdP649jeovAjPtvJYA4s9tH+bpDO37l4NwyWw76F6bCqbYV oGw2GYHRBBY2o9bn+o9XXowexQTXOoLDd9894zHoAb3z1Mep/0t2nR/rUbOHKNi8 +OLzCwEn1BMGy1MMHL7IBVH//1jcz3gNw7Md+/hH1NEIGswu8ztj6tbBkN7qMWFA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieehgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfekiefg udfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0EB87660069; Fri, 16 Oct 2020 04:32:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> In-Reply-To: <20201015180935.DBE31237B8C7@ary.qy> References: <20201015180935.DBE31237B8C7@ary.qy> Date: Fri, 16 Oct 2020 09:32:10 +0100 From: "Alexey Melnikov" To: "John R Levine" , emailcore@ietf.org Cc: "John C Klensin" Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 08:32:35 -0000 On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: > In article <1C1ADB5A63FF622622BEF328@PSB> you write: > >I think that, in retrospect, what 5321 should have said is not > >that an in-session EHLO implies RSET but that it subsumes RSET's > >function, clearing the mail transaction state as well as the > >session state to (almost) back to when the 220 was received. > >That was certainly the intent. More probably needs to be done > >but that specific change would be very easy to make if the WG > >agrees. > > That sounds correct to me. +1. > RFC 3207 sec 4.2 says that after STARTTLS "The server MUST discard any > knowledge obtained from the client," which sounds like it also does > what RSET does. It does what RSET does and more, e.g. clearing the remembered EHLO hostname. From nobody Fri Oct 16 01:52:05 2020 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 B29F13A0DF9 for ; Fri, 16 Oct 2020 01:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElI4GhOlw_YI for ; Fri, 16 Oct 2020 01:52:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EBC3A0DF8 for ; Fri, 16 Oct 2020 01:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602838317; bh=+vwPgeoLFzGwtloF7rUJ71aFoGch3pCAyhUYqL/cMQY=; l=2155; h=To:Cc:References:From:Date:In-Reply-To; b=AWbD5Q8CD/RS2uW+CjeoHy/trB3+SCMRIt53VWgnwhpi0pgFij6msd2XJLXxsmqoe iJ6oG66Gs46fP0zZZZmdnWjWoklQEFY7tV2hYUmhklalbnv9aGKbJ2G7ny8tgPSmtW qiNTvb6cg3JTFBQPQJF7bxcPte0WlCo8sWf55zaw9HaGcyfZwyqBus/EILXao Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005F895F2D.00000304; Fri, 16 Oct 2020 10:51:57 +0200 To: John C Klensin Cc: emailcore@ietf.org References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> <503aef36-7345-5920-d6c5-5baa7e1cc212@tana.it> <25DA1A273F168B5F7496C359@PSB> From: Alessandro Vesely Message-ID: <4c9ed519-6e35-87e2-f6fe-9706e0730a77@tana.it> Date: Fri, 16 Oct 2020 10:51:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <25DA1A273F168B5F7496C359@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 08:52:03 -0000 On Thu 15/Oct/2020 21:27:28 +0200 John C Klensin wrote: > --On Thursday, October 15, 2020 19:52 +0200 Alessandro Vesely wrote: > >> >> A possible clarification could say that a new EHLO entails >> RSET only if it is issued in the middle of a transaction >> —which is not a customary way to abort a mail transaction: > > It seems to me that there are only three places where an EHLO > can be issued, at least barring some rather strange extensions: > > [...] > > (2) After the MAIL command and before either QUIT or RSET. This > is, IMO, the only actual interesting case. But, while I now > think the text could use some clarification (see earlier note), > I think any interpretation other than "clear both the mail > transaction and any state information associated with the mail > session" leads quickly into silly states. Remembering that > nothing in the spec says that, if two different EHLO commands > have to get exactly the same response from the server, think > about what it would mean if you were partway through a mail > transaction, had issued commands that take advantage of > extensions the server offered in response to the initial EHLO > command, and then sent a new one that got a response that didn't > include some of those options. As I said, silly state. Undoubtedly. Yet, there are various places in the spec where EHLO is mentioned as a valid way to abort a transaction. Would it be too large a change to ban this? At least, shouldn't the spec mention that issuing EHLO during a transaction can lead to some kind of implementation defined state? > So you could, but, if you really want to send a second EHLO, you > need to be prepared for the offering of extensions to change and > that means resending every command that might (or might choose > to not) exercise those options... especially if you don't want > to encourage servers to respond to a second EHLO with > > 5yz-Do not know why you are doing this unless > 5yz-it is a new form of DoS attack so go away or > 5yz try a new transaction (much) later. Yeah, that should be the recommended response :-) Best Ale -- From nobody Fri Oct 16 01:53:51 2020 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 DE0823A0DF8 for ; Fri, 16 Oct 2020 01:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=G/JnYLCR; dkim=pass (2048-bit key) header.d=wizmail.org header.b=e/QrgRZq 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 OaXzRc1Uwi6M for ; Fri, 16 Oct 2020 01:53:47 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362473A0DEF for ; Fri, 16 Oct 2020 01:53:46 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=WTM2nm2a2JKjKrMjr3JJl2ueN37yn0k60i/g4+6T35g=; b=G/JnYLCRIJEijpGV2k2fSj5PCM 60MO5T8Ws+mS1RjL7d7Ld2NExiKiWp/YGeHpiQLW0jnGOBD9TdTMQRKvwkCQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=WTM2nm2a2JKjKrMjr3JJl2ueN37yn0k60i/g4+6T35g=; b=e/QrgRZql/ETg37kxHqWgSGtRc VZRqpC0QjLDHHabaD3VBphPJemT4I9X4Wdf2LfDL5K1AoRD0XYghANpBAqnIvwWlgM5b/Xm5Ycsjk h/HuZcJiY7NhyT+TAVdPVnkMXBD4bZcJlHTOLqF/rjSVg4jT9lF0AL58bzI9JeSNLeVSp7/g7ciwu felL6i2ID3Ft2TYbbzRQlWB41L58YnsOJ7hz3rJfYox+POw8MKeFNezM5Y7803Jf7kG6b8sFk1OJA m0AYlEsXXc1OK8+JaYA3ELjk2OynlLj8KDhfRhuX+QqZhlsFlgvLDTw0FF7CniD0tCCc99XTLMw4M Q4g/uCNA==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.107) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kTLUe-00Ef4S-Hn for emailcore@ietf.org (return-path ); Fri, 16 Oct 2020 08:53:44 +0000 To: emailcore@ietf.org References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <5F883C53.8020909@isdg.net> From: Jeremy Harris Message-ID: <683c5ee3-0781-3e53-c0f6-837e70da1bd2@wizmail.org> Date: Fri, 16 Oct 2020 09:53:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <5F883C53.8020909@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 08:53:49 -0000 On 15/10/2020 13:10, Hector Santos wrote: > On 10/14/2020 5:27 AM, Alexey Melnikov wrote: >>    While the specification says that an SMTP client's sending EHLO again >>    after it has been issued (starting an SMTP session and treats it as >>    if RSET had been sent (closing the session) > I do not think our smtp "resets" the TLS channel once established. I'm with Hector here. I suggest avoiding the use of the word "session" above, replacing it with "transaction" - meaning the MAIL, RCPT, DATA sequence but excluding the TCP connection startup/teardown, TLS ditto, and AUTH. There can be several transactions within a connection, and the connotations for "session" that I have are far more closely associated with the connection. I don't think that an extra EHLO between transactions is a problem (like RSET, mostly pointless in that placement). -- Cheers, Jeremy From nobody Fri Oct 16 04:03:25 2020 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 A7E443A0E91 for ; Fri, 16 Oct 2020 04:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Np7ojEK5zLqn for ; Fri, 16 Oct 2020 04:03:21 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 5D6153A0E90 for ; Fri, 16 Oct 2020 04:03:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQV2996DW000BA9M@mauve.mrochek.com> for emailcore@ietf.org; Fri, 16 Oct 2020 03:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1602845897; bh=HJORQpkkizdLCskpPgxKWvw035OOYS0c2+Q2rPB9W8I=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=iM946PEYOMJH+d888BJHvXyRZJV0a3cieyguqRdVN+KMK14lEJ8ObneI2kDMrRLNG L9B0Q9ZrFmSInLW5atDhTNWss/D+L2bYfQ9exPdD79TPIy8WTPSO/DnSWNiPVLOjeq y0W6SxOS2RbyXMw5Pqvfq916C0aSu0n0Lw/wtXZM= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Fri, 16 Oct 2020 03:58:15 -0700 (PDT) Cc: John C Klensin , emailcore@ietf.org Message-id: <01RQV296T2KC005PTU@mauve.mrochek.com> Date: Fri, 16 Oct 2020 03:43:08 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 16 Oct 2020 10:51:57 +0200" <4c9ed519-6e35-87e2-f6fe-9706e0730a77@tana.it> References: <8dd9178d-7bb0-15be-d6b5-df94db551839@isode.com> <8589eb09-889d-92ab-b824-a93e4f3c315b@tana.it> <12b759d0-def3-48c5-9138-23f38ea2e093@www.fastmail.com> <503aef36-7345-5920-d6c5-5baa7e1cc212@tana.it> <25DA1A273F168B5F7496C359@PSB> <4c9ed519-6e35-87e2-f6fe-9706e0730a77@tana.it> Alessandro Vesely To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 11:03:23 -0000 > On Thu 15/Oct/2020 21:27:28 +0200 John C Klensin wrote: > > --On Thursday, October 15, 2020 19:52 +0200 Alessandro Vesely wrote: > > > >> > >> A possible clarification could say that a new EHLO entails > >> RSET only if it is issued in the middle of a transaction > >> —which is not a customary way to abort a mail transaction: > > > > It seems to me that there are only three places where an EHLO > > can be issued, at least barring some rather strange extensions: > > > > [...] > > > > (2) After the MAIL command and before either QUIT or RSET. This > > is, IMO, the only actual interesting case. But, while I now > > think the text could use some clarification (see earlier note), > > I think any interpretation other than "clear both the mail > > transaction and any state information associated with the mail > > session" leads quickly into silly states. Remembering that > > nothing in the spec says that, if two different EHLO commands > > have to get exactly the same response from the server, think > > about what it would mean if you were partway through a mail > > transaction, had issued commands that take advantage of > > extensions the server offered in response to the initial EHLO > > command, and then sent a new one that got a response that didn't > > include some of those options. As I said, silly state. Well, on the one hand there is a possibility of silly states, but on the other hand there's the possibility of legitimate state changes. For example, suppose someone came up with an extension that reported remaining resources available to the session/connection/whatever. (Such extensions have been proposed on more than one occasion to report remaining transactions, remaining time, etc..) In such a case it's entirely reasonable for the response to change after a transaction or even a transaction attempt. > Undoubtedly. Yet, there are various places in the spec where EHLO is mentioned > as a valid way to abort a transaction. Would it be too large a change to ban > this? At least, shouldn't the spec mention that issuing EHLO during a > transaction can lead to some kind of implementation defined state? I don't think that's useful or a good idea. If your implementation does something strange with this sequence - and we actually had exactly this happen - I suggest treating it as a bug and fixing it. That said, since I can't imagine writing a client that used EHLO rather than RSET to terminate a transaction, I guess I can live with such text. The one case I can't abide with is not reseting the transaction state when either a security layer is added or the authentication state changes. Permissions can and do change as a result of such things, and that includes disallowing stuff that would have been allowed in an unprotected/unauthenticated state. FWIW, Mark Crispin and I had a big disagreement about this. He thought doing an AUTH in the middle of a transaction after receiving some sort of "not authorized" indicator made perfect sense, whereas I thought (and still think) it's a cute idea with no practical value and huge implementation costs. Ned From nobody Fri Oct 16 10:16:35 2020 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 F1D863A0FE4 for ; Fri, 16 Oct 2020 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=N1DQZI8A; dkim=pass (2048-bit key) header.d=taugh.com header.b=kB+BsWtE 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 LCZyJDl2t141 for ; Fri, 16 Oct 2020 10:16:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD6A3A0FDF for ; Fri, 16 Oct 2020 10:16:30 -0700 (PDT) Received: (qmail 5761 invoked from network); 16 Oct 2020 17:16:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=167f.5f89d56b.k2010; bh=hLU0FppLNiCkT97JOX7HxoTilHBkijoLEsBzA4yq6Wc=; b=N1DQZI8ATOTJYrY7qsSM1ViHc+Lj1xD8JopbXFfyUhwqk4TtmytJCWQo8Jp9RkHKpNlUEs+tVF9lbJYfQREvkGvs0Po+itPrFLRIFoLQLzoO3Kq+YlqaEWKw0vNHg6OCNx2L65a/Uzg6SqEZuY+zd/oQgz/fgQ3F8dWT+KgnwQvaMurSjXrW3CMlSl4JvPVncwgWtGX+/omeoZYah4kiplJttXbCyFR7kvDOj1tqozvQJph6iR230557Z1pRCmveyTm0hs2V1FK9FeTsPqq0R8WAZ8OzWcPxwq5UuOsbOexvEP86DijNAqcL0aCagG6XinMbf3JhhVKf3mKzH3iyjg== 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; s=167f.5f89d56b.k2010; bh=hLU0FppLNiCkT97JOX7HxoTilHBkijoLEsBzA4yq6Wc=; b=kB+BsWtE1nXibBXE6krn759rQMPTDRcvVjYu7DzFEeo9cFcDpTcpBQihtV3fbxwLxw18iZv/eZDmj3Hkq9lQCfXnmBXpLqRKXLIGJ+jSaoIPjVP1msBoGiX46oGm1a5OBVeIX6YgDKfYs0PnJ6mGnNywsCdD7FsiKfbJF0zfhHfUDHet8607viJ1Y6d/j2EalbSXAoNq7VL1TN2s5MrVB8W1tPC8ivHLr14TTJhhOC+/sJuo+CeJfIPjDSHehRO3rloGEscSvYVzyfnbvWI3CoDPd3zY4VP2HMIl+9B5ZU58iF/4ttJyIxTFuYNWfn1h3jUf9/qd/L5qxnkeYPUEWQ== 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 Oct 2020 17:16:27 -0000 Received: by ary.qy (Postfix, from userid 501) id 9C8DD23849F1; Fri, 16 Oct 2020 13:16:26 -0400 (EDT) Date: 16 Oct 2020 13:16:26 -0400 Message-Id: <20201016171626.9C8DD23849F1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vesely@tana.it In-Reply-To: <4c9ed519-6e35-87e2-f6fe-9706e0730a77@tana.it> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 17:16:33 -0000 In article <4c9ed519-6e35-87e2-f6fe-9706e0730a77@tana.it> you write: >Undoubtedly. Yet, there are various places in the spec where EHLO is mentioned >as a valid way to abort a transaction. Would it be too large a change to ban >this? At least, shouldn't the spec mention that issuing EHLO during a >transaction can lead to some kind of implementation defined state? No, that would be a rather incompatible change. If there actually are SMTP implementations that depend on EHLO not doing a reset, I think they should fix their code. Remember, the point of a standard is to tell people how to interoperate, and the best way to interoperate is to do what the fripping spec tells you to do. From nobody Fri Oct 16 10:45:35 2020 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 A1D193A0A2D for ; Fri, 16 Oct 2020 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=GR/yyc4V; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=TcSuQkIK 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 P-hyTvq2cNoO for ; Fri, 16 Oct 2020 10:45:31 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2923A0A16 for ; Fri, 16 Oct 2020 10:45:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8496; t=1602870326; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=YWBACNMlUFgsRCKtYhqjhbdQlHE=; b=GR/yyc4V16rn0xuFqvGrQ0DPEOzkCD1YGiDIWipl1yqzve+IjYJd2AOwrO9d8M yMKvfdpH9dt640EZDXdnR6zZy5GOqpyjgGovb5F/gTeGonCITbRouCdKXhy8tXRJ p90Sxu2JmJzIpkOVa2S7hM62MdS+oV4C3farCDHHKzaAo= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 16 Oct 2020 13:45:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 605430880.6831.2560; Fri, 16 Oct 2020 13:45:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8496; t=1602870079; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=w/RRpfc 6SE0KuEjK20u4s1JZpyDh7jEuupRrEMrhiC0=; b=TcSuQkIKq9DezwUwLcSmGvm vbA9hlucgsNzC+YleTL7/21oZ/p+UCEPD9hUpa1xSPB8byXqXXJnkf32wwlWd5qG POGh0eO+eC/qjjurR6G67dRAhA/DDofKarNKcaB6pQ3PKJhRq+duA2Nb23GwMpgR H+VBghYKYE4i88ZrJZho= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 16 Oct 2020 13:41:19 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 472350766.1.13308; Fri, 16 Oct 2020 13:41:18 -0400 Message-ID: <5F89DC39.9040505@isdg.net> Date: Fri, 16 Oct 2020 13:45:29 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> In-Reply-To: <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 17:45:34 -0000 On 10/16/2020 4:32 AM, Alexey Melnikov wrote: > On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: >> In article <1C1ADB5A63FF622622BEF328@PSB> you write: >>> I think that, in retrospect, what 5321 should have said is not >>> that an in-session EHLO implies RSET but that it subsumes RSET's >>> function, clearing the mail transaction state as well as the >>> session state to (almost) back to when the 220 was received. >>> That was certainly the intent. I am not sure if that was the intent. But a solid SMTP server isn't going complain too by handling a reissued EHLO. >>> More probably needs to be done >>> but that specific change would be very easy to make if the WG >>> agrees. >> >> That sounds correct to me. > > +1. We don't know what the SMTP Client state machine was programmed to do. I rarely see EHLO reissued after a RSET. > >> RFC 3207 sec 4.2 says that after STARTTLS "The server MUST discard any >> knowledge obtained from the client," which sounds like it also does >> what RSET does. > > It does what RSET does and more, e.g. clearing the remembered EHLO hostname. Why would the machine name, the domain name or ip-literal need to be cleared? It has no purpose to do so. It won't change. That's a fixed item. I believe the SMTP 20 years old protocol State Machine is well defined otherwise interoperability would suffer. I am not expecting to be changing my SMTP state machine with this RFC5321bis work. I think the best we can do is codify the SMTP client expected state machine command order and reemphasize SMTP server flexibility to handle any SMTP client command order which may diff from the norm but do not necessarily violate the specs nor harm the ability to perform a transaction -- Postel's Principle. There could also be security reasons for not clearing the client machine domain name. There other security considers and the one that comes to mind is the attempt to bypass a temporary reject behavior, i.e. a 4yz policy-based Greylisting response at DATA and the client attempt to do another transactions to get around the greylisting. Finally, most legacy SMTP server still have an human interface for the CLI-based protocol client/server model. wcSMTP still has an HELP: 220-home.winserver.com Wildcat! ESMTP Server v8.0.454.10 ready 220-************** WARNING: FOR AUTHORIZED USE ONLY! ********************** 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS * 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED * 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS * 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * 220 ************************************************************************ HELP 214-Commands: 214-HELO EHLO MAIL RCPT DATA RSET 214-NOOP ETRN QUIT HELP AUTH STARTTLS 214-For more info use "HELP ". 214 End of HELP info HELP RSET 214-Arguments: 214- RSET 214- Resets and clears ALL current mail buffers. 214 End of HELP info Going back to RFC821: RESET (RSET) This command specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data must be discarded, and all buffers and state tables cleared. The receiver must send an OK reply. RFC2821 (same in RFC5321) was updated with additional verbiage but at the end of the day, its the same as 821. The SMTP client/server state machine has to be prepared for all situations and I believe we got that all done right. Even if the EHLO data is cleared, the SMTP state machine will handle the situation when the client issues C: RSET S: 250 ok C: MAIL FROM: S: 250 OK but if we clear the EHLO with the RSET, then we may have this: C: RSET S: 250 ok C: MAIL FROM: S: 503 Send EHLO first and the question is not, are legacy clients ready to be loosely driven to start a EHLO. Here is an interesting session trace I see in today's log: ************************************************************************** Wildcat! ESMTP Server v8.0.454.10 SMTP log started at Fri, 16 Oct 2020 00:56:49 Connection Time: 20201016 00:56:49 cid: 00001AAF tid: 00000EEC SSL-Enabled=YES No-Quit-Cancel=OFF Receiver-Bin=ON Client IP: 23.90.57.244:61533 (unknown) Host IP: 76.245.57.69:25 00:56:49.295 ** WCX Process: smtpcmd-connect ret: -1 00:56:49.295 S: 220-mail.winserver.com Wildcat! ESMTP Server v8.0.454.10 ready 00:56:49.295 S: 220-************** WARNING: FOR AUTHORIZED USE ONLY! ********************** 00:56:49.295 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS * 00:56:49.295 S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED * 00:56:49.295 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS * 00:56:49.295 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * 00:56:49.295 S: 220 ************************************************************************ 00:56:49.414 C: EHLO cardsnarlspy.com 00:56:49.420 ** WCX Process: smtpcmd-check-ehlo ret: -1 00:56:49.420 S: 250-mail.winserver.com, Pleased to meet you. 00:56:49.420 S: 250-SIZE 102400000 00:56:49.420 S: 250-8BITMIME 00:56:49.420 S: 250-SUBMITTER 00:56:49.420 S: 250-ETRN 00:56:49.420 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 00:56:49.420 S: 250-AUTH=LOGIN 00:56:49.420 S: 250-HELP 00:56:49.420 S: 250 STARTTLS 00:56:49.578 C: MAIL FROM: BODY=8BITMIME SUBMITTER=rockhard@cardsnarlspy.com 00:56:49.579 S: 250 ... Sender validation pending. Continue. (8BITMIME ok) 00:56:49.638 C: RCPT TO: 00:56:49.639 S: 550 User not a member of domain: 00:56:49.715 C: RSET 00:56:49.715 S: 250 Reset State #1 00:56:49.775 C: MAIL FROM: BODY=8BITMIME SUBMITTER=rockhard@cardsnarlspy.com 00:56:49.776 S: 250 ... Sender validation pending. Continue. (8BITMIME ok) 00:56:49.833 C: RCPT TO: 00:56:49.834 S: 550 User not a member of domain: 00:56:49.896 C: RSET 00:56:49.896 S: 250 Reset State #2 00:56:49.953 C: MAIL FROM: BODY=8BITMIME SUBMITTER=rockhard@cardsnarlspy.com 00:56:49.954 S: 250 ... Sender validation pending. Continue. (8BITMIME ok) 00:56:50.011 C: RCPT TO: 00:56:50.082 ** WCX Process: wcsap ret: -1 (70 msecs) 00:56:50.082 S: 250 ... Recipient ok 00:56:50.145 C: DATA 00:56:50.145 S: 354 Start mail input; end with . 00:56:50.324 ** end of data received. (bytes: 34105) (193.7 K/s) 00:56:50.513 ** Reject: Rule#5 => Email contain(s) "penis" 00:56:50.513 ** WCX Process: SmtpFilterHookLoader ret: 0 (189 msecs) 00:56:50.513 ** Authentication-Results: dkim.winserver.com; 00:56:50.513 ** dkim=fail (DKIM_SIGNATURE_BAD) header.d=cardsnarlspy.com header.s=mail header.i=rockhard@cardsnarlspy.com; 00:56:50.513 ** dmarc=dkim-fail policy=quarantine author.d=cardsnarlspy.com signer.d=cardsnarlspy.com (originating signer); 00:56:50.514 S: 554 Message Not Accepted by filter. 00:56:50.571 C: RSET 00:56:50.572 S: 250 Reset State #3 00:56:50.636 C: MAIL FROM: BODY=8BITMIME SUBMITTER=rockhard@cardsnarlspy.com 00:56:50.636 S: 250 ... Sender validation pending. Continue. (8BITMIME ok) 00:56:50.693 C: RCPT TO: 00:56:50.694 S: 550 User not a member of domain: 00:56:50.758 C: RSET 00:56:50.758 S: 250 Reset State #4 00:56:50.816 C: MAIL FROM: BODY=8BITMIME SUBMITTER=rockhard@cardsnarlspy.com 00:56:50.816 S: 250 ... Sender validation pending. Continue. (8BITMIME ok) 00:56:50.878 C: RCPT TO: 00:56:50.879 S: 550 User not a member of domain: 00:56:50.947 C: QUIT 00:56:50.948 S: 221 closing connection 00:56:50.948 ** Completed. Elapsed Time: 1670 msecs Oh yes, wcSMTP also has a RSET limit... looking at the default limit ... DWORD MaxRSET = 10; // 452.5 06/08/08 03:32 pm Option to change it via undocumented registry. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Oct 16 15:48:57 2020 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 B71393A05D0 for ; Fri, 16 Oct 2020 15:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR0FAGdAdMC5 for ; Fri, 16 Oct 2020 15:48:53 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6E23A0489 for ; Fri, 16 Oct 2020 15:48:52 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 785681C74; Sat, 17 Oct 2020 00:48:50 +0200 (CEST) Date: Sat, 17 Oct 2020 00:48:50 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20201016224850.GA16002@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <5F89DC39.9040505@isdg.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 22:48:56 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-10-16 13:45:29 -0400, Hector Santos wrote: > On 10/16/2020 4:32 AM, Alexey Melnikov wrote: > > On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: > > > RFC 3207 sec 4.2 says that after STARTTLS "The server MUST discard any > > > knowledge obtained from the client," which sounds like it also does > > > what RSET does. > >=20 > > It does what RSET does and more, e.g. clearing the remembered EHLO host= name. >=20 > Why would the machine name, the domain name or ip-literal need to be > cleared? It has no purpose to do so. It won't change. That's a fixed ite= m. Because the EHLO/HELO command includes a new one. Unless your server keeps a list of EHLO names, it can only either keep the old one or replace it with the new one. (In almost all cases, those will be identical and I can't think of a plausible reason why it should change within a single connection, but if it does change it's probably better to use the new one.) > Even if the EHLO data is cleared, the SMTP state machine will handle the > situation when the client issues >=20 > C: RSET > S: 250 ok > C: MAIL FROM: > S: 250 OK >=20 > but if we clear the EHLO with the RSET, then we may have this: >=20 >=20 > C: RSET > S: 250 ok > C: MAIL FROM: > S: 503 Send EHLO first That's not what we are talking about. We are talking about using EHLO/HELO instead of RSET. So C: EHLO mail.example.com S: 250 ... C: MAIL FROM: S: 550 Sender blacklisted C: EHLO mail.example.com S: 250 ... C: MAIL FROM: S: 250 Sender acceptable should work. hp > Here is an interesting session trace I see in today's log: Not sure what's interesting or even relevant. Care to explain? --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAl+KI00ACgkQ8g5IURL+ KF3VIQ/8DgBk7w/lU34Gg3URY0uwDAzAMcOV1PahR7zmMBF2keCGXvUZ3oDKnjfm eLA7rUZUd3Dkz0hGcQcTxzfYqZQ1oavs2un0dtbO7oANCKfvhD8btA/pH7NTsNPZ PF2J4WSNqIqL4CBNOXGb2blLqTNMvGRoAq+422tqSYPbDRQtLRk/PecrVzJI96Fg xoGiLTs+OpEVTRjbOqp//pjgU0A2wm3ZWIaTjw1C7TaroxONTPie+/mCM//isaWK oh07z3DFK37aucGzW1nxJHJZRM0EPiQoWHq1Q7J70l7wicAYViH34vAob9NjvOqF 7ltjh0NpSeJh7dX/nSkIcI3dVYJQe5RVVdULhU1ui1CeAbgQBgvMrqEYUNX1rNbt IR0lp3YeX+Dzg2vEs40LrAmRFTB1rjuSbDTGieFL+bEi1hccCrhNqNDxL58SxN4b UrQgJOLtjh5AMrOpZ9FefUJetI6+JcpjNCPVQ+COGZUZ00wfOJRPQXbvMwRC82GM 6hyblkWQT6FRjkOPCzus5j3W1Ss6hc+6PpX6O8bkpXrOWaQWYExlZ09kDCrqUbL0 4B/JdXuYqSf94CuDou1RT11s1qdXgnUdsDVJoIRzJdK3oYyYEpj7CAj3OioTsWmV EQOhsFAon8Zq4Wi1d26azKBDzU82buMp1wu13TqQYfsjpLgY1UQ= =oM4I -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From nobody Fri Oct 16 16:29:45 2020 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 95B643A0977 for ; Fri, 16 Oct 2020 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4ty77HIxfuz for ; Fri, 16 Oct 2020 16:29:41 -0700 (PDT) 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 55BC73A0965 for ; Fri, 16 Oct 2020 16:29:41 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kTZAJ-0007io-GB; Fri, 16 Oct 2020 19:29:39 -0400 Date: Fri, 16 Oct 2020 19:29:33 -0400 From: John C Klensin To: "Peter J. Holzer" cc: emailcore@ietf.org Message-ID: <0A01EB8802E261F7D7DA2EB4@PSB> In-Reply-To: <20201016224850.GA16002@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> 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 #2: Repeated Use of 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: Fri, 16 Oct 2020 23:29:44 -0000 Peter and Hector, AFAICT, what makes this complicated isn't what the client/sender sends, it is that nothing obligates the server to return the same set of option offerings twice. Since the options that are in effect can affect what commands and arguments the client can send, that is potentially a big deal. So, RSET closes and resets a mail transaction, losing any information if MAIL, RSET, etc., commands. Sending EHLO once that mail transaction has started (e.g., the MAIL command is sent) is a superset of the RSET behavior but also clears the options that were advertised (and may or may not have been accepted) the first time around. A second EHLO being sent right after the first one (before any other functional commands) seems rather silly but, but, if, e.g., the sequence were EHLO ... AUTH ... EHLO... MAIL ... I'd expect the second EHLO to clear AUTH and whatever it did (which RSET in a mail transaction after the MAIL command was issued would not) and basically require starting over. That is more or less what the text was intended to say and says now (even if not clearly) and, the more I think about it, I cannot make sense of any other interpretation that would not constitute an incompatible change that might disrupt conforming implementations. The text is not as clear as it might be and I propose that we fix that as I outlined in an earlier note. Now the question, at least IMO, is whether anyone disagrees with that and if so, why, especially after noting that an incompatible change that affects existing deployed implementations would reset 5321bis to Proposed and is hence out of scope and a showstopper for the WG. Personally, I wouldn't lose a lot of sleep if something arose that was important enough to justify stopping the WG, publishing a draft with the changes, waiting six months or as long as it takes to demonstrate deployment and interoperability, and then returning to 5321bis but, IMO, the threshold for "important enough" to justify that should be really high, not just, e.g., a matter of taste and aesthetics. john --On Saturday, October 17, 2020 00:48 +0200 "Peter J. Holzer" wrote: > On 2020-10-16 13:45:29 -0400, Hector Santos wrote: >> On 10/16/2020 4:32 AM, Alexey Melnikov wrote: >> > On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: >> > > RFC 3207 sec 4.2 says that after STARTTLS "The server >> > > MUST discard any knowledge obtained from the client," >> > > which sounds like it also does what RSET does. >> > >> > It does what RSET does and more, e.g. clearing the >> > remembered EHLO hostname. >> >> Why would the machine name, the domain name or ip-literal >> need to be cleared? It has no purpose to do so. It won't >> change. That's a fixed item. > > Because the EHLO/HELO command includes a new one. Unless your > server keeps a list of EHLO names, it can only either keep the > old one or replace it with the new one. (In almost all cases, > those will be identical and I can't think of a plausible > reason why it should change within a single connection, but if > it does change it's probably better to use the new one.) > > >> Even if the EHLO data is cleared, the SMTP state machine will >> handle the situation when the client issues >> >> C: RSET >> S: 250 ok >> C: MAIL FROM: >> S: 250 OK >> >> but if we clear the EHLO with the RSET, then we may have this: >> >> >> C: RSET >> S: 250 ok >> C: MAIL FROM: >> S: 503 Send EHLO first > > That's not what we are talking about. We are talking about > using EHLO/HELO instead of RSET. > > So > > C: EHLO mail.example.com > S: 250 ... > C: MAIL FROM: > S: 550 Sender blacklisted > C: EHLO mail.example.com > S: 250 ... > C: MAIL FROM: > S: 250 Sender acceptable > > should work. > > hp > >> Here is an interesting session trace I see in today's log: > > Not sure what's interesting or even relevant. Care to explain? From nobody Fri Oct 16 16:42:56 2020 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 D9C073A0829 for ; Fri, 16 Oct 2020 16:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npo16uRV5qC3 for ; Fri, 16 Oct 2020 16:42:52 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76AA3A09FF for ; Fri, 16 Oct 2020 16:42:49 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id E3E802A00; Sat, 17 Oct 2020 01:42:47 +0200 (CEST) Date: Sat, 17 Oct 2020 01:42:47 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20201016234247.GA24097@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <0A01EB8802E261F7D7DA2EB4@PSB> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 16 Oct 2020 23:42:55 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-10-16 19:29:33 -0400, John C Klensin wrote: > AFAICT, what makes this complicated isn't what the client/sender > sends, it is that nothing obligates the server to return the > same set of option offerings twice. Since the options that are > in effect can affect what commands and arguments the client can > send, that is potentially a big deal. Yup. Although I guess that client which does send repeated EHLOs is prepared to deal with that (presumably by only using the latest response.) > So, RSET closes and resets a mail transaction, losing any > information if MAIL, RSET, etc., commands. Sending EHLO once > that mail transaction has started (e.g., the MAIL command is > sent) is a superset of the RSET behavior but also clears the > options that were advertised (and may or may not have been > accepted) the first time around. A second EHLO being sent right > after the first one (before any other functional commands) seems > rather silly but, but, if, e.g., the sequence were > EHLO ... > AUTH ... > EHLO... > MAIL ... >=20 > I'd expect the second EHLO to clear AUTH and whatever it did > (which RSET in a mail transaction after the MAIL command was > issued would not) and basically require starting over. That's what I would have assumed, too. But several people seemed to be quite confident that AUTH data in particular should not be cleared by a repeated EHLO, so I assumed that maybe the RFC for AUTH explicitely specified that and intended to reread that before discussing that claim. (I could seed that returning a different response to EHLO after AUTH might be potentially useful, but most clients probably aren't prepared to reissue EHLO to see if anything has changed (except after STARTTLS, where they have to.) hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAl+KL/MACgkQ8g5IURL+ KF38wQ/+L161veGwnjCkUCJxFLAh/3XHaqffI1MkRlr4NTBjFfTasGeEU8M31lf1 pPBmXZdaiSclmzZ4GlkZogY9PWrGrVZpe7fRSaRZmPvmPKyy0yn3iE+3OTwssqeG heUE4bhvD0YBFl3gXECYQlfOUcXtJVIugT4Dg9+OHEQjKUKXIPxcuH5gHn7AzM5V tzwjjN2cR9Uca4sPKihFgKGkDS1MOeZWDDHoq29+W6MlEdOdjXeXNv9FBkQHR+m2 P5It3fvz2bzHlgiVcNBbNZO2ISc0L6SXBNFNi55mZpgiBt2D+2SCFfSnhf02xrA0 g2QHKEMgrtaY52T5O2dfWRqe3uk3UgZKHPQQH6a2YBhXwi0f9IMuxsS5up/XIDdW +Sx1FyEXj/g3f4C4Tp+sH8JEihFBDXxapoo6T4519PUSCmtDlbDkLhJrReDc8tWn Q23P4bE7cXCBtbIDetDhM/MOwo2QjlGpKXnC+9yREcYGcJvCFHh+N92h0/gLwUFd Z5vpBqRsvl/vL+0TV6+E1a+AEj/sAhsnzWAP/tBHaxAbVti50ii23nGe/+uAjEDp F2nRWCgjFC4nen2RZo+XeM8VoluDwVTFmqvjMeqfJRkDsrs6svet8kcnNvop+JRs ZWpxLwgseLQJoE0wTqgosnlNtUKMqKPzIrNr2ngf2Du4ggsHJ/M= =Ekuu -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From nobody Fri Oct 16 19:28:35 2020 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 CC1483A0B01 for ; Fri, 16 Oct 2020 19:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si1XYb5YmQ_6 for ; Fri, 16 Oct 2020 19:28:32 -0700 (PDT) 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 3DCED3A0AFD for ; Fri, 16 Oct 2020 19:28:32 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kTbxO-000895-MC; Fri, 16 Oct 2020 22:28:30 -0400 Date: Fri, 16 Oct 2020 22:28:24 -0400 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: <0C3EDB08A5A25471A256B4AE@PSB> In-Reply-To: <20201016234247.GA24097@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> 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 #2: Repeated Use of 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, 17 Oct 2020 02:28:34 -0000 --On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer" wrote: > On 2020-10-16 19:29:33 -0400, John C Klensin wrote: >> AFAICT, what makes this complicated isn't what the >> client/sender sends, it is that nothing obligates the server >> to return the same set of option offerings twice. Since the >> options that are in effect can affect what commands and >> arguments the client can send, that is potentially a big deal. > > Yup. Although I guess that client which does send repeated > EHLOs is prepared to deal with that (presumably by only using > the latest response.) Indeed. But that would, again, be consistent with what I think the text was intended to say. >> So, RSET closes and resets a mail transaction, losing any >> information if MAIL, RSET, etc., commands. Sending EHLO once >> that mail transaction has started (e.g., the MAIL command is >> sent) is a superset of the RSET behavior but also clears the >> options that were advertised (and may or may not have been >> accepted) the first time around. A second EHLO being sent >> right after the first one (before any other functional >> commands) seems rather silly but, but, if, e.g., the sequence >> were EHLO ... >> AUTH ... >> EHLO... >> MAIL ... >> >> I'd expect the second EHLO to clear AUTH and whatever it did >> (which RSET in a mail transaction after the MAIL command was >> issued would not) and basically require starting over. > > That's what I would have assumed, too. But several people > seemed to be quite confident that AUTH data in particular > should not be cleared by a repeated EHLO, so I assumed that > maybe the RFC for AUTH explicitely specified that and intended > to reread that before discussing that claim. I did look at it. Alexey (as co-author of RFC 4954) may have more to add here, but I read it as saying that EHLO is sent after the 220, the client gets a response and negotiates SASL (or whatever) and sets up the security layer. That action (not anything having to do with the second EHLO) clears the state -- the server memory of what the client sent in EHLO and the client's memory of the server's response. The text says explicitly "the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting)." At that point, basically all the client can do is send another EHLO command. It can't send anything that depends on an extension because the information about extension offerings has been discarded. It can't send MAIL, or even VRFY or EXPN, because 5321 is fairly clear that doing so in that "after 220 but before EHLO" state requires the server to return a "command out of order" response. I suppose it could send NOOP and maybe RSET, but who cares. Because 5321 does not explicitly address the case, I also suppose it could send HELO. However, because it has already been established that the client knows how to send EHLO and that the server will accept it, none of the conditions that 5321 lays out for using HELO rather than EHLO apply [1]. So 4954 then says "The client SHOULD send an EHLO command as the first command after..."? The only justification I can think of for "SHOULD" and not "MUST" are to allow for NOOP and maybe RSET [2] although, of course, it could go to the trouble of setting up a security layer and then send QUIT (in which case we don't need to worry about what state is preserved either). STARTTLS cannot be sent because the EHLO response information that authorizes it has already been cleared. (as In any event, when that EHLO is sent there is no issue about what it resets or clears -- which I think has been the subject of this discussion -- because the security negotiation has already cleared all of the relevant information. Now, if the security negotiation fails, 4954 says "the client MAY proceed without authentication" which would be the normal behavior if a client sends a command that the server rejects. In the typical case, it either sends QUIT or goes ahead and sends MAIL. If it is sufficiently confused about what state things are in that it wants to send EHLO again, that should be fine and, again, there is not much state to clear and it would be really strange to both send EHLO and try to carry information forward from previous EHLO command. I can see a few places here in which someone might be inclined to update/amend 4954 to make some of these cases clear (including clarifying why "SHOULD send EHLO" rather than MUST), but no substantive 5321bis issues. I have not checked the STARTTLS text, but assume it is much the same. > (I could seed that returning a different response to EHLO > after AUTH might be potentially useful, but most clients > probably aren't prepared to reissue EHLO to see if anything > has changed (except after STARTTLS, where they have to.) Right. john [1] If people think that 5321bis should explicitly prohibit sending HELO in a session after EHLO has been sent and accepted, please get Alexey to open a ticket. As implied above, I don't personally see any technical problem with doing so but am having trouble convincing myself that the issue is worth extra text in 5321bis. [2] I haven't studied whether NOOP (or RSET, which is the same thing outside a mail transaction) are even allowed in the "right after 220" session initiation state. If someone wants to look at the text and concludes that changes or clarification are needed, make a specific suggestion on-list and ask Alexey to open a ticket. From nobody Sat Oct 17 09:51:52 2020 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 A67F33A113D for ; Sat, 17 Oct 2020 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8geu1FN8Liux for ; Sat, 17 Oct 2020 09:51:48 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EC73A113C for ; Sat, 17 Oct 2020 09:51:47 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 8A9153B90; Sat, 17 Oct 2020 18:51:45 +0200 (CEST) Date: Sat, 17 Oct 2020 18:51:45 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20201017165145.GA27090@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> <0C3EDB08A5A25471A256B4AE@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <0C3EDB08A5A25471A256B4AE@PSB> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 17 Oct 2020 16:51:51 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-10-16 22:28:24 -0400, John C Klensin wrote: > --On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer" > wrote: >=20 > > On 2020-10-16 19:29:33 -0400, John C Klensin wrote: > >> I'd expect the second EHLO to clear AUTH and whatever it did > >> (which RSET in a mail transaction after the MAIL command was > >> issued would not) and basically require starting over. > >=20 > > That's what I would have assumed, too. But several people > > seemed to be quite confident that AUTH data in particular > > should not be cleared by a repeated EHLO, so I assumed that > > maybe the RFC for AUTH explicitely specified that and intended > > to reread that before discussing that claim. >=20 > I did look at it. Alexey (as co-author of RFC 4954) may have > more to add here, but I read it as saying that EHLO is sent > after the 220, the client gets a response and negotiates SASL > (or whatever) and sets up the security layer. That action (not > anything having to do with the second EHLO) clears the state -- > the server memory of what the client sent in EHLO and the > client's memory of the server's response. The text says > explicitly "the SMTP protocol is reset to the initial state (the > state in SMTP after a server issues a 220 service ready > greeting)." =20 That sentence starts with "When a security layer takes effect," which explains why I haven't seen that behaviour yet. I've always set up my servers to require TLS before even offering auth, so auth has no reason to negotiate an extra security layer.=20 Here is transcript (lightly edited) from an SMTP session (client is Thunderbird, server is Postfix): S: 220 rorschach.hjp.at ESMTP Postfix (Debian/GNU) C: EHLO [212.17.106.130] S: 250-rorschach.hjp.at S: 250-PIPELINING S: 250-SIZE 209715200 S: 250-VRFY S: 250-ETRN S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250-DSN S: 250 CHUNKING C: STARTTLS S: 220 2.0.0 Ready to start TLS C: EHLO [212.17.106.130] S: 250-rorschach.hjp.at S: 250-PIPELINING S: 250-SIZE 209715200 S: 250-VRFY S: 250-ETRN S: 250-AUTH PLAIN LOGIN S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250-DSN S: 250 CHUNKING C: AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxx S: 235 2.7.0 Authentication successful C: MAIL FROM: BODY=3D8BITMIME SIZE=3D393 S: 250 2.1.0 Ok C: RCPT TO: S: 250 2.1.5 Ok C: DATA S: 354 End data with . S: 250 2.0.0 Ok: queued as 91E553B8E C: QUIT S: 221 2.0.0 Bye As you can see, the client sends a second EHLO after the STARTTLS, but not after the AUTH. In any case, "AUTH clears result of EHLO" and "EHLO clears result of AUTH" can't both be always true. That would cause an infinite loop. As an aside, does that mean that a client has to authenticate a second time if the first authentication added a security layer? If EHLO indeed clears the authentication info, it would have to. What do existing systems do? But after re-reading the RFCs I don't see that EHLO would have to clear authentication info. Section 4.1.4 says: | If it is issued after the session begins [...] the SMTP server MUST | clear all buffers and reset the state exactly as if a RSET command had | been issued. In other words, the sequence of RSET followed immediately | by EHLO is redundant, but not harmful other than in the performance cost | of executing unnecessary commands. I understand that to mean that EHLO can't clear any information that RSET wouldn't clear - otherwise it wouldn't be redundant and indeed harmful. So what does RSET clear? | This command specifies that the current mail transaction will be | aborted. Any stored sender, recipients, and mail data MUST be | discarded, and all buffers and state tables cleared. Authentication info is clearly not part of a transaction. It might be part of the "state tables", but | It is effectively equivalent to a NOOP (i.e., it has no effect) [...] | after an end of data indicator has been sent and acknowledged So since=20 AUTH MAIL RCPT=20 DATA =2E MAIL RCPT DATA =2E is possible (and retains the auth data for the second transaction), AUTH MAIL RCPT=20 DATA =2E RSET MAIL RCPT DATA =2E must also have the same effect, and so must AUTH MAIL RCPT=20 DATA =2E EHLO MAIL RCPT DATA =2E hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAl+LIR0ACgkQ8g5IURL+ KF0GDRAAqkbTqD3xcTBLDRSJUV5CbLWUWEo37myfWfiotxCFtxLa2EqNPF3UIbvR Dov867v8gcr64feC2SLG3a/VHAZstskICLs5rayQZJovO878bmSh9JpxR9YaJx+H /nqleWrmsjbpfX20ppE3czCuowl7bpxGu+oOWTO9yK7CPX5g7IBa7v1aV9AZYYBt PQYATAoG1Jl7UzQSoPvWStxUFkuUqFebVW2ctKBfifP71v6YEFp6XJKOftDyraL+ LgzWOS6hTeQGQZXFvZoB7QRnDAkKcm+pgWjlQE8m+7/iHvb0M06VaK0Z7HOzAo3G o98OX3IQFsAYVwkyy4XtDvUKJYH17rmDyWiQg5rjhfD+n+vSA6NChdW30Q52kMEY /rfmUpsjXaxvocmHRpbdcISK9k4RpzNc9LhrwH7LnWtLWZCRYRjKK0nMAjeRdSYg r8pBB+xI67XlXR+Puswpq8u0J3pq/y+r1HBhkgn461+hh7ZUx7YinK/TOpJvBIIB sMPXwxzU8pDc7e5rrd+dZ/e8oGQu4GePbqROt1WNjFtJaweV989mqrv9joxCIsQm WlP8WrT+6WhwfOZc8nfDITzF1F1S7/dtUZijquunK2qLI7g0yCW7i/aeR02zSe4w +KFUWhoVHZYBOG938fWBMScJTDYmatBVjB2qnRi7z72y/Qdsbr8= =qsD5 -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From nobody Sat Oct 17 12:19:41 2020 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 0C6973A08C4 for ; Sat, 17 Oct 2020 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUuT__pZuwzE for ; Sat, 17 Oct 2020 12:19:34 -0700 (PDT) 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 CFCE53A08B8 for ; Sat, 17 Oct 2020 12:19:33 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kTrjo-000Gbd-2y; Sat, 17 Oct 2020 15:19:32 -0400 Date: Sat, 17 Oct 2020 15:19:26 -0400 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: <725EE91EE667BE791CB2333A@PSB> In-Reply-To: <20201017165145.GA27090@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> <0C3EDB08A5A25471A256B4AE@PSB> <20201017165145.GA27090@hjp.at> 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 #2: Repeated Use of 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, 17 Oct 2020 19:19:40 -0000 --On Saturday, October 17, 2020 18:51 +0200 "Peter J. Holzer" wrote: > On 2020-10-16 22:28:24 -0400, John C Klensin wrote: >> --On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer" >> wrote: >> >> > On 2020-10-16 19:29:33 -0400, John C Klensin wrote: >> >> I'd expect the second EHLO to clear AUTH and whatever it >> >> did (which RSET in a mail transaction after the MAIL >... Peter, I think we are going around in circles and I'm not even sure we disagree, so I'm going to step back let others fight this out. Just to be clear in (relatively) short form about what I think the next steps are: (1) I agree with much of what you write but believe it calls for clarification to the AUTH and STARTTLS (and maybe elsewhere) to clarify the relationship between them and, in particular, saying things like "SHOULD send EHLO" an hope that readers can sort of when that does not apply, as you have done. None of that requires changes in 5321bis although it is possible that some language about relationships in the possible A/S could be use to address the issues. It also looks to me as if 4954 should be explicit that, if it, via a SASL negotiation, does not create a new security layer, it and the server MUST NOT do any of the state-clearing back to just after 220 and MUST NOT send another EHLO. precisely because that might induce exactly the loop with which you are concerned. I don't see how that can be fixed except in an update to, or replacement for, 4954. And, unless there is something we want to do in the A/S, all of the above is, IMO, out of scope for the WG as now chartered. (2) We (and I want to stress that people should not depend on me) need to go through 5321bis and be sure the following are absolutely clear and adjust the text if any of it is not: (i) RSET inside a mail transaction resets the mail transaction, essentially erasing everything back to before the most recent MAIL command. RSET when no mail transaction is active is exactly equivalent to NOOP, i.e., it does not change anything that is not part of the mail transaction. In an exception to the general principle that extensions can change anything, extensions that attempt to change the relationship between RSET and mail transactions are invalid/ impossible. To avoid even more confusion, I note that use of the AUTH parameter of the MAIL command (see Section 5 of 4954) is part of a mail session so RSET (or DATA...CRLLF.CRLF) clears it. If that is a problem (I don't think it is given the language of 4954),it needs to be fixed in an update to 4954 that manages to be consistent with 5321 (or we need to stop the WG while we go address that issue). (ii) If EHLO is issued within a mail transaction, it is a superset of RSET. More specifically, the behavior is identical to what it would have been had RSET been sent, abandoning and closing the mail transaction, and then EHLO had been sent. (iii) Sending a second EHLO clears and replaces the option advertisement of the prior one. If it would have been possible to initiate the use of an option that was advertised the first time but not the second, it is no longer possible and, any assumptions or dependencies on the initial _announcement_ are superceded by the second one. For example the server might advertise SIZE with different limits and only the most recent advertisement would count. The second (or subsequent) EHLO do not change the state of anything. In particular, if an option was negotiated in, or as part of, a mail session and EHLO is issued during that session, the implied RSET clears any state associated with that option, but EHLO doesn't do anything about that state. Any options that are validly negotiated, or actions that are taken in conjunction with them, outside of mail sessions and intended to persist throughout the connection are unchanged by a second EHLO. The only thing that is potentially changed by the second EHLO is the list of options that will be accepted after it is issued. Independent of issues related to security sessions and if I correctly remember the spec, I note that advertising SMTPUTF8 means that, within that connection, the client is allowed to send messages with conforming non-ASCII headers in messages whether non-ASCII mailbox names are present or not and that permission extends to all messages sent in the connection unless the server revokes it. AFAIK, the only way to revoke the permission is to send a second EHLO that does not advertise the option. An option that is negotiated or assumed outside of a mail session probably should have an "ok, stop doing that" (or believing that, or whatever): I don't know if 5321bis's discussion about extensions needs to make that explicit, recommend, or require it, but will assume none of those unless someone opens a ticket and gets consensus. Now, is that consistent with what you think should happen/ what you are asking for? And, if not, where and why? thanks, john From nobody Sat Oct 17 15:27:50 2020 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 E974B3A1089 for ; Sat, 17 Oct 2020 15:27:47 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByfF0N-uW1JP for ; Sat, 17 Oct 2020 15:27:46 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED6B3A1088 for ; Sat, 17 Oct 2020 15:27:45 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 4FDFC3913; Sun, 18 Oct 2020 00:27:43 +0200 (CEST) Date: Sun, 18 Oct 2020 00:27:43 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20201017222743.GA11058@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> <0C3EDB08A5A25471A256B4AE@PSB> <20201017165145.GA27090@hjp.at> <725EE91EE667BE791CB2333A@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <725EE91EE667BE791CB2333A@PSB> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 17 Oct 2020 22:27:48 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-10-17 15:19:26 -0400, John C Klensin wrote: > --On Saturday, October 17, 2020 18:51 +0200 "Peter J. Holzer" > wrote: >=20 > > On 2020-10-16 22:28:24 -0400, John C Klensin wrote: > >> --On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer" > >> wrote: > >>=20 > >> > On 2020-10-16 19:29:33 -0400, John C Klensin wrote: > >> >> I'd expect the second EHLO to clear AUTH and whatever it > >> >> did (which RSET in a mail transaction after the MAIL > >... >=20 > I think we are going around in circles and I'm not even sure we > disagree, so I'm going to step back let others fight this out. > Just to be clear in (relatively) short form about what I think > the next steps are: >=20 > (1) I agree with much of what you write but believe it calls for > clarification to the AUTH and STARTTLS (and maybe elsewhere) to > clarify the relationship between them and, in particular, saying > things like "SHOULD send EHLO" an hope that readers can sort of > when that does not apply, as you have done. None of that > requires changes in 5321bis although it is possible that some > language about relationships in the possible A/S could be use to > address the issues. [...] > And, unless there is something we want to do in the A/S, all of > the above is, IMO, out of scope for the WG as now chartered. Right. > (2) We (and I want to stress that people should not depend on > me) need to go through 5321bis and be sure the following are > absolutely clear and adjust the text if any of it is not: >=20 [...] That's consistent with how I understand 5321. But I think this thread has shown that there is some confusion (or maybe I just misunderstood what some people were saying), so it can probably be made clearer. > Now, is that consistent with what you think should happen/ what > you are asking for? Yeah, pretty much. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAl+Lb9oACgkQ8g5IURL+ KF0bXg/+LurUeEkcSciMFOeynHzSfIDZKPdUMPaG5efgn1grNP6SU5ncjWaD5YJA tMV1hy5Sn4kMgImQtvGEj4M3qemz6lfoYtSFLRefOzGukhFhDW9KPSA8kTWCj4xG 1OUGTI75pa2p1sep78cVhQ/Tpyld/NvSeG1iRoMudIKFIlCzmOu6vqZDh7eXdTb8 c5l1wwNjDeWIO0Hp+5RATshxRMA0r3Uz9goZrzuLDxwfGUIMhVn4QhaaLULOrBAe Yv7zkuLSnrUYUexhSwAuEM4Sxj1P1uThHH17Wek26OTAIkKP2axIrKTsfS0UN3Iy C77+eQ+NtnBhRucZzbR6wOghaV9O16iT3WipZZqEtkTSKP6hhSmnVO+WsHwSlkMV U+uAtyOQC/5oaOdtq7YRS5VBlOzom1HTY+r/iArydz0+AYOyvsF1Ec+G9jABtHdi FWWkrFBwKC3QM8uEjPsKpviLcWpaf15vqS9z0zsUFrBgUFD7vMyzNJXGAYd0P+3W 8r/dzvKvkUT1oG2+pdjTAHeapaabYKQzmMZr2NmRN/jgp93gg2/+32K++ayqwNg4 xSqIa3e8Yr3Q9f9GSFVnX9OVFu6D7h954RJac+sX3dZ+XQ/oC5EWU520dQuFzEZH DlGRxr0Z20Waue2g133xAfwbaoIwTdq6aT/jZkXOahhEyCvesPQ= =mdxb -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From nobody Sun Oct 18 01:45:45 2020 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 068BC3A064A for ; Sun, 18 Oct 2020 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziV4GHBkUNrj for ; Sun, 18 Oct 2020 01:45:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABAE3A0639 for ; Sun, 18 Oct 2020 01:45:37 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kU4Jr-000JEN-LJ; Sun, 18 Oct 2020 04:45:35 -0400 Date: Sun, 18 Oct 2020 04:45:29 -0400 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: <88E909430268FB2A340F89AB@PSB> In-Reply-To: <20201017222743.GA11058@hjp.at> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> <0C3EDB08A5A25471A256B4AE@PSB> <20201017165145.GA27090@hjp.at> <725EE91EE667BE791CB2333A@PSB> <20201017222743.GA11058@hjp.at> 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] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 08:45:42 -0000 --On Sunday, October 18, 2020 00:27 +0200 "Peter J. Holzer" wrote: >> (2) We (and I want to stress that people should not depend on >> me) need to go through 5321bis and be sure the following are >> absolutely clear and adjust the text if any of it is not: >> > [...] > > That's consistent with how I understand 5321. But I think this > thread has shown that there is some confusion (or maybe I just > misunderstood what some people were saying), so it can > probably be made clearer. > >> Now, is that consistent with what you think should happen/ >> what you are asking for? > > Yeah, pretty much. Good. Let me see what I can do, but suggested text is always welcome. john From nobody Sun Oct 18 03:55:31 2020 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 394B63A0B0E for ; Sun, 18 Oct 2020 03:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_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=fastmail.fm header.b=ITZS0eH3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bwdvuq8N 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 F2TtcyG6GcdJ for ; Sun, 18 Oct 2020 03:55:28 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2D33A0B0A for ; Sun, 18 Oct 2020 03:55:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3810D930; Sun, 18 Oct 2020 06:55:27 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 06:55:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=axiCNaR3cOtEtVk7Em8oXzdy2jCvFsm xT1yEWEjuDs0=; b=ITZS0eH3HTRjiYO6RBtHyV8aAmAbGUURPS+elrum77AnLF/ RN/1zokKxYUdtiZZcV0kgZI16KB4fnTQUCHkY+g7gKdolzzeRyRV1vGPIddJj7jy V66AmqlmacZltwaePEcLUpwc9rOitC7jgCngfxEHyQKG74re9WypLqaGSk0j/Fbo 7bI17b85Azov32FxjavnbKHR9GuUxDf+nXqSCZVHGXO+QV5tEVLKuMAgFD8BlfpO YpxT0Sn8SPwO0Y3W9w5gvBK5AtRZQVkhI0T3mCWm8JQMr3oeBCHhrRm6oFj3kEee SLg49nusbx1IJq9FEUHs+6FE5ObO8RBry8G7k3w== 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=axiCNa R3cOtEtVk7Em8oXzdy2jCvFsmxT1yEWEjuDs0=; b=bwdvuq8NTRq6xf7PyvE0js mrN0ijDQrQwZTlgsp0FLva4v/yCiUU+oasgsjTas7O6RBBAGGSE52XyVM0BRHuI3 5RokGQ6GlKNEJhOrDd/k57ecB8BBppHl+8tWK8qHgjjdyfWDqpDYpgTAv+cFNpCE RrE8dbIUWEY5EnsrZ9IAHvOKXPgAYH03JIGGgMYGUpnDzay0w5qtxj051NG9y4u9 XSEM1gve/Ymf3x8BeaEiLf8zCfysQvfJDYKS5NEPRQhmQJW2nDDNv4Xy9lKxhU5O qGmhWZRPlwH4U8QyCS080qw9EnhvJElCIW+k0ZQnUg3Y6m093JVHCQh2ZSHM5FZQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieelgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepgeelfeejhf egudefvdehvdeitefgfedtveejjeeuleeugfehieduteegkedtfefgnecuffhomhgrihhn pegvgigrmhhplhgvrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgr ihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B249660069; Sun, 18 Oct 2020 06:55:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: In-Reply-To: <0A01EB8802E261F7D7DA2EB4@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> Date: Sun, 18 Oct 2020 11:55:04 +0100 From: "Alexey Melnikov" To: "John C Klensin" , "Peter J. Holzer" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 10:55:30 -0000 Hi John, On Sat, Oct 17, 2020, at 12:29 AM, John C Klensin wrote: > Peter and Hector, > > AFAICT, what makes this complicated isn't what the client/sender > sends, it is that nothing obligates the server to return the > same set of option offerings twice. Since the options that are > in effect can affect what commands and arguments the client can > send, that is potentially a big deal. > > So, RSET closes and resets a mail transaction, losing any > information if MAIL, RSET, etc., commands. Sending EHLO once > that mail transaction has started (e.g., the MAIL command is > sent) is a superset of the RSET behavior but also clears the > options that were advertised (and may or may not have been > accepted) the first time around. Agree so far. > A second EHLO being sent right > after the first one (before any other functional commands) seems > rather silly but, but, if, e.g., the sequence were > EHLO ... > AUTH ... > EHLO... > MAIL ... > > I'd expect the second EHLO to clear AUTH As an editor of SMTP AUTH (RFC 4954) I disagree with EHLO clears AUTH state. AUTH state is sticky, in the same way as STARTTLS is. I.e. it is not possible to clear it without closing the TCP connection. > and whatever it did > (which RSET in a mail transaction after the MAIL command was > issued would not) and basically require starting over. > > That is more or less what the text was intended to say and says > now (even if not clearly) and, the more I think about it, I > cannot make sense of any other interpretation that would not > constitute an incompatible change that might disrupt conforming > implementations. The text is not as clear as it might be and I > propose that we fix that as I outlined in an earlier note. Agreed. (Modulo your comment about EHLO and AUTH). > Now the question, at least IMO, is whether anyone disagrees with > that and if so, why, especially after noting that an > incompatible change that affects existing deployed > implementations would reset 5321bis to Proposed and is hence out > of scope and a showstopper for the WG. Personally, I wouldn't > lose a lot of sleep if something arose that was important enough > to justify stopping the WG, publishing a draft with the changes, > waiting six months or as long as it takes to demonstrate > deployment and interoperability, and then returning to 5321bis > but, IMO, the threshold for "important enough" to justify that > should be really high, not just, e.g., a matter of taste and > aesthetics. > > john > > > --On Saturday, October 17, 2020 00:48 +0200 "Peter J. Holzer" > wrote: > > > On 2020-10-16 13:45:29 -0400, Hector Santos wrote: > >> On 10/16/2020 4:32 AM, Alexey Melnikov wrote: > >> > On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: > >> > > RFC 3207 sec 4.2 says that after STARTTLS "The server > >> > > MUST discard any knowledge obtained from the client," > >> > > which sounds like it also does what RSET does. > >> > > >> > It does what RSET does and more, e.g. clearing the > >> > remembered EHLO hostname. > >> > >> Why would the machine name, the domain name or ip-literal > >> need to be cleared? It has no purpose to do so. It won't > >> change. That's a fixed item. > > > > Because the EHLO/HELO command includes a new one. Unless your > > server keeps a list of EHLO names, it can only either keep the > > old one or replace it with the new one. (In almost all cases, > > those will be identical and I can't think of a plausible > > reason why it should change within a single connection, but if > > it does change it's probably better to use the new one.) > > > > > >> Even if the EHLO data is cleared, the SMTP state machine will > >> handle the situation when the client issues > >> > >> C: RSET > >> S: 250 ok > >> C: MAIL FROM: > >> S: 250 OK > >> > >> but if we clear the EHLO with the RSET, then we may have this: > >> > >> > >> C: RSET > >> S: 250 ok > >> C: MAIL FROM: > >> S: 503 Send EHLO first > > > > That's not what we are talking about. We are talking about > > using EHLO/HELO instead of RSET. > > > > So > > > > C: EHLO mail.example.com > > S: 250 ... > > C: MAIL FROM: > > S: 550 Sender blacklisted > > C: EHLO mail.example.com > > S: 250 ... > > C: MAIL FROM: > > S: 250 Sender acceptable > > > > should work. > > > > hp > > > >> Here is an interesting session trace I see in today's log: > > > > Not sure what's interesting or even relevant. Care to explain? > > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > From nobody Sun Oct 18 04:11:11 2020 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 7B3523A0B1C for ; Sun, 18 Oct 2020 04:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_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=fastmail.fm header.b=PczmieRu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fiG0ewO2 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 EUOb0hmtvCUd for ; Sun, 18 Oct 2020 04:11:04 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625963A0B1A for ; Sun, 18 Oct 2020 04:11:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C1B81999; Sun, 18 Oct 2020 07:11:02 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 07:11:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=qQnCi/xBFEntIRHIBlubJNrWlbCf95u a5joBy46vPb8=; b=PczmieRuw7b6EI6SyZdHWYtOB0JDgvL9qjunAL3foos3WxA XuZDNCuMpca0zaiNnCZfCU8k24RgiA/GradKk3/wHsXOS/uXllYuDYME+AIgt0LV gml3onZzPRCbdCA3hcO0I315bc76Yg9GWubrBj4hGZHqveOoomLK+QILoC513uy8 q98WIwMXA7Ii8DeOSuCQsDyODvuM82/LPMAAlFWGMatbDn+Te8vIeIPC+R/lNTiR ntZimzFMKpFzYJTWZVBM723v/uevDfAImHGVFv0qYCnPRRmxx4GkUmqHLGdAuhzR HR9yqQd58InFXp3UGgnHdC3e1LvmfWu6udQ+y0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qQnCi/ xBFEntIRHIBlubJNrWlbCf95ua5joBy46vPb8=; b=fiG0ewO2SC1r192q0qF4ZS S3javCsB6BO/4ZWIF5VxFl2HcqUcjzGKwNNqMbZsCtMhNc3OOP+Tuw8LBgazb1La zZ5YH3pkfetqN5M8JKKR5lYe9ee20VkLOTAF/Nd2LtCastKnF6JlUFE3sShD1ywP lD/ZvYcdal3MWJczgmPqrEl1QmNguwFVaISmtZ1bKcDzgWg2rMqeskUNNEmJadKw 60QxABR8cK+F1GxTiI8ab239nRCWGzunZv5UW17ppc2k2bILPdcK9FkxA5vwkLhu zbythDZztqE3hnuHiFjyIgQVymauvB0L7R1ryNslO5ysoILc+PuzbbOeBp7AK0GA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieelgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepfeevteekfe efteetgedtgefhieegieetgefhkeeigfduhffgjedvuddukeejfeeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvse hfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5A5B8660069; Sun, 18 Oct 2020 07:10:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: In-Reply-To: <725EE91EE667BE791CB2333A@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <20201016234247.GA24097@hjp.at> <0C3EDB08A5A25471A256B4AE@PSB> <20201017165145.GA27090@hjp.at> <725EE91EE667BE791CB2333A@PSB> Date: Sun, 18 Oct 2020 12:10:40 +0100 From: "Alexey Melnikov" To: "John C Klensin" , "Peter J. Holzer" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 11:11:09 -0000 Hi John/Peter, Speaking as a participant and co-editor of RFC 4954 below: On Sat, Oct 17, 2020, at 8:19 PM, John C Klensin wrote: > --On Saturday, October 17, 2020 18:51 +0200 "Peter J. Holzer" > wrote: > > > On 2020-10-16 22:28:24 -0400, John C Klensin wrote: > >> --On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer" > >> wrote: > >> > >> > On 2020-10-16 19:29:33 -0400, John C Klensin wrote: > >> >> I'd expect the second EHLO to clear AUTH and whatever it > >> >> did (which RSET in a mail transaction after the MAIL > >... > > Peter, > > I think we are going around in circles and I'm not even sure we > disagree, so I'm going to step back let others fight this out. > Just to be clear in (relatively) short form about what I think > the next steps are: > > (1) I agree with much of what you write but believe it calls for > clarification to the AUTH and STARTTLS (and maybe elsewhere) to > clarify the relationship between them and, in particular, saying > things like "SHOULD send EHLO" an hope that readers can sort of > when that does not apply, as you have done. None of that > requires changes in 5321bis although it is possible that some > language about relationships in the possible A/S could be use to > address the issues. > > It also looks to me as if 4954 should be explicit that, if it, > via a SASL negotiation, does not create a new security layer, it > and the server MUST NOT do any of the state-clearing back to > just after 220 and MUST NOT send another EHLO. precisely > because that might induce exactly the loop with which you are > concerned. I don't see how that can be fixed except in an > update to, or replacement for, 4954. I admit that RFC 4954 need clarifying in this area, but basically EHLO never clears AUTH specific state (which is SASL mechanism used, username after authentication and optionally SASL security layer state). It is always Ok to issue EHLO after AUTH, whether or not SASL security layer was negotiated. When SASL security layer is negotiate, EHLO is required, because the server should have cleared all other state, including received EHLO parameter. > > And, unless there is something we want to do in the A/S, all of > the above is, IMO, out of scope for the WG as now chartered. > > (2) We (and I want to stress that people should not depend on > me) need to go through 5321bis and be sure the following are > absolutely clear and adjust the text if any of it is not: > > (i) RSET inside a mail transaction resets the mail transaction, > essentially erasing everything back to before the most recent > MAIL command. RSET when no mail transaction is active is > exactly equivalent to NOOP, i.e., it does not change anything > that is not part of the mail transaction. Agreed. > In an exception to the > general principle that extensions can change anything, > extensions that attempt to change the relationship between RSET > and mail transactions are invalid/ impossible. I tend to agree. > To avoid even more confusion, I note that use of the AUTH > parameter of the MAIL command (see Section 5 of 4954) is part of > a mail session so RSET (or DATA...CRLLF.CRLF) clears it. If > that is a problem (I don't think it is given the language of > 4954), No, this is exactly right. >it needs to be fixed in an update to 4954 that manages to > be consistent with 5321 (or we need to stop the WG while we go > address that issue). > > (ii) If EHLO is issued within a mail transaction, it is a > superset of RSET. More specifically, the behavior is identical > to what it would have been had RSET been sent, abandoning and > closing the mail transaction, and then EHLO had been sent. Yes. > (iii) Sending a second EHLO clears and replaces the option > advertisement of the prior one. If it would have been possible > to initiate the use of an option that was advertised the first > time but not the second, it is no longer possible and, any > assumptions or dependencies on the initial _announcement_ are > superceded by the second one. For example the server might > advertise SIZE with different limits and only the most recent > advertisement would count. I agree with that. I can even see a way to advertise higher (or lower) SIZE limits after SMTP AUTH and/or STARTTLS. > The second (or subsequent) EHLO do > not change the state of anything. In particular, if an option > was negotiated in, or as part of, a mail session and EHLO is > issued during that session, the implied RSET clears any state > associated with that option, but EHLO doesn't do anything about > that state. Any options that are validly negotiated, or > actions that are taken in conjunction with them, outside of mail > sessions and intended to persist throughout the connection are > unchanged by a second EHLO. The only thing that is potentially > changed by the second EHLO is the list of options that will be > accepted after it is issued. Sounds very reasonable to me and this is what I thought was the intent. > Independent of issues related to security sessions and if I > correctly remember the spec, I note that advertising SMTPUTF8 > means that, within that connection, the client is allowed to > send messages with conforming non-ASCII headers in messages > whether non-ASCII mailbox names are present or not and that > permission extends to all messages sent in the connection unless > the server revokes it. AFAIK, the only way to revoke the > permission is to send a second EHLO that does not advertise the > option. > > An option that is negotiated or assumed outside of a mail > session probably should have an "ok, stop doing that" (or > believing that, or whatever): I don't know if 5321bis's > discussion about extensions needs to make that explicit, > recommend, or require it, but will assume none of those unless > someone opens a ticket and gets consensus. I don't know if we have any extensions like this, but IMHO, it would be worth clarifying one way or another. > Now, is that consistent with what you think should happen/ what > you are asking for? And, if not, where and why? Best Regards, Alexey From nobody Sun Oct 18 04:15:48 2020 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 635A93A0B2E for ; Sun, 18 Oct 2020 04:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_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=fastmail.fm header.b=EQncnWVv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c+EDuY2O 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 tFGbVOLFk9jP for ; Sun, 18 Oct 2020 04:15:44 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1963A0B2D for ; Sun, 18 Oct 2020 04:15:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 166A5B3E; Sun, 18 Oct 2020 07:15:44 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 07:15:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=SlvaTPqOvx62d2JkRROQeVLfzzjHXmE RARL4k6MK2pY=; b=EQncnWVvKd65MbBZ7vlPO4Jeit+PeoxGlx+e/b6kNSlopYq ZnZVCmP07JTWjwtiUls56kGV6FF4CqGSusadgu4hcKIo6O0FIlNNJya5XwdHYqHI n5c9DkFes2uF/eVHuGQWGIvu7pmxtrbmwYqmEl1eVRWn0kQzDhEZiJeQcrcDhQVy MEakXoUj/RRSdAcKIE6Dk+AmvXNudyIamxNbluBP3tXx8VEb/mewtVSdoX/TPERp fov0g6t0FpkhjQKrMrA4cGb+TxCs1/7uXG1fDmGuWL9SU87H3AhN2j/buyr+UFeo L14/Pxoi4NcNB9ELbXEkwCrGiKNo2bPw4tR4PxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SlvaTP qOvx62d2JkRROQeVLfzzjHXmERARL4k6MK2pY=; b=c+EDuY2OQYwqboYJI6jy+G 94uX500FxZLEtCW206l6J4OodOwD4C/tfhuMrjKqokzjWtFl5WZ55UCyhEnKFyXc E1gZOGZPTFyc5i4w4XsJx7bSHMsazgZdbYRXdGbL3KrV96Td7kkk4NmA1vHAYTfN FHKWa0KJPBauf3xVIr4Fn+z0P40v3rb7z/BJYsZ052ntISy/k4Baev2iDiIH5a0n HXrCDCnenO2DpE6HrvgGO2tnKfc/jrOylOyi2NzhbEUBPLgUs1504hxH2ANSfuJH AWjZ/sd3DIWZql05oHrfltFhUHOEm1KZhqUxBqqj+jB2ut9EqIYU3tzMKCG+rKpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieelgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfekiefg udfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BCEF1660069; Sun, 18 Oct 2020 07:15:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <43021415-ebd2-4ea7-9bac-79eaa71bed7d@www.fastmail.com> In-Reply-To: <5F89DC39.9040505@isdg.net> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> Date: Sun, 18 Oct 2020 12:15:21 +0100 From: "Alexey Melnikov" To: "Hector Santos" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 11:15:46 -0000 Hi Hecror, I just want to clarify one thing: On Fri, Oct 16, 2020, at 6:45 PM, Hector Santos wrote: > On 10/16/2020 4:32 AM, Alexey Melnikov wrote: > > On Thu, Oct 15, 2020, at 7:09 PM, John Levine wrote: > >> RFC 3207 sec 4.2 says that after STARTTLS "The server MUST discard any > >> knowledge obtained from the client," which sounds like it also does > >> what RSET does. > > > > It does what RSET does and more, e.g. clearing the remembered EHLO hostname. > > Why would the machine name, the domain name or ip-literal need to be > cleared? It has no purpose to do so. It won't change. That's a fixed > item. The reason for this is because anything before successful STARTTLS could have been modified by a man-in-the-middle attacker and thus can't be trusted. Best Regards, Alexey From nobody Sun Oct 18 04:37:49 2020 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 364423A0B32 for ; Sun, 18 Oct 2020 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=XAaf+Ue9; dkim=pass (2048-bit key) header.d=wizmail.org header.b=Ssy+vkgU 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 o12euffZ6qWp for ; Sun, 18 Oct 2020 04:37:46 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7082F3A0A35 for ; Sun, 18 Oct 2020 04:37:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=65OdZw6QETrp/GoB8hk5EgvheXD89m+aZOdAb/9fy/c=; b=XAaf+Ue9KxoC+yi3uZQqpnAnFv pJxh5JbUuKGqInSb7Rz9WKiDTeshBxD0pBj011GKdU9x3U5k/KrDqKH1clAw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=65OdZw6QETrp/GoB8hk5EgvheXD89m+aZOdAb/9fy/c=; b=Ssy+vkgUAR3FXugL/yz6S+LXKq wvDd6Xyq/qrhVNzKOcKWJ2iU8b/tY75Sqpvj9UEwYgvzDuO7qRE/pKgxhHPKVQ1xsPDTLf8L/M0aA a7F8U0r4ufXyQl7hAajKhms++uJX31L0b5IZjUUh/psFc0sLO08Xkoj78Vzw1eAQ1X9B7miewCeYi FL8DGlp1LPrEgXCrHCBm3tmw8VyGAB6Xi26y41uBtYq15uejcjQ5mUzIDUrnBr1xKOWxsRXeIa6o9 YPOBE+zRtaD2V/hZsSVVrD5tgxJg2+0GssF0e18qW07YdY3fDB1QRSBFXgQcD5JTHAYlRptofwo/t 4LebXvKA==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.107) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kU70R-00FX5L-EW for emailcore@ietf.org (return-path ); Sun, 18 Oct 2020 11:37:43 +0000 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> From: Jeremy Harris Message-ID: <9254ce6d-f5b7-d775-ad9c-4ee3bca77c01@wizmail.org> Date: Sun, 18 Oct 2020 12:37:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 11:37:48 -0000 On 18/10/2020 11:55, Alexey Melnikov wrote: > As an editor of SMTP AUTH (RFC 4954) I disagree with EHLO clears AUTH state. AUTH state is sticky, in the same way as STARTTLS is. I.e. it is not possible to clear it without closing the TCP connection. If we're considering corner-cases, perhaps we should nail down the effect of a second AUTH. I'd be happy to explicitly make the effect undefined, and SHOULD NOT be sent. -- Cheers, Jeremy From nobody Sun Oct 18 05:07:51 2020 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 9CEAB3A0B6F for ; Sun, 18 Oct 2020 05:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=cSo+liNm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eUsta90h 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 5vDQojOkoMvs for ; Sun, 18 Oct 2020 05:07:49 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8B63A0B6C for ; Sun, 18 Oct 2020 05:07:49 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9B63F5C00E9; Sun, 18 Oct 2020 08:07:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 08:07:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=J BZRAHHVba387VY/In/5sekb5bi9JLHiH6P94gUxAz4=; b=cSo+liNm6fSWqbQjS 5rGCoaoHd/AYMjcN8q+3klj8ogsClNM/fMbsJNpGE/ZLAfXBxDznrVQPffrkXNy1 ra9TbV6ywMxRZOALWqhus8F3o3CUYOegjb/NB3hTgkk6dN/ZlkTxTCCBb42U3Fnb iOOK9DgV0i/24JsteAFbjwaazeTrtuhGkfcKtSTsAfAjvNdZQEMst4GZNnKSOpXK 4PkjgGFGpA7U0DJ6rkPl8LlKQa+gLd5ip28h2DhkXSHhk7XuXrctOvIQkrghKBHm GLIgBm+RHV9vx8hAKBzctUk/xgbzxjaWlkmXTiTRj6JEgP37zOpyspiVxJLf7R/1 anzkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=JBZRAHHVba387VY/In/5sekb5bi9JLHiH6P94gUxA z4=; b=eUsta90hFQ9+yNP0ObPFHfkRxVczFdrf3FkZYYR/nn8jd+yDdliGBuGTV Fsy0COAuQXbx29EGEyDKSaz66STXDVMZbPBx3pShn9mnyvm7JjC3bP6nQvZZMA4d RnZ2ETrfLEL/Nc5dRE5REmV100Z7QoemNQs1U4l/rban0VK3xraCzGvyjf6rLBtM 0kmF5PcpXIWK3OlXudCsOq2dT/1XArld0L7bd0wGgu7F4jX7Gq6zYTUsYvge/WOS /sP+6/0HslxGEpUcKgsVfIQxYu+R9BM9+uoej1je/n6k9Dm3V2NswSLXfn7lyt33 x6z2X3SUYtd2caCfJ/1F27+/d6OPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieelgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhofgjfffgkfhfvfesthhqmh dthhdtvdenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepledvlefhffeuhe dvgeeftdeuhfelieffkeetueffgfdvfedtfeefhfehueeiheetnecukfhppedutdelrddv hedvrdektddrheefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: from [192.168.1.76] (unknown [109.252.80.53]) by mail.messagingengine.com (Postfix) with ESMTPA id E32743280059; Sun, 18 Oct 2020 08:07:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <9254ce6d-f5b7-d775-ad9c-4ee3bca77c01@wizmail.org> Date: Sun, 18 Oct 2020 15:07:45 +0300 Cc: emailcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <9254ce6d-f5b7-d775-ad9c-4ee3bca77c01@wizmail.org> To: Jeremy Harris Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 12:07:51 -0000 Hi Jeremy, > On 18 Oct 2020, at 14:37, Jeremy Harris wrote: >=20 >> On 18/10/2020 11:55, Alexey Melnikov wrote: >> As an editor of SMTP AUTH (RFC 4954) I disagree with EHLO clears AUTH sta= te. AUTH state is sticky, in the same way as STARTTLS is. I.e. it is not pos= sible to clear it without closing the TCP connection. >=20 > If we're considering corner-cases, perhaps we should nail down > the effect of a second AUTH. I'd be happy to explicitly make the > effect undefined, and SHOULD NOT be sent. Second AUTH is not allowed (it must always fail, unless previous AUTH was no= t successful) in SMTP AUTH, but I am happy to make it clearer. I.e. once an a= uthenticated user is set, it is not possible to change authenticated user on= an SMTP session. Best Regards, Alexey= From nobody Sun Oct 18 05:26:47 2020 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 C85123A0B8A for ; Sun, 18 Oct 2020 05:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=2opb+/Bp; dkim=pass (2048-bit key) header.d=wizmail.org header.b=rMPa2fAh 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 z1NTYIv4j_G6 for ; Sun, 18 Oct 2020 05:26:44 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBA43A0B89 for ; Sun, 18 Oct 2020 05:26:43 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=D4xTmE79UA4OV/6x4C9wm3q/czNDhtHXir8n4A3V+6c=; b=2opb+/BpMbfl260AFrRAlY62V0 9Eor1Y/vO2GBLI4qVJ9MospenBVy2CFX/zf2i/LFr+zRoa9PS9zkNZDchGDA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=D4xTmE79UA4OV/6x4C9wm3q/czNDhtHXir8n4A3V+6c=; b=rMPa2fAheq5HdcsMbpVyr5NSi5 qpsFQ2ByZnNfsGqGvzO/aBOf2IZXVNBvdFrX1tx8zk0xjeZL1KBaG3zT7gzR/ByxqmsZMSW/6rik7 mKgR5OGQcdiJOiu5rVMfDDCxZyS0Bl2VQ6j5ZPfhxGJFRvGwW9vWBy5RJu1E7K76JSu4I2/TYDwRM x5IZ3kvTZ1Ck3YT2ZNQb/Bcbz7jC6FGp/p55i7UE3VbqCylany0vk14SjrOK+YF8KLCpLlej0geK1 qkGlxwneCUb7tFlZVuO6icfG1/DVRuLzWz37csxOghkBahnyq7wNQFk+ayRRlFTSXebcoIZnhLQSt pAkUUwFQ==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.107) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kU7lp-00FXy4-Hm for emailcore@ietf.org (return-path ); Sun, 18 Oct 2020 12:26:41 +0000 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <9254ce6d-f5b7-d775-ad9c-4ee3bca77c01@wizmail.org> From: Jeremy Harris Message-ID: Date: Sun, 18 Oct 2020 13:26:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 12:26:46 -0000 On 18/10/2020 13:07, Alexey Melnikov wrote: > Second AUTH is not allowed (it must always fail, unless previous AUTH was not successful) in SMTP AUTH Ah yes; RFC 4954 Section 4, Restrictions. Server MUST 503. Sorry for the noise. -- Cheers, Jeremy From nobody Sun Oct 18 06:07:54 2020 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 3D4FA3A0BFE for ; Sun, 18 Oct 2020 06:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD7q6aZH5VXu for ; Sun, 18 Oct 2020 06:07:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08ADA3A0BFD for ; Sun, 18 Oct 2020 06:07:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQXZCC1DKG00B073@mauve.mrochek.com> for emailcore@ietf.org; Sun, 18 Oct 2020 06:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603026458; bh=LG8i3HCoceonY40CkMUEQmR6vZQlkli7Z289HojC98M=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=YFMBuVO88Vldx1y4FsiEYZ+4YFfepAyenpczmTR4hHlySLUrk+poh0IHTj4nVdPko OmZnZfxh/y5/uQB6AFJEuFoZcqmPg2SI7SGbQ4x3I6+q9R0d1iZzUdRoQeo640DGme rJfYlygVGs3nxy5/G+S8dChEbCHWRxRev9pL1JVQ= 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 <01RQXYXZFJIO0085YQ@mauve.mrochek.com>; Sun, 18 Oct 2020 06:07:36 -0700 (PDT) Cc: John C Klensin , "Peter J. Holzer" , emailcore@ietf.org Message-id: <01RQXZC8Q2RQ0085YQ@mauve.mrochek.com> Date: Sun, 18 Oct 2020 06:03:40 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 18 Oct 2020 11:55:04 +0100" References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 13:07:52 -0000 > Hi John, > On Sat, Oct 17, 2020, at 12:29 AM, John C Klensin wrote: > > Peter and Hector, > > > > AFAICT, what makes this complicated isn't what the client/sender > > sends, it is that nothing obligates the server to return the > > same set of option offerings twice. Since the options that are > > in effect can affect what commands and arguments the client can > > send, that is potentially a big deal. > > > > So, RSET closes and resets a mail transaction, losing any > > information if MAIL, RSET, etc., commands. Sending EHLO once > > that mail transaction has started (e.g., the MAIL command is > > sent) is a superset of the RSET behavior but also clears the > > options that were advertised (and may or may not have been > > accepted) the first time around. > Agree so far. > > A second EHLO being sent right > > after the first one (before any other functional commands) seems > > rather silly but, but, if, e.g., the sequence were > > EHLO ... > > AUTH ... > > EHLO... > > MAIL ... > > > > I'd expect the second EHLO to clear AUTH > As an editor of SMTP AUTH (RFC 4954) I disagree with EHLO clears AUTH state. > AUTH state is sticky, in the same way as STARTTLS is. I.e. it is not possible > to clear it without closing the TCP connection. Alexey is correct. Absent some sort of UNAUTH commend (such a commend presently exists in IMAP but not SMTP), AUTH state is sticky. Moreoever, the EHLO cannot work this way because issuing an EHLO is the only way to determine the state of things after AUTH, which may have changed to include new extensions, or disallow previous ones. The same applies to STARTTLS, and here there's an obvious use-case: The AUTH value can easily change after STARTTLS is negotiated to include cleartext optiosn not previously available. (Or if STARTTLS included authentication AUTH EXTENRAL may be the only mechanism available.) Ned From nobody Sun Oct 18 06:29:24 2020 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 E0F233A0C17 for ; Sun, 18 Oct 2020 06:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 eZoUkBYxfr1u for ; Sun, 18 Oct 2020 06:29:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26763A0BC2 for ; Sun, 18 Oct 2020 06:29:21 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kU8kK-000Jtp-C7; Sun, 18 Oct 2020 09:29:12 -0400 Date: Sun, 18 Oct 2020 09:29:06 -0400 From: John C Klensin To: Ned Freed , Alexey Melnikov cc: "Peter J. Holzer" , emailcore@ietf.org Message-ID: In-Reply-To: <01RQXZC8Q2RQ0085YQ@mauve.mrochek.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <20201016224850.GA16002@hjp.at> <0A01EB8802E261F7D7DA2EB4@PSB> <01RQXZC8Q2RQ0085YQ@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 18 Oct 2020 13:29:23 -0000 Ned, I think my note to Peter of October 18, 2020 00:27 +0200 and Alexey's response to it of October 18, 2020 12:10 +0100 clear this up and is consistent with what you wrote below clear this up in a way that is consistent with your message below. If it does not, please explain. FWIW, what I meant when I said "clear AUTH" was different from the way you, Alexey, and I think Peter (and, in the specific context of AUTH, probably any normal human being) would interpret it, but, unless anyone is really interested, I apologize for increasing the confusion and let's move on. john --On Sunday, October 18, 2020 06:03 -0700 Ned Freed wrote: >> Hi John, > >> On Sat, Oct 17, 2020, at 12:29 AM, John C Klensin wrote: >> > Peter and Hector, >> > >> > AFAICT, what makes this complicated isn't what the >> > client/sender sends, it is that nothing obligates the >> > server to return the same set of option offerings twice. >> > Since the options that are in effect can affect what >> > commands and arguments the client can send, that is >> > potentially a big deal. >> > >> > So, RSET closes and resets a mail transaction, losing any >> > information if MAIL, RSET, etc., commands. Sending EHLO >> > once that mail transaction has started (e.g., the MAIL >> > command is sent) is a superset of the RSET behavior but >> > also clears the options that were advertised (and may or >> > may not have been accepted) the first time around. > >> Agree so far. > >> > A second EHLO being sent right >> > after the first one (before any other functional commands) >> > seems rather silly but, but, if, e.g., the sequence were >> > EHLO ... >> > AUTH ... >> > EHLO... >> > MAIL ... >> > >> > I'd expect the second EHLO to clear AUTH > >> As an editor of SMTP AUTH (RFC 4954) I disagree with EHLO >> clears AUTH state. AUTH state is sticky, in the same way as >> STARTTLS is. I.e. it is not possible to clear it without >> closing the TCP connection. > > Alexey is correct. Absent some sort of UNAUTH commend (such a > commend presently exists in IMAP but not SMTP), AUTH state is > sticky. Moreoever, the EHLO cannot work this way because > issuing an EHLO is the only way to determine the state of > things after AUTH, which may have changed to include new > extensions, or disallow previous ones. > > The same applies to STARTTLS, and here there's an obvious > use-case: The AUTH value can easily change after STARTTLS is > negotiated to include cleartext optiosn not previously > available. (Or if STARTTLS included authentication AUTH > EXTENRAL may be the only mechanism available.) > > Ned From nobody Mon Oct 19 22:02:33 2020 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 775BF3A0C26 for ; Mon, 19 Oct 2020 22:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIyU8MlyLYoi for ; Mon, 19 Oct 2020 22:02:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADCD3A0C24 for ; Mon, 19 Oct 2020 22:02:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kUjn3-0001OM-7f; Tue, 20 Oct 2020 01:02:29 -0400 Date: Tue, 20 Oct 2020 01:02:23 -0400 From: John C Klensin To: hsantos@isdg.net, emailcore@ietf.org Message-ID: In-Reply-To: <5F89DC39.9040505@isdg.net> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.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 #2: Repeated Use of 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: Tue, 20 Oct 2020 05:02:33 -0000 --On Friday, October 16, 2020 13:45 -0400 Hector Santos wrote: >... > We don't know what the SMTP Client state machine was > programmed to do. I rarely see EHLO reissued after a RSET. If a client believes that EHLO implies RSET (whoever 5321 or we define that), then, AFAICT, the only possible reason to send RSET EHLO would be to waste an extra turnaround. I.e., while there seems to be no reason to ban it, doing it would be at least a little bit stupid. >>> RFC 3207 sec 4.2 says that after STARTTLS "The server MUST >>> discard any knowledge obtained from the client," which >>> sounds like it also does what RSET does. >> >> It does what RSET does and more, e.g. clearing the remembered >> EHLO hostname. > > Why would the machine name, the domain name or ip-literal need > to be cleared? It has no purpose to do so. It won't change. > That's a fixed item. I can think of cases in which they might change and the change might be significant, but they are far-fetched enough that, if a rule were adopted that if as second EHLO is sent it must contain the same information would probably be harmless. It also wouldn't accomplish much of anything and such cases exist, so why bother. The reason to issue a second EHLO has almost nothing to do with the parameters of the command. Instead, it is important to get a new and updated list of available options/extensions (and, if doesn't cause the previous list to be discarded, we end up in a silly state). > I believe the SMTP 20 years old protocol State Machine is well > defined otherwise interoperability would suffer. I am not > expecting to be changing my SMTP state machine with this > RFC5321bis work. I don't think anything in this discussion -- at least as it has evolved -- changes the fundamentals of the state machine. Both the extension model and EHLO and the idea of a security layer make the distinction between connection state and a mail transaction state more important than they were earlier, but nothing fundamental has really changed since 821 was published. > I think the best we can do is codify the SMTP client expected > state machine command order and reemphasize SMTP server > flexibility to handle any SMTP client command order which may > diff from the norm but do not necessarily violate the specs > nor harm the ability to perform a transaction -- Postel's > Principle. I hope this doesn't lead to a long philosophical discussion, but that principle is useful for two closely-related things: figuring out how to handle ambiguous specifications and avoiding the need for specification writers to spell out what should happen in every obscure edge case. I don't think it lets us off the hook for being specific and unambiguous where we can... and, normally, we get more interoperability if everyone does things the same way rather than when we try to force everything to have code to deal wit variant orderings and figure out if they mean anything. The commend order is codified now. We don't allow a second MAIL command once a mail transaction has happened because it makes no sense (we could change the spec so that MAIL implied RSET, but I can't imagine why we would want to and even that wouldn't change the structure of the state machine). By contrast, sending ELHO a second time in the expectations that available options might have changed makes perfectly good sense in the presence of options that, if invoked, might change the connection environment. > There could also be security reasons for not clearing the > client machine domain name. There other security considers and > the one that comes to mind is the attempt to bypass a > temporary reject behavior, i.e. a 4yz policy-based Greylisting > response at DATA and the client attempt to do another > transactions to get around the greylisting. Thinking about that gives me a headache, especially since the server would still have one of the few pieces of data it can really trust --the IP address from which the TCP connection was initiated-- and it is, after all, the same connection. However, it something were necessary for a case like that one, the solution would be to prohibit changing EHLO's parameters when the command were reissued, not ban reissuing it or changing the state model. > Finally, most legacy SMTP server still have an human interface > for the CLI-based protocol client/server model. wcSMTP still > has an HELP: > 220-home.winserver.com Wildcat! ESMTP Server v8.0.454.10 ready > 220-************** WARNING: FOR AUTHORIZED USE ONLY! > ********************** > 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY > COMPUTERS * > 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE > UNSOLICITED * > 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL > RESTRICT ACCESS * > 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * > 220 > ************************************************************** > ********** > HELP > 214-Commands: > 214-HELO EHLO MAIL RCPT DATA RSET > 214-NOOP ETRN QUIT HELP AUTH STARTTLS > 214-For more info use "HELP ". > 214 End of HELP info > HELP RSET > 214-Arguments: > 214- RSET > 214- Resets and clears ALL current mail buffers. > 214 End of HELP info > > Going back to RFC821: > > RESET (RSET) > > This command specifies that the current mail transaction is > to be aborted. Any stored sender, recipients, and mail data > must be discarded, and all buffers and state tables cleared. > The receiver must send an OK reply. > > RFC2821 (same in RFC5321) was updated with additional verbiage > but at the end of the day, its the same as 821. The SMTP > client/server state machine has to be prepared for all > situations and I believe we got that all done right. > > Even if the EHLO data is cleared, the SMTP state machine will > handle the situation when the client issues > > C: RSET > S: 250 ok > C: MAIL FROM: > S: 250 OK > > but if we clear the EHLO with the RSET, then we may have this: But, as far as I know, no one has suggested "clearing the EHLO" (or otherwise resetting the connection state) with RSET. RSET either clears a current active mail transaction or it is a NOOP. If 5321 is not clear enough about that, then we should fix the text. But I don't think we are disagreeing about the intent. >... john From nobody Tue Oct 20 01:19:29 2020 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 A3C563A0B78 for ; Tue, 20 Oct 2020 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzSEmEmOQL37 for ; Tue, 20 Oct 2020 01:19:27 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DED3A0B76 for ; Tue, 20 Oct 2020 01:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603181965; bh=FwoMzW3OlVg984ocZSGIrPYKpjsmmgtRe8/gJciDOBo=; l=619; h=To:References:From:Date:In-Reply-To; b=AqJGS7jotnavJokgbMhV6BsEsiV/ce1mav4qOHrsNekFDBAag+QlbnAjG/evBs7Km nmQqaUO8x2c+jNNAzxSbSzF/pH32FPQCbA20svRCpgr9AhjHg/soWLYPHW7k1AN2+5 hkZTIN7VtAmwK2L1vUPt/8CraH3d2IatYaGLKApgFnfLp+zSgQnDCwE3+gdGg Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC0B0.000000005F8E9D8C.00001C94; Tue, 20 Oct 2020 10:19:24 +0200 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> From: Alessandro Vesely Message-ID: <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> Date: Tue, 20 Oct 2020 10:19:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 08:19:29 -0000 On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote: >> There could also be security reasons for not clearing the >> client machine domain name. >> [...] > Thinking about that gives me a headache, especially since the > server would still have one of the few pieces of data it can > really trust --the IP address from which the TCP connection was > initiated-- and it is, after all, the same connection. How would that work with multipath TCP? MPTCP "aims to be transparent to both higher and lower layers". However, can't a second HELO lead to realize that the IP address changed? Best Ale -- From nobody Tue Oct 20 02:46:01 2020 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 9727B3A103A for ; Tue, 20 Oct 2020 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=q3MxCgj5; dkim=pass (2048-bit key) header.d=wizmail.org header.b=SMfy8Tp8 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 c_VKtbQ58P-H for ; Tue, 20 Oct 2020 02:45:58 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449C03A1039 for ; Tue, 20 Oct 2020 02:45:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Subject:From:References:To:From:Sender:Reply-To:Subject:Date: Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive: Autocrypt; bh=HiikD19YY1s3mJKngERLnVjqVJZd98HzdgfnFe/8B9Y=; b=q3MxCgj5GjMSOpm sYFMiyw7gUzRqaU+jNOPjm2AlAQa7usezl0it+8hynfV1vs8ddRZoxX3CQO7YISvoETuLBg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive:Autocrypt; bh=HiikD19YY1s3mJKngERLnVjqVJZd98HzdgfnFe/8B9Y=; b=SMfy8Tp8PiPQ0r1QKY3F+PLfBb xvqJ4adHxbtH8ghSZQzV127Ruvk1pi/yrYgCHUFdUX9of7Juagt2TlwXRQBkQdXu2eKnkGjt7MEOH EFsg8Wk0V6Q+vXS4jXU2ZovGRv4VhJ1PRA6bxhZp4K7+hRMv11IQ7BS9G5t63Hfjd39GWpGUcbSQp 6Qbas3kEmMyBpiYNW7iP625wXdrjjrBLRjNcQIt2GG5GSyDe63XvvemdJYkNjgd9IZBWKIz4matoG nBB7cVJ6imbNNRvUcp8QJR9Y6On0RGfPPzy4hcyHAifYZg0cdyAmjFYgOzUkOuEnF8NMmsIOEL4im Bl7X2nNg==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.108) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kUoDL-00GOyd-Cu for emailcore@ietf.org (return-path ); Tue, 20 Oct 2020 09:45:55 +0000 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> From: Jeremy Harris Message-ID: <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> Date: Tue, 20 Oct 2020 10:45:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="55nZRMm1oJWLdhswo2zzZKyG6atc5nlsW" X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 09:46:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --55nZRMm1oJWLdhswo2zzZKyG6atc5nlsW Content-Type: multipart/mixed; boundary="twGP1KrN3KF4KNJt24wRxf2bN9AYgwuoT"; protected-headers="v1" From: Jeremy Harris To: emailcore@ietf.org Message-ID: <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> Subject: Re: [Emailcore] Ticket #2: Repeated Use of EHLO References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> In-Reply-To: --twGP1KrN3KF4KNJt24wRxf2bN9AYgwuoT Content-Type: multipart/mixed; boundary="------------6A5A982A63F9B32F4AE67FF3" Content-Language: en-GB This is a multi-part message in MIME format. --------------6A5A982A63F9B32F4AE67FF3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 20/10/2020 06:02, John C Klensin wrote: > The commend order is codified now. We don't allow a second MAIL > command once a mail transaction has happened because it makes no > sense Nit: I think we do. RFC 5321, 4.1.4 :- "The MAIL command ... begins a mail transaction." "transaction consists of [...] and a DATA command, in that order." "There may be zero or more transactions in a session. MAIL [...] should be sent only if [...] or if the previous one successfully concluded with a successful DATA" Perhaps you meant "started" rather than "happened"? [this doesn't change anything regarding EHLO, which I don't thiks we have a real problem with] --=20 Cheers, Jeremy --------------6A5A982A63F9B32F4AE67FF3 Content-Type: application/pgp-keys; name="OpenPGP_0xBCE58C8CE41F32DF.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0xBCE58C8CE41F32DF.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpDp= 6zD FOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcjifOTM= 9C7 +Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7vVG8RbRUW= jQy xQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keKtTBp98/Y7/2xb= zi8 EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEBAAHNMkplcmVteSBIY= XJy aXMgKEV4aW0gTVRBIE1haW50YWluZXIpIDxqZ2hAZXhpbS5vcmc+wsCOBBMBCAA4FiEEqYbzp= r1j d9hzCVjevOWMjOQfMt8FAl4kUrYCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQvOWMj= OQf Mt+dqAf/bLKl+fzSgRXtW8HALADDAxTwcJKbF+ySo+P60G5NGGTqYpajbPxER+WpCa1O4pDKs= 3XU 8HyZQx1FhBskYlUyoiFXfFylliGwDXv5IeKdh9VPIiWshZuRIJe8DmGclH22vUKdM2ZkRMPsp= YxI GpJWLnvFGE/97CiJsW39fZotffWszb9nIxBUPOsNnKhrA3c1pn8kN5PhyfOy5CUwO1xmxlTYp= DiA xwXN+emNipxpje/YrTH0JFWDd8Tl4/m8DfFpTJdahfxkcF4sQve/DU/aHboB4KSRmDyRqyFj+= DX5 wp1sfdHX6/gpwwQW3M+lP0wxs0ghaFJsKRNh5dQk2m2UPs0eSmVyZW15IEhhcnJpcyA8amdoQ= HJl ZGhhdC5jb20+wsFcBBABCgAGBQJWregpAAoJECYQG2L2k3bOQ/0P/2KaHAnOE40JkRg4u25+q= IBu YM2cz0KI0qvIw8KIzk2PaXMZX+bqAKcvpZ9O4/ffJO7TTYERC1lxGDdP+595ZlM8wR18LIygv= 5Iz DElPW4/2uBt3+y9zGZbX76LCjq8Lfk9QgYbRqazaOhTS6G/5bnFjdUzzEugQpWhqpWOrXzoNu= eB7 jE7a6hwHvqXKvmtQNuJBGG3onHuLfuFjMZ0vOuaAEx8qBTOSw3cprcqVPH1BwpWnY6ejeK2jO= wOl t1UwYVKZGVYUF3XBlWP5wOXPotKFxGfG/5S9+w1bWivgL/NOQCL3XIC90Qg5gLDl2eMDv48gp= P9C 7HmAaYd/Rxc9R6iNDnLelRh1DdTqEeDmfyJR7OnymgG0i50N+j+F0VzWJHBIymFPsJtq/nxe/= FFf gwTT9QkJOrOhDVoY3yOA3YHb0rmyyHJITm0jxUZpCnZsImEKkkm5SdCSWKspJqcZ8U2ENkyEx= VCT ygOAqw4LKctHwp49bOhX5riTlomSL/UjRCJQqhgy5JdLJts77Igx3ahDK8ZVtSY1NT4bV6ueY= Qno cXpsbITDjmd5bjJkrFmi9TM/uS9xYeb4k5Wm5/ZpvKEFUPRzEggX6ofmHHK4eiNPLnVRFxLRs= tIa kkF5or/ECxKv6FSM12RuHQ7tTPlJ5CuHPyjT71h86WKQv/c2I44wwsCOBBMBCAA4FiEEqYbzp= r1j d9hzCVjevOWMjOQfMt8FAl4WMuQCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQvOWMj= OQf Mt8BrwgAxusgDbyLf8vf5aXbi82c7TWQzm+C8L7gQUyinYKEFwYXzEmlMcH0jCur6jJGGBQEf= pn1 zuNGK8Sat768DkbXaKbRuAZdm6DxCvrYS5+f5ix5fnUx1vSvJFf3iOeICF438JQFk1KlBBRSv= DLA AGUPnYuEJhCON5QJL4Vai95BRCox8fkfnq8XrWM/1+t3Nrs2MTAcEmGGXLR4vvSKe5vzxZ0eg= bKq xrzuiqvaGDCGQX3QjZEEmKMhmY61s92z4JuJGxoSH/93mf29nIfppud+ZGGnGXO3drw48Ujzb= Rfh isX6ju+dHHNrZeD+xWQhS9TTBRAqqlDerFVSxG2RVqarJMJGBBARAgAGBQJViVA4AAoJEOmEk= KDG FGPeHzwAni4L0r6i1qV6wBaE+5mav3mEAB2LAKCedUhRd7zQhO5BEEQ5NolCEXxrvcLAeAQTA= QIA IgUCVYAWBgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQvOWMjOQfMt/0Bwf6Ah3UW= uUL 1L2wChjHXktv0j8oQmL8CD1AUYkg+4NRTkZTm5ngZlNk4ZSJB7sonaEmzs30fw9zex8LMtCMn= EHQ YtFNb6r1M2QfMS8ZUdeaUNmlGHu8UnHqr+aTkQbQsvhs/UaLknWlOWqdsM29Z311yGA3BdlGx= w/2 wej+AtRSazT4dEISP8K8xfnoQmhIVUZ33aMVDF70iinmAfWfqUKhgRctrVMLgXxKtYiOeTGXD= tm2 dnvXTHOO3u0N2skwc6YwOxLj1XXwWL6KQJx77/2SqVHDJVeEkMEb9Wr/e/l1PggU+fYxLZ5/H= WbG atNmoRFoYNuCGlpBL9XOuQK98PcIysLBXAQQAQIABgUCVq5HxQAKCRCtXtu3k+xX5EB+D/9Mg= eeM 7ab8NVHauF+lNBFmSqT+9GpaZZCJlNv0C7+cittY6hUpr6fKC/t4m1n8k1Y2JP9iTjfMW2m8w= VBO XR8HbB3TD2Bmd8C23aNuOrTxzztt+PDZbdNsx+A315PEoMJ3idTxfTduNa0YOhsEoX4iAMhxK= ZUR DDMDvPq/FcFnqfYE48Oz6E04QMOAZqDwdEe3ntk1bt3RsSfdIvWT8NqgnGQ5V65XsLPA+UCld= 7JQ QiefJONJoXMr3yMspjtGgVF91tE+ph4ToNwI0q4XYr9r0jSjIvdjuJzvcXIQ7ClvqFXPRwVmF= Cq/ YIatlLkr/zkQUTeP9lpCX/85MZoiYUhjzUABn/fIFpgkdvTQ5bjZHai5WKAmFAT7K55FtwLKF= +tc cHh8X9EjRyWBWUfdMWxq1+/jz9xV9RI8llcsWVH4z/aOxpE7u64M+uc7J0KYNAdCtLvDAEIFi= YOs Bk2gUrE9f4lbMsB3+kCh3Ek2oUNF+APPD7yi6Qwgkhj4t20551ro7/RBbKcrjXCLTPzZNNfJS= Cww MS1HBI3jM5+AKqOUvWVlgfx58Kqjs1FyWitiLHEDTUr7jLtd2CtdcVf8qHzcGq/xsvpLp6YZt= ct1 uJOwUUlnk5PrDZ0M9DPsFDXH4c5LBnJUBFP7xBWxnPcWvAkY0myeSVvMMVjxvDDmsyG7fMLBY= gQT AQoADAUCVq3n8wWDB4YfgAAKCRATT/1qvnuFjcSuEAClqm10kW30akfkxmCmWM/vsi/tf+TWB= gH0 c7L43wMSM/ZQH2tL3JcZEsTxG1VOFc2I47JE4C5pLLDxJw19MqbiB+daNEUztJMJTIifmeQ0o= XWd uWD6tapI6QWSncmfn79gTa6IauJ8vT+EiqmEfjMuto5BEEM6b2liVMjBVe0pHb6ryA/TOgdfm= 8Ky v+/WEeX15faQyWhLnWad/7vnaMkpgQOryd7ZH5IFgPe8uHm/7UyeBJzOQxP26GAo0HHb9Kuup= FOL ta8/M/EDPwaGPVD3MrfUoxq5L+k6YgTr+nsR6qXri6O9LoXYn+daWxW5rmEfTl9zFrgkHsCDi= ysd 1lHnQbt+5Lo0zpwMpoacow0UTsBguH6DXez0auQOl5/RLTprTnRdnhv4hQzcWVI42eFEgV2Mb= 6sa TQ8pPYWsehvBMXIXAwUQfx9eTVwq3uCDIWLAmr1RJZPSORBFzlGT8JzoMA4Sf9NVKHEroxPxz= Crl Gr4ObukKKcOY+fXRZ7uveYdlw/FxKNpFLdrisGZRxwAU9rYHRZBrZc6yV3yp1/Xz1cC0jAtVK= AUV +0jvXKuXe0IT3LRi2NajNsVft/Dd/r1gOiBwhvPadsb60U6fwwKpDiqqYHLvez05Z9QP3xUkv= GWx Yf8u0OAQ/i0JSxBgVDc3utFSWpAKK4mOimH5DlrD68LAXAQSAQgABgUCV7/QZAAKCRAjRRsQe= qA5 QQjsB/sFCVVPuyJ0fe/eor2lRxSAvEffkcoKBK+N9CzCqZrLbP3qABw7brlnTSIjxuBYYe918= 2oR oWw6XN7dWbKfO3euX5cNWGycX9tURFp0cDO5EugYUa8O3xwC0mkb8K29Y9DuZNL9ZDmVDMCxg= k0/ cZuaavD7qartWYvCsIWaOYR0pVbpvU+qnuYlNy7pRfx0I6P13AAqupwXWLbOzmGlyF197p+Cs= fkX Pf8RS7dEDChz+06vVN/aUWVYEkThx8AlIrreKSxiOqgIVSV/FIk5bUtUAnb6FZuWMpV8qmtLe= DFd m5w/Wb2o09BOWCGGuMLKgYmWcfnyUPpprXD24rLacST0zSZKZXJlbXkgSGFycmlzIChub25lK= SA8 amdoQHdpem1haWwub3JnPsLBXAQQAQoABgUCVq3oJAAKCRAmEBti9pN2zgcyD/9gxU/bwwBWW= PRQ 5gJNfK9RoKsm1Bls6NMPMNqHqnDTozCyOsUQxIWSkkB3Ku49muGqVdSIUFhK6jux8n+rGyP+2= +Vf drWDTzuKQkPj+bi+djnYG+iB0St3uzAmXmIaawuaXTk5aH4yFlvtF2wwyXsaLrhc6aYlTXK89= Y2b gOeAPL6tVL5g1+KlxjfyxmxgH02l6U5LK/PubfMQvoQg5VcpprA5jIsx/GO5H39opwHWWIyVO= aem jZc+OARRxyZPigmSl02MqPmzArCnOWu/3jn99LV48yLXOLlhdsJvVGxvuEdTF93uW4AGMCme9= sGd LwIZdrAw5x0DNpQbf8sxP9X5eVMcJpmcbThFj887Z3rfDIf87nFV1kHeVTFctG+IdUY6QCL9m= /Vr qYGI6JCTnvN7v4zmNsscj/dGiFSFjpd/Zx+HPxQuzBL1siZnsW1WBHPae0sYFajueYPSQ62Eh= mey A5UvYZIA1khL5K1119pqcOb8OE6BaCAklmA+Cp7rU23vuX9G+cnh+td9Grap1QbU1NIvYx2bg= pYU NiiPmzaeAnCyE0KrSNdavDF6dWjOW2YeXfwrA3fPH7zDsfVJxSDBJua/1L4SWQ/WgN4+PQMDm= tgb ngASYRU5KzegdFJzl11azf2ndTR8QZzKhhthaqGESK8y57y8Wnx+Fwp5BM/HisLAjgQTAQgAO= BYh BKmG86a9Y3fYcwlY3rzljIzkHzLfBQJeFjLjAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAA= AoJ ELzljIzkHzLfeOoIAL6g69o71ZxiDdjY545dooissOHWHRczYWYI02q8olfdAX7VA8UbAbk1R= VAu l1PgddzBIEitM0Q8iOTaRB/iU1ud/YFpZs9pNlk05qAbJv47NRC6AIxq/4t9kgcqptH6NyT3L= Z/5 XO6E6NJrhmLwecVoUx0ZXE/cxk0VG/+rnGm1S4iVK3BoUtTqgxqu572EKRWXXw4+4csqwiq6u= mFD 0b6Kt2lsP6Omj1DfIJiY/oeKQeXTG2zSpu7ps+Dt0R1nHjvSQhmMXwuLodJPOW4CFW+MLWpYw= Vvd GGUVP+cyIw+q9m+q5bmOeay7pbMk+8QKnteHhNQJUQdaIP7OK1LUX/DCRgQQEQIABgUCVYlQO= AAK CRDphJCgxhRj3iOqAKCCwcoqiYhY2NFNbo9jQf2ZOo2h6QCgty7WOW6bRy3NxVkGTjBuprg2F= J/C wHgEEwECACIFAlWABsQCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELzljIzkHzLfA= HYH /3vLPwMg/HkAFifi7cYuNK3EhXOLmaf6hKzF2RVf1mfn5wwOBOwZj6uMyMAOW6Rde3ncNsLIf= t5u CDrR32KWr8iRcxjC+arS/ikumWEgmRsriR01K2ZiHCG/cgYkId3x8BNQ7azqd0OowHJVwrELp= CJX fQc6vvRTGtHAutt/DHW5EDryy6g96dj5xTK50zbm+eGEQChvTpjfahRiK+y+cQabmB1pqeWzY= 9mM PF2dBNUFGlCbZdpezVg2H/6fisE/TGbyC4T1Z+NWatX5vGW44CrMEECFsF/zXVNrEgHWAmv13= ZSv XDkNcrf3hKca42A8WxPxTv4U1qWV/Hm+l6DFWAvCwHsEEwECACUCGwMGCwkIBwMCBhUIAgkKC= wQW AgMBAh4BAheABQJVgBgEAhkBAAoJELzljIzkHzLfiIUH/3CjMhhGiA11jVp6MUWLFvr77LhvW= uLK My9YRQt4TMOVDSUxPpnc/FeFkgsPjLho/srPHSjNdrmporLjUQA8pCg+KmdEAfThDK0lsgRG/= PxO i38t4JUpRzQb0NXE48EPTdzNOCqDPgSNXaq+csX6tNTRgF6+s0KW4qiwZJ37dG8tZW7SEGGf2= kQs p9ck1JBdlv5OkcOFINn+AKuCUEQ6EDphZsNv/iDP7lMUp2T4H76IBBlIe/vMhJpuM34E9iAjj= sD4 xTgnJyhdoBScxzSXltrp8Y1oivOu4ThoBmuU/mj7uaVT0ybRAmp2pjFg8CKmUkatm/5hcfV+n= m54 QreX40bCwVwEEAECAAYFAlauR8EACgkQrV7bt5PsV+TQCQ/9H6pGxoZaHzkQjtZJQwu8iP6ZE= hNG rKXRY1ymw/MyIzJToykIsoZvAAahmCXj3bFj2mpq0pYtRlWYRaAryowrYR8qViC3wgPrWu0rl= ARS YtOm/BLnRv5hyR+1cGXNeKV4Ic2zfNLP9coIFmJO5/eJ1tarw8u3uImsbsQrcZ33bI6BxQ9NX= R// Cbsl3NQhygtMbrmLvQ46/JN+nL2Qp19DryIiF7PaoQstqOpGjwD/SNk9lPHrU+KGrZH1pNlgD= Zhw D2q1rG8R5ihRH/QiehPIaeGqq82TP1RkOGrNlGVHcZHnJz7/8hkJkGlJyPkl9ZgDwDmNDiWTJ= Zop 2WsO3wVpN/phSqBwXIYo3xQGOxunBqwWAS2KZlFCCTno7bJm+uX9SeRlLWUUQM4waZIHaCopc= N1q gY7UPjIiEvHotqyVatqPfClCvvUiosy76bd7Uy34BO8zzDGa0TDoqUZLZfo7TgqtCPxkiTxit= 5X5 dIYoXXdzhWsenN9rnD6HH6DbAKJZUpcW9+lCRLn3ZjslcdAQL3znLh69q0voaD8dkYwSvchlm= cVt KeqT5QjPkizrVtA5RUtB9KjmMcI7fTgnwCRWeTuONA7ct0xDMsZCDprTKmIgAkmMGE98obwX9= tcW svbFfQCNgADM7E5DEWqV1zKzadvEkYVBdk3SEisrLAAnGQzCwWIEEwEKAAwFAlat5+MFgweGH= 4AA CgkQE0/9ar57hY3toQ/8DnPLUxItOUTEZUGVWJVTMV5yu5Jv1SfQM4Tk7IdCkAV+ZxXrAm8GM= 4Xl /sMTgHNGMwBYRkrmW9Tdgr29Q03/JIP+ha4HbTIw8kbrjvDpXRMk87/1KVAB46izburyWX/3v= ra6 jK+rLtgQ7Fze2UOvvoBstPIkXS60qqbA9NWf+9Eq+mtFtfK8+bEz7HYM2wBh6mJHkSKVQ5y1O= lCW 6LR8grRbCi9MhltiPvvdZV9FL5TwcE9bNSWtNGoNY2yQhMzuSw5TNEjr8SeiyyOrA6jbEFIhn= knH 6Fd0x/K6G4fFd0hHfwW3zh8X43948Em9nJrQEjeT3w6uIsWv7keSgNtqizQdb5MJVp3vv31tF= h81 vtwGupArwjnts5Y76dbIRn7fXiNCMbw6CRu8Lfe/wXBMaSJLGOcqQbJ2phEU6OONB+lUJU7Mw= e4a TZHhYlpPDN6HmybNVBDJVOl1WylrjlDf6YukvG0Y9bxIgutHOP1DDaggDFmdGGQGq1QQrDgIi= sIr Uhh92wUkJ53RXqa7TjcBwGn3oe94V0rtPR4Y7jF++2d5M7WH5asjjnnwFHTqt0Vltq2aRhaXk= aIY 5wNtTbTPAjBwogh7O8AB00rwQ0RrbmqXh6S5Z7/YUAPG1ffRfKL6aUprlsDXz5OKmZZkhyogB= dsS 8jOqJzF8CdFOVytYYYfCwFwEEgEIAAYFAle/0FsACgkQI0UbEHqgOUF1WAf/Wh61UDMI+ZYMP= tZ/ Xf+btpP8kF2bhD8noaGrfbmk+PgZCyRNq5ueJXFsxYeSKEPOAWcgS880E3Y5Q8WRojF8DiwIN= I1z qiJeGZe/v0ONCyYe4TN5eE2uv38Lv3Nc411TXeacVg9io2ZFSMJINyOTu5qiVruLe0m714J2L= kE6 TiCB+QxtVWjGWdtNPGNh4PXU1G8GLq0YERCBv0n4rV4XW/u1CmednjfW6HYUW+AzxDl87z3d4= ywb vZqLqcRUOBHZpZQWoyq+V0ZCm7XzbgZiobrw9ghYYcWlp+iXY7J/4X1NUqlRqF7J08eIPTb0p= Pov ZxFZg0LVub641hart5xocc7ATQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns= 0QU KWkN9qfxdlyBi0vAnNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9= XhA mR50cxYRpTpqulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvy= zc/ le32bTbDezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6b= fIg tBj2ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPG= QAR AQABwsBfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw/= FBx ZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYoBXnFQ= 444 pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5RvqaPOx5vhNM= M+L MCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP7ONCnDaHfNzTO= B5/ 7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/mpsWwP2JSveS3nbLc= Lzf lnB2e3fvgK7OwE0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60zTBvb7IMm0Rfaeb+s5vk0= bX6 Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3iiZc62ERe5dRIr9EG1DAN3SW5f= Rc5 H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzsklloqd24z8c/+3C5cPjI26hyGFR0W= 5Q1 T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3BEUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXk= aOS EtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8ooHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAcLAf= AQY AQgAJhYhBKmG86a9Y3fYcwlY3rzljIzkHzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfj= g4I AM2GxIUaXLfO22z2JWS3byFvfRNSeXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBa= eH+ +LfzSghKRWLx2PdJlKzThyFiy23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHY= cf4 F0O3YgdoqGKR7m10jqXzgzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwp= OvG 4cQrMWZ0tg1txwZ/DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgoj= D5k kagRLURuYBefCxJ/k6RTKs8juRsbVGfJMmNdfyLOOAReJFQPEgorBgEEAZdVAQUBAQdAPr/8E= gFM 8AkB/CZz+BGJIezPAdpTYFLvRhsem2GoBicDAQgHwsB8BBgBCAAmFiEEqYbzpr1jd9hzCVjev= OWM jOQfMt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4e= tz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z8= gJ5 vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lwPYLeF= 6Dh 4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrRx805g1J6u= xix rMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIzxrAkJFP/CS+qk= jMI 47FKq1EzbQ=3D=3D =3DPwYM -----END PGP PUBLIC KEY BLOCK----- --------------6A5A982A63F9B32F4AE67FF3-- --twGP1KrN3KF4KNJt24wRxf2bN9AYgwuoT-- --55nZRMm1oJWLdhswo2zzZKyG6atc5nlsW Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEqYbzpr1jd9hzCVjevOWMjOQfMt8FAl+OsdEFAwAAAAAACgkQvOWMjOQfMt/l qQf9HCi1dGcLtxvrn9nq9DmIsAzNc0bpQEZbEJvELIpesTilYj8c7Zo7rjE5GYfZhRmB1f9xaMZe GZiobHyPGTsklwXp1mXj1V5qpPT+OiWSTyGZHy8kupqQL7fNciJO6MB9bMnie96k/s/ftjukbUXG tHx2J6o5unGkwihEPDu/ZkmQy1FIK06D0fUrJCnQhtcl6WMs0PeEUfj8C4AAWVAZi2CQS5Z6YkN/ 3Yo0BWWhRiTDP31c1OzfiQVv5MylaOGxkLMfM/9DAkgpm+rpDhwpbznFc8OujVLNfGO7+Yeb6QLe DTld8tUJG55bj9+0xoYA5mxS2mjog3bnWuyPae6dhw== =8oxR -----END PGP SIGNATURE----- --55nZRMm1oJWLdhswo2zzZKyG6atc5nlsW-- From nobody Tue Oct 20 02:55:55 2020 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 B3E4C3A105A for ; Tue, 20 Oct 2020 02:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Gf2YdY1S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oZVR2n/Z 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 OLAwZ6hzSKF6 for ; Tue, 20 Oct 2020 02:55:53 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ED13A1058 for ; Tue, 20 Oct 2020 02:55:52 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 391B15C0237; Tue, 20 Oct 2020 05:55:52 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 20 Oct 2020 05:55:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=qfpIpyLgpPReZiXpuLUihOpJUcLn2a5 0dA4C5L+utqg=; b=Gf2YdY1S93wspz++S1Es8FjQ6teY3rASGl1Frw0gchR5dgZ IcPYM5SkVnv3MQdnQBIq1uJi3KuUE140Sx5Co+h9+thy/BDtvjkxHtpknIAXGXLc 371I4Wqfy5cmyGT1LEg6CywXL3XdhVrftfoPGRYF7Pd8OvDY8s1m+wBHGzOZNAj2 EO5KshUBdpTBGR3vYzd/jRpMMIftu9dQihcgzxxY4E/afIxR8bLqInR1l8OilYGD cXXTIkRB31YM1wCU0lZQ08hlMgouAfHpOIXIheHi/mzOXLZ9hebtpQ7DvobPx9jI fp6ET/krboJSaLZiSG+Lw0FXKlBItNoQqTn20nQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qfpIpy LgpPReZiXpuLUihOpJUcLn2a50dA4C5L+utqg=; b=oZVR2n/ZPAbjXepSznd2yZ okM0l6FXr3W/Xx3DNw8V9/4KpvjyomK0SHEZXtGtcZip4FA+/UFzDTvJL0YpnGTh 1ZcQNQnSWNUfTBDdfEs6T7RPixsM2L75iyvAo97TjPaV7DXoXmLc1hctT7XqOnfy 9WjLi+kaPr1debqFLFHNj8c+VMnDwL91Hj70h1job6iqaSIbpgCMwCbdM2gCRZPp w9YqLi5OIQ0XIIdJYpyPy2dZajqTYAaA2S/XG7rTPhuDzQWvfZ1BvykBBdD9/i7Q 3s3d33t/KNI4EnrQsOx0p2B4pej4PBAz7i6nUagsAsNSX4/2MJ4rF66VfPGOjuww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeefgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeelffdtgffhveeuudeihfffjeelgfdtudfhvdettdeh feettdfhgefhfeeigfegffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhv sehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4090C660069; Tue, 20 Oct 2020 05:55:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888 Mime-Version: 1.0 Message-Id: <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> In-Reply-To: <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> Date: Tue, 20 Oct 2020 10:55:30 +0100 From: "Alexey Melnikov" To: "Alessandro Vesely" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 09:55:55 -0000 Hi Alessandro, On Tue, Oct 20, 2020, at 9:19 AM, Alessandro Vesely wrote: > On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote: > >> There could also be security reasons for not clearing the > >> client machine domain name. > >> [...] > > Thinking about that gives me a headache, especially since the > > server would still have one of the few pieces of data it can > > really trust --the IP address from which the TCP connection was > > initiated-- and it is, after all, the same connection. > > > How would that work with multipath TCP? MPTCP "aims to be transparent to both > higher and lower layers". However, can't a second HELO lead to realize that > the IP address changed? A couple of thoughts on this: 1) Multipath TCP wasn't defined when RFC 5321 was published. One can argue that use of multipath TCP with SMTP is an extension. So I think this needs a new "enhancement" ticket. 2) use of IP addresses (and change of IP addresses) interacts with ticket #1: . So let's discuss change of IP address when we discuss that ticket. 3) An issue inspired by your comment (but really a separate one) is: can an SMTP client change hostname in subsequent EHLOs. I think based on this thread the answer is "yes", but this probably needs to be clarified in the document. (If the WG decides while discussing ticket #1 that IP addresses in EHLO are fine, that would be another case of the same issue.) Best Regards, Alexey, as co-chair From nobody Tue Oct 20 03:20:32 2020 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 A52B43A111B for ; Tue, 20 Oct 2020 03:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E08Uo-g-HSau for ; Tue, 20 Oct 2020 03:20:30 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1EB3A0B88 for ; Tue, 20 Oct 2020 03:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603189227; bh=H8lr2uCoIpPxy/Es+yFwC+6ADmXJnEjhGxHhRmkJW9Q=; l=1663; h=To:References:From:Date:In-Reply-To; b=ALb6UVsW6I9wg9hY0a6FE1tGIejIgs38Zs/MP2UhUVVAKINk8hphuVCQic9MbhLHc pbRP22GGFiLPuESwD+1fexsQb4W1aE1FE9RXyqE8xqeHU38y9IYx0qG1OBf7G8MIsE TWOfKy5GG5e7YnporDTpke8kMUjVKMh4UtK068+K2a2JEdKwsiu61q/vpuAOt Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005F8EB9EB.00002B1E; Tue, 20 Oct 2020 12:20:27 +0200 To: Alexey Melnikov , emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> From: Alessandro Vesely Message-ID: Date: Tue, 20 Oct 2020 12:20:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 10:20:32 -0000 Hi, On Tue 20/Oct/2020 11:55:30 +0200 Alexey Melnikov wrote: > On Tue, Oct 20, 2020, at 9:19 AM, Alessandro Vesely wrote: >> On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote: >>> [...] the server would still have one of the few pieces of data it can >>> really trust --the IP address >> >> How would that work with multipath TCP? MPTCP "aims to be transparent to both >> higher and lower layers". However, can't a second HELO lead to realize that >> the IP address changed? > > A couple of thoughts on this: > > 1) Multipath TCP wasn't defined when RFC 5321 was published. One can argue that use of multipath TCP with SMTP is an extension. So I think this needs a new "enhancement" ticket. Yup. Possibly something that considers "TCP-like" connections, including TSL. > 2) use of IP addresses (and change of IP addresses) interacts with ticket #1: . So let's discuss change of IP address when we discuss that ticket. Ok. > 3) An issue inspired by your comment (but really a separate one) is: can an SMTP client change hostname in subsequent EHLOs. I think based on this thread the answer is "yes", but this probably needs to be clarified in the document. Some (virtual) servers define a different name for each hosted domain. In that case, it may make sense to change HELO name so as to align it with the return path. > (If the WG decides while discussing ticket #1 that IP addresses in EHLO are fine, that would be another case of the same issue.) IP addresses in EHLO, like MPTCP, seem to have more to do with Submission than with SMTP. Best Ale -- From nobody Tue Oct 20 06:31:47 2020 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 BA1E73A0B56 for ; Tue, 20 Oct 2020 06:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 yzPg8Alzv--N for ; Tue, 20 Oct 2020 06:31:44 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 05FAE3A0B45 for ; Tue, 20 Oct 2020 06:31:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR0SLLY6UO009ZGJ@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 06:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603200400; bh=0NV3yOc00FKiVxVYlEjVyYy1zZAkziSAN6mArDbetVs=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=i/4POT0wjejU0BMSjYr5Nn/PZHOItNy5WVQIUJBJEBnA1eKdaOjhKJY9YyuxDfyhk snVsJT9EaK1k9jVUlhCn6JWIdlbdF4Yjq7JhGbowuolB6tdcaIK4oEOGCzx/XsZHNl HDKOVbVhFzc/2JTQfGerjJjPVtSDetyiMgYB5L0Q= 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 <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 06:26:38 -0700 (PDT) Cc: Alessandro Vesely , emailcore@ietf.org Message-id: <01RR0SLJ91SS005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 06:07:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 10:55:30 +0100" <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 13:31:46 -0000 > Hi Alessandro, > On Tue, Oct 20, 2020, at 9:19 AM, Alessandro Vesely wrote: > > On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote: > > >> There could also be security reasons for not clearing the > > >> client machine domain name. > > >> [...] > > > Thinking about that gives me a headache, especially since the > > > server would still have one of the few pieces of data it can > > > really trust --the IP address from which the TCP connection was > > > initiated-- and it is, after all, the same connection. > > > > > > How would that work with multipath TCP? MPTCP "aims to be transparent to both > > higher and lower layers". However, can't a second HELO lead to realize that > > the IP address changed? > A couple of thoughts on this: > 1) Multipath TCP wasn't defined when RFC 5321 was published. One can argue > that use of multipath TCP with SMTP is an extension. So I think this needs a > new "enhancement" ticket. The history is irrelevant. Given that IP address reputation is a key component of many filtering mechanisms, including but definitely not limited to simple DNS checks of consistency of the the EHLO host and IP address, any use of multipath TCP is going to require substantial specification effort going far beyond this work. > 2) use of IP addresses (and change of IP addresses) interacts with ticket #1: > . So let's discuss change of IP > address when we discuss that ticket. Let's not and say we didn't. This is another can of worms we should not open. > 3) An issue inspired by your comment (but really a separate one) is: can an > SMTP client change hostname in subsequent EHLOs. I think based on this thread > the answer is "yes", but this probably needs to be clarified in the document. > (If the WG decides while discussing ticket #1 that IP addresses in EHLO are > fine, that would be another case of the same issue.) Of course it can. One of the reasons for issuing a second EHLO is to get a set of values you can trust after a security layer has been added. This applies in both directions. As such, the server should always replace the client name with the new one, just as the client should update its option list. I suppose it's also possible that the client doesn't want to reveal its true sooper-secret name until after the security layer in place. Even so, I think it would be a good idea to say that the client SHOULD NOT change the name it puts in subsequent EHLOs. Ned From nobody Tue Oct 20 08:04:15 2020 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 D8C963A0FCC for ; Tue, 20 Oct 2020 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0o2Si6RlLm0 for ; Tue, 20 Oct 2020 08:04:12 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314123A0FC9 for ; Tue, 20 Oct 2020 08:04:12 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kUtBH-0002yh-Um; Tue, 20 Oct 2020 11:04:07 -0400 Date: Tue, 20 Oct 2020 11:04:02 -0400 From: John C Klensin To: Ned Freed , Alexey Melnikov cc: emailcore@ietf.org, Alessandro Vesely Message-ID: <7B4FD11144F62A9ABA3BE458@PSB> In-Reply-To: <01RR0SLJ91SS005PTU@mauve.mrochek.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 15:04:14 -0000 --On Tuesday, October 20, 2020 06:07 -0700 Ned Freed wrote: >... >> 3) An issue inspired by your comment (but really a separate >> one) is: can an SMTP client change hostname in subsequent >> EHLOs. I think based on this thread the answer is "yes", but >> this probably needs to be clarified in the document. (If the >> WG decides while discussing ticket #1 that IP addresses in >> EHLO are fine, that would be another case of the same issue.) > > Of course it can. One of the reasons for issuing a second EHLO > is to get a set of values you can trust after a security layer > has been added. This applies in both directions. As such, the > server should always replace the client name with the new one, > just as the client should update its option list. > > I suppose it's also possible that the client doesn't want to > reveal its true sooper-secret name until after the security > layer in place. Even so, I think it would be a good idea to > say that the client SHOULD NOT change the name it puts in > subsequent EHLOs. And that is connected to the (IMO obscure) case I mentioned in passing in my prior note. I don't think clients changing those names is going to be a good idea in the overwhelming number of cases. I could easily go with a SHOULD NOT if Ned and others think it is a good idea, but preferably only if we are willing to insert at least one example of a situation in which an exception would be appropriate. Otherwise it might be better to say nothing other than that the EHLO MAY be reissued if the client thinks it is important or specific extensions require it and to specify that doing so clears and replaces all EHHO information offered by the client and provided by the server. john From nobody Tue Oct 20 08:10:36 2020 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 83EE53A1038 for ; Tue, 20 Oct 2020 08:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amvLZXv_3s33 for ; Tue, 20 Oct 2020 08:10:33 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6487E3A1036 for ; Tue, 20 Oct 2020 08:10:33 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kUtHS-0002zg-OW; Tue, 20 Oct 2020 11:10:30 -0400 Date: Tue, 20 Oct 2020 11:10:25 -0400 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: <0420A924A26F37B24F6E1FED@PSB> In-Reply-To: <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> 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 #2: Repeated Use of 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: Tue, 20 Oct 2020 15:10:35 -0000 --On Tuesday, October 20, 2020 10:45 +0100 Jeremy Harris wrote: > On 20/10/2020 06:02, John C Klensin wrote: >> The commend order is codified now. We don't allow a second >> MAIL command once a mail transaction has happened because it >> makes no sense > > Nit: I think we do. > > RFC 5321, 4.1.4 :- > > "The MAIL command ... begins a mail transaction." > "transaction consists of [...] and a > DATA command, in that order." > "There may be zero or more > transactions in a session. MAIL [...] > should be sent > only if [...] or if > the previous one successfully concluded with a successful DATA" > > > Perhaps you meant "started" rather than "happened"? Yes, I should have said "started". But nothing in the above convinces me that, e.g., MAIL ... RCPT ... MAIL ... is valid without something that closes out the mail transaction. I keep being tempted to say "RSET or DATA...CRLF.CRLF" but, given that we already have extensions that enable other commands (e.g., BDAT) that can close the mail transaction when they are finished, that doesn't work. > [this doesn't change anything regarding EHLO, which I don't > thiks we have a real problem with] I agree about "we" but I don't know if Alessandro is on board yet. john From nobody Tue Oct 20 08:32:29 2020 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 9B04E3A119E for ; Tue, 20 Oct 2020 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEZwqK9WaPWU for ; Tue, 20 Oct 2020 08:32:20 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3FF3A1223 for ; Tue, 20 Oct 2020 08:32:12 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kUtcP-00032b-DC; Tue, 20 Oct 2020 11:32:09 -0400 Date: Tue, 20 Oct 2020 11:32:03 -0400 From: John C Klensin To: Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org Message-ID: In-Reply-To: <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@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-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 15:32:28 -0000 --On Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov wrote: >> How would that work with multipath TCP? MPTCP "aims to be >> transparent to both higher and lower layers". However, >> can't a second HELO lead to realize that the IP address >> changed? > > A couple of thoughts on this: > > 1) Multipath TCP wasn't defined when RFC 5321 was published. > One can argue that use of multipath TCP with SMTP is an > extension. So I think this needs a new "enhancement" ticket. It is just a guess (I haven't thought about it enough), but my guess is that, once we started sorting out the details, we would decide that any situation in which SMTP is run over anything but "raw"/ direct TCP would require an option/ extension in the sense of a new option advertised by the EHLO response and negotiated as needed with the client. (AUTH and STARTTLS are just such extensions so this raises no problem with the model.) Without that advertisement and negotiation, one would predict situations in which the expectations and capabilities of client and server would be different... a recipe for interoperability problems. If that reasoning is correct, then the "enhancement" would be a new SMTP option, set of them, and/or a document describing how to specify options for "different transport" or "intermediate level" situations. That is, at least IMO, so far out of scope for the WG as now chartered that a ticket would be inappropriate. If one wanted to create a list of enhancements to be looked at sometime and somewhere, that would be fine but, at least IMO, we should try to keep things off the ticket list unless they are in scope and the WG actually expects to address them. john From nobody Tue Oct 20 08:33:53 2020 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 7AC3D3A110D for ; Tue, 20 Oct 2020 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVTr2dpz6Eif for ; Tue, 20 Oct 2020 08:33:49 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E615E3A12E6 for ; Tue, 20 Oct 2020 08:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603207979; bh=NU595ANXLpattFsv0RJ4ZpynkI8JfSDIxDl6cmaxeuQ=; l=463; h=To:References:From:Date:In-Reply-To; b=BkZAoXpIBwU5grnoc/eCOTmrmgDYMtBM8Yerb7uGBkDsR/HqzoMdxHwkWXkBACVPA tIhndO34jD8WbTOKsfV+2P7E95wBFcYuS/8VWq9lqYQEgGrtwYeuZLYkIsBV7cA8TZ p7DSiLku0qHKnXtAfcFbd+Uio2aJmd3xVrTaqjQykzoZWpV1u+upVjXJJqG3f Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005F8F032A.00004EA5; Tue, 20 Oct 2020 17:32:58 +0200 To: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> <0420A924A26F37B24F6E1FED@PSB> From: Alessandro Vesely Message-ID: Date: Tue, 20 Oct 2020 17:32:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <0420A924A26F37B24F6E1FED@PSB> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 15:33:52 -0000 On Tue 20/Oct/2020 17:10:25 +0200 John C Klensin wrote: > --On Tuesday, October 20, 2020 10:45 +0100 Jeremy Harris wrote: > >> [this doesn't change anything regarding EHLO, which I don't thiks we have >> a real problem with] > > I agree about "we" but I don't know if Alessandro is on board yet. Yes, I am. Issuing EHLO in the middle of a transaction has no sense, but the protocol can continue to tolerate it for historical reasons. Best Ale -- From nobody Tue Oct 20 08:54:58 2020 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 2F3433A1130 for ; Tue, 20 Oct 2020 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=pjk+xasx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ogUw3/5R 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 fw-qrMz1s3ls for ; Tue, 20 Oct 2020 08:54:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E8E3A112B for ; Tue, 20 Oct 2020 08:54:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BA6485C00C6; Tue, 20 Oct 2020 11:54:54 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 20 Oct 2020 11:54:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=QDho/e/3KKS8E4Tm4qFdvIosuQBSeuG 6CuM54XQcwKc=; b=pjk+xasxzcHyklen0qxijBUoZawaYRPl2BK5LrDxngxBje0 J61D3NefvBCBE/IyvjMFTxRE1cAeVlXKoeEPcFfXWdx/i0QBTEEkDWVYgOYMaWCE LyXsjWt12cKDF4UXvSi2vkUv1UV/SA3tDimFyPWpl83RS5GPc7BPCpV+Y6r28yFP PivSBd4M2yHIqhlZfw+iXd8wwqlIP/T374uCABaXNldeqfxU1EUPt2Gg9864M6bW 8Jz5k04nKwBfeeRjaFVrSA+8J2EXQCGJysiacMwKa9r11DfBdrY959dddYFfM6I3 FEw5EYXCXJ7mKET34l3kmZYPfts6azYggrWWFgQ== 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=QDho/e /3KKS8E4Tm4qFdvIosuQBSeuG6CuM54XQcwKc=; b=ogUw3/5RxpRlpgBpMlXKlq mssli69xcMyYByhExY21TB7Gmi2EQnN0hwl8mvks3Ar7DFQVWK9w5MEqA/LXlgH9 ztcRWU6cMgGl39acwRbt83qmmRHFCiKj1k8/yFPqDRy4l3RsQgz4NM6wMoqtoLdF 5XU/fQ+xxw/DykWZCBB/7Z0gJpad90DYxGlHmZ8UJBdLAWPlb91zzI9gr1PTRp1j Jz+Dx2F4DR97yKUB8R5/uRngmUF9gZKQMkg2yMyGl1i2hXI+RBWcmPiyKc0TXqfh w3ninlCiX3r67x624J7pfUEl25cDnvkH2P601uBMgJ6zHGJMBJzMoG5utVW+3frw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeefgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeelffdtgffhveeuudeihfffjeelgfdtudfhvdettdeh feettdfhgefhfeeigfegffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhv sehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B5F36660069; Tue, 20 Oct 2020 11:54:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888 Mime-Version: 1.0 Message-Id: In-Reply-To: <01RR0SLJ91SS005PTU@mauve.mrochek.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 16:54:34 +0100 From: "Alexey Melnikov" To: "Ned Freed" Cc: "Alessandro Vesely" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 15:54:57 -0000 Hi Ned, On Tue, Oct 20, 2020, at 2:07 PM, Ned Freed wrote: > > Hi Alessandro, > > > On Tue, Oct 20, 2020, at 9:19 AM, Alessandro Vesely wrote: > > > On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote: > > > >> There could also be security reasons for not clearing the > > > >> client machine domain name. > > > >> [...] > > > > Thinking about that gives me a headache, especially since the > > > > server would still have one of the few pieces of data it can > > > > really trust --the IP address from which the TCP connection was > > > > initiated-- and it is, after all, the same connection. > > > > > > > > > How would that work with multipath TCP? MPTCP "aims to be transparent to both > > > higher and lower layers". However, can't a second HELO lead to realize that > > > the IP address changed? > > > A couple of thoughts on this: > > > 1) Multipath TCP wasn't defined when RFC 5321 was published. One can argue > > that use of multipath TCP with SMTP is an extension. So I think this needs a > > new "enhancement" ticket. > > The history is irrelevant. Given that IP address reputation is a key component > of many filtering mechanisms, including but definitely not limited to simple > DNS checks of consistency of the the EHLO host and IP address, any use of > multipath TCP is going to require substantial specification effort going far > beyond this work. This is where I was heading anyway. > > 2) use of IP addresses (and change of IP addresses) interacts with ticket #1: > > . So let's discuss change of IP > > address when we discuss that ticket. > > Let's not and say we didn't. This is another can of worms we should not open. We will need to discuss ticket #1 at some point, but I am happy not to make the can of worms bigger when we do! > > 3) An issue inspired by your comment (but really a separate one) is: can an > > SMTP client change hostname in subsequent EHLOs. I think based on this thread > > the answer is "yes", but this probably needs to be clarified in the document. > > (If the WG decides while discussing ticket #1 that IP addresses in EHLO are > > fine, that would be another case of the same issue.) > > Of course it can. One of the reasons for issuing a second EHLO is to get a set > of values you can trust after a security layer has been added. This applies in > both directions. As such, the server should always replace the client name with > the new one, just as the client should update its option list. > > I suppose it's also possible that the client doesn't want to reveal its true > sooper-secret name until after the security layer in place. Even so, I think it > would be a good idea to say that the client SHOULD NOT change the name it puts > in subsequent EHLOs. Right. Another possible case that came to mind was a case of multi-tenant MTA that wants to switch domains when relaying messages from different domain. (I am not saying that this is a good idea, I was just trying to think of possible use cases for EHLO with different domain names) But anyway, as a participant I am happy with "SHOULD NOT" for changing of EHLO parameters. Best Regards, Alexey From nobody Tue Oct 20 09:03:30 2020 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 989303A0656 for ; Tue, 20 Oct 2020 09:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=JdnV4nAj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VJ1BInqG 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 Qfx-l77oktW3 for ; Tue, 20 Oct 2020 09:03:28 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C2F3A0489 for ; Tue, 20 Oct 2020 09:03:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8DD985C016A; Tue, 20 Oct 2020 12:03:27 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 20 Oct 2020 12:03:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=3TwO+vpwT4vRCElwjn9FMUxovkT7S85 +tfM/Cm02hOI=; b=JdnV4nAjSo7T9O4YmSqJR+bBjJ5uj3UbcyG2C6i+EnwUv7S 0FAl6KbKgN5A9489baM/AEH6uNkU3sGeUvt6V8IMwvvAsR/nVT1ZZPVdmVHtao4M eCItxE2ujVr4psIe3ma0DwMLP2f6uOzFFivnBDAOYwd1J4AOKs06kVcsS5gg0cgZ YHiEq6XTKVr5byFHq6y9DVF/eNE1q806Dvjh4vPmAQ32aljRYEsYl/3d4aqK0Ycz V3FiHsyGJGz48MJDCcfmRtlV3FF4kRmxhXnQOCHfNuRcKYKsK59MJI4FP7FNJ8zs WozL/cQQGvdLZKRlfHjLzNSS+Ri3McRtEJc0Cgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3TwO+v pwT4vRCElwjn9FMUxovkT7S85+tfM/Cm02hOI=; b=VJ1BInqGI6D8P7Vl7BN5Fq TKvRnwOcOSCU7GpQ77y0sG4phAwkQlahuUQk+f4X6RTvIxgaq2p+vTWkIQPkziHt jCVEcEzhMWuYPlahdqkf/vIssbtQl5jq+nXR4sMtTp7pli+xDtiwVc09IkOE5dEU mSt7nAco5SB4u8bRE89IGWWHxL+WdhGUK1UM0q0H03CY4/LLP2MkILPDSDDtoMGs KK693jAPKHofHT/O9kVbEFnq+tMDQ1PLY2TB9Fhaw+DJEksbOL8DR4rSs7Nc+cYM 5ZT8iK2q+IqQZsUff1ayvviK2pEynaZSHq7mgEXjfwIxReHeNxNmQTVS4oLzwuKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeefgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfekiefg udfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6B990660069; Tue, 20 Oct 2020 12:03:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> Date: Tue, 20 Oct 2020 17:03:05 +0100 From: "Alexey Melnikov" To: "John C Klensin" , "Alessandro Vesely" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 16:03:30 -0000 Hi John, On Tue, Oct 20, 2020, at 4:32 PM, John C Klensin wrote: > > --On Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov > wrote: > > >> How would that work with multipath TCP? MPTCP "aims to be > >> transparent to both higher and lower layers". However, > >> can't a second HELO lead to realize that the IP address > >> changed? > > > > A couple of thoughts on this: > > > > 1) Multipath TCP wasn't defined when RFC 5321 was published. > > One can argue that use of multipath TCP with SMTP is an > > extension. So I think this needs a new "enhancement" ticket. > > It is just a guess (I haven't thought about it enough), but my > guess is that, once we started sorting out the details, we would > decide that any situation in which SMTP is run over anything but > "raw"/ direct TCP would require an option/ extension in the > sense of a new option advertised by the EHLO response and > negotiated as needed with the client. (AUTH and STARTTLS are > just such extensions so this raises no problem with the model.) > Without that advertisement and negotiation, one would predict > situations in which the expectations and capabilities of client > and server would be different... a recipe for interoperability > problems. > > If that reasoning is correct, then the "enhancement" would be a > new SMTP option, set of them, and/or a document describing how > to specify options for "different transport" or "intermediate > level" situations. Yes. Or just a new document describing SMTP over multipath TCP (a new transport mapping). >That is, at least IMO, so far out of scope > for the WG as now chartered Yes. > that a ticket would be > inappropriate. If one wanted to create a list of enhancements > to be looked at sometime and somewhere, that would be fine but, > at least IMO, we should try to keep things off the ticket list > unless they are in scope and the WG actually expects to address > them. I was using the word "ticket" to record pretty much anything that might be worth doing/discussing in the future, whether or not under current EMAILCORE charter or future incarnations. In my mind creating a ticket doesn't mean that any change needs to be done or that it is even within the Charter. It is just a convenient way of recording discussions that came up. Let me ponder a bit more what is the best way to record this sort of thing. Best Regards, Alexey From nobody Tue Oct 20 09:41:21 2020 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 D943C3A0BF1 for ; Tue, 20 Oct 2020 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xneSm8Czl1Zp for ; Tue, 20 Oct 2020 09:41:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E9B3A0B97 for ; Tue, 20 Oct 2020 09:41:17 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR0Z7MIHOG00799T@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 09:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603211773; bh=f8exINLUdGXKZ06F59BWwqkwu6MIdkV0g3cXMA/YYqc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=LtLXFIkagcJY776qhk3kyvlrasBG81Yq7L7lgyajvpQe/d97l67EnyY+oZNcQiYgh /nQ+V4OtwwDzE0AtHUGO8rTHmL1OWluEa7D5g+WU+bSflsc/UDm2m6vODuQsjn+x65 NX/QmHIx9vjlaAHXb5XjUPTts94MwS+jEd/jrzI4= 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 <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 09:36:11 -0700 (PDT) Cc: Jeremy Harris , emailcore@ietf.org Message-id: <01RR0Z7KG4Z4005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 09:28:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 11:10:25 -0400" <0420A924A26F37B24F6E1FED@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <977da2e9-7de9-37d6-5e79-c660c023f6a2@wizmail.org> <0420A924A26F37B24F6E1FED@PSB> To: John C Klensin Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 16:41:19 -0000 > --On Tuesday, October 20, 2020 10:45 +0100 Jeremy Harris > wrote: > > On 20/10/2020 06:02, John C Klensin wrote: > >> The commend order is codified now. We don't allow a second > >> MAIL command once a mail transaction has happened because it > >> makes no sense > > > > Nit: I think we do. > > > > RFC 5321, 4.1.4 :- > > > > "The MAIL command ... begins a mail transaction." > > "transaction consists of [...] and a > > DATA command, in that order." > > "There may be zero or more > > transactions in a session. MAIL [...] > > should be sent > > only if [...] or if > > the previous one successfully concluded with a successful DATA" > > > > > > Perhaps you meant "started" rather than "happened"? > Yes, I should have said "started". But nothing in the above > convinces me that, e.g., > MAIL ... > RCPT ... > MAIL ... > is valid without something that closes out the mail transaction. Nothing in the MAIL command description says it resets state. In fact it states quite clearly that the above sequence is bogus: In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4. I also note that 503 command out of sequence is listed as a return code for MAIL. > I keep being tempted to say "RSET or DATA...CRLF.CRLF" but, > given that we already have extensions that enable other commands > (e.g., BDAT) that can close the mail transaction when they are > finished, that doesn't work. > > [this doesn't change anything regarding EHLO, which I don't > > thiks we have a real problem with] > I agree about "we" but I don't know if Alessandro is on board > yet. The semantics here are clear, and I've yet to see any justification for changing them. Ned From nobody Tue Oct 20 11:29:26 2020 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 5A7403A128F for ; Tue, 20 Oct 2020 11:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 bC_uhNDqDvaJ for ; Tue, 20 Oct 2020 11:29:23 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 3272D3A0EC4 for ; Tue, 20 Oct 2020 11:29:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR12ZMLKI8006150@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 11:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603218258; bh=Pl2Mj+w0FRebv3XUjhI5BoY/zt+1YmDnBqTopok0cC0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=PaZXEgrCUFXvRRMjrC9dWTD0YbfKXiYvAkIMjlA78FJGrNeIMdkrDYFHqb2Kix7Qa R77F5b7lQrV5vv4eS46sqmhQDegVgTbh1RBIZP1yd/MJ1wHDHq52Zd3gfUOjppoQFj zjBL/XI5jOKSuDL0sc3J6XxmuyCdbIaZFSuZxAD0= 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 <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 11:24:15 -0700 (PDT) Cc: Ned Freed , Alexey Melnikov , emailcore@ietf.org, Alessandro Vesely Message-id: <01RR12ZJJORM005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 11:22:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 11:04:02 -0400" <7B4FD11144F62A9ABA3BE458@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <7B4FD11144F62A9ABA3BE458@PSB> To: John C Klensin Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 18:29:24 -0000 > --On Tuesday, October 20, 2020 06:07 -0700 Ned Freed > wrote: > >... > >> 3) An issue inspired by your comment (but really a separate > >> one) is: can an SMTP client change hostname in subsequent > >> EHLOs. I think based on this thread the answer is "yes", but > >> this probably needs to be clarified in the document. (If the > >> WG decides while discussing ticket #1 that IP addresses in > >> EHLO are fine, that would be another case of the same issue.) > > > > Of course it can. One of the reasons for issuing a second EHLO > > is to get a set of values you can trust after a security layer > > has been added. This applies in both directions. As such, the > > server should always replace the client name with the new one, > > just as the client should update its option list. > > > > I suppose it's also possible that the client doesn't want to > > reveal its true sooper-secret name until after the security > > layer in place. Even so, I think it would be a good idea to > > say that the client SHOULD NOT change the name it puts in > > subsequent EHLOs. > And that is connected to the (IMO obscure) case I mentioned in > passing in my prior note. I don't think clients changing those > names is going to be a good idea in the overwhelming number of > cases. I could easily go with a SHOULD NOT if Ned and others > think it is a good idea, but preferably only if we are willing > to insert at least one example of a situation in which an > exception would be appropriate. Otherwise it might be better to > say nothing other than that the EHLO MAY be reissued if the > client thinks it is important or specific extensions require it > and to specify that doing so clears and replaces all EHHO > information offered by the client and provided by the server. The only noncontrived example I can think of is the nonstandard XCLIENT extension. We *really* don't want to go there. Ned From nobody Tue Oct 20 11:29:48 2020 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 90B4E3A128F for ; Tue, 20 Oct 2020 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkyD_lMGrLXH for ; Tue, 20 Oct 2020 11:29:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DB03A0EC4 for ; Tue, 20 Oct 2020 11:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603218583; bh=QpM0KJlGV8vDaVU7RHm1dwWxFb3FXchwBIArW2xoybQ=; l=877; h=To:Cc:References:From:Date:In-Reply-To; b=CVJ+9VUUhYd1DFzTR19t4tPyxX4pOzVVWf3Q+zRzb7T2kAx4kyFsLszQZ85sjgFli Su6GMVUwITJp6MH5ut8a+M3Z1mjarAEHqpaO1u7n/JCSwhqoru7CV8n4ZlM3JiWbjX ODV407/hQ4eNpq8AXdK0J2gMLIjHfAeQv5mkcCsgBc/QrM+KvZXI4z1MzROFp Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC0CC.000000005F8F2C97.00006188; Tue, 20 Oct 2020 20:29:43 +0200 To: Alexey Melnikov , Ned Freed Cc: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Tue, 20 Oct 2020 20:29:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 18:29:47 -0000 On Tue 20/Oct/2020 17:54:34 +0200 Alexey Melnikov wrote: >> I suppose it's also possible that the client doesn't want to reveal its true >> sooper-secret name until after the security layer in place. Even so, I think it >> would be a good idea to say that the client SHOULD NOT change the name it puts >> in subsequent EHLOs. > Right. > > Another possible case that came to mind was a case of multi-tenant MTA that wants to switch domains when relaying messages from different domain. (I am not saying that this is a good idea, I was just trying to think of possible use cases for EHLO with different domain names) > > But anyway, as a participant I am happy with "SHOULD NOT" for changing of EHLO parameters. With two acceptably valid use cases, adding a SHOULD NOT looks like an unjustified change to the spec. Does it accomplish anything? Best Ale -- From nobody Tue Oct 20 12:16:39 2020 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 1E7093A139A for ; Tue, 20 Oct 2020 12:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRycyXYqsqbd for ; Tue, 20 Oct 2020 12:16:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3318C3A13C6 for ; Tue, 20 Oct 2020 12:16:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR14MZ5HUO002N0Y@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 12:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603221082; bh=YKAp2/e/M+SVU7gIYl/F8mWiPMX77rzPrRzl2pZ58TU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ICthjYWjylFM6ASvZuaAKz+5ydUWTSr1ccRIxwPiNz2MAr/p2TKgsolQaMhGI44Mt TOipdtPgaXgMWGBRGVs7ieOgFTcUlWFm6JgNN3LfOXEraBLeQeuWjnmyYjmI7Ysl2m 0PfcPbXuUvxuNHbdDWU9xQYSwzxWT0UZO9JGHGlo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 12:11:18 -0700 (PDT) Cc: Alexey Melnikov , Ned Freed , emailcore@ietf.org Message-id: <01RR14MW2FQS005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 12:04:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 20:29:43 +0200" References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 19:16:38 -0000 > On Tue 20/Oct/2020 17:54:34 +0200 Alexey Melnikov wrote: > >> I suppose it's also possible that the client doesn't want to reveal its true > >> sooper-secret name until after the security layer in place. Even so, I think it > >> would be a good idea to say that the client SHOULD NOT change the name it puts > >> in subsequent EHLOs. > > Right. > > > > Another possible case that came to mind was a case of multi-tenant MTA that > > wants to switch domains when relaying messages from different domain. (I am not > > saying that this is a good idea, I was just trying to think of possible use > > cases for EHLO with different domain names) > > But anyway, as a participant I am happy with "SHOULD NOT" for changing of > > EHLO parameters. > With two acceptably valid use cases, adding a SHOULD NOT looks like an > unjustified change to the spec. I've yet to see an acceptable use case stated that doesn't involve extending SMTP semantics in other ways. My sooper-secret example was intedned to be, and was, nonsense. And the multi-tenant case only works if the client knows that (1) The EHLO parameter is somehow associated with tenancy and (2) Issuing an EHLO with no other state change will do something. THe specification guarantees hetierh. > Does it accomplish anything? It most certainly does: It prevents us from having exactly this protracted discussion of this bit of protocol minutiae in the future. Ned From nobody Tue Oct 20 12:24:45 2020 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 E990E3A1330 for ; Tue, 20 Oct 2020 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZBPdIeLVrd0 for ; Tue, 20 Oct 2020 12:24:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC69D3A132D for ; Tue, 20 Oct 2020 12:24:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR14X7XLJ4007ZQF@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 12:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603221578; bh=5Sk80RSPdMs3pjICNWIgfR5pzLEmh67/GAQbC1iWvDo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=kYFwwUpjRd3mB25E4k3GsHssaTXqPnncevtw9CfU/Mh9SoAX/A7fRx7GG5R3nklVr 3/jZE3u7dC/48njC/AGO26FBEUBb8Hpm6fkf3tJBe/TWuFooxgyL4z9nbI1oHodpQp Ftk6J40uKuKL8ld5oKtfy7+sRFCFavW/MDIqtlOo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 12:19:35 -0700 (PDT) Cc: Alessandro Vesely , emailcore@ietf.org, Ned Freed , Alexey Melnikov Message-id: <01RR14X5DPSS005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 12:19:07 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 12:04:46 -0700 (PDT)" <01RR14MW2FQS005PTU@mauve.mrochek.com> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> To: Ned Freed Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 19:24:43 -0000 > > On Tue 20/Oct/2020 17:54:34 +0200 Alexey Melnikov wrote: > > >> I suppose it's also possible that the client doesn't want to reveal its true > > >> sooper-secret name until after the security layer in place. Even so, I think it > > >> would be a good idea to say that the client SHOULD NOT change the name it puts > > >> in subsequent EHLOs. > > > Right. > > > > > > Another possible case that came to mind was a case of multi-tenant MTA that > > > wants to switch domains when relaying messages from different domain. (I am not > > > saying that this is a good idea, I was just trying to think of possible use > > > cases for EHLO with different domain names) > > > But anyway, as a participant I am happy with "SHOULD NOT" for changing of > > > EHLO parameters. > > With two acceptably valid use cases, adding a SHOULD NOT looks like an > > unjustified change to the spec. > I've yet to see an acceptable use case stated that doesn't involve extending > SMTP semantics in other ways. My sooper-secret example was intedned to be, and > was, nonsense. And the multi-tenant case only works if the client knows that > (1) The EHLO parameter is somehow associated with tenancy and (2) Issuing an > EHLO with no other state change will do something. THe specification guarantees > hetierh. That should have been "neither". Ned > > Does it accomplish anything? > It most certainly does: It prevents us from having exactly this protracted > discussion of this bit of protocol minutiae in the future. > Ned > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Tue Oct 20 13:05:44 2020 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 875E23A137B for ; Tue, 20 Oct 2020 13:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MoGLBqdZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=QSAB7c3U 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 BaH4blyoebqM for ; Tue, 20 Oct 2020 13:05:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFC83A18B6 for ; Tue, 20 Oct 2020 13:03:51 -0700 (PDT) Received: (qmail 49630 invoked from network); 20 Oct 2020 20:03: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; s=c1db.5f8f42a5.k2010; bh=XE0rHC52cRBkrVIY+DweizTdiXr066x6taupWxSASjQ=; b=MoGLBqdZcAi7AzqgfsEBGGEZp9e70km4NF5Ihf0TUGf2EIUhAVKUBEQEcmqekq8GXucHb3VaJCZL3k1UOz2AaaNhR3kwKEcLlCAot25LluhF2n613xXqZIW16gcq1cJkJgRB3qB1S52yeruP46vcMxchG+jafj3ZhSpE1AH2AI++UZVj9vvbQeGc+V4d7cqfXpmoSBdFM1Ix4IOi6BxcAE8qdZPZaFxCG7b/CwpBPO7Z8qGeaGzQLYYKqU5A46NNUJak9fdMMZmqWtgcTGyvoJI3azpA4k150x6T/ujFMGAr8EHMYOq3craIi1stfZfuFLk1Axpo5L+E5jMNan+wgQ== 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; s=c1db.5f8f42a5.k2010; bh=XE0rHC52cRBkrVIY+DweizTdiXr066x6taupWxSASjQ=; b=QSAB7c3UpwoBjtBsp6VTsrffiVQ+NkFhUuQmLVe+yAGPgQ+8s7S3Y2iRAckYDUlRxr+1jQjTj1HLRfVzavDApDUWxkSGKXZv6RZP9ClgmMgvaIatjqmVkQNdSjNRndq/l3gr6hnzF0uvJItEWfP6Qi2ny2wnpgcJdYF9XuO6klKbob+KjeEdNBt/AycMZD/3atTkrtuk4BroOtM5yas2E4C5d5nYIISEy+ZTbVaY510r3/GVllRjPS0Fk8jQIjOdWTsk1OMM6vJ5cRNcneKqxKFK0uEbciu3EAg5AnlTkPiGNVhUcbbApdoJnrmn+xnD6uzEi/7V0+v+6TDx6qQMXw== 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; 20 Oct 2020 20:03:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 2244D23B7BA8; Tue, 20 Oct 2020 16:03:48 -0400 (EDT) Date: 20 Oct 2020 16:03:48 -0400 Message-Id: <20201020200349.2244D23B7BA8@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: aamelnikov@fastmail.fm In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Tue, 20 Oct 2020 20:05:43 -0000 In article you write: >Another possible case that came to mind was a case of multi-tenant MTA that wants to switch domains when relaying >messages from different domain. (I am not saying that this is a good idea, I was just trying to think of possible >use cases for EHLO with different domain names) While this is hypothetically possible, has anyone ever seen this? Given the usual spam filtering rules, the MTA would need matching forward and reverse DNS for every name it uses. Big bunches of PTR records famously do not work well. I think we can safely not worry about it. From nobody Tue Oct 20 19:04:32 2020 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 E1F853A09D1 for ; Tue, 20 Oct 2020 19:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 93vWKrQ-oY03 for ; Tue, 20 Oct 2020 19:04:26 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 BD7CB3A08E3 for ; Tue, 20 Oct 2020 19:04:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR1IVUKUF4008013@mauve.mrochek.com> for emailcore@ietf.org; Tue, 20 Oct 2020 18:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603245563; bh=7AXsZoxoSUDBleHEIemgSlvSXoKwYqcurjMdr4qfpsI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=L5e0nX+t9AwTot6BHLaj641XQ+V5zMC4Smx4aC2eXXPCoq5zbN42ENWzPD+A7avs6 YO1Y9Z7zbtGpy7UUYbfdVTOfvGksj1fBYLqD3EUhgHOYRZbjBreaqirawBZBbsUP6s x5UYfR1dYpn45Y2AZwNjK4eNi7zQLg+q17bLAQ2U= 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 <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Tue, 20 Oct 2020 18:59:21 -0700 (PDT) Cc: emailcore@ietf.org, aamelnikov@fastmail.fm Message-id: <01RR1IVS1VNI005PTU@mauve.mrochek.com> Date: Tue, 20 Oct 2020 18:50:15 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Oct 2020 16:03:48 -0400" <20201020200349.2244D23B7BA8@ary.qy> References: <20201020200349.2244D23B7BA8@ary.qy> To: John Levine Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 02:04:31 -0000 > In article you write: > >Another possible case that came to mind was a case of multi-tenant MTA that wants to switch domains when relaying > >messages from different domain. (I am not saying that this is a good idea, I was just trying to think of possible > >use cases for EHLO with different domain names) > While this is hypothetically possible, has anyone ever seen this? No. Of course there are tons of multi-tenant MTAs out there - even my tiny little home system services multiple domains - but for tenant-specific EHLO to be useful there would have to be a strong connection between the EHLO name and the domain being served. Which AFAIK there isn't. That said, as I point out before, there is a use-case for multiplexing proxies. But this doesn't without also using XCLIENT or some similar extension. > Given the usual spam filtering rules, the MTA would need matching > forward and reverse DNS for every name it uses. Big bunches of PTR > records famously do not work well. I think we can safely not worry > about it. Which is why it only makes sense in a multiplexing context, where you also have a mechansism for resetting the IP information the server sees. Ned From nobody Wed Oct 21 00:13:13 2020 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 0DCA03A119D for ; Wed, 21 Oct 2020 00:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDGQhukeggIw for ; Wed, 21 Oct 2020 00:13:10 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB5D3A113C for ; Wed, 21 Oct 2020 00:13:10 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kV8J0-0007bh-Vn; Wed, 21 Oct 2020 03:13:06 -0400 Date: Wed, 21 Oct 2020 03:13:00 -0400 From: John C Klensin To: Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org Message-ID: <7B76DDDD7606B27CA830E9E9@PSB> In-Reply-To: References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@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-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 07:13:12 -0000 --On Tuesday, October 20, 2020 17:03 +0100 Alexey Melnikov wrote: > Hi John, > > On Tue, Oct 20, 2020, at 4:32 PM, John C Klensin wrote: >> >> --On Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov >> wrote: >> >> >> How would that work with multipath TCP? MPTCP "aims to be >> >> transparent to both higher and lower layers". However, >> >> can't a second HELO lead to realize that the IP address >> >> changed? >> > >> > A couple of thoughts on this: >> > >> > 1) Multipath TCP wasn't defined when RFC 5321 was published. >> > One can argue that use of multipath TCP with SMTP is an >> > extension. So I think this needs a new "enhancement" ticket. >> >> It is just a guess (I haven't thought about it enough), but my >> guess is that, once we started sorting out the details, we >> would decide that any situation in which SMTP is run over >> anything but "raw"/ direct TCP would require an option/ >> extension in the sense of a new option advertised by the EHLO >> response and negotiated as needed with the client. (AUTH and >> STARTTLS are just such extensions so this raises no problem >> with the model.) Without that advertisement and negotiation, >> one would predict situations in which the expectations and >> capabilities of client and server would be different... a >> recipe for interoperability problems. >> >> If that reasoning is correct, then the "enhancement" would be >> a new SMTP option, set of them, and/or a document describing >> how to specify options for "different transport" or >> "intermediate level" situations. > > Yes. Or just a new document describing SMTP over multipath TCP > (a new transport mapping). I suggest that either that gets done by an extension option or it isn't SMTP but, perhaps MPMTP. Even with an Internet Standard as the base, a new document that says "this is just like that other thing except where it isn't" is an invitation to both interoperability problems and a real mess if the base document is updated. >... > I was using the word "ticket" to record pretty much anything > that might be worth doing/discussing in the future, whether or > not under current EMAILCORE charter or future incarnations. In > my mind creating a ticket doesn't mean that any change needs > to be done or that it is even within the Charter. It is just a > convenient way of recording discussions that came up. ok. I'm just trying to keep things as narrowly focused as possible (as agreed) and to try to be certain that it is easy to say whether we are addressed all issues and are therefore done. > Let me ponder a bit more what is the best way to record this > sort of thing. Good luck... and thanks. john From nobody Wed Oct 21 02:43:01 2020 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 413F33A1544 for ; Wed, 21 Oct 2020 02:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHpZVeIP5N7u for ; Wed, 21 Oct 2020 02:42:59 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D877B3A1543 for ; Wed, 21 Oct 2020 02:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603273377; bh=27046A8rKt/kZ40da5B0UwcbP5yofOc2tQTHCBLWRJw=; l=3226; h=To:References:From:Date:In-Reply-To; b=BreN/UbOuTlGQKg+mesi2rNo3iVUaxnbY15GxXZ9iq9fl/O3azAMI/xUMDzI4YtNO 7y4Jxa0GK4xPYK9ooOB08eUr/ijV07ze5I0DbYHGuAs6RijBdITacyVb8byhREsoIX GxZK79+hiUi2BH/LykweYrYsftt5fVjEIrdBUke+Dn6B4n/MDq17SjmfF7leH Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC053.000000005F9002A0.00007C26; Wed, 21 Oct 2020 11:42:56 +0200 To: John C Klensin , Alexey Melnikov , emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> From: Alessandro Vesely Message-ID: Date: Wed, 21 Oct 2020 11:42:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <7B76DDDD7606B27CA830E9E9@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 09:43:00 -0000 On Wed 21/Oct/2020 09:13:00 +0200 John C Klensin wrote: > --On Tuesday, October 20, 2020 17:03 +0100 Alexey Melnikov wrote: >> On Tue, Oct 20, 2020, at 4:32 PM, John C Klensin wrote: >>> --On Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov wrote: >>> >>>>> How would that work with multipath TCP? >>>> >>>> A couple of thoughts on this: >>>> >>>> 1) Multipath TCP wasn't defined when RFC 5321 was published. One can >>>> argue that use of multipath TCP with SMTP is an extension. So I think >>>> this needs a new "enhancement" ticket. >>> >>> It is just a guess (I haven't thought about it enough), but my guess is >>> that, once we started sorting out the details, we would decide that any >>> situation in which SMTP is run over anything but "raw"/ direct TCP would >>> require an option/ extension in the sense of a new option advertised by >>> the EHLO response and negotiated as needed with the client. (AUTH and >>> STARTTLS are just such extensions so this raises no problem with the >>> model.) Why does it have to be an SMTP extension? Any A/S could do. >>> Without that advertisement and negotiation, one would predict situations >>> in which the expectations and capabilities of client and server would be >>> different... a recipe for interoperability problems. >>> >>> If that reasoning is correct, then the "enhancement" would be a new SMTP >>> option, set of them, and/or a document describing how to specify >>> options for "different transport" or "intermediate level" situations. >> >> Yes. Or just a new document describing SMTP over multipath TCP (a new >> transport mapping). > > I suggest that either that gets done by an extension option or it isn't SMTP > but, perhaps MPMTP. Even with an Internet Standard as the base, a new > document that says "this is just like that other thing except where it > isn't" is an invitation to both interoperability problems and a real mess if > the base document is updated. The current I-D says: SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 [3] describe some of them. I think it is time to remove that reference to RFC 821. IMHO, the document could discuss transport over "TCP-like" connections. That term would mean that a replacement transport must provide for equivalent functions (open, close or shut down, and accept) and credentials (IP address). A well hammered wording can say that the document uses the TCP metaphor to specify operations, while leaving to apposite A/S'es or Extensions to specify the equivalent details for each relevant TCP-like transport in turn.[*] That keeps the spec as is without limiting it to TCP. I don't think it's necessary to add an Appendix which lists existing SMTP extensions (or A/S) for existing alternative transports —as RFC 821 did. jm2c Ale -- [*] Indeed, specifying any protocol in abstract terms would result in an incomprehensible meta-specification. Using a specific transport as a metaphor is both practical and theoretically-consistent. From nobody Wed Oct 21 02:58:57 2020 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 4E7303A1590 for ; Wed, 21 Oct 2020 02:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV0ERX0mTMjF for ; Wed, 21 Oct 2020 02:58:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DD73A158C for ; Wed, 21 Oct 2020 02:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603274333; bh=wlL2C0m3wIdH8jk48Wah+4UjY7aQB5evC4mdntoz/QM=; l=2032; h=To:Cc:References:From:Date:In-Reply-To; b=Cq8m4aF5TIxCxCQaE13A1POFpJrcXypEsg7Wk86Knz3heNJMBdf3w738olFsv8IB6 k3PuVSlLy1A6uYe7ZINhpCdKqo/QnWNckGjXWtmX7LGet1Tvq0dOd2fWCbzZefPkTZ TeB4awOJ5pdVzYh7NXTpXpJyIcT998mNffkZyNFybF3CEKBw+P3u7IpmNWqev Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC053.000000005F90065D.00007EEE; Wed, 21 Oct 2020 11:58:53 +0200 To: Ned Freed Cc: emailcore@ietf.org, Alexey Melnikov References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> Date: Wed, 21 Oct 2020 11:58:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <01RR14MW2FQS005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 09:58:56 -0000 On Tue 20/Oct/2020 21:04:46 +0200 Ned Freed wrote: >> On Tue 20/Oct/2020 17:54:34 +0200 Alexey Melnikov wrote: >>>> I suppose it's also possible that the client doesn't want to reveal >>>> its true sooper-secret name until after the security layer in place. >>>> Even so, I think it would be a good idea to say that the client >>>> SHOULD NOT change the name it puts in subsequent EHLOs. >>> Right. >>> > >>> Another possible case that came to mind was a case of multi-tenant MTA >>> that wants to switch domains when relaying messages from different >>> domain. (I am not saying that this is a good idea, I was just trying to >>> think of possible use cases for EHLO with different domain names) > >>> But anyway, as a participant I am happy with "SHOULD NOT" for changing of >>> EHLO parameters. > >> With two acceptably valid use cases, adding a SHOULD NOT looks like an >> unjustified change to the spec. > > I've yet to see an acceptable use case stated that doesn't involve extending > SMTP semantics in other ways. My sooper-secret example was intedned to be, and > was, nonsense. And the multi-tenant case only works if the client knows that > (1) The EHLO parameter is somehow associated with tenancy and (2) Issuing an > EHLO with no other state change will do something. The specification guarantees > neither. For multi-tenant, sending an NDN from a domain featuring spf-all requires a valid HELO name. SPF adds some semantics, but it's still SMTP. >> Does it accomplish anything? > > It most certainly does: It prevents us from having exactly this protracted > discussion of this bit of protocol minutiae in the future. The minimum discussion is attained by leaving it as is. If we change it, we'll have to discuss how to word it. Issuing EHLO to change name before a transaction makes a lot more sense than issuing EHLO instead of RSET to abort a transaction. Yet, we leave the latter as is exactly to avoid protocol changes and related discussions. Best Ale -- From nobody Wed Oct 21 10:46:54 2020 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 69D0C3A13E0 for ; Wed, 21 Oct 2020 10:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irviEJsCHUca for ; Wed, 21 Oct 2020 10:46:51 -0700 (PDT) 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 C1DD43A13CD for ; Wed, 21 Oct 2020 10:46:50 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kVICE-0008UH-Qf; Wed, 21 Oct 2020 13:46:46 -0400 Date: Wed, 21 Oct 2020 13:46:40 -0400 From: John C Klensin To: Alessandro Vesely , Alexey Melnikov , emailcore@ietf.org Message-ID: <47EF54E0B8D9A53E24071951@PSB> In-Reply-To: References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 17:46:52 -0000 --On Wednesday, October 21, 2020 11:42 +0200 Alessandro Vesely wrote: > On Wed 21/Oct/2020 09:13:00 +0200 John C Klensin wrote: >... >>>> It is just a guess (I haven't thought about it enough), but >>>> my guess is that, once we started sorting out the details, >>>> we would decide that any situation in which SMTP is run >>>> over anything but "raw"/ direct TCP would require an >>>> option/ extension in the sense of a new option advertised = by >>>> the EHLO response and negotiated as needed with the client. >>>> (AUTH and STARTTLS are just such extensions so this raises >>>> no problem with the model.) >=20 > Why does it have to be an SMTP extension? Any A/S could do. There is a difficulty with SMTP, which is that it is a nearly 40 year old protocol (and therefore probably older than many IETF participants) that is not only very widely deployed but is widely deployed (especially on the client side) in hardware or firmware, historically without any updating mechanism and often on devices that would be described as IoT today. If the IETF publishes a new piece of specification that changes definitions (either an A/S or a modification to the base SMTP spec, the owners of some 30 year old thermostat or control system may not get the message much less be able to do anything about it. That situation makes incompatible changes or actions by either client or server that are different from what the other one expects a really bad idea. The difficulties are even greater because SMTP is designed to work in a relay environment: unlike something like the web, we can't expect to do a real-time end-to-end negotiation. We designed the SMTP extension mechanism with exactly those considerations in mind: the server needs to say "it is ok if you ask for this or do that because I will understand what you are doing" and, in most cases, the client needs to say "ok, here it comes and this is what we are going to do". Were it not for those considerations, we could, for example, much more easily handled internationalization and the work that became the SMTPUTF8 extensions and its relatives by saying "never mind that stuff that seems to restrict things to ASCII, you can just send UTF-8". There is a place for A/S-type statements in this and there are actually a lot of them in 5321bis, but they are ones that narrow possibilities, not expand or change them. A good example is case-sensitively of address local parts. 821 basically says that local parts are caze sensitive. 5321 doesn't change that and, in particular, the prohibition on sending systems assuming strings are case insensitive remain. It just says --to delivery systems and those allowing or assigning addresses-- that taking advantage of case insensitivity is generally a really bad idea. =20 >>>> Without that advertisement and negotiation, one would >>>> predict situations in which the expectations and >>>> capabilities of client and server would be different... a >>>> recipe for interoperability problems. >>> If that reasoning >>>> is correct, then the "enhancement" would be a new SMTP >>>> option, set of them, and/or a document describing how to >>>> specify options for "different transport" or "intermediate >>>> level" situations. >> >>> Yes. Or just a new document describing SMTP over multipath >>> TCP (a new transport mapping). > >> I suggest that either that gets done by an extension option >> or it isn't SMTP but, perhaps MPMTP. Even with an Internet >> Standard as the base, a new document that says "this is just >> like that other thing except where it isn't" is an invitation >> to both interoperability problems and a real mess if the base >> document is updated. >=20 > The current I-D says: >=20 > SMTP is independent of the particular transmission > subsystem and > requires only a reliable ordered data stream channel. > While this > document specifically discusses transport over TCP, other > transports > are possible. Appendices to RFC 821 [3] describe some of > them. > I think it is time to remove that reference to RFC 821. Probably, but the idea was to avoid invalidating previously conforming implementations. Let me suggest something else for your and the WG's consideration (without expressing an opinion on whether it would be a good idea): we deprecate HELO bind alternate transports and several other "we wouldn't do that if we were doing it today" to it. > IMHO, > the document could discuss transport over "TCP-like" > connections. That term would mean that a replacement > transport must provide for equivalent functions (open, close > or shut down, and accept) and credentials (IP address). A > well hammered wording can say that the document uses the TCP > metaphor to specify operations, while leaving to apposite > A/S'es or Extensions to specify the equivalent details for > each relevant TCP-like transport in turn.[*] That keeps the > spec as is without limiting it to TCP. My personal guess, without trying to write the text, if that defining what is TCP-like would take us down a horrible rathole. For example, TCP is basically a limited virtual-circuit arrangement running over a packet mechanism, one that imposes significant restrictions on source-specified routing. Would a virtual circuit running over one of the more circuit-like "New IP" be sufficiently TCP-like? Would it encourage moving further away from the relay model toward allowing depending on real-time, single-connection, end to end negotiation? I don't know without lots more specific proposals than your "equivalent functions" above. It would also require a very careful review of what 5321 says about gateways and maybe source routing which are things I (at least) hoped to avoid this time around. Even if nothing else, such a change would almost certainly require recycling at Proposed. =20 > I don't think it's necessary to add an Appendix which lists > existing SMTP extensions (or A/S) for existing alternative > transports =E2=80=94as RFC 821 did. Maybe that is part of my point. What 821 did was to say something close to "for this transport, do that" rather than trying to make general rules about what transports quality in a way that would ultimately make an Internet Standard SMTP dependent on a collection of Proposed Standard specs, some not written yet and without clear and enforceable criteria for them. We were afraid of such things 30 years ago; increased size of the Internet and increased deployment suggests to me that we should be even more afraid now.=20 An oddity is that we know how to do what I think you are looking for. It involves a three-level envelope model (much like X.400) or even a four-level one (rather than a two-level one with sometimes problematic separation of the headers of the inner level from actual content) and a much more clear separation of mail transport from network transport than 821/2821/5321 provide. However, that horse has no only left the barn but has completely disappeared from sight. john From nobody Wed Oct 21 13:43:55 2020 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 E7A183A07DB for ; Wed, 21 Oct 2020 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 sexMGG868THT for ; Wed, 21 Oct 2020 13:43:51 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 AB2CD3A045E for ; Wed, 21 Oct 2020 13:43:51 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR2LYPVQHC00A5O3@mauve.mrochek.com> for emailcore@ietf.org; Wed, 21 Oct 2020 13:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603312727; bh=kYa+E9FIvNqjhuj8sNT8XrTTlW8w5bq5ma/J7Og/GMc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=XLAySLuZgssnGdg9jLdfDXkaNNNu05xPvQfn4RCDGd3OFhp0ZJoXkogx4cdLQKoh0 EpsZDVjSC1Z7KurAEIxE3jfBuG5snE4/sAu8URcINVNvkzAz2I9+wENnL/3DIixmmO HvGzymyoT8MYqBpGdRzFIRmd0gfbwAS9v5llCDeE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Wed, 21 Oct 2020 13:38:41 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org, Alexey Melnikov Message-id: <01RR2LYL7FMM005PTU@mauve.mrochek.com> Date: Wed, 21 Oct 2020 12:29:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 21 Oct 2020 11:58:53 +0200" <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 21 Oct 2020 20:43:53 -0000 Alessandro Vesely wrote: > On Tue 20/Oct/2020 21:04:46 +0200 Ned Freed wrote: > >> On Tue 20/Oct/2020 17:54:34 +0200 Alexey Melnikov wrote: > >>>> I suppose it's also possible that the client doesn't want to reveal > >>>> its true sooper-secret name until after the security layer in place. > >>>> Even so, I think it would be a good idea to say that the client > >>>> SHOULD NOT change the name it puts in subsequent EHLOs. >>> Right. > >>> Another possible case that came to mind was a case of multi-tenant MTA > >>> that wants to switch domains when relaying messages from different > >>> domain. (I am not saying that this is a good idea, I was just trying to > >>> think of possible use cases for EHLO with different domain names) > > >>> But anyway, as a participant I am happy with "SHOULD NOT" for changing of > >>> EHLO parameters. > >> With two acceptably valid use cases, adding a SHOULD NOT looks like an > >> unjustified change to the spec. > > I've yet to see an acceptable use case stated that doesn't involve extending > > SMTP semantics in other ways. My sooper-secret example was intedned to be, and > > was, nonsense. And the multi-tenant case only works if the client knows that > > (1) The EHLO parameter is somehow associated with tenancy and (2) Issuing an > > EHLO with no other state change will do something. The specification guarantees > > neither. > For multi-tenant, sending an NDN from a domain featuring spf-all requires a > valid HELO name. SPF adds some semantics, but it's still SMTP. Why do you think this is the case? SPF HELO checks are self-contained; there's no requirement that the domain that shows up in the HELO/EHLO match up with anything. There's nothing in the DSN specification that says DSNs have to originate from someplace identified with the recipient domain, or for that matter that the domain in the From: field match the domain(s) being reported on. Mind you, it can be convenient for the From: address to match up with the domain being reported on, but that's at an entirely different set of issues. > >> Does it accomplish anything? > > > > It most certainly does: It prevents us from having exactly this protracted > > discussion of this bit of protocol minutiae in the future. > The minimum discussion is attained by leaving it as is. If we change it, we'll > have to discuss how to word it. 55 messages and counting in this round alone, to say nothing of the many times this has come up before, says otherwise. > Issuing EHLO to change name before a transaction makes a lot more sense than > issuing EHLO instead of RSET to abort a transaction. Yet, we leave the latter > as is exactly to avoid protocol changes and related discussions. Simply put, I disagree. I think this is silly and pointless. But feel free to prove me wrong by showing existing practice in the area. Ned From nobody Wed Oct 21 18:16:48 2020 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 34AD13A0EDF for ; Wed, 21 Oct 2020 18:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=AjdT4/S3; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=dl0GLi+J 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 olBy6ZjuPWEl for ; Wed, 21 Oct 2020 18:16:45 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D0F3A0EE2 for ; Wed, 21 Oct 2020 18:16:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2798; t=1603329403; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Onpv+ppyo192hzlqpWLKecAU7ZI=; b=AjdT4/S3lzA0nXOVEs88c/oN49ssErty+wXv9vUlcOhurJiEu3xom6Ezc2JnMm naOdR7PrFrJdJAE5Q1De1tYYGUniZa0oEhVq/jb9OEpyXqgVE7YqPAYUauZ087XE 3nb7esLEytCkOUAnQGYLMIgbHy5PNAqzzAebZvg/gDeXg= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 21 Oct 2020 21:16:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1064501465.3.640; Wed, 21 Oct 2020 21:16:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2798; t=1603329143; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YlhH10O qTtUM1UziLASG3zdHiTpOJqvWsKd3iL7Myfg=; b=dl0GLi+JoP4pu6waOHraAa6 CZjr8bwK3pHXudnBa6LGr4ohLVDn+j8hXHixHZC7IRoPwISiJN3U3YZzEl0IkZps OzJOu0yyC1RKecFeQxLKR3LVljYRfzyXHBTJdqUXVkhhNEndTMUQKCynbYYkVVwd nqLCBY50OcvB3j6NuZ3g= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 21 Oct 2020 21:12:23 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 931414610.1.17160; Wed, 21 Oct 2020 21:12:22 -0400 Message-ID: <5F90DD78.7030809@isdg.net> Date: Wed, 21 Oct 2020 21:16:40 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Ned Freed , Alessandro Vesely CC: emailcore@ietf.org, Alexey Melnikov References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> <01RR2LYL7FMM005PTU@mauve.mrochek.com> In-Reply-To: <01RR2LYL7FMM005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 22 Oct 2020 01:16:47 -0000 On 10/21/2020 3:29 PM, Ned Freed wrote: > Alessandro Vesely wrote: > >> The minimum discussion is attained by leaving it as is. If we >> change it, we'll have to discuss how to word it. > > 55 messages and counting in this round alone, to say nothing of the many > times this has come up before, says otherwise. > >> Issuing EHLO to change name before a transaction makes a lot more >> sense than issuing EHLO instead of RSET to abort a transaction. >> Yet, we leave the latter as is exactly to avoid protocol changes >>and related discussions. > > Simply put, I disagree. I think this is silly and pointless. But feel > free to prove me wrong by showing existing practice in the area. > > Ned +1 Catching up with all the comments.... I am of the belief, the Server is always in control and is driving, steering the client. So no matter what a client does RSET/EHLO or RSET/MAIL, etc, the server will handle it accordingly, including a double EHLO sequence because a human did a typo while in telnet. :-) As it is, the client issues RSET/MAIL and the wcSMTP server processes it. It does not clear EHLO. If a "new suggestion/recommendation" is followed (one or more server product clears EHLO), this means an 503 will be naturally issued at MAIL for lack of EHLO. The question is then is whether the 503 will drive the client to rewind to EHLO or will it just issue a QUIT like I have seen clients do when in a confused (unexpected) state. I could easily test the RSET clearing the EHLO to see how the clients coming my way will do. Most, if not all, are unsolicited bulk mailers trying different RCPT TO for their RSET/MAIL/RCPT sequences. Sometimes they get RCPT right and a spam sneaks by the DATA filter. Now I am curious if these clients will just issue a QUIT if they see a 503. It could be considered an optimizer! On a related note (maybe another issue?), only a few mailers sit after an DATA transaction holding the socket until something else comes in to start a new transaction. We had this discussion before, many years ago, and I decided to knock them out with a shorter timeout (PostDataTimeoutSecs=35 secs) after a DATA transaction because they were taking up resources setting there doing nothing for an extended time. In other words, we discussed the Timeout values and they are fine, but I felt the 5 mins was too long after the DATA transaction when certain mailers sit there and not send anything. I believe this is a permission concept to allow a client to just hold a server session, socket, process, resources, etc. When there are incoming loads limits, it doesn't help to have one client to hold a line. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Oct 22 02:57:48 2020 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 D87CB3A0838 for ; Thu, 22 Oct 2020 02:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Yd4FGejn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E1AGb+dF 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 O0l4A49V-7Pc for ; Thu, 22 Oct 2020 02:57:46 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812103A082F for ; Thu, 22 Oct 2020 02:57:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 727947DC; Thu, 22 Oct 2020 05:57:45 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 22 Oct 2020 05:57:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=mEOjB4034jF86y3SOOvGd4OCABI2uXT qF8oHWnuOmSM=; b=Yd4FGejnNbEG++iAqB/cuCWVLvHqj40Uv6Fo5ygG3F40yku hhhyIqmmh+eJ9p4EVMbABB8SmqwhQaoHInQM65rF4yGpA2YkjFbOU2emICWP+mcg XheFTrOPKpwfteFt3SoEP8B6wnPZX9SbZHo1rDRERun1/YbherxnnLac7JGGP3hI 14yPwlKAxPTAgzxllFNTzTTtxj4eupKS3KArCcyUR2HYIO5H/peyi0/yDFt4hKHM MXYeXTNWdZkWUczaeGWL1vpk38YVcWFEY51of3Rnolh4iL5jo4GLvhb5EFsasHA3 BITuu9oOwkvJ/YDP0hLG+UyiqhlUMITMd5REDLw== 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=mEOjB4 034jF86y3SOOvGd4OCABI2uXTqF8oHWnuOmSM=; b=E1AGb+dFA6ti9pjgbrlM5y x2HHc5UIURssNMTYEmffOjOz4vThjEYWCuMCTQFB8e8GFLnKz9VaMLw7BoXlfySf ZHAUBA86vsDaiV86PL8erqaT7XdVZwzX0dx73IXDtKxStcC9SungY15bZtU9fGYJ h3vFMRxmUnOEOJs6GZ5XNoKNazER/x3IJxhZaczcW74RP8oE94RBnDKT8mim/98N BdkIErJA/ahDcwwgs+3Hb0BKiS2YKENASVpjqbqwhJp6YfKlJ34Gy1CIObUeBz9f 1xNI+IB0pNvjWGgoFPN7fVkSZYbeqSo+HKyPGmygdLGrBrDzpcrcnZNdjlhwAoOg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeejgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeelffdtgffhveeuudeihfffjeelgfdtudfhvdettdeh feettdfhgefhfeeigfegffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhv sehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0171466006F; Thu, 22 Oct 2020 05:57:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13 Mime-Version: 1.0 Message-Id: In-Reply-To: <5F90DD78.7030809@isdg.net> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> <01RR2LYL7FMM005PTU@mauve.mrochek.com> <5F90DD78.7030809@isdg.net> Date: Thu, 22 Oct 2020 10:57:21 +0100 From: "Alexey Melnikov" To: "Hector Santos" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 22 Oct 2020 09:57:48 -0000 Hi Hector, On Thu, Oct 22, 2020, at 2:16 AM, Hector Santos wrote: > On a related note (maybe another issue?), only a few mailers sit after > an DATA transaction holding the socket until something else comes in > to start a new transaction. We had this discussion before, many years > ago, and I decided to knock them out with a shorter timeout > (PostDataTimeoutSecs=35 secs) after a DATA transaction because they > were taking up resources setting there doing nothing for an extended > time. In other words, we discussed the Timeout values and they are > fine, but I felt the 5 mins was too long after the DATA transaction > when certain mailers sit there and not send anything. I believe this > is a permission concept to allow a client to just hold a server > session, socket, process, resources, etc. When there are incoming > loads limits, it doesn't help to have one client to hold a line. I added your comment to ticket Best Regards, Alexey From nobody Thu Oct 22 09:57:32 2020 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 63D4B3A08CD for ; Thu, 22 Oct 2020 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=YUHGWrVp; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=PVpK5EtP 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 DQR3UVr62OMd for ; Thu, 22 Oct 2020 09:57:26 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0B83A08C6 for ; Thu, 22 Oct 2020 09:57:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1628; t=1603385840; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7ZsKoRtwovGTXr9MF37x5dDpma0=; b=YUHGWrVpNCC6KAJbgS6sIxcqz7/j2dLg6pxaBAZf7FRHUscSUlwEss27X3yuOp wU16jlz5aIoNNKiFZ/n8lCT2MhapgIp64+nXNSZp/l/4ON8h7kMKffRHpuUcq0/J RzrFoCL+snFDy0v3RxMP6qewFuir+bvAfcLq42lRf+GqM= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 22 Oct 2020 12:57:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1120937510.3.2304; Thu, 22 Oct 2020 12:57:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1628; t=1603385581; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QiYdDlj epfQH5kIGxO74tutVjGSmLXsGUOc6de1R1VU=; b=PVpK5EtPLtUPqJ6NA+qvkd7 6hjmux8Hd8jXZyUVeLLlK6prRj34z+4hZK6LGJHMeN9fNwYR06JWwq0KxvHrnbZk QQdGn+G8ig9mHpiK08ioRRcx+ithG3+JR5YlG8/+zWXY9SriPxm6dnwGvhyPZRZ8 GFPkfFSBQdLVVVgvrY6o= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Thu, 22 Oct 2020 12:53:01 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 987853579.1.12760; Thu, 22 Oct 2020 12:53:01 -0400 Message-ID: <5F91B9F1.8030103@isdg.net> Date: Thu, 22 Oct 2020 12:57:21 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Alexey Melnikov CC: emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <01RR0SLJ91SS005PTU@mauve.mrochek.com> <01RR14MW2FQS005PTU@mauve.mrochek.com> <4a1521e5-3666-54e8-e8c2-9a1a9576c6b9@tana.it> <01RR2LYL7FMM005PTU@mauve.mrochek.com> <5F90DD78.7030809@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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, 22 Oct 2020 16:57:30 -0000 On 10/22/2020 5:57 AM, Alexey Melnikov wrote: > Hi Hector, > > On Thu, Oct 22, 2020, at 2:16 AM, Hector Santos wrote: >> On a related note (maybe another issue?), only a few mailers sit after >> an DATA transaction holding the socket until something else comes in >> to start a new transaction. We had this discussion before, many years >> ago, and I decided to knock them out with a shorter timeout >> (PostDataTimeoutSecs=35 secs) after a DATA transaction because they >> were taking up resources setting there doing nothing for an extended >> time. In other words, we discussed the Timeout values and they are >> fine, but I felt the 5 mins was too long after the DATA transaction >> when certain mailers sit there and not send anything. I believe this >> is a permission concept to allow a client to just hold a server >> session, socket, process, resources, etc. When there are incoming >> loads limits, it doesn't help to have one client to hold a line. > > I added your comment to ticket Thanks. I would like to state I am not advocating change regarding timeouts. If anything, a consideration for server and client implementation notes if the editor and wg believe its worth to note in RFC5321bis. I see in March 2020, early discussion of Bis work, I showed an example of this timeout delay and how it was shorten by the implementation. It was followed by Klensin's response: https://mailarchive.ietf.org/arch/msg/ietf-smtp/urf_WjVuZedyWJpKEmBSDHxheqo -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Oct 23 04:13:59 2020 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 9C5953A0BBE for ; Fri, 23 Oct 2020 04:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc7rzLvqIUHO for ; Fri, 23 Oct 2020 04:13:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3B03A0BBA for ; Fri, 23 Oct 2020 04:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603451632; bh=OW+fQdmMPtX0mhDOBaxtiriLorwTaLIF7CMMafyw9hk=; l=8608; h=To:References:From:Cc:Date:In-Reply-To; b=CEErid5A0EEIR7tCHBQhI4ciHcexu2hThyEx+4rQKteU+hx+Ci0QKzEoPokp/6OR5 +HKwzWJt2iWFQYn806GUxPDTwBmcA+BgBWxx5QCKsPkYAetQYbf/9g/FejM9/Wm4tj ngTYSvNphwGITqzhQjzZfcSgKcrCVG4cQH8sINtI/mxlUM7/6m9WMfJ8ZcmZc Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC08B.000000005F92BAF0.00002898; Fri, 23 Oct 2020 13:13:52 +0200 To: John C Klensin , emailcore@ietf.org References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> <47EF54E0B8D9A53E24071951@PSB> From: Alessandro Vesely Cc: Alexey Melnikov Message-ID: <010e0ac0-8a60-3df0-7d87-248ccada7944@tana.it> Date: Fri, 23 Oct 2020 13:13:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <47EF54E0B8D9A53E24071951@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 23 Oct 2020 11:13:58 -0000 On Wed 21/Oct/2020 19:46:40 +0200 John C Klensin wrote: > --On Wednesday, October 21, 2020 11:42 +0200 Alessandro Vesely wrote: >> >> Why does [porting of SMTP to a non-TCP transport] have to be an SMTP >> extension? Any A/S could do. > > [...] > > We designed the SMTP extension mechanism with exactly those considerations > in mind: the server needs to say "it is ok if you ask for this or do that > because I will understand what you are doing" and, in most cases, the client > needs to say "ok, here it comes and this is what we are going to do". Were > it not for those considerations, we could, for example, much more easily > handled internationalization and the work that became the SMTPUTF8 > extensions and its relatives by saying "never mind that stuff that seems to > restrict things to ASCII, you can just send UTF-8". That's all true. However, while an extension works for STARTTSL, it cannot work for MPTCP or SCTP, or even Submission on port 465. In those cases, the listening socket opened by the server must be configured for the relevant transport. Although the server can advertise a different transport in its EHLO response, the corresponding keyword cannot, in general, be used in the current connection to alter the underlying protocol. The extension mechanism formalizes variations of the protocol or connections to external protocols running above TCP. Allowing variations at the transport level requires a different mechanism. A/S seems suitable. > There is a place for A/S-type statements in this and there are actually a > lot of them in 5321bis, but they are ones that narrow possibilities, not > expand or change them. [...] I'm not proposing that we write more A/S'es for any TCP-like protocol, either actually used or potentially apt. I'm just suggesting to tweak the wording about the underlying transport so that a possible future A/S wishing to port SMTP to a different transport can do so without having to rewrite the whole spec and call it a different name like MPMTP. Whoever will venture in writing an A/S for a different transport will probably want to introduce variations to take advantage of the transport's features. If I browse the I-D and look for "TCP", I find 22 matches distributed in about 10 groups. Of these, besides the intro (mentioned in the quote below) the relevant occurrences are just five: * the definition of host (Section 2.3.4), * considerations about unexpected connection resets (Section 4.1.1.5), * the FROM clause and "via TCP" in Received: (Section 4.4), * the initial 220 message timeout (Section 4.5.3.2.1), * the generic data block timeout (Section 4.5.3.2.5). I'm not proposing to formalize how an A/S should be specified and registered, that's too much. I'm just suggesting to mention those five points (are there more?), either in the intro or in an appendix, saying that an A/S for a different transport must translate them into functionally equivalent statements. >>>>> If that reasoning is correct, then the "enhancement" would be a >>>>> new SMTP option, set of them, and/or a document describing how to >>>>> specify options for "different transport" or "intermediate level" >>>>> situations. Perhaps this thread has protracted just because you dropped the above "and/or a document" in the quote below: >>> I suggest that either that gets done by an extension option or it isn't >>> SMTP but, perhaps MPMTP. Even with an Internet Standard as the base, a >>> new document that says "this is just like that other thing except where >>> it isn't" is an invitation to both interoperability problems and a real >>> mess if the base document is updated. >> >> The current I-D says: >> >> SMTP is independent of the particular transmission subsystem and >> requires only a reliable ordered data stream channel. While this >> document specifically discusses transport over TCP, other transports >> are possible. Appendices to RFC 821 [3] describe some of them. > >> I think it is time to remove that reference to RFC 821. > > Probably, but the idea was to avoid invalidating previously conforming > implementations. Let me suggest something else for your and the WG's > consideration (without expressing an opinion on whether it would be a good > idea): we deprecate HELO bind alternate transports and several other "we > wouldn't do that if we were doing it today" to it. I think you mean "previously conforming" but still running. The Network Control Program (NCP, in Appendix B) was officially ended on January 1, 1983. Dunno about the Network Independent Transport Service (NITS, in Appendix C, a.k.a. the Yellow Book Transport Service). Perhaps some museum...? For HELO, we can deprecate it (like source routes?) but we cannot remove it. >> IMHO, the document could discuss transport over "TCP-like" connections. >> That term would mean that a replacement transport must provide for >> equivalent functions (open, close or shut down, and accept) and >> credentials (IP address). A well hammered wording can say that the >> document uses the TCP metaphor to specify operations, while leaving to >> apposite A/S'es or Extensions to specify the equivalent details for each >> relevant TCP-like transport in turn.[*] That keeps the spec as is without >> limiting it to TCP. > > My personal guess, without trying to write the text, if that defining what > is TCP-like would take us down a horrible rathole. For example, TCP is > basically a limited virtual-circuit arrangement running over a packet > mechanism, one that imposes significant restrictions on source-specified > routing. Would a virtual circuit running over one of the more circuit-like > "New IP" be sufficiently TCP-like? That is up to the A/S writer to find out. Misunderstandings are always possible. I found someone who inferred that SMTP can run over UDP, because IANA register port 25 for UDP as well. (BTW, why do they do so, refring to RFC 5321 although it doesn't contain the term "UDP"?) > Would it encourage moving further away from the relay model toward allowing > depending on real-time, single-connection, end to end negotiation? I don't > know without lots more specific proposals than your "equivalent functions" > above. That is to say, if the proposed transport has equivalent functions, it is up to an A/S to specify which ones they are and how they match against TCP in order to provide the same functionality. > It would also require a very careful review of what 5321 says about gateways > and maybe source routing which are things I (at least) hoped to avoid this > time around. Source routes are defined after the concept of domain, which is central in SMTP. Domains are identified by name. Alternative transports may provide means to reach multi-homed hosts by multiple IP addresses, but must still support domain names. I don't think this requires TCP-specific considerations. Gateways by definition use some protocol other than SMTP, so they may use some other transport as well. Some of the considerations for gateways could be extended to alternative transports, for example Section 3.7.2. "Received Lines in Gatewaying". However, I'm not suggesting to do so, since that is the job of the relevant A/S. > Even if nothing else, such a change would almost certainly require recycling > at Proposed. No. I'm not proposing to change any detail of the spec. I'm just suggesting to note a little bit more explicitly which are the aspects of SMTP that depend on features of the underlying transport (besides being connection-oriented and reliable). >> I don't think it's necessary to add an Appendix which lists existing SMTP >> extensions (or A/S) for existing alternative transports —as RFC 821 did. > > Maybe that is part of my point. What 821 did was to say something close to > "for this transport, do that" rather than trying to make general rules about > what transports quality in a way that would ultimately make an Internet > Standard SMTP dependent on a collection of Proposed Standard specs, some > not written yet and without clear and enforceable criteria for them. Agreed. We shouldn't even mention alternative transports, let alone what to do for them. > An oddity is that we know how to do what I think you are looking for. It > involves a three-level envelope model (much like X.400) or even a four-level > one [...] No, that would change the spec and recycle to Proposed. It's not what I'm looking for. Best Ale -- From nobody Fri Oct 23 05:12:18 2020 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 D16FF3A0C47 for ; Fri, 23 Oct 2020 05:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYSRwGLaF08d for ; Fri, 23 Oct 2020 05:12:14 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7548E3A0C38 for ; Fri, 23 Oct 2020 05:12:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 95DF4C2B9227; Fri, 23 Oct 2020 07:12:12 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 570O50OImEbk; Fri, 23 Oct 2020 07:12:10 -0500 (CDT) Received: from [10.116.49.13] (unknown [199.184.122.7]) by episteme.net (Postfix) with ESMTPSA id C4562C2B9219; Fri, 23 Oct 2020 07:12:09 -0500 (CDT) From: "Pete Resnick" To: "Alessandro Vesely" Cc: "John C Klensin" , emailcore@ietf.org, "Alexey Melnikov" Date: Fri, 23 Oct 2020 07:12:01 -0500 X-Mailer: MailMate (1.13.2r5726) Message-ID: <76087AFC-BF1A-458C-87A9-1059394532BB@episteme.net> In-Reply-To: <010e0ac0-8a60-3df0-7d87-248ccada7944@tana.it> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> <47EF54E0B8D9A53E24071951@PSB> <010e0ac0-8a60-3df0-7d87-248ccada7944@tana.it> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Fri, 23 Oct 2020 12:12:16 -0000 On 23 Oct 2020, at 6:13, Alessandro Vesely wrote: > However, while an extension works for STARTTSL, it cannot work for > MPTCP or SCTP, or even Submission on port 465. Let's stop lumping MPTCP into this discussion. MPTCP appears to the application layer exactly like TCP, with a single address exposed to the application, and no protocol adjustments in SMTP need to be made for it. Using SMTP with other protocols may require additional documentation, but not MPTCP. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri Oct 23 14:19:30 2020 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 98F9F3A128B; Fri, 23 Oct 2020 14:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348776060.5087.7159667530864437547@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:00 -0700 Archived-At: Subject: [Emailcore] emailcore - Requested session has been scheduled for IETF 109 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, 23 Oct 2020 21:16:04 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. emailcore Session 1 (1:00 requested) Tuesday, 17 November 2020, Session II 1430-1530 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/emailcore.ics Request Information: --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: extra jmap dmarc uta Technology Overlap: calext dispatch secdispatch Key Participant Conflict: gendispatch wpack People who must be present: Pete Resnick Barry Leiba Alexey Melnikov Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 25 03:48:25 2020 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 E82E73A0C40 for ; Sun, 25 Oct 2020 03:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBBkcK-MCZ3Q for ; Sun, 25 Oct 2020 03:48:21 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845B93A0B9F for ; Sun, 25 Oct 2020 03:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603622898; bh=En+JxEJUevoLtDKC76pCz2dybH2unYDqIRAvvTJzp7A=; l=2476; h=From:To:Cc:References:Date:In-Reply-To; b=BNmwpcvO7PGF4NFTnhFjED8TbLaXwfT8gwh+xxtxPNTj5vbMvA0XbRHDDpXZbFYMW +uepr3l+5FE/9quXlqzXeqJ/1DpQNvZb17IRdWFvSsXISqgyHouV2kavUBxAbqCIbF /RxZvTpRhLrbElvwIOhxHB+kpy4gx22doFB4T2SgVyywjrLqbg7M6xuvhlq9M Authentication-Results: tana.it; auth=pass (details omitted) 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 00000000005DC053.000000005F9557F1.0000481C; Sun, 25 Oct 2020 11:48:17 +0100 From: Alessandro Vesely To: Pete Resnick Cc: John C Klensin , emailcore@ietf.org, Alexey Melnikov References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> <47EF54E0B8D9A53E24071951@PSB> <010e0ac0-8a60-3df0-7d87-248ccada7944@tana.it> <76087AFC-BF1A-458C-87A9-1059394532BB@episteme.net> Message-ID: Date: Sun, 25 Oct 2020 11:48:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <76087AFC-BF1A-458C-87A9-1059394532BB@episteme.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Sun, 25 Oct 2020 10:48:23 -0000 Hi Pete, On Fri 23/Oct/2020 14:12:01 +0200 Pete Resnick wrote: > On 23 Oct 2020, at 6:13, Alessandro Vesely wrote: > >> However, while an extension works for STARTTSL, it cannot work for MPTCP or >> SCTP, or even Submission on port 465. > > Let's stop lumping MPTCP into this discussion. MPTCP appears to the application > layer exactly like TCP, with a single address exposed to the application, and > no protocol adjustments in SMTP need to be made for it. Correct, MPTCP is transparent to apps. After I changed the underlying TCP/IP stack and rebooted, client programs appear to be using MPTCP, without even recompiling them. I learned that from the feedback by MPTCP-aware servers, which get it by getsockopt(fd, SOL_TCP, MPTCP_ENABLED, &optval, &optlen). All performance optimizations and routing tricks that exploit MPTCP can be configured below the application layer. > Using SMTP with other protocols may require additional documentation, but not > MPTCP. You are not suggesting that rfc5321bis makes such a statement, are you? Then, the question is where do you write this info (apart from this ML archives). Rfc5321bis implicitly assumes that there is only one exposed IP on each side of a TCP connection. By contrast, let me quote RFC 6897: Certain applications store the IP addresses of TCP connections, e.g., by logging mechanisms. Such logging mechanisms will continue to work with MPTCP, but two important aspects have to be mentioned: First, if the application is not aware of MPTCP, it will use the existing interface to the network stack. This implies that an MPTCP-unaware application will track the IP addresses of the first subflow only. IP addresses used by follow-up subflows will be ignored. Second, an MPTCP-aware application can use the basic API described in this document to monitor the IP addresses of all subflows, e.g., for logging mechanisms. If an MPTCP connection uses several subflows, this will possibly imply that data structures have to be adapted and that the amount of data that has to be logged and stored per connection will increase. It seems to be safer for an SMTP server running on an MPTCP stack to inspect the connections it accepts. IMHO, some kind of statement is in order. To repeat myself, I'm not proposing to write one. I'm just suggesting to make it clearer which are the hooks of rfc5321bis that future documents can refer to. Best Ale --