Thanks very much for the detailed reply!
Quoting Mark Martinec mark.martinec...@ijs.si:
If you can isolate one such message which causes a crash and
be able to reproduce it from a command line spamassassin, that would
be ideal. Otherwise, enable debugging and when a process crashes
check what
Hi Karsten,
thanks a lot for your reply...
Quoting Karsten Bräckelmann guent...@rudersport.de:
I first would check bugzilla for similar issues. In this particular
case, bug 6127. The comments in that bug should help to get debug logs,
which we would need.
I have previously had a look
On 05/25/2010 12:14 AM, Adam Katz wrote:
My original rule:
header SINGLE_HEADER_2K ALL:raw =~ /^(?=.{2048,3071}$)/m
Karsten Bräckelmann noted:
It does not match a single header, let alone a *specific*
header as the one mentioned, but ALL headers. It effectively
checks the entire headers'
Charles Gregory wrote:
On Wed, 2 Jun 2010, Helmut Schneider wrote:
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
What distinguishes 'certain mails'? Length? Content? Mime
attachements?
It's around 1 of 1000, I caught one that was a HTML mail, 100kB, no
Hi,
update on this is Ive had the system running using MySQL backend
for Bayes and AWL for the last 4 hours. So far all good, no 100% CPU
runaway processes and no Signal 11 errors. The 100% CPU issue did seem
to be resolved by my initial deleting of the bayes BDB files (prior to
On Thu, 2010-06-03 at 10:12 +0100, a.sm...@ukgrid.net wrote:
I first would check bugzilla for similar issues. In this particular
case, bug 6127. The comments in that bug should help to get debug logs,
which we would need.
I have previously had a look through this bug report and also
Quoting Karsten Bräckelmann guent...@rudersport.de:
That are *not* debug logs. That's standard logging, no debug.
Post 1 of 3 is normal log, post 3 of 3 was from spamassassin with
debug enabled. Is there some further debugging that can be enabled?
Alas, as you mentioned in your reply to
Hi,
I have a problem using Spamassassin, spamass-milter and postfix
together. I'm aware that the problem might be in my configuration,
postfix or spamass-milter, but I can't track it down. I'm running Debian
Lenny with details below.
Mails coming in thru postfix+spamass-milter+spamassassin
On 03.06.10 16:36, Tarvo Kurm wrote:
I have a problem using Spamassassin, spamass-milter and postfix
together. I'm aware that the problem might be in my configuration,
postfix or spamass-milter, but I can't track it down. I'm running Debian
Lenny with details below.
Mails coming in
On Thu, 2010-06-03 at 16:36 +0300, Tarvo Kurm wrote:
I have a problem using Spamassassin, spamass-milter and postfix
together. I'm aware that the problem might be in my configuration,
postfix or spamass-milter, but I can't track it down. I'm running Debian
Lenny with details below.
Bug
On Thu, 2010-06-03 at 14:33 +0100, a.sm...@ukgrid.net wrote:
Quoting Karsten Bräckelmann guent...@rudersport.de:
That are *not* debug logs. That's standard logging, no debug.
Post 1 of 3 is normal log, post 3 of 3 was from spamassassin with
debug enabled. Is there some further debugging
Tarvo Kurm wrote:
Mails coming in thru postfix+spamass-milter+spamassassin have
drastically lower scores than those checked manually with spamassasin or
spamc. Specifically, mails taking the milter path will not have RCVD_IN
rules matched _almost_ never. I'm suspicious of the UNPARSABLE_RELAY
Helmut Schneider wrote:
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
[...]
Any idea where to start?
Appendix: I set up a fresh and clean FreeBSD 8.0 with only SA 3.3.1 and
Perl 5.10.1_1 and the problem still persists. I then removed all
packages, compiled perl
On Thu, 3 Jun 2010, Helmut Schneider wrote:
I then started from scratch and tried with SA 3.2.5. The particular
body_tests take only 5 seconds (instead of 30).
As I mentioned before, I noticed this difference myself, and presumed it
was just a characteristic of the 'improved' logic for
On Thursday 03 June 2010 18:02:23 Charles Gregory wrote:
As I mentioned before, I noticed this difference myself, and presumed it
was just a characteristic of the 'improved' logic for deep-scanning the
body of emails, and perhaps just a larger number of rules than before
Though I am still
On 3-Jun-2010, at 03:27, Ned Slider wrote:
Can we re-evaluate how useful this is, or maybe exclude To: and CC: headers?
After several years I have trained all my users to use the Bcc header for any
email going to more than 4 or 5 users and to address those emails to themselves.
To me, this
On Thu, 3 Jun 2010, Mark Martinec wrote:
Here is one common problem of 'certain mail messages'
taking a long time to process - unresolvable for now:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5590
Sorry, but that bug has been around since 3.2.3 - it would not explain a
sudden
On 06/03/2010 05:29 PM, LuKreme wrote:
On 3-Jun-2010, at 03:27, Ned Slider wrote:
Can we re-evaluate how useful this is, or maybe exclude To: and CC: headers?
After several years I have trained all my users to use the Bcc header for any
email going to more than 4 or 5 users and to address
Well, before moving servers... What is its file size? See the bug I
referenced earlier, and the oddities found there.
Yeah, I did have a look at this before. I dont think I have any
unusually large files that would cause a prob, the sizes are:
82M./auto-whitelist
66K
On 6/3/2010 12:02 PM, Charles Gregory wrote:
On Thu, 3 Jun 2010, Helmut Schneider wrote:
I then started from scratch and tried with SA 3.2.5. The particular
body_tests take only 5 seconds (instead of 30).
As I mentioned before, I noticed this difference myself, and presumed
it was just a
After using SpamAssassin for a number of years, I'm finally getting
around to implementing Bayesian filters. For my particular setup, the
bulk of my users are non-technical users who make POP connections
(although there are some that use IMAP clients, both offline and
webmail). Thus, I'm
On Thu, 3 Jun 2010, NFN Smith wrote:
4) I run several servers in parallel. My spamtraps indicate that some
spam operations hit user ids on two or more of my servers, while
other ops seem to have only user addresses on a single server. Is
there a way of feeding the Bayesian data on
On 6/3/2010 7:52 AM, Helmut Schneider wrote:
Helmut Schneider wrote:
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
[...]
Any idea where to start?
Appendix: I set up a fresh and clean FreeBSD 8.0 with only SA 3.3.1 and
Perl 5.10.1_1 and the problem still
Helmut Schneider wrote:
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
I might have been able to catch a non-confident example mail[1] (bad
example because of the size, but an example).
While SA 3.2.5 needs ~45 seconds, with SA 3.3.1:
Jun 4 03:36:41.029 [56496]
I'm trying to write a rule to catch a bunch of spam I'm getting recently that
contain only an .RTF file. The filename, subject line, and other details
vary, but the raw message body is always the same i.e. the base64 encoded
RTF file.
See the headers and first few lines of the email here, plus
Hi,
There is allready a few threads about this ...
http://www.gossamer-threads.com/lists/spamassassin/users/153560?do=post_view_threaded
mvh
On Fri, Jun 4, 2010 at 4:44 AM, cviebrock colinviebr...@gmail.com wrote:
I'm trying to write a rule to catch a bunch of spam I'm getting recently that
Thanks for the link. That'll help.
In general, though, can I write a SA rule that looks at the raw message body
with trying to decode attachments, etc.? I thought that would be the
easiest way to catch these messages (and some other spam that comes in as
PNG files).
- Colin
--
View this
27 matches
Mail list logo
