Hi
I have upgraded my spamassassin to version 3.1.7 and after the restart
of the process I have saw an increment of the use of the ram.
I use the default rules of the spamassassin and the following rules:
53K Apr 20 11:00 70_sare_adult.cf
3.8K Jun 2 2005 70_sare_bayes_poison_nxm.cf
24K
4.7M Oct 10 03:00 blacklist-uri.cf
Remove this and use URI blacklists instead. Notice how this rule's size is
orders of magnitude greater than any of the others you listed? Same goes for
its RAM footprint.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
...Life is not a journey to the
Pooser [mailto:[EMAIL PROTECTED]
Sent: martedì 10 ottobre 2006 18.09
To: users@spamassassin.apache.org
Subject: Re: use of ram after upgrade
4.7M Oct 10 03:00 blacklist-uri.cf
Remove this and use URI blacklists instead. Notice how this
rule's size is orders of magnitude greater than any
'refs'; under that. Or something down that road. Look at http://perldoc.perl.org/strict.htmlfor more information.
-Sietse
From: ChrisSent: Mon 18-Sep-06 4:24To: users@spamassassin.apache.orgSubject: Problem after upgrade to Net::DNS 0.58
I'm running SA 3.1.5 and this evening upgraded to the above
On Monday 18 September 2006 8:13 am, Sietse van Zanen wrote:
Probably the writers of the module have decided to use strict references
in their programming.
You can do 1 of 2 things:
1. donwgrade back to 0.53.
2. edit the perl source for the new module and disable strict references.
There
I'm running SA 3.1.5 and this evening upgraded to the above version of
Net::DNS. Since then periodically I've been seeing this in my syslog:
Sep 17 20:27:04 localhost spamd[1126]: Can't use string (Net::DNS::RR::MX)
as a HASH ref while strict refs in use
at
On Sunday 17 September 2006 9:24 pm, Chris wrote:
I'm running SA 3.1.5 and this evening upgraded to the above version of
Net::DNS. Since then periodically I've been seeing this in my syslog:
As another question to this, I did an upgrade to the module instead a
removing the older version and
Sorry I took so long to respond to this. Of course it was me who
should RTFM :-P Since we are using CGPSA we are not using SPAMD if I
understand it right. From the CGPSA website ( http://
www.tffenterprises.com/cgpsa/ ):
The filter works efficiently, by directly using the SpamAssassin
| Subject: Re: [Bump] No log to syslog after upgrade
|
|
| Kurt Buff wrote:
| I've requested an account, and am waiting for the password.
|
| I understand about command line tools and their use, but SA
| is a bit of a
| special case, as it's used as more than simply a command line tool
Still not resolved. Any help appreciated.
Could this be of help?
[server]spamassassin --lint -D
[22110] dbg: logger: adding facilities: all
[22110] dbg: logger: logging level is DBG
snip
TIA
Thomas
After our upgrade from SA 2.6.3 to SA 3.1.3 we do not get any logs
written to
On Thu, 7 Sep 2006, Thomas Ericsson wrote:
[server]spamassassin --lint -D
[22110] dbg: logger: adding facilities: all
[22110] dbg: logger: logging level is DBG
snip
Is your syslog daemon configured to discard debug-level messages?
Are the messages being logged to /var/log/message (or
On Thu, Sep 07, 2006 at 09:11:22AM -0700, John D. Hardin wrote:
[server]spamassassin --lint -D
[22110] dbg: logger: adding facilities: all
[22110] dbg: logger: logging level is DBG
snip
Is your syslog daemon configured to discard debug-level messages?
[...]
At last check, spamassassin
| From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
| On Thu, Sep 07, 2006 at 09:11:22AM -0700, John D. Hardin wrote:
| [server]spamassassin --lint -D
| [22110] dbg: logger: adding facilities: all
| [22110] dbg: logger: logging level is DBG
| snip
|
| Is your syslog daemon configured to
On Thu, Sep 07, 2006 at 01:26:08PM -0700, Kurt Buff wrote:
Perhaps an invocation flag could be added?
You can feel free to open an enhancement BZ ticket if you like.
Generally speaking commandline tools don't log to syslog though.
--
Randomly Generated Tagline:
If ignorance is bliss, why
-
| From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 07, 2006 13:32
| To: users@spamassassin.apache.org
| Subject: Re: [Bump] No log to syslog after upgrade
|
|
| On Thu, Sep 07, 2006 at 01:26:08PM -0700, Kurt Buff wrote:
| Perhaps an invocation flag could be added?
|
| You
Entered as # 5093.
| -Original Message-
| From: Kurt Buff
| Sent: Thursday, September 07, 2006 14:27
| To: users@spamassassin.apache.org
| Subject: RE: [Bump] No log to syslog after upgrade
|
|
| I've requested an account, and am waiting for the password.
|
| I understand about
Kurt Buff wrote:
I've requested an account, and am waiting for the password.
I understand about command line tools and their use, but SA is a bit of a
special case, as it's used as more than simply a command line tool -
especially when you consider its use with Amavis, etc.
amavisd-new has
After our upgrade from SA 2.6.3 to SA 3.1.3 we do not get any logs
written to /var/log/mail.log anymore. Any ideas why this could be?
Here's our setup: OSX 10.3.9, Communigate 4.2.8, CGPSA 1.4, SA 3.1.3
Thomas Ericsson
I just updated to a newer version of spamassin a few days ago.
Since then I'm getting regular error messages in my spamlog:
Sep 2 03:46:03 Ishtar spamd[13106]: (?:(?=[\s,]))* matches null string
many times in regex; marked by -- HERE in m/\G(?:(?=[\s,]))* -- HERE
\Z/ at
On Sat, Sep 02, 2006 at 04:10:45AM -0700, Linda Walsh wrote:
Am I missing some needed configuration somewhere, or is the
above a problem?
It seems to be happening with every message.
It's a bug in Text::Wrap. See
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5056
--
Randomly
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info: rules: meta test
On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote:
Steven Stern wrote:
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
...etc
It's just info. Some of your rules have
John D. Hardin wrote:
On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote:
Steven Stern wrote:
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
...etc
It's just info. Some of your
On Thu, Jul 27, 2006 at 11:21:54AM -0700, John D. Hardin wrote:
I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version
bugfix) upgrade shouldn't suddenly make a bunch of previously-working
rules simply disappear...
This wouldn't make rules disappear. It's informational output, but
Hi!
It's just info. Some of your rules have undefined dependencies or are
disabled via a zero score.
That's fairly obvious from the warning message.
I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version
bugfix) upgrade shouldn't suddenly make a bunch of previously-working
On Thu, 27 Jul 2006, Theo Van Dinter wrote:
Does the upgrade do something like change the default local rules
path, such that the dependency rules can no longer be found? Etc.
No, the rules would likely have had these issues for a while (I
can't really comment on non-official rules), but
Does the upgrade do something like change the default local rules
path, such that the dependency rules can no longer be found? Etc.
No, the rules would likely have had these issues for a while (I
can't really comment on non-official rules), but with 3.1.4
there's now info output
Dear Groupmembers,
I am trying to upgrade using perl butit still shows Mail::SpamAssassin isuptodate. Let me know whether the version 3.1.4 is released for perl installation.
regards
On Fri, Jul 28, 2006 at 12:52:42AM +0530, sokka wrote:
I am trying to upgrade using perl butit still shows Mail::SpamAssassin
isuptodate. Let me know whether the version 3.1.4 is released for perl
installation.
It's not quite clear what you're asking. I think you're
asking if 3.1.4 is
On Fri, 28 Jul 2006, sokka wrote:
I am trying to upgrade using perl butit still shows Mail::SpamAssassin
isuptodate. Let me know whether the version 3.1.4 is released for perl
installation.
If you're using a CPAN shell, you may need to give the command
reload index for it to grab the latest
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Steven Stern wrote:
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has
undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info:
Bret Miller wrote:
So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work?
Disabled means disabled. Disabled rules are never run.
Quoting the relevant score config info from M:SA:Conf POD:
score SYMBOLIC_TEST_NAME n.nn [ n.nn
On Thu, Jul 27, 2006 at 02:48:06PM -0700, Bret Miller wrote:
So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work? Didn't work before
either?
It may have worked somewhat, but probably not as intended. It really depends
on the
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Bret Miller wrote:
So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work?
Disabled means disabled. Disabled rules are never run.
Quoting the relevant score config info from M:SA:Conf
From: Theo Van Dinter [EMAIL PROTECTED]
Don't confuse the meta rule is executed with the meta rule works
as expected.
Sorry, the bad conclusion was already made and depended upon for
proper operation without cluttering the header streams or the report
fields. So the question becomes, What is
jdow wrote:
The wording back then suggested you could write a META
rule with components scored zero so that they would not report but the
META would still work.
If I read the runes a-right, that's still how META rules work. Create a
rule like this:
body __CONDITION_1 /something/
On Thu, Jul 27, 2006 at 03:53:08PM -0700, jdow wrote:
If the scores are printed out in header fields the scores field can very
quickly exceed the 4k size limit. This is not a good thing.
Meta subrules (those that start with __) aren't displayed as part of the
standard rules hits.
--
Randomly
On Thu, Jul 27, 2006 at 03:48:29PM -0700, jdow wrote:
If you disable a rule it doesn't run. Period. When your eval is run
it'll use a false result in place of a disabled rule. Thus is the rule is
a required part of the meta (it's ANDed) then the meta will never fire.
If it's an optional
On Thu, Jul 27, 2006 at 06:20:57PM -0700, jdow wrote:
Even that is not clear. The way I interpret that NOW is that the
__METARULE needs a score of some sort or it will not ever contribute
to a META rule except via a default score that is independent of the
Yes, a subrule (__) needs a score to
From: Theo Van Dinter [EMAIL PROTECTED]
Yes, basically. However, all rules (ignoring test rules (starts with T_)) get a
score of 1 by default, so you don't need to specifically set a score for
__METARULE. In the end, as long as __METARULE doesn't have a score of zero,
it runs.
So far that
Hi,I have updated my SA installation yesterday. Most but not all seems to run well.In my mail.log I constantly find these errors all referring on some methods called from PerMsgStatus.pm:snip
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run __ENV_AND_HDR_FROM_MATCH SpamAssassin test,
Thomas Schlosser [EMAIL PROTECTED] [10-06-2006 15:38]:
[...]
I updated it via perl -MCPAN - e shell - force install Mail::SpamAssassin
The output was too long to have a chance to see if any problems have been
reportet.
New SA should have been installed somewhere around /usr/local (if your
perl
Thanks for the immediate answer!It seems that the old SA was under /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/while the new one under /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/rpm reported two packages spamassassin and perl-spamassassin.
I have deinstalled these using YAST (rpm
Jean-Paul Natola wrote:
Hi all
After upgrading to 3.1.1
I'm getting a bunch of
[36993] warn: config: SpamAssassin failed to parse line,
SARE_RMML_Stock27_.166 is not valid for score, skipping:
score_SARE_RMML_Stock27_.166
Is there something , or should I say, what step did I
On Wed, Mar 22, 2006 at 02:56:22PM -0500, Matt Kettler wrote:
score SARE_RMML_Stock27 .166
actually it should be score SARE_RMML_Stock27 0.166. not having a
leading 0 is invalid.
--
Randomly Generated Tagline:
Is there a space between the wall and paint? - Bob Lazarus
pgp2A4wCXStMA.pgp
Jean-Paul Natola wrote:
Hi all
After upgrading to 3.1.1
I'm getting a bunch of
[36993] warn: config: SpamAssassin failed to parse line,
SARE_RMML_Stock27_.166 is not valid for score, skipping:
score_SARE_RMML_Stock27_.166
Is there something , or should I say, what step did I miss?
Got this patch from a FreeBSD user yesterday. I tested it for a day and
all seems just fine.
This backs out the 3.1.1 change and reverts to the 3.1.0 behavior.
This
leaves some 3.1.1 CRLF code in Message.pm, but it now has no effect.
Normal processing of the headers fixes any trouble I was
Paul,
Thanks for posting the patch.
This works, I just tested it. I also forwarded it to Dan Nelson
(spamass-milter). I'm not certain this is the correct way to fix
it, though. Will let you know if I hear more.
Thanks.
Paul Stavrides wrote:
version=3.1.1
On Thu, Mar 16, 2006 at 12:33:50AM -0600, David B Funk wrote:
Silly question; would it be sufficient for the milter to just canonicalize
the message that it passes to SA by converting CRLF to a plain LF?
Or better, do the inverse of SA; for it to look at the first line of
the message and if
Theo, Carl,
I poked around the code this morning and I think for us, this is going
to be a tougher problem to solve than I first thought.
Theo, you are correct AFAIK the calls to the library routines
responsible for wrapping lines and adding in the \t chars are confused
by the lines they are
Since I upgraded, I'm seeing bits of the X-Spam-Header message
in my mail bodies, like this :
The latest version changed things to make life on Windows systems better.
Instead of always using a \n for a line ending, it looks at the kind of line
ending it got on the first line of the input file,
On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
rollcage2.bl.echidna.id.au
It looks like sometimes
Theo Van Dinter wrote:
On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
rollcage2.bl.echidna.id.au
It looks
Title: Header1
Felicity,
Thanks for the tips.
We too are having the problem of headers creeping into out
received e-mail. Difference here is that our setup is a Linux front end
to MSExchange. So we run SA site-wide and use Milter to keep the crap out
of Exchange. Works like a champ
On Thu, Mar 16, 2006 at 08:29:29AM +1100, Carl Brewer wrote:
Is this reproducable with spamassassin or spamc/spamd from a commandline?
I'm not sure, how would I test it?
Something similar to spamassassin file_with_message or
spamc file_with_message if you want to test spamd.
--
Randomly
Paul Stavrides wrote:
Felicity,
Thanks for the tips.
We too are having the problem of headers creeping into out received
e-mail. Difference here is that our setup is a Linux front end to
MSExchange. So we run SA site-wide and use Milter to keep the crap out
of Exchange. Works like
On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:
The problem is an extra an extra 0D in the X-Spam-Checker-Version
line, such that I see an ...0D 0D 0A 09... by the time I look at the
headers in Windows. The line is getting munged when it is getting
wrapped.
Interesting. I
Theo Van Dinter wrote:
On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:
The problem is an extra an extra 0D in the X-Spam-Checker-Version
line, such that I see an ...0D 0D 0A 09... by the time I look at the
headers in Windows. The line is getting munged when it is getting
On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:
Previously, the milter could assume that folding was going to happen via
\n\t, but now it's \r\n\t.
Does this mean that a change is needed in spamass-milter or
spamassassin? It seems odd that this started with 3.1.1 but
didn't
Theo Van Dinter wrote:
On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:
Previously, the milter could assume that folding was going to happen via
\n\t, but now it's \r\n\t.
Does this mean that a change is needed in spamass-milter or
spamassassin? It seems odd that this started with
Hello,
I just upgraded to 3.1.1 on a NetBSD box via pkgsrc, and
am using sendmail 8.13.5 with spamass-milter 0.3.0, and sendmail
is configured to use cyrus imapd as its local delivery agent.
Since I upgraded, I'm seeing bits of the X-Spam-Header message
in my mail bodies, like this :
To: Carl
Steven Manross wrote:
X-Spam-Status: No, score=-2.6 required=5.0
tests=AWL=0.023,BAYES_00=-2.599
autolearn=failed version=3.1.1
It seems that since upgrading to 3.11 last night, the
autolearn=yes|no|failed always shows up as failed (on all messages).
Did I miss something?
Generally
-Original Message-
From: Steven Manross
Sent: Monday, March 13, 2006 12:46 PM
To: users@spamassassin.apache.org
Subject: autolearn=failed after upgrade to 3.11
X-Spam-Status: No, score=-2.6 required=5.0
tests=AWL=0.023,BAYES_00=-2.599
autolearn=failed version=3.1.1
Steven Manross wrote:
It looks like the autolearn is working now.
Does anyone have any ideas on the misplaced headers? Or is that a new
de facto standard?
You mean this:
As well, the headers added by SA (and me [through SA] for MsgID) are now
showing at the top of the headers from the
-Original Message-
From: Matt Kettler [mailto:[EMAIL PROTECTED]
Sent: Monday, March 13, 2006 1:35 PM
To: Steven Manross
Cc: users@spamassassin.apache.org
Subject: Re: autolearn=failed after upgrade to 3.11
Steven Manross wrote:
It looks like the autolearn is working now
It seems that since upgrading to 3.11 last night, the
autolearn=yes|no|failed always shows up as failed (on all messages).
Did I miss something?
Generally Failed means that SA somehow can't access the
bayes database to write to it.
Have you tried sa-learn --sync and then
X-Spam-Status: No, score=-2.6 required=5.0
tests=AWL=0.023,BAYES_00=-2.599
autolearn=failed version=3.1.1
It seems that since upgrading to 3.11 last night, the
autolearn=yes|no|failed always shows up as failed (on all messages).
Did I miss something?
As well, the headers added by SA (and
Matt Kettler wrote:
...
Is the whole trusted_net, dnsbl business written up somewhere? I would
rather not waste your time; but searching the wiki doesn't turn anything up.
Not really, but I can go over it really fast..
First, SA parses all the received headers, in backward order,
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular I know that:
trusted_networks68.64/13
is no longer working because:
Content analysis details: (5.9 points,
Eric W. Bates wrote:
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular I know that:
trusted_networks68.64/13
is no longer working because:
Content
Matt Kettler wrote:
Eric W. Bates wrote:
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular I know that:
trusted_networks68.64/13
is no longer working because:
Eric W. Bates wrote:
Matt Kettler wrote:
Eric W. Bates wrote:
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular I know that:
trusted_networks68.64/13
is
Eric W. Bates wrote:
Eric W. Bates wrote:
Matt Kettler wrote:
Eric W. Bates wrote:
...
Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your
network
in the Received: headers?
No. But even if there were, wouldn't the rule fire on the offensive IP
rather than the
Eric W. Bates wrote:
Matt Kettler wrote:
Eric W. Bates wrote:
Matt Kettler wrote:
Eric W. Bates wrote:
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular
Eric W. Bates wrote:
Matt Kettler wrote:
...
No, it could fire on *ANY* external IP that isn't the first hop.
I don't think I was clear. I don't question that any IP in the chain
might cause the difficuly. I was questioning why, if 127.0.0.1 is the
problem, why it was reported as
Eric W. Bates wrote:
Eric W. Bates wrote:
Matt Kettler wrote:
...
No, it could fire on *ANY* external IP that isn't the first hop.
I don't think I was clear. I don't question that any IP in the chain
might cause the difficuly. I was questioning why, if 127.0.0.1 is the
problem, why it
Hello all,
I've upgrade SA 3.0.4 to 3.1.0 a few weeks ago and saw after a while,
that the db settings in mysql seem to be ignored. Making system wide
settings in local.cf are working.
Here my debug output from 3.1.0:
spamassassin -D --lint
[28039] dbg: logger: adding facilities: all
[28039]
On Mittwoch, 26. Oktober 2005 12:50 Thomas Booms wrote:
[28039] warn: lint: 5 issues detected, please rerun with debug
enabled for more information
Fix your config file, and do what above message suggests.
mfg zmi
--
// Michael Monnerie, Ing.BSc --- it-management Michael Monnerie
//
:
Alan Premselaar [EMAIL PROTECTED],
users@spamassassin.apache.org
Subject:
Re: spamassassin less effective after
upgrade to 3.1.0: some
checks no longer executed ?
Tom,
you may want to cross-post this to the mimedefang list. it's
likely
someone there may also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] writes:
Hi,
problem is solved.
i noticed via solaris' truss tool that mimedefang.pl didn't read
/usr/perl5/5.6.1/etc/mail/spamassassin. And this is the directory that
contained the v310.pre script which by default
Tom,
you may want to cross-post this to the mimedefang list. it's likely
someone there may also be able to help you.
I also run mimedefang but I haven't experienced these types of problems.
you may want to log in as the defang user and check the path and see if
there are any suspect
Only difference with my 'spamassassin --lint -D' output I saw was that
after the line 'uridnsbl: domains to query' I have a block of 14 lines
with 'dns: checking RBL sbl-xbl.etcetera' that you don't have. Probably
not important. And I can't see your SARE-rules getting loaded, in my
output I see
---
Menno van Bennekom [EMAIL PROTECTED]
13/10/2005 15:29
Please respond to mvbengro
To:
[EMAIL PROTECTED]
cc:
users@spamassassin.apache.org
Subject:
Re: spamassassin less effective after
upgrade to 3.1.0
[EMAIL PROTECTED]
13/10/2005 15:29
Please respond to mvbengro
To:
[EMAIL PROTECTED]
cc:
users@spamassassin.apache.org
Subject:
Re: spamassassin less effective after
upgrade to 3.1.0: some
checks no longer executed
?
Only difference with my 'spamassassin --lint
Hi,
I recently upgraded our mail relay software:
(sendmail is 8.13.3, but I didn't upgrade
this)
mimedefang from 2.51 to 2.53
razor2 from 2.67 to 2.77
dcc from 1.2.71 to 1.3.18
spamassassin from 3.0.2 to 3.1.0
we executed spamassassin via mimedefang's
mimedefang-filter file (and accompanying
I see that the site rules dir is /usr/perl5/5.6.1/etc/mail/spamassassin
according to the debug output, maybe you should check that your local.cf
v310.pre and sare-rules exist in that directory.
Regards
Menno van Bennekom
Hi,
I recently upgraded our mail relay software:
(sendmail is 8.13.3,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A tip: when the documentation says you need to read the UPGRADE
document, you really *do* need to read that document ;)
First item in
http://spamassassin.apache.org/dist/UPGRADE
will tell you what you need to know.
- --j.
[EMAIL PROTECTED]
@spamassassin.apache.org
Subject:
Re: spamassassin less effective after
upgrade to 3.1.0: some checks no longer
executed ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A tip: when the documentation says you need to read the UPGRADE
document, you really *do* need to read that document ;)
First
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] writes:
Hi Jim,
I suppose you're not referring to the fact that razor2 and dcc is
commented by default ? because i wrote in mail that i did uncomment them.
Tom --
doh! my mistake. Sorry about that.
I don't think anything
To:
[EMAIL PROTECTED]
cc:
users@spamassassin.apache.org
Subject:
Re: spamassassin less effective after
upgrade to 3.1.0: some checks
no longer executed ?
I see that the site rules dir is /usr/perl5/5.6.1/etc/mail/spamassassin
according to the debug output, maybe you
Bill Moseley wrote:
I updated two very similar Woody machines that day, and this machine
was trouble -- for some reason dist-upgraded removed a number of
packages for a reason I'm not clear on. (Like Apache and Bind!)
OT and probably too late, but in case anyone else's planning to do the
I'm stabbing in the dark a bit here, sorry.
I had a server running Debian Woody which was running, IIRC[1], 2.6x.
After upgrading to Sarge now running 3.0.3-2 and exim 4.50-8 the users
are complaining of a lot more spam getting through. I'm now seeing it
also -- looking at a few of my spam
From: Bill Moseley [mailto:[EMAIL PROTECTED]
I had a server running Debian Woody which was running, IIRC[1], 2.6x.
After upgrading to Sarge now running 3.0.3-2 and exim 4.50-8 the users
are complaining of a lot more spam getting through. I'm now seeing it
also -- looking at a few of my spam
Also make sure that if you are using bayes learning that spamassassin is
still able to read the bayes_ files. There must have been some
incompatibility with mine because I had to nuke everyones bayes_ files
and return sa-learn so that bayes started kicking in again. Also the
config problem that
From: Matthew Lenz [mailto:[EMAIL PROTECTED]
Also make sure that if you are using bayes learning that
spamassassin is still able to read the bayes_ files. There must
have been some incompatibility with mine because I had to nuke
everyones bayes_ files and return sa-learn so that bayes
On Fri, Oct 07, 2005 at 11:18:11AM -0400, Bowie Bailey wrote:
The most likely cause is a misconfigured trust path. 3.0.x introduced
the ALL_TRUSTED rule. This rule is supposed to fire with a negative
score if the message has not passed through any untrusted servers.
A common problem is that
On Fri, Oct 07, 2005 at 12:57:10PM -0400, Bowie Bailey wrote:
If you don't specify trusted_networks or internal_networks, SA tries
to guess at your network. It assumes that the first non-private IP
that it sees is your external mail relay. If your frontline
mailserver has a private IP, then
From: Bill Moseley [mailto:[EMAIL PROTECTED]
On Fri, Oct 07, 2005 at 12:57:10PM -0400, Bowie Bailey wrote:
If you don't specify trusted_networks or internal_networks, SA
tries to guess at your network. It assumes that the first
non-private IP that it sees is your external mail relay. If
hi!
i'm using 3.1.0 version on FreeBSD 5.4 and with MySQL 4.1.14.
My problem is that i can't add spam and ham after version upgrade.
i can reach the database, do sync or expire, so the db and the connection
works fine..
I attached the error log, I hope it helps..
Also attached the related files
101 - 200 of 261 matches
Mail list logo
