This has come up before a few times (not quite an FAQ though). The concensus at the end of the discussion ends up being that deciding whether or not to process mail through SA is best handled upstream of SA -- why invoke SA at all if you don't want to invoke it? The way you handle the should-SA-be-invoked thing will depend in practice on how you're planning to call SA -- if from procmail, then you can check for the presence of a magic file in $HOME, and invoke SA only if it exists (or doesn't exist). If you're invoking more directly from your MTA, you might be able to setup a transport map file or something, which will handle the incoming mail differently based on recipient.
C Marc G. Fournier wrote: MGF> MGF> Guess this is more for Craig directly, but has anyone thought to add a MGF> simple 'spamassassin=on' user preference? I'm looking at implementing MGF> spamassasin on a 4k+ mail server, but we want to default it to being off MGF> ... what we are looking at is increasing the required to some arbitrarily MGF> high number, so that it just never gets triggered, but even better would MGF> be to be able to turn it off so that no headers get added period, so that MGF> its being there is *totally* transparent to the end user unless they MGF> enable it ... MGF> MGF> I know there is hte 'size limit' one, where if its over X size, it just MGF> passes it through, so shouldn't be that hard to add an 'on / off' switch MGF> to the user preferences to do similar, should it? _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
