Milter-greylist

Fabien Tassin <fta+miltergreylist@...> wrote:

> 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.

We can immagine that the honeypot is managed by another program that
tells milter-greylist to drop entries from the database. That way you
keep the flexibility of doing anything you want with the honeypot tool,
such as archiving spam messages, communicating with other antispam
tools, and so on.

How to tell milter-greylist? We can just have a small feature addition:

acl blacklist could have a flush statement, which could tell
milter-greylist to drop anything about the IP in its databases.
Something like this:

acl blacklist dnsrbl "local-blacklist" flush

Your honeypotware would just have to feed a local DNSRBL to have
milter-greylist forgetting about the IP's tupples and blacklisting it.

If you don't want to use an external tool, then just do this:

acl blacklist rcpt spamtrap@... flush


I wonder if it is interesting to have a syntax for selecting the flushed
tuples:
 
flush (greylist|autowhite|*) (addr|*) (from|*) (rcpt|*)

Examples:   
flush greylist addr * rcpt 
flush autowhite addr * *

Or if we should just flush everything related to the IP address.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...