You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@spamassassin.apache.org by Robert Menschel <Ro...@Menschel.net> on 2005/02/12 23:26:02 UTC

[SARE] header rules updated

Just a quick note that SARE's header rules files have been updated.

Information concerning these rules files can be found at
http://www.rulesemporium.com/rules.htm#header

Bob Menschel

Re: [SARE] header rules updated

Posted by George Georgalis <ge...@galis.org>.

Didn't realize this was a on list with my private reply....

On Thu, Feb 17, 2005 at 04:51:08PM -0600, Chris Thielen wrote:
>George,
>
>>Maybe the way RDJ does the roll back needs be addressed? I know version
>>2 is nearing release, and this wouldn't be difficult to add:  It could
>>check the cf file for a grep-able, commented, "this release" changes
>>entry, which may include a rules.htm#ChangesVerX url.
>> 
>>
>RDJ has always reported the version line of the updated ruleset.  
>Ruleset authors can use this feature to get a one-line change 
>description to RDJ users when they are emailed.  Based on my RDJ run 
>logs, it seems that this used to happen more than it does now, but of 
>course that's up to the Ruleset authors...
>
>I suppose I could broaden the scope of the text returned for version 
>reporting to allow for multiple lines, or explicitly code for changelog 
>support.

The main work needs to come from the ruleset authors. I propose they
put a changes log in cf files, with special #@@# (look) comments.
I would expect changes to take a few to a few dozen lines... A url
for complete change log would be good to include here too.

>>Then if some change broke your site, you get a likely indicator why,
>>right there beside the roll back commands, near the lint output. And if
>>your update is multiple revisions behind, you have a url to get started
>>on finding changes at the relevant revision.
>> 
>>
>When I get time I will revisit --lint.  I also want to process linting 
>each new file one at a time to try to isolate the broken files.

Not sure if that would work for anything but testing for valid ruleset,
a local cf might score a missing rule which is an error, and lint has
limited use if you somehow just check the downloaded file.  I wouldn't
make it a high priority.

>>Actually, I like this proposed way of reporting changes a lot. I've
>>always wondered the point of email notifications, "ruleset x has
>>changed.." They kinda suggest I should do a diff and figure out if
>>everything is really okay. I'd just assume see a change log as part of
>>the notification that new rules have been loaded (or that lint prevented
>>those changes from happening).
>>
>I don't understand... I assume you would prefer the notification to not 
>knowing it was updated at all...?

The behavior is fine, just add the output of "grep '#@@#' newfile.cf"
to the ${MESSAGES} whether lint failed or not. (Once changes get that
tag.) I can send you a diff to try unless you want to put it in...

So I guess the question is, do any of the ninja's want to create
comments for their changes?

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: [SARE] header rules updated

Posted by Chris Thielen <cm...@someone.dhs.org>.

George,

>Maybe the way RDJ does the roll back needs be addressed? I know version
>2 is nearing release, and this wouldn't be difficult to add:  It could
>check the cf file for a grep-able, commented, "this release" changes
>entry, which may include a rules.htm#ChangesVerX url.
>  
>
RDJ has always reported the version line of the updated ruleset.  
Ruleset authors can use this feature to get a one-line change 
description to RDJ users when they are emailed.  Based on my RDJ run 
logs, it seems that this used to happen more than it does now, but of 
course that's up to the Ruleset authors...

I suppose I could broaden the scope of the text returned for version 
reporting to allow for multiple lines, or explicitly code for changelog 
support.

>Then if some change broke your site, you get a likely indicator why,
>right there beside the roll back commands, near the lint output. And if
>your update is multiple revisions behind, you have a url to get started
>on finding changes at the relevant revision.
>  
>
When I get time I will revisit --lint.  I also want to process linting 
each new file one at a time to try to isolate the broken files.

>Actually, I like this proposed way of reporting changes a lot. I've
>always wondered the point of email notifications, "ruleset x has
>changed.." They kinda suggest I should do a diff and figure out if
>everything is really okay. I'd just assume see a change log as part of
>the notification that new rules have been loaded (or that lint prevented
>those changes from happening).
>
I don't understand... I assume you would prefer the notification to not 
knowing it was updated at all...?