Bugzilla

Looking at [RFC 3501](https://tools.ietf.org/html/rfc3501#section-6.2.1) it seems that everything after the server response (`<tag> OK Begin TLS negotiation now\r\n`) would be considered part of the StartTLS negotiation. So I'd guess a server which sends extra plaintext _should_ result in a failed negotiation.

In an ideal world the TB IMAP parser would stop after the "\r\n", call StartTLS() and then, once the negotiation was complete, continue reading on the newly-secured socket. In practice, the IMAP parser will be greedy and slurp in as much data as it can buffer (otherwise you're just reading single bytes, looking for `\r\n`, which would suck). Because the StartTLS upgrade is handled at a lower level, the IMAP parser needs a way to feed the remaining buffered data back into the stream for the negotiation.

Back In the real world:
After the server sends it's `<tag> OK Begin TLS negotiation now\r\n` response, it must wait upon the client for the next step (which is, I think, the client saying which versions of SSL/TLS and ciphers it talks).
So, with that in mind, it seems perfectly fine for the client to completely discard everything after the  server's `OK Begin...` line.

Gene's approach in comment 11 seems to be the right approach... although technically I think it wants to drain the socket and clear the TB IMAP-parser-incoming-data buffer _before_ StartTLS() is called, rather than afterwards. But the main thing is that any dodgy data buffered up in the IMAP parser is ditched rather than used.

Looking at [RFC 3501](https://tools.ietf.org/html/rfc3501#section-6.2.1) it seems that everything after the server response (`<tag> OK Begin TLS negotiation now\r\n`) would be considered part of the StartTLS negotiation:

> A [TLS] negotiation begins immediately after the CRLF at the end
> of the tagged OK response from the server.  Once a client issues a
> STARTTLS command, it MUST NOT issue further commands until a
> server response is seen and the [TLS] negotiation is complete.

 So I'd guess a server which sends extra plaintext _should_ result in a failed negotiation.

In an ideal world the TB IMAP parser would stop after the "\r\n", call StartTLS() and then, once the negotiation was complete, continue reading on the newly-secured socket. In practice, the IMAP parser will be greedy and slurp in as much data as it can buffer (otherwise you're just reading single bytes, looking for `\r\n`, which would suck). Because the StartTLS upgrade is handled at a lower level, the IMAP parser needs a way to feed the remaining buffered data back into the stream for the negotiation.

Back In the real world:
After the server sends it's `<tag> OK Begin TLS negotiation now\r\n` response, it must wait upon the client for the next step (which is, I think, the client saying which versions of SSL/TLS and ciphers it talks).
So, with that in mind, it seems perfectly fine for the client to completely discard everything after the  server's `OK Begin...` line.

Gene's approach in comment 11 seems to be the right approach... although technically I think it wants to drain the socket and clear the TB IMAP-parser-incoming-data buffer _before_ StartTLS() is called, rather than afterwards. But the main thing is that any dodgy data buffered up in the IMAP parser is ditched rather than used.