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
yep it's still not working and other people are still reporting the
same problem.

On 5/19/05, Justin Frydman <justin.frydman@???> wrote:
> well it did it again, [<exim defunct>] and lots of child process
> errrors in the exim logs :(
>
> On 5/18/05, Justin Frydman <justin.frydman@???> wrote:
> > 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}}
> > > >
> > >
> >
>