Matt Kettler wrote on Fri, 16 Dec 2005 11:59:20 -0500: > Kai, I beg to differ.
I know :-) > > Most zombies ARE in the DULs and/or XBL. If you greylist on DULs and XBL > you'll > get most of the zombies. This is because about 90% of the zombies out there > are > home-user high-speed Internet machines that are trojan infected. DULs will > pretty much list all of these right off the bat, and XBL will pick up the > rest > quickly because that's what it is intended to list. I would have thought this as well or did so in the past. But it doesn't seem to be the case. One of the first hosts I blocked with greylisting was a (zombie?) DSL host which wanted to unload a few hundred [EMAIL PROTECTED] mails onto that machine and now filled the greylist.db instead. It was not and still is not on any zombie list nor in any dynamic IP space list. The DUL lists contain maybe 1 (one!) % of the dynamic IP space. They do contain a good amount of the "suspicious" address space and of "known" zombies (which can just have another IP next hour), but they don't contain hosts they don't know *yet* nor are they able to contain even a major part of the dynamic address space. I have been using SORBS and SBL+XBL at MTA level before greylisting for a long time and I can tell you that greylisting *does* make a big difference, that's why I implemented it so quickly after the first tests. Usually you would not be able to see the difference because on machines where clients have to SMTP AUTHenticate you have to use feature "check_delay" (or what it's called), so the greylisting would always happen before any RBL or access.db rejection. However, I have one machine where I can reject as early as possible (=RBL-based rejection takes precedence over greylisting). And there I clearly see that it makes a huge difference. Before greylisting I caught about 80% or so of spam at MTA level and it was quite common that about half the messages in Mailwatch were "spam red", unless there was a very high traffic on mailing lists (=ham). Since greylisting there's barely a message that makes it to SA at all, I catch nearly 100% at MTA level now. The only fear is that SA might get too few stuff for Bayes training. I haven't tested this and I won't, but I take a guess that greylisting is more effective than RBLing and probably also has less FPs. The combination with the best cost:benefit ratio would probably be greylist+SBL (but greylist first, not the combination you do it), so that anything that makes it thru the greylist is tested against SBL. (This would throw out all those fixed-ip operation spammers which retry. It's also possible that there are so few spammers that retry that the extra SBL stepp isn't worth it. In that case greylisting alone would be much more effective than RBLing.) > Due to FPs, i can't afford to blacklist all DUL nodes, but I could greylist > them. I do this now with RDNS name regexes and IP ranges in milter-greylist > ACLS > to great success (50% of my spam went away, with only about 100 nonspam > messages > delayed per week) Sure, you can do this, but it's like driving a Ferrari in town or having a cheetah as a pet in your house. ;-) Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
