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
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
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
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
-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
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
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
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,
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
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.
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
11 matches
Mail list logo