Testing SMTP AUTH connections

When setting up a mail server, one of the things you should do before you "go live" is to test it- not only to make sure things which should work, do work, but to make sure things which shouldn't work, don't.

One of the things to test is whether or not your server correctly supports the AUTH command. This command is used when a remote client wishes to identify themself as an "authenticated" user, normally so that they can use your server as an outbound mail relay. This is very handy for companies with employees who travel, or for ISPs with clients who travel.

Find your authentication information

In order to use the AUTH command, you need to know the base64-encoded version of the userid and password you will be using to authenticate to the server. Normally this would be the same as the userid and password you would use to check your mail using IMAP or POP3. This perl command (which requires the MIME::Base64 module) will do the encoding for you:

% perl -MMIME::Base64 -e 'print encode_base64("\000jms1\@jms1.net\000not.my.real.password")'
AGptczFAam1zMS5uZXQAbm90Lm15LnJlYWwucGFzc3dvcmQ=

Note: Make sure to use \0 both as the first character of what you're encoding, and as the separator between the userid and the password. There was an error with the original version of these directions- I had forgotten about needing a \0 at the beginning. Sorry all!

Another reader pointed out that perl silently interprets the "@" sign in the middle of a string and replaces it with the contents of an array with that name, if one exists... or with nothing, if not. I just did a full two-way test with my real password, and it turns out if you don't put a backslash in front of the "@" sign it won't work. Good call.

And JT Justman pointed out that if you use \0 as the separator, and the userid or password happens to start with a digit, perl will try to find and use a three-digit octal character code instead of a one-digit null byte with two normal digits behind it. Using \000 instead of just \0 prevents this from happening.

Connecting to the server

Depending on how the server is configured, you may need to use SSL or TLS before you are able to use the AUTH command. In fact, if you are able to use the AUTH command without using either SSL or TLS, you are in fact sending your userid and password over the internet in clear text. Anybody with a packet sniffer in the right spot will be able to read the base64-encoded string you send to authenticate, and it's really easy to decode that stuff- in fact the same command above will work if you change "encode_base64" to "decode_base64" (and put the encoded string between the double quotes, obviously.)

To connect to a normal, non-secured SMTP server on IP address 1.2.3.4, you would use this command:

% telnet 1.2.3.4 25
To connect to a server which should support TLS, you may wish to verify that it does support TLS first. When you send the EHLO command, the server will respond with a list of the items it supports. If you see STARTTLS on the list, it means the server will allow you to send the STARTTLS command. Example:

% telnet 1.2.3.4 25
220 a.mx.jms1.net NO UCE ESMTP
ehlo testing
250-a.mx.jms1.net NO UCE
250-STARTTLS
250-PIPELINING
250 8BITMIME
quit

Once you have verified that the server supports the STARTTLS command, you can use the "-starttls smtp" option of openssl s_client to connect. This makes openssl connect normally (without encryption), send a STARTTLS command, negotiate the SSL encryption, and then allow you to interact with the encrypted session. For example, to connect to a TLS-enabled SMTP servers on IP address 1.2.3.4, you would use this command:

% openssl s_client -starttls smtp -crlf -connect 1.2.3.4:25
And for an SSL server (where you connect to a different port number and have to establish an SSL connection before the SMTP conversation even starts) on IP address 1.2.3.4 port 465, you would use this command:

% openssl s_client -crlf -connect 1.2.3.4:465

Make sure the server supports AUTH

When you first connect to an SSL or TLS server, you will see the key-exchange information fly by on the screen, and the last line you see when it stops scrolling text will be the server's "banner" message, which tells the client that the server is ready to accept commands. For a non-secured connection, the first thing you see will be the banner.

When the banner is received, a normal SMTP client would send an EHLO command to the server in order to identify the client machine, as well as ask for a list of the capabilities supported by the server.

If you are using an openssl command to connect to an SSL or TLS server, make sure to enter your SMTP commands in lowercase as shown here. The openssl "s_client" command watches what you type- if you send a line of text starting with a capital "R", it will re-key the SSL layer instead of sending your command to the server... and if you send a line of text which starts with a capital "Q", it will terminate the SSL connection and exit.

220 a.mx.jms1.net NO UCE ESMTP
ehlo testing
250-a.mx.jms1.net NO UCE
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-PIPELINING
250 8BITMIME

Look at the response from your EHLO command, make sure AUTH is on the list, and that PLAIN is one of the options it supports. If it's not listed, the server will not let you send an AUTH command. This may be because the connection is not secured and the server is protecting you from sending your authentication information across the net in plain text...

Sending the AUTH command

Assuming the server supports AUTH, we will send the actual AUTH command to try and authenticate.

AUTH PLAIN AGptczFAam1zMS5uZXQAbm90Lm15LnJlYWwucGFzc3dvcmQ=
235 ok, go ahead (#2.0.0)

If you see this message, you are authenticated. If you see this one instead...

AUTH PLAIN AGptczFAam1zMS5uZXQAbm90Lm15LnJlYWwucGFzc3dvcmQ=
535 authorization failed (#5.7.0)

... then obviously it means you are not authenticated. If you were not able to authenticate, you can try another AUTH PLAIN command- although if the server is logging the traffic or running an intrusion detection system, having multiple AUTH commands in a single SMTP session is enough to raise a red flag. Be careful not to ban your test client's IP address.

Sending the message

Once you are authenticated, you may continue with a normal SMTP conversation and the server should accept any message from you, whether you are relaying to an outside domain or not. Even if you don't authenticate, the server will still accept messages from you- it just won't relay (it will act the same as if you had never entered an AUTH command at all.)

mail from: <nospam@jms1.net>
250 ok
rcpt to: <nospam@jms1.net>
250 ok
data
354 go ahead
From: John <nospam@jms1.net> To: Nobody <nospam@jms1.net> Subject: fnord hail eris! .
250 ok 1113954693 qp 29052
quit
221 a.mx.jms1.net NO UCE