$ guides / postfix / postfix-sasl-authentication-failed ▌

Operations Guides

Postfix SASL authentication failed: brute force on submission and credential errors

Postfix logs “SASL LOGIN authentication failed” or “SASL PLAIN authentication failed” when an SMTP client on port 587 (submission) or 465 (smtps) sends an AUTH command that the SASL backend rejects. Postfix does not verify credentials itself. It delegates to a backend via smtpd_sasl_type (dovecot or cyrus), which may in turn proxy to LDAP, Active Directory, PAM, or SQL.

The critical first distinction: sporadic failures from specific clients indicate misconfigured credentials, a password rotation, or an expired app password. A sustained flood of failures from one or many IPs with varying usernames is a credential brute-force. When all authentication fails for every client simultaneously, the backend is down or unreachable.

Each failed AUTH attempt counts toward Postfix’s error limits. After smtpd_soft_error_limit (default 10) errors, Postfix delays each additional error by 1 second. After smtpd_hard_error_limit (default 20), Postfix disconnects the client. Brute-force tools typically open new connections per attempt rather than retrying on one connection, driving reconnect churn and consuming smtpd process slots. The client IP is logged with each failure, making IP-based rate limiting the primary defense once an attack is confirmed.

Common causes

Cause	What it looks like	First thing to check
Credential brute force	Sustained flood of SASL failures from one or few IPs, varying usernames, rapid reconnects	Count failures per client IP over a 5-minute window
Backend auth outage	All auth fails at once, including previously working clients	Check Dovecot or saslauthd process and SASL socket
Client credential error	Sporadic failures from specific clients, same username each time	Test auth manually for the affected user
SASL mechanism mismatch	“no SASL authentication mechanisms” in logs	Compare `smtpd_sasl_security_options` against mechanisms the backend offers
SASL socket path error	“cannot connect to saslauthd server” or “No such file or directory”	Verify socket path accounts for Postfix chroot

Quick checks

Safe, read-only. Adjust the log path for your distribution: /var/log/mail.log on Debian/Ubuntu, /var/log/maillog on RHEL/CentOS. On systemd hosts, prefer journalctl.

# Count SASL auth failures in the last 5 minutes (systemd)
journalctl -S '5 min ago' --no-pager | grep 'SASL.*authentication failed' | wc -l

# Top client IPs by failure count
grep 'SASL.*authentication failed' /var/log/mail.log | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq -c | sort -rn | head -20

# Successful vs failed auth totals
success=$(grep 'SASL.*authentication succeeded' /var/log/mail.log | wc -l)
failure=$(grep 'SASL.*authentication failed' /var/log/mail.log | wc -l)
echo "Success: $success  Failure: $failure"

# Check SASL backend type, socket path, security options, enable state
postconf smtpd_sasl_type smtpd_sasl_path smtpd_sasl_security_options smtpd_sasl_auth_enable

# Check auth rate limit (empty value means no limit configured)
postconf smtpd_client_auth_rate_limit anvil_rate_time_unit

# Check backend process health
ps aux | grep -E 'dovecot|saslauthd' | grep -v grep

# Verify Dovecot SASL socket (Postfix chroots to /var/spool/postfix on Debian/Ubuntu)
ls -la /var/spool/postfix/private/auth

# Check submission and smtps service definitions in master.cf
postconf -M | grep -E '^(submission|smtps)/'

How to diagnose

flowchart TD
    A["SASL auth failures in log"] --> B{"All clients failing
simultaneously?"}
    B -- "Yes" --> C["Backend auth outage"]
    B -- "No" --> D{"Few IPs, many
different usernames?"}
    D -- "Yes" --> E["Credential brute force"]
    D -- "No" --> F["Client credential error
or mechanism mismatch"]
    C --> C1["Check Dovecot/saslauthd process"]
    C --> C2["Verify SASL socket path and perms"]
    E --> E1["Enable smtpd_client_auth_rate_limit"]
    E --> E2["Deploy fail2ban on ports 587/465"]
    F --> F1["Test auth manually for affected user"]

Determine whether all auth is failing or only some. Run the success-versus-failure check. If success is zero and failures span multiple clients and IPs, the backend is likely down. If successes coexist with failures, the issue is per-client: brute force or a credential problem.
If only some clients fail, examine the IP distribution. A single IP or small set generating dozens of failures with many different usernames is brute force. A specific client failing repeatedly with the same username is a credential error.
If all auth fails, check the backend process. For Dovecot SASL: verify the process is running and the socket at /var/spool/postfix/private/auth exists with mode 0660, owned by postfix:postfix. If the socket is missing, Dovecot is either not running or its unix_listener path does not match the Postfix chroot path. For Cyrus SASL: verify saslauthd is running. The message “cannot connect to saslauthd server” confirms saslauthd is unreachable.
Check for mechanism mismatch. If the log contains “no SASL authentication mechanisms,” the configuration is filtering out all mechanisms the backend offers. The common case: smtpd_sasl_security_options = noanonymous,noplaintext rejects PLAIN and LOGIN, while Dovecot only offers those two. On TLS-encrypted submission ports (587/465), plaintext mechanisms are safe because the transport is encrypted, so noplaintext is unnecessary there.
Verify SASL is enabled on the submission service. Check master.cf for the submission and smtps service entries. SASL must be explicitly enabled with smtpd_sasl_auth_enable = yes, either in main.cf or as a service-level override in master.cf. It is a common mistake to enable SASL globally but forget the submission service override.
Check whether a Postfix upgrade changed log format. Postfix 3.10 reportedly changed SASL-related logging to include sasl_method, sasl_username, and sasl_sender in reject lines. If you use fail2ban or a log-based alerting system, verify your filters match the new format after an upgrade. A filter that silently stops matching is worse than no filter.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
SASL auth failure rate	Distinguishes attack from baseline noise	More than 10 failures per minute from a single IP, or more than 10x baseline
Failures per client IP	Identifies brute-force sources	One IP generating most failures
Successful vs failed auth ratio	Detects total auth outage vs targeted attack	Ratio drops to zero successes across all clients
smtpd process count	Brute-force churn consumes process slots	Count approaching `maxproc` with “to limit” log messages
Connection rate per IP	Brute-force drives rapid reconnects	More than 100 connections per minute from one IP
Backend process health	SASL depends on Dovecot or saslauthd being alive	Process absent or restarting frequently
Outbound volume after auth success	Credential compromise enables spam relay	Sudden outbound queue spike following auth success from a suspicious IP

Fixes

Credential brute force

Enable smtpd_client_auth_rate_limit. This limits AUTH commands per client per time unit. anvil_rate_time_unit controls the window (default 60 seconds). The counter includes all AUTH commands, not just failures, so legitimate clients that authenticate successfully also consume quota.

# Limit to 20 AUTH commands per client per 60-second window
postconf -e 'smtpd_client_auth_rate_limit = 20'
postfix reload

Deploy fail2ban with correct port coverage. The default postfix-sasl jail may only block port 25 (smtp). Brute-force attacks target 587 (submission) and 465 (smtps). Ensure the ban action uses multiport covering all submission ports. After a Postfix 3.10 upgrade, test the filter regex against actual log lines from the new format.

Tune error limits. The defaults (smtpd_soft_error_limit = 10, smtpd_hard_error_limit = 20) are generous. Lowering them on submission ports forces faster disconnects of abusive clients, but also impacts legitimate users who mistype passwords multiple times.

Backend auth outage

Restart the backend process. If Dovecot or saslauthd is down, restarting resolves the immediate auth failure. Investigate the crash separately; Postfix logs will not reveal the backend’s root cause.

Fix the socket path. Postfix runs chrooted to /var/spool/postfix on Debian/Ubuntu by default. When smtpd_sasl_path = private/auth, Postfix looks for the socket at /var/spool/postfix/private/auth. The Dovecot unix_listener must be configured at that absolute path with mode 0660, user postfix, group postfix. If Dovecot creates the socket at a different path, Postfix cannot reach it through the chroot.

Check LDAP or Active Directory connectivity. If the backend proxies to a directory service, verify the directory server is reachable and responding within timeout. Network-backed authentication without proper timeout settings can hang smtpd processes indefinitely, causing them to accumulate and hit maxproc.

Client credential error

Test authentication manually. Generate an AUTH PLAIN credential string and test it against the submission port to reproduce the failure:

# Generate AUTH PLAIN base64 string (format: \0username\0password)
printf '\0user@example.com\0password' | base64

Connect to port 587 with STARTTLS and issue AUTH PLAIN <base64-string> to see the exact server response. This confirms whether the credentials are valid at the backend level.

Check for password rotation. If the failure started after a credential change, verify all clients and applications have been updated. App passwords may expire or be revoked without obvious notification to the user.

SASL mechanism mismatch

Remove noplaintext on TLS-protected submission ports. On ports 587 and 465 where TLS is enforced, PLAIN and LOGIN are safe because the transport layer is encrypted. Set smtpd_sasl_security_options = noanonymous on the submission service in master.cf.

Ensure Dovecot offers the expected mechanisms. Check the auth_mechanisms setting in Dovecot’s configuration. It should include plain login at minimum for submission port authentication.

Prevention

Set smtpd_client_auth_rate_limit before an attack starts to prevent brute-force traffic from exhausting smtpd process slots.
Configure fail2ban to cover all submission ports (25, 587, 465) from the start. Verify the ban action uses multiport.
Monitor Dovecot and saslauthd as independent services, not just as part of “Postfix is running.”
Alert on more than 10 SASL failures per minute from a single IP. More than 100 per minute sustained is an active attack.
Alert on success-to-failure ratio dropping to zero across all clients. This is the fastest signal of a backend outage.
After Postfix upgrades, test fail2ban filters against actual log lines before relying on them in production.

How Netdata helps

Per-second auth failure metrics. Netdata collects Postfix SASL authentication failure rates at per-second granularity, letting you spot a brute-force spike within seconds of onset rather than after a longer polling interval.
Correlation with smtpd process count. Brute-force attacks consume smtpd process slots through reconnect churn. Seeing auth failure rate and smtpd process count rise together confirms the attack is causing resource pressure, not just log noise.
Success-to-failure ratio tracking. Netdata surfaces both successful and failed auth counts, making a backend outage (ratio drops to zero for all clients) immediately distinguishable from a targeted attack (failures spike but successes continue for other clients).
Queue health correlation. If a successful brute-force leads to a compromised account sending spam, the outbound queue growth and bounce rate spikes become visible alongside the original auth failure signal, shortening the time from compromise to detection.