At 15:59 29-01-2009, Ned Freed wrote:
Yes, but the text currently says MUST, not SHOULD:
The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself.
I'm arguing that this MUST should be a SHOULD.
Alexey proposed a change that avoids the issue as it does not change the MUST.
Actually, the specification is quite clear that the session state is
reset to that of where the banner line has just been returned:
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).
I quoted that part previously. It's quite clear to me what "reset to
initial state" means.
So if the client sends a MAIL FROM without first sending a EHLO/HELO it is
doing so to a server that's supposed to be in the "initial banner sent, no
EHLO/HELO seen" state. IMO a server is perfectly entitled to refuse the MAIL
FROM in this case.
But I fail to see how this has any bearing on the point I've raised, which has
to do with the server retaining session history after STARTTLS - something the
specification currently forbids.
I was not addressing the question of session history; I was
commenting on the EHLO requirement.
Frankly, while I have no problem with clarifying the specification,
I don't buy
the argument that the nonissuance of a EHLO/HELO after STARTTLS and
FROM is in compliance with the SHOULD. Again, the specification is very clear
about the required session state and a predictable consequence of that is that
a HELO/EHLO is now required. IMO this is failing to understand the likely
consequences of omitting the EHLO/HELO.