Hi Tony,
Some of the text in this message is from from RFC 3207.
At 09:04 29-01-2009, Tony Hansen wrote:
If we were to write an Errata against RFC 3207, I'd suggest text such as
the following (in Errata format):
Section:
4.2 Result of the STARTTLS Command
Old text:
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.
New text:
The server MUST discard any knowledge obtained from the client that
was not obtained from the TLS negotiation itself. The server state
is otherwise as if the connection had just been opened.
Reason:
The example is misleading and has lead some people to think that
knowledge of an EHLO having been sent previously should be
remembered.
Quoting the entire paragraph from the RFC:
"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 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. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation."
Updated text:
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 server MUST discard any knowledge obtained
from the client, such as command verbs and their arguments, that was
not obtained from the TLS negotiation itself. The client MUST discard any
knowledge obtained from the server, such as the list of SMTP
service extensions,
which was not obtained from the TLS negotiation itself. As the
server state is
as when a SMTP session is initiated, the client SHOULD send an
EHLO command as the
first command after a successful TLS negotiation.
New text:
The client MUST send either an EHLO command or a HELO command as the
first command after a successful TLS negotiation.
As the two ends are support EHLO, there is no need to have HELO
there. I suggest leaving the MUST to the next revision.
Reason:
Since the state is reset to that of a connection having just been
opened, the requirement from RFC 5321 applies:
In any event, a client MUST issue HELO or EHLO before starting a
mail transaction.
I didn't use MUST for the EHLO because there isn't any restriction on
whether the client can only perform mail transactions in RFC 3207 or
RFC 5321. In the updated text, it is implied that the client must
not forget that the server supports the STARTTLS extension. Do we
expressly need to say that? :-)
Section:
4. The STARTTLS Command
Old text:
The format for the STARTTLS command is:
STARTTLS
with no parameters.
New text:
The format for the STARTTLS command is:
STARTTLS
with no parameters.
Because the server state machine is reset to an initial connection
state after negotiating TLS, and any modifications to the server
state will be lost, the client SHOULD NOT issue any MAIL
FROM or RCPT TO commands prior to using the STARTTLS command.
Agreed.
Now for the $64k questions:
1) Is there consensus behind this viewpoint?
See updated text.
3) If so, who wants to file the Errata?
You have already volunteered. :-)
Regards,
-sm