Rodger Ling wrote:

> Well over 90% of the mail received by UTC is spam.  These third-party
> blacklists are the only thing that are preventing hundreds of
> millions of junk messages from clogging UTC mailboxes.  If we were to
> stop using the blacklists, e-mail at UTC would become almost
> unusable.  Unfortunately, this is a "Sophie's Choice" kind of
> scenario, and we are forced to choose the lesser evil: block the
> spam, and accept that some legitimate mail will be blocked as well.

A little clarification from someone with control over most of our spam
filtering...

There are two issues at stake here regarding Comcast, Charter, Yahoo,
Hotmail, or any other major service provider:

Intro:  Due to the proliferation of virii, worms, trojans, and proxy
agents, most spam now originates from domestic broadband addresses;
e.g., the always-connected machines are prone to the growing
intelligence of virii.  If you never update your system, never use virus
scanners, or never use a firewall you are ripe for infection.  Once
infected, the real spammers will relay their spam through your machine
looking EXACTLY as if you really originated the spam (when in fact you
did not).  The average life expectancy of a new, unpatched Windows XP PC
on a broadband connection is approximately 10 minutes.  You may be
infected before you can even register/activate your XP license
(reference paper on surviving the first day of XP:
http://www.sans.org/rr/papers/index.php?id=1298).

(1) The spam "black lists" are starting to list broadband and dialup IP
address ranges because of the above spamming technique.  Ideally, you
should use the proper SMTP server for outgoing mail that matches your
service provider, and should *never* send mail directly to the
destination.  When on campus, this SMTP server is smtp.utc.edu.  When
using another ISP, the server is usually called smtp.<ISP-name>.net|com.

(2) Several providers are now enforcing the above policy by not
accepting outgoing mail from only their own users.

UTC currently blocks any outgoing mail other than from our registered
servers, and the "black lists" that we use will often list dialup and
broadband address ranges, causing mail to be "bounced".

There are two layers of spam protection employed by UTC:

(1) Well-known and well-documented sources of spam are blocked by our
routers.  Sources for these blocks can be found in the Spamhaus Black
List (www.spamhaus.org) and the Spam Prevention Early Warning System
(SPEWS) at (www.spews.org).  We have kept a close guard on these sources
over the years and they have proven to be stable and reliable.
Approximately 90% of attempted mail deliveries to UTC are blocked by
these two sources (note that a spam attempt may retry itself multiple
times before giving up).  Mail deliveries that are rejected via this
method will be returned to the sender with a "time out" message, such as
unable to deliver for 3 days, no more retries.

(2) Common spam "black lists" which are enforced by Onenet itself.
These messages will be rejected to the sender with an error message
indicating which "black list" caused them to be rejected.  Approximately
half of the mail deliveries which passed rule #1 above are blocked at
this level.

In either case, an error should be returned, mail should not simply
"disappear" altogether unless it was done by a third party, or the mail
contained a virus (Onenet will still generally pass at least the mail
header of a virus-infected mail, but may in extreme cases delete the
item entirely).

> If the campus decides it would like to try opening the gates, I'm
> sure it could be arranged, but I don't think we would enjoy the
> results.

If you don't like the level of spam you currently "enjoy" then we could
increase the amount ten-fold in a hurry.

Note that some departmental servers (other than Onenet) are responsible
for their own spam decisions.  Despite the recent concern over the spam
filtering (largely due to the massive increase in virii/worms/proxies)
we have had very few false positives.  I can count them on my fingers
without resorting to toes :-)

Hope that clarifies some of the "fog" surrounding this issue.

Jeff Kell, Network Services
System/Network Security
University of Tennessee at Chattanooga