134 lines
4.5 KiB
HTML
134 lines
4.5 KiB
HTML
|
<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>
|