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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
