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.
>>
>>   


-- 
-Eric 'shubes'

_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to