Testing Your Authentication Configuration

It's probably best to try authenticating to your SMTP server manually before having your users attempt it with their email clients. By connecting to your SMTP server and manually authenticating, you can see exactly what response you get, and you can immediately check your log file for any other important information.

The easiest way to connect to your SMTP server is to use a Telnet client and then start speaking SMTP to your server. (Chapter 2 shows a sample SMTP session.) The PLAIN mechanism is the easiest to test, so if you have disabled it, you may want to enable it just to confirm that authentication works. You can disable it after you are finished testing.

To authenticate using the PLAIN mechanism, you must send the command AUTH followed by your credentials encoded using base64. Your credentials are a combination of the authorization identity (identity to login as), followed by a null character, followed by the authentication identity (identity whose password will be used), followed by a null character, followed by the password. Usually, the authorization identity is the same as the authentication identity, and we'll assume as much here. Using the credentials for the user kdent, you need to encode the string 'kdentkdentRumpelstiltskin'.

The tricky part is to encode your credentials in base64 without including a carriage return character. If your system has the mmencode and printf commands, it should be simple. The printf command prints formatted strings, and does not automatically include a linefeed like the more common echo command. The mmencode command simply converts strings into various MIME formats and uses base64 by default, which is exactly what we need.

You can get the encoded string you need by executing the following:

$ printf 'kdentkdentRumpelstiltskin' | mmencode
a2RlbnQAa2RlbnQAcnVtcGxlc3RpbHRza2lu

On some platforms printf might not handle the null characters embedded in the middle of the string correctly. You'll know that you have this problem if the encoded string is shorter than your original string. You can try using the echo command with the -n switch instead of printf if it's available on your system. The -n tells echo not to include a trailing newline character. If you cannot get echo or printf to cooperate, or if you do not have the mmencode command, you can find a simple Perl solution in the sidebar in this chapter to get the string you need.

encode_sasl_plain pl

If you don't have the mmencode (or mimeencode) command, here's a simple Perl script to create the encoded string you need for testing. This script requires the MIME::Base64 module, which may not be installed on your system. You can easily retrieve it from your favorite CPAN mirror:

#!/usr/bin/perl
use strict;
use MIME::Base64;
if ( $#ARGV != 1 ) {
 die "Usage: encode_sasl_plain.pl  
";
}
print encode_base64("$ARGV[0]$ARGV[0]$ARGV[1]");
exit 0;

To get the required base64 authentication string for the user kdent using the password Rumpelstiltskin, execute the command as follows:

$ encode_sasl_plain.pl kdent Rumpelstiltskin
a2RlbnQAa2RlbnQAcnVtcGxlc3RpbHRza2lu

This produces the required string, which you can then cut and paste into your Telnet session.

Once you have the string you need, cut and paste it into your Telnet session. In the example below, you type the telnet command to get things started, and then all of the bold lines. Here you are testing authentication on the host mail.example.com. You should specify your own system's name:

$ telnet mail.example.com 25
Trying 192.168.100.5...
Connected to mail.example.com.
Escape character is '^]'.

Server: 220 mail.example.com ESMTP Postfix
EHLO test.ora.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-XVERP
250 8BITMIME
AUTH PLAIN a2RlbnQAa2RlbnQAcnVtcGxlc3RpbHRza2lu
Server: 235 Authentication successful
quit
Server: 221 Bye

Connection closed by foreign host.

If you do not see a message that the authentication was successful, check your mail log to see what Postfix has reported. Problems can be tricky to track down because there are many pieces involved.

When you test authentication using Telnet, if you don't see the line:

250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5

listed among the server's extensions, make sure that you didn't forget smtpd_sasl_auth_enable in your main.cf file. If the parameter is there (without typos), then you'd better look at how you compiled Postfix and make sure that it was built with support for SASL.

If the log tells you that it cannot open the db file, make sure that the password file exists in the /etc directory and that the permissions are set so the postfix account has access to it. The Cyrus distribution comes with some utilities that might help you diagnose problems. Check the documentation for the sasldblistusers2 and the saslpasswd2 commands.