Milter-greylist

One of the faculties at UW which implemented greylisting for their
local mail service found their users are generally content with it, but
there are several noisy exceptions.  They received enough requests to
opt out of greylisting that their computer support staff requested a
simple mechanism that users can use to opt out without a sysadmin's
intervention.

The attached patch and new source file for milter-greylist 2.0 checks
for the existence of a file named .nogreylist in the recipient's home
directory and whitelists mail to the associated address if the file
exists.  This works well for mail addressed directly to users
(including addresses of the form user+detail@host) without mailer
tables or aliases, in the case where user home directories are
available on the mail server.

Once milter-greylist has a back end for whitelisting from a source we
can let users update directly, we'll probably drop this patch.  In the
meantime, it cuts down on the day to day work load for our support
staff.

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

On Mon, Aug 22, 2005 at 11:18:50AM -0400, Dawn Keenan wrote:
> The attached patch and new source file for milter-greylist 2.0 checks
> for the existence of a file named .nogreylist in the recipient's home
> directory and whitelists mail to the associated address if the file
> exists.
[...]
> This works well for mail addressed directly to users
> (including addresses of the form user+detail@host) without mailer
> tables or aliases, in the case where user home directories are
> available on the mail server.

The problem with your code is that it blindly assumes that this is the
case. It should really check if the recipient is locale before accessing
the home directory. It also doesn't honor things like aliases or
".forward" files.

Another problem is the overhead which might be caused by accessing the
user's home directory which might e.g. be on a NFS server. The university
I visited e.g. had reconfigured their mail server to check for
"/var/mail/forward/user" instead of "~user/.forward" to avoid just that.

	Kind regards

-- 
Matthias Scheler                                  http://scheler.de/~matthias/

Dawn Keenan <dkeenan@...> wrote:

> Once milter-greylist has a back end for whitelisting from a source we
> can let users update directly, we'll probably drop this patch.  In the
> meantime, it cuts down on the day to day work load for our support
> staff.

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. 

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

Note I won't be able to follow up the discussion in the near future (see
my other message about being AFK)
 
-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

> 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