How to Debug SMTP with TLS(SSL) and AUTH

The first thing to test is a TLS (aka SSL) connection. The stunnel program has special code for this, the command “stunnel -n smtp -c -r mail.example.com:25” will connect to the server via SMTP and negotiate SSL.

If you use gnutls then the command “gnutls-cli -s mail.example.com -p 25” will connect to the server, allow you to establish the session (by typing “ehlo hostname” and then “starttls“) after which you can press ^D to enter TLS mode. This is a little more inconvenient.

Once one of these is done and you will receive a 220 message acknowledging the connection (which is the same as if you had just connected without TLS). If you want to test the TLS certificate then use the “-v” option to stunnel. Note that if the certificate is not verified successfully then stunnel will exit and log via syslog the reason why. While stunnel seems more convenient for actually using a protocol, the openssl utility is a much better program for actually testing out the SSL functionality. The command “openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.example.com:25” will dump a lot of diagnostic information about the SSL protocol. Note that the location of the SSL certificates varies by distribution, /etc/ssl/certs is the location used on Debian.

When compared to openssl and stunnel, gnutls-cli is less convenient than stunnel, and somewhere between the other two in terms of utility for debugging. It’s good to have all three clients available for testing!

Then enter the command “ehlo hostname.example.com” (the hostname is generally not checked for the case of mail relaying so any text that vaguely resembles a real host DNS name will do).

The response to that command will be something like the following:
250-mail.example.com Hello hostname.example.com [10.10.10.10], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP

The important thing to note is the 250-AUTH message which indicates that you may authenticate, it tells us that you can use the LOGIN and PLAIN methods of authentication. All the further communication for the login will be base64 encoded, the best utilities that I know of in Debian/Etch for encoding and decoding base64 are /usr/share/fml/bin/base64encode.pl and /usr/share/fml/bin/base64decode.pl which are in the fml package. Debian/Lenny and newer have base64 as part of the coreutils package.

The command auth login will typically give the response “334 VXNlcm5hbWU6“, the command “echo VXNlcm5hbWU6|/usr/share/fml/bin/base64decode.pl” shows that it is requesting the “Username:“.

To generate a response to the Username prompt run the command “echo -n user@example.com | /usr/share/fml/bin/base64encode.pl” (or whatever your user-name is) and you will receive an encoded message such as “dXNlckBleGFtcGxlLmNvbQ==“. Enter that to the mail server and you will get a response with another 334 code similar to “334 UGFzc3dvcmQ6“, again if you decode the part after the space you will br prompted for the “Password:“. The command “echo -n mypass | /usr/share/fml/bin/base64encode.pl” will give a response that you can give to that prompt. If all goes well that will give a 235 message to tell you that you are authenticated. Then you can relay mail!

When relaying mail after authenticating using SASL, if the mail is authenticated then you can use the auth parameter. This means that instead of using the SMTP command “mail from: <user@example.com>” you use the command “mail from: <user@example.com> auth=<user@example.com>“.

Normally this will all be done by your MUA, but if something goes wrong and you don’t know why then manually running through the steps can reveal the source of the problem.