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). > 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. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
