Re: [exim] odd spamd error, people say it's an exim bug

Top Page
Delete this message
Reply to this message
Author: Justin Frydman
Date:  
To: exim-users
Subject: Re: [exim] odd spamd error, people say it's an exim bug
adding the temp_errors = * after 24 hours i have yet to have any issues.

Thanks Tony.

On 5/17/05, Justin Frydman <justin.frydman@???> wrote:
> Thanks Tony I did read the changelog, just didn't understand that was
> the fix there.
>
> please understand i am quite new to exim configs etc so should i set a
> timeout_defer directive under my spamcheck directive and that should
> fix my issues? because spamd is still dying and exim defunct is
> showing up in ps aux with exim 4.51 and spam assassin 3.02.
>
> here is what I currently have:
>
> spamcheck:
> driver = pipe
> batch_max = 100
> command = /usr/sbin/exim -oMr spam-scanned -bS
> current_directory = "/tmp"
> group = mail
> home_directory = "/tmp"
> log_output
> message_prefix =
> message_suffix =
> return_fail_output
> no_return_path_add
> transport_filter = /usr/bin/spamc -u
> ${lookup{$domain}lsearch*{/etc/virtual/domainowners}{$value}}
> use_bsmtp
> user = mail
> temp_errors = *
> # must use a privileged user to set $received_protocol on the way back in!
>
>
> I just added the temp_errors = * to see how it will go.
>
> thanks for your time,
>
> Justin
>
>
>
> On 5/17/05, Tony Finch <dot@???> wrote:
> > On Tue, 17 May 2005, Justin Frydman wrote:
> >
> > > hrmm so i don't have a local_sa_delivery etc to add temp_errors too.
> > > where should it go?
> >
> > Perhaps you should try reading the log message, which helpfully indicates
> > the transport that failed:
> >
> > 2005-05-17 08:57:39 1DY2Ux-0006er-Cw <jay@xxxxxxxxxxxxxxxxxxx>: spamcheck transport output: An error was detected while processing a file of BSMTP input.
> >
> > > is this patch included in exim 4.51? if not then this bug is not fixed.
> >
> > Perhaps you should try reading the ChangeLog, which helpfully lists which
> > patches have been included in version 4.51.
> >
> > PH/45 In a pipe transport, although a timeout while waiting for the pipe
> >       process to complete was treated as a delivery failure, a timeout while
> >       writing the message to the pipe was logged, but erroneously treated as a
> >       successful delivery. Such timeouts include transport filter timeouts. For
> >       consistency with the overall process timeout, these timeouts are now
> >       treated as errors, giving rise to delivery failures by default. However,
> >       there is now a new Boolean option for the pipe transport called
> >       timeout_defer, which, if set TRUE, converts the failures into defers for
> >       both kinds of timeout. A transport filter timeout is now identified in
> >       the log output.

> >
> > Tony.
> > --
> > <fanf@???> <dot@???> http://dotat.at/ ${sg{\N${sg{\
> > N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
> > \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
> >
>