SMTP Authentication with Postfix

Oct 22

Taken From LinuxGazette.com Issue #142

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.

Prerequisites

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.

Mail User Agent (MUA)
This is the program for reading, writing and sending email. Typical MUAs are Mozilla Thunderbird/Icedove, mutt, Sylpheed, Evolution, KMail, and Pine. Some MUAs speak Simple Mail Transfer Protocol (SMTP), some don’t and submit the mail to a local program for relaying. MUAs are mail clients.
Mail Transport Agent (MTA)
This is the software also known as a mail server. MTAs relay mail to other mail servers by using SMTP/ESMTP. Any mail destined for local users will be dispatched to a local mailbox by means of the Local Delivery Agent (LDA). Typical MTAs include Exim, Postfix, Sendmail, and qmail.

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.

Configuration

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
START=yes

# 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"

MECHANISMS="sasldb"
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
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
^D
antigone:~#

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 =
    permit_mynetworks,
    reject_unlisted_recipient,
    check_recipient_access hash:/etc/postfix/rcpt_blacklist,
    check_helo_access hash:/etc/postfix/helo,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client realtimeblacklist.example.net,
    check_policy_service inet:127.0.0.1:60000,
    permit

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
Trying 127.0.0.1...
Connected to antigone.luchs.at.
Escape character is '^]'.
220 antigone.luchs.at ESMTP ready
EHLO client.example.net
250-antigone.luchs.at
250-PIPELINING
250-SIZE 10380902
250-ETRN
250-STARTTLS
250-AUTH DIGEST-MD5 CRAM-MD5
250 8BITMIME
QUIT
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
192.168.1.1             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:

Popularity: 18% [?]

M. Fahrizal Rahman Blog