We do not need the »STARTTLS« I proposed. The simpler way is like some‐
one said to just connect using TLS. The TLS header is an invalid ASCII
selector and so any compliant server will give back an error. If this
does not succeed the client should / must not try to connect us‐
ing plain gopher. If a server supports TLS should be cached by the
client.
3. Implicit TLS
Previous standards for the use of email protocols with TLS used
the STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With
STARTTLS, the client establishes a cleartext application session
and determines whether to issue a STARTTLS command based on
server capabilities and client configuration. If the client
issues a STARTTLS command, a TLS handshake follows that can
upgrade the connection. Although this mechanism has been
deployed, an alternate mechanism where TLS is negotiated
immediately at connection start on a separate port (referred to
in this document as "Implicit TLS") has been deployed more
successfully. To encourage more widespread use of TLS and to also
encourage greater consistency regarding how TLS is used, this
specification now recommends the use of Implicit TLS for POP,
IMAP, SMTP Submission, and all other protocols used between an
MUA and an MSP.