Milter-greylist

Michael Mansour <mic@...> wrote:

> 1. perform a consistency check on the greylist.conf file before reloading it.

I use to run milter-greylist -cf on the new file before moving it to
/etc/mail.

I agree that testing the config before reloading could be useful, but it
can also be quite time and memory consuming for sites that have very
large config file. There should probably be an option for that.
 
> 2. have the ability to support an external whitelist file.
> 
> I've recently started looking at www.dnswl.org which provides a whitelist of
> sites that are "trusted" and should not be greylisted.

Configure it as a DNSRBL and use it in a whitelist rule, you'll have
real time DNS lookups on this DNSWL.

Perhaps the dnsrbl keyword needs to be changed into "dnsl" so that
people understand it can be used for any purpose (blacklist or
whitelist)?

> 3. have a web interface to the whitelist system.
> 
> It would be good to have a web interface for users to be able to access their
> own whitelist system so they can enter "from" and "to" etc rules to manage
> their greylist. Maybe even keep these in a MySQL database for each management?

At work, I store per-user settings in a LDAP directory. milter-greylist
lookus up the directory using an urlcheck clause with an ldap:// URI.

I've a few web forms for user to enter their personnal white list, black
list, the DNSRBL they want to use, and the delays they want for
greylisting. They can also enable some content filter implemented by
milter-greylist: no HTML with embedded GIF, no PDF files smaller than
30k, and so on.
 
> 4. tools to pull out relevant information from the /var/log/maillog file.

Did you had a look at what can be done with the stat keyword? I use it
to provide a web-based per-user log of what hapened to each e-mail:
rejected, delayed or accepted, with the sender and the reasons for the
decision.

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