Translation(s): none

Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM in a chroot() environment. Employ TLS/SSL connections.

  1. Install libsasl2-modules, postfix, sasl2-bin

  2. Create a file /etc/postfix/sasl/smtpd.conf:

    pwcheck_method: saslauthd
    mech_list: PLAIN LOGIN
  3. 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

      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()

      (See /usr/share/doc/sasl2-bin/README.Debian.gz)

      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/saslauthd
      This is a quick-and-dirty hack, useful only for testing purposes. After the next reboot the contents of /run will be reset.
  4. Create required subdirectories in postfix chroot directory:

    dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
  5. Add the user "postfix" to the group "sasl":

    adduser postfix sasl
  6. Restart saslauthd:

    ~# 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.
  7. 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'
  8. (Optionally) Create a new PAM fragment and adjust it to your needs:

    ~# cd /etc/pam.d
    ~# cp other smtp
    ~# editor /etc/pam.d/smtp
  9. Restart (reloading is not enough) postfix:

    ~# service postfix restart

That's it, you're done, everything should work fine now.

Troubleshooting tip

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

Adding TLS/SSL

There are three options for transferring data to Postfix (smtpd):

  1. do not use TLS/SSL at all (only unsecure connections are available)
  2. use TLS/SSL, if possible. Fall back to unsecure connections otherwise.
  3. 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)

Previously two parameters (smtpd_use_tls and smtpd_enforce_tls) were used. They can be unset. See also Bugreport 520936.

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/ 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/

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/

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/ and add      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.

Edit /etc/fetchmailrc

# Server options
poll ...

# User options
user a ...
user b ...

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

See also:

Additional information

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

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