Milter-greylist

Benoit Branciard <benoit.branciard@...> wrote:

> I agree milter-greylist should rather concentrate on envelope (pre-DATA)
> stage, maybe SMTP-header stage (but here we already hit the DATA stage ?).

Yes, header are in the DATA stage.
 
[SQL backend to replace MX sync]
> Mmmm... Is that a good idea anyway ? In case of multiple MXes, This 
> introduces a single point of failure, or we need complicated setups to
> overcome (SQL mirroring with failover...). MX sync seems quite light and
> efficient in comparison.

Yes, I wouldn't give away the MX sync for something such overblown as a
distributed database. 

> More useful would be the ability to include files in greylist.conf, 
> which would permit to split configuration in case of long witelists for
> example; I believe it's not possible currently. Another interesting 
> feature would be to use SQL and/or LDAP backend for (white, black) 
> lists, instead of greylist.conf: this would permit easy dynamic update
> and looong lists without performance/memory hit. Anoter way (which 
> doesn't require milter-greylist changes) is to setup a local DNSBL 
> server, but this lacks the power of regexps and domain matching.

Heh... I have been using LDAP as a per-user configuration repository for
two years now. Users can set up in real-time their personnal greylist
settings, and even their personnal whitelist and blacklist.

I do that through the urlcheck clause, using an ldap:// URL.

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