On 08/23/2014 09:36 AM, Carlos E. R. wrote:
As for using "an external dynamically modified list with SA", here's what I do - my whitelist is just an SA ruleset called whitelist.cf (for instance). When I modify it, I copy it to the servers that run SA, and do an "rcspamd reload". (of course this is all automated). I'd be interesting in learning more details about that ;-)
Its a ridiculously simple rule and comes from a list of recipes I found on the 'Net ---------------- here you are... AGAIN ----------- # Test if the email's sender is whitelisted; if so, send it straight to # $DEFAULT. Note that this comes before any other filters. :0: * ? formail -rt -x"From" -x"From:" -x"Sender:" \ -x"Reply-To:" -x"Return-Path:" -x"To:" \ | egrep -is -f ${HOME}/.whitelist { LOG="Found on whitelist$NL" $DEFAULT } -------------------------------------------- Actually there's a short-form for all that, but this illustrates clearly Key is a simple grep against a list of patterns. On the machine this originally ran on, formail and grep were small and fast and used already cached libraries. grep is amazingly fast. Compared to starting perl and loading script and having spamassassin precompile... Well yes, running spamd/spamc changes all that, but not as much as you might think. When you start spamassassin or spamd it start perl and reads in the basic script *and* *compiles* it if you don't have the precomplied version. If you are calling spamassassin from the procmail or most of the other configs I know its gets this done on a per message basis. Starting perl is heavy. That why we use spamd/spamc that has it started already. Only the version running as a daemon is not user-specific, it still has to read all the per user settings and compile them as well. And yes this gets one on a per message basis. Its a lot better than having to start perl on a per message basis! But the custom use settings, that per user whitelist stuff, still gets read in and compiled and the modules found etc etc. So what it comes down to is this: what's the process switching overhead? The spamd/spamc method involves a lot of blocking and system calls and switch of execution processes. How well that is handled varies with CPU and memory. I measured this with the old machine and it was neck and neck. I know I could make my procmail more efficient, doing the 'formail' one "up-front", for example rather than in each module. I often prefer clarity over efficiency (one reason I don't use C or C++ any more and prefer scripting languages, even Perl). The reality is that it may be years before I come back to do 'maintenance' and the least bit of obscurity makes life too difficult. Once in upgrade I had something about spamd fail. I forget the details but think it was to do with perl. But the bulk of procmail still worked, formail, grep. So my mail came though and whitelisting and blacklisting and all the pre-spam checking such as the Asian character set was filtered out. To be honest it was a few days before I noticed the problem, mail was flowing so well. I like robustness and resilience and 'fail-soft'. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org