in the user's ~/.forward file, and through small "gate" programs to submit mail or to request queue status information. Other programs provide administrative support to start or stop Postfix, query status information, manipulate the queue, or to examine or update its configuration files. Yellow ellipses One of Postfix' many daemons serving exactly one purpose. This split-up into many smaller pieces of software is considered one of the reasons why Postfix is secure and stable. Blue boxes The blue boxes represent so-called lookup tables. A lookup table consists of two columns (key and value) containing information used for access control, e-mail routing etc. Orange boxes The orange boxes are either mail queues or files. In either case, e-mails are stored on persistent media (e.g., a hard disk). White clouds The clouds stand for points at which e-mails enter or leave Postfix. For example, smtpd receives mail from other mail servers or users whereas smtp relays mail to other MTAs. Implementation The Postfix implementation uses safe subsets of the C language and of the POSIX system API. These subsets are buried under an abstraction layer that contains about 50% of all Postfix source code, and that provides the foundation on which all Postfix programs are built. For example, the "vstring" primitive makes Postfix code resistant to buffer overflow attacks, and the "safe open" primitive makes Postfix code resistant to race condition attacks on systems that implement the POSIX file system API. This abstraction layer does not affect the attack resistance of non-Postfix code, such as code in system libraries or in third-party libraries. Robustness Conceptually, Postfix manages pipelines of processes that pass the responsibility for message delivery and error notification from one process to the next. All message and notification "state" information is persisted in the file system. The processes in a pipeline operate mostly without centralized control; this relative autonomy simplifies error recovery. When a process fails before completing its part of a file or protocol transaction, its predecessor in the pipeline backs off and retries the request later, and its successor in the pipeline discards unfinished work. Many Postfix daemons can simply "die" when they run into a problem; they are automatically restarted when the next service request arrives. This approach makes Postfix highly resilient, as long as the operating system or hardware don't fail catastrophically. Performance One single Postfix instance has been clocked at ~300 message deliveries/second across the