On Fri, Dec 07, 2001 at 10:12:50AM +0000, Philip Hazel wrote:
| On Thu, 6 Dec 2001, dman wrote:
|
| > $ ypcat passwd | grep dsh8290
| > dsh8290:##dsh8290:3283:150:Derrick S Hudson;951;wsen1;:/home/stu12/s18/dsh8290:/bin/csh
| >
| > $ egrep "^EXIM_[UG]ID" Local/Makefile
| > EXIM_UID=3283
| > EXIM_GID=150
|
| Those values agree with the passwd file, BUT:
|
| > 2001-12-06 22:24:06 16CBcE-0001BX-00 Unable to get root to set
| > uid 3283 and gid 6 for local delivery to dsh8290: uid=3283 euid=3283
|
| Exim wants to set gid=6. That's the problem. Why is it trying to do
| that? What have you got in your Exim configuration for the appendfile
| transport? You need to have it want to use gid=150, I suspect.
Oops, I didn't notice the gid it wanted to set to. I found
"group = mail" in the localdelivery section (which was correct as the
system MTA on my debian box).
| > I'm glad the feature has already been included, but I think it is a
| > bug that the default delivery fails when there is no reason to. Maybe
| > it would be better if the filter part was factored out into a separate
| > binary. The main exim binary can do the main MTA functions, and
| > invoke the filter binary in much the same way procmail is (commonly)
| > used today.
|
| If you want to do that, use procmail. No need to re-invent the wheel.
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).
| Note that the facilities available are different when Exim is used as a
| full MTA for a host (which is what it's designed for). In the
| environment for which it was designed, an Exim filter can do "true
| forwarding" (leaving the sender address unchanged), whereas something
| running as a user process (such as procmail) can only resubmit the
| message - thereby changing the sender. That is just one of the
| differences.
Mutt can "bounce" a message (send it to a new address as if the
original sender had) too.
| > This would also allow people who only want filtering to
| > ignore the rest of the MTA's capability.
|
| Using an MTA just to do personal filtering is using a sledgehammer to
| crack a nut.
:-). 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 ;-)).
| > (then again, one could argue
| > that delivery is not part of the MTA's responsibility at all, and all
| > of the local delivery and filtering should be handled by separate MDA
| > program)
|
| People do argue that way. Exim has no problem with that approach. Build
| it with only a pipe or lmtp transport and use them.
Actually, I was thinking "build it with only filtering, message input
as a pipe".
| > 1) Can I create and use variables of my own choosing in a filter
| > file?
|
| No.
One other usage I was thinking of is :
PATTERN="something"
if ( $header_1 matches $PATTERN or $header_2 matches $PATTERN ) then
<do something>
endif
What is your opinion of something like :
if anyof [ $header_1 , $header_2 ] matches "some pattern" then
...
endif
or
if $header_1 matches anyof [ "a pattern" , "another pattern" ] then
...
endif
where [] is the list notation from python and "anyof" is a new
operator? There should probably be an "oneof" operation to correspond
to it, if this is added. (you are not promising to implement this if
you state that you don't utterly detest this idea)
| > 2) Can I include another filter file?
|
| No (though that is on the Wish List).
Cool.
-D
--
He who finds a wife finds what is good
and receives favor from the Lord.
Proverbs 18:22
