"Lost input channel" does not mean lossy network. It means that
the connection was somehow closed without getting a "QUIT" command.
That could be the result of:
Posted on Thursday, September 18, 2003 - 07:24 pm:
ZMI,
We definitely send a QUIT.
The only thing I can see that might be an issue is that we do not wait for a
response back to the QUIT ... after we send the QUIT we terminate the
connection. I can't see why that would cause a problem.
But I'm still a bit puzzled by the error message that you get because it says
"after rcpt" ...
The basic sequence of actions in an SMTP dialog is:
HELO or EHLO
MAIL FROM:
RCPT TO: (one or more of these)
DATA
(send the content of the message)
.
Then "QUIT" if you want to end the session, or you may want to "RSET" and send
another message (I'm not sure if "RSET" is required in that instance as I'm not
an SMTP expert, but it seems like a good idea.)
Anyway, if the input channel is lost after a "RCPT TO:" command, that doesn't
make sense, because the "DATA" command would have had to follow in order to send
the message.
But it's always hard to guess what an error message in somebody else's software
product means.
Maybe we can try a more graceful closing of the port ... wait for the response
before closing ... maybe that will make a difference.
-bn
ZMI
| Posted on Thursday, September 18, 2003 - 08:18 pm: |
Maybe you only do not send QUIT if you received an error ("relay not
allowed" in my case).
As a side note: if definitly would be helpful if there could be an option to log
the smpt, http, etc. error message the MMSC receives.
Matthew Coulson <[email protected]> sent:
> To: [email protected]
> Subject: Re: Sendmail "Lost input channel"
> Message-ID: <[email protected]>
>
> It doesn't look like this is the case since the error message looks includes
> Lost input channel from [202.88.xxx.xxx]
>
> I have nmapped several of the remote systems and OS detected and they were
> running a variety of OS's. I think the problem may still revolve around the
> network somehow. So my original question of how to change the MTU size and
> how to see if I have having any errors at the network layer or higher on the
> OpenBSD server still applies?
>
> Matthew Coulson
>
> On Tue, Jun 17, 2003 at 08:44:33AM +0000, Alexander Farber wrote:
> > Hi,
> >
> > I think this message comes because MS Outlook just
> > drops connection to sendmail and there are several
> > reasons why it would do that.
> >
> > Regards
> > Alex
> >
> > On Tue, Jun 17, 2003 at 02:10:23AM -0600, [email protected] wrote:
> > > I am regularly seeing in my sendmail error logs the message "Lost input channel"
> > > looking on the web I see that this is typically a sign of a lossy connection. I
> > > am wondering what I can do to verify that is the problem is indeed a lossy
> > > connection. All of the statistics on my router and switches look fine however
> > > that doesn't negate this error message. I have not seen any other network
> > > connectivity problems. The server can access the web just fine and perform
> > > large downloads, scp large files, etc without a hitch. Any ideas? I also saw
> > > on the web that perhaps I might want to change my mtu size to help solve this
> > > however I am unaware of how to change my mtu size. Is there any other
> > > network setting I might want to change?
> > >
> > > TIA,
> > >
> > > Matthew Coulson
>
>
"Lost input channel" does not mean lossy network. It means that
the connection was somehow closed without getting a "QUIT" command.
That could be the result of
defective client software
network problems
The most common cause of "lost input channel" that I see is from
spammer software. Those too often don't say bye nicely. You can't
fix those with mtu. (at least, not nicely.)
If you think it's a network problem, rather than guessing "mtu
problem", you should probably try to establish that it *is* a network
problem, and that it's something you can fix at your end. You can only
do this by learning more about the problem. A misconfigured firewall
at either your end or theirs could cause problems. You can fix your
firewall, but probably not theirs. Some people have firewall rules
that are intended to stop spammers or vandals. Occasionally, people in
the middle try "interesting" tricks against spammers as well. Are you
sure they don't think you are a spammer? Are you sure they aren't a
spammer?
If you can narrow the problem down to known ip addresses, try tcpdump.
If it's a remote mail server with mail stuck in its queue that it can't
deliver to you, it will retry more or less regularly; and it probably
won't be sending you much other traffic. That should make it easy to
see what your end sees. A stuck queue entry at your end is even easier
to study -- run tcpdump & force a delivery retry on the errant
message. If you have more than one network segment of the path to the
remote site under your control, you might try running tcpdump on each
segment walking towards the remote site.
Once you have a good packet trace, *then* you can start making guesses
as to the problem. If it's a problem at your end, it will be obvious.
Reducing your mtu should only be necessary if the other end (or
something in the middle) has a smaller mtu than your localhost and
something between that & your host is blocking icmp messages so
breaking path mtu discovery. This is why you don't want to block all
icmp messages. Instead of using ifconfig to change mtu on all packets,
you can use "route" to add a static route to a problem IP address and
set an mtu on that route. This solution won't scale well however, so
you shouldn't even bother thinking about doing this if you have more
than 1 remote problem address.
If it's a path mtu problem at the other end, since you won't see the
big packet or the icmp message back, you may have to guess a bit. But
if you don't see anything past where you expect a "DATA" response
(where you would expect the first large packet) an mtu issue is a
possibility. Unfortunately, reducing your end's mtu in this case won't
fix the problem. You would instead need to fix the other end's mtu
size, identify the place in the middle that blocks icmp messages, or
perhaps advertise a smaller tcp window size on your end. Probably
in this case you would want to start by talking to postmaster@ the
other end, if mail from that site is worth receiving.
I hadn't heard that MS outlook just "drops connections" -- but that's
easy enough to test -- fire it up and see what happens.
-Marcus
| Product: | InterScan MSS for UNIX | |
| Version: | 5.1 for Solaris | |
| Solution ID: | 15397 | |
| Created: | 7/8/2003 12:03:28 PM |
| Problem: | The administrator sees the following in the Sendmail log : Jul 1 08:22:10 serverabc sendmail[2137]: [ID 23213 mail.notice] f674vIh1735: lost input channel from localhost [127.0.0.1] to MTA after rcpt |
|
| Solution: | To resolve this issue, do the following:
|
Thanks for all responses.
Brett Morgan <[email protected]>
"Thomas D. Knox" <[email protected]>
Dave McFerren <[email protected]>
Jochen Bern <[email protected]>
"Howard Boggs" <[email protected]>
"Erin Jones" <[email protected]>
Zareh Aratoon <[email protected]>
[email protected] (Marina Daniels)
Michael Cunningham <[email protected]>
Charles Holbrook <[email protected]>
For second problem, everyone give the solution right way, run newaliases.
For first question, The responses give lot idea to help me figure out what is
happening.
It turns out That somehow the users address book corrupted, one address entry
without address in. After he try to send out, the mail is queued and give the
error. After that he send a few other messages which all have correct
address, but when try to send correct message, eudora try to send out first
queued message first. Then no message send out. Because I don't want look at
other people's messages, so I did not even look the messages he try to send.
After I ask him to delete first queued message and try to send others again.
He recognize that he did have address in there, put address in, everything
works.
Thanks!
Feng Qiu
ORIGINAL MESSAGE:
> Hello, all,
> I have Ultra2 with solaris7. sendmail8.9.3 with qpopper2.5.3.
> One of my user got error message when he send mail through eudora in his
> Mac:
>
> There has been an error tranferring your mail,
> I said: DATA
> and then the SMTP server said:
> 503 Need RCPT (recipient)
>
> I found following in mail log:
>
> Oct 27 17:48:35 nmrserv sendmail[9739]: RAA09739: lost input channel
> from mac23.chem.okstate.edu [139.78.124.99]
> Oct 27 17:48:35 nmrserv sendmail[9739]: RAA09739:
> from=<[email protected]>,
size=0, class=0, pri=0, nrc pts=0,
> proto=ESMTP, relay=mac23.chem.okstate.edu [139.78.124.99]
>
> Anyone knows the problem? Thanks!
>
> Another error in my mail log is:
>
> Oct 27 16:09:59 nmrserv sendmail[9599]: alias database
> /etc/mail/aliases.pag out of date
>
> What is this mean? What should I do about it?
>
> Thanks!
> Feng Qiu