OS: FreeBSD9 64 Bit

MTA: EXIM4 with TLS with Self Signed Certificate.

I am using

telnet myserver.com 25 
EHLO [email protected]

It says

TLS go ahead

And then I issue

MSG FROM: [email protected]

It says

554 Security Error
It first says tls is ok go ahead then produces error!!!!!

Can someone figure out What is the problem. And/Or provide necessary solution.

If more information is required please let me know

I tested my tls here https://www.wormly.com/test_smtp_server, It produced:

Resolving hostname...
SMTP -> ERROR: EHLO not accepted from server: 
SMTP -> ERROR: HELO not accepted from server: 
Message sending failed.
  • 2
    run openssl s_client -starttls smtp -crlf -connect myserver.com:587 instead. It is supposed to handle TLS handshake internally. s_client - SSL/TLS client program Mar 13, 2014 at 18:49
  • @SparKotॐ, Thanks, It works. I still have problem but this one is over now. +1
    – Nishan
    Mar 14, 2014 at 7:36
  • @SparKotॐ You really should post that as a proper answer, so it can be voted on and accepted.
    – user
    Mar 26, 2014 at 14:35
  • @MichaelKjörling you can add the above command to supplement your well explained answer. Mar 27, 2014 at 10:50

2 Answers 2


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 STARTTLS:

  1. There is no MSG FROM command in SMTP. The proper syntax is MAIL FROM:<[email protected]>
  2. 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 HELO

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 EHLO).

  • Thank you. I now did STARTTLS->EHLO [email protected]>MAIL FROM:[email protected] BUT YET SAME ERROR.
    – Nishan
    Mar 13, 2014 at 14:15
  • @Nishan Please read my answer again. EHLO [email protected] CRLF MAIL FROM:[email protected] CRLF is almost certainly not a valid TLS negotiation.
    – user
    Mar 13, 2014 at 14:21
  • I am sorry. Can you please tell me what you mean by VALID TLS NEGOTIATION. Thanking you in advance.
    – Nishan
    Mar 13, 2014 at 14:24
  • @Nishan Not in comments. See my edits.
    – user
    Mar 13, 2014 at 14:30
  • @Downvoter a comment explaining what might be wrong with the answer would be appreciated, so I can improve it.
    – user
    Mar 13, 2014 at 18:39

You need to send an ALRM signal to it after the TLS go ahead,

killall -ALRM gnutls-cli

You can do this via another terminal or by hitting Crtl-Z to background the current process, doing the killall command, then typing fg to return to the SMTP session.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .