Learn Mailserver - Authentication & SASL

#Introduction

So far, anyone could send email through your Postfix as long as the destination was allowed — there's been no check on who's sending. In this episode we lock the outbound gate: authentication.

The core concept is SASL (Simple Authentication and Security Layer): a standard layer for authentication on top of protocols. Postfix doesn't need to manage its own password database — it "borrows" Dovecot's authentication capability via a Unix socket, so one set of credentials serves both sending and reading.

We'll set up the Dovecot auth socket, configure Postfix to use it, require authentication on the submission port, and test the result with swaks.

#The SASL Concept and Its Architecture

SASL separates the protocol (SMTP/IMAP) from the authentication mechanism. Instead of every protocol implementing its own login, they query the same SASL layer. In our architecture:

• Dovecot is the SASL provider — it has access to the virtual users database and knows how to verify credentials.
• Postfix is the SASL consumer — it contacts Dovecot via the Unix socket every time a client tries to log in on submission.

The result: passwords are stored in one place, a single source of truth, and there's no credential synchronization between Postfix and Dovecot.

#Setting Up the Dovecot Auth Socket

Dovecot provides the auth service that serves SASL requests. We need to make it reachable by Postfix from inside its chroot. Enable it in conf.d/10-master.conf:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }
}

The first socket is used by Postfix for SASL; the second is used internally by Dovecot for userdb lookups. Reload:

sudo dovecot reload
ls -la /var/spool/postfix/private/auth

If the socket appears with the postfix user, the connection path is open.

#SASL Configuration in Postfix

Connect Postfix to the Dovecot socket and enable authentication:

sudo postconf -e 'smtpd_sasl_type = dovecot'
sudo postconf -e 'smtpd_sasl_path = private/auth'
sudo postconf -e 'smtpd_sasl_auth_enable = yes'
sudo postconf -e 'smtpd_sasl_security_options = noanonymous'
sudo postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination'
sudo postfix reload

What the parameters mean:

• smtpd_sasl_type = dovecot — use the Dovecot SASL backend.
• smtpd_sasl_path = private/auth — the socket path relative to the Postfix queue directory.
• smtpd_sasl_auth_enable = yes — turn on the AUTH mechanism in SMTP.
• smtpd_sasl_security_options = noanonymous — reject anonymous logins.
• smtpd_recipient_restrictions — now permit_sasl_authenticated lets authenticated clients send to any destination.

Check that the mechanism is detected:

postconf smtpd_sasl_type smtpd_sasl_path smtpd_sasl_auth_enable

#Requiring Authentication on Submission

Right now AUTH is available on all ports. It shouldn't be: port 25 must reject authentication (preventing spammers from using leaked credentials), while submission (587) and SMTPS (465) require it. Separate the policies in master.cf:

sudo postconf -M submission/inet='submission inet n - y - - smtpd'
sudo postconf -P submission/inet/smtpd_tls_security_level=encrypt
sudo postconf -P submission/inet/smtpd_sasl_auth_enable=yes
sudo postconf -P submission/inet/milter_macro_daemon_name=ORIGINATING
sudo postfix reload

With this configuration, port 587 only serves clients that authenticate over TLS — a combination that forms modern mail security practice. Check the resulting master.cf:

postconf -M submission/inet

#Authentication Mechanisms: Choosing the Secure Ones

auth_mechanisms in Dovecot determines how passwords are sent:

• PLAIN / LOGIN — the password is sent as-is. Only allowed over TLS.
• CRAM-MD5 — challenge-hash, doesn't send the password. Safe without TLS but cryptographically weak.
• SCRAM-SHA-256 — modern, with salting and channel binding; fully supported in Dovecot 2.4.

The golden rule: since TLS has been mandatory on submission since episode 6, plain login is a valid choice and the most compatible with all clients. scram-sha-256 is an upgrade for clients that support it. Never enable PLAIN without TLS.

doveadm config set auth_mechanisms 'plain login'
sudo dovecot reload

#Testing with swaks

swaks (Swiss Army Knife for SMTP) is the best SMTP testing tool to make sure authentication works:

sudo apt install -y swaks

Test logging in to submission with TLS:

swaks --server mail.example.com --port 587 --tls \
  --auth-user admin@example.com --auth-password 'rahasia' \
  --to admin@example.com --from admin@example.com

If the output ends with 250 2.0.0 Ok: queued, authentication and delivery succeeded. To make sure port 25 rejects AUTH, try without --tls on port 25 — the result must be a rejection.

#Conclusion

Episode 13 is done. Key takeaways:

• SASL separates authentication from the protocol; Dovecot is the provider, Postfix the consumer.
• The auth socket at /var/spool/postfix/private/auth connects the two.
• Submission requires TLS + authentication; port 25 rejects both.
• permit_sasl_authenticated lets authenticated clients send anywhere.
• PLAIN/LOGIN is only safe over TLS; test with swaks --tls.

The outbound gate is locked. In episode 14 we fight the junk: Anti-Spam — SpamAssassin & RBL — installing rule-based scoring, learning from email history, and rejecting well-known IPs at the start of the connection. See you in episode 14!