Re: Sought Rules
On 21 Nov 2018, at 4:04, @lbutlr wrote: The page at https://wiki.apache.org/spamassassin/ImproveAccuracy lists Sought rules as recommended. The link leads to https://wiki.apache.org/spamassassin/SoughtRules which states "this is no longer active, and should not be used.” Fixed.
Sought Rules
The page at https://wiki.apache.org/spamassassin/ImproveAccuracy lists Sought rules as recommended. The link leads to https://wiki.apache.org/spamassassin/SoughtRules which states "this is no longer active, and should not be used.” -- "I hate to advocate drugs, alcohol, violence, or insanity to anyone, but they've always worked for me." — Hunter Thompson
Re: Re : Sought rules alive?
Axb wrote: SOUGHT rule updates are working again. That is truly wonderful news! The last update I had was from 2011-11-10. Looking forward to the revivied goodness! Thanks JM! Yes. Thanks! Bob
Re: Re : Sought rules alive?
On 03/07/2012 03:47 PM, Leveau Stanislas wrote: Hi I have the same problem but no idea Regards Stan Le 07/03/12, Andrea gabellini - SCandrea.gabellini...@telecomitalia.sm a écrit : Hello, I noticed that sought rules are not updated from many weeks? Is the project alive? FYI: SOUGHT rule updates are working again. Thanks JM!
Sought rules alive?
Hello, I noticed that sought rules are not updated from many weeks? Is the project alive? Thanks, Andrea
Re : Sought rules alive?
Hi I have the same problem but no idea Regards Stan Le 07/03/12, Andrea gabellini - SC andrea.gabellini...@telecomitalia.sm a écrit : Hello, I noticed that sought rules are not updated from many weeks? Is the project alive? Thanks, Andrea
Re: Sought rules alive?
On 03/07, Andrea gabellini - SC wrote: I noticed that sought rules are not updated from many weeks? Is the project alive? There was no mention of intentionally killing it off, so my guess is it accidentally broke and wasn't noticed. It hasn't been updated since 2012-01-02, and is supposed to update multiple times a day. This came up on the dev list two months ago, unfortunately it was in the form of Can somebody verify this isn't just broken for me? not Hey, sought is broken.: http://old.nabble.com/sought-sa-update-channel---SA-3.4.-trunk-td33164814.html -- You will need: a big heavy rock, something with a bit of a swing to it... perhaps Mars - How to destroy the Earth http://www.ChaosReigns.com
Sought rules revisited
Is it just me, or is the last sought_rules update November 9th? And it is not like an update is available: # sa-update --gpgkey 6C6191E3 -D --channel sought.rules.yerp.org dbg: channel: attempting channel sought.rules.yerp.org ... dbg: channel: current version is 3301199767, new version is 3301199767, skipping channel dbg: diag: updates complete, exiting with code 1 # _ -- View this message in context: http://old.nabble.com/Sought-rules-revisited-tp32872635p32872635.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Sought rules revisited
Is it just me, or is the last sought_rules update November 9th? And it is not like an update is available: # sa-update --gpgkey 6C6191E3 -D --channel sought.rules.yerp.org dbg: channel: attempting channel sought.rules.yerp.org ... dbg: channel: current version is 3301199767, new version is 3301199767, skipping channel dbg: diag: updates complete, exiting with code 1 # _ -- View this message in context: http://old.nabble.com/Sought-rules-revisited-tp32872636p32872636.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Sought rules revisited
Is it just me, or is the last sought_rules update November 9th? And it is not like an update is available: $ sa-update --gpgkey 6C6191E3 -D --channel sought.rules.yerp.org dbg: channel: attempting channel sought.rules.yerp.org ... dbg: channel: current version is 3301199767, new version is 3301199767, skipping channel dbg: diag: updates complete, exiting with code 1 $ _ -- View this message in context: http://old.nabble.com/Sought-rules-revisited-tp32872637p32872637.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Sought rules revisited
Is it just me, or is the last sought_rules update November 9th? And it is not like an update is available: $ sa-update --gpgkey 6C6191E3 -D --channel sought.rules.yerp.org dbg: channel: attempting channel sought.rules.yerp.org [...] dbg: channel: current version is 3301199767, new version is 3301199767, skipping channel dbg: diag: updates complete, exiting with code 1 $ _ Looks, other than the fact that update is from November 9th, okay to me. -- View this message in context: http://old.nabble.com/Sought-rules-revisited-tp32872639p32872639.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Sought rules revisited
Mynabbler wrote: Is it just me, or is the last sought_rules update November 9th? Sorry about the double posts... It was posted using Nabble, which returned 500 errors, and yet still posted the message. Oops. -- View this message in context: http://old.nabble.com/Sought-rules-revisited-tp32872639p32872671.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Sought rules
On Mon, 2011-06-13 at 10:56 -0400, Bowie Bailey wrote:
On 6/10/2011 8:01 PM, Karsten Bräckelmann wrote:
IFF you use the sought channel with SA 3.3.x, you will need the reorder
hack to bend the alphabet.
Would it be worthwhile to change the main code instead? Rather than
making a change to ensure that the sought channel is processed after
updates, why not ensure that the main updates file is always processed
first regardless of the naming of any other third party rules? You
could either make it a special case in the code that processes the .cf
files, or you could change the filename to 0_updates_spamassassin_org.cf.
This would not only fix the current issue with the sought rules, it
would also avoid future problems like this.
Thought about a stock always comes first code change myself, but this
won't help immediately. It will not get into the upcoming 3.3.2 release,
and moreover is very unlikely to make it into any version before 3.4.0.
The problem remains for 3.3.x -- until one of the next stock rules
updates, which will have the Sought FRAUD patterns dropped.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
Hi, Wait a sec, I'm confused about this. JM_SOUGHT_2 hitting on every legit Facebook message on dev@ list February 17th 2011. If the SOUGHT channel was being overridden by the sa-update rules, how would this problem appear from the SOUGHT channel? Doesn't this suggest that spamassassin was successfully using the SOUGHT channel? Yes, and no. grep for SOUGHT in the stock rules... The stock rule-set has a snapshot of the SOUGHT_FRAUD patterns, they do NOT have the SOUGHT patterns. And, well... READ THIS instead. ;) I see that recently Justin made some changes to the svn rules for this, but I wasn't sure if that was going to be reflected in the channel? I just noticed that the last update I have is 1083704, from Apr 18th, and wasn't sure if I was somehow missing something? Thanks, Alex
Re: Sought rules
On Tue, 2011-06-14 at 09:58 -0400, pseudonymous Alex wrote:
I see that recently Justin made some changes to the svn rules for
this, but I wasn't sure if that was going to be reflected in the
channel?
Yes, it will eventually. See the other direct reply by Justin from Sat
to the post you replied to.
I just noticed that the last update I have is 1083704, from Apr 18th,
and wasn't sure if I was somehow missing something?
$ host -t TXT 1.3.3.updates.spamassassin.org
1.3.3.updates.spamassassin.org descriptive text 1083704
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
Karsten Bräckelmann guent...@rudersport.de wrote in message news:1307824487.4844.55.camel@monkey... Yes, works. Regardless of using symlinks, a copy of the cf file, or include'ing it from another config file -- the target will be read again. But don't just take my word for it -- see for yourself! spamassassin --lint -D config Thanks Karsten, much appreciated! So I've just run the lint check, and I've attached the results here in this message (lint.txt). I'm not entirely sure if it's working as desired or not - can you help? I specifically ran this command: spamassassin.exe --lint -D config -x --siteconfigpath=rules --configpath=default_rules Looking at the output in the attached file, I can see the 'sought-rules.cf' file, which I created inside my 'rules' directory, there on line 20. It's getting read *after* the files inside the default_rules directory (lines 7-11), which is good. What's confusing me is that lines 21 onwards show the individual .cf files getting loaded from inside each of the channel subdirectories in default_rules. And this is *after* my sought-rules.cf file gets loaded. So does that mean the stock rules are still overriding the sought rules? Or am I misinterpreting the output here? - Jezz Jun 13 12:35:50.885 [2460] dbg: config: score set 0 chosen. Jun 13 12:35:51.775 [2460] dbg: config: using rules for site rules pre files Jun 13 12:35:51.783 [2460] dbg: config: read file rules/md_init324.pre Jun 13 12:35:51.783 [2460] dbg: config: using default_rules for sys rules pre files Jun 13 12:35:51.789 [2460] dbg: config: read file default_rules/MDaemon.pre Jun 13 12:35:51.789 [2460] dbg: config: using default_rules for default rules dir Jun 13 12:35:51.793 [2460] dbg: config: read file default_rules/khop-dynamic_sa_khopesh_com.cf Jun 13 12:35:51.793 [2460] dbg: config: read file default_rules/khop-general_sa_khopesh_com.cf Jun 13 12:35:51.794 [2460] dbg: config: read file default_rules/khop-sc-neighbors_sa_khopesh_com.cf Jun 13 12:35:51.795 [2460] dbg: config: read file default_rules/sought_rules_yerp_org.cf Jun 13 12:35:51.799 [2460] dbg: config: read file default_rules/updates_spamassassin_org.cf Jun 13 12:35:51.800 [2460] dbg: config: using rules for site rules dir Jun 13 12:35:51.810 [2460] dbg: config: read file rules/80_MDaemon_blacklist.cf Jun 13 12:35:51.811 [2460] dbg: config: read file rules/80_MDaemon_hashcash.cf Jun 13 12:35:51.812 [2460] dbg: config: read file rules/80_MDaemon_report.cf Jun 13 12:35:51.824 [2460] dbg: config: read file rules/80_MDaemon_scores.cf Jun 13 12:35:51.833 [2460] dbg: config: read file rules/80_MDaemon_whitelist_from.cf Jun 13 12:35:51.838 [2460] dbg: config: read file rules/80_MDaemon_whitelist_to.cf Jun 13 12:35:51.964 [2460] dbg: config: read file rules/local.cf Jun 13 12:35:51.965 [2460] dbg: config: read file rules/sought-rules.cf Jun 13 12:35:52.400 [2460] dbg: config: fixed relative path: default_rules/khop-dynamic_sa_khopesh_com/khop-dynamic.cf Jun 13 12:35:52.400 [2460] dbg: config: using default_rules/khop-dynamic_sa_khopesh_com/khop-dynamic.cf for included file Jun 13 12:35:52.409 [2460] dbg: config: read file default_rules/khop-dynamic_sa_khopesh_com/khop-dynamic.cf Jun 13 12:35:52.414 [2460] dbg: config: fixed relative path: default_rules/khop-dynamic_sa_khopesh_com/khop-trust.cf Jun 13 12:35:52.414 [2460] dbg: config: using default_rules/khop-dynamic_sa_khopesh_com/khop-trust.cf for included file Jun 13 12:35:52.420 [2460] dbg: config: read file default_rules/khop-dynamic_sa_khopesh_com/khop-trust.cf Jun 13 12:35:52.423 [2460] dbg: config: fixed relative path: default_rules/khop-general_sa_khopesh_com/khop-general.cf Jun 13 12:35:52.423 [2460] dbg: config: using default_rules/khop-general_sa_khopesh_com/khop-general.cf for included file Jun 13 12:35:52.437 [2460] dbg: config: read file default_rules/khop-general_sa_khopesh_com/khop-general.cf Jun 13 12:35:52.445 [2460] dbg: config: fixed relative path: default_rules/khop-general_sa_khopesh_com/khop-trust.cf Jun 13 12:35:52.445 [2460] dbg: config: using default_rules/khop-general_sa_khopesh_com/khop-trust.cf for included file Jun 13 12:35:52.452 [2460] dbg: config: read file default_rules/khop-general_sa_khopesh_com/khop-trust.cf Jun 13 12:35:52.455 [2460] dbg: config: fixed relative path: default_rules/khop-sc-neighbors_sa_khopesh_com/khop-sc-neighbors.cf Jun 13 12:35:52.455 [2460] dbg: config: using default_rules/khop-sc-neighbors_sa_khopesh_com/khop-sc-neighbors.cf for included file Jun 13 12:35:52.474 [2460] dbg: config: read file default_rules/khop-sc-neighbors_sa_khopesh_com/khop-sc-neighbors.cf Jun 13 12:35:52.500 [2460] dbg: config: fixed relative path: default_rules/sought_rules_yerp_org/20_sought.cf Jun 13 12:35:52.500 [2460] dbg: config: using default_rules/sought_rules_yerp_org/20_sought.cf for included file Jun 13 12:35:52.552 [2460] dbg: config: read file default_rules/sought_rules_yerp_org/20_sought.cf Jun 13 12:35
Re: Sought rules
On Mon, 2011-06-13 at 13:21 +0200, Jezz wrote:
Yes, works. Regardless of using symlinks, a copy of the cf file, or
include'ing it from another config file -- the target will be read
again.
But don't just take my word for it -- see for yourself!
spamassassin --lint -D config
Looking at the output in the attached file, I can see the 'sought-rules.cf'
file, which I created inside my 'rules' directory, there on line 20. It's
getting read *after* the files inside the default_rules directory (lines
7-11), which is good.
What's confusing me is that lines 21 onwards show the individual .cf files
getting loaded from inside each of the channel subdirectories in
default_rules. And this is *after* my sought-rules.cf file gets loaded. So
does that mean the stock rules are still overriding the sought rules? Or am
I misinterpreting the output here?
Have a close look at the output again. In particular search for all
lines containing sought.
You'll see the actual sought channel's contents being loaded -- twice.
Right before the stock rules, and again as the very last cf files being
read.
Does that answer the question? ;)
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On 6/10/2011 8:01 PM, Karsten Bräckelmann wrote: Until the frequent re-scoring and stock rules updates are working properly, you will have to use the dedicated channel, if you want the SOUGHT rules. And even after that, if you want the freshest patterns, you still need the sought channel -- unless stock rules are updated once a day. IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. Would it be worthwhile to change the main code instead? Rather than making a change to ensure that the sought channel is processed after updates, why not ensure that the main updates file is always processed first regardless of the naming of any other third party rules? You could either make it a special case in the code that processes the .cf files, or you could change the filename to 0_updates_spamassassin_org.cf. This would not only fix the current issue with the sought rules, it would also avoid future problems like this. -- Bowie
Re: Sought rules
Karsten Bräckelmann guent...@rudersport.de wrote in message news:1307971023.4766.8.camel@monkey... On Mon, 2011-06-13 at 13:21 +0200, Jezz wrote: Yes, works. Regardless of using symlinks, a copy of the cf file, or include'ing it from another config file -- the target will be read again. But don't just take my word for it -- see for yourself! spamassassin --lint -D config Looking at the output in the attached file, I can see the 'sought-rules.cf' file, which I created inside my 'rules' directory, there on line 20. It's getting read *after* the files inside the default_rules directory (lines 7-11), which is good. What's confusing me is that lines 21 onwards show the individual .cf files getting loaded from inside each of the channel subdirectories in default_rules. And this is *after* my sought-rules.cf file gets loaded. So does that mean the stock rules are still overriding the sought rules? Or am I misinterpreting the output here? Have a close look at the output again. In particular search for all lines containing sought. You'll see the actual sought channel's contents being loaded -- twice. Right before the stock rules, and again as the very last cf files being read. Does that answer the question? ;) Oh yeah, look at that - silly me! **slaps palm on forehead** :)
Re: Sought rules
On 6/11/2011 10:03 AM, Justin Mason wrote: guys -- I'm going to make the whole question moot (in trunk at least) -- the only reason SOUGHT and SOUGHT_FRAUD were being checked in there was to make their accuracy visible in ruleqa. It's been months since I've looked at that, so it's needless. I'll remove them from svn asap. --j. WAIT!!! Wouldn't this remove our ability to check for false positives of your patterns against the much larger ham collection of nightly masscheck? I wouldn't be concerned about this if there were a way to collaborate on feeding more ham into SOUGHT's safety check corpus, but when I asked about this earlier you seemed hesitant. Warren
Re: Sought rules
On 6/12/2011 12:32 AM, Warren Togami Jr. wrote: On 6/11/2011 10:03 AM, Justin Mason wrote: guys -- I'm going to make the whole question moot (in trunk at least) -- the only reason SOUGHT and SOUGHT_FRAUD were being checked in there was to make their accuracy visible in ruleqa. It's been months since I've looked at that, so it's needless. I'll remove them from svn asap. --j. WAIT!!! Wouldn't this remove our ability to check for false positives of your patterns against the much larger ham collection of nightly masscheck? The alternative is to filter SOUGHT from the sa-update rule updates with a script, but still allow it in the nightly masschecks. Testing sought in nightly masschecks has been useful to occasionally find obvious SOUGHT problems, or sometimes to locate spam that was misplaced in the ham folder. Warren
Re: Sought rules
On Sunday, June 12, 2011, Warren Togami Jr. wtog...@gmail.com wrote: On 6/12/2011 12:32 AM, Warren Togami Jr. wrote: On 6/11/2011 10:03 AM, Justin Mason wrote: guys -- I'm going to make the whole question moot (in trunk at least) -- the only reason SOUGHT and SOUGHT_FRAUD were being checked in there was to make their accuracy visible in ruleqa. It's been months since I've looked at that, so it's needless. I'll remove them from svn asap. --j. WAIT!!! Wouldn't this remove our ability to check for false positives of your patterns against the much larger ham collection of nightly masscheck? The alternative is to filter SOUGHT from the sa-update rule updates with a script, but still allow it in the nightly masschecks. Testing sought in nightly masschecks has been useful to occasionally find obvious SOUGHT problems, or sometimes to locate spam that was misplaced in the ham folder. Sure -- if that's preferable we can do that. We just need to be diligent about tflags Nopublish. Warren
Re: Sought rules
On 2011-06-11 3:38, Warren Togami Jr. wrote: On 6/10/2011 3:34 PM, John Hardin wrote: On Fri, 10 Jun 2011, Lawrence @ Rogers wrote: On 10/06/2011 10:24 PM, Warren Togami Jr. wrote: On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote: IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. It is not entirely clear to me, what exactly are you supposed to rename for the reorder hack? You have to do it every time you sa-update? Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting 20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the default and assumed older SA rules) solve this problem? Or symlinks from your local configs directory to the SOUGHT channel directory files. That would probably be easier to not forget about when things get fixed. Is Lawrence's suggestion something we can do upstream to fix this problem? Alternatively, I think it is a mistake for us to ship SOUGHT rules at all in the standard sa-update channel. That is, unless we plan on updating the patterns and scores of SOUGHT on a daily basis. I highly doubt we will do that. Agreed, I'm +1 with removing SOUGHT rules from mainstream sa update channel. and keep thems separate.
Re: Sought rules
Wait a sec, I'm confused about this. JM_SOUGHT_2 hitting on every legit Facebook message on dev@ list February 17th 2011. If the SOUGHT channel was being overridden by the sa-update rules, how would this problem appear from the SOUGHT channel? Doesn't this suggest that spamassassin was successfully using the SOUGHT channel? (I still agree we should remove the static SOUGHT from the sa-update rules.) Warren
Re: Sought rules
On 6/10/11 9:56 PM, Karsten Bräckelmann wrote:
spamassassin -D config --lint 21 | less
so, one MORE option, we don't need to add the symlink to crontab?
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/sought_rules_yerp_org.cf
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/updates_spamassassin_org.cf
Jun 11 06:39:13.420 [71425] dbg: config: using
/usr/local/etc/mail/spamassassin for site rules dir
we could put it into out ../etc/mail/spamassassin dir?
to summarize:
On 6/10/11 1:14 PM, Karsten Bräckelmann wrote:
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
(or freebsd, your MMV)
cd ../updates/spamassassin_org.cf (or ../etc/mail/spamassassin)
ln -s /var/db/spamassassin/{ver}/sought_rules_yerp_org.cf
/var/db/spamassassin/{ver}/updates_spamassassin_org.cf/zzz_sought.cf
right? scores are ok now?
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
__
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
__
Re: Sought rules
On 6/11/11 6:45 AM, Michael Scheidell wrote:
On 6/10/11 9:56 PM, Karsten Bräckelmann wrote:
spamassassin -D config --lint 21 | less
so, one MORE option, we don't need to add the symlink to crontab?
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/sought_rules_yerp_org.cf
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/updates_spamassassin_org.cf
Jun 11 06:39:13.420 [71425] dbg: config: using
/usr/local/etc/mail/spamassassin for site rules dir
we could put it into out ../etc/mail/spamassassin dir?
to summarize:
On 6/10/11 1:14 PM, Karsten Bräckelmann wrote:
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
(ie directory?)
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
(or freebsd, your MMV)
cd ../updates/spamassassin_org.cf (or ../etc/mail/spamassassin)
ln -s /var/db/spamassassin/{ver}/sought_rules_yerp_org.cf
/var/db/spamassassin/{ver}/updates_spamassassin_org.cf/zzz_sought.cf
no, because (at least on freebsd) you can't symlink a file to a directory.
ln:
/var/db/spamassassin/3.003001/updates_spamassassin_org.cf/zzz_sought.cf:
Not a directory
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
__
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
__
Re: Sought rules
On Sat, 2011-06-11 at 06:45 -0400, Michael Scheidell wrote:
On 6/10/11 9:56 PM, Karsten Bräckelmann wrote:
spamassassin -D config --lint 21 | less
so, one MORE option, we don't need to add the symlink to crontab?
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/sought_rules_yerp_org.cf
Jun 11 06:39:13.419 [71425] dbg: config: read file
/var/db/spamassassin/3.003001/updates_spamassassin_org.cf
Jun 11 06:39:13.420 [71425] dbg: config: using
/usr/local/etc/mail/spamassassin for site rules dir
we could put it into out ../etc/mail/spamassassin dir?
to summarize:
On 6/10/11 1:14 PM, Karsten Bräckelmann wrote:
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
(or freebsd, your MMV)
cd ../updates/spamassassin_org.cf (or ../etc/mail/spamassassin)
ln -s /var/db/spamassassin/{ver}/sought_rules_yerp_org.cf
/var/db/spamassassin/{ver}/updates_spamassassin_org.cf/zzz_sought.cf
right? scores are ok now?
OK - Forgive my ignorance, I just want to be sure about this...
On my F15 system, in my /var/lib/spamassassin/3.003002/ directory I have
the following:
# ls -l /var/lib/spamassassin/3.003002/
drwxrwxr-x. 2 root root 4096 Jun 11 12:19 sought_rules_yerp_org
-rw-rw-r--. 1 root root 120 Jun 11 12:19 sought_rules_yerp_org.cf
drwxr-xr-x. 2 root root 4096 Jun 11 12:17 updates_spamassassin_org
-rw-r--r--. 1 root root 2599 Jun 11 12:17 updates_spamassassin_org.cf
Inside sought_rules_yerp_org.cf is the following:
# cat /var/lib/spamassassin/3.003002/sought_rules_yerp_org.cf
# UPDATE version 3301124446
include sought_rules_yerp_org/20_sought.cf
include sought_rules_yerp_org/20_sought_fraud.cf
I create a symlink of the sought_rules cf file to a file called
zzz.something.cf
ln -s sought_rules_yerp_org.cf zzz_sought_rules_yerp_org.cf
I now have this:
drwxrwxr-x. 2 root root 4096 Jun 11 12:19 sought_rules_yerp_org
-rw-rw-r--. 1 root root 120 Jun 11 12:19 sought_rules_yerp_org.cf
drwxr-xr-x. 2 root root 4096 Jun 11 12:17 updates_spamassassin_org
-rw-r--r--. 1 root root 2599 Jun 11 12:17 updates_spamassassin_org.cf
lrwxrwxrwx. 1 root root 24 Jun 11 12:40 zzz_sought_rules_yerp_org.cf -
sought_rules_yerp_org.cf
I am now sorted - Is that right?
signature.asc
Description: This is a digitally signed message part
Re: Sought rules
On Sat, 11 Jun 2011, Michael Scheidell wrote: On 6/10/11 9:56 PM, Karsten Bräckelmann wrote: spamassassin -D config --lint 21 | less so, one MORE option, we don't need to add the symlink to crontab? Jun 11 06:39:13.419 [71425] dbg: config: read file /var/db/spamassassin/3.003001/sought_rules_yerp_org.cf Jun 11 06:39:13.419 [71425] dbg: config: read file /var/db/spamassassin/3.003001/updates_spamassassin_org.cf Jun 11 06:39:13.420 [71425] dbg: config: using /usr/local/etc/mail/spamassassin for site rules dir we could put it into out ../etc/mail/spamassassin dir? That's what I suggested. Putting it into the local customizations dir keeps it visible. If the symlink is buried down under /var/mumble then you may forget about it and not remove it once we get the sa-update process straightened out. right? scores are ok now? This isn't to fix the scores, it's to ensure that you're using the latest generated SOUGHT rules. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Our government should bear in mind the fact that the American Revolution was touched off by the then-current government attempting to confiscate firearms from the people. --- 184 days since the first successful private orbital launch (SpaceX)
Re: Sought rules
Karsten Bräckelmann guent...@rudersport.de wrote in message
news:1307726044.7307.29.camel@monkey...
On Fri, 2011-06-10 at 18:07 +0200, Jezz wrote:
I recently upgraded SpamAssassin from 3.2.5 to 3.3.1, and I discovered
that
the JM_SOUGHT_FRAUD_x rules are now included within the official ruleset,
within the 72_active.cf file.
However, as far as I can tell, these rules seem to be different to the
same-named rules that are within the latest copy of 20_sought_fraud.cf
which
is downloaded from the sought.rules.yerp.org channel. Which is to say,
the
contents of the 'meta' rule is different between these two files. My
guess
is that the version of these rules contained inside 72_active.cf is
perhaps
an older version than the ones inside 20_sought_fraud.cf. Is that the
case?
Yes. Well, currently at least.
The Sought rule-set is re-generated multiple times a day, which is what
you get from the dedicated sa-update channel. With 3.3.x the plan is, to
frequently perform mass-checks and re-scoring, distributed via the
regular channel. This includes a recent snapshot of the Sought rules, so
the dedicated channel is almost obsolete. Alas, the re-scoring currently
does not happen as we plan for.
What's more, I also see that these three FRAUD rules all have a score of
0
inside 50_scores.cf. My first question then is why they are zeroed out?
It's a safety default. If you want the FRAUD subset, assign them a score
in your local config.
Secondly, I'm wondering how I can enable these rules again if I do want
to
use them. In other words, if I want to use the latest version contained
within 20_sought_fraud.cf - I don't see how this could be possible.
Certainly I can add 'score' values for those three rules into my local.cf
file, which will override the zeroed-out scores in 50_scores.cf file.
However, because 72_active.cf comes numerically after 20_sought_fraud.cf,
that means the (assumedly older) FRAUD rules inside 72_active.cf will
override the (assumedly newer) FRAUD rules inside 20_sought_fraud.cf -
right? If so, there's no way for me to use the rules from
20_sought_fraud.cf
at all?
The score in your local config will take precedence, thus enabling the
rules.
You are generally correct about the numerical (actually lexical) order,
though it doesn't apply to the files you are talking about. The
mentioned 72_active and 20_sought are in different sa-update channels.
Now, the bad thing about this is that updates_spamassassin_org.cf is
lexically *after* sought_rules_yerp_org.cf in your rule update dir.
Which means the more recent rules in the dedicated Sought channel are
overwritten by the stock rules...
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
--
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;il;i++){ i%8?
c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){
putchar(t[s]);h=m;s=0; }}}
Thanks Karsten, and everyone else - that's very helpful!
So here's the thing: I'm actually running SA on Windows, via the MDaemon
mail server. So I can't so easily create a symlink as you've described.
However I think I can do something similar - let me know if this sounds
right:
Currently I've got the default rules located in a directory called
/default_rules. Inside that directory is the 'sought_rules_yerp_org' and
'updates_spamassassin_org' sub-directories, each containing their respective
.cf files, and there is also the sought_rules_yerp_org.cf and
updates_spamassassin_org.cf files with their 'include' entries inside,
pointing to the .cf files inside their sub-directories.
Then I also have a separate directory called /rules which is parallel to
/default_rules. In the /rules directory goes my local.cf file and my other
personal .cf files that I've created for myself.
The problem with your idea of a symlink or similar is that I can't change
anything inside the /default_rules directory, because MDaemon wipes and
replaces all the files and folders inside that directory each time I install
a new version of MDaemon - much to my annoyance. However, MDaemon doesn't
touch the contents of the /rules directory, so I can do whatever I want in
there.
So currently I'm thinking about this plan: I could create a file called
'zz_sought.cf' and place it into my /rules directory where it's safe. AFAIK
the files in here would be parsed *after* the files inside the
/default_rules directory - at least that would seem logical to me.
And inside this zz_sought.cf file I can include one line like this:
include C:\PATH\TO\default_rules\sought_rules_yerp_org.cf
...which is pointing to the .cf file from the SOUGHT channel, which itself
contains two 'include' lines pointing to 20_sought.cf
READ THIS Re: Sought rules
On 6/10/2011 11:13 PM, Warren Togami Jr. wrote: Wait a sec, I'm confused about this. JM_SOUGHT_2 hitting on every legit Facebook message on dev@ list February 17th 2011. If the SOUGHT channel was being overridden by the sa-update rules, how would this problem appear from the SOUGHT channel? Doesn't this suggest that spamassassin was successfully using the SOUGHT channel? (I still agree we should remove the static SOUGHT from the sa-update rules.) Warren NOTE: I'm skeptical that this bug is effecting us on Linux. I am not using a re-order hack and yet SOUGHT seems to be changing its behavior on a daily basis. Warren
Re: Sought rules
On Sat, 2011-06-11 at 06:45 -0400, Michael Scheidell wrote:
On 6/10/11 1:14 PM, Karsten Bräckelmann wrote:
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
ln -s /var/db/spamassassin/{ver}/sought_rules_yerp_org.cf
/var/db/spamassassin/{ver}/updates_spamassassin_org.cf/zzz_sought.cf
^^^
That's a file, not a directory.
For each update channel, there is an appropriately named directory and a
cf file. The per-channel sub-directories are not parsed for cf files.
The cf files in the updatedir itself are used -- and they consist of a
bunch of include directives, pulling in their channels contents.
# cd /var/lib/spamassassin/$VERSION
# ln -s sought_rules_yerp_org.cf z-INCLUDE-LATE.cf
See 'man sa-update' for the actual updatedir used by your OS / distro.
As a result, you'll get something like this.
drwxr-xr-x sought_rules_yerp_org/
-rw-r--r-- sought_rules_yerp_org.cf
drwxr-xr-x updates_spamassassin_org/
-rw-r--r-- updates_spamassassin_org.cf
lrwxrwxrwx z-INCLUDE-LATE.cf - sought_rules_yerp_org.cf
To verify the SOUGHT rules are indeed included a second time, after the
stock rule-set, have a look at the debug output.
$ spamassassin --lint -D config 21 | grep 'read file /var/' | less
You'll see the per-channel cf files for sought, stock, and the symlink.
Followed by their respective channel contents, included from these
files. So you'll see sought actually being read twice, before and after
stock.
The symlink needs to be created exactly once, after each SA upgrade,
since the updatedir is versioned.
Also, it should be possible to symlink from your site config dir, or
even use an include statement in a site config cf file. Didn't test
that, though. However, this too needs to be updated after each SA
upgrade.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Fri, 2011-06-10 at 23:13 -1000, Warren Togami Jr. wrote:
Wait a sec, I'm confused about this. JM_SOUGHT_2 hitting on every
legit Facebook message on dev@ list February 17th 2011. If the SOUGHT
channel was being overridden by the sa-update rules, how would this
problem appear from the SOUGHT channel? Doesn't this suggest that
spamassassin was successfully using the SOUGHT channel?
Yes, and no. grep for SOUGHT in the stock rules...
The stock rule-set has a snapshot of the SOUGHT_FRAUD patterns, they do
NOT have the SOUGHT patterns.
And, well... READ THIS instead. ;)
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
guys -- I'm going to make the whole question moot (in trunk at least)
-- the only reason SOUGHT and SOUGHT_FRAUD were being checked in there
was to make their accuracy visible in ruleqa. It's been months since
I've looked at that, so it's needless. I'll remove them from svn
asap.
--j.
2011/6/11 Karsten Bräckelmann guent...@rudersport.de:
On Fri, 2011-06-10 at 23:13 -1000, Warren Togami Jr. wrote:
Wait a sec, I'm confused about this. JM_SOUGHT_2 hitting on every
legit Facebook message on dev@ list February 17th 2011. If the SOUGHT
channel was being overridden by the sa-update rules, how would this
problem appear from the SOUGHT channel? Doesn't this suggest that
spamassassin was successfully using the SOUGHT channel?
Yes, and no. grep for SOUGHT in the stock rules...
The stock rule-set has a snapshot of the SOUGHT_FRAUD patterns, they do
NOT have the SOUGHT patterns.
And, well... READ THIS instead. ;)
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Sat, 2011-06-11 at 20:01 +0200, Jezz wrote:
So currently I'm thinking about this plan: I could create a file called
'zz_sought.cf' and place it into my /rules directory where it's safe. AFAIK
the files in here would be parsed *after* the files inside the
/default_rules directory - at least that would seem logical to me.
And inside this zz_sought.cf file I can include one line like this:
include C:\PATH\TO\default_rules\sought_rules_yerp_org.cf
...which is pointing to the .cf file from the SOUGHT channel, which itself
contains two 'include' lines pointing to 20_sought.cf and
20_sought_fraud.cf.
Yes, include directives may be nested. Just tested this. Hey, you could
have tested it, too. ;)
Also, since your site config is read after the default config, there is
no need for the z-prefix. Just have a file named sought.cf including the
Sought channel cf, which in turn includes the channel's contents...
Secondly, I now essentially have two files containing 'include' lines which
point to the two SOUGHT .cf files. First (lexically) is
sought_rules_yerp_org.cf. Then comes updates_spamassassin_org.cf which
overwrites the SOUGHT channel entries. Then after that we have my
zz_sought.cf file being parsed last, pointing back to the SOUGHT channel
again. So is there any issue or problem with having two files
(sought_rules_yerp_org.cf and zz_sought.cf) pointing to the two actual
SOUGHT .cf files? I'm guessing not, but I want to make sure.
Yes, works. Regardless of using symlinks, a copy of the cf file, or
include'ing it from another config file -- the target will be read
again.
But don't just take my word for it -- see for yourself!
spamassassin --lint -D config
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Sat, 2011-06-11 at 12:50 +0100, Arthur Dent wrote:
drwxrwxr-x. 2 root root 4096 Jun 11 12:19 sought_rules_yerp_org
-rw-rw-r--. 1 root root 120 Jun 11 12:19 sought_rules_yerp_org.cf
drwxr-xr-x. 2 root root 4096 Jun 11 12:17 updates_spamassassin_org
-rw-r--r--. 1 root root 2599 Jun 11 12:17 updates_spamassassin_org.cf
lrwxrwxrwx. 1 root root 24 Jun 11 12:40 zzz_sought_rules_yerp_org.cf -
sought_rules_yerp_org.cf
I am now sorted - Is that right?
Yes.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Fri, 2011-06-10 at 15:38 -1000, Warren Togami Jr. wrote:
Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting
20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the
default and assumed older SA rules) solve this problem?
Is Lawrence's suggestion something we can do upstream to fix this problem?
No. Please carefully re-read all my previous posts. As I already
explained, the names (and numbers) are meaningless in this context,
because they are in different directories.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Sat, 11 Jun 2011, Jezz wrote: So here's the thing: I'm actually running SA on Windows, via the MDaemon mail server. So I can't so easily create a symlink as you've described. http://lifehacker.com/5496652/how-to-use-symlinks-in-windows But then, this is just FYI as Justin is fixing the problem... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The third basic rule of firearms safety: Keep your booger hook off the bang switch! --- 184 days since the first successful private orbital launch (SpaceX)
Sought rules
Hi all, I recently upgraded SpamAssassin from 3.2.5 to 3.3.1, and I discovered that the JM_SOUGHT_FRAUD_x rules are now included within the official ruleset, within the 72_active.cf file. However, as far as I can tell, these rules seem to be different to the same-named rules that are within the latest copy of 20_sought_fraud.cf which is downloaded from the sought.rules.yerp.org channel. Which is to say, the contents of the 'meta' rule is different between these two files. My guess is that the version of these rules contained inside 72_active.cf is perhaps an older version than the ones inside 20_sought_fraud.cf. Is that the case? What's more, I also see that these three FRAUD rules all have a score of 0 inside 50_scores.cf. My first question then is why they are zeroed out? Secondly, I'm wondering how I can enable these rules again if I do want to use them. In other words, if I want to use the latest version contained within 20_sought_fraud.cf - I don't see how this could be possible. Certainly I can add 'score' values for those three rules into my local.cf file, which will override the zeroed-out scores in 50_scores.cf file. However, because 72_active.cf comes numerically after 20_sought_fraud.cf, that means the (assumedly older) FRAUD rules inside 72_active.cf will override the (assumedly newer) FRAUD rules inside 20_sought_fraud.cf - right? If so, there's no way for me to use the rules from 20_sought_fraud.cf at all? I hope that makes sense, and sorry if I'm completely overlooking something here. - Jezz
Re: Sought rules
On Fri, 2011-06-10 at 18:07 +0200, Jezz wrote:
I recently upgraded SpamAssassin from 3.2.5 to 3.3.1, and I discovered that
the JM_SOUGHT_FRAUD_x rules are now included within the official ruleset,
within the 72_active.cf file.
However, as far as I can tell, these rules seem to be different to the
same-named rules that are within the latest copy of 20_sought_fraud.cf which
is downloaded from the sought.rules.yerp.org channel. Which is to say, the
contents of the 'meta' rule is different between these two files. My guess
is that the version of these rules contained inside 72_active.cf is perhaps
an older version than the ones inside 20_sought_fraud.cf. Is that the case?
Yes. Well, currently at least.
The Sought rule-set is re-generated multiple times a day, which is what
you get from the dedicated sa-update channel. With 3.3.x the plan is, to
frequently perform mass-checks and re-scoring, distributed via the
regular channel. This includes a recent snapshot of the Sought rules, so
the dedicated channel is almost obsolete. Alas, the re-scoring currently
does not happen as we plan for.
What's more, I also see that these three FRAUD rules all have a score of 0
inside 50_scores.cf. My first question then is why they are zeroed out?
It's a safety default. If you want the FRAUD subset, assign them a score
in your local config.
Secondly, I'm wondering how I can enable these rules again if I do want to
use them. In other words, if I want to use the latest version contained
within 20_sought_fraud.cf - I don't see how this could be possible.
Certainly I can add 'score' values for those three rules into my local.cf
file, which will override the zeroed-out scores in 50_scores.cf file.
However, because 72_active.cf comes numerically after 20_sought_fraud.cf,
that means the (assumedly older) FRAUD rules inside 72_active.cf will
override the (assumedly newer) FRAUD rules inside 20_sought_fraud.cf -
right? If so, there's no way for me to use the rules from 20_sought_fraud.cf
at all?
The score in your local config will take precedence, thus enabling the
rules.
You are generally correct about the numerical (actually lexical) order,
though it doesn't apply to the files you are talking about. The
mentioned 72_active and 20_sought are in different sa-update channels.
Now, the bad thing about this is that updates_spamassassin_org.cf is
lexically *after* sought_rules_yerp_org.cf in your rule update dir.
Which means the more recent rules in the dedicated Sought channel are
overwritten by the stock rules...
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On 6/10/2011 7:14 AM, Karsten Bräckelmann wrote: You are generally correct about the numerical (actually lexical) order, though it doesn't apply to the files you are talking about. The mentioned 72_active and 20_sought are in different sa-update channels. Now, the bad thing about this is that updates_spamassassin_org.cf is lexically *after* sought_rules_yerp_org.cf in your rule update dir. Which means the more recent rules in the dedicated Sought channel are overwritten by the stock rules... This merely requires a re-ordering hack, though. A symlink zzz_sought.cf in your rule updates dir, pointing at the channel generated cf should do. These channel cf files only hold include statements, to pull in the actual cf files in the per-channel dir. Without a re-ordering hack, does this mean mean that essentially EVERYONE is using SOUGHT wrong? This is a bit worrisome. Warren
Re: Sought rules
On Fri, 2011-06-10 at 11:19 -1000, Warren Togami Jr. wrote:
On 6/10/2011 7:14 AM, Karsten Bräckelmann wrote:
Now, the bad thing about this is that updates_spamassassin_org.cf is
lexically *after* sought_rules_yerp_org.cf in your rule update dir.
Which means the more recent rules in the dedicated Sought channel are
overwritten by the stock rules...
This merely requires a re-ordering hack, though. A symlink zzz_sought.cf
in your rule updates dir, pointing at the channel generated cf should
do. These channel cf files only hold include statements, to pull in the
actual cf files in the per-channel dir.
Without a re-ordering hack, does this mean mean that essentially
EVERYONE is using SOUGHT wrong? This is a bit worrisome.
You'd be closer with a lower-cased everyone.
This is true since 3.3.0, since the SOUGHT rules got included into the
stock rule-set. It does not affect 3.2.x users.
It does not affect those *not* using the third-party sought channel, but
using the version in the main channel. Granted, those got some rather
stale patterns currently, and are unlikely to hit much recent spam, but
that's a different topic.
It *does* affect anyone using the third-party sought channel explicitly
to get frequent updates of fresh spam-phrase patterns the sought process
extracts. Basically, they just don't get what they wanted, unless...
Unless they participated in the previous thread discussing this issue,
or at least where lurking one way or the other. This topic came up
before, I just summarized the whole thread in my previous answer. :)
While I do agree this is an issue -- at the very least, all third-party
sought channel docs should include that note -- I do not agree that this
is worrisome. The negative impact basically boils down to the channel
does not work.
Similar to not running sa-update for the main channel. Simply no update.
No harm otherwise.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On 6/10/11 5:49 PM, Karsten Bräckelmann wrote: While I do agree this is an issue -- at the very least, all third-party sought channel docs should include that note -- I do not agree that this is worrisome. The negative impact basically boils down to the channel does not work. so, the 'best practice' is to what? symlink/reorder hack? or stop running sought channels, and add your own scores? Similar to not running sa-update for the main channel. Simply no update. No harm otherwise. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: Sought rules
On Fri, 2011-06-10 at 19:32 -0400, Michael Scheidell wrote:
On 6/10/11 5:49 PM, Karsten Bräckelmann wrote:
While I do agree this is an issue -- at the very least, all third-party
sought channel docs should include that note -- I do not agree that this
is worrisome. The negative impact basically boils down to the channel
does not work.
so, the 'best practice' is to what?
symlink/reorder hack? or stop running sought channels, and add your own
scores?
Adding or adjusting the scores might be a good idea in either case.
Other than that...
Until the frequent re-scoring and stock rules updates are working
properly, you will have to use the dedicated channel, if you want the
SOUGHT rules. And even after that, if you want the freshest patterns,
you still need the sought channel -- unless stock rules are updated once
a day.
IFF you use the sought channel with SA 3.3.x, you will need the reorder
hack to bend the alphabet.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote: IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. It is not entirely clear to me, what exactly are you supposed to rename for the reorder hack? You have to do it every time you sa-update? Warren
Re: Sought rules
On 10/06/2011 10:24 PM, Warren Togami Jr. wrote: On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote: IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. It is not entirely clear to me, what exactly are you supposed to rename for the reorder hack? You have to do it every time you sa-update? Warren Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting 20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the default and assumed older SA rules) solve this problem? Regards, Lawrence
Re: Sought rules
On Fri, 10 Jun 2011, Lawrence @ Rogers wrote: On 10/06/2011 10:24 PM, Warren Togami Jr. wrote: On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote: IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. It is not entirely clear to me, what exactly are you supposed to rename for the reorder hack? You have to do it every time you sa-update? Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting 20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the default and assumed older SA rules) solve this problem? Or symlinks from your local configs directory to the SOUGHT channel directory files. That would probably be easier to not forget about when things get fixed. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It is not the place of government to make right every tragedy and woe that befalls every resident of the nation. --- 183 days since the first successful private orbital launch (SpaceX)
Re: Sought rules
On 6/10/2011 3:34 PM, John Hardin wrote: On Fri, 10 Jun 2011, Lawrence @ Rogers wrote: On 10/06/2011 10:24 PM, Warren Togami Jr. wrote: On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote: IFF you use the sought channel with SA 3.3.x, you will need the reorder hack to bend the alphabet. It is not entirely clear to me, what exactly are you supposed to rename for the reorder hack? You have to do it every time you sa-update? Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting 20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the default and assumed older SA rules) solve this problem? Or symlinks from your local configs directory to the SOUGHT channel directory files. That would probably be easier to not forget about when things get fixed. Is Lawrence's suggestion something we can do upstream to fix this problem? Alternatively, I think it is a mistake for us to ship SOUGHT rules at all in the standard sa-update channel. That is, unless we plan on updating the patterns and scores of SOUGHT on a daily basis. I highly doubt we will do that. Warren Togami war...@togami.com
Re: Sought rules
On Fri, 2011-06-10 at 14:54 -1000, Warren Togami Jr. wrote:
On 6/10/2011 2:01 PM, Karsten Bräckelmann wrote:
IFF you use the sought channel with SA 3.3.x, you will need the reorder
hack to bend the alphabet.
It is not entirely clear to me, what exactly are you supposed to rename
for the reorder hack? You have to do it every time you sa-update?
No, only once.
The problem is, that cf files are parsed in lexical order per directory.
That means that 10_default comes before 72_active. However, have a look
at your updates conf dir (see 'man spamassassin' or 'man sa-update').
There's one directory per channel. And one identically named cf file per
channel. The dirs are not parsed recursively (and it wouldn't matter),
but the cf files are. THEIR order matters. Alphabetically.
Now since s is before u in any alphabet I've ever used, the sought
channel's cf file is parsed before the stock updates cf file. Both
consist of a bunch of include directives, actually loading the rules' cf
files.
To ensure some channel to be parsed after the general updates channel,
because the channel's content is supposed to overwrite stock, it must
begin with a char that is after u.
Thus, a single symlink should do. Once. Also see the output of
spamassassin -D config --lint 21 | less
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought rules
On Fri, 2011-06-10 at 22:40 -0230, Lawrence @ Rogers wrote:
Would renaming 20_sought_fraud.cf to 99_sought_fraud.cf, putting
20_sought_fraud.cf (from the yelp.org channel) after 72_active.cf (the
default and assumed older SA rules) solve this problem?
No, because they are in sub-directories. Not parsed directly, but
included. The order of the cf files including them matters. See my
previous post, as well as the older ones.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: What happened to SOUGHT rules' server?
On 2010/03/16 5:03 PM, Karsten Bräckelmann wrote: How is this messing you up? This should not affect any of your other channels. The only effect is that the sought rules don't get updated. I'm not sure how everyone else is doing it, but my script checks for updates using --channelfile, then runs sa-compile if sa-update returns 0. If a channel fails, sa-update returns something other than 0. Sure, my old rules are intact and the server continues to run normally, but I'm not getting the benefit of updates in other channels. This sounds like an improvement to sa-compile would be beneficial, so as to distinguish 'some updates available' from 'none' and 'all ok, updated'. Please open a feature request. s/compile/update/# :) In order to properly open a feature request, I'd like to get a better idea where you're going with this. It seems to me that a new exit code from sa-update would be more appropriate than running sa-compile every time just in case. Maybe I misunderstand? Yup, seems that is it. There are only all-or-nothing exit codes (0 and 4 respectively) in this scenario. It looks like the SOUGHT server is having issues again, so Bug 6380 is again relevant. Does anyone know the status of the SOUGHT server or if any work has been done on the bug? https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380 -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: What happened to SOUGHT rules' server?
On Thu, 2010-10-14 at 12:30 -0400, Jason Bertoch wrote:
On 2010/03/16 5:03 PM, Karsten Bräckelmann wrote:
In order to properly open a feature request, I'd like to get a better
idea where you're going with this. It seems to me that a new exit code
from sa-update would be more appropriate than running sa-compile every
time just in case. Maybe I misunderstand?
Yup, seems that is it. There are only all-or-nothing exit codes (0 and 4
respectively) in this scenario.
It looks like the SOUGHT server is having issues again, so Bug 6380 is
again relevant. Does anyone know the status of the SOUGHT server or if
*Had* have issues today, for about 10 hours +/- 2 according to my logs.
Granted, you sent this shortly before the issue has been resolved. ;)
I can confirm there have been issues with a missing update tarball, the
server appeared to be responsive all the while. I also can confirm
operation is back to normal since a couple hours ago.
any work has been done on the bug?
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
According to the bug, quite obviously, no one has been working on it.
Until your patch just today. Thanks!
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: What happened to SOUGHT rules' server?
On 10/14/2010 5:30 PM, Karsten Bräckelmann wrote: any work has been done on the bug? https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380 According to the bug, quite obviously, no one has been working on it. Until your patch just today. Thanks! Yes, I decided this was a logic issue and probably required little knowledge of perl, in which I have none. In the end, the change was trivial, to me at least. We'll see what the real devs think, though. /Jason
Re: Sought Rules Back?
On 2010/02/01 10:30 AM, Mark Martinec wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up. Btw, I prefer to avoid them monopolizing
the score when more than one hits:
score JM_SOUGHT_FRAUD_1 0.1
score JM_SOUGHT_FRAUD_2 0.1
score JM_SOUGHT_FRAUD_3 0.1
meta JM_SOUGHT_FRAUD_ANY JM_SOUGHT_FRAUD_1 || JM_SOUGHT_FRAUD_2 ||
JM_SOUGHT_FRAUD_3
score JM_SOUGHT_FRAUD_ANY 3.0
Mark
Bug 6155 is now closed, but the SOUGHT rules still have a score of 0.
Anyone have an idea on when these rules will be activated again?
--
/Jason
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Sought Rules Back?
On Mon, 2010-03-29 at 16:05 -0400, Jason Bertoch wrote:
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up. Btw, I prefer to avoid them monopolizing
the score when more than one hits:
score JM_SOUGHT_FRAUD_1 0.1
score JM_SOUGHT_FRAUD_2 0.1
score JM_SOUGHT_FRAUD_3 0.1
meta JM_SOUGHT_FRAUD_ANY JM_SOUGHT_FRAUD_1 || JM_SOUGHT_FRAUD_2 ||
JM_SOUGHT_FRAUD_3
score JM_SOUGHT_FRAUD_ANY 3.0
Bug 6155 is now closed, but the SOUGHT rules still have a score of 0.
Anyone have an idea on when these rules will be activated again?
The zero score request applies *only* to the SOUGHT_FRAUD sub-set. It
does *not* affect SOUGHT. Those do have scores according to the GA run.
Also, this applies *only* to 3.3, where this moved into stock. Again,
the dedicated sa-update channel (also suitable for 3.2) is *not*
affected and still has the same scores it used to.
Now, regarding activating again -- just do. They are merely disabled by
default (in 3.3 stock). You can activate them on your site, simply by
dropping score lines into your local config.
guenther
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: What happened to SOUGHT rules' server?
On Monday 15 March 2010, Daryl C. W. O'Shea wrote: On 15/03/2010 11:07 PM, j wrote: I've been having the same problem from several locations/ISPs, since mid-Saturday. 500 Can't connect to yerp.org:80 (connect: timeout) Dave Anyone figure this out? I have received the same yerp.org down errors and it's screwing up my SA royally. I guess this is what we get when we rely on external sources to help us at no charge.. :( Just so I understand your use case, so we can improve sa-update... how is it that a failing channel is royally screwing up your SA? Thanks! Daryl FWIW, my weekly sa-update from yerp.org also failed. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I consider the day misspent that I am not either charged with a crime, or arrested for one. -- Ratsy Tourbillon
Re: What happened to SOUGHT rules' server?
j wrote: I've been having the same problem from several locations/ISPs, since mid-Saturday. 500 Can't connect to yerp.org:80 (connect: timeout) Dave Anyone figure this out? I have received the same yerp.org down errors and it's screwing up my SA royally. I guess this is what we get when we rely on external sources to help us at no charge.. :( It appears to be having intermittent problems. It has only failed 2 out of the last 7 times I've checked it. How is this messing you up? This should not affect any of your other channels. The only effect is that the sought rules don't get updated. -- Bowie
Re: What happened to SOUGHT rules' server?
On 2010/03/16 9:30 AM, Bowie Bailey wrote: How is this messing you up? This should not affect any of your other channels. The only effect is that the sought rules don't get updated. I'm not sure how everyone else is doing it, but my script checks for updates using --channelfile, then runs sa-compile if sa-update returns 0. If a channel fails, sa-update returns something other than 0. Sure, my old rules are intact and the server continues to run normally, but I'm not getting the benefit of updates in other channels. Perhaps I should replace --channelfile with a loop instead, though it seems to me that caused other problems. -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: What happened to SOUGHT rules' server?
On Tuesday 16 March 2010 19:37:02 Jason Bertoch wrote: On 2010/03/16 9:30 AM, Bowie Bailey wrote: How is this messing you up? This should not affect any of your other channels. The only effect is that the sought rules don't get updated. I'm not sure how everyone else is doing it, but my script checks for updates using --channelfile, then runs sa-compile if sa-update returns 0. If a channel fails, sa-update returns something other than 0. Sure, my old rules are intact and the server continues to run normally, but I'm not getting the benefit of updates in other channels. This sounds like an improvement to sa-compile would be beneficial, so as to distinguish 'some updates available' from 'none' and 'all ok, updated'. Please open a feature request. Mark
Re: What happened to SOUGHT rules' server?
On 2010/03/16 2:44 PM, Mark Martinec wrote: On Tuesday 16 March 2010 19:37:02 Jason Bertoch wrote: On 2010/03/16 9:30 AM, Bowie Bailey wrote: How is this messing you up? This should not affect any of your other channels. The only effect is that the sought rules don't get updated. I'm not sure how everyone else is doing it, but my script checks for updates using --channelfile, then runs sa-compile if sa-update returns 0. If a channel fails, sa-update returns something other than 0. Sure, my old rules are intact and the server continues to run normally, but I'm not getting the benefit of updates in other channels. This sounds like an improvement to sa-compile would be beneficial, so as to distinguish 'some updates available' from 'none' and 'all ok, updated'. Please open a feature request. Mark, In order to properly open a feature request, I'd like to get a better idea where you're going with this. It seems to me that a new exit code from sa-update would be more appropriate than running sa-compile every time just in case. Maybe I misunderstand? /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: What happened to SOUGHT rules' server?
Jason, In order to properly open a feature request, I'd like to get a better idea where you're going with this. It seems to me that a new exit code from sa-update would be more appropriate than running sa-compile every time just in case. Maybe I misunderstand? Yes, that's what I had in mind. Or a short and concise message written to stdout or stderr when a verbose option (-v) is used. One or the other or both, so as to make shell scripting easier for cases like you came across. I didn't consider it thoroughly, so this is just a suggestion that came up first to my head. Mark
Re: What happened to SOUGHT rules' server?
How is this messing you up? This should not affect any of your other
channels. The only effect is that the sought rules don't get updated.
I'm not sure how everyone else is doing it, but my script checks for
updates using --channelfile, then runs sa-compile if sa-update returns
0. If a channel fails, sa-update returns something other than 0. Sure,
my old rules are intact and the server continues to run normally, but
I'm not getting the benefit of updates in other channels.
This sounds like an improvement to sa-compile would be beneficial,
so as to distinguish 'some updates available' from 'none' and
'all ok, updated'. Please open a feature request.
s/compile/update/# :)
In order to properly open a feature request, I'd like to get a better
idea where you're going with this. It seems to me that a new exit code
from sa-update would be more appropriate than running sa-compile every
time just in case. Maybe I misunderstand?
Yup, seems that is it. There are only all-or-nothing exit codes (0 and 4
respectively) in this scenario.
However, not even close to royally screwing update, as per some
earlier comment.
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: What happened to SOUGHT rules' server?
I've been having the same problem from several locations/ISPs, since mid-Saturday. 500 Can't connect to yerp.org:80 (connect: timeout) Dave Anyone figure this out? I have received the same yerp.org down errors and it's screwing up my SA royally. I guess this is what we get when we rely on external sources to help us at no charge.. :(
Re: What happened to SOUGHT rules' server?
On 15/03/2010 11:07 PM, j wrote: I've been having the same problem from several locations/ISPs, since mid-Saturday. 500 Can't connect to yerp.org:80 (connect: timeout) Dave Anyone figure this out? I have received the same yerp.org down errors and it's screwing up my SA royally. I guess this is what we get when we rely on external sources to help us at no charge.. :( Just so I understand your use case, so we can improve sa-update... how is it that a failing channel is royally screwing up your SA? Thanks! Daryl
What happened to SOUGHT rules' server?
It seems that the yerp.org www server is irresponsive. To my knowledge, that server was hosting the sought.rules.yerp.org update channel. Anybody knows if it is a transient problem or if that channel moved elsewhere? Regards, Giampaolo
Re: What happened to SOUGHT rules' server?
Giampaolo Tomassoni a écrit : It seems that the yerp.org www server is irresponsive. To my knowledge, that server was hosting the sought.rules.yerp.org update channel. Anybody knows if it is a transient problem or if that channel moved elsewhere? it was working yesterday. most probably a transient problem.
Re: What happened to SOUGHT rules' server?
On Sun, Mar 14, 2010 at 3:13 AM, Giampaolo Tomassoni g.tomass...@libero.it wrote: It seems that the yerp.org www server is irresponsive. To my knowledge, that server was hosting the sought.rules.yerp.org update channel. Anybody knows if it is a transient problem or if that channel moved elsewhere? Regards, Giampaolo I've been having the same problem from several locations/ISPs, since mid-Saturday. 500 Can't connect to yerp.org:80 (connect: timeout) Dave
Re: Sought rules not doing so good
On Tue, Feb 2, 2010 at 18:21, Warren Togami wtog...@redhat.com wrote: On 02/02/2010 12:07 PM, Adam Katz wrote: That is quite different from our masscheck stats. Today's results at http://ruleqa.spamassassin.org/20100201/%2FJM_SOUGHT look like this: SPAM% HAM% S/O RANK SCORE NAME 9.8564 0.0042 1.000 0.94 0.01 T_JM_SOUGHT_3 8.1587 0.0068 0.999 0.93 0.01 T_JM_SOUGHT_2 11.6464 0.0289 0.998 0.89 0.01 T_JM_SOUGHT_1 0 0 0.500 0.48 0.00 JM_SOUGHT_FRAUD_1 0 0 0.500 0.48 0.00 JM_SOUGHT_FRAUD_2 0 0 0.500 0.48 0.00 JM_SOUGHT_FRAUD_3 FWIW the nightly masscheck is often very unbalanced especially on the spam side. Sometimes we have only 50k spam, sometimes over 500k spam. Some spam corpora contain a disproportionate amount of high scoring spam trap mail. I personally randomly filter out a large percentage of high scoring mail in an attempt to balance my spam corpus. But ultimately we need more masscheck participants to have better results. The corpus-quality for that masscheck doesn't look too bad though: http://ruleqa.spamassassin.org/20100201-r905213-n/T_JM_SOUGHT_1/detail?s_corpus=1#corpus -- --j.
Re: Sought rules not doing so good
On 02/03/2010 09:18 AM, Justin Mason wrote: The corpus-quality for that masscheck doesn't look too bad though: http://ruleqa.spamassassin.org/20100201-r905213-n/T_JM_SOUGHT_1/detail?s_corpus=1#corpus That day was fine. The weekly masscheck however had only 50k spam. Warren
RE: Sought rules not doing so good
I understand the problem with the stats program and FP/FN, but the last time I looked at the stats for sought (which was admittedly quite a while ago), a couple of the rules were showing in my top 20 spam rules. Now I have to go all the way down to 111 to find the first one. I would like to confirm bowie's point. I see the exact same behavior in my stats. Sought rules used to be in my top15 now , while its much further down the list for the past weeks stats. I can't offer any explanation, we haven't changed out setup in many months. But for us as well as bowie, the sought rules are hitting significantly less mails than they used to. Med venlig hilsen / Best regards Jonas Akrouh Larsen TechBiz ApS Laplandsgade 4, 2. sal 2300 København S Office: 7020 0979 Direct: 3336 9974 Mobile: 5120 1096 Fax: 7020 0978 Web: www.techbiz.dk
Re: [sa] RE: Sought rules not doing so good
On Wed, 3 Feb 2010, Jonas wrote: But for us as well as bowie, the sought rules are hitting significantly less mails than they used to. Makes me wonder if the spammers have put some work into identifying the spamtraps used to feed the sought rules generator? Have the sought maintainers noticed a drop in spam volume coming in to their traps? - C
Sought rules not doing so good
Since the sought rules have been updating for a while now, I took a look at my stats to see how they were doing. They used to be one of my most useful rules, but recently, they don't seem to be doing so good. Here are the stats for the last month: TOP SPAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 111JM_SOUGHT_FRAUD_3 112 0.060.36 0.970.01 154JM_SOUGHT_253 0.030.17 0.460.16 214JM_SOUGHT_331 0.020.10 0.270.51 253JM_SOUGHT_121 0.010.07 0.180.01 261JM_SOUGHT_FRAUD_2 19 0.010.06 0.170.01 TOP HAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 85JM_SOUGHT_399 0.080.32 0.270.51 161JM_SOUGHT_230 0.030.10 0.460.16 351JM_SOUGHT_FRAUD_3 2 0.000.01 0.970.01 365JM_SOUGHT_FRAUD_2 2 0.000.01 0.170.01 378JM_SOUGHT_1 1 0.000.00 0.180.01 I think I'm going to disable it here for the moment. Justin, is everything supposed to be back to normal with sought, or are you still working on it? -- Bowie
Re: Sought rules not doing so good
Bowie Bailey wrote: Since the sought rules have been updating for a while now, I took a look at my stats to see how they were doing. They used to be one of my most useful rules, but recently, they don't seem to be doing so good. Here are the stats for the last month: That looks like the sare stats script (modified to show all rules as evidenced by rank 261). It doesn't account for FPs or FNs. I reformatted your output so it wraps well for email. TOP SPAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 111JM_SOUGHT_FRAUD_3 1120.060.36 0.970.01 154JM_SOUGHT_2530.030.17 0.460.16 214JM_SOUGHT_3310.020.10 0.270.51 253JM_SOUGHT_1210.010.07 0.180.01 261JM_SOUGHT_FRAUD_2 190.010.06 0.170.01 TOP HAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 85JM_SOUGHT_3 99 0.080.32 0.270.51 161JM_SOUGHT_2 30 0.030.10 0.460.16 351JM_SOUGHT_FRAUD_3 2 0.000.01 0.970.01 365JM_SOUGHT_FRAUD_2 2 0.000.01 0.170.01 378JM_SOUGHT_11 0.000.00 0.180.01 That is quite different from our masscheck stats. Today's results at http://ruleqa.spamassassin.org/20100201/%2FJM_SOUGHT look like this: SPAM% HAM% S/ORANK SCORE NAME 9.8564 0.0042 1.0000.940.01 T_JM_SOUGHT_3 8.1587 0.0068 0.9990.930.01 T_JM_SOUGHT_2 11.6464 0.0289 0.9980.890.01 T_JM_SOUGHT_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_2 00 0.5000.480.00 JM_SOUGHT_FRAUD_3 Here are my own numbers, as observed by a custom script which recalculates results based on re-scoring specific rules. Rejected requires a score of 8.0 and flagged requires 5.0. (It only examines three rules at a time, and we got 33 messages between my runs.) JM_SOUGHT_1 ( 0.3% of 34831 total) with score-bump of -4: 124 rejected 1 flagged, with 0 (0%) that would have been rejected 1 passed, with -1 (-0.0%) that would have been flagged JM_SOUGHT_2 ( 0.2% of 34831 total) with score-bump of -4: 47 rejected 8 flagged, with -2 (-0.1%) that would have been rejected 24 passed, with -8 (-0.0%) that would have been flagged JM_SOUGHT_3 ( 0.5% of 34831 total) with score-bump of -4: 121 rejected 10 flagged, with -3 (-0.1%) that would have been rejected 60 passed, with -10 (-0.0%) that would have been flagged JM_SOUGHT_FRAUD_1 ( 0.0% of 34864 total) with score-bump of -3: 34 rejected 0 flagged, with 0 (0%) that would have been rejected 0 passed, with 0 (0%) that would have been flagged JM_SOUGHT_FRAUD_2 ( 0.5% of 34864 total) with score-bump of -3: 203 rejected 0 flagged, with 0 (0%) that would have been rejected 0 passed, with 0 (0%) that would have been flagged JM_SOUGHT_FRAUD_3 ( 1.3% of 34864 total) with score-bump of -3: 486 rejected 0 flagged, with -4 (-0.2%) that would have been rejected 1 passed, with 0 (0%) that would have been flagged My script was mostly written for adding points rather than subtracting them, so the notation is a little less intuitive. For example, rule 2 moved two mails from flag to reject and caused eight mails to get flagged. Recall that unlike the masscheck (which is hand-verified), log parsers like the sare script and my own script have no knowledge of FPs or FNs. I bet most if not all of the 86 messages that the SOUGHT rules noticed but didn't push up to the 5.0 mark were probably FNs. Of course, the reason I have a flag threshold and a reject threshold is so that I can still deliver low-scoring FPs. My users get them flagged as spam, with SA's spaminess score in the subject. That means instead of risking a loss of 86 messages, I only risked losing 9, and thanks to the smtp-time reject nature of my implementation, the senders got notices of the deliver failure. I have not yet had a complaint of these rejections based on SOUGHT rules. (The complaints are rare enough and usually related to massive misconfigurations on the sending relay.)
Re: Sought rules not doing so good
Adam Katz wrote: Bowie Bailey wrote: Since the sought rules have been updating for a while now, I took a look at my stats to see how they were doing. They used to be one of my most useful rules, but recently, they don't seem to be doing so good. Here are the stats for the last month: That looks like the sare stats script (modified to show all rules as evidenced by rank 261). It doesn't account for FPs or FNs. I reformatted your output so it wraps well for email. Exactly. I told it to show me the top 400 so I could see the stats for all the sought rules. Thanks for the reformat. Call me lazy... :) TOP SPAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 111JM_SOUGHT_FRAUD_3 1120.060.36 0.970.01 154JM_SOUGHT_2530.030.17 0.460.16 214JM_SOUGHT_3310.020.10 0.270.51 253JM_SOUGHT_1210.010.07 0.180.01 261JM_SOUGHT_FRAUD_2 190.010.06 0.170.01 TOP HAM RULES FIRED RANKRULE NAME COUNT %OFRULES %OFMAIL %OFSPAM %OFHAM 85JM_SOUGHT_3 99 0.080.32 0.270.51 161JM_SOUGHT_2 30 0.030.10 0.460.16 351JM_SOUGHT_FRAUD_3 2 0.000.01 0.970.01 365JM_SOUGHT_FRAUD_2 2 0.000.01 0.170.01 378JM_SOUGHT_11 0.000.00 0.180.01 That is quite different from our masscheck stats. Today's results at http://ruleqa.spamassassin.org/20100201/%2FJM_SOUGHT look like this: SPAM% HAM% S/ORANK SCORE NAME 9.8564 0.0042 1.0000.940.01 T_JM_SOUGHT_3 8.1587 0.0068 0.9990.930.01 T_JM_SOUGHT_2 11.6464 0.0289 0.9980.890.01 T_JM_SOUGHT_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_2 00 0.5000.480.00 JM_SOUGHT_FRAUD_3 Here are my own numbers, as observed by a custom script which recalculates results based on re-scoring specific rules. Rejected requires a score of 8.0 and flagged requires 5.0. (It only examines three rules at a time, and we got 33 messages between my runs.) JM_SOUGHT_1 ( 0.3% of 34831 total) with score-bump of -4: 124 rejected 1 flagged, with 0 (0%) that would have been rejected 1 passed, with -1 (-0.0%) that would have been flagged JM_SOUGHT_2 ( 0.2% of 34831 total) with score-bump of -4: 47 rejected 8 flagged, with -2 (-0.1%) that would have been rejected 24 passed, with -8 (-0.0%) that would have been flagged JM_SOUGHT_3 ( 0.5% of 34831 total) with score-bump of -4: 121 rejected 10 flagged, with -3 (-0.1%) that would have been rejected 60 passed, with -10 (-0.0%) that would have been flagged JM_SOUGHT_FRAUD_1 ( 0.0% of 34864 total) with score-bump of -3: 34 rejected 0 flagged, with 0 (0%) that would have been rejected 0 passed, with 0 (0%) that would have been flagged JM_SOUGHT_FRAUD_2 ( 0.5% of 34864 total) with score-bump of -3: 203 rejected 0 flagged, with 0 (0%) that would have been rejected 0 passed, with 0 (0%) that would have been flagged JM_SOUGHT_FRAUD_3 ( 1.3% of 34864 total) with score-bump of -3: 486 rejected 0 flagged, with -4 (-0.2%) that would have been rejected 1 passed, with 0 (0%) that would have been flagged My script was mostly written for adding points rather than subtracting them, so the notation is a little less intuitive. For example, rule 2 moved two mails from flag to reject and caused eight mails to get flagged. Recall that unlike the masscheck (which is hand-verified), log parsers like the sare script and my own script have no knowledge of FPs or FNs. I bet most if not all of the 86 messages that the SOUGHT rules noticed but didn't push up to the 5.0 mark were probably FNs. Of course, the reason I have a flag threshold and a reject threshold is so that I can still deliver low-scoring FPs. My users get them flagged as spam, with SA's spaminess score in the subject. That means instead of risking a loss of 86 messages, I only risked losing 9, and thanks to the smtp-time reject nature of my implementation, the senders got notices of the deliver failure. I have not yet had a complaint of these rejections based on SOUGHT rules. (The complaints are rare enough and usually related to massive misconfigurations on the sending relay.) I understand the problem with the stats program and FP/FN, but the last time I looked
Re: Sought rules not doing so good
On 02/02/2010 12:07 PM, Adam Katz wrote: That is quite different from our masscheck stats. Today's results at http://ruleqa.spamassassin.org/20100201/%2FJM_SOUGHT look like this: SPAM% HAM% S/ORANK SCORE NAME 9.8564 0.0042 1.0000.940.01 T_JM_SOUGHT_3 8.1587 0.0068 0.9990.930.01 T_JM_SOUGHT_2 11.6464 0.0289 0.9980.890.01 T_JM_SOUGHT_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_1 00 0.5000.480.00 JM_SOUGHT_FRAUD_2 00 0.5000.480.00 JM_SOUGHT_FRAUD_3 FWIW the nightly masscheck is often very unbalanced especially on the spam side. Sometimes we have only 50k spam, sometimes over 500k spam. Some spam corpora contain a disproportionate amount of high scoring spam trap mail. I personally randomly filter out a large percentage of high scoring mail in an attempt to balance my spam corpus. But ultimately we need more masscheck participants to have better results. Warren
Re: Sought Rules Back?
On Mon, 2010-02-01 at 00:10 -0500, Jared Hall wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Had to pinch myself 2.5 times (1 per month)
to be sure.
Thanks.
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Sought Rules Back?
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up. Btw, I prefer to avoid them monopolizing
the score when more than one hits:
score JM_SOUGHT_FRAUD_1 0.1
score JM_SOUGHT_FRAUD_2 0.1
score JM_SOUGHT_FRAUD_3 0.1
meta JM_SOUGHT_FRAUD_ANY JM_SOUGHT_FRAUD_1 || JM_SOUGHT_FRAUD_2 ||
JM_SOUGHT_FRAUD_3
score JM_SOUGHT_FRAUD_ANY 3.0
Mark
Re: Sought Rules Back?
On 2/1/2010 10:30 AM, Mark Martinec wrote:
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up. Btw, I prefer to avoid them monopolizing
the score when more than one hits:
score JM_SOUGHT_FRAUD_1 0.1
score JM_SOUGHT_FRAUD_2 0.1
score JM_SOUGHT_FRAUD_3 0.1
meta JM_SOUGHT_FRAUD_ANY JM_SOUGHT_FRAUD_1 || JM_SOUGHT_FRAUD_2 ||
JM_SOUGHT_FRAUD_3
score JM_SOUGHT_FRAUD_ANY 3.0
I tried to read all 6 months of the comments on Bug 6155, but I just
don't have the time this morning to do so. Since the bug is now closed
as fixed, is there a reason why scores haven't been pushed out in an
update? If this ruleset is expected to come into and out of service,
and timely status updates generally aren't sent to this list, I'd rather
not manually add scores in local.cf.
Re: Sought Rules Back?
On 2/1/10 9:30 AM, Mark Martinec mark.martinec...@ijs.si wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Doesn't appear to be that way in the 3.2.5 channel:
$ cd /var/lib/spamassassin/3.002005/sought_rules_yerp_org/
$ grep score *
20_sought.cf:score JM_SOUGHT_1 4.0
20_sought.cf:score JM_SOUGHT_2 4.0
20_sought.cf:score JM_SOUGHT_3 4.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_1 3.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_2 3.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_3 3.0
$ ls -l
total 128
-rw-r--r-- 1 root root 44591 Feb 1 07:12 20_sought.cf
-rw-r--r-- 1 root root 80120 Feb 1 07:12 20_sought_fraud.cf
-rw-r--r-- 1 root root29 Feb 1 07:12 MIRRORED.BY
And in fact, looking at the 3.3.0 channel on a different box, the scores are
the same:
$ cd /var/lib/spamassassin/3.003000/sought_rules_yerp_org/
$ grep score *
20_sought.cf:score JM_SOUGHT_1 4.0
20_sought.cf:score JM_SOUGHT_2 4.0
20_sought.cf:score JM_SOUGHT_3 4.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_1 3.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_2 3.0
20_sought_fraud.cf:score JM_SOUGHT_FRAUD_3 3.0
Not sure if people using the channel realize that scores
need to be bumped up. Btw, I prefer to avoid them monopolizing
the score when more than one hits:
score JM_SOUGHT_FRAUD_1 0.1
score JM_SOUGHT_FRAUD_2 0.1
score JM_SOUGHT_FRAUD_3 0.1
meta JM_SOUGHT_FRAUD_ANY JM_SOUGHT_FRAUD_1 || JM_SOUGHT_FRAUD_2 ||
JM_SOUGHT_FRAUD_3
score JM_SOUGHT_FRAUD_ANY 3.0
Mark
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: Sought Rules Back?
On Mon, 1 Feb 2010 16:30:04 +0100
Mark Martinec mark.martinec...@ijs.si wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up.
That doesn't seem to be correct:
$ grep score 20_sought_fraud.cf
score JM_SOUGHT_FRAUD_1 3.0
score JM_SOUGHT_FRAUD_2 3.0
score JM_SOUGHT_FRAUD_3 3.0
$ ls -l 20_sought_fraud.cf
-rw-r--r-- 1 root wheel 80120 1 Feb 15:38 20_sought_fraud.cf
Re: Sought Rules Back?
On 2/1/2010 10:58 AM, RW wrote:
On Mon, 1 Feb 2010 16:30:04 +0100
Mark Martinec mark.martinec...@ijs.si wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up.
That doesn't seem to be correct:
$ grep score 20_sought_fraud.cf
score JM_SOUGHT_FRAUD_1 3.0
score JM_SOUGHT_FRAUD_2 3.0
score JM_SOUGHT_FRAUD_3 3.0
$ ls -l 20_sought_fraud.cf
-rw-r--r-- 1 root wheel 80120 1 Feb 15:38 20_sought_fraud.cf
updates_spamassassin_org/50_scores.cf overrides the scores in the sought
ruleset.
Re: Sought Rules Back?
On 2/1/10 9:59 AM, Jason Bertoch ja...@i6ix.com wrote:
On 2/1/2010 10:58 AM, RW wrote:
On Mon, 1 Feb 2010 16:30:04 +0100
Mark Martinec mark.martinec...@ijs.si wrote:
Update returned sought rules 1/31/2010.
Actually back since Jan 6. :) Re-viewed about 1k fraud spam the
following days, for the Sought Fraud sub-set.
Btw, the three rules JM_SOUGHT_FRAUD_{1,2,3} have a score of zero
as per Justin's request (Bug 6155 c 38, c72, c89, c124).
Not sure if people using the channel realize that scores
need to be bumped up.
That doesn't seem to be correct:
$ grep score 20_sought_fraud.cf
score JM_SOUGHT_FRAUD_1 3.0
score JM_SOUGHT_FRAUD_2 3.0
score JM_SOUGHT_FRAUD_3 3.0
$ ls -l 20_sought_fraud.cf
-rw-r--r-- 1 root wheel 80120 1 Feb 15:38 20_sought_fraud.cf
updates_spamassassin_org/50_scores.cf overrides the scores in the sought
ruleset.
Ah, I didn't catch that. But it is only in the 3.3.0 channel. Fixing my
3.3.0 test machines now
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: Sought Rules Back?
Thanks for this info and good idea about this meta rule! Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Sought Rules Back?
Update returned sought rules 1/31/2010. Had to pinch myself 2.5 times (1 per month) to be sure. Thanks.
Re: sought rules
Hi all - I'm afraid the sought rules, and generally most of my time to work on SA, is still on a bit of a hiatus due to circumstances out of my control :( unfortunately my house renovation is taking longer than planned, and my net access outside work, at the moment, consists of an iPhone! Working on anything this way is not particularly practical... On Wednesday, December 2, 2009, Bob Proulx b...@proulx.com wrote: Hi Justin, Right now I'm not likely to be able to perform more investigation for a week or two. :( Any word on your sought rules? They were working so well for me that I miss them now that they aren't getting updated! Good stuff. Sorry about this -- the perils of volunteer infrastructure! I don't want to be annoying or be a trouble maker. I just became impatient and decided I would ask about them! :-) Thanks! Bob -- --j.
Re: sought rules
Justin Mason wrote: unfortunately my house renovation is taking longer than planned, and my net access outside work, at the moment, consists of an iPhone! Construction always takes longer than people plan it to take. It is rather like software in that regard! Working on anything this way is not particularly practical... Don't worry about it further. You have your task queue full already. Thanks for the update! Bob
Re: sought rules
Post your server and bandwidth requirements here. I'm sure many of us would have the datacenter space and capacity to host a redundant backup. On Wed, Nov 11, 2009 at 03:29:07PM +, Justin Mason wrote: On Wed, Nov 11, 2009 at 14:04, Bowie Bailey bowie_bai...@buc.com wrote: john ffitch wrote: Have I missed something? I used to pull the sought rules daily, but nothing seems to have changed since 2 Nov. Is that expected behaviour? ==John ffitch No, that's not expected behavior... On Thu, 5 Nov 2009, Justin Mason wrote: Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( And that's about all we know at the moment. Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! -- --j. -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ| Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Mainehttp://www.midcoast.com/ */
Re: sought rules
On Sat, 14 Nov 2009, jp wrote: Post your server and bandwidth requirements here. I'm sure many of us would have the datacenter space and capacity to host a redundant backup. It's wonderful to see so many people offer 'mirror' space, but as I understand things, the issue is not with delivery/download of the rules, but with the regeneration program/process. And I believe the maintainer already stated that the issue there is with the security of the ham corpus he uses to regenerate the rules. It makes the server restricted for access for repair, and precludes the possibility of the regeneration process itself being mirrored So we're just going to have to wait patiently. :) - Charles
sought rules
Have I missed something? I used to pull the sought rules daily, but nothing seems to have changed since 2 Nov. Is that expected behaviour? ==John ffitch
Re: sought rules
john ffitch wrote: Have I missed something? I used to pull the sought rules daily, but nothing seems to have changed since 2 Nov. Is that expected behaviour? ==John ffitch No, that's not expected behavior... On Thu, 5 Nov 2009, Justin Mason wrote: Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( And that's about all we know at the moment. -- Bowie
Re: sought rules
On Wed, Nov 11, 2009 at 14:04, Bowie Bailey bowie_bai...@buc.com wrote: john ffitch wrote: Have I missed something? I used to pull the sought rules daily, but nothing seems to have changed since 2 Nov. Is that expected behaviour? ==John ffitch No, that's not expected behavior... On Thu, 5 Nov 2009, Justin Mason wrote: Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( And that's about all we know at the moment. Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! -- --j.
Re: sought rules
Justin Mason wrote: Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! No problem. I've set scores for all the JM_SOUGHT* rules to zero until I start seeing updates again. -- Bowie
Re: sought rules
Hi, Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! Where is it physically located? Isn't there someone in the area that you trust, or could trust, to go and fix it? I guess if there was, you would have done that, but I'm sure you could find some volunteers to put it up in a more centrally-located or managed location for the future, if you'd like. Off-site backup? At the least, I'm sure someone could contribute there. I've got a few servers, and would be happy to provide remote ssh/rsync access to someone, should you like. Best regards, Alex
Re: sought rules
On Wed, 11 Nov 2009 12:09:09 -0500, you wrote: Hi, Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! Where is it physically located? Isn't there someone in the area that you trust, or could trust, to go and fix it? I guess if there was, you would have done that, but I'm sure you could find some volunteers to put it up in a more centrally-located or managed location for the future, if you'd like. Off-site backup? At the least, I'm sure someone could contribute there. I've got a few servers, and would be happy to provide remote ssh/rsync access to someone, should you like. Truewhat do you need to host this thingif I can help out with space/bandwidth I'd be willing. I've got a couple linux boxes here that I could give you some space on. George -- ===[George R. Kasica]===+1 262 677 0766 President +1 206 374 6482 FAX Netwrx Consulting Inc. Jackson, WI USA http://www.netwrx1.com geor...@netwrx1.com ICQ #12862186
Re: sought rules
Hi guys -- the problem is that SOUGHT uses gigabytes of private mail, so running that on a shared host is not viable. Currently we don't have anything like that I can use :( On Wednesday, November 11, 2009, George R. Kasica geor...@netwrx1.com wrote: On Wed, 11 Nov 2009 12:09:09 -0500, you wrote: Hi, Yep -- sorry -- I got to reboot the server, but it appears to have not fixed the problem. Right now I'm not likely to be able to perform more investigation for a week or two. :( Sorry about this -- the perils of volunteer infrastructure! Where is it physically located? Isn't there someone in the area that you trust, or could trust, to go and fix it? I guess if there was, you would have done that, but I'm sure you could find some volunteers to put it up in a more centrally-located or managed location for the future, if you'd like. Off-site backup? At the least, I'm sure someone could contribute there. I've got a few servers, and would be happy to provide remote ssh/rsync access to someone, should you like. Truewhat do you need to host this thingif I can help out with space/bandwidth I'd be willing. I've got a couple linux boxes here that I could give you some space on. George -- ===[George R. Kasica]=== +1 262 677 0766 President +1 206 374 6482 FAX Netwrx Consulting Inc. Jackson, WI USA http://www.netwrx1.com geor...@netwrx1.com ICQ #12862186 -- --j.
Re: sought rules
On 11-Nov-2009, at 11:37, George R. Kasica wrote: Truewhat do you need to host this thingif I can help out with space/bandwidth I'd be willing. I've got a couple linux boxes here that I could give you some space on. I've got a pretty solid business-cable connection at home and my server is up pretty much 24/7/365, depending on bandwidth I could donate some. (I've got about 3Mb up) -- But you read a lot of books, I'm thinking. Hard to have faith, ain't it, when you've read too many books?
Re: sought rules
I need the full mails to do that -- but with the uploaded mail, yes, I should do that! good point. Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( On Thu, Nov 5, 2009 at 18:02, John Hardin jhar...@impsec.org wrote: On Thu, 5 Nov 2009, Dave Pooser wrote: I think I remember hearing some discussion about that at one point. I don't think that type of thing is as big of a concern here since these are all body rules. I agree that you need a good corpus of ham to prevent FP's, but I'm sure Justin is doing that. I'm sure he's working hard on it, but his ability is naturally going to be limited by his ham corpus. I just saw a whole bunch of legit AmEx corporate card updates get thrown into the quarantine bin due to hitting SOUGHT. It happens sometimes; I've found that when I send him a sample of the mistagged email he gets it fixed pretty quickly. I wonder if he's considered running the ham exclusion against the complete nightly masscheck ham corpora...? -- John Hardin KA7OHZ http://www.impsec.org/~jhardin/ jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Men by their constitutions are naturally divided in to two parties: 1. Those who fear and distrust the people and wish to draw all powers from them into the hands of the higher classes. 2. Those who identify themselves with the people, have confidence in them, cherish and consider them as the most honest and safe, although not the most wise, depository of the public interests. -- Thomas Jefferson --- 6 days until Veterans Day -- --j.
Re: sought rules
On Thu, 5 Nov 2009, Justin Mason wrote: I need the full mails to do that -- but with the uploaded mail, yes, I should do that! good point. Glad to help. Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( ruleqa/nightly masscheck seems to have fallen apart, too. :( -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 6 days until Veterans Day
Re: sought rules
On Fri, Nov 6, 2009 at 00:00, John Hardin jhar...@impsec.org wrote: On Thu, 5 Nov 2009, Justin Mason wrote: I need the full mails to do that -- but with the uploaded mail, yes, I should do that! good point. Glad to help. Right now, SOUGHT appears to be broken. I need to get to where the server is currently and fix it -- I don't have remote login to it at the mo :( ruleqa/nightly masscheck seems to have fallen apart, too. :( I think I may have just fixed that fingers crossed. -- --j.
Re: sought rules (was: Development dead)
On Wed, 4 Nov 2009, Bowie Bailey wrote: The SA core rules are not updated very often. For the most part, they just work. If you are not already doing so, you may want to consider Justin's Sought ruleset. It is dynamically generated and updated every 4 hours or so. http://wiki.apache.org/spamassassin/SoughtRules Is there a way to examine the sought rules *before* installing them into my spamassassin? Or at least a 'readme' so that if I download them via sa-update I can know which files will be created and how to remove them. I have a number of custom rules and want to vet the auto-generated rules for overlap - Charles
Re: sought rules
On 11/4/2009 5:22 PM, Charles Gregory wrote: On Wed, 4 Nov 2009, Bowie Bailey wrote: The SA core rules are not updated very often. For the most part, they just work. If you are not already doing so, you may want to consider Justin's Sought ruleset. It is dynamically generated and updated every 4 hours or so. http://wiki.apache.org/spamassassin/SoughtRules Is there a way to examine the sought rules *before* installing them into my spamassassin? Or at least a 'readme' so that if I download them via sa-update I can know which files will be created and how to remove them. I have a number of custom rules and want to vet the auto-generated rules for overlap - Charles sa-update --help will show you how
