Subject: [Emailcore] Ticket #2: Repeated Use of EHLO

From: Alexey Melnikov <[email-masked]>
Date: Wed, 14 Oct 2020 10:27:44 +0100

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.

Best Regards,

Alexey, as co-chair

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2020 16:53:01 -0400

In article <[email-masked]> you write:
>   there are apparently applications, at least some of them involving setting
>   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: "Alexey Melnikov" <[email-masked]>
Date: Thu, 15 Oct 2020 09:43:51 +0100

> Perhaps your informant is unclear about what RSET means.

I will redirect this question to John Klensin, as the wording from ticket is from him. John?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Oct 2020 13:29:39 +0200

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:
> 

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: Hector Santos <[email-masked]>
Date: Thu, 15 Oct 2020 08:10:59 -0400

On 10/14/2020 5:27 AM, Alexey Melnikov wrote:
> 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.
>

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: "Alexey Melnikov" <[email-masked]>
Date: Thu, 15 Oct 2020 14:03:47 +0100

Hi Hector,

(Speaking as a participant and an SMTP server implementor)

On Thu, Oct 15, 2020, at 1:10 PM, Hector Santos wrote:
> 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 

Correct. This is as expected (and agrees with my understanding of how RSET works.

> 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:

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 15 Oct 2020 14:07:00 +0100

Hi Alessandro,

On Thu, Oct 15, 2020, at 12:29 PM, Alessandro Vesely wrote:
> 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?

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Oct 2020 11:02:26 -0400

--On Thursday, October 15, 2020 09:43 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> >   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.
>> 

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: 

(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: John C Klensin <[email-masked]>
Date: Thu, 15 Oct 2020 11:31:39 -0400

--On Thursday, October 15, 2020 14:03 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> > 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 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.
>> > 
>> 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: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Oct 2020 16:44:54 +0100

Hi John,

I changed the subject as we are discussing general procedural stuff.

> them, are recorded in the tracker.
At least that makes two of us.
> 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

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: Jeremy Harris <[email-masked]>
Date: Thu, 15 Oct 2020 17:00:18 +0100

On 15/10/2020 16:02, John C Klensin wrote:
>  the question (on purely procedural
> 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: John C Klensin <[email-masked]>
Date: Thu, 15 Oct 2020 12:15:11 -0400

--On Thursday, October 15, 2020 16:44 +0100 Alexey Melnikov
<[email-masked]> 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: John C Klensin <[email-masked]>
Date: Thu, 15 Oct 2020 12:58:42 -0400

--On Thursday, October 15, 2020 17:00 +0100 Jeremy Harris
<[email-masked]> wrote:

>> 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.
> 

"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: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Oct 2020 19:52:55 +0200

> 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:

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:<[email-masked]>
     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:<[email-masked]>
     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: "John Levine" <[email-masked]>
Date: 15 Oct 2020 14:09:35 -0400

In article <1C1ADB5A63FF622622BEF328@PSB> you write:
>that an in-session EHLO implies RSET but that it subsumes RSET's

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: John C Klensin <[email-masked]>
Date: Thu, 15 Oct 2020 15:27:28 -0400

--On Thursday, October 15, 2020 19:52 +0200 Alessandro Vesely
<[email-masked]> 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.
> 
> 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:

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.

>     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.

> 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:<[email-masked]>
      S: 250 Ok.
      C: RCPT TO:<[email-masked]>
      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 
             (weird, I want an authenticated identity)
      S: 250-...
      S: 250 WHATEVER
      C: RCPT TO:<[email-masked]>
      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 

    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: "Alexey Melnikov" <[email-masked]>
Date: Fri, 16 Oct 2020 09:32:10 +0100

> That sounds correct to me.

+1.

> knowledge obtained from the client," which sounds like it also does

It does what RSET does and more, e.g. clearing the remembered EHLO hostname.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Oct 2020 10:51:57 +0200

On Thu 15/Oct/2020 21:27:28 +0200 John C Klensin wrote:
> --On Thursday, October 15, 2020 19:52 +0200 Alessandro Vesely wrote:
> 
>> 
> [...]

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?

>      5yz-Do not know why you are doing this unless
>      5yz try a new transaction (much) later.

Yeah, that should be the recommended response :-)

Best
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 16 Oct 2020 09:53:43 +0100

On 15/10/2020 13:10, Hector Santos wrote:
>>    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: Ned Freed <[email-masked]>
Date: Fri, 16 Oct 2020 03:43:08 -0700 (PDT)

> > 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.

> 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: "John Levine" <[email-masked]>
Date: 16 Oct 2020 13:16:26 -0400

>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: Hector Santos <[email-masked]>
Date: Fri, 16 Oct 2020 13:45:29 -0400

On 10/16/2020 4:32 AM, Alexey Melnikov wrote:
>>> 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

We don't know what the SMTP Client state machine was programmed to do. 
I rarely see EHLO reissued after a RSET.

> 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 <topic>".
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:<return-path>
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:<return-path>
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:<[email-masked]> BODY=8BITMIME 
SUBMITTER=[email-masked]
00:56:49.579 S: 250 <[email-masked]>... Sender validation 
pending. Continue. (8BITMIME ok)
00:56:49.638 C: RCPT TO:<[email-masked]>
00:56:49.639 S: 550 User not a member of domain: 
<[email-masked]>
00:56:49.715 C: RSET
00:56:49.715 S: 250 Reset State #1
00:56:49.775 C: MAIL FROM:<[email-masked]> BODY=8BITMIME 
SUBMITTER=[email-masked]
00:56:49.776 S: 250 <[email-masked]>... Sender validation 
pending. Continue. (8BITMIME ok)
00:56:49.833 C: RCPT TO:<[email-masked]>
00:56:49.834 S: 550 User not a member of domain: 
<[email-masked]>
00:56:49.896 C: RSET
00:56:49.896 S: 250 Reset State #2
00:56:49.953 C: MAIL FROM:<[email-masked]> BODY=8BITMIME 
SUBMITTER=[email-masked]
00:56:49.954 S: 250 <[email-masked]>... Sender validation 
pending. Continue. (8BITMIME ok)
00:56:50.011 C: RCPT TO:<[email-masked]>
00:56:50.082 ** WCX Process: wcsap ret: -1 (70 msecs)
00:56:50.082 S: 250 <[email-masked]>... Recipient ok
00:56:50.145 C: DATA
00:56:50.145 S: 354 Start mail input; end with <CRLF>.<CRLF>
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=[email-masked];
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:<[email-masked]> BODY=8BITMIME 
SUBMITTER=[email-masked]
00:56:50.636 S: 250 <[email-masked]>... Sender validation 
pending. Continue. (8BITMIME ok)
00:56:50.693 C: RCPT TO:<[email-masked]>
00:56:50.694 S: 550 User not a member of domain: 
<[email-masked]>
00:56:50.758 C: RSET
00:56:50.758 S: 250 Reset State #4
00:56:50.816 C: MAIL FROM:<[email-masked]> BODY=8BITMIME 
SUBMITTER=[email-masked]
00:56:50.816 S: 250 <[email-masked]>... Sender validation 
pending. Continue. (8BITMIME ok)
00:56:50.878 C: RCPT TO:<[email-masked]>
00:56:50.879 S: 550 User not a member of domain: 
<[email-masked]>
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.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 17 Oct 2020 00:48:50 +0200

On 2020-10-16 13:45:29 -0400, Hector Santos wrote:
> 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

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:<[email-masked]>
S: 550 Sender blacklisted
C: EHLO mail.example.com
S: 250 ...
C: MAIL FROM:<[email-masked]>
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?

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [email-masked]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Oct 2020 19:29:33 -0400

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"
<[email-masked]> 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.
>> > 
>> 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
> 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 ...

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 17 Oct 2020 01:42:47 +0200

> 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.)

> 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

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Oct 2020 22:28:24 -0400

--On Saturday, October 17, 2020 01:42 +0200 "Peter J. Holzer"
<[email-masked]> 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.

>> 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 ...
>> 
> 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: "Peter J. Holzer" <[email-masked]>
Date: Sat, 17 Oct 2020 18:51:45 +0200

> state in SMTP after a server issues a 220 service ready

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. 

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:<[email-masked]> BODY=8BITMIME SIZE=393
S:          250 2.1.0 Ok
C:  RCPT TO:<[email-masked]>
S:          250 2.1.5 Ok
C:  DATA
S:          354 End data with <CR><LF>.<CR><LF>
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 

AUTH
MAIL
RCPT 
DATA
.
MAIL
RCPT
DATA
.

is possible (and retains the auth data for the second transaction),

AUTH
MAIL
RCPT 
DATA
.
RSET
MAIL
RCPT
DATA
.

must also have the same effect, and so must

AUTH
MAIL
RCPT 
DATA
.
EHLO
MAIL
RCPT
DATA
.

        hp

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Oct 2020 15:19:26 -0400

--On Saturday, October 17, 2020 18:51 +0200 "Peter J. Holzer"
<[email-masked]> 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: "Peter J. Holzer" <[email-masked]>
Date: Sun, 18 Oct 2020 00:27:43 +0200

[...]

Right.

[...]

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.

> you are asking for?

Yeah, pretty much.

        hp

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Oct 2020 04:45:29 -0400

--On Sunday, October 18, 2020 00:27 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

> 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: "Alexey Melnikov" <[email-masked]>
Date: Sun, 18 Oct 2020 11:55:04 +0100

Hi John,

On Sat, Oct 17, 2020, at 12:29 AM, John C Klensin wrote:
> accepted) the first time around.

Agree so far.

> A second EHLO being sent right
> 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

Agreed. (Modulo your comment about EHLO and AUTH).

> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore
>

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 18 Oct 2020 12:10:40 +0100

Hi John/Peter,
Speaking as a participant and co-editor of RFC 4954 below:

> 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.

> that is not part of the mail transaction.

Agreed.

> In an exception to the

I tend to agree.

> 4954),

No, this is exactly right.

>it needs to be fixed in an update to 4954 that manages to

> closing the mail transaction, and then EHLO had been sent.

Yes.

> 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

Sounds very reasonable to me and this is what I thought was the intent.

> 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.

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 18 Oct 2020 12:15:21 +0100

Hi Hecror,
I just want to clarify one thing:

> cleared? It has no purpose to do so. It won't change.  That's a fixed 

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: Jeremy Harris <[email-masked]>
Date: Sun, 18 Oct 2020 12:37:42 +0100

> 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 connec…

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: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Oct 2020 15:07:45 +0300

Hi Jeremy,

> On 18 Oct 2020, at 14:37, Jeremy Harris <[email-masked]> wrote:
> 

Second AUTH is not allowed (it must always fail, unless previous AUTH was not successful) in SMTP AUTH, but I am happy to make it clearer. I.e. once an authenticated user is set, it is not possible to change authenticated user on an SMTP session.

Best Regards,
Alexey

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 18 Oct 2020 13:26:41 +0100

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: Ned Freed <[email-masked]>
Date: Sun, 18 Oct 2020 06:03:40 -0700 (PDT)

> 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: John C Klensin <[email-masked]>
Date: Sun, 18 Oct 2020 09:29:06 -0400

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
<[email-masked]> wrote:

>> > 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.
>> > 
>> > 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.
> 
>> > after the first one (before any other functional commands)
>> > seems rather silly but, but, if, e.g., the sequence were
>> >    EHLO ...
>> >    AUTH ...
>> >    EHLO...
>> >    MAIL ...
>> > 
>> 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
> 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: John C Klensin <[email-masked]>
Date: Tue, 20 Oct 2020 01:02:23 -0400

--On Friday, October 16, 2020 13:45 -0400 Hector Santos
<hsantos=[email-masked]> 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.
>> 
> 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-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL
> RESTRICT ACCESS *
> 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.
> 

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: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Oct 2020 10:19:24 +0200

On Tue 20/Oct/2020 07:02:23 +0200 John C Klensin wrote:
>> client machine domain name.
>> [...]
> 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: Jeremy Harris <[email-masked]>
Date: Tue, 20 Oct 2020 10:45:53 +0100

On 20/10/2020 06:02, John C Klensin wrote:
> 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]
-- 
Cheers,
   Jeremy

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 20 Oct 2020 10:55:30 +0100

Hi Alessandro,

> higher and lower layers".  However, can't a second HELO lead to realize that 

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: <https://trac.ietf.org/trac/emailcore/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: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Oct 2020 12:20:27 +0200

Hi,

On Tue 20/Oct/2020 11:55:30 +0200 Alexey Melnikov wrote:
>>> [...] the server would still have one of the few pieces of data it can
>>> really trust --the IP address >>

Yup.  Possibly something that considers "TCP-like" connections, including TSL.

> 2) use of IP addresses (and change of IP addresses) interacts with ticket #1: <https://trac.ietf.org/trac/emailcore/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: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 06:07:55 -0700 (PDT)

> 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:
> <https://trac.ietf.org/trac/emailcore/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: John C Klensin <[email-masked]>
Date: Tue, 20 Oct 2020 11:04:02 -0400

--On Tuesday, October 20, 2020 06:07 -0700 Ned Freed
<[email-masked]> 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: John C Klensin <[email-masked]>
Date: Tue, 20 Oct 2020 11:10:25 -0400

--On Tuesday, October 20, 2020 10:45 +0100 Jeremy Harris
<[email-masked]> 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 :-
> 

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.
 
> thiks we have a real problem with]

I agree about "we" but I don't know if Alessandro is on board
yet.

   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Oct 2020 11:32:03 -0400

--On Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov
<[email-masked]> 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?
> 
> 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: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Oct 2020 17:32:58 +0200

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: "Alexey Melnikov" <[email-masked]>
Date: Tue, 20 Oct 2020 16:54:34 +0100

Hi Ned,

> multipath TCP is going to require substantial specification effort going far

This is where I was heading anyway.

> 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!

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: "Alexey Melnikov" <[email-masked]>
Date: Tue, 20 Oct 2020 17:03:05 +0100

Hi John,

On Tue, Oct 20, 2020, at 4:32 PM, John C Klensin wrote:
> 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

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: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 09:28:19 -0700 (PDT)

> 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 agree about "we" but I don't know if Alessandro is on board

The semantics here are clear, and I've yet to see any justification
for changing them.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 11:22:34 -0700 (PDT)

> 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: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Oct 2020 20:29:43 +0200

> 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: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 12:04:46 -0700 (PDT)

> > 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)

> 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: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 12:19:07 -0700 (PDT)

> EHLO with no other state change will do something. THe specification guarantees

That should have been "neither".
 
				Ned

---

From: "John Levine" <[email-masked]>
Date: 20 Oct 2020 16:03:48 -0400

In article <[email-masked]> 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: Ned Freed <[email-masked]>
Date: Tue, 20 Oct 2020 18:50:15 -0700 (PDT)

> 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.

> records famously do not work well. I think we can safely not worry

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: John C Klensin <[email-masked]>
Date: Wed, 21 Oct 2020 03:13:00 -0400

--On Tuesday, October 20, 2020 17:03 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> 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.
> 

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

Good luck... and thanks.
    john

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Oct 2020 11:42:56 +0200

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 Tuesday, October 20, 2020 10:55 +0100 Alexey Melnikov wrote:
>>> 
>>>>> How would that work with multipath TCP?
>>>> 
>>>> 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: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Oct 2020 11:58:53 +0200

On Tue 20/Oct/2020 21:04:46 +0200 Ned Freed 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) >
> 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.

> 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: John C Klensin <[email-masked]>
Date: Wed, 21 Oct 2020 13:46:40 -0400

>>>> 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.)
> 

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.
 
>>>> Without that advertisement and negotiation, one would
>>>> predict situations in which the expectations and
>>>> 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
>> 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:
> 

> 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.   

> 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.
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. 

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: Ned Freed <[email-masked]>
Date: Wed, 21 Oct 2020 12:29:23 -0700 (PDT)

> 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.

> 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.

> 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: Hector Santos <[email-masked]>
Date: Wed, 21 Oct 2020 21:16:40 -0400

>
>> 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.
>
> 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.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 22 Oct 2020 10:57:21 +0100

Hi Hector,

> loads limits, it doesn't help to have one client to hold a line.

I added your comment to ticket <https://trac.ietf.org/trac/emailcore/ticket/16>

Best Regards,
Alexey

---

From: Hector Santos <[email-masked]>
Date: Thu, 22 Oct 2020 12:57:21 -0400

> I added your comment to ticket <https://trac.ietf.org/trac/emailcore/ticket/16>

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Oct 2020 13:13:52 +0200

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.

>>>>> 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:
>> 
> 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).

>> 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: "Pete Resnick" <[email-masked]>
Date: Fri, 23 Oct 2020 07:12:01 -0500

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: Alessandro Vesely <[email-masked]>
Date: Sun, 25 Oct 2020 11:48:17 +0100

Hi Pete,

On Fri 23/Oct/2020 14:12:01 +0200 Pete Resnick 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
--