Milter-greylist

All,

For scalability, the next step up for Milter-greylist will be to implement a database backend. MySQL is a good candidate.

In my discussions with Emmanuel, we have identified the following steps to address this challenge, without breaking any current setups in the mean time. The proposed steps are:

1. Agree on and implement a storage API
2. define a --with-sql compiler option
3. implement hash storage model when compiled --with-sql
4. modify yacc/lex definitions for sql directives (servers, user name, password)
5. implement MySQL API interface

As regards to step 1, the storage API can look something like this:

#define MG_PEND 0
#define MG_WHITE 1

struct tuple_fields {
        char    *addr;
        char    *from;
        char    *to;
        int     tag;
        int     timeout;
};

void mg_init();                            /* initialize storage backend */
void mg_start();                           /* start cleaning thread, if needed */
int mg_tuple_add(struct tuple_fields);
int mg_tuple_del(struct tuple_fields);  /* args may be NULL for wildcard */
int mg_tuple_match(struct tuple_fields);
int mg_tuple_refresh(struct tuple_fields); /* idem */
int mg_tuple_clean();                      /* if backend needs cleanup */

At this point, we need to build consensus about the steps to take and the API for a MySQL backend.

Also, I'd like to know if anyone is available to take on one or more of the tasks at hand. I will work on moving the current code to a storage API based model.

Thanks,
Rudy Eschauzier

On Sun, Jan 18, 2009 at 4:21 PM, Greg Troxel <gdt@...> wrote:
> I generally have a bias towards PostgreSQL.  It would be nice for the
> interface to be generic.  I know this is easy in perl, and I'm not clear
> on C APIs for database independence.

I second that. This should be simple database impementation and SQLite
might be the fastest candidate.

It's ok if MySQL is implemented first as long as some thought is given
towards neutral choice of db. :-)

-- 
/peter

On Sunday 18 January 2009 09:33:04 am Rudy Eschauzier wrote:
> All,
>
> For scalability, the next step up for Milter-greylist will be to implement
> a database backend. MySQL is a good candidate.
>
> In my discussions with Emmanuel, we have identified the following steps to
> address this challenge, without breaking any current setups in the mean
> time. The proposed steps are:
>

Whatever you do, please make sure the setup will allow easy adding of 
postgresql.

For small systems, using an embedded DB would be nice.

-- 
Techwolf
Techwolf@...
http://www.techwolf.net/index.html
PGP public keys on web site.

Hi all


> For scalability, the next step up for Milter-greylist will be to  
> implement a database backend. MySQL is a good candidate.
>
> In my discussions with Emmanuel, we have identified the following  
> steps to address this challenge, without breaking any current setups  
> in the mean time. The proposed steps are:


if an db backend is included it would be nice to place config parts  
like whitelists, peers and so on also in the db...

This would make it possible to code a central nice an sweet  
webfrontend for milter-greylist :-)

Mit freundlichen Gruessen || with kind regards

             Sven Holz

Sven Holz <sven.holz@...> wrote:

> This would make it possible to code a central nice an sweet  
> webfrontend for milter-greylist :-)

I already do it with LDAP: users have personnal white and blacklist and
various other per-recipient settings that they can change on they fly
using a web frontend to the LDAP directory. It has been working fine for
more than a year, now.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...