This document presents an overview of the Postfix architecture,
and is the place where you find a pointer to every Postfix command
or server program. The text gives the general context in which
each command or server program is used, and provides pointers to
documents with specific usage examples and background information.
Topics covered by this document:
When a message enters the Postfix mail system, the first stop
on the inside is the incoming queue. The figure below shows the
main processes that are involved with new mail. Names followed by
a number are Postfix commands or server programs, while unnumbered
names inside shaded areas represent Postfix queues.
Network mail enters Postfix via the smtpd(8) or qmqpd(8)
servers. These servers remove the SMTP or QMQP protocol encapsulation,
enforce some sanity checks to protect Postfix, and give the sender,
recipients and message content to the cleanup(8) server. The
smtpd(8) server can be configured to block unwanted mail, as
described in the SMTPD_ACCESS_README document.
Local submissions are received with the Postfix sendmail(1)
compatibility command, and are queued in the maildrop queue by
the privileged postdrop(1) command. This arrangement even works
while the Postfix mail system is not running. The local pickup(8)
server picks up local submissions, enforces some sanity checks to
protect Postfix, and gives the sender, recipients and message
content to the cleanup(8) server.
Mail from internal sources is given directly to the
cleanup(8) server. These sources are not shown in the figure, and
include: mail that is forwarded by the local(8) delivery agent (see
next section), messages that are returned to the sender by the
bounce(8) server (see second-next section), and postmaster
notifications about problems with Postfix.
The cleanup(8) server implements the final processing
stage before mail is queued. It adds missing From: and other message
headers, transforms addresses as described in the ADDRESS_REWRITING_README
document. Optionally, the cleanup(8) server can be configured to
do light-weight content inspection with regular expressions as
described in the BUILTIN_FILTER_README document. The cleanup(8)
server places the result as a single file into the incoming queue,
and notifies the queue manager (see next section) of the arrival
of new mail.
The trivial-rewrite(8) server rewrites addresses to the
standard "email@example.com" form, as described in the
ADDRESS_REWRITING_README document. Postfix currently does not
implement a rewriting language, but a lot can be done via table
lookups and, if need be, regular expressions.
Once a message has reached the incoming queue the next step is
to deliver it. The figure shows the main components of the Postfix
mail delivery apparatus. Names followed by a number are Postfix
commands or server programs, while unnumbered names inside shaded
areas represent Postfix queues.
The queue manager (the qmgr(8) server process in the
figure) is the heart of Postfix mail delivery. It contacts the
smtp(8), lmtp(8), local(8), virtual(8), pipe(8), or error(8) delivery
agents, and sends a delivery request for one or more recipient
addresses. The error(8) delivery agent is special: it always declares
mail as undeliverable. It is not shown in the figure above.
The queue manager maintains a small active queue with the
messages that it has opened for delivery. The active queue acts as
a limited window on potentially large incoming or deferred queues.
The limited active queue prevents the queue manager from running
out of memory under heavy load.
The queue manager maintains a separate deferred queue for mail
that cannot be delivered, so that a large mail backlog will not
slow down normal queue accesses. The queue manager's strategy for
delayed mail delivery attempts is described in the QSHAPE_README
and TUNING_README documents.
The trivial-rewrite(8) server resolves each recipient
address according to its local and remote address class, as defined
in the ADDRESS_CLASS_README document. Additional routing information
can be specified with the optional transport(5) table. The
trivial-rewrite(8) server optionally queries the relocated(5) table
for recipients whose address has changed; mail for such recipients is
returned to the sender with an explanation.
The smtp(8) client looks up a list of mail exchangers for
the destination host, sorts the list by preference, and tries each
server in turn until it finds a server that responds. It then
encapsulates the sender, recipient and message content as required
by the SMTP protocol; this includes conversion of 8-bit MIME to
The lmtp(8) client speaks a protocol similar to SMTP that
is optimized for delivery to mailbox servers such as Cyrus. The
advantage of this setup is that one Postfix machine can feed multiple
mailbox servers over LMTP. The opposite is true as well: one
mailbox server can be fed over LMTP by multiple Postfix machines.
The LMTP_README document gives examples of how to use the lmtp(8)
The local(8) delivery agent understands UNIX-style mailboxes,
qmail-compatible maildir files, Sendmail-style system-wide aliases(5)
databases, and Sendmail-style per-user .forward files. Multiple
local delivery agents can be run in parallel, but parallel delivery
to the same user is usually limited.
The local(8) delivery agent has hooks for alternative forms of
local delivery: you can configure it to deliver to mailbox files
in user home directories, you can configure it to delegate mailbox
delivery to an external command such as procmail, or you can delegate
delivery to a different Postfix delivery agent.
The virtual(8) delivery agent is a bare-bones delivery
agent that delivers to UNIX-style mailbox or qmail-style maildir
files only. This delivery agent can deliver mail for multiple
domains, which makes it especially suitable for hosting lots of
small domains on a single machine. This is described in the
The pipe(8) mailer is the outbound interface to other mail
processing systems (the Postfix sendmail(1) command being the
inbound interface). The interface is UNIX compatible: it provides
information on the command line and on the standard input stream,
and expects a process exit status code as defined in <sysexits.h>.
Examples of delivery via the pipe(8) mailer are in the MAILDROP_README
and UUCP_README documents.
The previous sections gave an overview of how Postfix server
processes send and receive mail. These server processes rely on
other server processes that do things behind the scenes. Where
practical, each service will be visualized in its own context. As
before, names followed by a number are Postfix commands or server
programs, while unnumbered names inside shaded areas represent
The resident master(8) server is the supervisor that keeps
an eye on the well-being of the Postfix mail system. It is typically
started at system boot time with the "postfix start" command, and
keeps running until the system goes down. The master(8) server is
responsible for starting Postfix server processes to receive and
deliver mail, and for restarting servers that terminate prematurely
because of some problem. The master(8) server is also responsible
for enforcing the server process count limits as specified in the
master.cf configuration file. The picture below gives the
program hierarchy when Postfix is started up. Only some of the mail
handling daemon processes are shown.
The anvil(8) server implements client connection and rate
limiting for all smtpd(8) servers. The TUNING_README document
provides guidance for dealing with mis-behaving SMTP clients. The
anvil(8) service is not included with Postfix version 2.1 or earlier.
The bounce(8), defer(8) and trace(8) servers each maintain
their own queue directory trees with per-message logfiles. This
information is used to send delivery or non-delivery notifications
to the sender.
The trace(8) service implements support for the Postfix "sendmail
-bv" and "sendmail -v" commands which produce reports about how
Postfix delivers mail, and is available with Postfix version 2.1
and later. See DEBUG_README
The flush(8) servers maintain per-destination logs and
implement both ETRN and "sendmail -qRdestination", as described
in the ETRN_README document. This moves selected queue files from
the deferred queue back to the incoming queue and requests their
delivery. The flush(8) service is available with Postfix version
1.0 and later.
The proxymap(8) servers provide read-only table lookup
service to Postfix processes. This overcomes chroot restrictions,
and reduces the number of open lookup tables by sharing one open
table among multiple processes.
The showq(8) servers list the Postfix queue status. This
is the queue listing service that does the work for the mailq(1)
and postqueue(1) commands.
The spawn(8) servers run non-Postfix commands on request,
with the client connected via socket or FIFO to the command's
standard input, output and error streams. You can find examples of
its use in the SMTPD_POLICY_README document.
The verify(8) server verifies that a sender or recipient
address is deliverable before the smtpd(8) server accepts it. The
verify(8) server injects probe messages into the Postfix queue and
processes status updates from delivery agents and/or queue manager.
This process is described in the ADDRESS_VERIFICATION_README
document. The verify(8) service is available with Postfix version
2.1 and later.
The Postfix architecture overview ends with a summary of
command-line utilities for day-to-day use of the Postfix mail
system. Besides the Sendmail-compatible sendmail(1), mailq(1), and
newaliases(1) commands, the Postfix system comes with it own
collection of command-line utilities. For consistency, these are
all named postsomething.
The postfix(1) command controls the operation of the mail
system. It is the interface for starting, stopping, and restarting
the mail system, as well as for some other administrative operations.
This command is reserved to the super-user.
The postalias(1) command maintains Postfix aliases(5) type
databases. This is the program that does the work for the
The postcat(1) command displays the contents of Postfix
queue files. This is a limited, preliminary utility. This program
is likely to be superseded by something more powerful that can also
edit Postfix queue files.
The postconf(1) command displays or updates Postfix main.cf
parameters and displays system dependent information about the
supported file locking methods, and the supported types of lookup
The postdrop(1) command is the mail posting utility that
is run by the Postfix sendmail(1) command in order to deposit mail
into the maildrop queue directory.
The postkick(1) command makes some Postfix internal
communication channels available for use in, for example, shell
The postlock(1) command provides Postfix-compatible mailbox
locking for use in, for example, shell scripts.
The postlog(1) command provides Postfix-compatible logging
for shell scripts.
The postmap(1) command maintains Postfix lookup tables
such as canonical(5), virtual(5) and others. It is a cousin of the
UNIX makemap command.
The postqueue(1) command is the privileged command that
is run by Postfix sendmail(1) and mailq(1) in order to flush or
The postsuper(1) command maintains the Postfix queue. It
removes old temporary files, and moves queue files into the right
directory after a change in the hashing depth of queue directories.
This command is run at mail system startup time and when Postfix