mirror of https://github.com/tLDP/LDP
new
This commit is contained in:
parent
8116caf3a0
commit
3105af4588
|
@ -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 <?dbhtml..?> 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 © 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>
|
|
@ -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:<<parameter>sender</parameter>@<parameter>address</parameter>>
|
||||||
|
</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:<<parameter>receiver</parameter>@<parameter>address</parameter>></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>
|
|
@ -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>
|
|
@ -0,0 +1,143 @@
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<chapter id="qanda" xreflabel="Questions & Answers">
|
||||||
|
<?dbhtml filename="qanda.html"?>
|
||||||
|
<title>Questions & 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>
|
File diff suppressed because it is too large
Load Diff
|
@ -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® Windows® 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>
|
|
@ -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>
|
||||||
|
<one line to give the program's name and a brief idea of what it does.>
|
||||||
|
Copyright (C) <year> <name of author>
|
||||||
|
</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>
|
||||||
|
<signature of Ty Coon>, 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>
|
File diff suppressed because it is too large
Load Diff
|
@ -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>
|
Loading…
Reference in New Issue