Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!jaynes
From: jaynes@med.umich.edu (William Jaynes)
Newsgroups: comp.protocols.tcp-ip
Subject: Sendmail/SMTP/TCP mystery?
Message-ID: <1991Feb25.153352.14063@engin.umich.edu>
Date: 25 Feb 91 15:33:52 GMT
Sender: news@engin.umich.edu (CAEN Netnews)
Reply-To: jaynes@med.umich.edu (William Jaynes)
Organization: University of Michigan Health Sciences, Ann Arbor
Lines: 44
Originator: jaynes@ives.itn.med.umich.edu


Someone felt that this problem may be a more general TCP protocol discrepancy
causing packets to be lost or ignored, so here is what I have posted elsewhere..

----------
Last week I noticed that messages to a particular host were being queued on
my mailhub.  The sendmail message  is

  (Deferred: Connection timed out during result wait with uv1.im.med.umich.edu)

These messages never get delivered.  All attempts fail until they time out and
are bounced.

The mailhub is a SunSLC.  The host in question is a Vax running some
Wollengong TCP-IP/SMTP etc. software.  Up until last week there was not a problem.
Both of us sys admins swear that we haven't changed anything. (of course)

Here are some facts:
    - A short message (less then about 1100 bytes) will be delivered.
      A longer message will not.
    - I forced my Suns (4.1 and 4.1.1) to skip the mailhub and mail direct
      and got the same results: longer messages were queued with the same
      deferred message.
    - I forced my Decs (Ultrix 4.0) to skip the mailhub and mail direct
      and did NOT get the same results.  Mail worked fine.
    - From my Suns, if I telnet to port 25 of the Vax and fake mail, I can
      send as big a message as I want.
    - From Suns that are not on my net (141.214) and which mail direct to the
      Vax, I can send as big a message as I want. (One is 4.0.3c)
    - This one Vax is the ONLY host with which there is a problem.
      Other Vaxen on the same ethernet don't have a problem. (I don't know
      if the other Vaxen use the same SMTP software.)
    - The data files are properly terminated with a 0x0a.

Using a Sniffer, I looked at packets during delivery attempts that failed.
The Suns simply aren't sending a <CR><LF>.<CR><LF> after the data is
sent.  Instead they send the data again and again until the connection
times out.  But they do send <CR><LF>.<CR><LF> on the short messages.

Why this one Vax?  Why the Suns and not the Decs?  What's going on?
-------

I have since seen that the SUNs and DECs are conifgured NOTRAILERS.
Doing an ifconfig on the VAX doesn't give a reference to trailers.


Brought to you by Super Global Mega Corp .com