Author: BigDumbDinosaur
Anyone who has used a computer for more than 15 minutes is well aware of the constantly growing volume of junk E-mail that flows around the Internet. I know several users who receive as many as 200 messages per day, almost all of which are spam (one of these users is an msn.com subscriber, which tells you a lot about how well MSN's butterfly does his job). I'm somewhat luckier in that respect: thanks to hyper-aggressive policing of our company mailserver, I have managed to reduce the inflow of spam to less than 30 messages a day (down from a peak of more 300 per day). However, "less than 30" is, to me, still unacceptable, and for some strange reason, messages that exhort her to find true love on the Internet continue to annoy my wife (which is good -- if she starts reading them I'm going to have a bit of a problem on my hands).
Spam is more than just a nuisance to users who have no need for home mortgage refinancing, sexual stimulants, or products that will supposedly enlarge certain parts of one's anatomy (if you believe that one, I have ocean-front property for sale in the Yukon). Heavy spam flow costs reputable ISPs a great deal in money and bandwidth consumption, and in somes cases, creates a volume of traffic that forces the installation of larger, more powerful servers in order to handle the load.
Given this, you'd think that the overwhelming majority of ISPs would be up in arms over spam, and actively ferreting out and shutting down the offenders. Unfortunately, that's not the case, simply because the economics at this time apparently aren't severe enough to force a resolution to the issue. After all, high powered servers aren't that costly anymore (especially if running on AMD Opteron hardware with Linux, Sendmail, etc.), and even backbone connectivity isn't as expensive as it used to be. So, where's the pecuniary incentive to smash down the spammers?
There is none, says Jeffrey Race at You needn't eat spam (or worms) (the page may be a bit slow in loading, so be patient). In his article, Mr. Race places the blame for spam squarely on the shoulders of ISPs (which blame is somewhat deserved, methinks) and makes a case for the use of aggressive legal measures to stem the tide of spam, as well as realtime blackhole lists (RBL) to isolate spam sources from the rest of the Internet.
I personally doubt that the legal system in any country will ever spring into action in a concerted effort to take out spammers. Most countries' legal systems are already heavily burdened with tracking down and prosecuting those who engage in "traditional" criminal acts, such as burglary, murder and rape, which probably leaves little in the way of resources that can be used to combat spammers. Also, in the minds of many authorities who do not grok the magnitude of the problem, spam is a victimless crime. After all, who gets hurt by spam? Maybe a few sensibilities are offended by sexually oriented content in some messages, but by and large, this isn't the same as some pistol-wielding crook going into a liquor store and demanding the day's cash receipts, is it?
The author does offer a more practical solution in suggesting more widespread use of RBLs to isolate ISPs who host spammers. An RBL-subscribing ISP will compare the header of each incoming message against the RBL and if a match is made, will refuse to accept the message for delivery. Although I don't subscribe to an RBL, I use the same principle with our company mailserver, with pretty good results. Basically, the server logs all inbound traffic and at periodic intervals, a program is started by cron that reads the log and looks for certain types of red flags, such as mailservers without valid PTR records, subject lines with offending phrases (if you put sexually explicit words in the subject line, our server will silently discard -- not bounce -- your message), messages with no subject line, etc. The end result builds an ever-expanding set of tables for use by sendmail in filtering out undesirable mail sources.
This system has become somewhat self-maintaining, although I do review the proposed sendmail table changes for "false positives." Another facet of our anti-spam vigilance involves having users forward spam to a fake user called (what else) spam, whose mailbox periodically is scanned to determine the true origin of each message. That information is also used to populate sendmail's access.db data table. It's not foolproof by any means, but it does stop a lot of the junk before it every finds its way into a user's mailbox.
While this approach works for me, it is of no value to anyone who doesn't run their own mailserver. Also, having to resort to this much effort to keep a lid on spam makes it painfully clear that I am not curing the problem, only treating the symptoms. So I have no illusions about the effectiveness of what I am doing: the effort to limit spam inflow will continue to increase as the amount of spam itself increases.
Interestingly enough, the fact that you don't have any real control over spam inflow unless you operate your own mailserver has lead some of our clients in recent years to start hosting their own mail so they do have some control. Although managing your own mailserver can be technical in nature and will consume a certain amount of time that you'd rather put to other uses, it does give you the capability of regulating what shows up in users' mailboxes. As an aside, it also gives you control over the mail that your users send -- which may be important in certain types of businesses.
Obviously, if you are dependent on someone else for mail hosting and you are being subjected to a spam barrage, all you can do is complain to whomever provides your service. If you are a corporate user of an ISP's mail services, you could threaten to take your business elsewhere if something isn't done to curtail spam. That might motivate the ISP, but then again, it probably won't. After all, the spam problem seems to be on an exponential growth curve and clearly, no ISP is in that much of a hurry to do anything about it. Otherwise, there would be no problem, right?
If this page was useful to you, please click to help others find it:
More Articles by BigDumbDinosaur
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar