Postfix Rate Controls Postfix Rate ControlsNote: this web page is no longer maintained. It exists only to avoid breaking links in web pages that describe earlier versions of the Postfix mail system.
Up one level | Basic Configuration | UCE Controls | Rate Controls | Resource Controls | Address ManipulationOn the inbound side, the Postfix SMTP server has defenses in place against malicious or confused clients. They won't protect against an all-out denial of service attack on your infrastructure, but then nothing will except pulling the plug.
Unless indicated otherwise, all parameters described here are in the main.cf file. If you change parameters of a running Postfix system, don't forget to issue a postfix reload command.
You can override this setting for specific Postfix daemons by editing the master.cf file. For example, if you do not wish to receive 100 SMTP messages at the same time, you could specify:
# ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== . . . smtp inet n - - - 5 smtpd . . .
The Postfix queue manager comes to the rescue. This program implements the analog of the TCP slow start flow control strategy: when delivering to a site, send a small number of messages first, then increase the rate as long as all goes well; back off in the face of congestion.
The initial_destination_concurrency parameter (default: 2) controls how many messages are initially sent to the same destination before adapting delivery concurrency. Of course, this setting is effective only as long as it does not exceed the process limit and the destination concurrency limit for the specific mail transport channel.
The default_destination_concurrency_limit parameter (default: 20) controls how many messages may be sent to the same destination simultaneously. You can override this setting for specific delivery channels (local, smtp, uucp etc.). The main.cf file recommends the following:
A destination concurrency limit of 20 for SMTP delivery seems enough
to noticeably load a system without bringing it to its knees. Be
careful when changing this to a much larger number.
You can override this setting for specific Postfix delivery agents
(smtp, uucp, etc.). For example:
You must be careful when increasing the recipient limit; some SMTP
servers abort the connection when they run out of memory or when
a hard recipient limit is reached, so the mail won't get through.
The smtpd_recipient_limit parameter (default: 1000)
controls how many recipients the SMTP server will take per delivery.
That's more than any reasonable SMTP client would send. The limit
exists just to protect the local mail system against a malicious
or confused client.
A small site that is on-line only part of the time, and
that wants to defer all deliveries until the command sendmail
-q is executed (e.g., from a PPP dialout script) would use:
An ISP can use the defer_transports feature for customers
that are off-line most of the time. The customer can trigger delivery
by issuing an ETRN command at the SMTP port. The following
examples show how to configure such a customer:
You can specify any number of transports here. The example gives
just one.
The [] are necessary to avoid MX lookups, which might point to your
local machine. The second entry is necessary only if you want to
relay mail for customer subdomains.
This is just the master.cf entry for regular SMTP, with the
first field changed to hold.
As you would expect, this whole process is governed by a bunch of
little parameters.
Some defenses are part of a more general strategy: for example,
how long a line of text may be before it is broken up into pieces,
and how much text may be carried in a multi-line message header.
See the resource controls documentation
for details.
The Postfix SMTP server increments a
per-session error counter whenever a client request is unrecognized
or unimplemented, or whenever a client request violates UCE restrictions or other reasons. The error
counter is reset when a message is transferred successfully.
As the per-session error count increases, the SMTP server changes
behavior. The idea is to limit the damage by slowing down the
client. The behavior is controlled by the following parameters:
Unfortunately, the Postfix SMTP server does not yet know how to
limit the number of connections from the same client,
other than by limiting the total number of SMTP server processes
(see process limit). Things could be worse:
some mailers don't even implement an SMTP server process limit.
That's of course no excuse. I'm still looking for a good solution.
Recipient limits
The default_destination_recipient_limit parameter (default:
50) controls how many recipients a Postfix delivery agent (smtp,
uucp, etc.) will send with each copy of an email message.
If an email message has more than
$default_destination_recipient_limit recipients at the same
destination, the list of recipients will be broken up into smaller lists,
and multiple copies of the message will be sent.
would limit the number of recipients per UUCP delivery to 100.
Always postponing delivery
The defer_transports parameter allows you to specify what
mail should always be deferred until Postfix is explicitly asked
to deliver.
Backoff from unreachable hosts
When a Postfix delivery agent (smtp, local, uucp, etc.)
is unable to deliver a message it may blame the message itself or
the receiving party.
Slowing down bad clients
First of all, no defense will protect against an all-out denial of
service attack. I just don't want to raise impossible expectations.
But there are a few simple things one can do in order to deal with
confused or malicious client programs.
Up one level |
Basic Configuration | UCE
Controls | Rate Controls | Resource
Controls | Address Manipulation