Reducing Spam with SBL/XBL Block Lists

Home Service Catalog Cruzmail Reducing Spam with SBL/XBL Block Lists

Spam blocking system known as SpamHaus Spam Block List and Exploit Block List (SBL/XBL) blocks all incoming messages against a list of known Spammers and rejects any message that comes from a server known to send large amounts of Spam. Effectively, this blocks spam "at the front door" and doesn't allow it into the system, which has.

When a message is rejected, the sender will receive a bounce message. Spammers will just ignore these messages, but legitimate senders will know to try sending to you from another address or to contact their ISP. This system is one that has been proven to have very, very low incidence of "false positive" errors. This system should reduce the load on the mail servers quite a bit.

The lists are maintained by an organization called Spamhaus. Information about the lists and the methods they use can be found at their web site. http://www.spamhaus.org

Details of SBL/XBL spam blocking:

Implementation of SBL/XBL block lists is an effort to reduce the amount of spam entering mailboxes, reduce the load on the CruzMail system, and to head off a potential overload problem as spam email grows in volume.

The legitimate email bounced by SBL/XBL is considered a very rare case. Blocked email is always bounced with an explanation and never simply discarded. When a system on the SBL/XBL list is blocked, the email from that system is bounced back to the immediate sender with a notification.

The School of Engineering (SOE) and Physical and Biological Sciences (PBSci) email servers have been using the SBL list for some time and the XBL more recently. SOE has seen a great decrease in the amount of spam hitting users mailboxes. On SOE email systems, thousands of spam messages per day are bounced back to the sender.

For additional details about SBL/XBL:

The SpamHause.org organization (http://www.spamhaus.org) provides two lists of systems to block. These lists are called the Spam Block List (SBL) and the Exploit Block List (XBL).

Systems on the SBL are known spammers. The faq for this list and the rational for being on the list are here:
http://www.spamhaus.org/sbl/sbl-faqs.lasso
http://www.spamhaus.org/sbl/sbl-rationale.html

Systems on the XBL are known to forward email with security exploits or forward spam email - often because they themselves are compromised. More information on XBL is located at:
http://www.spamhaus.org/xbl/index.lasso

FAQs:

1. Are block lists new to UCSC's central mail servers?

No, it is not. For at least 5 years, the central mail servers have used a local "sendmail access database" to block hosts. Some of these hosts were added by employees that are no longer here (things like dialup IP addresses, which can be a common source of spam, etc.). Periodically, and on an ad-hoc basis, the current staff will add hosts to this list if they are an immediately abusive sender (lots of spam from a single host, lots of viruses being sent by a single host, etc.). The current staff tries to clear them back out, but we don't have a set policy nor procedure for it (nor would it really be possible to establish one that is enforceable). Also, the current staff does not have the resources to add to the list every host that ought to be added to the list.

A block list is not new to our email service in this regard. Instead, what the SBL/XBL will get us is:

a) the expertise of those who do routinely update and remove hosts from the list as the addresses lose relevance.
b) lots of contributors who submit new addresses for blocking.
c) lots of experts who have the ability to do due diligence in insuring that hosts that are added to the list really do belong in the list.

The SBL and XBL get us all of those features, where our previous block list has none of those features. Plus, our previous block list had been shown every so often to have "false positives" (blocking people that just seemed to be abusing our service, but the actual root cause was something else; or adding what should have been a temporary block that never got removed). So far, in all of our tracking of "false positives", we have yet to find one that was related to the SBL or XBL (see below, about how we use the SBL and XBL in our Spam Assassin scores).

2. Is a block list the same as "deleting my mail before I see it"?

No, it is not. If we were to delete a user's email, on their behalf, when we find that it is spam, the user wouldn't know it and NEITHER would the sender. Thus, if it is a legitimate message that is being deleted as spam by mistake (a false positive), it will look like the message disappeared for no reason. With a block list, the message is rejected during the initial submission (before we use any processing resources upon it), so, if it is a false positive, then the sender will get a notification that the message didn't make it through. This is very important.

Also, it should be considered that with the current volume of spam we receive, many people just delete their messages marked as spam without reviewing them, so it is almost the same as the situation in which messages are deleted on behalf of the user: the message isn't reviewed, the message is deleted, and the user never sees it, nor does the sender find out that the message never got through. This appears to the users as though messages are "disappearing", when in reality they're just being marked as spam. With a real block list in place, the volume of spam will be reduced as much as 95%, which may mean users can feel comfortable actually reviewing their spam folders again, and thus false positive messages will still be reviewed and found.

3. Will the implementation of SBL/XBL "block at connection mode" on UCSC's central mail servers force us to abide by non-UCSC email & spam policies?

No. We can over-ride the external block list. We can set exceptions (standard ones like "let mail to abuse@ucsc.edu through, so people can let us know about false positives, and/or appeal for an exception to the block list", or we can enter exceptions for addresses that are being blocked, but that we feel shouldn't be blocked, including the addresses within our own network). We still have ultimate control over the situation.

4. Is using the SBL/XBL new to the central email service?

No. For some time, the SBL and XBL have been used to increase the Spam Assassin scores in the central email servers. They are HEAVILY weighted (10 points each), such that if a message came from one of those hosts, it was definitely be marked as spam. For users who just delete spam messages without reviewing them, this is almost the same thing (except for the note above, about how real block listing gives feedback for false positives). So, users shouldn't actually see fewer messages get through to their regular folders. Instead, the goal here is to reduce the load on our mail servers by rejecting messages before they get to our very CPU intensive virus/spam scanners.

It has previously been the case that the virus/spam scanners were under such a high load that on peak hours of peak days (generally 9 am - 5 pm, Monday through Friday) the backlog of messages to be scanned was as high as 90 minutes. That means that a critical message could take 90 minutes to get through to its recipient, instead of the 15 minutes we hope to set as a standard of service (or the "instantly" that many users mistakenly expect). Using the SBL/XBL as a means of reducing our mail load (instead of only using it for identifying spam) has the same effect as increasing our processing power by 160% (adding 3 more machines to our current array of virus/spam scanners).

5. Why can't we just increase our processing load instead of blocking some of our traffic?

The problem is that, if we go down the path of choosing to increase our processing power instead of reducing our load, we will forever be increasing our expenses to keep up with the ever increasing load of spam. With a block list, we don't need to increase our CPU resources, or embrace other expenses. This is because the block list is a minor cost in memory and CPU use when compared to the memory and CPU cost of scanning messages. By reducing the number of messages we scan we more than make enough room for the block list's resources ... and the block list will scale over time to keep track of increases in the number of spam senders out there. The economics heavily and dramatically lean toward blocking messages over adding more machines. We then use our scanning resources to identify the remaining 5 to 10 percent of spam that gets around the block list.

6. What about other anti-spam techniques?

There aren't any perfect anti-spam techniques. They all have work arounds, so the best approach is to evaluate the effectiveness of each, and use all of the ones that help, not just one. Along these lines, other techniques are being evaluated, but not as a substitute for the SBL/XBL, but rather as a supplement:

a) Greet Delay: this enforces some mail server protocol requirements that many spammers and viruses violate by slightly delaying the initial greeting of the mail protocol. This can have a dramatic effect on both spam and viruses.

b) Connection Rate Control: this keeps a single host from trying to flood our servers with multiple messages at the same time.

c) Other Block Lists: So far, research by our staff indicates that the SBL and XBL (run by spamhaus.org) are very accurate. However, some other schools use the MAPS block lists instead. One of the key differences is that MAPS is a subscription based service, where Spamhaus is free. MAPS is being evaluated, but Spamhaus shows as much, if not more, promise in reducing our traffic, and we already know that it has a high degree of accuracy for our traffic. The best first step is to use the SBL and XBL, and then try to evaluate whether or not we should add MAPS or compare the accuracy of MAPS to the SBL/XBL over time.

d) SMTP-AUTH (authenticated mail submission): This one works for internal traffic, and when our own users are at remote sites. When someone who is not one of our users (such as a vendor, or a professor at another school, or a student who has not yet applied or been accepted) sends us a message, they can't authenticate against our system. Thus, SMTP-AUTH does help for some types of spam reduction (which is in the works), but not for the general case, which is where the bulk of our current traffic load comes from. (Currently SMTP-AUTH is required on the residential network.)

7. What is the difference between SBL and XBL?

SBL is a list of known (verified) spam operators who send spam for their own personal gain, and is a fairly conservative list. XBL is a little more aggressive and blocks addresses that have been reported to be spam sources. They can be computers that have been "exploited" by a virus or worm and are unknowingly relaying spam (typically, from people already on the SBL), or they can be computers that "move" around the internet too frequently for the SBL to keep up with.

8. Why might I be affected by the XBL?

When an address is added to the XBL, it is not required to be a "permanent" address; in fact, computers (especially computers that connect to the internet via cable / DSL or a modem connection) can change addresses frequently (as often as every 4 hours or more!). Occasionally, this type of "dynamic" address will be added to the XBL because a computer that was using it was "exploited" or otherwise sending out spam. Since an XBL listing might last more then 4 hours, depending on which reason it was listed, the computer that was listed could return the address which would then be assigned to a non-exploited computer. This would be a rare case, because in order for this type of listing to affect a person, they would typically be running their own mail server. A computer might also be affected because it has been "exploited" by a virus or worm and is sending out spam without the owner's knowledge.

9. Why might my ISP be affected by the XBL?

It is possible for an ISP's mail server to be listed by the XBL if one of its customers gets "exploited" by a virus or worm and sends spam out using the ISP's mail server. This type of listing is generally acknowledged and fixed by the ISP very quickly (since it would affect a large amount of their email traffic). If you suspect that your ISP is listed or you receive an XBL "bounce" message, please contact your ISP and let them know; UCSC will only bypass an XBL block when they are contacted by the owner of the affected mail server.

10. What should I do if I am affected ("listed") by the XBL? What should I do if I receive a "bounce" message?

If you receive an XBL "bounce" message and you don't run your own mail server, you should see the next FAQ. If you are running your own mail server, you should check with the XBL (go to http://www.spamhaus.org/lookup.lasso and enter your IP address or reference number from the "bounce" message) to find out why you were listed. If you were inadvertently listed and need immediate access to the UCSC mail servers, you may contact abuse@ucsc.edu for an exception to the block list; if you were listed because your mail server is sending out spam, please correct the problem and request removal from the XBL using the above URL.

11. What should I do if my ISP is affected by the XBL?

You should contact your ISP and let them know that you think that their server is listed on the XBL; they will need to take the appropriate corrective actions themselves. You can direct them to abuse@ucsc.edu if they need to contact UCSC. This is a special address that is not subject to any of the SBL or XBL blocks.

For additional help with reducing spam, please contact the ITS Support Center .