Fedora Legacy Test Update Notification: spamassassin

Marc Deslauriers marcdeslauriers at videotron.ca
Mon Mar 7 03:42:34 UTC 2005


On Sun, 2005-03-06 at 18:58 -0700, Michal Jaegermann wrote:
> On Sun, Mar 06, 2005 at 07:26:49PM -0500, Marc Deslauriers wrote:
> ....
> > 
> > Name        : spamassassin
> > Versions    : fc1: spamassassin-2.63-0.2.2.legacy
> 
> It seems to me that this is one of these infrequent examples where
> running anything but the current released version, and as a
> corollary maintaining something older, is just a waste of time.
> Spammers do adjust to a way old versions were testings and I know
> from the real world experience that updating makes a real
> difference.  Last week spamassassin stopped over ten thousands
> emails addressed directly to me.  Without filtering my email would
> be useless.

I agree that the latest spamassassin is required in order to maintain an
up-to-date antispam setup. But for security's sake, there are three
options that FL can take here:

1- Update to the latest spamassassin version (3.0.2)

This option is a major upgrade and may very well break some people's
setups. I know of a bunch of people who have spamassassin installed with
MailScanner or some other software and who never upgraded it as it's
"good enough" or they don't have the required know-how to do so. Should
FL update spamassassin and simply say in the release notes "This may
break your setup and/or require updates of other installed software"? I
think it's important for people to be able to depend on the fact that
they can do a "yum update" and keep up with security patches without
breaking their servers every time. I think this option is unacceptable.

2- Don't issue a security update at all

Because the 2.x version of spamassassin is relatively useless in keeping
up with antispam techniques, FL could just assume people have already
upgraded to 3.x and not release an update. What about mail servers that
have 2.x installed and the amount of spam that is getting through is
acceptable? Does FL let them be affected by a potential DoS because we
think they should upgrade to 3.x? What about if the security issue was
more serious, like a remote root compromise? Where do we draw the line?

3- Issue a patch for the current, obsolete, version

Even though we know spamassassin 2.x is obsolete, at least we fix the
security issues present in production servers. If people have already
upgraded to 3.x, then this update will not affect them. If they are
using 2.x, then FL provides the security update that will keep their
server running smoothly. Is this option a waste of time? Maybe, but I
can see no other reasonable option. This is the option Red Hat usually
takes.

Is there any way we could be doing this any better?

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050306/ca840ccd/attachment.sig>


More information about the fedora-legacy-list mailing list