[Mimedefang] Network issues causing broken pipe errors (and subsequent tempfails)?

[Michael Sims]

David F. Skoll wrote:
> On Fri, 27 Feb 2004, Michael Sims wrote:
>> Basically I say all this to ask a question.  Is it possible that this
>> message is taking so long to transfer that the MD slave is dying
>> before it is fully received, and this is what is causing the broken
>> pipe error?
>
> Nope.  No slave is even involved until the message has been received
> in
> its entirety.

After thinking about it some more, I suspected that this was the case.  I
also suspect that explains why different slaves may handle filter_relay(),
filter_sender(), and filter_recipient() from the ones that handle
filter_begin(), filter(), and filter_end(), since you wouldn't want a slave
to hang around waiting for the DATA phase to complete...

> Right.  The multiplexor knows nothing about the message until it has
> been completely collected.  My guess is that there's a libmilter
> timeout somewhere that's terminating the milter thread.  See
>
http://www.sendmail.com/partner/resources/development/milter_api/smfi_settim
eout.html

I've been digging around a bit in the sendmail source (milter.c).  I always
assumed that these "to error state" log entries were being logged by
mimedefang, but I see that it's sendmail that these messages are coming
from.  It doesn't appear that any of your code calls smfi_settimeout, and
the documentation that comes with 8.12.10 says the default is 7210 seconds
(instead of the 1800 that the documentation the above URL points to stated).
That's slightly over two hours, and each time the message in question was
tempfailed, sendmail logged a delay of well over two hours, so that makes
sense.  I guess the reason I haven't seen this before is that it's pretty
rare for a message to take over 2 hours to deliver. :)

If I decided I wanted to troubleshoot this further, just for kicks, could I
simply add a call to smfi_settimeout before mimedefang.c calls smfi_main,
like this?

--- mimedefang.c.orig   Fri Feb 27 19:14:11 2004
+++ mimedefang.c        Fri Feb 27 19:14:18 2004
@@ -1905,6 +1905,7 @@
     } else {
        syslog(LOG_WARNING, "Multiplexor unresponsive - entering main loop
anyway");
     }
+    smfi_settimeout(14400);
     return smfi_main();
 }

I barely know anything about C at all, but this doesn't look like rocket
science...

___________________________________________
Michael Sims
Project Analyst - Information Technology
Crye-Leike Realtors
Office: (901)758-5648  Pager: (901)769-3722
___________________________________________