Users:

If you don't run your own mail server, you may be somewhat limited by your ISP (Internet Service Provider). For example, if your ISP has not installed procmail for general use, you probably cannot easily engage it as a mail filter. Regardless of your ISP, you can...

• Support or join CAUCE, the Coalition Against UCE (Unsolicited Commercial E-mail). Details are available at CAUCE's web-site.
• Complain to the spammer's ISP.
  In general, do not complain to the spammer. Many spammers unethically use any reply as a "validation" of an E-mail address -- and the end result is that communicating with any spammer results in a huge increase in spam that you receive. See my Anti-Spam Links page for links to tools, documentation, and tutorials on complaining about spam.
• Hit spammers in the wallet.
  Refuse to do business with any person or organization that sends UBE/UCE. (This is fairly easy, as they're all peddling worthless crap and scams anyway.)
• Hit spam-friendly ISPs in the wallet.
  If your ISP is soft on spam (e.g., they let customers spam without taking disciplinary action), then take your business elsewhere -- and let them know why you're leaving. If allowing spam is unprofitable, then the ISPs will change their policies and the spammers will be homeless. You can use a DejaNews query against the net-abuse newsgroups (news.admin.net-abuse*) to check out any ISP's historical track record on spam.
• Hit address-sellers in the wallet.
  If the spam doesn't come from a professional spam shop, it was still very likely sent to a list of addresses that was purchased from a spammer. These lists are often falsely claimed to contain only "subscibers" who want bulk E-mail, or "targeted" addresses who won't complain. Track down the non-pro spammer. Find out where they got the mailing list and what it was promised to contain. If the promise was inaccurate, then recommend that they take action (demand a refund, initiate a fraud charge, etc.) against the seller of the mailing list.

Sysadmins:

You can do a lot. There are quite a few options of varying severity (and varying significance of side-effect). You must consider both severity of your spam problem and your users' needs, to arrive at a solution. The ones that work for me include:

• Filter packets.
  Refuse some or all network traffic to/from a given site. This is an extremely drastic step. Depending on the exact filtering rules used, it could keep your users from sending anything to that site, could keep your users from seeing that site's web page, etc. I'm not doing this to anyone right now, though a few sites have come close.
• Set up an E-mail firewall.
  First, configure your mailer refuse third-party relaying. This prevents spammers from hijacking your site and using it as a base from which to attack others. There is some excellent information on spam self-defense via sendmail configuration, on Claus Aßmann's site.

  A TCP wrapper package allows for easy dropping of E-mail from particularly annoying sites. The wrappers library can be compiled into sendmail or used with a front-end such as SMTPD or SMAP (below).

  Obtuse Systems Corporation's SMTPD is a great, free sendmail front-end. It is easily configured to reject bogus "From" addresses, problem netblocks, etc., and can delay the SMTP conversation to slow up the spammer's mailings. You can see some portions of my SMTPD configuration file here.

  Trusted Information Systems' free Internet Firewall Toolkit contains some useful tools. I used to use "smap" (their SMTP front-end for sendmail), though I have switched to SMTPD (above) and prefer it.

• Give your users E-mail filtering capability.
  Install procmail, which can be used to filter E-mail by patterns in the header/body. It can be installed so that each user can determine what they want to keep, what they want to throw away, and what they want to put off to the side. Check out UIUC's procmail workshop or Infinite Ink's "Processing mail with procmail" page.
• Shield your users from USEnet address-harvesting.
  I supply an auto-bounce address ("occupant@stassen.com") which can be used as a bogus "reply address" for all USEnet postings. With some minor changes to smap's source code, it is set up to reject mail to "occupant" during "RCPT" phase of the SMTP conversation. The error is reported and the connection dropped before there is any attempt to send the message itself.
• Shield your users from WWW address-harvesting.
  Don't leave E-mail addresses where a robot can pick them up. I have a simple "form" with one check-box which must be accepted in order to get an E-mail address (you can see it here). Robots don't get past it. Also, warn your users about the dangers of placing their E-mail address up on the web.