on 2/19/02 9:34 PM, dman at [EMAIL PROTECTED] wrote:
> Is it possible to not use the AWL at all? I don't want to use a
> SQL-based system (at least not at this point), but I don't mind if the
> dir-based system is dropped as long as SA still runs :-).
Of course! Just don't use the -a flag.
C
On Tue, Feb 19, 2002 at 05:20:42PM -0800, Craig Hughes wrote:
| Does anybody need directory based (ie non-db based) auto-whitelists?
| It's going to be a real pain in my ass to extend the current
| DirBasedAddrList to the newly updated Autowhitelist setup. I'd rather
| just drop it, since it's p
Hi,
I'm trying to install SpamAssassin on my server, but I'm running into some
problems. I did a "install Mail::SpamAssassin" in perl's CPAN and I get the
errors below and I'm not really sure what to do. Can someone help me out
with this problem? Thanks! I'm using RedHat Linux 6.2.
--- snip ---
Oh yeah, I forgot to add implementation details:
The new DBBasedAddrList creates backward-compatible DB files. It stores the
count of messages for a user as an int keyed by the email address (with some
characters converted to _), and the total accumulated score for the user is
a floating point n
The subject says it all. I am running SA2.01 on a mid-size ISP (~3000
"average joe" clients) and have been manually going through about 2500 spam
messages a day to ensure that no false positives are getting killfiled.
I get about 2-3 false positives per day, which really isn't bad. I've
modi
Ok, it's done. That was the last thing on the list to get done before a
2.1 release, so now I think I'll go ahead and release in a day or two
(after people have a chance to notice that the new stuff is broken).
Here is a description of how the changed AWL stuff works:
One major thing: the AWL i
http://www.hughes-family.org/bugzilla/show_bug.cgi?id=34
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://www.hughes-family.org/bugzilla/show_bug.cgi?id=34
This bug depends on bug 23, which changed state:
What|Old Value |New Value
Status|ASSIGNED|RESOL
As I was re-writing AWL just now, I noticed that in fact the way
checking is set up, it kind of has been planning to do something like
this for a while now. I'll think about it on the 2.2 timeline --
probably combining in some of the other ideas from the "spamassassin in
100% C" discussion as wel
Does anybody need directory based (ie non-db based) auto-whitelists?
It's going to be a real pain in my ass to extend the current
DirBasedAddrList to the newly updated Autowhitelist setup. I'd rather
just drop it, since it's pretty kludgy anyway...
Let me know if it's an absolute must keep, and
Morning all ...
I think I've set everythign up right ... fixed the Mail::Audit
issue as recommended on the list, manually run /usr/local/bin/spamproxyd
from the command line, then change main.cf to add:
content_filter = smtp:localhost:10025
and master.cf to add:
localhost:1002
Hi,
I don't know if this is already in the current version but maybe if a piece
of mail already matches a set threshhold (say 10 points) then the RBL and
razor checks are not performed.
The majority of spam I see getting caught are already caught because of the
regxeps and the additional time to
On 18 Feb 2002 at 17:01, Daniel Rogers wrote:
> Recently, we've been the unfortunate recepients of several spams that are
> sent so quickly as to cause spamassassin to overwhelm our mail server.
>
> Here's what happens:
>
> Spammer connects to smtp port, gives his helo and mail from, then gives
On Tue, 2002-02-19 at 14:57, Charlie Watts wrote:
> > but procmail can...
> > (assuming there is a razor client somewhere)
>
> No, it can't. The procmail interfaces to DNS Blacklists are all call-out
> programs ... it is possible to parse out the received headers and pass
> those to a dns looker-
On Tue, 19 Feb 2002, Arpi wrote:
> > 3. Allow for far greater loads than will fit on a single mail processing
> > machine (regardless of how many CPUs you cram in your starfire box) by
> > enabling the processing load to be spread around a network. The network
> ok, you're right here, i must agr
Hi,
> > For the perl version, spamd+spamc solution (i would call it a messy
> > hack) is a workaround for perl's 'booting/startup' overload.
> It's really not so messy of a hack, and it's designed for a couple
> purposes:
>
> 1. work around perl's 'booting/startup' overload (though this would b
On Tue, 2002-02-19 at 13:02, Arpi wrote:
> Hi,
>
> > I think what would be a lot more interesting is spamd in C or C++. The
> > major benefit I can think of of going to C is performance (though I'm
> > not necessarily convinced you'll beat perl for doing text processing),
> > and if performance
I love getting credit for that sort of thing. Glad to help. Even if I was
just regurgitating things folks have told me before.
On Tue, 19 Feb 2002, Uwe Willenbacher wrote:
> Again, thanks to Charlie Watts, I was able to compile spamc and it is
> happily working on my Solaris box -- I really app
Hi,
> I think what would be a lot more interesting is spamd in C or C++. The
> major benefit I can think of of going to C is performance (though I'm
> not necessarily convinced you'll beat perl for doing text processing),
> and if performance is what you care about, you'll be wanting to use
> sp
Again, thanks to Charlie Watts, I was able to compile spamc and it is
happily working on my Solaris box -- I really appreatiate your help. Not
being a programmer, I can only imagine working with "us whiners":)
- Uwe
--On Tuesday, February 19, 2002 12:15 PM -0800 Craig Hughes
<[EMAIL PROTECTE
On Tue, 2002-02-19 at 03:56, Arpi wrote:
> so, my primary goal: make a small but very fast, efficient version to be
> used on very high traffic mail servers. and, by allowing several instances
> at the same time make possible to profit from SMP.
> (afaik spamd only processes a single mail at the s
I think what would be a lot more interesting is spamd in C or C++. The
major benefit I can think of of going to C is performance (though I'm
not necessarily convinced you'll beat perl for doing text processing),
and if performance is what you care about, you'll be wanting to use
spamd anyway, not
It looks like TRU64 doesn't define EX__MAX in sysexits.h, same as
SunOS. Do you know what preprocessor symbols TRU64 sets? Then we can
modify that conditional compile section to work for TRU64 too.
C
On Tue, 2002-02-19 at 00:20, Corrin Lakeland wrote:
> cc -std -fprm d -ieee -D_INTRINSICS -I/u
Dammit, that's the change I made to get it to compile on whatever that
other platform was. I think I'll actually change it back, because I
suspect that one guy's setup was just not right. I'll revert
Makefile.PL to link spamc against the same libs perl was linked
against. It's overkill, but it'
On 18 February 2002, Justin Stayton said:
> Hi Everyone,
Hi. You should throw a clue-brick at your ISP: your message was flagged
as spam because your relay host (130.94.172.43, aka
host3.createyourownhosting.com) is in three separate RBL blacklists.
Here's the SA report:
X-Spam-Report: 7.5 hi
Hi,
> > There are many pros and contras to C version, i won't list these, it's on
> > your fantasy.
>
> I can imagine a few of them, but am curious what you are thinking of as
> the pros and cons.
ok...
pros:
- portability (on unix platforms)
- much better speed (on my test p3 perl version with
On Tue, 19 Feb 2002, Arpi wrote:
> I'm working on a partial rewrite of SpamAssassin in plain C language, using
> the PCRE library for regexp matching.
> Thanks to the nice ruleset format, it is able to parse and use the .cf files
> without any change. Currently only regexps are parsed and checked
On Sun, 2002-02-17 at 22:02, Craig Hughes wrote:
> For the envelope TO, there seem to be 2 "standards", depending on when
> the info is added to the message header. One is added on SMTP-reception
> (such as with exim I think), in which case the header used is
> "Envelope-To".
Actually any head
Hi
Running v1.5 (installed by my system administrator) the message below was
caught and marked as spam (only just though)
Glenn.
SPAM: Start SpamAssassin results
--
SPAM: This mail is probably spam. The original message has been altered
SPAM: so you can
Hi,
I'm working on a partial rewrite of SpamAssassin in plain C language, using
the PCRE library for regexp matching.
Thanks to the nice ruleset format, it is able to parse and use the .cf files
without any change. Currently only regexps are parsed and checked, but i'll
implement the most importa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to install SpamAssassin (2.01) as a normal user on an old Tru64
system. The system's admin seemed mildly interested so if any of your
debugging suggestions need root I might be able to get her to help.
The installation initially ba
31 matches
Mail list logo
