> On 16 Jan 2003, Torsten Luettgert wrote:
>
> > > Again, I don't this should be the default. The sysadmin has
> > > configured Exim to use a filter; delivering without it
> may not be a
> > > good thing. (Consider a filter that is doing some kind of private
> > > encryption...)
> > >
> > > Even as an option it would not be particularly easy to do
> because of
> > > the way Exim is implemented. And I suspect it is of very minority
> > > interest.
>
> It occurs to me that you can implement this yourself. Instead
> of defining
>
> transport_filter = /some/command
>
> you can define
>
> transport_filter = "${if
> first_delivery{/some/command}{something else}}"
>
> Hmm. It seems that there isn't an obvious way to specify
> "something else" to mean "don't filter". An empty string is
> perhaps the obvious answer; I'll think about that. Meanwhile,
> if you really wanted to, you could use a filter that just
> copied the input to the output.
>
Actually "spamc" does copy the input to the output, if "spamd" is down.
The problem is that "spamc" then returns a non-zero exit code, so Exim
fails the filter, although it didn't really fail in this case. I guess
that's really a "spamc" issue.
A presented solution was to make a wrapper to run "spamc", and turn exit
code 69 into exit code 0. But then you have to be sure that wrapper
itself is stable for handling production mail, and it's probably just as
easy to modify "spamc" itself.
> > Having the possibility to freeze the mail after a filter
> error would
> > solve my problem.
>
> Noted for the Wish List.
>
I checked into that and it looks like Exim is indeed freezing messages
when a transport_filter fails. So, we've set our auto_thaw to 1 hour, so
it retries those frozen messages again when (hopefully) spamd is up.
Although not the ideal solution it seems to be working.
I appreciate everyones feedback,
Rich Sandberg
richs@???
