ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
While I have no objection to making this change, I note in passing
that quite a
few servers, ours included, violate the "the server MUST discard any
knowledge
obtained from the client" part of this and will continue to do so no
matter
what is written in any standard.
I think you could argue that the number of messages you have accepted
from the client, the session time, the number of recipients etc, is NOT
information received from the client, but information derived by the
server itself.
Maybe, but it's exactly the sort of handwaving argument we always lambast when
somebody uses it in support of some oddball thing they want to do that's
causing interoperability problems.
If there was an extension for the client to say 'I'm going to send 6
messages this session', then that information would have to be
discarded, but the server remembering that 6 messages have already been
sent is something the server could work out for itself.
Also, AIUI, you could always refuse to accept STARTTLS after you have
accepted a message. (I can't think of any good reason you'd want to send
some messages with TLS and others without, but maybe others can)
Not only have there been people arguing for this in the past, there have also
been proponents who wanted to be able to do AUTH and STARTTLS in the
middle of a transaction. Fortunately we managed to stomp out the latter.
Ned