Milter-greylist

> The patch covers a very narrow situation where you have user accounts on
> the MX. I'd be more happy if we could think of a more general mechanism
> to lookup whitelist the ACL.

I know my patch addresses only a specific set of circumstances and
would like to see some movement towards a more useful way for end users
to opt in to, as well as out of, greylisting.  The patch doesn't work
for our central mail service, which only handles filtering and
forwarding to mailboxes on other servers.  We would like to have a
solution which doesn't rely on user mailboxes or user accounts but is
still straightforward for users to update.

It's a small, inadequate, step that gets around an immediate problem in
our local environment.  I hope the resulting discussion will help
foster the development of a useful back end.

> For now we have local file. What about looking up information through
> DNS? Or LDAP? Anyone have good ideas about how it could work?

We have a homebrewed system in place for opting out of DNSBL-based
blacklisting that uses dynamic updates on a local DNS server, user
authentication for local users, a key sent via email for remote users,
and a small sendmail config localism.  It could be expanded to work for
greylisting, but it is basically a kludge which I would rather see die
than perpetuate.

We have political issues around LDAP here that would make it difficult
but not impossible to sell an LDAP-based solution.  That said, if
someone comes up with an LDAP interface, we'll find a way to use it.

We're hoping for something not tied to a user's account(s) or the mail
spool because these resources may not be available to the server where
the milter is running.

A database backend (file-based like Berkeley or using a real DB server
that speaks SQL) would be fine for us and probably has the most
flexibility.  We don't get them now (that anyone's told me about), but
I anticipate requests which are more complex than "do or don't subject
all email addressed to me (or all mail from a specific domain) to
greylisting".

I'd like to see a real-time configurable back end which can quickly
check (in a defined order not necessarily identical to the one below):

 - should (sender,recipient) be greylisted or whitelisted?
 - should (sender domain,recipient) be greylisted or whitelisted?
 - should (recipient) be greylisted or whitelisted?
 - should (sender) be greylisted or whitelisted?
 - should (sender domain) be greylisted or whitelisted?

and fall through to default processing if none of the lookups yields a
result.  I'm not convinced the set of questions above is the canonical
one to use:  it's just what came off the top of my head.

--
Dawn Keenan, Information Systems and Technology
University of Waterloo, Waterloo ON