> from a user's perspective, all this is confusing/confounding. as a
> user, i want to see/use one mechanism for rules.
From an SA admin, it makes perfect sense. :)
>
> currently, it all "smells" like a bunch o' (talented & well-meaning)
> engineers discussing how NOT to do things, and WHETHER to do things.
> and, a fair dosage of 'project pride' mixed in ...
A little from column A and B. But there are some good reasons to why they are seperate.
>
> iiuc, SARE, & eventually RDJ, were created a while ago because,
> historically , releasing new sa-project rules
>
You kind of trailed off there :)
> quite clearly, with the advent of SA-project released/blessed
> sa-update,
> it's not really necessary anymore. i.e., asynchronous rule & code
> releases are provided for.
Ok, no. SARE and the official SA are worlds apart. SARE has been setup to be QUICK and accurate. SA is accurate. SARE wants to get good rules out when they are needed. Now saupdate make the DELIVERY of that possible. But the creation of rules in the official method of SA is... please pardon me... a clusterfsck!
And the apache lic is like reading the fine print on a life insurance policy. I've looked into what it would take to make SARE a part of SA officialy. Yeah, I'll pass.
The ability for SARE to get good rules out fast is why it is there. We have differences on how things should be done. But we take our good rules and submit them to the official SA project. They go thru their testing and eventually get added.
RDJ allows you to get new rules, days maybe hours after a new spam sign is found. And these are TESTED! Not just thrown in. We just have quicker methods of doing it. Being a closed group gives us some abilities that the SA project will never have.
So you have 2 completely seperate ideals of rules. The method of which you choose, and how you aquire is up to you.
Thanks,
Chris Santerre
SysAdmin and Spamfighter
www.rulesemporium.com
www.uribl.com
