Tony Finch wrote:
I suggest that this paragraph should read:
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The requirement in [RFC5321] that "a client
MUST issue HELO or EHLO before starting a mail transaction" also
applies to this fresh state.
The server MUST NOT trust any knowledge obtained from the client before
the TLS negotiation itself. The client MUST NOT trust any knowledge
obtained from the server before the TLS negotiation itself. This
includes all commands, arguments, replies, and extended exchanges
(though in typical use there is little more than the client's EHLO
command and the server's reply).
This is much better form of the consolidated input.
But I still to get the "Client MUST NOT trust" statement. It has to
trust, blind or otherwise, what the server presented up to this point
before it can go to the next step.
In my view, I think it should say:
The client MUST NOT presume the server extensions apply
in the secure state as it may have changed.
To me, that is enough to give the client the incentive and
understanding that it needs to re-issue EHLO.
Alternatively, stop confusing people any further with these beating
around the bush subjective reasons, nix all attempts to explain the
"whys," and just say:
The client MUST re-issue the EHLO/HELO before attempting to begin
a MAIL FROM transaction after secured SMTP is established.
which would keep it consistent with 2821/5321.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com