NetBSD/gnu/dist/postfix/html/receiving.html

118 lines
3.7 KiB
HTML

<html>
<head>
<title>Postfix Anatomy - Receiving Mail</title>
</head>
<body>
<h1><a href="big-picture.html"><img src="small-picture.gif" width="115" height="45"></a> Postfix
Anatomy - Receiving Mail</h1>
<hr>
<a href="index.html">Up one level</a> | Receiving Mail | <a
href="delivering.html">Delivering Mail</a> | <a
href="backstage.html">Behind the Scenes</a> | <a
href="commands.html">Command-line Utilities</a>
<p>
When a message enters the Postfix mail system, the first stop on
the inside is the <b>incoming</b> queue. The figure below shows
the main components that are involved with new mail. For an
explanation of the symbols used, click on the icon in the upper
left-hand corner of this page.
<p>
<center>
<img src="inbound.gif" width="497" height="213">
</center>
<p>
<ul>
<li>Mail is posted locally. The Postfix <a
href="sendmail.1.html">sendmail</a> program deposits the message
into the world-writable <b>maildrop</b> directory, where the message
is picked up by the <a href="pickup.8.html">pickup</a> daemon.
This daemon does some sanity checks, in order to protect the rest
of the Postfix system. In order to avoid accidents, the directory
permissions on the <b>maildrop</b> directory must be such that a
user cannot delete someone elses mail.
<p>
<li>Mail comes in via the network. The Postfix <a href="smtpd.8.html">SMTP
server</a> receives the message and does some sanity checks, in
order to protect the rest of the Postfix system. The SMTP server
can be configured to implement <a href="uce.html">UCE</a> controls
on the basis of local or network-based black lists, DNS lookups,
and other client request information.
<p>
<li>Mail is generated internally by the Postfix system itself, in
order to return undeliverable mail to the sender. The <a
href="bounce.8.html">bounce or defer</a> daemon brings the bad
news.
<p>
<li>Mail is forwarded by the <a href="local.8.html">local</a>
delivery agent, either via an entry in the system-wide <a
href="aliases.5.html">alias</a> database, or via an entry in a
per-user <a href="aliases.5.html">.forward</a> file. This is
indicated with the unlabeled arrow.
<p>
<li>Mail is generated internally by the Postfix system itself, in
order to notify the postmaster of a problem (this path is also
indicated with the unlabeled arrow). The Postfix system can be
configured to <a href="basic.html#notify">notify</a> the postmaster
of SMTP protocol problems, UCE policy violations, and so on.
<p>
<li>The <a href="cleanup.8.html">cleanup</a> daemon implements the
final processing stage for new mail. It adds missing <b>From:</b>
and other message headers, arranges for address rewriting to the
standard <i>user@fully.qualified.domain</i> form, and optionally
extracts recipient addresses from message headers. The <b> cleanup</b>
daemon inserts the result as a single queue file into the
<b>incoming</b> queue, and notifies the <a href="qmgr.8.html">queue
manager</a> of the arrival of new mail. The <b>cleanup</b> daemon
can be configured to transform addresses on the basis of <a
href="rewrite.html#canonical">canonical</a> and <a
href="rewrite.html#virtual">virtual</a> table lookups.
<p>
<li>On request by the <b>cleanup</b> daemon, the <a
href="trivial-rewrite.8.html">trivial-rewrite</a> daemon rewrites
addresses to the standard <i>user@fully.qualified.domain</i> form.
The initial Postfix version does not implement a rewriting language.
Implementing one would take a lot of effort, and most sites do not
need it. Instead, Postfix makes extensive use of <a
href="rewrite.html">table lookup</a>.
</ul>
<hr>
<a href="index.html">Up one level</a> | Receiving Mail | <a
href="delivering.html">Delivering Mail</a> | <a
href="backstage.html">Behind the Scenes</a> | <a
href="commands.html">Command-line Utilities</a>
</body>
</html>