Subject: [Emailcore] Two extra issues

From: John C Klensin <[email-masked]>
Date: Thu, 17 Dec 2020 00:02:54 -0500

Hi.

As mentioned in my note about ticket #2 sent about an hour ago,
two additional issues came to my attention (or I was reminded
about them) while looking at that issue and looking through the
document.  

I've put them into the working version of what will become
draft-ietf-emailcore-rfc5321bis-01 as:

       ----

 G.12.  Extension Keywords Starting in 'X-'

   Section 2.2.2 contains a discussion of SMTP keywords starting
in "X".
   Given general experience with such things and RFC 6648, is
there any
   reason to not deprecate that practice entirely and remove
that text?
   If we do so, should Section 4.1.5 be dropped or rewritten to
make
   clear this is an obsolete practice?

 G.13.  Deprecating HELO

   RFC 5321 (and 2821 before it) very carefully circle around
the status
   of HELO, even recommending its use as a fallback when EHLO is
sent
   and a "command not recognized" response is received.  We are
just a
   few months short of 20 years; is it time to deprecate the
thing and
   clean out some or all of that text?  And, given a recent
(4Q2020)
   discussion on the EMAILCORE list, should EHLO be explicitly
bound to
   SMTP over TCP with the older transports allowed only with
HELO?
   While those questions may seem independent, separating them
is fairly
   hard given the way the text is now constructed.

Two more things...

(1) I think I've figured out how to overlay the ticket numbers
from https://trac.ietf.org/trac/emailcore/report/1 onto the
relevant lists in 5321bis where they are applicable, so the
request for someone to build a table for me is withdrawn -- they
will be in the next version.

(2) I await guidance from the WG Chairs as to when to post a new
version.  My personal preference would be to wait until we have
at least a few more tickets resolved, but up to them (and the
WG).

   john

---

From: "John Levine" <[email-masked]>
Date: 17 Dec 2020 15:54:13 -0500

> G.12.  Extension Keywords Starting in 'X-'

Kill them.

>   discussion on the EMAILCORE list, should EHLO be explicitly bound to
>   SMTP over TCP with the older transports allowed only with HELO?

I am pretty sure that all of the other transports described in RFC 821
are dead, or close enough (X.25, where it says to run TCP over it.)

Is anyone here aware of running SMTP over anything else, and if so
using HELO rather than EHLO? I'm not.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 Dec 2020 15:00:46 -0800 (PST)

> are dead, or close enough (X.25, where it says to run TCP over it.)

I haven't seen an alternate transport in use in a long time.

> using HELO rather than EHLO? I'm not.

There's still quite a few HELO's being sent by IOT stuff that supports email.
And I can understand why - when every byte counts, code to fall back from EHLO
to HELO isn't going to be written.

And as luck would have it only yesterday I had a request for the option in our
server to disable client use of EHLO. I guess something couldn't tolerate it.
(Yes, I had to look it up.)

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 17 Dec 2020 20:24:26 -0500

> to HELO isn't going to be written.

Is that SMTP or submission?  I think we will continue to tolerate a lot 
more sloppiness in submission than in SMTP relay.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 18 Dec 2020 18:23:35 +0100

On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote:
> Is that SMTP or submission?  I think we will continue to tolerate a lot more 
> sloppiness in submission than in SMTP relay.

What is going to be gained by not tolerating HELO on port 25 any more?  The 
server code is not going to shrink considerably, especially if the same code 
also supports port 587.

Sometimes I use HELO for a quick test with telnet[*] if for some reason I don't 
want the terminal window to scroll by the amount of lines that EHLO responses 
imply.

Best
Ale
-- 

[*] Telnet: another candidate to historic which still comes in handy.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 18 Dec 2020 17:43:21 +0000

Hi John,

>    clear this is an obsolete practice?

New ticket: <https://trac.ietf.org/trac/emailcore/ticket/42>
 
>    hard given the way the text is now constructed.

New ticket: <https://trac.ietf.org/trac/emailcore/ticket/43>

> at least a few more tickets resolved, but up to them (and the

I agree, you should wait until a few more issues are resolved.

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 18 Dec 2020 17:47:26 +0000

> want the terminal window to scroll by the amount of lines that EHLO responses 

[As a participant]

For reasons stated by Alessandro and Ned I have a weak preference to leave HELO as is in rfc5321bis.

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Dec 2020 15:24:22 -0500

--On Friday, December 18, 2020 17:47 +0000 Alexey Melnikov
<[email-masked]> wrote:

>> >> There's still quite a few HELO's being sent by IOT stuff
>> >> that supports email. And I can understand why - when every
>> >> byte counts, code to fall back from EHLO to HELO isn't
>> >> going to be written.
>> > 
>> > Is that SMTP or submission?  I think we will continue to
>> > tolerate a lot more  sloppiness in submission than in SMTP
>> > relay.
>> 
>> 
>> What is going to be gained by not tolerating HELO on port 25
>> any more?  The  server code is not going to shrink
>> considerably, especially if the same code  also supports port
>> 587.
>> 
>> Sometimes I use HELO for a quick test with telnet[*] if for
>> some reason I don't  want the terminal window to scroll by
>> the amount of lines that EHLO responses  imply.
> 
> [As a participant]
> 
> For reasons stated by Alessandro and Ned I have a weak
> preference to leave HELO as is in rfc5321bis.

(As a participant and for the same reasons)
 I share that preference

(And, as author)
 I recommend that the bar for making substantive changes, even
to drop things previously required or allowed, should be fairly
high.  My inclusion of that item was because I found it in my
notes from prior suggestions and comments; it was not a
recommendation for any particular action.

   john