RE: Database for greylisting plugin.

George Georgalis wrote:
> On Fri, Dec 08, 2006 at 02:23:34PM +1100, Graham Miller wrote:
>> 
>> mysql Pros:
>> - central (or replicated) DB for server farms.
> 
> is that really needed for greylisting?

I read on the greylist-users mailing list that is was a consideration, but
am not convinced it is necessary yet. In my case it will not be needed as we
are only a small hosting company. I was kinda thinking about other potential
users when I wrote that.

>> The current greylistd C program I am using in a beta test server on
>> one domain that gets lots of spam, is using the filesystem and files
>> named after their IP address. This seems to be working ok so far,
>> but I have concerns about the number of files that end up being
>> cached by the OS and robbing server RAM.
> 
> an advantage there is simple (emergency) shell manipulations

Now that is very true. If whitelist is stored separately to greylist, then
greylist can be blown away totally in an emergency if needed. And if I used
another database that was in the file system or ram, then there is also a
similar (if not heavier) RAM penalty to caching files directory entries.

I will be making the system fail open by default so if there is a DB
(whichever) error, then it will allow mail to pass. Probably make it a cli
option so it can be selected on a per instance basis.

> sqlite has a facility to use in-memory tables, you will probably
> want to add a capacity to dump/load data to disk. the source is
> mature and in public domain, so you can include the libs in your
> package.

Gosh, that is really great. Just checked out the web site and it looks very
powerful with a CLI to do management and add hoc queries. Thanks for the
tip.

> when a mx passes you could make the record 4 bytes (ip) and an
> integer (time). In any event, I have the sense your app won't
> cause memory problems, but it may be simple to optionally use on
> disk tables.

I guess if it ever became popular with others, then optional storage types
would be the go. I will try to make the storage interface as simple as
possible so DB engines can be plugged in relatively easily.

Thanks for you input George.

regards
Graham