ICESS/Bren Spam Reduction Project
ICESS/Bren Spam rejection counter
Many of us have noticed a increased amount of spam (unsolicited email) in our inboxes lately. This note is a brief explanation of spam, and an overview of what we the compute team, and you the users can do to reduce it.
The first thing to understand about spam is that it is inevitable. Just like telemarketers on the phone or junk mail in your snail mail (U.S. Postal Service mail) if you have an email address you will get some spam. There are a couple things you can do to reduce the rate of spam: first do NOT ever under any circumstances reply to spam. This includes trying to follow the "unsubscribe" instructions at the bottom of a message. This just encourages the spammers. The second thing is be careful with your email address. Every time you enter it on a website it increases the odds it will wind up in the hands of spammers. Many of us use a free email account from Hotmail (www.hotmail.com) or Yahoo (www.yahoo.com) when we need to enter an email address on a potentially suspicious site.
The above will help to reduce spam but will not eliminate it. The systems group also administers our mail server to reduce spam. Before I describe what we do, let me explain what we do not do. Our overriding concern is to be absolutely positive all real email gets to its recipient. In terms of a classification problem many of you are familiar with, ANY false positives are unacceptable. Secondly, while spam is annoying we do not consider it mission critical. If there is a choice between using compute team resources to fix computers, perform security related updates or reduce spam, spam will lose out every time. The last thing to keep in mind is that sendmail (the actual program that manages email) uses computational resources, and the more spam related filtering we do the more resources are consumed. Those of us who remember the "bad old days" when our email server needed to be rebooted on a daily or even hourly basis understand how bad it is to live with an overloaded mail server.
Having said that here is what we do to reduce spam. Internet organizations track mail servers that are known to forward spam and we block all mail from those. There are two common ways spammers try to hide themselves. They send mail with a blank "to:" line, or change the origination domain name to something nonexistent. This sounds rather arcane and it is. Suffice to say no legitimate email would every have either of those characteristics, so we block them. The counter below is keeping track of how much spam we've rejected lately.
The above is what we do today, we are also looking to take some additional steps. We will make it much more difficult for spammers to send mail to our big email lists (i.e. all at bren.ucsb.edu). For those of you who would like to inflict the death penalty on spammers, we are looking into user manageable solutions whereby only email address that you specify can send mail to your inbox. All other messages either go to a different folder (in Outlook) or go through some other process to be "authorized." More details on this as we get some experience with the different products.
We hope you have found this useful or at least informative, and please feel free to contact request with any questions or concerns.
The ICESS/Bren compute team.