doug@csd4.milw.wisc.edu (Doug Tiarks) (05/22/89)
I've gotten a number of replies on my sendmail posting. Thanks to all who responded. From what I've gathered it appears that the problem is not with sendmail itself, but is a manifestation of a problem on part of the Internet. There is a gateway which is clobering packets greater than about 1k. This would cause sendmail to hang when attempting to deliver messages > 1k because the packets with the message couldn't get through. I'm not sure which hosts this affects, but the problem is being worked on. On a related note phil@ux1.cso.uiuc.edu mentions: >I have been seeing this happen occaisionally on several hosts receiving mail >>from IBM VM SMTP. Some cases have been verified as having well over 100 >destination addresses, one per line, in the RFC822 To: field. Attempts to >send the same mail to other hosts running sendmail 5.61 also resulted in >sendmail getting hung. Another version of sendmail delivered the mail, but >inserted a blank line after the 100 or so To: addresses it was parsing. There is a problem in sendmail v5.61 that causes it to hang on large headers (such as a large To: field). The problem and a fix were posted on comp.bugs.4bsd. If anyone is interested in it let me know. Doug Tiarks UW-Milwaukee Computing Services Div. Internet: doug@csd4.milw.wisc.edu UUCP: {uwvax, uwmacc}!uwmcsd1!doug -- Doug Tiarks UW-Milwaukee Computing Services Div. Internet: doug@csd4.milw.wisc.edu UUCP: {uwvax, uwmacc}!uwmcsd1!doug
narten@CS.PURDUE.EDU (Thomas Narten) (05/23/89)
> There is a gateway which is clobering packets greater than about 1k. > This would cause sendmail to hang when attempting to deliver messages > > 1k because the packets with the message couldn't get through. I'm > not sure which hosts this affects, but the problem is being worked on. Without suggesting that this unnamed gateway exhibits reasonable behavior, let me point out that any TCP implementation that blindly sends out packets larger than 576 bytes in size is asking for trouble because no host or gateway is required to be able to *accept* datagrams larger than 576 bytes in size. The TCP layer should divide data generated by the application into reasonably-sized TCP segments. (Thus, large sendmail writes aren't your problem.) Current wisdom suggests that 576 bytes is an upper limit on the size of IP datagrams that a host should send in the absense of explicit information that larger packets won't cause problems. (See Mogul and Kent's 1987 SIGCOMM paper "Fragmentation Considered Harmful" for more details on the evils of large packets.) So, if your sending TCP is generating 1000 byte packets to send across the Internet, your TCP/IP implementation needs work. Thomas Narten
jbvb@VAX.FTP.COM (James Van Bokkelen) (05/24/89)
One consideration that hasn't been discussed is what TCP MSS options are sent when the connection is opened, and how the two hosts are supposed to deal with them. I have some recent experience with IBM VM systems which request 1460 byte MSS regardless of whether the connection is on the local subnet, or routed via a gateway. If your host's TCP/IP is just accepting and using the requested MSS (or min(1024, FRN_MSS), as Unices tend to), this could be the problem. FTP's TCP requests a 512-byte MSS when the connection is routed via a gateway, and uses min(512, FRN_MSS) on the transmit side (a relatively recent change; I used to just do what they told me, but 'they' were all too frequently broken). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
ELINSKY@YKTVMX.BITNET ("Jay Elinsky") (05/26/89)
James B. VanBokkelen writes: > ...I have some recent experience with IBM VM systems which >request 1460 byte MSS regardless of whether the connection is on the local >subnet, or routed via a gateway. ... Actually, our VM and MVS TCP/IP programs let you specify the MSS separately for each route, if desired. So if some networks are reachable through gateways that are known to accept large packets, you can tell our TCP to use large packets for better performance and efficiency. (TCP still respects the MSS offered by the other end, of course). Or you can specify the default size of 576, or even 512 like FTP Software's TCP does, if you aren't sure that some or all routes can handle larger packets. If James' recent experience with an IBM VM system is the one that I remember, the customer's TCP/IP configuration did specify a larger size for the route through ARPAnet. I suggested that they use the default size for the route, and I assume that that fixed the problem. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY