I'd like to run Postfix on a Debian VPS to send e-mails from my application. The application (running on other VPSes) would connect to Postfix via SMTP. Postfix does not have to handle incoming email; it's just about sending the outgoing messages.

To prevent being an open relay, SASL authentication should be used. However, I don't want to run Dovecot or MySQL for SASL authentication.

How can I setup SASL authentication using a simple file (containing usernames and passwords)?

I already found a similar question; however, no satisfying answers where given there.

  • Use a firewall to let only the ip addresses of the other VPS connect. Additionally you can set the mynetworks variable in main.cf to make postfix aware of that, even if the firewall fails. If you really want SASL, read the SASL_README that comes with postfix and set up SASL to use /etc/sasldb as a "database". Should work out of the box. saslpasswd adds/removes/changes the file. – AndreasM Oct 22 '13 at 14:40

Postfix currently supports only two SASL authentication methods. One of the is Dovecot, which you don't want. The other is Cyrus, which is about as close to what you want as it's possible to get without rewriting Postfix. It does involve running a separate authentication daemon (saslauthd), but the authentication file is easy to edit and update.

The basics for using Cyrus SASL can be found at the postfix documentation site, but here's a short description. Please look at the link if anything's confusing in any way!

Start by installing Cyrus SASL with the plugin sasldb. (How to do that is left as an exercise for the reader; presumably there's a package in whatever package system your brand of unix is using.) Since the communication between Postfix and SASL will take place via a unix domain socket, you may want to add postfix to the SASL group, and make sure that that group has read and execute permissions to the directory /var/run/saslauthd.

Configure SASL

Configure SASL to use sasldb by editing /etc/sasl2/smtpd.conf:

pwcheck_method: auxprop
auxprop_plugin: sasldb

The sasldb plugin means that sasl will use a Berkeley DB file for usernames and passwords. You add users with the command saslpasswd2:

$ saslpasswd2 -c -u example.com username
Again (for verification):

Note that you specify a domain together with the username, and the user will need to use "username@example.com" rather than just "username" when authenticating.

You can verify what users have been entered by running sasldblistusers2.

Start saslauthd, and verify that the authentication works by doing

testsaslauthd -u username@example.com -p password

Configure Postfix

Once that is done, tell Postfix to use SASL and to tell Cyrus that it's SMTP that it's authenticating, by editing /etc/postfix/main.cf to contain

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd

Then, reload postfix, and you should be set.

  • @AndreasM - thanks for the edit! – Jenny D Oct 23 '13 at 6:52
  • Thanks for your extensive answer! I've followed all steps and everything seems to work well. sasldblistusers2 correctly outputs the list of users I added. However, when performing testsaslauthd, I get this result: 0: NO "authentication failed". Do you have any idea how I could fix that? This is from my /var/log/auth.log: saslauthd[30471]: do_auth : auth failure: [user=XXX@XXX] [service=smtpd] [realm=] [mech=pam] [reason=PAM auth error] – Jonathan Oct 23 '13 at 20:41
  • That means that saslauthd is trying to use PAM instead of sasldb. What was the command line used to start it? – Jenny D Oct 24 '13 at 7:21
  • I used testsaslauthd (as described in your original answer), and also tried appending -s smtpd to it. If I set MECHANISMS="sasldb" in /etc/default/saslauthd and restart saslauthd, I get the same result from testsaslauthd. The auth log shows a different message: saslauthd[3706]: do_auth : auth failure: [user=XXX@XXX] [service=smtpd] [realm=] [mech=sasldb] [reason=Unknown] – Jonathan Oct 24 '13 at 8:53
  • 2
    Hm, testsaslauthd is working if I specify the username and domain part separately, like this: testsaslauthd -u username -r example.com -p XXX returns 0: OK "Success.". Now I'll check whether Postfix can work around this… – Jonathan Oct 24 '13 at 8:58

To prevent being an open relay, SASL authentication should be used.

SASL is only one of numerous ways to prevent this. Another would be to whitelist the IPs you use on the other VPSes, or to require TLS client certificates (this can be said to be the most secure way.)

Just set up a signing CA on the postfix machine, and sign one certificate per VPS you wish to submit email.
Then require full client certificate verification for all submitted mail; disable any other methods of submission.

What you ask is not possible, as postfix does not support SASL directly.


Just clarifying a few things,

Creating an account in sasldb:

% saslpasswd2 -c -u fqdn username

Testing authentication:

% testsaslauthd -u username -p password

(note: the username is not followed by the fqdn)

I would also like to add that creating a root account

% saslpasswd2 -c -u example.com root

will not let you authenticate,

% testsaslauthd -u root -p some_password
0: NO "authentication failed"

But this is not a bug. It is just a safety feature.


If you don't need to handle incoming mail, then don't bother with authentication. Just block incoming traffic with a firewall, and/or restrict it to localhost only.

 inet_interfaces =

No more open relay issue, and you also avoid complicating things for applications that need to send mail through postfix.

  • Thanks for the answer. The application is running on other VPSes, so Postfix will receive the email from other hosts than localhost. – Jonathan Oct 23 '13 at 20:25
  • Can you define the IPs of the expected connections and list them in either the postfix configuration or a firewall config? Eg they might all be in a single net-block, or a small enough set of IPs or blocks that you can easily list them. Alternatively you could look at using a private network between your virtual hosts. – mc0e Oct 24 '13 at 1:44

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.