<html> <head> <title>Postfix Overview - Goals and Features</title> </head> <body> <h1><a href="big-picture.html"><img src="small-picture.gif" width="115" height="45"></a> Postfix Overview - Goals and Features</h1> <hr> <a href="index.html">Up one level</a> | <a href="motivation.html">Introduction</a> | Goals and features | <a href="architecture.html">Global architecture</a> | <a href="queuing.html">Queue Management</a> | <a href="security.html">Security</a> <h2>Primary goals</h2> The goal of the Postfix project is to implement a viable alternative to the UNIX Sendmail program. Specific goals, and the ways that Postfix attempts to achieve them are: <ul> <li>Wide dissemination. Postfix must be adopted by lots of people in order to make a significant impact on Internet mail performance and security. Therefore the software is given away for free, with no strings attached to it. <p> <li>Performance. Postfix is up to three times as fast as its nearest competitor. A desktop PC running Postfix can receive and deliver a million <i>different</i> messages per day. Postfix uses web server tricks to reduce process creation overhead and uses other tricks to reduce file system overhead, without compromising reliability. <p> <li>Compatibility. Postfix is designed to be sendmail-compatible to make migration easy. Postfix supports <b>/var[/spool]/mail</b>, <b>/etc/aliases</b>, <b>NIS</b>, and <b>~/.forward</b> files. However, Postfix also attempts to be easy to administer, and therefore it does <i>not</i> use <b>sendmail.cf</b>. <p> <li>Safety and robustness. Postfix is designed to behave rationally under stress. When the local system runs out of disk space or memory, the Postfix software backs off, instead of making the problem worse. By design, no Postfix program keeps growing as the number of messages etc. increases. Postfix is designed to stay in control. <p> <li>Flexibility. Postfix is built from over a dozen little programs that each perform only one specific task: receive a message via SMTP, deliver a message via SMTP, deliver a message locally, rewrite an address, and so on. Sites with specific requirements can replace one or more little programs by alternative versions. And it is easy to disable functionality, too: firewalls and client workstations don't need local delivery at all. <p> <li>Security. Postfix uses multiple layers of defense to protect the local system against intruders. Almost every Postfix daemon can run in a <i>chroot</i> jail with fixed low privileges. There is no direct path from the network to the security-sensitive local delivery programs - an intruder has to break through several other programs first. Postfix does not even trust the contents of its own queue files, or the contents of its own IPC messages. Postfix filters sender-provided information before exporting it via environment variables. Last but not least, no Postfix program is <i>set-uid</i>. </ul> <h2>Other significant features of interest</h2> <ul> <li><a href="rewrite.html#transport">Multiple transports</a>. In the past the author has configured Sendmail systems that could relay between Internet, DECnet, X.400 and UUCP. Postfix is designed to be flexible enough that it can operate in such environments without requiring virtual domain or alias kludges. However, the initial release only talks SMTP, and has only limited support for UUCP. <p> <li><a href="rewrite.html#virtual">Virtual domains</a>. In the most common case, adding support for a virtual domain requires change to only a single Postfix lookup table. Other mailers usually need multiple levels of aliasing or redirection to achieve the same result. <p> <li><a href="uce.html">UCE control</a>. Postfix can restrict what hosts can relay their mail through a Postfix system, and supports restrictions on what mail is allowed to come in. Postfix implements the usual suspects: blacklists, RBL lookups, HELO/sender DNS lookups. Content filtering hasn't been implemented yet. <p> <li><a href="rewrite.html">Table lookups</a>. Postfix does not yet implement an address rewriting language. Instead it makes extensive use of table lookups. Tables can be local <b>dbm</b> or <b>db</b> files, or networked <b>NIS</b> or <b>NetInfo</b> maps. Adding support for other lookup mechanisms is relatively easy. </ul> <hr> <a href="index.html">Up one level</a> | <a href="motivation.html">Introduction</a> | Goals and features | <a href="architecture.html">Global architecture</a> | <a href="queuing.html">Queue Management</a> | <a href="security.html">Security</a> </body> </html>