Milter-greylist

Thanks for your feedback. You are describing exactly what I was running into with the dacl commands in the current greylist, and why I think it needs a major overhaul.

Basing precedence on the config order is intuitive to most users (except maybe for SMTP and milter die-hards) and it elegantly extends the milter-greylist philosophy. No additional keywords needed.

I'd be very interested to hear more feedback from users that are using dacl statements in their current setup, or have tried using them in the past but have given up.

Thanks,
Rudy.


--- In milter-greylist@yahoogroups.com, Fredrik Pettai <pettai@...> wrote:
> rest", the dacl with the rules for checking for example dkim, will
> become more or less useless. So, in order to do whitelisting of

> Mixing racl and dacl will be more CPU intensive than doing them in the  
> current order, but I think it adds more flexibility if it's possible  
> to be able to do whitelisting (or greylisting and perhaps even  
> blacklisting) on both RCPT and DATA before falling back on the default.
> 
> As an example, I would like to be able to do something similar to this.
> (where the acls are parsed in linear order)
> 
> racl whitelist list "my network"
> racl whitelist list "awl admin recipients"
> racl whitelist list "broken mta"
> dacl whitelist dkim pass
> dacl whitelist body /^-----BEGIN PGP.*MESSAGE-----$/
> racl greylist sm_macro "maybe_forged" delay 1h autowhite 3d
> racl greylist dnsrbl "SPAMHAUS" delay 24h autowhite 3d
> dacl greylist dkim fail delay 1h autowhite 3d
> *acl greylist default delay 30m autowhite 30d
> 
> *I think "racl greylist default" would be misleading in this  
> configuration case. Correct me if I'm wrong here, but I also believe  
> that the way "racl greylist default delay ... autowhite ..." works,  
> wasn't possible to configure with dacl (see it as another suggestion  
> for enhancement :-)).
> 
> Regards,
> /P
>