diff options
Diffstat (limited to 'contrib/sendmail/libmilter/docs/design.html')
| -rw-r--r-- | contrib/sendmail/libmilter/docs/design.html | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/contrib/sendmail/libmilter/docs/design.html b/contrib/sendmail/libmilter/docs/design.html new file mode 100644 index 0000000..fbc74e6 --- /dev/null +++ b/contrib/sendmail/libmilter/docs/design.html @@ -0,0 +1,144 @@ +<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> |
