Testing Your Authentication Configuration

Table of contents:

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

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:

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

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
Connected to mail.example.com.
Escape character is '^]'.

Server: 220 mail.example.com ESMTP Postfix
EHLO test.ora.com
250-SIZE 10240000
AUTH PLAIN a2RlbnQAa2RlbnQAcnVtcGxlc3RpbHRza2lu
Server: 235 Authentication successful
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:


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.



Postfix Architecture

General Configuration and Administration

Queue Management

Email and DNS

Local Delivery and POP/IMAP

Hosting Multiple Domains

Mail Relaying

Mailing Lists

Blocking Unsolicited Bulk Email

SASL Authentication

Transport Layer Security

Content Filtering

External Databases

Appendix A. Configuration Parameters

Appendix B. Postfix Commands

Appendix C. Compiling and Installing Postfix

Appendix D. Frequently Asked Questions

Postfix(c) The Definitive Guide
Postfix: The Definitive Guide
ISBN: 0596002122
EAN: 2147483647
Year: 2006
Pages: 130
Authors: Kyle Dent D.

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net