> There are some rules, which will lead it to a high spam detection rate > and less crashes - but I know, not all can follow them for different > reasons.
Let's see if I'm a "good guy" and/or if I can at least follow some... > - read the startup log lines and follow the recommendations > you get from there ok for this > - if you are hosting multiple domains and they are very different in > there mail volume and/or content - try to handle them on different > assp's - block as early as possible heh, that would be good, but in some cases (e.g. charities or either no-profit) you ... use what you have; still, till now ASSP has been doing a good job ! > - block on handshake mistakes and IP's yes, that's another one; I routinely null-route bad IP *blocks* so that they won't even *reach* the ASSP port, but then, sometimes you can't just do that and... working on IP blocks is ok, but if you have to deal with single IPs the whole approach may quickly turn into a nightmare... am I missing something ? > - use the DNS based features (RWL,RBL,SFP,preDKIM/DKIM) ok, doing that > - if you use Bayesian - try to reduce the usage of large regular > expression. For example, the Bayesian check needs much less > system resouces as blackRe Already doing that, my "re" are limited to "borderline cases" > - try to block as much as possible spam before the body will be > sent - use the penalty box - set it to block A bit of warn here, the PB may become quite "aggressive" from time to time, so, I think that's a good idea to only set it to "block" after some quite long training time and, in any case, after setting it to "monitor" and carefully examining the logs > - use LDAP instead of flat files for a large amount of users/addresses Doing that, either LDAP or VRFY or... RCPT TO, no "flat file" here > - don't use testmodes or monitoring, if you don't realy need it see the "PB" note above, sometimes you do *have* do set stuff to "monitor/test"; this usually happens when you have some fresh setup or either when a new filter is added to ASSP and you want to see how it behaves ... before letting it go :) > - test your own regular expressions in testRe using the GUI-analyzer > before they go in to the 'production' regex I use some external regexp checkers to avoid loading ASSP, but yes, totally correct ! > - try to commend out as much as possible lines from the vanilla > bomb regular expression files (language dependend entries for > example - and 'got nerver hits') Agreed again ! Uh... and also, avoid adding a bunch of signatures to ClamAV (if you use it) and ensure to only use the ones which really which get more hits, discard the others; the same goes for regexp and DNS lists; low-hits ones may just be discarded; in general, the other ASSP filtering mechanisms will still dump the spam :D ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
