Re: STARTTLS & EHLO: Errata text?

[Alexey Melnikov <[e-mail]>]

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.
>
I like that.

>Reason:
>   The example is misleading and has lead some people to think that
>   knowledge of an EHLO having been sent previously should be
>   remembered.
>
>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.
>  
>
I don't think we should recommend using HELO here: the client has issued 
STARTTLS already, so clearly it knows how to use EHLO.
Besides, I agree that we should move toward deprecating HELO.

>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.
>
>   The previous text implied that a client can get by without sending
>   one or the either.
>
>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.
>  
>
I would be Ok with making this a MUST NOT.
Also, I think it would be better to say "the client SHOULD/MUST NOT 
start a mail transaction prior to ...".

>Now for the $64k questions:
>
>1) Is there consensus behind this viewpoint?
>
We shall see :-).

>2) If so, does the text above cover the ground?
>
I frankly can't tell without rereading the RFC, but the text seems to 
address the immediate problems.

>3) If so, who wants to file the Errata?
>  
>
Go ahead and do that once there is the mailing list consensus.