Rate Limiting and Abuse Prevention for Mail Servers

Two Layers of Rate Limiting

Rate limiting operates at two independent levels: the MTA level (Postfix's built-in anvil service) and the filtering engine level. Both are necessary because they catch different types of abuse.

MTA-Level Rate Limiting

Postfix's anvil service tracks connection rates per client IP and enforces configurable limits:

smtpd_client_connection_rate_limit = 20
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 50
anvil_rate_time_unit = 60s
smtpd_client_event_limit_exceptions = $mynetworks

These limits prevent a single IP from overwhelming the server with connections. Twenty connections per minute is generous enough for any legitimate mail server (which typically opens one or two connections at a time) but low enough to throttle automated attacks.

The $mynetworks exemption is important — trusted networks (localhost, internal services, Docker containers) should not be rate-limited, as they may legitimately send bursts of mail.

Filter-Level Rate Limiting

The spam filtering engine can enforce more granular rate limits tracked in Redis:

• Per sender address: 5 messages per minute, 30 per hour
• Per sender domain: 20 per minute, 100 per hour
• Per recipient: 10 per minute
• Per source IP: 10 per minute, 50 per hour

When a limit is exceeded, the sender receives a 450 (temporary failure) response, which tells legitimate servers to retry later. This is preferable to a 550 (permanent failure) because it does not generate bounces for legitimate mail that happens to arrive during a burst.

A sender must pass both layers. The MTA limits catch connection-level floods. The filter limits catch application-level abuse patterns (like a single sender address sending to thousands of recipients).

Anti-Abuse Hardening

Several small Postfix configuration changes collectively make the server significantly harder to abuse:

Disable VRFY. The VRFY command allows remote clients to probe for valid email addresses. Spammers use it for address harvesting. There is no legitimate reason to leave it enabled:

disable_vrfy_command = yes

Minimize the SMTP banner. The default banner reveals the Postfix version number, which helps attackers identify known vulnerabilities:

smtpd_banner = $myhostname ESMTP

Set reasonable queue lifetimes. A message that cannot be delivered within 24 hours is unlikely to be delivered at all. The default 5-day lifetime causes queues to accumulate undeliverable messages:

maximal_queue_lifetime = 1d
bounce_queue_lifetime = 4h

Intrusion Prevention with Fail2ban

Fail2ban monitors log files across all services and bans IPs that exhibit abusive behavior. For a mail server, the critical jails are:

• SMTP authentication failures — catches brute-force attacks against the submission port
• Postfix abuse patterns — catches clients that trigger repeated errors
• RBL-listed senders — a single hit from a known-bad IP warrants an immediate ban
• Recidive — a meta-jail that escalates bans for IPs that keep getting banned across different services

The recidive jail is particularly important: an IP that triggers SSH bans, then SMTP bans, then HTTP bans is clearly hostile and should be banned across all ports for an extended period (a week is reasonable).

The Feedback Loop

A powerful pattern is to create a feedback loop between the intrusion prevention system and the spam filter. When Fail2ban detects a specific abuse pattern — such as Gmail throttling responses, which indicate degrading IP reputation — it can automatically add the offending IP to the spam filter's dynamic blacklist.

This means the spam filter starts rejecting mail from that IP immediately, without waiting for the next scan cycle. The intrusion prevention system feeds intelligence to the spam filter, and the spam filter's improved accuracy prevents further reputation damage.

This closed-loop defense is more effective than either system operating independently.