Limit on the amount of memory and CPU that Postfix will use for
rewriting addresses in message headers. The limit is expressed as
a number of tokens. Tokens text that do not fit are discarded.
This limit is enforced by the cleanup
header rewriting code.
The following parameters restrict the use of file system storage:
- message_size_limit (default: 10240000 bytes)
- The maximal size of a Postfix queue file, including envelope
information (sender, recipient, etc.).
- queue_minfree (default: no restriction)
- How many bytes of free space are needed in the queue file
system. The SMTP server declines inbound
mail delivery requests when there is insufficient space (the mail
will be accepted once enough space becomes available). There is
no default limit; however, it seems like a good idea to require at
least several times $message_size_limit so that the mail
system won't get stuck on a single large message.
- bounce_size_limit (default: 50000 bytes)
- How much of an undelivered message is sent back to the sender.
Object count limits
Once the sizes of memory objects have been limited, the next step
to implement Postfix's finite memory budget is to limit the number
of in-memory object instances.
- qmgr_message_recipient_limit (default: 20000)
- An upper bound on the number of queue
manager in-memory recipient address data structures. This
parameter also controls the number of instances of other in-memory
data structures. See, for example, the delivery rate control documentation.
- qmgr_message_active_limit (default: 20000)
- An upper limit on the number of messages in the active
queue. For an introduction to the Postfix queue organization see
the Postfix overview documentation.
- duplicate_filter_limit (default: 1000)
- How many recipient addresses the local
delivery agent and address cleanup
daemon remember when delivering a message. A recipient address is
ignored when it is found in the remembered list.
- virtual_alias_expansion_limit (default: 1000)
- This limits the number of addresses that result from each original
recipient by virtual alias expansion in the
address cleanup daemon. By default each original recipient is rewritten
via $virtual_alias_maps to at most 1000 actual recipients.
- virtual_alias_recursion_limit (default: 1000)
- This limits the recursive nesting of virtual alias expansion performed
by the address cleanup daemon. Virtual
alias expansion is recursive, and stops only when an address is not
found in the table, when an address maps to itself, or when the
recursion limit is reached.
Time limits
External commands are given a finite time for completion. Such
commands are run by the local delivery
agent when it finds a "|command" destination in an alias database, :include: file or .forward file. The pipe mailer implements an alternative way
to pipe mail into external commands.
- command_time_limit (default: 1000 seconds)
- How long the local delivery agent
will wait before aborting an external command.
- service_name_time_limit (default:
$command_time_limit)
- The time limit for delivery to external commands via the
pipe mailer. For service_name, substitute the service
name (the first field in the master.cf file).
Acquiring exclusive file locks
Internally, the Postfix programs cooperate in a very disciplined
manner and rarely need to fight for exclusive file access. However,
access conflicts may happen on the outside, for example, when mail
has to be delivered while a user is accessing her mailbox. Postfix
supports two types of file locks:
- Internal locks, implemented with the fcntl() or
flock() system primitives.
- External locks, implemented as files named file.lock.
Depending on the host system, Postfix uses one method or both.
The following configuration parameters control how Postfix deals
with file locks:
- deliver_lock_attempts (default: 5)
- The number of times to try locking a file before giving up.
- deliver_lock_delay (default: 1 second)
- How long to wait between attempts to lock a file.
- stale_lock_time (default: 500)
- How old an external lock file may be before it is forcibly
removed.
Error recovery
Under conditions of severe stress, available system resources may
be insufficient to accommodate Postfix's needs. The world may also
seem to fall apart when a Postfix configuration file is broken, or
when a Postfix program is defective.
The general approach taken in the face of disaster is to terminate
with a fatal run-time error (or with a panic in case of software
problems), and to try again after some time (the master daemon will restart processes after
some delay). Each failed attempt is logged; hopefully, someone will
notice the problem and fix it.
Some recovery strategies were implemented very early during Postfix
development, and haven't been made configurable yet. What follows
is the beginning of a growing list of recovery control parameters:
- fork_attempts (default: 5 times)
- The number of times to attempt to create a new process before
giving up.
- fork_delay (default: 1 second)
- The delay between attempts to create a new process.
- transport_retry_time (default: 60 seconds)
- The amount of time between queue manager attempts to contact
an apparently defunct Postfix delivery service.
Up one level | Basic
Configuration | UCE Controls | Rate Controls | Resource Controls | Address Manipulation