Re: [SAtalk] I never expected this!

jm said: > brad said: > > > I have received about 50 complaints from people Yelling at me to disable > > The easiest way to do this for *real* users (listed in /etc/passwd), is to > create a ~/.spamassassin/user_prefs (2.0 filename!) file with > > required_hits 100 If I were an ira

[SAtalk] false positives on conference announcements

Conference announcements often contain the phrase "the following format" when requesting submissions, which matches the THE_FOLLOWING_FORM rule, which has a quite high score. Adding \W to the end of the pattern prevents this, and seems safe in general. Tom __

RE: [SAtalk] false positives on conference announcements

> > Conference announcements often contain the phrase "the > > following format" > > when requesting submissions, which matches the > > THE_FOLLOWING_FORM rule, > > which has a quite high score. Adding \W to the end of the > > pattern prevents > > this, and seems safe in general. > > \b would

[SAtalk] bug in spamd defunct process reaper

Looks like the waitpid() loop got put in the wrong place in spamd in the 2.0 release. It needs to be the last statement in the for, but it ended up as the last statement in the spawned sub, so runs in the wrong process. Tom *** spamd/spamd.raw.origFri Jan 18 20:30:51 2002 --- spamd/spam

[SAtalk] addr to send false positives to?

> How bout setting up a box like [EMAIL PROTECTED] (or anything -- I > don't care) that would save a copy to the corpus, as well as forward/bounce How about an address for false positives? I'm not sure it's a good idea to make either address automatically add to the appropriate corpus. One of t

[SAtalk] Non-essential feature request: spamd reload rules on SIGHUP

Modifying the site-wide config requires killing and restarting spamd, which risks missing some mail or killing a running scan. It would be handy if sending SIGHUP to the parent spamd process would cause it to reload the rules cleanly. It should leave the listen up, and ideally it would continue

Re: [SAtalk] Non-essential feature request: spamd reload rules on SIGHUP

On 17 Feb 2002 11:29:53 -0800 Craig Hughes wrote: > I'll happily accept patches. Yeah, I've been meaning to do it for several weeks now, but it's not going to happen any time soon. I was hoping someone would see this and say "what a great idea, I think I'll do that." Apparently not. > In the

[SAtalk] VERY_SUSP_RECIPS missing some, matching some wrongly.

I noticed that VERY_SUSP_RECIPS and VERY_SUSP_CC_RECIPS were failing to match in some cases they should, and matching in some they shouldn't. /\b([a-z][a-z])[^@]{0,20}(@[-a-z0-9_\.]{0,30}).{0,30}?(?:\1[^@]*\2.{0,20}?){9,}/is - Sequences such as "[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTE

Re: [SAtalk] false positives from VERY_SUSP_RECIPS

At Wed, 20 Feb 2002 16:16:56 -0800 John Beck wrote: > ... > would trigger false positives on > > a@domain, b@domain, ..., k@domain > > i.e., 11 (not 10) of the same domain would trigger this regardless of the > local parts. Well, the SUSPICIOUS_[CC_]RECIPS macros seemed good, so I > tweaked the

[SAtalk] new, larger, GA scores

I haven't installed 2.1, but I agree that the new scores are worrisome. With large scores like this (positive or negative), very small perturbations in input can cause wildly different results, which seems undesirable. I'd like to hear Justin's take on this, if he's not incommunicado. Tom _