# Postfix Configuration - Resource Controls

Up one level | Basic Configuration | UCE Controls | Rate Controls | Resource Controls | Address Manipulation

## Introduction

The Postfix system is designed to run within a finite memory budget. To this end, there are configurable limits on the size of in-memory objects such as text line fragments, on the number of instances of such objects, and on the time an operation may take. In addition, strategies are in place for dealing with resource exhaustion. The idea is to keep running under conditions of stress, without making the problem worse.

- Object size limits

- Object count limits

- Time limits

- Acquiring exclusive file locks

- Error recovery

## Object size limits

The first step towards a fixed memory resource budget is to limit the size of each in-memory object. Once the size of in-memory objects is limited, total memory consumption is limited by limiting the number of object instances. Simple, no?

line_length_limit (default: 2048 bytes)
  How long a line of text can be before it is broken up into pieces. All Postfix perimeter programs (SMTP server, SMTP client, local pickup and local delivery) enforce this line length limit when reading data from an untrusted source. Long lines are reconstructed upon delivery.

header_size_limit (default: 102400 bytes)
  How much text may be carried in a multi-line message header. Header text that does not fit in $header_size_limit bytes is discarded. This limit is enforced by the cleanup header rewriting code.

header_address_token_limit (default: 10240 tokens)
  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.

extract_recipient_limit (default: 10240 recipients)
  How many recipients Postfix will extract from message headers before it gives up. This limits the damage that a run-away program can do with "sendmail -t".

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