This information is outdated. I quote here from the Using TLS in Applications Working Group @ IETF, and their current draft <https://tools.ietf.org/html/draft-i

This information is outdated. I quote here from the Using TLS in Applications Working Group @ IETF, and their current draft <https://tools.ietf.org/html/draft-ietf-uta-tls-attacks-04> https://tools.ietf.org/html/draft-ietf-uta-tls-attacks-04>: 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) Similarly, there are attacks on the transition between unprotected and TLS-protected traffic. A number of IETF application protocols have used an application-level command, usually STARTTLS, to upgrade a clear-text connection to use TLS. Multiple implementations of STARTTLS had a flaw where an application-layer input buffer retained commands that were pipelined with the STARTTLS command, such that commands received prior to TLS negotiation are executed after TLS negotiation. This problem is resolved by requiring the application- level command input buffer to be empty before negotiating TLS. Note that this flaw lives in the application layer code and does not impact the TLS protocol directly. SMTP and IMAP clients are affected by this, so best practice is to use their encrypted ports. The use of STARTTLS-type techniques in future protocols is deprecated due to the downgrade risk. This of course has a bit of a problem as 465 was a private assignment, later unfortunately reassigned to a Cisco protocol ("URD, a transitional technology for IGMPv2/IGMPv3 & SSM"), and some routers could mess it up: "routers running URD intercept all packets using port 465, regardless of destination". (You do NOT, however, want to run URD, and if you ever see it on the internet… well, think the whole thing through… if you have a Cisco, and find you have trouble with 465 through it sometimes, and haven't turned on URD yourself, maybe get your router forensically examined! <g>) That was on the whole not a good day for the IETF/IANA. I have limited time this morning: so here's the thread on UTA, see for yourself. https://www.ietf.org/mail-archive/web/uta/current/msg00176.html https://www.ietf.org/mail-archive/web/uta/current/msg00176.h... Long story short: using 465 is probably OK, lots of people are doing it (I am). Maybe use another port, too, in case you find a crazy misconfigured Cisco in-path, which complicates a dual-assignment. The advice in the article is wrong: you are not in breach of an RFC if you use port 465 - and you probably should, but there's no clear consensus or resolution yet, so it may just get another port assignment (have I overlooked that happening?).