It looks to me like recipient validation is the chkuser's major feature, which spamdyke will also implement in the next version. The tarpitting and delaying features are interesting and would be trivial to add as spamdyke features. I've always had a lot interest in the LaBrea project (and even used it for a while) and I would love to implement some similar tarpitting features in spamdyke. (LaBrea is now abandonware but used TCP trickery to force remote attackers to wait, nearly indefinitely, before timing out -- all while using nearly zero bandwidth.)
-- Sam Clippinger Eric Shubert wrote: > Sam, > Yes, but not a whole lot. Please have a look: > http://www.interazioni.it/opensource/chkuser/features.html > and let us know what you think. > > Sam Clippinger wrote: > >> Michael: I know QMT includes recipient validation already, but I would >> like to add it to spamdyke so it can also be used on non-QMT servers. I >> know a number of sysmadmen (myself included) who live by the policy >> "Never try to upgrade or patch a working qmail server." It's always >> been easier (and safer) to install qmail on a new server and migrate to >> it -- modifying an existing installation often (in my experience) leads >> to disaster. Adding recipient validation to spamdyke would allow those >> folks to add the filter without risking their entire mail server setup. >> >> Eric: I've glanced at chkuser a couple of times but I've never actually >> installed or used it. Does it do anything other than recipient validation? >> >> -- Sam Clippinger >> >> Eric Shubert wrote: >> >>> Michael Colvin wrote: >>> >>> >>>> After looking into QMT, which has recipient validation built in, I'm not >>>> sure Spamdyke really needs it... The implementation in QMT allows for >>>> VPOPmail and non-VPOPmail qmail servers to easily validate recipients. If >>>> Spamdyke implemented a version based on cdb files, with VPOPmail servers, >>>> something would have to be put in place to build those cdb files from the >>>> database. >>>> >>>> Spamdyke is fantastic at what it does. I'm not sure that it needs to be >>>> complicated. Of course, as long as the validation is easy enough to >>>> disable, then I guess it wouldn't matter, and non-VPOPmail users could >>>> enable it and use the cdb files... If Spamdyke included the ability to >>>> validate against the VPOPmail database, I'm not sure it would be any more >>>> or >>>> less efficient than the patch that's included in QMT. Eric? >>>> >>>> >>> My guess is that performance would be about the same whether spamdyke or >>> chkuser does the validation. I don't see the issue as being performance >>> related though. I'm more interested in having configuration options in a >>> simple, manageable place. I'd like to see spamdyke handle whatever >>> configuration variables are practical, even if spamdyke were to simply >>> set an environment variable for some other code to pick up. The fewer >>> number of patches to qmail source, the better. >>> >>> Which makes me wonder about chkuser. That patch is implemented in a >>> non-invasive fashion, as most of the code sits outside of qmail proper. >>> Most if not all of the chkuser configuration parameters can be altered >>> with environment variables. >>> >>> Sam, have you looked at bringing chkuser functionality into the spamdyke >>> realm? I would expect that you could probably find a way to integrate >>> chkuser into spamdyke, eliminating the need for the chkuser patch to >>> qmail. This would simply QMT a bit as well. >>> >>> Thanks for bringing this up Michael. >>> >>> >>> > > > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
