Milter-greylist

manu@... wrote:
> Matthieu Herrb <matthieu.herrb@...> wrote:
> 
>> I seem to remember that I've heard Emmanuel talk about implementing 
>> greytrapping, but I've not seen it discussed here. I've tried to 
>> implement that in mimedefang, but there are some drawbacks that could be
>>   avoided by using milter-greylist for that.
> 
> How are you going to store the blacklist? IMO, a reasonnable approach
> would be to match the messages using milter-greylist ACL, then feed a
> DNSRBL. 
> 
> You'd need to add a DNS update action clause to milter-greylist ACL,
> something such as:
> 
> dnsrblupdate "MYRBL"  ns.example.net  127.0.0.10
> racl blacklist rcpt wzizo1at5ti.fsf@... dnsrblupdate "MYRBL"
> 
> You'll also need to think about entries expiration. What do you think?

I was thinking about using the greylist database itself with a special 
attribute to store those dynamically blacklisted entries. The from and 
to fields are not meaningful in that case, but they can be kept for 
debugging purposes.
This database already have all mechanisms to manage the expiration of 
the entries.

> 
> 
> Your other proposal (matching messages that goes to secondary MX before
> primary) seems a bit more difficult. MX sync may help: the messages you
> want to match arrive at secondary MX without being already greylisted.
> It seems you need to add an information to the greylisting database:
> where the message was presented last time (IP of MX for instance).
> 

The trick is to have one unique milter-greylist instance that will 
handle the messages sent to 2 different IP addresses. The $if_addr 
sendmail macro can be used to distinguish them and treat the incoming 
connection as a spam attempt if the relay,from,to tuple doesn't already 
exist in the greylist database.
If it's present (whitelisted or greylisted) the message can be handled 
normally. Otherwise the relay IP will be auto-blacklisted.
-- 
Matthieu Herrb