[Exim] local_scan() wishlist

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Greg Ward
Date:  
À: Philip Hazel
CC: exim-users
Sujet: [Exim] local_scan() wishlist
Hi Philip --

I've just read through the current Exim wishlist to see if anyone else
has the same wishes as I do. I think I can make a few contributions,
based on my experience embedding Python in Exim
(http://elspy.sourceforge.net/):

* Access to the panic log.

Eg. if elspy is unable to import exim_local_scan.py, or to lookup the
Python local_scan() function, that's panic-worthy from elspy's point
of view. If the Python local_scan() returns an invalid value or
raises an exception, that *might* be panic-worthy too.

I'm not sure how applicable this is to local_scan() implementations
that don't embed a whole new programming language into Exim. I
suspect if you give the local_scan() API access to Exim's config file,
though, there will be a whole new class of panic-worthy errors.

* Ability to write a single line to the reject log, without logging
all the message headers too.

Related: ability to write the reject log without also appending a line
to the main log. I think. I'm not sure I need that feature, but more
flexible logging just seems like a good idea in general.

* Access to Exim's debug output facilities.

Right now, elspy writes all debug messages to the main log. And
I have to change a C macro and recompile to turn on debugging.
Sometimes I get lazy and write to stdout -- that works fine for
exim -bs or -bh, but if I accidentally run that binary as a daemon,
the debug messages go down the SMTP socket!

* Ability to distinguish a "-bh" session.

The local_scan() function currently running on python.org has two
real-world side-effects: it can optionally save every message in a
special directory (this is for collecting a corpus for
developing/testing spam filtering software), and it can update an
automated sender blacklist (if someone sends you three viruses within
an hour, blacklist that sender/IP address for the next six hours).
Both of these real-world side-effects should be suppressed in a "-bh"
session.

* Ability to create/query address lists, domain lists, host lists, etc.

The elspy library includes several modules for common email-filtering
tasks: a Python version of Nigel's old "Windows executable content"
filter, an interface to SpamAssassin, some code to reject mail with
certain Asian charsets in the subject, etc. Most of these have some
sort of config information, eg. a list of sender addresses to exempt
from this check. It would be nice if users could express that config
info in the usual way, ie. with Exim address/domain/host/etc lists.

(Right now, it would be enough for the C local_scan() API to expose
the required create/update/query functions; I could then write Python
wrappers, which people could use in their exim_local_scan.py. Access
to named lists in the config file would also be nice, but that's not
as important for me.)

* Ability to suppress local_scan() from the config file.

First use case: I want to unconditionally accept all messages from <>
or to "postmaster". It's easier to express that in the config file
than in local_scan(). Perhaps local_scan() should be activated from
the DATA ACL? Not sure of the right interface offhand.

Second use case: oh no, my Python installation just went haywire and
my main log is filling up with tracebacks from elspy! (Or, perhaps
more realistically: oh no, I just put a stupid error in
exim_local_scan.py!) In that case, I just want to completely suppress
local_scan() until I figure out what's going wrong and have a chance
to fix it.

I think that's everything for now...

        Greg
--
Greg Ward <gward@???>                         http://www.gerg.ca/
Never put off till tomorrow what you can avoid all together.