Tune Postfix anvil Rate Windows Without Guessing

Postfix anvil counts connections and requests per client, and this guide tunes its rate window with a reversible limit you can back out cleanly. It is not a command you run directly: anvil just keeps the counters that services such as smtpd consult when limits are configured. The examples use Postfix 3.8.6 on this machine.

Allow about fifteen minutes. You need shell access and permission to read Postfix configuration. The inspection commands are ordinary commands. Changing main.cf and reloading Postfix need root or equivalent service-administration privilege.

Safety boundary: rate limits can delay or reject legitimate mail. Test during a quiet period, start with a generous value, and watch logs and delivery before tightening anything. This guide does not touch master.cf or stop Postfix.

1. Confirm that anvil is installed and supervised

Check the package, the service entry and the defaults before you change a thing:

$ dpkg-query -W -f='${Package} ${Version}\n' postfix
postfix 3.8.6-1ubuntu0.1
$ postconf -M anvil
anvil      unix  -       -       y       -       1       anvil
$ postconf -h anvil_rate_time_unit anvil_status_update_time
60s
600s

The first value is the window used to calculate client connection and request rates. The second controls how often anvil logs peak usage. The exact package version and output will vary on your host, so treat the commands as the checkpoint, not the sample text pasted above.

Anvil runs under Postfix master. It accepts no network connections and offers no user-facing rate-control command of its own. Do not try to invoke anvil as if it were a standalone utility, because it is not one.

2. Inspect the limits that consume anvil's counters

Read the active values for the SMTP client limits. Read-only, no risk here:

$ postconf -h \
    smtpd_client_connection_count_limit \
    smtpd_client_connection_rate_limit \
    smtpd_client_message_rate_limit \
    smtpd_client_recipient_rate_limit \
    smtpd_client_auth_rate_limit
50
0
0
0
0

These values print in the order requested. On this host, 50 is the simultaneous connection limit, and the zeroes mean no limit for the other rates listed. A zero here does not mean "zero requests allowed", it means that limit is switched off. The connection-count limit is a different thing entirely from the per-window connection-rate limit, do not conflate them.

The limits are enforced by the SMTP service, while anvil just maintains the measurements behind them. If an anvil problem makes a limit unreliable, investigate the Postfix service and logs rather than assume that changing anvil's time window will fix it.

3. Choose the rate window

Keep the default unless you have a measured reason to change it. With 60s, rates get calculated over one minute. A shorter window reacts faster but keeps less history; a longer one smooths out bursts but holds client state for longer and eats more memory on a busy host.

Anvil keeps recent client information in memory only. There is no persistent database, so restarting the relevant process loses every counter. The service also needs connection and disconnect events to age rate information correctly, even when you are not limiting connections at all.

Got a documented target? Choose a value that states its unit clearly, 60s is far easier to review later than an unexplained bare number. Do not shorten the window just because a client looks noisy: work out first whether the traffic is a legitimate relay, a monitoring system, or genuine abuse.

4. Save and apply one modest limit

Save the current value first, so the change has an obvious undo command waiting:

$ old_rate=$(postconf -h smtpd_client_connection_rate_limit)
$ printf 'old connection-rate limit: %s\n' "$old_rate"
old connection-rate limit: 0

As root, set a deliberately modest example value of 30 connections per minute:

# postconf -e 'smtpd_client_connection_rate_limit = 30'
# postfix reload

This changes main.cf and asks the running Postfix instance to reread it. It does not touch the anvil window itself. The limit applies to each client identity as Postfix sees it, so clients behind a NAT gateway or proxy can end up sharing one apparent address.

Checkpoint: verify the stored value after the reload:

$ postconf -h smtpd_client_connection_rate_limit
30

Do not treat that output as proof a client has been throttled. It only proves Postfix holds the configured value. Confirm actual behaviour through normal SMTP logs and client impact, not by generating an artificial connection storm to test it.

5. Watch the evidence and undo safely

Anvil logs peak count and rate information at the configured status-update interval, but only for activity that is actually concurrency- or rate-limited. Check the Postfix log using whatever logging system your host runs. For a systemd journal, an ordinary read-only check is:

$ journalctl -u postfix --since '15 minutes ago' --no-pager
# review anvil and smtpd records for unexpected peaks or rejects

Recovery: legitimate clients getting limited? Restore the value captured earlier. The example below is root-only because it writes configuration and reloads the service:

# postconf -e "smtpd_client_connection_rate_limit = $old_rate"
# postfix reload
$ postconf -h smtpd_client_connection_rate_limit
0

Shell holding old_rate gone? Check version-controlled configuration or the current main.cf backup rather than guessing at a number. Setting the parameter to 0 disables this particular rate limit, but it will not restore a previous non-zero policy for you.

6. Avoid the common interpretation errors

Done means