Preface:
I'd like to make some suggestions about fighting spam, in particular relay spam. The intent of these suggestions is to add to the current techniques in use to fight relay spam.

Relay spam can be fought at the source, at the destination, and at the relay. Various spam filter techniques exist at the destination. Honorable ISPs do not provide service to relay spammers, and cancel any accounts found to be engaged in relay spamming. The techniques in use at the destination and at the source are fairly complete.

Techniques exist for use at the relay, but are not often used. One approach is to configure a potential relay as a teergrube system (http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html).  This works and you may wish to consider using it.
 This approach of configuring sendmail to accept and then discard relay messages appears to be used infrequently.

Briefly:

The material below takes too many words to say a simple thing.  Spammers test IPs to see if they are open relays.  The spammers will probably conclude that any IP that delivers a test message is an open relay.  Most of the time that is the correct conclusion (unfortunately.)   Those wishing for the spammers to have a harder time can set up a system that delivers test messages and no other.  Experience suggests that most spammers will not notice the non-delivery. The idea is epitomized in a single Unix/Linux command: sendmail -bd.  The reality is that sendmail is a bit more complex so this alone isn't quite enough (nor does this make sendmail deliver test messages.)  It isn't necessary to use sendmail: a honeypot has been written in Perl, for Linux.  A very successful honeypot uses Postfix. Any way you find to create a configuration that (1) delivers relay test messages and (2) delivers nothing else will also work.  Try it.  It is easy and can be very effective against the spammers.

A technique that is not recommended:
I have experience with configuring a mail server to filter incoming messages to identify and stop delivery of spam messages. One characteristic of relay spam messages is that they have multiple recipients. The technique I have used is to embargo all email messages with more than one recipient, and then subject these messages to a validation test. Those messages passing the validation test are delivered. The rest are held. These are reviewed periodically and the valid messages improperly held are delivered. Based on my experience I can say:
1. this works
2. I don't recommend it.

A technique that is recommended:
I don't recommend the mail filter approach outlined above because it is too complex and requires frequent attention. Instead I believe a simpler technique can be at least as effective. This technique can be expressed in its basic form in a single line:

Note: For sendmail versions 8.9 and newer the default is to not relay.  You can turn on relay by including the line

FEATURE(`promiscuous_relay')dnl

in the configuration file.  You need also to make sure that sendmail doesn't attempt delivery once upon receipt of the message. This is indicated in sendmail.cf in this manner:

   Change:
          # default delivery mode
      O DeliveryMode=background

   To:
      # default delivery mode
      # Mail never gets delivered if sendmail is run without
      # a "-q" option
      O DeliveryMode=queue

Without this you'll end up with a pretty good real open relay.  If you did not make this change  then make the change now and take heart in the fact that the spammer even more surely believes your IP is an open relay.
 

Further M4 Configuration of sendmail:

I've just received (March 10, 2002) this useful note from a person who wishes to identify himself as "A Mushroom":

I have just started operating a sendmail-based (sendmail 8.12.1) honeypot and I am pleased to report
that over the part 48 hours, I have managed to capture spam meant for 70,000 people!

I would like to offer the following "m4" configurations for those who want to build their sendmail.cf from scratch.

To turn off ETRN and other "privacy flags" use:

  define(`confPRIVACY_FLAGS', `goaway,noetrn')dnl

To tell sendmail to queue everything (NOTE:  THIS IS THE MOST IMPORTANT PART IN YOUR sendmail -bd scheme):

   define(`confDELIVERY_MODE', `queueonly')dnl

Or one may opt to tell sendmail that SMTP is "expensive" and thus it should queue everything meant for SMTP:

   define(`confCON_EXPENSIVE',`True')dnl
   define(`SMTP_MAILER_FLAGS',`e')dnl

An administrator may want to slow down a spammer's process by lowering the maximum number of "children" sendmail would spawn to handle things:

   define(`confMAX_DAEMON_CHILDREN',`2')

I have also found the 'mailq' command useful in detecting potential relay tests. From mailq, one can easily identity which queued files only has one or two recipients.  After that, examine the queue data files and then use the "sendmail -qS<insert sender address>" to selectively send it out!

I hope the above would be helpful.  Nonetheless, I urge all sendmail administrators to READ THE MANUAL first!

Sendmail -bd,  by default (at least on my installation, v 8.11.3) will  attempt *immediate* delivery when spam is received. If it succeeds this  would of course be A Bad Thing. Fortunately in my case I had a firewall  configured to prevent it, but other admins might not be so lucky...

A little research in the bowels of the sendmail documentation shows that  this can be prevented by adding the following two lines to sendmail.mc:

define(`confCON_EXPENSIVE', True)dnl
define(SMTP_MAILER_FLAGS, e)dnl

This effectively tells sendmail not to attempt immediate delivery with  SMTP --, which in absence of the -q option means no delivery at all  unless one manually intervenes.

From sendmail version 8.12.x onwards, one can define
different queue groups. For example one group for your
own domain and then another one for anything else.
For honeypots operators, you can tell sendmail to
queue mail for your domain in one particular queue.
You can then run this "good" queue every few minutes
without worries to deliver mail for your own domain.
In the meantime, mail for other domains (most likely
SPAM) are queued in another area.  Just make sure you
don't run the queue on this spam-filled queue!

This ability to define queue groups makes managing
honeypots easier. Usual warning: READ THE MANUAL
BEFORE YOU DO ANYTHING TO/WITH YOUR SENDMAIL
CONFIGURATION.  THIS IS NOT FOR BEGINNERS! YMMV.

What happens when you run sendmail this way?
1. Normal email is not affected. If this is being run on a non-server there is no legitimate normal email that should be coming through the system. If there is normal email going to or coming from this system it will be affected unless you do something to facilitate delivery of this normal mail. If you don't know how to do this and cannot come up with an alternative don't run sendmail -bd.
2. The first (and perhaps only) email trapped will be relay test messages. It is obvious that spammers use open relays, it is obvious that they find open relays. It is almost as obvious that they do this in the simplest and most direct way possible: they scan the internet for open relays. If you create a system on the net that accepts but does not deliver relay email it is almost certain that this system will be the target of and will trap relay test messages.

What do you do when you trap a relay test message? First you congratulate yourself that you have done something that can help to defeat a spammer. Next you can do any of several things:
1. You can report the tester to the originating ISP. Scanning for open relays is a spam support operation. (There have been those who have scanned for open relays so that these can be listed. If this scan was done by someone on the anti-spam side you may choose to simply ignore the message. The trick is to determine the nature of the sender. Use the techniques you already know for this. Search dejanews for reports on the domain, for example.)
2. You can report the tester to the ISP of the valid addressees, if any, of the test message. Same as above: receiving a test message is a spam-support activity.
3. You can save a copy of the message and then cause it to be delivered.  If you do this you are telling the spammer that your system is a relay. It isn't: you control what is or is not delivered. Having given your system the false identity of an open relay you can soon expect real spam to come its way. To deliver a message you probably will want to do this by recipient.  Find the entry on the mail queue that is a test message (it probably is the only entry), identify the recipient, and then do sendmail -qRrecipient, where recipient is some unique string in the email address of the recipient.  (Remember to first save a copy of the message.)  You can create a directory for spam messages, call it /home/spam in this example,  and then do cp /var/spool/mqueue/*AAwxyz /home/spam.  The string AAwxyz should be replaced by the identifier you see when you do a mailq command.  Note that if the only thing on your queue is the spam test message then you probably can simply do
cp /var/spool/mqueue/*AA* /home/spam.

If you set up a decoy you will find that there are various styles of relay test message.  Note that a spammer may try to disguise his test message as being something else, or as a test message from an anti-spam organization.  Do not be deceived by such tactics. If you have intercepted the message on a decoy it is nearly 100% certain that it is a test message.  It is very probable that the test message is the work of a spammer or spam supporter.

What can you do with trapped spam?
1. Report the attempted relay to the originating ISP, if that seems fruitful, and to the upstream ISP. You are not merely reporting spam: you are reporting an attempted theft of service. Even if the spammer has a "pink contract" with his ISP he has no protection. ( "pink contract" is an agreement between an ISP and a customer that exempts the customer from the ISP's terms of service that forbid spam.)  The ISP cannot by contract turn theft of service into a legitimate activity. You can suggest to the ISP that if he continues to ignore warnings such as the one you are sending he is making himself a co-conspirator in the criminal justice system and a co-defendant in the civil justice system. In the civil justice system he may be the co-defendant with the deepest pockets, so that if there ever is a class action suit on the behalf of those whose service has been stolen by relay spammers the ISP may end up owing a large judgment.
2. If the spammer is hitting you hard, trying to send a lot of spam through you, you can do something even more damaging to the spammer: throw it away (keeping enough as evidence) but let it continue. The spammer is wasting his bandwidth trying to send through you. You are wasting equivalent bandwidth. (Don't do this if you don't have the bandwidth to spare.)  You may make a significant dent in his activity while he continues to try to send through you.

[Note: this was written when ORBS was in operation.  The same ideas work for any of the successor listing services.]  So far I've described this as an infrequent activity: only a few relay decoys in operation. What happens if this is done in a widespread manner? Answer: a large fraction of the supposed "open" relays are not actually open. This means that the relay tester gets a lower yield when he runs his tests, has more false positives. What happens if the relay tester is more clever, and checks the aged relay list on ORBS? Answer: who says you can't have your decoy system listed on ORBS? You can fake a relay spam message through your system and nominate it yourself. You want it to be on the ORBS list, if that's where the spammer checks. What happens if the spammer doesn't relay check, but simply uses the ORBS list? Answer: if he tries to relay through your system he fails, no matter how he discovered your system. What happens if the relay tester is selling lists of open relays? Answer: his customers will become angry with him because he is giving them bad information. What if these customers decide to stop paying and to just use the ORBS aged relay list? Answer: if the decoy systems are on the relay list they are just as bad off.

Running sendmail -bd should be very effective on systems that have in fact been used as real open relays. Simply switch the configuration so that the system stops delivering mail. For some time the spammer probably will continue to try to use the system. The system has been switched from being an open relay to being a spam trap.

Note also that spammers typically relay via IP number, not by name. What does this mean? Answer: you can simply switch IP numbers between an identified open relay and a spam trap and use the trap to absorb the spam. If the open relay system is not secured it may be discovered again and used again. If that happens its IP number can be switched again.  (The best course is to close the relay, but even in this non-ideal scenario the spammer is still injured.)

Note also that currently there are three most-probable email states for an IP number:
1. The system with that IP number does not accept any email.
2. The system with that IP number accepts email but openly rejects relay.
3. The system with that IP number appears to be a relay and is a relay. (There may be more than 100,000 of these systems.)

The spammer is looking for systems in the third category. He is almost certain that any system that appears to be an open relay when it is tested is an open relay. He encounters almost no difficulty in his testing. He finds as many relays as he needs.
Running sendmail -bd (and then delivering identified test messages) takes this away from him, on a system-by-system basis. He either tries to send spam through the decoy systems or he must devise and use further tests to distinguish between open relays and decoy relays. He cannot hide these tests: they appear in the mail logs. Using the log entries you can notify his ISP of the relay scan activity. (Warn the ISP not to tell the relay tester anything that will identify the source of your report.) You also injure him when you shut down his relay test account.

What happens if the relay tester figures out that your system is a decoy? Answer: change its IP number and go again.

What happens if the relay tester decides your whole domain is suspect, that any relay he finds may be a decoy? Answer: that depends on the spammer. I'd like to think he simply crosses that domain off the list to be checked for open relays. Doesn't this end the usefulness of the decoys in that domain? Answer: Probably. Except that they still are useful as an example: make your domain hostile enough to the spammers and they will blacklist it. If other domains follow your example they will also be blacklisted by the spammers. The goal is to deny relay to the spammers. If they blacklist you that is just as good as if you had simply blocked relay in the first place. And you have the added benefit of all the trouble you have caused the spammer.

An important alert:
The description above is simple, but the world (and sendmail) aren't always as simple as one would like.  Sendmail has a feature, ETRN, that must be dealt with if you use this technique.  ETRN allows anyone to contact your sendmail (if it is running -bd, as suggested above) and cause it to run the queue (attempt to deliver messages) for a particular domain.  So, for example, if the spammer filled your system with spam aimed at users at aol.com he could connect to your server and do etrn aol.com.
So, either turn the feature off or have your decoy sendmail configured so that it can't deliver.  For example, set your smart host to something like nowhere.nodomain.com. If you have several decoys running (any Linux/Unix system with no legitimate or vital email function can be used as a decoy) you can have them all deliver to the same smart host, also running sendmail -bd.  This also simplifies the task of looking at the queue to see what you've capture: simply log on to that system and do a mailq.  Simpler yet, create a cron task that every n hours (your choice on n) does mailq | mail -v yourname@yourhost.  The -v forces delivery.  This may be a system that can connect within your domain but has no valid route to the rest of the world.  If you want to deliver some or all of the relay tests you capture (so the spammer thinks you are an open relay) you can move them to another system's queue and then deliver them (sendmail -qRwhatever, etc.)

The fix (in sendmail.cf):
Change:
      # SMTP daemon options
      O DaemonPortOptions=Port=25, Name=MTA

   To:
      # SMTP daemon options
      # Disables ETRN command to queue messages
      O DaemonPortOptions=Port=25, Name=MTA, M=E
 
 

Note:  I received this from a person who tried to set up a sendmail honeypot:

    Also, I notice you suggest the "sendmail -qRrecipient" option
    to force flushing the queue for that host, but later on you
    really recommend turning off the ETRN option of extended SMTP.
    Well, I turned off etrn, and now the queue flush you recommend
    won't work.  I'm using sendmail 8.12.1.  So I flush the queue
    with "sendmail -q -v".

I am not familiar with other popular MTAs so I can give no advice on these.  I assume they are no less simple to use. Your goal is to create a system that accepts relay messages but delivers only those you wish to deliver.  Typically these would be relay test messages. When you deliver a relay test you falsely identify your system as a relay. You can expect spam soon.

What else?
I believe part of the key to defeating relay spam is to make the internet more hostile and more complex to the spammers. The complexity I seek is in the response of internet email systems to relay test messages. Running sendmail -bd is simply an example of a way to accomplish this. Creating decoy systems add a fourth category email state: the system appears to be a relay but is not a relay. Any other way to do the same thing is just as good, and the more ways there are the more difficult it is for a spammer to distinguish between true open relays and decoy systems.

Sendmail systems should mis-identify their sendmail version when connection is made. They should be intentionally configured to appear to be older versions, so that the spammer cannot reject relay from systems current enough so that they can have relay rejection built in.

Key features:
The key features of the decoy approach described here are:

1.  If you run a honeypot you can intercept relay test messages sent by spammers.  These will give you information about how the spammers test for relays that you can get in no other way.  Remember there is no magic way to test for relays and there is no stealth way to test for relays.
2.  No new or special software is required.  If you are using an older system you do want to bring its sendmail up to date for general security reasons.  The procedures are simple to setup and to use.
3.  The spammers are the targets of your decoy.
4.  The internet is made more hostile to the spammer without effect on legitimate users.
5.  The relay tester identifies himself to you.  You set up the decoy; he sends the test message.  You do nothing which invades anyone's system.
6.  You do everything yourself when it comes to stopping the spam.  You rely on no one else to block, you rely on no one else to provide blocking criteria.
7.  Changing the IP numbers of systems disrupts the spammers map of the internet.
8.  Changing open relays to decoys (rather than changing them to relay rejecters) allows you to trap and retain spam and to complain about the spam as theft of service.
9.  Changing open relays which have been exploited to decoy relays partially compensates for the harm caused to others while they were being exploited.
10.  If a spammer finds he has been decoyed several times by systems in your IP block he may finally give up on trying to use any system in your IP block.  You may potentially protect your whole domain against relay tests and relay abuse by implementing only a few decoys.
11.  A relay decoy uses the simplest filtering possible: email that comes to it it is spam or is spam related. You do not have to analyze headers, you do not have to analyze contents, you do not have to count recipients. The spammer has done the filtering for you.  He's the only one who will try to relay through your system (he knows your system simply as an IP number in a block he is testing). Remember: the decoy is set up on a system that has no legitimate email function.
12.  (Not mentioned above)  When you characterize a relay test message you can pass its description on to any decoy allies you have so that they can configure their decoys to pass the test message almost instantly if they are tested. You pass relay test messages so that the spammer will conclude the system is an open relay.

DCC (Distributed Checksum Clearinghouse)

I've not done it but a more powerful honeypot could probably be created using the DCC idea.  See the link for further information.
 Distributed Checksum Clearinghouse

Vipul's Razor:
Vipul's Razor is a distributed, collaborative, spam detection and filtering network.  It has similarities to DCC and could be used similarly.  See:
 Vipul's Razor

A final word:
Spam fighters should remember Bernard Baruch's observation: "To the man with a hammer everything looks like a nail." In the anti-spam context this can be taken as a caution against trying to fight spam with computer tools alone simply because it is computer tools you have. One good criminal or civil decision against one spammer can give pause to all spammers, or at least drive them offshore. One good new federal law can almost destroy them. In addition to doing what you can using the computers and the internet please also do whatever you can to bring the criminal and civil justice systems to bear on these individuals and organization and to educate your legislators about the nature and the magnitude of this problem. It is very possible that your congressman has a computer staff, and that someone on that staff is strongly anti-spam. This person is your ally.

If you have instructions for setting up a honeypot using a different MTA I'd be glad to add a link to those instructions here.

Postfix:    (nothing yet)

Etc.     (nothing yet)

I wish you well.

Note: I have been wrong more than once. If you see an error in anything above I'd be grateful if you would take the time to show me my error. If I have been unclear feel free to ask, particularly if your reason for asking is that you are interested in trying this technique.  If you try these techniques and make an improvement in what is described above I'd be glad to add a link here to your page describing the improvement.  The same holds true for techniques for creating decoys using mail transfer agents other than sendmail.  Note also that there are sendmail experts in the world; I am not one of them. You would fare better if you consulted with one of them if you have questions touching on the intricacies of sendmail.

Thank you for reading this.  I hope you will use the information and ideas to help eliminate relay spam..

Honeypot in photo by:   Rita Spencer
Photo by:               Rita Spencer

Thanks to Jeff Mock for help with the sendmail configuration options.

Last modified 13-Jun-2002