MCP Efficiency?

Glenn Steen glenn.steen at gmail.com
Fri Aug 18 19:42:31 IST 2006


On 18/08/06, Matt Kettler <mkettler at evi-inc.com> wrote:
> Julian Field wrote:
> > Sorry, just checked the code. I am doing that already.
> >
> > The cause of the problem is that SpamAssassin does not appear to support
> > the way I am trying to use it. I want 2 completely separate instances of
> > SpamAssassin. One has all the normal SA rules as expected. The other one
> > has no rules or dns checks or Razor or anything at all, it *only* has
> > the few rules specified for MCP checking.
> >
> > I can't make it do this, while still keeping all the rules compiled in
> > both instances and every setup done and cached. The only thing I can
> > make it do to run the way I want, is to tell it not to pre-compile all
> > the rules. As a result it has to do a huge load of SA compilation for
> > every message.
> >
> > If Matt Kettler is around, maybe he could offer me some advice. I have
> > tried asking on the SA list several times, and they don't understand why
> > I would want my 2nd instance at all, so I never got any helpful answers.
>
>
> I am around, unfortunately, this is completely out of my domain.
>
> I'm very familiar with SA configuration, rule writing, and how the behavior of
> the code affects rules and configuration. However, I have almost no familiarity
> with the perl API and making it do various things..
>
> As an educated guess, I'd suggest you'd have to have to:
>
> 1) point rules_filename to a directory containing a single empty .cf file, or
> perhaps just a copy of 10_misc.cf. If the directory passed doesn't exist, SA may
> wind up defaulting back to searching for a suitable equivalent to
> /usr/share/spamassassin.
>
> 2) set site_rules_filename to a directory containing just your MCP rules. Again,
> this would have to exist or SA will probably search for a suitable equivalent to
> /etc/mail/spamassassin.
>
> 3) userprefs_filename would also have to point to an empty file.
>
This is pretty much what is done in Jules code already ( well, the
directories and MailScanner.conf settings come into it too:-), at
least that is what I could deduce.
If I've (finally!) understood the problem correctly, the problems
arise from "contamination" between the otwo separate SA objects
instantiated for MCP and the regular SA run, resulting in the rule
caching mechanism getting somewhat confused. Did I finally get it
right Jules? :-)

Not sure what one could do to alleviate this, unfortunately.

-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se


More information about the MailScanner mailing list