Lost Input Channel...
Daniel Holden
it. I have people trying to send email to a list and this is the error I
see in /var/log/maillog.
--
Daniel Holden
dho...@idsb.net
http://www.idsb.net
Claus Aßmann
> Does anyone know what "lost input channel from ..." means and what causes
> it. I have people trying to send email to a list and this is the error I
> see in /var/log/maillog.
Networking problem
or
the sender just hang up (telnet?)
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
james
spammers. There are always 3 log entries together:
Dec 18 12:42:13 sendmail[1166]: fBIHgDi01166: ruleset=check_rcpt,
arg1=<jim...@shoalhaven.net.au>, relay=cg637548-a.adubn1.nj.home.com
[24.252.123.221], reject=550 5.7.1 <jim...@shoalhaven.net.au>... Relaying
denied
Dec 18 12:42:13 sendmail[1166]: fBIHgDi01166: lost input channel from
cg637548-a.adubn1.nj.home.com [24.252.123.221] to MTA after rcpt
Dec 18 12:42:13 mail.th.net sendmail[1166]: fBIHgDi01166:
from=<cy1...@prodigy.net>, size=0, class=0, nrcpts=0, proto=SMTP,
daemon=MTA, relay=cg637548-a.adubn1.nj.home.com [24.252.123.221]
It looks like they are using the "lost input channel" to somehow slide the
mail through? Anyone
else seen this? We're using sendmail 8.12.1.
thanks,
James Triplett
Thelix Internet
"Claus Aßmann" <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de>
wrote in message news:9vitlj$t3m$1...@zardoc.esmtp.org...
Warren Block
> I see a lot of these "lost input channel" messages, particularly from some
> spammers. There are always 3 log entries together:
>
> Dec 18 12:42:13 sendmail[1166]: fBIHgDi01166: ruleset=check_rcpt,
> arg1=<jim...@shoalhaven.net.au>, relay=cg637548-a.adubn1.nj.home.com
> [24.252.123.221], reject=550 5.7.1 <jim...@shoalhaven.net.au>... Relaying
> denied
> Dec 18 12:42:13 sendmail[1166]: fBIHgDi01166: lost input channel from
> cg637548-a.adubn1.nj.home.com [24.252.123.221] to MTA after rcpt
> Dec 18 12:42:13 mail.th.net sendmail[1166]: fBIHgDi01166:
> from=<cy1...@prodigy.net>, size=0, class=0, nrcpts=0, proto=SMTP,
> daemon=MTA, relay=cg637548-a.adubn1.nj.home.com [24.252.123.221]
>
> It looks like they are using the "lost input channel" to somehow slide the
> mail through? Anyone else seen this? We're using sendmail 8.12.1.
I've seen it, but thought it was just a spammer checking for an open
relay. When they get the "Relaying denied" message, the spamware
disconnects and tries the next one on the list. It could be that the
ratware gets better performance by avoiding closing the session, or it
could just be that spammers are worthless bottom feeders who aren't
interested in treating your system nicely unless you have something they
can steal.
I don't think any mail actually gets through; have to watch for that now.
--
Warren Block * Rapid City, South Dakota * USA
Per Hedeland
I guess that about sums it up.:-)
>I don't think any mail actually gets through; have to watch for that now.
It doesn't - I guess you (both of you:-) are getting confused by the
'from=' line logged last - it's just sendmail dumping qinfo it has
already collected (in particular the envelope sender, i.e. the address
given in 'MAIL From:'), and which wouldn't have been logged until the
message had been received if it hadn't been rejected by check_rcpt. The
size=0 and nrcpts=0 clearly show that no message was received and no
recipients were accepted.
In general, it is of course possible for a message to have some
recipients that get rejected as "relaying denied" and others that do
not. Assuming the sender dosen't give up as soon as it gets a rejection
for one recipient (a correctly functioning and "legitimate" SMTP client
shouldn't, of course), the from= line will then give the actual size of
the message and the number of non-rejected recipients, and there will be
to= line(s) specifying those recipients (or rather the resulting
recipients after aliasing etc).
--Per Hedeland
p...@bluetail.com