Methods: Proactive vs Retroactive

There are two methods for combatting spam: proactive retroactive. The words "proactive" and "retroactive" are my own terms, so I'll define them.

Proactive

A spammer cares about one thing: delivering spam. He doesn't give two shits or a fuck about whether you actually read the spam. He already knows you probably won't; all he cares about is for his spam to be delivered to your host.

A proactive method stops the spam from ever reaching your system. The spammer's MTA won't even be able to start a connection with your machine. From his point of view, either your system is non-existent or you're giving him the biggest "fuck you" you can give to spammer: he has no way of reaching you. You have ceased to be a person he can spam; he will need to find someone else.

Retroactive

In a retroactive method, the spam was delivered. Even if you have a spam filter and never saw the spam, as far as the spammer is concerned the letter was received. He has no idea that the spam was filtered. To him, it was a successful spam.

Which Is Better?

All forms of combatting spam is good. However, proactive methods are better. If the vast majority of people on the net used proactive methods, spamming would no longer be a viable method of advertising. ISP's and backbones would be more eager to squelch any spammers from their network because they'd be afraid of being blacklisted themselves.



Ways To Combat Spam

Here's the bad news: If you don't control your own domain and don't have a static IP address, you cannot implement proactive spam controls. This is because your mail needs to go to an ISP (like all of you that use hotmail, AOL or whatever). You have no control over what gets delivered, and will therefore be relegated to complaining about or filtering the spam, both retroactive methods.

Open Relay Databases

See here if you don't know what an open relay is.

From my own experience, open relays are guilty of sending between about 75% of all spam. Depending on who you ask, this number can be as low as 20% or as high as 90%. Either way, that's a big chunk of spam.

There are a number of databases on the Internet which keep track of which hosts are open mail relays. You can configure your MTA to use their information to prevent spam from reaching your system. This is a very proactive method of combatting spam since it effectively blocks all SMTP traffic between your system and the spammer.

Here are a list of open relay database servers:

Spamcop

Ricochet



My Approach To Combatting Spam

I have a 3-tiered approach that servs me well:

  1. Using ORDB: The Open Relay Database (proactive)
  2. Using tcpwrappers (proactive)
  3. Using spamcop (retroactive)

My Approach: ORDB

I used to get 50+ spams per day. Using ORDB dropped this number to under 10 per day. I've heard some people claim that ORDB has dropped their spam count by 90%. I use Debian GNU/Linux, which uses the exim MTA. I added the following lines to /etc/exim/exim.conf to configure exim to reject mail from any Internet host which is classified as an open relay: 

      # reject messages whose sending host is in ORDB
      rbl_domains = relays.ordb.org/reject
      # check all hosts other than those on internal network
      rbl_hosts = !192.168.0.0/24:0.0.0.0/0
      # but allow mail to postmaster@my.dom.ain even from rejected host
      recipients_reject_except = postmaster@my.dom.ain
      # change some logging actions (collect more data)
      rbl_log_headers = true    # log headers of accepted ORDBed messages
      rbl_log_rcpt_count = true  # log recipient info of accepted ORDBed messages
      
      # The action for domains without either of these is controlled by
      # rbl_reject_recipients, which implies `/reject' when set.
      rbl_reject_recipients = true
      rbl_warn_header = false

My Approach: Tcpwrappers

I configured my system to start up exim as a network daemon started by inetd.conf and wrapped by the "tcpwrapper", tcpd. To do this, I added the following line to my /etc/inetd.conf: 

      smtp     stream   tcp   nowait   mail /usr/sbin/tcpd  /usr/sbin/exim -bs

Whenever a host contacts my system to deliver mail (SMTP port tcp/25), inetd looks in /etc/hosts.allow to see if I allow that host to send me mail. If it doesn't see explicit permission to send me mail, it then checks the file /etc/hosts.deny to see if i disallow that host from sending me email.

Whenever spam reaches its way into my mailbox, I look to see where it came from. The Received: headers are always reliable in determining the sender of the spam, even when the spammer has forged headers to try to confuse me about who sent the spam. Here's an example: 

      From vox-admin@lists.lugod.org Mon Sep 02 22:06:01 2002
      Return-path: <vox-admin@lists.lugod.org>
      Received: from dcn251-11.dcn.davis.ca.us ([168.150.251.11] helo=www.livepenguin.com)
              by satan.diablo.localnet with esmtp (Exim 3.35 #1 (Debian)) id 17m5t2-0008Gh-00
              for <p@dirac.org>; Mon, 02 Sep 2002 22:06:01 -0700
      Received: from www.livepenguin.com (livepenguin [127.0.0.1])
              by www.livepenguin.com (Postfix) with ESMTP id 7ADC26C34D
              for <p@dirac.org>; Mon,  2 Sep 2002 22:06:00 -0700 (PDT)
      Received: from lists.lugod.org (unknown [61.59.209.241])
              by www.livepenguin.com (Postfix) with SMTP id 0DCDC6C36C
              for <vox@lists.lugod.org>; Mon,  2 Sep 2002 17:13:41 -0700 (PDT)
      From: "FREDRICK JOHNSON" <fred_johnson333@mail.com>
      Date: Tue, 03 Sep 2002 01:14:18
      To: vox@lists.lugod.org
      Subject: PATNERSHIP
      
      Firstly, I must solicit your confidence in this transaction; this is by
      virtue of its nature as being utterly confidential and top secret. Though
      I know that a transaction of this magnitude will make any one apprehensive
      and worried, but I am assuring you that all will be well at the end of the
      day.  We have decided to contact you due to the urgency of this  transaction,
      as we have been reliably informed of it's swiftness and confidentiality.

Without explanation (you can find out how elsewhere), this spam came from IP address 61.59.209.241. The whois command tells me that this IP address belongs to an ISP in Taiwan. It also says that this ISP owns the netblock 61.59.0.0 - 61.59.255.255. So I simply add this line to /etc/hosts.deny: 

		ALL: 61.59.

At this point, nobody with an IP address of 61.58.x.x will be able to send me email of any kind, spam or not spam. I've created a black hole for this entire ISP. As far as anyone who uses this ISP is concerned, i no longer exist. By the way, the same is true for other services that I use tcpwrappers for, like cvs and ftp.

Why do I block an entire network rather than the single offending IP address?

My Approach: Spamcop

I only use one retroactive method: spamcop. I simply forward the spam to Spamcop, they parse the headers, determine who sent the spam and then send a letter complaining about the spam to the ISP involved on my behalf.

Why bother? Some ISP's do take these letters very seriously; they don't want to be known as a spamhause. I do it as a service. Perhaps a host was compromised by hackers. Maybe they found a way to sneak spam past the ISP's spam controls. A letter from spamcop is a way of telling them "By the way, did you realize that you just spammed me?".



Links

General Spam Sites

  1. "Stopping Spam and Malware with Open Source" by Brent Glass: A treatiste presented to ORA's open source convention in 2001, back when ORA was a friend to the open source movement. Quite long.
    www.brettglass.com/spam/paper.html
  2. A decent general page about spam.
    spam.abuse.net

Procmail Based