LDP/LDP/howto/docbook/Spam-Filtering-for-MX/chapter-qanda.xml

<?xml version="1.0" encoding="UTF-8"?>
<chapter id="qanda" xreflabel="Questions &amp; Answers">
  <?dbhtml filename="qanda.html"?>
  <title>Questions &amp; Answers</title>

  <abstract>
    <para>
      In this section I try to anticipate some of the questions that
      may come up, and to answer them.  If you have questions that are
      not listed, and/or would like to provide extra input in this
      section, please provide <link linkend="feedback">feedback</link>.
    </para>
  </abstract>

  <qandaset defaultlabel="qanda">
    <title>When Spammers Adapt</title>

    <qandaentry id="qanda-adapt">
      <question>
        <para>
	  What happens when spammers adapt and try to get around the
	  techniques described in this document?
	</para>
      </question>

      <answer>
        <para>
	  Well, that depends. :-)
	</para>

	<para>
	  Some of the checks described (such as <xref
	  linkend="smtpchecks"/> and <xref linkend="greylisting"/>)
	  specifically target <emphasis>ratware</emphasis> behavior.
	  It is certainly possible to imagine that this behavior will
	  change if enough sites incorporate these checks.  Hatmut
	  Danisch notes:
	  <emphasis>
	    Ratware contains buggy SMTP protocols because they didn't
	    need to do any better.  It worked this way, so why should
	    they have spent more time?  Meanwhile
	    <quote>ratware</quote> has a higher quality, and even the
	    quality of spam messages has significantly improved.  Once
	    enough people reject spam by detecting bad SMTP protocols,
	    spam software authors will simply improve their
	    software.
	  </emphasis>
	</para>

	<para>
	  That said, there are challenges remaining for such ratware:
	</para>

	<itemizedlist>
	  <listitem>
	    <para>
	      To get around <xref linkend="smtpdelays"/>, they need to
	      wait for each response from the receiving SMTP server.
	      At that point, we have collectively accomplished a
	      significant reduction in the rate of mail that a given
	      spamming host is able to deliver per unit of time.
	      Since spammers are racing against time to deliver as
	      many mails as possible before DNS blocklists and
	      collaborative content filters catch up, we are improving
	      the effectiveness of these tools.
	    </para>

	    <para>
	      The effect is similar to the goal of <xref
	      linkend="micropay"/>, wherein the sender spends a few
	      seconds working on a computational challenge for each
	      recipient of the mail, and adds a resulting signature to
	      the e-mail header for the recipient to validate.  The
	      main difference, aside from the complexity of these
	      schemes, is that they require the participation of
	      virtually everyone in the world before they can
	      effectively be used to weed out spam, whereas SMTP
	      transaction delays start being effective with the first
	      recipient machine that implements it.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      To get around a <xref linkend="helocheck"/>, they need
	      to provide a proper greeting, i.e. identify themselves
	      with a valid <xref linkend="fqdn"/>.  This provides for
	      increased traceability, especially with receiving <xref
	      linkend="mta"/>s that do not automatically insert the
	      results of a rDNS lookup into the Received: header of
	      the message.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      To get all of the <xref linkend="senderchecks"/>, they
	      need to provide their own valid sender address (or, at
	      least, <emphasis>a</emphasis> valid sender address
	      within their own domain).  Nuff said.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      To get around <xref linkend="greylisting"/>, they need
	      to retry deliveries to temporarily failed recipients
	      addresses after one hour (but before four hours).  (As
	      far as implementation goes, in order to minimize machine
	      resources, rather than keeping a copy of each
	      temporarily failed mail, ratware may keep only a list of
	      temporarily failed recipients, and perform a second
	      sweep through those addresses after an hour or two).
	    </para>

	    <para>
	      Even so, <emphasis>greylisting</emphasis> will remain
	      fairly effective in conjunction with <xref
	      linkend="dnsbl"/> that are fed from <xref
	      linkend="spamtrap"/>s.  That is because the mandatory
	      one-hour retry delay will give these lists a chance to
	      list the sending host.
	    </para>
	  </listitem>
	</itemizedlist>

	<para>
	  Software tools, such as <xref linkend="spamscanners"/> and
	  <xref linkend="virusscanners"/>, are in constant evolution.
	  As spammers evolve, so do these (and vice versa).  As long
	  as you use recent versions of these tools, they will remain
	  quite effective.
	</para>

	<para>
	  Finally, this document is itself subject to change.  As the
	  nature of junk mail changes, people will come up with new,
	  creative ways to block it.
	</para>
      </answer>
    </qandaentry>
  </qandaset>
</chapter>