We realized a great achievement in stopping 99.887% of the spam traffic to our mail boxes and 100% of the viruses in April 2004!

After sustaining those results for a sixty day period, we were so pleased we felt we should share our information with the world. We devoted one page on our web site to sharing how we did it. That was back in June 2004.

Well, it's now been 8 months and we are still winning the war on spam! We have since received a good many requests for additional information. We felt it was time to post an update. On September 9, 2004 we applied patches and software updates to our Novell mail server and our Windows 2000 workstation that required downing and restarting the computers. So the statistical data we are presenting below is for the ninety (90) day period beginning September 9th and ending December 8, 2004...

Our First Line Of Defense: GroupWise Internet Agent (GWIA)

1) Our mail server showed that 623,252 incoming mail delivery attempts were made during this 90 day period. This represents 6,925 incoming mail messages per day, or 289 messages per hour, or 5 emails per minute, or approximately 1 message every 12 seconds! Note: Last June we were receiving 8,049 attempts per day, 6,925 represents a decrease of 1,124 per day! A 14% decrease here is a big WIN as you will see later, because our volume of legitimate mail increased during this same period.

2) Our mail server denied connections to 403,132 attempts by utilizing the RBL's listed here. During our "Testing Phase" (February to April) we got zero "false positives". Therefore, we block them entirely. We don't accept them. We don't archive them. We waste zero time and resources on them.

3) The mail server dropped 175,053 connections and returned undeliverable notifications. These attempts are known as "Dictionary Spam", all addressed to nonexistent users. In the old days we had "undeliverables" moved to a "problem" directory. Not anymore! We don't accept them. We don't archive them. We waste zero time and resources on them. NOTE: We have one user whose name is commonly misspelled, so we gave him an "alias" in GroupWise with the common misspelled name. Now he gets his legitimate mail that was formerly undeliverable.

4) So, of the 623,252 attempted deliveries, our server accepted only 44,167 emails for processing. Note: 491 messages per day accepted for processing, compared to 686 per day last May. That is a reduction of 195 emails per day getting through our first line of defense! The server also denied 3,330 attempts to use our server for spam "relaying" during this 90 day period.

Our Second Line Of Defense: Guinevere/SpamAssassin (GUIN/SA)

1) Of the 44,167 messages processed by Guinevere and SpamAssassin, 2,875 scored so high as spam that they were deleted forever. The programs identified another 24,473 messages as spam and archived these after stopping them.

2) 244 emails were forwarded automatically to SpamCop for reporting.

3) 199 messages were infected with various viruses.

4) Only 16,376 got past this second line of defense and continued to the next step.

Our Third Line Of Defense: (GWAVA)

1) Of the 16,376 processed at this stage, 1,832 were blocked and archived. The blocking is performed based on different sets of criteria (mostly "source" blocking).

2) An additional 1,445 emails were identified as spam and archived.

3) Another 57 messages were identified as infected. NOTE: This number may be misleading and I apologize for not yet taking the time to verify it (which I can). The GWAVA program drops a harmless eicar virus file to test my anti-virus software and insure it is working correctly, every time its configuration is updated (screws up my real stats).

4) In summary, only 13,042 emails were delivered to user mail boxes out of 448,199 (623,252 total attempts less 175,053 undeliverables). ONLY 2.9% OF MESSAGES ATTEMPTING TO ENTER MY SYSTEM ACTUALLY GET THROUGH! NOTE: Some percentage of the 403,132 blocked by RBL's are probably "undeliverables" anyway.

We are winning and loving it...

At Stage 2 of our processing, we have Guinevere and SpamAssassin set to "not" notify anyone. We don't notify the sender that his message was not delivered. We do not notify the intended recipient that a message intended for him/her was blocked. We do not notify the Administrator each time a message is stopped here. Why have our system generate two additional emails for every bad one? One bad one is enough (one too many).

Why a "No Notifications" policy?

I trust these programs. We used notifications during our "Testing Phase" but turned them off afterwards. Let me explain it this way. I don't want to be notified twice a day when the program stops a virus (does its job), I want to be notified when one gets through.

If I don't want virus notices, why would I want spam notices? What's the point? To me, notifications would be slightly worse than just getting the spam.

At Stage 3, if a message is caught here, the Admin gets a notification. But again, we do not notify the "supposed" sender or "intended" recipient.

When reporting to SpamCop, it is important to report as soon as possible after the spam message is received. Quicker reporting gets the spammer listed on their RBL faster and prevents delivery of the spam message to many more people who are using the RBL for blocking, scoring or tagging (we use their RBL only for scoring).

Some Mail Admins will say we are playing "hard and fast" rules with our mail delivery. I will be the first to agree. The positions we're taking today are far more aggressive than those two years ago. But, I can also attest to the fact that the very few delays or failures are not "material".