CONTENT_INSPECTION_README.html [plain text]
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix Content Inspection </title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
Content Inspection </h1>
<hr>
<p> Postfix supports three content inspection methods, ranging from
light-weight one-line-at-a-time scanning before mail is queued, to
heavy duty machinery that does sophisticated content analysis after
mail is queued. Each approach serves a different purpose. </p>
<dl>
<dt> <b> built-in, light-weight, real-time </b> </dt>
<dd> <p> This method inspects mail BEFORE it is stored in the queue,
and uses Postfix's built-in message header and message body
inspection. Although the main purpose is to stop a specific flood
of mail from worms or viruses, it is also useful to block a flood
of bounced junk email and email notifications from virus detection
systems. The built-in regular expressions are not meant to implement
general SPAM and virus detection. For that, you should use one of
the content inspection methods described below. Details are described
in the BUILTIN_FILTER_README and BACKSCATTER_README documents.
</p>
<dt> <b> external, heavy-weight, not real time </b> </dt>
<dd> <p> This method inspects mail AFTER it is stored in the queue,
and uses standard protocols such as SMTP or "pipe to command and
wait for exit status". After-queue inspection allows you to use
content filters of arbitrary complexity without causing timeouts
while receiving mail, and without running out of memory resources
under a peak load. Details of this approach are in the FILTER_README
document. </p>
<dt> <b> external, medium-weight, real-time </b> </dt>
<dd> <p> This method inspects mail BEFORE it is stored in the queue,
and uses the SMTP protocol. Although this approach appears to be
the more attractive one, it really combines the worst of the other
two. Because mail is inspected before it is queued, content
inspection software must finish in a limited amount of time, and
must run in a limited amount of memory. If content inspection
needs too much time then incoming mail deliveries will time out,
and if content inspection needs too much memory then software will
crash under a peak load. Before-queue inspection limits the peak
load that your system can handle, and limits the sophistication of
the content filter that you can use. Details are in the
SMTPD_PROXY_README document. This approach is available only with
Postfix version 2.1 and later. </p>
</dl>
<p> The more sophisticated content filtering software is not built
into Postfix for good reasons: writing an MTA requires different
skills than writing a SPAM or virus killer. Postfix encourages the
use of external filters and standard protocols because this allows
you to choose the best MTA and the best content inspection software
for your purpose. Information about external content inspection
software can be found on the Postfix website at http://www.postfix.org/,
and on the postfix-users@postfix.org mailing list. </p>
</body>
</html>