When your MEG delivers email to next hop in clear text, and you are troubleshooting SMTP connection to the next hop server, you can run "telnet <target.SMTP.server.address> 25" on the MEG shell (command prompt) and issue some SMTP commands such as EHLO and QUIT. If the target server returns SMTP response code like 250 back against your commands, then the SMTP connection is working somehow.

 

However, when you expect your MEG to deliver email to next hop over TLS, telnet command will not suffice because TLS negotiation phase after STARTTLS requires exchanging binary data. For that particular purpose, you can use "openssl s_client" command instead. Below gives its typical usage:

 

openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp

 

The command will establish TCP connection to the target SMTP server address on given port, exchange initial EHLO command and STARTTLS command on the SMTP connection, exchange TLS handshake messages and certificates, then prompt you over TLS encrypted channel. Your input to this prompt will be transferred to the target SMTP server over the TLS channel, and the target SMTP server will respond you back over the TLS channel. The prompt looks like below:

 

CONNECTED(00000003)
.. (skip) ..
---
250 OK

 

Now that you can enter SMTP commands such as EHLO, MAIL, and RCPT. The target SMTP server will respond back to you with SMTP response code, such as 250 or 452. If you want finish testing it, enter QUIT or any phrase beginning with q.

 

In case you see the "250 OK" message after successful TLS negotiation but typing SMTP commands gives no response back from the server then eventually it shows like "451 4.7.0 Timeout waiting for client input" then try the below command instead:

 

openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf

 

The only difference is -crlf option.

 

The openssl s_client command can be used for identifying which SSL/TLS version does the target SMTP server accept:

 

just use SSLv2: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -ssl2
just use SSLv3: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -ssl3
just use TLSv1: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1
just use TLSv1.1: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1_1
just use TLSv1.2: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1_2

 

Take SSLv2 for example, if you don't receive ---250 OK then you can assume that the target server does not accept SSLv2. In such case, you can disable SSLv2 by following KB76671, or install the following MEG patch to your appliance to disable SSLv2 (see KB79384):

 

  • MEG 7.6: 7.6.2 and later
  • MEG 7.5: 7.5.2 and later
  • MEG 7.0: 7.0.4 and later

 

The same applies to TLSv1.2. You can identify whether or not the next hop SMTP server accepts TLSv1.2, then take necessary steps as outlined in KB78818 to disable TLSv1.2.

 

Now that you can identify the expected behavior of the target SMTP server on TLS. Then you can compare it with the network traffic capture of the MEG appliance while it is trying to deliver email to the target SMTP server.