That's because the response to
STARTTLS simply indicates that you should go ahead and do TLS negotiation; it does not mean that the link is now covered by TLS. TLS negotiation is the process of the two systems involved agreeing on keys, exchanging certificates, etc., all in the name of establishing a trusted, encrypted channel between the two systems.
Quoting RFC 2487 (SMTP Service Extension for Secure SMTP over TLS), section 5
The STARTTLS Command:
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
Also see section 6
Usage Example in the same RFC. Note that it specifically elides the actual TLS negotiation process.
When the server expects you to start negotiating TLS, and you instead give a SMTP (or not even SMTP) command, that is extremely likely to be an error. I'm not familiar with the TLS negotiation process internals but the odds that either
MSG FROM: or
MAIL FROM: forms valid TLS negotiation initiation stanzas would appear to me to be incredibly tiny. The SMTP server, in this case, is well within its rights to refuse your failed attempt at TLS negotiation; hence the error you receive back.
In addition to that, there are two problems with your
MSG FROM: [email protected] immediately following the
- There is no
MSG FROM command in SMTP. The proper syntax is
MAIL FROM:<[email protected]>
- The SMTP session is reset to the initial state when the TLS negotiation completes (see RFC 2487 section 5.2), so you must restart by first giving a
EHLO or possibly
If you want to connect to a SMTP server that requires STARTTLS, then you can use OpenSSL's SSL/TLS client for that purpose rather than telnet. That will be something along the lines of
openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 for SMTP STARTTLS. Once the connection has been established you can simply use the then properly set up SMTP connection (start at the