----MESSAGE-BEGIN---- <1983020206170000> Received: from MIT-MULTICS by SRI-NIC at 2-Feb-83 0828-PST Date: 2 February 1983 11:17 est From: Kovalcik.Multics at MIT-MULTICS (Richard Kovalcik, Jr.) Subject: TCP for Prime To: tcp-ip at SRI-NIC Does anyone know of a TCP implementation for the Prime? All leads would be greatly appreciated. -Rick Kovalcik (Honeywell Information Systems, Multics System Development) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983020411190000> Received: from MIT-MULTICS by SRI-NIC at 4-Feb-83 1353-PST Date: 4 February 1983 16:19 est From: JSLove at MIT-MULTICS (J. Spencer Love) Subject: Clarification of PUSH To: TCP-IP at SRI-NIC cc: JSLove.PDO at MIT-MULTICS On page 5 of my copy of RFC 793 is says that PUSH is not intended to provide a record service. With this in mind, I have implemented Multics TCP in such a way that it combines PUSHes whenever convenient. That is, if the segment cannot be transmitted because the window is full, and when the window opens there are several PUSHes outstanding, I format packets which merge PUSHes but which end on a PUSH boundary. Similarly, when the destination process reads out data, and several segments with PUSH set have arrived, I return as much data as will fit in the buffer, provided, again that as long as at least one PUSH is in the buffer that the data ends on a PUSH boundary. In addition, when congestion at the network interface is bad, I essentially reserve a place in the output queue when processing the first PUSH, but postpone formatting the packet until the place marker is near the front of the queue, in which case I take the opportunity to merge PUSHes. This is done for reasons of performance. Because PUSH is not a function of other types of terminal interfaces, reasonable response when communicating with a terminal via the network requires that every separate output operation do a PUSH when it crosses the boundary into the TCP world. The congestion and overhead involved with processing zillions of tiny packets, each with 40 or more bytes of header information, can easily cause a stricter observance of PUSH boundaries to actually delay delivery of data compared to this implementation. I have been looking for a reference which says this is a reasonable interpretation of the spec. I was sure I remembered one but I can't find it. Can someone point out such a reference or find some important objections to this policy? -- Spencer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983020706440000> Received: from MIT-XX by SRI-NIC at 7-Feb-83 0845-PST Date: 7 Feb 1983 1144-EST From: Chris Ryland Subject: Apollo TCP/IP To: tcp-ip@SRI-NIC Anybody have such a beast or know of one? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983021019080000> Mail-From: MILLER created at 11-Feb-83 03:08:22 Date: 11 Feb 1983 0308-PST From: Henry W. Miller Subject: TVT negotiations To: lynch at USC-ISIB, tcp-ip at SRI-NIC cc: Miller at SRI-NIC I just tried the suggestion by Dan Lynch and Charile Lynn about the default retransmission parameters for TVT's by prodding the running monitor, and here is the result: output is alot faster, with fewer pauses, however input seems to have suffered, as there is a much longer delay in echoing, as much as 20 or more characters before they start echoing. BTW, I am now using the system default RX params which are 1 sec num and dem, and 5 seconds backoff. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022404450000> Received: from USC-ISI by SRI-NIC at 24-Feb-83 1246-PST Date: 24 Feb 1983 1245-PST From: DEDWARDS at USC-ISI Subject: Talking to TOPS-20 To: tcp-ip at NIC We have noticed that when connected from our local UNIX system to a TOPS-20 system some strange behavior is noted when typing out files that are larger than a few pages. Specifically, if the terminal page length is set to zero on the TOPS-20 system after a few pages of text has been typed, response becomes non-existant! The system just sits and sends a few bursts of text every few minutes. Yet, if one sets up ones terminal parameters so that output stops every so many lines (term length 24 or whatever), and therefore one needs to type a continutation character at the end of each page, response remains good! Any thoughts, explainations, reasons, fixes for this behavior? Is this TOPS-20 or is it TCP? Howard Weiss ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022414140000> Received: from USC-ISIF by SRI-NIC at 27-Feb-83 2116-PST Date: 24 Feb 1983 2214-PST From: POSTEL at USC-ISIF Subject: Clarification of PUSH To: TCP-IP at NIC cc: JSLove.PDO at MIT-MULTICS Date: 7 Feb 1983 1552-PST Sender: WESTINE@USC-ISIF Subject: Clarification of Push From: Postel@USC-ISIF To: JSLove@MIT-MULTICS Spenser: Your interpretation is super. That is exactly the way I understand the intention of push. One would have a hard time proving it from the specification though! I will keep your note with my master copy to remind me to include more about push in the next edition. --jon. ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022416342800> Received: from PURDUE by SRI-NIC at 24-Feb-83 1838-PST Date: 24 Feb 1983 21:34:28-EST From: Christopher A Kent Reply-to: cak@Purdue To: DEDWARDS@USC-ISI, tcp-ip@NIC Subject: Re: Talking to TOPS-20 If you're running the BBN TCP/IP, there is the possibility that you are seeing the effects of silly window syndrome. The preventative code in the VAX code was commented out, because it didn't work! A fix is being tested here, at BBN, and at Wisconsin ... Cheers, chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022423470000> Received: from USC-ISI by SRI-NIC at 25-Feb-83 0750-PST Date: 25 Feb 1983 0747-PST From: DEDWARDS at USC-ISI Subject: Re: Talking to TOPS-20 To: CLYNN at BBNA cc: tcp-ip at NIC, DEDWARDS at USC-ISI In response to your message sent 25 Feb 1983 0947-EST More specifically, we have run into problems connected from our local system - TYCHO - a PDP 11/34 running the old Version 6 UNIX TCP as distributed by DCA/DCEC and USC-ISIA as well as DEC-MARLBORO. These are the two TOPS-20 sytems that I have personnaly observed the bhavior with. Howard Weiss ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022423580000> Received: from USC-ISI by SRI-NIC at 25-Feb-83 0759-PST Date: 25 Feb 1983 0758-PST From: DEDWARDS at USC-ISI Subject: Talking to TCP TOPS-20 To: tcp-ip at NIC Let me also add - when we first observed the no response syndrome one of our users was connected to USC-ISIA from our Version 6 UNIX with TCP from DCA/DCEC (originally written at BBN). I was able to connect to ISIA from anoher terminal and ran the ISI status program to observe tcp status on connection from TYCHO to ISIA. What was shown was that both hosts had window sizes up in the hundreds ( I think TYCHO was always hovering around 180 and ISIA was somewhere in the range of 800). Also, when the user who had no response tried to send a control C I did see the increase in the seq number on the rcv side (although it took several minutes for the control C to have any effect!). After the user finally broke out and set his terminal to stop on pages, response was good for the rest of his session. Howard Weiss ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022504110000> Mail-From: KLH created at 25-Feb-83 12:11:58 Date: 25 Feb 1983 1211-PST From: KLH at SRI-NIC Subject: Re: Talking to TOPS-20 To: lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC cc: KLH at SRI-NIC In-Reply-To: Your message of 25-Feb-83 1126-PST I think it should be pointed out that the phrase "failure to probe a zero window" is a bit misleading; it implies that the sending site (in this case, a TOPS-20 system) is solely at fault. This is not quite true. The receiving side also has a responsibility to inform the sender when the window opens up again by a sufficient amount. For this case, if both systems are on the ARPAnet I think it highly unlikely that such a window update from the receiver is being lost; thus, I would judge that the UNIX site is never sending one at all. This is bad, because you waste a lot of time if you expect the sender to uncover things by probing the supposedly zero window; note that the TCP document (RFC-793) states on page 42 that the recommended retransmit interval for such probing is two minutes. If this is a reproducible problem (and from the description it certainly appears to be) then it should be easy to finger the culprit simply by logging all the segments for that particular connection. So far, such logs have been my MOST useful tool for debugging TCP problems. I can't over-emphasize the importance of being able to record the actual datagram traffic. --Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022504470000> Received: from BBNA by SRI-NIC at 25-Feb-83 0652-PST Date: 25 Feb 1983 0947-EST Sender: CLYNN at BBNA Subject: Re: Talking to TOPS-20 From: CLYNN at BBNA To: DEDWARDS at USC-ISI Cc: tcp-ip at NIC Message-ID: <[BBNA]25-Feb-83 09:47:58.CLYNN> In-Reply-To: Your message of 24 Feb 1983 1245-PST It has been reported that the TOPS20 TCP does not properly probe zero windows (the problem is being investigated). TERM LEN 0 may well try to fill the window and thus get stuck until a packet arrives from the other end (your continuation character) which specifies a non-zero window. Note that this shouldn't cause a problem unless BOTH the TOPS20 doesn't probe for the window opening AND the UNIX system doesn't send a packet to the TOPS20 when the window opens or the packet gets lost. The TOPS20 code, as last distributed by BBN, contains the silly window prevention algorithm described by Dave Clark (Window and Acknowledgement Strategy in TCP). I know that ISI has modified their code to fill the window; I do not know what changes other sites have made. I would like to request those who are reporting problems to help locate the problem in a changing environment by including in the problem report the names of the hosts involved, the date and time, and, if known, which TCP/IP implementation is involved (e.g. from DEC, from BBN, from ISI, etc. for the TOPS20). Phrases like "a TOPS20" make it difficult to know at which target we should aim our (limited) resources. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022506265200> Received: from EDN-UNIX by SRI-NIC at 25-Feb-83 0834-PST Date: 25 Feb 1983 11:26:52 EST From: James S. Lloyd Subject: Re: Talking to TOPS-20 To: dedwards@usc-isi,tcp-ip@nic Cc: lloyd Howie, If you really get NO response at all ("response is non-existant"), I believe your problem is related to the fact that TOPS-20 TCP no longer probes an advertised zero-window. In the case where you have the terminal pagelength set to zero, it is likely that a large file would congest the TCP receive window faster than the user process (eg. telnet) could read the received data; thus forcing TCP to eventually advertise a receive window of 0. Since the TOPS-20 site does not probe the zero-window a deadlock condition results. In the case of specifying a pagelength, when you enter the appropriate control character used continue the output, your TCP sends the segment containing the control character along with the updated receive window. The fix to the problem lies within the TOPS-20 TCP since failure to probe a zero-window is clearly a violation of the TCP spec. If you get SOME response ("The system just sits and sends a few bursts of text every few minutes."), then it probably is silly window syndrome (SWS) as Chris Kent has pointed out. The response would appear better when using a specified pagelength since the TCP segements containing the control character would probably reflect a more accurate (ie. larger) receive window. RFC-813 by Dave Clark offers some viable solutions to SWS. Regards, Steve Lloyd ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022513225100> Received: from EDN-UNIX by SRI-NIC at 25-Feb-83 1626-PST Date: 25 Feb 1983 18:22:51 EST From: James S. Lloyd Subject: Re: Talking to TOPS-20 To: klh@sri-nic,tcp-ip@sri-nic Cc: lloyd Ken, I couldn't agree with you more about the usefulness of keeping accurate logs since without them I wouldn't be able to say that the TOPS-20 TCP is not probing the zero-window. As far as the Unix TCP sending updates when the window re-opens, you are again right. Our version of TCP does not send a window update automatically. Although I agree that it is good practice to do so, I don't see where the TCP spec says that it MUST be done. On the other hand, I do see where the spec clearly says that a zero-window MUST be probed. Refering to page 42 of RFC-793: The sending TCP must regularly retransmit to the receiving TCP even when the window is zero. Two minutes is recommended for the retransmission interval when the window is zero. This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other. (I would argue that a 2 minute retransmission interval is much too long - esecially when considering this type of problem.) Don't get me wrong, I am not trying to place blame on anyone. Actually, I believe that recovering from small windows should be the responsibility of both parties concerned. The fact that our TCP depends on a zero-window probe does not mean that it is the "right thing to do". All I am saying is that this practice is not a violation of the spec, no matter how inefficient it may seem. Regards, Steve Lloyd ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022600120000> Mail-From: SMTP created at 26-Feb-83 05:57:03 Received: FROM BRL-BMD BY USC-ISIF.ARPA WITH TCP ; 26 Feb 83 05:57:10 PST Sender: Mike Muuss From: TCP-IP@Brl.ARPA To: TCP-IP@Brl.ARPA Date: 26 Feb 1983 Subject: TCP-IP Digest, Vol 2 #1 Received: From brl-gateway.ARPA via smtptcp; 26 Feb 83 5:12 EST TCP/IP Digest Saturday, 26 Feb 1983 Volume 2 : Issue 1 Today's Topics: Administrivia -- Mail Programs for UNIX MOS Driver for Interlan? -- "C" for TCP/IP? Mail in FTP discontinued -- LH/DH-11 Driver for 3Com? SMTP Specification Clarification Gateway Table Availible -- Common SMTP Mail Problems InterNet Software for PDP-11 UNIX Availible TCP/IP above X.25? ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- From: Mike Muuss Subject: Administrivia While BRL's hosts started passing TCP traffic about 6-Jan, we were not able to overcome all our mail difficulties until just recently, so there have been no TCP Digest transmissions since 17-Dec-82. At this time, it should be "business as normal" once again. Remember, please address all submissions to the digest to TCP-IP at BRL and administrative correspondence (addition, deletion, meta-chatter, ...) to TCP-IP-REQUEST at BRL Since the big NCP to TCP conversion is (mostly) behind us now, I think that the topic of the digest should broaden to "Inter-Net Networking -- Design and Implimentation Issues", or thereabouts. Happy New Year! -Mike ------------------------------ Date: 19 Dec 82 02:06:42 EST (Sun) From: Chris Torek Subject: Re: Mail Programs for UNIX ?? To: NADC at Usc-Eclb, TCP-IP at BRL, POSTEL at Usc-Isif From: NADC at Usc-Eclb Subject: Mail Programs for UNIX ?? ... What are other sites with this environment (VAX, UNIX4.1 bsd, and BBN's TCP/IP) using? And what is a source for information on the programs? We are currently running MMDF and are not yet on the net, but have looked into this. The next release of MMDF will have an Arpa channel (an MMDF "channel" is a program that knows how to talk to a particular mailer -- an elegant solution to the multiple-mail-format problem, if you ask me). We were supposed to have received a version of this sometime this week, I think (hello, Dave Farber?) but haven't yet. As soon as we do I plan to hack at it so that it works "right". I'll let you know if we get something working. ------------------------------ Return-Path: Date: 20 December 1982 11:26 est From: DClark.INP at Mit-Multics Subject: Merle: To: neer at Usc-Eclb cc: tcp-ip at BRL We currently run MOS for our local net gateway. We expect to do an Interlan driver during January, unless we hear of one already done. If you can wait that long, you are welcome. We have a non-kernel tcp for Unix written in C. That could be move to a 68000, using the 68000 C compiler. The amount of work would depend on what operating system you were going to run. If you wait somewhat longer, we will do that too. I cannot predict the time, though. Dave Clark ------------------------------ Date: 20 Dec 1982 1651-EST From: Chris Ryland Subject: lightweight C version of TCP/IP To: tcp-ip at BRL I'm looking for a smallish C version of TCP/IP (for the 68000). Any leads to same appreciated. ------------------------------ Date: 20 Dec 1982 1548-PST From: POSTEL at Usc-Isif Subject: Mail in FTP discontinued under TCP To: TCP-IP at BRL Please note that even though the MAIL commands appear in the current document for FTP on TCP (RFC 765) they are not to be used. In the future all mail is to use the SMTP procedures documented in RFC 821. --jon. ------------------------------ Date: Tue, 21 Dec 1982 1629-EST From: Graham Campbell To: tcp-ip at BRL Subject: 3Com TCP/IP Does anyone have the interface code for the 3Com implementation to run an ACC LHDH-11? (We are running Unix v7, but anything would help) ------------------------------ Date: 27 Dec 1982 1612-PST From: POSTEL at Usc-Isif Subject: SMTP Problem To: tcp-ip at BRL Hi: There is a minor problem with many SMTP implementations due to a minor difference between the old specification (RFC-788) and the current specification (RFC-821). The difference is in the details of the reverse-path of the FROM argument of the MAIL command. In 788 the separator between all of the path elements was comma, in 821 the last separator is a colon. For example, in 788 one could have MAIL FROM:<@FOO,@BAR,JOE@HOST> but in 821 this must be MAIL FROM:<@FOO,@BAR:JOE@HOST> Certainly an obscure minor detail, but exactly the kind that computers are good at checking. People that have programs built to RFC-788 should change them soon so they can talk to new programs built to the current specification. This difference also ocurrs in the forward-path argument of the RCPT command. --jon. ------------------------------ Return-path: ROODE@SRI-NIC Date: 5 Jan 1983 2340-PST From: ROODE at SRI-NIC (David Roode) Subject: obtaining gateway table To: tcp-ip@BRL Location: EJ296 Phone: (415) 859-2774 With the cutover to TCP/IP on January 1, many more hosts now have Internet capability. Besides the entries always present in the ARPAnet host table, you now will have use for Internet Gateway entries. These are included as part of the standardized DoD Internet Host Table originally described in RFC 810, dated 1 March 1982. You may wish to utilize the NIC Hostnames Server (RFC 811) to obtain updated copies of the complete table. You can do this by TCP telneting to the NIC on the Hostname Server port (101 decimal), and entering a command line containing one of the following keys: HNAME --search for name HADDR --search for address ALL --dump entire table (all of the above display entries in the standard format) ALL-INGWAY --dump TENEX/TOPS-20 gateway file ALL-HSTNAM --dump TENEX/TOPS-20 gateway file is a name or nicname is a dotted Internet address (RFC 796), for example 10.0.0.73, composed of the four octets of the full 32 bit Internet address, each expressed in decimal The command line is terminated by carriage return. [ Hosts are strongly encouraged to reload their host tables frequently. Either when booting the system, or at certain times during the week seems to be the best approach. -Mike ] ------------------------------ Date: 17 Jan 1983 2255-PST From: POSTEL@Usc-Isif.arpa Subject: Common Mail Problems To: mike@Brl.arpa You might consider this for the TCP-IP-DIGEST. --jon. Date: 17 Jan 1983 2218-PST From: MOCKAPETRIS at USC-ISIF Subject: common SMTP problems In an effort to help mail implementers identify mail problems more rapidly, we have created a list of problems we have encountered, in the hope that others may not have to find them the same way we did. The file will be kept in ISIFmail.errors, and we encourage any contributions. It at least shows you some of the armor plating you need on your mailer. We have also set up a list of SMTP people in ISIF:SMTP.PEOPLE which has contacts for those installations we know of. Both files are ANONYMOUS accessible. ***** Accepting paths ***** Some mailers do not accept SMTP paths. In general, an SMTP receiver should always accept a path in the FROM specifiaction, even if it cannot relay mail, and hence can't accept paths in a TO specification. ***** "," vs ":", bad syntax errors ***** During August 1982, the SMTP specification for paths was changed. In the old specification, SMTP paths were specified using only commas. For example: MAIL FROM:<@ISID,MOCKAPETRIS@ISIF> RCPT TO:<@ISIA,@ISIB,SMTP@ISID> whereas the new specification changes the last ",", if any, to a colon: MAIL FROM:<@ISID:MOCKAPETRIS@ISIF> RCPT TO:<@ISIA,@ISIB:SMTP@ISID> Various mailers will accept only one or the other form, leading to (typically) syntax errors. The recommended approach to this problem is to accept both forms, and to generate ":" form addresses. More clever mailers will try the other form when one fails, and will avoid path creation when not necessary. That is send MAIL FROM: rather than MAIL FROM:<@ISIF,MOCKAPETRIS@ISIF> or MAIL FROM:<@ISIF:MOCKAPETRIS@ISIF> where possible. ***** various marginal addresses ***** We have seen several instances of mail transfers with commands like: RCPT to: rather than : RCPT to: We recommend that if your mailer accepts this sort of thing, it should rewrite the address before forwarding. I.E. Its OK to accept technically bad addresses, but you should not output them. ***** TCP PSH bit = timeouts ***** When sending SMTP data via TCP, the PSH bit should be set on the last character of each command/response/DATA text. The PSH bit forces the data through to the receiving SMTP. This is absolutely necessary when talking to TOPS-20 SMTPs. If PSH isn't set, TCP is free to buffer that data in either the sending or receiving host without passing it to the SMTP receiver. ***** UNIX TCP BUG = duplicated mail, timeouts ***** In at least old versions of the TCP code distributed by BBN, there is a bug that can cause buffered data to not be sent until more data is transmitted. When used by SMTP, this typically causes the end of a DATA transaction to appear to hang. When the sending SMTP times out, it sends a QUIT. This QUIT forces out the buffered data, and causes the receiver to see the end of the DATA commmand. Thus the sender thinks the transaction has failed (it timed out), and the receiver thinks that the transaction has succeeded. Later, the sender retransmits the whole message, leading to duplications. The fix is below: In tcp-states.c, procedure sss_snd, under the comment "find end of send buffer and append data", a while clause reading: while (m->m_next != NULL) { m = m->m_next; last +=m->m_len; } is in error. The fix is to reverse the two statements in the clause. As it is it counts the last buffer twice and the first buffer not at all. With the fix, each buffer is counted once. ***** CRLF at end of message ***** There is a bug in many versions of XMAILR that will garbage the MAIL.TXT file if asked to store a message that does not end in CRLF. The ISI SMTP adds an extra CRLF to all messages as a temporary cludge to avoid this problem. ***** CRLF and UNIX systems ***** Some UNIXes send mail that if full of LFs rather than CRLFs. This can cause problems in mail reading programs such as MSG, which can type the mail but not locate header fields. ***** Null FROM fields ***** The SMTP specification allows the FROM field to be null. Some mailers don't accept null fields, and others add hops to a null FROM field when forwarding mail. ***** Domain names ****** There is a great deal of disagrement regarding doamin names in host identifiers. The only widely acceptable domain names are X.ARPA for X, where X is a valid Internet (i.e. host table from NIC) host name. This will undoubtedly change as domain naming is standardized. ***** HELO command ***** Many mailers demand a HELO command before they will accept mail. Its best to give one before attempting to transmit. ***** QUIT command ***** Several mailers simply hang up rather than sending QUITs, particularly after errors. The QUIT command, followed by a TCP close, is recommended. ***** TCP close ****** SMTP connections are supposed to be closed rather than aborted. Several mailers don't do this, probably because TCP close can take a long time, i.e. 30 seconds. ***** RCPT command responses in UNIX SMTP ***** Some versions of SMTP derived from the BBN code don't look at the response to RCPT commands. ***** Multi-line responses ***** The SMTP protocol defines a method for giving multi-line response codes. Many mailers generate multi-line responses; some even use them in the message sent on initial connect. Unfortunately, some mailers don't understand multi-line responses. We have seen UNIX mailers that take each line of a multi-line response as a separate response. Thus, for example, they take a 3 line initial connect message and interpret it as the initial connect message and positive responses to the first two commands sent, and stay two commands out of phase in matching up commands and responses. This leads to interesting behavior. We have also observed the reverse problem. Some mailers send multi-line responses without the "-" which would identify the response as being multi-line. ***** sndmsg balks ***** Some versions of SMTP derived from the BBN SMTP seem to occasionally send SMTP responses without numeric codes. The message typically contains text "sndmsg balks ...". Other messages without codes are also seen. ***** TELNET protocol in SMTP transactions ***** The SMTP connection is not supposed to do TELNET negotiations, etc. The control codes used can make otherwise understandable transmissions unintelligible to SMTPs that don't implement TELNET codes. TELNET codes should not be supported because they would destroy the ability of the SMTP protocol to send arbitrary octets in the message body. Admittedly this is not a real issue for DEC-10s and 20s, but could prevent future use of mail to send arbitrary text. ***** \ and " in addresses ****** The use of the \ and " in addresses should be avoided when not necessary because many mailers don't as yet do the right thing; those mailers should be fixed. ------------------------------ Date: 26 Jan 1983 1028-EST (Wednesday) From: martin@Mit-Csr.arpa Subject: Internet Software for Unix To: TCP-IP@Brl.arpa This is probably an appropriate forum to mention the existence of some internet software which is running on our PDP 11/45 version 6 (with local mods) UNIX. In the kernel we have modules to drive a "Pronet" device (10 Mb/s token-passing ringnet), to transmit and receive internet packets, to demultiplex incoming TCP and UDP packets, to reassemble internet fragments, and to maintain a cache of internet hosts and their best first hop gateways. Kernel code and data use from 9k to 10.5k bytes depending on the size of the receive packets buffer. Outside the kernel we have: TCP, user and server telnet, SMTP, ICMP, and TFTP. All are running but are in varying stages of development. We are willing to give this software to anyone who wants it, has a Unix source license, and will agree to a few constraints. We should point out that it would be difficult for someone who is not a Unix wizard to install this code. To find out more about the software send mail to martin@mit-csr or to lwa@mit-csr. Liza Martin Larry Allen ------------------------------ Date: Fri 7 Jan 83 03:41:54-EST From: Marc Shapiro Subject: Request for info To: tcp-ip@BRL.ARPA, protocols@MIT-MC.ARPA, human-nets@RUTGERS.ARPA I need info on the following topics: * Are there any implementations of either TCP/IP or TCP alone *above* X.25 for DEC-20 and/or Vax/unix * all possible info on Ethernet/X.25 gateways, supported protocols and what they are worth. Thanks. Please reply directly to SHAPIRO@MIT-XX. [ Replies might as well include the digest too. -Mike ] ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [bnews.brl-bmd.517] <1983022619471100> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!duke!unc!brl-bmd!TCP-IP@BRL From: TCP-IP@BRL Date: Sun Feb 27 00:47:11 1983 Subject: TCP-IP Digest, Vol 2 #1 X-Google-Info: Converted from the original B-News header Posted: Sat Feb 26 05:19:23 1983 Received: Sun Feb 27 00:47:11 1983 TCP/IP Digest Saturday, 26 Feb 1983 Volume 2 : Issue 1 Today's Topics: Administrivia -- Mail Programs for UNIX MOS Driver for Interlan? -- "C" for TCP/IP? Mail in FTP discontinued -- LH/DH-11 Driver for 3Com? SMTP Specification Clarification Gateway Table Availible -- Common SMTP Mail Problems InterNet Software for PDP-11 UNIX Availible TCP/IP above X.25? ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- From: Mike Muuss Subject: Administrivia While BRL's hosts started passing TCP traffic about 6-Jan, we were not able to overcome all our mail difficulties until just recently, so there have been no TCP Digest transmissions since 17-Dec-82. At this time, it should be "business as normal" once again. Remember, please address all submissions to the digest to TCP-IP at BRL and administrative correspondence (addition, deletion, meta-chatter, ...) to TCP-IP-REQUEST at BRL Since the big NCP to TCP conversion is (mostly) behind us now, I think that the topic of the digest should broaden to "Inter-Net Networking -- Design and Implimentation Issues", or thereabouts. Happy New Year! -Mike ------------------------------ Date: 19 Dec 82 02:06:42 EST (Sun) From: Chris Torek Subject: Re: Mail Programs for UNIX ?? To: NADC at Usc-Eclb, TCP-IP at BRL, POSTEL at Usc-Isif From: NADC at Usc-Eclb Subject: Mail Programs for UNIX ?? ... What are other sites with this environment (VAX, UNIX4.1 bsd, and BBN's TCP/IP) using? And what is a source for information on the programs? We are currently running MMDF and are not yet on the net, but have looked into this. The next release of MMDF will have an Arpa channel (an MMDF "channel" is a program that knows how to talk to a particular mailer -- an elegant solution to the multiple-mail-format problem, if you ask me). We were supposed to have received a version of this sometime this week, I think (hello, Dave Farber?) but haven't yet. As soon as we do I plan to hack at it so that it works "right". I'll let you know if we get something working. ------------------------------ Return-Path: Date: 20 December 1982 11:26 est From: DClark.INP at Mit-Multics Subject: Merle: To: neer at Usc-Eclb cc: tcp-ip at BRL We currently run MOS for our local net gateway. We expect to do an Interlan driver during January, unless we hear of one already done. If you can wait that long, you are welcome. We have a non-kernel tcp for Unix written in C. That could be move to a 68000, using the 68000 C compiler. The amount of work would depend on what operating system you were going to run. If you wait somewhat longer, we will do that too. I cannot predict the time, though. Dave Clark ------------------------------ Date: 20 Dec 1982 1651-EST From: Chris Ryland Subject: lightweight C version of TCP/IP To: tcp-ip at BRL I'm looking for a smallish C version of TCP/IP (for the 68000). Any leads to same appreciated. ------------------------------ Date: 20 Dec 1982 1548-PST From: POSTEL at Usc-Isif Subject: Mail in FTP discontinued under TCP To: TCP-IP at BRL Please note that even though the MAIL commands appear in the current document for FTP on TCP (RFC 765) they are not to be used. In the future all mail is to use the SMTP procedures documented in RFC 821. --jon. ------------------------------ Date: Tue, 21 Dec 1982 1629-EST From: Graham Campbell To: tcp-ip at BRL Subject: 3Com TCP/IP Does anyone have the interface code for the 3Com implementation to run an ACC LHDH-11? (We are running Unix v7, but anything would help) ------------------------------ Date: 27 Dec 1982 1612-PST From: POSTEL at Usc-Isif Subject: SMTP Problem To: tcp-ip at BRL Hi: There is a minor problem with many SMTP implementations due to a minor difference between the old specification (RFC-788) and the current specification (RFC-821). The difference is in the details of the reverse-path of the FROM argument of the MAIL command. In 788 the separator between all of the path elements was comma, in 821 the last separator is a colon. For example, in 788 one could have MAIL FROM:<@FOO,@BAR,JOE@HOST> but in 821 this must be MAIL FROM:<@FOO,@BAR:JOE@HOST> Certainly an obscure minor detail, but exactly the kind that computers are good at checking. People that have programs built to RFC-788 should change them soon so they can talk to new programs built to the current specification. This difference also ocurrs in the forward-path argument of the RCPT command. --jon. ------------------------------ Return-path: ROODE@SRI-NIC Date: 5 Jan 1983 2340-PST From: ROODE at SRI-NIC (David Roode) Subject: obtaining gateway table To: tcp-ip@BRL Location: EJ296 Phone: (415) 859-2774 With the cutover to TCP/IP on January 1, many more hosts now have Internet capability. Besides the entries always present in the ARPAnet host table, you now will have use for Internet Gateway entries. These are included as part of the standardized DoD Internet Host Table originally described in RFC 810, dated 1 March 1982. You may wish to utilize the NIC Hostnames Server (RFC 811) to obtain updated copies of the complete table. You can do this by TCP telneting to the NIC on the Hostname Server port (101 decimal), and entering a command line containing one of the following keys: HNAME --search for name HADDR --search for address ALL --dump entire table (all of the above display entries in the standard format) ALL-INGWAY --dump TENEX/TOPS-20 gateway file ALL-HSTNAM --dump TENEX/TOPS-20 gateway file is a name or nicname is a dotted Internet address (RFC 796), for example 10.0.0.73, composed of the four octets of the full 32 bit Internet address, each expressed in decimal The command line is terminated by carriage return. [ Hosts are strongly encouraged to reload their host tables frequently. Either when booting the system, or at certain times during the week seems to be the best approach. -Mike ] ------------------------------ Date: 17 Jan 1983 2255-PST From: POSTEL@Usc-Isif.arpa Subject: Common Mail Problems To: mike@Brl.arpa You might consider this for the TCP-IP-DIGEST. --jon. Date: 17 Jan 1983 2218-PST From: MOCKAPETRIS at USC-ISIF Subject: common SMTP problems In an effort to help mail implementers identify mail problems more rapidly, we have created a list of problems we have encountered, in the hope that others may not have to find them the same way we did. The file will be kept in ISIFmail.errors, and we encourage any contributions. It at least shows you some of the armor plating you need on your mailer. We have also set up a list of SMTP people in ISIF:SMTP.PEOPLE which has contacts for those installations we know of. Both files are ANONYMOUS accessible. ***** Accepting paths ***** Some mailers do not accept SMTP paths. In general, an SMTP receiver should always accept a path in the FROM specifiaction, even if it cannot relay mail, and hence can't accept paths in a TO specification. ***** "," vs ":", bad syntax errors ***** During August 1982, the SMTP specification for paths was changed. In the old specification, SMTP paths were specified using only commas. For example: MAIL FROM:<@ISID,MOCKAPETRIS@ISIF> RCPT TO:<@ISIA,@ISIB,SMTP@ISID> whereas the new specification changes the last ",", if any, to a colon: MAIL FROM:<@ISID:MOCKAPETRIS@ISIF> RCPT TO:<@ISIA,@ISIB:SMTP@ISID> Various mailers will accept only one or the other form, leading to (typically) syntax errors. The recommended approach to this problem is to accept both forms, and to generate ":" form addresses. More clever mailers will try the other form when one fails, and will avoid path creation when not necessary. That is send MAIL FROM: rather than MAIL FROM:<@ISIF,MOCKAPETRIS@ISIF> or MAIL FROM:<@ISIF:MOCKAPETRIS@ISIF> where possible. ***** various marginal addresses ***** We have seen several instances of mail transfers with commands like: RCPT to: rather than : RCPT to: We recommend that if your mailer accepts this sort of thing, it should rewrite the address before forwarding. I.E. Its OK to accept technically bad addresses, but you should not output them. ***** TCP PSH bit = timeouts ***** When sending SMTP data via TCP, the PSH bit should be set on the last character of each command/response/DATA text. The PSH bit forces the data through to the receiving SMTP. This is absolutely necessary when talking to TOPS-20 SMTPs. If PSH isn't set, TCP is free to buffer that data in either the sending or receiving host without passing it to the SMTP receiver. ***** UNIX TCP BUG = duplicated mail, timeouts ***** In at least old versions of the TCP code distributed by BBN, there is a bug that can cause buffered data to not be sent until more data is transmitted. When used by SMTP, this typically causes the end of a DATA transaction to appear to hang. When the sending SMTP times out, it sends a QUIT. This QUIT forces out the buffered data, and causes the receiver to see the end of the DATA commmand. Thus the sender thinks the transaction has failed (it timed out), and the receiver thinks that the transaction has succeeded. Later, the sender retransmits the whole message, leading to duplications. The fix is below: In tcp-states.c, procedure sss_snd, under the comment "find end of send buffer and append data", a while clause reading: while (m->m_next != NULL) { m = m->m_next; last +=m->m_len; } is in error. The fix is to reverse the two statements in the clause. As it is it counts the last buffer twice and the first buffer not at all. With the fix, each buffer is counted once. ***** CRLF at end of message ***** There is a bug in many versions of XMAILR that will garbage the MAIL.TXT file if asked to store a message that does not end in CRLF. The ISI SMTP adds an extra CRLF to all messages as a temporary cludge to avoid this problem. ***** CRLF and UNIX systems ***** Some UNIXes send mail that if full of LFs rather than CRLFs. This can cause problems in mail reading programs such as MSG, which can type the mail but not locate header fields. ***** Null FROM fields ***** The SMTP specification allows the FROM field to be null. Some mailers don't accept null fields, and others add hops to a null FROM field when forwarding mail. ***** Domain names ****** There is a great deal of disagrement regarding doamin names in host identifiers. The only widely acceptable domain names are X.ARPA for X, where X is a valid Internet (i.e. host table from NIC) host name. This will undoubtedly change as domain naming is standardized. ***** HELO command ***** Many mailers demand a HELO command before they will accept mail. Its best to give one before attempting to transmit. ***** QUIT command ***** Several mailers simply hang up rather than sending QUITs, particularly after errors. The QUIT command, followed by a TCP close, is recommended. ***** TCP close ****** SMTP connections are supposed to be closed rather than aborted. Several mailers don't do this, probably because TCP close can take a long time, i.e. 30 seconds. ***** RCPT command responses in UNIX SMTP ***** Some versions of SMTP derived from the BBN code don't look at the response to RCPT commands. ***** Multi-line responses ***** The SMTP protocol defines a method for giving multi-line response codes. Many mailers generate multi-line responses; some even use them in the message sent on initial connect. Unfortunately, some mailers don't understand multi-line responses. We have seen UNIX mailers that take each line of a multi-line response as a separate response. Thus, for example, they take a 3 line initial connect message and interpret it as the initial connect message and positive responses to the first two commands sent, and stay two commands out of phase in matching up commands and responses. This leads to interesting behavior. We have also observed the reverse problem. Some mailers send multi-line responses without the "-" which would identify the response as being multi-line. ***** sndmsg balks ***** Some versions of SMTP derived from the BBN SMTP seem to occasionally send SMTP responses without numeric codes. The message typically contains text "sndmsg balks ...". Other messages without codes are also seen. ***** TELNET protocol in SMTP transactions ***** The SMTP connection is not supposed to do TELNET negotiations, etc. The control codes used can make otherwise understandable transmissions unintelligible to SMTPs that don't implement TELNET codes. TELNET codes should not be supported because they would destroy the ability of the SMTP protocol to send arbitrary octets in the message body. Admittedly this is not a real issue for DEC-10s and 20s, but could prevent future use of mail to send arbitrary text. ***** \ and " in addresses ****** The use of the \ and " in addresses should be avoided when not necessary because many mailers don't as yet do the right thing; those mailers should be fixed. ------------------------------ Date: 26 Jan 1983 1028-EST (Wednesday) From: martin@Mit-Csr.arpa Subject: Internet Software for Unix To: TCP-IP@Brl.arpa This is probably an appropriate forum to mention the existence of some internet software which is running on our PDP 11/45 version 6 (with local mods) UNIX. In the kernel we have modules to drive a "Pronet" device (10 Mb/s token-passing ringnet), to transmit and receive internet packets, to demultiplex incoming TCP and UDP packets, to reassemble internet fragments, and to maintain a cache of internet hosts and their best first hop gateways. Kernel code and data use from 9k to 10.5k bytes depending on the size of the receive packets buffer. Outside the kernel we have: TCP, user and server telnet, SMTP, ICMP, and TFTP. All are running but are in varying stages of development. We are willing to give this software to anyone who wants it, has a Unix source license, and will agree to a few constraints. We should point out that it would be difficult for someone who is not a Unix wizard to install this code. To find out more about the software send mail to martin@mit-csr or to lwa@mit-csr. Liza Martin Larry Allen ------------------------------ Date: Fri 7 Jan 83 03:41:54-EST From: Marc Shapiro Subject: Request for info To: tcp-ip@BRL.ARPA, protocols@MIT-MC.ARPA, human-nets@RUTGERS.ARPA I need info on the following topics: * Are there any implementations of either TCP/IP or TCP alone *above* X.25 for DEC-20 and/or Vax/unix * all possible info on Ethernet/X.25 gateways, supported protocols and what they are worth. Thanks. Please reply directly to SHAPIRO@MIT-XX. [ Replies might as well include the digest too. -Mike ] ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983022807230000> Received: from CMU-CS-A by SRI-NIC at 28-Feb-83 1040-PST Date: 28 February 1983 1223-EST (Monday) From: don To: KLH at SRI-NIC Subject: Re: Talking to TOPS-20 CC: lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC Sender: don.provan at CMU-CS-A Reply-To: don.provan at CMU-CS-A In-Reply-To: KLH\@SRI-NIC's message of 25 Feb 83 15:11-EST Message-Id: <28Feb83 122308 DP0N@CMU-CS-A> do i have the wrong TCP document? there's nothing i've been able to find in mine indicating any need for the receiving TCP to inform the sender when a zero window enlarges. in particular, in my experience, TACs do NOT send this information. for expediency in the tops-10 TCP implmentation, rather than wait 2 minutes to retransmit the probe byte, i just threw it on the retransmission queue to be retransmitted at the current retransmission rate (5 seconds). even this proved too long, so i now retransmit the probe byte every second. this seems acceptable. it would obviously be better if i could just be told that the window was enlarged so neither i nor the receiver had to deal with these discarded probe bytes, but i can't expect the receiver to do this. ----MESSAGE-END----