Milter-greylist

At Mon, 8 Jan 2007 09:06:32 +0100 (CET),
Oliver Fromme wrote:
> 
> 
> Emmanuel Dreyfus wrote:
>  > Fabien Tassin wrote:
>  > > Emmanuel Dreyfus wrote:
>  > > > I droped it because we had no garantee of not loosing data when the
>  > > > milter would be killed. How are you going to address that problem? 
>  > > 
>  > > What about SQLite ? I'd love to have that. No need to maintain a local DNSRBL
>  > > then. Any tool could update a table very easily from the outside.
>  > 
>  > How does it resist to a kill -9?
> 
> You need to use a real transactional database (such as
> PostgreSQL) in order to support that.  If the transaction
> is aborted for any reason (e.g. SIGKILL), it is guaranteed
> that the database server rolls it back and the database is
> always in a consistent state.  No data is lost except (of
> course) for the actual current transaction that has been
> aborted.

And Berkeley DB is also available for this purpose.

> By the way, using an SQL database would also provide more
> solutions to the MX synchronization problem.  For example,
> instead of using milter-greylist's own MX sync feature,
> you could simply let several instances of milter-greylist
> (on different MX servers) access the same SQL database.
> Or -- for improved redundancy -- let each MX server run its
> own SQL server instance, and use SQL replication features
> to distribute all changes ("INSERT" commands) to the other
> SQL servers.  There are probably even more possibilities,
> but the ones mentioned are the most obvious ones.

Replication copies data from the master read/write server to other
readonly servers. It is not what we want. In contrast, MX sync is
peer-to-peer mechanism. While MX sync cannot ensure consistency
between servers, it satisfies basic needs in SMTP world.