--On Wednesday, January 28, 2009 21:15 +0000 Peter Bowyer
<peter(_at_)bowyer(_dot_)org> wrote:
2009/1/28 Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk>:
To me, it was (initially) 'clear' that the example saying
'such as the argument to the EHLO command', was precise
enough to imply that the fact that the EHLO command was sent
should not be discarded. It could have said 'such as the EHLO
command', but it went out of its way to say '*the argument
to* the EHLO command'.
But the 'domain' argument to the EHLO command is mandatory
(RFC1869 S4.2). So a server state of having received a valid
EHLO but not knowing what the domain argument is, is not
attainable under 1869. I don't believe 3207's intent is to
introduce that state as valid after STARTTLS.
Peter, I don't believe that either 1859 or 5321 _require_ that
the server the EHLO domain or maintain it as part of its state.
Even if the server tries to inspect or check the field, as 5321
recommends, it would be a reasonable interpretation by the
server implementer to just maintain binary pass/fail
information.
That is, IMO, exactly what creates the situation here. If the
server intends to use the domain for anything that it considers
significant, it must get that information again after STARTTLS.
But there appears to be nothing in either the SMTP spec or the
STARTTS one that requires that it consider that information
significant. Conversely, if the client requires a list of
options (other than STARTTLS itself), it has to resend the EHLO,
but it is not clear that there is a requirement that it do so
otherwise.
From my point of view, the first of these two problems is
actually more important than the other in terms of requiring a
clarification in one of the two documents. If the server thinks
it needs the EHLO domain information after the TLS session has
started, it has no way to tell the client that other that by
issuing a non-fatal "command out of sequence" reply if some
other mail transaction command is issued before the second EHLO
is sent. In an alternate universe, I could imagine
303 Please send EHLO first, then resend command
but I don't imagine that most clients would respond well to that
in our universe.
john