356 lines
7.1 KiB
HTML
356 lines
7.1 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Questions & Answers</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Spam Filtering for Mail Exchangers"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="User Settings and Data"
|
|
HREF="usersettings.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Exim Implementation"
|
|
HREF="exim.html"></HEAD
|
|
><BODY
|
|
CLASS="chapter"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Spam Filtering for Mail Exchangers: </TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="usersettings.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="exim.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><H1
|
|
><A
|
|
NAME="qanda"
|
|
></A
|
|
>Chapter 4. Questions & Answers</H1
|
|
><BLOCKQUOTE
|
|
CLASS="ABSTRACT"
|
|
><DIV
|
|
CLASS="abstract"
|
|
><A
|
|
NAME="AEN1305"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> 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 <A
|
|
HREF="intro-feedback.html"
|
|
>feedback</A
|
|
>.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></BLOCKQUOTE
|
|
><DIV
|
|
CLASS="qandaset"
|
|
><H2
|
|
CLASS="title"
|
|
>When Spammers Adapt</H2
|
|
><DL
|
|
><DT
|
|
>Q: <A
|
|
HREF="qanda.html#AEN1311"
|
|
> What happens when spammers adapt and try to get around the
|
|
techniques described in this document?
|
|
</A
|
|
></DT
|
|
></DL
|
|
><DIV
|
|
CLASS="qandaentry"
|
|
><DIV
|
|
CLASS="question"
|
|
><P
|
|
><A
|
|
NAME="AEN1311"
|
|
></A
|
|
><B
|
|
>Q: </B
|
|
>
|
|
What happens when spammers adapt and try to get around the
|
|
techniques described in this document?
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="answer"
|
|
><P
|
|
><B
|
|
>A: </B
|
|
>
|
|
Well, that depends. :-)
|
|
</P
|
|
><P
|
|
> Some of the checks described (such as <A
|
|
HREF="smtpchecks.html"
|
|
>SMTP checks</A
|
|
> and <A
|
|
HREF="greylisting.html"
|
|
>Greylisting</A
|
|
>)
|
|
specifically target <EM
|
|
>ratware</EM
|
|
> behavior.
|
|
It is certainly possible to imagine that this behavior will
|
|
change if enough sites incorporate these checks. Hatmut
|
|
Danisch notes:
|
|
<EM
|
|
> 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
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"ratware"</SPAN
|
|
> 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.
|
|
</EM
|
|
>
|
|
</P
|
|
><P
|
|
> That said, there are challenges remaining for such ratware:
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> To get around <A
|
|
HREF="smtpdelays.html"
|
|
>SMTP transaction delays</A
|
|
>, 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.
|
|
</P
|
|
><P
|
|
> The effect is similar to the goal of <A
|
|
HREF="gloss.html#micropay"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Micropayment Schemes</I
|
|
></A
|
|
>, 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.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> To get around a <A
|
|
HREF="smtpchecks.html#helocheck"
|
|
>HELO/EHLO check</A
|
|
>, they need
|
|
to provide a proper greeting, i.e. identify themselves
|
|
with a valid <A
|
|
HREF="gloss.html#fqdn"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Fully Qualified Domain Name</I
|
|
></A
|
|
>. This provides for
|
|
increased traceability, especially with receiving <A
|
|
HREF="gloss.html#mta"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Mail Transport Agent</I
|
|
></A
|
|
>s that do not automatically insert the
|
|
results of a rDNS lookup into the Received: header of
|
|
the message.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> To get all of the <A
|
|
HREF="smtpchecks.html#senderchecks"
|
|
>Sender Address Checks</A
|
|
>, they
|
|
need to provide their own valid sender address (or, at
|
|
least, <EM
|
|
>a</EM
|
|
> valid sender address
|
|
within their own domain). Nuff said.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> To get around <A
|
|
HREF="greylisting.html"
|
|
>Greylisting</A
|
|
>, 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).
|
|
</P
|
|
><P
|
|
> Even so, <EM
|
|
>greylisting</EM
|
|
> will remain
|
|
fairly effective in conjunction with <A
|
|
HREF="dnschecks.html#dnsbl"
|
|
>DNS Blacklists</A
|
|
> that are fed from <A
|
|
HREF="gloss.html#spamtrap"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Spam Trap</I
|
|
></A
|
|
>s. That is because the mandatory
|
|
one-hour retry delay will give these lists a chance to
|
|
list the sending host.
|
|
</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
> Software tools, such as <A
|
|
HREF="datachecks.html#spamscanners"
|
|
>Spam Scanners</A
|
|
> and
|
|
<A
|
|
HREF="datachecks.html#virusscanners"
|
|
>Virus Scanners</A
|
|
>, 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="usersettings.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="exim.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>User Settings and Data</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Exim Implementation</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |