Red Hat Bugzilla – Bug 139693
Default included SA ruleset woefully out of date
Last modified: 2007-11-30 17:07:05 EST
Description of problem:
Ancient SpamAssassin rules misdetect real Outlook Message-Id's as forged.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Send email from Outlook 2003 to SA-filtered RHEL email server with
2. Notice that it believes the MUA identity was forged thus
significantly bumping up the SA score
3. Watch valid email be needlessly filtered into spam folders
That Red Hat would keep something as popular as SpamAssassin up to
date with regard to the ever changing needs of the out of the box rule
set in an enterprise product.
Of course, the work around here is to manually set the scoring for
these options to zero. But really... please... issue an updated SA
with a current/workable ruleset. This is the second such SA problem
that has bit me with RHEL 3. We migrated from Red Hat Linux to Red
Hat Enterprise Linux instead of Fedora Core because we wanted
stable... not stagnant.
I completely agree, I was about to submit an RFE on this matter when I
saw this bug. We like most also purchased RHEL for stability, and for
most programs I don't mind if they are a bit out of date.
SpamAssassin however needs to be kept up to date so it has a chance at
defeating the new tricks that spammers employ. The current version is
nearly two years old, and in that time the spammers learned how to
better defeat the older rules. Idealy, I would like to see RHEL
update SpamAssassin frequently, once stability testing has been performed.
One feature sorely lacking in the version RHEL ships with is SPF
(http://spf.pobox.com/) checking. This feature is in SpamAssassin 3
and would really help in cutting down forged emails (even MSN Hotmail
has started using it!).
Simply updating the ruleset of ancient spamassassin-2.55 will not solve our
problems. Right now we are weighing the options of what exactly to do about the
old version of spamassassin in RHEL3. It is no secret that 2.55 is too old to
be useful, but upgrading it to 3.x may require some manual intervention on the
part of system administrators. That detriment may be offset by the fact that
2.55 is so bad that nobody is using it anyway. So it may then be possible to
push the latest spamassassin to RHEL3 to match RHEL4, and RHEL3 becomes useful
again. If you want this to happen and you are customers with RHEL
subscriptions, you should go into IssueTracker in order to request this in RHEL3.
Otherwise I personally recommend using RHEL4 for spamassassin capability. Then
you can try the unofficial test packages at the URL above that I personally use
on my own mail servers, and will hopefully go into RHEL4 U2.
(Although if you want SPF, you don't want to be using SpamAssassin. SPF is
considered to be flawed by many mail experts and is mostly disabled by default
in upstream's latest spamassassin. There are however many other reasons why the
spamassassin-3.x is very good.)
In our business model we run a large number of services on each server. While I
would agree that for a simple mail server updating to RHEL4 might be the easiest
it is not such a reasonable option when you have many servers each doing a large
number of tasks in addition to email.
I opened a RFE with RH support and referred to this bug. They closed my RFE on
May 6th and said that they would submit a feature request linked to this bug and
that this bug would be updated by the egineering team after it has been evaluated.
This is a very old request now, and there has been no decision to budget
resources to upgrade spamassassin in RHEL3. Closing this as WONTFIX.
This can still be appealed but only at the business level.