GRP Productions wrote on Fri, 18 Mar 2005 10:38:29 +0200: > It seems SURBL is now enabled by default. It has also changed its name to > URIDNSBL :-)
SURBL refers generally to those xx_SURBL rules and to URIDNSBL since the only other distributed rules is SBL and SURBL started it all. I do not use SARE rules (although I am trying to find time to > look at them, as I am aware of their credibility). I use Gray's rules > (http://files.grayonline.id.au), they seem quite efficient. I wasn't aware of that site, but now that I visited it, I remember I visited it at least once. Use whatever works for you. After all, all this stuff isn't done to make you try out again and again but to help you focus your time on the important things. > I understand what you say. The point is, what should be the criteria to > understand if the time for an expiration has come? I mean, supposing we take > only the size in consideration, could be a problem. What if some old tokens > are still common nowadays in spam mail? This is not a problem. Expiry isn't done by "addition time", but by access time (short: atime). So, items which didn't occur recently drop to the "end" of the db and get removed by expiry. There's always the chance that old tokens which haven't been seen for a long time "come back". But the chance is slimmer the older the atime of that token is. There's probably some statistical curve algorithm which could be used to determine the best "break point". Because of the way dbx databases work expiry can't be done this way, though. > As I told you, since my last post I have reset everything. It seems to me > it works fine, and it learns rapidly. It gives me no reason not to trust it, > in a degree I have set my SA score to be more or less equal with the > BAYES_99 score (around 8). Your BAYES_99 score is 8? I would never do this. General rule is that no single rule should be able to mark a message as ham or spam. That cries for false positives. Of course I keep doing mistake-based learning, > but most of the times I feed it with 'subjective' spam mail (ie. mail that > my users don't want to receive, but is definitely not spam). What kind of mail is that? Newsletters they once subscribed to and don't like anymore? They should unsubscribe instead of declaring it as spam. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de & http://msie.winware.org