Subject: Its back

From: [email-masked]
Date: 8 Jan 1988 13:44:02 EST

17-Jan-83 14:02:01-PST,7082,000000000001
Date: 17 Jan 83 14:03 PST 
From: [email-masked]
Subject: SMTP MAIL ERRORS

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.
18-Jan-83 10:45:38-PST,4224;000000000001
Mail-From: SMTP created at 18-Jan-83 10:45:34
Date: 18 Jan 1983 10:37 PST
From: Taft at PARC-MAXC
Subject: Re: common SMTP problems
To: MOCKAPETRIS@USC-ISIF
cc: Postel@USC-ISIF, Taft

Your compilation of SMTP pitfalls should be very useful.  I've already stumbled
over many of them!

A couple of comments/questions:

1. QUIT command

What is supposed to be the problem with simply closing the connection?  The
QUIT handshake seems entirely redundant.  I know TCP close has rather peculiar
semantics in some implementations (e.g., the Tops20/Tenex TCP) and is therefore
somewhat flakey; but such problems should be fixed at the TCP level rather than
adding useless baggage to higher-level protocols.

2. Domain names

I've been forced to adopt a rather permissive attitude about the presence or
absence of root (top-level) domain elements such as .ARPA, since many SMTPs
don't send them (and, for that matter, most users don't type them).  Note,
however, that when the root domain element is considered to be optional, parsing
of domains becomes syntactically ambiguous.  Resolving this problem requires
applying semantic information, such as consulting the host table.

For example, the names "[email-masked]" and "[email-masked]" are
syntactically indistinguishable; but the host name of interest (for the purpose of
making SMTP connections) is "Berkeley" in both cases.  My algorithm is to use
the next-to-last element as the host name if the last element is "ARPA", else to
use the last element as the host name.

Also, the presence or absence of source routes in mailbox paths complicates
matters.  In a path of the form "x@y", y is the domain of interest; but in a path
of the form "x,y:z@w", x is the domain of interest (i.e., the one which should be
parsed to derive the name of the host to connect to).  This means that y in the
first case and x in the second case may be assumed to have "ARPA" as their root
element, whether they say so or not.  But note well that in the second case,
nothing can be assumed about y and w, and in general it would be incorrect to
automatically append ".ARPA" to either one.

For example, consider the following two pairs of paths:

1a) @ISIF.ARPA:Mockapetris@ISIF
1b) @ISIF.ARPA:[email-masked]

2a) @Berkeley.ARPA:foo!harpo!bilbo!frodo@RandomVAX
2b) @Berkeley.ARPA:[email-masked]

The first two paths are equivalent, and so are the second (or at least they might
be; I'm not too familiar with the Berkeley name space).  In the first instance the
mailbox is within the ARPA root domain, but in the second it is not.  When the
root element is not given, it is not possible to tell on a syntactic basis what the
root element is.  And actually there is no way of knowing whether or not a root
element exists unless you have a table of all possible root domains (a bad idea, in
my estimation).  Consider:

2c) @Berkeley.ARPA:[email-masked]

You may say that abbreviated domains shouldn't be sent; and in fact both the
header standard and the SMTP spec say precisely this.  But a lot of
implementations do send abbreviated domains anyway.  And even if they don't,
PEOPLE will type abbreviated domains, and the mail-sending software can't
always tell whether domains are abbreviated or not.  I think I have shown that
just mindlessly pasting on ".ARPA" everywhere would be incorrect, since there
exist root domains other than ARPA.  (UUCP and CSNET are the only ones I'm
aware of at present, but the number is sure to grow.)

What to do?  I don't see this problem being solved until name servers become
widely available and are sufficiently robust and sufficiently available to be
trusted.  Such servers must (a) be capable of looking up multi-element domains,
abbreviated or not, and returning an authoritative answer as to how they should
be parsed; and (b) be sufficiently up-to-date that they can be guaranteed to
contain at least all the root domains.

	Ed Taft

25-Jan-83 01:19:18-PST,1089;000000000001
Mail-From: SMTP created at 25-Jan-83 01:16:29
Date:           Tue, 25 Jan 1983 01:10:18 PST
From:           Rich Wales <wales@UCLA-Net>
To:             mockapetris@isi
Subject:        another mail bug to add to your list

When we fixed the bug in our sender-SMTP ("mailer.c") from BBN which
prevented it from looking at the reply to an RCPT command, we found
another bug.

As distributed, the only affirmative reply BBN's "mailer.c" will take
was a 250.  It looped forever until it got either a 250 or a rejection
(4xx or 5xx).  If the receiver-SMTP happened to reply with a 251 ("will
forward to ..."), our sender-SMTP would ignore that reply and timeout
waiting for something else.

Lots of mail for ISI is probably getting held up by this one, needless
to say.

The fix was fairly easy -- changing a "while (i != 250)" to "while
(i != 250 && i != 251)".

-- Rich

27-Jan-83 10:59:33-PST,1323;000000000001
Mail-From: SMTP created at 27-Jan-83 10:55:33
Date:           Wed, 27 Jan 1982 09:41:58 PST
From:           Rich Wales <wales@UCLA-Net>
To:             Robert Gurwitz <gurwitz@bbnv>
CC:             Paul Mockapetris <mockapetris@isi>
CC:             Lou Nelson <lou@aerospace>,
                Evelyn Walton <eve@ucla-net>,
                Charles Kline <csk@ucla-net>
Subject:        Silly Window Syndrome in BBN TCP kernel code

The BBN TCP kernel code suffers from Silly Window Syndrome.  The piece
of code designed to combat this problem (near line 230 of bbnnet/-
tcp_procs.c) suffers from Non-Terminated Comment Syndrome and thus
never gets compiled into the program.

	/* Avoid silly window syndrome: make sure usable window
	   is at least 25% of offered window.  Be sure the user
	   is not blocked for send resources. 
	
	else if (!tp->rexmt && !tp->ack_due && !tp->snd_fin &&
		 up->uc_snd != up->uc_ssize && tp->snd_wnd > 0 && 
		 100*((tp->snd_lst-tp->snd_una)/tp->snd_wnd) < 25)
		tp->snd_lst = tp->snd_nxt; 

Is this intentional?  (My initial assumption is that it isn't.)

-- Rich

27-Jan-83 14:45:48-PST,1278;000000000001
Mail-From: SMTP created at 27-Jan-83 14:10:53
Date:           Thu, 27 Jan 1983 12:33:06 PST
From:           Rich Wales <wales@UCLA-Net>
To:             gurwitz@bbnv
CC:             mockapetris@isi, lou@aerospace, eve@ucla-net,
                csk@ucla-net
Subject:        more on Silly Window Syndrome in BBN TCP kernel code

Regarding the code in "tcp_procs.c" to sidestep Silly Window Syndrome,
I just noticed what appears to be a bug.  (My apologies for not having
noticed it when I wrote my previous message!)

The computation

	100*((tp->snd_lst-tp->snd_una)/tp->snd_wnd) < 25

doesn't look like it will work right, since the result of the division
will be truncated to zero before being multiplied by 100.

It seems that the following modified version would work:

	(100*(tp->snd_lst-tp->snd_una))/tp->snd_wnd < 25

(where the outer set of parens is not really necessary, because of the
left-to-right evaluation).

For that matter, you could even use a left-shift for greater speed.

	((tp->snd_lst-tp->snd_una)<<2)/tp->snd_wnd < 1

-- Rich

25-Jan-83 13:54:55-PST,1566;000000000001
Mail-From: POSTEL created at 25-Jan-83 13:53:15
Date: 25 Jan 1983 1353-PST
From: POSTEL at USC-ISIF
Subject: DOMAIN STYLE NAMES
To:   "Internet-Contacts":

Hello:

This message is about the domain style names that were introduced with 
the new mail system.  The domain style names will be used in the future 
for all naming of hosts, not just in mail.

Currently all host names used in the Internet must be registered and 
kept on file at the Network Information Center.

The intent is to set in place a naming convention that allows for the 
eventual subdivision of the authority for assigning host names.  In the 
future, the Internet will be much larger and the task of maintaining a 
central list of all the hosts will become impossible.  The task of 
maintaining host name to address mapping tables, and tables of other 
information about hosts will, of necessity, be subdivided among a number
of authorities.

While policies and procedures are being developed for the use of the 
domain style names, we must restrict the use of such names.  One of the 
key issues to be resolved is to itemize the requirements on a naming 
subauthority.  One requirement will be to provide online hostname to 
address lookup servers.  Another task to be completed is the 
specification the protocol to be used in accessing such servers.

Currently the only permitted use of the domain style names is the form

   "hostname.ARPA"

where "hostname" is registered with the NIC and on file in the NIC's 
HOSTS.TXT file.

--jon.

-------
 1-Feb-83 09:53:08-PST,1282;000000000001
Mail-From: POSTEL created at  1-Feb-83 09:48:01
Date:  1 Feb 1983 0948-PST
From: POSTEL at USC-ISIF
Subject: more info for mail.errors
To:   MOCKAPETRIS at USC-ISIF

Mail-From: SMTP created at  1-Feb-83 08:38:40
Return-path: ajg@ll-vlsi
Received: FROM LL-VLSI BY USC-ISIF.ARPA WITH TCP ; 1 Feb 83 08:32:31 PST
Date: 1 Feb 1983 11:33:02-EST
From: ajg at ll-vlsi
To: dmpowles@bbn-unix
Subject: more mail problems
Cc: ajg@ll-vlsi, postel@isif

Hi,
  There are several additional problems with the 
delivermail version of smtp.c.
  If the the local mailer is delivermail smtp
responds O.K. to any RCPT command, even if the
recipient is not known locally. Delivermail
then fails, and smtp issues a "451 sndmsg balks .. try again".
The RCPT argument should be checked, anf if the user is
unknown a 550 should be issued.
  Also the MAIL argument is ignored, and delivermail 
is invoked with the "a" switch, get sender from message
header. The parser in delivermail dies on some message headers,
which again results in a "451 sndmsg balks ..."
Delivermail should probably be invoked with "f" switch,
with the argument from the MAIL command.

              -Tony Giovinazzo
               MIT Lincoln Laboratory
               617 863 - 5500 X2702
-------
 6-Feb-83 10:55:30-PST,743;000000000001
Mail-From: SMTP created at  6-Feb-83 10:53:02
Return-path: [email-masked]
Received: FROM PARC-MAXC BY USC-ISIF.ARPA WITH TCP ; 6 Feb 83 10:48:05 PST
Date: 6 Feb 1983 10:47 PST
From: [email-masked]
Subject: Another common SMTP problem
To: [email-masked]
cc: [email-masked], [email-masked]

Here is another problem I've been seeing quite a lot of lately: SMTP senders who
issue a QUIT command and then (without waiting for the reply) immediately
either close or abort the connection.  This causes the server to get an I/O error
while trying to send the reply.  If you use QUIT at all (I still consider it entirely
pointless), you should wait for the reply before terminating the connection.
	Ed

12-Feb-83 16:55:33-PST,2156;000000000001
Mail-From: SMTP created at 12-Feb-83 16:51:45
Date: 12-Feb-83 16:46 PST
From: WWB.TYM@OFFICE-3
Subject: NOSC SMTP weirdness
To: postel@isif, mockapetris@isif
Cc: RLL.TYM@OFFICE-3, DAP.TYM@OFFICE-3, DIA.TYM@OFFICE-3

Well.. you asked me to let you know if I saw anything weird anywhere.. and I 
did.  We've had a message or two bottled up on office-7 for many days now for 
NOSC.  Connections seem to get made sometimes (and not others) but it blows up 
mysteriously.  I spotted an odd one in the logs today - happened a couple times.
 Seems to be an instance of the missing-CR problem.  I tried to test it "by 
hand" and the thing disconnected remotely before I got a whole message body 
typed in!  That's too short a timeout.  Anyhow, as best I can guess from my 
lousy logs, the thing accepts ANY address at the RCPT stage but after the DATA 
part, it complains and presumably says NO if it doesn't like the address 
(ARPAVAX.MAILER-DAEMON@NOSC is the specific badguy).  But the way in which it 
says NO is weird, seeming to put out several messages that were intended to be 
separate, separated by linefeeds.  Namely, " Mail not 
delivered.<LF>ARPAVAX.MAILER-DAEMON... User unknown<LF>250 Mail Accepted.", 
which is then apparently followed by a quick disconnect or something.  There 
might have been a numeric code in front of the message; due to bad logging 
habits I wouldn't know.

The unwillingnesss of their server to listen long enough for me to send then a 
complaint msg by hand leaves us high and dry.  Do you know anything about this 
kind of thing?  I think they are running the BBN UNIX code, but not sure.  In 
any case they seem screwy to me.  If you happen to try it and discover anything,
I'd be interested in hearing of it.  -Bill

PS.  Very early in the picture, I seem to remember that we did send some 
messages successfully to NOSC.  Maybe they broke something while trying to jazz 
up something else recently.

15-Feb-83 07:07:50-PST,1188;000000000001
Mail-From: SMTP created at 15-Feb-83 06:45:26
Date: 15 Feb 1983  9:27:36 EST (Tuesday)
From: Rob Gurwitz <gurwitz at BBN-UNIX>
Subject: Re: Bum SMTP code for VAX Unix
To: POSTEL at USC-ISIF
Cc: Gurwitz at BBN-UNIX, Postel at ISIF, Clark at MIT-MULTICS,
    Haverty at BBN-UNIX, Kahn at ISIA

Jon,
I've got a version of SMTP that should fix all the bugs you refer to.  I have
a good list of the sites I sent tapes of the UNIX TCP code to, but I wouldn't
be too surprised if there were other sites running the code by now, too.  

There is now a net mailing list, bbn-tcp, through which we can reach many of
the recipients of our code.  I have not attempted to ship new code to each
individual site, but have made its availability known through the list.  It's
my understanding that we're not providing individual site support, except to
ARPA VLSI and Image Understanding contractors. We are maintaining the code
and making changes available to the non-ARPA sites, however.

Rob

14-Mar-83 12:34:26-PST,614;000000000001
Return-path: <dean@cornell>
Mail-From: SMTP created at 14-Mar-83 12:32:58
Received: FROM CORNELL BY USC-ISIF.ARPA WITH TCP ; 14 Mar 83 12:33:08 PST
Date: 14 Mar 1983 14:23:06-EST
From: dean at Cornell
To: mike@brl, postel@usc-isif
Subject: Re: Protocol Police!

I have made the fix to our SMTP server.  It now responds to an RSET with
"250 OK" rather than the incorrect "200 OK".  This bug was in the BBN
distribution we received for our 4.1bsd system, so it might be in other
people's running systems as well.  Notice of the error should probably be
distributed.
					Dean Krafft
					dean@cornell
27-Feb-83 13:56:22-PST,2334;000000000001
Return-path: <[email-masked]>
Mail-From: SMTP created at 27-Feb-83 13:51:41
Received: FROM BRL-BMD BY USC-ISIF.ARPA WITH TCP ; 27 Feb 83 13:51:44 PST
Date:     27 Feb 83 15:50:11 EST (Sun)
From:     Mike Muuss <[email-masked]>
To:       [email-masked]
cc:       [email-masked], [email-masked]
Subject:  TCP Retransmit Timeouts

I have been watching the way our TCP has been interacting with our IMP,
and I've noticed some really bad things.  Especially for bulk data transfers
(SMTP, FTP) there has been a good deal of IMP Blocking.

Now I know that the PDP-11 version of the code does not do RFNM counting,
but the problem would still be there if it did -- the TCP is simply
over-driving the ArpaNet, and going into lots of (unnecessary) retransmits
because of it.  After some inspection of the code in tcp_timer.c, I
have made the following mods (around line 110):

/* Note that the formula used by tcp_timers() goes like this:
 *	t_timer = ( (t_srtt/10) * tcp_backoff[t_rxtshift-1] ) / 10;
 *	t_srtt ~=~ t_rtt * 10;
 * with the result limited to the range 0.5--15 seconds.
 * t_srrt is the "smoothed" round trip time *10, t_rtt is 1 round trip time.
 */
int     tcp_backoff[TCP_MAXRXTSHIFT] =          /* scaled by 10 */
	{ 12, 20, 25, 32, 40, 50, 60, 80, 160, 320 };
/**	{ 10, 12, 14, 17, 20, 30, 50, 80, 160, 320 };	** OLD ***/

I can certainly understand retransmissions at 1x, 2x, 3x the round trip
times, but 1.0x 1.2x 1.4x 1.7x 2.0x ??  I don't see how those intermediate
retransmissions can hope to be ack'ed in time to prevent the next retransmit.
So, with no empirical evidence to support my suggestions, I suggest
using 1.2x 2.0x 2.5x 3.2x 4.0x ... as shown above.  The 1.2x gives a
triffle extra for the first ACK, 2.0 is obvious, 2.5 is being pesimistic,
and the rest are just for luck.

I suspect that even slightly more pesimistic numbers may be appropriate
for high-latency networks like the ArpaNet.  I have no idea what effect
my change to the strategy will make on high-loss networks (like SATNET),
but the penalty on local-area networks should be minimal, as retransmits
arn't usually expected.

Again, I assert that all this is completely ad-hoc, but I'm trying to
reduce IMP blocking / output queue backlogs.
						Cheers,
						 -Mike

25-Apr-83 12:31:03-PDT,1487;000000000001
Mail-From: SMTP created at 25-Apr-83 12:28:26
Date: Monday, 25 April 1983 15:28:00 EDT
From: Mike.Accetta@CMU-CS-CAD
To: postel@isif
Subject: SMTP question

Jon,

   We experienced problems over the weekend with mail from the
INFO-COBOL mailing list.  Due to the number of message recipients, the
sender was timing out before our local mailer finished delivering the
mail (and consequently lots of CMU people received 10-20 copies of the
same messages).  I guess this situation is really the product of the
length of the message and the number of recipients.  Should this be
considered a problem with the remote mailer not waiting long enough for
delivery (i.e. they need to fix their system) or our mailer not meeting
some maximum delivery time threshhold (i.e. we need to fix our system)?

   If we are at fault, would it be legal to change our mail servers to
limit the number of RCPT TO commands it will accept per message and
reject any after the first N with a 452 reply (so that those addresses
will be retried later in a subsequent attempt).  This seems to be
reasonable according to the specification and mailers ought to be
prepared to deal with it.  I'm told that at least XMAILR deals with
this type of reply correctly.  It won't handle the large message case
though.

				- Mike
 5-May-83 20:59:40-PDT,3648;000000000001
Return-path: <[email-masked]>
Mail-From: SMTP created at  5-May-83 20:56:11
Received: FROM SU-SCORE BY USC-ISIF.ARPA WITH TCP ; 5 May 83 20:56:17 PDT
Date: Thu 5 May 83 20:49:57-PDT
From: Mark Crispin <[email-masked]>
Subject: [Mark Crispin <[email-masked]>: TCP BUGFIX: Slow TVT response]
To: [email-masked], [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

For your information.  You might want to add this to the official log
of patches/bugfixes that affect the mailsystem.  I would consider this
to be a required patch for the MRC mailsystem:

                ---------------

Mail-From: MRC created at  5-May-83 20:43:39
Date: Thu 5 May 83 20:43:38-PDT
From: Mark Crispin <[email-masked]>
Subject: TCP BUGFIX: Slow TVT response
To: [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     This patch is based on a patch from Charlie Lynn at BBN.  It
fixes slow TVT response when the TVT is receiving a lot of data.
This should be considered a "required patch" for all sites
running my SMTP server (MAISER) to remedy a performance problem
with large incoming messages; for all other sites it is a
"recommended patch".

     This patch should improve the "slow TVT" problem.  The hook
to refill the TTY input buffer from a packet when it is emptied
is missing.  The current code "works" since arrivals of other
packets (e.g. retransmissions) cause the reassembler to be run.

GTTCI/	SKIPG T1,TTICT(T2)
GTTCI+1/  RET		JRST FFF

FFF/	HLRZ CX,TTSAL1(T2)
FFF+1/	CAIN CX,TT.TVT
FFF+2/	SKIPG TTNETW(T2)
FFF+3/	RET
FFF+4/	PUSH P,T2
FFF+5/	PUSH P,TCB
FFF+6/	JSP CX,NOSK11
FFF+7/	HRRZ TCB,TTDEV(T2)
FFF+10/	JUMPE TCB,.+11
FFF+11/	HRLI TCB,INTSEC
FFF+12/	XMOVEI T1,RA
FFF+13/	MOVEI T2,T20
FFF+14/	HRRZ T3,$TRCB(TCB)
FFF+15/	HRRZ T4,TCBRPQ(TCB)
FFF+16/	SKIPN T3
FFF+17/	CAIE T4,TCBRPQ(TCB)
FFF+20/	CALL SIGNAL
FFF+21/	JSP CX,OKSK11
FFF+22/	POP P,TCB
FFF+23/	POP P,T2
FFF+24/	RET
FFF+25/	FFF:

     A source version of this patch follows.  It hasn't been
tested yet, but ought to work.

     First, make the label SYMBOL in TCPTCP.MAC global (change
SYMBOL: to SYMBOL::).  Add SYMBOL as a global in GLOBS.MAC.

     Second, change the start of GTTCI from:
GTTCI:	SKIPG 1,TTICT(2)	;ANY CHARS IN BUFFER?
	RET			;NO
     to:
GTTCI:	SKIPLE 1,TTICT(2)	;ANY CHARS IN BUFFER?
	IFSKP.			;NO, MAYBE NEED TO REFILL FROM PACKET BUFFER
	  TDCALL D,<<TV,TVRFIL>>;DO TVT-DEPENDENT REFILL SIGNAL
	  RET			;RETURN EMPTY
	ENDIF.

     Finally, add the following routine to TTTVDV.MAC.  Make sure
you add it in a section that is RSCOD.  I put it in right after
the TVMNTR routine.

;TVRFIL - ROUTINE TO SIGNAL TVT BUFFER REFILL WHEN EMPTY
;CALLED FROM GTTCI

TVRFIL:	SKIPG TTNETW(T2)	;STILL CONNECTED TO NETWORK?
	 RET			;NO, NOTHING TO DO
	PUSH P,T2		;SAVE DYNAMIC DATA
	PUSH P,TCB		;SAVE TTYSRV CONTEXT
	NOSKED			;OWN THE SYSTEM
	LOAD TCB,PTVT,(T2)	;GET TCB IF EXISTS
	IFN. TCB		;HAVE ONE?
	  SETSEC TCB,INTSEC	;TCB'S ARE IN INTSEC
	  DO.
	    IFQE. TRCB,(TCB)	;RECV% BUFFER EXISTS?
	      LOAD T1,QNEXT,<+TCBRPQ(TCB)> ;NO, GET NEXT ITEM ON RA QUEUE
	      CAIN T1,TCBRPQ(TCB) ;IS RA QUEUE EMPTY?
	       EXIT.		;YES, NO NEED TO RUN REASSEMBLER
	    ENDIF.
	    $SIGNL(RA,20)	;RUN REASSEMBLER AFTER SHORT DELAY
	  ENDDO.
	ENDIF.
	OKSKED			;RETURN THE SYSTEM
	POP P,TCB		;RESTORE TTYSRV CONTEXT
	POP P,T2		;RESTORE DYNAMIC DATA
	RET
-------
-------
 5-May-83 21:43:58-PDT,1173;000000000001
Return-path: <[email-masked]>
Mail-From: SMTP created at  5-May-83 21:41:25
Received: FROM SU-SCORE BY USC-ISIF.ARPA WITH TCP ; 5 May 83 21:41:49 PDT
Date: Thu 5 May 83 21:38:44-PDT
From: Mark Crispin <[email-masked]>
Subject: TCP BUGFIX: ADDENDUM
To: [email-masked]
cc: [email-masked], [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Don Watrous is, of course, right that "SYMBOL" should be replaced by
"SIGNAL" in the comment on what to make global.  Let's hear it for bad
proofreading.

I've discovered a problem in Charlie's original patch.  When MAISER
invokes MMailbox to validate a host name, the connection starts echoing.
Damned if I know why.  The fix, however, is to remove the POP P,T2 from
the TVRFIL routine and replace the PUSH P,T2 with SAVET.  In the DDT
patch, remove the POP P,T2 and replace the PUSH P,T2 with JSP CX,SAVT.
I'll leave it as an exercise for those who are somewhat less tired than I
am right now to figure out why this is necessary and why invoking an
inferior fork tickles this bug.
-------
 5-May-83 23:14:45-PDT,911;000000000001
Mail-From: SMTP created at  5-May-83 23:10:20
Date:  6 May 1983 0206-EDT
From: Don <WATROUS@RUTGERS>
Subject: Re: TCP BUGFIX: ADDENDUM
To: MRC@SU-SCORE, TOPS-20@SU-SCORE
cc: Postel@USC-ISIF, Mockapetris@USC-ISIF

There's an incompatibility between TCPTCP's SIGNAL label and PROLOG's
SIGNAL macro, causing MACRO to give one of its endearing Q errors on
the $SIGNL macro we are adding to TTTVDV.

You can get around this by entering SIGNL (rather than SIGNAL) in
GLOBS, putting SIGNL:: right before the SIGNAL: in TCPTCP, and
changing the CALL SIGNAL in the definition of $SIGNL in TCPPAR to
CALL SIGNL.  (Whew!)

Don

P.S. - We're now running the source version of MRC's patch, including
replacing the PUSH/POP of T2 with SAVET.
-------
 6-May-83 02:32:12-PDT,1628;000000000001
Return-path: <[email-masked]>
Mail-From: SMTP created at  6-May-83 02:29:31
Received: FROM SU-SCORE BY USC-ISIF.ARPA WITH TCP ; 6 May 83 02:29:35 PDT
Date: Fri 6 May 83 02:32:03-PDT
From: Mark Crispin <[email-masked]>
Subject: more TVT performance fixes
To: [email-masked]
cc: [email-masked], [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     A fix that should be put into the TVT performance
improvement patch is to check to see if the reassembler's process
lock is running already.  Otherwise, it is possible that the
system could get an NSKDIS bughlt if RA's PRCLCK is locked when
TVRFIL decides to wake up RA.  Here's an updated routine, with
that check added:

;TVRFIL - ROUTINE TO SIGNAL TVT BUFFER REFILL WHEN EMPTY
;CALLED FROM GTTCI

TVRFIL:	SKIPG TTNETW(T2)	;STILL CONNECTED TO NETWORK?
	 RET			;NO, NOTHING TO DO
	SAVET			;SAVE TEMPS
	PUSH P,TCB		;SAVE TTYSRV CONTEXT
	NOSKED			;OWN THE SYSTEM
	SKIPL RA+PRCLCK		;IS REASSEMBLER RUNNING ALREADY?
	IFSKP.
	  LOAD TCB,PTVT,(T2)	;NO, GET TCB IF EXISTS
	  IFN. TCB		;HAVE ONE?
	    SETSEC TCB,INTSEC	;TCB'S ARE IN INTSEC
	    DO.
	      IFQE. TRCB,(TCB)	;RECV% BUFFER EXISTS?
		LOAD T1,QNEXT,<+TCBRPQ(TCB)> ;NO, GET NEXT ITEM ON RA QUEUE
		CAIN T1,TCBRPQ(TCB) ;IS RA QUEUE EMPTY?
		 EXIT.		;YES, NO NEED TO RUN REASSEMBLER
	      ENDIF.
	      $SIGNL(RA,20)	;RUN REASSEMBLER AFTER SHORT DELAY
	    ENDDO.
	  ENDIF.
	ENDIF.
	OKSKED			;RETURN THE SYSTEM
	POP P,TCB		;RESTORE TTYSRV CONTEXT
	RET
-------
 6-May-83 04:32:24-PDT,746;000000000001
Mail-From: SMTP created at  6-May-83 04:27:56
Date: Fri 6 May 83 07:29:44-EDT
From: Dan Tappan <[email-masked]>
Subject: Re: TCP BUGFIX: ADDENDUM
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked],
    [email-masked]

The reason the connection starts echoing is that the routine INIT:
does a RESET% which in addition to everything else resets TTY modes to
system default. This is documented but I've long felt it's a bad idea
for exactly this reason.

However, I don't know why the patch should affect it.

Dan
-------
 6-May-83 08:20:46-PDT,537;000000000001
Mail-From: SMTP created at  6-May-83 08:19:30
Date:  6 May 1983 1015-EDT
From: Don <WATROUS@RUTGERS>
Subject: Re: TCP BUGFIX: ADDENDUM
To: MRC@SU-SCORE, TOPS-20@SU-SCORE
cc: Postel@USC-ISIF, Mockapetris@USC-ISIF

Never mind all that about a SIGNAL macro in PROLOG.  I should have
noticed it's part of a local PUP implementation.  Sorry about the
confusion.

Don
-------
26-Apr-83 21:13:59-PDT,3153;000000000001
Mail-From: POSTEL created at 26-Apr-83 21:09:31
Date: 26 Apr 1983 2109-PDT
From: POSTEL at USC-ISIF
Subject: Andler is right
To:   Taft at PARC, Reilly at UDEL-RELAY
cc:   Postel at ISIF, ANDLER.IBM-SJ at RAND-RELAY,
cc:   FARBER at UDEL-RELAY, Landweber at UWISC

Folks:

I agree with Sten.  Every SMTP implementation should do the full protocol
and complete the session with the Quit command.  And every SMTP implementation
must take full responsibility for the message when it sends an OK response
after receiving the dot at the end of the message data.

--jon.

*****

Mail-From: SMTP created at 25-Apr-83 19:27:04
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Subject: Interesting SMTP interpretation problem
To: Postel@isif
Cc: taft@parc, reilly@udel-relay
Via:  IBM-SJ; 25 Apr 83 19:09-PDT

Here is a copy of a message I sent to Ed Taft and Brendan Reilly after
having found that we have received no mail from Xerox PARC since 1/1/83,
and discovering that Ed Taft's transcripts seemed to show that mail
had been delivered correctly.
 
=== Begin forwarded message ===
Date: 13 Apr 1983 14:12:24-PST (Wednesday)
From: Sten Andler <ANDLER@IBM-SJ>
To: taft@parc
Subject: Mail deliveries from PARC to CSNET
CC: cic@csnet-sh, reilly@udel-relay
Via:  IBM-SJ; 13 Apr 83 19:04-PST
 
I have now looked at the mail transcript that you sent me together
with Dick Edmiston of the CSNET CIC (at BBN) and Brendan Reilly of U.
Delaware.  The reason your mail gets lost (and this has happened to
all mail delivered by you to CSNET, as far as I can understand) is
that there is a disagreement between you and CSNET on what commits a
mail transaction.  You believe that the '.' at the end of the message
data commits the transaction, whereas Brendan believes the mail
transaction is not committed until the user quits the mail session by
issuing the QUIT command (which is REQUIRED by the SMTP protocol as
the way to terminate a session).  Since PARC never issues the QUIT,
the CSNET end times out and aborts the mail transaction.
 
My view on this follows:
 
1) I think PARC should follow the protocol and end the session with a
    QUIT command.
 
2) I interpret the SMTP specifications to say that the receiving end
    (CSNET) should commit the mail transaction when the DATA part of
    the mail is terminated by the period ('.'), and not respond ' 250
    Ok' until the transaction has been committed.  The absence of the
    QUIT command should thus NOT cause the mail transaction to be
    aborted.
 
Either one of the two changes above would cause the immediate problem
of lost mail to go away, and I will leave it to a shouting match between
PARC and CIC about who should change it first.  But in my opinion, both
changes have to be made to be able to say that both sides live up to the
specifications.
 
   Regards,
   Sten
=== End forwarded message ===
-------
 5-May-83 20:59:39-PDT,3648;000000000001
Return-path: <[email-masked]>
Mail-From: SMTP created at  5-May-83 20:56:11
Received: FROM SU-SCORE BY USC-ISIF.ARPA WITH TCP ; 5 May 83 20:56:17 PDT
Date: Thu 5 May 83 20:49:57-PDT
From: Mark Crispin <[email-masked]>
Subject: [Mark Crispin <[email-masked]>: TCP BUGFIX: Slow TVT response]
To: [email-masked], [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

For your information.  You might want to add this to the official log
of patches/bugfixes that affect the mailsystem.  I would consider this
to be a required patch for the MRC mailsystem:

                ---------------

Mail-From: MRC created at  5-May-83 20:43:39
Date: Thu 5 May 83 20:43:38-PDT
From: Mark Crispin <[email-masked]>
Subject: TCP BUGFIX: Slow TVT response
To: [email-masked]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     This patch is based on a patch from Charlie Lynn at BBN.  It
fixes slow TVT response when the TVT is receiving a lot of data.
This should be considered a "required patch" for all sites
running my SMTP server (MAISER) to remedy a performance problem
with large incoming messages; for all other sites it is a
"recommended patch".

     This patch should improve the "slow TVT" problem.  The hook
to refill the TTY input buffer from a packet when it is emptied
is missing.  The current code "works" since arrivals of other
packets (e.g. retransmissions) cause the reassembler to be run.

GTTCI/	SKIPG T1,TTICT(T2)
GTTCI+1/  RET		JRST FFF

FFF/	HLRZ CX,TTSAL1(T2)
FFF+1/	CAIN CX,TT.TVT
FFF+2/	SKIPG TTNETW(T2)
FFF+3/	RET
FFF+4/	PUSH P,T2
FFF+5/	PUSH P,TCB
FFF+6/	JSP CX,NOSK11
FFF+7/	HRRZ TCB,TTDEV(T2)
FFF+10/	JUMPE TCB,.+11
FFF+11/	HRLI TCB,INTSEC
FFF+12/	XMOVEI T1,RA
FFF+13/	MOVEI T2,T20
FFF+14/	HRRZ T3,$TRCB(TCB)
FFF+15/	HRRZ T4,TCBRPQ(TCB)
FFF+16/	SKIPN T3
FFF+17/	CAIE T4,TCBRPQ(TCB)
FFF+20/	CALL SIGNAL
FFF+21/	JSP CX,OKSK11
FFF+22/	POP P,TCB
FFF+23/	POP P,T2
FFF+24/	RET
FFF+25/	FFF:

     A source version of this patch follows.  It hasn't been
tested yet, but ought to work.

     First, make the label SYMBOL in TCPTCP.MAC global (change
SYMBOL: to SYMBOL::).  Add SYMBOL as a global in GLOBS.MAC.

     Second, change the start of GTTCI from:
GTTCI:	SKIPG 1,TTICT(2)	;ANY CHARS IN BUFFER?
	RET			;NO
     to:
GTTCI:	SKIPLE 1,TTICT(2)	;ANY CHARS IN BUFFER?
	IFSKP.			;NO, MAYBE NEED TO REFILL FROM PACKET BUFFER
	  TDCALL D,<<TV,TVRFIL>>;DO TVT-DEPENDENT REFILL SIGNAL
	  RET			;RETURN EMPTY
	ENDIF.

     Finally, add the following routine to TTTVDV.MAC.  Make sure
you add it in a section that is RSCOD.  I put it in right after
the TVMNTR routine.

;TVRFIL - ROUTINE TO SIGNAL TVT BUFFER REFILL WHEN EMPTY
;CALLED FROM GTTCI

TVRFIL:	SKIPG TTNETW(T2)	;STILL CONNECTED TO NETWORK?
	 RET			;NO, NOTHING TO DO
	PUSH P,T2		;SAVE DYNAMIC DATA
	PUSH P,TCB		;SAVE TTYSRV CONTEXT
	NOSKED			;OWN THE SYSTEM
	LOAD TCB,PTVT,(T2)	;GET TCB IF EXISTS
	IFN. TCB		;HAVE ONE?
	  SETSEC TCB,INTSEC	;TCB'S ARE IN INTSEC
	  DO.
	    IFQE. TRCB,(TCB)	;RECV% BUFFER EXISTS?
	      LOAD T1,QNEXT,<+TCBRPQ(TCB)> ;NO, GET NEXT ITEM ON RA QUEUE
	      CAIN T1,TCBRPQ(TCB) ;IS RA QUEUE EMPTY?
	       EXIT.		;YES, NO NEED TO RUN REASSEMBLER
	    ENDIF.
	    $SIGNL(RA,20)	;RUN REASSEMBLER AFTER SHORT DELAY
	  ENDDO.
	ENDIF.
	OKSKED			;RETURN THE SYSTEM
	POP P,TCB		;RESTORE TTYSRV CONTEXT
	POP P,T2		;RESTORE DYNAMIC DATA
	RET
-------
-------
 6-Jun-83 09:20:13-PDT,1179;000000000001
Mail-From: SMTP created at  6-Jun-83 09:16:20
Received: FROM [128.16.3.4] BY USC-ISIF.ARPA WITH TCP ; 6 Jun 83 09:16:32 PDT
Date:     2 Jun 83 12:52:13 BST (Thu)
From:     Steve Kille <steve@ucl-cs> (44a)
To:       knutsen @ sri-unix, dpk @ brl, mike @ brl
cc:       robert @ UCL-CS, steve @ UCL-CS, postel @ isif
Subject:  TCP performance across the Sattelite

After finding the thoughputs we have been getting across the sattelite,
we ran a packet trace.  By some conicidence we caught a letter from
SRI-KL running familiar code.

There are two points on the way the SMTP uses the TCP as a
transport:
1. The command line is split into two parts, the command and a
<CR><LF> pair. Both parts are pushed (delivered with an EOL
marker), this is ineficient for the receiving TCP/host.

2. The data part is sent on 40 byte pieces, with an ACK
required for each piece before sending the next. Each 40 bytes
is pushed (EOL bit set). Thus on a call
to the UK (3 sec approx round trip time) you get about 10
bytes/sec. IT IS possible to put more than 40 bytes of data
into a TCP packet, and IT IS NOT necesary to push every packet.

Robert Cole + Steve Kille

 6-Jun-83 11:07:26-PDT,1093;000000000001
Mail-From: SMTP created at  6-Jun-83 11:06:35
Date: Mon, 6 Jun 83 11:05 PDT
From: [email-masked]
Subject: Re: SMTP use of TCP & impact of SATNET
To: [email-masked]
cc: Steve Kille <[email-masked]>, [email-masked]

The reason Tops20 and Tenex SMTP senders use small segments and push
each one is that there is some problem in the TCP code that prevents
progress otherwise.  This was discovered through painful trial and error
by several people independently, including myself.

I actually get reasonably good results with 256-byte segments (rather
than 40), but I still have to push each one.

I realize this is inefficient, especially in an environment with large
round-trip delay.  But there is not much that can be done until this
crummy TCP implementation gets cleaned up.  I don't know when that will
be for Tops20, but I do for Tenex: probably never.

	Ed

25-Apr-83 19:28:40-PDT,2550;000000000001
Mail-From: SMTP created at 25-Apr-83 19:27:04
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Subject: Interesting SMTP interpretation problem
To: Postel@isif
Cc: taft@parc, reilly@udel-relay
Via:  IBM-SJ; 25 Apr 83 19:09-PDT

Here is a copy of a message I sent to Ed Taft and Brendan Reilly after
having found that we have received no mail from Xerox PARC since 1/1/83,
and discovering that Ed Taft's transcripts seemed to show that mail
had been delivered correctly.
 
=== Begin forwarded message ===
Date: 13 Apr 1983 14:12:24-PST (Wednesday)
From: Sten Andler <ANDLER@IBM-SJ>
To: taft@parc
Subject: Mail deliveries from PARC to CSNET
CC: cic@csnet-sh, reilly@udel-relay
Via:  IBM-SJ; 13 Apr 83 19:04-PST
 
I have now looked at the mail transcript that you sent me together
with Dick Edmiston of the CSNET CIC (at BBN) and Brendan Reilly of U.
Delaware.  The reason your mail gets lost (and this has happened to
all mail delivered by you to CSNET, as far as I can understand) is
that there is a disagreement between you and CSNET on what commits a
mail transaction.  You believe that the '.' at the end of the message
data commits the transaction, whereas Brendan believes the mail
transaction is not committed until the user quits the mail session by
issuing the QUIT command (which is REQUIRED by the SMTP protocol as
the way to terminate a session).  Since PARC never issues the QUIT,
the CSNET end times out and aborts the mail transaction.
 
My view on this follows:
 
1) I think PARC should follow the protocol and end the session with a
    QUIT command.
 
2) I interpret the SMTP specifications to say that the receiving end
    (CSNET) should commit the mail transaction when the DATA part of
    the mail is terminated by the period ('.'), and not respond ' 250
    Ok' until the transaction has been committed.  The absence of the
    QUIT command should thus NOT cause the mail transaction to be
    aborted.
 
Either one of the two changes above would cause the immediate problem
of lost mail to go away, and I will leave it to a shouting match between
PARC and CIC about who should change it first.  But in my opinion, both
changes have to be made to be able to say that both sides live up to the
specifications.
 
   Regards,
   Sten
=== End forwarded message ===
26-Apr-83 21:13:59-PDT,3153;000000000001
Mail-From: POSTEL created at 26-Apr-83 21:09:31
Date: 26 Apr 1983 2109-PDT
From: POSTEL at USC-ISIF
Subject: Andler is right
To:   Taft at PARC, Reilly at UDEL-RELAY
cc:   Postel at ISIF, ANDLER.IBM-SJ at RAND-RELAY,
cc:   FARBER at UDEL-RELAY, Landweber at UWISC

Folks:

I agree with Sten.  Every SMTP implementation should do the full protocol
and complete the session with the Quit command.  And every SMTP implementation
must take full responsibility for the message when it sends an OK response
after receiving the dot at the end of the message data.

--jon.

*****

Mail-From: SMTP created at 25-Apr-83 19:27:04
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Subject: Interesting SMTP interpretation problem
To: Postel@isif
Cc: taft@parc, reilly@udel-relay
Via:  IBM-SJ; 25 Apr 83 19:09-PDT

Here is a copy of a message I sent to Ed Taft and Brendan Reilly after
having found that we have received no mail from Xerox PARC since 1/1/83,
and discovering that Ed Taft's transcripts seemed to show that mail
had been delivered correctly.
 
=== Begin forwarded message ===
Date: 13 Apr 1983 14:12:24-PST (Wednesday)
From: Sten Andler <ANDLER@IBM-SJ>
To: taft@parc
Subject: Mail deliveries from PARC to CSNET
CC: cic@csnet-sh, reilly@udel-relay
Via:  IBM-SJ; 13 Apr 83 19:04-PST
 
I have now looked at the mail transcript that you sent me together
with Dick Edmiston of the CSNET CIC (at BBN) and Brendan Reilly of U.
Delaware.  The reason your mail gets lost (and this has happened to
all mail delivered by you to CSNET, as far as I can understand) is
that there is a disagreement between you and CSNET on what commits a
mail transaction.  You believe that the '.' at the end of the message
data commits the transaction, whereas Brendan believes the mail
transaction is not committed until the user quits the mail session by
issuing the QUIT command (which is REQUIRED by the SMTP protocol as
the way to terminate a session).  Since PARC never issues the QUIT,
the CSNET end times out and aborts the mail transaction.
 
My view on this follows:
 
1) I think PARC should follow the protocol and end the session with a
    QUIT command.
 
2) I interpret the SMTP specifications to say that the receiving end
    (CSNET) should commit the mail transaction when the DATA part of
    the mail is terminated by the period ('.'), and not respond ' 250
    Ok' until the transaction has been committed.  The absence of the
    QUIT command should thus NOT cause the mail transaction to be
    aborted.
 
Either one of the two changes above would cause the immediate problem
of lost mail to go away, and I will leave it to a shouting match between
PARC and CIC about who should change it first.  But in my opinion, both
changes have to be made to be able to say that both sides live up to the
specifications.
 
   Regards,
   Sten
=== End forwarded message ===
-------
30-Apr-83 08:30:05-PDT,1562;000000000001
Mail-From: SMTP created at 30-Apr-83 08:26:28
Redistributed-Date:  30 April 1983 09:20 edt
Redistributed-By:  Saltzer.CSR at MIT-MULTICS
Redistributed-To:  Andler.SJRLVM1.IBM at RAND-RELAY, 
                   Postel at USC-ISI
Date:  29 April 1983 11:56 edt
From:  Schiller (Jeffrey I. Schiller)
Subject:  Re: RAND-Relay mail problems
To:  Saltzer

Well that sounds incredibly bogus! RFC 822 states that once the "OK"
reply is received, the mail is committed. The "QUIT" command is used to
gracefully shutdown the SMTP connection. To interpret this any other way
is to say that if Multics opens a connection to Rand-Relay and sends 50
pieces of mail down the channel, all 50 pieces aren't commited until the
QUIT!??

Btw. What Multics does is keep the connection open (ie. NOT send a quit)
for about 3 minutes. This is a optimization in case other mail for the
same site is encountered while scanning the mail queues. If no activity
is found on the connection after about 3 minutes Multics sends a QUIT
and closes the connection. Mail transacations on one connection are
separated by "RSET" commands. Rand-Relay is probably timing out on the
connection during the quiescent period, thus Multics never gets a chance
to send the QUIT.

                    -Jeff
 2-May-83 14:58:06-PDT,502;000000000001
Mail-From: WESTINE created at  2-May-83 14:55:05
Date: 2 May 1983 1454-PDT
Sender: WESTINE at USC-ISIF
Subject: Re: Rand-Relay Mail Problems
From: Postel@isif
To: Saltzer.CSR at MIT-MULTICS
Bcc: postel at USC-ISIF
Message-ID: <[USC-ISIF] 2-May-83 14:54:57.WESTINE>

Jeff:

I agree!  It is bogus!!!  The mail is committed when the receiver
sends the "ok" after processing the "dot" at the end of the data.
Sending that "ok" means the receiver takes responsibility for
the mail.

--jon.
10-Jun-83 19:24:41-PDT,2443;000000000001
Mail-From: SMTP created at 10-Jun-83 19:24:23
Date:  10 June 1983 22:17 edt
From:  Saltzer at MIT-MULTICS
Subject:  SMTP argument again
To:  postel at USC-ISI
cc:  Saltzer at MIT-MULTICS, DClark at MIT-MULTICS, 
     "andler.sjrlvm1.ibm@RAND-Relay" at MIT-MC

Jon,
Perhaps I misunderstood, but I thought you, together with
Sten Andler, had come to a complete resolution on the
question of when mail is committed in SMTP.  We are again having
trouble getting the CSNET relays to accept mail from Multics sites.

Would you please look over this message I just received from
the Multics mail system maintenance person, and then refresh
my memory as to what the official position on SMTP commit is?
Is the position described here of the CSNET relays actually
correct?  Or is the interpretation used by the Multics implementation
acceptable?  What seems to be needed is a definitive handing
down of the law.

Thanks for you help.

		Jerry

----- ----- ----- ----- ----- -----

 #17 (18 lines)  06/10/83 18:47  Mailed by: Schiller.SysMaint
Date:  10 June 1983 18:47 edt
From:  Schiller (Jeffrey I. Schiller)
Subject:  Mail to UDEL-RELAY losing
To:  Saltzer

Brendan Reilly at UDEL has once again modified their mailer to drop mail
on the floor that was sent via an SMTP connection that didn't end in a
QUIT command. For some reason our QUITS aren't getting through to him (I
will investigate this).

Brendan told me he will be modifying his mailer to return to addressee
any mail that was sent on an SMTP connection and was "250 OK'd" but for
which a QUIT was not received. This is WRONG, it puts the onus of broken
connections (which should be a temporary error) on the users by
returning mail that was successfully sent on a connection that broke
before the QUIT. Note: On MIT-MULTICS when we have several messages to
go to a host we use 1 smtp connection and separate the messages by
RSET's. His interpretation of the SMTP spec (which he claims he checked
through with Postel) says that if we send him 39 out of 40 messages on
an smtp connection, and then some error breaks that connection, he will
return the 39 messages to the sender.

                    -Jeff
 ---(17)---


10-Jun-83 19:39:49-PDT,771;000000000001
Mail-From: SMTP created at 10-Jun-83 19:38:05
Date: 10 Jun 1983 1933-PDT
From: POSTEL at USC-ISIF
Subject: Re: SMTP argument again
To:   Saltzer at MIT-MULTICS, postel at USC-ISI
cc:   DClark at MIT-MULTICS, "andler.sjrlvm1.ibm at RAND-RELAY,
cc:   POSTEL at USC-ISIF, reilly at UDEL-RELAY

In response to the message sent   10 June 1983 22:17 edt from Saltzer@MIT-MULTICS

Jerry:

The correct statement of the rules is that saying "OK" to the dot "." at
the end of the mail data commits the receiver (server) to delivering the
mail.

--jon.
-------
10-Jun-83 18:45:02-PDT,4224;000000000001
Mail-From: SMTP created at 10-Jun-83 18:43:40
Date: Fri, 10 Jun 83 18:31 PDT
From: Bill Nowicki <nowicki%Diablo@SU-Score>
Subject: Mail Loop explanation
To: DCrocker@UDel-Relay, KLH@MIT-MC, reid@Glacier
Cc: HEADER-PEOPLE@MIT-MC, MsgGroup@BRL, mailhax

Some people have requested a few more details of our
experience with sendmail and the disaster which caused a
mail loop on Wednesday June 8. First some background:

At Stanford we run 4.1BSD Unix with BBN TCP code, with CMU
packet filtering on 3 Mbit Ethernets connecting about a dozen VAXes (and
many other machines).  We would like to use 4.2 whenever (if ever?) it
finally gets done, so we got a 4.1c beta distribution and were trying
to phase in some of the user programs on that release, like sendmail.
The predecessor of sendmail, delivermail, 
we had customized slightly by changing a few tables and recompiling.
It read the host name by the gethostname() system call, so we could
take the program (or an entire disk pack for that matter) from one
system to another and it would work.  Sendmail contains an SMTP server
as well as the other mail switching and aliasing functions of
delivermail.

Integrating the SMTP server and the aliasing turns out to be a good
idea, but all sorts of other "features" were added to sendmail in the
mean time.  For example, instead of having compile-time tables and
modular code, there are enormous configuration files that are read at
run-time.  You have to specify a "program" to parse your addresses
using an incredibly unfathomable production language.  The host name is
hard-wired into the configuration file, so they are not portable
between machines anymore.  Part of the confusion came from the
distinction between switches entered on the command line, commands in
the configuration file, options which can be given on the command line
OR in the configuration file (with yet another strange syntax), mailer
flags, and configuration file macros.  All five of these are
represented by single character case sensitive identifiers, with
different meanings for the letters in many cases.  A vertiable lesson
in terrible user interfaces.

The specific problem came when we discovered a case in which our
TOPS-20 SMTP mailer would open a connection, send part of a message,
and then simply give up without sending a RESET packet.  The BBN TCP
code had no timeouts, so the connection would stay around forever,
along with the two sendmail processes and the spool files.  I
remembered reading about a timeout feature, and glancing at the manual
found it was the "t" option.  So I ran sendmail with the "t" switch on
the command line.  There were two mistakes: first, the timeout is an
Option, not a Switch, and secondly it is upper case T not lower case
t.  I was silly enough to think that since it gave me no error message
that everything was OK, and went off to our research group meeting.

When I came back after the meeting I looked at the log file and noted
some suspicious behaviour.  What it was doing was sending a copy of
each message to the people listed in the "To:" and "Cc:" fields in the
header, as well as the person given in the RCPT TO:<> command of SMTP.
This resulted in the loop back through our local Ethernet, the Arpanet,
the MIT Chaos Net, as well as several nets at BRL and BBN!  I killed
the server after about an hour, and restarted it with the right options
(although the timeout still does not do anything), but the duplicated
mail took at least two days to stop bouncing through the net.

Morals (some are my personal opinions):  
1. Case sensitivity is a bad idea.  
2. Single letter identifiers are a bad idea.  
3. Multiple notions that are similar are confusing.  
4. Large (multi-domain) mailing lists should have a moderator.  
5. Timeouts should be in SMTP servers and TCP implementations by default.  
6. internet mail systems are fragile things.  
7. "Improved" software with more "features" usually isn't.

	-- Bill

 8-Jun-83  9:32:11-PDT,1919,000000000001
Date:  8 Jun 1983  9:32:11 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: TCP problem
To: Rob Gurwitz <gurwitz@BBN-UNIX>, dpk@brl-vgr

[ This message was forwarded to the Digest by Doug Kingston, and details
  a particularly insidious bug in the BBN VAX TCP.  Hopefully, if any site
  using that code has not heard of this problem yet, this message will
  have served a purpose.  Note that Berkeley 4.1a and 4.1c code does
  not have this bug.  -Mike ]

The fix for this bug is as follows: (I'm afraid I have no
familiarity whatsoever with the TCP variants, but the
code should be fairly easy to find)

In the routine rcv_text (in tcp_procs.c in our code), the routine
that does the resequencing, there is the following code:

			/* new overlaps at beginning of successor frags */

			q = savq->t_next;
			while ((q != (struct th *)tp) && (t->t_len != 0) && 
			       SEQ_LEQ(q->t_seq, last))

				/* complete cover */

        			if (SEQ_LEQ(t_end(q), last)) {
					p = q->t_next;
					tcp_deq(q);
					m_freem(dtom(q));
					q = p;

				} else {		/* overlap */

In your code, the first SEQ_LEQ is probably a SEQ_LT.  This is the bug.
There is an analogous bug in ip_input.c:

			/* new overlaps at beginning of successor frags */

				q = savq->ip_next;
				while ((q != (struct ip *)fp) &&
					(ip->ip_len != 0) && 
					(q->ip_off <= ip->ip_end)) 

					/* complete cover */

					if (q->ip_end <= ip->ip_end) {
						p = q->ip_next;
						ip_deq(q);
						m_freem(dtom(q));
						q = p;

Again, in your code the first <= is probably a <.

This fix was made just last week, and is slowly percolating out to the
other local BBN sites.  We are trying to spread this fix around, but
that's difficult.  Please tell everybody you know who is running this
code about the fix.

Good luck!  Feel free to write or call me at (617) 497-2643.

 8-Jul-83 16:13:10-PDT,1916;000000000001
Return-Path: <mike@brl-vgr>
Mail-From: SMTP created at  8-Jul-83 15:20:23
Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 8 Jul 83 15:20:37 PDT
Date:     Fri, 8 Jul 83 18:11:50 EDT
From:     Mike Muuss <mike@brl-vgr>
To:       rogers@usc-isib, postel@usc-isif, koda@usc-isif, mike@brl-vgr
Subject:  [dan:  tcp_subr.c bug]

Here is the bug fix announcement -- observe the date on the message.

If Craig is not getting the UNIX bug fixes for the 4.1a software,
he should subscribe to "ucbtcp11@sri-tsc";  ask postmaster@sri-unix
to get him on.

			Best,
			 -Mike

PS:  I am assuming that I got a copy of the message to provide help,
not because there is evidence that we are doing it wrong at BRL, right?

----- Forwarded message # 1:

Date: 20 Jan 1983 at 1455-PST
To: [email-masked]
Reply-To: [email-masked]
Subject: tcp_subr.c bug
From: [email-masked]
Received: From Sri-Tsc.ARPA via smtptcp;  20 Jan 83 20:58 EST
Received: From Brl.ARPA via smtptcp;  21 Jan 83 0:40 EST

Clem Cole mentioned a bug to me a while ago, which I forgot to pass on.  In
net/tcp_subr.c the variable t_maxseg should be set to 512, not 576.  The
default packet size should be 512 + header = 576, but t_maxseg should not
include the header in it's value.  Clem said it might affect transfers to
and from TENEX systems, but I haven't noticed that problem.  I made the
change, and it doesn't seem to break anything that wasn't broken before.

<<<<diff tcp_subr.c tcp_subr.c->>>>
154c154
< 	tp->t_maxseg = 512;		/* 512+header = 576, to satisfy the rest of the world */
---
> 	tp->t_maxseg = 576;		/* satisfy the rest of the world */

By the way, I have updated the PRMH sources (added a lot of the bug fixes
reported through this list) -- changes are in Modlog on PRMH in case anyone is
trying to stay in sync with us (lord knows why!).

	-Dan

----- End of forwarded messages
 8-Jul-83 18:16:00-PDT,2961;000000000001
Date: 8 Jul 1983 1515-PDT
Sender: CHASE at USC-ISIB
Subject: Re: Possible ISIB TCP bug
From: CHASE at USC-ISIB
To: tcp-ip at SRI-NIC

The problem reported by KLH with Ftp between ISIB and MIT-MC has been fixed.
The bug was in the Tops20 monitor code.  Basically, Tops20 couldn't send a Fin
at the time the Ftp process did its Close% because there was still data queued
from a previous Send%, and by the time the data went out, the check for
needing to send a Fin was missed.  Much thanks to Ken for his accurate error
reports and assistance in tracking this down.

The fix inserts new check after PKZ23A.  If the send side of the connection is
still open but the user has done a Close%, ENCPKT is called to "encourage" a
packet later, when the Fin can be sent.

==========
PKZ23A:
	LOAD T1,TSSYN,(TCB)	; Get send state ;;;LDB T1,[110314,,13]
	CAIE T1,SYNCED		; Connection synchronized? ;;;CAIE T1,7
	 JRST PKZ24B		; No.  No FIN can be sent.
	JN TSUOP,(TCB),PKZ24B	; Jump if connection still OPEN by user
				;  ;;;MOVE CX,13(14)
				;  ;;;TRNE CX,400 
				;   ;;;JRST PKZ24B
	MOVEI T1,^D200		; Try to send FIN later, we must have been
	CALL ENCPKT		;  unable to send it this time through
				;  (ie, due to presence of q'd snd data)
PKZ24B:
==========

While putting this problem to rest, it would be appropriate to put to rest
some misconceptions that came out of the discussion of this problem.
The TCPSIM package from BBN running at ISI does not just abort data
connections in place of trying to close them properly.  A Close% is done,
and only after the Close% fails to take effect after a timeout period is an
Abort% done to clean things up.  I'm sure that the above bug caused it to
appear to certain sites that only the abort was done.  But although the
package does have its shortcomings (the case in question is an example of its
skimpy error reporting), it does the best that can be done in this case.

The characterization of Tops20's TCP implementation as record oriented is not
quite accurate.  A user program can send one byte, two, ten or a whole page
worth, without any kind of record or segment considerations.  The monitor will
buffer these bytes until there are enough of them for efficient transmission,
or until the user program does a push.  The real fault with the user interface
is that it requires a different set of monitor calls instead of the Bin/Bout
flavor, and that these calls are very clumsy to use.  Now, however, the just
released DEC user interface will hopefully restore consistency and simplicity
to network i/o, and remove the need for simulation packages altogether.

<>Dale Chase
15-Jul-83 14:11:08-PDT,5415;000000000001
Return-Path: <jbn@FORD-WDL1>
Received: FROM BBNCCQ BY USC-ISIF.ARPA WITH TCP ; 15 Jul 83 14:09:08 PDT
Return-Path:<>
Date: 15-Jul-83 14:03:40-PDT
From: [email-masked]
Subject: Outstanding TOPS-20 TCP bug remains in v5.2
To: [email-masked], [email-masked], [email-masked],
    [email-masked]
Cc: [email-masked]

     For some months now, we have observed that the BBN TOPS-20 implementation
of TCP does not perform the TCP close handshake properly.  This problem has
been documented and reported to the appropriate people as shown below.
Crispin at SU-SCORE has just installed a new TOPS-20 monitor (5.2) and
this outstanding problem has NOT been fixed.
     The effect of this problem is that when a system which correctly
performs the handshake is talking to a noncomplying TOPS-20, and the
TCP close is initiated from the non-TOPS-20 end, the non-TOPS-20 end
will hang in the close and eventually time out.  This tends to cause
STOR operations in FTP to TOPS-20 sites to fail.  It also has the
annoying property for us that every time we get mail from a TOPS-20
site, our TCP logs a protocol violation.
     Larson at SRI has located the defective code in TOPS-20 as shown
below.  The messages below are the previous ones relating to this problem.
     As we at Ford Aerospace do not run any TOPS-20 systems, we do not
directly have this problem, but our users who need to communicate with
some of the TOPS-20 sites find this a continual annoyance.  Because of
the former importance of TOPS-20 in the ARPANET community, there has been
an informal tradition that the TOPS-20 implementation has been considered
the ``standard'' with which others were expected to interoperate.  For this
reason, it appears that considerable effort has been expended in some of
the newer implementations (such as the 4.2BSD systems) to interoperate with
TOPS-20 despite this problem.  (Elaborate FTP strategies regarding data
connection establishment are a means of getting around this problem).
Other implementors should be aware of this problem so that such wasted
effort can be avoided.

					John Nagle
					Ford Aerospace and Communications Corp.
  Return-path: <Mailer@SRI-NIC>
  Mail-From: SMTP created at 27-Apr-83 15:01:09
  Received: FROM SRI-NIC BY USC-ISID.ARPA WITH TCP ; 27 Apr 83 15:01:22 PDT
  Received:  from SRI-KL by SRI-NIC via ARPANET/MILNET with TCP/SMTP;
             Wed 27 Apr 83 14:23-PDT
  Date: Wed 27 Apr 83 14:18:48-PDT
  From: [email-masked]
  Subject: Re: need help from a tops-20 wizard
  To: [email-masked]
  cc: [email-masked], [email-masked], [email-masked],
      [email-masked]
  In-Reply-To: Your message of Tue 26 Apr 83 18:02:00-PDT
  
    This discussion  of  wierd  action  with  TCPSIM  related  stuff
  prompted me to look at the close in TCPSIM.  What wonders does one
  find!
    The wait in the flags to the CLOSE is commented out.  Thus,  one
  never waits for the FIN to  be returned.  If the ABORT is  reached
  too soon, would it be possible for a queued outgoing FIN to not be
  sent before the TCB is destroyed?  There appears to be no DISMS in
  the direct line,  so if GETBU2  is not reached,  there will be  no
  delay before the ABORT is reached.
    The MOVX B,... and the AOJN pair  result in a loop that will  be
  executed 2097152 times.  I  really do not think  this is what  was
  intended.  AOBJN perhaps?
  
    I suspect  that this  may  be part  of why  foreign  connections
  (especially to  unix  systems) may  be  being left  in  FIN_WAIT_2
  states.
  	Alan

  TCPCLS:				; TPC and TPD should be zero here
  	MOVE A,T.JCN(TFSB)
  ;	MOVE B,A(TAC0)		; Flags in left half
  ;	TXNE B,CO%WCL		; Wait?
  ;	 TXO A,TCP%WT		; Yes
  	CLOSE			; Tell other end to close it up
  	  SETZ TOB,		; Error return
  
  	MOVX D,<<RXTMOT*2+10>/10> ; Short timeout for GETBUF here
  	MOVX B,<-^D8,,0>	; Allow 8 buffers
  TCLOOP:	CALL GETBUF		; Start input
  	SKIPN A,T.JCN(TFSB)	; Is it closed yet?
  	  JRST TCXT		; Yes, done
  	AOJN B,TCLOOP		; No, try next buffer
  
  	ABORT			; Tried all 10, give up
  	  SETZ TOB,		; Error return
  TCXT:	SETZB TPC,TPD		; Nothing remaining
  -------
  Date: 29 Apr 1983 2046-PDT
  From: MILLS at USC-ISID
  Subject: Re: need help from a tops-20 wizard
  To:   LARSON at KL, Rudy.Nedved at CMU-CS-A
  cc:   HEDRICK at RUTGERS, JGoldberger at ISIF,
  cc:   don.provan at CMU-CS-A, TCP-IP-TOPS20 at NIC,
  cc:   MILLS at USC-ISID
  
  In response to the message sent  Wed 27 Apr 83 14:18:48-PDT from [email-masked]
  
  Folks,
  
  YE GODZ! I have been grousing about this problem for over two years. You mean
  this is the first time anybody checked?! Your description on the close
  is a*c*c*u*r*a*t*e.
  
  Regards,
  Dave
  
  From root Mon May 16 18:56:21 1983
  Return-Path: <[email-masked]>
  Mail-From: SRI-KL received by FORD-WDL1 at 16-May-83 18:56:06-PDT
  Date: Mon 16 May 83 18:52:42-PDT
  From: [email-masked]
  Subject: Re: TCP close fix
  To: [email-masked]
  In-Reply-To: Your message of Mon 16 May 83 18:04:47-PDT
  
    No.  I have received no fixes to this stuff.  It is real frustrating.
  I wish the DOD folks who think TCP/IP is such a wonderful thing would
  figure out who is to support it.
  	Alan
27-Jun-84 15:30:28-PDT,1266;000000000001
Date: 27 Jun 84 14:26 PDT
From: Tom Perrine <[email-masked]>
To: Postmaster@COLUMBIA-20
Cc: TCP-IP@SRI-NIC, Postmaster@LOGICON, John Codd <john@logicon>
Subject: SMTP amd TCP problems

We keep getting "nasty-grammed" by the COLUMBIA-20.ARPA SMTP mailer when
it attempts to deliver mail to us. 

The first attempt to deliver a piece of mail to us fails, and often
hangs our SMTP server.  The second attempt usually has a header field
called "Delivery-Notice", which informs us that it had to use "50 byte,
pushed segments" or something similiar.

>From our end (LOGICON.ARPA) we see the TCP connection closed from
your end *before* the CRLF.CRLF sequence to terminate the SMTP 'DATA'
protocol.  This should not be happening.

Has anyone else mentioned or noticed any similiar problems?

>From discussion in the sig-tcp mailing list and our trace efforts, we
suspect that these problems (delay/timeout and segment size/push) are a
"feature" of the gateway. What gateway are you using to reach MILNET?

Thanks,
Tom Perrine
Logicon

27-Jun-84 15:49:42-PDT,609;000000000001
Mail-From: POSTEL created at 27-Jun-84 15:46:43
Date: 27 Jun 1984 15:46:45 PDT
From: [email-masked]
Subject: SMTP problems
To:   [email-masked]
cc:   [email-masked]

Tom:

What version of what system are you running?  Where did you get your SMTP
code?  We did see this problem a long time ago, and we thought that all
instances were fixed.

This problem is described in the collection of messages in the file
<SMTP>MAIL.ERRORS on USC-ISIF.ARPA.  You should be able to copy that file
via FTP.  Let me know if you have an trouble getting a copy of
that file.

--jon.
-------
27-Jun-84 16:47:51-PDT,1015;000000000001
Mail-From: POSTEL created at 27-Jun-84 16:44:32
Date: 27 Jun 1984 16:44:33 PDT
From: [email-masked]
Subject: Re: SMTP amd TCP problems
To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked],
cc:   [email-masked], [email-masked]

In response to the message sent  27 Jun 84 14:26 PDT from [email-masked]

The problem looks to me like a combination of a fast timeout and a failure
to push the data (both on the sender side), but....  There could be other
bugs that would produce this effect.  If the receiver side miscalculated
something and/or failed to process a less than full buffer even if pushed,
one might get the same effect.

In general, one should look for the problem in the system that is new to the
game, and one should test with lots of different systems.

There is a file of old discussion about SMTP problems.  This can be copied
from USC-ISIF.ARPA via FTP.  The file name is <SMTP>MAIL.ERRORS.

--jon.
-------
28-Jun-84 11:29:47-PDT,992;000000000001
Date: 28 Jun 84 11:23 PDT
From: Tom Perrine <[email-masked]>
To: [email-masked]
Cc: John Codd <john@logicon>, Tom Perrine <tom@logicon>
Subject: Re:  SMTP Problems

Well, we are running the TCP implementation known to the NIC as
BBN-V6-UNIX, on a highly-hacked PWB system.  The UNIX is fine, but it
appears that this TCP implementation uses ports for buffering between
TCP and the user process, and therefore effectively ignores the PSH bit
on receives!

I am considering adding code at the SMTP level to handle the kind of
buffer disassembly that should be done by TCP, but isn't.  *sigh* If
only our contracting officer would let is spend $4000 to upgrade to V7,
then we could get 2.9BSD.  *moby sigh*

Thanks for all the help,
Tom Perrine
"at the mercy of an incomplete TCP"

19-Jul-84 14:30:50-PDT,1427;000000000001
Return-Path: <@MIT-MC:[email-masked]>
Received: FROM MIT-MC.ARPA BY USC-ISIF.ARPA WITH TCP ; 19 Jul 84 14:26:00 PDT
Date: Thu, 19 Jul 84 14:17 PDT
From: [email-masked]
Subject: embedded spaces in mail addresses
To: [email-masked]

i'm so sick of mailers complaining about quoted addresses with embedded
blanks i could scream.  is it possible to get unix fixed so that it
understands addresses of the form '"provan don"@lll-mfe.arpa', or
should we just flush this syntax?  as long as my syntax is legal, i find
it real hard to justify going to the lengths i'd have to go to make it
some address without any blanks in it.  i've been waiting since i first
brought up SMTP in march '83 for unix to be fixed, but i think it's
time to give up waiting.  i used to send notes to postmasters telling
them we were having problems, but i always got the response that it was
purchased software so they couldn't fix it.  it wasn't so bad when it
was just a couple of cases a month.  i could tell someone to use a user
number instead of a name or change a name to not have a blank in a few
cases.  but now there's been a great surge of interest in the arpanet
mail system so something has to be done.  should i give up?  should i
consider that syntax obsolete and unsupported?  should i just not let my
users communicate with unix sites?

well, to start with, i guess i'll get mad....

19-Jul-84 14:59:16-PDT,556;000000000001
Date: 19 Jul 84 1749 EDT (Thursday)
From: [email-masked]
To: [email-masked]
Subject: Re: embedded spaces in mail addresses

i forgot i was in an anonymous account when i send the message titled
"embedded spaces in mail addresses."  i hereby accept responsibility
for that message.

20-Jul-84 16:47:25-PDT,5739;000000000001
Return-Path: <@MIT-MC:[email-masked]>
Received: FROM MIT-MC.ARPA BY USC-ISIF.ARPA WITH TCP ; 20 Jul 84 16:43:25 PDT
Return-Path:<@MIT-MULTICS.ARPA:[email-masked]>
Received: from MIT-MULTICS.ARPA by CMU-CS-A.ARPA; 20 Jul 84 19:09:31 EDT
Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[email-masked]>; 20 Jul 1984 19:08:09 edt
Date:     20-JUL-1984 13:39 EDT
From:     WILLUT%EDUCOM.MAILNET@MIT-MULTICS
To:       [email-masked]
Subject:  Quotes and spaces in usernames
Resent-To: [email-masked]
Resent-From: [email-masked]
Resent-Date: 20 Jul 84 1932 EDT (Friday)

Some of our MAILNET sites have had a great deal of trouble with quoted
usernames, too.  Thought you might enjoy Alan Hunter's assessment of
the problem (they have now, by the way, changed their system to send
out usernames in the firstname_lastname format)
                                                  --Candy Willut
----------------------------------------
From:     MAILNET        18-MAY-1984 13:11
To:       WILLUT
Subj:     From:<@MIT-MULTICS.ARPA:"Alan Hunter"@Newcastle.Mailnet>

Received: from Newcastle.Mailnet by MIT-MULTICS.ARPA with Mailnet id <[email-masked]>; 17 May 1984 19:47:17 edt
Date: Thu, 17 May 84 16:02:38 BST
From: "Alan Hunter"@Newcastle.Mailnet
To: [email-masked],
    [email-masked],
    [email-masked],
    [email-masked]
Message-ID: <[email-masked]>
Subject: MTS network mail addresses

Steve, Gav:                        cc: Candy, John Rushby

 I spend a lot of time explaining this sort of thing (see following
 message) to users.  I think perhaps the MTS NETMAIL program ought to
 throw in the sponge and sign outgoing messages in the First_Last@Site
 form rather than the equally correct "First Last"@Site.  A lot of our
 mail is to ARPA and CSNET, and UNIX, TOPS and RSX systems in use on
 those nets don't seem to like quotes, even now.  I doubt they ever will.

 I have actually had complaints from SRI-CSL (a Foonly TOPS system)
 saying we send them illegally formatted messages!  So much for the
 success of the #822 revision!

     - Alan
---(Forwarded from: "Alan Hunter"@Newcastle, Dated: Thu, 17 May 84 15:37:28 BST
Brian:                cc: sundry others

 Once upon a time there was a mail system called ARPA.  It had network
 mail gurus who designed a protocol for the presentation of network
 mail messages.  They called this RFC #733 so that everyone would
 instantly know what it was, and respect it as The Truth.

 In the course of time, the gurus found that a number of groups among
 the ARPA proletariat had actually ignored the words of wisdom, and
 implemented what they thought it ought to be rather than what it was
 supposed to be.  Most of these illiterate programmers ran a young
 upstart operating system (the name escapes me) and knew, of course,
 that personal names were things like 'brian' and 'lindsay' and never
 had spaces in them.  So a message to:

     brian randell@newcastle

 clearly had two recipients; some local guy called 'brian' and somebody
 over the net called 'randell'.  Obvious isn't it?  (Actually they were
 supposed to use commas as separators for this case but these people
 never did that at home and didn't see why users of lesser systems
 should need to.)

 Eventually things got so bad that the gurus got together five years
 later and rewrote RFC #733, fixing all the problems and calling it
 RFC #822 which is a much better title.  They said that if a local part
 (that's what gurus have instead of names) had certain characters in
 it, it had to be surrounded by quotes (").  Spaces are one of these
 specials; underbars are not.

 So your messages from MTS go out signed correctly as:

     "Brian Randell"@Newcastle.Mailnet

 Meanwhile the mail types who used that operating system had heard from
 a friend of a friend that 822 wasn't much different to 733, so they
 changed the comment at the head of their mail program to say '822'
 instead of '733'.  All their friends used the same system (other
 people didn't seem to want to talk to them) and anyway they had much
 more fun things to do, because they'd discovered RPCs.

 The gurus got very annoyed with this and have spent the last two years
 issuing RFC's with ever more impressive numbers on them giving ever
 receding dates by which they must comply.  Since the mail implementors
 think they are complying they don't read these either.  They have even
 been known to complain when more up to date sites send them correctly
 formatted messages!

 The MTS mail people, being kind, are prepared to accept recipient's
 names with underbars representing the spaces.  Nor do they care if
 people shout at you and call you BRIAN RANDELL at the top of their
 voice.  Both quoted and underbarred forms are equally valid.  Few
 non-MAILNET-or-BITNET sites can generate our (correct) quoted
 signatures as return addresses.  So I always tell people to quote the
 underbarred form in the message text when establishing a connection.
 You are:

     [email-masked]

 but these people don't know where that is, so tell them you are:

     [email-masked]

 They'll think you are being pedantic putting the ".ARPA" on the end
 because they don't believe there is anybody else out there.  They'll
 also think you have a funny name and must live in or near Cambridge,
 Mass., BUT THEIR MESSAGES WILL GET THROUGH.

 I suppose MTS will be reduced to signing messages with underbars one
 day.  Sigh....

       - Alan

24-Jul-84 19:23:53-PDT,1134;000000000001
Date:        24 Jul 84 15:47 +0200
From:        [email-masked]
Reply-to:    [email-masked],
             [email-masked]
To:          [email-masked],
             header-people <[email-masked]>,
             [email-masked]
Subject:     embedded spaces in mail addresses

In the QZCOM mail network interface, I translate internal COM
names of the format "Jacob Palme QZ" into the external mail format
Jacob_Palme_QZ so as to avoid quotes and spaces which some mail
systems cannot handle.

I have never in my life come across a "standard" which in actual
implementation is to blatantly disregarded as RFC822.

25-Jul-84 13:00:09-PDT,1252;000000000001
Date: 25 Jul 84 1151 EDT (Wednesday)
From: [email-masked]
To: [email-masked]
Subject: re: embedded spaces in mail addresses

I went into the lll-mfe mail server to put in a underbar-equals-space hack
and found i'd already given up on UNIX and put a hash-equals-space
hack (hash because it's the standard around my network) in.
i wonder how many other sites have done the same thing just to
relieve UNIX of the need to fix it.  CMU uses a dot-equals-space
hack, as i'm sure many other sites do from the rfc722 days, but
that's because it's been in so long no one would think of taking
it out.  (it's become a standard all the way to user level.)  everytime
i bitch to a UNIX site, they say, "gee, you're the first site we've
dealt with that had spaces in their user names."  i suspect i'm just
the first to complain about it.

the thing that pisses me off most is that i need to add hashes on
the return addresses of out-going mail even for sites that can handle
spaces.  i think we should all boycott UNIX until the mail system's
fixed.

25-Jul-84 17:16:40-PDT,1537;000000000001
Date: 25 Jul 84 1954 EDT
From: [email-masked]
To: [email-masked]
Subject: Re: embedded spaces in mail addresses

For the record:

CMU supports the dot-equals-space hack and actually uses it as "the
way to go" for non-CMU sites because of the belief that most sites do
not have lexically powerful mail systems and can only handle simple
single lexical token <user> @ <host> mail addresses.

We advocate internal CMU mail to use quoted names and that mail user
interfaces/composers are expected to work very hard to resolve a
"name" or "nickname" into an electronic mail address (i.e. 'Mr. E. R.
Nedved' turns into '"Rudy Nedved"@CMU-CS-A.CMU.ARPA').

CMU's 4.1BSD Unix mail system (the majority around here) supports
spaces in names and quoted names. When we upgrade to 4.2BSD or
whatever, the mail system will support quoted names also.

What you want to do is boycott simple mail delivery software that
tries to use a hacked up version of the COPY or CAT program to
move mail around. Given the growing importance of eletronic mail
systems it is amazing that managers have not allocated more
software developement resources into this area.....it still seems
to be under the "general software maintainence" for most sites.

Rudy Nedved
CMU CS/RI Facilities Staff

23-Jul-84 10:30:08-PDT,1001;000000000001
Return-Path: <@MIT-MC:[email-masked]>
Received: FROM MIT-MC.ARPA BY USC-ISIF.ARPA WITH TCP ; 23 Jul 84 10:25:19 PDT
Date: Mon, 23 Jul 84 10:12 PDT
From: [email-masked]
Subject: where do error reports go now?
To: [email-masked]

it has been pointed out to me that RFC822 (4.4.4) says that reports
for undeliverable mail should be sent to the Sender: field (or the
From: field if there's no sender field).  RFC821 (4.1.1, Mail command)
says that non-delivery notices should be sent to the return path passed
in the SMTP Mail command, which, of course, ends up as the Return-Path:
header in the mail.  i'm sure this has been argued about before.  i don't
remember the argument.  anyway, i'm not feeling very argumentative, so i
just want to know which field i should use in my implementation.  presumably
they both point back to the same mailbox, but if they don't, which should
i choose?
						don provan
						provan@cmu-cs-a
						postmaster@lll-mfe

23-Jul-84 18:21:05-PDT,436;000000000001
Return-Path: <@MIT-MC:[email-masked]>
Received: FROM MIT-MC.ARPA BY USC-ISIF.ARPA WITH TCP ; 23 Jul 84 18:18:15 PDT
Date:     Mon, 23 Jul 84 21:08:56 EDT
From:     Doug Kingston <[email-masked]>
To:       [email-masked]
cc:       [email-masked]
Subject:  Re:  where do error reports go now?

	The address given in the SMTP MAIL FROM: command
is the prefered return address for errors.

					-Doug-

26-Jul-84 01:33:40-PDT,2157;000000000001
Date:        25 Jul 84 16:29 +0200
From:        [email-masked]
Reply-to:    [email-masked],
             [email-masked]
To:          [email-masked],
             header-people <[email-masked]>,
             [email-masked]
Subject:     where do error reports go now?

I would strongly urge you to send reports for undeliverable mail
to the SMTP sender, not to the FROM or the SENDER in the RFC822
header.

When a mailing list resends a message, it usually will not munge
the RFC822 header, but most mailing list implementations will
put the list maintainer as the SMTP SENDER, and it is the list
maintainer, not the original author, who should get these kind
of messages.

At the same time, I would warn you against doing what some mail
systems do: They send a message saying that "the next message
is a returned undeliverable mail" and then they send the undeliverable
mail as a separate message.

This causes problems at least in my mail system (QZCOM) because
when I get the second message, I immediately note that I already
have that message in my data base, and since there are no new
recipients on it, I will just disregard it. Thus, people will
get a message saying "the next message is an undeliverable mail",
and then they will not get any next message at all.

The principle of sending undeliverable mail as two separate
messages, one with the error message and one with the returned
message, would be a good idea, but only if the first of these
two messages, the error message, contained some identification
of the returned message, the message-id of it and the author
and date fields for example.

26-Jul-84 06:03:42-PDT,2806;000000000001
Date: Thu, 26 Jul 84 07:53:46 cdt
To: [email-masked]
Subject: returned mail under separate cover
Cc: implementors@csnet-sh
Sender: [email-masked]
From: [email-masked]

Jacob Palme points out one problem with returning undeliverable mail
in a separate message from the error report (what I'll call "two-message
error reports" or TMER).  I would go further than he did and assert that TMER
is an extremely bad idea.  Another facility interfered with by TMER is 
automated handling of errors.  Error recovery is difficult enough
in the current chaotic mail world; TMER makes it almost impossible.  The
latest version of the CSNET nameserver software provides an example.

The software intercepts outgoing mail and tries to give the sender
additional assistance in getting it to its destination.  It puts
"forwarder" in the "sender" field (and in the SMTP envelope)
so that error reports are returned to a program rather than the original
author (see the header of this message for an example).  This program
queries a central database to see if the failure was due to stale
information (for example, because the recipient has moved).  Only if such
attempts fail does it return the message to the author.  The information
necessary to query the database, and indeed the identity of the original
author is only in the original message.  At the very least, TMER introduces a
headache:  One error message must be queued until the other arrives (note that
there is no guarantee on order of delivery, so the returned mail may precede
the error message!)  In the absence of any standards on how the two messages
identify each other, it is impossible to deal with TMER in any reasonable way.

By the way, another bogosity at some sites pointed up by the new nameserver
software is sites that send replies (mail generated by humans using a "reply"
command in their mail-reading software) to the address in the "sender"
field or the SMTP envelope in clear violation of RFC 822.  From time
to time we get mail addressed to "forwarder" with contents like
"You're right Jim, but I disagree with the third paragraph."  In some
cases it is impossible to figure out who the sender was trying to reach
and we are reduced to returning the mail (by hand) to the sender,
along with a nasty note to the postmaster at the sending site.  Luckily, 
postmasters seem to be reasonably willing to clean up their acts when
they have the problem pointed out.  We haven't had too many try to tell us
they're right and we're wrong.

12-Apr-85 09:34:25-PST,1348;000000000001
Date: 12 April 1985 0836-PST (Friday)
From: stanonik@nprdc
Reply-To: stanonik@NPRDC
To: tcp-ip@sri-nic
Subject: long delay connections
Cc: stanonik@nprdc

We've always had problems connecting to ucl-cs (we're in california,
ucl-cs is in london).  The symptoms bounce between "host unreachable",
"connection timed out", and "connection refused".  Mail in particular
seems to queue for at least a day before getting through.  Is this
response/reliability typical?  I've assumed so, because the connection
must hop through several gateways, including a slow(?) and congested(?)
link over/under(?) the atlantic.  We're running 4.2bsd on a vax 780.
Back in the 4.1bsd days, we were running bbn's tcp/ip, and had gotten
some modifications to help with long delay connections.  Has any tuning
been done on 4.2bsd for long delay connections?  Or is this response/
reliability the norm?  How about sites running something other than
4.2bsd?  Fuzzballs?  Dec 10's, 20's?

Thanks,

Ron Stanonik
stanonik@nprdc
12-Apr-85 17:05:46-PST,1011;000000000001
Date: 12 Apr 1985 19:24:42 EST
From: [email-masked]
Subject: Re: long delay connections
To:   [email-masked], [email-masked]
cc:   [email-masked]

In response to the message sent  12 April 1985 0836-PST (Friday) from  stanonik@NPRDC

Ron,

Your problems with 4.2 are well-known and documented. Fuzzballs have been
specially built to handle long-delay paths and have several features
designed to minimize the impact on intervening gateways of the type used
on SATNET paths, such as the send-policy and ack-policy algorithms described
to this list recently. According to Berkeley gurus, similar policies are
planned for the next release.

My experience has been that, with carefully engineered algorithms, SATNET
performance can be quite satisfactory.

Dave
-------
12-Apr-85 19:56:15-PST,3056;000000000001
To: [email-masked]
Cc: [email-masked]
Subject: Re: long delay connections
Date: 12 Apr 85 19:09:38 PST (Fri)
From: Van Jacobson <van@lbl-csam>

The problems you're seeing are probably due to mistakes in the
round-trip-timer code of the distributed 4.2bsd.  All of the bugs
reported to Berkeley have been fixed in 4.3bsd (& the 4.3bsd
release is immanent).

If you have source & don't want to wait for 4.3, here's a slightly
annotated diff listing of the fixes.  The annotations are mine &
may be neither correct nor comprehensible.  The fixes are from
various people around the country & seem to work (we've shipped
a lot of mail through ucl-cs with no problems).  The diff line numbers
will probably bear no resemblance to your sources.

 - Van Jacobson, Lawrence Berkeley Lab

 --------------------------------
(these lines added to tcp_timer turn off the round trip timing when you
re-transmit):
*** tcp_timer.c
*** 153,163 *****
  			    TCPTV_MIN, TCPTV_MAX);
  		}
  		tp->snd_nxt = tp->snd_una;
+ 		/*
+ 		 * If timing a segment in this window, stop the timer.
+ 		 */
+ 		if (tp->t_rtt && SEQ_GT(tp->t_rtseq, tp->snd_una))
+ 			tp->t_rtt = 0;
  		(void) tcp_output(tp);
  		break;
  
(deleting the following line prevents you from computing a bogus, too small
rtt when you get a ack for less than all the outstanding data).
*** tcp_input.c
*** 503,509
  		else {
  			TCPT_RANGESET(tp->t_timer[TCPT_REXMT],
  			    tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
- 			tp->t_rtt = 1;
  			tp->t_rxtshift = 0;
  		}
  		if (acked > so->so_snd.sb_cc) {

(if a timeout was caused by the subnet getting overloaded & discarding packets,
you don't want to retransmit everything because that will just make the problem
worse.  This change limits the sender to one MSS segment per timeout interval
until packets start getting through without timeouts)
*** tcp_output.c
*** 60,70 *****
  		return (0);	/* ??? */	/* past FIN */
  	if (len > tp->t_maxseg) {
  		len = tp->t_maxseg;
+ 		/*
+ 		 * Don't send more than one segment if retransmitting.
+ 		 */
+ 		if (tp->t_rxtshift == 0)
+ 			sendalot = 1;
  	}
  
  	flags = tcp_outflags[tp->t_state];
***************
(this line was just someone's mistake.  It prevents you from ever computing the
rtt on the first packet.  In fact, it keeps you from computing the rtt on about
half the packets).
*** 271,277
  		    tp->snd_nxt != tp->snd_una) {
  			TCPT_RANGESET(tp->t_timer[TCPT_REXMT],
  			    tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
- 			tp->t_rtt = 0;
  			tp->t_rxtshift = 0;
  		}
  		tp->t_timer[TCPT_PERSIST] = 0;
-------