Here's a couple: $ grep g8QGlQbi016840 sendmail.log Sep 26 12:48:46 bugs sendmail[16840]: g8QGlQbi016840: lost input channel from loopback [127.0.0.1] to MTA after rcpt Sep 26 12:48:46 bugs sendmail[16840]: g8QGlQbi016840: from=<[log in to unmask]>, size=0, class=0, nrcpts=34, proto=ESMTP, daemon=MTA, relay=loopback [127.0.0.1] $ grep g8QGlQbi020196 sendmail.log Sep 26 12:48:46 bugs sendmail[20196]: g8QGlQbi020196: lost input channel from loopback [127.0.0.1] to MTA after rcpt Sep 26 12:48:46 bugs sendmail[20196]: g8QGlQbi020196: from=<[log in to unmask]>, size=0, class=0, nrcpts=44, proto=ESMTP, daemon=MTA, relay=loopback [127.0.0.1] -Patrick [log in to unmask] wrote: >On Thu, 26 Sep 2002 11:56:15 EDT, Patrick Price <[log in to unmask]> said: > >>Should I be concerned about these? >> >>Sep 26 11:50:59 bugs sendmail[34894]: g8QFndhQ034894: lost input channel >>from loopback [127.0.0.1] to MTA after rcpt >> > >Aha. > >These are probably the *OTHER* end of the listserv-sendmail connection >going away after the 'resource temporarily unavailable' error. The fact >that the number of hits *increased* when you tweaked SMTP_FORWARD_1 indicates >that whatever is happening is doing so at a fairly low level. > >I admit being at a loss for what resource could run out after the RCPT TO:, >but I'm feeling pretty confident that the problem is that the LSV side starts >sending the mail, gets into the RCPT TO phase, runs out of "something", >and closes the connection. Lather, rinse, repeat. > >Could you take one of those queue id's ( g8QFrghQ031672 for example) and >grep for *all* occurences in your sendmail log? I'm curious about how many >recipients were listed, and exactly how far (and how fast) it got to the >point it died... >