Database for greylisting plugin.
"Graham Miller" <[email protected]> Fri, 8 Dec 2006 14:23:34 +1100
| Newsgroups | gmane.comp.sysutils.bgware |
|---|---|
| Organization | G.M.C.S. |
| Message-ID | <[email protected]> |
Hi all, I am designing a plugin for mailfront to do greylisting. After writing (in C) an in-line filter (based on IP address only) to sit between rblsmtpd and smtpfront, I am now encouraged to do it properly after seeing great results. (160 per day down to 10 in the test mailbox). I am designing the plugin to use IP address, Recipient, and Sender as a triplet (maybe configurable down to ip-recipient), and am having a bit of trouble choosing a database type to use. I hope that those here can help with some feedback to make it as good as possible. On one hand, the greylist.org site refers to the relaydelay perl script version and it uses mysql. Many others seem to use mysql too. mysql Pros: - central (or replicated) DB for server farms. - extra valuable info available with sql query. - known robust DB. - reasonably quick data access. mysql Cons: - need to handle "no access to db" issue. - slower than file system access (perhaps). - extra layer of complexity. - not all sites use mysql. On another hand, simpler systems I have seen use Berkeley style file system DBs. These are more prevalent on unix/linux hosts, but lack simple add hock query ability and detailed record structures. Another option is DJBs cdb, but that seems to be tuned for read only applications rather than write intensive ones like a greylisting program. Another thought I have had is some kind of file system thing like DJB uses for the mail queue, or an indexed directory structure of some kind with filenames made up of the triplet. 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. So anyone want to wade in here and put in their experience or ideas? Any comments about the trade-off of post event analysis versus simpler storage needs? thanks Graham Miller