Bug#398224: Re: This is a design flaw

[Matthew Wakeling]

On Mon, 7 Feb 2011, Dominic Hargreaves wrote:
> [adding CC to current package maintainer]

Thanks.

> So it's possible that greylistd doesn't provide any real benefit if it's
> possible to implement similar things without any extra code. It sounds like
> I should spend a bit of time looking at the various options before committing
> time to significant updates to greylistd.

Let's face it - greylistd is a horrible little hack, with all sorts of 
problems. It works for a few people (like me), most of the time, but it is 
far from the wonderful one-step-install it should be.

I dislike the way it keeps the database in memory, and has no safe 
mechanism for committing changes to disc. I dislike the nasty auto exim 
config altering script. I dislike how several options (like singleupdate, 
see bug #502460) don't really seem to do what everyone thinks they do, and 
none of the possible configurations do exactly what everyone wants. I 
dislike the way MessageLabs fails to try my secondary MX when it gets a 
greylisted response. Other people dislike the fact that other senders *do* 
try the secondary host, bypassing the greylisting. I dislike the way most 
of the options are extremely poorly documented.

I don't have time at the moment to work on a proper replacement for 
greylistd, however my feeling is that it should probably be part of the 
main exim package (probably a configuration switched off by default), and 
maybe sqlite is the way to go. As long as we are munging the exim config 
file for our users, that's a disaster waiting to happen.

Food for thought. Sorry I'm putting my foot in without actually offering 
any help.

Matthew

-- 
 Some people, when confronted with a problem, think "I know, I'll use regular
 expressions." Now they have two problems.                  -- Jamie Zawinski