ftp.cse.unsw.edu.au/2014.06.ftp.cse.unsw.edu.au.tar/ftp.cse.unsw.edu.au/pub/doc/standards/smtp/mail.errors.Z/mail.errors

Text File | 1992-10-18 | 69.4 KB | 1,748 lines

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
Return-path: [e-mail]
Received: FROM PARC-MAXC BY USC-ISIF.ARPA WITH TCP ; 18 Jan 83 10:41:54 PST
Date: 18 Jan 1983 10:37 PST
From: Taft at PARC-MAXC
Subject: Re: common SMTP problems
In-reply-to: MOCKAPETRIS' message of 17 Jan 1983 2218-PST
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 "[e-mail]" and "[e-mail]" 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:[e-mail]

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

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:foo!harpo!bilbo![e-mail]2

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
Return-path: @USC-ISI,wales@UCLA-Net
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 25 Jan 83 01:15:44 PST
Received: FROM UCLA-SECURITY BY USC-ISI.ARPA WITH TCP ; 25 Jan 83 01:11:05 PST
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
Return-path: @USC-ISI,wales@UCLA-Net
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 27 Jan 83 09:51:23 PST
Received: FROM UCLA-SECURITY BY USC-ISI.ARPA WITH TCP ; 27 Jan 83 09:44:27 PST
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
Return-path: @USC-ISI,wales@UCLA-Net
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 27 Jan 83 12:42:35 PST
Received: FROM UCLA-SECURITY BY USC-ISI.ARPA WITH TCP ; 27 Jan 83 12:38:46 PST
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: [e-mail]
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: [e-mail]
Subject: Another common SMTP problem
To: [e-mail]
cc: [e-mail], [e-mail]

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
Return-path: <WWB.TYM@OFFICE-3>
Mail-From: SMTP created at 12-Feb-83 16:51:45
Return-path: [e-mail]
Received: FROM OFFICE-3 BY USC-ISIF.ARPA WITH TCP ; 12 Feb 83 16:47:24 PST
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
Message-ID: <[OFFICE-3]TYM-WWB-1U8WH>

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
Return-path: <gurwitz@BBN-UNIX>
Mail-From: SMTP created at 15-Feb-83 06:45:26
Return-path: gurwitz@bbn-unix
Received: FROM BBNT BY USC-ISIF.ARPA WITH TCP ; 15 Feb 83 06:41:20 PST
Date: 15 Feb 1983  9:27:36 EST (Tuesday)
From: Rob Gurwitz <gurwitz at BBN-UNIX>
Subject: Re: Bum SMTP code for VAX Unix
In-Reply-to: Your message of 14 Feb 1983 12:14 PST
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: <[e-mail]>
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 <[e-mail]>
To:       [e-mail]
cc:       [e-mail], [e-mail]
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
Return-path: <mja@cmu-cs-cad>
Mail-From: SMTP created at 25-Apr-83 12:28:26
Received: FROM CMU-CS-CAD BY USC-ISIF.ARPA WITH TCP ; 25 Apr 83 12:28:34 PDT
Date: Monday, 25 April 1983 15:28:00 EDT
From: Mike.Accetta@CMU-CS-CAD
To: postel@isif
Subject: SMTP question
Message-ID: <1983.4.25.18.48.39.Mike.Accetta@CMU-CS-CAD>

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: <[e-mail]>
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 <[e-mail]>
Subject: [Mark Crispin <[e-mail]>: TCP BUGFIX: Slow TVT response]
To: [e-mail], [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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 <[e-mail]>
Subject: TCP BUGFIX: Slow TVT response
To: [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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: <[e-mail]>
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 <[e-mail]>
Subject: TCP BUGFIX: ADDENDUM
To: [e-mail]
cc: [e-mail], [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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
Return-path: <WATROUS@RUTGERS>
Mail-From: SMTP created at  5-May-83 23:10:20
Received: FROM RUTGERS BY USC-ISIF.ARPA WITH TCP ; 5 May 83 23:10:31 PDT
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
In-Reply-To: Your message of 6-May-83 0049-EDT

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: <[e-mail]>
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 <[e-mail]>
Subject: more TVT performance fixes
To: [e-mail]
cc: [e-mail], [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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
Return-path: <[e-mail]>
Mail-From: SMTP created at  6-May-83 04:27:56
Received: FROM BBNG BY USC-ISIF.ARPA WITH TCP ; 6 May 83 04:28:00 PDT
Date: Fri 6 May 83 07:29:44-EDT
From: Dan Tappan <[e-mail]>
Subject: Re: TCP BUGFIX: ADDENDUM
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail],
    [e-mail]
In-Reply-To: Your message of Fri 6 May 83 00:49:10-EDT

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
Return-path: <WATROUS@RUTGERS>
Mail-From: SMTP created at  6-May-83 08:19:30
Received: FROM RUTGERS BY USC-ISIF.ARPA WITH TCP ; 6 May 83 08:19:50 PDT
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
In-Reply-To: Your message of 6-May-83 0206-EDT

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.

*****

Return-path: <@rand-relay.ARPA:ANDLER.IBM-SJ@Rand-Relay>
Mail-From: SMTP created at 25-Apr-83 19:27:04
Received: FROM RAND-RELAY BY USC-ISIF.ARPA WITH TCP ; 25 Apr 83 19:27:06 PDT
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Return-Path: <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: <[e-mail]>
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 <[e-mail]>
Subject: [Mark Crispin <[e-mail]>: TCP BUGFIX: Slow TVT response]
To: [e-mail], [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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 <[e-mail]>
Subject: TCP BUGFIX: Slow TVT response
To: [e-mail]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (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
Return-path: <[e-mail]>
Mail-From: SMTP created at  6-Jun-83 11:06:35
Received: FROM PARC-MAXC BY USC-ISIF.ARPA WITH TCP ; 6 Jun 83 11:06:47 PDT
Date: Mon, 6 Jun 83 11:05 PDT
From: [e-mail]
Subject: Re: SMTP use of TCP & impact of SATNET
In-reply-to: "[e-mail]'s message of 6 Jun 83 09:36 PDT"
To: [e-mail]
cc: Steve Kille <[e-mail]>, [e-mail]

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
Return-path: <@rand-relay.ARPA:ANDLER.IBM-SJ@Rand-Relay>
Mail-From: SMTP created at 25-Apr-83 19:27:04
Received: FROM RAND-RELAY BY USC-ISIF.ARPA WITH TCP ; 25 Apr 83 19:27:06 PDT
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Return-Path: <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.

*****

Return-path: <@rand-relay.ARPA:ANDLER.IBM-SJ@Rand-Relay>
Mail-From: SMTP created at 25-Apr-83 19:27:04
Received: FROM RAND-RELAY BY USC-ISIF.ARPA WITH TCP ; 25 Apr 83 19:27:06 PDT
Date: 25 Apr 1983 16:03:03-PST (Monday)
From: Sten Andler <ANDLER.IBM-SJ@Rand-Relay>
Return-Path: <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
Return-path: <@USC-ISI:[e-mail]>
Mail-From: SMTP created at 30-Apr-83 08:26:28
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 30 Apr 83 08:26:34 PDT
Received: FROM [10.0.0.6] BY USC-ISI.ARPA WITH TCP ; 30 Apr 83 08:24:15 PDT
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
In-Reply-To:  Message of 28 April 1983 20:52 edt from 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
Return-path: <@USC-ISI:[e-mail]>
Mail-From: SMTP created at 10-Jun-83 19:24:23
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 10 Jun 83 19:24:28 PDT
Received: FROM MIT-MULTICS BY USC-ISI.ARPA WITH TCP ; 10 Jun 83 19:22:47 PDT
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
Return-path: <@USC-ISI:POSTEL@USC-ISIF>
Mail-From: SMTP created at 10-Jun-83 19:38:05
Received: FROM USC-ISI.ARPA BY USC-ISIF.ARPA WITH TCP ; 10 Jun 83 19:38:10 PDT
Received: FROM USC-ISIF.ARPA BY USC-ISI.ARPA WITH TCP ; 10 Jun 83 19:36:09 PDT
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
Return-path: <@MIT-MC:[e-mail]>
Mail-From: SMTP created at 10-Jun-83 18:43:40
Received: FROM MIT-MC BY USC-ISIF.ARPA WITH TCP ; 10 Jun 83 18:43:48 PDT
Received: from Diablo by Score with Pup; Fri 10 Jun 83 18:32:04-PDT
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

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

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 [phone].

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

 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: [e-mail]
Reply-To: [e-mail]
Subject: tcp_subr.c bug
From: [e-mail]
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
Return-Path: <@SRI-NIC:CHASE@USC-ISIB>
Received: FROM SRI-NIC BY USC-ISIF.ARPA WITH TCP ; 8 Jul 83 18:13:16 PDT
Received:  from USC-ISIB by SRI-NIC via DDN;   8 Jul 83 16:57:00-PDT
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
Message-ID: <[USC-ISIB] 8-Jul-83 15:15:05.CHASE>
In-Reply-To: Your message of 18 June 1983 02:31 EDT

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: [e-mail]
Subject: Outstanding TOPS-20 TCP bug remains in v5.2
To: [e-mail], [e-mail], [e-mail],
    [e-mail]
Cc: [e-mail]

     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: [e-mail]
  Subject: Re: need help from a tops-20 wizard
  To: [e-mail]
  cc: [e-mail], [e-mail], [e-mail],
      [e-mail]
  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 [e-mail]

  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: <[e-mail]>
  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: [e-mail]
  Subject: Re: TCP close fix
  To: [e-mail]
  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