Nicklas,
> I finally found the root of the problem. The QMQP code in qmail have
> hardcoded timeouts set. 10 seconds for connect and 60 seconds for
> read/write. If amavisd processing takes longer than 60 secs you get the
> early MTA connection drop.
>
> I found the following patch by Eric Hess on
> The 3.7 minutes is well below 8 minutes of $child_timeout, so
> amavisd does not time out on this message.
>
> If MTA times out with waiting earlier than in 3.7 minutes,
> you end up with mail message being send, one copy at every
> attempt: amavisd successfully processes and forwards the
>
> Fix MTA timeout, it should not give up sooner than
> $child_timeout time, customarily MTA timeout is set to 20
> minutes. Don't know how to set this timeout value\ on qmail.
qmail is running with it's default timeout values, which is 1200 secs. I've
got another log (see previous posts) saying
Nicklas,
> Here is level 5 amavisd logs from both sending and receiving MTA. ...
> I'm sorry but the qmail MTA logs didn't say much. ...
> you can't see message id's in those logs. What you
> want to do is tracing the id from amavisd->MTA logs.
Thanks, that is more helpful.
The mail size is 4.9
> > In this case I get "do_unzip: p003, zero length members,
> archive retained".
> > Seems like this is triggering the odd behaviour on the other end.
>
> I'm working on better timeouts for daemonized AV checkers, but we
> should really take a look at your log and timestamps there and
> timesta
