1<HTML> 2<HEAD> 3<TITLE>Architecture</TITLE> 4</HEAD> 5<BODY> 6<!-- 7$Id: design.html,v 1.13 2013-11-22 20:51:39 ca Exp $ 8--> 9 10<H1>Architecture</H1> 11 12<H2>Contents</H2> 13 14<UL> 15 <LI>Design Goals 16 <LI>Implementing Filtering Policies 17 <LI>MTA - Filter Communication 18</UL> 19 20<H2>Goals</H2> 21 22The Sendmail Content Management API (Milter) provides an interface for 23third-party software to validate and modify messages as they pass 24through the mail transport system. Filters can process messages' 25connection (IP) information, envelope protocol elements, message 26headers, and/or message body contents, and modify a message's 27recipients, headers, and body. The MTA configuration file specifies 28which filters are to be applied, and in what order, allowing an 29administrator to combine multiple independently-developed filters. 30 31<P> 32We expect to see both vendor-supplied, configurable mail filtering 33applications and a multiplicity of script-like filters designed by and 34for MTA administrators. A certain degree of coding sophistication and 35domain knowledge on the part of the filter provider is assumed. This 36allows filters to exercise fine-grained control at the SMTP level. 37However, as will be seen in the example, many filtering applications 38can be written with relatively little protocol knowledge. 39 40<P> 41Given these expectations, the API is designed to achieve the following 42goals: 43 44<OL> 45 <LI>Safety/security. 46 Filter processes should not need to run as root 47 (of course, they can if required, but that is a local issue); 48 this will simplify coding 49 and limit the impact of security flaws in the filter program. 50<P> 51 <LI>Reliability. 52 Coding failures in a Milter process that cause that process 53 to hang or core-dump 54 should not stop mail delivery. 55 Faced with such a failure, 56 sendmail should use a default mechanism, 57 either behaving as if the filter were not present 58 or as if a required resource were unavailable. 59 The latter failure mode will generally have sendmail return 60 a 4xx SMTP code (although in later phases of the SMTP protocol 61 it may cause the mail to be queued for later processing). 62<P> 63 <LI>Simplicity. 64 The API should make implementation of a new filter 65 no more difficult than absolutely necessary. 66 Subgoals include: 67 <UL> 68 <LI>Encourage good thread practice 69 by defining thread-clean interfaces including local data hooks. 70 <LI>Provide all interfaces required 71 while avoiding unnecessary pedanticism. 72 </UL> 73<P> 74 <LI>Performance. 75 Simple filters should not seriously impact overall MTA performance. 76</OL> 77 78<H2>Implementing Filtering Policies</H2> 79 80Milter is designed to allow a server administrator to combine 81third-party filters to implement a desired mail filtering policy. For 82example, if a site wished to scan incoming mail for viruses on several 83platforms, eliminate unsolicited commercial email, and append a mandated 84footer to selected incoming messages, the administrator could configure 85the MTA to filter messages first through a server based anti-virus 86engine, then via a large-scale spam-catching service, and finally 87append the desired footer if the message still met requisite criteria. 88Any of these filters could be added or changed independently. 89 90<P> 91Thus the site administrator, not the filter writer, controls the 92overall mail filtering environment. In particular, he/she must decide 93which filters are run, in what order they are run, and how they 94communicate with the MTA. These parameters, as well as the 95actions to be taken if a filter becomes unavailable, are selectable 96during MTA configuration. <A href="installation.html">Further 97details</A> are available later in this document. 98 99<H2>MTA - Filter communication</H2> 100 101Filters run as separate processes, outside of the sendmail address 102space. The benefits of this are threefold: 103 104<OL> 105 <LI>The filter need not run with "root" permissions, thereby 106 avoiding a large family of potential security problems.</LI> 107 108 <LI>Failures in a particular filter will not affect the MTA or 109 other filters.</LI> 110 111 <LI>The filter can potentially have higher performance because of 112 the parallelism inherent in multiple processes.</LI> 113</OL> 114 115<P> 116Each filter may communicate with multiple MTAs at the same time over 117local or remote connections, using multiple threads of execution. 118<A HREF="#figure-1">Figure 1</A> illustrates a possible network of 119communication channels between a site's filters, its MTAs, and other 120MTAs on the network: 121</P> 122<DIV align="center"> 123<A name="figure-1"><IMG src="figure1.jpg" ALT=""></A><BR> 124<B>Figure 1: A set of MTA's interacting with a set of filters.</B> 125</DIV> 126<P> 127The Milter library (libmilter) implements the communication protocol. 128It accepts connections from various MTAs, passes the relevant data to 129the filter through callbacks, then makes appropriate responses based 130on return codes. A filter may also send data to the MTA as a result 131of library calls. <A href="#figure-2">Figure 2</A> shows a single 132filter process processing messages from two MTAs: 133</P> 134<DIV align="center"> 135<IMG src="figure2.jpg" ALT=""><BR> 136<B>Figure 2: A filter handling simultaneous requests from two MTA's.</B> 137</DIV> 138<HR size="1"> 139<FONT size="-1"> 140Copyright (c) 2000, 2003 Proofpoint, Inc. and its suppliers. 141All rights reserved. 142<BR> 143By using this file, you agree to the terms and conditions set 144forth in the LICENSE. 145</FONT> 146</BODY> 147</HTML> 148
