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
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}}
>