On Mon, Dec 10, 2001 at 10:34:34AM +0000, Philip Hazel wrote:
| 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.
Ahh, I see.
| > :-). 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?
$ du -sk bin/procmail bin/exim
79 bin/procmail
512 bin/exim
$ python -c "print 512.0/79"
6.48101265823
Ok, I was a little off.
| 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.
[ architectural overview ]
Ok, thanks. I see now how exim's filter implementation fits in with
the overall architecture, and how it can't (easily) be factored out
into a stand-alone app.
| > 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 ...
Cool.
| > What is your opinion of something like :
| >
| > if anyof [ $header_1 , $header_2 ] matches "some pattern" then
| > ...
| > endif
|
| Similarly.
Actually, the (immediately) above is the result of wanting to do the
(farther) above.
| Or even use $message_headers, which contains a concatenation
| of all the header lines.
Unless you only want a match on a subset of all the headers.
| > if $header_1 matches anyof [ "a pattern" , "another pattern" ] then
| > ...
| > endif
|
| if $header_1: matches "(a pattern|another pattern|a third pattern)" then...
Erm, yeah, I know about alternations. Brain fart. :-).
| 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.
If you can recall any keywords that would yield a fruitful google
search, I'm interested. I've actually been considering creating a
filter program.
In any event, I might not as I've learned a bit more about procmail
recently (partly in comparing it to exim, and partly from some
comments on debian-user regarding recent spam).
-D
--
Q: What is the difference betwee open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
number and they will tell you it might be solved in a future version.
For open-source sofware there isn't a phone number to call, but you
get the solution within a day.
