Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] milter-greylist 3.1.x branch and OpenBSD performance loading greylist.db

2007-01-08 by eclark

I agree with Aida here. I also further believe that while some flavor of db 
backend might be nice for smaller users, I highly doubt its function in a 
larger environment. Currently gdmilter is very fast, writing its db only 
periodically and storing as much of the transitional information in memory as 
possible. Adding additional layers to its complexity really does nothing 
beneficial for the milter outside of small homegrown offices. I certainly 
would not want a 2million+ daily mail server feeding its requests for 
updates/whitelistings/blacklistings from some sort of third party database. 
It slows the entire transaction down, increases hardware requirements for it 
to run reliably, and provides only better auditing and recovery in case of 
total failure. 

On Monday 08 January 2007 08:11 am, AIDA Shinra wrote:
> At Mon, 8 Jan 2007 09:47:19 +0100,
>
> manu@... wrote:
> > AIDA Shinra <shinra@...> wrote:
> > > I'm writing Berkeley DB backend, but cannot make advance due to my
> > > real life... Development may or may not resume in February.
> >
> > That will obviously require a storage API for milter-greylist. It would
> > be nice if that could be discussed here before a complete patch is done.
> > Other people might have other strage plans, and having an API on which
> > anything could plug-in would be better than hacking the thing over and
> > over to add more storage back-ends.
>
> Plug-in makes many problems. Milter-greylist is not such a big project
> that benefits of plug-in architecture exceed costs.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.