Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SpamAssassin: users

URIBL_BLACK

 

 

First page Previous page 1 2 Next page Last page  View All SpamAssassin users RSS feed   Index | Next | Previous | View Threaded


up at 3

Oct 10, 2008, 1:55 PM

Post #1 of 27 (512 views)
Permalink
URIBL_BLACK

Of the fair amount of false negatives that get through, more than 90% of
them appear to hit on URIBL_BLACK. I have incrementally increased it
recently to a score of 5.0 (I hit on 6.0). The stuff that's still getting
through seems to be hitting on only URIBL_BLACK.

I am very tempted to bump the score of it to 6.0 or higher, as it would
drastically reduce spam, but I'd like to get any false positive feedback
on doing that first. I haven't seen any so far, but I figure others must
be doing this.

James Smallacombe PlantageNet, Inc. CEO and Janitor
up[at]3.am http://3.am
=========================================================================


felicity at apache

Oct 10, 2008, 2:19 PM

Post #2 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

This has come up on the list before, but... Looking at my most recent
network run:

OVERALL SPAM% HAM% S/O RANK SCORE NAME
0 460740 21564 0.955 0.00 0.00 (all messages)
0.00000 95.5290 4.4710 0.955 0.00 0.00 (all messages as %)
74.714 78.1593 1.1130 0.986 0.78 0.00 URIBL_BLACK

a 1.1% FP rate is very bad IMO. SURBL is < 0.1%, for comparison.


On Fri, Oct 10, 2008 at 04:55:57PM -0400, up[at]3.am wrote:
> Of the fair amount of false negatives that get through, more than 90% of
> them appear to hit on URIBL_BLACK. I have incrementally increased it
> recently to a score of 5.0 (I hit on 6.0). The stuff that's still getting
> through seems to be hitting on only URIBL_BLACK.
>
> I am very tempted to bump the score of it to 6.0 or higher, as it would
> drastically reduce spam, but I'd like to get any false positive feedback
> on doing that first. I haven't seen any so far, but I figure others must
> be doing this.

--
Randomly Selected Tagline:
"... the Saab company didn't report a slight problem with the Saab 9000
cars. The Saabs have a problem with the wiring which causes the engine
to fail, and the power windows and door locks to stop working. The car then
fills with smoke pouring from the dashboard, and then may explode."
- From Headline News


me at junc

Oct 10, 2008, 3:01 PM

Post #3 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Fri, October 10, 2008 22:55, up[at]3.am wrote:

> I am very tempted to bump the score of it to 6.0 or higher, as it would
> drastically reduce spam, but I'd like to get any false positive feedback
> on doing that first. I haven't seen any so far, but I figure others must
> be doing this.

meta URIBL_BLACK_ADJ (URIBL_BLACK)
describe URIBL_BLACK_ADJ Meta: i trust uribl more :)
score URIBL_BLACK_ADJ 1.5

that way you still benefit from score adjust on sa-rules

--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098


raymond at prolocation

Oct 10, 2008, 3:11 PM

Post #4 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

Hi!

>> I am very tempted to bump the score of it to 6.0 or higher, as it would
>> drastically reduce spam, but I'd like to get any false positive feedback
>> on doing that first. I haven't seen any so far, but I figure others must
>> be doing this.

> meta URIBL_BLACK_ADJ (URIBL_BLACK)
> describe URIBL_BLACK_ADJ Meta: i trust uribl more :)
> score URIBL_BLACK_ADJ 1.5
>
> that way you still benefit from score adjust on sa-rules

Huh, why not simply:

score URIBL_BLACK 6

Inside your local.cf? This is wasting CPU... ?

Bye,
Raymond.


sa-list at alexb

Oct 10, 2008, 3:15 PM

Post #5 of 27 (476 views)
Permalink
Re: URIBL_BLACK [In reply to]

On 10/10/2008 11:19 PM, Theo Van Dinter wrote:
> This has come up on the list before, but... Looking at my most recent
> network run:
>
> OVERALL SPAM% HAM% S/O RANK SCORE NAME
> 0 460740 21564 0.955 0.00 0.00 (all messages)
> 0.00000 95.5290 4.4710 0.955 0.00 0.00 (all messages as %)
> 74.714 78.1593 1.1130 0.986 0.78 0.00 URIBL_BLACK
>
> a 1.1% FP rate is very bad IMO. SURBL is < 0.1%, for comparison.

Would you pls post those FP URIs so ppl can judge what your rating is
based upon.


me at junc

Oct 10, 2008, 3:16 PM

Post #6 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Sat, October 11, 2008 00:11, Raymond Dijkxhoorn wrote:
>> meta URIBL_BLACK_ADJ (URIBL_BLACK)
>> describe URIBL_BLACK_ADJ Meta: i trust uribl more :)
>> score URIBL_BLACK_ADJ 1.5
>> that way you still benefit from score adjust on sa-rules

read last line here one more time

> Huh, why not simply:
> score URIBL_BLACK 6
> Inside your local.cf? This is wasting CPU... ?

olso works, but when sa-rules change the score you did not notice the change

--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098


raymond at prolocation

Oct 10, 2008, 3:30 PM

Post #7 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

Hi!

>>> describe URIBL_BLACK_ADJ Meta: i trust uribl more :)
>>> score URIBL_BLACK_ADJ 1.5
>>> that way you still benefit from score adjust on sa-rules

>> Huh, why not simply:
>> score URIBL_BLACK 6
>> Inside your local.cf? This is wasting CPU... ?

> olso works, but when sa-rules change the score you did not notice the change

Sure i understand your idea behind it but you can also write little perl
script that mails you the changes after a SA-UPDATE. And not waste cycles
on extra metas.

Bye,
Raymond.


felicity at apache

Oct 10, 2008, 3:32 PM

Post #8 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Sat, Oct 11, 2008 at 12:01:48AM +0200, Benny Pedersen wrote:
> meta URIBL_BLACK_ADJ (URIBL_BLACK)
> describe URIBL_BLACK_ADJ Meta: i trust uribl more :)
> score URIBL_BLACK_ADJ 1.5
>
> that way you still benefit from score adjust on sa-rules

The right way to do this is:

score URIBL_BLACK (1.5)

you don't need another rule, you just want to add a value to the score.

--
Randomly Selected Tagline:
"Presenting.... MIP- Men in Pain
Starring... Mr. T... Our new security advisor... pocket protectors with
an attitude! "I pity the fool who tries to break into MY firewall!""
-Don Roeber


felicity at apache

Oct 10, 2008, 3:43 PM

Post #9 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Sat, Oct 11, 2008 at 12:15:00AM +0200, Yet Another Ninja wrote:
> > 74.714 78.1593 1.1130 0.986 0.78 0.00 URIBL_BLACK
>
> Would you pls post those FP URIs so ppl can judge what your rating is
> based upon.

(imperfect) command posted for my future reference ...
$ grep URIBL_BLACK ham-net-theo.log | samailoffset | egrep -A1 ' URIBL_BLACK ' | grep URIs | sort | uniq -c | sort -rn

180 * [URIs: displaymarketplace.com]
16 * [URIs: cmcx4.com]
6 * [URIs: bme1.net]
5 * [URIs: s2d6.com]
5 * [URIs: expatica.com]
3 * [URIs: closeoutcatalogoutlet.com]
2 * [URIs: n-email.com]
2 * [URIs: lduhtrp.net]
2 * [URIs: internetbrands1.com]
1 * [URIs: mybid.com.au]
1 * [URIs: jdoqocy.com]
1 * [URIs: delivra.com]
1 * [URIs: bit.ly]
1 * [URIs: barackobama.com]

--
Randomly Selected Tagline:
"Oh ... I love God. He's so deliciously evil." - Stewie on Family Guy


me at junc

Oct 10, 2008, 3:49 PM

Post #10 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Sat, October 11, 2008 00:32, Theo Van Dinter wrote:
> score URIBL_BLACK (1.5)
> you don't need another rule, you just want to add a value to the score.

both ways do the same ?

--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098


ned at unixmail

Oct 10, 2008, 4:05 PM

Post #11 of 27 (498 views)
Permalink
Re: URIBL_BLACK [In reply to]

up[at]3.am wrote:
>
> Of the fair amount of false negatives that get through, more than 90% of
> them appear to hit on URIBL_BLACK. I have incrementally increased it
> recently to a score of 5.0 (I hit on 6.0). The stuff that's still
> getting through seems to be hitting on only URIBL_BLACK.
>
> I am very tempted to bump the score of it to 6.0 or higher, as it would
> drastically reduce spam, but I'd like to get any false positive feedback
> on doing that first. I haven't seen any so far, but I figure others
> must be doing this.
>

Relying on a single rule is dangerous IMHO unless you have some good
negative scoring ham rules to counteract any potential FPs. A
combination of lower scoring rules is always going to be more reliable
than a single high scoring rule.

Do you have Bayes enabled and a well trained Bayes database? I see >97%
hits on Bayes_99 and 98.5% on Bayes_80 and above. As well as
incrementing spam scores, negative scoring Bayes and AWL hits are great
for saving potential FP spam assignments when other rules hit as FPs,
especially if you've bumped the score of those rules to at or near your
spam threshold.

Another alternative is to look at adding a few custom rules to hit
against the stuff that's currently sneaking past.


sa-list at alexb

Oct 10, 2008, 11:29 PM

Post #12 of 27 (476 views)
Permalink
Re: URIBL_BLACK [In reply to]

On 10/11/2008 12:43 AM, Theo Van Dinter wrote:
> On Sat, Oct 11, 2008 at 12:15:00AM +0200, Yet Another Ninja wrote:
>>> 74.714 78.1593 1.1130 0.986 0.78 0.00 URIBL_BLACK
>> Would you pls post those FP URIs so ppl can judge what your rating is
>> based upon.
>
> (imperfect) command posted for my future reference ...
> $ grep URIBL_BLACK ham-net-theo.log | samailoffset | egrep -A1 ' URIBL_BLACK ' | grep URIs | sort | uniq -c | sort -rn
>

> 180 * [URIs: displaymarketplace.com]
not listed

> 16 * [URIs: cmcx4.com]
no site on URI????

> 6 * [URIs: bme1.net]
hits harvested tagged traps addrs.
(lottsa evidence)


> 5 * [URIs: s2d6.com]
not listed


> 5 * [URIs: expatica.com]
not listed

> 3 * [URIs: closeoutcatalogoutlet.com]
parked site

> 2 * [URIs: n-email.com]
Delivra ESP - dirty lists hits traps on a daily basis.
Snowshoeing domains


> 2 * [URIs: lduhtrp.net]
not listed - redirects to CommissionJunction trash - in & out of
blacklists all the time.
ZERO global relevance.

> 2 * [URIs: internetbrands1.com]
not listed - often spamvertized to traps

> 1 * [URIs: mybid.com.au]
was delisted on 2008-09-18 - HOSTED PHISH

> 1 * [URIs: jdoqocy.com]
no listed - last UCE reported on 2008-06-17

> 1 * [URIs: delivra.com]
ESP with dirty practices - tons of complaints.
List appender, the works - hardly worth a CPU cycle
Snowshoeing domains


> 1 * [URIs: bit.ly]
abused URL shortener - no abuse prevention
not worth the cycles

> 1 * [URIs: barackobama.com]

listed in white.uribl.com
hits harvested rcpts on daily basis


Something tells me your stats are either obsolete, biased, borked or
your ham corpus would be quite a few other ppl's mainsleaze spam corpus.

Imo, that 1.1% FP rating seems to have little value in a global context.

thx for the trouble...


mkettler_sa at verizon

Oct 12, 2008, 4:34 PM

Post #13 of 27 (480 views)
Permalink
Re: URIBL_BLACK [In reply to]

Benny Pedersen wrote:
>
>> Huh, why not simply:
>> score URIBL_BLACK 6
>> Inside your local.cf? This is wasting CPU... ?
>>
>
> olso works, but when sa-rules change the score you did not notice the change
>
>
You can always do a relative score adjust.. SA supports that you know:

score URIBL_BLACK (1.5)

Will take whatever the existing score is and add 1.5 to it.

See also "score" under:

http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html#scoring_options


jeffc at surbl

Oct 13, 2008, 2:27 AM

Post #14 of 27 (476 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Friday, October 10, 2008, 11:29:33 PM, Yet Ninja wrote:

> Something tells me your stats are either obsolete, biased, borked or
> your ham corpus would be quite a few other ppl's mainsleaze spam corpus.

> Imo, that 1.1% FP rating seems to have little value in a global context.

> thx for the trouble...

Something tells me Theo may not be sharing his FPs with you
anymore. ;)

Seems you don't need them anyway....

Cheers,

Jeff C.
--
Jeff Chan
mailto:jeffc[at]surbl.org
http://www.surbl.org/


sa-list at alexb

Oct 13, 2008, 2:49 AM

Post #15 of 27 (476 views)
Permalink
Re: URIBL_BLACK [In reply to]

On 10/13/2008 11:27 AM, Jeff Chan wrote:
> On Friday, October 10, 2008, 11:29:33 PM, Yet Ninja wrote:
>
>> Something tells me your stats are either obsolete, biased, borked or
>> your ham corpus would be quite a few other ppl's mainsleaze spam corpus.
>
>> Imo, that 1.1% FP rating seems to have little value in a global context.
>
>> thx for the trouble...
>
> Something tells me Theo may not be sharing his FPs with you
> anymore. ;)

he commented offlist - my initial reply never made it to the list.
Second time I sent, shows up two days later, although my MTA delivered
with no issues.

>
> Seems you don't need them anyway....

I was interested in knowing what his 1.1% FP rating was.

If his rating engine sees not listed or whitelisted domains
(barackobama.com) as blacklisted there seems to something borked and
subject to questioning.


csanterre at MerchantsOverseas

Oct 14, 2008, 7:54 AM

Post #16 of 27 (447 views)
Permalink
RE: URIBL_BLACK [In reply to]

> -----Original Message-----
> From: Jeff Chan [mailto:jeffc[at]surbl.org]
> Sent: 2008-10-13 05:28
> To: users[at]spamassassin.apache.org
> Subject: Re: URIBL_BLACK
>
>
> On Friday, October 10, 2008, 11:29:33 PM, Yet Ninja wrote:
>
> > Something tells me your stats are either obsolete, biased, borked or
> > your ham corpus would be quite a few other ppl's mainsleaze
> spam corpus.
>
> > Imo, that 1.1% FP rating seems to have little value in a
> global context.
>
> > thx for the trouble...
>
> Something tells me Theo may not be sharing his FPs with you
> anymore. ;)

We go back and forth we Theo on his FPs all the time :) I for one
appreciate his efforts. He's been patient enough with us. I tend to disagree
with his FP rate for URIBL as well. I'm glad he took the time to show us
which domains were hitting.

--Chris


kdeugau at vianet

Oct 15, 2008, 2:55 PM

Post #17 of 27 (428 views)
Permalink
Re: URIBL_BLACK [In reply to]

Matt Kettler wrote:
> You can always do a relative score adjust.. SA supports that you know:
>
> score URIBL_BLACK (1.5)
>
> Will take whatever the existing score is and add 1.5 to it.

... but this doesn't work in rule channels pulled in by sa-update. :(

(You *can* have "score RULE newvalue" entries in a channel ruleset, but
you can't use the score adjustment mechanism as above in a channel ruleset.)

-kgd


mkettler_sa at verizon

Oct 15, 2008, 3:10 PM

Post #18 of 27 (428 views)
Permalink
Re: URIBL_BLACK [In reply to]

Kris Deugau wrote:
> Matt Kettler wrote:
>> You can always do a relative score adjust.. SA supports that you know:
>>
>> score URIBL_BLACK (1.5)
>>
>> Will take whatever the existing score is and add 1.5 to it.
>
> ... but this doesn't work in rule channels pulled in by sa-update. :(
>
> (You *can* have "score RULE newvalue" entries in a channel ruleset,
> but you can't use the score adjustment mechanism as above in a channel
> ruleset.)
>
>
It doesn't???!!! That sounds like a bug to me.


mkettler_sa at verizon

Oct 15, 2008, 3:16 PM

Post #19 of 27 (428 views)
Permalink
Re: URIBL_BLACK [In reply to]

Kris Deugau wrote:
> Matt Kettler wrote:
>> You can always do a relative score adjust.. SA supports that you know:
>>
>> score URIBL_BLACK (1.5)
>>
>> Will take whatever the existing score is and add 1.5 to it.
>
> ... but this doesn't work in rule channels pulled in by sa-update. :(
>
> (You *can* have "score RULE newvalue" entries in a channel ruleset,
> but you can't use the score adjustment mechanism as above in a channel
> ruleset.)

I just tested this, and it works perfectly on my system. I added this
line to my local.cf:

score URIBL_SC_SURBL (1.5)

And that rule jumped from 0.5 to 2.0 in a test message.

Yes, I used a surbl rule, not a uribl.com rule, but that's only because
the test point I used doesn't trip uribl black.

And for the record:

X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08)


guenther at rudersport

Oct 15, 2008, 4:08 PM

Post #20 of 27 (428 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Wed, 2008-10-15 at 17:55 -0400, Kris Deugau wrote:
> Matt Kettler wrote:
> > You can always do a relative score adjust.. SA supports that you know:
> >
> > score URIBL_BLACK (1.5)
> >
> > Will take whatever the existing score is and add 1.5 to it.
>
> ... but this doesn't work in rule channels pulled in by sa-update. :(
>
> (You *can* have "score RULE newvalue" entries in a channel ruleset, but
> you can't use the score adjustment mechanism as above in a channel ruleset.)

Why would that be? The configuration order looks exactly as expected.
Site pre files, sys pre files, default rules (sa-update), site rules
(including your local adjustments), user prefs. See the debugging output
below.

guenther


dbg: config: using "/etc/mail/spamassassin" for site rules pre files
dbg: config: read file /etc/mail/spamassassin/init.pre
dbg: config: read file /etc/mail/spamassassin/v310.pre
dbg: config: read file /etc/mail/spamassassin/v312.pre
dbg: config: read file /etc/mail/spamassassin/v320.pre
dbg: config: using "/var/lib/spamassassin/3.002005" for sys rules pre files
dbg: config: using "/var/lib/spamassassin/3.002005" for default rules dir

dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org.cf
dbg: config: using "/etc/mail/spamassassin" for site rules dir
dbg: config: read file /etc/mail/spamassassin/foo.cf
[...]
dbg: config: read file /etc/mail/spamassassin/local.cf
[...]

dbg: config: using "/home/guenther/.spamassassin" for user state dir
dbg: config: using "/home/guenther/.spamassassin/user_prefs" for user prefs file
dbg: config: read file /home/guenther/.spamassassin/user_prefs


--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


kdeugau at vianet

Oct 16, 2008, 2:10 PM

Post #21 of 27 (418 views)
Permalink
Re: URIBL_BLACK [In reply to]

Matt Kettler wrote:
> I just tested this, and it works perfectly on my system. I added this
> line to my local.cf:
>
> score URIBL_SC_SURBL (1.5)
>
> And that rule jumped from 0.5 to 2.0 in a test message.

Yes, that works fine. What doesn't work is where the "score RULE (adj)"
entry is in a channel ruleset, and the original rule is in a different
channel or the stock ruleset.

At least, as of last time I tried that was the case. And it still seems
to be:

config: SpamAssassin failed to parse line, "FORGED_MUA_OUTLOOK (-1)" is
not valid for "score", skipping: score FORGED_MUA_OUTLOOK (-1)
channel: lint check of update failed, channel failed

(Even though exactly the same line in local.cf lints just fine, and in
fact if I copy the particular file that rule is in to SA's system config
directory, that *also* lints fine.)

-kgd


guenther at rudersport

Oct 16, 2008, 2:56 PM

Post #22 of 27 (418 views)
Permalink
Re: URIBL_BLACK [In reply to]

On Thu, 2008-10-16 at 17:10 -0400, Kris Deugau wrote:
> Yes, that works fine. What doesn't work is where the "score RULE (adj)"
> entry is in a channel ruleset, and the original rule is in a different
> channel or the stock ruleset.
>
> At least, as of last time I tried that was the case. And it still seems
> to be:
>
> config: SpamAssassin failed to parse line, "FORGED_MUA_OUTLOOK (-1)" is
> not valid for "score", skipping: score FORGED_MUA_OUTLOOK (-1)
> channel: lint check of update failed, channel failed

Unlike regular score lines for non-existent rules (which are kind of
ignored), the relative score adjustment depends on the rule to be
defined before.

Given your demo rule above, you are distributing a custom channel. It
will work, if you rename the channel name to come after the stock
updates channel when sorting lexically.

guenther


> (Even though exactly the same line in local.cf lints just fine, and in
> fact if I copy the particular file that rule is in to SA's system config
> directory, that *also* lints fine.)

--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


kdeugau at vianet

Oct 16, 2008, 3:24 PM

Post #23 of 27 (418 views)
Permalink
Re: URIBL_BLACK [In reply to]

Karsten Bräckelmann wrote:
> Unlike regular score lines for non-existent rules (which are kind of
> ignored), the relative score adjustment depends on the rule to be
> defined before.
>
> Given your demo rule above,

Nominally live, actually. I've had perfectly legitimate staff email
hitting FORGED_MUA_OUTLOOK. :( (I've created a meta rule instead to
drop the score, and since then I've also added whitelist_from_rcvd rules
for all of our office firewalls as well... but if it hits us, it could
hit customer mail as well.)

> you are distributing a custom channel. It
> will work, if you rename the channel name to come after the stock
> updates channel when sorting lexically.

*shrug* It does; it's called zzsarules.vianet.ca. When I first
created it, I *did* run into problems simply redefining scores at fixed
values for rules in other rulesets which were, indeed, sorted *after* my
local channel originally (don't recall the details ATM; pretty sure I
posted here asking about it). Thus the "zz" prefix - but it still
doesn't accept a score *adjustment*.

I've isolated an example into a testable "ruleset"; try:

# sa-update --channel zzsarules.deepnet.cx --nogpg

(Single scoreadj.cf file, with the single rule
"score FORGED_MUA_OUTLOOK (-1)")

Note I'm running 3.2.5 on all the machines using the live ruleset, but
IIRC I first hit this problem with 3.2.4.

-kgd


mkettler_sa at verizon

Oct 16, 2008, 6:20 PM

Post #24 of 27 (417 views)
Permalink
Re: URIBL_BLACK [In reply to]

Kris Deugau wrote:
> Matt Kettler wrote:
>> I just tested this, and it works perfectly on my system. I added this
>> line to my local.cf:
>> score URIBL_SC_SURBL (1.5)
>>
>> And that rule jumped from 0.5 to 2.0 in a test message.
>
> Yes, that works fine. What doesn't work is where the "score RULE
> (adj)" entry is in a channel ruleset, and the original rule is in a
> different channel or the stock ruleset.
Hmm, I'm not exactly sure why you'd do that. Are you trying to
distribute updates rule sets over sa-update that contain score mods?

In general, the adjustment must be parsed after the rule, so unless you
can gaurntee the channel is parsed *after* the channel containing the
rule, it's not a good idea.

But if you're just changing a local box, local.cf is the place it
belongs in anyway, not in a channel. (a channel used only by one server
is really silly)


jm at jmason

Oct 17, 2008, 1:29 AM

Post #25 of 27 (412 views)
Permalink
Re: URIBL_BLACK [In reply to]

Kris Deugau writes:
> Karsten Bräckelmann wrote:
> > Unlike regular score lines for non-existent rules (which are kind of
> > ignored), the relative score adjustment depends on the rule to be
> > defined before.
> >
> > Given your demo rule above,
>
> Nominally live, actually. I've had perfectly legitimate staff email
> hitting FORGED_MUA_OUTLOOK. :( (I've created a meta rule instead to
> drop the score, and since then I've also added whitelist_from_rcvd rules
> for all of our office firewalls as well... but if it hits us, it could
> hit customer mail as well.)
>
> > you are distributing a custom channel. It
> > will work, if you rename the channel name to come after the stock
> > updates channel when sorting lexically.
>
> *shrug* It does; it's called zzsarules.vianet.ca. When I first
> created it, I *did* run into problems simply redefining scores at fixed
> values for rules in other rulesets which were, indeed, sorted *after* my
> local channel originally (don't recall the details ATM; pretty sure I
> posted here asking about it). Thus the "zz" prefix - but it still
> doesn't accept a score *adjustment*.
>
> I've isolated an example into a testable "ruleset"; try:
>
> # sa-update --channel zzsarules.deepnet.cx --nogpg
>
> (Single scoreadj.cf file, with the single rule
> "score FORGED_MUA_OUTLOOK (-1)")
>
> Note I'm running 3.2.5 on all the machines using the live ruleset, but
> IIRC I first hit this problem with 3.2.4.

In this situation, I think the cleanest way to do it is to define a meta:

meta FORGED_MUA_OUTLOOK_ADJUST (FORGED_MUA_OUTLOOK)
score FORGED_MUA_OUTLOOK_ADJUST -1

those are not dependent on the order in which they're defined in any
way.

--j.

First page Previous page 1 2 Next page Last page  View All SpamAssassin users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.