NB: This project is dead.

Distributed Spam Traps

Quick download, for the impatient.


Spam traps (also known as Honeypot addresses) are a good way of detecting spam activities: you publish the honeypot e-mail address somewhere, hidden to humans but visible to machines, you await for spambots to catch it,and you start getting junk mail at that address. The key point is that you only get spam in your spam trap, never regular mail. Any machine sending a message to a honeypot address is involved in some spam activity.

The machine can be a compromized host running a spam engine, or a regular mail server used as a relay. In both cases we want to detect it, and maybe temporarilly stop accepting mail from it.

Using spam traps on your site is not very efficient, because spammers have hordes of compromised zombi PCs awaiting their commands. They are able to distribute the spam attack so that you never see the spam coming from the same IP twice. That means that your spam trap might not catch anything useful.

The answer to that problem is to distribute the spam traps. With many traps on many sites, odds are better that a compromised machine will hit a honeypot address before it tries to send you a spam in a regular mailbox (if you use greylisting that makes your chances even better). DST (Distributed Spam Traps) is an effort to build a network of distributed honeypots, with real-time communication between all the participants.

Another key point is resistance to attacks. Good DNSRBL get easily shot down by Distributed Denial of Service (DDoS). DST works with no single point of failure: spam reports get distributed in a Usenet news fashion, and the identified spammer IP is injected in a local DNSRBL at each participating site. This DNSRBL does not have to be public, but it ensure that the information carried by the DST network is easily made available to any DNSRBL-aware MTA.

DST parts

dstc is the DST client dstc should be installed on a honeypot e-mail address, for example through a .forward file, or through the system-wide aliases file. Here is an example of dstc invocation through .forward:

       "|/usr/local/bin/dstc -m 'mx[12].example.net'"

That mecanism ensures that dstc can de deployed easily on any Unix platform and with any MTA.

On each incoming mail, dstc will parse the headers, looking for the machine your MX received the message from. Because the message is recieved in a honeypot address, this machine is likely to participate in a spam operation. dstc will create a report with the address of the machine and will send it to a dstd daemon for propagation to other sites.

dstd is a spam report exchange daemon for the DST network. Its job is to collect reports from the DST client, dstc, and from other dstd daemons. Various operations can be done with the reports, depending on local configuration:

  • text logging
    Each spam report (IP, date and hour) can be logged to a plain text file.
  • outgoing feeds
    The spam report can be sent other dstd daemons. The report features a message-Id and a Path header to avoid loops, just like Usenet news message do.
  • local database
    The spammer IP address can be temporarily stored in a Berkeley DB database, until the information times out. The use of the database is strongly advised, as it helps avoiding duplicate reports (the database retains the Message-Id)
    The spammer IP address can be injected in a DNSRBL through the DNS update mecanism, so that the information can be available from any MTA. The Berkeley database timeout will be used to remove the IP from the DNSRBL after a timeout.

  • External program feed
    The whole spam message can be piped out to an external program,thus making integration with other antispam tools possible.


This software is still experimental. It probably do not work as we want now. The idea is to experiment on it and see what advanced antispam technique we can build for the next battle.


Download dst-0.11.tgz
SHA1 (dst-0.11.tgz) = 59dbefffa590f39af9ebe06ed7ddf8a5b4183840

Emmanuel Dreyfus, $Date: 2004/12/22 14:33:47 $