Milter-greylist

According to manu@...:
> 
> > Thoughts ?
> > Can you see a flaw ?
> 
> What is the advantage of doing this inside milter-greylist instead of
> using other existing tools? I'm all in favor of improving this software,
> but I wouldn't want to see it killed by bloat...

I agree that bloat is no good but here, I don't think it is.

Well, the point is to stop spam as early as possible, right?
Greylisting is good but it has to store all tuples and then treats all emails
separately. I mean, spammers make sure the tuples are always different
so you have to store everything to be effective. honeypots are no good
here as you have no way to kill everything else coming from the same source.
By mixing the advantage of grey list on one side and black list of those honey
pots on the other side, you can stop the whole flow coming from an ip that
you don't know beforehand (and that you will probably never see again),
even the emails that came before the one toward the honeypot, just because
they are on hold in the greylist.

If you split the features, let say, grey 1st, then black, you loose the
advantage of grey. Same thing, if you black 1st, grey has no more ways to
take advantage of the honeypots. It has to be at the same level to kill
the whole flow.

Do you get my point?

I don't know how your own db looks like but mine has plenty of consecutive
duplicates for the Sender IP field. Just got a row of 369 emails from the
same sender in a few seconds, all are sitting in the greylist now, with
thousands of others. With the auto-blacklist feature I've described before,
at the 3rd email (that happened to be a honeypot addr), I would have stopped
all that, even if the spammer retry later (no longer matters).

/Fabien