Milter-greylist

Fredrik Pettai <pettai@...> wrote:

> an way that gets that functionality to mix racls   & dacls

An idea about this:

We have something called properties, that can be fetched from a LDAP
directory or a web service. I use it for have LDAP-stored, per-recipient
filtering settings. It does somthing like this:

ldapcheck "senderpref" "ldapi:///o=home?userBlackList?one?mail=%f" clear
racl whitelist ldapcheck "senderpref"
racl blacklist $userBlackList "%f" msg "you're in recipient's blacklist"

the ldapcheck statement is just the LDAP source configuration.
The first racl cause $userBlackList to be populated as the list of
recipients blakclisted by the user, as stored in the LDAP directory.
There is a syntax horror here, as this "whitelist" will not stop ACL
evaluation. It should really be changed as racl continue ldapcheck
"senderpref", but  this is another story.

Now, we could extend this so that any ACL would be able to set a
property. Something like this:

racl continue from friend@... set($skipdacl,"TRUE")
dacl whitelist $skipdact "TRUE"

And here we get a really powerful solution, where racl can store a lot
of information to be used to make a décision at DATA stage.

If we go that way, we need to introduce the continue action, and I'm in
favor or renaming whitelist/blacklist in accept/tempfail/reject. 

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