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 spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
