Milter-greylist

On Mon, Sep 15, 2008 at 08:30:32PM +0200, shuttlebox wrote:
> On Mon, Sep 15, 2008 at 8:06 PM, Manuel Badzong <manuel@...> wrote:
> > On Mon, Sep 15, 2008 at 02:30:43PM +0200, Akos Szalkai wrote:
> >
> >> But what's the use for greylisting after the data stage?  Why not only
> >> accept or refuse (and perhaps temporarily black/whitelist the triplet)?
> >
> > At the data stage you could use various additional spam identifying methods besides
> > ip, sender and recipient.
> 
> But if you identify it as spam with your "additional methods", don't
> you want to blacklist it then? What's the point to greylist (ask them
> to resend) if you already know it's spam?

That's the advantage of conditional greylisting: A non-human content
inspector -- like a public DNSBL -- can always be wrong, so just
greylisting the sender still leaves a door open for real MTAs to deliver
their mail. At the same time you don't have to greylist _everyone_.

Imagine the following scenery:

	spamdsock "/var/run/spamd.sock"

	dacl greylist  spamd-score >  5 delay  6h
	dacl greylist  spamd-score > 10 delay 12h
	dacl greylist  spamd-score > 15 delay 24h
	dacl blacklist spamd-score > 20


That's called `adaptive greylisting' and is already implemented in
exim-sa:

	http://marc.merlins.org/linux/exim/sa.html


However, I do understand that this would interfere with all those
whitelist statements you defined before the dacl, but such overrides are
already permitted by milter-greylist by allowing `dacl blacklist'.


Thanks,

Petar