4-May-83 00:21:34-PDT,6982;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 3 May 83 23:17:35-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 4 May 83 1:07 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 4 May 83 0:56 EDT Received: From Usc-Eclc.ARPA by BRL via smtp; 4 May 83 0:48 EDT Date: 1 May 83 12:37:26 EDT (Sun) From: MSGGROUP@usc-eclc.arpa To: msggroup@usc-eclc.arpa Subject: MSGGROUP#2001 SURVEY #1951-#2000 from MSGGROUP.1901-2000.1 Sender: MsgGroup@usc-eclc.arpa Reply-to: MsgGroup-Request@brl.arpa Remailed-date: 3 May 1983 2139-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup@brl.arpa Some of you have missed some of these messages because of failed mail problems. You can FTP the whole file from [ECLC]msggroup.1901-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#1951 SURVEY #1901-#1950 from MSGGROUP.1901-2000.1 6397 chars 14 Dec 1982 0845-PST From: MsgGroup Moderator - Stefferud To MSGGROUP#1957 New RFCs 832 through 839 Now Available 3041 chars 26 Jan 1983 22:45 PST From: Postel@USC-ISIF.ARPA To: "Reques MSGGROUP#1958 New RFC 820 Now Available 934 chars 3 Feb 1983 21:15 PST From: Postel@USC-ISIF To: "Request-for- MSGGROUP#1959 List was down 1/27 -> 2/4 604 chars 4 Feb 83 3:57:30 EST (Fri) From: Michael Muuss To MSGGROUP#1980 Re: more on domains 2158 chars 25 Apr 1983 12:34:36-EST From: Christopher A Kent To MSGGROUP#1996 RE: One man's view of the world (MOBY message) 4680 chars 29 Apr 83 10:52 EST From: Stephen Tihor Received: from BRL by USC-ECLC; Sun 1 May 83 19:16:37-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 1 May 83 19:59 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 1 May 83 19:57 EDT Received: From Su-Score.ARPA by BRL via smtp; 1 May 83 19:26 EDT Date: 1 May 83 16:29:53-PDT (Sun) From: Mark Crispin Subject: MSGGROUP#2002 domains here To: MsgGroup@brl.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The discussion about domains raged on offline from MsgGroup within our own local Stanford Ethernet community. In general, the discussion in the Internet community has been on a much higher level. I've pretty much thrown in the towel on any hope of seeing anything reasonable happen with internet (small "i") routing with our Pup hosts. One good thing may have come out of it, though; it's spurred efforts towards replacing Pup with Internet. The worst problem we have here is the issue of name registries. Politically, nobody wants a "Stanford Pup" name registry. They want a "Stanford" name registry that incorporates both Pup and Internet. In actual implementation, we have a Pup registry that (formerly) included an Internet-only host. We also have an Internet registry that includes several hosts that don't support Internet very well. With the exception of that one Internet-only host and perhaps a single DEC-20, Pup is the preferred (meaning the only one that will work) transport protocol to send mail here. You should start to see the problem. Given a name without any form of qualifier, it was impossible to tell what transport protocol was "right" to use. It is also not feasible to try multiple transport protocols; in the process of setting the name to be the "official" registered name (You don't want us sending you random nicknames, do you?) the transport protocol is pretty much set. Once "Score" becomes "SU-SCORE.ARPA", it is hard to conclude that maybe it should try the Pup host named "Score". Now, let's add this. There are only two DEC-20's for relaying mail between Internet and Pup. There's also a VAX Unix and a DEC-10, but they are not serious relays so far as this is concerned. This means that for the bulk of our community, the Pup naming registry is the primary naming registry. More specifically, it is the Stanford naming registry to these people!! In fact there is information in the naming registry about whether or not a given host supports Pup or Internet. The only problem is, by the time it gets through the TOPS-20 Pup name server query system call, that information has been lost. The TOPS-20 software no longer has any knowledge of how to access host tables; it can only query name servers. The whole premise of my original message was that Score (and its counterpart in "the other end" of Stanford, SUMEX) is in fact the actual Stanford name server, or rather the closest thing that exists today. The Score mailsystem didn't ask to be the name server; it got that way by default. To the Score mailsystem, the Pup registry is merely a resource it can use in finding out hosts it can reach via the Pup protocol. It certainly is not the Stanford name registry, which really doesn't exist. THAT was the crux of our problem. I was accused of a hopeless pro- Internet bias to the determent of Stanford. I (and I suspect a few others) would like to wring the neck of the next person who accuses ANYBODY of a "pro-Internet bias" for trying to implement a reasonable form of internet (with a small "i") mailing. I hope this story can be a lesson to some of us, on how purely political considerations can get in the way of internet mailing. For me, it says that there are a number of theories on how to do internet mailing: . the users want to say "user@" or some other such consistant interface. They don't care how it gets there, they just want it to get there and they want their recepient to be able to reply to them. [Note that I am NOT denigrating CSnet's interface; but I am saying that to be right the CSnet interface has to apply to all addresses. There should not be addresses in "CSnet format" vs. "Internet format" vs. "UUCP format".] . the internet software engineers want a consistant interface too, and feel it is best done by coercing all the networks to use some common address scheme. . the individuals in charge of the protocols for the various networks and various other bureaucrats are adamantly opposed to anything which breaks the sancity and purity of their network protocols. I have seen this on more networks of more different types in more places than I care to list. The Stanford Pup people are by no means the only, or the worst, offenders! Perhaps I've become too cynical. I really am starting to think that the only people who should specify internet mailing are those who implement it. Only they can be objective enough to balance the pros and cons of the individual networks to something that is workable. Those others who object to the specification are welcome to elect not to implement it and reject internet mail traffic. If they lose users to sites that support the internet specification, it's their problem. How much of this sounds familiar? -- Mark -- ------- 2-May-83 13:33:22-PDT,1105;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 2 May 83 13:30:13-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 2 May 83 13:59 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 2 May 83 13:49 EDT Received: From Office-3.ARPA by BRL via smtp; 2 May 83 12:24 EDT Date: 2 May 83 09:25 (PDT) From: RICH.GVT@office-3.arpa Subject: MSGGROUP#2003 Re: [Paul Milazzo: Re:] What is a domain? To: msggroup@brl.arpa Message-ID: <[OFFICE-3]GVT-RICH-2C3QN> Paul is partially right but is still guilty, I think, of confusing name-server/naming-authority domains with transport-mechanism "domains". In actuality, the UUCP Name Server would probably relay requests (or return a pointer) to lower-level servers for the indivudual UUCP sub-nets. "UUCP" would only be a top-level domain and might be unable to resolve individual names to addresses at all, but would only be able to assist in finding a subnet name server that could. [Actually, "USA" would probably be the top-level domain, and UUCP, ARPA, etc., second-level domains.] Rich Zellich 2-May-83 16:42:00-PDT,2989;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 2 May 83 16:39:34-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 2 May 83 16:19 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 2 May 83 15:49 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 2 May 83 15:42 EDT Date: 2 May 83 14:31:02-EDT (Mon) From: Mark Horton Subject: MSGGROUP#2004 UUCP as a domain Message-Id: <8305021942.AA00602@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.337/3.26) id AA00602; 2 May 83 12:42:29 PDT (Mon) Via: cbosgd.UUCP (V3.94 [3/6/82]); 2-May-83 14:31:04-EDT (Mon) To: msggroup@brl.arpa Paul Milazzo is worried about disconnected UUCP networks and feels that you can't treat UUCP as a single domain because there might be several disconnected UUCP networks. In theory, this could be a valid concern. In practice, it's not a problem. While I'm sure there are sites in remote locations (both geographically and in the who-knows-who sense) that are only connected via a UUCP transport to a couple of local sites which don't go anywhere, we don't count such networks. There is one connected network of well over 1000 (current estimates run around 1500) sites, all of which run UUCP. When we refer to the UUCP domain, we are talking about this connected graph. I don't think anyone would argue that it is not the "main UUCP network". Also, you have to consider that, when some site turns up that is not connected in, it's very easy to hook them in by just adding their phone number (and a uucp login and password and a few other pieces of information, like the baud rate and any special protocol needed to get through a front end switch, for instance) to a disk file on one system that is already connected in. This is why UUCP (as a domain) is so big - it's so easy to connect in. No messing with getting permission from DOD or a leased phone line from TPC. All you need is a dialup and somebody willing to call you, or a dialer and a site willing to be called. (You also need software, which comes with UNIX and is also available for VMS under various UNIX emulators and at least one Z80. Thus, most, but not all, sites in the UUCP domain run UNIX.) Since there are now UUCP sites in all major metropolitan areas in the USA plus many in Canada, Europe, and Australia, it's not usually too hard to find somebody to hook up to. When referring to the UUCP domain, we're referring to this connected graph of sites. The fact that the transport mechanism also happens to be UUCP for many (not all, as it turns out) just causes confusion. (Yes, it's been suggested that another name be used, but nobody has come up with one that isn't already being used that is as descriptive as UUCP.) The domain is defined by "all sites reachable from (say) ucbvax via mail using the a!b!...!z!user syntax". Eventually that definition will be replaced by "all sites in the routing table". 2-May-83 12:35:46-PDT,1250;000000000001 Return-path: Mail-from: DECNET site ECLA rcvd at 2-May-83 1227-PDT Mail-from: DECNET site ECLC rcvd at 2-May-83 1226-PDT Received: from MIT-MC by USC-ECLC; Mon 2 May 83 12:22:22-PDT Date: 2 May 1983 15:00:43 EDT (Monday) From: Ed Frankenberry Subject: MSGGROUP#2005 Re: [MsgGroup Moderator - Stefferud : [Stephen Tihor : [Daemon : Undeliverable mail]]] In-Reply-to: Your message of 2 May 1983 14:05 EST To: Stephen Tihor Cc: postmaster@BBN-UNIX.ARPA, msggroup-request@MIT-MC.ARPA Steve, With our current mail software, there is only one class of messages. They are all considered to be important so an indication is returned when the mail couldn't be delivered to any one of the expanded recipients. The timeout period can be adjusted at this end, but there is no standard header field to indicate "if undeliverable, do not return to sender." The best I can suggest for the time being is to specify the list maintainer in the "reply-to:" field, or have your mailer indicate a null reverse path (smtp "mail from:<>") when sending a message so that the return-path will be empty. Ed Frankenberry 2-May-83 15:42:16-PDT,813;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 2 May 83 15:39:58-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 2 May 83 16:33 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 2 May 83 16:26 EDT Received: From Brl-Vgr.ARPA by BRL via smtp; 2 May 83 16:21 EDT Date: 2 May 83 15:22:49 EDT (Mon) From: Mike Muuss To: Mark Horton cc: MsgGroup@brl.arpa Subject: MSGGROUP#2006 Re: Name servers My understanding was that there had to be a name server at the JUNCTION of the InterNet and the non-InterNet network, which would return the InterNet address of the "relay" macine for mail forwarding. What happens behind that "relay" machine is of no real concern to the InterNet mechanisms. -Mike 3-May-83 08:06:33-PDT,2341;000000000001 Return-path: <@rand-relay:milazzo.rice.Rice@rand-relay> Received: from BRL by USC-ECLC; Tue 3 May 83 08:05:59-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 3 May 83 9:46 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 3 May 83 8:44 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 3 May 83 8:42 EDT Date: 3 May 83 02:03:31 CDT (Tue) From: Paul.Milazzo Return-Path: Subject: MSGGROUP#2007 Re: UUCP as a domain To: MsgGroup@brl.arpa Message-Id: <1983.05.03.0203.610.01414@rice> In-Reply-To: Everyone's enthusiastic responses of 2 May 83 Via: Rice; 3 May 83 5:36-PDT "Paul is partially right but is still guilty, I think, of confusing name-server/naming-authority domains with transport-mechanism 'domains'. In actuality, the UUCP Name Server would probably relay requests (or return a pointer) to lower-level servers for the indivudual UUCP sub-nets." - Rich Zellich I am certainly often confused by domains. My point is that the set of UUCP sites is likely to be (incorrectly) viewed by the Internet as a sub-domain of ".ARPA". Thus there may be no lower-level server to which to refer the request, since the necessary server might be accessible only through another Internet site. "While I'm sure there are sites in remote locations (both geographically and in the who-knows-who sense) that are only connected via a UUCP transport to a couple of local sites which don't go anywhere, we don't count such networks. There is one connected network of well over 1000 (current estimates run around 1500) sites, all of which run UUCP." - Mark Horton I referred not to completely isolated networks, but rather to networks connected to an Internet host not in UUCP contact with the "main UUCP network." I agree that the existence of such networks is hypothetical, but I am concerned because the current theory will not permit them to exist in the future. One can certainly conceive of an organization wishing to employ low-cost local networking technology, but owning one machine with a high-speed link to far-away places. Incidentally, my UUCP routing table lists 1320 distinct sites, although a few are apparent duplications such as "rochester" and "rocheste". Paul 3-May-83 13:11:19-PDT,1500;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 3 May 83 13:01:08-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 3 May 83 13:59 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 3 May 83 13:47 EDT Received: From Nyu.ARPA by BRL via smtp; 3 May 83 13:36 EDT Date: 3 May 83 13:30 EST From: Stephen Tihor To: milazzo.rice@rand-relay.arpa Subject: MSGGROUP#2008 RE: UUCP as a domain Cc: MsgGroup@brl.arpa Message-ID: <1234A2EB0.051C0031;1983@CMCL1.NYU.ARPA> In-Reply-To: <1983.05.03.0203.610.01414@rice> ; Message of 3-MAY-1983 10:41 from Paul.Milazzo Received: from BRL by USC-ECLC; Wed 4 May 83 00:20:06-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 4 May 83 2:42 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 4 May 83 2:40 EDT Received: From Purdue.ARPA by BRL via smtp; 4 May 83 2:33 EDT Date: 4 May 83 01:31:13-EST From: Christopher A Kent Reply-to: cak@purdue.arpa To: namedroppers@sri-nic.arpa, Header-People@mit-mc.arpa, MsgGroup@brl.arpa Subject: MSGGROUP#2009 why are these separate lists? Hello.... I will receive this message twice. No doubt there are some of you that will receive it thrice. What I'm curious about is why. I have just spent a few most interesting hours catching up on about a week's worth of large messages dealing with SMTP/Internet addressing issues, relays, gateways, domain, nameservers, and the like. When it came time to file all this in an orderly fashion, I was faced with a dilemma; the mail was all centered around the same broad topic, but appeared in two very separate lists! I usually file Header-People mail one place, and NameDroppers another; tonight I felt like it should all go in the same place. I don't know what MsgGroup started out for, since I've never been a member. I believe that Header-People wants to deal with mail headers and their formats and evolution, i.e., the "Mail Police", as Dave Mills would put it. NameDroppers was formed (to the best of my recollection) to try to hammer out the issues of creating domains and dealing with them in getting everyone in the world to be able to send mail to everyone else. The groups seem to be bleeding all over one another. I don't find this objectionable, but am concerned that there are folks out there that should be seeing some of these messages that aren't, and we are therefore missing their valuable contributions. Perhaps we should merge these lists into a "Mail-Concerns@foo" (who can support the traffic?) and eliminate this problem. Comments? Cheers, chris 4-May-83 17:10:49-PDT,1098;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 4 May 83 16:53:42-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 4 May 83 18:58 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 4 May 83 18:48 EDT Received: From Su-Score.ARPA by BRL via smtp; 4 May 83 18:39 EDT Received: from Diablo by SCORE with Pup; Wed 4 May 83 15:40:55-PDT Date: 4 May 1983 15:40-PDT (Wednesday) To: cak@purdue.arpa Cc: namedroppers@sri-nic.arpa, Header-People@mit-mc.arpa, MsgGroup@brl.arpa Subject: MSGGROUP#2010 Re: why are these separate lists? In-reply-to: Your message of 4 May 1983 01:31:13-EST. From: Keith Lantz I have a similar problem, due to being on header-people and msggroup. I am actually more interested in being on namedroppers, now that I hear of it, so: (1) Could whoever add me to same? (2) Strikes me that it (namedroppers) is precisely the domain, as it were, for these discussions. Perhaps the interested parties from the other lists could simply make sure that they are now on namedroppers? Keith 5-May-83 10:32:03-PDT,2306;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 5 May 83 10:29:42-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 5 May 83 10:44 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 5 May 83 10:36 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 5 May 83 10:32 EDT Date: 5 May 83 10:06:53 EDT (Thu) From: Mark Horton Subject: MSGGROUP#2011 Re: why are these separate lists? Message-Id: <8305051406.AA15594@cbosgd.UUCP> Received: by cbosgd.UUCP (3.320/3.7) id AA15594; 5 May 83 10:06:53 EDT (Thu) Received: by UCBVAX.ARPA (3.339/3.27) id AA11925; 5 May 83 07:32:33 PDT (Thu) To: cak@purdue.arpa Cc: Header-People@mit-mc.arpa, MsgGroup@brl.arpa, namedroppers@nic.arpa This debate about people getting 2 or 3 copies of everything is amusing. I can't resist pointing out that if you were using Usenet (=Netnews, and !=UUCP) instead of mailing lists, this problem never would have arisen. Only one copy of each message goes to each system, tagged with the appropriate newsgroups, e.g. this message might be tagged net.mail.namedroppers,net.mail.header-people,net.mail.msggroup (assuming the same names were used instead of something descriptive of the separate functions of the groups). Each reader then only sees it once, not twice or thrice. (We do get duplicates in Usenet, too, but most of them seem to be caused by arpanet mail that got half transmitted and then aborted before completion). I'll repeat my invitation to any sites, ARPANET or otherwise, who want to join Usenet - drop me a line and I'll point you at a nearby contact. If you run UNIX, the code is all written; if you run something else, you'll have some work to do. (Anybody want to produce a TWENEX implementation?) For all the comments I've heard about how the ARPANET mail technology is supposed to be better than Usenet for mass mailings (my opinion hasn't changed) I'm surprised that the very implementors of the mail systems are unable to solve a problem as simple as multiple copies of the same mail message. If nothing else, why not just have one mailing list MAIL@MC.ARPA to which we all belong? I haven't seen any qualitatively different discussions in MsgGroup or Header-People. Mark Horton 8-May-83 06:21:37-PDT,1471;000000000001 Return-path: <@MIT-MC:OLE@sri-csl> Received: from BRL by USC-ECLC; Sun 8 May 83 06:19:54-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 May 83 8:53 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 May 83 8:48 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 8 May 83 8:21 EDT Date: 5 May 1983 1606-PDT Sender: OLE@sri-csl.arpa Subject: MSGGROUP#2012 All that irrelevant information! From: Ole J. Jacobsen To: MSGGROUP@mit-mc.arpa Cc: HEADER-PEOPLE@mit-mc.arpa Message-ID: <[SRI-CSL] 5-May-83 16:06:41.OLE> I sit here reading a huge backlog of mail at 300 baud and what do I see? Every message has this strange "Received:" field saying stuff like: "from BRL by SRI-CSL via ARPANET/MILNET with TCP/SMTP; Fri 29 Apr 83 12:59-PDT From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 22:22 EDT From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 22:15 EDT From Mit-Mc.ARPA by BRL via smtp; 27 Apr 83 22:10 EDT via:.....etc" Now, can anyone tell me what use this is (apart from those who gather statistics on mail and delivery times) and why it sits there as an apperently required field? And is it not the case that all this routing stuff wil grow and grow forever as the network grows (domains or not)? Is it not enough that my mailer knows? (Ther is a field in every msg that says: "Return-Path: MAILER at SRI-CSL") Maybe this is a very naive question, enlighten me please! 5-May-83 22:19:56-PDT,577;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 5 May 83 22:10:22-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 6 May 83 0:32 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 6 May 83 0:22 EDT Received: From Usc-Isif.ARPA by BRL via smtp; 6 May 83 0:13 EDT Date: 5 May 1983 1952-PDT From: POSTEL@usc-isif.arpa Subject: MSGGROUP#2013 Irrelevant Header Lines To: msggroup@brl.arpa OLE: Why not have your message reading program have an option to suppress printing header lines you find irrelevant? --jon. ------- 7-May-83 08:56:03-PDT,1688;000000000001 Return-path: <@MIT-MC,@su-dsn:greep@su-dsn> Received: from BRL by USC-ECLC; Sat 7 May 83 08:44:32-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 7 May 83 11:14 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 7 May 83 10:58 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 7 May 83 10:56 EDT Date: 5 May 1983 17:41-PDT (Thursday) To: Ole J. Jacobsen Cc: MSGGROUP@mit-mc.arpa, HEADER-PEOPLE@mit-mc.arpa Subject: MSGGROUP#2014 Re: All that irrelevant information! In-reply-to: Your message of 5 May 1983 1606-PDT. <[SRI-CSL] 5-May-83 16:06:41.OLE> From: greep@su-dsn..arpa It really is useful for mail system maintainers to have that information around. Certainly the average user should not have to see it if he doesn't want to. There is no reason why mail-reading programs cannot filter out that information, and I think some of them do. (Most people aren't interested in seeing message-id's either, but they can be useful too.) However, there is no place to put the information other than in the message itself, and the way messages are defined, header fields all come at the beginning (before the body of the message). So the moral is: (1) find out if your mail program has a way to hide the fields you don't want to see; (2) if not, find out why not and maybe try to get someone to add this feature. (I won't suggest doing it yourself for fear of being deluged by comments from the rest of the world about how it shouldn't be necessary for each user to do this himself. I agree.) (If you were running Unix, it would be very easy to do this with an existing program, "egrep".) 9-May-83 09:36:04-PDT,817;000000000001 Return-path: <@MIT-MC:cak@purdue> Received: from BRL by USC-ECLC; Mon 9 May 83 09:33:30-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 9 May 83 11:28 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 9 May 83 11:24 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 9 May 83 10:10 EDT Date: 5 May 1983 20:43:22-EST From: Christopher A Kent Reply-to: cak@purdue.arpa To: MSGGROUP@mit-mc.arpa, OLE@sri-csl.arpa Subject: MSGGROUP#2015 Re: All that irrelevant information! Part of RFC82[23]; thank Dave Crocker. The idea is that if your mailer *doesn't* know how to get back, you can construct a return path, in case the Return-Path didn't get included. Neat, huh? Get your mail reader to be able to not display junk lines like this. That's what I'm doing. chris 7-May-83 19:43:13-PDT,1737;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 7 May 83 19:40:14-PDT Date: 7 May 83 22:19:25 EDT (Sat) From: Einar Stefferud (DARCOM/consultant) To: msggroup@Brl.ARPA cc: msggroup-request@Brl.ARPA Subject: MSGGROUP#2016 Review of MsgGroup list changes Here is a review of changes made during the recent episode of MsgGroup activity. I may have lost some folks who did not want to be removed. If you know any of the deleted folks who want to stay on, please let me know. If all is well with this list, please do not respond. Thanks - Stef < REMOVAL FROM v109 > ADDED to get v117 (ignoring inbetween) < "/ofc/stef/msggroup.109" > "/Ofc/stef/msggroup.117" < Hampton@ACC, < Swernofsky@BBNA, > bmirrer@BBN-UNIX, < Mark@BERKELEY, < INGVAX.fogg@Ucb-C70, > INGVAX.fogg@Berkeley, < amd70!pn@Ucb-C70, > amd70!msggroup@Berkeley, > jalbers@bnl, > hnij@BNL, < Griffin@CMU-20c, < ECG.ALA@Dec-Marlboro, > MMJohnson.CIM_Serv@HI-MULTICS, > Hazzard.CIM_Serv@HI-MULTICS, > DBrown.TSDC@HI-MULTICS, < Agarwal@ISID, < JTSchudy@USC-ISIE, > jkreynolds@Usc-Isif, > PCO-disty@MIT-MULTICS, > Hdt@MIT-MC, < PROCEP@MIT-MC, < JFW.MIT-CCC@MIT-MC, < EB.Mike@MIT-MC, < MsgGroup@MITRE-BEDFORD, > NCRAWFORD@OFFICE-10, > cak@Purdue, > llp@Purdue, > inuxa!ram@PURDUE, > wft@Purdue, < davec.Tektronix@Rand-Relay, > MCGREGOR.HP-LABS@RAND-RELAY, > davec.Tektronix@RAND-RELAY, < Aloha@SRI-CSL, < JPM@SU-AI, < CSD.Hahn@SU-SCORE, < CSD.Harkness@SU-SCORE, < Admin.MDP@SU-SCORE, < Reid@SU-SCORE, < FCC-MsgGroup.FCC@UDEL-RELAY, > RSanders.Pascalx@USGS2-MULTICS, < LSchwarz.Activate@Usgs1-Multics, 8-May-83 01:25:16-PDT,3741;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 8 May 83 00:57:50-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 May 83 3:24 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 May 83 3:17 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 8 May 83 3:09 EDT Date: 8 May 83 00:03:11 PDT (Sun) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2017 Basic Message Format Message-Id: <8305080711.AA15723@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA15723; 8 May 83 00:11:55 PDT (Sun) To: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: DCrocker@udel-relay.arpa, Postal@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Basic Message Format - 1 - "Structure of a Message" My conception of what the structure of an electronic mail message should be is based on the basic message format used by military communications. A basic military message consist of three parts: the "heading", "text", and "ending". HEADING Beginning Procedures Message Heading (Addresses, etc) TEXT Body of Message ENDING Ending Procedures The "beginning procedures" and "ending procedures" are dependent upon the transmission medium and change as the message is passed from one type of circuit to another. Applying the "postal letter" model and generalizing the above I have derived the following "basic message structure": HEADING Transmission Heading Envelope Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Envelope Ending Transmission Ending Using the analogy of a postal letter, the Message Heading, Message Text, and Message Ending are the "letter"; the Envelope Heading and Envelope Ending are the "envelope"; and the Transmission Heading and Transmission Ending are the "mailbag". The "basic message" consists of the Message Heading, Message Text and Message Ending. These parts are ones that the drafter and his mail formatting program create. A "posted message" consists of the Envelope Heading, Message Heading, Message Text, Message Ending, and Envelope Ending. The "message envelope" consisting of the Envelope Heading and Envelope Ending (if defined) contains elements of information added by the post office ("originating host") which accepts the message for transmission. This is where the first postmark ("Message-Id") is added. Post offices passing the message along ("relaying hosts") may or may not add their postmark ("Received"). The message may be put into different mailbags (Transmission Headings and Transmission Endings such as SMTP, UUCP) as it is passed along between different post offices. To ensure that the message is delivered each post office handing the message, takes the message of one mailbag before putting it in another mailbag. (Even though it is possible to put one mailbag inside another, the next post office may not be able to read what instructions are written on the inner mailbag.) Applying the above model, I find that all messages have a text (a message has to say something); that military messages have Transmission Heading, a Message Heading, a Text, and a Transmission Ending; and that Internet messages (RFC 822) have a heading that has a mix of Envelope Heading and Message Heading elements, a Text, and no ending. The Internet message format (RFC 822) defines elements of the Message Heading and some elements of the Envelope Heading. Amateur Radio messages have elements of the Transmission Heading, Message Heading, Message Ending, and Transmission Ending. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 8-May-83 03:05:13-PDT,1519;000000000001 Return-path: <@rand-relay:Stef.UCI.UCI@rand-relay> Received: from BRL by USC-ECLC; Sun 8 May 83 03:03:37-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 May 83 5:28 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 May 83 5:24 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 May 83 5:12 EDT Date: 8 May 83 01:48:36 PST (Sun) From: Stef.UCI@rand-relay.arpa Return-Path: Subject: MSGGROUP#2018 Re: Basic Message Format To: wcwells%Topaz.CC@ucb-vax.arpa Cc: MsgGroup@Brl, header-people@Mit-Mc, cbosgd!mark@Ucb-Vax stef.UCI@Rand-Relay In-Reply-To: Your message of 8 May 83 00:03:11 PDT <8305080711.AA15723@UCBVAX.ARPA> Via: UCI; 8 May 83 1:52-PDT I can see a great deal of value in separating between the "message" (header + text), the "envelope", and the "mailbag" but I am not sure what adding separate endings for each of these will do for us in our computer network mail systems. I can see why the military might do that to help keep things separated in the TWX environment where the transmission facilities are not organized to bound these entities naturally. When all messages, envelopes, and transmission signals are carried "inband" on the same channel using otherwise undistinguishable text strings, all those "endings" must be very useful. But, we do use various delimiters to separate messages in files, after they have been transmitted, so I suppose we do find use for "endings" in that context. Stef 9-May-83 00:46:58-PDT,3680;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 9 May 83 00:29:03-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 9 May 83 2:56 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 9 May 83 2:45 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 9 May 83 2:19 EDT Date: 8 May 83 22:56:15 PDT (Sun) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2019 Re: Basic Message Format Message-Id: <8305090622.AA11023@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA11023; 8 May 83 23:22:46 PDT (Sun) To: Stef.UCI@rand-relay.arpa Cc: DCrocker@udel-relay.arpa, MsgGroup@brl.arpa, POSTEL@usc-isif.arpa, header-people@mit-c Basic Message Format - 1 - "Structure of a Message" - Remarks In reply to: Date: 08 May 83 01:48:36 PST (Sun) From: Stef.UCI@Rand-Relay I can see a great deal of value in separating between the "message" (header + text), the "envelope", and the "mailbag" but I am not sure what adding separate endings for each of these will do for us in our computer network mail systems. I agreed that some systems may not use or need more than one type of ending. One of the simplest endings I can think of is no "message ending" and an "end-of-file" for the "envelope ending" and "transmission ending". However, separate endings have their uses. The "message ending" is at the user application level. In some systems the "message ending" contains the signature. I have also seen it used to repeat critical parts of the text (for example, all numeric fields in a telegram) as a "confirmation" that those parts have not been garbled in transmission. One of the most significant uses of the ending part of a message is to ensure that the message has been completely transmitted. In some systems, a "message ending" string indicates to the reader that he has received the end of the message. For various reasons, hosts out there in netland like to periodically truncate messages. Clerks have also been known to lose the last page of a message when they reproduce it offline. If the end of message is broken off at a logical point, the reader may have no indication that he has an incomplete message. If you are interested in reliable communications, using some type of "message ending" indicator at the user level is a very good idea. The "envelope ending" is used by the mail forwarding program(s) of "relaying hosts". It may also provide useful information for the user when things go wrong. The "originating host" can use the "envelope ending" to indicate the end of a "posted message". When a "postmark" , containing unique identification information, is repeated at the beginning and end of a message, you can test to see if the end of the message just read matches the beginning of the message. Using an "envelope ending" in this manner becomes important when messages are spooled for storage in a single file or batched (stacked) to be sent as a single transmission. If the middle of a string of messages is lost, repeating a "postmark" at the beginning and end of message can tell your mail forwarder that you have lost the middle. (If you do not use message identification at the beginning and end of each message in a stack, how can you be sure that end-of-message is not the end-of-message of the following message?) The "transmission ending" is use by the transport system. The simpliest "transmission ending" is a delimiter or string to indicate the end-of-transmission. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 9-May-83 18:52:42-PDT,5134;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 9 May 83 18:51:19-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 9 May 83 21:02 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 9 May 83 20:59 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 9 May 83 20:47 EDT Date: 9 May 83 17:44:16 PDT (Mon) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2020 Re: Basic Message Format Message-Id: <8305100051.AA21946@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA21946; 9 May 83 17:51:16 PDT (Mon) To: DDEUTSCH@bbna.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa Basic Message Format - 1 - "Structure of a Message" - Remarks In reply to: Date: 9 May 1983 1217-EDT From: DDEUTSCH@BBNA Stef is absolutely right when he points out that military message procedures have a lot to do with their Telex-like nature. For example, a single long message might be transmitted in several smaller pieces. In that case, it is necessary to mark the last piece as being the end. You also argue that "endings" are needed in order to detect transmission errors. However, the need for doing this goes away with the use of real OSI systems. If you believe in the OSI model, the session layer provides error-free data transmission. That means that message protocols, which reside above the session layer, do not have to do error checking. However, a message protocol must make sure that all the pieces of a message are transmitted and received. That does not require any "ending" in the message content or envelope data; it requires that the sending protocol entity be able to indicate when the last piece of a data is being or has been sent and that the receiving protocol entity be able to indicate that it has received the last piece of data. I was not trying to address the problem of breaking a single long message into sections and transmitting each section as separate "posted-message". When restrictions on the maximum length of a basic message are required, the user can be told to break his narrative message into sections with each section identified in the text as "SECTION .... OF ..." (or a gateway mail forward might do that when entering a long message into that type of network). Though I think you are right in saying that when a message is transmitted in that manner, that "end-of-message" indicator in the Message Ending would come at in the Message Ending of the last section transmitted. The main point of my article on "basic message structure", is that there are three functional levels in transporting a message from user A to user B: basic message (the "letter") - User Level posted message (the "envelope") - Host/Mail Forwarder Level network message (the "mailbag") - Network Level (Yes, I am aware that the "network message" may be a lot of little packets being transmitted separately. In some systems (eg. UUCP) it could also be a set of "posted message" which have be batched to be transmitted as a single "network message".) I will admit that the Network Level should not be of concern to the mail system, however we should be aware that it exists and that some mail systems require users to work at this level. Thus, I have included it in my generalized model. I can believe in the OSI model, but until it is implemented everywhere, I do not trust our growing world of interconnected networks to function perfectly. Not all of these interconnected systems have hardware and software that function perfectly all the time. Even within the ideal OSI environment, software errors and hardware failures are going to occur. Also note that errors not only occur online, but may occur offline as well (for example, a clerk loses part of the message while reproducing it before it is delivered to the reader). If we are going to design a universal message format (which appears to be the goal of the Internet message format), then the basic message format should be designed to ensure that the message sent by the drafter is the same one that is received by the reader; or if it is not complete the reader should have some indication that something is missing. Military communications are particularly concerned about reliability. For example, I might be in a combat situation and order a strike on my current location as follows: Fire on my current position at 1800. Since I am planning to leave my current position before 1800, I would be in a very unhappy situation, if the missile I ordered was fired immediately because the reader of my message only received the first line: Fire on my current position Thus, until all systems and networks connected to the Internet World are functioning perfectly under the OSI model, I think I still have a good argument for using a user level end-of-message indicator in a Message Ending of my basic message structure. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 9-May-83 18:52:42-PDT,1036;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Mon 9 May 83 18:47:55-PDT Date: 9 May 1983 1820-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#2021 RFC 849 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 849: Title: Suggestions for Improved Host Table Distribution Author: M. Crispin Pages: 2 pathname: [SRI-NIC]RFC849.TXT This memo make a few suggestions for different procedures for distributing host table information. This memo is indended to stimulate thought and discussion, it does not propose or establish any standard. 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. ------- 9-May-83 20:11:09-PDT,2466;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 9 May 83 20:06:39-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 9 May 83 22:17 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 9 May 83 22:13 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 9 May 83 21:55 EDT Date: 9 May 83 18:51:58 PDT (Mon) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2022 Message Identification Message-Id: <8305100159.AA22480@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA22480; 9 May 83 18:59:50 PDT (Mon) To: DDEUTSCH@bbna.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa In reply to: Date: 9 May 1983 1217-EDT From: DDEUTSCH@BBNA ..., I'd like to point out that a message-id is not a postmark, and that there are many kinds of message-ids. A message-id, associated with the content of a message, refers to a communication from the message's originator to its recipients. If I transmitted the exact same message more than once, it would still have the same message-id. On the other hand, the message transfer system uses identifiers for message envelopes. These ids are different from the ids in the message content. For instance, in the example where I transmitted the exact same message more than once, its message-id would remain the same while its envelope would have a new id every time the message was sent. The purpose of an id is to identify a unit of data; the purpose of a postmark is to record the path it has taken. I think we agree. Did I get lost in my use of words? I sometimes use the term "message identification" to mean "message identification in general" Here is how I think we should identify message: Basic message - User Level: Originator ("From:") and Date-Time ("Date:") Posted message - Host/Mail Forwarding Level Originating host postmark ("Message-ID:"). Transmission Identification - Network level: Whatever your network requires. Note that if the same basic message is retransmited by the user, a new "Message-ID" is assigned by the mailer. (See definition in RFC 822). Unfortunately, most mailers do not let the user retransmit the same message with the same date, but assign a new date. If they did, we could trap duplicates. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 ~e 9-May-83 20:11:08-PDT,860;000000000001 Return-path: <@SU-DSN:greep@su-dsn> Received: from BRL by USC-ECLC; Mon 9 May 83 20:04:39-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 9 May 83 22:18 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 9 May 83 22:13 EDT Received: From Su-Dsn.ARPA by BRL via smtp; 9 May 83 21:56 EDT Date: 9 May 1983 18:58-PDT (Monday) To: wcwells%Topaz.CC@ucb-vax.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa Subject: MSGGROUP#2023 Re: Basic Message Format In-reply-to: Your message of 9 May 83 17:44:24 PDT (Mon). <8305100054.AA21995@UCBVAX.ARPA> From: greep@su-dsn.arpa I got two copies of your message that have identical bodies but different "date" and "message-id" fields. If you are really trying to send two copies, please don't. If not, maybe your message system is doing something you don't know about. 9-May-83 20:41:02-PDT,3792;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Mon 9 May 83 20:38:10-PDT Date: 9 May 1983 1939-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#2024 RFC 854 Through 861 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. Eight RFCs relating to the TELNET protocol for Remote Terminal Access are now available. These memos document the basic protocol and the most commonly used options. These memos obsolete earlier versions including those in the Internet Protocol Transition Workbook (IPTW). RFC 854: Title: Telnet Protocol Specification Author: J. Postel & J. Reynolds Pages : 15 pathname: [SRI-NIC]RFC854.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 18639. RFC 855: Title: Telnet Option Specifications Author: J. Postel & J. Reynolds Pages : 3 pathname: [SRI-NIC]RFC855.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 18640. RFC 856: Title: Telnet Binary Transmission Option Author: J. Postel & J. Reynolds Pages : 4 pathname: [SRI-NIC]RFC856.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 15389. RFC 857: Title: Telnet Echo Option Author: J. Postel & J. Reynolds Pages : 5 pathname: [SRI-NIC]RFC857.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 15390. RFC 858: Title: Telnet Supress Go Ahead Option Author: J. Postel & J. Reynolds Pages : 2 pathname: [SRI-NIC]RFC858.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 15392. RFC 859: Title: Telnet Status Option Author: J. Postel & J. Reynolds Pages : 3 pathname: [SRI-NIC]RFC859.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 31154 = RFC 651. RFC 860: Title: Telnet Timing Mark Option Author: J. Postel & J. Reynolds Pages : 3 pathname: [SRI-NIC]RFC860.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 16238. RFC 861: Title: Telnet Extended Options List Option Author: J. Postel & J. Reynolds Pages : 2 pathname: [SRI-NIC]RFC861.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet are expected to adopt and implement this standard. This specification obsoletes NIC 16239. 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. ------- 9-May-83 21:20:34-PDT,3521;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Mon 9 May 83 21:09:40-PDT Date: 9 May 1983 2005-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#2025 RFC 862 Through 868 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. Seven RFCs describing the simple server protocols for: Echo, Discard, Character Generator, Quote of the Day, Active Users, Daytime, and Time functions are now available. These functions are used primarily for debugging. The implementation of any of these services on any particular host is elective. Each of the protocols is defined for use via TCP and via UDP. RFC 862: Title: Echo Protocol Author: J. Postel Pages : 1 pathname: [SRI-NIC]RFC862.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. This specification obsoletes RFC 347. RFC 863: Title: Discard Protocol Author: J. Postel Pages : 1 pathname: [SRI-NIC]RFC863.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. This specification obsoletes RFC 348. RFC 864: Title: Character Generator Protocol Author: J. Postel Pages : 3 pathname: [SRI-NIC]RFC864.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. This specification obsoletes RFC 429. RFC 865: Title: Quote of the Day Protocol Author: J. Postel Pages : 1 pathname: [SRI-NIC]RFC865.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. RFC 866: Title: Active Users Protocol Author: J. Postel Pages : 1 pathname: [SRI-NIC]RFC866.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. RFC 867: Title: Daytime Protocol Author: J. Postel Pages : 2 pathname: [SRI-NIC]RFC867.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. RFC 868: Title: Time Protocol Author: J. Postel & K. Harrenstien Pages : 2 pathname: [SRI-NIC]RFC868.TXT This RFC specifies a standard for the ARPA Internet community. Hosts in the ARPA Internet that choose to provide this service are expected to adopt and implement this standard. This specification obsoletes IEN 142. 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-May-83 14:50:47-PDT,1201;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 10 May 83 14:49:45-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 10 May 83 16:51 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 10 May 83 16:42 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 10 May 83 16:41 EDT Date: 9 May 83 23:22:31 PDT (Mon) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2026 duplicate message Message-Id: <8305100630.AA25379@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA25379; 9 May 83 23:30:45 PDT (Mon) To: greep@su-dsn.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa If you are on both MsgGroup and header-people you may have received two copies of the same text with different dates due to the fact that I mistyped the host name for the headers-people mailbox the first time the message was sent. To ensure delivery to people in the headers-people list who are not in the MsgGroup list the message was later resent to headers-people. Sorry, my mailer does not permit me to retransmit with the same date (dates are automatically generated). Here is another vote for combining these two mailing lists into one. Bill Wells 10-May-83 21:49:08-PDT,7372;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 10 May 83 21:38:05-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 10 May 83 23:13 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 10 May 83 23:08 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 10 May 83 23:01 EDT Date: 10 May 83 18:55:07 PDT (Tue) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2027 Basic Message Format Message-Id: <8305110206.AA01132@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA01132; 10 May 83 19:06:16 PDT (Tue) To: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: DCrocker@udel-relay.arpa, POSTAL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Basic Message Format - 1 - "Structure of a Message" Version 2 - 10 May 83 1. Introduction. The Internet Mail Protocols as published in November 1982 provided us with a standard for the format of electronic mail message (RFC 822 - Standard for the Format of ARPA Internet Text Messages) and a method of transport mail in a packet network transmission channel (RFC 821 - Simple Mail Transfer Protocol). In view of the the number of non-OSI networks that are connected to the Internet I perceive a need for message structure model that is not only consistent with Internet mail format, but also applicable to existing non-OSI network message systems. The message structure defined herein, includes the concepts of "transmission envelopes" and "batch envelopes" in addtion to "message envelope" and "message content". I have also noticed that, although the Internet mail format standard (RFC 822) says it is not concerned with defining the "message envelope", many of the header fields defined in RFC 822 are functionally "message envelope" fields. Thus I see a need to identify which fields are "message envelope" fields and which are "message content" fields. My conception of the a generalized electronic mail message structure is based on the basic message format used by military communications. A basic military message consist of three parts: the "heading", "text", and "ending". HEADING Beginning Procedures Message Heading (Addresses, etc) TEXT Body of Message ENDING Ending Procedures The heading beginning procedures are a mix of message envelope information and transmission information. The ending procedures are a mix of user information, message envelope information, and transmission information. The "message content" consists of the message heading and the text. I have found that this structure is also applicable to non-military message systems including Amateur Radio, Domestic and International Telegrams, Telex and TWX. One significant feature of the military message format is that the "message content" and much of the "message envelope" format is the same for a variety of transmission media. That is, the message can be relayed via couriers, flashing light, semaphore, flag hoist, radiotelegraph, wire and radiotelewriter, paper tape relay, wire and radiotelephone, and computer networks. 2. Basic Message Structure. HEADING Transmission Heading Batch Heading Envelope Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Envelope Ending Batch Ending Transmission Ending Using the analogy of a postal letter, the Message Heading, Message Text, and Message Ending are the "letter" (message content); the Envelope Heading and Envelope Ending are the "envelope" (message envelope); the Batch Heading and Batch Ending are the rubber band around several "envelopes" being sent to the same "post office"; and the Transmission Heading and Transmission Ending are the "mail bag" (transmission envelope). The "basic message" contains only "message content" information and consists of the Message Heading, Message Text and Message Ending. These parts are ones that the drafter and his mail formatting program create. A "posted message" contains "message envelope" and "message content" information and consists of the Envelope Heading, Message Heading, Message Text, Message Ending, and Envelope Ending. The "message envelope" consisting of the Envelope Heading and Envelope Ending (if used) contains elements of information added by the post office (Message Transfer Sublayer (MTSL) program on the "originating host") which accepts the message for transmission. This is where the first postmark ("Message-Id") is added. Post offices (MTSL mail forwarding programs on relaying hosts) passing the message along may or may not add their postmark ("Received"). A "batch of messages", sometime called a "bundle" or "string of messages", is a set of "posted messages" which have been bundled together for transmission to the same post office as a single message. The post office address on a "batch of messages" should be readable by all post offices. A "batch of messages" is not unbundled until it arrives at the post office to which it is being sent. Not all message systems bundle messages. A "transmission message" may be either a "posted message" or a "batch of messages" surrounded by a "transmission envelope". That is, the "envelopes" (posted messages) and "bundles" (batches of messages) may be put into different mail bags (transmission envelopes) as it is passed along between different post offices. The format of the transmission envelope will vary with the type of network being used to transmit the message. "Post offices" are also known as "Message Transfer Agents (MTA)". To ensure that the message is delivered, each post office ("gateway MTA") that changes the mode of transportation (eg. ARPANET to UUCP) takes the message out of one mail bag before putting it in another mail bag. (Even though it is possible to put one mail bag inside another, the next post office may not be able to read what instructions are written on the inner mail bag.) An alternative to changing "mail bags" is to "refile the message". A simplest way to refile a message from one system to another is to quote the "basic message" in the text of message that has the correct type of heading (and ending) for the next network transporting the message. The refile method is used where the formats of two message systems are incompatible. It should be noted that the trend is towards mail programs that handle "posted messages" only. There are also message systems that have no "ending" or only use one type of ending. 3. Conclusions. Applying the above model, I find that all messages have a text (a message has to say something); that military messages have Transmission Heading, a Message Heading, a Text, and a Transmission Ending; and that Internet messages (RFC 822) have a heading that has a mix of Envelope Heading and Message Heading fields, a Text, and no ending. Amateur Radio messages have some elements of the Transmission Heading, Message Heading, Message Ending, and Transmission Ending. If we are going to make the Internet mail format a universal standard then we will have to define header fields for the Batch Heading Envelope Heading in addition to the Message Heading. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 11-May-83 06:52:24-PDT,1813;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 10 May 83 23:32:53-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 1:33 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 1:31 EDT Received: From Usc-Ecl.ARPA by BRL via smtp; 11 May 83 1:22 EDT Date: 10 May 1983 2218-PDT Sender: ESTEFFERUD@usc-ecl.arpa Subject: MSGGROUP#2028 Re: Basic Message Format From: ESTEFFERUD@usc-ecl.arpa To: wcwells%Topaz.CC@ucb-vax.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: cbosgd!mark@ucb-vax.arpa Message-ID: <[USC-ECL]10-May-83 22:18:26.ESTEFFERUD> In-Reply-To: <8305110206.AA01132@UCBVAX.ARPA> Hi Bill --- First, your topic is OK for MsgGroup, but not very appropriate for Header-People which has always focused more on implementation aspects rather than theoretical wool gathering. So, I suggest that you omit Header-People from your distribution. And Second, fresh ideas are always welcome, but all this is beginning to sound repetitious. Before we proceed further, may we ask for a statement of your purpose? Are you doing this as a term paper for a class at UCB? Are you seriously proposing that what we need are more endings? Are you suggesting that structured mail transfer systems (822/SMTP) should be analyzed as though they were actually flat, like TWX/TELEX where there is only one channel for both transmission and signalling? I am having trouble shaking the feeling that you have not yet come to grasp the important concepts of structured protocols. In any case, I think that you owe the MsgGroup community a bit more background about yourself and your purposes before you continue with your lectures. Not too long winded though. About one CRT screenful should do it. Best regards - Stef 11-May-83 06:52:30-PDT,5150;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 11 May 83 00:22:37-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 2:40 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 2:28 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 11 May 83 2:20 EDT Date: 10 May 83 23:14:05 PDT (Tue) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2029 Basic Message Format Message-Id: <8305110623.AA03846@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA03846; 10 May 83 23:23:42 PDT (Tue) To: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: DCrocker@udel-relay.arpa, POSTEL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Basic Message Format - 2 - "Heading Components" 1. Introduction. In my first article I introduced a Basic Message Structure having the following parts. HEADING Transmission Heading Batch Heading Envelope Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Envelope Ending Batch Ending Transmission Ending This article is my first attempt to list the header fields in the "Standard for the Format of ARPA Internet Text Messages (RFC 822, August 13, 1982) by sub-part and functional component membership. 2. Discussion. In reviewing RFC 822, I found two fields that I consider to be "message envelope" fields: Return-Path: Received: My definition of a "message envelope" field is: a heading field that is defined by a message forwarding program (message transfer agent) at the Message Transfer Sub-layer. RFC 822 calls programs at this level "transport system" or "transport service" (see articles 4.3.1 and 4.3.2). The intended use of "Message-ID" and "Resent-Message-ID" is less clear. Article 4.6.1 states that "this identifier is intended to be machine readable and not necessarily meaningful to humans". That statement along would make me believe that these fields are not at the user level. I think this machine generated and readable field is suppose to be the originating post office's postmark. Thus I conclude that these are "message envelope" fields. If true, then why two different fields? If a "basic message" is resent, it should be given a new "message envelope" with a new "Message-ID" by the MTA posting program. If "Message-ID" is the original postmark, then we do not need the "Resent-Message-ID" field. If these fields have some other use, then we need to define a machine readable "Postmark:" field for the "message envelope", and leave these fields in the "message content". Comments? 3. Header Fields by Sub-Part and Component. ENVELOPE HEADING SUB-PART COMPONENT FIELD ___________________________________________________ Envelope Postmark Message-ID: Heading Return Field Return-Path: Envelope Address (not defined) Relay Instructions (not defined) Trace Fields Received: ___________________________________________________ MESSAGE HEADING SUB-PART COMPONENT FIELD ___________________________________________________ Readdressal Precedence (not defined) Message Heading Date-Time Resent-Date: Originator's Resent-From: Address Resent-Sender: Resent-Reply-To: Receiver's Resent-To: Address Resent-cc: Resent-bcc: ___________________________________________________ Original Precedence (not defined) Message Heading Date-Time Date: Heading Originator's From: Address Sender: Reply-To: Receiver's To: Address cc: bcc: Classification (not defined) Content Subject: Information Keywords: In-Reply-To: References: Encryption Encrypted: Field ___________________________________________________ Heading Comments Comments: Comments Field ___________________________________________________ Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 11-May-83 13:51:06-PDT,3489;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 11 May 83 13:50:54-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 15:41 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 15:18 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 11 May 83 15:08 EDT Date: 11 May 83 12:02:02 PDT (Wed) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2030 Re: Basic Message Format Message-Id: <8305111910.AA01670@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA01670; 11 May 83 12:10:32 PDT (Wed) To: ESTEFFERUD@usc-ecl.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa In reply to: Date: 10 May 1983 2218-PDT From: ESTEFFERUD@USC-ECL Before we proceed further, may we ask for a statement of your purpose? Part of my purpose in putting "basic message format" on the net is to get a discussion going on how the Internet message format should be implimented in a non-structured protocol environment. I have not seen any information on "message envelope" header fields. I think the "header fields" list should be expanded to include information used at the "message transfer" layer. I am also concerned about current implimentations of RFC822 that do not make a distinction between "message envelope" and "message content" header fields. (I would like the "message content" I send to be same when the reader sees it.) In comparing US Govt. (military and non-military) message header fields I have found a number of fields which I believe should be part of the Internet message format standard if it is ever going to be adopted for official communications. Are you doing this as a term paper for a class at UCB? No this is not a term paper, but it may become a RFC. Are you seriously proposing that what we need are more endings? I think at least one user readable ending is needed at the "message content" or "message envelope" level. Are you suggesting that structured mail transfer systems (822/SMTP) should be analyzed as though they were actually flat, like TWX/TELEX where there is only one channel for both transmission and signalling? No. But I believe that the "message envelope" should be upward compatible. I think we should have a "message envelope" standard that will work in both a structured and a non-structed environment. I am having trouble shaking the feeling that you have not yet come to grasp the important concepts of structured protocols. I think I grasp the concepts. Just rusty on the details. In any case, I think that you owe the MsgGroup community a bit more background about yourself and your purposes before you continue with your lectures. Not too long winded though. About one CRT screenful should do it. I am a Programing Consultant at the U.C. Berkeley Center where I write user documentation and assist users with using our systems. I am also a Radioman Chief (telecommunications specialist) in the Naval Reserve about 12 years experience in the use of military message systems. My military duties include telecommunications planning for Naval Reserve activities in the Western US. I am interested in evaluating the feasibility of using ARPANET as an emergency communications alternate to AUTODIN. Best regards Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 11-May-83 17:23:43-PDT,911;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 11 May 83 16:56:05-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 19:24 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 19:13 EDT Received: From Hi-Multics.ARPA by BRL via smtp; 11 May 83 19:11 EDT Date: 11 May 1983 18:12 est From: DBrown.TSDC@hi-multics.arpa Subject: MSGGROUP#2031 Bravo, Mr. Wells To: wcwells%Topaz.CC@ucb-vax.arpa cc: header-people@mit-mc.arpa, msggroup@brl.arpa Bravo, Mr. Wells. You gave the kind of answer that I see all too rarely on this net: succinct, to the point and polite, even in answer to an unwarranted "flame". I'll be saving this one away to recommend as a model, both for my own use and for my associates --dave brown DBrown.TSDC at HI-MULTICS.ARPA decvax!watmath!watbun!drbrown late of HM Canadian Forces 11-May-83 20:22:01-PDT,1264;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 11 May 83 19:58:32-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 22:30 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 22:28 EDT Received: From Usc-Ecl.ARPA by BRL via smtp; 11 May 83 22:26 EDT Date: 11 May 1983 1925-PDT Sender: ESTEFFERUD@usc-ecl.arpa Subject: MSGGROUP#2032 Re: Bravo Mr. Wells From: ESTEFFERUD@usc-ecl.arpa To: DBrown.TSDC@hi-multics.arpa Cc: wcwells%Topaz.CC@ucb-vax.arpa, msggroup@brl.arpa Message-ID: <[USC-ECL]11-May-83 19:25:26.ESTEFFERUD> In-Reply-To: Your message of 11 May 1983 18:12 est Hear, Hear! I will agree that Bill Wells provided a proper answer, which I believe we all deserved to see. It helps a great deal in my efforts to understand what he is driving at. The MsgGroup list includes all manner of members, and I think it is important for anyone who suddenly appears with a great deal to say should stand and be identified. I am pleased to note that Bill Wells showed no offense at the request. When I next need to request such information from a new member of the club, I will be sure to ask assistance from Mr Brown.TSDC@hi-multics in the art of being gentle. Best - Stef 11-May-83 20:28:37-PDT,1182;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 11 May 83 20:27:42-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 11 May 83 22:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 11 May 83 22:39 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 11 May 83 22:34 EDT Date: 11 May 83 20:27:47 CDT (Wed) From: Mike.Caplinger Return-Path: Subject: MSGGROUP#2033 Re: Basic Message Format To: MsgGroup@brl.arpa Message-Id: <1983.05.11.20.27.47.166.02324@dione.rice> In-Reply-To: wcwells%Topaz.CC's message of 10 May 83 23:14:05 PDT (Tue) Via: Rice; 11 May 83 19:19-PDT I'd like to suggest that, in following with current computer science vogue (as with Algol 68's if-fi), the message ending be simply the message heading, but byte-reversed. For example, the close to this message would be: (euT) TDP 50:41:32 38 yaM 01 fo egassem s'CC.zapoT%sllwwec :oT-ylpeR-nI :DI-egasseM lrb@puorGgsM :oT tamroF egasseM cisaB :eR :tcejbuS regnilpaC.ekiM :morF TDC 74:72:02 38 yaM 11 ,deW :etaD 12-May-83 01:12:17-PDT,1290;000000000001 Return-path: <@SU-DSN:greep@Su-Dsn> Received: from BRL by USC-ECLC; Thu 12 May 83 00:49:48-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 12 May 83 2:16 EDT Received: From Su-Dsn.ARPA by BRL-BMD via smtp; 12 May 83 2:05 EDT Date: 11 May 1983 23:09-PDT (Wednesday) From: Steven Tepper To: NIC@sri-nic.arpa Cc: MsgGroup@brl-bmd.arpa Subject: MSGGROUP#2034 Updating the online Arpanet directory I noticed that some entries in the online Arpanet directory at NIC are very out-of-date, and it occurred to me that the only time the this list is normally updated is when a new printed version is about to appear. (At least I, as a host liaison, don't remember ever being asked to submit updates at any other time.) Have you considered soliciting updates on a more frequent basis? Obviously if someone from NIC had to intervene manually this could take an overwhelming amount of manpower, but the state of the art is easily up to having a data base be updated automatically (e.g. by sending a message of a prescribed format to a designated mailbox at NIC). I am copying this to MsgGroup since a major use of the online directory is (or at least could be if it were current) finding out someone's present mailbox in order to send mail to him. 12-May-83 03:44:53-PDT,1009;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 12 May 83 03:43:01-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 12 May 83 6:18 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 12 May 83 6:12 EDT Received: From Office-10.ARPA by BRL via smtp; 12 May 83 6:04 EDT Date: 12 May 1983 0306-PDT Sender: BHUTCHINSON@office-10.arpa Subject: MSGGROUP#2035 Re: Bravo Mr. Wells From: BHUTCHINSON@office-10.arpa To: ESTEFFERUD@usc-ecl.arpa Cc: DBrown.TSDC@hi-multics.arpa, wcwells%Topaz.CC@ucb-vax.arpa Cc: msggroup@brl.arpa Message-ID: <[OFFICE-10]12-May-83 03:06:02.BHUTCHINSON> In-Reply-To: <[USC-ECL]11-May-83 19:25:26.ESTEFFERUD> BRAVO/BRAVO/BRAVO Stef!!! I did not consideer your request for info a flame at all. If my mailbox overfloweth from one source, I also think it is very important to know something about that source. I shall save your response to DBrown and refer to it when I am in need of a response to unwarranted accusations. 13-May-83 08:37:03-PDT,1103;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 13 May 83 08:33:59-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 13 May 83 9:22 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 13 May 83 9:06 EDT Received: From Hi-Multics.ARPA by BRL via smtp; 13 May 83 8:53 EDT Date: 13 May 1983 07:55 cdt From: Stachour.CSCswtec@hi-multics.arpa Subject: MSGGROUP#2036 Re: Basic Message Format To: Mike.Caplinger In-Reply-To: Message of 11 May 1983 22:20 cdt from Mike.Caplinger However, may I note that byte-reversal may require the saving away of a not insignficant amout of text. Also, I'm not so sure about the advantages of reversal, and of reverse parsing (if needed). How does one handle the white-space and comments? As one who recently wrote an Ada-mode for the Multics Eamcs Screen Editor, it became clear to me that Ada was NOT designed to be parsed in reverse. I believe that we would find similar problems here, especially in the continued lines, and comments continued over line boundaries. ???Paul 22-May-83 22:56:50-PDT,7866;000000000000 Return-path: Received: from BRL by USC-ECLC; Sun 22 May 83 22:27:44-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 23 May 83 0:22 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 23 May 83 0:17 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 23 May 83 0:11 EDT Date: 22 May 83 20:54:59 PDT (Sun) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2037 Basic Message Format Message-Id: <8305230409.AA12659@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA12659; 22 May 83 21:09:51 PDT (Sun) To: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: DCrocker@udel-relay.arpa, POSTEL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Basic Message Format - 2 - "Heading Components" Version 2 - 22 May 83 ------------------------------------------------------------------------ Changes in this version: a. "Envelope Heading" and "Envelope Ending" changed to "Postal Heading" and "Postal Ending" to avoid confusion with all the different definitions of "envelope" and "message envelope". b. New header fields have been added for use in the Postal Heading and Message Heading parts of the message. c. "Message-ID" is clearly defined as a user application level field and has been placed in the original message heading. A "Post-ID" field has been defined for use at the "electronic post office" level. ------------------------------------------------------------------------ 1. Introduction. RFC 822 is primarily concerned with "message content" header fields. These header fields are primarily used for obtaining information from the user (drafter of the message) to (a) permit the message to be identified by other users (readers of the message); (b) obtain addressing information to send the message. This article introduces new header fields for use in the Postal Heading of a message. The Postal Heading contains fields that are used by "electronic post offices" to (a) identify the message being sent, (b) supply relay (source routing) information to relaying mail systems, and (c) record audit trail information. In my first article I introduced a Basic Message Structure having the following parts and sub-parts. HEADING Transmission Heading Batch Heading Postal Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Postal Ending Batch Ending Transmission Ending The Internet Text Message as currently defined by the "Standard for the Format of ARPA Internet Text Messages" (RFC 822) has a heading and a text. No ending is defined. This article classifies RFC 822 header fields into two groups, Message Heading and Postal Heading, and adds additional fields for use in the Postal Heading. No attempt has been made to define "Batch" or "Transmission" fields since these are more the concern of the network and transport system being used. 2. Header Fields by Sub-Part and Component. POSTAL HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ MESSAGE HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Readdressal Date-Time Resent-Date: Message Heading(s) Originator's Resent-From: Address Resent-Sender: Resent-Reply-To: Originator's Resent-Message-ID: Message ID. Precedence Resent-Precedence: Receiver's Resent-To: Address Resent-cc: Resent-bcc: Resent-Exempt: _____________________________________________________ Original Date-Time Date: Message Heading Originator's From: Address Sender: Reply-To: Originator's Message-ID: Message ID. Precedence Precedence: Receiver's To: Address cc: bcc: Exempt: Security Classification: Classification Content Subject: Information Keywords: In-Reply-To: References: Encryption Encrypted: Field _____________________________________________________ Heading Comments Comments: Comments Field _____________________________________________________ Notes: (a) Fields not defined in RFC 822 are: Posted-Date, Posted-From, Post-ID, Postmaster, Relay-To, Do-Not-Relay-To, Resent-Precedence, Precedence, Resent-Exempt, Exempt, Classification. (Syntax of postal header fields is defined in my next article.) The order of sub-parts differs from RFC 822 Article 4.1 in that "source" is defined as: source = [trace] [resent] originator (b) Each sub-part of the heading begins with its corresponding date- time field. Fields pertaining to one sub-part may not be placed in another sub-part. With the exception of the date-time field which begins the sub-part, the order of fields within the sub-part is not defined. However the above order is recommended. (c) There may be none, one or more "readdressal message heading" sub- parts in the message heading. If there is more than one "readdressal message heading" the later ones precede the earlier ones. (d) "Relay-To" fields may be deleted by relaying hosts (MTA's) when delivery has been made (or protected) by that host. (e) Relaying hosts will not make changes to the Message Heading within an Internet mail system environment. Gateways to non-Internet mail systems, may translate header fields into other formats. However, if the other mail system is incompatible with Internet, the message should be quoted in the text of the other systems message. The same applies to incompatible messages being entered into an Internet mail system. (f) There may be only one "Date:", "From:", "Sender:" and "Message- ID:" field per original message. Relaying hosts may not add or change the "Message-ID" field. (g) "Exempt" and "Resent-Exempt" fields are optional user fields that may be used with collective addresses to indicate that the drafter (or user resending the message) does not want the message sent to one or more addressees in the collective address. Syntax is same as "To": exempt = "Exempt" ":" 1#address resent-exempt = "Resent-Exempt" ":" 1#address Comments? Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 22-May-83 21:47:58-PDT,3828;000000000000 Return-path: Received: from BRL by USC-ECLC; Sun 22 May 83 21:36:06-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 23 May 83 0:11 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 23 May 83 0:06 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 23 May 83 0:04 EDT Date: 22 May 83 20:55:38 PDT (Sun) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGRROUP#2038 Basic Message Format Message-Id: <8305230402.AA12546@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA12546; 22 May 83 21:02:23 PDT (Sun) To: MsgGroup@brl.arpa, header-people@mit-mc.arpa Cc: DCrocker@udel-relay.arpa, POSTEL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Basic Message Format - 3 - "Postal Heading Syntax" Version 1 - 22 May 1983 1. Introduction. This article defines the syntax of header fields used in the Postal Heading. 2. Syntax POSTED-DATE. This is the date the message was posted by the originating "electronic post office". This field is required since it defines the beginning of the Postal Heading. Syntax is the same as "Date": post-date = "Posted-Date" ":" date-time POSTED-FROM. This required field contains the identity of the originating "electronic post office" which enters the message into a Internet type mail system. It is suggested that the "()" comment argument of this field contain the name and version of the posting program. Syntax is the same as "From": orig-post-office = "Posted-From" ":" mailbox POST-ID. This is an optional field that may be added by the originating "electronic post office" to identify the message. Syntax is the same as "Message-ID": orig-post-id = "Post-ID" ":" msg-id POSTMASTER. This optional field contains the identity of the Postmaster at the originating "electronic post office". It is intend for use by sites having several hosts and only one Postmaster. Syntax is: postmaster = "Postmaster" ":" address RETURN-PATH. Defined in RFC 822. RELAY-TO. This optional field may be used with a message containing multiple addresses to tell the relaying and destination "post offices" that that they are only required to deliver to the address indicated. This field is not normally used for single addressee message expect to indicate source routing in the Postal Heading. If this field contains source routing, the source routing indicated in this field will be used instead of the source routing (if any) indicated for the same address in the message heading. This field may be used by the originating "electronic post office" (as opposed to the drafter and his mail format/submission program(s)) to specify source routing for mail systems that require source routing. Unless otherwise indicated in an outer layer (eg. SMTP, or other envelope), the lack of any "Relay-To" fields indicates to the post office that it is responsible for relaying the message to all addresses of the message. If one or more "Relay-To" fields is present, then the post office is only responsible for relaying the message to the addresses indicated in the "Relay-To" field(s). Syntax is: relay-to = "Relay-To" ":" address DO-NOT-RELAY-TO. This optional field may be used with a collective address by the "post office" or drafter to indicate that the message has already delivered (or is being delivered by other means) to the indicated address. Syntax of this field is: do-not-relay = "Do-Not-Relay-To" ":" addr-spec RECEIVED. Defined in RFC 822. Comments? Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720 22-May-83 22:57:07-PDT,1535;000000000000 Return-path: Received: from BRL by USC-ECLC; Sun 22 May 83 22:45:41-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 23 May 83 0:43 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 23 May 83 0:39 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 23 May 83 0:38 EDT Date: 22 May 1983 2135-PDT (Sunday) From: Eric Allman Subject: MSGGROUP#2039 Re: Basic Message Format Message-Id: <7070.31.422512549@ucbarpa> Received: by UCBARPA.ARPA (3.342/3.29) id AA07071; 22 May 83 21:35:51 PDT (Sun) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29) id AA12954; 22 May 83 21:35:14 PDT (Sun) Phone: (415) 548-3211 To: wcwells%Topaz.CC@ucb-vax.arpa Cc: DCrocker@udel-relay.arpa, POSTEL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa, MsgGroup@brl.arpa, header-people@mit-mc.arpa In-Reply-To: Your message of 22 May 83 20:56:05 PDT (Sun). <8305230406.AA12603@UCBVAX.ARPA> Fcc: mail I have been quite interested by almost everything you have posted up to this point. Your description of the military message system was extremely educational and was in my opinion at least somewhat apropos. However, at this point I find your suggestions heavy on complexity and low on benefit. Although I agree that there is a real need, I don't believe it requires as large a solution as you are proposing. All computer types should be constantly on guard to insure that their solutions of today do not become the problems of tomorrow..... eric 23-May-83 03:46:06-PDT,1189;000000000000 Return-path: Received: from BRL by USC-ECLC; Mon 23 May 83 03:42:41-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 23 May 83 5:58 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 23 May 83 5:53 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 23 May 83 5:44 EDT Date: 23 May 83 02:35:39 PDT (Mon) From: wcwells%Topaz.CC@ucb-vax.arpa Subject: MSGGROUP#2040 Re: Basic Message Format Message-Id: <8305230942.AA15229@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA15229; 23 May 83 02:42:23 PDT (Mon) To: eric%ucbarpa@ucb-vax.arpa Cc: MsgGroup@brl.arpa, header-people@mit-mc.arpa Eric, Give me a while to discuss the "why's and wherefores" behind my heading format, before you shoot the whole thing down. You may even like a few of the ideas I have put out. I realize I have put a lot out as once. With all the different terms and phrases being used to discuss message formats, I felt it was necessary to define the terms I am using. Let's look at some of the idea's I have presented an idea at a time and see if they are worth implimenting. Best Regards. Bill Wells topaz.wcwells@BERKELEY.ARPA 24-May-83 01:22:42-PDT,1429;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 23 May 83 23:42:40-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 1:58 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 1:53 EDT Received: From Usc-Isib.ARPA by BRL via smtp; 24 May 83 1:47 EDT Date: 23 May 1983 2204-PDT From: POSTEL@usc-isib.arpa Subject: MSGGROUP#2041 re: updating the online Arpanet directory To: msggroup@brl.arpa cc: postel@usc-isib.arpa Steven Tepper (greep@su-dsn) Steve: I disagree about using automatic procedures to update data bases. I think there is an important problem in the verification of the updates. Most of the databases that i have seen that allowed updates by random uses, even limited to their own record, turn into garbage. It seems to take a human to verify that the updates are reasonable is several different ways. For example, you could set up a mailbox "Kahn" on SU-DSN, and send in an update to say that REK2 has changed his mailbox from "KAHN@USC-ISI" to "Kahn@SU-DSN". Should that update be processed? The CSNET designers have thought about these problems and cover quite a few of them in their "name server" (see: Solomon et. al., "the design of the CSNET name server", Computer Networks, v6, pp161-172, 1982). But still, i believe that a human in the loop is essential to preserve the quality of the data base. --jon. ------- 23-May-83 20:32:11-PDT,1805;000000000000 Return-path: Received: from BRL by USC-ECLC; Mon 23 May 83 20:13:29-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 23 May 83 22:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 23 May 83 22:47 EDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 23 May 83 22:37 EDT Date: 23 May 1983 2230 EDT From: Larry Campbell To: wcwells%Topaz.CC@ucb-vax.arpa, MsgGroup@brl.arpa cc: DCrocker@udel-relay.arpa, POSTEL@usc-isif.arpa, cbosgd!mark@ucb-vax.arpa Subject: MSGGROUP#2042 Re: Basic Message Format Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11921812246.13.71..9143 at DEC-MARLBORO> References: Message from wcwells%Topaz.CC@Berkeley of 23-May-83 0052-EDT In-reply-to: <8305230412.AA12691@UCBVAX.ARPA> Although I haven't had time to think about the details of each message in the recent mountains of traffic, I think most of the problems that are being discussed have been solved by the NBS protocols. Two especially nice features of the NBS protocols that are relevant are: 1) Almost all fields can have arbitrary property lists associated with them 2) Each element of a message has a type and a length, and the definitions are recursive. Thus, you send an object of type "message". In that object you can have, for example, an object of type "subject", which in turn can contain another object of type "message". The recursive definition of NBS solves the "wrapper" problem, and the fact that objects have lengths solves the "ending" problem. I think it's unfortunate that the DoD community has greeted the NBS protocols with such a deafening silence. They're not RFC822, but they've had a lot of thought put into them. Comments and flames? -------- 24-May-83 16:21:43-PDT,2857;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 24 May 83 16:21:35-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 16:46 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 16:33 EDT Received: From Usc-Ecl.ARPA by BRL via smtp; 24 May 83 16:20 EDT Date: 23 May 1983 2149-PDT Sender: ESTEFFERUD@Usc-Ecl.ARPA Subject: MSGGROUP#2043 Re: Basic Message Format From: ESTEFFERUD@Usc-Ecl.ARPA To: LCAMPBELL@Dec-Marlboro.ARPA Cc: wcwells%Topaz.CC@Ucb-Vax.ARPA, MsgGroup@Brl.ARPA Cc: DCrocker@Udel-Relay.ARPA, POSTEL@Usc-Isif.ARPA Cc: cbosgd!mark@Ucb-Vax.ARPA Message-ID: <[USC-ECL]23-May-83 21:49:46.ESTEFFERUD> In-Reply-To: <"MS11(2347)+GLXLIB1(1056)" 11921812246.13.71..9143 at DEC-MARLBORO> I agree with Larry Campbell that careful consideration should be given to the way layered protocol designs tend to eliminate the need for the beginnings and endings, et al, that WCWells is talking about. The vital distinction, as I see it, is between layered protocols where more structure is available, and the case where the message protocol must be implemented using a single channel for both signalling and data, and where the channel has the same general charactaristics as a plain old TWX network. In this latter case, the structure must be imbedded in the message itself. If there is a need to convert upon transferring to a TWXnet through a gateway from 822 or NBS protocol MTAs, then the gateway can insert all the beginnings and endings it wishes, but it is not at all reasonable from my view to impose all that beginning and ending and other additional strucure to our structured message transmission systems just because someone out there wants that sort of thing. For example, I have arranged my BBN HERMES User Agent to print the junk fields of a message at the end rather than at the beginning. Thus I see an "ending" without imposing such things on anyone else. If I were to be printing all these messages on paper, and was concerned about losing pages in the clerical reproduction process, I could (and should) arrange for each page to be marked as "Page n of m from Message-ID" and get all the control I might want, again without bothering everyone else around the whole net. We all have agreed many times in this forum that we are and should be moving toward more such use of User Agents to provide these results. (Last time I was on the other side of the argument about Xerox letting long lines out when so many of us were not equipped to handle them with our cretenous User Agents.) So, I am not one to look kindly on reversions to meet the needs of the old days tomorrow. Lets not follow the lead of the parking authority whose motto is ... "Planning today for yesterday's needs tomorrow!" I say Onward! Stef 24-May-83 11:31:58-PDT,1987;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 24 May 83 10:46:44-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 12:26 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 12:13 EDT Received: From Cmu-Cs-A.ARPA by BRL via smtp; 24 May 83 12:07 EDT Date: 24 May 1983 1153-EDT From: Rudy.Nedved@cmu-cs-a.arpa To: POSTEL@usc-isib.arpa Subject: MSGGROUP#2044 Re: updating the online Arpanet directory CC: msggroup@brl.arpa In-Reply-To: "POSTEL@usc-isib.arpa's message of 24 May 83 00:04-EST" Message-Id: <24May83.115301.EN0C@CMU-CS-A> Jon, One of the things CMU is currently working on is an internal white pages so people don't have to worry about which host Susan.Brown is on. Alot of the design work that we have done so far has been based on Xerox's Grapevine and Clearinghouse systems. I have never heard any comments about either of these systems indicating their databases have "dropped in quality". The problems I have heard have always been along the line of getting an update to all the databases (since it is distributed). If I remeber correctly, Steve's comments were directed at NIC's "name database". I don't consider it infeasible if NIC flagged an administrative name to each host and name entry and assigned a password for validating the right to modify entries owned by the administrative name. Problems do arise with allocating new unique ids (seems politics and FCFS assignments don't work well together) and new host names/nicnames. [The Grapevine documents should be required reading for mail maintainers/designers....good stuff] I am pushing for distributed database mechanisms for both the host name and personal name databases but there are still too many small important organizations that don't have our type of problems. Xerox has "dealt" with these problems for several years now. I expect CMU to "hide" the same internal mechanisms as Xerox does. -Rudy 24-May-83 13:18:31-PDT,1000;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 24 May 83 13:15:06-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 13:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 13:23 EDT Received: From Wisc-Crys.ARPA by BRL via smtp; 24 May 83 13:07 EDT Date: 24 May 83 11:59:18-CDT From: Marvin Solomon Reply-to: solomon@csnet-sh.arpa To: MsgGroup@brl.arpa Subject: MSGGROUP#2045 Re: Basic Message Format It looks like there's a lot to be learned from the proposed NBS mail standard. I for one have to admit that I know nothing about it, and I feel I should. I suspect others on this list are in the same boat. What is the easiest way of getting a copy? Would it be possible to put a machine-readable copy somewhere for FTP retrieval? Larry Campbell referes to the "NBS protocols" (in plural). How many separate documents are there, and which ones are most relevant to this discussion? Thanks 24-May-83 16:46:42-PDT,1577;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 24 May 83 16:43:58-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 16:47 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 16:33 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 24 May 83 16:27 EDT Date: 24 May 83 16:15:54 EDT (Tue) From: Steven M. Bellovin Subject: MSGGROUP#2046 Re: Basic Message Format Message-Id: <8305242024.AA03917@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA03917; 24 May 83 13:24:22 PDT (Tue) To: MsgGroup@brl.arpa, Larry Campbell In-Reply-To: Message of 23 May 1983 2230-EDT from ucbvax!LCAMPBELL@dec-marlboro.arpa <"MS11(2347)+GLXLIB1(1056)" 11921812246.13.71..9143 at DEC-MARLBORO> I read the NBS proposals about the time 822 was being drafted/debated. There seemed to be two problems with their draft: (a) the protocol is exceedingly hairy and complex, with many features (all the different dates, for example) of dubious relevance; (b) they seemed concerned with different issues. Addressing, and Internet domains were a major source of flaming here (quick -- how many "@" signs can dance on the header of a pin-message? how many "at"s?), but were totally swept under the rug in the NBS proposal. Besides, their format was not at all RFC733-like, and hence not germane at the time. But you're right; it may be time to discuss the question some more. The proposal was issued as RFC806; I assume it's still online in the usual places. 24-May-83 20:02:36-PDT,1241;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 24 May 83 19:37:59-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 May 83 21:03 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 24 May 83 20:58 EDT Received: From Cmu-Cs-A.ARPA by BRL via smtp; 24 May 83 20:49 EDT Date: 24 May 1983 1747-EDT From: Rudy.Nedved@cmu-cs-a To: solomon@csnet-sh Subject: MSGGROUP#2047 NBS standard CC: MsgGroup@brl In-Reply-To: "Marvin Solomon's message of 24 May 83 11:59-EST" Message-Id: <24May83.174751.EN0C@CMU-CS-A> RFC #806 is a copy as of Sep '81 of the Proposed Federal standard. Somewhere in Header-People and/or Msg-Group archives is a message giving pointers to who or where you can get the NBS standards. Last thing I heard was that at least three corporations had picked NBS mutlimedia standard as a standard. CMU currently uses Xerox PRESS files to move images/text information and ASCII files to move text information around. We currently do not have a need to have a powerful but uniform multimedia file standard but I expect the need to appear in less then 3 years when people around here start sending multimedia proposals from one personal computer to another. -Rudy 25-May-83 15:19:06-PDT,671;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 May 83 15:16:48-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 25 May 83 15:53 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 25 May 83 15:40 EDT Received: From Usc-Isif.ARPA by BRL via smtp; 25 May 83 15:33 EDT Date: 25 May 1983 1229-PDT From: POSTEL@usc-isif Subject: MSGGROUP#2048 RFC 806 = NBS Mail Protocol To: msggroup@brl The NBS Mail Protocol is online in the Network Information Center Library as RFC 806. One can copy this document via FTP. Use the FTP username ANONYMOUS and password GUEST. The pathname is RFC806.TXT --jon. ------- 25-May-83 21:16:32-PDT,1106;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 May 83 21:14:36-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 25 May 83 21:32 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 25 May 83 21:12 EDT Received: From Bbna.ARPA by BRL via smtp; 25 May 83 21:02 EDT Date: 25 May 1983 1950-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2049 Re: RFC 806 = NBS Mail Protocol From: DDEUTSCH@bbna To: POSTEL@usc-isif Cc: msggroup@brl, DDeutsch@bbna Message-ID: <[BBNA]25-May-83 19:50:29.DDEUTSCH> In-Reply-To: The message of 25 May 1983 1229-PDTfrom As somebody else has already pointed out, RFC 806 (dated September 1981) is an old version of the NBS "Mail Protocol". A somewhat different version was adopted as a Federal Information Processing Standard this past January. Its official name is "Specification of Message Format for Computer Based Message Systems"; it is also known as FIPS (Federal Information Processing Standard) 98. I would be happy to send you an on-line copy of FIPS 98 so that it could become an RFC, replacing RFC 806. Debbie 25-May-83 21:57:16-PDT,2517;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 May 83 21:32:51-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 25 May 83 21:32 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 25 May 83 21:12 EDT Received: From Bbna.ARPA by BRL via smtp; 25 May 83 21:07 EDT Date: 25 May 1983 2056-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2050 Re: NBS standard From: DDEUTSCH@bbna To: Rudy.Nedved@cmu-cs-a, mhb5b!smb@ucb-vax Cc: solomon@csnet-sh, LCAMPBELL@dec-marlboro Cc: MsgGroup@brl, DDeutsch@bbna Message-ID: <[BBNA]25-May-83 20:56:13.DDEUTSCH> In-Reply-To: <24May83.174751.EN0C@CMU-CS-A> In-Reply-To: <8305242024.AA03917@UCBVAX.ARPA> I'd like to help the discussion along by clearing up a misunderstanding or two. The subject of this discussion is a standard for the format of the contents of messages. Its scope includes the definition of a set of message fields and their usage; it also defines a syntax for representing messages, fields, and their component parts. This standard is part of an on-going program at NBS. The NBS message format standard does not deal with naming and addressing. However, last year NBS published a report on just that subject. The question of naming and addressing was not dealt with in the message format standard because when the message format standard was being written it was felt that any proposals on naming/addressing would be premature. There was much less understanding and consensus about naming/addressing at that time. Another thing that the NBS message format standard does not deal with is the representation of multimedia objects. It was too early for a commercial standard to deal with that. What the NBS message format standard DOES do is provide all the "hooks", such as bit-strings, for multimedia objects. An eventual NBS standard for multimedia objects would make use of these hooks. In the meantime, people would be able to experiment with them. Finally, and as I mentioned in a message I just sent out, the NBS message format standard is a real standard; it is no longer a proposal as far as the commercial world is concerned. I know of at least six major vendors of message systems and message system services that have endorsed its use. It's out there, and it's real. The question is, how does the the NBS message format standard solve the problems we encounter in providing an Internet mail service, and are those solutions applicable here? Debbie Deutsch 28-May-83 20:31:35-PDT,7172;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 28 May 83 20:31:19-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 May 83 18:23 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 28 May 83 17:55 EDT Received: From Usc-Eclc.ARPA by BRL via smtp; 28 May 83 10:38 EDT Return-path: From: MSGGROUP@usc-eclc Date: 25 May 1983 1800 PDT To: msggroup@usc-eclc Subject: MSGGROUP#2051 SURVEY #2001-#2050 from MSGGROUP.2001-2100.1 Sender: MsgGroup@usc-eclc Reply-to: MsgGroup-Request@brl Remailed-date: 28 May 1983 0013-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.1901-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#2001 SURVEY #1951-#2000 from MSGGROUP.1901-2000.1 6982 chars 1 May 83 12:37:26 EDT (Sun) From: MSGGROUP@usc-eclc.arpa To MSGGROUP#2002 domains here 5516 chars 1 May 83 16:29:53-PDT (Sun) From: Mark Crispin : [Tihor : [: Undeliverable mail]]] 1250 chars 2 May 1983 15:00:43 EDT (Monday) From: Ed Frankenberry Received: from BRL by USC-ECLC; Wed 25 May 83 21:51:50-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 25 May 83 22:04 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 25 May 83 21:54 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 25 May 83 21:47 EDT Date: 25 May 83 18:42:28 PDT (Wed) From: wcwells%Topaz.CC@berkeley Subject: MSGGROUP#2052 Re: Basic Message Format Message-Id: <8305260144.AA08931@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA08931; 25 May 83 18:44:16 PDT (Wed) To: ESTEFFERUD@usc-ecl Cc: MsgGroup@brl Date: 23 May 1983 2149-PDT From: UCBJADE:ESTEFFERUD@USC-ECL Subject: Re: Basic Message Format Message-Id: <[USC-ECL]23-May-83 21:49:46.ESTEFFERUD> I agree with Larry Campbell that careful consideration should be given to the way layered protocol designs tend to eliminate the need for the beginnings and endings, et al, that WCWells is talking about. The vital distinction, as I see it, is between layered protocols where more structure is available, and the case where the message protocol must be implemented using a single channel for both signalling and data, and where the channel has the same general charactaristics as a plain old TWX network. In this latter case, the structure must be imbedded in the message itself. ------------------- Stef, I agree. --- I think my purpose is being misunderstood. The "basic message structure" is a general model and all of its headings and endings are not intended to be part of the "content" (ie. SMTP 'DATA') of a message sent in a structured environment. In a structured system, I would expect that the Transmission Heading and Transmission Ending functions to be implemented at a lower layer. I do not think that the Batch Heading and Batch Ending are applicable to a network where the orginating host and destination host are in direct communications with each other, however they do have an application in "store and forward" type message transport systems. I do believe that the current Internet message heading should be divided into three functional (if not physically separated) sub-parts: a. postal (envelope) instructions and information b. audit trail (trace) information c. user (content) instructions and information Some of the problems I see occuring as various sites try to implement RFC 822 are related to the fact that there are two sub-layers in the application layer in an electronic mail system: the user layer and the "electronic post office" layer. With the exception of a couple of fields, RFC 822 has only defined fields for use at the user level. (Note, that I do not consider SMTP to be an "electronic post office", but just a "transport" system at a lower level.) Some of the discussion we have had recently on "separation of the envelope and heading", I think is beginning to recognized these two sublayers. Because I believe the "electronic post office" (and the "transport system") should not be changing the drafter's message including "message content" information in header fields, I have defined a Postal Heading and a Message Heading. To provide for functional separation I believe a few more fields (that can be changed as required by the "electronic post offices" and "mail transport agents") are required. Because RFC 822 does not provide for multiple readdressals (resends) I have made a distinction between readdressal and original information in the Message Heading. I admit that in building my heading scheme, I added a few fields to handle user functions not currently supported by RFC 822. I do think some of those new functions need to be discussed. I particular I think we need to take a closer look at how collective addressee designators (eg. mailing list names, news group names) are being handled (or not handled). For example, should the user be able to indicate that delivery is not required to a particular address in a collective because the user has already delivered it by other means? Best Regards, Bill Wells topaz.wcwells@BERKELEY 25-May-83 22:39:26-PDT,677;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 25 May 83 22:07:39-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 25 May 83 22:05 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 25 May 83 21:54 EDT Received: From Hi-Multics.ARPA by BRL via smtp; 25 May 83 21:48 EDT Date: 25 May 1983 20:44 est From: DBrown.TSDC@hi-multics Subject: MSGGROUP#2053 Re: RFC 806 = NBS Mail Protocol To: msggroup@brl I wonder if someone could put the exact name of the NBS Mail (Text?) Protocol out on the net. It is probably easier for some of us to get it from NBS than from the net library, if only we knew what to ask for. --dave 27-May-83 13:48:21-PDT,963;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 27 May 83 13:21:35-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 May 83 11:21 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 May 83 11:19 EDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 27 May 83 11:05 EDT Date: 27 May 1983 1000-EDT From: Larry Campbell To: mhb5b!smb@berkeley, MsgGroup@brl Subject: MSGGROUP#2054 Re: Basic Message Format Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11922724285.14.71.19975 at DEC-MARLBORO> References: Message from mhb5b!smb@Berkeley (Steven M. Bellovin) of 26-May-83 2027-EDT In-reply-to: <8305242023.AA03895@UCBVAX.ARPA> You're right; the NBS protocol does contain a lot of hair. It is, however, subsettable to a very small and easily implemented stub. The number of fields that an implementation is REQUIRED to understand is actually very small. -------- 27-May-83 18:41:46-PDT,831;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 27 May 83 18:27:18-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 May 83 16:48 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 May 83 16:33 EDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 27 May 83 16:18 EDT Date: 27 May 1983 1607-EDT From: Larry Campbell To: DDEUTSCH@bbna cc: MsgGroup@brl Subject: MSGGROUP#2055 Re: RFC 806 = NBS Mail Protocol Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11922791113.20.71.9790 at DEC-MARLBORO> References: Message from DDEUTSCH@bbna of 27-May-83 1119-EDT In-reply-to: <[BBNA]25-May-83 19:50:29.DDEUTSCH> I would also be interested in seeing online copies of the NBS paper(s) on naming and addressing, even if they're not yet standards. -------- 27-May-83 18:41:48-PDT,827;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 27 May 83 18:41:20-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 May 83 16:48 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 May 83 16:34 EDT Received: From Bbna.ARPA by BRL via smtp; 27 May 83 16:27 EDT Date: 27 May 1983 1628-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2056 Re: RFC 806 = NBS Mail Protocol From: DDEUTSCH@bbna To: LCAMPBELL@dec-marlboro Cc: DDEUTSCH@bbna, MsgGroup@brl Message-ID: <[BBNA]27-May-83 16:28:44.DDEUTSCH> In-Reply-To: <"MS11(2347)+GLXLIB1(1056)" 11922791113.20.71.9790 at DEC-MARLBORO> To get a copy of the naming/addressing report (hard- or softcopy) you should contact Shirley Watkins (Watkins@NBS-VMS). Her telephone number is 301-921-3516 in case netmail doesn't work. Debbie 1-Jun-83 22:16:00-PDT,3660;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 1 Jun 83 22:13:46-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 1 Jun 83 14:55 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 1 Jun 83 14:45 EDT Received: From Mit-Multics.ARPA by BRL via smtp; 1 Jun 83 14:41 EDT Date: 1 June 1983 08:47 edt From: Frankston.SoftArts@mit-multics Subject: MSGGROUP#2057 Newton vs Einstein Sender: SAI-relay.SoftArts@mit-multics Reply-To: Bob Frankston To: msggroup@brl *from: BOB (Bob Frankston) Local: msggroup at brl, cc:BOB:sent.po Original-date: 31 MAY 1983 10:38:28 I have about 100 pages of the last month's msggroup and header people discussions sitting beside me at teh moment. I'm not going to try to read it all, but do want to add a comment on the absolute vs relative path issue. It is something I've flamed about in past years and am actually encouraged to see reality forcing the issue. 1. I don't know how to state this strongly enough. Absolute mail names do not exist. Networks are born and die continually. I can create a network by hooking up any sets of machines that I happen to have lying around. I can also create a network with an autodialler. Even if I am on Tymnet, I create a network among any subset of cooperating hosts. In fact, any translation list can act as a network. Thus one can have "Joe@lunch-club" be a valid entry. This is no different than "Joe@MIT-ML" or "Joe@lunch-club@Mike's-computer" or "subscriber-1234@magazine-of-the-month" or "Occupant@home". Whether "lunch-club" is a host, a name server or just a file doesn't really make a difference as long as the mail server that gets this address knows that it can either as "lunch-club" or knows how to read the "lunch-club" file. I should even be able to send mail to a a network that doesn't exist yet via a host that is willing to wait. Whatever sugaring and complexities exist, I will always need some escape to route addressing. Each stage of address processing just needs to do its part and past the rest on. I think that this is the spirit of Mike O'Dell's proposal. Sure there can be Name servers, domains, encaching, abbreviations, aliasing etc. But these are not fundamental mechanisms. The notion of a rooted path is nice. It even exists to a limited extent for the phone system, though anyone who has tried to use autodialing in a program will discover that it is more theory than practice. Sure I can specify my office number as "1-617-237-4000". But that "1" is the North American access code. It is unclear whether that has any relationship to the "1-" is must dial for long distance. Anyway, if I dial "1-617" the phone system would consider my call invalid. I don't know why, but I can't use rooted addresses on the "617-237" exchange. So why this interest in doing better than the phone company? 2. A lot of concern is associated with assuring a reverse path for replying. I don't understand this. Sure it is nice, but do you know of the post office refusing to deliver mail when it can't read the return address? The dead letter office is an effective mechanism. Why this interest in limiting ourselves to be more restrictive than the postal system? PS: I presume none of the mail conventions rely on the existence of the Arpanet or even its cooperation. It should be possible to have networks that the Pentagon does not condone nor is even aware of. 1-Jun-83 21:41:03-PDT,1048;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Wed 1 Jun 83 21:37:09-PDT Date: 1 Jun 1983 2057-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#2058 RFC 841 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 841: Title: Specification for Message Format for Computer Based Message Systems Author: NBS Pages: 109 pathname: [SRI-NIC]RFC841.TXT This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. 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. ------- 2-Jun-83 14:52:33-PDT,2698;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 2 Jun 83 14:50:04-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 2 Jun 83 16:40 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 2 Jun 83 16:23 EDT Received: From Su-Score.ARPA by BRL via smtp; 2 Jun 83 16:14 EDT Date: 2 Jun 83 13:16:11-PDT Thu From: Mark Crispin Subject: MSGGROUP#2059 Frankston on Newton vs. Einstein To: MsgGroup@BRL.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is, however, absolutely no reason why an attempt should not be made to provide absolute addresses for as many cases as possible. We should do at least as well as the phone or postal networks. I agree with the concept of not rejecting mail just because the return path is invalid (several SMTP servers have this unfortunate property) as long as it is not carried to extremes. An SMTP server should always be able to decline to accept a MAIL FROM: command which is syntactically invalid. An SMTP sender should always be clever enough to try various approaches with reluctant SMTP servers which decline its initial return path; it should give up only if MAIL FROM:<> is rejected (and it should never be). I've worked around the absence of absolute naming for small-i internet by designing my own form of name registry. FTP the file MRC:DOMAINS.TXT from Score to see what it looks like. It defines various pseudo top-level domains for the mailsystem to use. I can, for example, mail to somebody at Columbia University's computer center by using the knowledge that Columbia and CMU are part of a large cooperative DECnet and that ARPA host CMU-CS-C is a member of that network and willing to act as a bridge. They call their DECnet "CCNET". The ARPA-valid specification is something like SY.FDC%CU20B@CMU-CS-C, but in my mailsystem I can use SY.FDC@CU20B.CCNET or even SY.FDC@CU20B provided that CU20B is a uniquely registered name. I didn't need to know that CU20B existed, as long as I knew that CCNET existed and who was the bridge. Temporarily, my mailsystem is obliged to transmogrify SY.FDC@CU20B.CCNET into the ARPA-valid SY.FDC%CU20B@CMU-CS-C.ARPA and I look forward to seeing that ending. The .ARPA is what makes things ever so much easier. Entities within CCNET are less likely to know the membership of ARPA than outside, however the .ARPA makes the address absolute. So as long as the site knows how to reach the ARPA mail bridge, it can get the mail through. It's not as clean as it could be, but it does work. ------- 4-Jun-83 21:20:07-PDT,2276;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 4 Jun 83 21:18:04-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 3 Jun 83 13:01 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 3 Jun 83 12:49 EDT Received: From Nyu.ARPA by BRL via smtp; 3 Jun 83 12:47 EDT Date: 3 Jun 83 12:33 EDT From: Stephen Tihor To: Mike O'Dell@BRL-BMD.ARPA, mo@LBL-CSAM.ARPA Subject: MSGGROUP#2060 RE: One man's view of the world (MOBY message) Cc: msggroup@BRL.ARPA Message-ID: <15444FEA4.003D0023;1983@CMCL1.NYU.ARPA> In-Reply-To: <8304281504.AA19861@LBL-CSAM.ARPA> ; Message of 3-JUN-1983 01:33 from Mike O'Dell@BRL-BMD.ARPA, mo@lbl Believing in domain routers is sufficient. Lets look at a real example from here at NYU. Logically our mailers think they are in a SMTP universe in Domain NYU. We also have a couple of disconnected nodes (off the local net) connected by UUCP links. SO lets assume a user on 20.GBA.NYU wants to send a message to FRED.MC.MIT (or to use current naming FRED@MIT-MC.ARPA. 20.GBA.NYU knows that the ARPA domain, (and indeed everything in any domain its never heard of is accessed through VAX.GBA.NYU so it sends the message there. VAX.GBA.NYU know that everything except VAX.GBA.NYU and 20.GBA.NYU (and those same names .ARPA) is handled by "NYU.ARPA" aka CMCL2.NYU.ARPA which it reaches by shoveling the mail over a UUCP link to cmcl2!FRED@MIT-MC.ARPA. Once at CMCL2 the mail can be routed to the rest of the NYU internet, or, in this case, out into the cold cruel world or pure ARPAnet addressing. (Of course when the message gets to MIT-MC it is probably aliased to somthing on a Chaosnet machine, but thats just that much backending.) Note that if MIT were a top level domain, as long as the Internet mailer on CMCL2 knew about it everything would work the same, and as long as we know the destination nodes top-level domain at each end, which central registry is supposed to accomplish, then we need know nothing else since we can always bounce it off of the Internetmail forwarding service nodes which are being set up to support MILNET, ARPANET mail gatewaying anyway. Not to mention all the very smart nodes such as RUTGERS, MIT-MC, etc. ------- 7-Jun-83 03:00:06-PDT,1058;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Tue 7 Jun 83 02:59:49-PDT Date: 6 Jun 1983 2221-PDT From: POSTEL at USC-ISIF Subject: MSGGROUP#2061 RFC 850 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 850: Title: Standard for Interchange of USENET Messages Author: M. Horton Pages: 18 pathname: [SRI-NIC]RFC850.TXT This RFC specifies the standard format for news articles in USENET. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. 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. 8-Jun-83 01:02:12-PDT,5655;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 01:01:40-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 2:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 2:45 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 Jun 83 2:34 EDT Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2062 problems with NBS standard Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT To: msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:25-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 ------- 8-Jun-83 14:01:38-PDT,1459;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 13:58:11-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 9:55 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 9:25 EDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 8 Jun 83 9:24 EDT Date: 8 Jun 1983 0922-EDT From: Larry Campbell To: Scott L. McGregor , msggroup@brl cc: header-people@mit-mc, name-droppers@sri-nic Subject: MSGGROUP#2063 Re: problems with NBS standard Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO> References: Message from Scott L. McGregor of 8-Jun-83 0348-EDT In-reply-to: <423854936.28783.hplabs@HP-VENUS> You seem to imply that the EBCDIC difficulty makes it difficult for a certain class of user to use NBS. Yet using clear text makes it difficult for a much larger class of user: those who don't speak English. I believe that was the primary reason the NBS people chose the structure they did. To indulge in a particularly awkward neologism, the NBS standard is "internationalizable". It's not sufficient to dismiss this problem by saying that most computer users learn English as a second language; many governments are rightly requiring that data processing equipment sold in their countries conform to national language requirements. -------- 8-Jun-83 16:44:51-PDT,3000;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 16:41:58-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 12:40 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 12:25 EDT Received: From Bbna.ARPA by BRL via smtp; 8 Jun 83 11:41 EDT Date: 8 Jun 1983 1138-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2064 Re: problems with NBS standard From: DDEUTSCH@bbna To: MCGREGOR.HP-HULK@rand-relay Cc: msggroup@brl, header-people@mit-mc Cc: name-droppers@sri-nic, DDeutsch@bbna Message-ID: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH> In-Reply-To: <423854936.28783.hplabs@HP-VENUS> If the purpose of the NBS message format standard were to support messages containing text only, I might agree with you. However, that is not the case. One of the design criteria for the NBS message format standard was that it should be extensible for multimedia messages. In order to do this in a flexible, efficient way, it was necessary to use a binary encoding scheme instead of a character-encoded scheme. Thus, data is interpretted in octets (8-bit bytes) instead of in characters. I am surprised to hear you complain that a specialized data transfer protocol cannot handle general data, and then blame the problem on the the nature of the data. The file transfer protocol that you describe is specialized for the transfer of text. You could not use it to move a file containing an executable program; you could not use it to move a file containing a bitmap image. Are attempts to exchange these kinds of data between different systems violations of the ISO OSI layered architecture? Of course not. Your file transfer protocol implements a small part of the presentation layer, concerned only with character set translation. That is fine, as long as you use that protocol only for character-encoded data. An OSI purist would say that the problem is that you have not implemented a complete presentation layer. I say that the functionality of computer mail is going beyond purely textual messages, and that we must use more general data transfer mechanisms to accomodate the facsimile, voice, bitmaps, etc. that we would like to include with the text in our messages. It is easy to print NBS-style messages. As part of the development of the standard, a program that translates NBS-style messages to RFC 733 messages was built. It could handle everything in the NBS standard. It was fairly simple, and ran very quickly. So having a computer translate an NBS-style message to a textual representation before printing it is quite straightforward. I am left wondering about your final paragraph (before "About the author"). There is nothing to lobby about, because the NBS standard is a standard now. More puzzling is your comment about "mail systems that are biased against certain vendors". Could you explain what you mean by that? What is the bias, and which are the vendors? Debbie Deutsch 8-Jun-83 17:48:32-PDT,2450;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 17:48:21-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 16:21 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 15:44 EDT Received: From Su-Score.ARPA by BRL via smtp; 8 Jun 83 15:47 EDT Date: 8 Jun 83 12:14:13-PDT (Wed) From: Mark Crispin Subject: MSGGROUP#2065 Re: problems with NBS standard To: LCAMPBELL@DEC-MARLBORO.ARPA cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA, header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA In-Reply-To: Message from "Larry Campbell " of Wed 8 Jun 83 06:22:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Larry - I have heard the language justification for NBS before, and am distinctly unimpressed. Instead of "most computer users learn English as a second language" it is more accurate to state "English is the language of computing." Programming languages which have any language base at all (that is, excepting things like APL) are based upon English. This is the case even in the Soviet Union and China, which due to western trade restrictions are obliged to build a lot of their own computing engines. Another fallacy to the "internationalizable" argument is the fact that with networking there is a lot of foreign computer usage; e.g. a user in Germany accessing a computer in the USA. Still another is that most operating systems with international usage (e.g. TOPS-20) are English-based. I am skeptical that even relatively large software vendors such as DEC have the ability to maintain multiple versions of operating systems, documentation, etc. for the myriad of human languages. I have the sneaky suspicion that this entire argument is to coddle the French and the Quebecois. Recent legislation in Quebec and France has been directed against usage of English or of adding English words to French (e.g. "le garbage"). The best attitude to take is to ignore it, not to argue with or bend over backwards to coddle. If anything, the attempt to prevent any change or language mingling in French will ultimately lead to its becoming a dead language. Latin is an unchanging language, unaffected by English slang. There are also no native speakers of it. -- Mark -- ------- 8-Jun-83 19:08:24-PDT,1593;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 19:07:22-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 17:08 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 16:48 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 8 Jun 83 16:52 EDT Date: 8 Jun 83 15:09:19 EDT (Wed) From: Mark Horton Subject: MSGGROUP#2066 Re: problems with NBS standard Message-Id: <8306081909.AA09577@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA09577; 8 Jun 83 15:09:19 EDT (Wed) Received: by UCBVAX.ARPA (3.341/3.31) id AA22298; 8 Jun 83 12:47:08 PDT (Wed) To: msggroup@brl.ARPA (Why is this going to all 3 mailing lists? On Usenet people have been loudly flamed at for making somebody read something twice!) Re: Larry Campbell's comments on foreign languages. If you use octets, you are essentially picking a NEW language, one which nobody speaks, so everybody (or every program) has to keep a translation table handy. If you use 822, at least the fraction of the users who speak English (probably at least 99%, given the popularity of English as a foreign language, plus the high incidence of computer work in English speaking countries and in computer journals) won't have to keep a conversion chart handy. Most programming languages have English keywords. Apparently large numbers of foreign programmers learn (or already know) those English words - I recall a sample SIMULA program where all the keywords were ALGOL (e.g., English) and all the identifiers were in Norwegian! 8-Jun-83 21:45:44-PDT,2115;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 21:41:11-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 17:32 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 17:10 EDT Received: From Usc-Ecl.ARPA by BRL via smtp; 8 Jun 83 17:12 EDT Date: 8 Jun 1983 1412-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2067 Discussion of NBS reports From: DDEUTSCH@bbna, ESTEFFERUD@usc-ecl Reply-To: MsgGroup-request@brl To: MsgGroup@brl Cc: header-people@mit-mc, Name-Droppers@sri-nic Message-ID: <[USC-ECL] 8-Jun-83 14:12:26.ESTEFFERUD> To all MsgGroupers, and others ... in Header-People and Name-Droppers: There has been quite a bit of interest in MsgGroup recently about the NBS program to develop federal information processing standards for computer-based message systems. NBS would like to encourage such discussion, in the belief that the technical concepts it has developed may be of interest to the Internet community, and that feedback from the Internet community will be helpful to NBS. In order to facilitate this process, NBS is willing to make the appropriate NBS reports available as RFCs. The NBS message format standard is already available from the NIC as RFC 841. Two additional NBS reports should be of interest at this time. One deals with naming and addressing, and the other is an analysis of the features of message transfer protocols. Both already have been published for public comment. Contributions are encouraged from all interested parties whether you are a member of MsgGroup or not. In order to capture the entire discussion, it should be conducted in MsgGroup. The MsgGroup transcript of the discussion will be kept in an organized archive for public access and NBS use. Contributions to the discussion should go to MsgGroup@BRL. Extra copies to Header-People and Name-Droppers will not be appreciated by recipients who are also members of MsgGroup. Requests to be added to the MsgGroup mailing list should go to MsgGroup-Request@BRL. Debbie Deutsch and Einar Stefferud 8-Jun-83 23:02:03-PDT,559;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 23:00:30-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 20:03 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 19:41 EDT Received: From Usc-Eclc.ARPA by BRL via smtp; 8 Jun 83 19:40 EDT Date: 8 Jun 1983 1635-PDT From: Chris Subject: MSGGROUP#2068 Mail loop To: msggroup@brl Phone: (213) 743-5520 Office: PHE-220 There is some kind of weird mail loop going on....see header in following message. Chris. ------- 8-Jun-83 23:11:50-PDT,829;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 23:07:57-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 20:03 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 19:41 EDT Received: From Office-2.ARPA by BRL via smtp; 8 Jun 83 19:48 EDT Date: 8 Jun 83 16:43 PDT From: WBD.TYM@office-2 Subject: MSGGROUP#2069 Re: problems with NBS standard To: DDEUTSCH@bbna Cc: MCGREGOR.HP-HULK@rand-relay, msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic, DDeutsch@bbna Message-ID: <[OFFICE-2]TYM-WBD-2K6MT> In-reply-to: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH> <423854936.28783.hplabs@HP-VENUS> HELP!!! Are we (OFFICE) the only people getting MULTIPLE copies of this message? Please stop it if it is the outside world's fault. Thanks, William Daul 8-Jun-83 21:45:46-PDT,1471;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 21:43:15-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 17:33 EDT Date: 8 Jun 83 17:14:17 EDT (Wed) From: Ron Natalie To: msggroup@brl-bmd, gurus@brl-bmd Subject: MSGGROUP#2070 [Scott L. McGreg: problems with NBS standard] Boy, this one sure made the rounds... Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 16:14 EDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 16:22 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 16:00 EDT Received: From Su-Score.ARPA by BRL via smtp; 8 Jun 83 16:00 EDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:24:52-PDT Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 2:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 2:45 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 Jun 83 2:34 EDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:25-PDT 8-Jun-83 23:11:51-PDT,1278;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 23:08:51-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 20:14 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 19:52 EDT Received: From Nyu.ARPA by BRL via smtp; 8 Jun 83 19:55 EDT Date: 8 Jun 83 19:50 EDT From: Stephen Tihor To: mrc@SU-SCORE.ARPA Subject: MSGGROUP#2071 Re: problems with the NBS standard Cc: msggroup@BRL.ARPA Message-ID: <1596D091D.017C0023;1983@CMCL1.NYU.ARPA> Actually re foreign languages and operating systems. I have been watching the VMS developement group making some fairly dramatic efforts to insure that the major pieces of the system which constitute the user interface are well modularized for the explicitly stated reason of Foreign (Non-English) Language support. They appear to be fairly near to having done it so that one could simply slide in a separate set of help, error message, and command files and almost all of the system would appear to be speaking some other language. Wether it is necessary of cost effective to change the names of the system calls (especially for another Romance language where the abreviations can probably be redefined) is still a question. ------- 9-Jun-83 00:49:12-PDT,744;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 00:48:22-PDT Received: From Sri-Nic.ARPA by BRL via smtp; 9 Jun 83 2:29 EDT Date: 8 Jun 1983 2210-PDT From: David Roode Subject: MSGGROUP#2072 applying Received: time stamps to mail To: MsgGroup@brl Location: EJ296 Phone: (415) 859-2774 It seems some implementations of SMTP apply then at the top of the message, and some read into the message and apply them at the end of any existing such stamps. I personally prefer the former, looking at it as sort of a "stack" of stamps. Behavior should be consistent, and I think the Internet mail protocol specifications had applying the time stamps at the top in mind. ------- 9-Jun-83 00:33:41-PDT,828;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 00:32:43-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 9 Jun 83 2:24 EDT Date: 8 Jun 1983 2323-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2073 Re: problems with NBS standard From: ESTEFFERUD@usc-ecl To: WBD.TYM@office-2 Cc: msggroup@brl Message-ID: <[USC-ECL] 8-Jun-83 23:23:36.ESTEFFERUD> In-Reply-To: <[OFFICE-2]TYM-WBD-2K6MT> HELP! We are all beseiged with multiple copies because of a loop that has been fixed, and all of you out there should look at the mail enough to figure out that sending complaints to the entire list is not the way to help! If you must complain before reading, at least send your to complaints to Msggroup-Request@BRL !!!!!!!!! HELP HELP HELP HELP HELP Help help help ---- Stef 8-Jun-83 22:50:32-PDT,1725;000000000000 Return-path: Received: from BRL by USC-ECLC; Wed 8 Jun 83 22:44:29-PDT Received: From Brl-Vgr.ARPA by BRL via smtp; 9 Jun 83 0:46 EDT Date: 9 Jun 83 0:40:12 EDT (Thu) From: Mike Muuss To: MsgGroup@brl Subject: MSGGROUP#2074 List-Processor This evening I changed the MsgGroup mailing list to use our new MMDF List-Processor channel (kindly designed and written by Doug Kingston ). This MMDF channel is, in actuality, a "user agent", even though this implementation is incestuous with the mail delivery system. Features: *) The return address (SMTP "MAIL FROM" field) will be given as , so that failed-mail messages, etc, will be returned to the moderator, rather than to message contributors. *) Inbound SMTP service will no longer be delayed while the list is verified; list expansion is done as a separate operation. (We beat the delay by bouncing the mail to another machine; this is no longer necessary). Please direct specific questions or complaints to ; further discussion of the usefulness of this "mail exploder" can be sent to . An interesting topic for discussion: Some systems (eg, MIT's ITS and Berkeley's Sendmail/Delivermail) will accept any address straightaway, and will mail back a transcript to the message sender if trouble arises when delivery is attempted. Offhand, it looks like these systems do not stash away the "MAIL FROM" field provided, so that their notifications of trouble go back to the message contributor, and not to the moderator. If this is in fact true, what can/should we do about it? Best, -Mike 9-Jun-83 20:45:25-PDT,3868;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 20:39:05-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 9 Jun 83 13:18 EDT Date: 9 Jun 83 01:14:00 EDT (Thu) From: Mark Horton Subject: MSGGROUP#2075 problems with NBS standard Message-Id: <8306090514.AA16924@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA16924; 9 Jun 83 01:14:00 EDT (Thu) Received: by UCBVAX.ARPA (3.341/3.31) id AA16345; 9 Jun 83 10:11:16 PDT (Thu) To: msggroup@brl.ARPA If the purpose of the NBS message format standard were to support messages containing text only, I might agree with you. However, that is not the case. One of the design criteria for the NBS message format standard was that it should be extensible for multimedia messages. In order to do this in a flexible, efficient way, it was necessary to use a binary encoding scheme instead of a character-encoded scheme. Thus, data is interpretted in octets (8-bit bytes) instead of in characters. If I were designing a way to encode, say, a picture for transmission via mail, I sure wouldn't encode it using 8 bit bytes. I would be willing to bet that some gateway somewhere wouldn't transparently transmit all 8 bits. I would encode it with printing ASCII characters. At one point I proposed an RFC 822 header line Encoded: method where "method" is registered at NIC. A method might be a printing-to-binary format, or something specially geared for pictures, or whatever is needed. We already have Encrypted: method, key which does essentially the same thing - the body of the message is encrypted according to a registered method (resulting in only printing characters, if the method is go work over all mail gateways), and the key can be used as a hint to the reading program to determine the real key. You can even mix text and encoded data - to use examples from UNIX troff: Encoded: pic Encoded: eqn Ordinary printing text. .PS square size 15 right 20 circle rad 5 .PE This is some more text. .EQ sum from 1 to inf of 1 over x .EN Certainly you can make it more efficient by using 8 bits; but you lose any hope of having all those 8 bit quantities make it through whatever mailers exist with their local character sets and conventions. (Even the ARPANET does not like isolated 's in SMTP.) Your file transfer protocol implements a small part of the presentation layer, concerned only with character set translation. I think you'll find that he wasn't talking about a file transfer protocol, but SMTP and TELNET protocols, both of which must use a network virtual (ASCII) terminal. These protocols assume they are transferring text. FTP allows either text or binary file transfer, but if you transfer a binary NBS message from an ASCII machine to an EBCDIC machine, you wind up with a binary file containing NBS octets and gibberish. Something with knowledge of the mail formats has to do the ASCII-EBCDIC translation; this is contrary to the nice layered OSI approach. It is easy to print NBS-style messages. As part of the development of the standard, a program that translates NBS-style messages to RFC 733 messages was built. It could handle everything in the NBS standard. It was fairly simple, and ran very quickly. So having a computer translate an NBS-style message to a textual representation before printing it is quite straightforward. Sure, but it's a program that has to be included in every single piece of software that might ever want to print a mail message. With 822, you don't have to build this info in - you can just print the message with the normal type or cat command, you can edit the message with an ordinary text editor. Only the mail program should have to know about mail formats. Mark Horton 9-Jun-83 07:12:41-PDT,1053;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 07:11:48-PDT Received: From Bbna.ARPA by BRL via smtp; 9 Jun 83 8:56 EDT Date: 9 Jun 1983 0847-EDT Sender: MOOERS@bbna Subject: MSGGROUP#2076 Re: applying Received: time stamps to mail From: MOOERS@bbna To: ROODE@sri-nic Cc: MsgGroup@brl Message-ID: <[BBNA] 9-Jun-83 08:47:39.MOOERS> In-Reply-To: The message of 8 Jun 1983 2210-PDTfrom From: David Roode Subject: applying Received: time stamps to mail It seems some implementations of SMTP apply then at the top of the message, and some read into the message and apply them at the end of any existing such stamps. I personally prefer the former, looking at it as sort of a "stack" of stamps. Behavior should be consistent, and I think the Internet mail protocol specifications had applying the time stamps at the top in mind. This message is not very specific. Could you give examples of the two ways of applying time stamps? ---Charlotte 9-Jun-83 19:50:42-PDT,525;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 19:48:40-PDT Received: From Usc-Isif.ARPA by BRL via smtp; 9 Jun 83 10:59 EDT Date: 9 Jun 1983 0755-PDT From: POSTEL@usc-isif Subject: MSGGROUP#2077 applying "Received:" time stamps to mail To: msggroup@brl The SMTP specification (RFC 821) requires that the "Received:" time stamps be applied to the message with the most recent on top, that is, the newest time stamp becpmes the first line of the header. --jon. ------- 9-Jun-83 20:08:10-PDT,1395;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 20:06:36-PDT Received: From Su-Dsn.ARPA by BRL via smtp; 9 Jun 83 12:26 EDT Date: 9 Jun 1983 09:26-PDT (Thursday) To: MOOERS@bbna Cc: ROODE@sri-nic, MsgGroup@brl Subject: MSGGROUP#2078 Re: applying Received: time stamps to mail In-reply-to: Your message of 9 Jun 1983 0847-EDT. <[BBNA] 9-Jun-83 08:47:39.MOOERS> From: greep@su-dsn The message seems plenty specific to me. He said that some mail servers tack on their "Received:" lines at the beginning of the message header, others at the end (approximately). Thus, for example, if host-3 does the latter while host-4 does the former, you end up with timestamps that are not in any logical order: Received: From host-3 by host-4 (third timestamp) Received: From host-1 by host-2 (first timestamp) Received: From host-2 by host-3 (second timestamp) From an implementation standpoint, putting them at the beginning is generally the easiest thing since it doesn't require looking at the message. There is also the problem that some hosts don't add timestamps at all, thus making it even harder to figure out what path a message took. This has caused problems with people trying to get themselves off of mailing lists since they can't always tell what host actually has the list they're on. 9-Jun-83 23:01:23-PDT,4771;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 22:59:22-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 9 Jun 83 22:48 EDT Date: 9 Jun 1983 1047-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2079 Re: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 9 Jun 1983 10:51:46-PDT To: DDEUTSCH@bbna, MCGREGOR.HP-HULK@rand-relay Cc: msggroup@brl, header-people@mit-mc, name-droppers@sri-nic, MCGREGOR.HP-HULK@rand-relay In-Reply-To: Your message of 8-Jun-83 0838-PDT Message-Id: <424029107.4147.hplabs@HP-VENUS> Via: HP-Labs; 9 Jun 83 19:27-PDT I see that I have not been clear about the kinds of communication that I was addressing. My comments in my previous letter were addressed only to the subset of possible computer communication that is textual. I intended to raise implementations concerns in comparision to RFC822, a textual standard. Debbie is entirely correct that NBS addresses a larger scope, namely multimedia communication. I agree that it probably addresses that scope better than RFC822, which never really was intended to have that scope (according to the RFC822 standard, communications are limited to ascii characters, 8-bit binaries would not be "legitimate" even if accepted by a such a mail system). There is still something to lobby about. Standards have to be implemented. A standard does not enforce conformity any more than laws against drunk driving mean that no more people will die on the roads. People have to follow standards for them to work, just as with traffic laws. To get standards implemented, they have to be made palatable to implementors, and in this case, a general purpose translator is needed. This is especially true for those machines that might want to translate ascii text (if it is contained within the message) to ebcdic, as would occur in transferring text mail from a DEC20 to an IBM370, or vice versa from EBCDIC to ASCII as would happen sending text mail from an IBM370 to a DEC20. In response to the question of mail systems biased against certain vendors, let me say this. If a mail standard is more difficult to implement on one kind of machine than certain others, I consider it "biased" against that vendor. This is not neccessarily bad, it may be the best solution to a bad problem. The fact is, that IBM uses EBCDIC as its character standard on its large mainframes while most of the rest of the world uses ASCII, thus ASCII mail standards are inherently biased against IBM, because extra effort (i.e. translation) is required to get the text readable to the IBM user. What makes an ASCII standard such as RFC822 palatable to an IBM mail system implementor is the existence of vendor supported translation programs. Because such translators cannot be used on NBS text mail, NBS is even more difficult to implement. If IBM were to release a smarter translator that could handle NBS mail containing ASCII text, the NBS would be just as acceptable as RFC822. I think people who are interested in NBS mail to IBM systems should lobby to make this a reality. The existence of an NBS to RFC822 translation program for the printing of text begs the question. RFC822 text can be sent down a tty line to a device and it is unimportant whether it is intelligent or not. It could just be a printer. NBS mail would require an intelligence at the end of the TTY line capable of running the translator, therefore, extra hardware is required here. Of course NBS designers recognized this, it is no suprise; the NBS standard is a standard for communication between computers, and is not intended to be able to go directly to printers. RFC822 just has the nice property that it can go directly to a printer. Some of the comments about my references to ISO OSI, seem to fall out of the confusion of my comparison of the use of NBS (a multimedia standard) with RFC822 (a text standard). Again, I want to clarify my intent, to mention implementation problems concerned with the mailing of text. But there is another issue which I haven't fully digested yet concerning the advantage of a multimedia standard over a text standard. The implication is that because multimedia can include text that the text standard will become unneccessary. My first reaction is that the existence of trucks, which can carry freight or passengers never lead to the abolishment of cars and motorcycles which can only transport people effectively. Still, there are some interesting questions raised here, and I will have to ponder more. Best wishes to all, and thanks for the comments! Scott L. McGregor ------- 9-Jun-83 23:21:44-PDT,670;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 23:17:42-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 9 Jun 83 22:55 EDT Date: 9 Jun 1983 1112-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2080 multiple copies of my previous letter Received: by HP-VENUS via CHAOSNET; 9 Jun 1983 11:16:45-PDT To: msggroup@brl Message-Id: <424030606.4601.hplabs@HP-VENUS> Via: HP-Labs; 9 Jun 83 19:30-PDT A hundred thousand apologies to those of you who received multiple copies of my previous correspondence. Sorry Scott L. McGregor ------- 9-Jun-83 23:36:43-PDT,2025;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 23:33:08-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 9 Jun 83 22:56 EDT Date: 9 Jun 1983 1114-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2081 [Scott L. McGregor : Re: problems with NBS standard] Received: by HP-VENUS via CHAOSNET; 9 Jun 1983 11:16:51-PDT To: msggroup@brl Message-Id: <424030613.4608.hplabs@HP-VENUS> Via: HP-Labs; 9 Jun 83 19:30-PDT To those of you who wrote to me regarding Larry Campbell's reply to my notes on NBS, I thought I would forward you a copy of my reply. Scott L. McGregor --------------- Date: 9 Jun 1983 0950-PDT From: Scott L. McGregor Subject: Re: problems with NBS standard To: LCAMPBELL@DEC-MARLBORO cc: MCGREGOR In-Reply-To: Your message of 8-Jun-83 0622-PDT I have no problem with an international standard. If we named the date field "1:" and the to field "2:" etc. I would have no problem with that because translation programs generally handle printable characters well (including printable numerics). Its the non-printable characters, such as the octet `0000 1001'b which get translated poorly. I personally would prefer field headings like date: and to: because they are immediately meaningful, particularly in a national standard such as NBS, as opposed to an international standard such as you propose. In any case, a mail daemon could translate (to Spanish for example), "date" to "dia" and "to" to "por" just as simply as it could translate "1" to either "date" or "dia". I would like to point out that this is in fact something that we will do with our RFC822 mail to nonEnglish speaking countries: we will send mail in RFC822 (i.e. English) form, and translate it on the destination machine to the machine or user defined native language. Scott L. McGregor ------- ------- 9-Jun-83 21:00:35-PDT,787;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 21:00:28-PDT Received: From Usc-Isi.ARPA by BRL via smtp; 9 Jun 83 14:49 EDT Date: 9 Jun 1983 1144-PDT Sender: LEINER@usc-isi Subject: MSGGROUP#2082 Re: problems with NBS standard From: LEINER@usc-isi To: MCGREGOR.HP-HULK@rand-relay Cc: msggroup@brl, header-people@mit-mc Cc: name-droppers@sri-nic Message-ID: <[USC-ISI] 9-Jun-83 11:44:25.LEINER> In-Reply-To: <423854936.28783.hplabs@HP-VENUS> I have now received an uncountable number of duplicates of messages related to this topic. Could someone advise as to which of the exploders are subsets of which, or are they separate with duplicates, and if so, isn't it possible to combine them. thank you Barry Leiner/DARPA 9-Jun-83 21:23:06-PDT,1677;000000000000 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 21:17:16-PDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 9 Jun 83 14:56 EDT Date: 9 Jun 1983 1449-EDT From: Larry Campbell To: Mark Crispin cc: MCGREGOR.HP-HULK@rand-relay, msggroup@brl, header-people@mit-mc, name-droppers@sri-nic Subject: MSGGROUP#2083 Re: problems with NBS standard Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11926184758.38.71.25377 at DEC-MARLBORO> References: Message from Mark Crispin of 8-Jun-83 1543-EDT Simply put, Mark, you're wrong. Let's take your major points one at a time: 1) "English is the language of computing... computer languages are English-based". Most computer users never write a program or see a line of code. This process is accelerating. 2) "I doubt that even DEC has the resources to provide different language versions of operating systems..." Wrong again. Both the Rainbow and PC are being produced in, I think, 14 different languages. This means that ALL the software DEC provides with these machines is translated, as well as the keycap legends and boot ROM messages. (I've seen the French keyboard; it's got legends like "page avancer" for "next screen".) DEC is spending lots of money to insure that its products are translatable. One example of this is that there is a documentation language standard, and I think there's even a program to check for violations. The point here is that intentionally limiting the vocabulary used in manuals makes it easier (and cheaper) to translate them. -------- 9-Jun-83 21:38:15-PDT,1759;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 21:33:49-PDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 9 Jun 83 15:14 EDT Date: 9 Jun 1983 1505-EDT From: Larry Campbell To: Mark Horton , msggroup@brl Subject: MSGGROUP#2084 Re: problems with NBS standard Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11926187580.38.71.60840 at DEC-MARLBORO> References: Message from Mark Horton of 8-Jun-83 2158-EDT In-reply-to: <8306081909.AA09577@cbosgd.UUCP> I've already responded to the chauvinistic and specious argument that "everyone who counts speaks English" in my reply to Mark's message, but you raise another point I'd like to respond to: that the NBS octets are a new language that NOBODY speaks. This is true enough. But remember that when setting standards, you're often better off offending everyone equally than in favoring anyone. I once attended a talk given by Jean Sammett in which she gave a retrospective on the history of COBOL, a language that she had no small part in defining. (Say what you will about COBOL, in 1960 it was a major step forward.) Anyway, during the Q & A session afterwards, someone asked "Why did you specify that COBOL identifiers could be up to 30 characters long? Why not 32, or 16, or some more natural number?" Her response was: "Thirty was equally inconvenient for everyone, and so had a much better chance of being accepted than any limit which favored one manufacturer or another." This is an important and often neglected principle in standards processes: DON'T FAVOR ANYONE OR THE LESS FAVORED PEOPLE WILL IGNORE OR SUBVERT THE STANDARD. -------- 9-Jun-83 21:54:13-PDT,1659;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 21:48:23-PDT Received: From Su-Score.ARPA by BRL via smtp; 9 Jun 83 15:34 EDT Date: 9 Jun 83 12:34:51-PDT (Thu) From: Mark Crispin Subject: MSGGROUP#2085 Re: problems with NBS standard To: LCAMPBELL@DEC-MARLBORO.ARPA cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA, header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA In-Reply-To: Message from "Larry Campbell " of Thu 9 Jun 83 11:49:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Larry - Come on! There is a difference between personal computers and mainframes. The world doesn't seem to think that the DEC PC's are terribly exciting; some of the recent price slashes implies desperation. Something can be said for national character sets on terminals, but there are pitfalls with that. I once had to explain to an individual in Germany that he could not use the umlaut or ess-tset characters on his terminal in sending a message to the USA. There is a subset of ASCII (I don't know if its formally defined or not) which you can count upon being on all ASCII terminals in the world. It's basically the alphanumerics and punctuation characters. In fact, a weakness of 822 is that it uses "@", "<", and ">" and certain national terminals have different characters there! It will be interesting to see how useful DEC's national (not international) variants of its products are and how successful they are in sales. ------- 9-Jun-83 23:53:47-PDT,1528;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 9 Jun 83 23:49:00-PDT Received: From Ucb-Vax.ARPA by BRL via smtp; 10 Jun 83 0:25 EDT Date: 9 Jun 83 21:13:34 PDT (Thu) From: SPGGGM%UCBCMSA.CC@berkeley Subject: MSGGROUP#2086 octets and translation tables, etc. Message-Id: <8306100417.AA03024@UCBJADE.CC.Berkeley.ARPA> Received: from by UCBJADE.CC.Berkeley.ARPA (3.320/3.28) id AA03024; 9 Jun 83 21:17:28 PDT (Thu) Received: from UCBJADE.CC.Berkeley.ARPA (ucbjade.ARPA) by UCBVAX.ARPA (3.341/3.31) id AA04866; 9 Jun 83 21:19:34 PDT (Thu) To: msggroup@brl.ARPA Hi, In response to Mark's message (and, speaking directly from EBCDIClandia) I will mention that even restricting 'encoded' binary data to printable ASCII characters will break. Possibly, you could encode using ONLY {A-Z,a-z,0-9}. If you want to build a reasonable Ascii<->Ebcdic gateway, you HAVE to know what the data you are trans- ferring is - in order to know what translate table (sigh) to use. Either the network can do the translation - imperfectly but possibly functionally - or the translation can be left up to the end user (agent). In the latter case the translation will be done 'perfectly' if the entity can handle that one of the N possible translations - if it can't handle that particular one, you will surely wish the network had done it. I vote for the octets. Is there an octet code saying "IBM yellow card (now book) EBCDIC - left column"? Greg Minshall 10-Jun-83 00:38:04-PDT,2751;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 00:36:32-PDT Received: From Su-Score.ARPA by BRL via smtp; 10 Jun 83 1:32 EDT Date: 9 Jun 83 22:34:17-PDT (Thu) From: Mark Crispin Subject: MSGGROUP#2087 SMTP performance tests/results To: MsgGroup@BRL.ARPA cc: Postel@USC-ISIF.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Folks, As promised, I am experimenting with having Score run a mailer which sends 400-byte segments and does not Push except when required by the protocol. This is in answer to various sites (particularly SATNET and some of the Unix systems on our local network) which had trouble with 40-byte segments. I've discovered that most of the hosts which exhibited the hanging problem no longer do so. However, some hosts still do. For your amusement, here are the ones I've discovered so far. AFSC-HQ (TOPS-20) hangs KESTREL (Tenex) hangs or connection dies during transfer MIT-MULTICS (Multics) hangs, later retry worked NLM-MCS (TOPS-20) hangs OFFICE-3 (Tenex) hangs or connection dies during transfer PARC-MAXC (Tenex) hangs, later retry worked SANDIA (TOPS-20) hangs SRI-CSL (Tenex) hangs or connection dies during transfer By "hangs" I mean that more than two minutes of real time was expended attempting to send 1000 bytes. MIT-MULTICS only had one hit that hung and a subsequent retry succeeded. So the jury is still out but we could consider this problem to be noise. I have verified that AFSC-HQ and NLM-MCS do not have the TVRFIL kernal bugfix; I suspect but have not proven that the same is true of SANDIA. As this bugfix is crucial for the proper performance of the TOPS-20 SMTP server, this probably accounts for their problems. There was no hanging observed with TOPS-20 systems which do have this bugfix. To send SMTP mail to a TOPS-20 site which does not have the bugfix, you have to send small segments (e.g. 40 bytes) and Push every segment. All of the Tenex systems to which mail was addressed from Score exhibited the problem. Some messages succeeded after many retries, most never got there. I found that setting Push on every segment worked on at least two sites, SRI-CSL and KESTREL; 400 byte segments worked as long as Push was set. PARC-MAXC is the exception to the Tenex rule in that after several retries a message was delivered without having to use small segments or set Push on every segment. -- Mark -- PS: On a side note, JPL-VAX rejects mail with the message "(No such file or directory) Mail trouble (sndmsg balks), try later". ------- 10-Jun-83 01:10:45-PDT,1214;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 01:10:37-PDT Received: From Usc-Ecl.ARPA by BRL via smtp; 10 Jun 83 2:27 EDT Date: 9 Jun 1983 2322-PDT Sender: ESTEFFERUD@usc-ecl Subject: MSGGROUP#2088 [Crispin : Re: possible loop ...] From: ESTEFFERUD@usc-ecl To: msggroup@brl Message-ID: <[USC-ECL] 9-Jun-83 23:22:59.ESTEFFERUD> Here is the explaination of where and how the recent mail loop occured. BRL was not the cause, nor was SU-SCORE, though SCORE was closer to the site that was sending it back to msggroup@brl. I had thought that this had gone to the whole msggroup list. Sorry bout the delay. Best - Stef Begin forwarded message Date: Wed 8 Jun 83 18:37:43-PDT From: Mark Crispin Subject: Re: possible (probable?) mail loop To: v.wales@UCLA-LOCUS.ARPA cc: estefferud@USC-ECL.ARPA, mcgregor.hp-hulk@RAND-RELAY.ARPA In-Reply-To: Message from "Rich Wales " of Wed 8 Jun 83 18:33:45-PDT Yes, it was a problem at Diablo. Apparently they ran sendmail with the "t" instead of the "T" option. Yet another good reason to hate Unix I guess. End forwarded message 10-Jun-83 00:58:05-PDT,2421;000000000000 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 00:54:28-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 10 Jun 83 2:11 EDT Date: 10 June 1983 01:35 EDT From: Ken Harrenstien Subject: MSGGROUP#2089 Explanation of endless NBS messages To: HEADER-PEOPLE@mit-mc cc: MsgGroup@brl I tried to track down the source of the recent stream of duplicated messages, and it appears that they were falling victim to a bug somewhere at Stanford. What made it difficult was the fact that the original message went to not one but two large mailing lists (it would have been three, but fortunately the incorrect name "name-droppers" was used instead of "namedroppers"!) Enclosed are the two most informative messages which resulted: ---------------------------------- Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Thu 9-Jun-83 19:46:08-EDT Date: Thu, 9 Jun 83 19:48 EDT From: Mike McMahon Subject: Loop tracing To: KLH@MIT-MC In-reply-to: The message of 9 Jun 83 15:39-EDT from Ken Harrenstien Message-ID: <830609194825.2.MMcM@SCRC-TENEX> I'd be curious to know what you learn. What I guessed from my mail was that a host named "diablo" was plugged in where su-shasta should be. header-people goes to csl.bkr@score, which goes to reid@shasta. Diablo probably had a broken piece of mail software (like /etc/delivermail without setuid root, wasn't the the explanation last year?) which parses the to: field to find out who to send to, giving it right back to mc. Like I said, this is entirely guesswork, but confirmed a little bit by some troubles Jan Walker was having sending to Brian Reid. ---------------------------------- Date: Thu 9 Jun 83 17:09:39-PDT From: Bill Nowicki Subject: Mailing loop To: klh@MIT-MC.ARPA For a short period of time yesterday afternoon there was such a loop, but it was fixed. Sorry for the inconvenience. -- Bill ------- ---------------------------------- Considering that this is not the first time this has happened (ie it can happen again) and that the size of mailing lists has become rather awesome, perhaps it is time to revive the old ideas for detecting and killing mail forwarding loops. I suggest that any such discussion be confined to Header-People, which is oriented to hairy technical bull sessions. --Ken 10-Jun-83 03:08:13-PDT,1201;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 03:05:34-PDT Received: From Cmu-Cs-A.ARPA by BRL via smtp; 10 Jun 83 3:53 EDT Date: 10 June 1983 0351-EDT From: Rudy.Nedved@cmu-cs-a To: MsgGroup@brl Subject: MSGGROUP#2090 UUCP mail Message-Id: <10Jun83.035142.EN0C@CMU-CS-A> My apology for adding an old subject to the fire. I was wondering if the following would work: Assuming that each UNIX site knows who it calls and who calls it for UUCP mail then each UNIX site could broadcast as a news item its current "connection table". In turn, a site could generate from the news items a "path" to use to send mail to a UNIX site. If a user specified a host which has a possible path between it and the current host in the graph generated from the news items, the mail delivery system could prepend a path specification to the uucp "host!user" pair and use it. Otherwise, an error would be generated indicating "host not known" or "no known path" and the user would have to specify the path if he/she knew it. Does this "flattening" of the address space solve the problems that the UUCP folks have with having "domains"? Curious, -Rudy 10-Jun-83 07:11:02-PDT,946;000000000000 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 07:07:48-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 10 Jun 83 7:27 EDT Received: From Brl-Vgr.ARPA by BRL-BMD via smtp; 10 Jun 83 7:18 EDT Date: 10 Jun 83 7:13:36 EDT (Fri) From: Doug Kingston To: msggroup@brl-vgr cc: howard@brl-vgr, gwyn@brl-vgr Subject: MSGGROUP#2091 Mis-directed mail The two pieces of mail that got in to MSGGROUP were the result of a bug in the MMDF loop detection software. We all saw many copies of the NBS letter. What you don't know is that MMDF rejected a good many more. I estimate that about two thirds of the looped messages were rejected at BRL for looping. The criteria was that those messages had more than 15 Received: lines. Unfortunately, this little used code did not clear the address list before starting to read the next message... One bug begets another, Sigh. -Doug- 10-Jun-83 09:00:15-PDT,1638;000000000000 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 08:58:29-PDT Received: From Su-Score.ARPA by BRL via smtp; 10 Jun 83 11:16 EDT Received: from Glacier by Score with Pup; Fri 10 Jun 83 08:18:45-PDT Date: 10 Jun 1983 08:18-PDT (Friday) To: Ken Harrenstien Cc: HEADER-PEOPLE@mit-mc, MsgGroup@brl Cc: nowicki@diablo Subject: MSGGROUP#2092 Re: Explanation of endless NBS messages In-reply-to: Your message of 10 June 1983 01:35 EDT. From: Brian Reid The mail loop this time was caused by a new Berkeley 4.1C program that we had just installed on one of our VAXen (Diablo). It is called "sendmail", and it is supposed to replace the old "delivermail" that was indirectly the cause of last year's loop. The loop path was CSL.Lantz@Score-->lantz@Diablo-->loop. The loop was tracked down and fixed by Bill Nowicki. I don't know anything about the details of this loop, or about the "sendmail" program, but the word that I hear in the halls around here is that sendmail is really complex and incomprehensible (and therefore terrible) and that it is not at all a step forward from the old delivermail. Since it is Berkeley's intention that all Berkeley Unix sites convert to sendmail soon, and since we had this trouble with it, it might be worthwhile getting Bill to explain the loop so that other sites, when installing this new software, do not make the same mistake. Bill seemed to think that part of the cause was a very dangerous feature of the program (that got accidentally invoked), which perhaps Berkeley could be persuaded to remove. 11-Jun-83 04:53:57-PDT,2288;000000000000 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 04:50:36-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 11 Jun 83 7:31 EDT Date: 10 Jun 1983 1041-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2093 Re: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 10 Jun 1983 10:43:29-PDT To: LCAMPBELL@dec-marlboro, Mark@rand-relay, Horton@rand-relay, cbosgd!mark@ucb-c70, msggroup@brl Cc: MCGREGOR.HP-HULK@rand-relay In-Reply-To: Your message of 9-Jun-83 1205-PDT Message-Id: <424115011.26779.hplabs@HP-VENUS> Via: HP-Labs; 11 Jun 83 4:14-PDT In Larry Campbell's last letter to Mark Horton, he writes, This is an important and often neglected principle in standards processes: DON'T FAVOR ANYONE OR THE LESS FAVORED PEOPLE WILL IGNORE OR SUBVERT THE STANDARD. In a previous letter, Larry supported the NBS standard over RFC822 for text, brushing aside the implementation arguments that I had given. While NBS does not require its internal information to be encoded in any particular format, several passages in the standard suggest the use of ASCII for communicating text is assumed. Undoubtedly, this is because ASCII is the national text standard. All this is fine and good at the theoretical level, but implementation problems DO raise their ugly heads. Sending mail that uses two encoding schemes (NBS for headers, ASCII for text) will favor computer systems that support those codes already. Nobody had NBS, so no one was favored there, but lots of people have ASCII, but some don't. Those who don't include IBM and IBM plug compatable machines. Since these people are less favored, they will subvert the standard (according to Larry's Dictim), which is in fact what happened in the case that I reported. HP Pinewood decided that NBS was too hard to implement if communication to EBCDIC machines was desirable, so it chose a different standard, RFC822, that was less viscious in its treatment of EBCDIC machines. I know Larry is a proponent of NBS, and would not use his Dictim in support of this action, but I think that HPs actions can be understood in terms of his principle. ------- 10-Jun-83 14:02:44-PDT,3833;000000000000 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 13:58:09-PDT Received: From Bbna.ARPA by BRL via smtp; 10 Jun 83 15:21 EDT Date: 10 Jun 1983 1519-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2094 Re: problems with NBS standard From: DDEUTSCH@bbna To: MCGREGOR.HP-HULK@rand-relay Cc: DDEUTSCH@bbna, msggroup@brl, header-people@mit-mc Message-ID: <[BBNA]10-Jun-83 15:19:55.DDEUTSCH> In-Reply-To: <424029107.4147.hplabs@HP-VENUS> Just a few points in response. The NBS message format standard was published for public review twice before it became a standard. Copies were sent out to every vendor of computer based message systems that NBS could identify, every person/organization who requested one, other individuals that hadn't requested copies but NBS thought might be interested, and other national and international standards organizations working in the area. Of all the comments that came back, I can't remember a single one that said the then proposed standard was too difficult to implement, and should be discarded. In fact, the nature of a standard message format (text-based or otherwise) is that some translation between the transfer-syntax and internal form almost always takes place. For example, the system that I am using now stores my draft message as a list of pointers to fields. The pointers are associated with binary numbers that identify the field names; the fields themselves are stored in various formats, according to their types (address, date, text, etc.). So when I tell my system to send the draft message, it must translate from its internal form to RFC822; when I tell it to show me the draft message it must translate from its internal form to a character stream that my terminal can handle. My system does that in order to facilitate the process of composing and editing draft messages. The designers of message systems sometimes find it advantageous to store received messages in a specialized internal format (such as an inverted database). So translators are often used to optimize performance/functionality in various parts of message systems when a internal format can take advantage of local architecture and resources. I am sorry that you must deal with ASCII/EBCDIC translations - the world would be a (slightly) better place if one character encoding scheme could be universally agreed upon. However, any standard issued by NBS must use ASCII. First of all, ASCII is the NBS standard character set. Having the message format standard allow EBCDIC would have been inconsistant. ASCII came to NBS (and the rest of the country) from ANSI. (ANSI has a lot of IBM participation, by the way.) ASCII is also a subset of IA5, the ISO standard for character sets. So, allowing EBCDIC would put NBS in violation of ANSI and ISO standards. Can you imagine the hue and cry from all the folks who are in compliance with ASCII if NBS permitted the use of EBCDIC? By the way, I have never heard an IBM representative argue against the use of ASCII and for the use of EBCDIC at a standards meeting. You can use your favorite vendor-supported translation program on the contents of any NBS ASCII-String data element. The rest of the format would remain the same, no matter which character set was native. There is a flaw in your trucks vs. cars/motorcycles. A manufacturer of motor vehicles would be overjoyed if a given part could be used for both trucks and cars. It usually is cheaper to make one kind of component than two different kinds of components. The same is true in the standards world. It is generally preferable to have a single general-purpose standard than a number of specialized ones. That's the whole idea of having standards in the first place. Debbie 10-Jun-83 15:17:54-PDT,8350;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 15:14:24-PDT Received: From Bbna.ARPA by BRL via smtp; 10 Jun 83 17:30 EDT Date: 10 Jun 1983 1731-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2095 Re: problems with NBS standard From: DDEUTSCH@bbna To: cbosgd!mark@berkeley Cc: msggroup@brl Message-ID: <[BBNA]10-Jun-83 17:31:40.DDEUTSCH> In-Reply-To: <8306090514.AA16924@cbosgd.UUCP> (Long message, beware.) The people working on multimedia mail on the Internet do not encode messages using ASCII characters. They use 8-bit bytes. (I believe the pertinent RFCs are 757 and 769.) I also agree with Greg Minshall about gateways and translation tables. It just does not make sense to try to make everything into characters. What Scott McGregor said was this: "Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail." That does not sound like he was talking about SMTP and TELNET. You are wrong when you say: "Something with knowledge of the mail formats has to do the ASCII-EBCDIC translation; this is contrary to the nice layered OSI approach." It is true that you have to know the mail format in order to extract the ASCII or EBCDIC string. However, this is not contray to the OSI approach. The presentation layer is supposed to take care of ASCII-EBCDIC translation. In fact, it deals with data translation in general. Here is what the December 3 1982 revision of DIS 7498 (the ISO reference model) says about the presentation layer. "7.2 The Presentation Layer 7.2.1 Definitions No Presentation Layer specific terms are identified. 7.2.2 Purpose The Presentation Layer provides for the representation of information that application-entities either communicate or refer to in their communication. The Presentation Layer covers two complementary aspects of this representation of information: a) the representation of data to be transferred between application-entities; and b) the representation of the data structure which application-entities refer to in their communication, along with the representation of the set of actions which may be performed on this data structure. The Presentation Layer is concerned only with the syntax, i.e. the representation, of the data and not with its semantics, i.e. their meaning to the Application Layer, which is known only by the application-entities. The Presentation Layer provides for a common representation to be used between application-entities. This relieves application entities of any concern with the problem of "common" representation of information, i.e. it provides them with syntax independence. This syntax independence can be described in two ways: a) the Presentation Layer provides common syntactical elements which are used by application-entities; and b) the application-entities can use any syntax and the Presentation Layer provides the transformation between these syntaxes and the common syntax needed for communication between application-entities. This transformation is performed inside the open systems. It is not seen by other open systems and therefore has no impact on the standardization of presentation protocols. In this International Standard the approach outlined in b) is used. 7.2.3 Services provided to the Application Layer The Presentation Layer provides session-services (see 7.3) and the following facilities: a) transformation of syntax; nd b) selection of syntax Transformation of syntax is concerned with code and character set conversions, with the modification of the layout of the data, and the adoption of actions on the data structures. Selection of syntax provides the means of initially selecting a syntax and subsequently modifying the selection. 7.2.4 Functions within the Presentation Layer The Presentation Layer performs the following functions to help accomplish the presentation-services: a) session establishment request; b) data transfer; c) negotiation and renegotiation of syntax; d) transformation of syntax including data transformation and formatting and special purpose transformations (e.g. compression); and e) session termination request. 7.2.4.1 Transformation of syntax There are three syntactic versions of the data; the syntax used by the originating application-entity, the syntax used by the receiving application-entity, and the syntax used between presentation-entities ("the transfer syntax"). It is clearly possible that any two or all three of these syntaxes may be identical. The Presentation Layer contains the functions necessary to transform between the transfer syntax and each of the other two syntaxes as required. There is not a single predetermined transfer syntax for all OSI. The transfer syntax to be used on a presentation-connection is negotiated between the correspondent presentation-entities. Thus, a presentation-entity must know the syntax of its application-entity and the agreed transfer syntax. Only the transfer syntax needs to be referred to in the Presentation Layer protocols. To meet the service requirement specified by the application-entities during the initiation phase, the Presentation Layer may utilise any transfer syntax available to it. To accomplish other service objectives (e.g.data volume reduction to reduce data transfer cost), syntax transformation may be performed either as a specific syntax-matching service provided to the application-entities, or as a function internal to the presentation layer. 7.2.4.2 Negotiation of syntax Negotiation of syntax is carried out by communication between the presentation-entities on behalf of the application-entities to determine the form that data will have while in the OSI environment. The negotiations will determine what transformations are needed (if any) and where they will be performed. Negotiations may be limited to the initiation phase or they may occur any time during a session. In OSI, the syntaxes used by application-processes that wish to communicate may be very simialr or quite dissimilar. When they are similar, the transformation functions may not be needed at all; however, when they are dissimilar, the Presentation Layer services provide the means to converse and decide where needed transformations will take place. 7.2.4.3 Addressing and multiplexing There is a one-to-one correspondence between presentation-address and session-address. There is no multiplexing nor splitting in the Presentation Layer. 7.2.4.4 Presentation Layer management The Presentation Layer protocols deal with some management activitieis of the layer (such as activiation and error control). See clause 5.9 for relationship with other management aspects." (Sorry about having to include the whole thing; there is very little that made sense to leave out.) As you can see, the "nice layered OSI approach" has a layer for data transformation, including structured data (like NBS messages). The NBS message format standard is a transfer syntax. If the local presentation entity takes structured, mixed data and treats it as if it were an ASCII or EBCDIC character stream, the problem lies with the local presentation entity, not the data. The local presentation entity must be able to deal with all types of data sent or received by its user (application-entity). The NBS-to-RFC733 translating program only has to be callable by, not included in, software that prints messages. I use a TOPS-20 for my mail reading/writing activities. It has no analogue to "type" or "cat" commands for individual messages. To read or write messages, I must use special mail software. This is the general case, especially for commercial mail systems. There is no real advantage in being able to use just the usual text editor or file-listing command if that's not what is being used. Debbie Deutsch 10-Jun-83 23:06:31-PDT,4233;000000000000 Return-path: Received: from BRL by USC-ECLC; Fri 10 Jun 83 23:05:48-PDT Received: From Su-Score.ARPA by BRL via smtp; 10 Jun 83 21:30 EDT Received: from Diablo by Score with Pup; Fri 10 Jun 83 18:32:17-PDT Date: 10 Jun 83 18:31 PDT (Fri) From: Bill Nowicki Subject: MSGGROUP#2096 Mail Loop explanation To: DCrocker@udel-relay, KLH@mit-mc, reid@glacier Cc: HEADER-PEOPLE@mit-mc, MsgGroup@brl, mailhax@BRL.ARPA Some people have requested a few more details of our experience with sendmail and the disaster which caused a mail loop on Wednesday June 8. First some background: At Stanford we run 4.1BSD Unix with BBN TCP code, with CMU packet filtering on 3 Mbit Ethernets connecting about a dozen VAXes (and many other machines). We would like to use 4.2 whenever (if ever?) it finally gets done, so we got a 4.1c beta distribution and were trying to phase in some of the user programs on that release, like sendmail. The predecessor of sendmail, delivermail, we had customized slightly by changing a few tables and recompiling. It read the host name by the gethostname() system call, so we could take the program (or an entire disk pack for that matter) from one system to another and it would work. Sendmail contains an SMTP server as well as the other mail switching and aliasing functions of delivermail. Integrating the SMTP server and the aliasing turns out to be a good idea, but all sorts of other "features" were added to sendmail in the mean time. For example, instead of having compile-time tables and modular code, there are enormous configuration files that are read at run-time. You have to specify a "program" to parse your addresses using an incredibly unfathomable production language. The host name is hard-wired into the configuration file, so they are not portable between machines anymore. Part of the confusion came from the distinction between switches entered on the command line, commands in the configuration file, options which can be given on the command line OR in the configuration file (with yet another strange syntax), mailer flags, and configuration file macros. All five of these are represented by single character case sensitive identifiers, with different meanings for the letters in many cases. A vertiable lesson in terrible user interfaces. The specific problem came when we discovered a case in which our TOPS-20 SMTP mailer would open a connection, send part of a message, and then simply give up without sending a RESET packet. The BBN TCP code had no timeouts, so the connection would stay around forever, along with the two sendmail processes and the spool files. I remembered reading about a timeout feature, and glancing at the manual found it was the "t" option. So I ran sendmail with the "t" switch on the command line. There were two mistakes: first, the timeout is an Option, not a Switch, and secondly it is upper case T not lower case t. I was silly enough to think that since it gave me no error message that everything was OK, and went off to our research group meeting. When I came back after the meeting I looked at the log file and noted some suspicious behaviour. What it was doing was sending a copy of each message to the people listed in the "To:" and "Cc:" fields in the header, as well as the person given in the RCPT TO:<> command of SMTP. This resulted in the loop back through our local Ethernet, the Arpanet, the MIT Chaos Net, as well as several nets at BRL and BBN! I killed the server after about an hour, and restarted it with the right options (although the timeout still does not do anything), but the duplicated mail took at least two days to stop bouncing through the net. Morals (some are my personal opinions): 1. Case sensitivity is a bad idea. 2. Single letter identifiers are a bad idea. 3. Multiple notions that are similar are confusing. 4. Large (multi-domain) mailing lists should have a moderator. 5. Timeouts should be in SMTP servers and TCP implementations by default. 6. internet mail systems are fragile things. 7. "Improved" software with more "features" usually isn't. -- Bill 11-Jun-83 05:18:01-PDT,1930;000000000000 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 05:13:44-PDT Received: From Rand-Relay.ARPA by BRL via smtp; 11 Jun 83 7:40 EDT Date: 10 Jun 1983 2003-PDT From: Scott L. McGregor Return-Path: Subject: MSGGROUP#2097 Re: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 10 Jun 1983 20:04:13-PDT To: DDEUTSCH@bbna, MCGREGOR.HP-HULK@rand-relay Cc: msggroup@brl, header-people@mit-mc, MCGREGOR.HP-HULK@rand-relay In-Reply-To: Your message of 10-Jun-83 1219-PDT Message-Id: <424148654.14765.hplabs@HP-VENUS> Via: HP-Labs; 11 Jun 83 4:17-PDT I have no problem with NBS as a standard, nor do I propose EBCDIC as a standard. I only point out that it is harder to implement NBS for sending text than RFC822 when you are implementing for an IBM computer using EBCDIC. Some mail systems do more layering separating internal format from presented format. This is nice and gives one more capabilities, but it is more difficult to implement. Such systems take more time to develop and may be prone to more bugs. If one is concerned with expediency of getting a mail transport up, as HP was, then RFC822 was easier and so was chosen. >From some of your comments I can only conclude that NBS is like bad tasting medicine, It tastes bad at first, but it is good for you in the long run. You may be right, but don't be suprised if the natives turn to the local witchdoctors for a while, at least until they see results. I am a bit sorry about that for NBS fans, that seems to be reality of how implementations go. I'm sure in a few years this will all be past history and implementing NBS will be much easier, particularly if vendors provide implementors with smarter interfaces. Please don't paint me as an NBS opponent, I'm just one of the wounded. Scott L. McGregor ------- 11-Jun-83 02:18:39-PDT,1083;000000000000 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 02:18:27-PDT Received: From Mit-Mc.ARPA by BRL via smtp; 11 Jun 83 4:32 EDT Received: from Diablo by Score with Pup; Sat 11 Jun 83 01:33:58-PDT Date: 11 Jun 1983 01:33-PDT (Saturday) To: msggroup@mit-mc Subject: MSGGROUP#2098 "Received" line in headers From: Tim Mann Since Jon Postel has pointed out that Received lines are supposed to be added to the top of headers, perhaps Berkeley will be prompted to conform to the standard. Mail that goes through their Vaxes currently has a 2-line Received line added in the middle of the header, after other Received lines. What's worse, the version of sendmail distributed with 4.1c Unix generate Received lines in this way, and is rather difficult to change -- getting new Received lines to appear in front of the old ones requires hacking the program, not just changing a configuration file. We may see a flood of incorrect Received lines when 4.2 Unix is released if this is not corrected soon. --Tim 11-Jun-83 10:32:05-PDT,805;000000000000 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 10:30:22-PDT Received: From Udel-Relay.ARPA by BRL via smtp; 11 Jun 83 13:05 EDT Date: 11 Jun 83 7:04:35-EDT (Sat) From: Larry Layten Return-Path: Subject: MSGGROUP#2099 Re: problems with NBS standard To: DDEUTSCH@bbna Cc: MCGREGOR.HP-HULK@rand-relay, DDEUTSCH@bbna, msggroup@brl, header-people@mit-mc Via: Darcom-HQ; 11 Jun 83 12:40-EDT So now we have two standards. One of them has been adopted by the DOD/DDN/ARPANET community, and is in operation. Can someone indicate what the base of support is for the NBS standard. If that base is not strong enough, maybe changes to the NBS standard wouldn't be too difficult to implement. Larry 11-Jun-83 13:46:27-PDT,3217;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 11 Jun 83 13:44:23-PDT Received: From Bbna.ARPA by BRL via smtp; 11 Jun 83 16:19 EDT Date: 11 Jun 1983 16:09-EDT Sender: DDEUTSCH@bbna Subject: MSGGROUP#2100 Re: problems with NBS standard From: DDEUTSCH@bbna To: llayten@darcom-hq Cc: DDEUTSCH@bbna, MCGREGOR.HP-HULK@rand-relay Cc: msggroup@brl, header-people@mit-mc Message-ID: <[BBNA]11-Jun-83 16:09:21.DDEUTSCH> In-Reply-To: The message of 11 Jun 83 7:04:35-EDT (Sat) from Larry Layten The NBS standard is being used in the commercial sector. When it was published for review, comments were almost unanimously favorable. It just became a standard this January, and will not come up for review for several years. A discussion about what people do and do not like about the standard can be interesting and informative, but it will not lead to any changes in the standard in the near future. The NBS standard was written with full cognizance of RFC 733 (RFC 822 had yet to be written, and isn't fundamentally different). There was a conscious decision to use a binary encoding instead of a text-based encoding, for the reasons I have already given (plus a few others). The main objection that I have heard in this discussion is that people don't like binary encoding. These people much prefer text-based encoding. However, that is not the feeling in the commercial standards arena. The purpose of NBS standards is to govern procurements of the federal government. As Scott has pointed out, a standard isn't worth the paper it is printed on if nobody implements it. However, vendors have indicated that the standard is acceptable to them by their comments made during the review process and by their explicit announcements that they will support it. It is the endorsement of the vendors that is important in approving a FIPS, and NBS has received that endorsement for its message format standard. When the standard comes up for review in a few years, NBS will again consider what to do. At that time, if the vendors say that the standard could not be implemented cost-effectively, or that there was some serious technical flaw, NBS would probably want to reconsider the whole matter. On the other hand, if the vendors are still happy with the standard, NBS would probably only consider refinements to the current document. (Of course, the other important players are the government agencies that buy from the vendors. They were also quite supportive of the standard when it went out for comment.) The important contribution that MsgGroup can make is to come up with ideas that will be helpful during the next review period. So far, people who have actually implemented the standard have reported no problems. If this trend continues, NBS will be interested in ways of extending the standard where additional functionality may be warranted, and refining the standard where a simpler or more powerful mechanism can be substituted for what is already there. Of course, if somebody were to implement the standard and then find a problem with it, NBS would be very interested indeed! Debbie