11-Jun-83 15:51:05-PDT,7168;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 15:47:03-PDT Received: From Usc-Eclc.ARPA by BRL via smtp; 11 Jun 83 18:10 EDT Date: 11 Jun 1983 1409-PDT Subject: MSGGROUP#2101 SURVEY #2051-#2100 from MSGGROUP.2001-2100.1 From: MsgGroup Moderator - Stefferud Reply-To: MsgGroup-Request@brl To: msggroup@eclc Remailed-date: 11 Jun 1983 1507-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup@brl Some of you may have missed some of these messages because of failed mail problems. You can FTP the whole file from [ECLC]msggroup.2001-2100.1, using FTP with LOGIN ANONYMOUS with Password MSGGROUP. I will remail requested items, with some delay for processing, if you will request them by reply mail to MsgGroup-Request@BRL. Please cite what you want by their specific Msggroup#nnnn identifiers, as shown. ======== MSGGROUP#2051 SURVEY #2001-#2050 from MSGGROUP.2001-2100.1 7172 chars 25 May 1983 1800 PDT From: MSGGROUP@usc-eclc To: msggroup@ MSGGROUP#2052 Re: Basic Message Format 4164 chars 25 May 83 18:42:28 PDT (Wed) From: wcwells%Topaz.CC@berkeley MSGGROUP#2053 Re: RFC 806 = NBS Mail Protocol 677 chars 25 May 1983 20:44 est From: DBrown.TSDC@hi-multics To: msg MSGGROUP#2054 Re: Basic Message Format 963 chars 27 May 1983 1000-EDT From: Larry Campbell To: msggrou MSGGROUP#2069 Re: problems with NBS standard 829 chars 8 Jun 83 16:43 PDT From: WBD.TYM@office-2 To: DDEUTSCH@bbna MSGGROUP#2070 [Scott L. McGreg: problems with NBS standard] 1471 chars 8 Jun 83 17:14:17 EDT (Wed) From: Ron Natalie To: M MSGGROUP#2073 Re: problems with NBS standard 828 chars 8 Jun 1983 2323-PDT From: ESTEFFERUD@usc-ecl To: WBD.TYM@of MSGGROUP#2074 List-Processor 1725 chars 9 Jun 83 0:40:12 EDT (Thu) From: Mike Muuss MSGGROUP#2075 problems with NBS standard 3868 chars 9 Jun 83 01:14:00 EDT (Thu) From: Mark Horton : Re: problems with NBS standard] 2025 chars 9 Jun 1983 1114-PDT From: Scott L. McGregor : Re: possible loop ...] 1214 chars 9 Jun 1983 2322-PDT From: ESTEFFERUD@usc-ecl To: msggroup@b MSGGROUP#2089 Explanation of endless NBS messages 2421 chars 10 June 1983 01:35 EDT From: Ken Harrenstien To MSGGROUP#2090 UUCP mail 1201 chars 10 June 1983 0351-EDT From: Rudy.Nedved@cmu-cs-a To: MsgGrou MSGGROUP#2091 Mis-directed mail 946 chars 10 Jun 83 7:13:36 EDT (Fri) From: Doug Kingston Received: from BRL by USC-ECLC; Sat 11 Jun 83 14:54:06-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 11 Jun 83 17:18 EDT Date: 11 June 1983 17:19 EDT From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#2102 EBCDIC in NBS standard To: msggroup@brl The NBS standard specifies a large number of data types. There is absolutely no requirement that any field be in ASCII at all. For example all fields could be specified as facsimile bit strings. In practice, for the next few years most users will specify fields as ASCII text strings. They could just as easily have specified them as EBCDIC bit strings. Indeed, there is a data element identifier code 177 which is reserved for vendor defined data element types. HP or IBM could simply assign that code to mean EBCDIC. (This doesn't solve the problem of having to separate out the data element identifiers, which are binary bit strings from the text parts. It only eliminates the need to do any character translation after the data element contents have been extracted.) The real problem with the standard, one that I raised to NBS during the review process, is the failure to have assigned a data element identifier to EBCDIC from the beginning. (They should also have assigned an identifier to the Teletex alphabet and NAPLP as well.) As a result of their failure to do so, different vendors will make up different ad hoc identifier codes or use data element identifier 177 in multiple incompatible ways, therefore making it more difficult for those who would like to have a standard way of referring to these other alphabets/data element types. What they have done is the same as if Xerox had defined internet protocol identifiers in the Ethernet protocol only for XNS and TCP and had refused to assign a number for CHAOS or SNA protocols. Marvin Sirbu 12-Jun-83 15:02:56-PDT,9356;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 12 Jun 83 15:02:40-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 12 Jun 83 17:05 EDT Received: by UCBARPA.ARPA (3.344/3.32) id AA14066; 12 Jun 83 14:04:45 PDT (Sun) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.31) id AA07707; 12 Jun 83 13:59:30 PDT (Sun) Date: 12 Jun 1983 1404-PDT (Sunday) From: eric%UCBARPA@berkeley Subject: MSGGROUP#2103 mail loop caused by sendmail (166 lines) Message-Id: <13382.31.424299882@ucbarpa> Phone: (415) 548-3211 To: MsgGroup@brl, Header-People@mit-mc Cc: nowicki%Diablo@su-score Fcc: mail As the author of sendmail, the new mail router out of Berkeley, I feel compelled to respond to the explanation of the mail loop given by Bill Nowicki a few days ago. Part of this will be a defense, and part will be a confession. I hope that this will be an interesting lesson in software engineering, if nothing else. I have had plans to turn this into a paper for some time, but a preview seems appropriate. Let's start with confessions. I agree completely with the criticism that sendmail is just too big and too baroque. This results from several forces. First, I didn't understand the problem when I started. Part of this was because initially I was trying to solve an isolated problem on one machine at Berkeley; I had no idea that it was going to turn into a general problem. Indeed, it was never my "job" to do delivermail or sendmail -- they were "small" (hah!) spare time projects. However, the other side of this was that there was almost nothing published regarding mail routing at that time. I suppose MsgGroup et al existed at that time, but since there does not exist a publicized list of mailing lists, I did not know about them. In summary: the Arpanet community is a difficult community to break into, almost as difficult as the Unix-Wizards community, with no one willing to talk to you until you know the ropes, but no way to learn the ropes unless someone will talk to you. Second, I was entirely too susceptible to criticism. All of us have heard stories of offensive people in the community who are sure that they have all the right answers and will not listen to anyone. I continue to believe that this is a serious problem that has been all too prevalent. But I now understand the other extreme to be equally as bad: the person who puts in anything that anyone suggests ends up with a monster with a voracious appetite. I gained enough confidence to start saying "no", but too late. I have tried to take out features, but it proves harder to take features out than to never put them in in the first place. Third, I underestimated the complexity of the problem. I contend that single-letter identifiers are fine when you have eight or ten identifiers. In my early configuration tables this was indeed the case. When I had to go to split case I should have realized that something was wrong, but it was so easy to go to split case and so hard to go to full words; besides, I had other reasons to stick to single character identifiers (see below). Now for some defense. I will start with the simple rebuttals and then move on to the more sweeping issues. It is not the case that configuration tables are not portable. The host name is available. Sendmail is not intended as a "user interface." My intent was was to be able to read the configuration file doing a fairly trivial amount of parsing -- hence the single letter identifiers, etc. Similarly, the command line arguments are not required to be highly user-friendly, because they are for use by gurus (who presumably have a certain level of intelligence and care) and not by the casual user. About 50% of the configuration table need not be touched until RFC911 comes out (or whatever the next mail protocol is). A large amount of the complexity was put in during the 733 => 822 transition; during that period it was important to be able to handle either protocol. The roughest part of that was route-addr's; production systems seem to be able to handle left-to-right parsing well, and right-to-left parsing adequately, but both at once is a real pain. If the route-addr's had been in the syntax "user@hostc@hostb@hosta" indicating "route to hosta, then hostb, then hostc" it would have been unambiguous, closer to 733, and strictly right-to-left. Sendmail sits in a difficult position. Many of the mail servers on the Arpanet speak only to SMTP-compatible hosts. Sendmail talks to SMTP, UUCP, Purdue Net, Berknet (which uses colons [ugh] in addresses), Phonenet (via MMDF), and can be made to talk to others fairly trivially. This adds an untold amount of complexity. Was this a mistake? Perhaps. My idea was to build a "language" (i.e., the configuration file) that could be programmed to handle the various address formats, etc. I find myself under fire from all sides for this. The world is filled with UNIX-egoists who care only about UUCP. They are exceeded only by the SMTP-egoists who claim to be building an "Internet" based on only one style of communication. Yes, sendmail is complex, because it deals with a complex problem. (By the way, at one time I considered MMDF to be a competitor. At this point I have only the greatest respect for MMDF and it's implementors; if nothing else comes out of this project, I will have developed a contact, respect, and even a degree of friendship with Dave Crocker, Dave Farber, Brendan Reilly, Doug Kingston, and others who have done a magnificent job with a problem so complex that most people cannot even comprehend it.) Strangely enough, one of my recent conclusions is that the obscurity of the configuration file is an advantage! Such heresy deserves explanation. I have discovered (much to my disappointment) that the world is full of people who have no concern whatsoever for protocols. These people are typically called "hackers" and are frequently located far enough off the beaten path that the protocol police cannot find them or cannot touch them. These are people who change Date: lines to be UNIX-style date lines because it is "more standard," people who delete Received: lines because they don't like them and don't understand their importance, people who insist on their "right" to use user@hosta@hostb even though it clearly violates the protocols, etc. This one really falls in the "confession" section, because I now realize that people who are afraid to touch code think nothing of touching a configuration file. The bottom line is that it may be better to leave the configuration somewhat unapproachable than to make it easy for hackers to make gratuitous changes. Finally, no system can protect itself from the person who uses it incorrectly. It seems bizarre to me that sendmail can be criticized for functioning correctly. Today, I would do a number of things differently: Although I remain convinced of the power of the configuration file, I would limit the contents. For example, I would retain the concept of protocol conversion, but only for the most simple cases, such as converting domain-based addresses (as used internally) into Arpanet-based addresses (e.g., I map "user@host.BITNET" into "user%host.BITNET@Berkeley.ARPA"). The configuration file would map external addresses into internal (domain-based) addresses, but after that the parsing would be ad hoc; in particular, the inside-out route-addr's are just too difficult to parse in a production system (which I would probably retain). I would certainly push the absurd cases (e.g., UUCP so-called "addresses" which are really routes) into another module. Given that I seem to have more power and respect now than I once did, I would almost certainly simply outlaw colons in addresses and convert Berknet to use another syntax. I would make the configuration files a very different format, but include a compiler that would generate something that could be read very quickly. The compiler could also do a lot of checking. Morals (some are my personal opinions): 1. Case sensitivity is a bad idea. 2. Single letter identifiers are a bad idea if you have more than about ten of them. 3. Multiple notions that are similar are confusing, but sometimes necessary; there is a difficult balance between exploiting the similarities and accentuating the differences. 4. internet mail systems are fragile things. 5. "Improved" software with more "features" sometimes is and sometimes isn't: the important thing is to realize that every feature has both a cost and a benefit. 6. (Corollary 1) One man's feature is another man's bell or whistle. 7. Both the UNIX and the Arpanet community could afford to learn from the other. 8. Flexibility is a nice thing, but too much flexibility can backfire. 9. Better loop/duplicate detection is needed. Message-Id's should be required in all messages at their origination to make this feasible. Message-Id's should probably be in a well-defined format to simplify their use, e.g., ; this would allow the database to implement timeouts on the message-id's after (say) one week trivially, etc. eric 13-Jun-83 19:24:24-PDT,1420;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 13 Jun 83 19:22:45-PDT Received: From Office-3.ARPA by BRL via smtp; 13 Jun 83 21:54 EDT Date: 13 Jun 83 18:53 PDT From: RICH.GVT@office-3 Subject: MSGGROUP#2104 Lists of mailing lists To: MsgGroup@brl Cc: eric%UCBARPA@berkeley Message-ID: <[OFFICE-3]GVT-RICH-2L7Y7> I had thought that by now, everyone pretty well knew of the list-of-lists, but a recent message indicates tht it (they, actually) may still not be widely known. I maintain a list on host OFFICE-3 of all the ARPANET mailing-lists and digests that I know about in publicly readable/FTPable file INTEREST-GROUPS.TXT Also, Adam Buchsbaum (research!sjb or esquire!harpo!npoiv!alice!sjb [I think]) apparently maintains a list of all known (to him) USENET Newsgroups; I have his list A/O November 1982, but don't know where he keeps the current one. I don't know about Adam Buchsbaum, but I also maintain a mailing-list (listed in the list-of-lists, of course) for those who want to receive update-notices so they can re-FTP the current version only when necessary. This isn't exactly MsgGroup business, but the subject was brought up here. Anyone wanting to be put on the mailing list for the list-of-lists, or anything else related to this, PLEASE reply directly to me - - and NOT to MsgGroup. Cheers, Rich Zellich 13-Jun-83 23:06:24-PDT,1007;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 13 Jun 83 23:00:16-PDT Received: From Washington.ARPA by BRL via smtp; 14 Jun 83 1:37 EDT Date: 13 Jun 83 22:36:11-PDT Mon From: Richard Furuta Subject: MSGGROUP#2105 Re: Lists of mailing lists To: RICH.GVT@OFFICE-3.ARPA, MsgGroup@BRL.ARPA cc: eric%UCBARPA@UCB-VAX.ARPA, Furuta@WASHINGTON.ARPA In-Reply-To: Your message of Mon 13 Jun 83 18:53:00-PDT For the information of Msggroup readers, Adam Buchsbaum periodically posts his list of Usenet lists to the Usenet itself. The latest version (from the beginning of the month, I believe) can be found on any Usenet site in the net.news group (at least I think it's net.news--it might be one of the subgroups). If you are on an Arpanet site without access to the Usenet and are interested in seeing this list, send me mail at Furuta@UW-VLSI (not the address given here in the header) and I'll forward a copy to you. --Rick ------- 14-Jun-83 12:23:30-PDT,1198;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 14 Jun 83 12:19:25-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 14 Jun 83 12:52 EDT Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.345/3.33) id AA11707; 14 Jun 83 09:51:40 PDT (Tue) Received: by UCBARPA.ARPA (3.344/3.32) id AA05534; 14 Jun 83 09:49:23 PDT (Tue) Phone: (415) 548-3211 Date: 14 Jun 1983 0949-PDT (Tuesday) From: eric%UCBARPA@berkeley Message-Id: <5533.31.424457361@ucbarpa> To: RICH.GVT@office-3 Cc: MsgGroup@brl Subject: MSGGROUP#2106 Re: Lists of mailing lists In-Reply-To: Your message of 13-Jun-83 18:53 PDT <[OFFICE-3]GVT-RICH-2L7Y7> Fcc: mail The problem is not so much whether the list does or does not exist, but what you need to do to find out. I have been on the Arpanet for about five years now, and this is indeed the first time I have heard of this list-of-lists. Pity the poor beginner, who gets his Arpanet Protocol Handbook (or whatever). There is no mention of the lists or the list-of-lists in this book. Perhaps the list-of-lists should be bundled as an ongoing RFC (much like Assigned Numbers) that gets sent out with the description of the net. eric 17-Jun-83 17:55:08-PDT,1199;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 17 Jun 83 17:50:14-PDT Received: From Office-2.ARPA by BRL via smtp; 17 Jun 83 19:49 EDT Date: 17 Jun 83 16:42 PDT From: WBD.TYM@office-2 Subject: MSGGROUP#2107 Bulletin Board For Micro Users Set Up By NBS To: OAD.TYM@office-2, hardy%office-5@BRL.ARPA, human-nets@rutgers To: works@rutgers Cc: info-micro@brl, msgGroup@brl Message-ID: <[OFFICE-2]TYM-WBD-2M6ML> WASHINGTON, D.C. -- An electronic bulletin board that will inform microcomputer users about upcoming conferences, seminars and workshops, as well as update them on the latest telecomputing services, publications and users groups, has been established by the Commerce Department's National Bureau of Standards (NBS). Dubbed the Microcomputer Electronic Information Exchange (MEIE), the service will be available 24 hours a day, 7 days a week. Both fedral and nonfederal users with Acscii terminals that communicate at 300 bit/sec with eight data bits, no parity and one stop bit can reach the exchange by calling (301) 948-5718. Further information on MEIE can be obtained fom the NBS. From June 13th issue of COMPUTERWORLD 23-Jun-83 22:48:01-PDT,3355;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 23 Jun 83 22:47:24-PDT Received: From Ucla-Locus.ARPA by BRL via smtp; 24 Jun 83 1:23 EDT Date: 23 Jun 83 17:14:22 PDT Thu From: Rich Wales To: MsgGroup@brl Subject: MSGGROUP#2108 Playing with message headers -- pro's and con's [I may have made this comment sometime earlier -- either to this list or to Header-People -- but I can't recall ever getting any feedback, so here goes again. . .] One question that arises when you talk about conversion between differ- ent mail format standards (e.g.: ARPA RFC822, UUCP, and NBS) is the extent to which it is OK to "digest" the header of an incoming message and then later reconstitute it in a "canonical" form that may differ "cosmetically" from the original. RFC822 seems to bless this practice when it says -- Some message systems may store messages in formats that differ from the one specified in this standard. This specification is intended strictly as a defi- nition of what message content format is to be passed BETWEEN hosts. (page 1) Judging from various "round trip" messages, messages sent to mailing lists, and mail returned as undeliverable which I have seen lately, it appears that many sites apply one or more of the following transforma- tions to the headers of mail that they process: (1) Recopying of "Date" and "From" lines in a different, but (usually) equivalent, format. (2) Changing the width of "linear white space" fields. In particular, the extra white space after the colons -- which my mailer lets me insert in order to make the data in the header "line up" -- often disappears when the mail goes through certain sites. (3) Rearranging of the sequence of header lines. I once designed a mail system which transformed "Date" and "From" lines of incoming messages into more-or-less canonical forms; I was severely chastised for doing this (and in fact ended up redesigning the mail system in question) on the grounds that: (1) "The header is part of the message, the sender formatted the header to look the way he wanted it to look, and recipients have a right to see it EXACTLY the way the sender composed it." (2) Many sites "out there" had mail-reading programs which matched up the "Date" lines in a user's outgoing messages with the "In-reply- to" lines in incoming replies. If the foreign site transformed the original "Date" line into a "canonical" form, then proceeded to use this new form in its "In-reply-to" line, the "smart" mail-reading program didn't know what was going on. (3) As a last resort, the human recipient of a message should be able to see what the original header looked like (say, if the return address has problems). If the recipient's mail system has trans- formed the header into a supposedly (but not quite) equivalent form, important data may thereby be lost. What do people currently think about these issues? In particular, I hope to elicit comments from people whose mail systems store incoming mail in special data-base formats (with various header lines going into special data elements within a "message" record). For example, I have heard that Xerox's mail system works this way. -- Rich 26-Jun-83 09:57:49-PDT,912;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 26 Jun 83 09:57:09-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 26 Jun 83 11:16 EDT Date: 26 June 1983 11:16 EDT From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#2109 Playing with message headers -- pro's and con's To: v.wales@ucla-locus cc: MsgGroup@brl If you adopt the approach of the NBS message format where the header fields are in a connonical form to begin with (e.g. Date) then the problem goes away. In general you have two kinds of information in any field. Inforamtion realted to the content, and inforamtion related to the appearance. Header fields are generally those wehre the content is primary and so changing the display should not be critical. By contrast,, the text field contains both content and format information (generally) and thus should be left alone. Marvin Sirbu 26-Jun-83 18:52:46-PDT,10183;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 26 Jun 83 18:49:19-PDT Received: From Parc-Maxc.ARPA by BRL via smtp; 26 Jun 83 19:39 EDT Date: 26 Jun 83 16:39 PDT Sun From: Taft.PA@PARC-MAXC.ARPA Subject: MSGGROUP#2110 Re: Playing with message headers -- pro's and con's (long message) In-reply-to: "v.wales@ucla-locus.ARPA's message of Thu, 23 Jun 83 17:14:22 PDT" To: MsgGroup@brl.ARPA cc: Taft.PA@PARC-MAXC.ARPA Since you mentioned Xerox, I will restate and amplify my opinions on this matter. You refer to "Xerox's mail system" as if it were a monolithic entity. It is precisely this failure to distinguish layers of function and protocol that leads to confusion and controversy over who should do what to messages. 1. Principles The proper model for the ARPA electronic mail system (when used to communicate text messages between humans) is as follows: 1. The human sender interacts with a mail composition program to provide a variety of information such as recipient names, subject, and message body. The nature of this interaction is exclusively a user interface issue and is not subject to any of the ARPA protocol standards. 2. The information in the message is bundled up according to a standard protocol, namely RFC 822. 3. The message is shipped to the desired destination using another standard protocol, namely SMTP (RFC 821), which in turn is layered on top of a hierarchy of other standard protocols. 4. At that destination, the information is extracted from the message by interpreting it according to RFC 822. 5. The information is presented to the human recipient by his or her mail reading program. The nature of this interaction is exclusively a user interface issue and is not subject to any of the ARPA protocol standards. To use ISO terminology, steps 1 and 5 are application-level activities, steps 2 and 4 are presentation-level activities, and step 3 includes activities at the session level and below (transport, network, etc.) RFC 822 defines a peer-to-peer protocol between presentation-level entities, and SMTP defines a peer-to-peer protocol between session-level entities. The thing that's terribly important to understand is that the protocol between the presentation-level entities has nothing to do with the protocol between the human users and their respective application programs. The former is dictated by ARPA standards and the latter is a user interface issue. The thing that makes this hard to understand is that data conforming to RFC 822 happens to be human-readable, so people get the mistaken impression that what goes across the wire is what the humans are meant to see. The need to deal with the ISO layers properly is much more obvious if the presentation-level protocol is not human-readable, such as the NBS standard (or the new CCITT standard, which I understand is being adopted for Xerox products). So in principle, the sending and receiving application programs are free to represent messages any way they care to (internally and when interacting with the user). RFC 822 dictates only the presentation-level interactions; and the lower-level programs responsible for transporting messages have no business touching the data being transported. This principle is rigidly adhered to in the Xerox Internet. In simple user interface programs, the mapping between application and presentation levels is (nearly) the identity transformation; in fancier ones, information in a message is stored in a data base and its appearance to the user may be arbitrarily different from RFC 822. 2. Pragmatics Now, when it comes to relaying messages between the Xerox and ARPA Internets, ugly realities intrude. There are three main areas of difficulty: 1. The Xerox and ARPA name spaces are structured differently. From within the ARPA name space, the entire Xerox name space appears as a sub-tree of a single ARPA domain, namely PARC-MAXC.ARPA. Conversely, the entire ARPA name space dangles off a single node of the Xerox name space. This "mutual embedding" of name spaces requires that names be translated when crossing from one environment to the other. (Someday I hope to solve this by making Xerox be an independent top-level domain.) 2. We have completely converted to RFC 822 whereas the ARPA world has not. Our message generators and parsers deal in RFC 822 headers exclusively. They must be insulated from the large amount of non-822 traffic that still pours in from the Arpanet. 3. In the ARPA world it is customary to insert line-folding CRLFs in transmitted messages so as to suit the needs of "conventional" terminals (whatever that means). In the Xerox world this is not done; and I should point out that doing so is a fundamental violation of the separation between presentation-level and application-level functions. These difficulties really boil down to a single problem, namely a disagreement about the interpretation of RFC 822. The effect of this is that the Xerox and ARPA Internets are using slightly different and incompatible presentation-level protocols. Translation is required. The agent performing this translation is not a simple "relay". It is actually a pair of presentation-layer entities connected back-to-back, one dealing with the Xerox variant of RFC 822 and one dealing with the ARPA variant (which is not really RFC 822 but is an amalgamation of 822, 733, and various random additions). This is actually how it's implemented, and it works quite well. The translator does not change things gratuitously (for example, it is careful not to lose the comments in structured fields); but when it has to make a change due to protocol incompatibility, it does so. 3. Remarks In light of the above, here are my reactions to the issues raised in the message that started this discussion. a) Transformations. First of all, only presentation-level entities should be messing with headers; simple relays should not touch them. 1. Converting dates to canonical form. Well, either the original dates conformed to the standard or they didn't. Non-conforming dates shouldn't be sent in the first place, and senders of non-conforming dates have no business complaining. As for converting between different conforming representations (e.g., with or without weekday, with or without seconds, etc.), I don't see any point in making the change, but I also don't see any harm (so long as it is correct!) All conforming dates have unique, unambiguous interpretations. It is the interpretation that matters, not the representation; the syntax that the user sees is strictly a user interface issue. 2. Adjusting linear white space in header fields. In structured fields, there are no semantics associated with differences in width of linear white space. "Making the data line up" is strictly a user interface issue. Attempts by a sender to make structured fields look pretty are misguided anyway; something that looks pretty on your terminal may be ugly on someone else's. A different argument applies to unstructured field bodies, e.g., Subject. The body is just a which is assigned no semantics by RFC 822. In this case it would be most inappropriate to fiddle with the formatting. Note, however, that a line-folding CRLF is not considered to be a part of a , so adjusting it would be perfectly OK. 3. Rearranging the sequence of header fields. With the possible exception of multiple Received fields (which don't belong at the presentation level anyway), the order of header fields has no semantics. This is strictly a user interface issue. b) Objections to the transformations. 1. "The sender formatted the header to look the way he wanted it to look." Baloney. The correct model is that the sender dealt with an application program, which transformed the sender's intentions into the syntax and semantics prescribed by RFC 822. 2. Matching Date with In-reply-to. I assume you are talking about the variant of In-reply-to in which the field body is a as opposed to a . The standard does not specify any semantics for this variant. If there is a date inside, that is something to be established by higher-level convention or by heuristic means. If a mail reading program is failing to match up a canonicalized Date with a corresponding date extracted from an In-reply-to field, that is the fault of the heuristic, not of the canonicalization. 3. Being able to see the original header in case things go wrong. This is a somewhat more compelling argument, but is still misguided. A program that transforms correct headers into correct headers does not change the semantics, so no additional information is to be obtained from the original header. A program that transforms correct headers into incorrect headers has a bug that should be fixed. It is unreasonable to encumber the protocol with extra restrictions or to violate the protocol layering just to cater to this eventuality. A program that transforms incorrect headers into "correct" headers is skating on thin ice unless the semantics of the incorrect headers are perfectly understood. To avoid trouble, the syntax and semantics of the non-822 messages that are accepted had better be as precisely specified as RFC 822 itself; and the translator should either reject header fields not conforming to that modified grammar or pass them through unchanged. This is the approach we have taken in our translator. For example, it does not simply change all occurrences of "AT" to "@" in structured fields. Rather, it parses using an augmented grammar that includes rules such as = "AT" , and it performs the translation only if a correct parse results. Well, I've been going on long enough. As you can see, all manner of religious issues can be easily disposed of once you view RFC 822 in the proper way, namely as strictly a presentation-level peer protocol. Ed Taft 27-Jun-83 09:37:18-PDT,1258;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 27 Jun 83 09:36:07-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 27 Jun 83 7:25 EDT Via: Rice; 27 Jun 83 4:08-PDT Date: 27 Jun 83 01:37:29 CDT Mon From: Dave Johnson Return-Path: Subject: MSGGROUP#2111 Re: Playing with message headers -- pro's and con's To: Msg Group In-Reply-To: Ed Taft's message of Sun, 26 Jun 83 16:39 PDT Speaking of transforming a message with correct headers into one with incorrect headers, take a look at my "To:" line above. It left my mailer looking like: To: Msg Group but most (all?) of you will receive: To: Msg@Rand-Relay, Group@Rand-Relay, While this change does not make the header incorrect according to a very literal interpretation of RFC 822, did Rand-Relay really try to mail this to the two people "Msg@Rand-Relay" and "Group@Rand-Relay" ? Dave Johnson Dept. of Math Science Rice University dbj.rice@Rand-Relay 27-Jun-83 13:36:47-PDT,1306;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 27 Jun 83 13:32:42-PDT Received: From Ucl-Cs.ARPA by BRL via smtp; 27 Jun 83 12:00 EDT Via: Rlgk.AC-UK; to UCL-CS.AC-UK (44b) over Sercnet with NIFTP; 27 Jun 83 16:45 BST From: Philip Gladstone (on GEC 4090 at Rutherford) To: MsgGroup@Brl.Arpa Date: 27 Jun 83 16:45 BST Mon Subject: MSGGROUP#2112 Mail languages Message-Id: <27 JUN 1983 16:45:11 NSIN08@RLGK> Before we go overboard about translating headers, consider the case of Europe (and Canada I guess). My standard mailing domain includes 4 different countries but in each of these many languages are spoken. E.g. In Switzerland all three of French, German and English are spoken, and in Wales there is a vociferous minority who speak Welsh rather than English. This leads me to the conclusion that when translating message headers (and dates), some information needs to be available as to the source language. (what about the destination language?) (what about error reports - they should be in the language of the sender.) Since RFC822 is only a transport protocol, it seems obvious to junk all the above and declare that User Interfaces should have means for displaying the headers in an appropriate language. 28-Jun-83 02:32:11-PDT,1643;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 28 Jun 83 02:27:47-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 28 Jun 83 2:50 EDT Via: Rice; 27 Jun 83 23:13-PDT Date: 27 Jun 83 22:12:07 CDT Mon From: Dave Johnson Return-Path: Subject: MSGGROUP#2113 Re: Playing with message headers -- pro's and con's To: Msg Group Amazing.. the "To:" field in the copy of my own message that I received was indeed correct. Somebody must have fixed this very recently... thank you and thanks to all the people who replied telling me how my header looked when they received it. I'm happy to say (and I'm sure Rand-Relay will be happy to know) that I haven't had any reports of anybody receiving my "To:" field incorrectly. Of course, there still are two "Via:" lines in the copy I received... As far as my statement that the transformation that I was expecting (and have seen on every message to come back to me before this one) was technically correct, I was refering to the rule that makes everything outside "<" and ">" in an address a comment, but I had not noticed that adding the "," before the "<" would turn my comments into actually two new addresses, so that transformation would indeed have been very incorrect. The problem only occurred when there was a user's full name (or whatever) outside the "<" ">", so I don't see this on every message I receive, but I did see it on two messages that I received on the day the I sent my original message... Sigh... Dave Johnson 28-Jun-83 20:38:15-PDT,1477;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 28 Jun 83 20:34:35-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 Jun 83 22:49 EDT Date: 28 Jun 83 21:45:37 EDT Tue From: Ron Natalie To: tcp-ip@brl-bmd, unix-wizards@brl-bmd cc: msggroup@brl-bmd Subject: MSGGROUP#2114 Security Problem? I have noticed that many sites have taken the precaution of having their login programs (and their FTP servers) not make a distinction between an invalid user name and an invalid password. The reasoning behind this is that if a user could tell, he could sit there hacking a user name until he got a valid one and then start hacking its password. While trying to figure out a user name that I had written down rather illegibly, I found this is a rather effective deterrent to those guessing at user name. Until I got the following idea. I connected to the site's SMTP server and did the following: 220 HOST-OF-HOSTS SERVER SMTP HELO HACKER 250 HOST-OF-HOSTS MAIL FROM: 250 OK RCPT TO: 550 We have no "ROT" here. RCPT TO: 250 Recipient accepted. Since most machines have mailboxes that are the same as the valid login names, this may prove an effective way of hacking the names. In addition, the easiest way to get user names at valid hosts is to just subscribe to one of the busy mailing lists and use the ones of those sending mail. -Ron 29-Jun-83 10:26:17-PDT,1004;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 29 Jun 83 10:22:37-PDT Received: From Sri-Csl.ARPA by BRL via smtp; 29 Jun 83 12:21 EDT Date: 29 Jun 1983 09:10-PDT Sender: GEOFF@sri-csl Subject: MSGGROUP#2115 Re: Security Problem? From: the tty of Geoffrey S. Goodfellow@BRL.ARPA Reply-To: Geoff@sri-csl To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd Message-ID: <[SRI-CSL]29-Jun-83 09:10:54.GEOFF> In-Reply-To: The message of Tue, 28 Jun 83 21:45:37 EDT from Ron Natalie A real easy way of "hacking names" on a host is to just connect up with TELNET and do a SYSTAT or FINGER. Big Deal. A gourmet "name hacker" would use the NIC's informative "WHOIS" Server. Just give the name of your favorite host preceded with a star `*' (i.e. try `*brl' for example) and a nicely formatted list, replete with full name, initials(nic id), mailbox and phone number will promptly be displayed. Happy Hacking. 29-Jun-83 14:11:08-PDT,1017;000000000001 Return-path: <@SU-DSN:greep@su-dsn> Received: from BRL by USC-ECLC; Wed 29 Jun 83 14:07:11-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 29 Jun 83 15:56 EDT Received: From Su-Dsn.ARPA by BRL-BMD via smtp; 29 Jun 83 15:43 EDT Date: 29 Jun 1983 12:41-PDT Wednesday To: Ron Natalie Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd Subject: MSGGROUP#2116 Re: Security Problem? In-reply-to: Your message of Tue, 28 Jun 83 21:45:37 EDT. From: greep@su-dsn Other tactics include looking in the Arpanet directory or just trying common names. In addition, many Unix sites have a "who" login that runs the "who" or "finger" program, and most tops-20 sites let you run "finger" or "systat" without being logged in. In fact, you can (at least with some dec-20's) run finger with a null argument and get a list of every user (not just those logged in). It is generally agreed that keeping user names secret is not a reasonable thing to do -- that's what passwords are for. 29-Jun-83 15:46:06-PDT,1256;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 29 Jun 83 15:42:09-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 29 Jun 83 18:06 EDT Date: 29 Jun 1983 1745-EDT From: Greg Skinner Subject: MSGGROUP#2117 Re: Security Problem? To: greep@su-dsn cc: ron@brl, msggroup@brl, unix-wizards@brl In-Reply-To: Your message of 29-Jun-83 1703-EDT There is another way to hack user logins -- just wander around the Arpanet looking for a user named "smith" or "jones" who has an account with no password. I know instances of this happening with Unix machines -- in fact, when the TCP/IP switchover took place the users on our internet vaxes were required to give themselves passwords, or a password was chosen for them different from their name. Actually, if the host has a finger server, you could try all logged-in users looking for a non-password account. Also, some users stupidly have login and password names the same. This happens often when accounts are newly created and the user is not present at the creation time. The operator makes the username and password names the same. As far as I know, non-password accounts are allowed on Unix, and not on TOPS-20. --greg ------- 29-Jun-83 17:59:19-PDT,900;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 29 Jun 83 17:58:43-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 29 Jun 83 20:02 EDT Received: From Su-Score.ARPA by BRL-BMD via smtp; 29 Jun 83 19:57 EDT Date: 28 Jun 83 23:17:08-PDT Tue From: Mark Crispin Subject: MSGGROUP#2118 Re: Security Problem? To: ron@BRL-BMD.ARPA cc: tcp-ip@BRL-BMD.ARPA, unix-wizards@BRL-BMD.ARPA, msggroup@BRL-BMD.ARPA In-Reply-To: Message from "Ron Natalie " of Tue 28 Jun 83 20:35:39-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) One thing you could do would be to not validate mailboxes in the SMTP server, but that only delays the error message unless you "black hole" mail to invalid mailboxes. It's a trade-off between security and friendliness. ------- 29-Jun-83 19:13:32-PDT,1801;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 29 Jun 83 19:10:47-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 29 Jun 83 20:56 EDT Date: 28 Jun 1983 2357-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2119 Re: Security Problem? From: Einar Stefferud Reply-To: MsgGroup@brl To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd Message-ID: <[USC-ECL]28-Jun-83 23:57:39.ESTEFFERUD> In-Reply-To: Your message of Tue, 28 Jun 83 21:45:37 EDT I can see how you connect this question to MsgGroup because of the involvement of SMTP, or mailing lists. But, of course there are lots of other non-mail ways to get login names on most any host. So, I don't think this is a mail system issue after all, beyond your accurate initial observations. So, rather than trying to shut down the ability to extract login names from mail servers, I think attention should be focused on other security techniques. Like, making the penalty higher for failing to login correctly, and making the user start over at the beginning of the whole process when an error occurs before completion. One thing to do is force a delay following any failure, like an extra 5 or 10 seconds, which slows down the hacking rate to less than 6 tries per minute. Then, I think that too many failures in a row should cause a disconnect, which further slows down serious password hackers. Seems to me that it is too easy to put obstacles in the way to let ourselves get sidetracked into trying to conceal names. Whither goest the whole idea of name-servers if we try to close the mail gap? So, lets just chase this issue back to the other lists, unless a more genuine mail connection can be conjured up. Cheers - Stef 30-Jun-83 21:33:23-PDT,713;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 30 Jun 83 21:29:06-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 30 Jun 83 23:26 EDT Date: 30 June 1983 23:25 EDT From: Steve Kudlak Subject: MSGGROUP#2120 Security Problem? To: EE.GDS@mit-oz cc: msggroup@brl, ron@brl, unix-wizards@brl, greep@su-dsn In-reply-to: Msg of 29 Jun 1983 1745-EDT from Greg Skinner There are lots of hacks like this one. The legendary, excuse the language, <>. Guessing female names is supposedly good on some sites, and some commercial places whose names will remain unmetioned have WHEELED accounts that still have the DEFAULT DEC PASSWORD. 1-Jul-83 04:27:46-PDT,698;000000000001 Return-path: <@UCL-CS:steve@ucl-cs> Received: from BRL by USC-ECLC; Fri 1 Jul 83 04:23:35-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 1 Jul 83 5:53 EDT Received: From Ucl-Cs.ARPA by BRL-BMD via smtp; 1 Jul 83 5:37 EDT Via: 44a.AC-UK; to UCL-CS.AC-UK (44b) over Inter-UNIX with NIFTP; 1 Jul 83 10:01 BST Date: 1 Jul 83 9:54:49 BST (Fri) From: Steve Kille To: greep@su-dsn cc: Ron Natalie , tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd Subject: MSGGROUP#2121 Re: Security Problem? There seems to be a definite argument here for separating login name and mail address (as happens on some sites I know of). Steve 6-Jul-83 09:30:16-PDT,782;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 6 Jul 83 09:28:24-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 6 Jul 83 11:21 EDT Received: From Ucb-Vax.ARPA by BRL-BMD via smtp; 6 Jul 83 11:10 EDT Received: by UCBVAX.ARPA (3.346/3.33) id AA18898; 6 Jul 83 08:10:01 PDT (Wed) From: Steven M. Bellovin Message-Id: <8307061510.AA18898@UCBVAX.ARPA> Date: 6 Jul 83 11:07:36 EDT (Wed) Subject: MSGGROUP#2122 mail systems To: MsgGroup@brl-bmd I'm interested in information about high-end mail systems, especially for mouse-based, multiwindow systems. Any pointers to papers, technical reports, etc., would be appreciated. --Steve Bellovin ulysses!smb@Berkeley Bell Labs, Murray Hill 201-582-5886 6-Jul-83 11:45:16-PDT,760;000000000001 Return-path: <@USC-ISIF:POSTEL@usc-isif> Received: from BRL by USC-ECLC; Wed 6 Jul 83 11:43:55-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 6 Jul 83 13:47 EDT Received: From Usc-Isif.ARPA by BRL-BMD via smtp; 6 Jul 83 13:18 EDT Date: 6 Jul 1983 1016-PDT From: POSTEL@usc-isif Subject: MSGGROUP#2123 Re: mail systems To: ulysses!smb@berkeley, MsgGroup@brl-bmd cc: POSTEL@usc-isif In response to the message sent 6 Jul 83 11:07:36 EDT (Wed) from ulysses!smb@berkeley Steve: You should try to find out about NLS (particularly the NLS Journal) (oh, NLS is now called AUGMENT and sold as a service by TYMSHARE), LAURAL (a mail system at XEROX PARC on ALTOs), and possibly the mail features of the XEROX STAR. --jon. ------- 7-Jul-83 17:32:28-PDT,787;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 7 Jul 83 17:30:21-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 7 Jul 83 20:06 EDT Date: 7 Jul 83 19:59:34 EDT Thu From: Ron Natalie To: msggroup@brl-bmd Subject: MSGGROUP#2124 OFFICE-10 I am Info-Micro-Request and this information has been referred to me by Frank Wancho (FJW@MC). This is probably of use to most mail maintainers: Office-10 is now rejecting any new mail in preparation for the move to STL-HOST1. I am informed that most of the directories have been crated on STL-HOST1, so mail can be sent to "directory@STL-HOST1" instead. STL-HOST1 will be down part of the weekend but will be back up by next week. Office-10 will be going down at 2PM PDT Thursday. -Ron 8-Jul-83 01:50:24-PDT,626;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 8 Jul 83 01:48:47-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jul 83 3:17 EDT Received: From Office-2.ARPA by BRL-BMD via smtp; 8 Jul 83 3:18 EDT Date: 8-Jul-83 00:16 PDT From: WBD.TYM@office-2 Subject: MSGGROUP#2125 Re: OFFICE-10 To: Ron Natalie Cc: msggroup@brl-bmd Message-ID: <[OFFICE-2]TYM-WBD-2R1RX> In-reply-to: EXT-ron-2R15I I believe that OFFICE-10 will be forwarding mail for the next month. This should start happening when OFFICE-10 is brought back up by our SYSTEMS people. --Bill Daul TYMSHARE INC. 8-Jul-83 15:04:17-PDT,457;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 8 Jul 83 15:03:18-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jul 83 17:13 EDT Date: 8 Jul 83 17:08:05 EDT Fri From: Ron Natalie To: WBD.TYM@office-2 cc: Ron Natalie , msggroup@brl-bmd Subject: MSGGROUP#2126 Re: OFFICE-10 I'm sorry, but you are wrong. All mail that I have sent to OFFICE-10 for the last few days have been returned. -Ron 10-Jul-83 13:29:11-PDT,2617;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 10 Jul 83 13:25:42-PDT Received: From Office-2.ARPA by BRL via smtp; 10 Jul 83 16:04 EDT Date: 10-Jul-83 13:04 PDT From: WWB.TYM@office-2 Subject: MSGGROUP#2127 STL-HOST1 and OFFICE-10 To: msggroup@brl Message-ID: <[OFFICE-2]TYM-WWB-2R7E2> Here is a statement of the status of mail users on STL-HOST1 and OFFICE-10, as requested by Ron Natalie. The mailboxes are really on STL-HOST1 now, but that host has not "officially" begun service. It is scheduled to do so Monday morning, July 11. It has already been up and receiving at times, but not continuously. OFFICE-10 service was discontinued for those mail users on Thursday, July 7 at 1400 PDT. The host still exists and will provide *backup* mailforwarding until July 31 ONLY. This service is provided primarily to keep services that truly NEED it, such as the automatic LIF query/response system (LCAQ), in a happy state until they naturally learn to talk to STL-HOST1 instead. Buffering all this mail has proven to be a problem. When final delivery can't proceed fast enough to keep up (when STL was not up, or the network flaked out, or LCAQ dumped in giant heaps of mail, or while we halted delivery Wednesday/Thursday for testing/installation of the new identification database), I've seen backlogs of several thousand messages choking the filesystem. Then Of10 gets crabby and either won't talk to you, or puts out rarely seen (but correct) SMTP refusal responses such as 451 and 452. What any site's SMTP sender chooses to do about such a response is up to them, and may possibly show up as a failure note returned to the message originator. Also, when certain directory overflow conditions happen on Of10 and the mailer cannot make forward progress, a failure note may be returned from Office-10 saying "unknown major trouble processing item". This is not really a permanent failure; it is correctable by (my) human intervention after the crisis passes, and the mail starts moving again. Anyway, the best thing for everyone "out there" to do is to send mail to STL-HOST1 instead of OFFICE-10. The users should already have told their known correspondents about the switch (which has been in the works for a long time), but apparently in many cases they didn't. But ready or not, the switch is happening, so it would undoubtedly be a great help if mail senders in general, and list maintainers in particular, just went ahead and changed all mailbox@OFFICE-10 to mailbox@STL-HOST1. --Bill Barns 28-Jul-83 14:58:49-PDT,2649;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Jul 83 14:57:39-PDT Received: From Office-3.ARPA by BRL via smtp; 28 Jul 83 16:28 EDT Date: 28 Jul 1983 1327-PDT Sender: WMARTIN@office-3 Subject: MSGGROUP#2128 "Universal" message system(s) From: Will Martin To: msggroup@brl Message-ID: <[OFFICE-3]28-Jul-83 13:27:22.WMARTIN> I do a lot of FTPing of archived collections of messages from various hosts with varied flavors of operating systems. It would be handy if there was some sort of "universal" message-reading and -processing program that could read any sort of message-file, whether it originated on a TENEX/TOPS-20 host, a UNIX machine, the ITS systems from MIT. (Are there any other basic types of message-files?) I envision something relatively simple, like MSG in terms of the user interface, though that isn't vital. The important thing is that it would be able to look at a message-file and divide it up into the individual component messages, regardless of whether each message begins with the special TENEX/TOPS-20 data line, or the funny characters between messages on ITS, or however UNIX mailsystems determine where one message starts and another ends. It might be too much to ask for automatic recognition of the format of message files; I would be happy to tell the program, when calling it or when directing its attention to a particular message-file, what style of messages it is to look for. Current message systems I have used all expect the particular message-file format of their own environments, of course. The usual result of trying to read another style of message-file is that the process either doesn't recognize the file as being comprised of messages at all, or thinks it is one huge message. This forces the reader to step through the file with an editor or just print it out as a whole. What we need is to be able to scan the file and look at fields within messages (like with Hermes Survey or MSG Header commands) and to easily extract individual messages. Ideally, this "universal" message-reading program would be able to read any format file, but would write the kind of file proper to the system on which it runs, so you could easily file or move messages from a foreign format to your host's proper format. We need versions of this kind of process that will run under TENEX (actually AUGUST on these Office-n hosts, I believe) and under UNIX (for future use when we move to UNIX ARPANET hosts); does anything like this exist now in either of these environments? Will Martin USArmy DARCOM ALMSA 28-Jul-83 16:27:55-PDT,822;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Jul 83 16:25:46-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 28 Jul 83 18:57 EDT Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.347/3.35) id AA09155; Thu, 28 Jul 83 15:55:46 PDT Received: from UCBINGRES.ARPA by UCBARPA.ARPA (3.347/3.37) id AA16250; Thu, 28 Jul 83 15:57:22 PDT Date: 28 Jul 83 15:56:01 PDT (Thu) From: Joe Kalash Subject: MSGGROUP#2129 Please delete the account "fogg" from your lists, Message-Id: <8307282256.AA10344@UCBINGRES.ARPA> Received: by UCBINGRES.ARPA (3.320/3.7) id AA10344; 28 Jul 83 15:56:01 PDT (Thu) To: editor-people@su-score, msggroup@brl He has been gone for over a year, and I just noticed he has a HUGH backlog of mail here. Thanks, Joe Kalash 28-Jul-83 19:45:22-PDT,670;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Jul 83 19:41:45-PDT Received: From Office-7.ARPA by BRL via smtp; 28 Jul 83 21:10 EDT Date: 28 Jul 1983 1807-PDT From: King@office-7 Subject: MSGGROUP#2130 Re: Please delete the account "fogg" from your lists, To: kalash%UCBINGRES@berkeley, editor-people@su-score To: msggroup@brl cc: KING@BRL.ARPA In response to the message sent 28 Jul 83 15:56:01 PDT (Thu) from kalash%UCBINGRES@berkeley Just to emphasize your "error in protocol", I'm going to respond the same way you did. I don't really care that "fogg" has a "HUGH" backlog of mail there. Bill King ------- 28-Jul-83 20:16:41-PDT,1218;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Jul 83 20:14:04-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 28 Jul 83 22:35 EDT Date: 28 Jul 1983 1749-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2131 Re: "Universal" message system(s) From: ESTEFFERUD@usc-ecl To: WMartin@office-3 Cc: msggroup@brl Message-ID: <[USC-ECL]28-Jul-83 17:49:33.ESTEFFERUD> In-Reply-To: <[OFFICE-3]28-Jul-83 13:27:22.WMARTIN> [At UCI, I have been collecting old archives from time to time, and encountered the problem you describe. To solve it, one of my students wrote some simple programs to convert the different formats into UNIX MMDF/MSG format. From that we then converted to MH folder format with the standard MH inc(1) program for archiving on tar tapes. Some of the conversion programs were written in cshell script. I will try to find the source code of these and mail them to you to use with your UNIX. As for TWenex, I do not know of anything comparable, and I suspect that construction of similar solutions will not be trivial, but it should not be too hard if you pattern them after the UNIX filters I will send to you, if I find them. Good luck - Stef 28-Jul-83 22:33:45-PDT,639;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Jul 83 22:33:22-PDT Received: From Rand-Unix.ARPA by BRL via smtp; 29 Jul 83 0:48 EDT Date: 28 Jul 1983 21:28-PDT Thursday To: Will Martin Cc: msggroup@brl Subject: MSGGROUP#2132 Re: "Universal" message system(s) In-reply-to: Your message of 28 Jul 1983 1327-PDT. <[OFFICE-3]28-Jul-83 13:27:22.WMARTIN> From: guyton@rand-unix I wrote a simple hack to split twenex style msg files into Unix MH style msgs. I've used it on the unix-wizard archives and it seems to work ok. Let me know if you'd like it. -- Jim 28-Jul-83 23:24:28-PDT,1238;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 8 Jul 83 23:18:38-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 29 Jul 83 1:54 EDT Date: 28 Jul 1983 2247-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2133 HALT!!!!!! Re: Please delete the account "fogg" ... From: Einar Stefferud (MsgGroup Moderator) Reply-To: msggroup-request@brl To: King@office-7 Cc: kalash%UCBINGRES@berkeley, editor-people@su-score Cc: msggroup@brl, KING@brl, msggroup-request@brl Message-ID: <[USC-ECL]28-Jul-83 22:47:00.ESTEFFERUD> In-Reply-To: Your message of 28 Jul 1983 1807-PDT STOP!!!! Sorry to bother the rest of you but I don't know any other way to reach the thoughtless and careless ones among us. Before anyone else commits the faux pas of mailing comments about address list problems to the whole mssgroup and editor-people list, please note that for MsgGroup such mail should only be sent to Msggroup-Request@BRL. I expect that a similar address "-request" is proper for Editor-People@SU-Score. In any case, is not proper to slop this stuff onto the regular main list recipients. I hope I have put it strongly enough to prevent any more such errors! Best - Stef 29-Jul-83 09:06:02-PDT,543;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 29 Jul 83 09:03:06-PDT Received: From Pica.ARPA by BRL via smtp; 29 Jul 83 9:33 EDT Date: 29 Jul 83 9:27:46 EDT Fri From: Bill Bolte To: Msggroup@brl cc: bolte@pica Subject: MSGGROUP#2134 Address Change Hi Stef - As you already know from Dave G., we (MISD at Dover) now have our own host on the NET. I would appreciate it if you could change my Msggroup mail address from 'Bolte@Office-8' to 'Bolte@Pica'. Thanks...Bill Bolte 1-Aug-83 14:17:39-PDT,776;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 1 Aug 83 14:13:30-PDT Received: From Office-3.ARPA by BRL via smtp; 1 Aug 83 16:03 EDT Date: 1 Aug 1983 1300-PDT Sender: WMARTIN@office-3 Subject: MSGGROUP#2135 Followup - "universal" message systems From: Will Martin To: Msggroup@brl Message-ID: <[OFFICE-3] 1-Aug-83 13:00:09.WMARTIN> Thanks to all those who sent me info and offers of help in response to my inquiry. Several pointed me to "BABYL", which should do most of what I want. Another even more versatile system is ZMAIL, which is available on Lispmachines. Some correspondents pointed out other mail-file formats I hadn't mentioned; these included VAX/VMS, Xerox, and RdMail. Regards, Will Martin 12-Aug-83 17:52:07-PDT,2419;000000000001 Return-path: <@USC-ISIF:WESTINE@USC-ISIF> Received: from USC-ISIF by USC-ECLC; Fri 12 Aug 83 17:47:12-PDT Date: 12 Aug 1983 16:49:50 PDT From: WESTINE@USC-ISIF Subject: MSGGROUP#2136 RFC 871-875 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. These five RFCs by M. A. Padlipsky discuss the ARPA protocol family and clarify the differences between it and the ISO Reference Model. These memos were issued as Technical Reports by the Mitre Corporation in September 1982. The purpose of these five RFCs is to present information on the concepts underlying the ARPA protocols and to promote discussion of protocol design issues. RFC 871: Title: A Perspective on the Arpanet Reference Model Author: M. Padlipsky Pages : 25 pathname: [SRI-NIC]RFC871.TXT This memo describes the development of the ARPA protocols, and compares and contrasts the ARPA protocol reference model with the ISO Reference Model. RFC 872: Title: TCP-ON-A-LAN Author: M. Padlipsky Pages : 8 pathname: [SRI-NIC]RFC872.TXT This memo discusses the use of TCP on a local area network. RFC 873: Title: The Illusion of Vendor Support Author: M. Padlipsky Pages : 8 pathname: [SRI-NIC]RFC873.TXT This memo argues that vendor supplied software for computer networking based on the ISO Reference Model is not worth waiting for, especially in light of the existing ARPA family of protocols. RFC 874: Title: A Critique of X.25 Author: M. Padlipsky Pages : 13 pathname: [SRI-NIC]RFC874.TXT This memo is a discussion of the CCITT X.25 protocol and its attendant conceptual framework, the ISO Reference Model. RFC 875: Title: Gateways, Architectures, and Heffalumps Author: M. Padlipsky Pages : 8 pathname: [SRI-NIC]RFC866.TXT This memo discusses Gateways and Protocol Translation. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 16-Aug-83 00:24:44-PDT,3429;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 16 Aug 83 00:21:31-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 16 Aug 83 2:51 EDT Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 15 Aug 83 23:49:44 PDT Via: 44a.Ucl-Cs.AC.UK; to 44b.Ucl-Cs.AC.UK over Inter-UNIX with NIFTP; 16 Aug 83 7:43 BST Date: 16 Aug 83 7:33:44 BST (Tue) From: Steve Kille Reply-To: hsmith@ucl-cs To: msggroup@mit-mc.arpa, mailgroup@ucl-cs cc: hsmith@ucl-cs Subject: MSGGROUP#2137 IFIP WG 6.5 Conference IFIP 6.5 INTERNATIONAL WORKING CONFERENCE on COMPUTER-BASED MESSAGE SERVICES 1st - 4th May, 1984 NOTTINGHAM, UK CALL FOR PAPERS Programme The purpose of the conference is to provide an international forum for the exchange of information on the technical, economic, and social impacts of computer messaging systems and services. The conference format will be two days of conference paper presentations followed by two days of workshops. Papers are desired in the following topic areas: System design Hardware/Software implementations Voice messaging Naming/Addressing Issues Multi-Media systems Message System Performance Teletex Security, Reliability Cost/Benefit Issues International Regulation Computer Conferencing User Interface Factors Directory Services Messaging for developing countries Office System design Social impacts Systems for special needs (e.g., the handicapped) Instructions to Authors Prospective authors are invited to submit for review unpublished original contributions (not exceeding 5000 words) which describe recent developments on any design or service aspect of computer message systems. Accepted papers will appear in the Conference Proceedings pub- lished by North Holland. Deadlines Today Contact the address below (or a committee member) stating your intention to submit a paper or general interest in the conference. 25 November 1983 Draft Versions of papers required 25 January 1984 Notification of Acceptance 30 February 1984 Camera-ready papers required Papers should be submitted to H.T. Smith Human-Computer Interaction Group Nottingham University Nottingham NG7 2RD United Kingdom Tel: +44 602 56101 x3193 Telex: 37346 UNINOT G Net: hsmith@ucl-cs Provisional Programme Committee A. Danthine Belgium J. Garcia-Luna Mexico P. Kirstein United Kingdom E. Lillevold Norway R. Miller United States N. Naffah France G. Neufeld Canada J. Palme Sweden S. Ramani India P. Schicker Switzerland L. Tarouco Brazil J. White United States K. Wimmer Germany Federal Republic Organising Committee H.T. Smith Nottingham University, United Kingdom W. Dzida GMD, German Federal Republic R. Uhlig Bell Northern Research, Ottawa, Canada 25-Aug-83 14:32:34-PDT,2683;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 25 Aug 83 14:32:10-PDT Received: From Ucla-Locus.ARPA by BRL via smtp; 25 Aug 83 16:37 EDT Date: 25 Aug 83 13:29:48 PDT (Thu) From: Rich Wales To: Craig M. Rogers CC: Action@usc-isi, Bug-MAISER@su-score, HEDRICK@rutgers CC: MsgGroup@brl Subject: MSGGROUP#2138 ISI-VAXA's SMTP sender doesn't say HELO Craig -- Hi. I am Rich Wales, the UCLA Computer Science Department's mail guru. I may have mentioned the following to you some time ago, but since the problem apparently still exists . . . . There seems to be a bug in the ISI-VAXA SMTP sender program; namely, it doesn't start each transaction with a HELO command. The following is a log of a recent connection between ISI-VAXA and UCLA-LOCUS: 220 UCLA-LOCUS SMTP Server ready; Thu, 25 Aug 83 10:15:05 PDT === mail from: 250 MAIL: OK, even though you forgot to say HELO first === rcpt to: 250 RCPT: OK === data 354 Enter message === [13 lines of message text] === . 250 Message accepted === quit 221 UCLA-LOCUS SMTP Server exiting; Thu, 25 Aug 83 10:15:21 PDT While I admit that RFC821 may not be 100% clear on the issue of whether the HELO is mandatory (and many SMTP servers, including our own, do not require the sender to say HELO), there are quite a few SMTP's around which will reject a MAIL command (with a 503 reply code) unless a HELO comes first. Based on tests I ran this morning, here is a partial list of hosts who appear to insist on being HELO'ed before accepting mail: BBNA BBNG CMU-CS-C DEC-MARLBORO HI-MULTICS MIT-MC MIT-ML OFFICE-3 RADC-TOPS20 RUTGERS SANDIA SRI-AI SU-SCORE SUMEX-AIM SRI-KL SRI-NIC USC-ECL USC-ECLB USC-ECLC UTAH-20 UTEXAS-20 WASHINGTON Note particularly, by the way, that SRI-NIC is on the above list. The "fix" to your SMTP sender program to have it send a HELO and gobble up the "250" reply shouldn't really be too big (if it's more than about 10 lines I would be amazed). My personal opinion, by the way, is that the other hosts ought to fix their SMTP's so as not to demand a HELO -- in keeping with the oft- stated axiom that you should be conservative in what you send out and liberal in what you accept. The pragmatic facts of life, however, are that you can modify your code a lot faster than 22 other people will modify theirs. -- Rich Wales 25-Aug-83 15:52:57-PDT,1132;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 25 Aug 83 15:48:36-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 25 Aug 83 18:11 EDT Date: 25 Aug 1983 1507-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2139 Re: ISI-VAXA's SMTP sender doesn't say HELO From: ESTEFFERUD@usc-ecl To: wales@ucla-locus Cc: ROGERS@usc-isib, Action@usc-isi Cc: Bug-MAISER@su-score, HEDRICK@rutgers, MsgGroup@brl Cc: header-people@mit-mc Message-ID: <[USC-ECL]25-Aug-83 15:07:07.ESTEFFERUD> In-Reply-To: Your message of Thu, 25 Aug 83 13:29:48 PDT Hi Rich - I appreciate your intent in sending your message to MsgGroup, but I suspect that most of our members are not the right folks to help you. I would expect Header-People to be the better forum for oprational SMPT problems, so I suggest that you shift to that group for future discussion. I will redistribute your message to Header-People, in spite of the large overlap with MsgGroup, with the hope that the discussion will totally shift to the other list. I wish you the best in solving the problems! Stef (MsgGroup Moderator) 25-Aug-83 16:22:38-PDT,3577;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 25 Aug 83 16:18:58-PDT Received: From Su-Score.ARPA by BRL via smtp; 25 Aug 83 18:32 EDT Date: 25 Aug 83 15:27:51-PDT (Thu) From: Mark Crispin Subject: MSGGROUP#2140 Re: ISI-VAXA's SMTP sender doesn't say HELO To: wales@UCLA-LOCUS.ARPA cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, MsgGroup@BRL.ARPA In-Reply-To: Message from "Rich Wales " of Thu 25 Aug 83 13:36:38-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Sigh. Another round in the "lets make our protocols simpler to accomodate the quick and dirty implementations" battle. According to section 3.5 of RFC821, "at the time the transmission channel is opened there is an exchange" and "the following...are used in transmission channel opening and closing...HELO...QUIT". That implies to me that HELO is not optional. I'll conceed that 503 isn't listed as a reply code to MAIL, but I would consider that a bogosity in the reply codes list. HELO serves a purpose. That purpose is voided if it isn't used. I would rather mandate a change in a single SMTP user process than force an unknown number of present and future SMTP server processes to be changed. We have a desirable situation now. Despite the ambiguity in RFC821, the de facto situation is that HELO is required. An SMTP user that doesn't send HELO is going to have a lot of hassle getting its mail out. Let's not break a good thing! I cannot believe that a straightforward protocol such as SMTP has gotten corrupted by various short-cut implementations. Isn't it enough that from time to time we are expected to tolerate host-less arguments to MAIL and RCPT, or pre-RFC821 syntax for source routing? In the principle of being "liberal in what you accept", let's make MAIL optional too. It should be the default. While we're at it, why require RCPT? We can just accept DATA and parse the header. Another example of the flaw in the "be conservative/be liberal" argument is in SMTP data flow. For a shocking number of hosts, an SMTP transaction will not work in a message of non-trivial size unless the SMTP user process periodically sets Push in its segments, completely independently of where Push is actually required. A subset of those hosts also fail if you send segments larger than 50 bytes or so. The TOPS-20 SMTP user process used to do all of its TCP transitions in 40 byte Pushed segments. The problem was, that gronked our UK friends at the other end of SATNET. Today, it does normal TCP I/O, and reverts into the Pushed minigram mode if the connection times out (taking more than 2 minutes to output 1000 bytes) or if the connection dies unexpectedly. When it does so it prepends a message (the infamous "Delivery-Notice" message some of you may have seen) suggesting that maybe the receiver's TCP ought to be fixed. Certain mailers across the Internet have discovered that the TOPS-20 mailer has the feature of being able to talk to the broken hosts; Score gets a lot of third-party traffic this way. Also, every so often an innocent host gets sent to in the minigram mode (and gets the obnoxious Delivery-Notice). In a few weeks it will only do normal TCP I/O, when I cut over to the DEC TCP/IP interface. After all, people have had 9 months to get their TCPs working. -- Mark -- ------- 26-Aug-83 03:24:02-PDT,816;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 03:21:39-PDT Received: From Sri-Nic.ARPA by BRL via smtp; 26 Aug 83 5:57 EDT Date: 26 Aug 83 02:51:28-PDT (Fri) From: Henry W. Miller Subject: MSGGROUP#2141 Re: ISI-VAXA's SMTP sender doesn't say HELO To: MRC@SU-SCORE.ARPA, wales@UCLA-LOCUS.ARPA cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, MsgGroup@BRL.ARPA, Miller@SRI-NIC.ARPA In-Reply-To: Message from "Mark Crispin " of Thu 25 Aug 83 23:18:45-PDT Mark, Actually, I think the idea of ttaking RCPT out is a bit extreme... But seriously, I agree. The spec is there; it has been "agreed" on. If they don't want to play ball our way, well, it's our bat and our ball, and... -HWM ------- 26-Aug-83 07:39:25-PDT,1359;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 07:35:06-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 26 Aug 83 9:01 EDT Date: 26 Aug 83 8:40:13 EDT (Fri) From: Mike Muuss To: Postmaster@mit-multics cc: MsgGroup@brl Subject: MSGGROUP#2142 Errors returned under separate cover? AAARRRRRGGGHH!!! Not again!!!! Please fix this! It is INCREDIBLY PAINFUL for Multics to insist on returning the bad mail in a separate message. It makes it impossible to delete using any reasonable pattern matching. Not unreasonable if only 1 message is being returned, but really awful when dozens or hundreds of them come flying back in my face! I assert that it is not good style to return errors back under separate cover, and doubly so without even tacking on some header line to give a clue (other than Received:). -Mike ----- Forwarded message # 1: Received: From Mit-Multics.ARPA by BRL-VGR via smtp; 24 Aug 83 8:21 EDT From: Network_Server.Daemon at MIT-MULTICS.ARPA Subject: Unable to deliver mail from unix-wizards-request@BRL-VGR.ARPA@BRL-VGR Message will be returned under separate cover. To: ">udd>Unix>mtgs>Unix-Wizards.control" at SYSTEM-M.PHOENIX.HONEYWELL: Some directory in path specified does not exist. ----- End of forwarded messages 26-Aug-83 08:24:06-PDT,1384;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 08:22:17-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 26 Aug 83 9:48 EDT Date: 26 August 1983 08:43 cdt From: Stachour.CSCswtec@hi-multics Subject: MSGGROUP#2143 Re: ISI-VAXA's SMTP sender doesn't say HELO To: Henry W. Miller cc: MRC@su-score, wales@ucla-locus, ROGERS@usc-isib, Action@usc-isi, HEDRICK@rutgers, MsgGroup@brl In-Reply-To: Message of 26 August 1983 07:28 cdt from Henry W. Miller When I use a mail-system, one of the most common this I do is 'Reply', just as I'm doing now. I expect my mailer to be able to send a response to anyone who can send a msg to me (I hope that's not expecting too much). IF my mailer does not demand a HELO when recieving via SMTP, then it's very easy to get a msg that turns out to be non-replyable automatically, and not even a good "RECEIVED" header for me to try and figure it out manually. Yes, I know that a mailer can 'lie' about who it is, and most SMTP implementations will accept the 'lie'. However, that at least enables me to get a msg back to someone who can disclaim resposibility for the orginal send, something not even possible without a HELO. In short, I think a mailer NOT sending HELO is not only against the RFC, it's not a good way to use a protocol. ...Paul 26-Aug-83 08:44:06-PDT,764;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 08:41:19-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 26 Aug 83 10:14 EDT Date: 26 August 1983 09:13 est From: DBrown.TSDC@hi-multics Subject: MSGGROUP#2144 Re: ISI-VAXA's SMTP sender doesn't say HELO To: MsgGroup@brl I hope the comment about taking your bat and ball was humor... Seriously, if a program expects a certain protocol and doesn't need it, then there's ane error in defining the protocol. If one *needs* the protocol but is capable of surviving misuse of it in known special cases then the best tack is to send lots of messages (in this case mail) to the person/thing which isn't meeting the spec. Or even to this forum.... --dave 26-Aug-83 11:04:09-PDT,1380;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 11:01:08-PDT Received: From Wisc-Crys.ARPA by BRL via smtp; 26 Aug 83 12:40 EDT Date: 26 Aug 1983 11:14:56-CDT From: Marvin Solomon Reply-to: solomon@uwisc To: MsgGroup@brl Subject: MSGGROUP#2145 Re: ISI-VAXA's SMTP sender doesn't say HELO Not requiring the HELO is definitely a violation of spec and should therefore be strongly discouraged, but what is a server SMTP supposed to do with the info? Specifically, what should it do if: The name given isn't in the host tables? The name is in the host tables, but doesn't correspond to the address at the other end of the TCP connection A "MAIL FROM:" command is issued during the course of the session with a return path that does not indicate the named host as the first step? In general, the various Internet specs are good on indicating what correct behavior is, but quite weak on telling you what to do in response to errors. Obviously, not all possible errors can be anticipated, but a few of the more likely ones should be mentioned. P.S. Does this discussion belong in MsgGroup or HeaderPeople? I can never keep straight the difference. I have the feeling there is a large overlap in membership. In fact the lists may be nearly identical. If so, perhaps they should be merged? 26-Aug-83 13:39:10-PDT,2468;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 26 Aug 83 13:37:25-PDT Received: From Su-Score.ARPA by BRL via smtp; 26 Aug 83 15:06 EDT Date: 26 Aug 83 12:06:08-PDT (Fri) From: Mark Crispin Subject: MSGGROUP#2146 Re: ISI-VAXA's SMTP sender doesn't say HELO To: solomon@UWISC.ARPA cc: MsgGroup@BRL.ARPA In-Reply-To: Message from "Marvin Solomon " of Fri 26 Aug 83 09:14:56-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Re: What to do if: Q: The name given in HELO isn't in the host table? A: 1. Accept the HELO, perhaps adding "never heard of you". 2. Note that in the Received line, perhaps by putting the name we think that host has (or the dotted form if unknown) in a comment. 3. * If the host was unknown, add it to the host table dynamically. Q: The name is in the host tables, but doesn't correspond to the address? A: 1a. * Reject the HELO, perhaps notifying the local postmaster. 1b. Accept the HELO, perhaps adding something like "you are a charlatan". 2b. Note that in the Received line as in the not in host table case. 3b. * Notify the postmaster. Q: What to do if MAIL FROM's host doesn't match the HELO host? A: This is okay. The message may have been relayed. Officially the dialog should be: HELO host1 MAIL FROM:<@host1:user@host2> but since source routing is almost useless except for debugging (because all host names must be Internet!) there isn't much of a reason not to accept: MAIL FROM: instead. The TOPS-20 SMTP server ignores the source route except for the purposes of building a Return-Path. In that case, it will properly prepend its local name and pass it to the next host. The behavior of the TOPS-20 SMTP server is all of the UNSTARRED items above. I'd eventually like to do dynamic addition of unknown hosts to the naming registry. I'm uncertain of the wisdom of rejecting mismatched HELOs. Hosts do change their addresses faster than the NIC can update them, and since NIC is a TOPS-20 these days I wouldn't want them cut off from receiving mail from a host announcing its update! I think if I ever reject HELOs it would be only in the case of a mail loop; in other words if I receive a HELO with my own host name THEN I should validate the address. -- Mark -- ------- 27-Aug-83 01:28:00-PDT,2153;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 27 Aug 83 01:23:08-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 27 Aug 83 4:00 EDT Date: 27 Aug 1983 0057-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2147 Please honor on my request! From: ESTEFFERUD@usc-ecl To: MsgGroup: Message-ID: <[USC-ECL]27-Aug-83 00:57:48.ESTEFFERUD> On Aug 15, 1983, at 1507-PDT, I requested that the dicsussion of HELO be shifted to Header-peple where such discussions of operational problems normally belongs. I have redistributed all mail on this topic to Header-people, and I still expect you all to honor my request, or to at least privately explain to me why you think I am wrong in my request so I might have some reason to rescind it. To date, I have not received and comments whatever, pro or con, but I do note that some contributors (identified below) have roundly ignored my request and have even reduced their addressee TO: MsgGroup. Did you all not see my request? I have continued to redistribute each item on this HELO topic to Header-People, knowing that many of you are on the both lists. If any of you are upset about this duplication, please direct your comments to those contributors who have ignored my request. If you have comments about how I am trying to moderate MsgGroup, please send them to me privately. Thanks much for your patience! Stef *** SURVEY of HELO items to MsgGroup on the day after my request: Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO 1554 chars 26 August 1983 08:43 cdt From: Stachour.CSCswtec@hi-multic Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO 928 chars 26 August 1983 09:13 est From: DBrown.TSDC@hi-multics To: Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO 1533 chars 26 Aug 1983 11:14:56-CDT From: Marvin Solomon Received: from BRL by USC-ECLC; Sat 27 Aug 83 06:20:55-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 27 Aug 83 9:01 EDT Date: 27 Aug 1983 0851-EDT From: Greg Skinner Subject: MSGGROUP#2148 Re: ISI-VAXA's SMTP sender doesn't say HELO To: Stachour.CSCswtec@hi-multics cc: mrc@su-score, hedrick@rutgers, msgroup%MIT-OZ@mit-mc, wales@ucla-security, action@usc-isi, rogers@usc-isib In-Reply-To: Your message of 26-Aug-83 0843-EDT Return-path: Received: From Hi-Multics.ARPA by BRL via smtp; 26 Aug 83 9:48 EDT Date: 26 August 1983 08:43 cdt From: Stachour.CSCswtec@hi-multics Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: Henry W. Miller cc: MRC@su-score, wales@ucla-locus, ROGERS@usc-isib, Action@usc-isi, HEDRICK@rutgers, MsgGroup@brl In-Reply-To: Message of 26 August 1983 07:28 cdt from Henry W. Miller When I use a mail-system, one of the most common this I do is 'Reply', just as I'm doing now. I expect my mailer to be able to send a response to anyone who can send a msg to me (I hope that's not expecting too much). IF my mailer does not demand a HELO when recieving via SMTP, then it's very easy to get a msg that turns out to be non-replyable automatically, and not even a good "RECEIVED" header for me to try and figure it out manually. Yes, I know that a mailer can 'lie' about who it is, and most SMTP implementations will accept the 'lie'. However, that at least enables me to get a msg back to someone who can disclaim resposibility for the orginal send, something not even possible without a HELO. In short, I think a mailer NOT sending HELO is not only against the RFC, it's not a good way to use a protocol. ...Paul I agree with that. In a recent edition of this distribution list, I tried to reply to a msg that came from RU-GREEN, but OZ is not on the arpanet yet (!!) and can't figure the path back to there. I thought it might use the Return-path and have BRL figure out the path from it to RU-GREEN, but instead the mailer refused to send the reply, claiming "No path to site". greg ------- 27-Aug-83 08:38:07-PDT,979;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 27 Aug 83 08:38:03-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 27 Aug 83 11:21 EDT Date: 27 August 1983 10:17 est From: DBrown.TSDC@hi-multics Subject: MSGGROUP#2149 HELO from who????? To: MsgGroup@brl I would suggest that the smtp server not try to concern itself too much with validating names/systems, etc. It is very difficult to get a server to test your new host-table entry for site bar if you have to have a correct host-table entry for bar first. Besides, I have a system that can (and probably will) talk smtp and its NOT where i try to have mail sent. My return address is DBrown.TSDC @ HI-MULTICS.ARPA but my system is Daves_micro @ tsd1.toronto.honeywell (an alias for brown at tsd1...). Probably the best criteria is to regard smtp as a mail-transfer mechanism with optional audit trail, and not a mechanism for data-entry with verification. --dave 27-Aug-83 15:34:57-PDT,1562;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 27 Aug 83 15:30:29-PDT Received: From Mit-Multics.ARPA by BRL via smtp; 27 Aug 83 18:05 EDT Date: 27 August 1983 18:00 edt From: Jeffrey I. Schiller Subject: MSGGROUP#2150 Re: Errors returned under separate cover? To: ESTEFFERUD@usc-ecl cc: Mike Muuss , Postmaster@mit-multics, MsgGroup@brl Whether or not a message failure notification should include the text of the failed message, or return the message under separate cover, is a function of taste. You gentlemen don't appear to like it, but I could probably find several (or maybe even many) people who equally strongly object to having the text enclosed in the message (making it harder to forward in the event the error was due to a typo when the message was first sent etc...). As one of the people who works on the Multics network mailer, I don't particularly care which way it does it. HOWEVER AS Host Administrator and Technical Liaison for the network host MIT-Multics I am strongly offended at the tone and direct THREAT that your message contained. It is extremely childish to try to force other people to adopt their programs to your taste. If every person who developed code for the ArpaNet took the position that he wouldn't communicate with network hosts that didn't appeal to his taste, the network really would have fallen pretty flat on its face, do you want to start that now? -Jeff 27-Aug-83 15:34:57-PDT,7231;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 14 Sep 83 00:24:17-PDT Received: From Usc-Eclc.ARPA by BRL via smtp; 14 Sep 83 3:01 EDT Date: 27 August 1983 1200-PDT Subject: MSGGROUP#2151 SURVEY #2101-#2150 from MSGGROUP.2101-200.1 From: MsgGroup Moderator - Stefferud Reply-To: MsgGroup-Request@brl To: msggroup@eclc Remailed-date: 13 Sep 1983 2357-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup@brl Some of you may have missed some of these messages because of failed mail problems. You can FTP the whole file from [ECLC]msggroup.2101-2000.1, using FTP with LOGIN ANONYMOUS with Password MSGGROUP. I will remail requested items, with some delay for processing, if you will request them by reply mail to MsgGroup-Request@BRL. Please cite what you want by their specific Msggroup#nnnn identifiers, as shown. ======== MSGGROUP#2101 SURVEY #2051-#2100 from MSGGROUP.2001-2100.1 7168 chars 11 Jun 1983 1409-PDT From: MsgGroup Moderator - Stefferud T MSGGROUP#2115 Re: Security Problem? 1004 chars 29 Jun 1983 09:10-PDT From: the tty of Geoffrey S. Goodfello MSGGROUP#2116 Re: Security Problem? 1017 chars 29 Jun 1983 12:41-PDT Wednesday From: greep@su-dsn To: Ron N MSGGROUP#2117 Re: Security Problem? 1256 chars 29 Jun 1983 1745-EDT From: Greg Skinner To: E MSGGROUP#2121 Re: Security Problem? 698 chars 1 Jul 83 9:54:49 BST (Fri) From: Steve Kille MSGGROUP#2122 mail systems 782 chars 6 Jul 83 11:07:36 EDT (Wed) From: Steven M. Bellovin T MSGGROUP#2125 Re: OFFICE-10 626 chars 8-Jul-83 00:16 PDT From: WBD.TYM@office-2 To: Ron Natalie < MSGGROUP#2126 Re: OFFICE-10 457 chars 8 Jul 83 17:08:05 EDT Fri From: Ron Natalie T MSGGROUP#2127 STL-HOST1 and OFFICE-10 2617 chars 10-Jul-83 13:04 PDT From: WWB.TYM@office-2 To: msggroup@brl MSGGROUP#2128 "Universal" message system(s) 2649 chars 28 Jul 1983 1327-PDT From: Will Martin To MSGGROUP#2129 Please delete the account "fogg" from your lists, 822 chars 28 Jul 83 15:56:01 PDT (Thu) From: Joe Kalash To: MSGGROUP#2135 Followup - "universal" message systems 776 chars 1 Aug 1983 1300-PDT From: Will Martin To MSGGROUP#2136 RFC 871-875 Now Available 2419 chars 12 Aug 1983 16:49:50 PDT From: WESTINE@USC-ISIF To: Reques MSGGROUP#2137 IFIP WG 6.5 Conference 3429 chars 16 Aug 83 7:33:44 BST (Tue) From: Steve Kille MSGGROUP#2138 ISI-VAXA's SMTP sender doesn't say HELO 2683 chars 25 Aug 83 13:29:48 PDT (Thu) From: Rich Wales Received: from BRL by USC-ECLC; Sat 27 Aug 83 18:22:00-PDT Received: From Mit-Xx.ARPA by BRL via smtp; 27 Aug 83 20:59 EDT Received: from SCRC-BLACKSTONE by SCRC-SPANIEL with CHAOS; Sat 27-Aug-83 20:57:45-EDT Date: 27 August 1983, 20:57-EDT (Saturday) From: Robert W. Kerns Subject: MSGGROUP#2152 Re: Errors returned under separate cover? To: Jeffrey I. Schiller Cc: ESTEFFERUD@usc-ecl, Mike Muuss , Postmaster@mit-multics, MsgGroup@brl In-reply-to: The message of 27 Aug 83 18:00-EDT from Jeffrey I. Schiller Date: 27 August 1983 18:00 edt From: Jeffrey I. Schiller MsgGroup@brl Whether or not a message failure notification should include the text of the failed message, or return the message under separate cover, is a function of taste. You gentlemen don't appear to like it, but I could probably find several (or maybe even many) people who equally strongly object to having the text enclosed in the message (making it harder to forward in the event the error was due to a typo when the message was first sent etc...). As one of the people who works on the Multics network mailer, I don't particularly care which way it does it. If there was a standard format for encapsulating these returned messages, mail reading programs could handle remailing them with corrected addresses very simply. 28-Aug-83 22:03:09-PDT,3436;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 28 Aug 83 21:58:18-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 29 Aug 83 0:40 EDT Date: 28 Aug 1983 1657-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2153 Re: Errors returned under separate cover? From: ESTEFFERUD@usc-ecl To: Schiller@mit-multics Cc: Postmaster@mit-multics, MsgGroup@brl, mike@brl Message-ID: <[USC-ECL]28-Aug-83 16:57:29.ESTEFFERUD> In-Reply-To: Your message of 27 August 1983 18:00 edt Several things: First, my note to you was private, in that it was no sent to the whole of msggroup. It was sent to the follwong addresses: To: Postmaster@mit-multics Cc: mike@brl, MsgGroup-request@brl I do not apprecate your broadcasting your response to the whole group. Much of what is offensive about your new separate failed mail notice is that it is devoid of identifying information, other than the failed address, that would help me figure out what failed, and decide what to do about it, in each case. In my own situation, I have received about 100 failed mail notices in the last two days, due to various kinds of mail troubles around the net. I am thus moving towards a policy of simply removing all addresses that cause troublesome failed mail notices, such as those that are too frequent (as with UCL-CS these days), too hard to process (as with MIT-Multics these days), or due to carelessness of recipients (as when they let their accounts refuse mail due to being over allocation), to give you some examples. I do thank you for rsponding, though your response essentially tells me that nothing is to be changed, and that your position is not negotiable. I would hope that you will reconsider, and seek ways to make your failed mail notices more helpful. For the MsgGroup record, here is a sample of a complete message: Return-path: <@MIT-MC:Liaison@MIT-MULTICS> Received: from MIT-MC by USC-ECL; Sat 27 Aug 83 08:59:07-PDT From: Network_Server.Daemon at MIT-MULTICS.ARPA Subject: Unable to deliver mail from ESTEFFERUD@USC-ECL@MIT-MC Message will be returned under separate cover. To: Ruptash at SYSTEM-M.PHOENIX.HONEYWELL: Entry not found. Several things are important to note here: 1. The original was not TO: Ruptash@system-m,phoenix.honeywell ... It was to msggroup, or maybe it was to header-people. 2. The promised return of the original must have gone to someone else. It has not arrived in my mail with any identifiying marks that I can see to distinguish it from my other copy of the same mail item, assuming that I can tell which item is being referenced. 3. This notice does not tell who it was addressed to. In short, from my perspective, you can save us both a lot of time and trouble if you will just stop sending any notice at all. These notices only tell me that there is trouble somehere that I cannnot do anything about, without even telling me who it thinks I am. And then it forces me to search through my mail to see if I can find something to/cc/bcc/resent to ruptash or to/cc/bcc/resent to some list that included ruptash, or ... You did not even do me the favor of giving me a subject, or date/time, or ... Perhaps with this more complete bill of particulars, you can see that there is more to all this that just (good/bad) taste and style. Best regards - Stef 28-Aug-83 23:29:17-PDT,899;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 28 Aug 83 23:24:47-PDT Received: From Sri-Kl.ARPA by BRL via smtp; 29 Aug 83 2:05 EDT Date: 28 Aug 1983 22:12-PDT Sender: BILLW@sri-kl Subject: MSGGROUP#2154 Re: Errors returned under separate cover? From: BILLW@sri-kl To: ESTEFFERUD@usc-ecl Cc: Schiller@mit-multics, Postmaster@mit-multics Cc: MsgGroup@brl, mike@brl Message-ID: <[SRI-KL]28-Aug-83 22:12:08.BILLW> In-Reply-To: <[USC-ECL]28-Aug-83 16:57:29.ESTEFFERUD> Ill bet one part of the "returned message" is using the "return path" spec for an address, and the other is parsing the from field. Thus mail sent to one of the many mailing lists that convert the "mail from" field to point to the mailing list maintainer will get half of the error message sent to the original sender, and half sent to the list maintainer. Pretty obscure! BillW 29-Aug-83 05:21:55-PDT,705;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 29 Aug 83 05:19:09-PDT Received: From Sri-Nic.ARPA by BRL via smtp; 29 Aug 83 7:26 EDT Date: 29 Aug 83 02:50:58-PDT (Mon) From: Henry W. Miller Subject: MSGGROUP#2155 Re: ISI-VAXA's SMTP sender doesn't say HELO To: DBrown.TSDC@HI-MULTICS.ARPA, MsgGroup@BRL.ARPA cc: Miller@SRI-NIC.ARPA In-Reply-To: Message from "DBrown.TSDC@hi-multics" of Fri 26 Aug 83 09:13:00-PDT Actually, it was intended to be partially humorous, but, equally as serious. The protocol is defined, and is accepted by most rationial beings. Sooner or later, we all shall have to conform to the spec. -HWM ------- 29-Aug-83 10:18:11-PDT,4860;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 29 Aug 83 10:15:15-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 29 Aug 83 12:34 EDT Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Mon 29-Aug-83 11:46:44-EDT Date: 29 August 1983, 11:45-EDT (Monday) From: Charles Hornig Reply-to: CAH@mit-mc Subject: MSGGROUP#2156 Re: Errors returned under separate cover? To: ESTEFFERUD@usc-ecl, Jeffrey I. Schiller , Robert W. Kerns , BILLW@sri-kl, Postmaster@mit-multics Cc: mike@brl, Mike Muuss , MsgGroup@brl In-reply-to: <[USC-ECL]27-Aug-83 00:13:56.ESTEFFERUD>, The message of 27 Aug 83 18:00-EDT from Jeffrey I. Schiller , The message of 27 Aug 83 20:57-EDT from Robert W. Kerns , <[USC-ECL]28-Aug-83 16:57:29.ESTEFFERUD>, <[SRI-KL]28-Aug-83 22:12:08.BILLW> I may regret this, but I feel compelled to enter the fray. Although I have since left Honeywell, I was resposible for the current Multics network mailer design. Originally, the failed mail notification was done the way it is because it was easier to write (I already had the data structures for the original mail set up and ready). When it was put into operation, I found that it was very convenient to be able to reforward a piece of failed mail with the original header (with a few added Redistributed fields) rather than completely encapsulated in a new message, as other mailers do. The reason that there is no identifying information in the "message failed" mail is that none is available beacuse of modularity. I designed the mail delivery subsystem to know only SMTP and domains, not about RFC822. It does not make any attempt to parse the mail itself. Since there is no Message-ID in the SMTP "envelope", there is not way to link the two messages. I don't trust mailers which claim to know how to parse headers. I've been screwed by MMDF too many times. In any case, very many systems on the ARPANET are still using pre-RFC822 mail formats. How am I supposed to parse them? Note that none of the messages to which I am replying use domain-based host names, as specified in RFC 822. SMTP is deficient in not specifying how mail delivery failures which occur after the RCPT command has been acknowledged are to be reported. This could be remedied. Add a transaction ID to an SMTP transaction which could be returned in the failed mail message. This would allow automatic processing at the originating site. Date: Saturday, 27 August 1983, 20:57-EDT From: Robert W. Kerns If there was a standard format for encapsulating these returned messages, mail reading programs could handle remailing them with corrected addresses very simply. This would also be reasonable. Date: 28 Aug 1983 1657-PDT From: ESTEFFERUD at USC-ECL For the MsgGroup record, here is a sample of a complete message: Return-path: <@MIT-MC:Liaison@MIT-MULTICS> Received: from MIT-MC by USC-ECL; Sat 27 Aug 83 08:59:07-PDT From: Network_Server.Daemon at MIT-MULTICS.ARPA Subject: Unable to deliver mail from ESTEFFERUD@USC-ECL@MIT-MC Message will be returned under separate cover. To: Ruptash at SYSTEM-M.PHOENIX.HONEYWELL: Entry not found. Several things are important to note here: 1. The original was not TO: Ruptash@system-m,phoenix.honeywell ... It was to msggroup, or maybe it was to header-people. The address after the To: in the response is what was sent from MIT-Multics to System-M in the RCPT command, translated to English. It has nothing to do with the header field of the same name. 2. The promised return of the original must have gone to someone else. It has not arrived in my mail with any identifiying marks that I can see to distinguish it from my other copy of the same mail item, assuming that I can tell which item is being referenced. 3. This notice does not tell who it was addressed to. This is due solely to laziness on my part. Date: 28 Aug 1983 22:12-PDT From: BILLW@SRI-KL Ill bet one part of the "returned message" is using the "return path" spec for an address, and the other is parsing the from field. Thus mail sent to one of the many mailing lists that convert the "mail from" field to point to the mailing list maintainer will get half of the error message sent to the original sender, and half sent to the list maintainer. Pretty obscure! Nope. Both parts were sent using the return-path. The message is never parsed at all. Perusal of logs could probably determine where the errant message went. 29-Aug-83 11:52:10-PDT,1229;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 29 Aug 83 11:50:23-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 29 Aug 83 13:59 EDT Date: 29 Aug 1983 1005-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2157 Re: Errors returned under separate cover? From: ESTEFFERUD@usc-ecl To: CAH@mit-mc Cc: Schiller@mit-multics, RWK%SCRC-TENEX@mit-mc Cc: BILLW@sri-kl, Postmaster@mit-multics, mike@brl Cc: unix-wizards-request%BRL-VGR@mit-mc, MsgGroup@brl Message-ID: <[USC-ECL]29-Aug-83 10:05:09.ESTEFFERUD> In-Reply-To: Your message of Monday, 29 August 1983, 11:45-EDT Your explanation is most welcome. It lays bare the essential issues. If you could get the needed information and tie the two messages together, then maybe it would be OK to separate them. But, the information is not available, so it is my most serious recommendation that Multics be changed to put them back together again. The present state of affairs is terrifying for those who process larger quantities of mail. I have handled more than 100 failed mail notices this weekend. Suppose I had not been on the net over the weekend! Any volunteers to help sort things out this morning? Thanks - Stef 29-Aug-83 20:24:32-PDT,1008;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 29 Aug 83 20:24:21-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 29 Aug 83 20:04 EDT Date: 29 Aug 83 20:00:08 EDT (Mon) From: Ron Natalie To: ESTEFFERUD@usc-ecl cc: Schiller@mit-multics, Postmaster@mit-multics, MsgGroup@brl, mike@brl Subject: MSGGROUP#2158 Re: Errors returned under separate cover? Aha...You've found one of the great problems. Returned mail from the Honeywell Multics sites (Honeywell, CISL-SERVICE-MULTICS) sends back a letter (in illegal format I should say) saying the mail has failed to be delivered and in addition it sends you a seperate copy of the original letter with no changes to the text of the letter. These are only distinguishable from the originals by looking carefully at the received lines (if your mail system adds them) to see what host routed a copy of your own letter back to you. -Ron (INFO-MICRO-REQUEST, INFO-CPM-REQUEST, and INFO-MUSIC-REQUEST) 9-Sep-83 21:40:30-PDT,1552;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Fri 9 Sep 83 21:35:41-PDT Date: 9 Sep 1983 19:05:19 PDT From: POSTEL@USC-ISIF Subject: MSGGROUP#2159 RFC 876-877 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 876: Title: Survey of SMTP Implementations Author: D. Smallberg Pages : 13 pathname: [SRI-NIC]RFC876.TXT This memo reports the results of a survey of implementations of the mail transport protocol. The features checked were: (1) the interaction with an ARPANET host (a host on a class A network), (2) the interaction with a ISI-NET host (a host on a class B net), (3) the implementation of the VRFY command, (4) the implementation of the Postmaster mailbox, and (5) the treatment of a bad recipient name. RFC 877: Title: A Standard for the Transmission of IP Datagrams Over Public Data Networks Author: J. T. Korb Pages : 2 pathname: [SRI-NIC]RFC877.TXT This memo specifies the standard encapsulation for transmission of IP Datagrams in X.25 Packets over Public Data Networks. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 26-Sep-83 10:10:07-PDT,1203;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 26 Sep 83 10:09:27-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 26 Sep 83 12:08 EDT Date: 26 Sep 1983 0905-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2160 [Jeffrey@OFFICE-6: IBM's DCA/DIA] From: MsgGroup Moderator Reply-To: MsgGroup@brl To: msggroup@brl Cc: Jeffrey@office Message-ID: <[USC-ECL]26-Sep-83 09:05:13.ESTEFFERUD> This question seems worthy of MsgGroup consideration, if anyone has any light to shine on it. Pointers anyone? Stef Begin forwarded message Date: 25 Sep 1983 0728-PDT To: estefferud@USC-ECL Cc: msggroup@USC-ECLC Subject: IBM's DCA/DIA From: Jeffrey@OFFICE-6 Hello, This is Jeffrey Stone of Menlo Park, CA. I am trying to understand the status and future of IBM's CDA/DIA architectures (Document Content Architecture and Document Interchange Architecture). There seems to be very little information available except the IBM documents describing the architectures. I would appreciate any pointers that anyone could give me. Thanks very much, Jeffrey Stone End forwarded message 26-Sep-83 14:35:28-PDT,1564;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 26 Sep 83 14:35:12-PDT Received: From Sri-Tsc.ARPA by BRL via smtp; 26 Sep 83 17:12 EDT Date: 26 Sep 1983 at 1339-PDT To: MsgGroup@brl Cc: Jeffrey@office-2 Subject: MSGGROUP#2161 Re: [Jeffrey@OFFICE-6: IBM's DCA/DIA] In-reply-to: Your message of 26 Sep 1983 0905-PDT. <[USC-ECL]26-Sep-83 09:05:13.ESTEFFERUD> From: garcia.tsca@sri-unix Received: from SRI-Tsca.micom by SRI-TSC.micom with rs232; 26 Sep 83 13:56-PDT Jeffrey: From your message I gather that you are not interested in IBM reports (e.g., Report 50008-- $395.00 from what I know). However, you may have around some old reports that deal with DCA/DIA indirectly, such as: 1) IBM Report SC27-0548-0, Distributed Office Support Facility-- Document Transmission Function Guide. 2) IBM Report SC23-0710-2, IBM 5520 Administrative System. I can only think of two (old) introductory articles on the subject: 1) The Document Interchange Architecture: A member of a family of architectures in the SNA environment, T. Schick and R.F. Brockish, IBM Systems Journal, Vol. 21, No. 2, 1982, pp. 220-244. 2) Electronic information interchange in an office environment, M.R. DeSousa, IBM Systems Journal, Vol. 20, No. 1, 1991, pp. 4-22. For more information on the subject you could contact: Mr. R.F. Brockish IBM Information Products Division Laboratory P.O. Box 1900 Boulder, Colorado 80302 303/447-1900 I hope this information is useful. Jose ---------- 3-Oct-83 15:59:42-PDT,1257;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 3 Oct 83 15:55:05-PDT Received: From Ucl-Cs.ARPA by BRL via smtp; 3 Oct 83 18:34 EDT Via: UNKNOWN-HOST; (src/csmail/listen); to 44d.Ucl-Cs.AC.UK over Sercnet with NIFTP; 3 Oct 83 20:19 BST From: Jonathan Mills (on GEC 4090 at Rutherford) To: Header-People Date: 3 Oct 83 15:30 BST Subject: MSGGROUP#2162 Message-IDs Message-Id: <03 OCT 1983 15:38:44 NSIN24@RLGK> Cc: sgGroup As I seem to get multiple copies of messages from the State's mailing list i decided to sit down today and write some code that eliminates duplicate messages. My code was based on the MESSAGE-ID field contents, and the idea was that if two MESSAGE-ID fields were the same, I could discard one of the messages. However, when I fired up the code, I set it to work on my collection of HEADER-PEOPLE and MSGGROUP mail, and it said it found 1 duplicate message. I then discovered that very few of the states mailers seem to stamp MESSAGE-ID fields - Is there a good reason for this? (Actual figures were that only 25 out of 80 messages had MESSAGE-IDs) Jonathan 4-Oct-83 00:46:12-PDT,893;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 4 Oct 83 00:45:43-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 4 Oct 83 3:17 EDT Date: 4 Oct 1983 00:19-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2163 Re: Message-IDs From: Einar Stefferud - Mssgroup Moderator Reply-To: Msggroup@brl To: NSIN24%rlgk@brl Cc: Header-People@mit-mc, MsgGroup@brl Message-ID: <[USC-ECL] 4-Oct-83 00:19:30.ESTEFFERUD> In-Reply-To: <03 OCT 1983 15:38:44 NSIN24@RLGK> With some fear and trepidation, I want to strongly suggest that this discussion of whether or not to ID messages should flow in Header-People only, since this is a relativley operational issue. The last time I requested this, I discovered an immense inertia among the contributors who basically ignored my request entirely. Lets not do that this time. Thanks - Stef 12-Oct-83 04:07:31-PDT,2725;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 12 Oct 83 04:03:36-PDT Date: 12 Oct 83 6:34:41 EDT From: Larry Layten (DARCOM) To: msggroup@brl, info-law@sri-csl cc: llayten%darcom-hq@udel-relay, llayten@brl Subject: MSGGROUP#2164 File Privacy I am sending this message to this group as an individual interested in the future uses of electronic mail and computer usage in workplace automation. My comments and perceptions should not be construed to be those of the agency for which I work. BACKGROUND: I work for the Army Material Development and Readiness Command (DARCOM) which has been quite active in the use of electronic mail and in the use of computers in the office environment. The command has well over three thousand users with access to the DDN. Within our command headquarters, there are currently over 500 users of our internal workplace automation computers. The use of the computer support includes standard text processing support as well as electronic mail and other office support functions. PROBLEM: There have been several (three that I know of) instances where the Army Criminal Investigation Division (CID), sometimes in conjunction with the FBI, has obtained complete dumps of our workplace automation computers without any type of court order or identification of what they are looking for other than "wrongful use of government property". They do not limit their dumps to specific files or individuals. They have read individuals their rights and otherwise tried to intimidate them in two instances that I know of, once after finding a recipe in a message, an once, when a baby sitter's phone number was found in a telephone number file. Our commands legal staff has advised our managers that what is taking place is legal, by all precedents. They say that computer files do not have the same privacy protections that telephone usage has. We are now seeing some people that used to use the system for at least receiving electronic mail, request that their accounts be removed because they do not want to leave themselves open to criticism. If in fact, the owner of a computer system has the right to search (in a witch-hunt fashion) through all files, with the threat of prosecution, then I too will refain from using the system as I have in the past: as a note pad, telephone replacement, sounding board for ideas, etc. I should mention, that there has not yet been any official charges filed in conjunction with any of the file searches. Does anyone out there know where the law is heading in this type of issue? I would hope that 1984 is not as close as it appears. Larry  12-Oct-83 19:38:48-PDT,3153;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 12 Oct 83 16:09:54-PDT Received: From Su-Score.ARPA by BRL via smtp; 12 Oct 83 18:19 EDT Date: 12 Oct 83 15:21:37-PDT From: Mark Crispin Subject: MSGGROUP#2165 Re: File Privacy To: llayten@BRL.ARPA cc: msggroup@BRL.ARPA, info-law@SRI-CSL.ARPA In-Reply-To: Message from "Larry Layten (DARCOM) " of Wed 12 Oct 83 03:59:13-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Unfortunately, the exact same situation as you describe exists on many academic computer systems as well. What freedoms or privacy exists depends solely on the good will of those people in power. Regrettably, many computer centers are run by various flavors of petty dictators. I spent my four undergraduate years in the mid 70's dealing with such a computer center, and am determined never to repeat that experience. In general, one should never keep any sensitive personal information online. Even if your computer center is run by individuals who believe in privacy, there are sufficient electronic vandals who have no such qualms. If you don't like the way your computer center is run, the only recourse is to vote with your feet. Not that the computer center would care. My observation has been that the more dictatorial a computer center is, the more business it tends to bring in. I wish I knew why. I guess it's because most people are suckers for punishment. I am convinced that the single most potent factor behind the "personal computer revolution" is the ability of individuals or small organizations to free themselves from the control of such computer centers. Not that that helps much. The problem with records in electronic media is that it makes "fishing" trivial; if somebody wants to nail you they could subpoena your floppy disks for some trivial bit of information and while they're at it read everything else. They can't do that with records on paper. I would never put anything sensitive or personal on a floppy disk without having a bulk eraser handy to degauss it at an instant's notice. I am quite skeptical of any good results coming out of any court or legislative decisions regarding computer or electronic mail privacy issues. They are likely to make matters worse, not better; sensational stories about "hackers" and "computer crime" are most likely to give computer centers greater power to the detriment of individual privacy and rights. On the "abuse of facilities" issue, just about every company has rules and regulations regarding the use of company telephones for personal business. However, most reasonable companies tolerate a limited amount of such "abuse", such as calling one's spouse just before quitting time, on the grounds that such tolerance returns more in employee morale (and productivity) than a strict by the book implementation would. If your organization does not do this, again, your only real recourse is to vote with your feet. ------- 12-Oct-83 19:39:13-PDT,1537;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 12 Oct 83 18:05:57-PDT Date: 12 Oct 83 19:57:25 EDT From: Larry Layten (DARCOM) To: Mark Crispin cc: llayten@brl.arpa, msggroup@brl.arpa, info-law@sri-csl.arpa Subject: MSGGROUP#2166 Re: File Privacy Mark, Thanks for your reply. I agree with most everything you say, with the exception of the mail privacy issue. I really did not have that much problem with the systems administrators, or even the CID doing their thing, because in fact, the CID is just another layer of the bureaucracy (being a part of the Army). But when the FBI gets thrown into the picture, it is apparent that the law obviously supports the seizure of information stored on a computer without regard to the processes that they would have to follow if there had been suspected mail or telephone missuse. Even government phones may not be tapped (for any purpose other than national security) without a court order. I would think that the same processes should apply (and probably will once it gets high enough in the court system) to information on computers that apply to other forms of privileged communications. Without some degree of protection, the chances are to great for abuses by the various police activities. I was in hope that someone might know of court decisions that would tend to support the individuals right to "due process" in the electronic mail or computer stored information area. Larry 13-Oct-83 13:38:46-PDT,1221;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Thu 13 Oct 83 13:35:16-PDT Date: 13 Oct 1983 11:38:14 PDT From: WESTINE@USC-ISIF Subject: MSGGROUP#2167 RFC 870 & RFC 880 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 870: Title: Assigned Numbers Author: J. Reynolds Pages : 26 pathname: RFC870.TXT This memo specifies the currently defined uses of several Internet protocol family parameters, including network numbers, versions, prorocols, and ports. RFC 880: Title: Official Protocols Author: J. Reynolds Pages : 26 pathname: RFC880.TXT This memo lists the official protocols of the Internet protocol family and indicates their specifying documents, and status. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 14-Oct-83 13:28:22-PDT,906;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 14 Oct 83 13:25:51-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 14 Oct 83 15:47 EDT Date: 14 Oct 83 12:35:23-PDT From: Mark Crispin Subject: MSGGROUP#2168 HELO command in SMTP To: Header-People@MIT-MC.ARPA, MsgGroup@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I was reading through RFC 821 looking up the TURN command, and found a definite statement that HELO is required. On page 27 of 821, at the top (this is the last set of paragraphs in 4.1.1), it states: "The first command in a session must be the HELO command." If there are still any individuals who think the HELO command is optional and that the TOPS-20 mailer is wrong for requiring it, this should settle that. ------- 14-Oct-83 16:38:01-PDT,762;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 14 Oct 83 16:33:19-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 14 Oct 83 19:04 EDT Received: from USC-ECL by SU-SCORE.ARPA with TCP; Fri 14 Oct 83 14:47:51-PDT Date: 14 Oct 1983 14:43-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2169 Re: HELO command in SMTP From: Einar Stefferud - MsgGroup Moderator Reply-To: msggroup-request@brl To: MRC@su-score Cc: Header-People@mit-mc, MsgGroup@mit-mc Message-ID: <[USC-ECL]14-Oct-83 14:43:28.ESTEFFERUD> In-Reply-To: The message of Fri 14 Oct 83 12:35:23-PDT from Mark Crispin OK. Now lets keep the remaining traffic on ths topic in Header-People only, Please! Thanks - Stef 16-Oct-83 18:16:48-PDT,1997;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 16 Oct 83 18:15:33-PDT Received: From Rutgers.ARPA by BRL via smtp; 16 Oct 83 20:44 EDT Date: 16 Oct 83 20:41:43 EDT From: Charles Hedrick Subject: MSGGROUP#2170 privacy of files To: msggroup@BRL.ARPA Are there not good security grounds for the Army to want to limit the amount of fishing the FBI does with its computers? Even if you do not keep top secret information around in your mail files (and I trust you do not), it seems undesirable for any outside agency to go on fishing expeditions through military files of any kind. I would think your system administrators could stop it on those grounds if nothing else. Also, most laws on computer use talk about authorized use. I am perfectly willing to say that my staff are authorized to use our computer for a limited amount of personal business, much along the lines of telephone use. I would think that in this case nobody would be able to say anything about the cases you mentioned. The world being what it is, it is clear that employees have to be able to arrange babysitters during the hours of 9 to 5. I do not think our laws are so far gone that an employer can't allow that sort of thing if he wants to. This seems to be an issue that the people who administer the computers could settle if they wanted to, by an appropriate definition of authorized. Furthermore, the people in charge of the word processing systems may even have an interest in doing this, if failing to do so will cause them to lose business. Have you tried talking to any of the administrators? It may also be appropriate to write congressmen on this issue. I realize politicians can sometimes be obtuse. But as computers start taking over the office, this will become a problem to more and more people. Congress certainly does not want to seem to be in a position of causing the workplace to become oppressive. ------- 17-Oct-83 13:31:59-PDT,1169;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 17 Oct 83 13:31:26-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 17 Oct 83 15:58 EDT Date: 17 Oct 83 15:51:47 EDT From: Stephen Wolff To: Charles Hedrick cc: msggroup@brl.arpa Subject: MSGGROUP#2171 Re: privacy of files Sorry, Charlie! I am not permitted to "arrange babysitters" during "duty" (office) hours. I can lose my job for using the taxpayers' telephone for ANY personal business (it's no real hardship, though; there's a perfectly good pay phone in another building not 200 yards from my office). Not too long ago, one of our commands in the bureaucratic stratosphere sent a Colonel around to Army installations, with authority to conduct unannounced inspections of office desks - looking for "personal" items ("Project Ferret"). Writing this response on Gummint time may be prohibited. Or suspect at least. And don't prate about Congress. We're Civil Servants - Executive Branch, remember? The Enemy. Overpaid, undersmart and retiring in droves and opulence in early middle age at taxpayer expense. 17-Oct-83 14:22:03-PDT,752;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 17 Oct 83 14:21:40-PDT Received: From Utexas-20.ARPA by BRL via smtp; 17 Oct 83 16:55 EDT Date: 17 Oct 83 15:54:23-CDT From: Clive Dawson Subject: MSGGROUP#2172 Re: privacy of files To: steve@BRL-BMD.ARPA cc: HEDRICK@RUTGERS.ARPA, msggroup@BRL.ARPA In-Reply-To: Message from "Stephen Wolff " of Mon 17 Oct 83 15:35:13-CDT Sigh...If I had anything to say about it, people who spent 10 or 15 minutes making a round trip to a public phone 200 yards away would be in more trouble than those who expedited things from their desk phone in 3 minutes flat! Double sigh....You have my condolences, Steve. Clive Dawson ------- 17-Oct-83 15:57:13-PDT,6808;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 17 Oct 83 15:52:16-PDT Received: From Sri-Csl.ARPA by BRL via smtp; 17 Oct 83 18:18 EDT Date: 17 Oct 1983 15:08-PDT Sender: GEOFF@sri-csl Subject: MSGGROUP#2173 Re: privacy of files From: the tty of Geoffrey S. Goodfellow@BRL.ARPA Reply-To: Geoff@sri-csl To: steve@brl-bmd Cc: HEDRICK@rutgers, msggroup@brl Message-ID: <[SRI-CSL]17-Oct-83 15:08:51.GEOFF> In-Reply-To: The message of Mon, 17 Oct 83 15:51:47 EDT from Stephen Wolff This reminds me of an article which appeared in COMPUTERWORLD during December of 1980, about a `bust' of this nature. Then, someone on the ARPANET wrote up a `parody' of the incident for a fictitious publication called COMPUTERVISION, (n.b. the year!). I enclose both the "real" and the "parody", fyi and enjoyment: ------- COMPUTERWORLD, December 8, 1980 No More `Star Trek' on CPU COmputer Security Tightened at Sandia Labs by Jake Kirchner, CW Washington Bureau, Washington D.C. Federal auditors have all but closed the books on an investigation into unauthorized computer use by employees of a government nuclear weapons research center in Albuquerque, N.M. Although it has not done a follow-up study, the Department of Energy (DOE) said recently the Sandia Laboratory has taken "commendable" steps to beef up computer security following revelations of widespread problems at the facility. The DOE Inspector General's office here revealed last month it had found more than 200 Sandia employees had stored a total of 456 unauthorized files on one of the facility's Control Data Corp. system. The laboratory, operated for the government by Western Electric Co., performs nuclear weapons research and development and conducts research projects in such areas as solar and wind energy. Although the lab does classified work, the time-shared CDC 6600 system involved was used for unclassified projects. DOE Investigation The DOE investigation began a year ago when the Federal Bureau of Investigation informed the department it had found one of Sandia's employees using the CDC system to help local gamblers run a bookmaking operation. The employee was fired and a subsequent audit found hundreds of rather routine, although unauthorized, files that included several hundred games, such as Star Trek and Adventure, as well as poetry, jokes, personal letters, a beer collection catalog and bowling team rosters. About half the offending employees disregarded an initial warning to purge the files of unauthorized data and were later reprimanded, according to DOE. One of the "most disturbing findings," the DOE said, was that a so-called "bomb book" was on the system and accessible to all users. This file contained numerous nuclear test shots. While not classified, the bomb book was considered sensitive and was later removed from the system. This problem and other findings of the investigation raised questions about Sandia's overall computer security procedures. The DOE investigators found, for example, that "a common practice at Sandia was to share passwords among staff people." Also, passwords were changed only once a year so that a person leaving Sandia employ could still access the computer system using another person's passwork. Another problem was with physical security. DOE said its auditors observed no security checks on briefcases or packages carried by Sandia, DOE or contract emplyees. Policy Directive Following the DOE investigation, Sandia issued a policy directive stating any use of a facility computer must be for official work. DOE also advised Sandia employees that personal or improper use of the computers would result in disciplinary action. Employees were further reminded that misuse of government property is punishable by fine, imprisonment or both. DOE called for better recordkeeping of computer security guidelines to employees, as well as periodic random sampling of computer files to make sure no authorized data is being stored. ------- ------- COMPUTERVISION, December 10, 1984 No More Aspirin at Work Desk Security Tightened at Boffin Labs by Walter Newswriter, PAP News Bureau, Washington D.C. Federal auditors have all but closed the books on an investigation into unauthorized desk contents by employees of a government research center in Yourtown, U.S.A. Although it has not done a follow-up study, the Department of Ultimate Bombastic Bona-Partism (DUMBB) said recently the Boffin Laboratory has taken "commendable" steps to beef up desk security following revelations of widespread problems at the facility. The DUMBB Inspector General's office here revealed last month it had found more than 200 Boffin employees had stored a total of 456 unauthorized items in desks issued to them by the facility. The laboratory, operated for the government by an unnamed energy magnate, performs research and development and conducts research projects in such areas as solar and wind energy. Although the lab does classified work, the desks involved were used for storing unclassified items. DUMBB Investigation The DUMBB investigation began a year ago when the Federal Bureau of Investigation informed the department it had found one of Boffin's employees using a calculator normally stored in the top desk drawer to help local gamblers run a bookmaking operation. The employee was fired and a subsequent audit found hundreds of rather routine, although unauthorized, desk contents that included several hundred decks of cards, such as Bridge and Pinochle, as well as aspirin, candy, personal letters, a beer collection and bowling team rosters. About half the offending employees disregarded an initial warning to purge their desks of unauthorized items and were later reprimanded, according to DUMBB. Policy Directive Following the DUMBB investigation, Boffin issued a policy directive stating any use of a facility desk must be for official work. DUMBB also advised Boffin employees that personal or improper use of the desks would result in disciplinary action. Employees were further reminded that misuse of government property is punishable by fine, imprisonment or both. DUMBB called for better recordkeeping of desk security guidelines to employees, as well as periodic random sampling of desk drawers to make sure no authorized items are being stored. ------- ------- Geoff 17-Oct-83 16:47:29-PDT,1267;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 17 Oct 83 16:47:14-PDT Received: From Mit-Ml.ARPA by BRL via smtp; 17 Oct 83 19:28 EDT Received: from SCRC-YUKON by SCRC-QUABBIN with CHAOS; Mon 17-Oct-83 19:25:43-EDT Date: 17 Oct 83 19:25 EDT From: Robert W. Kerns Subject: MSGGROUP#2174 Re: privacy of files To: Stephen Wolff Cc: Charles Hedrick , msggroup@BRL.ARPA In-reply-to: The message of 17 Oct 83 15:51-EDT from Stephen Wolff Message-ID: <831017192523.6.RWK@YUKON.SCRC> Date: Mon, 17 Oct 83 15:51:47 EDT From: Stephen Wolff Sorry, Charlie! I am not permitted to "arrange babysitters" during "duty" (office) hours. I can lose my job for using the taxpayers' telephone for ANY personal business (it's no real hardship, though; there's a perfectly good pay phone in another building not 200 yards from my office). So THAT's where all our taxes are going. Not only do we pay for the phones to sit unused on your desk, we pay for you to go to the next building to make your call. Not to mention paying by losing good people to more reasonable working environment. 18-Oct-83 01:47:10-PDT,2154;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 01:45:47-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 18 Oct 83 4:17 EDT Date: 18 Oct 83 4:12:03 EDT From: Stephen Wolff To: rwk%yukon.scrc@mit-mc cc: msggroup@brl, hedrick@rutgers Subject: MSGGROUP#2175 Re: privacy of files Don't get me wrong: my working environment isn't bad. Quite good in fact. I have license to research any number of really tough problems in technology, applied science and mathematics. I have quite a collection of creative folks -- and a few genuinely gifted ones -- to help. And the two levels of management above me are in that lot. I have a not-wholly-inadequate suite of hardware to use on the appropriate bits of some of the problems. And the pay's not bad; and most of the time I can respect most of the people I am working for though corporately they be afflicted with terminal stuffiness. It's just that at some times the hair shirt is itchier than at others, and the irrelevancies of the job less easy to ignore. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- No. The point of my note was that at least in the Army the usage of the classical (physical) office and of the time of office-people is at least in my opinion a wholly inappropriate -- certainly at least unattractive -- model for the social and bureaucratic organization of the computer-automated workspace, though in more progressive/enlightened/laid-back organizations such may not indeed be the case. Thanks to Geoff Goodfellow for resurrecting that old article+parody from COMPUTERWORLD; if he had not, I should have. For you now understand that there are people in the Army's management (e.g., the instigators of "Project Ferret") who would take the PARODY seriously! Mete and proper in fact. Or, as Queen Victoria is reputed to have said about "The Pirates of Penzance", "We are NOT amused." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Should further discussion (if any) move elsewhere? Human-nets maybe? 18-Oct-83 11:17:43-PDT,1082;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 11:15:43-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 18 Oct 83 13:35 EDT Date: 18 Oct 1983 10:31-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2176 MsgGroup vs Human-nets for "privacy of files" From: ESTEFFERUD@usc-ecl To: MsgGroup@brl Message-ID: <[USC-ECL]18-Oct-83 10:31:22.ESTEFFERUD> In-Reply-To: The message of Tue, 18 Oct 83 4:12:03 EDT from Hi Steve, et al ... MsgGroup is fine for this if we want to have an interactive discussion, without benefit of delays and digestification, and mixing it in with lots of other topics. I for one would like to let it run unfettered by intermediaries in MsgGroup. I don't know about others, but I find that reading all of Human-Nets every day to see what new has been said on one topic of interest is just to laborous, so I put it off for weeks at a time. (Months unless someone calls my attention to something.) I expect that Human-Nets can pick it up and carry a copy if they want. Best - Stef 18-Oct-83 16:30:20-PDT,495;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 16:30:14-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 18 Oct 83 19:11 EDT Date: 18 Oct 83 19:07:28 EDT From: Ron Natalie To: msggroup@brl-vgr Subject: MSGGROUP#2177 NLM-MCS Does anybody know what happened to NLM-MCS. They suddenly dropped off. They are commented out of the host tables and the IMP to which they were connected does not seem to be alive anymore either. -Ron 18-Oct-83 17:02:49-PDT,741;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 17:02:33-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 18 Oct 83 19:42 EDT Received: From Sri-Csl.ARPA by BRL-VGR via smtp; 18 Oct 83 19:32 EDT Date: 18 Oct 1983 16:20-PDT Sender: GEOFF@sri-csl Subject: MSGGROUP#2178 Re: NLM-MCS From: the tty of Geoffrey S. Goodfellow@BRL-VGR.ARPA Reply-To: Geoff@sri-csl To: ron@brl-vgr Cc: msggroup@brl-vgr Message-ID: <[SRI-CSL]18-Oct-83 16:20:28.GEOFF> In-Reply-To: The message of Tue, 18 Oct 83 19:07:28 EDT from Ron Natalie Ron I think your inquiry into NLM-MCS's network connectivity would have more apropos addressed to NIC@SRI-NIC, rather than to msggroup. Geoff 18-Oct-83 18:27:53-PDT,1026;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 18:27:21-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 18 Oct 83 21:05 EDT Received: From Su-Score.ARPA by BRL-VGR via smtp; 18 Oct 83 21:00 EDT Date: 18 Oct 83 18:00:51-PDT From: Mark Crispin Subject: MSGGROUP#2179 Re: NLM-MCS To: ron@BRL-VGR.ARPA cc: msggroup@BRL-VGR.ARPA In-Reply-To: Message from "Ron Natalie " of Tue 18 Oct 83 16:27:54-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Ron - NLM-MCS shut down operations early in October. They are replacing their former system (a DECSYSTEM-20) with a VAX running Unix. Apparently they couldn't afford the maintenance costs of the -20 and think that their low usage would let them get away with a VAX. Maybe they're right; their system was rather underloaded, but as they're big Interlisp users I'm a bit skeptical. -- Mark -- ------- 18-Oct-83 23:02:17-PDT,863;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 18 Oct 83 23:00:33-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 19 Oct 83 1:35 EDT Received: From Su-Score.ARPA by BRL-VGR via smtp; 19 Oct 83 1:30 EDT Received: from USC-ECL by SU-SCORE.ARPA with TCP; Tue 18 Oct 83 22:29:11-PDT Date: 18 Oct 1983 22:27-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2180 Re: NLM-MCS From: ESTEFFERUD@usc-ecl To: MRC@su-score Cc: ron@brl-vgr, msggroup@brl-vgr Message-ID: <[USC-ECL]18-Oct-83 22:27:16.ESTEFFERUD> In-Reply-To: The message of Tue 18 Oct 83 18:00:51-PDT from Mark Crispin OK you guys! Lets pay a little attention to what is going into our addresses! Just because someone makes an error, it is not required for us all to follow like lemmings to fill up our colleagues malboxes with trash. Stef 23-Oct-83 20:06:40-PDT,564;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 23 Oct 83 20:02:03-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 23 Oct 83 22:36 EDT Date: 22 Oct 1983 2138-EDT From: Greg Skinner Subject: MSGGROUP#2181 Re: Computer Science Seminar at BU To: G.Bostonu=csc126@ucb-vax cc: msggroup%mit-oz@BRL.ARPA, header-people@mit-mc Reply-To: ee.gds%oz@BRL.ARPA In-Reply-To: Your message of 22-Oct-83 1825-EDT I am very curious. Why do bitnet addresses have the syntax ? ------- 23-Oct-83 21:51:51-PDT,641;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 23 Oct 83 21:45:57-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 24 Oct 83 0:21 EDT Date: 23 Oct 1983 21:20-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2182 RE: COMPUTER SCIENCE SEMINAR AT BU From: ESTEFFERUD@usc-ecl Reply-To: MSGGROUP-REQUEST@brl To: EE.GDS%OZ@brl Cc: G.BOSTONU=CSC126@ucb-vax, MSGGROUP@brl Cc: HEADER-PEOPLE@mit-mc Message-ID: <[USC-ECL]23-Oct-83 21:20:20.ESTEFFERUD> In-Reply-To: THE MESSAGE OF 22 OCT 1983 2138-EDT FROM GREG SKINNER SIGH! PLEASE RESTRICT REPLIES TO HEADER-PEOPLE ONLY! STEF 23-Oct-83 22:28:17-PDT,1830;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 23 Oct 83 22:25:51-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 24 Oct 83 1:09 EDT Date: 23 Oct 1983 22:06-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2183 Whither MsgGroup From: ESTEFFERUD@usc-ecl To: Message-ID: <[USC-ECL]23-Oct-83 22:06:04.ESTEFFERUD> With increasing frequency, MsgGroup mail consists of requests to not copy both MsgGroup and Header-People on Header-People issues. As Moderator, I question the value of keeping MsgGroup alive as an active discussion list. But, if MsgGroup should go inactive, I will arrange for the archives to remain accessible somehow in the net. It is true that in the transcripts of MsgGroup there are discussions of practically any and all relevant issues we have faced, and some that we have not yet faced, but the value of current discussions seems to me to be approximately nil, or if not nil, then they could easily occur in some other appropriate list. I am interested in your comments on this question. If I hear nothing in return, I will certainly understand the meaning, and will certainly take no offense. Indeed, I would let out a great sigh of relief, knowing that MsgGroup has made its contribution and now can be laid to rest. For a long time now, I have considered that the cost of MsgGroup was low enough while inactive to warrant letting it lay dormant, just waiting for someone to say something relevant. But, the cost has been rising as addressing problems have mounted, and the list requires more and more tender loving care. In short, lets not keep it going with heroic artificial means! I propose a nice dignified distributed wake. How about 300-400 glasses hoisted simultaneously within the reach of MsgGroup? Cheers - Stef 25-Oct-83 09:11:53-PDT,1094;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 25 Oct 83 09:10:36-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 25 Oct 83 11:24 EDT Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA02572; Tue, 25 Oct 83 08:15:07 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA26085; Tue, 25 Oct 83 08:23:56 pdt From: Eric Allman Phone: (415) 548-3211 Date: 25 Oct 1983 0823-PDT (Tuesday) Message-Id: <26084.31.435943433@ucbarpa> To: Ron Natalie Cc: csc126%Bostonu.BITNET@berkeley, msggroup@brl.ARPA, ee.gds%oz@brl.ARPA Subject: MSGGROUP#2184 Re: Computer Science Seminar at BU In-Reply-To: Your message of Tue, 25 Oct 83 1:05:01 EDT. <8310250558.AA23779@ucbvax.ARPA> Fcc: mail Actually the G.host=user@Berkeley (euch) syntax was the result of ad hoc changes made by our computer center to delivermail. The "@Berkeley" got the message to Berkeley, "G." got the message to a machine that understood the syntax, and "host=user" was the syntax that the CC selected for BITNET addresses. eric 1-Nov-83 16:45:42-PST,880;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 16:45:30-PST Received: From Mit-Mc.ARPA by BRL via smtp; 1 Nov 83 19:16 EST Date: 1 Nov 1983 16:13-PST Sender: BILLW@sri-kl Subject: MSGGROUP#2185 nicknames From: William "Chops" Westfield To: msggroup@mc Message-ID: <[SRI-KL] 1-Nov-83 16:13:18.BILLW> We have recently run into the following problem: the HSTNAM.MULTINET (for TOPS20) distributed by the NIC does not contain ALL nickames. We have been receiving a lot of mail recently where the headers contain a nickname, rather than the "official name", of the sending host. Now then, Id be perfectly happy to let the user type whichever nickname they want in the TO: fields of a message, but I feel that the FROM: and REPLY-TO: etc type field ought to use the "official name". COmments ? BillW 1-Nov-83 19:05:28-PST,1607;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 19:03:40-PST Received: From Mit-Mc.ARPA by BRL via smtp; 1 Nov 83 21:43 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 1 Nov 83 21:29:27 EST Date: 1 Nov 83 2140 EST (Tuesday) From: Craig.Everhart@cmu-cs-a To: William "Chops" Westfield Subject: MSGGROUP#2186 Re: nicknames CC: MsgGroup@mit-mc In-Reply-To: <[SRI-KL] 1-Nov-83 16:13:18.BILLW> Message-Id: <01Nov83.214033.CE10@CMU-CS-A> CMU has had local-only nicknames for its local hosts for years--e.g., ``A'' for CMU-CS-A, ``V'' for CMU-CS-VLSI, etc. Of course, other sites don't understand these nicknames. Therefore, for years the CMU mailers have been letting users refer to a host by any nickname they choose, but have substituted the official NIC name for that host in the outgoing mail's header. This seems to work pretty well; we're pretty sure that any host that understands Arpanet/Internet names will be able to accept the official host name, and it keeps us from having to burden the whole net community with local short nicknames. The same philosophy allows us to expand abbreviations of hosts' names; how many other mailers will understand ``sco'' as an abbreviation for SU-Score? We let users provide their own capitalization for host names, if they want; if what they give is the full official name for a host, except for possible differences in alphabetic case, we use the user's capitalization rather than the (pedestrian) all-upper-case version from the NIC's table. Craig Everhart 1-Nov-83 20:05:56-PST,1706;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 20:04:19-PST Received: From Mit-Mc.ARPA by BRL via smtp; 1 Nov 83 22:37 EST Date: 1 Nov 83 19:32:07-PST From: Mark Crispin Subject: MSGGROUP#2187 Re: nicknames To: Craig.Everhart@CMU-CS-A.ARPA cc: BillW@SRI-KL.ARPA, MsgGroup@MIT-MC.ARPA In-Reply-To: Message from "Craig.Everhart@cmu-cs-a" of Tue 1 Nov 83 21:40:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 mailsystem uses the official names exclusively, and sends out whatever case is used in the naming registry (as opposed to the user's entered case). That is, a user may enter "score", but an Internet header would show "SU-SCORE.ARPA" and a Pup Ethernet header would show "Score". Matches are done on a case-independent basis. At one time I didn't like mixed or lower case host names. I've since modified my views to prefer either all upper case or mixed case provided the mixed case is done correctly. In particular, SU is an acronym for Stanford University, Score is a proper name, and ARPA is an acronym. Should the NIC migrate to mixed case Score should be listed as SU-Score.ARPA, not Su-Score.Arpa, Su-score, etc. Sometimes I wish CSNet expressed some of its host names in a more sensible form than all lower case or mixed case at the start and after hyphens. I guess I don't even object that much to Unix-style all lower case. What raises my hackles are atrocities such as Mrc@Su-Score.Arpa -- MRC are initials, not short for "Marc" (which isn't how my name is spelled anyway). -- Mark -- ------- 1-Nov-83 21:00:26-PST,956;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 20:59:35-PST Received: From Usc-Isif.ARPA by BRL via smtp; 1 Nov 83 23:35 EST Date: 1 Nov 1983 20:34:06 PST From: POSTEL@usc-isif Subject: MSGGROUP#2188 Nicknames and Official Names To: msggroup@brl Hi. 1) All mail between computers should have the official host names in all header field they appear in (no host nicknames anywhere). What you do internal to your computer is your business. 2) The recogntion of host names should not depend on case. 3) As a matter of style, and personal preference, I think great care should be exercised in "caseifying" host names. At ISI we like to think that the Science is at least as important as the Information. Seeing "USC-ISI" transformed into "Usc-Isi" makes us wonder sometimes if it is just a dumb program or a subtle comment on the quality of our work. --jon. ------- 1-Nov-83 21:40:25-PST,1508;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 21:38:47-PST Received: From Mit-Mc.ARPA by BRL via smtp; 2 Nov 83 0:24 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 2 Nov 83 00:08:22 EST Date: 2 Nov 83 0018 EST From: Rudy.Nedved@cmu-cs-a To: Mark Crispin Subject: MSGGROUP#2189 Re: nicknames CC: Craig.Everhart@cmu-cs-a, BillW@sri-kl, MsgGroup@mit-mc In-Reply-To: "Mark Crispin's message of 1 Nov 83 22:32-EST" Message-Id: <02Nov83.001854.EN0C@CMU-CS-A> Mark, Another way to look at it is this: Where do you think mail should go to for host "ISL". Two to one odds you will think "SU-ISL" but around here we have added to our host table the nickname "ISL" for "CMU-RI-ISL" (and in fact for a while....mail on CMU-CS-C would go to SU-ISL because the DOMAINS.TXT file was examined first and HOSTS.TXT was not checked if a name was found). If that kinda of confusion exists for a mail composer what would a mail delivery agent do? I suspect it would send it to the wrong place or reject it. Therefore as I thought it said somewhere in one of the mail documents... mail headers and mail transport subsystems should only use fully qualified names....if a user wants to use a nickname for a host or a person then let the mail composer worry about it but force the mail composer to generate a fully qualified name. Now if I can only get my home terminal to have menus and a mouse, I would be set. -Rudy 1-Nov-83 22:30:38-PST,539;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 22:28:40-PST Received: From Mit-Mc.ARPA by BRL via smtp; 2 Nov 83 0:59 EST Date: 2 Nov 83 0:40:36 EST From: Ron Natalie To: William "Chops" Westfield cc: msggroup@mit-mc Subject: MSGGROUP#2190 Re: nicknames Could someone explain to me why the NIC maintains several different format of host table rather than just requiring everyone to process the RFC810 style ones as appropriate for their system? -Ron 1-Nov-83 23:20:33-PST,940;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 1 Nov 83 23:18:00-PST Received: From Mit-Mc.ARPA by BRL via smtp; 2 Nov 83 1:56 EST Date: 1 Nov 83 22:54:38-PST From: David Roode Subject: MSGGROUP#2191 Re: nicknames To: ron@brl-vgr, BillW@sri-kl cc: msggroup@mit-mc In-Reply-To: Message from "Ron Natalie " of Tue 1 Nov 83 22:24:37-PST Location: EJ286 Phone: (415) 859-2774 In answer to the question as to why the NIC maintains more than one HOSTS table format, I can observe that the reasons are largely historical and the move toward consolidation is well underway. The other two formats have essentially fallen into disuse as TOPS-20 and Tenex both now have been upgraded to read the RFC810 format directly. A program generates the older formats so the overhead of generating them was largely a one-time expenditure that took place in the past. ------- 2-Nov-83 09:37:45-PST,935;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 2 Nov 83 09:33:26-PST Received: From Mit-Mc.ARPA by BRL via smtp; 2 Nov 83 11:56 EST Date: 2 Nov 83 08:43:52-PST From: Mark Crispin Subject: MSGGROUP#2192 Re: nicknames To: Rudy.Nedved@CMU-CS-A.ARPA cc: Craig.Everhart@CMU-CS-A.ARPA, BillW@SRI-KL.ARPA, MsgGroup@MIT-MC.ARPA In-Reply-To: Message from "Rudy.Nedved@cmu-cs-a" of Wed 2 Nov 83 00:18:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Rudy's comment about DOMAINS.TXT being searched first is a "feature" in the TOPS-20 mailsystem which I have come to consider a misfeature or even a bug. The reason for it doing its current behavior was good, but it has turned out to be a misuse of a mechanism better suited for something entirely different. I am going to change it. ------- 4-Nov-83 01:45:05-PST,2426;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Fri 4 Nov 83 01:40:28-PST Date: 4 Nov 1983 00:50:49 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2193 RFCs 881, 882, and 883 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. These three RFCs discuss the introduction of domain style names for the DDN/ARPA Internet. This is a structured naming system which will provide flexibility for the growth of the Internet, and will provide for a consistent naming facility for interactions with other communication environments. The implementation of domain style names will impact all host in the DDN/ARPA Internet. For those interested in the discussion of this topic a mailing called "Namedroppers" has been created. If you are interested in the day-to-day technical development of these concepts and protocols please send a message to NAMEDROPPERS-REQUEST@SRI-NIC to be added to this mailing list. RFC 881: Title: The Domain Names Plan and Schedule Author: J. Postel Pages : 10 pathname: RFC881.TXT This memo outlines a plan and schedule for the implementation of domains style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts in the DDN/ARPA community. RFC 882: Title: Domain Names - Concepts and Facilities Author: P. Mockapetris Pages : 31 pathname: RFC882.TXT This memo introduces the domain style names, decscibes the conceptual framework for the domain names system including name servers ans name resolvers, and use of domain names in the DDN/ARPA Internet. RFC 883: Title: Domain Names - Implementation Specification Author: P. Mockapetris Pages : 75 pathname: RFC883.TXT This memo discusses the implementation of domain name servers and name resolvers, and the protocol procedures and message formats used in their interaction. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 10-Nov-83 06:40:20-PST,3083;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 10 Nov 83 06:39:44-PST Received: From Usc-Eclc.ARPA by BRL via smtp; 10 Nov 83 8:29 EST Date: 10 Nov 1983 0000-PST From: MsgGroup Moderator - Stefferud Subject: MSGGROUP#2194 [Marvin Solomon : Re: nicknames] To: msggroup@brl Sorry to bother you with an out of sequence item, but I found this in the msggroup-request mail just now. Enjoy - Stef --------------- Date: 2 Nov 83 08:54:06 CST (Wed) From: Marvin Solomon Subject: Re: nicknames Message-Id: <8311021454.AA02349@wisc-crys.ARPA> To: msggroup-request@BRL.ARPA I've been surprised that by an attitude some people seem to have that host nicknames are somehow "impure". For example: Now then, Id be perfectly happy to let the user type whichever nickname they want in the TO: fields of a message, but I feel that the FROM: and REPLY-TO: etc type field ought to use the "official name". I guess it depends on what you think nicknames are for. If you think of them as simply a way to save on typing, you may be right. However, we use use a nickname here at Wisconsin for what I believe to be a legitimate purpose that REQUIRES the nickname to go into the FROM field. We have several hosts here on a local network. They are all reachable directly from Arpanet via a PRIME gateway, so the From fields could point to the originating machine, but we frequently shuffle people amongst the local machines, so we prefer another strategy: Mail addressed to @ will be forwarded to the user's "home" machine according to a local table that lists all Arpanet-authorized users and their home mailboxes. All the mailers here mark outgoing Arpanet mail as being From: @UWISC. We bind "UWISC" as an alias for whatever local machine is most convenient. For a while, the local machine also known as CSNET-SH was most convenient, since it was the only local machine directly accessible from Arapnet (10.1.0.94), and many hosts in the Internet didn't know how to talk to a Class-C network. Soon, however, CSNET-SH is leaving Wisconsin, so we decided to move the UWISC nickname to another local host. If everybody in the Internet knows me as "solomon@uwisc", then nobody should notice the change provided they use the latest HOSTS.TXT. Correct me if I'm wrong, but I believe the motivation for the HSTNAM tables failing to include all nicknames was a design in which the table is kept in core. With the Internet growing by leaps and bounds, that design makes less and less sense. If the table is kept on mass storage, with some sort of index, there's no reason why a table of 10's or even hundreds of thousands of entries cannot be efficiently stored and accessed. The latest HOSTS.TXT contains only 1235 names, including all nets, gateways, and nicknames. "Official" nicknames--those registered with a name server--should be full and equal citizens. ------- 10-Nov-83 15:33:09-PST,872;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 10 Nov 83 15:29:54-PST Received: From Wisc-Crys.ARPA by BRL via smtp; 10 Nov 83 18:09 EST Date: 10 Nov 83 17:09:07 CST (Thu) From: Marvin Solomon Subject: MSGGROUP#2195 Re: nicknames [Message-id <831102145.AA02349@wisc-crys.ARPA>] Message-Id: <8311102309.AA03546@wisc-crys.ARPA> Received: by wisc-crys.ARPA (3.327/3.7) id AA03546; 10 Nov 83 17:09:07 CST (Thu) To: msggroup@brl Sorry I sent that last item to msggroup-request. I know better...must have hit the wrong button. By the way, although I still stand behind the arguments in that note, we have backed off using that scheme (for the time being). In the interest of harmony, mail originating at UWISC hosts will be addressed as coming from the "official" host name of the originating host. 11-Nov-83 20:34:59-PST,1049;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Fri 11 Nov 83 20:33:26-PST Date: 11 Nov 1983 20:00:21 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2196 RFC 879 Now Available To: Request-for-Comments-List: A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 879: Title: The TCP Maximum Segment Size and Related Topics Author: J. Postel Pages: 11 pathname: [SRI-NIC]RFC879.TXT This RFC clarifies the TCP specification and provides some advice to implementers. In particular, the relationship between the TCP maximum segment size and the IP maximum datagram size is discussed and defined. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 16-Nov-83 17:43:34-PST,2453;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 16 Nov 83 17:41:20-PST Received: From Nrl-Aic.ARPA by BRL via smtp; 16 Nov 83 20:20 EST Date: 16 Nov 1983 18:02 EST From: Dan Hoey Subject: MSGGROUP#2197 Digesting and ending To: Human-Nets@rutgers, MsgGroup@brl There have recently been discussions in Human-Nets (V6 #71) about standards for separating the messages in a digest. This recalls a discussion begun by Bill Wells in MsgGroup this past May (among messages 2017-2054) about the need for ending markers in messages. Mabry Tyson notes that you can't use ``separators the way it is currently done.'' The problem is that any fixed sequence that marks the end of messages may be included in the body of a message, leading to false recognition of the end of the message. Many message systems use some quoting scheme to prevent the ending string from occurring in the message. These schemes have led to such abominations as extraneous angle brackets on lines beginning with the word ``From'' and duplication or removal of periods at the beginning of lines. Mabry suggests using a character count at the beginning of each message, and notes several problems involving CR LF versus LF, NULs, and the previously-mentioned abominations. These problems are easily overcome by using a line count instead of a character count, but I still find the scheme distasteful: remember how hard it is to read Fortran's 9HHollerith specifications for strings? Fortunately, there is a solution to the problem. Given any message, it is fairly easy to find a string that does not occur in the message. Such a string may be used to mark the end of the message. The string itself can be mentioned in the message header, so that a reader seeing the beginning of the message will know where the end is. Thus: Date: 16 Nov 1983 18:02 EST From: Luser@Random-Site End-marker: XYZ Message not containing that string. End-of-message: XYZ An added frill is to reverse the string in the message header, in our example ``End-marker: ZYX''. This prevents the end marker from occurring anywhere in the message, even in the header, and yields the amusing bonus of allowing a context-free syntax for messages. I dearly hope that there will be some work done to make message endings more recognizable by humans and machines. Dan Hoey hoey@NRL-AIC 22-Nov-83 10:00:32-PST,1772;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 22 Nov 83 09:56:48-PST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 22 Nov 83 11:12 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Nov 83 05:50:06 EST Date: 22 Nov 83 0601 EST From: Rudy.Nedved@cmu-cs-a To: MsgGroup@brl Subject: MSGGROUP#2198 forwarding errors Message-Id: <22Nov83.060124.EN0C@CMU-CS-A> Let us assume that everyone implements return-paths correctly, that received: lines are used everytime mail enters a system and that mail exploders change the return-path to be some local mailbox, what does one do when he/she gets an error message for an address not in his mailing list? The case that I am hitting and a couple of other mailing list maintainers/postmaster types are hitting is the "bad forwarding address" problem where mail is address to foo@X and foo@X forwards to bad-address@Y. You get an error message saying "invalid user 'bad-address@Y'" which can not be found in your mailing list. A high percentage of the time you only have one person who is listed as getting mail with the lowest received: line being "host X" so you can elimante that person. Another high percentage of the time the forwarding user id is closely related to the "bad-address" id. But what about the rest of the cases? My imagination has not come up with a solution other then hoping that mailers that forward mail to the next hop keep around the original address along with the current address and send both addresses back in the error message. This is alot to expect from modular mailers and it doesn't handle the multiple hop case where the forwarding address has a source route (uucp, "%" or RFC822 forms). Anybody got any ideas? -Rudy 16-Dec-83 18:22:04-PST,2333;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Fri 16 Dec 83 18:19:48-PST Date: 16 Dec 1983 17:44:27 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2199 RFCs 886 & 887 Now Available To: Request-for-Comments-List: ************************************************************************ Please note a change in procedures for Request for Comments. A new directory called has been established at the NIC. All new RFCs will be placed only in this directory, and all old RFCs (that were ever on line) have also been moved to this directory. ************************************************************************ New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC. RFC 886: Title: Proposed Standard for Message Munging Author: M. Rose Pages : 16 pathname: RFC886.TXT This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified. RFC 887: Title: Resource Location Protocol Author: M. Accetta Pages : 16 pathname: RFC887.TXT This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet. These public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 19-Dec-83 19:46:01-PST,1708;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Mon 19 Dec 83 19:41:46-PST Date: 19 Dec 1983 17:59:37 PST From: WESTINE@USC-ISIF Subject: MSGGROUP#2200 RFCs 884 and 885 Now Available To: Request-for-Comments-List: ************************************************************************ Please note a change in procedures for Request for Comments. A new directory called has been established at the NIC. All new RFCs will be placed only in this directory, and all old RFCs (that were ever on line) have also been moved to this directory. ************************************************************************ New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC. RFC 884: Title: Telnet Terminal Type Option Author: M. Solomon Pages : 5 pathname: RFC884.TXT This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol. RFC 885: Title: Telnet End of Record Option Author: J. Postel Pages : 2 pathname: RFC885.TXT This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections. Public access files may be copied from the directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. -------