Testing SMTP AUTH after STARTTLS

A mail server should allow relaying only for authorized clients or it will quickly become a spam relay. In my case the sendmail clients use certificates signed by my own root CA for the purpose of authentication. Unfortunately not all MUAs (e.g. the one on my mobile) are capable of presenting a certificate to the server and then SMTP AUTH seems to be the solution.

While CRAM-MD5 is more secure it is unfortunately often necessary to allow the authentication mechanisms PLAIN or LOGIN to support all clients. PLAIN and LOGIN make it quiet easy for an eavesdropper to extract the username and password from the network traffic and so I wanted to make sure that SMTP AUTH would only be used over an encrypted SMTP session.

Telnetting to the smtp port and talking directly to the mail server has always been a helpful tool for debugging and testing. But using the same method to establish an encrypted session with STARTTLS is not feasible. Here is a brief description of how to do it with the help of the commandline tool gnutls-cli.

As a prerequisite we need to encode the username and password as Base64 string. You can use the following line of perl to get the encoded string. Perl will print a string that contains the username and password in the exact format that is needed for AUTH PLAIN.

$ perl -MMIME::Base64 \
       -e 'print encode_base64("\000"."user"."\000"."secret");'
AHVzZXIAc2VjcmV0

Obviously user and secret should match your account details. Then use gnutls-cli to connect to the mail server.

$ gnutls-cli --crlf --starttls \
    --x509cafile /etc/ssl/certs/my-root-ca.pem \
    --port 25 smtp.example.net
Processed 1 CA certificate(s).
Resolving 'smtp.example.net'...
Connecting to '198.51.100.42:25'...

- Simple Client Mode:

220 smtp.example.net ESMTP Sendmail

With the --starttls argument gnutls-cli will create a transparent connection until either an EOF is issued on stdin or it receives a SIGALRM signal. The option --x509cafile points to the file with my root CA certificate that the server will present during the encryption negotiation.

The last line with the SMTP code 220 indicates that we can start talking SMTP to the server. So we can continue and use the EHLO command to introduce ourself.

EHLO host.example.net
250-smtp.example.net Hello host.example.net [198.51.100.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 16777216
250-DSN
250-STARTTLS
250-DELIVERBY
250 HELP

From the response of the server we can see that it allows STARTTLS to encrypt the connection but currently does not support the AUTH command. Therefore we issue the STARTTLS command and after the server has signaled that it is willing to negotiate the encryption we type Control-D as if we would want to logout. This tells gnutls-cli to take over and establish the encryption with the server.

STARTTLS
220 2.0.0 Ready to start TLS
^D

Then gnutls-cli prints details about the encryption process. When the encryption has succeeded we can continue to type SMTP commands but now no eavesdropper is able to read what goes on between us and the server. We issue the AUTH command using the encoded string.

AUTH PLAIN AHVzZXIAc2VjcmV0
235 2.0.0 OK Authenticated

The response from the server tells you if the authentication has been successfull or not. In general codes starting with a two indicate success while codes starting with a five indicate failure. So in this case username and password were accepted by the server.

I have written the perl script smtpauth as reference for myself.