Rosserver Webhosting is continually working to reduce spam while ensuring that normal
email service is guaranteed. Here is a brief discussion of our present methodology to ensure fast,
reliable, spam-free email. Other email providers (like MS hotmail) prefer to keep their methods secret,
security through obscurity; this is a completely failed model, if you can think of it then someone
else can think of it too, this is the same model that protects windows from virus and spyware.
Like our choice of Linux for Operating System; "openness" is our philosophy for email/spam protection.
While spam filtering is a desirable feature of any email system. Harsh email filtering can degrade the
system performance, cost more money and result in good email (ham) being mistaken for spam.
We must also obey all of the industry standard regulations (RFC's) to avoid being blacklisted.
Even worse, a strict following of all the standard procedures (the way they were intended)
can still result our system getting blacklisted.
Wild bouncing of rejected emails back and forth just doubles the amount of spam. Thus we absolutely must
protect our network and individual addresses from attack to stay within the community of civilized ISP's.
|
SMTP Rejections per Trap updated every hour
in the order applied to incoming connections |
| Yesterday | Reason for Rejection | Today |
| 9299
| Banned by Ross | 5027
|
| 4586
| Host Ratelimited | 3157
|
| 20447
| Improper HELO | 12335
|
| 21612
| SpamCop Blacklisted | 16437
|
| 13968
| SpamHaus Blacklisted | 9734
|
| 1796
| Barracuda Blacklisted | 1149
|
| 134
| Spam Eating Monkey | 66
|
| 1681
| No Such User | 1091
|
| 29
| Spam Assassin +10 | 29
|
|
Spammers database email addresses (either in part: users and domains) or in whole.
They no longer send from their own address to a data-base of victims.
Instead they send from one data-based victim address to another.
Spam traps, or honey pots, are email addresses (never used for email) set up to
reveal the senders of spam. Any IP address attempting to deliver email to the honey pot
is blacklisted.
Unfortunately there are numerous reasons that the RFC's require us to notify a sender by email
that the email was undeliverable.
If even one of these emails had a honey pot in it's fake "from" address
and we send the "no user here" or "user box full" message then we risk being blacklisted.
For this reason we must do everything possible to determine if mail is deliverable before accepting
it.
We are however allowed to refuse a connection, and can place an error message in the refusal handshake.
If we do not accept the email for delivery -- then no return email is required.
We therefore use the blacklists, setup by these spam trap owners, to reduce our spam but more importantly
to avoid getting placed on the list ourselves. This works well as long as we do not accept undeliverable spam first
(as before the sender gets blacklisted) that we must then return to the spam trap.
|
We apply different methods of detecting spam in the order of processor usage (cost) over the number of
trapped spam. The first three methods catch many with very little cost, while subsequent methods take
more time to process. This is all done at the mere connection attempt, only the last two tests require
us to get additional information from the sender. We never accept the email until all the tests are completed.
The four blacklists have us pause to check the sender's IP address over the internet via a rather efficient dns query.
There are hundreds of lists to choose from. We use more than one because, like us the different lists attract different
types of spam. We have chosen these carefully, changing the number of lists, the particular
lists used, the order that they are applied, tracking the results and tweaking the configuration often.
"No Such User" is costly in cpu usage but very valuable in avoiding the instance where an email has passed the
blacklists but is still from a sender that uses fake "to" and "from" address. We reduce the cost by remembering the
violators and rate-limiting them in the future. At this point any remaining spam should be safely deliverable, any
bounces should be to real senders not spam traps.
Spam Assassin is last because it is the most expensive. Only emails passing all other tests are subjected
to this one. Spam Assassin actually scans the entire email for objectionable content using an artificial
intelligence scoring system. This cost is controlled by only scoring the individual email once
(and if under a +10) placing the results into the header for an easy threshold comparison by your control panel
or even by your email client program like Outlook or Thunderbird. An S.A. scoring of +10 or more has a nearly 100%
likelihood of being spam. We could catch more for the same cost by lowering the threshold score,
but as we also strive to pass 100% of ham we are gentle here and leave the choice to be more brutal
up to domain owners and individual email users.
Users of our system can further reject lower S.A. scores (even fractions and negative numbers) with a variety of methods.
Turn on Spam Assasin in Cpanel to add additional stiffness "account wide" or add a filter under "user level filtering"
for different scores on different email addresses. You can use the control panel, webmail or an email
client program to save the rejected emails in a spam box or delete them immediately.
Our best advice is: a +5 will catch more spam and is relatively safe but anything lower should only be used with
a well maintained white list. We will be happy to help our customers set up Spam Assassin in their server control panel or
Mozilla Thunderbird.
|
|