SpamCop FAQ

Help for abuse-desks and administrators

How can I control spam from my network?

Recently, there have been a lot of unsolicited bounces from ISPs which are created due to the following chain of events:

1. Spammer 0wns a box on an ISP network (zombie)
2. Zombie is programmed to use ISP's mailserver to send spam
3. Spam sent has forged env-sender, not hosted by ISP.
4. Spam is rejected during delivery to recipient mailserver.
5. ISP mailserver generates a bounce to the original, forged env-sender.

As a result of these messages (which are plauging my spamtraps as well as end-users' inboxes), the ISP mailserver is listed (blocked).

Here are some possible solutions to this problem, all requiring action from the ISP.

1. Look at your double-bounces and triage them.

   (rant on) For a long time, it has been conventional "wisdom" at large sites that double-bounces should simply be ignored. This was stupid from the begining, moreso in the current hostile email environment. Double-bounces are important indications of problems. They should not be ignored. The problem I outline will always be accompanied by a flood of double-bounces (as the forged sender address on the spam also proves invalid). Please please please, people: read your postmaster email!(rant off)

   I would guess that 90% of your postmaster mail represents actionable TOS violations at sites where this problem exists. You need look no further than your own postmaster accounts to find evidence of spam on your network.

2. Rate limit your outbound mxes to deny useful service to spammers on your network.
3. Rewrite the envelope-sender on outbound mail to a local address for the user sending the mail. Warn your users to check their ISP account for bounces.
4. Send bounces from a different server which we can all stand to see blocked. This option is not a real answer to the problem, but may be the only option in some cases.
5. Discard bounces which are not destined for local delivery. Another not-great option.
6. Force users to go through a closed loop confirmation process for every address they would like to use as a env-sender, reject mail with sender addresses not in the resulting opt-in list - or resort to #5 or #3 for them. This is probably the best option, but also the one that requires the most work from ISPs and their users.