Postfix Design

Postfix in it’s design focuses on several major issues:

Security
The Postfix mail server creates multiple layers of security to defend against the evils of the Internet. The general concept of least privilege is used widely in Postfix. This means that the server by default only allows each process to use necessary rights to function, unnecessary rights are eliminated. It also creates an atmosphere where processes that must run higher privileges do not trust the unprivileged processes.

Related Postfix Training
Postfix Configuration
Postfix Mail Server Design

Control SPAM with Postfix
Postfix Mailbox Changes
Postfix Mail Gateway
Postfix Mail Server Course
 Postfix Mail Statistics

8 Week Course for $499.95  ORDER NOW

Don't Outsource Your Mail Server, Learn how to run it yourself! We specialize in helping companies become independent of outsourcing Linux services. 8 Week Course for $499.95  ORDER NOW

Postfix uses a modular design whereas Sendmail uses a monolithic design. The problem with security and a monolithic design is that it tends to be all or nothing. In a monolithic design, a security breach in one aspect of the system leads to a security breach of the whole system. For example, much of the security problems of Sendmail in the past has been that it must run as a privileged user to perform most of it’s tasks. Postfix is able to run as the least privileged user and has the ability to turn off modules not used by the system, thus limiting the security issues. The Postfix mail server isolates processes from each other so that they do not depend on as much communication between processes.

Postfix executes processes for the most part as a trusted daemon that does not run child processes. When a process creates child processes it increases security issues because the child-parent communication can lead to security failure for both. This means that Postfix is more immune to attacks that use shared memory and common open files.

The chroot environment can be employed by Postfix to limit access to the main system. A chroot directory provides a way that /var/spool/postfix is a limited file system that cannot view the rest of the system. Several other newer security options can be used with Postfix. One option is use use AppArmor to defend

Postfix.

AppArmor attempts to protect processes on the server or desktop from security threats. AppArmor enforces limits on what processes can access on the system. It attempts to restrict processes to those resources that the process requires to function only. AppArmor will not only define the system resources a program can access , it will also determine the privileges with which it can access those resources. To protect applications you will need to set up a security profile for each application that you want to protect.

When you have many software applications on a system you have the risk of hosting software flaws that you are not aware of. These software flaws provide avenues of access for attackers to compromise your system. Exploits that are discovered and on the same day that they are used to crack a system by an attacker are called zero-day exploits. AppArmor provides protection against these kinds of attacks by protecting against known and unknown vulnerabilities.

Another newer option is SELinux which is an open source project sponsored by the National Security Agency. The focus is to use SELinux to implement mandatory access control at the kernel level. What this does for security is provide a security system at a fundamental level that will not be as impacted by security settings of individual programs. In effect, SELinux takes programs and isolates each program from the system so that it still functions with the system but is in a security sense independent of the system. In other words, if a program is compromised it does not offer more access to the system, rather it offers less access to the system. An added benefit to this isolation is that it protects data from being shared incorrectly, by removing discretion of the user. The image below illustrates this concept. Daemons and their support programs are placed in domains. These domains prevent access to other parts of the operating system.

Performance
In order to enhance performance Postfix used two basic techniques; limit the number of new processes that need to be created and limit the number of files that Postfix needs to access to process mail.

Reliability
Reliability was built into Postfix by configuring the mail server so that it became aware of limited RAM and file system space in order that it may make adjustments to these conditions. These adjustments would provide time for system administrators to make the necessary changes on the system.

Simplicity
The goal was to create a mail server that was easy to configure. Simplicity means the system functions the way that most people would think.

Compatibility
Postfix was designed to be compatible with Sendmail so that administrators could replace Sendmail easily with Postfix.

Modularity

Postfix was designed in modules so that each module handles a specific task and passes it on to the next module. Sendmail for example is monolithic in that one program handles all the processes. In Postfix the master daemon initiates processes as needed and when each process is complete it is terminated. There are three basic components to Postfix; receiving messages, queueing messages and delivering messages. In the example diagram you can see that Sendmail is monolithic and handles everything using one major process.