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-----