Milter-greylist

According to Alan M. Evans:
> I can respond to this, since it's a feature that I am very much
> interested in. In fact, this feature is the reason I subscribed to the
> group -- been lurking to get a feel for the community and see if anybody
> else mentions the same idea. I guess now's the time.
> 
> The idea I was toying with was this: if the milter receives mail for the
> bogus address (presumably an address hidden on our homepage along with
> legit addresses), it rejects in the same way as if it were greylisting,
> but silently adds the sender IP to the blacklist for a period. When the
> same spammer retries, all their mail is rejected outright. Looking at my
> mail logs makes me think that this would be quite effective.

me too. look at the archives, I've mentionned that some months ago, and
even more. Look for autoblack.
I've received bad feedbacks from Manu so I planed to add it myself,
which I nearly did but due to lack of time to finish the thing (and m-g
evolving quickly at the same time), I gave up. I've now dropped it completly
during an upgrade to gain a feature.
I ended up with plenty of blacklist rules, all acting as grey. That's tons of
spams blocked for good but that requires some log monitoring and manual
black list rules. Could have been better at low cost for m-g.
I don't want to add another link to Bind by creating a local RBL (even if
I already have plenty of nsupdate/dyn-zones in place).
nor do I want to add yet another milter or layer on top of milter, it's
already a maze.

> The reason for pretending to greylist is to prevent the spammer from
> discovering what the bad address is. Perhaps that's not worthwhile.

That's why I always use blacklist with code and ecode, (and flushaddr).

list "spam traps" rcpt { \
  .. all my honeypots here
}

acl blacklist list "spam traps" \
        code    "451" \
        ecode   "4.7.1" \
        msg     "Greylisting in action, please come back later" \
        flushaddr

That way, greylist.db is relatively free from those ugly spammers and my
honeypots are not exposed either. you still let some spams pass from those
guys but with blacklist+451+flushaddr and greylist as default, that's
good enough for me at the moment.

> Thinking further, I suppose I could whitelist the bogus address and have
> some other milter handle the auto-blacklist. But then it must either
> accept or reject the mail. So mail sent to the honeypot address is
> treated differently than that sent to other addresses, making discovery
> of which address causes blacklisting relatively easy. Again, maybe
> that's not worth worrying about, but I prefer not to give spammers any
> clue about how to circumvent my defenses.

You can still follow the path of monitoring the logs and populating
a DNS zone that g-m could use as a DNSRBL. Depends on your local constraints.

/Fabien