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
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
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
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
when the tflags
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
So it is an intel 32 bit thing or a perl 5.12?
--
Michael Scheidell
CTO SECNAP Network Security
561-948-2259tel:5619482259
-Original message-
From: Lee Dilkie l...@dilkie.com
To: Michael Scheidell michael.scheid...@secnap.com
Cc: users@spamassassin.apache.org
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
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
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
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
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
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
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 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 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 =~
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),
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
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
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
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.
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 and the
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:
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%.
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 see that
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=6558
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
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
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,
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
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,
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
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 data
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,
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
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
35 matches
Mail list logo
