Thanks for the comments about filters. My original message said:
> I have been implementing a system-wide filter.
:
> If you try to do anything at all structured the read-only nature of the
> filter processing language becomes a bit painful.
:
after which I asked the wrong question, ie "what do I lose by not using a
filter and running through procmail instead from the exim config file."
What I really should have asked was "how can I have filters that aren't a
complete pain to write things like custom anti-spam in?".
If you look at
ftp://ftp.cs.huji.ac.il/pub/exim/spam_filter/ for example
you can see a good effort at anti-spam. But in modifying and extending it
to do different things I soon came across things I didn't like, such as
the inability to make changes to the Subject line, put the result in a
variable and make further changes a little later before delivering the
message. I've considered the use of compiled-in perl and piping to
procmail within a system filter and neither helps because the problem is
the nearly completely read-only nature of the filter language. I really
want to chop and change the contents before I take some action on a
message, rather than just choosing which action to take based on the
contents.
The thing is, to make the filter spec capable of doing this would mean
that it would have become yet another procmail-like package.
Dan
--
*** Exim information can be found at
http://www.exim.org/ ***
