...making Linux just a little more fun!

SMTP Authentication with Postfix

By René Pfeiffer

Sending and receiving email is still one of the most important aspects of the Internet. Anyone who has ever worked in first level support knows this. Sending email is not a trivial task anymore, because a lot of Internet service providers fight against unsolicited email known as spam. For end users this means that you have to configure a fixed mail server that accepts email from you and relays it to other servers. This usually works fine as long as you aren't mobile. Laptop users with ever changing IP addresses sometimes need to change their relay mail server depending on their location. Accepting email from dynamically assigned addresses is best done by SMTP Authentication. I will show you how this works.


Who is Who

The configuration can be done with almost all GNU/Linux distributions. Nevertheless I will focus on using Debian Etch together with Postfix. We will also use encryption, so you need to have OpenSSL and a suitable certificate at hand. The article "Migrating a Mail Server to Postfix/Cyrus/OpenLDAP" in issue #124 shows you how to prepare Postfix for encryption. Your Postfix installation will therefore need Transport Layer Security (TLS) support. On Debian you can enable TLS by installing the postfix-tls package.

We will be speaking of two distinct components when dealing with email.

I will focus on using mutt as a MUA. The confusing advantage of mutt is that it submits the email to a MTA on the local machine for delivery.

Authentication Software

We need a source for the authentication information. The easiest way is to use the Simple Authentication and Security Layer (SASL) framework, which allows us to use a variety of sources through a single mechanism. The packages sasl2-bin and libsasl2-modules are needed for our purposes. sasl2-bin contains the utilities to maintain and query the user database with the passwords and is only needed on the MTA that should use SMTP Authentication. The libsasl2-modules are needed on both sides. Some MUAs already provide code for SASL authentication.


Now let's try to get everything to work together seamlessly.

Postfix as Inbound Mail Relay

Postfix will use the SASL Authentication daemon saslauthd in order to decide whether the authentication is correct or not. The query is done by using saslauthd's UNIX socket, usually found in /var/run/saslauthd/mux. This is a problem since Postfix runs in its own chroot environment, /var/spool/postfix/, and can't see the socket. You now have two options - give up Postfix's chroot or move saslauthd's socket to another place. Fortunately, the last option can be done easily by editing /etc/default/saslauthd:

# This needs to be uncommented before saslauthd will be run
# automatically

# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"

PARAMS="-m /var/spool/postfix/var/run/saslauthd"

We changed the MECHANISMS to the SASL database (we don't want to use system accounts for SMTP AUTH) and we moved the socket into Postfix' chroot by using the -m option. We still have to make sure that the path to the socket exists.

antigone:~# mkdir -p /var/spool/postfix/var/run/saslauthd

Now we can turn our attention to the Postfix configuration. It needs to be told that it should use SASL for authentication and what options it should accept. First, we create a directory and a file with the options:

antigone:~# mkdir /etc/postfix/sasl/
antigone:~# cat > /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
auxprop_plugin: sasldb
saslauthd_path: /var/run/saslauthd/mux

smtpd.conf tells Postfix to ask saslauthd's user database the path to the socket and the allowed authentication options. PLAIN and LOGIN are simple cleartext authentication methods. Leave them out in case your MTA doesn't support encryption. LOGIN is deprecated so you won't need it anyway; I just included it as example. CRAM-MD5 and DIGEST-MD5 based on challenge-response or digests respectively. Most modern MUAs know them, so it's good to allow them in this configuration.

The last thing you need to do is to add the authentication directives to the Postfix main config file /etc/postfix/main.cf:

smtpd_sasl_auth_enable      = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_application_name = smtpd
smtpd_sasl_local_domain     = $mydomain
broken_sasl_auth_clients    = no

The first line enables SASL AUTH. The security options define what to accept. It is very important to include noanonymous or else the authentication allows any mail relaying, which is not what you and I want. Be careful to double-check that noanonymous is present! The application name tells Postfix the name that should be used when initiating the SASL server. It corresponds to our file smtpd.conf, which contains the options we wish to use. The SASL local domain defines the realm that should be used as the authentication realm. Every user has a login, a realm, and a password. Usually the realm corresponds to the domain your server is part of. The last option deals with the special needs of some MUAs. Set this option to yes if a Microsoft Outlook Express Version 4 and Microsoft Exchange server Version 5.0 use your Postfix as authentication mail relay. Otherwise, it is safe to use no.

We still need to tell Postfix that authenticated clients are ok. You can configure this with the smtpd_recipient_restrictions directive.

smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/rcpt_blacklist,
    check_helo_access hash:/etc/postfix/helo,
    reject_rbl_client realtimeblacklist.example.net,
    check_policy_service inet:,

We added a permit_sasl_authenticated right before the blacklist and greylist check. Make sure you accept the authenticated connection as soon as possible, but don't skip important checks in case the MUA gets something wrong. The files rcpt_blacklist and helo are custom hash files with blacklisted addresses and faked name in the HELO/EHLO dialog. You can skip them if you don't have them yourself. The same is true for the real time blacklist. You don't have to use one.

We're almost done. We only need the account with username and password. You can add users by using the saslpasswd2 command.

antigone:~# saslpasswd2 -u your.realm username

The tool will prompt twice for the password. Now you are all set. Reload or restart saslauthd and Postfix. Make sure the UNIX socket in Postfix's chroot environment was created. Check with telnet for the SMTP AUTH banner.

lynx@agamemnon:~ $ telnet antigone.luchs.at 25
Connected to antigone.luchs.at.
Escape character is '^]'.
220 antigone.luchs.at ESMTP ready
EHLO client.example.net
250-SIZE 10380902
221 Bye
Connection closed by foreign host.
lynx@agamemnon:~ $ 

If everything works you should see the string 250-AUTH DIGEST-MD5 CRAM-MD5 after the HELO/EHLO command.

Postfix as Outbound Mail Relay with Authentication

Since I use mutt, the component that deals with SMTP is my local Postfix. It doesn't know about SMTP AUTH yet, but we only need two additional options in main.cf

smtp_sasl_auth_enable   = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

The first directive enables SMTP AUTH in Postfix's SMTP client component. The second dictates which username and password to use when talking to each server. A sample sasl_passwd map looks like this:

smtp.example.net        username:seckrit             username2:geheim

Don't forget to create the hash of the map by using postmap /etc/postfix/sasl_passwd. Now point your relayhost variable to one of the servers listed in sasl_passwd and reload the Postfix configuration. Mail relay should now be using SMTP AUTH. If the login fails, check for the presence of the libsasl2-modules package. Without it Postfix will try to use authentication, but will fail because no suitable authentication methods can be found.

One Word About Encryption

Although I didn't show how to configure encryption in this example, I strongly suggest using TLS with every MTA you run. The setup isn't too hard and having encrypted SMTP AUTH sessions is the best way to protect the passwords.

Useful Resources

This is one of many articles written about this topic. You can find more details here:

Talkback: Discuss this article with The Answer Gang

Bio picture

René was born in the year of Atari's founding and the release of the game Pong. Since his early youth he started taking things apart to see how they work. He couldn't even pass construction sites without looking for electrical wires that might seem interesting. The interest in computing began when his grandfather bought him a 4-bit microcontroller with 256 byte RAM and a 4096 byte operating system, forcing him to learn assembler before any other language.

After finishing school he went to university in order to study physics. He then collected experiences with a C64, a C128, two Amigas, DEC's Ultrix, OpenVMS and finally GNU/Linux on a PC in 1997. He is using Linux since this day and still likes to take things apart und put them together again. Freedom of tinkering brought him close to the Free Software movement, where he puts some effort into the right to understand how things work. He is also involved with civil liberty groups focusing on digital rights.

Since 1999 he is offering his skills as a freelancer. His main activities include system/network administration, scripting and consulting. In 2001 he started to give lectures on computer security at the Technikum Wien. Apart from staring into computer monitors, inspecting hardware and talking to network equipment he is fond of scuba diving, writing, or photographing with his digital camera. He would like to have a go at storytelling and roleplaying again as soon as he finds some more spare time on his backup devices.

Copyright © 2007, René Pfeiffer. Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 142 of Linux Gazette, September 2007