The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1983)
DOCUMENT: TCP-IP Distribution List for February 1983 (16 messages, 12610 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1983/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      2 February 1983 11:17 est
From:      Kovalcik.Multics at MIT-MULTICS (Richard Kovalcik, Jr.)
To:        tcp-ip at SRI-NIC
Subject:   TCP for Prime
Does anyone know of a TCP implementation for the Prime?  All leads would
be greatly appreciated.

-Rick Kovalcik (Honeywell Information Systems, Multics System
Development)
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      4 February 1983 16:19 est
From:      JSLove at MIT-MULTICS (J. Spencer Love)
To:        TCP-IP at SRI-NIC
Cc:        JSLove.PDO at MIT-MULTICS
Subject:   Clarification of PUSH
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
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 1983 1144-EST
From:      Chris Ryland <CPR@MIT-XX>
To:        tcp-ip@SRI-NIC
Subject:   Apollo TCP/IP
Anybody have such a beast or know of one?
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1983 0308-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        lynch at USC-ISIB, tcp-ip at SRI-NIC
Cc:        Miller at SRI-NIC
Subject:   TVT negotiations
	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
-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1983 1245-PST
From:      DEDWARDS at USC-ISI
To:        tcp-ip at NIC
Subject:   Talking to TOPS-20
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
-------
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1983 2214-PST
From:      POSTEL at USC-ISIF
To:        TCP-IP at NIC
Cc:        JSLove.PDO at MIT-MULTICS
Subject:   Clarification of PUSH
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.
-------
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1983 21:34:28-EST
From:      Christopher A Kent <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
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 0747-PST
From:      DEDWARDS at USC-ISI
To:        CLYNN at BBNA
Cc:        tcp-ip at NIC, DEDWARDS at USC-ISI
Subject:   Re: Talking to TOPS-20
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
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 0758-PST
From:      DEDWARDS at USC-ISI
To:        tcp-ip at NIC
Subject:   Talking to TCP TOPS-20
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
-------
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 1211-PST
From:      KLH at SRI-NIC
To:        lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC
Cc:        KLH at SRI-NIC
Subject:   Re:  Talking to TOPS-20
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
-------
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 0947-EST
From:      CLYNN at BBNA
To:        DEDWARDS at USC-ISI
Cc:        tcp-ip at NIC
Subject:   Re: Talking to TOPS-20

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

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 11:26:52 EST
From:      James S. Lloyd <lloyd@EDN-UNIX>
To:        dedwards@usc-isi,tcp-ip@nic
Cc:        lloyd
Subject:   Re:  Talking to TOPS-20
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


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1983 18:22:51 EST
From:      James S. Lloyd <lloyd@EDN-UNIX>
To:        klh@sri-nic,tcp-ip@sri-nic
Cc:        lloyd
Subject:   Re:  Talking to TOPS-20
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


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1983
From:      TCP-IP@Brl.ARPA
To:        TCP-IP@Brl.ARPA
Subject:   TCP-IP Digest, Vol 2 #1
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 <Mike@BRL>
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 <chris.umcp-cs@Udel-Relay>
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: <DClark@MIT-MULTICS.ARPA>
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 <CPR@Mit-Xx>
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 <gc@Bnl>
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 <name>	    --search for name
	HADDR <addr>	    --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

<name> is a name or nicname
<addr> 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 ISIF<SMTP>mail.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>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:<MOCKAPETRIS@ISIF>
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:<mockapetris>
rather than :
	RCPT to:<mockapetris@isif>

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 <Shapiro@MIT-XX.ARPA>
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
********************

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Sun Feb 27 00:47:11 1983
From:      TCP-IP@BRL
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #1


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 <Mike@BRL>
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 <chris.umcp-cs@Udel-Relay>
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: <DClark@MIT-MULTICS.ARPA>
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 <CPR@Mit-Xx>
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 <gc@Bnl>
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 <name>	    --search for name
	HADDR <addr>	    --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

<name> is a name or nicname
<addr> 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 ISIF<SMTP>mail.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>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:<MOCKAPETRIS@ISIF>
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:<mockapetris>
rather than :
	RCPT to:<mockapetris@isif>

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 <Shapiro@MIT-XX.ARPA>
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
********************

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      28 February 1983 1223-EST (Monday)
From:      don
To:        KLH at SRI-NIC
Cc:        lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC
Subject:   Re: Talking to TOPS-20
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.

END OF DOCUMENT