New Spam Policy: Return to Sender

Computerworld - We've been trying to control the problem of spam, and at long last, we can see light at the end of the tunnel.
My security team and I already use an outsourced service that identifies spam and labels each message accordingly. It does a surprisingly good job, but most users still read every spam-labeled message, even though only one in 10,000 e-mails is incorrectly marked.
Last week, we implemented the next phase: We reconfigured our e-mail gateway to return spam to the sender.
Now the end user never sees any e-mails identified as spam. Instead, we send those e-mails back to the return address and give the sender instructions on how to be added to the "allowed" list. This process uses fax rather than e-mail, so it costs senders time and effort. But we figure that if they are legitimate business users, they'll follow this simple process.
Just over half of our daily e-mail is spam, so returning it saves enormous amounts of disk space and e-mail server processing power.
A Rare Thank You
Seven days into using the new system, it's working like a dream. We've had no complaints, and a handful of users even phoned to say thank you -- a pretty rare experience for my team.
We've sent back hundreds of thousands of messages, and only one sender asked to be added to our allowed list. That's a near-perfect record.
But we've had some problems. Here's one: We send our returned messages from a special not_read@company.com e-mail address. We were initially worried that by doing so we might inadvertently create e-mail loops.
Some of the spam comes from semilegitimate companies that use a genuine source address and have an autoreply on that address. We worried that our returned spam would cause them to send us an autoreply that would be marked as spam and returned to them, which, of course, they would reply to with another message that we thought was spam and so on. So we put in a rule that if the incoming e-mail is addressed to not_read@company.com and is marked by the antispam company as spam, then our rule discards it instead of sending another alert.
Since it's likely that many of the return addresses on spam e-mails are fake and that innocent users will receive our replies, we made sure our responses were polite. In fact, half the messages we returned bounced. This means that the not_read account gets pretty busy. But after this week of bedding in, we really won't read messages sent to it. Instead, we will just delete them.
We thought we had covered all the fairly obvious problems pretty well, but we hadn't thought of everything. I was surprised to come in one day to find that the team that monitors the postmaster e-mail account was unhappy with us.
Endless Autoreplies
Our system's autoreply to a spam from an online catalog vendor had received a reply from that vendor's autoreply system, and our postmaster account had received tens of thousands of messages overnight. It seemed that somehow we had created a loop that included the postmaster account.
As with most Web sites, our postmaster account is read by a real person. This gives administrators a way to contact other administrators to troubleshoot problems with the e-mail system itself.
In our case, for some reason the postmaster account had replied to every message sent to not_read, and that account was getting autoreplies back from the online catalog company. But the not_read account wasn't receiving any of these messages, so it was difficult for us to investigate.
We looked into all kinds of bizarre theories. Perhaps our e-mail was being spoofed by a spammer to get back at us? Perhaps our outsourced service was blocking them because of the number of messages to and from this account? It was frustrating. Then I began to think about why an e-mail in-box wouldn't have any new mail in it. I asked the team, and one of them suggested that it might be full.
I could only laugh, because that was the sort of question we should have asked at the beginning, not after we had wasted our time investigating wild theories. The not_read mailbox had filled up with all the rubbish being returned, and the postmaster account was returning every subsequent e-mail sent to not_read to the sender. But every message returned to the catalog company received an autoreply to the postmaster account.
Once we deleted all the old messages in not_read, we stopped the problem. But it was a bit embarrassing to know that our antispam system had spammed our own e-mail administrators.
I do feel guilty about pushing the problem of sorting through the spam back onto the sender. It would be better if everyone was civilized and we could trust them to send only things we want. But we have to pay to receive spam that uses up our network bandwidth, e-mail server resources and the recipient's time, so I feel justified in forcing the senders of e-mails that look like spam to jump through a few hoops.
A handful of spam messages still get through each day. And already, our users have acclimated to the dramatically lower levels of spam and are complaining that even this reduced level is unacceptable. It's good that we're being pushed to always improve, but I hope we can convince users that this current level of control is right for the issues that spammers pose now. Maybe, just maybe, it will hold until new laws are passed and enforced and spamming finally drops away.
This week's journal is written by a real security manager, "Vince Tuesday," whose name and employer have been disguised for obvious reasons. Contact him at vince.tuesday@hushmail.com, or join the discussion in our forum.
To find a complete archive of our Security Manager's Journals, go to computerworld.com/secjournal.