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): spamassassin-2.55-3.2 How reproducible: Always Steps to Reproduce: 1. Send email from Outlook 2003 to SA-filtered RHEL email server with default rules 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 Expected results: 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!). Best Regards, Will.
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. http://people.redhat.com/wtogami/temp/spamassassin/el4/ 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.