Bug 139693
Summary: | Default included SA ruleset woefully out of date | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Sean E. Millichamp <sean> |
Component: | spamassassin | Assignee: | Warren Togami <wtogami> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | will |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-06-08 18:50:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sean E. Millichamp
2004-11-17 16:07:08 UTC
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. |