Robert Spier <[EMAIL PROTECTED]> wrote:
> In a perfect world, there would be a Mail::SpamAssassin::SpamC,
> or something.. a lightweight perl equivalent of spamc, so we
> wouldn't have to re-implement it.
True. It would also be nice if it were possible to get more
information from spamd, like t
On Nov 10, 2003, at 5:54 PM, Robert Spier wrote:
In a perfect world, there would be a Mail::SpamAssassin::SpamC, or
something.. a lightweight perl equivalent of spamc, so we wouldn't
have to re-implement it.
And so it wouldn't implode when they randomly break^H^H^H^H^H change
the protocol. :-)
> I don't think anyone was suggesting that Mail::SpamAssassin is
> lighter. The idea is to have spamd running and have the plugin
> communicate with it, as in the spamassassin plugin that's in
> cvs (and the various patches that have been posted to this
> list). The plugin acts as a client to
Skaag Argonius <[EMAIL PROTECTED]> wrote:
> That's true. It's much faster than running the spamassassin
> binary itself, since it's a relatively light client that
> communicates with a daemon that was alive anyway. But if using
> Mail::SpamAssassin is even lighter and maybe even faster, why
> not
Personally I don't like using Mail::Spamassassin. Its just a resource hog.
Really, the most efficient way is to just talk to spamd directly using
perl sockets. The most basic, and thus most impervious to different
versions of spamassassin is to use spamc. And, the most feature rich
way to go
That's true. It's much faster than running the spamassassin binary itself,
since it's a relatively light client that communicates with a daemon that
was alive anyway. But if using Mail::SpamAssassin is even lighter and maybe
even faster, why not :-)
My qpsmtpd does run under tcpserver. I heard abo
> Surely invoking an external binary is higher overhead than communicating
> with spamd directly?
The cost of executing 'spamc' is relatively cheap compared to qpsmtpd
in tcpserver mode. spamc is pretty damn light weight, especially with
the UNIX socket support in 2.60.
-R
Hi Andrew,
You'r right. I didn't think about that. Aran did write a replacement plugin
called spamassassin_direct.
However, I was under a lot of pressure to make it all work as smoothly and
quickly as possible.
This is why the plugin looks like it does. I will however try to make
another version w
On Mon, Nov 10, 2003 at 06:46:58PM -0800, Skaag Argonius wrote:
> * Some versions did not use spamc, resulting in unessecary overhead
Surely invoking an external binary is higher overhead than communicating
with spamd directly?
Regards,
*** Xanni ***
--
mailto:[EMAIL PROTECTED]
Hello guys! :-)
I've taken the time with all the versions of the spamassassin plugins that I
found on this mailing list, and came up with a version that works real well
for me.
Here's a list of the problems that I've managed to fixed, with my barely
minimal perl knowledge:
* Some versions died w
Gabriel Russell wrote:
what's the current state of spamassassin support? Is there is plugin in
cvs that works, and with which versions of sa?
Start with the CVS version and apply my patch here:
http://nntp.x.perl.org/group/perl.qpsmtpd/591
and the follow up patch by Keith Ivey:
http://nntp.
This message was cancelled from within Mozilla.
cvsuser 03/11/10 00:06:00
Modified:plugins milter
Log:
Doc fix.
Revision ChangesPath
1.2 +2 -2 qpsmtpd/plugins/milter
Index: milter
===
RCS file: /cvs/public/qpsmtpd/plugins/milter,v
re
13 matches
Mail list logo
