Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM in a chroot() environment. Employ TLS/SSL connections.
- Note: The following steps have been carried out and verified on a Debian 7.1 system (Jan. 2015).
Note: SASL2 (saslauthd) creates a socket in its working directory. Postfix (smtpd) needs access to this socket. If smtpd is running chroot()ed (what is standard on Debian) saslauthd must run within this chroot() environment also (though not being chrooted itself). While this is fine for smtpd there are other services (Cyrus imapd for example) which expect saslauthd 's socket at its "regular" location (/var/run/saslauthd).
The recommended way to solve this is to run separate saslauthd processes for Postfix and for others. Debian is prepared for this. Alternatively a symlink-trick can be used. See below. Or you can disable chroot()ing by editing the chroot columns in /etc/postfix/master.cf.
Create a file /etc/postfix/sasl/smtpd.conf:
pwcheck_method: saslauthd mech_list: PLAIN LOGIN
- Setup a separate saslauthd process to be used from Postfix:
Create a copy of saslauthd's config file
~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
and edit it
START=yes DESC="SASL Auth. Daemon for Postfix" NAME="saslauthd-postf" # max. 15 char. # Option -m sets working dir for saslauthd (contains socket) OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" # postfix/smtp in chroot()
Alternatively you can replace the directory /run/saslauthd with a symlink to /var/spool/postfix/var/run/saslauthd
~# rm -rf /run/saslauthd ~# ln -s /var/spool/postfix/var/run/saslauthd /run/saslauthdThis is a quick-and-dirty hack, useful only for testing purposes. After the next reboot the contents of /run will be reset.
Create required subdirectories in postfix chroot directory:
dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
Add the user "postfix" to the group "sasl":
adduser postfix sasl
~# service saslauthd restart [ ok ] Stopping SASL Auth. Daemon: saslauthd. [ ok ] Stopping SASL Auth. Daemon for Postfix: saslauthd-postf. [ ok ] Starting SASL Auth. Daemon: saslauthd. [ ok ] Starting SASL Auth. Daemon for Postfix: saslauthd-postf.
Edit Postfix configuration:
~# postconf -e 'smtpd_sasl_local_domain = $myhostname' ~# postconf -e 'smtpd_sasl_auth_enable = yes' ~# postconf -e 'broken_sasl_auth_clients = yes' ~# postconf -e 'smtpd_sasl_security_options = noanonymous' ~# postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination'
(Optionally) Create a new PAM fragment and adjust it to your needs:
~# cd /etc/pam.d ~# cp other smtp ~# editor /etc/pam.d/smtp
Restart (reloading is not enough) postfix:
~# service postfix restart
That's it, you're done, everything should work fine now.
If something goes wrong (cannot connect to server, authentification fails) try to see what is happening behind the scenes. Try to connect to your mailserver via
~# telnet server 25
Can smtpd be connected? If yes, enter the command "ehlo dummy". What does smtpd respond? For more information see Check for SMTP AUTH support
There are three options for transferring data to Postfix (smtpd):
- do not use TLS/SSL at all (only unsecure connections are available)
- use TLS/SSL, if possible. Fall back to unsecure connections otherwise.
- only allow TLS/SSL (unsecure connections are not available)
The second option (called STARTTLS) is recommended for general purpose mail servers. It provides some sort of "compatibility mode". Secure data transfer is enabled but not enforced.
STARTTLS connections start unencrypted via the regular smtp port 25. If both sides agree the rest of the data transfer is encrypted, still using port 25.
Pure TLS/SSL uses it own port, usually smtps (465). See below.
Recent postfix versions employ the parameter smtpd_tls_security_level to control TLS encryption (valid values are none, may or encrypt)
With following commands TLS is enforced (no STARTTLS) and the old configuration parameters are reset to default values:
~# postconf -e smtpd_tls_security_level=encrypt ~# postconf -# smtpd_use_tls ~# postconf -# smtpd_enforce_tls
Alternate TLS/SSL Ports
You may be interested in supporting the smtps and/or submission ports (see /etc/services) so that your mobile/remote users who may be on a system that blocks, filters or poorly proxies SMTP (port 25) traffic can still send mail through your server. Since these ports are not also used for MTA to MTA traffic, you can enforce extra restrictions such as requiring SSL/TLS.
We do this by modifying the file /etc/postfix/master.cf to run additional smtpd services with special parameters on dedicated ports.
The submission port (587), covered in RFC 2476, is reserved for mail user agents (MUA)/ mail submission agents (MSA) to send email to a mail transfer agent (MTA).
In order to enable an additional service edit the file /etc/postfix/master.cf.
In this example we disallow ETRN, require TLS and enable SASL Auth on the submission port.
submission inet n - - - - smtpd -o smtpd_etrn_restrictions=reject -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
The smpts (or ssmtp) port (465) is the equivalent of https. The secure layer is expected from the get-go and not an optional negotiated parameter after connecting.
Whether the port is named smpts or ssmtp depends on the contents of your /etc/services file. On Debian both names seem to be defined. The output of netstat -tl shows ssmtp.
In order to enable an additional service edit the file /etc/postfix/master.cf.
On Debian there is already a prepared entry for smtps but commented out. Remove the "#" characters to enable it.
smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
Connections from Fetchmail to Postfix
It seems fetchmail is not able to setup a TLS connection to Postfix. (Not to be confused with fetchmail 's capabilities to fetch mails via TLS-connections.)
If Postfix is configured to only accept TLS connections (smtpd_tls_security_level=encrypt) fetchmail will fail with an error like "Must issue a STARTTLS command first".
One way to escape from this is to provide an unencrypted smtp service. Of course, this service should be available for a local fetchmail process only.
Edit /etc/postfix/master.cf and add
127.0.0.1:40025 inet n - - - - smtpd -o smtpd_tls_security_level=none
This will add an additional smtp service listening on port 40025 with TLS disabled but only accepting local connections.
Fetchmail has to be configured accordingly via the option smtphost.
# Server options poll ... # User options user a ... smtphost 127.0.0.1/40025 user b ... smtphost 127.0.0.1/40025
The smtphost option is a so called "user option". It must be added to every user section.
Alternatively fetchmail can be instructed to use an external TLS-capable program*) to forward mails. This is not handled here. And if fetchmail and Postfix run on the same machine it does not make much sense anyway.
*) so called "lightwight" MTAs like msmtp or sSMTP
Alternative implementation using Dovecot
--- Note: The following text seems to be outdated. Obviously it dates back to times of Debian 3.1 and SuSE 9.3 (2005). The presented settings for "tls config" are more less the same as for SuSE 9.3. I leave it here for reference. [M.A. 2015-01-16]---
Modified for Debian from http://www.yocum.org/faqs/postfix-tls-sasl.html
# tls config smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/ssl/certs/smtpd.pem smtpd_tls_cert_file = /etc/ssl/certs/smtpd.pem smtpd_tls_["CAfile"] = /etc/ssl/certs/smtpd.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes
Things to note:
If you want better entropy, use /dev/random if you are handling only a few clients -- in some cases /dev/random cannot provide entropy as fast as required, in these cases Postfix will have to wait for enough entropy. If you are going to be handling a lot of clients and want better entropy than urandom, you may want some sort of entropy gathering hardware for random.
My smtpd.pem file is a symbolic link to the same certificate I am using for imapd in the same directory.