Practical Methods for Combatting Spam

Practical Methods for Combatting Spam

This article will describe how spammers can get away with spamming, why spam is such a problem, and why it's likely to remain a problem for quite a while. However, it's not all bad news; I'll give you concrete tips for reducing spam and lowering the cost of spam to your organization. As an added benefit, some of the techniques serve to increase spammers' costs.

How Internet E-Mail Works
To understand spam, we first have to understand how e-mail flows across the Internet. Suppose Alice wants to e-mail Bob; Figure 1 shows how it might work.

Alice sits down at her computer and starts her Mail User Agent (MUA). This is simply the technical term for Evolution, Outlook, Pine, or whatever program Alice uses to create and send e-mail. Alice composes her e-mail and then clicks "Send."

Alice's MUA contacts her service provider's SMTP server. SMTP (Simple Mail Transfer Protocol) is the agreed-upon "language" for transferring mail across the Internet. Alice's MUA tells the SMTP server who is sending the e-mail and who the recipients are (in general, there can be many recipients). It then sends the message header and bodies. Once the SMTP server has collected the message and agreed to transfer it to the final destination, Alice's MUA reports successful transmission.

The SMTP server stores the message on disk and attempts to send it to its final destination. If Bob is across the country and uses a different ISP, Alice's ISP's server determines which server handles mail for Bob's domain. It looks up this information in the Domain Name System (DNS). DNS is a large, decentralized database that maps machine names (like to IP addresses (like DNS also tells mail servers where to send mail for a given domain.

Alice's ISP's SMTP server connects to another SMTP server and transmits the message, much as Alice's e-mail program did in the first place. The server may contact the final SMTP server responsible for Bob's e-mail directly, or there may be a series of servers that relay the message. The exact path taken by the mail depends on Bob's ISP, and to some extent on conditions on the Internet at the time. For example, if Bob's ISP's main SMTP server has crashed, mail may be temporarily routed to an alternate server. Alternatively, Alice's ISP's server may hold on to the mail and retry transmission periodically.

Eventually, Alice's message arrives at the final server that holds Bob's mail. The mail stays there until Bob connects to retrieve it. When Bob clicks on "Check for New Mail" in his MUA, the MUA contacts Bob's ISP's server and downloads mail. Rather than using SMTP, this final download usually uses a protocol called Post Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP). Regardless, once the mail is safely on Bob's computer, it is usually deleted from the ISP's server.

How Spammers Exploit Internet E-Mail
When SMTP was designed some 21 years ago, it met the design goals admirably - it was a simple, easy-to-implement, reliable mechanism for getting mail from Alice to Bob. Understandably, of course, it did not meet goals which weren't important 21 years ago, but have become very important today. SMTP suffers from the following shortcomings:

  • There is no mechanism for authenticating a sender. That is, anyone can fake e-mail from Alice, and Bob will have a hard time telling that it isn't actually from Alice.
  • Even if we could authenticate senders, SMTP has certain special sender-addresses that must always be accepted as valid, no matter what. These special addresses are intended for error reporting, but can be exploited by spammers.
  • SMTP doesn't define a policy for relaying mail. Until fairly recently, many SMTP servers would happily accept e-mail from anyone, for anyone, and relay it onward. In the next section, you'll see why these so-called "open relays" are a problem.

Unfortunately, neither SMTP nor the underlying Internet protocols were designed with security or authentication in mind. On the one hand, the simplicity of the protocols leads to the rapid expansion of the Internet and the dramatic growth of the Web. On the other hand, it also led to problems like spam and Internet fraud.

A Few Years Ago: Open Relays
In the past, spammers would actively search for and exploit open relays. An open relay is an SMTP server that will accept e-mail from anyone and send it to anyone else, without requiring authentication. The reason open relays were so attractive is that they serve as bandwidth multipliers.

If a spammer on a dial-up line wants to send one million messages, that could take a while if he or she has to send each message individually. However, an open relay allows the spammer to batch up messages - for example, he or she can send one message and tell the relay to send it to 100 recipients. This reduces the spammer's bandwidth by a factor of 100 - an enormous savings.

The problem of open relays led to the formation of DNS-based real-time blacklists. Just as the DNS can hold information about host names and addresses, it is also possible to maintain databases of known open relays. SMTP software can consult these databases and refuse e-mail from a known open relay.

DNS-based blacklists are useful, but they can also cause problems. Some blacklists are overly aggressive, blacklisting whole swaths of the Internet because of one badly behaved server. They also may be slow to remove open relays once they have been fixed. Relying on such overly aggressive blacklists can result in legitimate mail being lost.

On the other hand, more conservative blacklists are reactive - they require ample proof that a machine is an open relay before listing it. Unfortunately, by the time the relay makes it onto the blacklist, the spam has already been sent and the spammer begins searching for another open relay to victimize.

Spammers still use open relays because they can help obscure the original source of the e-mail. So real-time blacklists are worthwhile, but be aware that they will not stop all or even most of your spam, and banning mail based on the fact that its relay is in a blacklist will cause you to lose valid e-mail.

More Recently: Cheap Broadband
In the last couple of years, residential broadband has become cheap enough that many people can afford a fast Internet connection. This means that spammers can send directly from their cable modem or DSL link, without requiring the bandwidth multiplication of an open relay. For example, a spammer with a cable modem capable of transmitting 500KB/s can theoretically transmit just over a million 5KB spams per day. Thus we see a couple of trends: spam messages tend to be fairly short now, because home spammers don't have the benefit of bandwidth multiplication. Also, we see message mutation - spammers insert random characters into message headers and bodies to try to fool software that recognizes "known-spam" messages. If you have to transmit every message from your computer anyway, you might as well mutate it to make widespread detection of identical messages difficult.

Anti-Spam Tools
Anti-spam tools can be divided into the broad categories described in this section.

Blacklists and Whitelists
These tools cover both real-time DNS-based blacklists as well as personal blacklists and whitelists maintained by server administrators or end users. Blacklists and whitelists have a number of problems. They tend to be reactive, kicking in only after spam has been delivered at least once. They may also be overzealous, stopping legitimate e-mail. Finally, blacklisting by sender address or domain is practically worthless, because these can easily be faked.

Distributed 'Bulk-Measurement' Tools
The Distributed Checksum Clearinghouse (DCC) collects statistics about how many copies of a particular message have been sent. Clients can query the DCC and refuse messages that "look" bulky, by whatever criteria the client uses. For example, you may choose to reject a message if 350 identical copies of it have been sighted in the wild. DCC is a very clever idea, but it only samples a small percentage of all Internet e-mail. It can also be fooled by hash-busting techniques (message mutation to fool duplicate-detection) and may yield false positives for mailing-list traffic.

Distributed Spam-Reporting Centers
One example is like Vipul's Razor. Razor allows you to report spam to a central clearinghouse, and other Razor clients can query the clearinghouse to see if a message has been reported as spam. Razor uses sophisticated techniques to try to fool mutations and hash-busting, but again, a determined spammer can probably work around it, and Razor also sees only a small percentage of all Internet e-mail traffic - as of mid-March 2003, Razor processes around 15 million e-mail messages per day, which is probably much less than 1% of the Internet's daily e-mail volume.

Sender-Verification Tools
These tools attempt to verify that the sender address exists. There is no satisfactory automatic way to determine this, so some tools send out a "challenge" to unknown senders. If the sender does not reply with a correct response within a certain time period, the mail is discarded.

Challenge/response tools are probably highly effective, but they are also very annoying for people who are trying to communicate with you. Many people will not bother responding to a challenge to prove their existence, especially if they just dashed off a quick note to a sales or information address on a Web site. Also, the e-mail traffic caused by the outgoing challenges may itself be viewed as spam if challenge/response systems become widespread.

Content Filters
These tools examine the content of e-mail messages, and (with varying degrees of sophistication) attempt to classify e-mail as "spam" or "non-spam." Simple-minded content filters can often incorrectly categorize e-mail, much to the annoyance of both senders and recipients, but better-designed and more sophisticated filters can achieve quite high accuracy rates.

The content-filtering category can be further divided into tools that come with a built-in set of rules, and tools that "learn" from your incoming e-mail. The hottest topic in mail filtering recently is so-called Bayesian filters. You train these filters by marking your incoming mail as spam or non-spam. Using statistical techniques, the filters eventually come to recognize key words or phrases that are useful for distinguishing spam from non-spam, and can automatically characterize e-mail fairly accurately.

Content filtering has some disadvantages. Because it must analyze the mail message, content filtering can be applied only after the sending SMTP relay has transmitted the message. If content filtering is done on the mail client, then you've already wasted time downloading the mail so your filter can examine it. On the other hand, some organizations that filter on the server use a single set of rules for the entire organization. This may or may not be acceptable; what the engineering group considers spam might not be spam to the marketing group.

Content filtering is expensive in terms of CPU time. And Bayesian filters can quickly build a rather large database of word or phrase frequencies; if you want to have individual Bayesian filters for thousands of end users, you could be looking at significant amounts of storage.

Content filtering can be fooled. A filter that uses externally supplied rules needs constant updating. While it is harder to fool Bayesian filters, it is still possible. By carefully crafting e-mail messages, an attacker could cause the Bayesian database to grow significantly. Also, Bayesian filters require a fair amount of work from the end user to train them.

In spite of these problems, filters are currently the most accurate way to sort spam from non-spam, and Bayesian filters are probably the best way to customize filtering per recipient.

False Positives
In an ideal world, you'd set up your mail server with its arsenal of anti-spam tools, and it would automatically get rid of almost all of your spam, leaving you only with valid messages and the occasional spam that slips through.

Unfortunately, almost all spam-detection tools have a nasty side effect: they occasionally misclassify valid e-mail as spam. This kind of misclassified e-mail is called a "false positive," and is a show-stopper for many people. Many businesses feel they cannot afford to lose even a single potential client or sales lead, so they do not discard e-mail identified as spam. Instead, they simply tag it or file it in a different folder. Unfortunately, this means that you have to check the spam messages every so often to extract the occasional valid e-mail. This wastes time and defeats the purpose of having automatic spam-detection tools.

  1. Profile of the Ideal Anti-Spam Tool
    After all this discussion, we can build the profile of the ideal anti-spam tool.
  2. The tool must work with current protocols and Internet infrastructure: A true solution to the spam problem will probably require complete reengineering of Internet e-mail protocols; such reengineering is unlikely to happen within the next decade, if at all. So practical anti-spam tools must work within today's SMTP environment.
  3. The tool must not depend on a significant fraction of the Internet adopting it: It's no good to say "if only all SMTP service providers would provide strong authentication..." because it won't happen. Getting even a small fraction of Internet users to agree to change something on their mail servers is nearly impossible.
  4. The tool should run on the mail server: Updating software on a few million mail servers is far cheaper than distributing software to hundreds of millions of end-user PCs. Filtering on the server also saves download time for dial-up users.
  5. The tool should be broad-spectrum and capable of easily integrating new anti-spam technologies as they become available: Simply using real-time blacklists and leaving it at that, or only doing simplistic word or phrase filtering, just won't cut it. Because the spam versus anti-spam battle is an arms race, our anti-spam tools must be capable of identifying and reacting quickly to new spammer tactics.
  6. The tool should be flexible: This follows from the previous point; it should be easy to modify the tool to stop new spammer tactics.
  7. As far as possible, the tool should preserve both the sender's and the recipient's privacy: It should not expose the contents of e-mail to anyone unless the recipient explicitly consents to such exposure.
  8. The tool should be customizable on a per-recipient basis: What's spam to you might be fascinating news to someone else. Server-based filtering should not arbitrarily decide for end users what is spam and what isn't; end users should be able to select their own level of filtering, and set their own level of tolerance for false positives. Individual users should decide whether or not they want to put correspondents through the hassle of a challenge-response system. Per-recipient customization has the additional benefit of making it harder for spammers to tailor messages to evade filters; if different users have different filtering rules, it's hard to know how to construct a message that will evade them all.
  9. The tool should be efficient and not overload the mail server.

SpamAssassin and MIMEDefang
A combination of tools that comes very close to our ideal profile is SpamAssassin combined with MIMEDefang. Both of these tools are freely available under open source licenses.

SpamAssassin is a Perl-based filter that performs hundreds of checks against e-mail headers and bodies, and assigns a score to each check that matches. The scores are designed so that any mail scoring under 5 points is probably not spam, and anything scoring 5 or over probably is spam. Because SpamAssassin uses sound statistical methods to derive the scores, it is amazingly accurate and produces very few false positives. SpamAssassin also integrates DCC and Razor clients.

Of course, as time goes by, the SpamAssassin rules become less effective, because spammers change tactics. Nevertheless, the basic SpamAssassin rules retain their efficacy for several months, which is enough time for the SpamAssassin crew to identify new spam tactics and update the rule set.

In addition, the latest release of SpamAssassin features Bayesian filtering, so it can learn to distinguish spam from non-spam from your mail stream. This extends the useful lifetime of a particular SpamAssassin release quite a bit.

SpamAssassin can be integrated into the mail server in several ways. Probably the most common is to call it from "procmail" - when the mail message is about to be delivered to your mailbox, SpamAssassin scans it and can affect how the message is delivered.

However, a more efficient method is to integrate SpamAssassin directly into the MTA. The popular Sendmail MTA has a method for hooking content filters right into the SMTP conversation; this method is called "Milter," for "Mail Filter."

MIMEDefang is a C- and Perl-based milter that integrates with Sendmail and SpamAssassin (and a number of virus scanners). MIMEDefang uses architectural tricks to make Perl scanning efficient - ordinary PCs can easily handle 100,000 messages per day, and some organizations have MIMEDefang deployments that handle almost 2 million messages per day.

Note that there are other content scanners out there, such as CRM-114, a very sophisticated statistical classifier, and Bogofilter, another Bayesian filter. There's also POPFile, a Bayesian filter designed to pull mail off POP3 servers and classify it.

There are also other Sendmail milter programs, many of which are listed on the Milter Community Site. However, in this article, I concentrate on SpamAssassin and MIMEDefang for a few reasons: SpamAssassin is the best-known content-scanning tool, and it also integrates many other anti-spam tricks such as the DCC and Razor. It's also under active development.

And MIMEDefang is the milter I'm most familiar with (having written it). It's also easy to customize the behavior of your Sendmail server with MIMEDefang, and I believe that rapid customization is the key to reacting to new spammer tactics. However, all of the anti-spam ideas presented here are applicable to any mail server and any mail filtering system. Depending on your setup, however, some of these ideas may be more work to implement with a non-Sendmail system than with a Sendmail server running MIMEDefang.

Using MIMEDefang and SpamAssassin
Once you download and install MIMEDefang and SpamAssassin, your mail server will automatically tag messages that look like spam. You can configure your e-mail client to look for these special tags and file spam in a separate folder or even discard it entirely.

For more control, however, you can customize MIMEDefang's filter. MIMEDefang filter rules are written in Perl, so you need to know a bit of Perl before you tackle filter customization. However, this programmability yields tremendous flexibility. Here are some things you can do very easily with MIMEDefang; the Perl recipes are available from the MIMEDefang mailing list archives:

  • Automatically reject messages scoring higher than a specified spam value.
  • Remove large attachments and replace them with URLs.
  • Reject mail in certain character sets, such as Korean.
  • Redirect suspected spam to a spamtrap e-mail address.
  • Detect and remove viruses and Windows executables.
  • Blacklist certain domains unless the sending relay matches the domain.

For example, it is very effective to block mail from "" unless the name of the sending relay ends in "". While this can block legitimate messages, this rarely happens, in my experience. It does block a lot of spam, though. Once you become used to MIMEDefang, you can explore tricks to combat spammer strategies. Let's look at a few of these tricks.

Force a Retry
Spammers want to send messages cheaply. The normal rules of SMTP allow for a "temporary failure." That is, the receiving server can tell the sending server that it is unable to accept mail for the moment, but the sender should retry a little later. This allows workarounds for transient problems, such as a full disk or a broken network connection, that are expected to be fixed later on.

Well-behaved SMTP servers queue the outgoing message and retry periodically. Spammers often do not wish to incur this expense; they simply ignore the failure and never resend the message.

Therefore, a very effective technique is for your mail server to keep a list of "known senders"; that is, a list of senders who have ever attempted to send e-mail to the server. If mail from an unknown sender arrives, the sender is added to the list and a temporary failure notice is issued. If the sender is legitimate, the mail will be resent (typically after 15-30 minutes) and will be delivered as usual. If the mail is from a spammer using special "never-retry" software, the mail will never be delivered.

This simple rule is very cheap, uses very little bandwidth, and stops anywhere from 10-20% of spam with no human intervention and practically no false positives.

With a little effort, this rule can be programmed into MIMEDefang.

Check the HELO string
The rules of SMTP state that the sending relay must identify itself upon connection with a so-called "HELO" command. This command is supposed to contain the full host name of the sending relay. However, some spamware uses the host name of the receiving relay in the misguided belief that this will somehow relax anti-relay or anti-spam rules. Since your own mail server should never connect to itself, you can simply reject mail from any mail server claiming to be your own.

Other spamware uses an IP address in the HELO command, often a completely random IP address to try to confuse recipients and cause them to misdirect spam complaints. Refusing mail from machines that use an IP address in the HELO command is cheap and effective.

The two HELO checks, on our mail server, stop about 2.5% of all the mail we receive.

Check for Sender/Relay Mismatches
This rule is not suitable for general-purpose use, because it could yield many false positives. However, we have discovered that rejecting mail from senders at "", "", "", and "" unless the sending relay's name ends in the corresponding domain stops about 5% of our incoming mail volume. Our mail logs show that all such stopped mail is almost certainly spam - we see sender addresses such as "<[email protected]>" and "<[email protected]>", which appear to be randomly generated, as well as obvious spam sources like "<[email protected]>".

Use Open-Relay Blacklists
Open-relay and other spam-source blacklists can be very effective; unfortunately, they can also yield a lot of false positives. We recommend that before you block mail based on results from an open-relay database, you configure MIMEDefang to tag such mail first. After a month or so, you'll get a feel for how aggressive or conservative the database is, and you can decide whether or not to trust it to reject mail automatically.

Spam is a problem because of a combination of technical, economic, and social conditions. Current e-mail protocols cannot enforce authentication; sending e-mail is so cheap that even dismal response rates make spamming profitable, and enough people are taken in by spam fraud that it makes the con artists keep spamming.

Unfortunately, all of those conditions are difficult to change. An overhaul of e-mail protocols is not likely in the short to medium term. One of the attractions of e-mail is the very low cost of sending e-mail; any solution that makes it expensive to send e-mail will also change the nature of e-mail and make it much less attractive. And as long as there are gullible people out there, spammers will always have a non-zero response rate.

Given these conditions, the fight against spam will be a long, grinding arms race. No single tool or technique will vanquish spam; instead, we need to use combinations of tools and techniques to restrict the strategies available to spammers. By forcing certain behavior on spammers, we can lower the cost of dealing with spam and improve our spam-fighting tools' automation.

More Stories By David Skoll

As founder and president of Roaring Penguin Software, Inc., David Skoll applies his more experience in custom software development, network design/security, Web, e-mail, and FTP server configuration to solving the networking, systems, and software tools challenges of enterprises. David is the developer of MIMEDefang and creator of rp-pppoe, a PPPoE implementation for Linux that is deployed across Linux servers and clients worldwide. Most recently, he developed and now offers CanIt, an industry-leading anti-spam solution for enterprises.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Wes Peters 12/24/03 03:17:24 PM EST

In response to t sterling, while your intent is good, your solution won't help. Spammers don't run mail servers, they run spam-sending software. This software implements just enough of the SMTP protocol to get the spam into your mail server, or some unsuspecting open relay. Also, spammers do not use proper from addresses, they either use a faked, non-existant sender or worse joe-bob somebody's address. I'm amazed and disappointed at the number of messages I get from spam and virus detectors about the harmful email I've sent to people I've never heard of, often from email addresses I never send from.

t sterling 11/30/03 07:44:34 PM EST

Can we call a global feedback time to answer spam rather than ignore? What I mean is if everybody picks 6.00-6.10pm gmt to answer all spam would it cram their servers and relays. The principle is that there are more of us than them.

Brad Spencer 10/24/03 05:11:23 PM EDT

The article describes how open relays were used to send spam. I know: I had an open relay. Unlike almost everyone else I didn't solve the problem by securing the relay so that the MTA didn't accept the relay spam. That wasn't by design, I just couldn't - not without spending money or changing to an MTA I didn't like. So instead I did what I thought was the next best thing: I accepted the relay spam but didn't deliver it.

That opened my eyes, eventually. Because I was trapping illicit email I soon trapped what everyone would have predicted I would: a test message sent by a spammer to see if the system would relay. Eventually I had the AHA! insight: if I'd trap and deliver the spammer relay tests the spammers would tell themselves they'd found an open realy and would send me spam. I'd not deliver that spam - the spammer would waste his time. With the spam as evidence I could report the spammer to his ISP for ATTEMPTED THEFT OF SERVICE, not for merely sending spam, and that got the ISP's attention - sufficiently so that it would, if anywhere near reputable, cancel the spammer's account. I do recall a lying phone call from one ISP that said he was terminating the spammer ... right ... now. After the call I asked myself why he'd bother to call me to tell me that: email would work.

That worked for years, worked as recently as May (when I shut down the fake open relay. Well, actually, a disk problem shut it down for me.) Users elsewhere have taken the idea and improved on it. Michael Tokarev, in Moscow, added a web page to the open relay honeypot. That was a simple but extremely brilliant idea. All one needed to do was send the URL to the ISP from which the spam appeared to emanate. The ISP could check the IP, see the spam coming out, and terminate the account. Then wait a while and refresh the web page. If the spammer had a backup account a new IP would appear and the ISP could repeat the process. Neat, huh? A complaint now carries forward into the future. (For the actual spam it was more complex, but the description is close enough to the truth. The spammer was spoofing his own IPs in the transmitted spam, with the spoofed IPs throwaway dialup accounts. That way he could send spam on a high-speed connection and never reveal the IP. The dial-ups were fast enough to handle the ACKs, which is all they had to do.)

Another operator set up a very quiet system - one that just accepted and archived spam, nothing more. He trapped spam to over 750,000 recipients a day, on average, in his first year of operation.

Both these systems were ancient X86 boxes, both running Linux: a 100 MHz 386 DX4 and a 90 MHz Pentium. For that matter mine was an ancient Vaxstation 4000/90 -but that ran VMS.

Today the power is in open proxy honeypots - proxypots. There's even a free download:

I restarted the open relay honeypot last week. Not thinking, I paused the process and have been checking it, day after day, not seeing anything. "They've given up on open relays" I thought. Then today I noticed the paused process and resumed it. Three tickles so far, but no test message, no spam - just network connection time-outs. twice, once. (Maybe the spammer is playing DNS games with the latter one - I can't find it.)

I'll keep watching.

At the relay and proxy level (particularly the proxy leve) you don't have to think: if it comes it's spam (for a fake relay that's true if it is a fake: no real email function, not an MX for anything. It can even not have an IP name: spammers work by IP number a lot for relays.)

If you have a Linux box on the net that doesn't need an MTA for any real purpose why not start up sendmail, smarthosted to something that has no MTA and can't accept email? That way email can come in but can't get out - no way. Then just watch the queue nd see what, if anything, you catch. (If you know sendmail then you can be smarter in your configuration - I'm more a VMS guy.) On the VMS system I now just have the execution queue for the processes that deliver email stopped (it no longer is an actual server.) For open relay abuse you can get a lot done without needing any new software at all.

John 10/16/03 10:57:09 AM EDT

We have been using SpamAssassin for some time. SA is a great product and the price is right!!! In addition we use IMPSEC to defang inbound mail for any script kiddies, attached viruses, etc which has eliminated ALL mail born viruses.

You mentioned the "Force a Retry" which sounds like a great idea. I visited the MIMEDefang site but couldn't see anything on how to configure this. Could you point us in the right direction?


Wes Peters 09/10/03 04:11:29 PM EDT

If you have the same email address for any period of time, you will get spam. My father has had the same dial-up ISP account for a little over two years now. He exchanges email with a few friends and family members, is a member of no mailing lists, and has never supplied an email address to an online forum; he gets 3 or 4 spam messages a week. I, on the other hand, have had the same email address for 9 years; it can be found on thousands of web sites, mail list archives, usenet newsgroups, etc. I get a hundred spams a day.

Having email be a medium that is only useful if you don't use it is absurd.

The amount of spam that I get, while tremendously annoying, is not the least bit surprising. The puzzling part is how they found my father's email address. I've encouraged him to change to a cheaper local ISP but he hasn't, probably because he's waiting for me to do it for him. Perhaps this one will do a better job of protecting it's user lists.

Current User 08/18/03 12:55:57 PM EDT

I don't get any spam. All of the PC's I setup don't get spam. Getting rid of profiles and trusted sites seems to do the trick. "Go Figure." Looks to me that putting a user profile on your computer amounts to walking around in real life with a sandwich board sign. With all of your contact information and preferences flashing in bright neon for all (spammers) to see. What actual benefit does user profiles bring to the end user anyway ?

sridhar 08/18/03 03:33:30 AM EDT

Over the last few days we have had this problem of our SMTP servers being used as open relays. As a result even geunine mail sent out were being blocked by recipient mail servers. This article helped us secure our sendmail servers. Thanks David.