Re: [Exim] Malware and Spam Scanning in an ISP environment w…

Top Page
Delete this message
Reply to this message
Author: Hilko Bengen
Date:  
To: exim-users
CC: Marc Haber
Subject: Re: [Exim] Malware and Spam Scanning in an ISP environment with "Mandantenfaehigkeit"
Philip Hazel <ph10@???> writes:

>> I think it would be a good idea if it would be possible to have a
>> local_scan_late function which is called after exim has taken
>> responsibility for the message and the SMTP transaction has been
>> completed. The API would be the same, with the sole difference that
>> the REJECT return codes of the function would cause a delivery
>> failure which would in turn result in a bounce being generated.
>
> This is effectively a "system filter" with a different API.


Right.

When starting work on the predecessor of AMaViS-ng, our goal was that
Exim should not have give up responsibility while the message is
scanned. The only way I saw back (that was Exim 3.2x, IIRC) then was
the system filter calling a Perl function that does the scanning on
the message.

It's bad that we didn't have a (documented) means of passing the
message to the Perl function; what we did was to call "exim -Mvh
$message_id" and "exim -Mvb $message_id", so in the end we got
something we could throw at a mime parser.

With Exim4, you could do this not only via a ${perl} expansion, but
also via ${run}, ${readsocket}, but the mechanism of accessing the
message's content still has to be essentially the same.

Although we used only documented interfaces (one probably could just
have accessed the spool files from inside the Perl code...), I
consider this a hack that does the job but isn't really beautiful to
look at.

>> Philip, would you consider applying a patch to exim that adds a
>> local_scan-to-Milter-Interface to exim? Thanks for your
>> consideration.
> I don't know anything about milter, but I have the impression that
> it is a daemon that listens on a socket? Is this right?


Right. The Milter protocol is modelled closely after a normal SMTP
connection and the whole message, along with envelope information, is
passed down to the daemon.

> If so, it should not be too hard to write an interface for it. This
> has in fact been on the Wish List for quite a long time.


I am willing to do this; I have written a Milter client (the MTA's
side) implementation in Perl that can be hooked into the system filter
via a simple Perl expansion. Although this code has been in productive
use on an ISP mail server for some months now and hasn't caused any
problems there, I'd still rather view it as proof-of-concept code. I
think it's time to rewrite the thing in C. :-)

For the best possible flexibility on the admin's side, I'd like to
provide as an expansion item (or a set of expansion items) which could
be called from various places in the Exim configuration file. Would
this work and would you accept a patch that implements this?

-Hilko