Re: I-D ACTION:draft-hoffman-rfc2487bis-02.txt

On Mon, Sep 13, 1999 at 10:26:58AM -0400, Jeffrey Altman wrote:

>>>> The client might have to stop after the 220, such as if it realized that it
>>>> couldn't really start TLS. Thus, the client should be able to issue a QUIT.
>>>> Your proposed MUST NOT would prevent that.

>>> Deliberately, because forcing server implementations to be able to
>>> recognize both protocols (clear SMTP and TLS handshake) complicates
>>> implementation without really having any significant benefit: The 220
>>> response to STARTTLS should not come as much of a surprise to the
>>> client, or it should not have sent the STARTTLS command in the first
>>> place.

>>> Is there really any (alleged) RFC 2487 server implementation that
>>> continues as specified when the client sends clear SMTP commands after
>>> the 220 answer to STARTTLS?

>> These are good questions. If no one *could* handle a text QUIT at that 
>> point, Bodo's MUST NOT seems sensible. It would mean that, if a client 
>> wanted to say "whoops", the only way would be to drop the connection, but 
>> that is probably better than confusing the TLS stack with unexpected garbage.

> I'm sorry that I have not been paying attention to this thread.  The
> rule is: 
> 
> . if the START_TLS negotiation fails, then the server should should 
>   drop the connection.
> 
> . if the client's policy is to allow a non-TLS connection, the client 
>   should reconnect and refuse to negotiate START_TLS.
[...]

That's not exactly the situation that we are discussing: RFC 2487
allows the client to continue without even having really attempted to
start a TLS handshake -- the client sends STARTTLS, the server replies
220, and the client sends any other SMTP commands (intended use is to
send QUIT only, but there's no such restriction in the specification)
in clear where one would expect a client hello message.