What a Volumetric SMTP Attack Looks Like

Most people think of spam as a content problem — suspicious phrases, dodgy links, fake sender names. And most of the time, that's correct. But there's a category of attack where content filtering isn't even the right tool: volumetric attacks, where the threat is sheer connection volume rather than message content.

A volumetric SMTP attack typically takes one of three forms. The first is a simple connection flood: a single IP or a coordinated range of IPs opens hundreds or thousands of simultaneous TCP connections to port 25, overwhelming your server's connection queue before a single message body is ever transmitted. Your mail server spends all its resources negotiating TLS handshakes and never gets to the business of accepting or rejecting mail.

The second form is a dictionary attack on recipients. The attacker sends RCPT TO commands for thousands of email addresses — first.last@yourdomain.com, jsmith@yourdomain.com, info@yourdomain.com — hoping to enumerate valid mailboxes or deliver to whatever sticks. Even if none of the messages are spam by content, your server is doing expensive recipient lookups for each one.

The third form is backscatter spam. Attackers forge your domain as the sender in their spam campaigns. When those messages are rejected by recipient servers, the bounces come back to you — thousands of NDR messages clogging your inbound queue, none of which you asked for.

In all three cases, a content-based filter running on the message body is the wrong layer to defend at. You need to stop connections before they consume resources.

Why the Proxy Layer Is the Right Place to Rate Limit

An SMTP proxy sits in front of your actual mail server. It accepts the TCP connection, negotiates SMTP, and only forwards traffic to your downstream server when it decides to. This gives it a uniquely powerful position: it can enforce rules purely based on the connection itself — IP address, connection rate, recipient count — without ever seeing message content.

When rate limiting is implemented at the proxy layer rather than on the mail server itself, your mail server is completely shielded. It never receives the flood. Its queues stay clear. Its processes stay available for legitimate mail. The proxy absorbs the attack or simply drops connections silently.

This is the same principle behind putting a CDN in front of a web server for DDoS protection — you're offloading the problem to a layer designed to handle volume, not content.

Key insight: Rate limiting and spam scoring are complementary, not competing strategies. Rate limiting handles volumetric abuse; content scoring handles deceptive content. You need both.

Per-Minute vs Per-Hour Limits: How to Tune Them

Rate limits work on time windows. A per-minute limit of 10 connections from a single IP means the 11th connection within any 60-second window gets dropped or deferred. A per-hour limit of 200 catches slow-and-low attacks that stay under per-minute thresholds but accumulate over time.

The right values depend on your traffic patterns. For a typical small-to-medium business mail server receiving legitimate mail from transactional services, cloud providers, and other businesses, you'll rarely see more than 5-10 connections per minute from a single IP. Legitimate email infrastructure sends and then backs off.

Here's a sample configuration showing how rate limits are expressed in Indition Spam Killer's proxy config:

rate_limiting:
  enabled: true
  per_ip:
    connections_per_minute: 10
    connections_per_hour: 120
    rcpt_commands_per_minute: 30
    rcpt_commands_per_hour: 200
  action: defer          # Options: defer, drop, block
  defer_code: "421"
  defer_message: "Too many connections, try again later"
  block_duration_minutes: 60

  # Dictionary attack protection
  unknown_recipient_threshold: 5   # Block after N unknown recipients from same IP
  unknown_recipient_window: 300    # Within this many seconds

The rcpt_commands_per_minute setting is particularly useful for stopping dictionary attacks. A legitimate sending server sending a single message to a mailing list will issue many RCPT TO commands in sequence — but they'll be for known-valid addresses. An attacker doing recipient enumeration will trip the unknown recipient threshold quickly.

Blocking vs Rate Limiting: Choosing the Right Response

When a connection exceeds your rate limit, you have two basic choices: defer it or block it.

Deferring means responding with a 4xx SMTP code — "try again later." This is the right response for cases where you're not certain the sender is malicious. Legitimate sending infrastructure respects deferrals and will retry after a backoff period. An attack tool may not bother. Deferral has the advantage of not causing permanent delivery failures for edge cases where a legitimate server briefly exceeds your threshold.

Blocking (dropping the connection silently or responding with a 5xx code) is appropriate when you've accumulated strong evidence of abuse — an IP that has tripped your limits repeatedly, or that appears on known blocklists. Be more conservative with hard blocks than with deferrals; a misfired block causes permanent mail loss.

Temporary IP blocks (the block_duration_minutes setting above) are a good middle ground: block aggressively during an active attack, but automatically lift the block after an hour so you're not permanently blacklisting an IP that may have been a compromised machine now cleaned up.

Whitelisting Your Own Outbound Mail Server

One critical configuration step that's easy to overlook: make sure your own outbound mail server is whitelisted from rate limits. Many organizations send from the same IP range they receive on, and your transactional email systems (CRM, billing, support) may legitimately exceed per-minute connection thresholds when sending bulk notifications.

rate_limiting:
  whitelist:
    - ip: "203.0.113.10"        # Primary outbound mail relay
      comment: "Internal relay - exempt from rate limits"
    - cidr: "203.0.113.0/24"    # Entire outbound IP range
      comment: "Office and server block"
    - ip: "198.51.100.42"
      comment: "Transactional email provider (SendGrid)"

Also whitelist IP ranges for any email service providers you use — your marketing platform, your CRM's email feature, your support tool's notification system. These services send in bursts that would look suspicious without context.

Signs You're Being Attacked: What to Look for in Logs

Rate limiting works best when you're monitoring for it. Several log patterns indicate you're under a volumetric attack:

  • Sudden spike in connection attempts from a single /24 or /16 subnet — legitimate senders use a variety of IPs; attackers often come from a single netblock.
  • High ratio of RCPT TO commands to DATA commands — legitimate senders issue one RCPT per message (or a few for list messages). An attacker enumerating recipients will issue hundreds of RCPT commands and never reach DATA.
  • Rapid sequence of 550 unknown user responses — each unknown recipient in a dictionary attack produces a 550. A burst of these from one IP is a clear signal.
  • NDR flood in your inbound queue — sudden influx of bounce messages for addresses you never sent to indicates a backscatter attack using your domain as the forged sender.
  • Connection queue depth climbing — if your proxy's connection queue is consistently near capacity during off-hours, you're absorbing a connection flood rather than processing legitimate mail.

Indition Spam Killer's admin dashboard surfaces all of these signals in the per-domain traffic view, with rate-limit trigger counts broken out by IP so you can see exactly who is tripping your thresholds and how often.

Volumetric attacks don't require sophisticated filtering to defeat — they just require the right enforcement point. Moving that enforcement to the proxy layer, before your mail server ever sees the traffic, is the simplest and most effective thing you can do to protect mail infrastructure that needs to stay available under pressure.