To:           Kevin Jordan / 413-545-2690 <Jordan@UMass>
Cc:           For Your Information <LSTSRV-L@UIUCVMD>
 
The malfunction was that the usual actions of all previously known nodes
in both BITNET and ARPANET have never ever done what the UMASS system did
with looping mail.  It seems that UMASS is in fact the first node to follow
certain standards (such as RFC822) exactly.  Unfortunately, there is NO
written standard that anyone I have asked knows about that specifies the
FORMAT of the return message.  The server we run has in the past prevented
these loops because it detected the defacto standard formats that have to
now been used.  Clearly from this situation we do need to abandon such
defacto standards and get things in writing so we can all do things.  As
it turns out, there are a few ambiguities in RFC822 that I am trying, and
have tried even before all this happened, to pressure people into looking
at.  For instance there are 4 different ways and needs to identify mail
origins while there are only 3 different header fields to put them in.
This will always result in problems since people will always use their
own interpretations to figure out what how to squeeze "4 round pegs into
3 round holes" where RFC822 dictates the 3 round holes.
 
My initial reaction to the loop was overreacted and based on a number of
complaints that were sent to me about a lot of "garbage" being redistributed
that came from "UMASS".  Since UMASS was not running software any of the
rest of us knew anything about, and due to the fact that it was incompatible
in a few subtle ways that became serious problems, it was typical to blame
UMASS for the problem.  As it turns out, UMASS's intentions and efforts
were of the best and highest quality I have seen.  The only real flaw that
probably exists there is that no one looked at how it might impact a
network (BITNET) that has to this date not completely adopted RFC822.
 
As it seems to me, the problem is not in the list server we run, but rather
in RFC822's lack of capacity to handle any lists at all.  Nevertheless such
lists are very numerous and in many cases very large.  Most problems such
as looping have been eliminated, probably by means of the defacto standards
previously mentioned.  I believe that I made an error in over emphasizing
the seriousness of the problem in relation to UMASS.  Based on knowing what
I did at that time, I still believe that anyone would have blamed the
problem on UMASS since such problems are now very rare and when they did
occur, were a result of software flaws at the offending node.
 
The seriousness of the problem still remains serious, though, in my opinion,
but the blame does NOT rest on UMASS.  The blame resides in RFC822 and with
the use of defact standards on the networks.  Unfortunately, these things
are all that we have here right now.
 
For a moment, consider a problem that could very well be a software
development project for your machine.  You will be creating a program that
retrieves mail sent to various mailboxes and redistributes that mail out
to users on a list of addresses associated with that particular mail box.
The requirements are as follows:  1. the original sender of the message
must be identified  2. the name of the list itself must be identified so
that automatic logging mail user agent programs can save the messages in
the proper place  3. the name of the person to who the mail is addressed
must be in the header since an SMTP transaction is not being used  4. a
place to send rejection mail is identified so that such rejections can be
directed to other that the whole list.  Now, how would UMASS design such
a facility.  If this can be defined and documented, I'm sure it would be
used.  Currently, requirement number 4 is not there and a method of
recognizing rejections in "standard" format is used.