First off, this question is appropriate for the users list, not here. Next: see "trusted_networks" and "internal_networks".
Finally: the Shortcircuit plugin in SpamAssassin 3.2.0 will allow efficient scan short-circuiting. --j. Laurent Neiger writes: > I belong to the system and network team of grenoble.cnrs.fr, which is the > domain of a french public research center. > > I will ask my question here at the top of my message for those of yours > who don't have much time (What ? All of you ?! ;-) ) and details and > configuration are given after. > > Is it actually possible to exclude a domain to be checked by spamassassin ? > And except from some machines ? > Typically we would like emails coming from our domain grenoble.cnrs.fr, > when submitted to spamd, beeing recognized and accepted immediately > without parsing the rules, except if coming from xxx.grenoble.cnrs.fr or > yyy.grenoble.cnrs.fr, which must be checked as they are some kinds of > reflectors (a.k.a. list servers, etc.) and so could propagate spams. > In other words how could we add a new first rule which would say : > if from grenoble.cnrs.fr, exit immediately, except if from > xxx.grenoble.cnrs.fr > ou yyy.grenoble.cnrs.fr ? > > > And secondly, is it possible to configure spamd to give up parsing after > a certain amount of points ? I mean while attributing points to a message, > if reach 20 for example, stop processing rules and take time as from this > level we know it is spam and we don't care it reach 50 or 70 points ! > > Tiebreaker : if the above is not already possible, can you give us hints > to where in the spamassassin code we could add these tests ? > > Many many thanks in advance ! > > Best regards, > > Laurent. > > ========== > > We operate an etch debian linux server : > > [EMAIL PROTECTED]:~# uname -a > Linux srv1.grenoble.cnrs.fr 2.6.12-rc4-mm2-cric #1 SMP Mon Jun 6 > 14:36:41 CEST 2005 x86_64 GNU/Linux > > owning (among others) postfix, qpopper and spamassassin. > > Here is the version of our spamassassin : > > [EMAIL PROTECTED]:~# dpkg -l | grep -i spamassassin > ii spamassassin 3.1.7-1 Perl-based spam filter using text analysis > ii spamc 3.1.7-1 Client for SpamAssassin spam filtering > daemon > > running, as you can see, on the spamc/spamd mode. > > spamd is running in daemon mode and spamc is activated by procmail while > delivering > in local (not launched by postfix but by procmail). > > We receive a very huge amount of spam and spamassassin is really doing a > great job > in ratio filtering (e.g. 10-20 spams delivered for ~8000 received). > > But we have a big problem of saturation, as our mailq is beeing filled > almost quicker than > it is flushed... > We have a huge amount of pending e-mails, waiting to be processed by > spamassassin : > for 100-200 in good days to over 10000 when beeing suffering a spam storm. > > Our problem is a hard-disk access problem, not a memory nor cpu one. cpu > and memory > are not saturated, but concurential access to the disk seem to be the > problem. > A spam takes about 6-10 seconds to be processed and while one is > processed two more arrive... > > Playing with setting does not work out in our context. > To be short we have tried use_bayes, use_dcc, use_pyzor, use_razor2 and > skip_rbl_checks > options with all the combinations to work out what was taking time, and > tried different numbers > of spamd children (5, 10 20, 25, 50) as cpu and memory are available on > our server. > > None of these settings helped us. > > What we see is for example if there is 1000 mails in our mailq, about > 100 are outgoing emails > (temporarely error (SMTP 4XX) or greylisting from remote sites waiting > to be re-processed, etc.) > but the other ones are emails destinated to our domain grenoble.cnrs.fr > waiting for spamd children > to be available... > And into these ones, some are from our domain too. > That mean that when I'm sending an email to my colleague whose desk is 2 > meters from mine, > sometimes he received it 15 minutes later ! > We'd like to reduce the processing time at least for our local mails ! > > If the spams take 30 mn to be discarded, we don't mind, it is not > important. But for local mail > it is not really acceptable. > > > Once more may thanks for your help to the 2-3 questions at the start of > these mail, > and congratulations for the ones who have read it entirely ! > > Staying at your disposal, > > Regards, > > Laurent. > part 1.2 text/x-vcard 433 > begin:vcard > fn:Laurent Neiger > n:Neiger;Laurent > org;quoted-printable:CNRS Grenoble;Centre R=C3=A9seau & Informatique Commun > adr:;;25, avenue des Martyrs;Grenoble;;38042;France > email;internet:[EMAIL PROTECTED] > tel;work:(0033) (0)4 76 88 79 91 > tel;fax:(0033) (0)4 76 88 12 95 > note:Certificats : http://igc.services.cnrs.fr/Doc/General/trust.html > x-mozilla-html:TRUE > url:http://cric.grenoble.cnrs.fr > version:2.1 > end:vcard
