On Sun, 20 Mar 2011, Dan Grossman wrote:
Hmm ... my problem is that I can't get the bug to go away. I've
commented out the offending lines in the ruleset download location, and
yet the problem still happens.
I'm not sure whether I compile the rules or not ... I don't use a
spamd, if that matte
On Sun, 2011-03-20 at 22:44 -0500, Dan Grossman wrote:
> Hmm ... my problem is that I can't get the bug to go away. I've
> commented out the offending lines in the ruleset download location, and
> yet the problem still happens.
That seems to suggest you are using compiled rules. Do you use
sa-c
Hmm ... my problem is that I can't get the bug to go away. I've
commented out the offending lines in the ruleset download location, and
yet the problem still happens.
I'm not sure whether I compile the rules or not ... I don't use a
spamd, if that matters.
-dg
On 2011-03-20 at 10:58, jhar...
On Sun, 2011-03-20 at 23:13 -0400, Michael Scheidell wrote:
> On 3/20/11 8:57 PM, Karsten Bräckelmann wrote:
> > There are now reports, that this bug is not strictly related to 32 bit
> > architecture (though always with compiled rules).
> >
> > Since there have been offers for further testing: One
On Mon, 2011-03-21 at 01:57 +0100, Karsten Bräckelmann wrote:
> Another might be to reproduce the issue, and get a minimal test-case.
Just received a reply privately, containing like heaps of information
and debugging. Two very noteworthy points it appears to surface.
(a) The actual rule that tri
On 3/20/11 8:57 PM, Karsten Bräckelmann wrote:
There are now reports, that this bug is not strictly related to 32 bit
architecture (though always with compiled rules).
Since there have been offers for further testing: One data point is to
collect details about systems, CPU architecture, instruct
On 3/20/11 4:39 PM, Karsten Bräckelmann wrote:
On Sun, 2011-03-20 at 20:26 +0100, Sam wrote:
Some email on this list is crashing my spamassin daemon :
My server went down and I saw it was when spamd is starting to scan for
exemple the email from Matt Elson a few minutes ago.
Yes. Please see th
There are now reports, that this bug is not strictly related to 32 bit
architecture (though always with compiled rules).
Since there have been offers for further testing: One data point is to
collect details about systems, CPU architecture, instruction set used
for compiling, versions (OS, kernel,
On Sun, 2011-03-20 at 10:50 -0400, Matt Elson wrote:
> I'm having the problem on an Intel 32-bit Linux machine running 5.8.8
> with the same version of re2c, so it looks like the common thread is
> Intel 32 bit + re2c. I'll see if I can throw up 64 bit machine to test
> further.
We saw the pro
Sorry for the noise,
I didn't read inside the email that was crashing my server.
All was resolved by quoting PILL_PRICE as explained ans re-run sa-compile.
Strange bug.
It's going to be an involontary mailing list DOS if lot of people use
sa-compile.
For me it's on 64 bit squeeze from Debia
On Sun, 2011-03-20 at 22:09 +0100, JKL wrote:
> On 03/20/2011 10:04 PM, Karsten Bräckelmann wrote:
> > This appears to be a bug with re2c (using sa-compile) and some
> > combination of hardware architecture and/or OS. Bug 6558 [1].
> > [1] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=65
Am 20.03.2011 22:09, schrieb JKL:
> On 03/20/2011 10:04 PM, Karsten Bräckelmann wrote:
>> On Sun, 2011-03-20 at 21:37 +0100, JKL wrote:
>>> I noticed a problem that started this morning, where postfix was
>>> timing out whilst talking with the spamass-milter. Looking further into
>>> this, I se
On 03/20/2011 10:04 PM, Karsten Bräckelmann wrote:
> On Sun, 2011-03-20 at 21:37 +0100, JKL wrote:
>> I noticed a problem that started this morning, where postfix was
>> timing out whilst talking with the spamass-milter. Looking further into
>> this, I see that sometimes spamd PIDs still at 100
Hi,
On dim, 2011-03-20 at 21:37 +0100, JKL wrote:
> Happy weekend everybody,
...
> Any ideas where I should start to look?
It's surely related to the "__PILL_PRICE" (aka re2c bug with sa-compile
on ia32) problem.
See:
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201103.mbox/%3c4d
On 03/20/2011 09:53 PM, Robert Schetterer wrote:
> Am 20.03.2011 21:37, schrieb JKL:
>> --max-children 3
> perhaps high this one
>
>
I thought 3 was the default. Opps.
> check for timeouts in
> dns related stuff like rbls
> and/or thing like razor,pyzor,dcc
local.cf has DNS black-lists disabled a
On Sun, 2011-03-20 at 21:37 +0100, JKL wrote:
> I noticed a problem that started this morning, where postfix was
> timing out whilst talking with the spamass-milter. Looking further into
> this, I see that sometimes spamd PIDs still at 100%. Its been running
> the milter on it for many months
Am 20.03.2011 21:37, schrieb JKL:
> --max-children 3
perhaps high this one
-m num, --max-children=numAllow maximum num children
--timeout-tcp=secsConnection timeout for client headers
--timeout-child=secs Connection timeout for message
checks
-m num
On Sun, 2011-03-20 at 20:26 +0100, Sam wrote:
> Some email on this list is crashing my spamassin daemon :
>
> My server went down and I saw it was when spamd is starting to scan for
> exemple the email from Matt Elson a few minutes ago.
Yes. Please see that full thread, in any archive of your ch
Happy weekend everybody,
I noticed a problem that started this morning, where postfix was
timing out whilst talking with the spamass-milter. Looking further into
this, I see that sometimes spamd PIDs still at 100%. Its been running
the milter on it for many months.
PID USER PR NI VI
no problem on freebsd 7.3 i386, perl 5.10, compiled rules.
1.3.3.updates.spamassassin.org => 1083147
Hmmm. I'm not seeing any obvious common thread with my admittedly
untrained eye then.
I just deployed two fresh virtual machines (RHEL6 32 bit, RHEL6 64 bit -
kicks perl up to 5.10.1), gr
On 20/03/11 17:17, Marc Perkel wrote:
Want to share your bank list? Here's mine:
Mine was embedded in my last reply:
headerLOCAL_FROM_BANKFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|allianceleicester|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citi
On 3/20/11 10:50 AM, Matt Elson wrote:
On 3/20/11 10:28 AM, Michael Scheidell wrote:
So it is an intel 32 bit thing or a perl 5.12?
I'm having the problem on an Intel 32-bit Linux machine running 5.8.8
with the same version of re2c, so it looks like the common thread is
Intel 32 bit + re2c.
On 3/20/2011 9:57 AM, Ned Slider wrote:
On 20/03/11 16:29, Marc Perkel wrote:
Just throwing this out there to see if people like this rule and if you
would like to improve it. Bank phishing usually involves a lot of
phrases to get you to give up your information. This rule looks for 5
matches
On 20/03/11 16:29, Marc Perkel wrote:
Just throwing this out there to see if people like this rule and if you
would like to improve it. Bank phishing usually involves a lot of
phrases to get you to give up your information. This rule looks for 5
matches out of the following list.
Hi Marc,
I g
Just throwing this out there to see if people like this rule and if you
would like to improve it. Bank phishing usually involves a lot of
phrases to get you to give up your information. This rule looks for 5
matches out of the following list.
body __BANK_PHISH_00 /\byour account\b/i
On Sun, 20 Mar 2011, Matt Elson wrote:
fails for me, loops, freebsd 7.3, intel, perl 5.12.3, SA 3.3.1, re2c
001305
what rule should we comment out until this is fixed?
Commenting out the following fixed it for me, so should be safe
# tflags __PILL_PRICE_1 multiple
# tflags
On Sun, 20 Mar 2011, Matt Elson wrote:
It looks like you can get away with just commenting out the tflags
multiple stanza:
#tflags __PILL_PRICE_1 multiple
Not sure how effective MANY_PILL_PRICE is without the multiple hits from
each sub rule,
Much less so. It'd still hit if al
On Sun, 20 Mar 2011, Matt Elson wrote:
Unsure if anyone else is seeing this, but the following rules in the
latest ruleset
Hey! A rules update went out! Yay!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@i
On 3/20/11 10:28 AM, Michael Scheidell wrote:
So it is an intel 32 bit thing or a perl 5.12?
I'm having the problem on an Intel 32-bit Linux machine running 5.8.8
with the same version of re2c, so it looks like the common thread is
Intel 32 bit + re2c. I'll see if I can throw up 64 bit machi
So it is an intel 32 bit thing or a perl 5.12?
--
Michael Scheidell
CTO SECNAP Network Security
561-948-2259
-Original message-
From: Lee Dilkie
To: Michael Scheidell
Cc: "users@spamassassin.apache.org"
Sent: Sun, Mar 20, 2011 14:05:35 GMT+00:00
Subject: Re: __PILL_PRICE Problems
On
fails for me, loops, freebsd 7.3, intel, perl 5.12.3, SA 3.3.1, re2c 001305
what rule should we comment out until this is fixed?
Commenting out the following fixed it for me, so should be safe
#tflags __PILL_PRICE_1 multiple
#tflags __PILL_PRICE_2 multiple
#tflags
On 3/20/2011 8:48 AM, Michael Scheidell wrote:
> On 3/20/11 6:04 AM, Matt Elson wrote:
>> body__PILL_PRICE_3
>> /free\s(?:pill|tablet|cap(?:sule|let))s/i
>> tflags __PILL_PRICE_3 multiple
>>
>> Specifically, they're causing spamassassin to run in an endless loop
>> whe
I see same here. But it only seems to happen if you compile the rules. I
have one server where I compile the rules, and this exhibited the same
problem.
I can confirm that the endless loop only happens on rule compilation as
well; without compilation everything's fine. Also, because I forgot t
On 3/20/11 6:04 AM, Matt Elson wrote:
body__PILL_PRICE_3
/free\s(?:pill|tablet|cap(?:sule|let))s/i
tflags __PILL_PRICE_3 multiple
Specifically, they're causing spamassassin to run in an endless loop
when the tflags line active when the rule hits. Debug just shows t
20.03.2011 12:04, Matt Elson kirjutas:
Unsure if anyone else is seeing this, but the following rules in the
latest ruleset fetched around 1AM EST or so today (version 1083147 if
I'm reading the debug logs right - I don't have a copy of any previous
ones, so unknown if they are new) are creating
35 matches
Mail list logo
