email - Howto smtp auth with Postfix
Howto smtp auth with Postfix
2004-04-23 15:18 pm来自：Linux文档
现载：Www.8s8s.coM
地址：无名
Howto smtp auth with Postfix(1)
Introduction
What's the problem?
If you want to relay messages from everywhere in the world using only one (your) smtp server you usually run into trouble. The servers relay permissions check your IP if it belongs to a trusted network (e.g. a range of IP Adresses). From the smtp servers point of view you try to send from an untrusted network when you dial-up.
This HOWTO will help you deploy a method that is called smtp auth in conjunction with Postfix. It will explain installation, configuration and use of the softwares needed (Cyrus-SASL, TLS and Postfix) for this solution. Before you decide on using this method, read if you can do with less.
What are the approaches to fix this issue?
Add ip manually
Each time a user wants to relay from an IP Adress unknown to the system, she adds the IP to the relay net, restarts the smtp server and sends her mail. After messaging is done she removes the IP and restarts the smtp server once more.
This is by far the most insecure solution. Though possible, you would have to permit shell access to users and teach them how to deal with the system. It won't work for those who focus on the computing and not the computer...
smtp-after-pop (pop-before-smtp)
A service/script runs on the smtp server that will add IPs of users that have successfully authenticated to their pop3 or imap server. The service/script will write the IP of those users to a file or database. Since they are valid users to the pop/imap server they must also be valid users to the smtp server. When they send messages after the pop/imap the smtp server also looks up the file or database that the pop/imap server has written to and if the IP is found in there the client may relay messages. After a certain period the IP expires and is removed from the file/database.
This will not work easily with common Mailclients, as not all of them come with built-in support for smtp-after-pop. There are workrounds on the net, but solution may require expensive configuration and/or constant support.
smtp auth
This approach uses a totally different, IP independend method. Instead of checking the IP of the Mailclient and comparing it to a range of permitted IP Adresses, the Mailclient authenticates itself providing username and password to the mailserver (or sharing a secret with it). These credentials are compared to a source that the mailserver has access to and if valid data has been provided, the mailserver will permit relaying.
This HOWTO will help you to enable Postfix to provide smtp auth using Cyrus-SASL. Read about the benefits of using smtp auth and how smtp auth is beeing processed before you will find out what steps you will have to go to deploy your specific smtp auth solution.
Howto smtp auth with Postfix(2)
(52 阅读)
Benefits of using smtp auth
Authentication for Mailclients
Mobile Users
1. Using smtp auth we can make it possible for clients, colleagues, and ourselves to relay messages from everywhere in the world using only one (our) smtp server.
2. Being mobile then we don't have to deal with the hassle to find a smtp server that permits us to relay.
3. Once set up, we do not have to give extra support to others to reconfigure their mailclients properly.
4. We can make use of scripts and daemons that run on our server and provide services that we need e.g. server-side virus scanning.
Corporate Network
Imagine all users are allowed to send messages to users in the local network, but only a few should be permitted to send messages to remote users. If you check by IP the "forbidden users" simply have to use a machine with a valid IP. This is where smtp auth can also help you as it checks for users and not IP. You then only provide smtp auth accounts for those who may relay outbound messages and configure Postfix to reject other senders.
Authentication for Mailservers (e.g. Dial-Up smtp, Corporate Networks)
1. We can enable our smtp server to authenticate itself with other smtp servers.
2. We might use this when our ISP requires us to authenticate our (dial-up) smtp server or even connect several (dial-up) company locations to each other in order to provide safe and explicit messaging.
3. Finally we can add an extra layer of security to encrypted communication (TLS).
You want that? Understand the process of smtp auth first, before you install and configure. It will save lot's of time when you need to trace down a malfunction. You will know where things go wrong and be able to concentrate on that only.
Howto smtp auth with Postfix(3)
(31 阅读)
How smtp auth is processed
Authentication for Mailclients
1. A Mailclient, configured to use smtp auth, connects to its smtp server.
2. The smtp server responds and offers one or more mechanisms for authentication.
3. The Mailclient chooses a mechanism and submits data for authentication.
4. The Mailclient's data is verified by the authentication service.
5. The authentication service submits the result (valid user/invalid user) of the verification to the smtp server.
6. If the Mailclient is a valid user the smtp server will receive message data otherwise it will end the connection.
Authentication for Mailservers
1. A local smtp server wants to relay messages to a remote smtp server. It connects to the remote server.
2. The remote smtp server responds and offers smtp auth (one or more mechanisms for authentication) to the local server
3. The local smtp server looks up for preconfigured information that will tell username and password for the remote server
4. It submits the given data for authentication
5. The transmitted data is verified by the remote authentication service. It then submits the result (valid user/invalid user) of the verification to the remote smtp server
6. If the local smtp server is a valid user the smtp server will allow the messages to be relayed; otherwise it will end the connection.
Now that we have split Authentication for Mailclients from Authentication for Mailservers, find out next what you will need to install and configure to get each of them running. Nonetheless important you should read and understand the job of Cyrus-SASL in smtp auth and which methods and mechanisms to choose from that software to suite your needs best.
Howto smtp auth with Postfix(4)
(26 阅读)
What do you need to offer smtp auth in Postfix?
Authentication for Mailclients
You want Postfix to authenticate incomming connections from Mailclients?
You have to go through the following steps:
1. install Cyrus-SASL
2. configure Cyrus-SASL
3. configure Postfix source-code with Cyrus-SASL support
4. build Postfix
5. (re)install Postfix
6. configure Postfix to use the SASL smtpd features
Mechanism Plain and/or Login
If you want Postfix to authenticate incomming connections from Mailclients and offer the mechanism PLAIN and/or LOGIN we strongly recommend that you also add the use of TLS to your solution.
You have to go through the following steps:
1. install Cyrus-SASL
2. configure Cyrus-SASL
3. patch Postfix source-code to add TLS support
4. configure Postfix source-code with Cyrus-SASL and TLS support
5. (re)install Postfix
6. configure Postfix to use the SASL smtpd features
7. configure Postfix to use TLS smtpd features
Authentication for Mailservers
You want Postfix to authenticate itself to other Mailservers?
You have to go through the following steps:
1. install Cyrus-SASL
2. configure Cyrus-SASL
3. configure Postfix source-code with Cyrus-SASL support
4. build Postfix
5. (re)install Postfix
6. configure Postfix to use the SASL smtp features
Mechanism Plain and/or Login
If the other Mailserver only offers the mechanism PLAIN to Postfix, but also offers TLS, we strongly recommend that you also add the use of TLS to your solution.
You have to go through the following steps:
1. install Cyrus-SASL
2. configure Cyrus-SASL
3. patch Postfix source code to add TLS support
4. configure Postfix source-code with Cyrus-SASL and TLS support
5. (re)install Postfix
6. configure Postfix to use the SASL smtpd features
7. configure Postfix to use TLS smtpd features
Howto smtp auth with Postfix(5)
(22 阅读)
Authentication service or what is Cyrus-SASL?
Cyrus-SASL is a software that provides different methods and mechanisms of authentication. This software is often used in conjunction with Cyrus IMAP Server and is provided as standalone software. SASLs concept, the Simple Authentication and Security Layer, is written down in RFC 2222.
This HOWTO will focus on the Cyrus-SASL version only.
Methods to provide the authentication service
Cyrus-SASL may use various methods to connect to a source that holds user and password data. By nature Cyrus-SASL is capable to connect to PAM and sasldb. However there are situations where this approach runs short:
Permissions
To authenticate via PAM from passwd/shadow requires root priviledges. Any daemon (here: Postfix) that uses SASL which is not run as root, will therefore not be permitted to query passwd/shadow. Some systems solve this by adding the SASL-user to a special group that is permitted to read from passwd/shadow. Is that good? Well consider running Postfix chrooted and having to copy your passwd/shadow files to the jail. Huh? Yes, you'd have to do that and that would make the idea running a chrooted Postfix to keep malicious users from your valuable password useless. You'd be at the start again... read on as there is a solution to this!
user:pass sources
There are situations where you don't want to use PAM or sasldb, because you want to have all the mailusers separated from machines users or have them on a different machine or you run a central auth service for single sign on and so on...
For both scenarios you may configure SASL to use a deamon that will run as root and can connect to various backends e.g. a LDAP or SQL database.
Note:
Cyrus-SASL daemons don't support LDAP and e.g. MySQL from source. However there are patches available on the net that will give you those functionalities. You will have to patch Cyrus-SASL, recompile and install it, before these functionalities will be available to SASL.
You may use different methods to provide authentication service with Cyrus-SASL.
Daemons
Cyrus-SASL comes with two daemons that may run on your mailserver: pwcheck and saslauthd. Basically they are pretty much the same. The newer daemon saslauthd (since Cyrus-SASL 1.5.27) is said to be based on the code of the former pwcheck. Anyway saslauthd goes beyond the functionality of pwcheck and pwcheck will be dropped in the future. So we will have a look at the newer daemon in this HOWTO.
LDAP and SQL authentication
If you want to authenticate your mailusers against an LDAP or SQL server you might want to go for the pwcheck daemon. There might be more patches available for this at the moment.
Which method can you use in Postfix?
You can use all of them, but note: If you use PAM, saslauthd or pwcheck you only have the mechanisms PLAIN and LOGIN at your command.
Mechanisms for Authentication
Cyrus-SASL offers various mechanisms to clients that seek authentication.
ANONYMOUS
Authentication data is transmitted plaintext. Anyone can authenticate to the system. This mechanism is of no use in our context as it would result in making our smtp server an open relay!
PLAIN
If you use PLAIN data is transmitted plaintext. The mechanism is simple and it works well, but imposes a security risk if used without encrypted communication layer!
Used without encryption anyone can read the autentication data as it is transmitted plaintext. Anyone running a sniffer (e.g. snort, tcpdump) could read the secrets.
The solution is to use the TLS-Patch (Transport Layer Security, formerly: SSL) as provided by Lutz J?nicke to Postfix. We believe this to be mandatory when using mechanism PLAIN and will also provide information on how to install and configure TLS-Support in this HOWTO.
LOGIN
Authentication data is transmitted plaintext. LOGIN imposes the same security risk as described in PLAIN. The same solution applies if you want to get rid of the problem.
The LOGIN mechanism exists parallel with PLAIN, simply because there are Mailclients (e.g. Outlook Express, Outlook) that do not implement the RFC-standard when seeking authentication. Cyrus-SASL supports LOGIN, but there is no support to users by the makers of Cyrus-SASL.
DIGEST-MD5
RFC 2831
You can use this mechanism without TLS.
CRAM-MD5
"It is conjectured that use of the CRAM authentication mechanism provides origin identification and replay protection for a session. Accordingly, a server that implements both a cleartext password command and this authentication type should not allow both methods of access for a given user." (from: RFC 2195, 4 Security Considerations)
You can use this mechanism without TLS.
GSSAPI (MIT Kerberos 5 oder Heimdal Kerberos 5)
You can use this mechanism without TLS.
KERBEROS_V4
You can use this mechanism without TLS.
Concerns on cyrus-SASLs SASL implementation
The SASL concept as described in the RFC is a good idea. Yet at the moment Cyrus-SASL lacks sufficient documentation and does not provide meaningful error messages.
Therefore it becomes a black-box to those who lack programming skills and simply would take look at the code to understand what's going on or wrong. Environments with high-security standards consider these issues as disqualifying criteria for use of software.
As for the documentation this HOWTO aims to provide you with the knowledge needed to install, configure and run Cyrus-SASL in combination with Postfix.
Note
The Cryptix SASL Library is the second SASL library known at the moment. It runs with JAVA, but isn't supported by Postfix.
While writing this HOWTO cabalSASL has become the next competitor to Cyrus-SASL. Read more at the official cabalSASL Homepage.
Howto smtp auth with Postfix(6)
(23 阅读)
Building RPMS from SOURCE or SRPMS
If you haven't done so before: It is easy to build or rebuild RPMS from SRPMS. Let's get a quick overview how we build RPMS in our HOWTO.
Build as non-root user
We never build RPMS as root. So we log into our machine as a regular user. Then we create a mirror image of the main RPM directory structure in our HOMEDIR and tell RPM to use these directories instead of the original ones.
Step1: Create RPM directories
RPM needs a certain directory structure to build RPMS from SOURCE or from SRPMS. When we build them as non-root user, we cannot use the default location because only root is allowed to write to those directories. So we create the same directory structure in our regular users $HOME-directory:
[[email protected]]# mkdir $HOME/rpm $HOME/rpm/SOURCES $HOME/rpm/SPECS $HOME/rpm/BUILD $HOME/rpm/SRPMS $HOME/rpm/RPMS $HOME/rpm/RPMS/i386
When we are done with this, the directory tree of the new rpm directory in our $HOME-directory should look like that:
rpm
|-- BUILD
|-- RPMS
| `-- i386
|-- SOURCES
|-- SPECS
`-- SRPMS
Step2: Set environment variables
Now we need to tell the RPM-Manager that the non-root user wants this location to build RPMS instead of the default location.
[[email protected]]# echo "%_topdir $HOME/rpm" >> $HOME/.rpmmacros
Note:
You will have to set the environment every time you log in and out as the user who build the RPMS.
If you want to dig deeper into building RPMS you can find excellent information in the Maximum RPM HOWTO at rpm.org.
That's it, you are ready to build RPMS.
Howto smtp auth with Postfix(7)
(19 阅读)
Cyrus-SASL Installation from SRPMS provided by Tuomo Soini
Tuomo Soini currently provides RPMs for Cyrus-SASL and for Postfix. He constructed the RPMs so that they fit together well, which means that when you install both of his RPMs you will be half the way through on your way to a nicely working version of Cyrus-SASL and Postfix.
Tuomos RPMs are SOURCE RPMs. This means that they have to be compiled before we can install them. But before we do this, we'll have to download them.
Step 1: Download the SRPMS
Point you Browser to http://tis.foobar.fi/software/ and download the current versions of Cyrus-SASL and Postfix (if you want to use the Postfix SRPM also) to your future smtp-server.
Note:
By the time of writing this HOWTO current versions of Cyrus-SASL and Postfix are:
cyrus-sasl-1.5.27-t22.src.rpm
postfix-1.1.7-t4.src.rpm
We'll be using these throughout this HOWTO.
New to RPM?
Source RPMs (or SRPMS) do not contain the ready-to-run binaries, but merly the sourcecode that still needs to be compiled. So we will compile the SRPMS first and install the RPM that we built afterwards. If you want to know more about RPM read this RPM HOWTO.
Step 2: Install SRPMS for compilation
First we have to install the SRPMS into the RPM framework. Before you do that, please read this tiny Building RPMS and consider to follow the concept.
Login and cd to the directory where you put the two RPMs. Then install the two RPMs:
[[email protected]]# rpm -ivh cyrus-sasl-1.5.27-t22.src.rpm
Now the source.rpms are installed. Our next step is to configure and build them.
Step 3: Configure and build RPM from SRPM
In Order to configure our RPMs whe need to add some changes to the specification files. We change to the location the RedHat Package Manager has put it to:
[[email protected]]# cd /usr/src/redhat/SPECS/
Remember: Postfix needs the SASL libraries when at compilation time. So we have to compile and install Cyrus-SASL first and turn to build Postfix only then.
Step 4: Build Cyrus-SASL
Cyrus-SASL builds nicely the way it is and we do not need to pass any extra configuration options. All we have to do, is build it:
[[email protected]]# rpmbuild -ba cyrus-sasl.spec
Step 5: Check for existing Cyrus-SASL
You should check if you already have an existing version on your machine. It doesn't matter if you already have an existing version of cyrus-sasl installed, as we are going to install Tuomos Version anyway. All we need to know is if we have to install a complete new cyrus-sasl or if we 'only' need to update the existing one.
This is how we check. We query the RPM Database to tell us if there is a Cyrus-SASL RPM installed:
[[email protected]]# rpm -q cyrus-sasl
If it reads
[[email protected]]# package cyrus-sasl is not installed
go to Install Cyrus-SASL otherwise if the output is
[[email protected]]# cyrus-sasl-XX
else proceed with Update Cyrus-SASL.
Step 6: Cyrus-SASL installation
Step 6.1: Install Cyrus-SASL
Change to the directory where the now completed and compiled Cyrus-SASL RPM was dropped by the RPM Build.
[[email protected]]# cd $HOME/rpm/RPMS/i386
Let's see what we have:
[[email protected]]# ls cyr*
cyrus-sasl-1.5.27-t22.i386.rpm
cyrus-sasl-authd-1.5.27-t22.i386.rpm
cyrus-sasl-devel-1.5.27-t22.i386.rpm
cyrus-sasl-gssapi-1.5.27-t22.i386.rpm
cyrus-sasl-md5-1.5.27-t22.i386.rpm
cyrus-sasl-plain-1.5.27-t22.i386.rpm
We need at least the following RPMs installed in order to make Cyrus-SASL and Postfix work and Postfix get what it needs to when it has to compile with SASL support:
cyrus-sasl-1.5.27-t22.i386.rpm
cyrus-sasl-authd-1.5.27-t22.i386.rpm
cyrus-sasl-devel-1.5.27-t22.i386.rpm
Then you have to choose at least on of the following mechanisms to use when authenticating users:
cyrus-sasl-gssapi-1.5.27-t22.i386.rpm
cyrus-sasl-md5-1.5.27-t22.i386.rpm
cyrus-sasl-plain-1.5.27-t22.i386.rpm
In this HOWTO we are going to install all of them. We su to root and type:
[[email protected]]# rpm -ivh cyrus-sasl-*
That's it for now. We leave Cyrus-SASL the way it is and will build and install Postfix before we will return to configure SASL. Your next Step is Step 7.
Step 6.2: Update Cyrus-SASL
Let's see what we have:
[[email protected]]# ls cyr*
cyrus-sasl-1.5.27-t22.i386.rpm
cyrus-sasl-authd-1.5.27-t22.i386.rpm
cyrus-sasl-devel-1.5.27-t22.i386.rpm
cyrus-sasl-gssapi-1.5.27-t22.i386.rpm
cyrus-sasl-md5-1.5.27-t22.i386.rpm
cyrus-sasl-plain-1.5.27-t22.i386.rpm
We need at least the following RPMs installed in order to make Cyrus-SASL and Postfix work and Postfix get what it needs to when it has to compile with SASL support:
cyrus-sasl-1.5.27-t22.i386.rpm
cyrus-sasl-authd-1.5.27-t22.i386.rpm
cyrus-sasl-devel-1.5.27-t22.i386.rpm
Then you have to choose at least on of the following mechanisms to use when authenticating users:
cyrus-sasl-gssapi-1.5.27-t22.i386.rpm
cyrus-sasl-md5-1.5.27-t22.i386.rpm
cyrus-sasl-plain-1.5.27-t22.i386.rpm
In this HOWTO we are going to update and install the missing ones. We su to root and type:
[[email protected]]# rpm -Uvh cyrus-sasl-*
Before you go and get some fresh coffee, let's wrap things up to now up.
Summary: Cyrus-SASL SRPM installation
Tuomos Cyrus-SASL RPM did the following when we installed it:
Cyrus-SASL
* install cyrus-sasl binaries and libraries
* install Cyrus-SASL mechanisms
* add an init-script /etc/init.d/saslauthd to start the saslauthd required by the latter /usr/lib/sasl/smtpd.conf
* add a /etc/pam.d/cyrus file, which will be used by the saslauthd to connect to PAM.
That's it for now. We leave Cyrus-SASL the way it is and will build and install Postfix before we will return to configure SASL.
Howto smtp auth with Postfix(8)
(24 阅读)
Postfix Installation from SRPMS provided by Tuomo Soini
Tuomo Soini currently provides RPMs for Cyrus-SASL and for Postfix. He constructed the RPMs so that they fit together well, which means that when you install both of his RPMs you will be half the way through on your way to a nicely working version of Cyrus-SASL and Postfix.
Tuomos RPMs are SOURCE RPMs. This means that they have to be compiled before we can install them. But before we do this, we'll have to download them.
New to RPM?
Source RPMs (or SRPMS) do not contain the ready-to-run binaries, but merly the sourcecode that still needs to be compiled. So we will compile the SRPMS first and install the RPM that we built afterwards. If you want to know more about RPM read this RPM HOWTO.
Step 1: Download the SRPMS
Point you Browser to http://tis.foobar.fi/software/ and download the current version of the Postfix SRPM to your future smtp-server.
Note:
By the time of writing this HOWTO current versions of Cyrus-SASL and Postfix are:
cyrus-sasl-1.5.27-t22.src.rpm
postfix-1.1.7-t4.src.rpm
We'll be using these throughout this HOWTO.
Step 2: Install SRPMS for compilation
First we have to install the SRPMS into the RPM framework. Before you do that, please read this tiny Building RPMS and consider to follow the concept.
Login and cd to the directory where you put the SRPM and install it with:
[[email protected]]# rpm -ivh postfix-1.1.7-t4.src.rpm
Now the SRPM is installed. Our next step is to configure and build it.
Step 3: Configure and build Postfix-RPM from -SRPM
First we change to the SPECS directory of our RPM framework:
[[email protected]]# cd rpm/SPECS/
Remember
Postfix needs the SASL libraries at compilation time. If you don't have Cyrus-SASL installed yet, your Postfix build will fail. To get a working SASL either install from Cyrus-SASL SRPM or from Cyrus-SASL SOURCE.
Tuomo's Version of Postfix comes with support for many additional features. You can trigger enabling or disabling them when you build the RPM. All you need to do is add --with FEATURE or --without FEATURE to the command line. We want SASL and TLS for this HOWTO and will not add anything else. If you want more features you either add them to the following statement or rebuild and reinstall Postfix later once you have smtp auth up and running. So let's find out what is in the SRPM to help you decide.
In order to get to know the features that come with the SRPM you use the following command:
[[email protected]]# rpm -qpil postfix-1.1.7-t4.src.rpm
We build the RPM as follows:
[[email protected]]# rpmbuild -ba --without ldap --without pgsql --without mysql postfix.spec
In case that the RPM Manager complains about missing dependencies you decide on your own if you need to install them first or just tell the RPM Manager to build --without. If everything runs through we've successfully configured and built our customized Postfix RPM.
Step 4: Remove Sendmail
RedHat Linux comes with Sendmail preinstalled. Since we want to use Postfix instead, we first will have to remove the sendmail RPM. If we only issue rpm -e sendmail the RedHat Package Manager will complain that there are many other applications that need Sendmails functionality.
Right, but we want Postfix to take over and Postfix will provide binaries that will mend what we will break. So we override the RedHat Package Manager's complaints and advise it, not to check for dependencies when ordered to erase existing Sendmail RPM. Since not every user is allowed to install and uninstall software we su to root first.
[[email protected]]# rpm -e --nodeps sendmail
So Sendmail has just left the building. In comes Postfix...
Step 5: Install Postfix
To install the Postfix RPM we go back to the directory where our newly built RPMs have been put by the RedHat Package Manager:
[[email protected]]# cd ~rpm_user/rpm/RPMS
[[email protected]]# rpm -ivh postfix-1.1.7-t4.i386.rpm postfix-utils-1.1.7-t4.i386.rpm
Note
The postfix-utils-1.1.7-t4.i386.rpm installs a few utilities e.g. a perl script that summarizes the daily mailtraffic and prints out a lot of other useful information. It will be called by a cron-job and the output will be mailed to postmaster@localhost.
That's it for the installation. If everything wen't fine you've successfully installed Postfix from RPM.
Before you go and get some fresh coffee, let's wrap things up to now up.
Summary
Tuomos Postfix RPM did the following when you installed it:
Postfix
* install Postfix binaries and helper applications
* install the configuration files to /etc/postfix/
* install the samples and LICENSE to /etc/postfix/samples/
* install documentation (man, html)
* add a smtpd.conf file to /usr/lib/sasl
This file tells sasl how we want to authenticate smtpd queries for authentication. By default it is set to 'pwcheck_method:saslauthd', which means that it we want to use the saslauth deamon. If you want to use sasldb stick with this HOWTO. We will enquire this as we get to know our way around configuring Cyrus-SASL
* install /etc/cron.daily/postfix.cron a cron file that is run on a daily basis. It rebuilds your .db files and copies changed files to the chroot-dir even if you don't have that configuration enabled.
* additionally if you installed: postfix-utils-1.1.7-t4.i386.rpm
install /usr/sbin/pflogsumm.pl a perl-script that will mail you daily stats, if you add this script 1postfix to /etc/cron.daily and chmod 755 1postfix and chown root:root 1postfix the file.
OK. Now take a break. The upcomming configuration will need your full attention again... ;-)
Howto smtp auth with Postfix(9)
(20 阅读)
Cyrus-SASL configuration (saslauthd)
You installed SASL from Tuomos RPM?
There's nothing to be configured at the moment. Tuomos Cyrus-SASL and Postfix RPMs took care of the most basic needs, when they added a few extra files and directories.
All we need for the moment is to start the saslauthd.
[[email protected]]# /etc/init.d/saslauthd start
Howto smtp auth with Postfix(10)
(34 阅读)
Basic Postfix configuration and preparation for smtp auth
Before we proceed to our part of the configuration we must disable a feature that was set when Tuomos Postfix RPM was installed. Remember it comes built with support for the Cyrus-IMAP Server? We're not going to use the Cyrus-IMAP Server in this HOWTO. So let's disable this setting, as we don't want it to interfere with our setup at the moment.
Edit main.cf
Postfix main configuration is done in the /etc/postfix/main.cf. Use your favorite editor to edit the file. We are going to use vi throughout this HOWTO.
[[email protected]]# vi /etc/postfix/main.cf
Step 1: Disable Cyrus-IMAP setting
We will not need mailbox_transport = lmtp:unix:/var/imap/socket/lmtp because this is a setting that applies not only but especially for Cyrus-IMAP server which we will not be using. Find the line that reads mailbox_transport = lmtp:unix:/var/imap/socket/lmtp and disable it. When you are done it should read as follows:
#mailbox_transport = lmtp:unix:/file/name
#mailbox_transport = cyrus
#mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
Step 2: Parameters specific to your environment
Now it's time to grab some good old paper and a pencil. You will need these infos that are specific to your domain and network later. But then you should be able to focus on incorporating these.
Question 1: What is the primary domain (or machine) that Postfix will be authoritative for?
The mydomain parameter specifies the local internet domain name.. If you don't run a DNS server or don't have access to one provide a domain name. We will use example.com throughout this HOWTO as this domain is reserved for use in documentation.
When we set this value we will add it to the parameter mydomain in main.cf.
Question 2: What is the hostname of the machine that Postfix runs on?
The myhostname parameter specifies the internet hostname of this mail system. Postfix needs to know its fully qualified domainname (FQDN). It will append this to all local users unless specified different by us.
When we set this value we will add it to the parameter myhostname in main.cf.
Question 3: What is the IP-Range of the Net that your (remote) machine stands in?
We need this to tell Postfix that the IP that your Mailclient (for testing purposes) comes from is allowed to use Postfix as a relay.
When we set this parameter, we'll set mynetworks in main.cf.
Question 4: What is the IP-adress of the server that Postfix will run on?
Important
These are the parameters that will be used in the HOWTO. You will have to provide your own.
Q1: example.com
Q2: mail.example.com
Q3: 172.16.0.0/24
Q4: 172.16.0.2
Step 3: Enable your Parameters
Now that you have put your parameters down, we'll edit main.cf and put them into place.
[[email protected]]# vi /etc/postfix/main.cf
mydomain
Search for mydomain = and you'll find #mydomain = domain.name
We uncomment the line and set the value we defined in Q1. The mydomain parameter of this HOWTO now reads as follows:
[HOWTO SETTING] mydomain = example.com
myhostname
Search for myhostname = and you'll find #myhostname = host.domain.name
We uncomment the line and set the value we defined in Q2. The myhostname parameter of this HOWTO now reads as follows:
[HOWTO SETTING] myhostname = mail.example.com
mynetworks
Search for mynetworks = and you'll find #mynetworks = 168.100.189.0/28, 127.0.0.0/8 and two more entries for mynetworks. We'll be using the style of the first one.
We uncomment the line and add the value we defined in Q2 and remove 168.100.189.0/28. The mynetworks parameter of this HOWTO now reads as follows:
[HOWTO SETTING] mynetworks = 172.16.0.0/24, 127.0.0.0/8
Step 4: Enable common parameters
Remember that we disabled a few lines that came with the RPM? We will now set these in their context. It's not that Postfix needs the parameters in a certain order. It just makes it easier for us humans to find them where they belong ;-)
Note:
Tuomo fixed that in his recent SRPMS. Still you will have to enable these.
alias_maps
Search for alias_maps = and you'll find #alias_maps = dbm:/etc/aliases and three more lines that offer different values.
We uncomment the second line and set the value to hash:/etc/postfix/aliases. Our alias_maps parameter now reads as follows:
alias_maps = hash:/etc/postfix/aliases
alias_database
Search for alias_database = and you'll find #alias_database = dbm:/etc/aliases and three more lines that offer different values.
We uncomment the third line and set the value to hash:/etc/postfix/aliases. Our alias_database parameter now reads as follows:
alias_database = hash:/etc/postfix/aliases
That's it for a start. We're still away from having a sophisticated smtp server that saves us a lot of work and is a real pain to spammers, but we're very close to fire up Postfix and send our first message.
Step 5: Enable verbose logging
Postfix doesn't want to bother us with information into detailed depth unless we ask it to. Since we are still setting Postfix up and testing functions we might run into problems while doing that. So we'll have Postfix being more detailed about what's going on when it gets its work done. This will save us lot of time when we look for errors!
In order to enable verbose logging we have to append a string that is passed to the smtpd when it is started. This is done in /etc/postfix/master.cf.
[[email protected]]# vi /etc/postfix/master.cf
search for smtpd and append -v.
When your done it should look like this:
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
# ==========================================================================
smtp inet n - n - - smtpd -v
That's it for our first basic setup. Postfix should now be configured to accept messages from the local machine and from any machine who's IP matches the IP Range you specified when you answered Q3.
Step 6: Add user for testmails
We'll be sending quite some mail in this HOWTO. But to whom? We need a valid user on the local machine!
[[email protected]]# adduser test
[[email protected]]# passwd test
This HOWTO sends mail to the user test. It's password is testpass.
Feel free to add your own user, but remind that you'll have to replace our values with yours throughout this HOWTO.
Step 7: Start Postfix
Now it's time to start Postfix for the first time:
[[email protected]]# /etc/init.d/postfix start
You can tell it's up from the feedback the init-script provides; but will the Postfix-Server die after a few seconds because something is wrong?
Let's check the process list and pipe it's output to grep which will grab for the string postfix in the output.
[[email protected]]# ps axf | grep postfix
7547 ? S 0:00 /usr/libexec/postfix/master
Still there. OK, time to send our first mail. If it's gone check /var/log/maillog for error messages.
Step 8: Send Testmail from local machine
First we will verify that we are able to send mail on localhost to user test. This is the simpliest testcase that we have. If we succeed we will move on sending mails to test from a Mailclient that does not run on our Postfix server.
[[email protected]]# mail test
Subject: Test from localhost
Test #1
.
Cc:
[[email protected]]#
Note:
In case you are not familiar with the programm mail.
Enter the name of the account that you want to mail to after you've entered mail
Then your're prompted to enter the Subject.
After this you may add the Body of your mail.
You end your mail and send it away after entering a single dot '.' on a blank line and hitting enter.
Step 9: Check for delivery of Testmail on local machine
Did Postfix deliver our mail? We'll check by simply letting less open the file in /var/spool/mail for the user test.
[[email protected]]# less /var/spool/mail/test
From [email protected] Fri Mar 15 21:09:54 2002
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: by mail.example.com (Postfix, from userid 0)
id 029E640789; Fri, 15 Mar 2002 21:09:53 +0100 (CET)
To: [email protected]
Subject: Test from localhost
Message-Id: <[email protected]>
Date: Fri, 15 Mar 2002 21:09:53 +0100 (CET)
From: [email protected] (root)
Test #1
So it got delivered. Good. Let's go on to send some mail from another host.
Step 10: Sending testmail from a remote host to a local user
The simpliest Mailclient we can think of is a telnet client that connects to the smtp port 25. We'll be doing it the hard way, because we want to exclude sideeffects that might be introduced by other, more comfortable Mailclients.
Look at the paper where you answered a few questions. It's time for Q4. We use 172.16.0.2 for our Postfix server. You'll have to replace this IP with yours in the following statement.
First we will see if we can deliver mail to a local user. On your remote machine we telnet 172.16.0.2 25.
Postfix comes up and greets us with it's smtpd banner:
220 mail.example.com ESMTP Postfix
We say hello and introduce ourselves:
EHLO domain.com
Postfix offers it's services:
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XVERP
250 8BITMIME
We tell where this testmail is comming from:
mail from:<[email protected]>
Postfix responds:
250 Ok
We tell Postfix where this mail is going to:
rcpt to:<[email protected]>
Postfix responds:
250 Ok
We tell Postfix that we'll be sending data
data
Postfix responds:
354 End data with <CR><LF>.<CR><LF>
We write our message
Test from remote host
Test #2
.
Postfix responds:
250 Ok: queued as 9BB3F40789
Good. The mail got delivered. Time to end this session.
quit
Postfix responds:
221 Bye
So, we have just send our first mail from a remote host to a local user on the Postfix-server. But what if we wanted Postfix not do deliver to a local user, but to relay the message for us to another user on a remote host?
Step 11: Delivering Mail to a remote user (Relaying)
Again we telnet 172.16.0.2 25. We'll do as before with the only difference that this time we send to a remote (aka non-local) user. Since you've seen the principle in Step 10 we'll just summarize this session (S: = server, C: = client):
S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-XVERP
S: 250 8BITMIME
C: mail from:<[email protected]>
S: 250 Ok
C: rcpt to:<[email protected]>
S: 250 Ok
C: data
S: 354 End data with <CR><LF>.<CR><LF>
C: Testmail relaying mail from [email protected] to [email protected]
C: Test #3
C: .
S: 250 Ok: queued as 84BA64078A
C: quit
S: 221 Bye
Now it's up to you to send mail to a remote user through the Postfix server. But behold, don't close your telnet-program after the session. You'll need some of the information that was specific to your session in a few paragraphs from now.
Why did relaying work for us?
We were able to relay a message using Postfix, because Postfix knows the remote machine is part of the network (see: mynetworks) that it permits relaying.
Before we will configure smtp auth there's something that we have to take care of...
Step 12: Deleting Mail that can't get delivered
Remember that we've just sent a mail to [email protected]. Since the Postfix server in our HOWTO is not connected to the real world it hardly will be able to deliver the message. So what is Postfix doing with the mail at the moment? It's still trying, holding the mail in the queue...
Time to learn something about a helper application that comes with Postfix which is used to remove mails from Postfix's mqueue: postsuper
When you delete a mail it goes like this: postsuper -d MESSAGEID
Every message has it's unique ID provided by Postfix when it accepts a message. This MESSAGEID was given to us, when we did our telnet session. Have a look at the second last message that Postfix gave us in the HOWTO before we quit the session.
250 Ok: queued as 84BA64078A
84BA64078A is our HOWTOS MESSAGEID.
Look at your telnet program. What is your MESSAGEID?
At the command prompt enter:
[[email protected]]# postsuper -d MESSAGEID
postsuper: MESSAGEID: removed
postsuper: Deleted: 1 message
[[email protected]]#
We removed the undeliverable mail. Postfix should feel better now... ;-)
Step 13: Preparing relay permissions for smtp auth testing
Let's do it the XP way and define and test a test before we do the configuration. Huh? Read on...
Since our remote machine is part of the network defined in mynetworks it will be allowed to relay no matter if we configured smtp auth correctly or not. This will not help us to prove, our configuration for smtp auth works.
In order to gain valid results whether relaying with smtp auth works the way we want it, we'll have to ensure that we are not part of mynetworks. We do this by simply removing our subnet from the mynetworks parameter and only let the IP-range for localhost remain.
[[email protected]]# vi /etc/postfix/main.cf
We reduce mynetworks = 172.16.0.0/24, 127.0.0.0/8 to mynetworks = 127.0.0.0/8.
It should look like this:
mynetworks = 127.0.0.0/8
In order to let the changes be known to Postfix we must restart it.
[[email protected]]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
Let's prove that our test setup will not allow us to relay messages. We telnet from our remote machine. Keep in mind that relaying means sending a message through Postfix to a remote user. The value we provide with rcpt to: must not be a local user.
This is the transcript from our session:
S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-XVERP
S: 250 8BITMIME
C: mail from:<[email protected]>
S: 250 Ok
C: rcpt to:<[email protected]>
S: 554 <[email protected]>: Recipient address rejected: Relay access denied
C: quit
S: 221 Bye
Relay access denied. Just the way we want it at the moment. Postfix will not allow us to relay mails to remote users. Now that we've configured this we can go on and add SASL which will provide us with the functionality to relay even if we are not part of Postfix's network.
Summary
* We gathered informations to use for configuration.
* We configured Postfix to give us basic functionality.
* We added a user for testing purposes.
* Then we sent testmessages from localhost to a local user,
* from a remote machine to a local user and
* from the remote machine to a remote user.
* We did this the hard way in order to exclude failures that could be introduced by more complex Mailclients
* We successfully deleted a non-deliverable message from Postfix without stopping it or manually deleting files from it's mail queue.
* We prepared Postfix to reject relaying for our network in order to prove SASL to work correctly later on.
Howto smtp auth with Postfix(11)
(27 阅读)
Smtp authentication for Mailclients
This chapter deals with Authentication for mailclients that need to relay through your Postfix server.
To keep in mind. There are several apps within Postfix that take care of correct mail delivery. In this chapter our focus will be on the smtpd daemon, which receives mail from clients before deciding what to do with it and passing it on to other apps.
Note
You can tell we are dealing with the smtpd, because most of our configuration settings will start with smtpd_....
Step 1: Enable SASL support
To enable SASL support in Postfix we must configure some settings in the main.cf.
[[email protected]]# vi /etc/postfix/main.cf
You will notice that there is no section in the main.cf that offers pre-installed settings. Therefore we will add a new section on our own.
We add the following lines:
# SASL SUPPORT FOR CLIENTS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mailclients.
#
Enable smtp auth
The first thing we need to do is to tell Postfix to enable smtp auth. We do this by adding the following line:
smtpd_sasl_auth_enable = yes
Security options
There's a really nice, but insecure fallback feature in smtp auth when authenticating. If one mechanism doesn't work it'll try another one. Insecure? The idea is nice, but look how it's done...
It appears that clients try authentication methods in the order as advertised by the server (e.g., PLAIN ANONYMOUS CRAM-MD5) which means that if you disable plaintext passwords, clients will log in anonymously, even when they should be able to use CRAM-MD5. So, if you disable PLAIN logins, disable ANONYMOUS logins too. Postfix treats ANONYMOUS login as no authentication.
Since we want to use the plaintext mechanism in this HOWTO, but not anonymous we'll simple set:
smtpd_sasl_security_options = noanonymous
This will keep Postfix from offering anonymous logins.
Passing the realm
When you use method sasldb Cyrus-SASL needs to know a value from a parameter that's called realm. It's about the same as a domain. In Cyrus-SASL this is used to authenticate users with the same username, but from different domains (e.g. [email protected], [email protected]).
Since our users don't pass the realm when they authenticate, but Cyrus-SASL requires it in order to work properly we set a default value in Postfix. Postfix will append this when it hands over data for Cyrus-SASL to authenticate our relay-users.
In our HOWTO we'll simply reuse a value that we've set when we did or first configuration:
smtpd_sasl_local_domain = $myhostname
sasldb users
If you plan to use sasldb you might want to add this to your paper that holds the parameters that are specific to your setting.
Supporting non-standard mailclients
The broken_sasl_auth_clients controls inter-operability with SMTP clients that do not recognize that Postfix supports RFC 2554 (AUTH command). Examples of such clients are MicroSoft Outlook Express version 4 and MicroSoft Exchange version 5.0.
Specify yes to have Postfix also advertise smtp auth in a non-standard way.
broken_sasl_auth_clients = yes
Now we have configured Postfix to enable SASL support, but one last step is still missing. We must tell Postfix that SASL authenticated clients are allowed to relay. So keep your editor on main.cf open...
Enable relaying for smtp auth users
There are a number of values that we can add to the following parameter. For the moment we stick with a minimum to keep our setup simple and under control.
Search for relay_domains = and add the following line below:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
Configuration overview
When you are done with the configurations from above, your should have added the following lines:
# SASL SUPPORT FOR CLIENTS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mailclients.
#
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
...
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
If you have entered all of this you save the file. Now we will have to make Postfix reread it's configuration.
Step 2: Reload Postfix
You can always stop and start Postfix, but this takes time which you may not have when your online and your have lots of traffic. So we rather have Postfix reread it's configuration by ordering it to reload. Still it will not deliver or receive messages while it reloads, but the downtime will be shorter.
[[email protected]]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
Step 3: Check for smtp auth support
So, now that we've have enabled SASL authentication in the configuration we need to verify that Postfix serves us the new feature. We check from a remote host and telnet to the Postfix server.
S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-XVERP
S: 250 8BITMIME
C: quit
S: 221 Bye
Notice the two new lines?
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
These are the lines that Postfix issues when it offers the use of smtp auth and we can see two things from looking at them:
Fallback feature
First let us remember the insecure fallback feature:
PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI is the order of the mechanisms in which a Mailclient would try to authenticate to. If SASL issued ANONYMOUS in between LOGIN and DIGEST-MD5 we'd be lost or rather an open relay to every spammer in the world who knew this 'feature'.
Broken clients
Did you notice that there are two lines that only differ in an extra '=' in between AUTH and PLAIN. The AUTH=PLAIN statement is the one that broken clients need in order to recognize that they may use smtp auth.
Note:
If you don't see all the mechanisms as pointed out in this HOWTO it means that you didn't install or compile all the SASL mechanisms. Please make sure that you have at least the following as we are going to need them in the HOWTO.
PLAIN
LOGIN
Step 4: Check if smtp auth works
Before we start and configure a Mailclient to relay mail using smtp auth we do one more last check. If we pass this we know were done with server side smtp auth configuration. In this step we will telnet to the server and pass our username and password just to see if we pass the authentication.
Since we use PLAIN as mechanism we will have to pass our credentials plaintext. But hold, the credentials must be Base64 encoded, when we issue them. This can easily be done on our server. The basic script looks like this:
[[email protected]]# printf 'username
Howto smtp auth with Postfix(12)
(34 阅读)
Configuring SASL to use sasldb
If you installed the RPMs you might not have been through this yet. By default Cyrus-SASL's configuration file needs to be put in /usr/lib/sasl. There can be several configuration files, each named after the application that wants Cyrus-SASL to authenticate users.
In our case it is Postfix's smtpd seeking assistance; therefore the file must be named /usr/lib/sasl/smtpd.conf.
Step 1: Edit smtpd.conf
This file holds the parameter that tells Cyrus-SASL which method of authentication we want it to use: saslauthd or sasldb.
So there's only one thing that's needs to be done: Replace the value saslauthd with sasldb.
[[email protected]]# vi /usr/lib/sasl/smtpd.conf
After the edit our smtpd.conf looks like that:
pwcheck_method:sasldb
Step 2: Stop saslauthd
Why should we disable the saslauthd daemon. First of all we don't need it, when we use method sasldb, secondly we are kind of greedy and don't want unused daemons wasting CPU-time and MEM and last and most important in our context: Only when we do not run saslauthd and succeed in authentication we really can tell the sasldb-method did the job.
If you start|stop the saslauthd from an INIT-script, as the RPM-Version does, all you need to do is call the INIT-script and order it to stop the saslauthd. If you use a different method you will hopefully know how to stop the daemon by yourself.
[[email protected]]# /etc/init.d/saslauthd stop
Shutting down saslauthd: [ OK ]
Step 3: Disable saslauthd (optional)
If you plan to use sasldb instead of saslauthd on your system then you should make sure the daemon will not get started automatically when you system enters the different runlevels or when you reboot. So you either disable the daemon or remove it completely.
Disabling saslauthd
[[email protected]]# cd /etc/init.d/
[[email protected]]# chkconfig --del saslauthd
Removing saslauthd
[[email protected]]# rpm -e cyrus-imapd-authd
Step 4: Collect informations to create sasldb
When we create the sasldb database we must provide information that we defined when we configured Postfix - the value of the realm. This value is set in the smtpd_sasl_local_domain parameter in main.cf
Let's see what we have in /etc/postfix/main.cf:
[[email protected]]# egrep myhostname /etc/postfix/main.cf
In the output of the egrep we find these two lines:
smtpd_sasl_local_domain = $myhostname
myhostname = mail.example.com
So in our HOWTO mail.example.com is the value that Postfix will pass as realm when it asks Cyrus-SASL to look for users in the sasldb. We must remember that when we add users, because then we must provide exactly this value to the sasldb; if we don't do that, authentication will fail.
Step 5: Create sasldb
Cyrus-SASL provides us with a tool to create, edit and delete users in the sasldb: saslpasswd. The first time we use it, it will also create the sasldb if it hadn't been there before. Default for saslpasswd, unless compiled with different option, is to create the sasldb in /etc. You might want to check if that file exist, before we override some settings that another application might depend on.
[[email protected]]# cd /etc/
[[email protected]]# ls -all sasldb
ls: sasldb: No such file or directory
Perfect. Let's focus on the parameters and values that we need to pass when we create users in sasldb.
There are three parameters that we must provide when adding users to the sasldb. We begin our statement with the option -c and tell saslpasswd to create a new entry, then we add the already mentioned realm with -u realmname add the task with -a smtpauth and finally we provide the username. If you need a little more information read man saslpasswd.
In the HOWTO we will add our user test to the sasldb.
[[email protected]]# saslpasswd -c -u mail.example.com -a smtpauth test
This is how our command reads. When you add your user, don't forget to use our own, specific realm.
Next thing is to change the owner because it's going to be the user postfix who will want to access the sasldb. There is an option called autotransition which will have Cyrus-SASL upgrade passwords from PLAIN to the other mechanisms that are available. If you enable that option with autotransition:true Postfix will also need to write to that file. This will not be needed in this HOWTO, but we'll prepare the sasldb for use of that option by setting correct r/w permissions.
[[email protected]]# ls -all sasldb
-rw------- 1 root root 12515 Mar 15 04:32 sasldb
Since we created it as root it is owned by root and the group root. We'll hand it over to Postfix this way:
[[email protected]]# chown postfix sasldb
[[email protected]]# ls -all sasldb
-rw------- 1 postfix root 12515 Mar 15 04:32 sasldb
Permissions and ownership are correct, but what about it's content?
Step 6: Check content of sasldb?
Cyrus-SASL provides yet another tool that will list all the users inside the sasldb: sasldblistusers. You simply execute the tool and it will write all the users, their different realms and keys to standard-output.
Our output produces this:
[[email protected]]# sasldblistusers
user: test realm: mail.example.com mech: PLAIN
user: test realm: mail.example.com mech: CRAM-MD5
user: test realm: mail.example.com mech: DIGEST-MD5
That's it. We're done configuring. Ready to find out if everything works.
Step 7: Send Testmail
TDB...
Howto smtp auth with Postfix(13)
(36 阅读)
Adding TLS support to Postfix
TLS (formerly SSL) stands for Transport Layer Security. Once this layer is established, it encrypts the communication between two hosts. If we use smtp auth and the mechanisms PLAIN or LOGIN usernames and passwords are sent plaintext over the internet. This means that anyone could sniff the communication and read the passwords. If you don't want this - we bet you don't - you can use TLS to help.
Process to smtp auth using plaintext passwords and TLS
1. Connect to your Postfix-server
2. establish a TLS encrypted communication layer and
3. only then send our smtp auth PLAIN or LOGIN
Steps for integration
1. Check if our Postfix build supports TLS
2. Build the certificates that are issued when a TLS connection is being established
3. Add configuration parameters to Postfix main.cf that enable TLS
4. Advise Postfix only to smtp auth when a TLS connection has successfully been established.
Step 1: Check Postfix for TLS support
If you built the RPMs you may wonder why we check for TLS support. This section also applies for NON-RPM configuration and people that might just jump in on this HOWTO. Anyway it's a good exercise. You'll find out how to query binaries for the libraries they support.
In our HOWTO the smtpd daemon is in /usr/libexec/postfix/. So we do the following at the command line:
[[email protected]]# ldd /usr/libexec/postfix/smtpd
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4001e000)
libssl.so.2 => /lib/libssl.so.2 (0x4002a000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40057000)
libdb-3.2.so => /lib/libdb-3.2.so (0x4011a000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401c1000)
libresolv.so.2 => /lib/libresolv.so.2 (0x401d7000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x401ea000)
libc.so.6 => /lib/i686/libc.so.6 (0x401f1000)
libdl.so.2 => /lib/libdl.so.2 (0x4032c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40330000)
libpam.so.0 => /lib/libpam.so.0 (0x4035d000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40365000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40378000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x403d1000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x403e2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
The smtpd daemon supports TLS. If you cannot find the libssl in the output you either built Postfix with static libraries or building Postfix with TLS didn't work. In this case you'll have to reconfigure your Postfix SOURCE, recompile or rebuild it, backup the data in /etc/postfix/ and reinstall the newly compiled Postfix binaries.
Step 2: Which certificates are required?
CERT 1: CA cert (cacert.pem)
We need a cert from a Cert-Authority that we can refer to when a client wants to validate the cert that we issued from our Postfix-server. There are two possibilities and it all boils down that "It's a matter of trust".
Become your own CA
If you are a private user and simply want to enjoy encrypted communication, but don't want to pay for a cert, you can become your own CA. You'll only will use it for yourself and hey who shouldn't trust yourself more that you. This HOWTO will show you how to do that.
Get an official certificate
If you will use your server for business purposes (ISP, etc.) you should go and get a valid cert for your server from an offical CA. Your customers will apprechiate. Meanwhile this should not keep you from reading on and building your own CA authority certificate for testing purposes.
CERT 2: public server.cert (newcert.pem)
We will need to issue a certificate when we establish the connection. This certificate is the public server.cert.
CERT 3: private server cert (newreq.pem)
What do we need this for? Anyway, it's the private server cert.
Step 3: Build certificates for TLS use
When a TLS connection is being established the host establishing the connection has to validate itself. This is because someone else could hijack the connection and establish an encrypted connection. The remote host probably wouldn't notice and pass sensible information. Therefore certificates are used to provide unique information that proves that the host encrypting the communication really is the host your client wants to talk to.
You are right when you argue that anyone even a hostile server could issue a certificate if it wasn't for that little detail we left out: Each certificate that is issued provides information about an authority that will validate the cert that is issued when an TLS connection is established. Now that you understand the concept you'll understand what we need:
RH 7.x Users
On RedHat machines openssl has its configuration file for creating certs in /usr/share/ssl. So we go there and edit that file first as it carries the default values that will be offered to us later. You can skip this section, but don't complain when you mistype your values and must start the whole script again. ;-)
[[email protected]]# cd /usr/share/ssl/
[[email protected]]# vi openssl.cnf
edit countryName_default and 0.organizationName_default and provide values that make sense to your setting. This HOWTO will use Germany (DE) and HOWTO as values.
countryName_default = DE
0.organizationName_default = HOWTO
then uncomment organizationalUnitName_default and add a value. We will use Mailserver in this HOWTO.
organizationalUnitName_default = Mailserver
add the lines commonName_default (must be the name of your Mailserver!) and emailAddress_default and provide values specific to your setting. Our Mailservers hostname is mail.example.com and [email protected] is in charge.
commonName_default = mail.example.com
emailAddress_default = [email protected]
That's it and it will save us a lot of typing as we will build not only one cert. Save the file and read on as we will have to edit yet another file.
Consider this: Usually certs are crypted. That's a good idea when you take them along with yourself and the disc you have it on gets lost. It won't be of any use to the finder unless that person also knows your secret passphrase... But then if you don't take it with you, but leave it on a server this feature can become a real problem to the availabilty of your service. Why? Well, any time you restart the server and the server wants to get its hand on the cert, the cert wants to be given the secret passphrase and the server hangs in there waiting to pass that task on its start list. And it waits and waits and waits... until you enter the secret passphrase at the command prompt. The bottom line is: No passphrase, no service.
So we will not create certs with secret passphrases, as we will not always be available when the server needs to be restartet or starts itself, say after a power failure.
In order to have certs that aren't crypted we will have to add a parameter to the script that we run when we create a cert. So let's cd to the directory that holds the script and create a backup first before we edit it.
[[email protected]]# cd misc/
[[email protected]]# cp CA CA_nodes
[[email protected]]# edit CA_nodes
Note
Either it's CA or CA.pl. This depends on your RedHat distribution. Both scripts will help you generate certs.
Search for # create a certificate and add -nodes to the line below that begins with $REQ.
When your done with this search for # create a certificate request and do the same again.
When your done it should look like this:
-newcert)
# create a certificate
$REQ -new -nodes -x509 -keyout newreq.pem -out newreq.pem $DAYS
RET=$?
echo "Certificate (and private key) is in newreq.pem"
;;
-newreq)
# create a certificate request
$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS
RET=$?
echo "Request (and private key) is in newreq.pem"
;;
That's it for preparations. Let's create the certs.
Step 3.1: Generating the CA certificate
The first cert we will create is the Authority cert. We do this by calling the CA script and telling it that we want it to create a new CA:
[[email protected]]# ./CA_nodes -newca
CA certificate filename (or enter to create)
MAKING CA CERTIFICATE ...
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
................++++++
......................++++++
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [DE]:
State or Province Name (full name) [Germany]:
Locality Name (eg, city) []:Munich
Organization Name (eg, company) [ExampleOrganisation]:
Organizational Unit Name (eg, section) [Mailserver]:
Common Name (eg, your name or your server's hostname) [mail.example.com]:
Email Address [[email protected]]:
Step 3.2: Generating the server certificate request
Then we will create the server cert request that will be signed by the CA Authority:
[[email protected]]# ./CA_nodes -newreq
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.........................++++++
.............++++++
writing new private key to 'newreq.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [DE]:
State or Province Name (full name) [Germany]:
Locality Name (eg, city) []:Munich
Organization Name (eg, company) [ExampleOrganisation]:
Organizational Unit Name (eg, section) [Mailserver]:
Common Name (eg, your name or your server's hostname) [mail.example.com]:
Email Address [[email protected]]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:certpass
An optional company name []:
Request (and private key) is in newreq.pem
Step 3.3: Signing the server certificate
Finally we sign the server cert request with our own CA cert:
[[email protected]]# ./CA_nodes -sign
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'DE'
stateOrProvinceName :PRINTABLE:'Germany'
localityName :PRINTABLE:'Munich'
organizationName :PRINTABLE:'ExampleOrganisation'
organizationalUnitName:PRINTABLE:'Mailserver'
commonName :PRINTABLE:'mail.example.com'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until Mar 15 07:45:17 2003 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
...
Signed certificate is in newcert.pem
Let's review what we have generated.
newreq.pem
This is the private SERVER CERT. We generated it in order to request an CA to sign it. It contains our private key.
newcert.pem
That is your public SERVER CERT. It has been signed by a CA in this case ourselves.
demoCA/cacert.pem
This is the CERT of the CA Authority. We created it when we made ourselves a CA.
Step 3.4: Installing the certificates
We want the certs that we use for TLs support in smtp to stick closely with our Postfix configuration files. So we copy them to the Postfix CONFIG_DIR.
[[email protected]]# cp newcert.pem /etc/postfix/
[[email protected]]# cp newreq.pem /etc/postfix/
[[email protected]]# cp demoCA/cacert.pem /etc/postfix/
Step 4: Enabling TLS in Postfix
We got the certs. Next we will tell Postfix where they are and that we want it to offer TLS using them.
[[email protected]]# cd /etc/postfix
[[email protected]]# vi main.cf
There is no TLS configuration in the main.cf. So we start wherever we want to and add some documentation as we enter the configuration:
## TLS
# Transport Layer Security
# TLS-Patch by Lutz J?nicke
#
smtpd_use_tls = yes
#smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/newreq.pem
smtpd_tls_cert_file = /etc/postfix/newcert.pem
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
There's one parameter that we leave commented out for the moment, as we want to check only if we can initiate a TLS session without 'hiding' smtp auth at the moment.
Note
If you want to understand what these parameters are for you might want to read Postfix/TLS - Configuring main.cf and master.cf by Lutz J?nicke the creator and maintainer of Postfix/TLS support.
Step 5: Reloading Postfix
So we're done with the configuration. We now need to reload postfix and make it reread the new configuration.
[[email protected]]# postfix reload
Step 6: Checking for TLS support
Next we will check if we can initiate a TLS session. We telnet to the server and check, if the string STARTTLS shows up when Postfix advertises it's capabilities. Then we simply type in STARTTLS and wait for Postfix to respond that it is ready to start TLS. This is how our successful telnet session should looked like:
C: [[email protected]]# telnet mail.example.com 25
S: 220 mail.example.com ESMTP Postfix (1.1.5)
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-XVERP
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
So Postfix advertises TLS and it can start a session. Time to go for the full experience and configure a mailclient.
Step 7: Configure mailclient to use SSL for smtp
Again we will be using MS Outlook in this HOWTO. Open Extras --> Accounts --> mailaccount and switch to the advanced tab. Then check the box that reads: Server requires secure connection.
Save the configuration and send a mail to our local user test. Everything should work.
Step 8: Enabling Postfix to offer smtp auth only when TLS is established
That leaves us with one major step to be done. We want to make sure that smtp auth PLAIN will only be available to users who use TLS. So we advise Postfix to issue the smtp auth command only when TLS has been established. This brings us back to the one line we had left commented out in main.cf when we added TLS support.
[[email protected]]# vi main.cf
Search for smtpd_tls_auth_only and uncommented the line. It should read like this:
smtpd_tls_auth_only = yes
Step 9: Reloading Postfix
We edited main.cf, we must tell Postfix. So we reload it.
[[email protected]]# postfix reload
Now when we send messages to the server smtp auth will only be offered after the TLS layer has been established. You can see that when you telnet to the server. The AUTH announcement is gone and still when you use a mailclient you can relay using smtp auth.
C: [[email protected]]# telnet mail.example.com 25
S: 220 mail.example.com ESMTP Postfix (1.1.5)
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-XVERP
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
That's it. Your done. Have fun.