Spammers’ Most Lethal Weapon

This is a real case study, which happened over the last couple of weeks at a client site. During this time the client email administration team had been experiencing various problems with their LISTSERV.  First, let’s cover a few technical details. This will lay a foundation as to why backscatter is the most dangerous tool in a spammer’s arsenal of weapons.

Spammers like to put fake information in email messages. This sneaks them past email filters. Since email spam  filters now just delete messages that come from non-existent domains, the spammers are very slick about making their messages look like they’re coming from real email addresses.   If your corporate e-mail addresses has been published anywhere on the Internet, you and your coworkers  are at risk as prime candidates for backscatter.

The spammer may peel email addresses off web sites or sometimes even guesses them.  Then the spammer places the addresses in the “from” line of fake messages.  Now these messages are sent out to hundreds of thousands of recipients. When the spam is sent to an inactive address, it can sometimes be bounced back to unsuspecting valid email inboxes . . . maybe even yours.

Spammers have figured out how to capitalize on this bouncing back of email to accomplish their scams.  The email server bounce back mechanism basically becomes a cash register to spammers.  Since backscatter comes from legitimate mail servers, it can cause special problems. In fact, some security specialists are convinced that spammers have been intentionally sending messages that will be bounced back as a way to sneak around spam filters. That’s because some mail servers bounce back the original message as part of their notice.

So a LISTSERV comes on the scene of an organization to cut spammers off at the knees, while allowing staff to send bulk email messages to many valid email addresses. The implementation of a LISTSERV usually occurs when email administrators discover corporate staff are using the the regular email system for mailings to large groups of people. This creates a quite a few issues for the regular email server(s).  Email users call the helpdesk about email not being received, which was sent to a list of a few hundred people.  This is ususally caused by the email server being blasklisted, which email addministrators find out after the fact.  So mainstream email systems like AOL, Yahoo, MSN, Gmail, Hotmail etc. reject the company email server connection when doing a DNS Blacklist look up.

Back to Our Case Study

What makes backscatter especially dangerous on a LISTSERV is there could be hundreds of mailing lists with hundreds of thousands of legitimate email subscribers stored on this particular type of server. Outside subscribers opt-in to LISTSERV lists with the thought their email address is safe and protected. The corporate staff list owners have the same mind set.  When a spammer gets past all the security level locks embedded into a LISTSERV to prevent spam, a company must scramble quickly to do reputation damage control. This is in addition to resolving the technical issues.

After analyzing the logs, and getting on the phone with L-Soft support, it was concluded that the main problem the client was experiencing was backscatter.  LISTSERVs directly connected to the Internet are sitting ducks as targets for backscatter,  since they usually block all emails except from authorized senders and have a number of different bounce back templates based on varying configurations. This tightness of security is what spammers rely on to accomplish their backscatter mission. The client was seeing around 50,000 NDRs coming in per hour. Rejecting a message will usually cause the sending mail transfer agent (MTA) to generate a bounce message or NDR to a local, authenticated user. Alternatively, if the MTA is relaying the message, it should only send such an NDN to a plausible originator as indicated in the reverse-path, e.g. where an sender policy framework (SPF) check has passed.

In order to combat backscatter on the client’s LISTSERV, the following actions were taken.

1. The MSG_POSTING_REJECT_NOTAUTH template was supressed.  This template is the one used to report that a particular user is “…not authorized to send mail to the LISTNAME list…”  This was the predominant (90+%) template being generated via backscatter.  If a legitimate user cannot post to the list, they will most likely contact the list owner or the helpdesk.  So concerns about legitimate blockages here are negligible.

2. The client is now routing all incoming email to the LISTSERV through their spam firewall.  There no longer is any direct connections from external email servers and the LISTSERV.   The spam filter was configured to only scan for viruses, and blacklisted hosts.  This method alone has resulted in over 75% of incoming messages being blocked.

The end result is that LISTSERV performance is now notably improved.  The LISTSERV web management interface is much more responsive and the LISTSERV spool and SMTP queues are virtually empty.

In addition to these methods, the client also configured individual OS logins for all individual email administrators, instead of a single administrator login ID.  In this way email admin staff needing access to the LISTSERV must use their personal credentials.  These allow for the monitoring of future mailing lists being created on the LISTSERV.  Part of the issues contributing to the backscatter were attributed to individual administrators configuring LISTSERV mailing lists incorrectly.  Since every administrator was using the same login ID, there was no way to identify who requires advance training in administering a LISTSERV.

Have you experienced similar situations with backscatter? How did you resolve the issues?