LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

new

This commit is contained in:
gferg 2004-09-13 12:45:14 +00:00
parent 8116caf3a0
commit 3105af4588
9 changed files with 8386 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

783
LDP/howto/docbook/Spam-Filtering-for-MX/Spam-Filtering-for-MX.xml Normal file
View File

@ -0,0 +1,783 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY background SYSTEM "chapter-background.xml">
<!ENTITY techniques SYSTEM "chapter-techniques.xml">
<!ENTITY consider SYSTEM "chapter-considerations.xml">
<!ENTITY qanda SYSTEM "chapter-qanda.xml">
<!ENTITY exim SYSTEM "impl-exim.xml">
<!ENTITY glossary SYSTEM "glossary.xml">
<!ENTITY gpl SYSTEM "gpl.xml">
]>
<!-- "/usr/share/sgml/docbook/dtd/4.2/docbookx.dtd" -->
<!-- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -->
<book>
<bookinfo>
<title>Spam Filtering for Mail Exchangers</title>
<subtitle>
How to reject junk mail in incoming SMTP transactions.
</subtitle>
<authorgroup>
<author>
<firstname>Tor</firstname>
<surname>Slettnes</surname>
<affiliation>
<address><email>tor@slett.net</email></address>
</affiliation>
</author>
<editor>
<firstname>Joost</firstname>
<surname>De Cock</surname>
<affiliation>
<address><email>joost.decock (at) astrid.be</email></address>
</affiliation>
<contrib>Technical Review</contrib>
</editor>
<editor>
<firstname>Devdas</firstname>
<surname>Bhagat</surname>
<affiliation>
<address><email>devdas (at) dvb.homelinux.org</email></address>
</affiliation>
<contrib>Technical Review</contrib>
</editor>
<editor>
<firstname>Tom</firstname>
<surname>Wright</surname>
<affiliation>
<address><email>tom (at) maladmin.com</email></address>
</affiliation>
<contrib>Language Review</contrib>
</editor>
</authorgroup>
<edition>Version 1.0 -- Release</edition>
<keywordset>
<keyword>anti-spam</keyword>
<keyword>anti-virus</keyword>
<keyword>bogus virus warnings</keyword>
<keyword>collateral spam</keyword>
<keyword>delivery status notification</keyword>
<keyword>dsn</keyword>
<keyword>exim</keyword>
<keyword>exim4</keyword>
<keyword>exiscan</keyword>
<keyword>exiscan-acl</keyword>
<keyword>greylisting</keyword>
<keyword>junk mail</keyword>
<keyword>sa-exim</keyword>
<keyword>smtp</keyword>
<keyword>spam</keyword>
<keyword>spamassassin</keyword>
<keyword>teergrubing</keyword>
<keyword>transaction delay</keyword>
</keywordset>
</bookinfo>
<preface>
<?dbhtml filename="introduction.html"?>
<title>Introduction</title>
<section id="purpose">
<?dbhtml filename="intro-purpose.html"?>
<title>Purpose of this Document</title>
<para>
This document discusses various highly effective and low
impact ways to weed out spam and malware during incoming SMTP
transactions in a mail exchanger (MX host), with an added
emphasis on eliminating so-called <xref linkend="colspam"/>.
</para>
<para>
The discussions are conceptual in nature, but a sample
implementation is provided using the Exim MTA and other
specific software tools. Miscellaneous other bigotry is
expressed throughout.
</para>
</section>
<section id="audience">
<?dbhtml filename="intro-audience.html"?>
<title>Audience</title>
<para>
The intended audience is mail system administrators, who are
already familiar with such acronyms as SMTP, MTA/MDA/MUA,
DNS/rDNS, and MX records. If you are an end user who is
looking for a spam filtering solution for your mail reader
(such as Evolution, Thunderbird, Mail.app or Outlook Express),
this document is <emphasis>not</emphasis> for you; but you may
wish to point the mail system administrator for your domain
(company, school, ISP...) to its existence.
</para>
</section>
<section id="updates">
<?dbhtml filename="intro-updates.html"?>
<title>New versions of this document</title>
<para>
The newest version of this document can be found at
<ulink url="http://slett.net/spam-filtering-for-mx/" />.
Please check back periodically for corrections and additions.
</para>
</section>
<section id="history" xreflabel="Revision History">
<?dbhtml filename="intro-history.html"?>
<title>Revision History</title>
<para>
<revhistory>
<revision>
<revnumber>1.0</revnumber>
<date>2004-09-08</date>
<authorinitials>TS</authorinitials>
<revremark>
First public release.
</revremark>
</revision>
<revision>
<revnumber>0.18</revnumber>
<date>2004-09-07</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated second language review from Tom Wright.
</revremark>
</revision>
<revision>
<revnumber>0.17</revnumber>
<date>2004-09-06</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated language review from Tom Wright.
</revremark>
</revision>
<revision>
<revnumber>0.16</revnumber>
<date>2004-08-13</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated third round of changes from Devdas Bhagat.
</revremark>
</revision>
<revision>
<revnumber>0.15</revnumber>
<date>2004-08-04</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated second round of changes from technical
review by Devdas Bhagat.
</revremark>
</revision>
<revision>
<revnumber>0.14</revnumber>
<date>2004-08-01</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated technical review comments/corrections from
Devdas Bhagat.
</revremark>
</revision>
<revision>
<revnumber>0.13</revnumber>
<date>2004-08-01</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated technical review from Joost De Cock.
</revremark>
</revision>
<revision>
<revnumber>0.12</revnumber>
<date>2004-07-27</date>
<authorinitials>TS</authorinitials>
<revremark>
Replaced "A Note on Controversies" with a more
opinionated "The Good, The Bad, the Ugly" section. Also
rewrote text on DNS blocklists. Some corrections from
Seymour J. Metz.
</revremark>
</revision>
<revision>
<revnumber>0.11</revnumber>
<date>2004-07-19</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated comments from Rick Stewart on RMX++.
Swapped order of "Techniques" and "Considerations".
Minor typographic fixes in Exim implementation.
</revremark>
</revision>
<revision>
<revnumber>0.10</revnumber>
<date>2004-07-16</date>
<authorinitials>TS</authorinitials>
<revremark>
Added &lt;?dbhtml..?&gt; tags to control generated HTML
filenames - should prevent broken links from google etc.
Swapped order of "Forwarded Mail" and "User Settings".
Correction from Tony Finch on Bayesian filters;
commented out check for Subject:, Date:, and Message-ID:
headers per Johannes Berg; processing time subtracted
from SMTP delays per suggestion from Alan Flavell.
</revremark>
</revision>
<revision>
<revnumber>0.09</revnumber>
<date>2004-07-13</date>
<authorinitials>TS</authorinitials>
<revremark>
Elaborated on problems with envelope sender signatures
and mailing list servers, and a scheme to make such
signatures optional per host/domain for each user.
Moved "Considerations" section out as a separate
chapter; added subsections "Blocking Access to other
SMTP Server", "User Settings" and "Forwarded Mail".
Incorporated Matthew Byng-Maddick's comments on the
mechanism used to generate these signatures, Chris
Edwards' comments on sender callout verification, and
Hadmut Danisch's comments on RMX++ and other topics.
Changed license terms (GPL instead of GFDL).
</revremark>
</revision>
<revision>
<revnumber>0.08</revnumber>
<date>2004-07-09</date>
<authorinitials>TS</authorinitials>
<revremark>
Additional work on Exim implementation: Added section on
per-user settings and data for SpamAssassin per
suggestion from Tollef Fog Heen. Added SPF checks via
Exiscan-ACL. Corrections from Sam Michaels.
</revremark>
</revision>
<revision>
<revnumber>0.07</revnumber>
<date>2004-07-08</date>
<authorinitials>TS</authorinitials>
<revremark>
Made corrections to the Exim Envelope Sender Signatures
examples, and added support for users to "opt in" to
this feature, per suggestion from Christian Balzer.
</revremark>
</revision>
<revision>
<revnumber>0.06</revnumber>
<date>2004-07-08</date>
<authorinitials>TS</authorinitials>
<revremark>
Incorporated Exim/MySQL greylisting implementation and
various corrections from Johannes Berg. Moved "Sender
Authorization Schemes" up two levels to become a
top-level section in the Techniques chapter. Added
greylisting for NULL empty envelope senders after DATA.
Added SpamAssassin configuration to match Exim examples.
Incorporated corrections from Dominik Ruff, Mark
Valites, "Andrew" at Supernews.
</revremark>
</revision>
<revision>
<revnumber>0.05</revnumber>
<date>2004-07-07</date>
<authorinitials>TS</authorinitials>
<revremark>
Eliminated the (empty) Sendmail implementation for now,
to move ahead with the final review process.
</revremark>
</revision>
<revision>
<revnumber>0.04</revnumber>
<date>2004-07-06</date>
<authorinitials>TS</authorinitials>
<revremark>
Reorganized layout a little: Combined "SMTP-Time
Filtering", "Introduction to SMTP", and "Considerations"
into a single "Background" chapter. Split the previous
"Building ACLs" section in the Exim implementation into
top-level sections. Added alternate sender
authorization schemes to SPF: Microsoft Caller-ID for
E-Mail and RMX++. Incorporated comments from Ken
Raeburn.
</revremark>
</revision>
<revision>
<revnumber>0.03</revnumber>
<date>2004-07-02</date>
<authorinitials>TS</authorinitials>
<revremark>
Added discussion on Multiple Incoming Mail Exchangers;
minor corrections related to Sender Callout Verification.
</revremark>
</revision>
<revision>
<revnumber>0.02</revnumber>
<date>2004-06-30</date>
<authorinitials>TS</authorinitials>
<revremark>Added Exim implementation as an appendix</revremark>
</revision>
<revision>
<revnumber>0.01</revnumber>
<date>2004-06-16</date>
<authorinitials>TS</authorinitials>
<revremark>Initial draft.</revremark>
</revision>
</revhistory>
</para>
</section>
<!-- Give credit where credit is due...very important -->
<section id="credits">
<?dbhtml filename="intro-credits.html"?>
<title>Credits</title>
<para>
A number of people have provided feedback, corrections, and
contributions, as indicated in the <xref linkend="history"/>.
Thank you!
</para>
<para>
The following are <emphasis>some</emphasis> of the people and
groups that have provided tools and ideas to this document, in
no particular order:
</para>
<!-- Please scramble addresses; help prevent spam/email harvesting -->
<itemizedlist>
<listitem>
<para>
Evan Harris <email>eharris (at) puremagic.com</email>, who
conceived and wrote a white paper on <link
linkend="greylisting">greylisting</link>.
</para>
</listitem>
<listitem>
<para>
Axel Zinser <email>fifi (at) hiss.org</email>, who
apparently conceived of
<link linkend="smtpdelays">teergrubing</link>.
</para>
</listitem>
<listitem>
<para>
The developers of
<ulink url="http://spf.pobox.com/">SPF</ulink>,
<ulink url="http://www.danisch.de/work/security/antispam.html">RMX++</ulink>,
and other
<xref linkend="senderauth"/>.
</para>
</listitem>
<listitem>
<para>
The creators and maintainers of distributed, collaborative
junk mail signature repositories, such as
<ulink url="http://rhyolite.com/anti-spam/dcc/">DCC</ulink>,
<ulink url="http://razor.sf.net/">Razor</ulink>, and
<ulink url="http://pyzor.sf.net/">Pyzor</ulink>.
</para>
</listitem>
<listitem>
<para>
The creators and maintainers of various DNS blocklists and
whitelists, such as
<ulink url="http://www.spamcop.net/">SpamCop</ulink>,
<ulink url="http://www.spamhaus.org/">SpamHaus</ulink>,
<ulink url="http://www.sorbs.net/">SORBS</ulink>,
<ulink url="http://cbl.abuseat.org/">CBL</ulink>, and
<ulink url="http://moensted.dk/spam/">many others</ulink>.
</para>
</listitem>
<listitem>
<para>
The
<ulink url="http://www.spamassassin.org/full/3.0.x/dist/CREDITS">developers</ulink>
of
<ulink url="http://www.spamassassin.org/">SpamAssassin</ulink>,
who have taken giant leaps forward in developing and
integrating various spam filtering techniques into a
sophisticated heuristics-based tool.
</para>
</listitem>
<listitem>
<para>
Tim Jackson <email>tim (at) timj.co.uk</email> collated
and maintains a list of
<link linkend="bogusviruswarning">bogus virus warnings</link>
for use with SpamAssassin.
</para>
</listitem>
<listitem>
<para>
A lot of smart people who developed the excellent <link
linkend="exim">Exim</link> MTA, including: Philip
Hazel <email>ph10 (at) cus.cam.ac.uk</email>, the
maintainer; Tom Kistner <email>tom (at)
duncanthrax.net</email>, who wrote the Exiscan-ACL patch
for SMTP-time content checks; Andreas Metzler
<email>ametzler (at) debian.org</email>, who did a really
good job of building the Exim 4 Debian packages.
</para>
</listitem>
<listitem>
<para>
Many, many others who contributed ideas, software, and
other techniques to counter the spam epidemic.
</para>
</listitem>
<listitem>
<para>
You, for reading this document and your interest in
reclaiming e-mail as a useful communication tool
</para>
</listitem>
</itemizedlist>
</section>
<!-- Feedback -->
<section id="feedback">
<?dbhtml filename="intro-feedback.html"?>
<title>Feedback</title>
<para>
I would love to hear of your experiences with the techniques
outlined in this document, and of any other comments,
questions, suggestions, and/or contributions you may have.
Please send me an e-mail at: <email>tor@slett.net</email>.
</para>
<para>
If you are able to provide implementations for other <xref
linkend="mta"/>s, such as Sendmail or Postfix, please let me
know.
</para>
</section>
<!-- Translations -->
<section id="translations">
<?dbhtml filename="intro-translations.html"?>
<title>Translations</title>
<para>
No translations exist yet. If you would like to create one,
please let me know.
</para>
</section>
<section id="copyright">
<?dbhtml filename="intro-copyright.html"?>
<title>Copyright information</title>
<para>
Copyright &copy; 2004 Tor Slettnes.
</para>
<para>
This document is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
</para>
<para>
This document is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more details.
A copy of the license is included in <xref linkend="gpl"/>.
</para>
<para>
Read <ulink url="http://www.fsf.org/gnu/manifesto.html">The
GNU Manifesto </ulink> if you want to know why this license
was chosen for this book.
</para>
<para>
The logos, trademarks and symbols used in this book are the
properties of their respective owners.
</para>
</section>
<section id="prerequisites">
<?dbhtml filename="intro-prerequisites.html"?>
<title>What do you need?</title>
<para>
The techniques described in this document predicate system
access to the inbound <xref linkend="mx"/>(s) for the internet
domain where you receive e-mail. Essentially, you need to be
able to install software and/or modify the configuration files
for the <xref linkend="mta"/> on that system.
</para>
<para>
Although the discussions in this document are conceptual in
nature and can be incorporated into a number of different
MTAs, a sample Exim 4 implementation is provided. This
implementation, in turn, incorporates other software tools,
such as <ulink
url="http://www.spamassassin.org/">SpamAssassin</ulink>.
See <xref linkend="exim"/> for details.
</para>
</section>
<section id="conventions">
<?dbhtml filename="intro-conventions.html"?>
<title>Conventions used in this document</title>
<para>
The following typographic and usage conventions occur in this text:
</para>
<table id="conventiontable" frame="all">
<title>Typographic and usage conventions</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Text type</entry>
<entry>Meaning</entry>
</row>
</thead>
<tbody>
<row>
<entry><quote>Quoted text</quote></entry>
<entry>Quotes from people, quoted computer output.</entry>
</row>
<row>
<entry><screen>terminal view</screen></entry>
<entry>
Literal computer input and output captured from
the terminal, usually rendered with a light grey
background.
</entry>
</row>
<row>
<entry><command>command</command></entry>
<entry>
Name of a command that can be entered on the command
line.
</entry>
</row>
<row>
<entry><varname>VARIABLE</varname></entry>
<entry>
Name of a variable or pointer to content of a
variable, as in <varname>$VARNAME</varname>.
</entry>
</row>
<row>
<entry><option>option</option></entry>
<entry>
Option to a command, as in <quote>the
<option>-a</option> option to the
<command>ls</command> command</quote>.
</entry>
</row>
<row>
<entry><parameter>argument</parameter></entry>
<entry>
Argument to a command, as in
<quote>read <command>man
<parameter>ls</parameter></command>
</quote>.
</entry>
</row>
<row>
<entry>
<cmdsynopsis>
<command>command
<option>options</option>
<parameter>arguments</parameter>
</command>
</cmdsynopsis>
</entry>
<entry>
Command synopsis or general usage, on a separated
line.
</entry>
</row>
<row>
<entry><filename>filename</filename></entry>
<entry>
Name of a file or directory, for example <quote>Change
to the <filename>/usr/bin</filename>
directory.</quote>
</entry>
</row>
<row>
<entry><keycap>Key</keycap></entry>
<entry>
Keys to hit on the keyboard, such as <quote>type
<keycap>Q</keycap> to quit</quote>.
</entry>
</row>
<row>
<entry><guibutton>Button</guibutton></entry>
<entry>
Graphical button to click, like the
<guibutton>OK</guibutton> button.
</entry>
</row>
<row>
<entry>
<menuchoice>
<guimenu>Menu</guimenu>
<guimenuitem>Choice</guimenuitem>
</menuchoice>
</entry>
<entry>
Choice to select from a graphical menu, for instance:
<quote>Select
<menuchoice><guimenu>Help</guimenu><guimenuitem>About
Mozilla</guimenuitem> </menuchoice> in your
browser.</quote></entry>
</row>
<row>
<entry>
<emphasis>Terminology</emphasis></entry>
<entry>
Important term or concept:
<quote>The Linux <emphasis>kernel</emphasis>
is the heart of the system.</quote>
</entry>
</row>
<row>
<entry>
See <xref linkend="glossary" />
</entry>
<entry>
link to related subject within this guide.
</entry>
</row>
<row>
<entry>
<ulink
url="http://slett.net/gallery/2003-05/IMG_1655">The author</ulink>
</entry>
<entry>Clickable link to an external web resource.</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section id="organization">
<?dbhtml filename="intro-organization.html"?>
<title>Organization of this document</title>
<para>
This document is organized into the following chapters:
</para>
<variablelist>
<varlistentry>
<term><xref linkend="background"/></term>
<listitem>
<para>
General introduction to SMTP time filtering, and to SMTP.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><xref linkend="techniques"/></term>
<listitem>
<para>
Various ways to block junk mail in an SMTP transaction.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><xref linkend="considerations"/></term>
<listitem>
<para>
Issues that pertain to transaction time filtering.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><xref linkend="qanda"/></term>
<listitem>
<para>
My attempt at anticipating your questions, and then
answering them.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
A sample Exim implementation is provided in <xref
linkend="exim"/>.
</para>
</section>
</preface>
<toc></toc>
&background;
&techniques;
&consider;
&qanda;
&exim;
&glossary;
&gpl;
</book>

606
LDP/howto/docbook/Spam-Filtering-for-MX/chapter-background.xml Normal file
View File

@ -0,0 +1,606 @@
<?xml version='1.0' encoding='ISO-8859-1'?>
<chapter id="background" xreflabel="Background">
<?dbhtml filename="background.html"?>
<title>Background</title>
<abstract>
<para>
Here we cover the advantages of filtering mail during an
incoming SMTP transaction, rather than following the more
conventional approach of offloading this task to the mail
routing and delivery stage. We also provide a brief
introduction to the SMTP transaction.
</para>
</abstract>
<section id="whysmtptime" >
<?dbhtml filename="whysmtptime.html"?>
<title>Why Filter Mail During the SMTP Transaction?</title>
<section id="statusquo">
<title>Status Quo</title>
<para>
If you receive spam, raise your hands. Keep them up.
</para>
<para>
If you receive computer virii or other malware, raise your
hands too.
</para>
<para>
If you receive bogus <xref linkend="dsn"/>s (DSNs), such as
<quote>Message Undeliverable</quote>, <quote>Virus
found</quote>, <quote>Please confirm delivery</quote>, etc,
related to messages you never sent, raise your hands as well.
This is known as <xref linkend="colspam"/>.
</para>
<para>
This last form is particularly troublesome, because it is
harder to weed out than <quote>standard</quote> spam or
malware, and because such messages can be quite confusing to
recipients who do not possess godly skills in parsing message
headers. In the case of virus warnings, this often causes
unnecessary concern on the recipient's end; more generally, a
common tendency will be to ignore all such messages, thereby
missing out on legitimate DSNs.
</para>
<para>
Finally, I want those of you who have lost legitimate mail into
a big black hole - due to misclassification by spam or virus
scanners - to lift your feet.
</para>
<para>
If you were standing before and are still standing, I suggest
that you may not be fully aware of what is happening to your
mail. If you have been doing any type of spam filtering, even
by manually moving mails to the trash can in your mail reader,
let alone by experimenting with primitive filtering techniques
such as DNS blacklists (SpamHaus, SPEWS, SORBS...), chances
are that you have lost some valid mail.
</para>
</section>
<section id="cause">
<title>The Cause</title>
<para>
Spam, just like many other artifacts of greed, is a social
disease. Call it affluenza, or whatever you like; lower life
forms seek to destroy a larger ecosystem, and if successful,
will actually end up ruining their own habitat in the end.
</para>
<para>
Larger social issues and philosophy aside: You - the mail system
administrator - face the very concrete and real life dilemma of
finding a way to deal with all this junk.
</para>
<para>
As it turns out, there are some limitations with the
conventional way that mail is being processed and delegated by
the various components of mail transport and delivery
software. In a traditional setup, one or more <xref
linkend="mx"/>(s) accept most or all incoming mail deliveries
to addresses within a domain. Often, they then forward the
mail to one or more internal machines for further processing,
and/or delivery to the user's mailboxes. If any of these
servers discovers that it is unable to perform the requested
delivery or function, it generates and returns a DSN back to
the sender address in the original mail.
</para>
<para>
As organizations started deploying spam and virus scanners,
they often found that the path of least resistance was to work
these into the message delivery path, as mail is transferred
from the incoming <xref linkend="mx"/>(s) to internal delivery
hosts and/or software. For instance, a common way filter out
spam is by <emphasis>routing</emphasis> the mail through
SpamAssassin or other software before it is delivered to a
user's mailbox, and/or rely on spam filtering capabilities in
the user's <xref linkend="mua" />.
</para>
<para>
Options for dealing with mail that is classified as spam or
virus at this point are limited:
</para>
<itemizedlist>
<listitem>
<para>
You can return a <xref linkend="dsn"/> back to the sender.
The problem is that nearly all spam and e-mail borne
virii are delivered with faked sender addresses. If you
return this mail, it will invariably go to innocent third
parties -- perhaps warning a grandmother in Sweden, who
uses Mac OS X and does not know much about computers, that
she is infected by the Blaster worm. In other words, you
will be generating <xref linkend="colspam"/>.
</para>
</listitem>
<listitem>
<para>
You can drop the message into the bit bucket, without
sending any notification back to the sender. This is an
even bigger problem in the case of <xref
linkend="falsepos"/>s, because neither the sender nor
the receiver will ever know what happened to the message
(or in the receiver's case, that it ever existed).
</para>
</listitem>
<listitem>
<para>
Depending on how your users access their mail (for
instance, if they access it via the IMAP protocol or use a
web-based mail reader, but not if they retreive it over
POP-3), you may be able to file it into a separate junk
folder for them -- perhaps as an option in their account
settings.
</para>
<para>
This may be the best of these three options. Even so, the
messages may remain unseen for some time, or simply
overlooked as the receiver more-or-less periodically scans
through and deletes mail in their <quote>Junk</quote>
folder.
</para>
</listitem>
</itemizedlist>
</section>
<section id="solution">
<title>The Solution</title>
<para>
As you would have guessed by now, the <emphasis>One
True</emphasis> solution to this problem is to do spam and
virus filtering during the SMTP dialogue from the remote host,
as the mail is being received by the inbound mail exchanger
for your domain. This way, if the mail turns out to be
undesirable, you can issue a SMTP <emphasis>reject</emphasis>
response rather than face the dilemma described above. As a
result:
</para>
<itemizedlist>
<listitem>
<para>
You will be able to stop the delivery of most junk mail
early in the SMTP transaction, before the actual message
data has been received, thus saving you both network
bandwidth and CPU processing.
</para>
</listitem>
<listitem>
<para>
You will be able to deploy some spam filtering techniques
that are not possible later, such as
<xref linkend="smtpdelays"/> and
<xref linkend="greylisting"/>.
</para>
</listitem>
<listitem>
<para>
You will be able to notify the sender in case of a
delivery failure (e.g. due to an invalid recipient
address) without directly generating <xref
linkend="colspam"/>
</para>
<para>
We will discuss how you can avoid causing collateral spam
indirectly as a result of rejecting mail forwarded from
trusted sources, such as mailing list servers or mail
accounts on other sites
<footnote>
<para>
Untrusted third party hosts may still generate
collateral spam if you reject the mail. However,
unless that host is an <xref linkend="openproxy"/> or
<xref linkend="openrelay"/>, it presumably delivers
mail only from legitimate senders, whose addresses are
valid. If it <emphasis>is</emphasis> an Open Proxy or
SMTP Relay - well, it is better that you reject the
mail and let it freeze in <emphasis>their</emphasis>
outgoing mail queue than letting it freeze in yours.
Eventually, this ought to give the owners of that
server a clue.
</para>
</footnote>.
</para>
</listitem>
<listitem>
<para>
You will be able to protect yourself against collateral
spam from others (such as bogus <quote>You have a
virus</quote> messages from anti-virus software).
</para>
</listitem>
</itemizedlist>
<para>
OK, you can lower your hands now. If you were standing, and
your feet disappeared from under you, you can now also stand up
again.
</para>
</section>
</section>
<section id="goodbadugly" xreflabel="The Good, The Bad, The Ugly">
<?dbhtml filename="goodbadugly.html"?>
<title>The Good, The Bad, The Ugly</title>
<para>
Some filtering techniques are more suitable for use during the
SMTP transaction than others. Some are simply better than
others. Nearly all have their proponents and opponents.
</para>
<para>
Needless to say, these controversies extend to the methods
described here as well. For instance:
</para>
<itemizedlist>
<listitem>
<para>
Some argue that <xref linkend="dnschecks"/> penalize
individual mail senders purely based on their Internet
Service Provider (ISP), not on the merits of their
particular message.
</para>
</listitem>
<listitem>
<para>
Some point out that ratware traps like <xref
linkend="smtpdelays"/> and <xref linkend="greylisting"/> are
easily overcome and will be less effective over time, while
continuing to degrade the Quality of Service for legitimate
mail.
</para>
</listitem>
<listitem>
<para>
Some find that <xref linkend="senderauth"/> like the <xref
linkend="spf"/> give ISPs a way to lock their customers in,
and do not adequately address users who roam between
different networks or who forward their e-mail from one host
to another.
</para>
</listitem>
</itemizedlist>
<para>
I will steer away from most of these controversies. Instead, I
will try to provide a functional description of the various
techniques available, including their possible side effects, and
then talk a little about my own experiences using some of them.
</para>
<para>
That said, there are some filtering methods in use today that I
deliberately omit from this document:
</para>
<itemizedlist>
<listitem>
<para>
Challenge/response systems (like <ulink
url="http://tmda.net/">TMDA</ulink>). These are not
suitable for SMTP time filtering, as they rely on first
accepting the mail, then returning a confirmation request to
the <xref linkend="envfrom"/>. This technique is therefore
outside the scope of this document.
<footnote>
<para>
Personally I do not think challenge/response systems are
a good idea in any case. They generate <xref
linkend="colspam"/>, they require special attention for
mail sent from automated sources such as monthly bank
statements, and they degrade the usability of e-mail as
people need to jump through hoops to get in touch with
each other. Many times, senders of legitimate mail will
not bother to or know that they need to follow up to the
confirmation request, and the mail is lost.
</para>
</footnote>
</para>
</listitem>
<listitem>
<para>
<xref linkend="bayesian"/>. These require training specific
to a particular user, and/or a particular language. As
such, these too are not normally suitable for use during the
SMTP transaction (But see <xref linkend="usersettings"/>).
</para>
</listitem>
<listitem>
<para>
<xref linkend="micropay"/> are not really suitable for
weeding out junk mail until all the world's legitimate mail
is sent with a virtual <emphasis>postage stamp</emphasis>.
(Though in the mean time, they can be used for the opposite
purpose - that is, to accept mail carrying the stamp that
would otherwise be rejected).
</para>
</listitem>
</itemizedlist>
<para>
Generally, I have attempted to offer techniques that are as
precise as possible, and to go to great lengths to avoid <xref
linkend="falsepos"/>s. People's e-mail is important to them,
and they spend time and effort writing it. In my view,
willfully using techniques or tools that reject large amounts of
legitimate mail is a show of disrespect, both to the people that
are directly affected and to the Internet as a whole.
<footnote>
<para>
My view stands in sharp contrast to that of a large number
of <quote>spam hacktivists</quote>, such as the maintainers
of the <ulink url="http://www.spews.org/">SPEWS</ulink>
<link linkend="dnsbl">blacklist</link>. One of the stated
aims of this list is precisely to inflict <xref
linkend="coldamage"/> as a means of putting pressure on ISPs
to react on abuse complaints. Listing complaints are
typically met with knee-jerk responses such as <quote>bother
your ISP, not us</quote>, or <quote>get another ISP</quote>.
</para>
<para>
Often, these are not viable options. Consider developing
countries. For that matter, consider the fact that nearly
everywhere, broadband providers are regulated monopolies. I
believe that these attitudes illustrate the exact crux of
the problem with trusting these groups.
</para>
<para>
Put plainly, there are much better and more accurate ways
available to filter junk mail.
</para>
</footnote>
This is especially true for SMTP-time system wide filtering,
because end recipients usually have little or no control over
the criteria being used to filter their mail.
</para>
</section>
<section id="smtpintro" xreflabel="The SMTP Transaction">
<?dbhtml filename="smtpintro.html"?>
<title>The SMTP Transaction</title>
<para>
SMTP is the protocol that is used for mail delivery on the
Internet. For a detailed description of the protocol, please
refer to <ulink url="http://www.ietf.org/rfc/rfc2821.txt">RFC
2821</ulink>, as well as Dave Crocker's introduction to
<ulink url="http://www.brandenburg.com/specifications/draft-crocker-mail-arch-00.htm">Internet Mail Architecture</ulink>.
</para>
<para>
Mail deliveries involve an SMTP transaction between the
connecting host (client) and the receiving host (server). For
this discussion, the connecting host is the peer, and the
receiving host is your server.
</para>
<para>
In a typical SMTP transaction, the client issues SMTP commands
such as <command>EHLO</command>, <command>MAIL FROM:</command>,
<command>RCPT TO:</command>, and <command>DATA</command>. Your
server responds to each command with a 3-digit numeric code
indicating whether the command was accepted
(<command>2<parameter>xx</parameter></command>), was subject to
a temporary failure or restriction
(<command>4<parameter>xx</parameter></command>), or failed
definitively/permanently
(<command>5<parameter>xx</parameter></command>), followed by
some human readable explanation. A full description of these
codes is included in
<ulink url="http://www.ietf.org/rfc/rfc2821.txt">RFC 2821</ulink>.
</para>
<para>
A best case scenario SMTP transaction typically consists of the
following relevant steps:
</para>
<table id="smtpdialogue" frame="all">
<title>Simple SMTP dialogue</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Client</entry>
<entry>Server</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>
Initiates a TCP connection to server.
</para>
</entry>
<entry>
<para>
Presents an SMTP banner - that is, a greeting that
starts with the code <command>220</command> to indicate
that it is ready to speak SMTP (or usually ESMTP, a
superset of SMTP):
<screen>220 <parameter>your.f.q.d.n</parameter> ESTMP...</screen>
</para>
</entry>
</row>
<row>
<entry>
<para>
Introduces itself by way of an Hello command, either
<command>HELO</command> (now obsolete) or
<command>EHLO</command>, followed by its own <xref
linkend="fqdn" />:
<screen>EHLO <parameter>peers.f.q.d.n</parameter></screen>
</para>
</entry>
<entry>
<para>
Accepts this greeting with a <command>250</command>
response. If the client used the
<emphasis>extended</emphasis> version of the Hello
command (<command>EHLO</command>), your server knows
that it is capable of handling multi-line responses,
and so will normally send back several lines
indicating the capabilities offered by your server:
<screen>
250-<parameter>your.f.q.d.n</parameter> Hello ...
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-STARTTLS
250-AUTH
250 HELP
</screen>
</para>
<para>
If the <command>PIPELINING</command> capability is
included in this response, the client can from this point
forward issue several commands at once, without waiting
for the response to each one.
</para>
</entry>
</row>
<row>
<entry>
<para>
Starts a new mail transaction by specifying the
<xref linkend="envfrom" />:
<screen>MAIL FROM:&lt;<parameter>sender</parameter>@<parameter>address</parameter>&gt;
</screen>
</para>
</entry>
<entry>
<para>
Issues a <command>250</command> response to indicate
that the sender is accepted.
</para>
</entry>
</row>
<row>
<entry>
<para>
Lists the <xref linkend="envto"/>s of the message, one
at a time, using the command:
<screen>RCPT TO:&lt;<parameter>receiver</parameter>@<parameter>address</parameter>&gt;</screen>
</para>
</entry>
<entry>
<para>
Issues a response to each command
(<command>2<parameter>xx</parameter></command>,
<command>4<parameter>xx</parameter></command>, or
<command>5<parameter>xx</parameter></command>,
depending on whether delivery to this recipient was
accepted, subject to a temporary failure, or
rejected).
</para>
</entry>
</row>
<row>
<entry>
<para>
Issues a <command>DATA</command> command to indicate
that it is ready to send the message.
</para>
</entry>
<entry>
<para>
Responds <command>354</command> to indicate that the
command has been provisionally accepted.
</para>
</entry>
</row>
<row>
<entry>
<para>
Transmits the message, starting with RFC 2822
compliant header lines (such as:
<option>From:</option>, <option>To:</option>,
<option>Subject:</option>, <option>Date:</option>,
<option>Message-ID:</option>). The header and the
body are separated by an empty line. To indicate the
end of the message, the client sends a single period
(".") on a separate line.
</para>
</entry>
<entry>
<para>
Replies <command>250</command> to indicate that the
message has been accepted.
</para>
</entry>
</row>
<row>
<entry>
<para>
If there are more messages to be delivered, issues the
next <command>MAIL FROM:</command> command.
Otherwise, it says <command>QUIT</command>, or in rare
cases, simply disconnects.
</para>
</entry>
<entry>
<para>
Disconnects.
</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</chapter>

223
LDP/howto/docbook/Spam-Filtering-for-MX/chapter-considerations.xml Normal file
View File

@ -0,0 +1,223 @@
<?xml version='1.0' encoding='ISO-8859-1'?>
<chapter id="considerations" xreflabel="Considerations">
<?dbhtml filename="considerations.html"?>
<title>Considerations</title>
<abstract>
<para>
Some specific considerations come into play as a result of
system-wide SMTP time filtering. Here we cover some of those.
</para>
</abstract>
<section id="multimx" xreflabel="Multiple Incoming Mail Exchangers">
<?dbhtml filename="multimx.html"?>
<title>Multiple Incoming Mail Exchangers</title>
<para>
Most domains list more than one incoming <xref linkend="mx"/>s
(a.k.a. <quote>MX hosts</quote>). If you do so, then bear in
mind that in order to have any effect, any SMTP time filtering
you incorporate on the primary MX has to be incorporated on all
the others as well. Otherwise, the sending host would simply
sidestep filtering by retrying the mail delivery through your
backup server(s).
</para>
<para>
If the backup server(s) are not under your control, ask
yourself whether you need multiple MXs in the first place. In
this situation, chances are that they serve only as
<emphasis>redundant</emphasis> mail servers, and that they in
turn forward the mail to your primary MX. If so, you probably
don't need them. If your host happens to be down for a little
while, that's OK -- well-behaved sender hosts will retry
deliveries for several days before giving up
<footnoteref linkend="noretrysenders"/>.
</para>
<para>
A situation where you <emphasis>may</emphasis> need multiple
MXs is to perform load balancing between several servers -
i.e. if you receive so much mail that one machine alone could
not handle it. In this case, see if you could offload some
tasks (such as <link linkend="virusscanners">virus</link> and
<link linkend="spamscanners">spam</link> scanners) to other
machines, in order to reduce or eliminate this need.
</para>
<para>
Again, if you do decide to keep using several MXs, your backup
servers need to be (at least) as restrictive as the primary
server, lest filtering in the primary MX is useless.
</para>
<para>
See also the section on <xref linkend="greylisting"/> for
additional concerns related to multiple MX hosts.
</para>
</section>
<section id="otherservers" xreflabel="Blocking Access to Other SMTP Servers">
<?dbhtml filename="otherservers.html"?>
<title>Blocking Access to Other SMTP Servers</title>
<para>
Any SMTP server that is not listed as a public <xref
linkend="mx"/> in the DNS zone of your domain(s) should not
accept incoming connections from the internet. All incoming
mail traffic should go through your incoming mail exchanger(s).
</para>
<para>
This consideration is not unique to SMTP servers. If you have
machines that only serve an internal purpose within your site,
use a firewall to restrict access to these.
</para>
<para>
This is a rule, so therefore there must be exceptions. However,
if you don't know what they are, then the above applies to you.
</para>
</section>
<section id="forwardedmail" xreflabel="Forwarded Mail">
<?dbhtml filename="forwardedmail.html"?>
<title>Forwarded Mail</title>
<para>
You should take care not to reject mail as a result of spam
filtering if it is forwarded from <quote>friendly</quote>
sources, such as:
</para>
<itemizedlist>
<listitem>
<para>
Your backup MX hosts, if any. Supposedly, these have
already filtered out most of the junk (see <xref
linkend="multimx"/>).
</para>
</listitem>
<listitem>
<para>
Mailing lists, to which you or your users subscribe. You may
still filter such mail (it may not be as criticial if it
ends up in a black hole). However, if you reject the mail,
you may end up causing the list server to automatically
unsubscribe the recipient.
</para>
</listitem>
<listitem>
<para>
Other accounts belonging to the recipient. Again,
rejections will generate collateral spam, and/or create
problems for the host that forwards the mail.
</para>
</listitem>
</itemizedlist>
<para>
You may see a logistical issue with the last two of these
sources: They are specific to each recipient. How to you allow
each user to specify which hosts they want to whitelist, and
then use such individual whitelists in a system-wide SMTP-time
filtering setup? If the message is forwarded to several
recipients at your site (as may often be true in the case of
a mailing list), how do you decide whose whitelist to use?
</para>
<para>
There is no magic bullet here. This is one of those situations
where we just have to do a bit of work. You can decide to
accept all mails, regardless of spam classification, so long as
it is sent from a host in the whitelist of any one of the
recipients. For instance, in response to each <command>RCPT
TO:</command> command, we can match the sending host against the
corresponding user's whitelist. If found, set a flag that will
prevent a subsequent rejection. Effectively, you are using an
<emphasis>aggregate</emphasis> of each recipient's whitelist.
</para>
<para>
The implementation appendices cover this in more detail.
</para>
</section>
<section id="usersettings" xreflabel="User Settings and Data">
<?dbhtml filename="usersettings.html"?>
<title>User Settings and Data</title>
<para>
There are other situations where you may want to support
settings and data for each user at site. For instance, if you
scan incoming mail with SpamAssassin (see <xref
linkend="spamscanners"/>), you may want to allow for individual
spam thresholds, acceptable languages and character sets, and
Bayesian training/data.
</para>
<para>
A sticking point is that SMTP-time filtering of incoming mail is
done at the system level, before mail is being delivered to a
particular user, and as such, does not lend itself too well to
individual preferences. A single message may have several
recipients; and unlike the case with <xref
linkend="forwardedmail"/>, using an aggregate of each
recipient's preferences is not a good option. Consider a
scenario where you have users from different linguistic
backgrounds.
</para>
<para>
As it turns out, though, there is a modification to this truth.
The trick is to limit the number of recipients in incoming
messages to one, so that the message can be analyzed in
accordance with the settings and data that belongs to the
corresponding user.
</para>
<para>
To do this, you would accept the first <command>RCPT
TO:</command>, then issue a SMTP <command>451</command> (defer)
response to subsequent commands. If the caller is a
well-behaved MTA, it will know how to interpret this response,
and try later. (If it is confused, then, well, it is probably a
sender from which you don't want to receive mail in the first
place).
</para>
<para>
Obviously, this is a hack. Every mail sent to several users at
your site will be slowed down by 30 minutes or more per
recipient. Especially in corporate environments, where it is
common to see e-mail discussions involving several people on the
inside and several others on the outside, and where timelines of
mail deliveries are essential, this is probably not a good
solution at all.
</para>
<para>
Another issue that mainly pertains to corporate enterprises and
other large sites is that incoming mail is often forwarded to
internal machines for delivery, and that recipients don't
normally have accounts on the mail exchanger. It may still be
possible to support user-specific settings and data in these
situations (e.g. via database lookups or LDAP queries), but you
may also want to consider whether it's worth the effort.
</para>
<para>
That said, if you are on a small site, and where you are not
afraid of delayed deliveries, this may be an acceptable way
to allow each user to fine tune their filtering criteria.
</para>
</section>
</chapter>

143
LDP/howto/docbook/Spam-Filtering-for-MX/chapter-qanda.xml Normal file
View File

@ -0,0 +1,143 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="qanda" xreflabel="Questions &amp; Answers">
<?dbhtml filename="qanda.html"?>
<title>Questions &amp; Answers</title>
<abstract>
<para>
In this section I try to anticipate some of the questions that
may come up, and to answer them. If you have questions that are
not listed, and/or would like to provide extra input in this
section, please provide <link linkend="feedback">feedback</link>.
</para>
</abstract>
<qandaset defaultlabel="qanda">
<title>When Spammers Adapt</title>
<qandaentry id="qanda-adapt">
<question>
<para>
What happens when spammers adapt and try to get around the
techniques described in this document?
</para>
</question>
<answer>
<para>
Well, that depends. :-)
</para>
<para>
Some of the checks described (such as <xref
linkend="smtpchecks"/> and <xref linkend="greylisting"/>)
specifically target <emphasis>ratware</emphasis> behavior.
It is certainly possible to imagine that this behavior will
change if enough sites incorporate these checks. Hatmut
Danisch notes:
<emphasis>
Ratware contains buggy SMTP protocols because they didn't
need to do any better. It worked this way, so why should
they have spent more time? Meanwhile
<quote>ratware</quote> has a higher quality, and even the
quality of spam messages has significantly improved. Once
enough people reject spam by detecting bad SMTP protocols,
spam software authors will simply improve their
software.
</emphasis>
</para>
<para>
That said, there are challenges remaining for such ratware:
</para>
<itemizedlist>
<listitem>
<para>
To get around <xref linkend="smtpdelays"/>, they need to
wait for each response from the receiving SMTP server.
At that point, we have collectively accomplished a
significant reduction in the rate of mail that a given
spamming host is able to deliver per unit of time.
Since spammers are racing against time to deliver as
many mails as possible before DNS blocklists and
collaborative content filters catch up, we are improving
the effectiveness of these tools.
</para>
<para>
The effect is similar to the goal of <xref
linkend="micropay"/>, wherein the sender spends a few
seconds working on a computational challenge for each
recipient of the mail, and adds a resulting signature to
the e-mail header for the recipient to validate. The
main difference, aside from the complexity of these
schemes, is that they require the participation of
virtually everyone in the world before they can
effectively be used to weed out spam, whereas SMTP
transaction delays start being effective with the first
recipient machine that implements it.
</para>
</listitem>
<listitem>
<para>
To get around a <xref linkend="helocheck"/>, they need
to provide a proper greeting, i.e. identify themselves
with a valid <xref linkend="fqdn"/>. This provides for
increased traceability, especially with receiving <xref
linkend="mta"/>s that do not automatically insert the
results of a rDNS lookup into the Received: header of
the message.
</para>
</listitem>
<listitem>
<para>
To get all of the <xref linkend="senderchecks"/>, they
need to provide their own valid sender address (or, at
least, <emphasis>a</emphasis> valid sender address
within their own domain). Nuff said.
</para>
</listitem>
<listitem>
<para>
To get around <xref linkend="greylisting"/>, they need
to retry deliveries to temporarily failed recipients
addresses after one hour (but before four hours). (As
far as implementation goes, in order to minimize machine
resources, rather than keeping a copy of each
temporarily failed mail, ratware may keep only a list of
temporarily failed recipients, and perform a second
sweep through those addresses after an hour or two).
</para>
<para>
Even so, <emphasis>greylisting</emphasis> will remain
fairly effective in conjunction with <xref
linkend="dnsbl"/> that are fed from <xref
linkend="spamtrap"/>s. That is because the mandatory
one-hour retry delay will give these lists a chance to
list the sending host.
</para>
</listitem>
</itemizedlist>
<para>
Software tools, such as <xref linkend="spamscanners"/> and
<xref linkend="virusscanners"/>, are in constant evolution.
As spammers evolve, so do these (and vice versa). As long
as you use recent versions of these tools, they will remain
quite effective.
</para>
<para>
Finally, this document is itself subject to change. As the
nature of junk mail changes, people will come up with new,
creative ways to block it.
</para>
</answer>
</qandaentry>
</qandaset>
</chapter>

2083
LDP/howto/docbook/Spam-Filtering-for-MX/chapter-techniques.xml Normal file
View File

File diff suppressed because it is too large Load Diff

675
LDP/howto/docbook/Spam-Filtering-for-MX/glossary.xml Normal file
View File

@ -0,0 +1,675 @@
<glossary id="glossary" xreflabel="Glossary">
<?dbhtml filename="gloss.html"?>
<title>Glossary</title>
<abstract>
<para>
These are definitions for some of the words and terms that are
used throughout this document.
</para>
</abstract>
<glossdiv>
<title>B</title>
<glossentry id="bayesian">
<glossterm>Bayesian Filters</glossterm>
<glossdef>
<para>
A filter that assigns a probability of spam based on the
recurrence of words (or, more recently, word
constellations/phrases) between messages.
</para>
<para>
You initially train the filter by feeding it known junk mail
(spam) and known legitimate mail (ham). A bayesian score
is then be assigned to each word (or phrase) in each
message, indicating whether this particular word or phrase
occurs most commonly in ham or in spam. The word, along
with its score, is stored in a <emphasis>bayesian
index</emphasis>.
</para>
<para>
Such filters may catch indicators that may be missed by
human programmers trying to manually create keyword-based
filters. At the very least, they automate this task.
</para>
<para>
Bayesian word indexes are most certainly specific to the
language in which they received training. Moreover, they are
specific to individual users. Thus, they are perhaps more
suitable for individual content filters (e.g. in <xref
linkend="mua"/>s) than they are for system-wide, SMTP-time
filtering.
</para>
<para>
Moreover, spammers have developed techniques to defeat
simple bayesian filters, by including random dictionary
words and/or short stories in their messages. This
decreases the spam probability assigned by a baynesian
filter, and in the long run, degrades the quality of the
bayesian index.
</para>
<para>
See also:
<ulink url="http://www.everything2.com/index.pl?node=Bayesian"/>.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>C</title>
<glossentry id="coldamage">
<glossterm>Collateral Damage</glossterm>
<glossdef>
<para>
Blocking of a legitimate sender host due to an entry in a
DNS blocklist.
</para>
<para>
Some blocklists (like SPEWS) routinely list the entire IP
address space of an ISP if they feel the ISP is not
responsive to abuse complaints, thereby affecting
<emphasis>all</emphasis> its customers.
</para>
<para>
See also: <xref linkend="falsepos"/>
</para>
</glossdef>
</glossentry>
<glossentry id="colspam">
<glossterm>Collateral Spam</glossterm>
<glossdef>
<para>
Automated messages sent in response to an original message
(mostly spam or malware) where the sender address is forged.
Typical examples of collateral spam include virus scan
reports (<quote>You have a virus</quote>) or other <xref
linkend="dsn" />s).
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>D</title>
<glossentry id="dns">
<glossterm>Domain Name System</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: DNS</emphasis>) The de-facto standard for
obtaining information about internet domain names. Examples
of such information include IP addresses of its servers
(so-called <emphasis>A records</emphasis>), the dedication
of incoming mail exchangers (MX records), generic server
information (SRV records), and miscellaneous text
information (TXT records).
</para>
<para>
DNS is a hierarctical, distributed system; each domain name
is associated with a set of one or more DNS servers that
provide information about that domain - including delegation
of name service for its subdomains.
</para>
<para>
For instance, the top-level domain <quote>org</quote> is
operated by The Public Interest Registry; its DNS servers
delegate queries for the domain name <quote>tldp.org</quote>
to specific name servers for The Linux Documentation
Project. In turn, TLDPs name server (actually operated by
UNC) may or may not delegate queries for third-level names,
such as <quote>www.tldp.org</quote>.
</para>
<para>
DNS lookups are usually performed by forwarding name
servers, such as those provided by an Internet Service
Provider (e.g. via DHCP).
</para>
</glossdef>
</glossentry>
<glossentry id="dsn">
<glossterm>Delivery Status Notification</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: DSN</emphasis>) A message automatically
created by an MTA or MDA, to inform the sender of an
original messsage (usually included in the DSN) about its
status. For instance, DSNs may inform the sender of the
original message that it could not be delivered due to a
temporary or permanent problem, and/or whether or not and
for how long delivery attempts will continue.
</para>
<para>
Delivery Status Notifications are sent with an empty <xref
linkend="envfrom" /> address.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>E</title>
<glossentry id="envfrom">
<glossterm>Envelope Sender</glossterm>
<glossdef>
<para>
The e-mail address given as sender of a message during the
SMTP transaction, using the <command>MAIL FROM:</command>
command. This may be different from the address provided in
the <quote>From:</quote> header of the message itself.
</para>
<para>
One special case is <xref linkend="dsn" /> (bounced message,
return receipt, vacation message..). For such mails, the
<xref linkend="envfrom"/> is empty. This is to prevent
<xref linkend="loop"/>s, and generally to be able to
distinguish these from <quote>regular</quote> mails.
</para>
<para>
See also: <xref linkend="smtpintro" />
</para>
</glossdef>
</glossentry>
<glossentry id="envto">
<glossterm>Envelope Recipient</glossterm>
<glossdef>
<para>
The e-mail address(es) to which the message is sent. These
are provided during the SMTP transaction, using the
<command>RCPT TO</command> command. These may be different
from the addresses provided in the <quote>To:</quote> and
<quote>Cc:</quote> headers of the message itself.
</para>
<para>
See also: <xref linkend="smtpintro" />
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>F</title>
<glossentry id="falseneg">
<glossterm>False Negative</glossterm>
<glossdef>
<para>
Junk mail (spam, virus, malware) that is misclassified as
legitimate mail (and consequently, not filtered out).
</para>
</glossdef>
</glossentry>
<glossentry id="falsepos">
<glossterm>False Positive</glossterm>
<glossdef>
<para>
Legitimate mail that is misclassified as junk (and
consequently, blocked).
</para>
<para>
See also: <xref linkend="coldamage"/>.
</para>
</glossdef>
</glossentry>
<glossentry id="fqdn">
<glossterm>Fully Qualified Domain Name</glossterm>
<glossdef>
<para>
(a.k.a. <quote>FQDN</quote>). A full, globally unique,
internet name, including DNS domain. For instance:
<quote>www.yahoo.com</quote>.
</para>
<para>
A <emphasis>FQDN</emphasis> does not always point to a single
host. For instance, common service names such as
<quote>www</quote> often point to many IP addresses, in
order to provide some load balancing on the servers.
However, the <emphasis>primary</emphasis> host name of a
given machine should always be unique to that machine; for
instance: <quote>p16.www.scd.yahoo.com</quote>.
</para>
<para>
A <emphasis>FQDN</emphasis> always contains a period (".").
The part before the first period is the
<emphasis>unqualified name</emphasis>, and is not globally
unique.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>J</title>
<glossentry id="joejob">
<glossterm>Joe Job</glossterm>
<glossdef>
<para>
A spam designed to look like it came from someone else's
valid address, often in a malicous attempt at generating
complaints from third parties and/or cause other damage to
the owner of that address.
</para>
<para>
See also:
<ulink url="http://www.everything2.com/index.pl?node=Joe%20Job"/>
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>M</title>
<glossentry id="mda">
<glossterm>Mail Delivery Agent</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: MDA</emphasis>) Software that runs on the
machine where a users' mailbox is located, to deliver mail
into that mailbox. Often, that delivery is performed
directly by the MTA <xref linkend="mta" />, which then
serves a secondary role as an MDA. Examples of separate
Mail Delivery Agents include: Deliver, Procmail, Cyrmaster
and/or Cyrdeliver (from the Cyrus IMAP suite).
</para>
</glossdef>
</glossentry>
<glossentry id="loop">
<glossterm>Mail Loop</glossterm>
<glossdef>
<para>
A situation where one automated message triggers another,
which directly or indirectly triggers the first message
over again, and so on.
</para>
<para>
Imagine a mailing list where one of the subscribers is the
address of the list itself. This situation is often dealt
with by the list server adding an <quote>X-Loop:</quote>
line in the message header, and not processing mails that
already have one.
</para>
<para>
Another equivalent term is <emphasis>Ringing</emphasis>.
</para>
</glossdef>
</glossentry>
<glossentry id="mta">
<glossterm>Mail Transport Agent</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: MTA</emphasis>) Software that runs on a
mail server, such as the mail exchanger(s) of a internet
domain, to send mail to and receive mail from other hosts.
Popular MTAs include: Sendmail, Postfix, Exim, Smail.
</para>
</glossdef>
</glossentry>
<glossentry id="mua">
<glossterm>Mail User Agent</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: MUA</emphasis>; a.k.a. <emphasis>Mail
Reader</emphasis>) User software to access, download, read,
and send mail. Examples include Microsoft Outlook/Outlook
Express, Apple Mail.app, Mozilla Thunderbird, Ximian
Evolution.
</para>
</glossdef>
</glossentry>
<glossentry id="mx">
<glossterm>Mail Exchanger</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: MX</emphasis>) A machine dedicated to
(sending and/or) receiving mail for an internet domain.
</para>
<para>
The DNS zone information for a internet domain normally
contains a list of <xref linkend="fqdn" />s that act as
incoming mail exchangers for that domain. Each such listing
is called an <quote>MX record</quote>, and it also contains
a number indicating its <quote>priority</quote> among
several <quote>MX records</quote>. The listing with the
lowest number has the first priority, and is considered the
<quote>primary mail exchanger</quote> for that domain.
</para>
</glossdef>
</glossentry>
<glossentry id="micropay">
<glossterm>Micropayment Schemes</glossterm>
<glossdef>
<para>
(a.k.a. <emphasis>sender pay</emphasis> schemes). The
sender of a message expends some machine resources to create
a virtual <emphasis>postage stamp</emphasis> for each
recipient of a message - usually by solving a mathematical
challenge that requires a large number of memory read/write
operations, but is relatively CPU speed insensitive. This
stamp is then added to the headers of the message, and the
recipient would validate the stamp through a much simpler
decoding operation.
</para>
<para>
The idea is that because the message requires a postage
stamp for every recipient address, spamming hundreds or
thousands of users at once would be prohibitively
"expensive".
</para>
<para>
Two such systems are:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="http://www.camram.org/">Camram</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://research.microsoft.com/research/sv/PennyBlack/">Microsoft's
Penny Black Project</ulink>
</para>
</listitem>
</itemizedlist>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>O</title>
<glossentry id="openproxy">
<glossterm>Open Proxy</glossterm>
<glossdef>
<para>
A <xref linkend="proxy" /> which openly accepts TCP/IP
connections from anywhere, and forwards them anywhere.
</para>
<para>
These are typically exploited by spammers and virii, who
use them to conceal their own IP address, and/or to more
effectively distribute transmission loads across several
hosts and networks.
</para>
<para>
See also: <xref linkend="zombie" />
</para>
</glossdef>
</glossentry>
<glossentry id="openrelay">
<glossterm>Open Relay</glossterm>
<glossdef>
<para>
A <xref linkend="relay" /> which openly accepts mail from
anywhere, and forwards them to anywhere.
</para>
<para>
In the 1980s, virtually every public SMTP server was an
<xref linkend="openrelay" />. Messages would often travel
between multiple third-party machines before it reached the
intended recipient. Now, legitimate mail are almost
exclusively sent directly from an outgoing <xref
linkend="mta"/> on the sender's end to the incoming <xref
linkend="mx"/>(s) for the recipient's domain.
</para>
<para>
Conversely, <xref linkend="openrelay"/> servers that still
exist on the internet are almost exclusively exploited by
spammers to hide their own identity, and to perform some
load balancing on the task of sending out millions of
messages, presumably before DNS blocklists have a chance to
get all of these machines listed.
</para>
<para>
See also the discussion on <xref linkend="relayprevent"/>.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>P</title>
<glossentry id="proxy">
<glossterm>proxy</glossterm>
<glossdef>
<para>
A machine that acts on behalf of someone else. It may
forward e.g. HTTP requests or TCP/IP connections, usually to
or from the internet. For instance, companies - or
sometimes entire countries - often use <quote>Web Proxy
Servers</quote> to filter outgoing HTTP requests from their
internal network. This may or may not be transparent to the
end user.
</para>
<para>
See also: <xref linkend="openproxy" />, <xref
linkend="relay" />.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>R</title>
<glossentry id="ratware">
<glossterm>Ratware</glossterm>
<glossdef>
<para>
Mass-mailing virii and e-mail software used by spammers,
specifically designed to deliver large amounts of mail in a
very short time.
</para>
<para>
Most ratware implementations incorporate only as much SMTP
client code as strictly neccessary to deliver mail in the
best-case scenario. They provide false or inaccurate
information in the SMTP dialogue with the receiving host.
They do not wait for responses from the receiver before
issuing commands, and disconnect if no response has been
received in a few seconds. They do not follow normal retry
mechanisms in case of temporary failures.
</para>
</glossdef>
</glossentry>
<glossentry id="relay">
<glossterm>Relay</glossterm>
<glossdef>
<para>
A machine that forwards e-mail, usually to or from the
internet. One example of a relay is the
<quote>smarthost</quote> that an ISP provides to its
customers for sending outgoing mail.
</para>
<para>
See also: <xref linkend="openrelay" />, <xref
linkend="proxy" />
</para>
</glossdef>
</glossentry>
<glossentry id="rfc">
<glossterm>Request for Comments</glossterm>
<glossdef>
<para>
(<emphasis>abbrev: RFC</emphasis>) From
<ulink
url="http://www.rfc-editor.org/">http://www.rfc-editor.org/</ulink>:
<quote>
The Request for Comments (RFC) document series is a set of
technical and organizational notes about the internet
[...]. Memos in the RFC series discuss many aspects of
computer networking, incluing protocols, procedures,
programs, and concepts, as well as meeting notes,
opinions, and sometimes humor.
</quote>
</para>
<para>
These documents make up the <quote>rules</quote> internet
conduct, including descriptions of protocols and data
formats. Of particular interest for mail deliveries are:
<itemizedlist>
<listitem>
<para>
<ulink url="http://www.ietf.org/rfc/rfc2821">RFC
2821</ulink>, "Simple Mail transfer Protocol", and
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.ietf.org/rfc/rfc2821">RFC
2822</ulink>, "Internet Message Format".
</para>
</listitem>
</itemizedlist>
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>S</title>
<glossentry id="spamtrap">
<glossterm>Spam Trap</glossterm>
<glossdef>
<para>
An e-mail address that is <emphasis>seeded</emphasis> to
address-harvesting robots via public locations, then used to
feed collaborative tools such as <xref linkend="dnsbl"/> and
<xref linkend="jmsr"/>.
</para>
<para>
Mails sent to these addresses are normally spam or malware.
However, some of it will be <emphasis>collateral</emphasis>,
spam - i.e. <xref linkend="dsn"/> to faked sender addresses.
Thus, unless the spam trap has safeguards in place to
disregard such messages, the resulting tool may not be
completely reliable.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv>
<title>Z</title>
<glossentry id="zombie">
<glossterm>Zombie Host</glossterm>
<glossdef>
<para>
A machine with an internet connection that is infected by a
mass-mailing virus or worm. Such machines invariably run a
flavor of the Microsoft&reg; Windows&reg; operating system,
and are almost always in <quote>residential</quote> IP
address blocks. Their owners either do not know or do not
care that the machines are infected, and often, their ISP
will not take any actions to shut them down.
</para>
<para>
Fortunately, there are various DNS blocklists, such as
<quote>dul.dnsbl.sorbs.net</quote>, that incorporate such
"residential" address blocks. You should be able to use
these blocklists to reject incoming mail. Legitimate mail
from residential users should normally go through their
ISP's <quote>smarthost</quote>.
</para>
</glossdef>
</glossentry>
</glossdiv>
</glossary>

427
LDP/howto/docbook/Spam-Filtering-for-MX/gpl.xml Normal file
View File

@ -0,0 +1,427 @@
<appendix id="gpl">
<?dbhtml filename="gpl.html"?>
<appendixinfo>
<title>GNU General Public License</title>
<pubdate>Version 2, June 1991</pubdate>
<copyright>
<year>1989, 1991</year>
<holder>Free Software Foundation, Inc.</holder>
</copyright>
<legalnotice>
<para>
<address>Free Software Foundation, Inc.
<street>59 Temple Place, Suite 330</street>,
<city>Boston</city>,
<state>MA</state>
<postcode>02111-1307</postcode>
<country>USA</country>
</address>.
</para>
<para> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
</para>
</legalnotice>
<releaseinfo> Version 2, June 1991</releaseinfo>
</appendixinfo>
<title>GNU General Public License</title>
<sect1 id="gpl-1">
<?dbhtml filename="gpl-1.html"?>
<title>Preamble</title>
<para> The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public License is
intended to guarantee your freedom to share and change
free software - to make sure the software is free for all its users.
This General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit
to using it. (Some other Free Software Foundation software is covered
by the GNU Library General Public License instead.) You can apply it
to your programs, too.
</para>
<para> When we speak of free software, we are referring to freedom, not price.
Our General Public Licenses are designed to make sure that you have the
freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new free
programs; and that you know you can do these things.
</para>
<para> To protect your rights, we need to make restrictions that forbid anyone
to deny you these rights or to ask you to surrender the rights. These
restrictions translate to certain responsibilities for you if you distribute
copies of the software, or if you modify it.
</para>
<para> For example, if you distribute copies of such a program, whether gratis or
for a fee, you must give the recipients all the rights that you have. You
must make sure that they, too, receive or can get the source code. And you
must show them these terms so they know their rights.
</para>
<para> We protect your rights with two steps:
<orderedlist>
<listitem>
<para> copyright the software, and
</para>
</listitem>
<listitem>
<para> offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
</para>
</listitem>
</orderedlist>
</para>
<para> Also, for each author's protection and ours, we want to make certain that
everyone understands that there is no warranty for this free software. If
the software is modified by someone else and passed on, we want its
recipients to know that what they have is not the original, so that any
problems introduced by others will not reflect on the original authors'
reputations.
</para>
<para> Finally, any free program is threatened constantly by software patents.
We wish to avoid the danger that redistributors of a free program will
individually obtain patent licenses, in effect making the program
proprietary. To prevent this, we have made it clear that any patent must be
licensed for everyone's free use or not licensed at all.
</para>
<para> The precise terms and conditions for copying, distribution and modification
follow.
</para>
</sect1>
<sect1 id="gpl-2">
<?dbhtml filename="gpl-2.html"?>
<title>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</title>
<sect2 id="gpl-2-0">
<title>Section 0</title>
<para> This License applies to any program or other work which contains a notice
placed by the copyright holder saying it may be distributed under the terms
of this General Public License. The "Program", below, refers to any such
program or work, and a
<quote>work based on the Program
</quote> means either
the Program or any derivative work under copyright law: that is to say, a
work containing the Program or a portion of it, either verbatim or with
modifications and/or translated into another language. (Hereinafter, translation
is included without limitation in the term
<quote>modification
</quote>.) Each licensee is addressed as <quote>you</quote>.
</para>
<para> Activities other than copying, distribution and modification are not covered by
this License; they are outside its scope. The act of running the Program is not
restricted, and the output from the Program is covered only if its contents
constitute a work based on the Program (independent of having been made by running
the Program). Whether that is true depends on what the Program does.
</para>
</sect2>
<sect2 id="gpl-2-1">
<title>Section 1</title>
<para> You may copy and distribute verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and appropriately
publish on each copy an appropriate copyright notice and disclaimer of warranty;
keep intact all the notices that refer to this License and to the absence of any
warranty; and give any other recipients of the Program a copy of this License
along with the Program.
</para>
<para> You may charge a fee for the physical act of transferring a copy, and you may at
your option offer warranty protection in exchange for a fee.
</para>
</sect2>
<sect2 id="gpl-2-2">
<title>Section 2</title>
<para> You may modify your copy or copies of the Program or any portion of it, thus
forming a work based on the Program, and copy and distribute such modifications
or work under the terms of
<link linkend="gpl-2-1">Section 1
</link> above, provided
that you also meet all of these conditions:
<orderedlist>
<listitem>
<para> You must cause the modified files to carry prominent notices stating that
you changed the files and the date of any change.
</para>
</listitem>
<listitem>
<para> You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to be
licensed as a whole at no charge to all third parties under the terms of
this License.
</para>
</listitem>
<listitem>
<para> If the modified program normally reads commands interactively when run, you
must cause it, when started running for such interactive use in the most
ordinary way, to print or display an announcement including an appropriate
copyright notice and a notice that there is no warranty (or else, saying
that you provide a warranty) and that users may redistribute the program
under these conditions, and telling the user how to view a copy of this
License.
<note>
<title>Exception:
</title>
<para> If the Program itself is interactive but does not normally print such an
announcement, your work based on the Program is not required to print an
announcement.)
</para>
</note>
</para>
</listitem>
</orderedlist>
</para>
<para> These requirements apply to the modified work as a whole. If identifiable sections
of that work are not derived from the Program, and can be reasonably considered
independent and separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as separate works. But when
you distribute the same sections as part of a whole which is a work based on the
Program, the distribution of the whole must be on the terms of this License, whose
permissions for other licensees extend to the entire whole, and thus to each and
every part regardless of who wrote it.
</para>
<para> Thus, it is not the intent of this section to claim rights or contest your rights
to work written entirely by you; rather, the intent is to exercise the right to control
the distribution of derivative or collective works based on the Program.
</para>
<para> In addition, mere aggregation of another work not based on the Program with the Program
(or with a work based on the Program) on a volume of a storage or distribution medium
does not bring the other work under the scope of this License.
</para>
</sect2>
<sect2 id="gpl-2-3">
<title>Section 3
</title>
<para> You may copy and distribute the Program (or a work based on it, under
<link linkend="gpl-2-2">Section 2
</link> in object code or executable form under the terms of
<link linkend="gpl-2-1">Sections 1
</link> and
<link linkend="gpl-2-2">2
</link> above provided that you also do one of the following:
<orderedlist>
<listitem>
<para> Accompany it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
</para>
</listitem>
<listitem>
<para> Accompany it with a written offer, valid for at least three years, to give any
third party, for a charge no more than your cost of physically performing source
distribution, a complete machine-readable copy of the corresponding source code,
to be distributed under the terms of Sections 1 and 2 above on a medium customarily
used for software interchange; or,
</para>
</listitem>
<listitem>
<para> Accompany it with the information you received as to the offer to distribute
corresponding source code. (This alternative is allowed only for noncommercial
distribution and only if you received the program in object code or executable form
with such an offer, in accord with Subsection b above.)
</para>
</listitem>
</orderedlist>
</para>
<para> The source code for a work means the preferred form of the work for making modifications
to it. For an executable work, complete source code means all the source code for all modules
it contains, plus any associated interface definition files, plus the scripts used to control
compilation and installation of the executable. However, as a special exception, the source
code distributed need not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of the operating system
on which the executable runs, unless that component itself accompanies the executable.
</para>
<para> If distribution of executable or object code is made by offering access to copy from a
designated place, then offering equivalent access to copy the source code from the same place
counts as distribution of the source code, even though third parties are not compelled to
copy the source along with the object code.
</para>
</sect2>
<sect2 id="gpl-2-4">
<title>Section 4
</title>
<para> You may not copy, modify, sublicense, or distribute the Program except as expressly provided
under this License. Any attempt otherwise to copy, modify, sublicense or distribute the
Program is void, and will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License will not have their
licenses terminated so long as such parties remain in full compliance.
</para>
</sect2>
<sect2 id="gpl-2-5">
<title>Section 5
</title>
<para> You are not required to accept this License, since you have not signed it. However, nothing
else grants you permission to modify or distribute the Program or its derivative works.
These actions are prohibited by law if you do not accept this License. Therefore, by modifying
or distributing the Program (or any work based on the Program), you indicate your acceptance
of this License to do so, and all its terms and conditions for copying, distributing or
modifying the Program or works based on it.
</para>
</sect2>
<sect2 id="gpl-2-6">
<title>Section 6
</title>
<para> Each time you redistribute the Program (or any work based on the Program), the recipient
automatically receives a license from the original licensor to copy, distribute or modify
the Program subject to these terms and conditions. You may not impose any further restrictions
on the recipients' exercise of the rights granted herein. You are not responsible for enforcing
compliance by third parties to this License.
</para>
</sect2>
<sect2 id="gpl-2-7">
<title>Section 7
</title>
<para> If, as a consequence of a court judgment or allegation of patent infringement or for any other
reason (not limited to patent issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this License, they do not excuse you
from the conditions of this License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent obligations, then as a consequence
you may not distribute the Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who receive copies directly or
indirectly through you, then the only way you could satisfy both it and this License would be
to refrain entirely from distribution of the Program.
</para>
<para> If any portion of this section is held invalid or unenforceable under any particular circumstance,
the balance of the section is intended to apply and the section as a whole is intended to apply
in other circumstances.
</para>
<para> It is not the purpose of this section to induce you to infringe any patents or other property
right claims or to contest validity of any such claims; this section has the sole purpose of
protecting the integrity of the free software distribution system, which is implemented by public
license practices. Many people have made generous contributions to the wide range of software
distributed through that system in reliance on consistent application of that system; it is up
to the author/donor to decide if he or she is willing to distribute software through any other
system and a licensee cannot impose that choice.
</para>
<para> This section is intended to make thoroughly clear what is believed to be a consequence of the
rest of this License.
</para>
</sect2>
<sect2 id="gpl-2-8">
<title>Section 8
</title>
<para> If the distribution and/or use of the Program is restricted in certain countries either by patents
or by copyrighted interfaces, the original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding those countries, so that
distribution is permitted only in or among countries not thus excluded. In such case, this License
incorporates the limitation as if written in the body of this License.
</para>
</sect2>
<sect2 id="gpl-2-9">
<title>Section 9
</title>
<para> The Free Software Foundation may publish revised and/or new versions of the General Public License
from time to time. Such new versions will be similar in spirit to the present version, but may differ
in detail to address new problems or concerns.
</para>
<para> Each version is given a distinguishing version number. If the Program specifies a version number of
this License which applies to it and "any later version", you have the option of following the terms
and conditions either of that version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of this License, you may choose any
version ever published by the Free Software Foundation.
</para>
</sect2>
<sect2 id="gpl-2-10">
<title>Section 10
</title>
<para> If you wish to incorporate parts of the Program into other free programs whose distribution
conditions are different, write to the author to ask for permission. For software which is copyrighted
by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions
for this. Our decision will be guided by the two goals of preserving the free status of all
derivatives of our free software and of promoting the sharing and reuse of software generally.
</para>
</sect2>
<sect2 id="gpl-2-11">
<title>NO WARRANTY Section 11
</title>
<para> BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
</para>
</sect2>
<sect2 id="gpl-2-12">
<title>Section 12
</title>
<para> IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR
ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED
INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH
ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
</para>
<para>END OF TERMS AND CONDITIONS
</para>
</sect2>
</sect1>
<sect1 id="gpl-3">
<?dbhtml filename="gpl-3.html"?>
<title>How to Apply These Terms to Your New Programs
</title>
<para>
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
</para>
<para>
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
</para>
<para>
&lt;one line to give the program's name and a brief idea of what it does.&gt;
Copyright (C) &lt;year&gt; &lt;name of author&gt;
</para>
<para>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
</para>
<para>
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
</para>
<para>
Also add information on how to contact you by electronic and paper mail.
</para>
<para>
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
</para>
<para>
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
</para>
<para>
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
</para>
<para>
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
</para>
<para>
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
</para>
<para>
&lt;signature of Ty Coon&gt;, 1 April 1989
Ty Coon, President of Vice
</para>
<para>
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
</para>
</sect1>
</appendix>

3406
LDP/howto/docbook/Spam-Filtering-for-MX/impl-exim.xml Normal file
View File

File diff suppressed because it is too large Load Diff

40
LDP/howto/docbook/Spam-Filtering-for-MX/impl-sendmail.xml Normal file
View File

@ -0,0 +1,40 @@
<appendix id="sendmail" xreflabel="Sendmail Implementation">
<?dbhtml filename="sendmail.html"?>
<title>Sendmail Implementation</title>
<abstract>
<para>
Here we cover the integration of techniques and tools described
in this document into the Exim <xref linkend="mta"/>.
</para>
</abstract>
<section id="sendmail-prereq" xreflabel="Prerequisites">
<?dbhtml filename="sendmail-prereq.html"?>
<title>Prerequisites</title>
<para>
For the examples in this section, you need the
<ulink url="http://www.sendmail.org/">Sendmail</ulink>
<xref linkend="mta"/>, version 8.9.3 or higher.
</para>
</section>
<section id="sendmail-mech" xreflabel="Filtering Mechanism">
<?dbhtml filename="sendmail-mech.html"?>
<title>Filtering Mechanisms</title>
<para>
</para>
</section>
<section id="sendmail-config" xreflabel="The Sendmail Configuration File">
<?dbhtml filename="sendmail-config.html"?>
<title>The Sendmail Configuration File</title>
<para>
</para>
</section>
</appendix>