On Fri, 7 Dec 2001, dman wrote:
> Unless, of course, you can make a better wheel. This is my reason for
> trying out exim's filtering -- it's syntax looks nicer than procmail's
> (and I don't really understand procmail very much).
But it's facilities are very different.
> Mutt can "bounce" a message (send it to a new address as if the
> original sender had) too.
So can Pine (and no doubt other MUAs), but this is only apparently "as
if the original sender had". If an unprivileged MUA does this on a
traditionally configured Exim system (and other MTAs behave the same),
the envelope sender of the bounced message will be the user who did the
bouncing, not the original envelope sender. (Exim has options to allow
unprivileged users to forge sender addresses, but they are turned off by
default.) Also, Pine adds Resent-From: and Resent-To: headers to the
message, IIRC. The original header lines are unchanged, and these are
what the final recipient sees, so it looks as if the message came from
the original sender to the uninitiated.
In contrast, a forwarding from an Exim filter leaves the envelope sender
address unchanged.
> :-). Hence my idea/suggestion of splitting the filtering capability
> into a separate binary. (I did notice that exim is about 5 times the
> size of procmail. I think a sledgehammer is a bit more than 5 times
> bigger than a nutcracker ;-)).
I'm surprised it's only 5 times bigger. Coconuts, anybody?
If you want to build a procmail-like thing that uses Exim's filtering
syntax, about the only code you could salvage from Exim would perhaps be
the code for parsing the filtering instructions. Everything else would
have to be re-implemented, and I think you would be better off starting
from scratch. Remember, procmail and Exim filters run in different
environments.
1. Procmail has the message arriving on its standard input (usually a
pipe). An Exim filter has the headers decoded and in memory, with the
body in a separate file.
2. Procmail must actually do any deliveries that are specified, and
handle the results. An Exim filter merely *schedules* the deliveries;
they don't happen till later, and the results are handled by the normal
delivery code.
3. The Exim filter code also assumes the availability of general Exim
processing functions for memory handling, string expansion etc. Some of
this might be cribbable, but it wouldn't all be suitable for a
freestanding program.
4. ... and no doubt other similar things.
What I'm saying is "If you want to go there, don't start from here".
> PATTERN="something"
> if ( $header_1 matches $PATTERN or $header_2 matches $PATTERN ) then
> <do something>
> endif
You can do that with
if "$header_1: $header_2:" matches "something" then ...
> What is your opinion of something like :
>
> if anyof [ $header_1 , $header_2 ] matches "some pattern" then
> ...
> endif
Similarly. Or even use $message_headers, which contains a concatenation
of all the header lines.
> if $header_1 matches anyof [ "a pattern" , "another pattern" ] then
> ...
> endif
if $header_1: matches "(a pattern|another pattern|a third pattern)" then...
The Exim filtering facility was designed to provide simple features that
could easily be used by inexperienced end users. It was not intended to
be an all-singing, all-dancing programming language. I have no plans to
extend it significantly.
I believe there is work going on to design a general filtering language,
but I have not kept up with it, and I can't recall a reference.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
