Re: Question regarding meta's

2006-04-21 Thread Justin Mason

Matt Kettler writes:
 Dan wrote:
  Thanks Matt,
 
  That certainly would explain my problem.  The entry is listed near the
  bottom of this page:
 
  http://bmrc.berkeley.edu/resources/how_to/email/Mail_SpamAssassin_Conf.html
 
 
  Checking Google, its the only page in the world saying meta
  SYMBOLIC_TEST_NAME regular expression.  Its not clear which version
  this relates to.
 
  Back to the drawing board...
 
 Yeah, I just checked the latest SVN snapshot, it doesn't have this either.
 
 Looking closer at that page, it also mentions required_hits, but does
 not mention it as deprecated. required_hits became deprecated in SA 3.0.0.
 
 It also doesn't mention report_safe, which was present in the release of
 SA 2.60
 
 However it does mention the use of arithmetic meta's, which were new in
 SA 2.50.
 
 My only guess is that page is built from some kind of SVN build of a
 pre-release version of SA 2.50. They may have been intending to add
 regex support, and then backed it out when it caused problems.

Yeah, we had that in a *long* time ago.  I think we took it out for
2.60; nobody was using it, and it was tricky to support.

--j.


Re: Question regarding meta's

2006-04-20 Thread Dan

I have an similar meta question,

I'm trying to include all tests conforming to a wildcard (*) meta  
entry so I don't have to type out each member.  This is the  
configuration I have so far but as you can see, RemoveBBB is not  
scoring.  Is what I'm attempting possible and am I doing it  
correctly?  There is no SCORE line, so it should default to 1.0:



CONTENT
Disable This Rubbish
Discontinue Correspondence
Discontinue Emails Like These
Discontinue This Kind of Message


TESTS
body REMOVE_B16 /Disable This Rubbish/i
body REMOVE_B17 /Discontinue Correspondence/i
body REMOVE_B18 /Discontinue Emails Like These/i
body REMOVE_B19 /Discontinue This Kind of Message/i


META
meta RemoveBBB ( (REMOVE_B.* +)  1)


RESULTS
X-SpamAssassin: score=4.0  
tests=REMOVE_B16,REMOVE_B17,REMOVE_B18,REMOVE_B19




This is the section of the manual I'm following:

meta SYMBOLIC_TEST_NAME regular expression
Finally, parts of a meta rule may be defined by a regexp followed by  
an operator. All rules matching the regular expression will be strung  
together, with the given operator between each expression. The rule  
compiler will add ``^'' and ``$'' before and after each regexp, so  
the regexp must match the entire rule; a rule name begining with a  
``.'' or a ``['' will be treated as a regexp.

As an example:
meta TOO_MANY_UA ( (USER_AGENT.* +)  1)

Thanks!
Dan



Re: Question regarding meta's

2006-04-20 Thread Matt Kettler
Dan wrote:


 This is the section of the manual I'm following:

 meta SYMBOLIC_TEST_NAME regular expression
 Finally, parts of a meta rule may be defined by a regexp followed by
 an operator. All rules matching the regular expression will be strung
 together, with the given operator between each expression. The rule
 compiler will add ``^'' and ``$'' before and after each regexp, so the
 regexp must match the entire rule; a rule name begining with a ``.''
 or a ``['' will be treated as a regexp.
 As an example:
 meta TOO_MANY_UA ( (USER_AGENT.* +)  1)

Erm, what version of the man page contains that?

This syntax is not in SA 3.0.x or 3.1.x.



Re: Question regarding meta's

2006-04-20 Thread Dan

Thanks Matt,

That certainly would explain my problem.  The entry is listed near  
the bottom of this page:


http://bmrc.berkeley.edu/resources/how_to/email/ 
Mail_SpamAssassin_Conf.html


Checking Google, its the only page in the world saying meta  
SYMBOLIC_TEST_NAME regular expression.  Its not clear which version  
this relates to.


Back to the drawing board...

Dan




On Apr 20, 2006, at 17:13, Matt Kettler wrote:


Dan wrote:



This is the section of the manual I'm following:

meta SYMBOLIC_TEST_NAME regular expression
Finally, parts of a meta rule may be defined by a regexp followed by
an operator. All rules matching the regular expression will be strung
together, with the given operator between each expression. The rule
compiler will add ``^'' and ``$'' before and after each regexp, so  
the

regexp must match the entire rule; a rule name begining with a ``.''
or a ``['' will be treated as a regexp.
As an example:
meta TOO_MANY_UA ( (USER_AGENT.* +)  1)


Erm, what version of the man page contains that?

This syntax is not in SA 3.0.x or 3.1.x.





Re: Question regarding meta's

2006-04-20 Thread Matt Kettler
Dan wrote:
 Thanks Matt,

 That certainly would explain my problem.  The entry is listed near the
 bottom of this page:

 http://bmrc.berkeley.edu/resources/how_to/email/Mail_SpamAssassin_Conf.html


 Checking Google, its the only page in the world saying meta
 SYMBOLIC_TEST_NAME regular expression.  Its not clear which version
 this relates to.

 Back to the drawing board...

Yeah, I just checked the latest SVN snapshot, it doesn't have this either.

Looking closer at that page, it also mentions required_hits, but does
not mention it as deprecated. required_hits became deprecated in SA 3.0.0.

It also doesn't mention report_safe, which was present in the release of
SA 2.60

However it does mention the use of arithmetic meta's, which were new in
SA 2.50.

My only guess is that page is built from some kind of SVN build of a
pre-release version of SA 2.50. They may have been intending to add
regex support, and then backed it out when it caused problems.



Re: Question regarding meta's

2006-04-20 Thread Dan
Yeah, I just checked the latest SVN snapshot, it doesn't have this  
either.


Looking closer at that page, it also mentions required_hits, but does
not mention it as deprecated. required_hits became deprecated in SA  
3.0.0.


It also doesn't mention report_safe, which was present in the  
release of

SA 2.60

However it does mention the use of arithmetic meta's, which were  
new in

SA 2.50.

My only guess is that page is built from some kind of SVN build of a
pre-release version of SA 2.50. They may have been intending to add
regex support, and then backed it out when it caused problems.



Superb info, thanks!


Re: Question regarding meta's

2006-04-13 Thread Theo Van Dinter
On Thu, Apr 13, 2006 at 08:40:30PM +0200, Ruben Cardenal wrote:
   header __ID1 /regexp1/
   header __ID2 /regexp2/
   header __ID3 /regexp3/
   meta MYID ((__ID1 + __ID2 + __ID3)  1)
 
   When a message triggers MYID, is there any way in the X-Spam-Report of
 showing which individual parts of the meta the message matched?

As far as I know, you can't do that without a plugin.  You could write
a small plugin such that _SUBTESTS_ or something would be rewritten to
the list of subtests (starts with __) that hit, and then include that
in the report.

-- 
Randomly Generated Tagline:
It's a question of consistency.  With a Republican president, I think
 you should just expect a certain amount of corruption -- And with a
 Democratic president, you should expect a [ bleep ] in the oval office.
 - Dave Foley on Politically Incorrect, 2001.12.07


pgpQsFQAHB14A.pgp
Description: PGP signature


Re: Question regarding meta's

2006-04-13 Thread Matt Kettler
Ruben Cardenal wrote:
 Hi,
 
   Let's say I have:
 
   header __ID1 /regexp1/
   header __ID2 /regexp2/
   header __ID3 /regexp3/
   meta MYID ((__ID1 + __ID2 + __ID3)  1)
   score MYID 1
 
   When a message triggers MYID, is there any way in the X-Spam-Report of
 showing which individual parts of the meta the message matched?

No, but you can do something like this:


 header ID1 /regexp1/
 score ID1 0.0001
 header ID2 /regexp2/
 score ID2 0.0001
 header ID3 /regexp3/
 score ID3 0.0001

 meta MYID ((ID1 + ID2 + ID3)  1)
 score MYID 1

This will force ID1-3 to be evaluated as normal rules and show up in the hit
list, but will give them an insignificant score. (You can't make the score 0,
that will disable them)