Subject Rules

2009-07-22 Thread twofers
I'm writing rules for header Subject and have a rule question.
 
I want a rule that would hit on specific words, no matter what order they were. 
Would a rule written like this rule below accomplish that?
 
Is the  *  redundant and not needed?
 
Would a rule written like this be more efficient and faster than a rule where 
say, each of these words was used in a separate individual rule?
 
header LR  Subject =~ 
/ [independent]*[opportunity]*[luxury]*[cowhides]*[win]*[money]*[rep]*[save]*/i
 
Thanks.
 
Wes


  

Re: Subject Rules

2009-07-22 Thread Michael Scheidell



twofers wrote: (in html which might look strange once its replied to)

I'm writing rules for header Subject and have a rule question.
 
I want a rule that would hit on specific words, no matter what order 
they were. Would a rule written like this rule below accomplish that?
 
Is the  *  redundant and not needed?
 
Would a rule written like this be more efficient and faster than a 
rule where say, each of these words was used in a separate individual 
rule?
 
header LR  Subject =~ 
/ [independent]*[opportunity]*[luxury]*[cowhides]*[win]*[money]*[rep]*[save]*/i
 
Thanks.



and if someone sends you an email about 'windows' will you block it?

and what about mispellings of 1dependent? 0pp0rtun1th?

content filtering type rules are very prone to fp's and mostly useless

of you insist, something like this would block (way too much) but do 
what you are looking to do:


header LR Subject =~ 
/\b(independent|opportunity|luxary|cowhides|win|money|rep|save)\b/i


(at least, with \b you will only block subjects that don't accidentally 
contain rep or win in the middle of the word)


Still, put a very low score on it, maybe tie it using meta rules to 
bayes, razor or dcc hits.


--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
 *| *SECNAP Network Security Corporation

   * Certified SNORT Integrator
   * 2008-9 Hot Company Award Winner, World Executive Alliance
   * Five-Star Partner Program 2009, VARBusiness
   * Best Anti-Spam Product 2008, Network Products Guide
   * King of Spam Filters, SC Magazine 2008

_
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/

_
  


Re: Subject Rules

2009-07-22 Thread McDonald, Dan
On Wed, 2009-07-22 at 04:27 -0700, twofers wrote:
 I'm writing rules for header Subject and have a rule question.
 I want a rule that would hit on specific words, no matter what order
 they were. Would a rule written like this rule below accomplish that?

No.  That rule would match every subject line, in strange and bizarre
ways. For example, it would match Subject Rules because the letter R
is in the opportunity group, the u and l in the luxury group, and e
and s in the cowhides group.  Since you have zero or more letters in
those groups, it matches.  And overall, you have zero or more matches on
every line, even if you have zero

You would be wise to read perldoc perlretut.

 header LR Subject=~ 
 /[independent]*[opportunity]*[luxury]*[cowhides]*[win]*[money]*[rep]*[save]*/i


-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX
www.austinenergy.com


signature.asc
Description: This is a digitally signed message part


Re: Subject Rules

2009-07-22 Thread Matt Kettler
twofers wrote:
 I'm writing rules for header Subject and have a rule question.
  
 I want a rule that would hit on specific words, no matter what order
 they were. Would a rule written like this rule below accomplish that?
  
 Is the  *  redundant and not needed?
  
 Would a rule written like this be more efficient and faster than a
 rule where say, each of these words was used in a separate individual
 rule?
  
 header LR  Subject =~
 / 
 [independent]*[opportunity]*[luxury]*[cowhides]*[win]*[money]*[rep]*[save]*/i
  
 Thanks.
  
 Wes


Well, I wouldn't say that * is redundant.. however, I would say this
entire rule is silly and doesn't do what you want, and it's a little
ambiguous what you're really trying to do.

The whole rule devolves to being any empty regex (//) if you express the
*'s as {0}, meaning this should match *any* text.  I highly doubt that's
what you meant.

Also, you've put the words inside [], which turns them into character
classes.
[win]  will match a single character. a w, an i or an  n, not the word
win. I doubt that's what you want either.

You probably meant to do something like this:
header LR  Subject =~ /
independent.*\bopportunity\b.*\bluxury\b.*\bcowhides\b.*\bwin\b.*\bmoney\b.*\brep\b.*\bsave\b.*/i

But that will only match if all the words are used IN THAT ORDER.

If you want to match all of them being used in arbitrary order, you'll
have to use multiple rules and combine them with a meta rule.

Or perhaps you were looking to detect if any one of them was used, which
would be this rule:

header LR  Subject =~ /
\b(?:independent.|opportunity|luxury|cowhides|win|money|rep|save)\b/i

Probably very false positive prone, but that works.






Re: Spamd/spamassassin not catching custom subject rules.

2006-02-01 Thread spongebob
 [EMAIL PROTECTED] wrote:
 Hello,

 I have spamd setup and its working perfectly except for processing
 custom
 subject rules in user_prefs files. The subject rules for the default
 rule
 set are processed and applied as expected all the time.

 Rules are by default not allowed in user_prefs files when using spamd.
 Hence,
 they won't work.

 Set the site-wide option of allow_user_rules to change this, but be warned
 it
 poses a security risk.

 A malicious user could possibly craft a malicious regex containing a shell
 execution escape sequence and gain the privilege level of the user spamd
 is
 scanning mail as. While no exploits are known to me, this is one of the
 better
 spots for malicious local users to try to exploit spamd.


I don't see this option anywhere for spamd. I run it as

/usr/local/sbin/spamd -d --virtual-config-dir=/data/mail11/%d/%l -c -x -r
/var/run/spamd.pid -s /data/log/spamd.log

so there is no configuration file.

The problem is that the rules actually ARE being processed however its
just random. If i send the same message 100 times 80 of them will get
tagged with custom rules in user_prefs file the other 20 will only be
tagged with rules from the default rule set. Its really random as to when
it chooses to process some or all of the rules in user_prefs.



Spamd/spamassassin not catching custom subject rules.

2006-01-31 Thread spongebob
Hello,

I have spamd setup and its working perfectly except for processing custom
subject rules in user_prefs files. The subject rules for the default rule
set are processed and applied as expected all the time. I have copied and
renamed subject rules to user_prefs files and tested them. I wrote a
script to send the same email 30 times a minute and only about 10% of
those messages have the custom subject rule triggered. I have written
custom body rules in the user_prefs files and they work 100% of the time.
Is this a known bug or a configuration issue? Any assistance is
apprechated. Below is my system configuration

FreeBSD hostname 6.0-STABLE FreeBSD 6.0-STABLE #3: Wed Jan  4 17:01:52 EST
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MAILSTORE11  i386

p5-Mail-SpamAssassin-3.1.0_5/
p5-Mail-SPF-Query-1.997/
postfix-2.2.8,1/

I have been able to replicate this issue on multiple servers.


Re: Spamd/spamassassin not catching custom subject rules.

2006-01-31 Thread Matt Kettler
[EMAIL PROTECTED] wrote:
 Hello,
 
 I have spamd setup and its working perfectly except for processing custom
 subject rules in user_prefs files. The subject rules for the default rule
 set are processed and applied as expected all the time.

Rules are by default not allowed in user_prefs files when using spamd. Hence,
they won't work.

Set the site-wide option of allow_user_rules to change this, but be warned it
poses a security risk.

A malicious user could possibly craft a malicious regex containing a shell
execution escape sequence and gain the privilege level of the user spamd is
scanning mail as. While no exploits are known to me, this is one of the better
spots for malicious local users to try to exploit spamd.