You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/07/10 04:27:12 UTC

Re: Rules compiled as subroutines?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ewan Edwards writes:
> Hi list,
> 
> I'm curious about the mechanism for processing rules, specifically, is there 
> a distinct advantage to compiling rule subroutines into the 
> Mail::SpamAssassin::PerMsgStatus namespace compared to, say, using anonymous 
> subs?

Hi Ewan --

the main reason that is done is so that we can use perl's Devel::DProf
module to profile and identify slow rules.  It works well, and there's
not a whole lot of effort beyond using anon subs.

> I'm trying to get per-user rules running within the spamd environment as it 
> is not feasible to invoke spamassassin per message delivery given current 
> mail volumes on our servers. Also, per-user rules are becoming a necessity 
> since the default rule sets (SA 2.6.3) are no longer very effective against 
> current spam.
> 
> None of the user's rules will require the eval:method(args) facility, 
> however, multiple users may use the same name.

Any problems with "allow_user_rules"?  that should work....

> Unless there is an advantage to using named subroutines, I will be modifying 
> PerMsgStatus.pm to process rules directly. Should the eval: rule definition 
> facility become required, I would use anonymous subs, so that multiple 
> users' rules do not conflict with each other.
> 
> If there are no real complaints about this sort of modification, would a 
> patch for the change be welcome?

yep, unless allow_user_rules works OK ;)

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFA71P/QTcbUG5Y7woRAktRAJ9gvn7Pd/UCvDUayKgNQh7oIEKZCQCgp1Qj
m2jAleZDN72F297H2wFAHhw=
=FzjF
-----END PGP SIGNATURE-----