Re: [spamdyke-users] Databases revisited

2009-10-29 Thread Sam Clippinger
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

Re: [spamdyke-users] Databases revisited

2009-10-29 Thread Sam Clippinger
Actually, spamdyke's configuration file is typically so small and so frequently accessed that it should remain cached in memory. This would basically have the same effect as putting it on a RAM disk. I added the configuration file because spamdyke's option list had grown to the point that

Re: [spamdyke-users] Databases revisited

2009-10-25 Thread BC
I'm not a savvy programmer, so consider that when reading my comments. On 10/23/2009 spamdyke-users-requ...@spamdyke.org wrote: I'm thinking that no database might just be the best for this particular application (spamdyke). I don't know where people get the idea that databases provide

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread Eric Shubert
Nice piece, Sam. In addition, the OS will likely have cached spamdyke's config file(s) anyhow, so I expect any real performance gain would be negligible. BL to me is that there are a host of other inefficiencies (pardon the pun) that would bring a mail server to its knees long before

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread Michael Colvin
-users- boun...@spamdyke.org] On Behalf Of Eric Shubert Sent: Thursday, October 22, 2009 11:41 AM To: spamdyke-users@spamdyke.org Subject: Re: [spamdyke-users] Databases revisited Nice piece, Sam. In addition, the OS will likely have cached spamdyke's config file(s) anyhow, so I expect

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread BC
Hi Sam - That is a pretty good synopsis of what he is doing. Doesn't he claim to find *any* sought after data in no more than 7 seeks? Maybe I misread that somewhere. :) My take on the below would be that if spamdyke remains a qmail-only spam blocker, then going with a cdb-based database

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread Eric Shubert
BC wrote: Hi Sam - That is a pretty good synopsis of what he is doing. Doesn't he claim to find *any* sought after data in no more than 7 seeks? Maybe I misread that somewhere. :) My take on the below would be that if spamdyke remains a qmail-only spam blocker, then going with a

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread Eric Shubert
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,

Re: [spamdyke-users] Databases revisited

2009-10-22 Thread Sam Clippinger
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

Re: [spamdyke-users] Databases revisited

2009-10-21 Thread Eric Shubert
lenn...@wu-wien.ac.at wrote: Dear all, I have been reading up on the discussions on this list as well as the concerns about databases in the FAQ. Whilst I concur with most of the points wrt. to a fully fledged SQL database, I think that CDBs are ideally suited for the purposes of spamdyke.

Re: [spamdyke-users] Databases revisited

2009-10-21 Thread Jake Briggs
Eric Shubert wrote: lenn...@wu-wien.ac.at wrote: Dear all, I have been reading up on the discussions on this list as well as the concerns about databases in the FAQ. Whilst I concur with most of the points wrt. to a fully fledged SQL database, I think that CDBs are ideally suited for the