Filter::SpamAssassin

I made a version of Filter::SpamAssassin that works with the
latest/greatest versions of both SpamAssassin and RT.

http://www.documentroot.com/SpamAssasin.pm

I didn’t want to muck about with fetchmail, procmail or anything else
to get it to work, and the version that was out there didn’t seem to
work at all… maybe some version of SpamAssassin grokked MIME:Entity

  • but not mine, as_string is safe though… should work for a long
    time.

It supports the “spamd” daemon, which may or may not improve
performance (but certainly allows some scalability) depending on how
you implement your version of RT

  • Erik

Sorry I forgot the extra “s”

documentroot.com/SpamAssassin.pm

  • ErikOn Thu, Aug 7, 2008 at 5:36 AM, Erik Aronesty erik@q32.com wrote:

I made a version of Filter::SpamAssassin that works with the
latest/greatest versions of both SpamAssassin and RT.

http://www.documentroot.com/SpamAssasin.pm

I didn’t want to muck about with fetchmail, procmail or anything else
to get it to work, and the version that was out there didn’t seem to
work at all… maybe some version of SpamAssassin grokked MIME:Entity

  • but not mine, as_string is safe though… should work for a long
    time.

It supports the “spamd” daemon, which may or may not improve
performance (but certainly allows some scalability) depending on how
you implement your version of RT

  • Erik

Has anyone gotten this to work? I know Erik posted a revised version
back in August,
but I’ve been playing around with it, and it seems the original sample
filter made many
many bad assumptions (and also that Interface/Email makes it very very
hard on the
filter writer). Besides Erik’s discovery of problems with MIME::Entity
objects being
passed on to SpamAssassin, it seems filters cannot expect to be handed
a real user
name or authlevel, and figure out the former for themselves?

Cambridge Energy Alliance: Save money. Save the planet.

Hi Pierce,

I have it working fine, tho there was a problem with the Auth and I
think the solution was to put spamassassin before Auth

Set( @MailPlugins => “Filter::SpamHeader”, “Auth::MailFrom”);

w.

Jerrad Pierce wrote:

Has anyone gotten this to work? I know Erik posted a revised version
back in August,
but I’ve been playing around with it, and it seems the original sample
filter made many
many bad assumptions (and also that Interface/Email makes it very very
hard on the
filter writer). Besides Erik’s discovery of problems with MIME::Entity
objects being
passed on to SpamAssassin, it seems filters cannot expect to be handed
a real user
name or authlevel, and figure out the former for themselves?

Richard Wood (Woody)
Managing Director
Wild Thing Safaris Ltd.
PO BOX 34514 DSM
Office: +255 (0) 222 617 166
Mobile: +255 (0) 773 503 502

http://www.wildthingsafaris.com
http://www.wildthingsafaris.com/pub/woody.html

Hi Pierce,

I have it working fine, tho there was a problem with the Auth and I think
the solution was to put spamassassin before Auth

Set( @MailPlugins => “Filter::SpamHeader”, “Auth::MailFrom”);

Aha! That makes much more sense. So it’s a bug/ambiguity in the
documentation. Thanks so much!

I will soon have an updated version of Erik’s module that offers more
options. In particular, it will allow you to defer to existing X-Spam
headers (in case say, your mail sever is already doing them) which
significantly increases responsiveness.

Cambridge Energy Alliance: Save money. Save the planet.