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.