Postfix as relay to a SMTP requiring authentication

Sometimes you may in need to use an external SMTP provider to send your emails, and usually ISPs give instruction on how to configure mail clients such as Outlook or Thunderbird. But what if you are already using an internal SMTP server such as Postfix?

These guidelines are for Debian (but may be helpful with other systems as well) and are related to Postfix. The SMTP provider in the example is AuthSMTP which is a well known provider for SMTP relaying.

Given you already have a working Postfix environment, first of all edit your and add these lines:

relayhost = []
smtp_sasl_mechanism_filter = digest-md5

then, create with $EDITOR a file called /etc/postfix/sasl-passwords and fill it with something like this:

[] yourusername:yourpassword

then, compile the map file

# postmap hash:/etc/postfix/sasl-passwords

now we are almost done, just restart postfix and it should work.

Now, probably it won’t really work and you’ll start to see messages like these in your postfix log:

warning: SASL authentication failure: No worthy mechs found
SASL authentication failed; cannot authenticate to server

that’s because you are missing some SASL packages from Debian. Issue

# aptitude install libsasl2-modules

and it should install all the missing packages and make the thing work :)

Maildrop and the automatic maildirmake problem

If you are using a vanilla maildrop in a classic postfix (or another MTA) environment, you will have your to look like this:

maildrop unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/maildrop -d ${user}@${nexthop} ${user} ${nexthop} ${sender}

for example. And with this configuration, maildrop will not elaborate at all your /etc/maildroprc directive file. Why? Very simple (once you discover it): because we are using the -d switch which implies the Delivery mode. And it’s even written in the maildrop man page! Look:

Delivery mode

maildrop is the mail server’s mail delivery agent. maildrop runs in delivery mode when no filename is specified on the command line. maildrop
changes the current directory to the user’s home directory, then reads /etc/maildroprc, then $HOME/.mailfilter.

so, what’s happening here? Maildrop check if the ${user}@${nexthop} home directory exists and since it doesn’t, it simply exits spitting in your face :) So, no maildroprc rule applies, so you cannot create on-the-fly the homedir.
Now, there are two solutions:

  1. create manually (well, in the user-creation script) the home directory plus the Maildir with something like this:
    mkdir -p /home/vmail/domains/$DOMAIN/$USER
    maildirmake /home/vmail/domains/$DOMAIN/$USER/Maildir
    chown -R vmail:vmail /home/vmail/domains/$DOMAIN/$USER
  2. edit to be like this (in the maildrop part):

    maildrop unix - n n - - pipe
    flags=DRhu user=vmail:vmail argv=/usr/bin/maildrop /etc/maildroprc ${user} ${nexthop} ${sender}
    then give 0600 permissions and vmail ownership to /etc/maildroprc and finally append this to it (if you want to enable maildrop filter capabilities)
    if ( $RETURNCODE == 0 )

PS: Gentoo maildrop version is affected by this “problem”. On the other hand, Debian’s one seems to be “immune”

Postfix in a multi-IP environment

If you have to install postfix in a multi-IP environment, say, if you need it to listen to two or more IP (for example a real IP and an alias on the same NIC), there is a cute directive in that let you decide which IP should postfix (well, it’s parts like smtp, virtual/maildrop etc) use when contacting an external server.

inet_interfaces =,, localhost
smtp_bind_address =

with inet_interfaces your postfix will listen to these 3 IPs, and with smtp_bind_address you will tell postfix to specifically use when contacting an external address.