SMTP Authentication with Postfix
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:
- Negotiating an SMTP AUTH Authentication Mechanism
- Simple Authentication and Security Layer (SASL)
- SMTP Authentication for Mail servers
- Testing SMTP AUTH connections
- Using SMTP AUTH and STARTTLS with sendmail
Talkback: Discuss this article with The Answer Gang
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.
