> On Thu, 29 Jan 2009, Tony Hansen wrote:
> >
> > 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.
> I prefer Alexey's suggested "MUST NOT trust" text.
> Note that my comment about AUTH information applies to the client as well
> as the server.
> Also note that AUTH means this trust issue applies to more than just SMTP
> commands, arguments, and replies - it applies to SASL exchanges as well.
> > Section:
> > 4.2 Result of the STARTTLS Command
> >
> > Old text:
> > 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.
> That's incorrect. It's OK to QUIT at this point, for example. Rather than
> paraphrasing 2821/5321, perhaps it would be better to quote verbatim.
> 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 definitely works for me.
> > 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.
> I think this is unnecessary. I doubt anyone has been confused enough to
> implement software that would violate this requirement. I only mentioned
> it for sake of argument.
Agreed.
Ned
