$ guides / postfix / postfix-connection-storm-dictionary-attack ▌

Operations Guides

Postfix connection storm: dictionary attacks, anvil rate limits, and connection floods

A flood of inbound SMTP connections hits your Postfix server. The smtpd process count climbs, file descriptors tighten, and legitimate mail starts queuing behind connection churn. Throughput drops even though the system is busy. The likely cause is a connection storm: a dictionary attack harvesting recipient addresses, a credential-stuffing run against your submission port, or a misbehaving client with a broken connection pool.

The distinguishing signal is the ratio of connections to messages. A dictionary attack opens many connections, probes for valid recipients, and disconnects without delivering mail. A legitimate flash crowd opens connections that carry real messages. Telling them apart quickly determines whether you throttle, block, or scale.

Postfix has two built-in defenses: anvil(8), the in-memory rate limiter shared across all smtpd processes, and postscreen(8), which filters zombies before they reach smtpd. Both need to be configured and monitored to survive a sustained flood.

How Postfix handles connection floods

When inbound connections spike, every smtpd process that accepts a connection holds a file descriptor and memory for the duration of the SMTP transaction. If connections arrive faster than smtpd processes can complete or time out, the process pool fills toward its maxproc limit (default 100). Once all smtpd slots are consumed, new connections queue at the kernel level or are refused entirely.

Anvil tracks per-client connection counts and rates in volatile memory. It enforces limits you configure via smtpd_client_connection_count_limit, smtpd_client_connection_rate_limit, and related parameters. Because anvil uses volatile memory only, all counters reset to zero whenever the process terminates or Postfix restarts. An attacker who detects a restart window can reconnect without rate-limit pressure.

Postscreen sits in front of smtpd and applies lightweight tests: pregreet detection, DNSBL lookups, pipelining checks. It sheds zombie clients before they consume an smtpd process. In its default mode, postscreen blocks no clients, making it useful for non-destructive testing before you enable enforcement.

flowchart TD
    A[Connection flood begins] --> B[anvil tracks per-client counts/rates]
    B --> C{Limits configured?}
    C -- No limits --> D[smtpd pool fills to maxproc]
    C -- Limits set --> E[anvil rejects excess with 421]
    D --> F[New connections queued or refused]
    F --> G[Legitimate mail delayed]
    E --> H[Zombies shed before smtpd]
    D --> I[File descriptor pressure]
    I --> J[Possible FD exhaustion]

Common causes

Cause	What it looks like	First thing to check
Dictionary / recipient-harvest attack	Many connections from distributed IPs, high RCPT reject count, few or zero messages delivered	Reject log lines for “Recipient address rejected” or “User unknown”
Credential-stuffing run	Spike in SASL authentication failures on port 587, low successful auth rate	SASL failure count and source IPs
Misbehaving client connection pool	Many connections from a single IP, legitimate sender domain, connections open and close rapidly	Per-IP connection concentration in logs
NAT or proxy aggregation	Single apparent client IP hitting connection count limits despite being multiple real clients behind NAT	Whether the client IP belongs to a known NAT range or corporate proxy
No rate limits configured	Connections never throttled, smtpd pool saturates under any load spike	postconf output for smtpd_client_connection_count_limit and smtpd_client_connection_rate_limit

Quick checks

# Check daemon responsiveness and greeting
time curl --max-time 2 telnet://localhost:25

# Current smtpd process count
ps aux | grep smtpd | grep -v grep | wc -l

# Connections per client IP in recent logs
grep 'connect from' /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Established connections on SMTP ports
ss -tn | grep -E ':25\b|:587\b' | wc -l

# Reject rate by category (dictionary attacks show high RCPT rejects)
grep 'NOQUEUE: reject' /var/log/mail.log | tail -100 | grep -oE '(Recipient address rejected|Sender address rejected|relay access denied|Client host rejected)' | sort | uniq -c | sort -rn

# SASL auth failure rate (credential stuffing on submission port)
grep 'SASL.*authentication failed' /var/log/mail.log | wc -l

# Current anvil rate-limit configuration
postconf -h smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit smtpd_client_recipient_rate_limit anvil_rate_time_unit

# Check if postscreen is enabled in master.cf
postconf -M | grep postscreen

# Master.cf maxproc settings for smtp/smtpd services
postconf -M | awk '$1 ~ /^smtp/ {print $1, $2, "maxproc:", $7}'

# File descriptor usage across Postfix processes
for pid in $(pgrep -f postfix); do ls /proc/$pid/fd 2>/dev/null | wc -l; done | paste -sd+ | bc

# Anvil status messages in logs
grep 'anvil' /var/log/mail.log | tail -10

How to diagnose it

Confirm it is a connection storm, not a delivery problem. If active and deferred queues are stable but smtpd process count is high, you are in a connection storm. If queues are growing instead, see Postfix active queue saturation or Postfix deferred queue growing.
Measure connections per message. Count inbound connections versus accepted messages over the same five-minute window. A dictionary attack shows a high ratio of connections to delivered messages, often 10:1 or worse. A flash crowd shows proportional throughput.
Identify per-IP concentration. If a single IP or small CIDR range dominates the connection log, the cause is either a misbehaving client or a NAT aggregation point. If connections are distributed across many IPs with few connections each, suspect a botnet or coordinated harvest.
Check reject categories. High “Recipient address rejected” or “User unknown” counts indicate recipient harvesting. High “relay access denied” indicates relay probing. High SASL authentication failures indicate credential stuffing against port 587.
Check process pool saturation. Look for “to limit” messages in the log. These are info-level entries that are easy to miss. If smtpd is at maxproc, new connections are being delayed or refused. Confirm the configured maxproc from master.cf.
Verify anvil is active and limits are set. Anvil only enforces limits you configure. The default for smtpd_client_connection_count_limit is 50, but the default for smtpd_client_connection_rate_limit is 0 (no limit). If rate limits are not set, per-client throttling never triggers.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
smtpd process count vs maxproc	Indicates process pool saturation	Sustained above 80% of maxproc
Connections per client IP per minute	Reveals concentration and attack patterns	Single IP above 50 concurrent or above 100 per minute sustained
Connections-per-message ratio	Distinguishes attack from flash crowd	Ratio above 5:1 suggests probing, not delivery
RCPT reject rate	Detects recipient-harvest dictionary attacks	Sudden spike from baseline
SASL auth failure rate	Detects credential stuffing on submission port	Above 100 failures per minute from single IP
File descriptor usage	Approaching ulimit causes cascading failures	Above 80% of soft limit
Established connections on port 25 or 587	Raw concurrency indicator	Sustained deviation from baseline
“to limit” log messages	Services hitting maxproc	Any occurrence for smtpd or qmgr

Fixes

Enable anvil rate limits

The most direct defense is configuring per-client connection and rate limits:

# Set connection count limit (default is 50)
postconf -e 'smtpd_client_connection_count_limit = 50'

# Set connection rate limit per time unit (default is 0 = no limit)
postconf -e 'smtpd_client_connection_rate_limit = 20'

# Optional: limit messages and recipients per client
postconf -e 'smtpd_client_message_rate_limit = 100'
postconf -e 'smtpd_client_recipient_rate_limit = 100'

# Auth rate limiting requires Postfix 3.1+
postconf -e 'smtpd_client_auth_rate_limit = 60'

# Reload to apply
postfix reload

Tradeoffs: Rate limits that are too aggressive will reject legitimate clients behind NAT or corporate proxies. The parameter smtpd_client_event_limit_exceptions (default: $mynetworks) exempts trusted IPs from connection and rate limits. Adjust this if legitimate high-volume senders are affected. Anvil state is lost on restart, so there is a brief window after any restart where limits are not enforced.

Reject unlisted recipients

The primary defense against dictionary attacks is reject_unlisted_recipient in your smtpd_recipient_restrictions. This causes Postfix to reject mail for recipients that do not exist before accepting the message into the queue:

# Verify current restrictions include reject_unlisted_recipient
postconf -h smtpd_relay_restrictions

# For relay or gateway setups, ensure relay_recipient_maps is populated
postconf -h relay_recipient_maps

# Test map lookup for a known invalid recipient
postmap -q nonexistentuser@yourdomain.com hash:/etc/postfix/relay_recipients

Tradeoffs: If you use local_recipient_maps, Postfix validates only recipients it knows about. For relay or gateway setups, you must maintain relay_recipient_maps or queries against your directory. Without recipient validation, Postfix accepts everything and bounces later, which consumes resources on both acceptance and bounce generation and feeds backscatter.

Enable and tune postscreen

Postscreen filters zombies before they consume smtpd processes. It applies pregreet detection, DNSBL lookups, and protocol violation checks.

There is no postscreen_enable main.cf parameter; postscreen is enabled by editing master.cf (see POSTSCREEN_README).

Enabling postscreen requires master.cf changes: the smtp service on port 25 must point at postscreen instead of smtpd, and the postscreen, dnsblog, and tlsproxy services must be enabled. See the POSTSCREEN_README for the exact master.cf changes.

Once postscreen is running, configure enforcement in main.cf:

# Observe mode (default - logs but does not block)
postconf -h postscreen_greet_action postscreen_dnsbl_action postscreen_pipelining_action

# Enable enforcement after observing what postscreen catches
postconf -e 'postscreen_greet_action = enforce'
postconf -e 'postscreen_dnsbl_action = enforce'

Tradeoffs: Postscreen is not an SMTP proxy. It does not announce AUTH, XCLIENT, or XFORWARD. Do not use it on submission ports (587) used by end-user mail clients. Postscreen adds a brief delay for new clients on first connection as it runs its tests, which is by design but can surprise senders who monitor connection latency.

Block or throttle attack sources

For immediate relief during an active attack, blocking at the firewall is more efficient than at the application layer:

# WARNING: firewall rules affect all traffic from the target IP, not just SMTP.
# Block a specific IP via iptables for large-scale attacks:
# iptables -I INPUT -s <attack_ip> -p tcp --dport 25 -j DROP

# Or use Postfix access maps for surgical, SMTP-only control
postconf -e 'smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access'

Use Postfix-level blocking when you need per-sender or per-recipient granularity. Use firewall-level blocking when you need to drop thousands of IPs without consuming smtpd process slots.

Handle credential stuffing on submission port

If the attack targets port 587 specifically:

# Auth rate limiting requires Postfix 3.1+
postconf -e 'smtpd_client_auth_rate_limit = 10'

# Consider fail2ban or similar for repeat offenders
# Ensure Postfix log format is compatible with your tooling

Prevention

Configure anvil limits proactively. Do not wait for an attack. Set smtpd_client_connection_count_limit and smtpd_client_connection_rate_limit to values appropriate for your traffic. The default count limit is 50. The default rate limit is 0, meaning no rate limiting occurs at all until you set it.
Enable reject_unlisted_recipient. This is the single most effective defense against dictionary attacks. Without it, Postfix accepts mail for any recipient and generates bounces for invalid ones, consuming smtpd slots and queue resources.
Deploy postscreen. Start in observe mode (the default, which blocks no clients), analyze what it catches, then enable enforcement. Postscreen stops zombies before they reach smtpd, saving process slots and file descriptors for legitimate mail.
Monitor connections per message. This ratio is your early warning system. A sudden increase means either an attack or a client misconfiguration.
Account for NAT and proxy environments. If your legitimate clients appear as a single IP due to NAT, they can trigger false rate-limit hits. Use smtpd_client_event_limit_exceptions to exempt trusted ranges.
Plan around anvil restart behavior. Because anvil loses all state on restart, schedule restarts during low-traffic windows and understand that there is a brief enforcement gap after every restart.
Understand stress-adaptive behavior. Postfix 2.5 and later automatically restarts smtpd with aggressive timeout and error-limit settings when all smtpd processes are busy. Once stress mode activates for a process, it persists for the lifetime of that smtpd process and does not automatically de-escalate when connections drop. The default stress settings include smtpd_timeout of 10 seconds, smtpd_hard_error_limit of 1, and smtpd_junk_command_limit of 1. Be aware that smtpd_hard_error_limit=1 can cause significant delays with legitimate mailing lists that contain a few inactive user names.

How Netdata helps

Correlate connection rate with smtpd process count. Per-second metrics let you see exactly when connection spikes translate into process pool saturation, and whether anvil limits are shedding load or letting it through.
Track connections per message ratio in real time. When this ratio diverges sharply from baseline, it is the clearest signal of a dictionary or probing attack versus a legitimate flash crowd.
Monitor file descriptor usage alongside process counts. Correlating fd usage with smtpd process counts shows when you are approaching ulimit before connections start failing.
Surface reject rate by category. Tracking RCPT rejects, relay denials, and SASL auth failures separately lets you classify the attack type and target immediately rather than parsing logs under pressure.
Alert on stress-adaptive behavior. Detect when Postfix enters stress mode so you can investigate before legitimate mail is affected by aggressive stress-mode limits.