145 lines
5.4 KiB
HTML
145 lines
5.4 KiB
HTML
<html>
|
|
<head>
|
|
<title>Architecture</title>
|
|
</head>
|
|
<body>
|
|
|
|
<h1>Architecture</h1>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>Design Goals
|
|
<li>Implementing Filtering Policies
|
|
<li>MTA - Filter Communication
|
|
</ul>
|
|
|
|
<h2>Goals</h2>
|
|
|
|
The Sendmail Content Management API (Milter) provides an interface for
|
|
third-party software to validate and modify messages as they pass
|
|
through the mail transport system. Filters can process messages'
|
|
connection (IP) information, envelope protocol elements, message
|
|
headers, and/or message body contents, and modify a message's
|
|
recipients, headers, and body. The MTA configuration file specifies
|
|
which filters are to be applied, and in what order, allowing an
|
|
administrator to combine multiple independently-developed filters.
|
|
|
|
<p>
|
|
We expect to see both vendor-supplied, configurable mail filtering
|
|
applications and a multiplicity of script-like filters designed by and
|
|
for MTA administrators. A certain degree of coding sophistication and
|
|
domain knowledge on the part of the filter provider is assumed. This
|
|
allows filters to exercise fine-grained control at the SMTP level.
|
|
However, as will be seen in the example, many filtering applications
|
|
can be written with relatively little protocol knowledge.
|
|
|
|
<p>
|
|
Given these expectations, the API is designed to achieve the following
|
|
goals:
|
|
|
|
<OL>
|
|
<LI>Safety/security.
|
|
Filter processes should not need to run as root
|
|
(of course, they can if required, but that is a local issue);
|
|
this will simplify coding
|
|
and limit the impact of security flaws in the filter program.
|
|
<p>
|
|
<LI>Reliability.
|
|
Coding failures in a Milter process that cause that process
|
|
to hang or core-dump
|
|
should not stop mail delivery.
|
|
Faced with such a failure,
|
|
sendmail should use a default mechanism,
|
|
either behaving as if the filter were not present
|
|
or as if a required resource were unavailable.
|
|
The latter failure mode will generally have sendmail return
|
|
a 4xx SMTP code (although in later phases of the SMTP protocol
|
|
it may cause the mail to be queued for later processing).
|
|
<p>
|
|
<LI>Simplicity.
|
|
The API should make implementation of a new filter
|
|
no more difficult than absolutely necessary.
|
|
Subgoals include:
|
|
<UL>
|
|
<LI>Encourage good thread practice
|
|
by defining thread-clean interfaces including local data hooks.
|
|
<LI>Provide all interfaces required
|
|
while avoiding unnecessary pedanticism.
|
|
</UL>
|
|
<p>
|
|
<LI>Performance.
|
|
Simple filters should not seriously impact overall MTA performance.
|
|
</OL>
|
|
|
|
<h2>Implementing Filtering Policies</h2>
|
|
|
|
Milter is designed to allow a server administrator to combine
|
|
third-party filters to implement a desired mail filtering policy. For
|
|
example, if a site wished to scan incoming mail for viruses on several
|
|
platforms, eliminate unsolicited commercial email, and append a mandated
|
|
footer to selected incoming messages, the administrator could configure
|
|
the MTA to filter messages first through a server based anti-virus
|
|
engine, then via a large-scale spam-catching service, and finally
|
|
append the desired footer if the message still met requisite criteria.
|
|
Any of these filters could be added or changed independently.
|
|
|
|
<p>
|
|
Thus the site administrator, not the filter writer, controls the
|
|
overall mail filtering environment. In particular, he/she must decide
|
|
which filters are run, in what order they are run, and how they
|
|
communicate with the MTA. These parameters, as well as the
|
|
actions to be taken if a filter becomes unavailable, are selectable
|
|
during MTA configuration. <a href="installation.html">Further
|
|
details</a> are available later in this document.
|
|
|
|
<h2>MTA - Filter communication</h2>
|
|
|
|
Filters run as separate processes, outside of the sendmail address
|
|
space. The benefits of this are threefold:
|
|
|
|
<OL>
|
|
<LI>The filter need not run with "root" permissions, thereby
|
|
avoiding a large family of potential security problems.</LI>
|
|
|
|
<LI>Failures in a particular filter will not affect the MTA or
|
|
other filters.</LI>
|
|
|
|
<LI>The filter can potentially have higher performance because of
|
|
the parallelism inherent in multiple processes.</LI>
|
|
</OL>
|
|
|
|
<p>
|
|
Each filter may communicate with multiple MTAs at the same time over
|
|
local or remote connections, using multiple threads of execution. <a
|
|
href="#figure-1">Figure 1</a> illustrates a possible network of
|
|
communication channels between a site's filters, its MTAs, and other
|
|
MTAs on the network:
|
|
</p>
|
|
<div align="center">
|
|
<a name="figure-1"><img src="figure1.jpg" ALT=""></A><br>
|
|
<b>Figure 1: A set of MTA's interacting with a set of filters.</b>
|
|
</div>
|
|
<p>
|
|
The Milter library (libmilter) implements the communication protocol.
|
|
It accepts connections from various MTAs, passes the relevant data to
|
|
the filter through callbacks, then makes appropriate responses based
|
|
on return codes. A filter may also send data to the MTA as a result
|
|
of library calls. <a href="#figure-2">Figure 2</a> shows a single
|
|
filter process processing messages from two MTAs:
|
|
</p>
|
|
<div align="center">
|
|
<img src="figure2.jpg" ALT=""><br>
|
|
<b>Figure 2: A filter handling simultaneous requests from two MTA's.</b>
|
|
</div>
|
|
<hr size="1">
|
|
<font size="-1">
|
|
Copyright (c) 2000 Sendmail, Inc. and its suppliers.
|
|
All rights reserved.
|
|
<br>
|
|
By using this file, you agree to the terms and conditions set
|
|
forth in the <a href="LICENSE.txt">LICENSE</a>.
|
|
</font>
|
|
</body>
|
|
</html>
|