It looks like 1.8e is dropping emails each time this happens. This is how my /spool filled up before leading to overall delivery delays. Sep 26 18:39:26 bugs sendmail[31966]: g8QK7xdC031966: lost input channel from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt Sep 26 18:41:31 bugs sendmail[45148]: g8QMd6bm045148: lost input channel from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt Sep 26 18:44:41 bugs sendmail[31862]: g8QMfBbs031862: lost input channel from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt :/home/listserv/spool>ls -l - -rw-r--r-- 1 listserv staff 7359 Sep 26 18:38 100250.mail -rw-r--r-- 1 listserv staff 5187 Sep 26 18:39 100253.mail -rw-r--r-- 1 listserv staff 4979 Sep 26 18:43 100259.mail -rw-r--r-- 1 listserv staff 6 Sep 26 16:03 listserv.PID Valdis Kletnieks 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... >-- > Valdis Kletnieks > Computer Systems Senior Engineer > Virginia Tech > >