Re: [Exim] Looking at Exim for anti-spam filtering

Top Page
Delete this message
Reply to this message
Author: Lorens Kockum
Date:  
To: exim-users
CC: 
Subject: Re: [Exim] Looking at Exim for anti-spam filtering
On exim-users I wrote:
>On exim-users Philip Hazel wrote:
>>On 1 Feb 2000, Lorens Kockum wrote:
>>>
>>> 3) per-domain, per-user, and per-alias incoming mail filtering on
>>> message DATA, which would reject after the <CRLF>.<CRLF>
>>
>>Exim cannot do that. All it can do is check the syntax of header lines
>>that contain addresses, and ensure that there is a valid sender in one
>>of them.
>
>So it does do some filtering, then? Hmmm ... I just might
>care enough about this to hack something in there myself. But
>the problem is of course that I am complicating a process that
>should be very simple :-(


OK, I've been looking at the source code, specifically the last
lines of accept_msg() in accept.c. To begin with, let me say
that I found everything quite legible.

It seems there is no problem hacking in what I want, namely a
filter before the final 250.

Even better, replying 5xx while still keeping the message is
trivial (though of course I'd have to be reasonably sure that
the message does not generate a bounce later on). That's called
having my cake and eating it too.

Now, the kind of filtering I want to do is quite possible to do
in the code along with the sender/rcpt filtering, which would
have zero impact on performance.

That is what I'm going to do. It means no perl, and a recompile
everytime I want to change something, but I'm not (yet)
conversant enough with options and system filters and exim in
general to envisage putting regexps in the configuration file,
and my system programming is years too mossy to start calling
procmail from C while checking permissions and errors and signal
handlers -- I stopped thinking about it when I found myself
wondering if I should make the call before or after resetting
the signal handlers.

So, simple problem, simple/crude solution. I may start thinking
about something more complicated sometime.

HAND.