dcc 1.2.0 start/stop-dccd scripts

Vernon Schryver vjs@calcite.rhyolite.com
Tue Aug 26 15:40:05 UTC 2003


> From: Valentin Chopov <valentin@valcho.net>

> in start-dccd there is a "BRAND=" after reading of dcc_conf
> in stop-dccd there is a missing '#' before "! /bin/sh"

Yes, I discovered as much last night. 

Thanks for trying 1.2.0, but please note that the link symbolic
links still point to 1.1.45.
1.2.0 is a beta release, and perhaps even an alpha release.
It contains the major changes needed for greylisting.  There may
be other side effects of those changes on normal operations.

Late today or tomorrow I'll make a 1.2.1 beta release to fix an
inflation of 1 in target counts of greylist embargoed messages when
they are finally passed.

There are a few words about greylisting in the dccd man page
under -G.  I really need to whack on the dcc man page and add
words about greylisting.  

The DCC implementation of greylisting requires that the same message
be transmitted after the embargo.  The default embargo is 5 minutes.
Spam clears entries in the greylist database.  The first time a message
is embargoed, its checksums are reported to the DCC.  Each time it is
retried, its checksums are checked with the DCC for bulkiness.

To turn on greylisting you need to run your own private newwork of
dccd greylist servers.  You must also be using either dccm or dccifd.
To start your greylist servers,

  - install the dccd tarball even if you are not running a DCC server

  - switch to the new version of /var/dcc/dcc_conf found in the
      homedir directory in the source tree after ./configure

  - turn on the greylist dccd.  If you are not running a DCC server,
      assign server-IDs in /var/dcc/dcc_conf and /var/dcc/ids

  - add -G to DCCM_ARGS and/or DCCIFD_ARGS

  - start the DCC daemons with /var/dcc/libexec/rcDCC


Before doing all of that, you might want to think twice.  

  - if you run a large system, it might be wise to run the greylisting 
     dccd for a week or so with -G0 to populate the greylisting databse.
     I very much doubt this is worthwhile, because of turn over among
     users, their correspondents, and other ISPs and their IP addresses.

  - some large ISPs are...well...I can't think of a polite way of describing
     them so I'll just state the problems:

      -- many SMTP clients ignore RFC 2821 and RFC 821 and retransmit
       far quicker than 30 minutes.  5, 10, and 15 minutes seem to be
       common.

      -- AOL likes to retry 20-35 seconds after a 4yz.  If you greylist
       with an embargo close to the minimum retry required by RFC 2821
       of 30 minutes, you'll see bursts of dozens (!) retransmissions
       followed by silence.  In many cases, AOL will later do the same
       with the message from another IP address, which starts a new
       embargo for the sender and message from the new address.  An
       embargo of 5 minutes seems to fix this problem.  Note however
       that each time they switch IP addresses, they will have inflated
       the DCC target count.

     -- Cox takes AOL's tactic to the extreme.  They retransmit at one
      (1!) second intervals half a dozen to a dozen times and then stop.
      Perhaps an hour later they start again from another IP address.
      After repeating this amazing waste of bandwidth from half a
      dozen addresses, they give up entirely.

     -- Besides Cox, I've seen one other SMTP client trie several
      times from various IP addresses and then give up.

In summary, greylisting appears very promising for stopping spam
from open proxies and "direct-to-SMTP server" spamware for small
and modest domains or others than can tolerate some false positives
from exceptionally incompetent SMTP clients.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.