Date: 10 June 1980 1251-EDT (Tuesday) From: Richard H. Gumpertz Subject: bogus headers in mail To: Header-People at MIT-MC CC: Howard.Wactlar at CMU-10A Message-ID: <10Jun80 125100 RG02@CMU-10A> Given the stink that has been made about our spaces in names, which are perfectly legal, why are we still being inflicted with the TENEX generated addresses of the form [Site]FILNAME: such as the one I keep getting [SRI-KL]liason-sndmsg.txt: Isn't it about time that the TENEX sites cleaned up their acts as well? Rick  Date: 13 June 1980 1134-EDT (Friday) From: Richard H. Gumpertz Subject: CMU-10a will be down for a week To: Feinler at SRI-KL CC: MsgGroup at MIT-MC, Header-People at MIT-MC Message-ID: <13Jun80 113458 RG02@CMU-10A> CMU-10a will be down for about 10 days starting this evening. We are moving the machine to a new room. If any of you have automatic mail delivery programs which give up after less than a week you might consider taking appropriate action. Our scheduled return to the net is on Monday, June 23, but that date is somewhat tentative either way. For urgent mail, many of the CMUA users who have regular dealings with the network community also have mailboxes on CMU-10B and/or CMU-10D. You can check by TELNETing to one of those sites and saying (without any LOGIN needed) FINGER (or by using your local FINGER, if you have one). In general, all addresses on the two alternate machines are identical to those on CMUA, except for the host name, of course. Rick Gumpertz  Date: 24 June 1980 1605-EDT (Tuesday) From: Brian Reid at CMU-10A Subject: Mail to CMUA lost To: BBoards: News at BBN-Unix, BBoard at CMU-10A, BBoard at CMU-10B, BBoard at CMU-10D, News at EDN-Unix, *MAC at MIT-MC, News at NPS, BBoard at Rand-AI, BBoard at Rutgers, BBoard at DARCOM-KA, BBoard at SRI-KL, BBoard at SRI-Unix, BBoard at SU-SCORE, BBoard at SU-AI, Bulletins at SUMEX-AIM, BBoard at USC-ISIB, BBoard at USC-ISIE, BBoard at USC-ECL, BBoard at Utah-20;, Net-Users: MsgGroup at MIT-MC, Header-People at MIT-MC; Message-ID: <24Jun80 160504 BR10@CMU-10A> Essentially all mail delivered to CMUA between June 13 and June 24 was lost in a head crash today and should be resent if it was important.  Date: 18 SEP 1980 2024-EDT From: MOON5 at MIT-MC (David A. Moon) To: HEADER-PEOPLE at MIT-MC The Header-People mailing list has been broken for a few weeks. It is fixed now. Here is the mail that you didn't see. (Not very exciting, it just deals with headers.) Date: 17 Sep 1980 0012-EDT From: GEOFF at DEC-2136 To: Header-People at MC Subject: DEC's MS takes the lead in the meaningful MESSAGE-ID Dept. Message-ID: [DEC-2136].11665191777.21.8589934664.22967 Move over Multics! -------- Date: 17 Sep 1980 1611-EDT From: GEOFF at DEC-2136 To: Header-People at MC Subject: DEC's MS MESSAGE-ID's surpass Multics's for obsecurity. Message-ID: [DEC-2136].11665366441.14.8589934664.1520 Anyone care to take a guess what it all stands for? Geoff  Date: 21 Sep 1980 22:12 PDT From: Stewart at PARC-MAXC Subject: message addresses To: Header-People@AI cc: Stewart From: web Do any of you know of a way to get this past a Tenex mailer as a To: address? -Larry  Date: 22 Sep 80 09:03-EDT (Mon) From: Dcrocker at Darcom-HQ Subject: Re: message addresses To: Stewart at Parc-Maxc cc: Header-People at Mit-Ai Message-ID: <80265.32584.6980 @ Darcom-HQ> In-Reply-To: Your message of 21 Sep 1980 22:12 PDT I don't know how to get it past the user program, so that it is queued. However, having it queued under the filename [---unsent....].dsp^V.dove^V at^V mit-speech@mit-speech should work. (Not sure about the @... stuff or the exact sequence for the unsent-mail portion.) For reference, puting the mailbox part (dsp...speech) in double quotes would be the way to get it past an RFC733 parser, which no one has a full implementation of... (Sorry for all the ellipses, but it's early in my morning and nothing feels complete.) Dave (DCrocker @ UDel). p.s. are you sure that the mit-ai ftp server will handle dsp.dover at mit-speech in its MAIL or MLFL command line?  Date: 22 Sep 80 18:29:32-CDT From: Rich Zellich Subject: Re: message addresses To: Stewart at Parc-Maxc Cc: Header-People at Mit-Ai, Dave Crocker , "DSP.DOVER at MIT-SPEECH" at MIT-AI In-Reply-To: <80265.32584.6980 @ Darcom-hq> Dave is right - the indicated sequence works fine. I wonder what both the MIT-AI server did with DSP.DOVER AT MIT-SPEECH and, if it was actually delivered, what the MIT-Speech system made of it because I didn't send an RFC733-standard message, but merely a 6-character file containing "test".... I don't know how to get it past the Tenex user programs, either, but you can always put a temporary address in place of the one you want, tell the program (MSG, HERMES, etc.) to Queue it instead of sending immediately, and then rename the appropriate [--UNSENT-MAIL--].* file to the address you really want. Cheers, Rich  Date: 22 Sep 1980 1644-PDT From: Mark Crispin Subject: Re: message addresses To: Stewart at PARC-MAXC cc: Header-People at MIT-AI In-Reply-To: Your message of 22-Sep-80 0603-PDT Yes, MIT-AI is quite capable of handling an address of the form DSP.DOVER@MIT-SPEECH in its MAIL or MLFL command line. So it SCORE's FTP server; and the MM mailsystem is also capable of processing such multiple host addresses. We've been sending mail back and forth between Chaosnet and ARPANET sites using MM/XMAILR for quite a while now. MM actually doesn't need to be told that MIT-SPEECH has to be reached via MIT-AI or some other MIT ARPANET site; MM works it out for itself and lets XMAILR have the option of selecting the route (XMAILR will pick another host if the first host it tries is down). By the way, Dave, where and what is DARCOM-HQ? It ain't in my host table. If it's a nickname, allow me to express my antipathy towards mailsystems which neglect to convert user-entered nicknames to official names before sending messages out on the network. -- Mark -- -------  Date: 22 Sep 1980 1659-PDT From: Mark Crispin Subject: addition to previous message To: Header-People at MIT-MC I should add that DEC's MS mailsystem (a cousin of MM which had a common ancestor about two years ago) is also capable of handling such addresses and of comprehending Chaosnet hosts without any routing specification if the user's site has the multi-network HOSTS2 host table available (see my RFC circa January '79 for more details of HOSTS2; HOSTS2 is the official host table at SU-AI, SU-SCORE, and most MIT systems). I had thought that HERMES would be dumb enough to not be smart enough to barf on that type of address. It was certainly the intent in the design of that format of address that it be legal and presumably other mailsystems would be capable of handling it if they merely treated "FOO@MIT-SPEECH" as a literal address to send to MIT-AI's FTP server. There probably are bugs in the old Tenex mailer daemon which make this impossible, though. -------  Date: 22 Sep 1980 1644-PDT From: Mark Crispin Subject: Re: message addresses To: Stewart at PARC-MAXC cc: Header-People at MIT-AI In-Reply-To: Your message of 22-Sep-80 0603-PDT Yes, MIT-AI is quite capable of handling an address of the form DSP.DOVER@MIT-SPEECH in its MAIL or MLFL command line. So it SCORE's FTP server; and the MM mailsystem is also capable of processing such multiple host addresses. We've been sending mail back and forth between Chaosnet and ARPANET sites using MM/XMAILR for quite a while now. MM actually doesn't need to be told that MIT-SPEECH has to be reached via MIT-AI or some other MIT ARPANET site; MM works it out for itself and lets XMAILR have the option of selecting the route (XMAILR will pick another host if the first host it tries is down). By the way, Dave, where and what is DARCOM-HQ? It ain't in my host table. If it's a nickname, allow me to express my antipathy towards mailsystems which neglect to convert user-entered nicknames to official names before sending messages out on the network. -- Mark -- -------  Date: 23 Sep 80 13:11-EDT (Tue) From: Dcrocker at UDel Subject: hostnames & from fields To: Header-People at Mit-Ai Message-ID: <80266.47474.9100 @ UDel> First of all, let me apologize for the fact that mail has gone out from this site with host references to Darcom-HQ. The apology is not for my/our error, but for the inconvenience. In fact, it was intentional and unavoidable. We notified Jake Feinler of the synonym, but that takes time to propogate and we could not wait for everyone's host table to get updated. You will note that we are now using the official hostname. Second, UDel-EE has always and only been a synonym and that didn't bother people, because it was in the host table. Hence, Mark's concern is a little misplaced. Now, the reason for the hassle: The machine which calls itself "UDel" and is attached to the arpanet is a Darcom (army) machine which we have an are using for some mail-relaying work we are doing for them. For a period of time, I had to have our software think of itself as Darcom-HQ, so that we could get a version of it down to an unattached machine in Washington. It will relay through us, so eventually, it will be passing mail onto the net under the name Darcom-HQ. This is identical with the way we have been sending mail out of Rand under the name UDel-EE, for over 1 1/2 years. This morning, I converted our system to think of itself as UDel. The official set-up is to become: UDel-EE is no longer a synonym for Rand-Unix. Host 114(decimal) is UDel, official name. The official synonym is to be Darcom-HQ. Other synonyms are to be: UDel-EE, UDEE, and Delaware. Dave.  Date: 23 Sep 1980 1227-PDT From: POSTEL at USC-ISIF Subject: Re: hostnames & from fields To: Dcrocker at UDEL, Header-People at MIT-AI cc: POSTEL In response to the message sent 23 Sep 80 13:11-EDT (Tue) from Dcrocker@UDel Dave: Host 114 decimal? I think it is time we started using "new" format numbers. Is that host 0 on imp 114, or host 1 on imp 50? --jon. -------  Date: 23 Sep 80 16:42-EDT (Tue) From: Dcrocker at UDel Subject: Re: hostnames & from fields To: POSTEL at Usc-Isif cc: Dcrocker at Usc-Isif, Header-People at Mit-Ai Message-ID: <80266.60144.8260 @ UDel> In-Reply-To: Your message of 23 Sep 1980 1227-PDT The Arpanet Directory show us as 1/50. I'll assume that is correct. Dave.  Date: 27 September 1980 15:14 edt From: Sibert at MIT-Multics (W. Olin Sibert) Subject: NBS Computer Standards Sender: Sibert.Multics at MIT-Multics To: header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI The following cheerful news is brought to us by the September 29 issue of Computerworld. Copyright (c) 1980 by CW Communications, Inc. Following ANSI guidelines: NBS to Give Format Standards Over Four Years Chicago - The National Bureau of Standards (NBS) will release over the next four years a series of format standards aimed at improving computer communications and integration and at aiding electronic mail transmissions between automated offices. The MBS-sanctioned standards - five in all - will be voluntarily developer by the user and vendor community, following American National Standrads Institute (ANSI) guidelines and processing requirements, according to James H. Burrows, director of the NBS' Institute for Computer Science and Technology (ICST). The ICST manages the governmentwide computer standards program and provides technical assistance to federal agencies. At the recent National Symposium on Office Automation, sponsored by the Data Processing Management Assicoation's Education Foundation (DMPA) here, Burrows gave a brief outline of each of the proposed protocol standards. The NBS standards will include: 1) A message interchange format standard, which will allow users of one system to send and receive messages from a foreign system. 2) A flexible disk format standard to establish common file formatting and labelling for flexible disks. 3) A text editing directives standard that will establish a common set of user directives for text editing systems. 4) A text formatting directives standard to provide directives for text formatting systems. 5) A message processing directives standard establishing a common set of directives for computer-based message systems. The latter three standards will provide a minimal level of functioanllity and help users switch from one text editing, formatting, or message system to another, Burrows explained. As a flagship for these five standards, the NBS is planning to release several guidelines geared to help users plan for, select, and evaluate computer based office machinery. The first guideline, "requirements analysis for office automation systems", which Burrows said will be available in late October or early November, will recommend a process to measure the benefits of office automation. Drafts of the requirements analysis guideline have already been circulated to a number of federal agencies and vendors for comments. ------------------------------------------------------- It all sounds kinda familiar, doesn't it? Remember NETED? Standard mail systems, described in an RFC too old for me to remember? Since the ARPAnet technical community has already been through exactly this same process, perhaps we should provide some input; presumably Mr. Burrows is the person to talk to.  Date: 27 Sep 1980 1623-EDT Sender: DDEUTSCH at BBNA Subject: Re: NBS Computer Standards From: DDEUTSCH at BBNA To: Sibert at MIT-MULTICS Cc: header-people at MIT-AI, human-nets at MIT-AI, Cc: msggroup at MIT-AI Message-ID: <[BBNA]27-Sep-80 16:23:12.DDEUTSCH> In-Reply-To: Your message of 27 September 1980 15:14 edt I believe that Marvin Sirbu mentioned (at least to MsgGroup) last spring that NBS was having BBN develop a message format standard. This is the very same standard as was mentioned in the CW article. We have finally made it to the "draft standard" stage. NBS will soon be publishing a document for public review. The lessons learned on the ARPAnet have not been ignored by either NBS or the draft standard's authors. After the public has made its comments and suggestions the draft standard will be revised into a final version. Debbie  Date: 29 Sep 1980 0841-EDT From: POGRAN at BBND Subject: Re: NBS Computer Standards To: Sibert.Multics at MIT-MULTICS, header-people at MIT-AI, To: human-nets at MIT-AI, msggroup at MIT-AI cc: POGRAN NBS/ICST has been an ARPANET participant just about as long as anyone else; I think we can safely assume that they are fully aware of the ARPANET experience in these areas. In particular, I think the fact that the goals, and the phrasing, sounded so familiar to us is an indication that NBS is aware. What NBS must now do is LISTEN to all the input they're soliciting from industry -- and still come up with technically valid standards, a la ARPANET. Ken Pogran -------  Date: Monday, 29 September 1980 11:12-EDT From: John A. Pershing Jr. To: POGRAN at BBND Cc: Sibert.Multics at MIT-MULTICS, header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI Subject: NBS Computer Standards It seems the one lesson to be learned from the ARPA Net (which NBS apparently hasn't learned) is that there IS such a thing as too many protocols. With DOD issuing their "standard" protocol, ANSI issuing theirs, yet another coming from Europe (CCITT), plus the extant ARPA Net, ChaosNet, PRNet, PUP, etc., etc., etc., this country needs another "standard" protocol about as much as I need another hole in my head. -jp  Date: 30 Sep 1980 (Tuesday) 0933-EST From: WATKINS at NBS-10 Subject: The NBS Standards Program in Computer Based Office Systems To: Sibert at MIT-MULTIC cc: header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI As manager of the NBS program in Computer Based Office Systems, I would be happy to receive any comments either on the general program of standards planned or any specific product. It would greatly expedite things, if comments were directed to me (either via netmail, USPS mail, or phone) rather than Jim Burrows or any of our contractors. The success of this standards program, as any, is dependent upon sound technical inputs from vendors, Government, users, and implementors. I look forward to hearing from the ARPANET community and certainly their voice of experience. Shirley Ward Watkins (301) 921-3516 National Bureau of Standards Bldg. 225 B226 Washington, D. C. 20234  Date: 1 Oct 1980 0348-PDT From: POSTEL at USC-ISIF Subject: Mail Plans To: header-people at MIT-AI There is a real effort to get the lower level protocols converted from the old arpanet only set to the new internet set, the most visible thing right now being the switch from NCPs to TCPs. In light of this plans are being made for computer mail service during and after this transition. RFCs 771 & 772 address some of the issues and suggest the direction. your comments are invited. --jon. -------  Date: 17 OCT 1980 0645-PDT From: BHUBER at USC-ECL Subject: 2741/X.25 Info Request To: Header-People at MIT-AI: Anyone have any technical info regarding support for IBM 2741 protocol devices on X.25 networks, specifically concerning time response characteristics of signal from ATTENTION/INTERRUPT key? Thanks, Bud Huber -------  Date: 18 October 1980 03:38-EDT From: Charles Frankston Subject: 2741/X.25 Info Request To: BHUBER at USC-ECL cc: HEADER-PEOPLE at MIT-MC Date: 17 OCT 1980 0645-PDT From: BHUBER at USC-ECL Anyone have any technical info regarding support for IBM 2741 protocol devices on X.25 networks, specifically concerning time response characteristics of signal from ATTENTION/INTERRUPT key? I'm just curious what sort of an answer you expect. Surely you realize that the protocol definition of an X.25 network does not define any performance parameters. Are you asking for metering statistics for an X.25 network such as Tymshare, Tymnet or Datapac? (I am not saying I have such statisticis). Do you care which one? Do you have any reason to believe that a TIP (or whatever they call them) that has 2741 support would exhibit significantly different transmission delays from an ASCII terminal on the same node? Lastly, are you just trying to ask how long until your keyboard is unlocked?  Date: 30 Jan 1981 2041-PST From: Zellich at OFFICE-3 (Rich Zellich) Subject: NBS Draft Report on Message Format Standard To: MsgGroup at MIT-ML, Header-People at MIT-MC cc: Parsons, Zellich Anyone who didn't receive a copy of the following report should take steps to obtain one: NBS Report No. ICST/CBOS - 80-2, "Specification of a Draft Message Standard" You can probably get one by writing to the address given for comments: National Bureau of Standards (Code CBOS) Systems and Network Architecture Division Technology Building, Room B218 Washington, DC 20234 -------  Date: 2 Feb 1981 (Monday) 0950-EST From: WATKINS at NBS-10 Subject: NBS Draft Report on Message Format Standard To: msggroup at MIT-ML, header-people at MIT-MC Copies of NBS Report NO. ICST/CBOS - 80-2, "Specification of a Draft Message Format STandard" may be obtained by sending netmail to watkins@nbs-10. Please send your USPS address with your request. Shirley  Date: Monday, 9 February 1981 20:49-EST From: JHAVERTY at BBND To: WATKINS at NBS-10 Cc: header-people at MIT-MC, msggroup at MIT-ML Subject: NBS Draft Report on Message Format Standard Shirley, I'd like to receive an official copy of the report: Jack Haverty Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02238 Tnx, Jack  Date: 12 Mar 1981 1937-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: quotes in Reply-To To: Header-People at MIT-MC cc: Woods at PARC-MAXC, LaurelSupport at PARC-MAXC If a mail program sees a line in the header looking like: Reply-To: "Bridge^"@PARC should it reply to "Bridge^" at PARC, or to Bridge^ at PARC? MM assumes the former, and PARC barfs on it. MM is happy to parse Reply-To: Bridge^@PARC with no hassles, sending to Bridge^ which is what PARC wants to see. -- Mark -- -------  Date: 12 Mar 1981 2132-PST From: Brian K. Reid Subject: Re: quotes in Reply-To To: Admin.MRC at SU-SCORE, Header-People at MIT-MC cc: Woods at PARC-MAXC, LaurelSupport at PARC-MAXC In-Reply-To: Your message of 12-Mar-81 1937-PST a field of "Bridge^"@Parc should send mail to (Bridge^) and not ("Bridge^"), i.e. the quotes are to be removed. -------  Date: 13 Mar 1981 0835-EST From: WJN at MIT-DMS (Wayne J. Noss) To: Admin.MRC at SU-SCORE Cc: Header-People at MIT-MC, Woods at PARC-MAXC, LaurelSupport at PARC-MAXC In-reply-to: Message of 12 Mar 81 at 1937 PST by Admin.MRC@SU-SCORE Subject: [Re: quotes in Reply-To] Message-id: <[MIT-DMS].189825> Mark, I think that Reply-To: "Bridge^"@PARC should mean exactly what it says--to reply to "Bridge^", quotes and all. There is no need to magicize a double quote. Introducing universal peculiarities to dodge peculiar behavior at some particular sites is neither necessary nor desirable. The protocol should be clear and simple (to the extent possible), and sites should then find ways to make it work. the WJN  Date: 13 Mar 1981 0947-EST From: PDL at MIT-DMS (P. David Lebling) To: WJN at MIT-DMS Cc: Admin.MRC at SU-SCORE, Header-People at MIT-MC, Woods at PARC-MAXC, LaurelSupport at PARC-MAXC In-reply-to: Message of 13 Mar 81 at 0835 EST by WJN@MIT-DMS Subject: [Re: [Re: quotes in Reply-To]] Message-id: <[MIT-DMS].189836> As it says in RFC733 (on p.11), "The quote character and characters which delimit syntactic units are not, generally, to be taken as data which is part of the delimited or quoted unit(s). ... In particular, the quotation-marks which define a quoted string ... are NOT part of the quoted-string..." And later in the same paragraph: "Quotation marks which delimit a quoted string ... should NOT accompany the quoted-string when the string is used with processes that do not interpret data according to this specification (e.g., ARPANET FTP mail servers)." Those who doubt (for some odd reason) that quoted strings are in the syntax are referred to pp.14-16, where the "BNF" gives (in compressed form): address = host-phrase host-phrase = phrase host-indicator phrase = 1*word word = atom / quoted-string Q.E.D. Dave  Date: 13 March 1981 1112-EST (Friday) From: Richard H. Gumpertz To: Mark Crispin Subject: Re: quotes in Reply-To CC: Header-People at MIT-MC, Woods at PARC-MAXC, LaurelSupport at PARC-MAXC In-Reply-To: Mark Crispin's message of 12 Mar 81 22:37-EST Message-Id: <13Mar81 111247 RG02@CMU-10A> It should put "Bridge^" at PARC in the HEADER but the FTP command line should read "MLFL Bridge^" when sent over the command connection. Rick  Date: 18 Mar 1981 1920-PST Sender: GEOFF at SRI-CSL Subject: Illegal header? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: Header-People at MC Cc: Wancho at DARCOM-KA Message-ID: <[SRI-CSL]18-Mar-81 19:20:04.GEOFF> I'm getting headers occasionally of the form From: John Q. Luser with no "@HOST" or "at HOST" after LUSER. It was my understanding that the host name always had to be specified, and that just having and not is illegal? The TOPS-20 MM program (and now new program on TENEX, which sent me such a message tonight) is generating the above style header. Legal or Illegal?  Date: 18 Mar 1981 1949-PST From: POSTEL at USC-ISIF Subject: Re: Illegal header? To: Geoff at SRI-CSL, Header-People at MC cc: Wancho at DARCOM-KA, POSTEL In response to the message sent 18 Mar 1981 1920-PST from Geoff at SRI-CSL Geoff: Illegal. --jon. -------  Date: 18 Mar 1981 1951-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Re: Illegal header? To: Geoff at SRI-CSL, Header-People at MIT-MC cc: Wancho at DARCOM-KA In-Reply-To: Your message of 18-Mar-81 1920-PST MM will generate the "From: John Q. Luser " format headers if and only if it is explicitly delivering the message to a local user. Since MM also runs on non-network systems this must be legal for non-network mail; and it appears to be a convention among Tenex/TOPS-20 sites not to include the host name in local message delivery. Some mail reading programs, including MM, have a REMAIL feature that allows a message to be retransmitted to another user, preserving the original header of the message. Usually information about the origin of the message, such as a "Remailed-From" line, is appended to the end of the header. It is therefore possible that a message with a local From header may be sent out on the ARPANET by accident. It is difficult to detect this happening and even more difficult to correct it (I guess you have to edit the From line somehow), especially given that certain people cause their mail originating programs to generate From lines like From: the outhouse of Fred Foobar and rely upon the Reply-To line to return the necessary information. -- Mark -- -------  Date: 18 Mar 81 23:02:49-EST (Wed) From: Dave Crocker To: Geoff at sri-unix cc: Header-People at mc, Wancho at darcom-ka Subject: Re: Illegal header? To the extent that anybody considers RFC733 the standard, for such a question, the hostname is absolutely required. Dave.  Date: 19 March 1981 19:05-EST From: Earl A. Killian Subject: Illegal header? To: Admin.MRC at SU-SCORE cc: HEADER-PEOPLE at MIT-MC, Geoff at SRI-CSL, Wancho at DARCOM-KA The obvious thing to do to MM is to have it use host names if and only if it is running on a machine with a network. People that don't want to see local host names should fix their mail reader, not send illegal headers.  Date: 20 Mar 1981 0159-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Re: Illegal header? To: EAK at MIT-MC cc: Header-People at MIT-MC In-Reply-To: Your message of 19-Mar-81 1605-PST Date: 19 March 1981 19:05-EST From: Earl A. Killian The obvious thing to do to MM is to have it use host names if and only if it is running on a machine with a network. That does nothing whatsoever to solve the problem. The message which MM may be REMAILing may not have been generated by MM in the first place! As long as ANY mail sender can generate such a header, the problem will exist, irregardless of whether or not MM is changed so that it does not send out messages with such a header. I was not aware that RFC 733 presumed to dictate the format of a message sent from one local user to another without using a network. I think it is quite reasonable to assume that a header looking like: From: Fred Foobar or more commonly From: FOOBAR means local user FOOBAR; SNDMSG will generate the latter format header. As a side note, since Geoff uses Hermes I tested Hermes' REDISTRIBUTE command, and found that it behaves in the same manner as MM. I'd be interested if a REMAILing feature in any mailsystem knows enough to edit the From:/Reply-To:/whatever line when necessary (including handling the "From the outhouse" case). In any case, I think it is inappropriate to single out MM for criticism. -- Mark -- -------  Date: 20 Mar 1981 0841-EST From: POGRAN at BBND Subject: Re: Illegal header? To: Admin.MRC at SU-SCORE, EAK at MIT-MC cc: Header-People at MIT-MC, POGRAN I'd suggest that the best way out of this situation would be for a program about to REMAIL a message to parse the existing header according to 733 standards; if there's anything "illegal" about it, the remailer should fabricate a complete new header and treat the old header as part of the text field of the message. Clumsy and ugly, to be sure, but it's easier than trying to figure out how to patch up a header that doesn't QUITE meet 733 specs. Ken -------  Date: 20 March 1981 1431-EST (Friday) From: Richard H. Gumpertz To: Pogran at bbnd Subject: Bogus headers CC: Header-People at mit-mc Message-Id: <20Mar81 143110 RG02@CMU-10A> Gee, what is that "Pogran" in your CC field? It has no host! Rick - - - - Begin forwarded message - - - - Date: 20 Mar 1981 0841-EST From: POGRAN at BBND Subject: Re: Illegal header? To: Admin.MRC at SU-SCORE, EAK at MIT-MC cc: Header-People at MIT-MC, POGRAN Via: MIT-MC; 20 Mar 1981 0855-EST I'd suggest that the best way out of this situation would be for a program about to REMAIL a message to parse the existing header according to 733 standards; if there's anything "illegal" about it, the remailer should fabricate a complete new header and treat the old header as part of the text field of the message. Clumsy and ugly, to be sure, but it's easier than trying to figure out how to patch up a header that doesn't QUITE meet 733 specs. Ken ------- - - - - End forwarded message - - - -  Date: 20 Mar 1981 1559-EST From: POGRAN at BBND Subject: Ain't it awful! To: Rick.Gumpertz at CMU-10A cc: Header-People at MIT-MC Just goes to show you how much ANTIQUATED software is used regularly around the net by well-meaning people. And how much software ISN'T maintained and kept up-to-date. Now, back when I was at MIT-Multics . . . Ken -------  Date: 23 March 1981 03:41-EST From: Earl A. Killian Subject: Illegal header? To: Admin.MRC at SU-SCORE cc: HEADER-PEOPLE at MIT-MC I wasn't singly out MM for criticism; I was simply suggesting that by so modifying MM the number of illegal headers in the world would be reduced. It is an obvious fix, that is easy as well. I don't believe that MM should be held responsible if it remails an illegal header generated by Hermes; Hermes should be held responsible for sending the original header. In general I think this whole discussion proves that it is a loss to send hostless addreses even to local recipients.  Date: 23 March 1981 1459-EST (Monday) From: Richard H. Gumpertz To: Earl A. Killian Subject: Re: Illegal header? CC: HEADER-PEOPLE at MIT-MC In-Reply-To: Earl A. Killian's message of 23 Mar 81 03:41-EST Message-Id: <23Mar81 145900 RG02@CMU-10A> The solution at CMU is to ALWAYS include a host in the header. The mail reading program then suppresses display of the host if it is the same as the one you are then running on. This seems to work out quite nicely. Rick  RMS@MIT-AI 03/28/81 06:21:48 Re: remailing To: HEADER-PEOPLE at MIT-MC There's no need to worry about truly weird From fields which are accompanied by Reply-to fields, since they don't get used as addresses. With that out of the way, we can consider only From fields really intended to be used as the address to mail a reply to. About them, if people want to have no host name mentioned in mail which is completely local, then any mailer which has a "remail" feature ought to look through the existing From field (only if there is no reply-to) and add a host name to it if appropriate. Since this only needs to be done for local mail, the parser can be simplified by assuming that the mail was generated by one of the mail systems that runs on the local machine. It needs to test that assumption, of course, but if the assumption is seen to be false, it is safe to assume that the mail came from elsewhere, and already has the host name (or, if it doesn't, it's someone else's fault) so you can leave it alone. Perhaps this makes the task simpler.  Date: 7 Apr 81 17:7:13-PDT From: mclure at Sri-Unix To: header-people at mc Subject: odd header This is an extremely strange header I recently received. Comments anyone? DATED 7 Apr 1981 at 1552 Pacific Standard Time SENT BY jeff (Jeff Schriebman - Consultant/JSC) SUBJECT Re: Unix V7 on 11/44 SENT TO obrien@RAND-UNIX COPY TO unix-wizards@SRI-UNIX ORIG BY obrien at RAND-UNIX Date: 7 Apr 1981 at 1348-PST To: Spencer W Thomas Cc: unix-wizards at SRI-UNIX Subject: Re: Unix V7 on 11/44 In-reply-to: Your message of 6 Apr 1981 1746-MST. From: obrien at RAND-UNIX Via: 199.ArpaNet; 7 Apr 81 14:20-PDT I replied to the question of V7 on 11/44's. Jeff Schriebman at lll-comp  Date: 8 Apr 1981 at 1028-PST To: Lauren at UCLA-S (Lauren Weinstein) Cc: obrien at RAND-UNIX, mclure at SRI-UNIX, header-people at MC Subject: Re: Schriebman's message In-reply-to: Your message of 7 Apr 1981 1819-PST (Tuesday). From: obrien at RAND-UNIX That header is not only peculiar, it is misleading. Despite the tag "ORIG BY", whatever that means, it was a reply to me from Schriebman about something. I've never seen anything like it.  RMS@MIT-AI 06/04/81 22:59:55 Re: Depending on DEC is not an excuse. To: header-people at MIT-MC "I have a nice computer company which is going to make all my programs do just what they ought. I'm very loyal and I trust them. I'm going to do just what they say. I'm sure if the programs can't send mail to you, the computer company must have a good reason. It's your own fault. You should have been nice to the nice computer company. Then I'm sure you wouldn't have any trouble."  Date: 4 Jun 1981 2238-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: RMS' flame about "depending on DEC" To: Header-People at MIT-MC RMS' message referred to problems a user on one of Tymshare's Foonlys had in sending a message to an esoteric address (one of the MIT Chaosnet addresses). Evidently RMS has not realized that DEC has nothing whatsoever to do with software support for Foonly computers. In fact, DEC's TOPS-20 mail system, MS, does support MIT Chaosnet addresses of the form "Foo at MIT-EECS at MIT-AI". Perhaps RMS should do some research before he flames. -- Mark -- -------  Date: 6 June 1981 20:39-EDT From: Charles Frankston Subject: RMS' flame about "depending on DEC" To: Admin.MRC at SU-SCORE cc: HEADER-PEOPLE at MIT-MC I'm glad you know RMS' message referred to a problem a user on a Tymshare foonly had. Frankly, I had thought it referred to a message of Johnathan Solomon's (sent to MsgGroup) saying that Rutgers could not support foo@x@y because they had a policy of running only standard DEC software. Since I think RMS knows full well about the software support relative to Foonly's, I'll bet he was replying to Solomon's message, in which case I woul dhave to say I'm rather in agreement with the tone of his message. Perhaps MRC should do some research before he flames.  Date: 8 June 1981 15:57-EDT From: Mike McMahon To: Header-People at MIT-MC Could someone point me to the revised address BNF that allows To: Foo: (no ";")? This isn't legal in the version in the protocol handbook. I certainly hope that CRLF isn't significant, since the lexer treats that as whitespace.  Date: 8 Jun 81 16:09:15-EDT (Mon) From: Dave Crocker To: Mike McMahon cc: Header-People at Mit-Mc There is no specification, of the sort that you want. People usually say that the document in the protocol handbook (rfc733) is the standard. Occasionally, they qualify and say that a subset of it is the standard. No one has ever gone and specified exactly what the current REAL standard is. Dave  Date: 8 Jun 1981 1515-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: (Response to message) To: MMcM at MIT-AI, Header-People at MIT-MC cc: ZELLICH In response to the message sent 8 June 1981 15:57-EDT from MMcM@MIT-AI Not sure just what the legality of To: Foo: would be - it's NOT intended as an address, certainly. What it is is a mechanism for providing address lists and having the mailsystem use the addresses following the "Foo:" for actual mailing, but showing only the "Foo:" in the message header. Use of such a mechanism implies that you don't want automatic replies to the Foo list. Wish I had a copy of 733 here at home so I could recheck to see if that (Twenex only?) feature is mentioned therein for lists. -Rich -------  Date: 8 Jun 1981 1812-PDT (Monday) From: Lauren at UCLA-SECURITY (Lauren Weinstein) Subject: (Response to message) In-reply-to: Your message of 8 Jun 1981 1515-PDT To: Zellich at OFFICE-3 CC: MMcM at AI,Header-People at MC The UCLA Unix systems (ATS and SECURITY) have also used the FOO: convention for local mailing lists for years. --Lauren-- -------  Date: Wednesday, 10 June 1981, 23:43-EDT From: Robert W. Kerns Subject: Strange COMSYS headers To: BUG-ZMAIL at MIT-AI, PDL at MIT-MC, SWG at MIT-MC, HEADER-PEOPLE at MC Date: 6 Jun 1981 0927-EDT Forwarded-to: user-a at MIT-DMS by SWG at MIT-DMS on 8 Jun 81 at 1400 EDT From: SWG at MIT-DMS (S. W. Galley) To: DEVON at MIT-DMS In-reply-to: Message of 05 Jun 81 at 2145 EDT by DEVON@MIT-MC Subject: [Re: [RE^3: Dianne]] Message-id: <[MIT-DMS].200123> It would be nice if we could standardize on Forwarded-to:, Redistributed-To:, etc. fields. From a program's point of view, having three fields, Forwarded-to, Forwarded-by, and Forwarded-date is far simpler to parse, especially since some systems already use this convention. However, it certainly is a lot less clutter to put it all in one header line. But what does COMSYS do when there are more people forwarded to than will fit on one line? I would hope that it still only uses one header entry, with the usual convention for continued lines, leaving multiple Forwarded-to entries for multiple forwardings. I guess this is another advantage of the COMSYS-style format.  Date: 11 Jun 1981 1012-EDT From: PDL at MIT-DMS (P. David Lebling) To: RWK at MIT-MC Cc: BUG-ZMAIL at MIT-AI, SWG at MIT-MC, HEADER-PEOPLE at MIT-MC In-reply-to: Message of 10 Jun 81 at 2347 EDT by RWK@MIT-MC Subject: [Re: Strange COMSYS headers] Message-id: <[MIT-DMS].200674> But what does COMSYS do when there are more people forwarded to than will fit on one line? I would hope that it still only uses one header entry, with the usual convention for continued lines, leaving multiple Forwarded-to entries for multiple forwardings. In theory this is precisely what it does. Dave  Date: 30 June 1981 23:08 edt From: Frankston.SoftArts at MIT-Multics Subject: Change of name Sender: COMSAT.SoftArts at MIT-Multics Reply-To: Frankston at MIT-Multics (Bob Frankston) To: header-people at MIT-AI, msggroup at MIT-AI *from: BOB (Bob Frankston) Local: header-people at mit-ai,cc:msggroup at mit-ai I am sending this to the entire list instead of just the "-request" identity. I'd like to change the current entry for me on Multics from whatever it is (SALawrence.SoftArts or sal.sai or maybe Frankston or bob or rmf or ...) to header-list.SoftArts and msggroup-list.SoftArts as appropriate. Instead of being Frankston at misc.SoftArts at MIT-Multics I will get the mail via header-list.SoftArts at MIT-Multics which will be examined by a program that will do local redistribution. the reason is that the "at .. at" syntax is fine by itself, but since the information is not preserved in the letter itself, but only the FTP "envelope" the syntax is only usable by those who modify their operating systems. This is not fair and unnecessary. We need to add the "envelope-to" field that contains the same information as the address for FTP. That is the field that can be used by mail processing programs. The "to:" field and such are only used for mail preparation and presentation programs. I realize that "envelope-to" is ugly. Suggestions?  Date: 28 Aug 1981 1631-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: In-Reply-To field - use Message-Id only, in combination, or what? [collected MsgGroup correspondence] To: Header-People at MIT-MC 1 28 Aug Larry Campbell To: MsgGroup at MIT-ML Subject: Standards vs. practices Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11755753035.20.71.16863 at DEC-MARLBORO> I am in a quandary over what to do about "Message-ID" and "In-reply-to" fields. RFC733 seems to indicate that a mailsystem, when generating a reply, should copy the contents of the "Message-ID" field of the message being replied to into the "In-reply-to" field. This is presumably to make it easy for mailsystems to automatically locate the original to a reply you've received, or to collect related sequences of messages together. However, it appears that very few mailsystems on the ARPANET actually do this. Most of them generate "In-reply-to" fields like: In-reply-to: Message from Jobe Blow of 1-Apr-84 I recently added code to a mailsystem I'm hacking to automatically trace originals to replies. I needed to include the "Message-ID" of the original in replies, but didn't want to incompatibly change the behavior of "In-reply-to" (every time I incompatibly change the mailsystem, hordes of wildeyed people with weapons invade my office). So I invented a new field, "Reference", which behaves the way RFC733 says "In-reply-to" ought to. I don't like this solution. After much thought, I've decided that the "right" thing to do is to adhere to the standard, even if this means an incompatible change. However, the current de facto interpretation of "In-reply-to" is also useful; I really appreciate being told the name of the human who sent the original message whose reply I'm reading. It would appear that we need to invent a new header name for just this purpose. I thus have two questions: 1) What should the new header name be? "Re"? "In-regard-to"? etc. (Or do we need one at all? Is all this off the wall?) 2) Is it deemed desirable to change the mailsystems that violate the standard so that they generate "In-reply-to" fields which conform to the spirit of RFC733? -------- 2 -- ************************ Date: 28 Aug 1981 1034-PDT From: Zellich Subject: Re: Standards vs. practices To: LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML cc: ZELLICH In response to the message sent 28 Aug 1981 1120-EDT from LCAMPBELL@DEC-MARLBORO Or perhaps the In-Reply-To field could contain *both* entries; probably the usual "...message from etc..." first, then the originators Message-Id. In whichever order they appeared, they would be separated by a CRLF and LWSP to make them readable. EX: In-Reply-To: The message from Jobe Blow 1-Apr-81 <[ORIGHOST]1-Apr-1981 01:01:01 JBLOW> I don't have a copy of RFC733 here with me, so I don't remember how explicit it is about the content of the In-Reply-To field; it might need changing to allow the above. If we want to change RFC733 to allow this kind of formating, I think I would prefer the format as shown, with the copied Message-Id second, since some mailsystems don't necessarily generate an Id, but the sender and date/time sent should always be known. -Rich Z. ------- 3 -- ************************ Mail from MIT-ML rcvd at 28-Aug-81 1425-PDT Date: Friday, 28 Aug 1981 13:49-PDT To: Larry Campbell Cc: MsgGroup at MIT-ML Subject: Re: Standards vs. practices In-reply-to: Your message of 28 Aug 1981 1120-EDT. <"MS5(1734)+GLXLIB1(1033)" 11755753035.20.71.16863 at DEC-MARLBORO> From: greep at RAND-UNIX Since angle brackets are used to indicate text designed mainly for program (rather than human) use, I thought the idea was that you could put anything you wanted in the in-reply-to field, with the original message id inside angle brackets, e.g. In-reply-to: Message from foo at bar <314159 at BAR> RFC 733 says (section IV.B.2, page 22) about the in-reply-to field: "The contents of this field identify previous correspondence which this message answers. Note that if message identifiers are used in this field, they must use the mach-id specification format." (The latter is something of the form "string at host".) 4 -- ************************ Mail from MIT-ML rcvd at 28-Aug-81 1453-PDT Date: 28 Aug 1981 (Friday) 1734-EDT From: DREIFU at WHARTON-10 (Henry Dreifus) Subject: Suggestion(s) for RFC999, improvement to RFC733 To: MsgGroup at MIT-ML I would tend to think an invisible field [somewhat akin to the 0000000's in the header of the message] containing the unique identifier should be proposed. Instead of seeing that hacker-created-prime number, a 'user' oriented In Reply to |Message Header| of |Message Date| be printed. In fact, almost anything within cognitive reason should be there. The point of the message is, one should display only the information that is relevant to a given message. The sender, the reciever(s), the date and time, and some additional fields, where appropriate. I do not think the Message Id is appropriate. The less one has to dig through a message, the better. In fact, one must dig through the context of a message to gleen its meaning(s). Henry Dreifus 5 -- ************************ Mail from MIT-ML rcvd at 28-Aug-81 1526-PDT Date: Friday, 28 Aug 1981 14:55-PDT To: DREIFU at WHARTON-10 (Henry Dreifus) Cc: MsgGroup at MIT-ML Subject: Re: Suggestion(s) for RFC999, improvement to RFC733 In-reply-to: Your message of 28 Aug 1981 (Friday) 1734-EDT. From: greep at RAND-UNIX What do you mean by "invisible" field? Re "the 0000000's in the header", what are you talking about? In general, the mail reading program should filter out, at the user's discretion, whatever he doesn't want to see. There is no law saying that the program that displays mail has to show the whole message exactly as it was transmitted - it should be able to skip over fields the user isn't interested in, move them to the bottom, or whatever. 6 -- ************************ Mail from SRI-CSL rcvd at 28-Aug-81 1559-PDT Date: 28 Aug 1981 1550-PDT Sender: GEOFF at SRI-CSL Subject: Re: Standards vs. practices From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: Zellich at OFFICE-3 Cc: LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML Message-ID: <[SRI-CSL]28-Aug-81 15:50:26.GEOFF> In-Reply-To: Your message of 28 Aug 1981 1034-PDT I on the other hand I either like getting In-Reply-To: Your message of 28 Aug 1981 1034-PDT or In-Reply-To: The message from Zellich at Office-3 at 28 Aug 1981 1034-PDT or In-Reply-To: <[Office-3]28-Aug-81 10:34:00-PDT> but what I don't like getting is what the RAND-MH and PARC-Laurel message systems send out which, on the first line give you the "Your message of.." or "The message from..." AND then on the second line put the "machine type" Message-Id or even worse, split the "Machine Type" message id in the middle of the first line onto the second. In essence: One or the other, but please NOT both! I also think this topic would be more appropriate for HEADER-PEOPLE, the list where RFC733 was reviewed. 7 -- ************************ Date: 28 Aug 1981 1628-PDT From: Zellich Subject: Re: Standards vs. practices To: Geoff at SRI-CSL, Zellich at OFFICE-3 cc: LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML, ZELLICH In response to the message sent 28 Aug 1981 1550-PDT from Geoff at SRI-CSL I agree with Geoff about the subject being [more] appropriate for Header-People and have taken the liberty of forwarding the collected correspondence to date to that list. It might be a good idea for anyone concerned with this subject to start sending to Header-People instead of MsgGroup or at least CCing Header-People (but an awful lot of us will get two copies of everything, then). Cheers, Rich ------- -------  Date: 29 August 1981 00:16-EDT From: Mike McMahon Subject: In-reply-to fields To: LCampbell at DEC-MARLBORO cc: header-people at MIT-MC The lisp machine mail reader also has some commands for finding originals from replies. It understands about 10 different formats of in-reply-to. Problems like this really won't be satisfactorily solved so long as mail is transmitted as unstructured text.  Date: 29 Aug 81 15:39:22-EDT (Sat) From: Dave Crocker To: Header-People at Mit-Mc Subject: In-reply-to contents [[ would someone with mit-mc write-access change my header-people address to be dcrocker@udel, rather than dcrocker@rand-unix? thanks.]] To summarize what a couple of you noted, In-reply-to contents may be: random text or or random text where the last form has both kinds of information and is what Geoff does not like. (sorry.) It should also be noted that it is legal (albeit not entirely well defined) to have the following: In-reply-to: random text In-reply-to: Personally, I do not see the need for this, since any program that is going to selectively print In-reply-to contents probably can just strip the angle-bracketed stuff from the more compact form. Dave  Date: 29 August 1981 1555-EDT (Saturday) From: Richard H. Gumpertz To: Dave Crocker Subject: Re: In-reply-to contents CC: Header-People at MIT-MC Sender: Rick.Gumpertz at CMU-10A In-Reply-To: Dave Crocker's message of 29 Aug 81 14:39-EST Message-Id: <29Aug81 155521 RG02@CMU-10A> Should there be some restriction on the random text, such as prohibiting angle-brackets except for a real message ID?? Rick  Date: 29 Aug 1981 (Saturday) 1611-EDT From: DREIFU at WHARTON-10 (Henry Dreifus) Subject: Actually I prefere to see NONE of that at all. To: header-people at MIT-MC Message ID's are not for people, but for compu-tons. When the message is shorter than the 'header information' I get very turned off. While you are at it, make Message-Id's uniform (:=standardized). Hank  Date: 29 Aug 81 17:11:20-EDT (Sat) From: Dave Crocker To: Richard H Gumpertz To: Henry Dreifus cc: Header-People at Mit-Mc Subject: Re: In-reply-to contents Subject: Actually I prefere to see NONE of that at all. 1. RFC 733 specifies what characters are legal and in what ways; e.g., angle-brackets are and may only occur in text strings which are quoted. 2. The form of message id's IS standardized, but only to the extent that is reasonable for global action. A message id is generated by individual hosts, so that it is up to each host to be able to use the string it generates. Hence, Network message-id's have a part which indicates source host and a part which is the unique string generated by that host. What each host considers appropriate is none of the business of the rest of us. D/  Date: 29 Aug 1981 1528-PDT Sender: GEOFF at SRI-CSL Subject: Re: In-reply-to contents From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: dcrocker at UDEL Cc: Header-People at MIT-MC Message-ID: <[SRI-CSL]29-Aug-81 15:28:53.GEOFF> In-Reply-To: Your message of 29 Aug 81 15:39:22-EDT (Sat) The reason why I don't like random text is that "random text" and more or less contain the same information (usually being that "random text" is a subset of what's in ). I know that Message-Id's and the Date field contain redundant information, but the message system I use (HERMES) allows me to suppress the printing of the Message-Id field whenever I look at messages, so i never see them, and hence only see the information once. However, with Rand-MH and PARC-Laurel that put both "random text" and in the In-Reply-To field, there is (unnecessary) duplication of information (in my humble opinion), and I don't see any purpose or reason for this duplication. Hence, my request for either "random text" or , but not both.  Date: 30 August 1981 1145-EDT (Sunday) From: David Lamb To: Dave Crocker Subject: Standardising Message-ID contents CC: Header-People at Mit-Mc Reply-To: Rdmail In-Reply-To: Dave Crocker's message of 29 Aug 81 16:11-EST Message-Id: <30Aug81 114503 RD00@CMU-10A> Like Henry Dreifus, I'd prefer to see the form of 's standardised to some extent. The CMU RdMail program has facilities for searching for messages that answer a particular message, and to which a particular message is the answer. At the moment this involves a linear search for messages with matching In-Reply-To or Message-Id fields. Anyone who has any need for these cross-reference searches typically has hundreds of messages in their message file, so the searches are too slow to be useful. If message-id's always included the date of origin in some form, RdMail could do a fast search since it has a date-of-origin index into the message file. Even standardising on "so-and-so's message of date-and-time" would be sufficient here.  Date: 1 Sep 1981 1519-EDT From: Larry Campbell To: Header-people at MIT-MC Subject: Address change Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11756845178.19.71.15782 at DEC-MARLBORO> (Sorry about sending this message to the whole list, but I've tried everything similar to Header-people-request@MIT-MC without hitting a valid mailbox name...) Please change my address, which is currently either LCampbell@SRI-KL or G.LCampbell@SU-SCORE, to LCampbell@DEC-MARLBORO. --------  Date: 1 Sep 1981 1324-PDT From: Daul at OFFICE Subject: Please add my name to this... To: header-people at MIT-AI list. Thanks, --Bill -------  Date: 1 Sep 1981 1349-PDT From: Feinler at SRI-NIC Subject: Address changes, etc. To: lcampbell at DEC-MARLBORO cc: header-people at MIT-MC, nic These come to the NIC. NIC@NIC or NIC@SRI-NIC. Larry, (and others) do you have a copy of the NIC WHOIS user program which lets you do 'Whois LASTNAME' and get a return of name, address, phone and network mailbox? If you want a copy let me know. It can run at the system level or in your own directory if the system doesn't want to run it. Anyway, nice to hear from you. Jake -------  Date: 08 Sep 1981 0940-PDT From: Hon Wah Chin To: header-people at MIT-AI Anyone out there know how to strap a Bell 303 from option Z to option E, so that it would accept external sync from the DTE for transmission? It seems TPC might take forever to get this done for us.  Date: 9 Sep 1981 1350-PDT From: Daul at OFFICE Subject: RFC 733 To: header-people at MIT-AI Have there been supplements to this RFC? How can I get copies? Thanks, --Bill (DAUL@OFFICE) -------  Date: 9 Sep 1981 1618-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: RFC 733 To: Daul at OFFICE, header-people at MIT-AI cc: ZELLICH In response to the message sent 9 Sep 1981 1350-PDT from Daul@OFFICE As far as I know, RFC 733 is *it*. There are later RFC's (?) and IEN's (Internet Experiment Notes) dealing with proposed new [inter-] network mail standards, but nothing updating or amending RFC 733. You can FTP a formatted copy from [SRI-NIC]RFC733.TXT - this file is 38 print pages. For other related RFC's and IEN's, I recommend you also FTP RFC-INDEX.TXT (about 2000+ lines, unformatted) and IEN-INDEX.TXT (didn't check the size, but it's a lot smaller). SRI-NIC supports the ANONYMOUS FTP convention (password ARPA or GUEST). -Rich Zellich -------  Date: 9 Sep 81 22:37:42-EDT (Wed) From: Dave Crocker To: Daul at Office-2 cc: header-people at Mit-Ai Subject: Re: RFC 733 rfc733 is part of the arpanet protocol handbook, which has an NTIS number and may also be aquirable from the Network Information Center, Jake Feinler (Feinler@sri-nic). I also have an online copy I can netmail you, if you wish. Dave  Date: 10 September 1981 2219-PDT (Thursday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: changing headers To: MSGGROUP at MC, HEADER-PEOPLE at MC Hi. What is the current feeling regarding the local reformatting of message headers by delivery software BEFORE delivery to destinations? Example: Presume there is a "smart" FTP server which, before delivering any incoming network mail, reformats the FROM, CC, and DATE lines to a local standard to simplify later mail handling. Considering the current state of the various mail handling systems around the net, are there currently any problems that could be caused or increased in severity through this sort of manipulation? Is there still any strong reason to maintain the philosophy that received message headers "should" look the same when received as they did when sent? Thanks much. --Lauren--  Date: 11-Sep-81 8:18:33 PDT (Friday) From: Karlton at PARC-MAXC Subject: Re: changing headers In-reply-to: Lauren's message of 10 September 1981 2219-PDT (Thursday) To: lauren at UCLA-Security (Lauren Weinstein) cc: MSGGROUP at MC, HEADER-PEOPLE at MC There is no "philosophy that received messageheaders 'should' look the same when received as they did when sent." Some mail handling systems tailor the display of the headers (usually by some sort of user settable profile). I think that it would be a mistake for any FTP server to throw away some of the information in a header. There might be something in there that the user really wants one time in a thousand. PK  Date: 12 Sep 81 0:29-PDT From: mclure at SRI-UNIX To: header-people at mit-mc Subject: headers without to's I've noticed a lot of messages coming out of Berkeley's VAX system which have no "to" address in their header. Is this legal? It's hard to know whether the message was sent to a distribution list or me in particular.  RMS@MIT-AI (Sent by RMS0@MIT-AI) 09/12/81 04:46:04 To: HEADER-PEOPLE at MIT-MC Reformatting messages is a reasonable idea, but isn't it always better to do it in the user's mail reader program than in the FTP server? This way 1) it is easy to let different users do it differently, 2) it doesn't have to be irreversible.  Date: 12 Sep 81 9:03:33-EDT (Sat) From: Dave Crocker To: mclure at Sri-Unix cc: header-people at Mit-Mc Subject: Re: headers without to's Only From and Date are officially required, on the arpanet. dave  Date: 15 Sep 1981 1026-PDT From: Daul at OFFICE Subject: ADD THESE NAMES (there is no header-people-request) To: header-people at MIT-MC cc: daul Date: 15 Sep 1981 1002-PDT From: Daul Subject: Please add two people... To: header-people-request at MIT-MC cc: daul Please add: Andrews@OFFICE and clen@OFFICE Thanks, Bill ------- -------  Date: 29 Sep 1981 1726-PDT From: Daul at OFFICE Subject: List Of Currently Used Header Fields For ARPAnet Mail Traffic To: header-people at MIT-MC cc: daul Does anyone have a lst (complete or otherwise) of all the header fields used on/in Arpanet mail? I have read RFC733, but there are many more types of fields being used here (Arpaland). Thanks, --lliB -------  Date: Tuesday, 29 Sep 1981 23:39-PDT To: Daul at OFFICE-2 Cc: header-people at MIT-MC Subject: Re: List Of Currently Used Header Fields For ARPAnet Mail Traffic Pizza-type: Nobones In-reply-to: Your message of 29 Sep 1981 1726-PDT. From: greep at RAND-UNIX There is no such thing as a complete list of header fields, since any arbitrary field may be added as long as it conforms to the syntax rules. The best you can do is collect a sample of messages and assume they represent the most common fields.  Date: 2 Oct 81 17:50:57-EDT (Fri) From: Dave Crocker To: header-people at Mit-Mc Subject: multiple at-signs I am curious how many mail systems actually can handle the multiple at-signes (e.g., "foo at bar at blat") that is legal in RFC733. I would appreciate reports from people who know of systems that can and systems that cannot properly cope. Dave  Date: 2 Oct 1981 1536-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: multiple at's and at-signs To: DCrocker at UDEL cc: Header-People at MIT-MC The TOPS-20 MM mailsystem handles such addresses, both in parsing and generating them. It is especially sophisticated with such addresses when the system uses its friend XMAILR as the mail delivery process. -------  Date: 2 October 1981 19:59-EDT From: Earl A. Killian Subject: multiple at-signs To: dcrocker at UDEL cc: HEADER-PEOPLE at MIT-MC Babyl's mail reading side can parse and hand FOO@BAH@HUMBUG to the mail composition side for replying. On 20X Babyl's mail composer does the right thing; at last it writes the correct MAILER or XMAILR file. MAILER on most 20x sites does the wrong thing the last time I looked, though at BBN it was fixed to find the host name by scanning backward from the end for "@" rather than scanning forward from the beginning. And XMAILR wins, of course. The ITS mailer daemon can mail to such addreses if you ask it nicely enough, though I don't think it gets the header right (I may be wrong on this). Unfortunately none of the three mail composition programs on ITS (MAIL, RMAIL, Babyl) ask the ITS mailer nicely enough when you give them simply the string FOO@BAH@HUMBUG. If you were to type "FOO@BAH"@HUMBUG, they'd all send the right thing to COMSAT, and you'd at least get the mail sent. Anyway, since it's probably not too hard, I may fix Babyl's ITS mail sending code. I can't say what will happen with MAIL and RMAIL.  Date: 2 October 1981 20:00-EDT From: Earl A. Killian Subject: multiple at-signs To: dcrocker at UDEL cc: HEADER-PEOPLE at MIT-MC Also, Multics EMACS can handle multiple atsigns properly.  Date: 2 Oct 1981 2240-EDT From: PDL at MIT-DMS (P. David Lebling) To: DCrocker at UDEL, HEADER-PEOPLE at MIT-MC In-reply-to: Message of 02 Oct 81 at 1959 EDT by EAK@MIT-MC Subject: Multiple Atsigns Message-id: <[MIT-DMS].211795> The MIT-DM and -XX READER program and mailer demon COMSYS handle multiple atsigns correctly. They just look for the last atsign in the address. I think the headers come out right too. Dave  Date: 3 October 1981 03:47-EDT From: David A. Moon Subject: multiple at-signs To: EAK at MIT-MC cc: HEADER-PEOPLE at MIT-MC, dcrocker at UDEL These work completely in Comsat and Rmail. The only place in ITS where they don't work is in the :MAIL command, which is because it has its own address parser which is left over from the days before the present mail system (Comsat). Some day that address parser will be ripped out and it will simply supply the string the user typed to the mail system, at which point multiple @'s will work in the :MAIL command, too. Multiple @'s are actually used around MIT, for sending mail between Chaosnet hosts that aren't on the Arpanet and outside-world Arpanet hosts that don't know there is a Chaosnet.  Date: 3 October 1981 03:55-EDT From: David A. Moon Subject: multiple at-signs To: EAK at MIT-MC cc: DCROCKER at MIT-MC, HEADER-PEOPLE at MIT-MC Here's a follow-up to my previous message, just for laughs. Also making sure that multiple @'s really work in ZMail.  Mail-from: ARPANET site MIT-ML rcvd at 3-Oct-81 0421-EDT From: MOON@MIT-MC Date: 10/03/81 04:17:19 Subject: multiple at-signs MOON@MIT-MC 10/03/81 04:17:19 Re: multiple at-signs To: EAK at MIT-MC CC: HEADER-PEOPLE@MIT-MC@EE@XX@ML@MC at MIT-DMS CC: dcrocker@UDEL@AI@MC at MIT-ML Here's another obnoxious message from me about multiple @'s. The last one probably looked pretty stupid; it turns out multiple @'s don't work in ZMail although no doubt they will soon.  Date: 5 Oct 1981 1126-EDT From: Larry Campbell To: dcrocker at UDEL, header-people at MIT-MC Subject: Re: multiple at-signs Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11765715618.28.71.24348 at DEC-MARLBORO> In-reply-to: Message from Dave Crocker of 2-Oct-81 1750-EDT Version 5 of MS (DEC's rather MM-like mailsystem) does handle multiple atsigns properly. Unfortunately I've not yet been able to get a copy of this out to the ARPANET because my DECNET link to our ARPANET machine has been mostly unusable lately. As soon as I can I will get a copy of it to DEC-MARLBORO (via magtape (ugh) if necessary) and anyone interested in getting a copy should drop me a line... --------  Date: 21 October 1981 2135-EDT From: Craig Everhart at CMU-10A To: Dave Crocker Subject: Re: multiple at-signs CC: header-people at Mit-Mc In-Reply-To: Dave Crocker's message of 2 Oct 81 16:50-EST Message-Id: <21Oct81 213514 CE10@CMU-10A> On the CMU PDP10s, RdMail can handle any number of "@"s or " at "s. Unfortunately, the current mail deliverer can't handle more than one "@" in an address, so the practical limit for local delivery is two "@"s--one gets stripped off in the queueing process. This limitation should be going away soon, I like to think.  Date: 21 Oct 1981 2202-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: New NBS proposed draft standard for Message Formats available To: Header-People at MIT-MC cc: Feinler at SRI-NIC Proposed Federal Information Processing Standard "Specification for Message Format for Computer Based Message Systems", dtd Sep 81 is now out. It is also highlighted in the 6 Oct 81 issue of the Federal Register (Book 1 of 2, pages 49168 & 49169). The address for obtaining a copy is given in the F/R as Director, Institute for Computer Sciences and Technology National Bureau of Standards Attn: MFCBMS Washington, D.C. 20234 This is the result of the comments received on the "preliminary draft" earlier in the year. Enjoy, Rich -------  Date: Thursday, 29 October 1981 12:43-EST From: Jan Walker To: Editor-People at Score CC: Header-people at MC Subject: mail systems standards The following message is typical of many that have been arriving lately via the Editor-People mailing list. At least, I can only guess from the contents that they are arriving via editor-people. They lack any To field, indicating that they have been composed either in an editor by someone who does not know about message format standards or by a quite ersatz message system. In addition to lacking a To field, they lack the "header" for the Text field (which is a blank line). 29-Oct-81 12:09:11-EST,411;000000000001 Mail-from: SU-SCORE Received-Date: 29-Oct-81 1209-EST Mail-from: ARPANET site UCB-C70 rcvd at 29-Oct-81 0853-PST Date: 28 Oct 1981 21:30:36-PST From: decvax!utzoo!xxxxx at Berkeley Re: Alto User's Handbook Some of us who ARE interested to know that this document is now cleared for release would ALSO be interested in having a slightly more detailed mailing address than "Sara Dake at Xerox-PARC". I protest this form of message being sent to a mailing list on the ARPAnet. At least some message systems that parse messages according to the usual standards can't present this message in a reasonable fashion. The "text" field gets displayed in the middle of the headers (because it is parsed as "unrecognized other field", whose print position happens to be in the middle). I can't use my mail reader to search for messages of this kind -- with no To: field and no Subj: field, there isn't a whole lot available to search for. The only real tip-off is the presence of ! in the From: field. I hope that whoever is responsible for the software (if it is a message system that creates these messages) will find time to make the messages sent conform to the standards. (If people are just creating the messages and "posting" them via an editor, then they should take a little time out to study the usual conventions involved in a draft message.) It would make things more pleasant for all of us readers. Thanks. Jan  Date: 29 Oct 1981 1143-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: Re: mail systems standards To: JWALKER at BBNA, Editor-People at SU-SCORE cc: Header-people at MIT-MC In-Reply-To: Your message of 29-Oct-81 0944-PST Jan - I agree with you completely. The problem isn't the SCORE software, since SCORE is just redistributing mail as it is being read. The problem is in the UNIX software (you'll notice this all comes from Berkeley). I have just as much trouble reading those messages with MM (my mailsystem) as you do with yours (Hoimes?). By the way, do you think you can get your mailsystem fixed to change nicknames into official names? This is another of my pet peeves. -- Mark -- -------  Date: Thursday, 29 October 1981 15:06-EST From: Jonathan Alan Solomon To: Mark Crispin Cc: Editor-People at SU-SCORE, Header-people at MIT-MC, JSol at RUTGERS, JWALKER at BBNA Subject: mail systems standards I have a general complaint about the Beserkeley addresses all by themselves. Not only do you have those cryptic addresses (which our mailer insists on putting ^Vs before the !'s in - but that's another problem with another solution), but you have no guarantee that the address path the recipient used to send mail to you can be used to send the reply. I have yet to successfully REPLY to any of the messages I got from the "uucp" network. Cheers, Jsol  Date: 29 Oct 81 14:05:37-EST (Thu) From: Dave Crocker To: Jan Walker cc: Editor-People at Su-Score, Header-people at Mit-Mc Subject: Re: mail systems standards The "To:" field is not officially required by the Arpanet standard. The blank line most certainly IS required. It would appear that the Berkeley relay mechanism is failing to massage Unix mail into the required Arpanet format. Dave  Date: 29 Oct 1981 1418-PST From: J. Q. Johnson Subject: Re: Re: mail systems standards To: editor-people at SU-SCORE cc: header-people at MIT-MC In-Reply-To: Your message of 29-Oct-81 1105-PST It seems to me that the discussion of mail system standards is not directly relevant to the EDITOR-PEOPLE discussion of text editors. Jan's initial message was, since it related directly to problems with receipt of messages on the mailing list. But let's move further discussion of mail headers off EDITOR-PEOPLE, and confine it to the HEADER-PEOPLE discussion group. OK, everybody? Let's get back to technical discussion of editor technology. -------  Date: 29 Oct 1981 1725-EST From: J. Noel Chiappa Subject: Re: mail systems standards To: JSOL at RUTGERS, Admin.MRC at SU-SCORE cc: Editor-People at SU-SCORE, Header-people at MIT-MC, JWALKER at BBNA, JNC at MIT-XX In-Reply-To: Your message of 29-Oct-81 1600-EST I've got a better one than that. I got some mail from a uucp site (via Berkeley) with a 'Reply-to:' line. Needless to say, after I replied to the message, I got back a message 'User or mailbox not known at this site'. -------  Date: 29 October 1981 1546-PDT (Thursday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: uucp addresses To: HEADER-PEOPLE at MC This is not really Berkeley's fault. The UUCP network is a bizarre sort of animal. There are several hundred computers on it currently (I *think* -- I'm not even sure, and I'm supposed to be in charge of the World UUCP Map). Many of these systems are at various Bell Labs facilities. There are two problems: 1) UUCP is a store and forward system of the lowest order -- most connections are made at intervals on dialup lines (via autodialers). Many sites are "slaves" only -- they never make calls, but are polled for traffic by other systems. Some sites only poll other sites when the originating system has traffic, not on a regular basis. New sites can (and do) join the network without any formal announcement (in many cases) so that every day it seems someone new has popped up. All of this makes it very difficult to backtrack paths to other than well-known sites. I can usually do it, but only because I deal with this stuff all the time and have all the info. 2) There have been considerable "gateway" problems between the ARPANET and the UUCP net. For quite a while, Berkeley was providing the only such service, and that was dicontinued for quite some time for technical reasons. Now I believe the gateway is back, so replies to individuals should again be possible. It is important to remember that each field in a UUCP address is a separate computer: ucla-s!lauren@Berkeley if used as an address on the Arpanet, would send the message to Berkeley via the ARPANET. Berkeley would then forward the message to: ucla-s!lauren via the UUCP net. The current convention is that addresses which combine UUCP and ARPA address in this way take the ARPA hop first. Normally, the ARPA address would be the gateway (in this case Berkeley), and the UUCP address would be RELATIVE to Berkeley. By the way, the UUCP name for Berkeley is ucbvax. So if you saw a message from: ucbvax!ihnss!research!bart (with no ARPA field for some reason), you could reply to: ihnss!research!bart@Berkeley Does any of this make sense? I freely admit that this is a confused situation, but there are alot of people out there in UUCP-land, and overall, the network works pretty well in practice. --Lauren--  Date: 29 Oct 1981 1541-PST From: Bill Nowicki Subject: Re: mail systems standards To: Admin.MRC at SU-SCORE, JWALKER at BBNA, Editor-People at SU-SCORE cc: Header-people at MIT-MC In-Reply-To: Your message of 29-Oct-81 1145-PST These tell-tale exclamation points indicate that "UUCP" is the culprit. The problem is that there are numerous versions of Unix, each with many different mail programs. Actually, the forwarding of this mail by Berkeley is quite suspect, since most of those "UseNet" users are not Arpa contractors. I am not arguing for stopping information flow, but the problem is that these people communicate with autodialers that call each other up at 2am every morning. Thus by the time the message gets to them, and they give their response, it has often gone through a half dozen phone hops and taken a week. In the meantime we get another dozen responses from other scattered about the country because of the phase problem. If you think this is bad on editor-people, you should see unix-wizards! I think pressure should be brought against Bezerkeley to stop polluting the mail systems with stuff that does not conform to RFC 733. -- Bill -------  Date: 29 Oct 1981 16:39:12-PST From: mo at LBL-UNIX (Mike O'Dell [wizard]) To: header-people at mit-mc Subject: busted headers At the risk of inviting flames, I suggest mail readers should be more robust. Definition of robust: be conservative in what you do, but be liberal in what you let others get away with. In the case of a mail reader, it should get suspicious when it stops finding things that look like headers and starts finding things that look like text, in spite of a possibly missing blank line. I realize the importance of adherence to standards, but you can't trust anyone's code but your own, and then only if you are truly brave. -Mike  Date: 29 Oct 1981 2036-PST From: Brian K. Reid Subject: Re: busted headers To: mo at LBL-UNIX, header-people at MIT-MC In-Reply-To: Your message of 29-Oct-81 1639-PST Don't be ridiculous. Mail reading programs are a stupid place to do AI. Mail interchange has to be simple and reliable, and there is an existing interchange format for it, however flawed. To ignore the standard and generate crap is both ignorant and vain. -------  Date: 30 Oct 1981 0118-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: busted headers To: Header-People at MIT-MC I agree with both Mike and Brian on this. A mail reading program should be robust enough to not die totally if the standard is violated. The program shouldn't execute an illegal instruction or otherwise crash, nor should it destroy the mail file, etc. But Brian is also right in that a mail sending program should not send crap. Beserkley's badly formatted UUCP mail has been annoying me too. I can easily come up with an example where an improperly formatted message will appear to obey the standard to a moderately sophisticated program (such as MM; other programs will behave similarly). Such a program, attempting to parse the message according to the standard, may find itself doing something -- to its human user -- totally random in processing the message, yet perfectly reasonable given the badly formatted message. Garbage In, Garbage Out. -- Mark -- -------  Date: 30 Oct 1981 1042-EST From: Larry Campbell To: mo at LBL-UNIX, header-people at MIT-MC Postal-address: "73 Concord St., Maynard, Mass. 01754" Subject: Re: busted headers Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11772272127.29.71.10909 at DEC-MARLBORO> Regarding: Message from mo at LBL-UNIX (Mike O'Dell [wizard]) of 29-Oct-81 1939-EST I'm reasonably certain that there aren't any mailsystems that crash or anything when they try to display Beserkeley's mixed-up messages. However, my mailsystem (which is probably typical) attempts to display headers "intelligently". This may involve a combination of displaying them in a certain order, omitting certain headers, compressing long address lists, and so forth. If an unparsable message arrives, my mailsystem must instead now display it literally in its entirety. Just to let me know that it isn't a bug, it also warns me: %Incorrectly formatted header for this message, displaying literally or something like that. I don't think this means it isn't robust; but it is still an annoyance, with or without the warning line. --------  Date: 30 Oct 1981 1859-EST From: Larry Campbell To: MsgGroup at MIT-MC, Header-people at MIT-MC Postal-address: "73 Concord St., Maynard, Mass. 01754" Subject: DECmail Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11772362638.19.71.8834 at DEC-MARLBORO> DEC announced yesterday a product called DECmail, which is DEC's "long-awaited" (?) entry into the world of commercial electronic mail. I would be very interested in hearing what anyone out in the real world of electronic mail thinks about it (I have my own opinions, but for the moment I'm witholding them). I'm especially interested in hearing of the experiences of anyone who has actually tried to use it. --------  Date: 31 Oct 1981 0406-EST From: Jonathan Alan Solomon Subject: [Communications Satellite : Msg of Saturday, 31 October 1981 03:46-EST] To: HEADER-PEOPLE at MIT-AI Mail-from: MIT-AI rcvd at 31-Oct-81 0347-EST Date: 31 October 1981 03:46-EST From: Communications Satellite Subject: Msg of Saturday, 31 October 1981 03:46-EST To: JSol at RUTGERS A copy of your message is being returned, because: "HEADER-PEOPLE-REQUEST" at MIT-AI is an unknown recipient. Message not sent. Failed message follows: ------- Date: 31 Oct 1981 0347-EST From: Jonathan Alan Solomon Subject: add me to the list To: header-people-request at MIT-AI if I am not already on the list ------- --------------- -------  Date: 31 Oct 1981 07:48:13-PST From: cbosgd!mark at Berkeley To: header-people@mc Subject: please add me to the list Please add csvax.mark@berkeley and ingvax.eric@berkeley to the list. Sorry to send to the whole list, but header-people-request came back with no such addressee. Mark Horton  Mail-from: ARPANET site UCB-C70 rcvd at 2-Nov-81 1457-PST Date: 2 Nov 1981 14:44:52-PST From: vax135!hocsg!brs at Berkeley FROM: b.r.schatz TO: vax135!ucbvax!editor-people@Berkeley DATE: 11/2/81, 12:00 PM SUBJECT: mail header standards being the propagator of a UNIX mail program as well as being linked into Bell product developments, I would be very interested in a summary of the ARPA standard and comparison to the UNIX one. Remailed-date: 2 Nov 1981 1558-PST Remailed-from: J. Q. Johnson To: header-people at MIT-MC The EDITOR-PEOPLE mailing list received this message in the mail today, though I decided that HEADER-PEOPLE was a more appropriate destination. Note that the header has bad format (no From: field). --------------- Mail-from: ARPANET site UCB-C70 rcvd at 2-Nov-81 1722-PST Date: Sun Nov 1 15:54:36 1981 Subject: Problems with Mail Addresses This is a quick flame to the ARPA people who have had problems replying to UUCP addresses . . . its no picnic from this end either. I have to deal with submitting to a "ucbvax" address set up just for the purpose of porting through to ARPA when I want to send mail to a digest. Those of you (ARPA folk) who wish to reply to news/mail from UUCP sites can undoubtedly learn to apply the reverse procedure (having said that, I hope such a procedure exists). Don't assume your mail system has no problems talking with the outside world!!!! Alan Roberts (ucbvax!decvax!duke!unc!wolfvax) -------  Date: Friday, 6 November 1981 00:47-EST From: SWERNOFSKY at BBND To: Larry Campbell Cc: Swernofsky at BBND, Header-people at MIT-MC, MsgGroup at MIT-MC, HUMAN-NETS at MIT-MC Subject: evaluation of DECmail (long message) From: Larry Campbell Postal-address: "73 Concord St., Maynard, Mass. 01754" DEC announced yesterday a product called DECmail, which is DEC's "long-awaited" (?) entry into the world of commercial electronic mail. I would be very interested in hearing what anyone out in the real world of electronic mail thinks about it (I have my own opinions, but for the moment I'm witholding them). I'm especially interested in hearing of the experiences of anyone who has actually tried to use it. Richard Moore is a good friend of mine and the manager of certain system operations at Commercial Union, an insurance company with 13 DEC machines of various flavors. DECmail is being field-tested at their facility; they have generated about 50 QARs ("and a lot of sore fingers") on the subject. Herewith his opinions on this dinosaur: ---------------- I would not have used the word dinosaur. In fact, I wasn't intending to give sweeping condemnations of the product. Just the facts, that's bad enough. Decmail is an incomplete product at this time. The DEC people we deal with claim that this is only what is to be expected from a product in early field test. However, I think that DECMAIL's problems go deeper than that. DECMAIL is designed to be a part of an office automation package that DEC is going to released in parts over the next few years. Its basic release is going to be frozen after awhile unless you want to buy the full package, and then it will be updated as the package is updated. So if DECMAIL isn't what you want as a generally applicable EMS by the freeze date, forget it. If you don't wish to try your luck with a part of DEC (the office automation group) that may be ambivalent to your general system needs, be it known that DECMAIL doesn't seem to pay as much attention to VMS as to be called ambivalent. It does not use RMS-11 for the storing of memos (Gee look MA, BACKUP don't work). It does not use the VMS conventions for the meaning of such special control characters as ^O and ^C. It has a special lock-in editor which "looks like" EDT, but it isn't. Instead, the editor that comes as part of DECMAIL is based on the word-processor that will be put on the VAX and DECMAIL doesn't allow you to bypass it, either by asking for the Editor of your choice, OR defining keys. (the subset of EDT doesn't allow for the defining of keys since "Sally Secretary might break something" -[that was a DEC spokesman]). DEC has promised that someday real soon DECMAIL will allow for the inputing of a non-DECMAIL generated file to be entered into the "system". Right now you can do it by a kluge, but DEC won't admit it since you will have SYSPRV while you read in the file of your choice. (someday DEC will learn about turning off Priv.s, when we told them about the kluge, they promised to remove it for the next release). The list goes on and on and on.. I am running late. The fifty QAR's are real QAR's. As far as I can tell DECMAIL was not designed top-down. (that is a guess) Instead it was designed, bottom up. The menus are not consistent in the method that you use to exit them. The Marketing people quickly learned that the most obvious way to exit the ditty was to turn off their terminals. If you want a piece of EMS that will be usable only by a small subset of the system users with any ease at all, then DECMAIL is for you. If not, be comforted by the fact that the internal developers for DEC won't touch it with a ten-foot pole. They use the freebee MAIL instead. ----------------  Date: 18 Nov 1981 19:15:26-PST From: chico!duke!unc!smb at Berkeley In-real-life: Steven M. Bellovin Location: University of North Carolina at Chapel Hill To: HEADER-PEOPLE@MIT-AI Subject: mailing list Please add my name to your mailing list. Thanx, Steve Bellovin  Date: 25 Nov 1981 0957-PST From: Daul at OFFICE Subject: Header Field Order To: header-people at MIT-MC Are the fields required to be in any particular order? What do the standards say (ARPA/NBS)? -------  Date: 25 Nov 1981 1122-PST From: Feinler at SRI-NIC Subject: Re: Header Field Order To: Daul at OFFICE, header-people at MIT-MC cc: FEINLER In response to the message sent 25 Nov 1981 0957-PST from Daul@OFFICE Bill, Do you have a copy of RFC-733? This sets the standards for mail headers. Also, there will be a new mail protocol which runs under TCP/IP (which every host on the network must have in place by Jan. 83) called SMTP. I only have a draft of it so far... will get the final soon. You are welcome to a copy of the draft which is in smtp-11-81.txt on our machine. These two items should give you some insight. As you probably know the old ARPANET mail protocol was kind of an afterthought and is thoroughly mixed up with FTP. This will not be the case with the new protocols. Jake -------  Date: 25 November 1981 1422-EST (Wednesday) From: David Lamb To: Daul at OFFICE-2 Subject: Re: Header Field Order CC: header-people at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: Daul@OFFICE's message of 25 Nov 81 12:57-EST Message-Id: <25Nov81 142229 RD00@CMU-10A> According to RFC733, page 13 (the "NOTE" in the section on General Syntax of Messages), header fields are not required to be in any order. It does recommend the order Date, From, Subject, Sender, To, CC, other fields. Only Date and From are required (page 14), aside from requirement of a Sender field under certain circumstances.  Date: 30 Nov 1981 15:36:12-PST From: chico!duke!unc!smb at Berkeley In-real-life: Steven M. Bellovin In-Reply-To: Daul at OFFICE's message of 25 Nov 1981 0957-PST To: Daul@OFFICE, header-people@MIT-MC Subject: Re: Header Field Order RFC-733 explicitly permits any order for header fields, though it does give a suggested order.  Date: 14 Jan 82 6:15:59-EST (Thu) From: Michael Muuss To: MSGroup at Mit-Ai, Header-People at Mit-Ai cc: Stef at Darcom-Ka, Mike at Brl Subject: TCP Digest & Discussion of Mailer Headers As a result of talking about connections between multiple networks, and mail relay between NCP and TCP style ArpaNet hosts, there has recently been a fair amount of discussion about MAIL headers, and proper multiple network naming and addressing schemes. I would be interested in getting pointers to earlier discussion of this material, so that the TCP-Digest people don't run open loop and re-invent the wheel. Especially if it came out oblong! -Mike  Date: 28 Jan 1982 1556-EST From: J. Noel Chiappa Subject: [jnc at mit-csr at mit-multics: LSI11 lossage] To: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC cc: lwa at MIT-XX Mail-from: ARPANET site MIT-MULTICS rcvd at 27-Jan-82 2206-EST Date: 27 Jan 1982 2152-EST (Wednesday) From: jnc at mit-csr at mit-multics Reply-to: jnc@mit-xx Subject: LSI11 lossage To: acm CC: ddc,lwa,martin,dt,jnc When Dave went to start using the +/-15V on the TST machine, he had a lot of problems. The -15V was completely dead, and the backplane wiring for the +15V was broken in several places. I suspect that this happened when Greg plugged that CTL board in in the wrong place and blew out a bunch of things. Dave is going to send a message out describing the things that were broken in more detail. The backplane contains shorts on the contact side of the etch; i.e. where they are unreachable, so that backplane may be unfixable. Opinions? ------- Well, when I try to say 'REP ALL' to this message in MM, I get addresses of the form 'DDC at MIT-Multics'. It is my understanding that you weren't supposed to have local addresses in outside mail; is this true? If not, who is at fault, MM or the mail sender? Should the From field not have the 'at MIT-Multics'? Should MM be putting the whole source on the destination, and not just the last host? What gives? -------  Date: 28 Jan 1982 1339-PST From: Mark Crispin Subject: Re: [jnc at mit-csr at mit-multics: LSI11 lossage] Sender: ADMIN.MRC at SU-SCORE To: JNC at MIT-XX, mmcm at MIT-AI, header-people at MIT-MC cc: lwa at MIT-XX Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 28-Jan-82 1256-PST Local addresses should not be allowed outside of a host. MM takes great pains not to compose such messages for network mail. When it encounters a header such as your example it takes an educated guess of where the origin is. It's even more academic than that, because multiple at addresses are going to be going away very soon anyway. -------  Date: 28 Jan 1982 1453-PST From: Daul at OFFICE Subject: MM document wanted... To: jnc at MIT-XX cc: mmcm at MIT-AI, Admin.MRC at SU-SCORE, lwa at MIT-AI, cc: header-people at MIT-MC can someone tell me of a good document on MM or even XMAILER? Thanks, Bill -------  Date: 28 Jan 1982 1513-PST From: Mark Crispin Subject: Re: MM document wanted... Sender: ADMIN.MRC at SU-SCORE To: Daul at OFFICE-2, jnc at MIT-XX cc: mmcm at MIT-AI, lwa at MIT-AI, header-people at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 28-Jan-82 1453-PST The current set of MM documentation is pretty out of date. My wife is working on an up to date manual. What there is can be found online at SU-SCORE on MM.* (the * is a wildcard meaning all files with first filename MM). SU-SCORE supports ANONYMOUS FTP login with any password. -- Mark -- -------  Date: 28 January 1982 1818-EST From: David Lamb at CMU-10A To: J. Noel Chiappa Subject: Re: [jnc at mit-csr at mit-multics: LSI11 lossage] CC: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC, lwa at MIT-XX Reply-To: Rdmail at CMU-10A In-Reply-To: J. Noel Chiappa's message of 28 Jan 82 15:56-EST Message-Id: <28Jan82 181843 RD00@CMU-10A> That address is perfectly legal according to RFC733, the ARPAnet header standard. However, a lot of mailers don't understand addresses with multiple "at"s in them.  Date: 28 Jan 1982 1704-PST From: Mark Crispin Subject: Re: Re: [jnc at mit-csr at mit-multics: LSI11 lossage] Sender: ADMIN.MRC at SU-SCORE To: Rdmail at CMU-10A, JNC at MIT-XX cc: mmcm at MIT-AI, header-people at MIT-MC, lwa at MIT-XX Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 28-Jan-82 1518-PST However, ARPA has decreed that nobody is supposed to use multiple at addresses. I found that out earlier this month. They were in fact rather angry at MIT and Stanford for generating such addresses. I expressed my distaste at this part of the standard being declared invalid with no general announcement to the ARPANET community. Apparently this had been decided by the Internet working group some time ago. Their reasons were perfectly valid; but their proposed solution was completely unacceptable for a number of sites. There is a new proposal which is actually rather elegant and looks towards the future, but it hasn't been officially announced yet. -------  Date: 28 Jan 1982 1728-PST From: Daul at OFFICE Subject: Please remove CLEN@OFFICE-2 To: header-people at MIT-MC she has moved to greener pastures. Thanks, -Bill -------  Date: Tuesday, 2 Feb 1982 19:01-PST To: greep at ISL Postmark: Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1857-PST Received: Network mail from host MIT-MC for greep on Thu Jan 28 15:57:49 1982 Date: 28 January 1982 1818-EST From: David Lamb at CMU-10A To: J. Noel Chiappa Subject: Re: [jnc at mit-csr at mit-multics: LSI11 lossage] CC: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC, lwa at MIT-XX Reply-To: Rdmail at CMU-10A In-Reply-To: J. Noel Chiappa's message of 28 Jan 82 15:56-EST Message-Id: <28Jan82 181843 RD00@CMU-10A> Sender: root at ISL That address is perfectly legal according to RFC733, the ARPAnet header standard. However, a lot of mailers don't understand addresses with multiple "at"s in them.  Date: Tuesday, 2 Feb 1982 19:02-PST To: greep at ISL Postmark: Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1900-PST Received: Network mail from host MIT-MC for greep on Thu Jan 28 15:41:05 1982 Date: 28 Jan 1982 1513-PST From: Mark Crispin at ISL Subject: Re: MM document wanted... Sender: ADMIN.MRC at SU-SCORE To: Daul at OFFICE-2, jnc at MIT-XX cc: mmcm at MIT-AI, lwa at MIT-AI, header-people at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 28-Jan-82 1453-PST Sender: root at ISL The current set of MM documentation is pretty out of date. My wife is working on an up to date manual. What there is can be found online at SU-SCORE on MM.* (the * is a wildcard meaning all files with first filename MM). SU-SCORE supports ANONYMOUS FTP login with any password. -- Mark -- -------  Date: Tuesday, 2 Feb 1982 19:26-PST To: greep at ISL Postmark: Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1923-PST Received: Network mail from host MIT-MC for greep on Thu Jan 28 17:20:16 1982 Date: 28 Jan 1982 1704-PST From: Mark Crispin at ISL Subject: Re: Re: [jnc at mit-csr at mit-multics: LSI11 lossage] Sender: ADMIN.MRC at SU-SCORE To: Rdmail at CMU-10A, JNC at MIT-XX cc: mmcm at MIT-AI, header-people at MIT-MC, lwa at MIT-XX Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 28-Jan-82 1518-PST Sender: root at ISL However, ARPA has decreed that nobody is supposed to use multiple at addresses. I found that out earlier this month. They were in fact rather angry at MIT and Stanford for generating such addresses. I expressed my distaste at this part of the standard being declared invalid with no general announcement to the ARPANET community. Apparently this had been decided by the Internet working group some time ago. Their reasons were perfectly valid; but their proposed solution was completely unacceptable for a number of sites. There is a new proposal which is actually rather elegant and looks towards the future, but it hasn't been officially announced yet. -------  Date: Tuesday, 2 Feb 1982 19:30-PST To: greep at ISL Postmark: Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1927-PST Received: Network mail from host MIT-MC for greep on Thu Jan 28 17:46:02 1982 Date: 28 Jan 1982 1728-PST From: Daul at OFFICE Subject: Please remove CLEN@OFFICE-2 To: header-people at MIT-MC Sender: root at ISL she has moved to greener pastures. Thanks, -Bill -------  Date: 3 Feb 1982 1054-EST From: PDL at MIT-DMS (P. David Lebling) To: Header-people at MIT-MC In-reply-to: Message of 03 Feb 82 at 1017 EST Subject: Ridiculous Header Message-id: <[MIT-DMS].222392> Someone seems to be sending a message with this baroque header around like a hot potato. I've gotten about 10 copies of it so far. Is it considered kosher for a message to have two date fields, two sender fields, etc.? This question is independent of the aesthetic considerations, of course. I can't even tell who sent it to whom when and why... Date: Tuesday, 2 Feb 1982 19:26-PST To: greep at ISL Postmark: Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1924-PST Received: Network mail from host MIT-ML for rand-msggroup on Fri Jan 22 14:12:36 1982 Date: 22 Jan 1982 1349-PST Sender: ADPSC at USC-ISI Subject: Call for COMPCON papers From: jim.fcc-net at UDEL Reply-To: jim.fcc-net at UDEL To: msggroup at MIT-AI, Human-nets at MIT-AI Message-ID: <[USC-ISI]22-Jan-82 13:49:13.ADPSC> Sender: root at ISL Comments, anyone? Dave  Date: 3 Feb 1982 1225-EST Sender: MOOERS at BBNA Subject: Re: Ridiculous Header From: MOOERS at BBNA To: PDL at MIT-DMS Cc: Header-people at MIT-MC, Cc: Mooers at BBNA Message-ID: <[BBNA] 3-Feb-82 12:25:46.MOOERS> In-Reply-To: <[MIT-DMS].222392> It is probably intended to be a forwarded message. Somehow, the necessary blank line between the first set of header lines and the text was erased. ---Charlotte  Date: Wednesday, 3 Feb 1982 10:13-PST To: greep at ISL Postmark: Date: Wednesday, 3 Feb 1982 10:13-PST To: PDL at MIT-DMS (P. David Lebling) Cc: Header-people at MIT-MC Subject: Re: Ridiculous Header In-reply-to: Your message of 3 Feb 1982 1054-EST. <[MIT-DMS].222392> From: Brian Reid Sender: root at ISL As nearly as I can tell, Greep@SU-ISL is sending that message around. I don't know why. There are some bugs in the incoming mailer at SU-ISL whose fingerprints are all over that header. He might not even realize he is doing it.  Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1013-PST Date: Wednesday, 3 Feb 1982 10:13-PST To: PDL at MIT-DMS (P. David Lebling) Cc: Header-people at MIT-MC, Steve Tepper Subject: Re: Ridiculous Header In-reply-to: Your message of 3 Feb 1982 1054-EST. <[MIT-DMS].222392> From: Brian Reid @Shasta at Sumex-Aim As nearly as I can tell, Greep@SU-ISL is sending that message around. I don't know why. There are some bugs in the incoming mailer at SU-ISL whose fingerprints are all over that header. He might not even realize he is doing it.  Date: 3 Feb 1982 1023-PST From: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: Ridiculous Header To: MOOERS at BBNA, PDL at MIT-DMS cc: Header-people at MIT-MC, Mooers at BBNA, ZELLICH In response to the message sent 3 Feb 1982 1225-EST from MOOERS@BBNA Besides the odd header format, there were, indeed, several copies of some messages sent out. The latter problem was due to a screwed-up mail distribution system - perhaps the bad formatting of the forwarded header/message was also due to the broken distributor (although I feel all the stuff in some of those headers is a little excessive - I don't feel a strong need to know the senders' US Mail address, etc.). -Rich -------  Date: Wednesday, 3 Feb 1982 10:47-PST To: greep at ISL Postmark: Date: Wednesday, 3 Feb 1982 10:46-PST To: Header-people at MIT-MC Cc: PDL at MIT-DMS (P. David Lebling) Subject: Re: Ridiculous Header In-reply-to: Your message of Wednesday, 3 Feb 1982 10:13-PST Wednesday, 3 Feb 1982 10:13-PST. From: Brian Reid Sender: root at ISL I think I see what is happening. When a message arrives in Greep's mailbox at Tamalpais, it is somehow being resubmitted to the Tam mailer for reparsing and retransmission. The Tamalpais mailer, like many dumb Unix mailers, works by parsing the message header to figure out who the message should be transmitted to. The message as it arrives in that mailbox will have these fields in it: Postmark: Date: Wednesday, 3 Feb 1982 10:13-PST To: PDL at MIT-DMS (P. David Lebling) Cc: Header-people at MIT-MC Subject: Re: Ridiculous Header In-reply-to: Your message of 3 Feb 1982 1054-EST. <[MIT-DMS].222392> From: Brian Reid Some trying-to-be-clever forwarding system then adds this line the front: To: greep at ISL and submits it to the Tamalpais mailer for "forwarding". The mailer there sees a "From:" field in it that does not correspond to the person who submitted the mail to the mailer, so it adds Sender: root at ISL at the end of the header and Date: Wednesday, 3 Feb 1982 10:13-PST at the beginning of the header. It then gets re-transmitted to all of the original recipients in addition to the intended recipient of "greep at ISL". Since one of those recipients was Header-People at MC, the message is routed through MC where it acquires this field: Via: MIT-MC; 3 Feb 1982 1324-EST and ends up in all of our mailboxes looking like that. Wow. Brian  Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1047-PST Date: Wednesday, 3 Feb 1982 10:46-PST To: Header-people at MIT-MC Cc: Steve Tepper , PDL at MIT-DMS (P. David Lebling) Subject: Re: Ridiculous Header In-reply-to: Your message of Wednesday, 3 Feb 1982 10:13-PST Wednesday, 3 Feb 1982 10:13-PST. From: Brian Reid @Shasta at Sumex-Aim I think I see what is happening. When a message arrives in Greep's mailbox at Tamalpais, it is somehow being resubmitted to the Tam mailer for reparsing and retransmission. The Tamalpais mailer, like many dumb Unix mailers, works by parsing the message header to figure out who the message should be transmitted to. The message as it arrives in that mailbox will have these fields in it: Postmark: Date: Wednesday, 3 Feb 1982 10:13-PST To: PDL at MIT-DMS (P. David Lebling) Cc: Header-people at MIT-MC Subject: Re: Ridiculous Header In-reply-to: Your message of 3 Feb 1982 1054-EST. <[MIT-DMS].222392> From: Brian Reid Some trying-to-be-clever forwarding system then adds this line the front: To: greep at ISL and submits it to the Tamalpais mailer for "forwarding". The mailer there sees a "From:" field in it that does not correspond to the person who submitted the mail to the mailer, so it adds Sender: root at ISL at the end of the header and Date: Wednesday, 3 Feb 1982 10:13-PST at the beginning of the header. It then gets re-transmitted to all of the original recipients in addition to the intended recipient of "greep at ISL". Since one of those recipients was Header-People at MC, the message is routed through MC where it acquires this field: Via: MIT-MC; 3 Feb 1982 1324-EST and ends up in all of our mailboxes looking like that. Wow. Brian  Date: Wednesday, 3 February 1982 11:21-PST From: Jonathan Alan Solomon To: Zellich at OFFICE-3 (Rich Zellich) Cc: Header-people at MIT-MC, MOOERS at BBNA, PDL at MIT-DMS Subject: Ridiculous Header Seems that SU-ISL's mailer is sending out return mail to everybody who sends to it (in the case of some of it the sender was INFO-VAX at SANDIA, a distribution list). This caused a loop, which I stopped by forcing all mail for INFO-VAX to be sent to a file, and I redistribute manually. Since last night, I have about 50 TOPS-20 pages of junk from SU-ISL, and no real mail for INFO-VAX to send out. Ahh, such is life on the ARPAnet. --JSol  Date: 3 Feb 1982 1218-PST From: Richard Furuta Subject: Re: Ridiculous Header To: reid at SU-AI, header-people at MIT-MC cc: Furuta at WASHINGTON Incidentally, it is not only header-people who are victims of this mailer. The other groups I know of include info-vax, msggroup, and info-terms. I think I received from ten to twenty old messages yesterday, courtesy of Tamalpais' mailer. Indeed, info-vax has gone to indirect redistribution until the bug is fixed. Since the messages arriving are around a week old, I suspect that the problem was related to the Usenet newsgroups in some fashion, particularly since the info-vax messages' headers contain a field saying that they are intended for news.info-vax. Perhaps someone's computer finally got around to calling up SU-ISL and attempted to deliver the collection of news and thereby originated the flood of repeated messages. Do you suppose it'll all happen again next Tuesday evening? --Rick -------  Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1956-PST Date: Wednesday, 3 Feb 1982 19:56-PST To: Header-People at MIT-MC, Info-VAX at MIT-MC Cc: Neumann at SRI-KL, Hartwell at ISL, Greep at ISL, Nowicki at Shasta Subject: the great SU-ISL mail looping mystery solved Reply-to: Reid at SU-AI From: Brian Reid @Shasta at Sumex-Aim As you all know, there has been a problem recently with mail passing through SU-ISL littering the airwaves with multiple repeated copies to half of the Arpanet. The SU-ISL machine is on our local ethernet, so I took the liberty of poking around in it, and after several hours of tense debuggery I have tracked down and fixed the cause of the loop. There's a lesson in here somewhere, but I fear it might just be "never import software; always write your own". People on SU-ISL use the Rand mail handler MH, a very nice mail package that provides good handling and responsible local transport of mail. One of the things that MH tries very hard to do is to authenticate mail that is being sent. If a user sends a message that already contains a "From" field, the MH delivery software checks to make sure that the user is not lying about who is is, and if the MH delivery program detects fibbing, it adds a "Sender:" field identifying who it thinks is the real author of the mail. Unfortunately, the mail transport sections of MH just aren't up to the quality of the rest of it, so running MH in our ethernet environment required a better mail delivery agent than its built-in code. SU-ISL is not on the Arpanet; mail for it is routed through SUMEX and converted from Arpanet FTP into Xerox Ethernet MTP protocol, where it is transmitted by Ethernet to SU-ISL. At SU-ISL, a program called MTPserver is run, which accepts RFC's on the Ethernet for mail delivery, and when it gets one, attempts delivery of the mail. MTPserver runs the Xerox mail protocols, and thinks it is dealing with Berkeley mailboxes. The delivery is actually accomplished by running a program named "delivermail", which was written at Berkeley and is part of the Berkeley mail system. The Berkeley mail system is somewhat of an opposite of the Rand mail system: it has a really primitive (some call it terrible) mail handling component, but an extremely sophisticated and flexible mail delivery component. So the Unix systems at Stanford use Berkeley delivery software regardless of whether they use Berkeley mail handling software. The Berkeley "delivermail" program discovers that (a) the intended recipient of the mail is local to ISL, and (b) that the recipient is a user of the MH mail system and therefore wants his mail delivered in MH format. Deliver therefore duly forks off to the MH mail program, /etc/mh/mail, charging it with accomplishing the local delivery of this mail. The mechanism by which "mail" is told that its job is to deliver incoming net mail rather than send keyboard-origin mail is that it is run as "root", a privileged userid. This program "mail" doesn't really know how to deliver mail; in true Unix fashion it passes the buck off to somebody who does; in this case, the MH delivery module /etc/mh/deliver, passing it a special option saying "I have been invoked by privileged users, so don't edit this header at all; this is just local delivery". Being deeply suspicious and trying to prevent forgery (as mentioned before), the MH deliver program checks to see if that can be true; it checks the user id (had better be "root"), and the local host id (had better be the same). For incomprehensible reasons, some anonymous person at ISL recently made a "bug fix" to some piece of MH, recompiled, and reinstalled. Unfortunately, the correct sources were not on that machine, only the original sources as distributed from Rand (the updates to interface it to the Berkeley mailer were off on another machine). So the Rand-original version of "mail" got suddenly put up on ISL; it never heard of the Berkeley mailer, and in particular it was not in the mood to invoke privilege when calling the local delivery program. So there was an intended-use conflict, and the requisite "this user is privileged" information did not get passed through to the delivery program. The delivery program responded to this conflict by saying "you are lying", and refusing to honor the "just do local delivery" option handed it (indirectly) by the Berkeley mailer. Because it thought that it had detected a case of intended mail forgery, it treated the mail as being of local origin, and therefore needing to be (a) verified and (b) parsed to find out who the mail is supposed to be sent to. The verification discovered that the mail had a random "From:" in it, so a "Sender: root at ISL" field was added. The mail was then parsed to extract a list of recipients, some local and some network; and a copy of the mail was then sent through normal delivery channels to all of the recipients mentioned in the mail header. Loop. I see the following morals in this story: * All of the software has compiled-in host names. Bad. A program operating in a network environment should determine its host name dynamically. Both Berkeley and Rand are equally guilty of this error, but it seems to be pretty much the way things are done under Unix, so they were only following convention. This made it impossible to distribute binary versions of the software from a single master source on one machine. * The Rand software is trying to make one program serve two totally separate functions, namely local delivery (if privileged) or origination delivery (if not privileged). The Swiss Army Knife is one of the few examples I have seen of a multi-purpose tool that does each job properly. The general Unix philosophy of having a program serve equally well for reading from the terminal or from a file or pipe is in a sense responsible, because there was (unusuable) information in the fact of the mail's having originated from the network and not from a keyboard. * The Rand local-origin delivery program parses the mail header to find out who the mail should be sent to. It should be getting this information "out of band" through some private communication from the mail handling program, rather than parsing the file. Doubly true if it can ever accidentally fall into this mode, as was happening in this bug. * Network programs like these should not communicate information to each other by the 1-bit channel of "being in privileged mode" or "not being in privileged mode". There are more civilized ways, like options. Admittedly this information path was not part of either the Rand system or the Berkeley system, but rather of the hack job that made them talk to each other. * Network programs like these should be written so that their debug modes can be activated without killing and restarting the process. All of them have a "debug mode" that can be turned on when the program is first run; there needs to be a way that it can be turned on and off by sending it special functions while it is actually running. Sorry to bend your ears for so much text, but I figured that the community should at least learn something from all of this nuisance. Brian Reid  Date: 3 February 1982 23:39-EST From: David Eppstein Subject: legal header? To: HEADER-PEOPLE at MIT-MC cc: BUG-BABYL at MIT-MC, Reid at SU-AI Babyl barfs on the following: Reply-to: Reid at SU-AI From: Brian Reid @Shasta at Sumex-Aim Is this legal?  Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 2204-PST Date: Wednesday, 3 Feb 1982 22:04-PST To: David Eppstein Cc: HEADER-PEOPLE at MIT-MC, BUG-BABYL at MIT-MC Reply-to: Reid at SU-AI Subject: Re: legal header? In-reply-to: Your message of 3 February 1982 23:39-EST. From: Brian Reid @Shasta at Sumex-Aim Of course it's not legal. I just haven't succeeded in convincing the guy who maintains the mail gateway program that he should stop munging with headers.  Date: 4 Feb 1982 0026-MST From: Jay Lepreau Subject: Re: the great SU-ISL mail looping mystery solved Sender: LEPREAU at UTAH-20 To: reid at SU-AI cc: header-people at MIT-MC In-Reply-To: Your message of 3-Feb-82 2103-MST Wonderful loop! There are two things Berkeley is doing which should help a bit: -- Finally, all local info, including host name, will be maintained somewhere in the environment, not compiled into binaries. You are right that this has been a gross failing of Unix. -- Delivermail is being replaced with something called sendmail, which I'm told makes poor old delivermail look sick. It keeps all local info, including routing, in a file and not in the binaries. It might even address some of the other points you raised. -------  Date: 4 February 1982 1114-EST (Thursday) From: Richard H. Gumpertz To: David Eppstein Subject: Re: legal header? CC: HEADER-PEOPLE at MIT-MC, BUG-BABYL at MIT-MC, Reid at SU-AI Sender: Rick.Gumpertz at CMU-10A In-Reply-To: David Eppstein's message of 3 Feb 82 23:39-EST Message-Id: <04Feb82 111436 RG02@CMU-10A> RdMail at CMU doesn't like Brian's FROM field either. Perhaps we should appeal to the ARPANET POLICE, those same people who insisted that CMU put dots instead of spaces between our first and last names! Rick  Date: 3 Feb 1982 1028-PST From: POSTEL at USC-ISIF Subject: re: ridiculous header To: header-people at MIT-MC Dave: i have also received several messages with this ridiculous header, but with different texts. The common elements are: greep@isl Tamalpais root@ISL 2-Feb-82 19:26 i suugest that greep should send in an explaination. --jon. -------  Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1658-PST Date: Wednesday, 3 Feb 1982 16:57-PST To: Jonathan Alan Solomon Cc: Steve Tepper , Guyton at RAND-UNIX, header-people at MIT-AI, Mike at RAND-UNIX, MOOERS at BBNA, PDL at MIT-DMS, Reid at SU-AI, STEF at DARCOM-KA, ZELLICH at OFFICE-3 Subject: Re: Mail looping In-reply-to: Your message of Wednesday, 3 February 1982 16:03-PST. From: Brian Reid @Shasta at Sumex-Aim Three of us (none associated with SU-ISL) are working full time on this problem. It seems to be some design flaw in the Rand mail handler, but debugging network software is tricky.  Date: 3 Feb 1982 1552-PST From: Steve Tepper Subject: Mail looping To: STEF at DARCOM-KA, JSOL at USC-ECLB, PDL at MIT-DMS, ZELLICH at OFFICE-3, Reid at SU-AI, MOOERS at BBNA, Mike at RAND-UNIX, Guyton at RAND-UNIX cc: header-people at MIT-AI, greep at RAND-AI My apologies for all the inconvenience everyone suffered. The problem is at ISL, which is on the Stanford Ethernet and is accessed through the gateway at Sumex-Aim. For some reason ISL's mail system seems to treat incoming mail as mail that should be processed for sending. The problem is not at Rand-Unix. It showed up when I tried having my mail forwarded from Rand-Unix to greep@ISL@Sumex-Aim, which I will certainly not try again in the near future! The person responsible for the ISL machine is Steve Hartwell, who can be reached (I think) as hartwell@shasta@Sumex-Aim. If that doesn't work, try CSL.LAB.HARTWELL@SU-Score. -------  Date: 24 Feb 1982 2301-PST From: Richard Furuta Subject: [cbosg!harpo!whuxlb!nrf at Berkeley:] To: header-people at MIT-AI cc: Furuta at WASHINGTON Can't someone please convince Berkeley to at least include a To: line in the messages it sends out onto the net? I just got this message. Note that there is very little in either the header or in the message to indicate what distribution list it came from (other than the hint that it was forwarded through MIT-MC). --Rick --------------- Mail-from: ARPANET site MIT-MC rcvd at 24-Feb-82 2204-PST Date: 24 Feb 1982 21:52:57-PST From: cbosg!harpo!whuxlb!nrf at Berkeley you should have asked about this when it happened, we solved that problem years ago! -------  foo  Date: 6 Apr 1982 2144-EST (Tuesday) From: lwa at mit-csr Reply-to: lwa.INP@MIT-Multics Subject: Common usage in recipient names To: HEADER-PEOPLE at MIT-MC CC: lwa.INP at MIT-Multics What are the common formats for recipient names allowed by various mail sending and reading programs? In particular I am interested in the interpretation of single and double quotes, angle brackets, and parentheses in determining the mailbox name a message is to be delivered to given a recipient name. The reason that I ask is that I am rewriting a mail sender and want to conform to common usage. My current program works as follows: The only delimiters between recipient names are commas and ASCII control characters (includes and ). Within each recipient name: Strings enclosed in angle brackets have precedence over other strings; if the recipient name includes a string enclosed in angle brackets that string is used as the mailbox address. Strings enclosed in parentheses are treated as comments and are ignored, unless the entire parenthesized string is enclosed in double quotes. If the recipient name does not include a string enclosed in angle brackets, the program uses the entire recipient name string as the mailbox. Double quotes allow the inclusion of arbitrary strings (including the normal recipient name delimiters) within the mailbox name. Does this sound right? If not, where do the problems lie? Is there by any chance a compendium of common practice for mailers, since many things allowed by RFC733 are discouraged in practice? Thanks. -Larry Allen -------  Date: 13 Apr 1982 1517-PST From: Daul at OFFICE Subject: RFC-733 query To: header-people at MIT-MC cc: daul Is there a restriction on the number of addresses a mail item can be sent "From"? Can one have: From: daul@office, wdaul@office-2, daul@mit-mc Feel free to answer only to me at daul@office, if you don't think the readership is interested. -------  Date: 15 Apr 1982 2326-PST From: Daul at OFFICE Subject: RFC733 request To: header-people at MIT-MC Date: 13 Apr 1982 1517-PST From: Daul Subject: RFC-733 query To: header-people at MIT-MC cc: daul Is there a restriction on the number of addresses a mail item can be sent "From"? Can one have: From: daul@office, wdaul@office-2, daul@mit-mc Feel free to answer only to me at daul@office, if you don't think the readership is interested. ------- My first try at sending this seems to have failed, so.......... ............................................................... -------  Date: 1 May 1982 1159-PDT From: Daul at OFFICE Subject: RFC-733 (multiple header fields) To: header-people at MIT-AI cc: daul Is there a restriction on the number of addresses a mail item can be sent "From"? Can one have: From: daul@office, wdaul@office-2, menlo70!daul@ucb-c70 Thanks, --Bill (DAUL at OFFICE) -------  Date: 11 May 1982 1651-PDT From: POSTEL at USC-ISIF Subject: how many messages a day does your computer handle? To: header-people at MIT-MC really! how many computer mail type messages a day go out from your computer to other computers, how many come in, and how many are sent between users internal to your system? what counts as a message? do all copies of the same text count as one message, or once for each recipient? the answer to these questions are desired be people trying to size some mail handling systems. --jon. -------  Date: 14 May 1982 0010-PDT From: Daul at OFFICE Subject: Rumor Confirmation (CCIT new Inter-System Communications Standards) To: msggroup at MIT-MC, header-people at MIT-MC cc: daul I have heard a rumor that new standards have been drawn-up/released in the last 2 or 3 weeks. Is it true and, if so how can I get further info? Thanks, --Bill -------  Date: 14-May-82 9:00:48 PDT (Friday) From: white at PARC-MAXC Subject: Re: Rumor Confirmation (CCIT new Inter-System Communications Standards) In-reply-to: Daul's message of 14 May 1982 0010-PDT To: Daul at OFFICE cc: msggroup at MIT-MC, header-people at MIT-MC, White.pa Bill, The CCITT rapporteur's group on message handling facilities (i.e., electronic mail) maintains a living document that will eventually become--but is not now--a proposed CCITT recommendation (i.e., standard). Version 3, which reflects the work done at the March meeting in Melbourne, was indeed completed just a week or two ago. I would be happy to send a copy to you and to other interested members of MSGGroup, provided the number of such people is modest. /Jim  Date: 27 May 82 17:48:16-EDT (Thu) From: Dave Crocker To: Header-People at Mit-Mc Subject: Draft Revision to RFC #733 Greetings. As most of you are aware, ARPA has directed that RFC #733, "Standard for the Format of ARPA Network Text Messages" be modified, to meet the needs of the larger Internet context. By virtue of your membership in the Header-People mailing list, I would appreciate your reviewing a draft of the revised specification. We are under severe time pressures; if you can find it in your heart to provide me with feedback by the end of next week, I will be eternally grateful. The specification is the result of several meetings and considerable discussion. However, the document is still subject to change. Now is the time to voice your suggestions. The file is located at UDel-Relay. You can login through FTP with username anonymous, and any password. The name of the file is: /usa/dcrocker/733/new.ff If is fully formatted, indented and uses form-feeds. Underlines are handled by line overprinting (rather than character backspacing). The document is 46 paper pages, under 113K characters, and ends with the Table of Contents. Thanks. Dave  Date: 30 May 82 20:49:36-EDT (Sun) From: Dave Crocker To: Relay-Sites at UDel-Relay, MsgGroup at Mit-Mc, Header-People at Mit-Mc cc: CSNet-Staff at UDel-Relay Subject: XMAILR problem. I apologize for shotgunning this message, but a condition has arisen that needs to be fixed as quickly as possible. We happen to have a very slow NCP; it is the Rand Front-End and commonly gives us about 1 (one) KBaud on a connection. This is being worked on, by its author, but currently is a fact of life. Even with a faster NCP, we would eventually run into the following problem. Apparently, the Tops-20 XMAILR Arpanet channel imposes an absolute 5 minute limit on TOTAL transmission time for a message. If the message takes longer, XMAILR aborts the connection and requeues the message. One fix, being tested at USC, is to impose the limit on 1Kbyte chunks of messages. As the UDel-Relay machine is servicing more Phonenet sites, it is getting stung more frequently by this XMAILR behavior. Like many of Unix sites, our FTP server forwards incompletely received Arpanet messages -- there was originally dictated by occasionally misbehaving senders. Given the current problem, I am turning that feature off our own FTP server. Dave  Date: 31 May 1982 14:20-EDT From: Ken Harrenstien Subject: Ignore this message, unless... To: header-people at MIT-MC you get two copies, in which case let me know. I'm just testing a new version of the mailing list.  Date: 31 May 1982 1315-PDT From: Mark Crispin Subject: XMAILR and timeouts Sender: ADMIN.MRC at SU-SCORE To: MsgGroup at MIT-ML cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think it's been agreed that we'll change XMAILR, with one note: It isn't unreasonable for a system manager to feel that his system mailer should not be tied up for more than 5 minutes delivering a single copy of a message to a single site, EVEN IF it is merely because the receiving site is too slow. Much of the sort of traffic which is impacted by XMAILR's present behavior are junk mail which isn't even legitimate usage of ARAPNET anyway. -------  Date: Monday, 31 May 1982 15:58-PDT To: Admin.MRC at SU-SCORE Cc: MsgGroup at MIT-ML, Header-People at MIT-MC, DCrocker at UDEL-RELAY Subject: Re: XMAILR and timeouts In-reply-to: Your message of 31 May 1982 1315-PDT. From: greep at SU-DSN Obviously, no matter how fast all the systems are, there is some length of message which will exceed any fixed timeout. An alternate strategy would be for the mailer to delay long messages until the system load is light, or late at night, or whatever.  Date: 1 Jun 1982 0032-PDT Sender: STEF at DARCOM-KA Subject: Re: XMAILR and timeouts From: STEF at DARCOM-KA To: greep at SU-DSN Cc: Admin.MRC at SU-SCORE, MsgGroup at MIT-ML, Cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY Message-ID: <[DARCOM-KA] 1-Jun-82 00:32:04.STEF> In-Reply-To: Your message of Monday, 31 May 1982 15:58-PDT In any case, what we now have is a single community with two conflicting policies which severely impact unwitting users and sites who are not able to control what happens to them. The 5 minute XMAILR maximum coupled with a "forward partial copies" policy in CSNET was deadly. The new ECL XMAILR policy of a 5 minute maximum per 1000 bytes looks like a winner. Can we look forward to its rapid installation in XMAILRS around the net so as to operationally resolve what is otherwise going to be a long untenable summer. Thanks - Stef  Date: 1 Jun 1982 1339-PDT From: Mark Crispin Subject: Re: XMAILR and timeouts Sender: ADMIN.MRC at SU-SCORE To: STEF at DARCOM-KA cc: greep at SU-DSN, MsgGroup at MIT-ML, Header-People at MIT-MC, DCrocker at UDEL-RELAY Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 1-Jun-82 0032-PDT Sorry for the flames, and especially to those of you who will receive this message four times. I did have to reply to Stef's message. I suppose you folks are all aware that XMAILR has done this 5 minute timeout for two years or so now. It isn't that this is something recent, or for that matter something that suddenly came up. I am a bit distressed if not angered by terms like "rapid installation" to the first patch which comes along. It smacks of administratively mandated changes in software which otherwise is never modified. The fact is, XMAILR is part of a package receiving extensive development and maintainence. In addition, as a primary maintainer and developer of XMAILR, I can't help but wonder why a message about the internals of a particular message delivery process was sent to all of MsgGroup and Header-People instead of to one of the XMAILR maintainers. It smacks of washing dirty laundry in public. Sometimes public broadcasting of such an issue is necessary if the maintainers are unresponsive, but in this case I had heard nothing until it was bannered across the mailing lists. Among other things, I never received a copy of the complaint addressed to me personally. Now, as for the proposed changes, ECL's change nominally fixes that particular problem, but is not in any way a general solution. I do not like patchwork or myoptic changes to solve an individual problem. The fact is, a more general solution to this and other related issues has been specified, and will be implemented in XMAILR in the next few weeks. I also wish to point out that the "forward partial copies" policy in CSNET was, is, and will continue to be a bug until it is removed. Under no circumstances will XMAILR remove timeouts entirely. I acknowledge that XMAILR's old timeout policy was inadequate. As part of the solution we will have a 5 minute per 1000 byte timeout; but I think 33 baud is too slow of a datarate to be considered "reasonable" and XMAILR in the future may enforce a minimum of, say, 300 baud throughput. CSNET is clearly an important project, but the attitude that its needs override all other needs is wrong. Compromises can and will be made to accomodate CSNET, but at the same time a site running XMAILR cannot be expected to have its electronic mail service "go south" for extended periods of time while long messages are being delivered to a slow mail receiving process on CSNET. The problem is heightened by the fact that CSNET does not recognize the XRCP extension to the FTP mail protocol, so if a hundred recepients on CSNET are each receiving a message that takes 10 minutes/copy to deliver, it could take 17 hours to deliver it! In a non-multitasking mail delivery model such as XMAILR's, that can mean that all network mail service (or on systems like SCORE which use XMAILR exclusively ALL mail service) is "shut off" for that period of time. I would therefore like to ask the maintainers of the CSNET FTP server to extend it to support XRCP in exchange for a more reasonable timeout policy on the part of XMAILR (a change which we will make in any case). -- Mark -- -------  Date: 1 Jun 82 19:47:54-EDT (Tue) From: Dave Crocker To: Admin.MRC at Su-Score cc: STEF at Darcom-Ka, greep at Su-Dsn, MsgGroup at Mit-Ml, Header-People at Mit-Mc, DCrocker at UDel-Relay Subject: Re: XMAILR and timeouts Mark -- None of the relevant software, running on the UDel-Relay machine, were developed for CSNet. While CSNet is funding the machine, CSNet policies and activities are not particularly relevant to this technical problem. The FTP server is a derivative of the original Illinois one, and most of its copies have demonstrated the forward-partial-copy philosophy for six, or so, years. Implementing an unofficial ftp command might help, as will the approaching improvements to the NCP, but they only postpone the fundamental incompatibility, not remove it. Sorry about sending the original note to a large distribution list. We got stung twice in three days from different sites, with this problem and I did not have the address of a person notify. XMAILR is quite popular & running on many sites, so I wanted specifically to make sure they were aware of the policy. The problem had occurred a month or so ago, and the people at Rutgers apparently knew nothing about XMAILR's policy.  Date: 1 Jun 1982 1818-PDT Sender: STEF at DARCOM-KA Subject: Re: XMAILR and timeouts From: STEF at DARCOM-KA To: MsgGroup at MIT-ML, Header-People at MIT-MC Message-ID: <[DARCOM-KA] 1-Jun-82 18:18:29.STEF> In-Reply-To: DCrocker message of 1 Jun 82 19:47:54-EDT (Tue) Hi Marc, et al --- I am at quite a loss to know why this conflict of policies has not caused trouble among us in the net before now, but the trouble has bitten me twice in the last month and it cost a large amount of time, and wasted message transmission effort both times. Is it posible that no one ever sent a long enough message to cause this repeated attempt behavior from an XMAILER site, where the message was never going to make it in 5 minutes, and XMAILR was nevr doing to give up trying? The problem seems to have been a sleeper, and I agree that it is very unpleasant to be awakened by such things. But, I want to protest on my own behalf that I am mostly just the guy who announced the nature of the basic policy conflict, and I want to note that I understand the strong tendency for rudely awakened people to kill the messenger first, and fix the problem second. Surely this will not be the last arrow I attract. Swish ===========> Stef  Date: 2 June 1982 14:53-EDT From: Ken Harrenstien Subject: Re-transmitted message (or, why are you seeing this?) To: HEADER-PEOPLE at MIT-MC Some people have complained that without warning they are now seeing a dialogue about XMAILR which they are completely uninterested in. What really happened is that their names, being part of Postel's MTP interest group mailing list, were added to Header-People so that Dave Crocker could begin discussion of the latest RFC733 revisions. Unfortunately, his initial message was sent just before I tested the new list. In order to start over from the right place, I am re-sending that message. Apologies to those long-time Header-people members who have already seen it. ----- Date: 27 May 82 17:48:16-EDT (Thu) From: Dave Crocker To: Header-People at Mit-Mc Subject: Draft Revision to RFC #733 Greetings. As most of you are aware, ARPA has directed that RFC #733, "Standard for the Format of ARPA Network Text Messages" be modified, to meet the needs of the larger Internet context. By virtue of your membership in the Header-People mailing list, I would appreciate your reviewing a draft of the revised specification. We are under severe time pressures; if you can find it in your heart to provide me with feedback by the end of next week, I will be eternally grateful. The specification is the result of several meetings and considerable discussion. However, the document is still subject to change. Now is the time to voice your suggestions. The file is located at UDel-Relay. You can login through FTP with username anonymous, and any password. The name of the file is: /usa/dcrocker/733/new.ff If is fully formatted, indented and uses form-feeds. Underlines are handled by line overprinting (rather than character backspacing). The document is 46 paper pages, under 113K characters, and ends with the Table of Contents. Thanks. Dave  Date: 2 June 1982 14:53-EDT From: Ken Harrenstien Subject: Re-transmitted message (or, why are you seeing this?) To: HEADER-PEOPLE at MIT-MC Some people have complained that without warning they are now seeing a dialogue about XMAILR which they are completely uninterested in. What really happened is that their names, being part of Postel's MTP interest group mailing list, were added to Header-People so that Dave Crocker could begin discussion of the latest RFC733 revisions. Unfortunately, his initial message was sent just before I tested the new list. In order to start over from the right place, I am re-sending that message. Apologies to those long-time Header-people members who have already seen it. ----- Date: 27 May 82 17:48:16-EDT (Thu) From: Dave Crocker To: Header-People at Mit-Mc Subject: Draft Revision to RFC #733 Greetings. As most of you are aware, ARPA has directed that RFC #733, "Standard for the Format of ARPA Network Text Messages" be modified, to meet the needs of the larger Internet context. By virtue of your membership in the Header-People mailing list, I would appreciate your reviewing a draft of the revised specification. We are under severe time pressures; if you can find it in your heart to provide me with feedback by the end of next week, I will be eternally grateful. The specification is the result of several meetings and considerable discussion. However, the document is still subject to change. Now is the time to voice your suggestions. The file is located at UDel-Relay. You can login through FTP with username anonymous, and any password. The name of the file is: /usa/dcrocker/733/new.ff If is fully formatted, indented and uses form-feeds. Underlines are handled by line overprinting (rather than character backspacing). The document is 46 paper pages, under 113K characters, and ends with the Table of Contents. Thanks. Dave  Date: 2 June 1982 14:53-EDT From: Ken Harrenstien Subject: Re-transmitted message (or, why are you seeing this?) To: HEADER-PEOPLE at MIT-MC Some people have complained that without warning they are now seeing a dialogue about XMAILR which they are completely uninterested in. What really happened is that their names, being part of Postel's MTP interest group mailing list, were added to Header-People so that Dave Crocker could begin discussion of the latest RFC733 revisions. Unfortunately, his initial message was sent just before I tested the new list. In order to start over from the right place, I am re-sending that message. Apologies to those long-time Header-people members who have already seen it. ----- Date: 27 May 82 17:48:16-EDT (Thu) From: Dave Crocker To: Header-People at Mit-Mc Subject: Draft Revision to RFC #733 Greetings. As most of you are aware, ARPA has directed that RFC #733, "Standard for the Format of ARPA Network Text Messages" be modified, to meet the needs of the larger Internet context. By virtue of your membership in the Header-People mailing list, I would appreciate your reviewing a draft of the revised specification. We are under severe time pressures; if you can find it in your heart to provide me with feedback by the end of next week, I will be eternally grateful. The specification is the result of several meetings and considerable discussion. However, the document is still subject to change. Now is the time to voice your suggestions. The file is located at UDel-Relay. You can login through FTP with username anonymous, and any password. The name of the file is: /usa/dcrocker/733/new.ff If is fully formatted, indented and uses form-feeds. Underlines are handled by line overprinting (rather than character backspacing). The document is 46 paper pages, under 113K characters, and ends with the Table of Contents. Thanks. Dave  Date: 4 June 1982 21:39-EDT From: Jr. Mike McDevitt To: HEADER-PEOPLE at MIT-MC please add me to your mailing list. tks.  Date: 14 Jun 82 11:36:40-EDT (Mon) From: Dave Crocker To: Header-People at Mit-Mc Subject: 733 revision query Well, folks, some interesting comments have been coming in. While I have opinions about some suggestions, I would like to get your general reactions to them. The following is in no particular order. Please send your comments/votes directly to me, unless you think there should be more general discussion by the group. At-sign vs. Period There has been question about the continued use of '@', instead of just using periods. At the original discussion meetings, a couple of groups lobbied very strongly for the firewall that at-sign provides. They were concerned about being able to tell when to change parsing schemes. From field Some people are confused about what is legal in the From field. The new spec requires that the From field only contain addresses, rather than permitting general text (unusable as a machine address) if there is a Sender field. The reason for this is to simplify global field handling. Currently, you have to make a full pass through the header before you know whether to accept a From field which has random text in it. This way, the field is required always to have usable text. Thoughts?? Simplicity: Machine orientation Several votes have been cast for making the standard even more stringent, such as specifying exactly one acceptable form for an address, rather than permitting optional and alternative forms. This has been specifically requested for date/time format. If enough of you agree, and few enough complain, I will make the change of installing the subset format (taken from Postel's SMTP spec) as the ONLY permitted form. Another suggestion is that only '@' be used, discarding the " at " form of . Whadaya think? Some requests for more time zones have been made. Anyone feeling strongly about this should send me a complete list of the time-zone strings (and what they reference) that they want added. Another request is to do away with the line-folding convention. That is, do not coerce the text to fit within some arbitrary line size, unless the user does it explicitly. The suggestion comes, I feel, from having access to nicely modern systems. Unfortunately, a large segment of our user population is stuck with far more simplistic (dumb) systems. I strongly suggest we keep the current rigidity. (To give you some idea of the problem, a number of sites had trouble with the fact that the draft of this new spec had underlines and bare carriage-returns.) Groups & Comments The simplification of what constitutes an acceptable address, down to mailbox & group, seems to be generally acceptable to people. There is one suggestion for eliminating groups and another that SOME sort of extension mechanism be permitted. I think that there may be a compatible solution. The gist of the argument against group lists is that they do not have any defined action or semantics associated and hence are simply comments. Why not just count them as such? There is one case in which the group bracketing MIGHT have some special action; it was the original reason for including them in 733: If the group list contents are included with the message, then a display program could choose to display only the group name and not display the group's addresses. On the other hand, I have not seen anybody actually include the list contents and do not know of any system that selectively shows addresses versus group names. What I would like to propose is two sets of comments. The first is parenthetical text, as is currently used, which is handled as strictly throw-away, at all times. (This, of course, is a lie, given that some systems still put the person's name in a parenthetical string after the mailbox.) The second type would be treated by the official syntax as exactly the same as a parenthetical comment, however superset parsers would use it to signal to themselves that there is a private convention that is being invoked. I will tentatively suggest braces ( {} ) as the surrounding delimiters. Context-sensitive dots People seem to be having a lot of trouble with the fact that periods are lexical delimiters throughout the specification. They note that the spec REALLY cares only in the domain spec and does not care in local-part. My concern is that the lexical analyzer not be context sensitive, treating dot differently for the two syntactic situations. If somebody really wants to fight this point, then I suggest that they provide me with an alternative formal syntax. Content munging People generally despise the idea of having a relay go in and play with the headers. They believe that the sending system should make any and all necessary changes. Unfortunately, this is not really possible, without requiring that all the sending systems be rather sophisticated and always have fast access to large tables. The Arpanet history is such that I doubt we can demand this. Basically, our problem is that we have limited control over the programmers and organizations which compose the network. The more dramatic (traumatic) the change, the less conformance. Meta-Field names A suggestion was made that there be a meta-convention for user-defined fields, similar to Remail-*. I suggest that we define X-*. Thoughts? Dave  Date: 16 June 1982 14:50-EDT From: David A. Moon Subject: 733 revision query To: dcrocker at UDEL-RELAY cc: HEADER-PEOPLE at MIT-MC {} syntax extension. It isn't right to treat this as comments. The need is for a way to have a structured (more than one token) address, which can be passed through relays (including the special case of automatic reply-addressing mail readers) which don't understand the semantics, but do parse the structured syntax to the extent that they send the same characters back to the originating host (which does understand the semantics). Note that the host name, which everyone has to understand the semantics of, would be outside the brackets, where it can be seen without parsing anything inside the brackets. dots. I think the present treatment of dots is kludgey, confusing, and error-prone. It's really just a result of BNF limitations. Any implementation would be much better off treating a host address as a single token, and then splitting it at the dots once it has been identified (through the parsing process) as a host address. The alternative of following the BNF and splitting everything in the header at the dots, and then gluing back together everything that has been identified as not a host address, is more likely to cause problems, especially if this parser is going to be implemented 50 different times and mostly by people in a hurry. I would suggest changing the formal syntax not to include the dots as delimiters, but simply to leave host addresses as an atomic token, and provide an informal appendix specifying that a host address consists of 1 or more components with dots between them. header munging. I agree that host addresses have to be translated by mail relays; that's the only way that will work. It seems desirable to minimize the number of different kludgey formats, in order to make such translation less error-prone. I think groups should be eliminated; if for some reason it is necessary to find out the expansion of a mailing list, SMTP provides a way to do that. In the more advanced mail systems, the distinction between a user and a group is not even meaningful, since many users have their mail delivered pre-sorted and/or in multiple copies to short-term and long-term mailboxes. Certainly both "name " and "mailbox (name)" need not both exist; I'd rather see the former flushed since it complicates left-to-right parsing, but it is probably very much too deeply entrenched by now. date formats. Since the mail systems I have any contact with have long since learned either not to try to parse dates, or to understand literally dozens of different date formats, I don't care in a practical sense. Certainly it would be much cleaner to specify a standard date format, however it's not very important since simple mail systems will not do anything with the date anyway other than treat it as a character string to display to the user.  Date: Wednesday, 16 Jun 1982 12:05-PDT To: Dave Crocker Cc: Header-People at MIT-MC Subject: Re: 733 revision query In-reply-to: Your message of 14 Jun 82 11:36:40-EDT (Mon). From: phyl at RAND-UNIX Re: Another suggestion is that only '@' be used, discarding the " at " form of . Whadaya think? '@' don't work so good with interactive editors (sa MH's prompter), so long as it's the tty driver's line-kill. Phyllis  Date: 16 Jun 1982 16:45:27 EDT (Wednesday) From: Ken Pogran Subject: Re: 733 revision query In-Reply-to: Your message of 16 Jun 1982 12:05 PDT To: phyl at RAND-UNIX Cc: Dave Crocker , Header-People at MIT-MC Phyllis, You're missing the (perhaps subtle) point. At issue is what's to be allowed in the message headers transmitted between systems. There needn't be an exact correspondence between that and what a user types to his local mail-input program. More and more, mail-input programs are being written that help a user formulate the header of the message that he/she is typing in. Putting the at-sign in the proper place based on some other sort of input from the user is just one more example of the help that such a program can provide. Ken  Date: 16 Jun 1982 17:31:44-CDT From: solomon at uwisc To: header-people@mit-mc Subject: Re: 733 revision Concerning @ instead of "at": The only system I know of that uses @ as line-kill in the terminal driver is UNIX. Back in the ancient past, it was rather inconvenient to enter an @ sign (although to the best of my knowledge, it was always possible). For all versions distributed in the last five or six years, however, it has been possible to change the line kill character, and everybody I know of does so as a matter of course (usually to ^U or ^X). As a general principle, it's probably a mistake to hang on to an anachronism just because you suspect that somebody else might object if you remove it. If somebody really objects on his own behalf, let him speak now or forever hold his peace.  Date: 16 June 1982 20:13 edt From: Palter at MIT-MULTICS (Gary M. Palter) Subject: Re: 733 revision Sender: Palter.Multics at MIT-MULTICS To: Header-People at MIT-MC In-Reply-To: Message of 16 June 1982 18:31 edt from solomon As maintainer of the mail system on a machine where @ is still the line kill character, I vote for removing the " at " construct if it makes parsing simpler. (The parser in our mail system has no trouble with either form and, in fact, does handle multiple @s but...) Our users rarely have to actually type the at-sign. The command line syntax for addresses uses a keyword (-at) and users do not have to type addresses as they appear in the header. On the separate subject of {}, let me second Dave Moon's statement that they should not be considered to be comments but rather are a form of address whose internals are left to the sending (and perhaps receiving) site to understand. My mail system presently uses this format for some of the possible addresses we support and will be using it more in the future.  Date: 16 Jun 82 20:14:19-EDT (Wed) From: Dave Crocker To: Header-People at Mit-Mc Subject: 733' discussion transcript I have been collecting people's comments about the revised format proposal and will shortly be summarizing them. For those of you who are interested, they are available via FTP on the UDel-Relay machine, in the file /usa/dcrocker/733/notes in a batched file, with a line of 4 control-A's between messages. There just under 70 messages. Login anonymous and any password will permit you to read the file. Dave  Date: 17 Jun 1982 08:34:55-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: solomon at uwisc cc: header-people at mit-mc Subject: Re: 733 revision In-reply-to: Your message of 16 Jun 1982 1713-PDT (Wednesday). I do use @ as my line delete character, and even then, I PLEAD for the abolition of " at " as a synonym. I don't mind quoting the character to use it, and if I get tired of it, is will be just one more pressure to make me use something a little more standard (Unix not withstanding). Back in my Algol68 days, I can remember many discussions on how to avoid "bold blanks" in tokens. "Bold" characters are used in creating special words and when the grammar for Algol68 first appeared, there was no direct exclusion of blanks within bold character sequences! This clearly posed typographic problems! Finally, an add-on semantic rule simply outlawed them. The point is that the spaces around the " at " are in fact "bold" and cause a multitude of parsing problems in other places. I STRONGLY lobby that son-of-733 specify that an internet address consists a character sequence NOT containing any white space and NOT containing anything you don't want treated as an ADDRESS. I specifically mean "From: out behind the barn "!!! It is cute, but not that useful. Besides, as more of us have to do real intermailing between different message systems (as apposed to simply mail in the Internet), the fewer special characters we randomly interpret, the better off we will be. Who knows, there might be a mail system out there that specifies forwarding as foo@bar>crap If you ever want to talk to that, the currently allowed makes that very hard. I realized I am about to be ignited for heresy regarding non-ARPAnet things. ARPAnet myopia may have been reasonable in the past, but there are those of use who talked to other networks first and ARPAnet later. While it may be close to the centroid, ARPAnet is not the center of the universe and I am very concerned that our standards be capable of interoperating with other standards (who "standards efforts" care as much about us as we do about them!) with minimal grief. I am NOT advocating rushing out and adopting the NBS or X* recommendations; I think 733 is far superior in many ways. I am saying that my motivation for these comments comes from concern about the ever-increasing amount of bailing wire that must be constructed if I intend to talk to everyone I can and need to talk to. Sorry for the soapbox. -Mike  Date: 17 Jun 1982 1112-PDT From: Jon Solomon Subject: Re: 733 revision To: mo at LBL-UNIX cc: solomon at UWISC, header-people at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 17-Jun-82 0834-PDT Next you will be suggesting that we all have 7 digit user numbers instead of usernames so we can conform with most IBM systems. I think "From:User@Host" is ugly, certainly has no white space here, do you object to the space between the "From:" and the "User@Host"? (I'm being sarcastic) On a more serious note, As you can see by my header, I like to be somewhat verbose. I include my US Mail address and Commercial Telephone number in the off chance that someone will not be able to figure out how to reply to my message. This is also useful in the case where a message I send via computer mail finds its way onto some other medium, and the mechanism for replying to it is lost. I think it is reasonable to have my personal name in the From field, or in some other field, e.g. "Full-name:". In the future, although it is not specifically addressed in this new document, I would hope that intelligent mail parsers will be able to figure out my mail address without any dependencies on computers, e.g. why have a From: field contain anything but my name and place (e.g. From: Jon Solomon at The University Of Southern California, Engineering Computing Lab). This leaves method of delivery optional, I could get it in my postal address or in my computer mailbox. I think it is really awful to force computer technology down everybody's throat (theory: If you want computers, you have to live with credit card numbers and cryptic addressing schemes). Let Cobol Die! On with more modern languages and ideas. Cheers, --JSol -------  Date: 17 Jun 1982 16:59:30-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) Message-ID: <3990.10.393206366.LBL-Unix@LBL-Unix> To: JSol at USC-ECLC cc: solomon at UWISC, header-people at MIT-MC, mo at LBL-UNIX Subject: Re: 733 revision In-reply-to: Your message of 17 Jun 1982 1121-PDT (Thursday). As for lots of headers, I don't quarrel with you using them, but I have a private dislike for them. There are those who claim "your mail reader shouldn't show them to you if you don't want to see them." Well, how am I supposed to know what I am missing if it doesn't tell me about them? Moreover, I believe that if the author put them on there, they are important enough to examine, at least in passing. So, while I really don't enjoy getting messages with headers like: Lives-next-door-to: or Last-seen-with: I will defend your right to include them, and I will dutifully read them in case they ever say anything I really need to know. If someone has a mail reader which can reliably do thematic analysis of messages (including the headers!), let me know! -Mike  Date: 17 Jun 1982 17:00:46-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) Message-ID: <4052.10.393206439.LBL-Unix@LBL-Unix> To: JSol at USC-ECLC cc: solomon at UWISC, header-people at MIT-MC, mo at LBL-UNIX Subject: Re: 733 revision In-reply-to: Your message of 17 Jun 1982 1121-PDT (Thursday). I don't care about whitespace AROUND addresses, only whitespace WITHIN addresses. I consider ALWAYS having to comma-seperate addresses an intrusion (do you use commas in LISP?). But this is wildly picking nits. I am not advocating making a standard which is the lowest common denominator of everything else. That is clearly absurd. What I am lobbying against is making any more rules than necessary to do the job. This is an example of Occam's Razor. If we spell-out the syntax of an Internet address in 733, then we can't change it without having to know "oh yea, that part of 733 was upstaged later." When we complain about people's programs not doing the right thing, we should keep in mind just how hard it is to discover the current distributed opinion of what that is! The other issue is Internet versus internet. The first has the administrative luxury of decision by fiat. Some group or individual decides what to do and then everybody else within the Internet does it that way. The "internet", on the other hand, is a global beast consisting of many different networks, most of whom all have the notion they are the only network in the world, and their mail systems certainly don't admit the existance of any others! Again, I am not advocating the abrogation of any right-of-existance or compromising any creative or scientific progress. I am simply arguing that we should be aware of other worlds and not build any walls between them a priori. -Mike  Date: 17 June 1982 2231-EDT (Thursday) From: Craig Everhart at CMU-10A To: mo at LBL-UNIX (Mike O'Dell [system]) Subject: Re: 733 revision CC: JSol at USC-ECLC, Header-People at MIT-MC, solomon at UWisc Reply-To: Rdmail at CMU-10A In-Reply-To: <4052.10.393206439.LBL-Unix@LBL-Unix> Message-Id: <17Jun82 223141 RD00@CMU-10A> I think it enough of an intrusion that spaces within names are being decommisioned. When you try to build protocol-translating gateways (say, a mail forwarder between Internet and uucp), you're reduced to the common features of both protocols. And, too, it's well-understood that the translator has to understand what it's translating: it must understand each format and re-cast the content in the other format. That's the principal reason why protocol translation is so hard. Does that mean that those using only one protocol need to limit their usage to what would be acceptable under all protocols? As long as the bold spaces in `` at '' are representable in the uucp world by replacing the whole phrase with ``@'', I don't know what the problem is.  Date: 17 Jun 1982 22:54:08-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: smb.unc at UDel-Relay cc: header-people at mit-mc Subject: Re: 733 revision In-reply-to: Your message of 17 Jun 1982 2048-PDT (Thursday). I agree with you strongly on the importance of things like full names in headers. That is why I would like them elevated to "full" status. Making the parsing simpler would improve the likelyhood of a correct implementation, and possibly promote inclusion of such informative information in headers by making it easy to add. Currently, you can use a "Full-name:" line, of course, but tradition has it in the "From:" field. -Mike  Date: Friday, 18 Jun 1982 08:48-PDT To: mo at LBL-UNIX (Mike O'Dell [system]) Cc: JSol at USC-ECLC, solomon at UWISC, header-people at MIT-MC Subject: Re: 733 revision In-reply-to: Your message of 17 Jun 1982 16:59:30-PDT. <3990.10.393206366.LBL-Unix@LBL-Unix> From: obrien at RAND-UNIX We do. Our MH lister (one of several possible options for showing messages) parses headers according to a user-specified format. It puts all the ones you specify where you specify (so you can make it look like a business letter if you like, with the date at top right), and throws all the rest down at the bottom of the message, after the body. My only objection is that it takes awhile to parse the header. I therefore don't use it because it's too slow for me.  Date: 18 Jun 1982 1852-PDT From: Mark Crispin Subject: " at " vs. "@" Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) If I was implementing a mailsystem, I would vote for removing " at ". Now, I really don't care, but I definitely DO like the idea of forever laying to rest headers like To: Frodo at BAG-END, Bilbo at BAG-END where newlines are placed in the middle of addresses. This is terribly difficult for a parser which tries to parse the header as is without the benefit of a preprocessor to implode away continuation lines. Come to think of it, are continuation lines flushed? If not, why not? Would people find multiple To-lines harder to parser than a continued To-line? Consider that to be right you really do have to allow multiple To-lines, since some mailsystems do generate them. I guess since network addresses are published with @ by the NIC, maybe for consistance we should remove " at ". It does make parsing easier. If we want to make parsing yet easier, how about making all non-address entities go away from parsed headers like From, To, etc. In other words, instead of From: Mark Crispin have From: Admin.MRC@SU-SCORE Personal-Name: Mark Crispin or some other such thing. We could have a sanctioned list of various "human" header items. Of course, doing this will remove pretty much all of the richness of RFC 733 so that we may end up with a 5 page document! -- Mark -- -------  Date: 18 Jun 1982 2007-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: " at " vs. "@" To: Header-People at MIT-MC, Admin.MRC at SU-SCORE The hell with making things easier for the parsers! The computers are there to serve us, not the other way around (and I have implemented a parser, so I know how difficult, or not, it is). -Rich -------  Date: 18 Jun 1982 21:42:35-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: obrien at RAND-UNIX cc: JSol at USC-ECLC, solomon at UWISC, header-people at MIT-MC Subject: Re: 733 revision In-reply-to: Your message of 18 Jun 1982 0908-PDT (Friday). Mike, By "user-defined" do you mean I can specify pattern expressions that pick header lines based on content, or some other thing? The real issue is that I still have to a priori decide how to tell something interesting from something that isn't. The part that makes sense, however, is placing the "reject" header lines down at the bottom. That way, they are there to see, just unobtrusive. -Mike  Date: 18-Jun-82 21:51-PDT From: KELLEY at OFFICE Subject: Parsing RFC 733 To: Header-People at mit-mc Identifier: OAD-KIRK-11601 Length: 1 page(s)[estimate] Posted: 18-Jun-82 21:49-PDT As one who recently finished implementing an RFC 733 parser (to convert to the Augment Mail system), I'd just like to say we found it doable, but non-trivial. Some complexity was due to distinguishing Arpanet addresses from intermixed Augment addresses. I am somewhat chagrined to see this debate about changing the very things that I spent so much time accommodating. Some random thoughts: 1) The converter would run a little faster if it did not have to look for " at " and the code would be somewhat cleaner. I wouldn't mind re-writing that code. Right now, all " at "s get converted to atsign anyway so Augment users never see " at ". Furthermore, we automatically generate no " at "s in mail going out to the Arpanet (though a user can make it happen). 2) The parser assumes there will be no in the host part. 3) The multi-line field problems are solved quite elegantly by a recursive descent parser. I threw out my recursive version, however, and gathered fields in a loop because, under time pressure, I was too lazy to add dynamic string allocation necessary to avoid a potential procedure stack overflow. 4) We assume a field continuation of a multi-line field does NOT terminate an address. -- kirk  Date: 18 Jun 82 22:01-PDT From: mclure at SRI-UNIX To: header-people at mit-mc Subject: annoying headers without To field I find message headers like the following very annoying. The text asks a question of an unamed person, and there's no way of telling if the message was directed to me, a list, or whomever. The via field (appended by our mail daemon) would seem to imply that it is a MIT mailing list of some sort. Is there some reason why the Berkeley folks allow headers like this one to get out from UUCPnet onto the Arpanet? Date: Fri Jun 18 17:17:03 1982 From: decvax!duke!alr at Berkeley Via: Mit-Mc.ArpaNet; 18 Jun 82 21:59-PDT I have been told that I might be able to get an evaluation by you of the Mince screen editor for the IBM pc. My main interest is in an editor that can handle large (>60K) text files, do all the necessary buffering, etc, and, perhaps even allow editing of multiple files. I currently use vi on UNIX, and it's ok; I found IBM's spf even better when I was there. I'd really appreciate any info you're willing to share. Arny Rosenberg Duke University Computer Science duke!alr  Date: 19 June 1982 03:00 edt From: Schauble.Multics at MIT-MULTICS Subject: David Moon's comments on dates To: Header-People at MIT-MC I agree with his comments about standard date formats. But, I think that rather than giving up, this all the more reason to establish a standard date format. I have an on-line copy of a paper written by one of the Honeywell people that is a survey of international standards on date formats. I ti is too long to distribute as a message. Will someone please tell me where to put it so that those interested can get it via FTP?  Date: 18 Jun 1982 2327-PDT From: Richard Furuta Subject: [decvax!utzoo!utcsrgv!utcsstat!antoni at Berkeley:] To: header-people at MIT-MC cc: furuta at WASHINGTON, mcclure at SRI-UNIX I second the annoyance over lack of To: fields in Berkeley's mail. Coincidentally, the following message arrived just before McClure's. At least the one McClure got was intelligible! --Rick --------------- Mail-from: ARPANET site MIT-MC rcvd at 18-Jun-82 2248-PDT Date: Fri Jun 18 08:26:04 1982 From: decvax!utzoo!utcsrgv!utcsstat!antoni at Berkeley How much is a BLIT & where do you get them? Thanks. Lou. -------  Date: 19 Jun 1982 07:40:31-CDT From: solomon at uwisc To: header-people@mit-mc Subject: Mailing lists I sent a comment to the list, somebody replied with an automatic reply feature of a mailer that added me to the cc list, and now everyone is continuing the discussion using reply commands that keep me in the cc list. At least that's what I suspect happened. The result is that I'm getting two copies of everything: one addressed to header-people and one addressed to me personally. Please take me off the cc list.  Date: 19 Jun 1982 08:55:59-CDT From: solomon at uwisc To: header-people@mit-mc Subject: Messages to mclure without To fields Those messages to mclure look to me like they came from USENET. For those of you who don't know, USENET is a sort of distibuted billboard system that runs on top of the uucp "network". The latter is a very large (perhaps as many as 1000-host) collection of UNIX sites that exchange mail over dial-up telephone connections. To join the "network" all you have to do is arrange to poll or be polled by some other uucp member. The programs for uucp are distributed with UNIX. All routing is by manually supplied source-route: an "address" has the form "site1!site2!...!siten!username", where "site1" is a site you connect to directly, etc., and "username" is a mailbox on "siten". (This syntax is considerably complicated by local nets and interfacing to ARPAnet.) USENET sits on top of uucp. Articles, classified by "newsgroup" are distributed by a hot-potato algorithm: each site sends copies to all neighbors that run USENET. Each article carries a unique id (originating-host.serial-number) to detect duplicates and break loops. Some mailing lists are relayed from ARPAnet to USENET by various hosts. The point of this rather long-winded discussion is that USENET has a "reply" command that allows the user to send a message back to the originator of the message. For some reason I don't completely understand, there seem to have been many items in USENET recently that have "mclure" somewhere in the "From" field and then say somewhere in the body that they are really from somebody else. I suspect that people are replying, carelessly forgetting to specify who they are really talking to, and using a mailer that doesn't supply a To field. The reply feature of USENET uses whatever mailer is lying around and some of the mailers used at UNIX sites (but not the Berkeley mailer) neglect to add a To field. "To:" is not required by 733, but perhaps it should be. The To field should be supplied by the originator, not the forwarder. However, given that some mailers forget to supply it, perhaps Berkeley should add it to messages it relays. (In uucp, like SMTP, the To field is merely for comment; the real destination address is sent separately). Marvin Solomon solomon@uwisc  Date: 19 Jun 82 11:21:03 EDT (Sat) From: Steve Bellovin Subject: "To" fields To: Furuta at Washington, mcclure at Sri-Unix Cc: HEADER-PEOPLE at Mit-Mc Via: UNC; 19 Jun 82 13:03-EDT I share your annoyance at letters without a "Subject" or "To" line; however, the current standard explicitly permits this. Perhaps it shouldn't?  Date: 19 Jun 1982 1041-PDT From: Jon Solomon Subject: Re: Messages to mclure without To fields To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 19-Jun-82 0655-PDT I also received the messages mclure sent to us, indicating some form of mailing list at MIT in use. MIT is not the only place which supports mailing lists but they have the largest number of them. When I stopped digestifying WorkS, all the USENET messages which apppeared without TO fields and everyone was up in arms about it. The technical issue was that RFC733 did not require the TO field, the political one was that people had a tough time figuring out what the message was about. I think it would be technically difficult for Berkeley to construct a TO field if all it has is one of the recipients, however that is more than sufficient. I believe that uucp's next generation of mailers will try to conform to RFC733 standard, including addressing (Mark Horton will have to comment on this) and hopefully include at least what is absolutely required to make the message valid. I wish to lobby for a TO field in the required list of headers. Jon Solomon p.s. I like the header the way I use it, I think it is much nicer than "JSOL at USC-ECLC (Jon Solomon)". I think that I am more important than my mailbox and that I should get top billing. This is clearly a religious issue of the calibre of the UNIX vs VMS debate which moved from mailing list to mailing list like a hot potato until everybody stopped flameing about it, nothing was gained from this except to formally define the two sides. I hardly think RFC733 should deal with religious issues, only those technical and administrative issues which everyone agrees on. -------  Date: 19 Jun 1982 1106-PDT Sender: CERF at USC-ISI Subject: Re: David Moon's comments on dates From: CERF at USC-ISI To: Schauble.Multics at MIT-MULTICS Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]19-Jun-82 11:06:57.CERF> In-Reply-To: Your message of 19 June 1982 03:00 edt SUGGEST THAT THE NETWORK INFO CENTER COULD BE THE REPOSITORY FOR FILES TO BE FTP'D FOR GENERAL CONSUMPTION - THIS REGARDING YOUR PAPER ON INTERNATIONAL DATE STANDARDS. VINT CERF FEINLER@SRI-NIC IS A POINT OF CONTACT AT THE NIC.  Date: 19-Jun-82 13:43:13-EDT (Sat) From: mark@Berkeley (Mark Horton) Subject: Re: 733 revision Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 13:43:13-EDT (Sat) To: mo@LBL-UNIX, smb.unc@UDel-Relay Cc: header-people@mit-mc I agree that full names need more attention. The current variety os schemes to represent them is a real nightmare for a poor program to deal with. Life would be so much simpler if the From line just had a mailing address that would get back to the sender. I would prefer to see Full-name: on a separate line too. There are so many pieces of software that have to reply to a message, and all these forms: From: user@host From: user at host From: user@host (Joe Blow) From: Joe Blow don't add anything useful, they just make life more complex. This pretty radical, but the spirit of 733 could be upheld and life made much simpler if we just used From: Joe Blow Sender: user@host Reply-to: jblow@otherhost where From was just a human-readable field. Then each field has exactly one meaning, and software doesn't have to play the pea-under-the-shells game. The problem is that From suddenly changes meaning dramatically, so we could rename some fields and be much more upward-compatible: From: user@host Full-name: Joe Blow Reply-to: jblow@otherhost and just get rid of Sender completely. The problem with this is that the standard allows (...) commenst in To and Cc lines also. This feature seems little used (I've seen one message once that ever used it) and I am less concerned about To and Cc lines because simple programs that send a message back to the sender don't have to worry about them. But, please, can we simplify the From line? Mark  Date: 19 June 1982 1657-EDT (Saturday) From: Craig Everhart at CMU-10A To: Admin.MRC at SU-SCORE, mark at UCB-C70 (Mark Horton) Subject: Re: " at " vs. "@" and 733 revision CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: Mark Crispin\@SU-SCORE's message of 18 Jun 82 20:52-EST, mark\@Berkeley's message of 19 Jun 82 12:43-EST Message-Id: <19Jun82 165722 RD00@CMU-10A> I agree with Zellich. Allow `` at '' and comments in name lists and <> forms. Writing parsers just isn't that hard. It might have been a little tricky with the special :INCLUDE: and :POSTAL: atoms; but with the reduced syntax, life is just not that complicated. Let the computer work for the user, not the other way around.  Date: 19-Jun-82 14:11:42-EDT (Sat) From: mark@Berkeley (Mark Horton) Subject: Re: " at " vs. "@" Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 14:11:42-EDT (Sat) To: Admin.MRC@SU-SCORE, Header-People@MIT-MC, Zellich@OFFICE-3 From Zellich@OFFICE-3 Sat Jun 19 06:23:36 1982 Date: 18 Jun 1982 2007-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: " at " vs. "@" Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 06:23:35-EDT (Sat) Mail-From: office-3 received by cbosgd at 19-Jun-82 06:23:34-EDT (Sat) To: Header-People at MIT-MC, Admin.MRC at SU-SCORE The hell with making things easier for the parsers! The computers are there to serve us, not the other way around (and I have implemented a parser, so I know how difficult, or not, it is). -Rich ------- OK, so we don't have to make things easier for the computers. But it still might be nice to make things easier for the poor person who has to \program the computers/! The old axiom "Woe be unto he who maintains the mail program" is well known to everyone on this list. We'd all like to make our own lives as simple as possible. Mark  Date: 19 Jun 1982 1324-PDT From: Stef Subject: Re: 733 revision To: header-people at MIT-MC In-Reply-To: Your message of 19-Jun-82 1043-PDT There is a fundamental problem with the fact that in some cases, FROM and SENDER are different people, and REPLY-TO is yet a third party. Also, I see real needs to attach "comment" information to any address in any field, to be interpreted by the receivers, individually, and each in their own context. I think (personally) that this comment information is best attached with the "address (comment)" format than the "comment
" format. If we must reduce formats to only one, I vote for "()". As for dates, I sure wish there would come to be a way to consistently sort on all date fields, which strongly suggests that a standard date format be established. I certainly vote for adoption of something reasonable to replace the current anarchy. Best - Stef -------  Date: 19 June 1982 20:20 edt From: Palter at MIT-MULTICS (Gary M. Palter) Subject: Re: 733 revision Sender: Palter.Multics at MIT-MULTICS To: Header-People at MIT-MC In-Reply-To: Message of 19 June 1982 16:24 edt from Stef Stef is correct. However, I would vote for the "comment
" syntax. As RFC733 currently stands, anything within parentheses is considered equivalent to whitespace and it is, therefore, acceptable for a mail reading program to throw it away. The first format, however, is actually a named address where the name is important and should be remembered.  Date: 19 Jun 82 17:48-PDT From: mclure at SRI-UNIX To: header-people at mit-mc Subject: annoying addresses without To fields Several people have replied that RFC733 allows headers without To fields. Could one of the RFC733 authors explain what the reason for that was?  Date: 19 June 1982 2123-EDT (Saturday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Re: " at " vs. "@" CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: mark\@Berkeley's message of 19 Jun 82 13:11-EST Message-Id: <19Jun82 212332 RD00@CMU-10A> Nobody has ever quoted that `axiom' to me, and I see no reason for its existence. All it says is that people rely on how their mail system works. We knew that already. Craig Everhart, CMU RdMail maintainer  Date: 19 Jun 1982 1845-PDT From: Jon Solomon Subject: Re: " at " vs. "@" To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 19-Jun-82 1111-PDT I don't believe in your axiom ("Woe be unto he who maintains the mail program"). I maintain a whole lot of mail programs, mailers, and even get my hands dirty fixing ARPANET wide mail loops (including multi-net loops in this), and I hardly consider myself overworked by it. My opinion on the subject of making things easier for the "poor person who has to program the computer" is that it would probably be a small amount more work to implement a more intelligent parser and the benefits of having such a parser (especially when you consider receiving random mail which doesn't conform to RFC733 or Son-Of-...), especially when it can parse the non-trivial cases the headers, are boundless. So far this discussion has taken two distinct paths, so I declare this discussion religious based: One side wants the most features and the most extensibility (re: User-defined headers), because (they claim) the computer age is upon us and computers can do almost everything, especially something as (seemingly) trivial as parsing mail headers. After all (some say), computers are there to remove mundane tasks from those who use them. The other side wants the simplest and most straightforward scheme so that their computer programs need not be modified to handle the expensive cost, however virtual or actual these costs are (cpu power may be a financial restriction, addressing space is a physical restriction, programming time is a virtual restriction). I doubt very much if we wish to decide the fate of religion in RFC733, but we do want to make the best quality system (perhaps not the fanciest, but certainly the most reliable), with the fewest effort on all our parts. For this reason, I believe, arguing over what to restrict from RFC733 is a moot topic. Most if not all ARPANET systems already have programs written to handle the difficult parsing algorithm already stated forth in RFC733, anything WE (=> arpanauts) have to change should be enhancement, not restriction. In most cases, non-arpanet systems can benefit from the wealth of programs and systems available on the ARPANET either as an example of how to do it, or as an actual program (I'm referring to the case of uucp). In the special case of :INCLUDE:, CMU seems to use it heavily, I wonder how difficult it would be to have that conform to the standard List-name: Foo, Bar, Baz ; convention for group naming? I could be totally missing the point here, but the general idea is can we come up with a mechanism so they can have their way while not forcing the parsers to handle a million of different parsing schemes. Since I am one of those who \program the computers/, let me point out that it is not that difficult to program a parser, I may not have done one from scratch before, but I have looked at others and copied, which in some sense is cheating (I did read several different kinds of programs to get a general view of parsers and I did contact people who were knowledgeable about them, so I did not completely cheat). Even so it took me a total of 2 hours to write a parser equivalent to MM's mailbox address parser, hardly a herculean task (actually, 2 hours is a bit long)! I don't think this kind of flameing will get us anywhere. I would like to hear if the present mailbox addressing scheme is impossible to implement on your specific machine. Send these replies to me and I will summarize them and present them in a future message. Please be specific, if you can't have @ signs because of some constraint such as your terminal driver throws them away, and changing the driver so that you get the @signs means breaking the whole system (or is completely nontrivial in your implementation), I want to know all the gory details. Be prepared for some comments and questions on my part, I'm really skeptical as to whether or not it is actually impossible. Cheers, --JSol (a.k.a. Jon Solomon) -------  Date: Saturday, 19 Jun 1982 20:42-PDT To: mclure at SRI-UNIX Cc: header-people at MIT-MC Subject: Re: annoying headers without To field In-reply-to: Your message of 18 Jun 82 22:01-PDT. From: greep at RAND-UNIX You could have your server FTP program tell you (eg by adding a "mail-from:" line to the message) who the message was sent to, i.e. the argument of the MAIL/MLFL command. I added this to our system and have found it very useful. This is not to disagree with your complaint about the lack of a "to:" field.  Date: 20 Jun 82 1:50:50-EDT (Sun) From: Dave Crocker To: Header-People at Mit-Mc Subject: "To:" optional To answer McClure's query about the reason for making the "To:" field option, in RFC733: If I remember correctly, we were trying to require as little as possible. There were cases of anonymous or list (group distribution) mail where people might not want to show the name or contents of the address list. Personally, I do not have a strong feeling for or against requiring it. But I do think that it is worth noting that its absence causes hassles fairly consitently. Anyone care to argue AGAINST requiring the "To:" field? Unless there is a solid case made for maintaining it as an option, rather than requiring it, I think it would be best to make it required, in the new specification. Dave  Date: 20 Jun 82 10:12:39-EDT (Sun) From: Dave Crocker To: Header-People at Mit-Mc Subject: Date/Time paper A copy of the mentioned paper on Date & Time is stashed as UDel-Relay, in the file /usa/dcrocker/733/date.time and can be retrieved via FTP, using login username of anonymous and any password. Dave  Date: 20-Jun-82 19:09:49-EDT (Sun) From: mark@Berkeley (Mark Horton) Subject: Re: 733 revision Via: cbosgd.uucp (V3.94 [3/6/82]); 20-Jun-82 19:09:51-EDT (Sun) To: header-people@mit-mc@Berkeley There is a fundamental problem with the fact that in some cases, FROM and SENDER are different people, and REPLY-TO is yet a third party. I can see where a person might be visiting and have someone else send the mail for them, but does anyone have a real example that really happens where three electronic addresses that do not appear in the To or Cc lists are involved? I always see Reply-To used to indicate that a person has logged in on some machine other than his home machine, and wants his replies sent elsewhere. Is there another legitimate use? There are a number of simple utilities that need to generate replies to the senders of messages. This occurs not only with mail, but with other software that adopts RFC 733 as a standard format, such as netnews. Such a program might only be a few dozen lines long, and forcing it to contain an entire parser for ()'s and <>'s and continuation lines just to extract the From line seems unnecessary. While I would prefer to have the full name of the sender in a separate field, such as Full-Name:, I could live with a format that looks like From: user@host.net (Full Name) that is, the From line is restricted to one line (no continutations) and the only comment is in parentheses at the end. A simple program could view '(' as a comment-to-the-end-of-the-line character. This restriction would apply to the From: line only - I don't care what's on the To or Cc lines. Does anyone have a problem with this restriction? Mark  Date: Saturday, 19 Jun 1982 23:56-PDT To: Header-people at MIT-MC Subject: Parsers for mail headers From: greep at RAND-UNIX In writing a header parser I found one of the headaches to be making sure that I understood the spec correctly and handled all the weird cases. In short, the problem of converting the spec into an algorithm was much more of a task than converting the algorithm into a program. So how about having the revised spec include an algorithm? Then there can be no question about how a particular case is to be handled. This would require that the algorithm be generated only once, leaving us implementors with the more straightforward, and less risky, job of programming it for our particular systems and integrating it with the rest of the mail system. This procedure would also aid in standarization. I imagine DCrocker can think of some language to write an algorithm in that is sufficiently rigorous as to be unambiguous, while being at a high-enough level to be easily readable. (I would also like to see this sort of thing done for FTP reply codes and the like, but that doesn't belong on this mailing list.)  Date: 20 Jun 1982 2332-CDT From: ZELLICH at OFFICE-3 Subject: Using 3 separate addresses; Long From fields To: Header-People at MIT-MC In-Reply-To: The message from Mark Horton 20-Jun-82 19:09:49-EDT (Sun) Message-ID: <20-Jun-82 23:29:44-CDT ZELLICH at OFFICE-3> Yes, we have cases where all 3 fields (Sender, From, and Reply-To) will be used with 3 separate addresses. More common though, and due to the rule that if From is present that address(es) gets the reply, is the case where the secretary sends the messages for his/her boss and the replies are supposed to go to the secretary: Sender is the secretary's address, From is the boss's address, and because the replies aren't to go to the boss's mailbox, Reply-To must be put in with the secretary's mailbox again. A From field can't be restricted to one line because there may be multiple addresses in the field. Even without verbose address forms without full names, the field can still exceed a line (I wonder how many mailers properly handle this case in a Reply). Cheers, Rich  Date: 21 June 1982 0108-EDT (Monday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Re: 733 revision CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: mark\@Berkeley's message of 20 Jun 82 18:09-EST Message-Id: <21Jun82 010827 RD00@CMU-10A> I generated a piece of mail with three independent name lists about a month ago; the mail was From someone without a mailbox, its Sender was me, and replies were to go to a third person (who was also on the To list) because I was leaving town for a few days and the third person was handling the arrangements for the mailbox-less person. I'd also like to cast a vote against the rigid-format From line. Shouldn't there be a namelist-parsing package that all such tiny programs can use on a given system? Craig  Date: 21 June 1982 0108-EDT (Monday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Re: 733 revision CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: mark\@Berkeley's message of 20 Jun 82 18:09-EST Message-Id: <21Jun82 010827 RD00@CMU-10A> I generated a piece of mail with three independent name lists about a month ago; the mail was From someone without a mailbox, its Sender was me, and replies were to go to a third person (who was also on the To list) because I was leaving town for a few days and the third person was handling the arrangements for the mailbox-less person. I'd also like to cast a vote against the rigid-format From line. Shouldn't there be a namelist-parsing package that all such tiny programs can use on a given system? Craig  Date: 21 June 1982 0108-EDT (Monday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Re: 733 revision CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: mark\@Berkeley's message of 20 Jun 82 18:09-EST Message-Id: <21Jun82 010827 RD00@CMU-10A> I generated a piece of mail with three independent name lists about a month ago; the mail was From someone without a mailbox, its Sender was me, and replies were to go to a third person (who was also on the To list) because I was leaving town for a few days and the third person was handling the arrangements for the mailbox-less person. I'd also like to cast a vote against the rigid-format From line. Shouldn't there be a namelist-parsing package that all such tiny programs can use on a given system? Craig  Date: 21 June 1982 0108-EDT (Monday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Re: 733 revision CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: mark\@Berkeley's message of 20 Jun 82 18:09-EST Message-Id: <21Jun82 010827 RD00@CMU-10A> I generated a piece of mail with three independent name lists about a month ago; the mail was From someone without a mailbox, its Sender was me, and replies were to go to a third person (who was also on the To list) because I was leaving town for a few days and the third person was handling the arrangements for the mailbox-less person. I'd also like to cast a vote against the rigid-format From line. Shouldn't there be a namelist-parsing package that all such tiny programs can use on a given system? Craig  Date: 21 Jun 82 14:23:45 EDT (Mon) From: Steve Bellovin Subject: Re: "To:" optional To: Header-People at Mit-Mc In-Reply-To: Dave Crocker 's message of 20 Jun 82 1:50:50-EDT (Sun) Via: UNC; 21 Jun 82 18:46-EDT I've seen two cases where RFC733-compatible have mailers generated letters without "To" fields. The first is a private mailing -- I can persuade this mailer to put all addressees in the "bcc" line, with nothing in the "To" line. Clearly, one could always generate "To: (private)" in such a situation, but this is rarely done. A second situation is in the copy of a letter sent to "bcc" recipients; in this case, the field-name can be modified to prevent inadvertent replies to the publicly-named original recipients. It isn't clear to me what should be required under these circumstances. In any event, if the standard is changed to require a "To" line, I'd suggest having it require one of "To", "Cc", or "bcc" -- *something* to show that the mailer considered the problem. An SMTP-like processor could be permitted to add a "To" line when handed a letter with no destination headers, though I'd hesitate to require such. Perhaps a different header should be picked, something like "Apparently-To"? --Steve Bellovin  Date: 21 Jun 82 16:47:41 EDT (Mon) From: Steve Bellovin Subject: rfc733 -- simplified syntax To: header-people at Mit-Mc Via: UNC; 21 Jun 82 18:46-EDT Several different people have requested a simplified syntax of some sort for address lists. I agree in spirit, but I'm not enthralled with many of the specific suggestions. So I've compiled a few of my own... True names: I favor 'name '; stuff in parentheses is equivalent to white space, and harder to preserve across header-transforming code. What should a program do with a (legal) string like this? (I'm) Joe (the great) at (the lovely) Host (north campus) I prefer keeping the human-name as part of the address syntax; some folks might want to include such in "To" fields, especially when starting a discussion among people who may not know each other. Nor do I feel that this syntax is any more trouble for a simplified parser, as Mark Horton suggested; one simply checks for the presence of a '<', and ignores everything before it. 'at' vs. '@' Not a problem for anything even slightly complex; if the parser has any sort of lexical level, the distinction can be hidden there. The major place this is troublesome is for very simple- minded programs that just want to compare one address with another; even these need some sort of lexical level to deal with comments. Quoting and nesting In my opinion, the *real* villains -- most parsers, even the moderately complex ones, don't handle nested comments or symbols quoted via '\'. Named lists (especially in the new syntax, where they may not be nested, and hence can't be handled by a simple recursion) are likely to prove troublesome; the parser has to maintain a extra piece of global state; also, the inclusion of commas in address lists (for routing info) will break the simpler parsers. A goal, I think, should be to devise a syntax that can be interpreted by the sophisticated parsers, but treated atomically by simpler ones. Thus, "{....}" is better than the old ":Include: string", because it's easier to ignore; all the program has know how to do is treat "{....}" as an atom. Named address lists A real waste of effort.. .. They're not that hard to ignore (if you see a ':', flush the buffer; also, ignore ';' or treat as equivalent to ','), but they are troublesome to do anything useful with. If the list contents are shown, the mailer must be prepared to handle a structured address list; if they aren't shown, the name is really equivalent to an alias expansion that's syntactically different from a regular mailbox name. (I can't send mail to 'header-people:; @mit-mc', for example.) Nor does the mail-composer necessarily know which addressees are real users, and which are aliases; trying to make that change in the delivery layer is messier than appending a domain name. And how do I reply to such a list? In summary -- use 'name ' as the basic syntax, though a simple 'user@host' should be accepted. Treat all bracketed pairs ("(...)", "[...]", "{...}", maybe even "<...>") as atoms at some level, but do not allow (or strongly discourage) nesting; quoted characters inside such constructs should likewise be prohibited. As much as possible, '@' and ',' should be treated as firewalls -- always break on them, and don't try to figure out their context. And -- for the benefit of all those little programs Mark Horton mentioned -- provide library routines on every system to do all this parsing.... --Steve  Date: 21 Jun 82 19:29:58-EDT (Mon) From: Dave Crocker To: Header-People at Mit-Ai Subject: [To]: Steve Bellovin points up an issue that I would like to make sure is not missed: I modified a Unix version of the sndmsg program (called 'send') so that Bcc recipients received messages which did not have ANY To or CC fields. This was to subvert receivers' Reply commands. The supposition is that a Bcc recipient usually should not send a reply to other (public) recipients of the message. As a consideration, I include the public To and CC fields, with the field names bracketed. Therefore, users can see the contents, but the Reply commands do not. This seems to be a very useful feature. Requiring a To field would subvert its intent. Dave  Date: 21-Jun-82 23:08:17-EDT (Mon) From: mark@Berkeley (Mark Horton) Subject: sender, from, and reply-to Via: cbosgd.uucp (V3.94 [3/6/82]); 21-Jun-82 23:08:19-EDT (Mon) To: header-people@mit-mc@Berkeley I hope you guys aren't getting tired of this... I asked for examples of the use of all 3 electronic addresses, and the replies have shown two examples, each of which had an electronic address for the sender an electronic address to send replies to a non-electronic address telling who the mail was sent for. These examples are both handled by what I proposed earlier. What I was asking is if anyone has a situation where three ELECTRONIC addresses are really needed for Sender, From, and Reply-To. Putting it another way, what other needs are there besides (1) send to the sender, (2) send to the reply-to, (3) send to the reply-to plus some combination of To, Cc, and Bcc? I think the idea of specifying algorithms is a big win, although I'm not sure what the set of algorithms needed is. But I would prefer a standard that is so simple and unambiguous that the algorithms are all trivial and obvious. The current variety of (different) implementations of reply algorithms shows that RFC 733 is not this simple. Mark  Date: 21 Jun 1982 2133-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: sender, from, and reply-to To: Header-People at MIT-MC Not really true that Sender and Reply-To are purely electronic addresses, and the From is purely a human-name...in our environment, where office symbols are frequently used for addresses "DRXAL-FD at OFFICE-3", etc., and mailboxes are shared by multiple people in an organization, it is common (both for courtesy and for authentication and record-keeping) to incude both the human name and the electronic address in any address field. There are also overriding considerations when you want to force a reply to the From person, instead of following the Reply-To request, so you need the electronic address there as well as human name. There are a helluva lot of combinations, and considering that we're starting to build message systems for use during the next 10 years, I'd like to see as much diversity and flexibility as possible allowed. We'll only have to program the parsers once (theoretically...), but we'll be using them for 10 years; that argues for putting up with a complex task up front to keep from tacking on bits and pieces of improvements forever or just doing without them. Cheers, Rich -------  Date: 21 Jun 1982 2210-PDT From: Jon Solomon Subject: Re: [To]: To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 21-Jun-82 1629-PDT Dave, I agree with what you are saying, but we might consider defining both a "To:" and a [To]: field and similar for "cc:" and "[CC]:" requiring one or both. At the very least I want to know why I am getting a message, perhaps a better choice would be to have this information placed in a new "Mail-To:" line? E.g. Mail-From: .... Mail-To: ARPA-MAILING-LIST@MIT-MC by the program which initially receives or sends the message? Subsequent forwarding routers could check to be sure this information exists and puts it in if it is lacking. This is just to answer the question "why did I get this random message"! Just an idea, --Jsol -------  Date: 21 June 1982 22:21-PDT (Monday) From: David Eppstein To: mark at Berkeley (Mark Horton) Cc: Header-People at MIT-MC Subject: sender, from, and reply-to Recently my account went away temporarily, and the mail I sent about the problem had 3 electronic addresses: from my full name and computer address here, sender the friend whose account I used to send the mail, and reply-to an alternate net address. I think this is a true example of three electronic addresses in one message.  Date: 21 June 1982 22:21-PDT (Monday) From: David Eppstein To: mark at Berkeley (Mark Horton) Cc: Header-People at MIT-MC Subject: sender, from, and reply-to Recently my account went away temporarily, and the mail I sent about the problem had 3 electronic addresses: from my full name and computer address here, sender the friend whose account I used to send the mail, and reply-to an alternate net address. I think this is a true example of three electronic addresses in one message.  Date: 21 June 1982 22:21-PDT (Monday) From: David Eppstein To: mark at Berkeley (Mark Horton) Cc: Header-People at MIT-MC Subject: sender, from, and reply-to Recently my account went away temporarily, and the mail I sent about the problem had 3 electronic addresses: from my full name and computer address here, sender the friend whose account I used to send the mail, and reply-to an alternate net address. I think this is a true example of three electronic addresses in one message.  Date: 21 Jun 1982 2228-PDT From: Jon Solomon Subject: Re: sender, from, and reply-to To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 21-Jun-82 2008-PDT [This may seem a bit extreme for purely ARPANET mail, but in WorldNet (which is closer than you may think), this is a real issue.] I, Joe, tell my secretary Mary to write a message to you. Mary, who doesn't have access to the computer mail facility at USC, writes the message to be sent in a memo to Jim, the computer center clerk responsible for this. Jim creates a special mailbox called MARY at USC-ECLC which is in reality a file in Jim's directory (we can do this now), or a subdirectory of him in the mail forwarding database (granted this is a bit esoteric, I'm really thinking of a more general idea which includes something known to US Mail users as "General Delivery"), so when replies come to it, he can stuff them into Mary's Campus mailbox. The headers look like this: From: JOE at USC-ECLC Sender: JIM at USC-ECLC Reply-to: MARY at USC-ECLC To: Mark at Berkeley You get the message in your mailbox, you reply to it, the headers for the reply look like this: From: Mark at Berkeley To: Mary at USC-ECLC In-reply-to: JOE's message of 14-JUN-82 02:34:00-PDT Indeed, the from field specifies the owner of the message, i.e. it is JOE's message. Mary get's the replies in her mailbox, because Jim is stuffing them into envelopes. I know this is a bit esoteric, and if I spent enough time thinking about it I could come up with a better one, but it does show a potential use for having both a To field, a Sender field, and a Reply-To field. --JSol -------  Date: 21 Jun 1982 2237-PDT From: Jon Solomon Subject: an opinion To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 I wish to argue for having the state of address parsing remain the way it is. The most important reason I can think of is that I already have a program which does it. That's also the most selfish reason I can come up with. Being a bit less selfish, I don't think there is an operating system or machine which we are currently hooked up to on our collective networks which doesn't have a parser which will handle the type of field currently supported by RFC733. I'm not saying that EVERYBODY's parsers know about it, but there are public domain (emphasis here) parsers available for especially UNIX (which is where I seem to hear most of the complaining coming from) which deal with parsing the from field on standard ARPANET messages. I think that we are really wasting much time (and quite a bit of disk space) arguing over what should NOT be in the document. Cheers, --Jsol -------  Date: 22 Jun 82 6:27:20-EDT (Tue) From: Dave Crocker To: Jon Solomon cc: Header-People at Mit-Mc Subject: Re: [To]: Jon -- If we standardize something like [To]:, then someone is going to write a mail system that knows about it and makes it convenient to use it for replies. My whole idea was to avoid this. Dave  Return-path: @USC-ISID,steve@ucl-cs Via: USC-ISID ; Tuesday, June 22, 1982 04:05:08-PDT Date: 22 Jun 82 11:16:37-BST (Tue) From: Steve Kille Reply-To: ucl-netwiz at isid To: Mark Horton cc: header-people at mit-mc Subject: Re: sender, from, and reply-to Mark, Another very useful reason for having all three valid is that mailboxes valid in one context may not be valid in another. Header munging will solve some cases but not all. Try replying to the from field of this message (which works fine in the UK). The Reply-To: field can be used to point the reply somewhere else. The Sender is still useful as an electronic address (if i had a secretary). Steve -------- Š  Date: 22 Jun 1982 8:21:36 EDT (Tuesday) From: Ken Pogran Subject: Re: [To]: In-Reply-to: Your message of 21 Jun 82 19:29:58-EDT (Mon) To: Dave Crocker Cc: Header-People at Mit-Ai Dave, I find it hard to believe that you of all people have built a mailer that contains a genuine HACK! The notion that the mailer itself should ensure that bcc recipients of a message cannot reply to it strikes me as a bit strange. After all, if I receive a message as a bcc recipient, I ought to realize -- seeing myself on the bcc list -- that the To: and cc: recipients don't know I've gotten the message, and that if I reply to it, my knowledge of the message will be revealed to them -- something that the sender of the message didn't want to happen. But, I OUGHT TO HAVE THE FREEDOM OF CHOICE to decide whether or not to "blow my cover". Besides, I don't think that a reply distributed to To: and cc: recipients of the original message, from someone who apparently wasn't on the original distribution lists, would be all that surprising today. Many mailers and mail-reading programs include forwarding and redistribution features that have the capability of placing messages into the mailboxes of people who weren't intended recipients. And THEIR reply might be just as relevant as the reply from an original recipient (example: Manager asks subordinate to respond to a query). Regards, Ken  Date: 22 Jun 82 9:39:32-EDT (Tue) From: Dave Crocker To: Ken Pogran cc: Header-People at Mit-Ai Subject: Re: [To]: (Thought this might stir things up, a bit.) I agree that the Bcc recipient should have the opportunity to reveal himself. My concern -- based on painful experience -- was with the human factors problem of people ACCIDENTALLY revealing themselves, because their reply command automatically incluced To and/or CC in the reply message. The bracketing hack retains the information, but requires that the recipient exercise extra effort to use it. The premise is that Bcc recipients were meant to be hidden from the rest. Dave  Date: 22 Jun 1982 07:09:18-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: an opinion In-reply-to: Your message of 21 Jun 1982 2351-PDT (Monday). Yes indeedy, there are lots of programs which do SOMETHING to 733 headers. But the issue in building a standard has to do with specifying WHAT is supposed to happen. I have seen NO two mail munching programs that do the same thing. Maybe this is fine; it's what makes horse races. But as I think Greep pointed out, the problem is getting things to be precise enough so something can be widely implemented with some hope of having uniform semantics (not to mention correctness!). I am not arguing that the existing 733 fails to be implementatable; I am suggesting it is being over specific. Again, ARPAnet myopia should be avoided. Twenex sites running MM or Hermes or whatever else and only seriously connected to the ARPAnet may not be concerned with the more global issues, but there are sites, mine for instance, which talk to 4 completely different mail systems on 4 diffenent kinds of networks. Leaving 733 the way it is is a brilliant finess of the issues. While it is not the only work to be done, a really hard problem is how to do mail and intermailing in a mixed-network environment. The situation at my site is that we choose not to finess the question because there are too many people we couldn't talk to if we did. If this means that the image of any one mail system suffers some minor loss of "functionality" or has to forgo some clever "feature" to widen the world to which the whole system can speak, then we are willing to make this trade. I suspect we are not alone in this position. I will admit something publicly right now. The mail system we use here at LBL has implemented most of the restrictions we have been discussing out of the need outlined above. Doom has not cracked nor has the earth opened up to swallow the non-believers. For the very same self-serving reasons JSol cites, unless 733 is changed to make our life easier, we will not be changing anything very much. So maybe the sad truth is that beyond getting the "domain" part added to the addresses, 733 is a moot issue. People will go on implementing whatever part of it that serves their purposes and ignoring the rest of it. The Purists will complain and the Users will continue to get their work done. And the NBS protocol will eventually swallow us all. Flaming out for the last time on this subject, -Mike  Date: 22 Jun 1982 07:09:18-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: an opinion In-reply-to: Your message of 21 Jun 1982 2351-PDT (Monday). Yes indeedy, there are lots of programs which do SOMETHING to 733 headers. But the issue in building a standard has to do with specifying WHAT is supposed to happen. I have seen NO two mail munching programs that do the same thing. Maybe this is fine; it's what makes horse races. But as I think Greep pointed out, the problem is getting things to be precise enough so something can be widely implemented with some hope of having uniform semantics (not to mention correctness!). I am not arguing that the existing 733 fails to be implementatable; I am suggesting it is being over specific. Again, ARPAnet myopia should be avoided. Twenex sites running MM or Hermes or whatever else and only seriously connected to the ARPAnet may not be concerned with the more global issues, but there are sites, mine for instance, which talk to 4 completely different mail systems on 4 diffenent kinds of networks. Leaving 733 the way it is is a brilliant finess of the issues. While it is not the only work to be done, a really hard problem is how to do mail and intermailing in a mixed-network environment. The situation at my site is that we choose not to finess the question because there are too many people we couldn't talk to if we did. If this means that the image of any one mail system suffers some minor loss of "functionality" or has to forgo some clever "feature" to widen the world to which the whole system can speak, then we are willing to make this trade. I suspect we are not alone in this position. I will admit something publicly right now. The mail system we use here at LBL has implemented most of the restrictions we have been discussing out of the need outlined above. Doom has not cracked nor has the earth opened up to swallow the non-believers. For the very same self-serving reasons JSol cites, unless 733 is changed to make our life easier, we will not be changing anything very much. So maybe the sad truth is that beyond getting the "domain" part added to the addresses, 733 is a moot issue. People will go on implementing whatever part of it that serves their purposes and ignoring the rest of it. The Purists will complain and the Users will continue to get their work done. And the NBS protocol will eventually swallow us all. Flaming out for the last time on this subject, -Mike  Date: 22 Jun 1982 09:15:33-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: header-people at mit-ai Subject: revelation?? Maybe I am dense, but I think I understand what is happening with some of this discussion. One group of parties is arguing from what they think the User should see. Another group is arguing from what the Programs (below the reader/composer) should see. What exactly is 733?? Is it a description of the User interface to a mail system?? I think not. It certainly drives the functional requirements of such programs, but is not one itself. I see 733 as an interchange specification, which attempts to define some semantics and syntax for information exchange, not necessarily its presentation to the user. Maybe the way to resolve this address parsing business is to point out that if users want to read "foo at bar" and type "foo at bar", they should use a reader/composer can do that for them neatly. But at the interchange level, where mail systems speak to mail systems, 733 applies as the canonical form. Here we could say "addresses are things not containing whitespace (or commas for the IBM minded)" to make the job easier at that level. Supporting this position are the draft mail standards like NBS which encode the "headers" and variable length property lists in BINARY. This forces the reader/composer to do "presentation" processing of headers in general (and addresses specifically), so the syntax is forced to be stylized, unless the poor user has to type things in in binary. -Mike  Date: 22 Jun 1982 1020-PDT From: Jon Solomon Subject: Re: [To]: To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 22-Jun-82 0639-PDT If I receive too many messages with a [To]: field I might just write a mail program which parses that header so I get that freedom of choice in a convenient fashion. Whether or not this is a "required" or optional standard header or even if the header is not included in the "standard". The point still remains that I want to know who (or specifically, WHAT) the message is for, and sometimes the "From" field and text of message don't give enough information. --JSol -------  Date: 22 Jun 1982 1032-PDT From: Jon Solomon Subject: Re: an opinion To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 22-Jun-82 0709-PDT I have been a victim of harrassment from people who tell me my headers are "illegal" and that I should "cease sending garbage network mail or will sick the network security agents on me and remove our network connection until we comply". If you restrict RFC733, I will be forced to remove from our mailer all remnants of the previous one else someone will flame at us the same way. I do not wish to have DCA or DOD come down on us so hard, and while I can see your argument that you should not be forced to offer these features to your users, it is indeed sad that I, and others like me, will have to throw away perfectly good work just to conform to someone's specific bureaucratic problem. Incdentally, one of the things I may end up having to write is a program which (on the fly) converts from RFC733 standard to NBS standard. I don't see this as overly difficult. If we finally decide to restrict the "from" field to some stringent format I will probably have do the same thing to outgoing ARPANET mail. Our users tend to like the diversity of headers. It still seems quite a shame to waste all that effort, just because someone else's mailer can't parse the headers. Not to mention all the effort that went into implementing this one and helping our users get used to the format. A non trivial number of them will notice and probably complain to us about it. Cheers, --JSol -------  Date: 22 Jun 82 14:45:53-EDT (Tue) From: Dave Crocker To: Header-People at Mit-Mc Subject: changes It has been a busy morning. I have gone through the transcript, trying to synthesize people's comments into the next draft of the format spec. I think I have been reasonably fair, so that, with any luck at all, everyone will feel shortchanged. To reiterate one point: I personally favor a standard which is STRICTLY interchange-oriented and which does NOT take cognizance of nice human-factors items, such as " at " vs. "@". However... My mandate was for a restricted delta on the existing standard. I hope that the multi-media standard will free us of this very cumbersome historical robe. To wit: "at" is retained. The From field may contain only machine-usable addresses (one or more) and may NOT contain a group (named list). The {} bracketing construct will not be added. I believe that most of its applications are system-dependent, anyhow, and thus need not appear in the standard. I expect some exceptions, such as Postal addresses, and recommend that they be served by naming some special Domains. (!) Postel's restricted date/time format have been adopted, except that the dash ("-") between time and timezone has been removed, per many people's requests. (I had not, previously, noticed the parsing ambiguity.) Line-folding is retained. At least one destination address (To, CC, Bcc) will be required. To and CC must contain at least one address. Bcc does not. Groups are retained, though recursive group specification is not allowed. It turns out that several sites really do use groups in the way we originally intended, displaying the group name, while hiding the list contents. If a group list has no contents, then the terminating semi-colon is optional. Period (".") remains a universal special character. I have tried to make some modifications to the text to guide usage, for the local-part. In a route-addr, the route sequence is separated from the addr by colon (":") rather than comma (","). may not contain SPACE. The "Remail-*" meta construct is renamed "Resent-*". Several people commented on the linguistic anomaly of "remail" so I chose the shortest acceptable alternative. (I had, originally, been trying not to favor an existing implementation. Sorry, Hermes and the rest...) Extension-field and User-defined field naming and usage rules remain the same, except that no Extension-field (i.e., future standardized field) will have a name beginning with "X-". Dave P.S. I will be out of town, for several days, which should afford my cpu an opportunity to cool down from your replies.  Date: 22 Jun 1982 8:31:11 EDT (Tuesday) From: Ken Pogran Subject: Re: sender, from, and reply-to In-Reply-to: Your message of 21-Jun-82 23:08:17-EDT (Mon) To: mark at Berkeley, pogran@(Mark@Berkeley, pogran@Horton)@Berkeley Cc: header-people at mit-mc, @, pogran@Berkeley@Berkeley "But I would prefer a standard that is so simple and unambiguous that the algorithms are all trivial and obvious." Mark, We're trying to provide the framework for an electronic mail system that's capable of representing a reasonable subset of the patterns of human communication. If the standard is so "simple and unambiguous" that it restricts the patterns of communication, then systems implementing it won't find much use in the real world; they'll be used only by died-in-the-wool computerniks like ourselves (heaven forbid!). I'm not arguing that we need to retain as much freedom as there is today in the use of From:, Sender:, and Reply-To:; just that we need to have enough functionality to provide a system that's attractive to people. It's the USE of the system that needs to be simple and straightforward, not necessarily the programming task. After all, isn't the latter what we get paid for? Ken  Date: 22 Jun 82 16:55:35-EDT (Tue) From: Dave Crocker To: Header-People at Mit-Mc Subject: Address-Fields Given that we expect to have relay systems that massage headers (terrible, but currently seems to be necessary), one of the issues they face is the identification of fields which contain addresses to massage. I would like to propose the specification of a field which lists which fields contain addresses. It would be used whenever the message contained "non-standard" address fields. I.e., fields not named in the standard. A minor, but potentially useful hack. Thoughts? Dave  Date: 22 Jun 1982 1506-PDT From: Mark Crispin Subject: named address lists Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The purpose of named address lists as most TOPS-20 and Tenex software implements them is to sabotage a receiver's Reply command intentionally, e.g. to have To: Various People: ; as the TO-list. The only "reply" to this message is to its From or Reply-to. There is completely different technology for a named address list that can be replied to, that is, having a mailbox which explodes to the address list such as VARIOUS-PEOPLE@SU-SCORE. Both functions are useful. Both should be kept. Both have been in common use for over a decade. I like the "text " syntax and think "@" is somewhat prettier than " at ", but don't terribly care. Another thing we could do is just say the hell with changing the spec radically and just make the necessary modifications for SMTP and domain addressing. -------  Date: 22 Jun 1982 1509-PDT From: Mark Crispin Subject: 3 electronic addresses Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Since enough software implements it already, I see no reason for disallowing it. I'll grant that a number of people use three electronic addresses for silly stuff like: From: the outhouse of Larry Loser Sender: LOSER at RANDOM-HOST Reply-to: Loser at RANDOM-HOST and there is some administrative pressure to disallow this sort of thing, but it all seems too silly to worry about. Is there any movement among people to leave the standard essentially intact? -------  Date: 22 Jun 1982 1516-PDT From: Mark Crispin Subject: ARPANET myopia and TOPS-20 Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Mike - I think it is unfair to accuse TOPS-20 sites running HERMES or MM as being [ARPANET] myoptic. MM and its friends support several different networks (more than the 4 you quoted). As the principle MM maintainer I am quite aware of multiple network (as opposed to Internet) issues. The BBN maintainers of HERMES are likewise composed of a number of bright people. Most of the simplifications proposed for RFC 733 were aimed for those sites (such as small Unix systems) who may not have the manpower to implement full 733 or who would have problems. Neither MM nor HERMES would benefit from those simplifications other than perhaps making some of the code simpler since both have supported all of this for some time. My comments on simplification were to try to be helpful to small systems. I don't need any of those simplifications, having done the work already. -- Mark -- -------  Date: 22 Jun 1982 16:05:13-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: dcrocker at UDel-Relay cc: Header-People at Mit-Mc Subject: Re: Address-Fields In-reply-to: Your message of 22 Jun 1982 1421-PDT (Tuesday). Dave, The "address-list" is in principle useful, but header munging may well be done differently for "To:", "From:", and "Reply-to:" fields (it is in our environment if replies are to have any chance of working). This means you have to scout around anyway, so while the line might give you some hints, you may not be able to discover how it is you should munge "Reply-by-way-of:" if it were to appear in the "Address-lines:" line. In fact, it looks like we may be buying a bigger problem: restrictions on the lines that can appear in the "Address-lines:" line! -Mike  Date: 22 Jun 1982 1726-PDT From: Stef Subject: Re: sender, from, and reply-to To: mark at UCB-C70, header-people at MIT-MC In-Reply-To: Your message of 21-Jun-82 2008-PDT From: Boss Sender: Secretary Reply-to: Staff-Analyst Is one good example. To see more, all you need to do is think in the larger context of complex groups of workers. Best - Stef -------  Date: 22 Jun 1982 1725-PDT Sender: CERF at USC-ISI Subject: Re: [To]: From: CERF at USC-ISI To: pogran at BBN-UNIX Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI Message-ID: <[USC-ISI]22-Jun-82 17:25:48.CERF> In-Reply-To: Your message of 22 Jun 1982 8:21:36 EDT (Tuesday) Ken, I disagree - I've been burned more than once by replying to a BCC messasge, intending it only to go to the originator , but having it show up to everyone. I think Dave's hack is the right idea. Vint  Date: 22 Jun 1982 1800-PDT From: Stef Subject: Re: [To]: To: Header-People at MIT-MC In-Reply-To: Your message of 22-Jun-82 1020-PDT I would like to isolate the essential issues around TO: and [TO]: It is clear that Computer mail is more prone to let people err in replying without intention, to a received BCC copy. With a paper memo or letter, this is not an issue because of the lack of automation in the reply process (maybe). But, it sure is an issue in Computer Mail! In an earlier Hack (maybe Dave's), the BCC field was omitted in the BCC recipient's copy. Detection of ownership of a BCC copy required careful inspection, and inference based on lack of any visible trace of how the message got to the recipient. This one really bit me once! So, I complained, and now we have this nice new hack that does pretty much what I want. It prevents me from inadvertant errors, but it does not prevent me from deliberate disclosure of my having a copy. This is exactly right in my opinion, but I will no go so far as Dave does in trying to prevent a deliberate reply through sme kind of manual over-ride. To me, it is enough to require the recipient to take some action which clearly means "Yes, I see that this is an abnormal/unusual Action, but I am doing it anyway!" At worst, this can be done by retyping the "blinded" addresses. Anyone who creates a User Agent that fails to distinguish between TO: and [TO]: as we have defined them here, is not going to win any sales with my clients. But, now I have a new problem. (New Systems Always Create New Problems!) I cannot now scan with a string search on TO: to find a [TO]: unless someone will kindly modify MM and HERMES, et al. (anyone for MSG?) So, I would like to see a standard way to show TO fields that are not intended for automatic reply, but are expected to be processable. Then it will be reasonable to enhance User Agents to deal with this new "standard" case. I expect that the "custom" of using "[x]" for the alternate form of "x" is a good one, and one that will work in general for many fields other than TO and [TO]. BUT! I do not propose that this be used if a better form exists! Is it reasonable to go so far as to include such a "meta" standard? Best - Stef -------  Date: 22 Jun 1982 1858-PDT From: Jon Solomon Subject: Re: [To]: To: ESTEFFERUD at USC-ECL cc: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 22-Jun-82 1800-PDT I propose that the blind [to] and [cc] fields be not headere fields but comments in a new field (original:) which makes it crystal clear that programs should not be hacked to do this. On the other hand, it seems reasonable for a mail system to allow you to reply to a [to]: field but to query the user "Are you sure you wish to reply to this blind carbon copy?" --JSol -------  Date: 22 June 1982 2129-EDT From: Rudy.Nedved at CMU-10A To: CERF at USC-ISI Subject: Re: [To]: CC: dcrocker at UDEL-RELAY, Header-People at MIT-AI In-Reply-To: <[USC-ISI]22-Jun-82 17:25:48.CERF> Message-Id: <22Jun82 212907 EN10@CMU-10A> Vint, What is the purpose of the hack? It is to make it harder for the mail responding software to parse the TO: and CC: fields. After the [To] hack has been around, software will be available which parses this field....enabling you to get "burned" again. What the software should do is see that YOU are on the BCC field of the message that you are answering and that it should say "Are you *REALLY* sure you want to send it to the receiver??" Delicate comments made thru a mail system should not be handle by the mail header. Wouldn't the same problem occur if your mail file was unprotected? -Rudy  Date: 22 Jun 1982 1902-PDT Sender: CERF at USC-ISI Subject: Re: [To]: From: CERF at USC-ISI To: Rudy.Nedved at CMU-10A Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI Message-ID: <[USC-ISI]22-Jun-82 19:02:31.CERF> In-Reply-To: <22Jun82 212907 EN10@CMU-10A> Rudy, normally I don't like to contemplate systems which "save us from ourselves" - like some government regulations seem to attempt. However, I do think we need some protection against inadvertently sending responses to the wrong parties without some control. I won't quibble about the mechanisms used to help avoid accidental blunders, but believe we need some way to avoid them. Vint  Date: 22 Jun 1982 21:54:55 EDT (Tuesday) From: Jack Haverty Subject: Re: [To]: In-Reply-to: Your message of 22 Jun 1982 17:25 PDT To: CERF at USC-ISI Cc: pogran at BBN-UNIX, dcrocker at UDEL-RELAY, Header-People at MIT-AI My two cents: Whenever we talk about any particular behavioral characteristic of mail, like the treatment of bcc in replying, for every person who likes it to work in the X fashion, there is another for whom Y makes more sense. My favorite is the convention for what happens when you just say 'answer', and something decides whether or not to include the cc field, etc. It is not the business of a mail protocol to define the behavior of mail systems. The protocol should provide the basis upon which various systems can be built, and the user, as customer of mail software, should pick his favorite. The protocol must support all of the choices, in the sense that it is rich enough to convey the information in a lossless fashion, if we desire to maintain interoperability. If the Hermes Users' Group, or MM, or MH, or whatever, want to argue about what their software should do, that is I think the proper place for the arguments. There is no correct global answer to most of these questions, it's like trying to define a standard computer, or standard operating system. They all run programs, but the best choice depends a lot on what you expect or need the system to do for you. Flameout, Jack  Date: 23 Jun 82 00:12:14 EDT (Wed) From: Steve Bellovin Subject: [To], larger issues To: header-people at Mit-Mc Via: UNC; 23 Jun 82 0:30-EDT Even though I like Dave's mod, I'm preparing to install a different protective device on our mailer here -- his way doesn't fit in with its structure, and would cause a fair amount of extra overhead, given the way it already works. I plan to have it check the 'To' and 'Cc' lines of the message being replied to; if your userid doesn't appear, it will warn you. Note that that catches replies to mailing lists, bcc copies (boy have I been burned on that one...), etc., but without requiring any explicit action at all if you really want to send the reply. Turning for a moment to some larger issues.... Has anyone compared the new draft standard with the NBS proposal? Specifically, does 733' contain all the information they require/like? Are there any important elements of 733' that are hard to represent in NBS, and vice-versa? It seems certain that translators are going to have to be written between the two; we may save ourselves a lot of grief later on by doing some extra checking now. (I haven't gotten around to typing up a U.S. Snail letter to them; if only they were on the net.... (or are they?))  Date: 23 June 1982 01:31-EDT From: Gail Zacharias Subject: sender, from, and reply-to To: mark at UCB-C70 cc: HEADER-PEOPLE at MIT-MC I don't know whether this is exactly the intended use of the sender field, but at least on ITS if you send mail from another user's account (i.e. use his terminal to send a message without logging him out), the logged in person's name will be placed in the sender field. This situation is clearly independent of whether you want the replies to go somewhere else, if so, you have a case with 3 distinct net addresses involved.  Date: 22 Jun 1982 22:49:40-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: smb.unc at UDel-Relay cc: header-people at Mit-Mc Subject: The Proposed NBS Standard In-reply-to: Your message of 22 Jun 1982 2155-PDT (Tuesday). I have been looking at the proposed NBS standard in some detail, especially since at least 4 commercial companies have endorsed it at an INTERCHANGE standard. Compared with NBS, 733 appears rather naive about the political world envisioned for electronic mail in a corporation (I do not subscribe to supporting "An Evening in Byzantium", but they didn't ask me). The headers are coded as variable length property lists with lengths and "descriptor codes" in binary. There are many new kinds of headers like: "Assigned-for-action-to:" and "Assigned-for-action-on:" (implying a date), plus many other things I would have never thought about (nor would ever use). However, it is interesting reading; a good example of design by "thinking of everything you would ever want to do and putting in a frob". In deferrence to the designers, it isn't a bad document, just seems like overkill for the mail environment we know. But in the corporate world, maybe things are different; I don't want to know. The semantics of the headers are specified in English, but the standard doesn't attempt to define the fine semantics of what reader/composers should do with the fields. (The current discussion of "no single sufficient semantic for reply" is a good example of open issues.) I have a hard copy of the document, but I can't seem to remember exactly how I got it. -Mike  Date: 23 June 1982 0345-EDT From: Rudy.Nedved at CMU-10A To: mo at LBL-UNIX (Mike O'Dell [system]) Subject: Re: The Proposed NBS Standard CC: header-people at Mit-Mc In-Reply-To: mo@LBL-UNIX's message of 23 Jun 82 00:49-EST Message-Id: <23Jun82 034505 EN0C@CMU-10A> Isn't the proposed NBS standard RFC806?? -Rudy  Date: 23 Jun 1982 0500-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: NBS Document/personnel available online To: smb.unc at UDEL-RELAY cc: Header-People at MIT-MC Yes, at least one good NBS contact, Shirley Watkins, is online at WATKINS@NBS-VMS. Also, as Rudy pointed out, RFC806 is the online version of the Sep 81 version of the Proposed Federal Information Processing Standard "Specification for Message Format for Computer Based Message Systems". It is 99 pages, formatted, and can be FTPed from host SRI-NIC in file RFC806.TXT. For CSNET users, or any others not having direct ARPANET access for FTP, a message to NIC@SRI-NIC requesting it should get you a copy in your mailbox. ALso, I now have a copy in my directory and for the next couple of days I will also honor such requests. Cheers, Rich -------  Date: 23 Jun 1982 8:14:00 EDT (Wednesday) From: Ken Pogran Subject: Re: [To]: In-Reply-to: Your message of 22 Jun 1982 17:25 PDT To: CERF at USC-ISI Cc: pogran at BBN-UNIX, dcrocker at UDEL-RELAY, Header-People at MIT-AI Vint, Could we compromise on interaction? I can see your point, but I don't like the unilateral hack. So, perhaps, if the mail system recognizes that you're about to do a dumb thing, it should ask you if you REALLY want to do it. But only if you've put the right entry in your profile ... Warning: You are a bcc recipient. Reply to to/cc list? (Y/N) Ken  Date: 23 June 1982 09:08 edt From: Charles Hornig at MIT-MULTICS Subject: Re: [To]: Sender: Hornig.Multics at MIT-MULTICS To: header-people at MIT-MC In-Reply-To: Message of 23 June 1982 08:35 edt from Ken Pogran The Multics mail reading program takes a different approach to replying that seems to get around some of these problems. First, you must explicitly indicate that you want to reply to all the (original) recipients of a message. The default is to reply only to the mailbox in the Reply-to: (or From:) field. Second, it tells you exactly to whom it is replying before you start composing your reply. If there are more than 2 or 3, it gives the first few and tells you how many others there are. This gives you a wonderful opportunity to realize that you don't want X to receive the reply, and edit him out of the header. This seems to me to be a more general solution to the problem of replies.  Date: 23 Jun 1982 0727-PDT Sender: CERF at USC-ISI Subject: Re: The Proposed NBS Standard From: CERF at USC-ISI To: mo at LBL-UNIX Cc: smb.unc at UDEL-RELAY, header-people at MIT-MC Message-ID: <[USC-ISI]23-Jun-82 07:27:17.CERF> In-Reply-To: Your message of 22 Jun 1982 22:49:40-PDT Mike, everyone got one! sent them to a lot of places. Some of the ideas in the BBN/NBS format are like the ideas Jon Postel developed in his multimedia message transport format. The NBS stuff fits more into that area, I think. The revised 733 is not, in my view, intended to compete at all with the NBS or other multimedia ideas. It is intended to bring stability and documentation to the current text-only mail system of which we have so many implementations. Any substantive comments you might wish to share about the NBS document would be of real interest to me. Vint Cerf  Date: 23-Jun-82 10:00:18-EDT (Wed) From: mark@Berkeley (Mark Horton) Subject: Re: [To]: Via: cbosgd.uucp (V3.94 [3/6/82]); 23-Jun-82 10:00:19-EDT (Wed) To: header-people@mit-mc@Berkeley Untrue! People often put in Reply-to: with the intent that they are modifying the semantics of the Reply command on the other end. Thus, there had better be some universal notion of what "reply" means or this is meaningless. In my experience, there are two major uses of reply: (1) reply only to the person who sent the mail, (2) reply to all people who sent or received the mail. These two need to be explicitly defined. Of course, if a mail system wants to implement ADDITIONAL options, there is not reason why they shouldn't. But these two functions are so common and important (and confused by all the different special cases and exceptions) that we need algorithms. Mark  Date: Wednesday, 23 Jun 1982 09:21-PDT To: header-people at MIT-MC Subject: Re: [To]: In-reply-to: Mark Horton's message of 23-Jun-82 10:00:18-EDT (Wed). From: greep at RAND-UNIX What we currently have is that messages specify various data in the form of header fields, to which the receiving programs may attach different interpretations than those intended by the sending program or user, e.g. the use of "from" and "sender". Mark's message suggests (I'm not sure if this is what he intended) that the header could specify to the receiving programs how they are expected to handle the message. For instance the header could somehow indicate that replies should, by default, go to certain of the listed addresses but not others. That is, we are talking about moving towards transmitting algorithms of a restricted form rather than just data. I think this sort of thing would be a step in the right direction since it would reduce the effects of different interpretations of headers.  Date: 23 Jun 1982 0941-PDT Sender: CERF at USC-ISI Subject: Re: [To]: From: CERF at USC-ISI To: pogran at BBN-UNIX Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI Message-ID: <[USC-ISI]23-Jun-82 09:41:42.CERF> In-Reply-To: Your message of 23 Jun 1982 8:14:00 EDT (Wednesday) Ken, as I've said before, my interest is not so much in the mechanism as in having some means of protecting against accidental response to something received as a bcc. Of course, I hope the mechanism selected, if any, is technically sound and generally acceptable to the implementers. Vint  Date: 23 Jun 82 13:31:54-EDT (Wed) From: Dave Crocker To: Header-People at Mit-Mc Subject: "From" clarification I seem to have created some confusion, about the status of acceptable From field contents. My note, yesterday, did not make a point of mentioning‡‡ its relationship with the Unix/Mark Horton/etc. issues about simplifying contents. I had focussed solely on the issue of requiring machine-usable addresses and not on the prohibition of human-name information. The spec currently permits which permits human name . Dave  Date: 23 Jun 1982 1839-PDT From: Stef Subject: Re: [To]: To: CERF at USC-ISI, pogran at BBN-UNIX cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI In-Reply-To: Your message of 23-Jun-82 0941-PDT I think we have drifted off from the RFC733 related import of this issue. Dave's HACK has established a new user field which is not defined in 733, though it is not illegal either, under the "user-defined" rules as I recall. But, if everyone used this ploy to avoid BCC REPLY problems, would we not need to recognize [to] in RFC733 so that USER AGENTS couuld all know what such things mean and be programmed to take meaningful actions related to the acepted meanings? It seems to me that the real issues underlying RFC733 are to provide common understanding of the meaning of transmitted header information, so as to facilitate communication between UA's on behalf of their users, who are the primary correspondents in the first place. Is it not towards common menaing and use of header fields that we are headed? Best - Stef -------  Date: 23 Jun 1982 1115-EDT From: J. Noel Chiappa Subject: Re: [To]: To: CERF at USC-ISI cc: Header-People at MIT-AI, JNC at MIT-XX In-Reply-To: Your message of 22-Jun-82 2202-EDT What you really want is a mail system where 'REPLY ALL' is not the default, as well as a delay after hitting the 'SEND' button to allow the poor user to cancel the message. -------  Date: 24-Jun-82 13:30-PDT From: ANDREWS at OFFICE Subject: RE: [To], larger issues To: Steve Bellovin Cc: HEADER-PEOPLE at MIT-MC Identifier: OAD-DIA-11CA3 Length: 2 page(s)[estimate] Posted: 24-Jun-82 13:28-PDT Let's here it for Steve Bellovin's suggestion regarding looking at the NBS standard. Several of us at Tymshare are just finishing up the new AUGMENT Mail system -- AUGMENT is Tymshare's comprehensive office information system, and runs on several hosts on ARPANET and TYMNET (some on both nets). We are following the proposed NBS message format quite closely. AND we convert both to/from RFC733 format now. We are sitting here waiting for you all to get your act together! All I have to say at this point is: (1) Sheeee! what a volume of discussion, (2) if you deviate from the NBS standard significantly you should have good reasons and lean on NBS about them, and (3) you have some funny looking fields proposed that relate to inter-net kinds of things (return-path, received) that in my opinion belong in the transfer protocols but NOT in the message format. That is, that info is for message handlers and not necessarily people -- sure, mail hackers want to see that stuff, but Joe mail reader just wants the To, From, (a few more) and the body, and the hell with how it got here, as long as he can answer it. I suggest you try to stick to the NBS message item fields and build up on information exchange between mailers. Our philosophy is that mailers should not even be able to read let alone munge the item, and that the item should be accompanied by distribution information for it (mailer) to twiddlle and pass on -- to other mailers and not to the recipient. Of course when an item is converted to another format a "converter" has to translate (possibly) every field etc and munge addresses so that "answer" functions will work in the target mail environment-- but the whole idea behind having a format protocol is to avoid that. While I'm at it let me add that I agree with a recent point about a Bcc recipient answering and getting burned-- that is a user feature issue, not a RFC733 level issue! PLEASE don't confuse the two. Along that line I have no use for the Remail-* fields. I suggest putting the previous header info in the body or in a "user-defined" type field but NOT formalizing it in the protocol. --Don  Date: 24 June 1982 1719-EDT From: Rudy.Nedved at CMU-10A To: ANDREWS at OFFICE-2 Subject: Re: [To], larger issues CC: HEADER-PEOPLE at MIT-MC In-Reply-To: ANDREWS@OFFICE's message of 24 Jun 82 15:30-EST Message-Id: <24Jun82 171937 EN0C@CMU-10A> Don, Us poor 36-bit machines have all our stuff currently encoded into 7-bits....It is going to take a major amount of work (three to five man years??) to get the mail deliverers and mail readers to understand 8-bits and any new multi-media standard. I admit that CMU seems to be gearing up for 8-bit byte everything but most of the mail system transfers are 7-bit. Therefore, one should look at the new RFC733 as an interim standard ONLY supporting TEXT and that some new RFC on multi-media mail will become adopted for ArpaNet (If I remeber correctly this is mentioned in the NCP to TCP conversion plan RFC as something to think of for the future). As for mail-routing information munged into the mail headers: Well, either you have a mail routing table which is updated auto-magically (real quick....not every month or year) or you put mail routing information in the headers. It seems the decision has already been made to munge the mail headers. -Rudy  Date: 24 June 1982 2341-EDT (Thursday) From: Craig Everhart at CMU-10A To: Rudy.Nedved at CMU-10A Subject: Re: [To], larger issues CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: <24Jun82 171937 EN0C@CMU-10A> Message-Id: <24Jun82 234145 RD00@CMU-10A> Andrews' message, if I read it correctly, only suggested that the information embedded in the Return-Path and Mail-From header lines should be communicated out-of-band in the mail handling protocol, not stored as part of the (generally) user-visible mail header text. I happen to agree with that philosophy. However, isn't the Return-Path line supposed to give automatic reply-ers precisely the information that some on this list were so adamant about finding unadorned in the From field?  Date: 25 Jun 1982 1123-PDT Sender: WESTINE at USC-ISIF Subject: Re: [TO], Larger Issues From: Postel@isif To: Rudy.Nedved at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISIF]25-Jun-82 11:23:31.WESTINE> The "Return-Path" and "Mail-From" lines that get stuck on the front of the message are really information used by and developed by the mail transmission procedures, that is, they are part of the envelope not the contents. The problem is where to put them, when the message is delivered. In many systems a message is just a file or just a small portion of a file. Is it that important to mark the boundary between the envelope and the contents? --jon.  Date: 25 Jun 1982 11:45 PDT From: Taft at PARC-MAXC Subject: RFC 733 as an interchange standard To: Header-People at MIT-MC cc: Taft I would like to add my support to the view that RFC 733 is primarily an interchange standard as opposed to a user interface standard, and to advocate that this approach be pushed as far as possible within the limits imposed by Dave Crocker's mandate. While I join Dave in hoping that the multi-media standard will eventually supercede RFC 733, I despair of that happening any time soon. We should do the best we can with RFC 733 given the constraints within which we must work, since (if past history is any guide) we are unlikely to have another opportunity for a long time. One way of viewing the current draft specification is as an impure interchange standard which includes concessions to previous usage for backward compatibility. That is, the standard should emphasize its role as a machine-to-machine protocol; but those aspects of user interface design that have crept into the protocol and can't be eradicated during this revision should be clearly labelled as such and their use discouraged in new implementations. To pick a trivial example, "@" and "at" are clearly redundant. But apparently we have decided that there are so many implementations using each one that arbitrarily eliminating one of them would have too big an impact on existing software. Therefore, the specification should identify one of them as the "preferred" usage (presumably "@" since it is syntactically cleaner -- "at" is the only separator which is not a special). All software that parses headers must continue to accept either "@" or "at"; but new implementations that generate headers should be required to emit only "@", and existing software should be modified to conform to the preferred usage whenever the opportunity arises. That way, at some future time when most of the old software has rotted away, we can flush "at" altogether. Various people have objected to this sort of standardization because "computers should serve people, not the other way around". But this misses the point of having an interchange standard. Your computer should serve you and my computer should serve me; but my computer shouldn't need a fancy parser to figure out what your computer said to it. What confuses the issue is that the interchange protocol is human-readable, as opposed to a more machine-oriented protocol such as the NBS draft standard; this causes implementors of mail-handling software to gain the mistaken impression that what appears on the wire between computers is what the humans are meant to see. Actually, we are adopting this human-readable protocol for backward compatibility, and also to permit the participation of mail users who have minimal support from user interface software. But such use should not be the primary focus of RFC 733, and the convenience of such use should not even be a consideration. The draft RFC 733 already has something to say along these lines, particularly in section 1.1, "Scope", and 1.2, "Communication Framework". The document needs more emphasis on its role as an interchange standard so as to forestall religious debates over matters that are really user interface issues. Ed Taft  Date: 25 Jun 1982 14:01 PDT From: Taft at PARC-MAXC Subject: Line folding To: Header-People at MIT-MC cc: Taft In line with my position that RFC 733 should be an interchange standard rather than a user interface standard, I would like to advocate strongly that we delete from the specification any requirement that the contents of a message (either header or text) be divided into lines of any particular fixed length. Such a requirement is a serious infringement on the ability of user interface software to control the appearance of messages being presented to the human user (which is stated as an important property of the communication framework in section 1.2 of the draft specification). The specific problem this causes, of course, is that the sender and recipient of a message may be using terminals with very different characteristics, particularly a different number of characters per line. If the mail sending program inserts CRLFs in outgoing messages to conform to the format of the sender's terminal, the resulting text may be too wide or too narrow for the recipient's terminal. It is extremely difficult for the recipient's mail software to reformat such a message properly, because information has been lost: there is no syntactic distinction between CRLFs inserted for formatting purposes and ones that truly represent breaks in the text. (There is sometimes a semantic distinction, but one that requires an unreasonably sophisticated parser to discern.) On the other hand, if the transmitted version of the message does NOT contain CRLFs inserted for line folding, both the sending and receiving mail systems can trivially format the text as appropriate for their own local terminals. Note that I am NOT advocating either that the syntax for folding long headers be removed from the specification or that mail sending programs be prohibited from folding long lines if they want to. There are clearly situations in which the sender wants to convey a specific visual effect to the recipient; and there is no widely-agreed-upon convention for conveying such information other than by explicit insertion of CRLFs, spaces, etc. The specific measures I propose are: (1) Delete all mention of any specific required or recommended line length (e.g., the "65 or 72 characters" in section 3.4.7). (2) The spec should either discourage automatic CRLF insertion in transmitted messages or remain silent on the issue, particularly with regard to the text of messages. (I'm actually not so concerned about the header -- since the header DOES conform to a well-specified syntax, reformatting it is not especially hard.) (3) The spec must disallow mail software from unilaterally imposing any line length limit on incoming messages -- or, indeed, any restrictions at all on the content of the text. Currently there exist FTP mail servers that will not accept messages containing lines longer than some limit or containing certain characters such as control-C. Ed Taft  Date: 25 Jun 1982 1703-PDT From: Jon Solomon Subject: Unexplored Topic -- Length of Mail Message To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 This may actually be straying a bit, but I think it deserves at least some attention. Some mail handlers impose limits on the size of messages which they may transport. The impact this has varies from site to site, and has several different reasons for being. In our case, our mailer imposes a limit which prohibits large source files or documents from being transmitted via the network mail system. The reason to do this was apparently to convince people to use FTP for long files, and mail only pointers of the file. We also try to prevent one user from tying up the mail process all day with his message and have timeouts set up to control this. In current practice, networks and internetworks can have problems doing ftp transfer system to system, while mail processing tends to happen more easily and less expensively. Mailing a message containing the entire source to the operating system may be of some real value to me. Certainly mailing something as small sized as RFC733 should not pose a problem, yet it does for some systems and sites. Perhaps this is really something to think about in SMTP, but the issue of whether or not we should impose a limit, allow this to be a site independent issue, or require that there be no limit on the size of mail messages might be a useful topic on Header-People for inclusion in Son-Of-RFC733. There are really two issues here: One of them is clearly related to the protocol which actually transfers the mail (e.g. SMTP), in that it needs to have some built-in mechanism to control what happens to mail if the site can't deliver it. We recently fell into a problem like this trying to send semi-large messages to a site which had a slow receiver. Our mailer kept timing out, and requeued the message, while the remote site kept sending the peices of the message (effectively saying "Here's what I got of it"). The second one is the one which needs to be addressed here, Is "MAIL" defined to be the transaction of small messages of minimal information exchange, relying on some other form of processing to handle large items (e.g. FTP), or should we consider MAIL an independent and completely self-sufficient form of computer information exchange and communication? I vote for the latter. Cheers, --JSol -------  Date: 25 June 1982 1753-PDT (Friday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: length of mail messages To: HEADER-PEOPLE at MC I'm glad Jon brought this topic into the spotlight. As he suggests, we are seeing increasing numbers of cases (particularly when dealing with multiple networks) where standard mail presents the simplest (and in many cases the ONLY) means for moving large files. The provision of a file pointer with instructions to "use FTP" doesn't do any good to a user without direct access to the host network. There are also situations where, for security reasons, users on ARPANET computers have access to network mail but *not* to TELNET or FTP. Some reasonable way to deal with these sorts of situations, which can only be expected to occur more frequently, is a fairly critical issue. --Lauren--  Date: 25-Jun-82 14:07:06-EDT (Fri) From: mark@Berkeley (Mark Horton) Subject: Return-Path and From and Sender Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jun-82 14:07:07-EDT (Fri) To: header-people@mit-mc@Berkeley Craig Everhart has a good point. However, I thought it was the Sender line that had the same information as Return-Path. Why do we need both? If the full return path is always a valid thing to mail to to get back to the sender, and if in fact everything up to the last comma can normally be ignored, and Return-Path is required on every message, I have no problem with fancy From lines. On the other hand, if you're going to have an algorithm that looks like Try Reply-to. if that fails, check From, and understand the various syntaxes. if that fails, check Return-Path, and (optionally) strip to last comma. if that fails, check Sender. then things are even getting MORE complex. Mark  Date: 25 Jun 1982 1958-PDT Sender: CERF at USC-ISI Subject: Re: Unexplored Topic -- Length of Mail Message From: CERF at USC-ISI To: JSol at USC-ECLC Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]25-Jun-82 19:58:06.CERF> In-Reply-To: Your message of 25 Jun 1982 1703-PDT JON, WE TREAT THE MAIL SYSTEM AS A COLLECTION OF MORE OR LESS AUTONOMOUS PROGRAMS WHICH RUN MOST OF THE TIME, SERVING OUR NEEDS AS WE GENERATE OR RECEIVE MESSAGES. PERHAPS ONE COULD IMAGINE A SIMILAR COLLECTION OF FILE SERVICE PROCESSES WHICH MIGHT RESPOND TO REQUESTS FOR FILES OR PART OF FILES. PRESUMABLY THE PATH THE RETRIEVED FILE TAKES MAY BE A FUNCTION OF THE SEQUENCE OF SERVERS WHICH ARE NEEDED TO ACHIEVE THE SERVICE. IT ISN'T OBVIOUS TO ME AT THIS POINT WHETHER WE SHOULD PUT THE BURDEN OF ALL SUCH SERVICES ON A SINGLE MAIL SYSTEM OR CONTEMPLATE MANY SUCH SYSTEMS. ECONOMY SUGGEST THE FORMER BUT SANITY MAY SUGGEST THE LATTER. VINT  Date: 26 Jun 1982 0442-PDT From: Jon Solomon Subject: Re: Unexplored Topic -- Length of Mail Message To: CERF at USC-ISI cc: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 25-Jun-82 1958-PDT Ok, I guess I interpret your message as saying that we should not confuse Mail processing with general File Transfer, but the fact remains that people who will probably try to use this (e.g. mailing to a uucp or CSNET host) as a file transfer protocol, which breaks some of the implementations currently in use. If a message times out or is somehow incomplete, it seems that half the servers simply throw the incomplete message away, while the rest of them try to deliver a part of the message. The real problem comes when a mail sender expecting the latter meets a server which does the former. The user process requeues the message (because it expects the server to throw it away), and the server tries to deliver it, because it thinks the sender process is going to dequeue it (saying "Oh well, I tried"). The result is (or was, in our case) one message every half an hour being sent to the same address. We filled up a disk pack on both the system we were trying to send to (UCI) and the gateway to CSNET at UDEL! While we may not need to deal with this in the ARPANET frame, it is reasonably cost effective for someone to set up a trivial mail server/sender processor on their system, one which could use dial up phone lines to do the actual delivery. In this context a mail system also doubles as primary file transfer mechanism. A timeout in this context could be disastrous (especially if server and sender don't agree with what to do with the message, see above), if not expensive (in phone bills alone). On the other hand, if you don't time out then the possibility of a connection hanging could interrupt mail service for quite some time. I tend to vote for the timeout issue being a local (i.e. host related) issue, while the protocol to deal with what to do with a failed message might be part of SMTP, but couldn't we make some statement of preference? I would think that the best idea is for the sender to requeue, and the server should discard, incomplete mail (mail that it KNOWS is incomplete). Does anyone out there disagree? I'm still confused as to where this type of statement belongs. --JSol -------  Date: 26 Jun 1982 0816-EDT From: Dan Subject: MAIL as FTP To: header-people at MIT-MC A crucial differenct between MAIL and FTP is that FTP is receiver-controlled, whereas MAIL is sender-controlled: i.e. you may find it very convenient to mail the entire source to the monitor, but I may not wish to pay for the storage when I receive it, and I have no way of stopping you from sending it other than restricting the length of incoming messages. It seems to me that a request/response system would be better for unattended FTP (where the receiving server could match up incoming files with outstanding requests). I suspect that this discussion is getting out of the province of header-people (I don't know what list it's appropriate for, maybe protocals) Dan -------  Date: 26 Jun 1982 1126-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: MAIL as FTP discussion - can we move it to MsgGroup? To: Header-People at MIT-MC cc: Tappan at BBNG I think Dan is right - this discussion is larger than Header-People's restricted domain. I propose moving it to MsgGroup; for those few who may not be familiar with MsgGroup, the public [OFFICE-3]INTEREST-GROUPS.TXT entry for it is enclosed here. Cheers, Rich --- MsgGroup at BRL (or at MIT-ML) Interest in electronic mail, message formats, message systems, and the sociological implications of the above. Archives are kept at USC-ECL in files MSGGROUP.*, where * stands for a range of messages, in blocks of 100 (from 0001 thru 1100) or 50 (from 1101 on up) (MSGGROUP.0001-0100, MSGGROUP.0101-0200, MSGGROUP.1101-1150, etc.). As of 5 May 82, the last file was *.1701-1750. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to MsgGroup-Request at BRL (or at MIT-ML). Coordinator: EStefferud at USC-ECL/MsgGroup at USC-ECL -------  Date: 26-Jun-82 14:02:33-EDT (Sat) From: mark@Berkeley (Mark Horton) Subject: Re: Unexplored Topic -- Length of Mail Message Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jun-82 14:02:34-EDT (Sat) To: Header-People@MIT-MC@Berkeley I'm glad Jon brought this up. I'm not sure I have the answer, but I certainly will defend to the death the right of a site not to have to serve as a forwarding service for huge files! Certainly each site should have the right to set an upper limit on individual message size, or on number of bytes or messages per unit of time from a particular site or user to another particular site or user. We might also want to set a lower limit - that is, each site must allow messages of up to X bytes (unless it disallows the message for some other reason, of course). While we're on this topic, let me throw a couple of other thoughts out into the ring. First, I think RFC 733 requires all 128 ASCII characters to be allowed in the message. I believe that some systems do strange things to certain non-printing characters, and would like to see this restricted to printing ASCII plus certain control characters, for example space, tab, backspace, and the CRLF combination. It is not reasonable to assume that a 7 bit binary file will make it through intact, but the new standard leaves me with the impression that it is expected to. Here's another one: what about the famous escape sequence security bug? (This is the one in the LA times several months ago - the one found at Berkeley, but that some people have known about for years). This is where a security breaker, say joe, knows that sam@isi, who is a wheel, uses an HP 2645 (say). So he mails sam a message containing the escape sequence to load sam's function keys with a string containing a bad deed, then remotely triggers the function key. There are lots of variations - he creates a file with name porno.joke containing the escape sequence; the subject contains the sequence, he writes a program to write it on sam's terminal; the sequence can also vary: it can put the bad deed on the screen and get the terminal to transmit the screen or line, then erase the evidence, or it can load it into the function key where it waits for the sam to press the key, etc. I propose that RFC 733 mail and all mailers adopt the following rule: all control characters except for a set of a few well defined "harmless" characters such as above will be deleted from all mail send, received, or forwarded. (Not just escape, because some terminals use other codes. I don't know what to do about hazeltines with their ~ sequences.) This has been implemented in netnews for a few months now, and the only problem was that we had to add backspace to the allowed set. Mark  Date: 26 June 1982 1621-EDT (Saturday) From: Craig Everhart at CMU-10A To: mark at UCB-C70, Craig.Everhart@(Mark@Berkeley, Craig.Everhart@Horton)@Berkeley Subject: Bogus characters in mail text CC: Header-People@MIT-MC, Craig.Everhart@at@Berkeley, Craig.Everhart@UCB-C70@Berkeley Reply-To: Rdmail at CMU-10A In-Reply-To: mark@Berkeley's message of 26 Jun 82 13:02-EST Message-Id: <26Jun82 162106 RD00@CMU-10A> I always viewed the defense of terminals against infiltration by random text a province of the operating system, or perhaps of the mail reader. The interchange format that the machines see is not the same as the sequence of characters that must be transmitted to a person's terminal.  Date: 26 Jun 1982 1450-PDT From: Jon Solomon Subject: [Craig Everhart at CMU-10A: Bogus characters in mail text] To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 This is just an example of the sort of lossage we are faced with. Does anyone really understand how this header got mangled so badly? --------------- Date: 26 June 1982 1621-EDT (Saturday) From: Craig Everhart at CMU-10A To: mark at UCB-C70, Craig.Everhart@(Mark@Berkeley, Craig.Everhart@Horton)@Berkeley Subject: Bogus characters in mail text CC: Header-People@MIT-MC, Craig.Everhart@at@Berkeley, Craig.Everhart@UCB-C70@Berkeley --------------- Hmm, perhaps not everybody got it this mangled, am I the only one afflicted with this bug? --JSol -------  RMS@MIT-AI 06/26/82 18:45:10 Re: protection against mail files with escape sequences. To: header-people at MIT-MC The proper solution to this problem, if you care about it, is to either 1) remove the security from your system, making it a moot point, or 2) have ordinary ASCII mode output on your system (or whatever mode if used for printing out random files) convert all invisible characters to visible ones. (There would be other modes available for use by programs that really do want to control the display). Since ITS does both of these things, it is not only useless but also impossible (without patching the system) to use that trick. Meanwhile, people frequently mail BUG-EMACS samples of TECO code which contain control characters and Altmodes ("escapes"), and it would be a total screw if they could not. (It doesn't screw the recipients. They read their mail with EMACS, and invisible characters all display as something). I've been sensitized for a long time to the way that security measures involve a great deal of imposition on others. But this is the biggest imposition, on the most people, that I've ever heard suggested. Perhaps some of the rest of you were also grossed out by it. If so, I'd like to ask you to think of it when you think about other security measures, both proposed and already existing. Perhaps they, too, are screwing people in ways that you haven't thought about. ITS's treatment of nonprinting characters was implemented as a feature -- so you could read files containing them -- not as a security measure. Because TECO uses text files containing all 128 ASCII characters, including stray CR and LF, it would be nice if any string of ASCII characters can be transmitted in the text of a message. It doesn'T matter if some systems can't originate or ultimately receive such messages, since presumably the places where people find it useful to do one or the other will arrange that they can. But any gateways or forwarders ought to handle them.  Date: 26 Jun 1982 1837-PDT From: Mark Crispin Subject: mail files with funny characters Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC, RMS at MIT-AI Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think it is a foregone conclusion that the transport protocol is not the right place to fix the security bugs with terminal control sequences. It's ridiculous to propose, as RMS does, that just because somebody suggests an improper solution to a security bug that attempting to have security (or more accurately privacy) is wrong. Most people seem to prefer the luxury of having their electronic mailboxes private and readable only by them. -------  Date: 26-Jun-82 18:43:22-EDT (Sat) From: cbosgd!mark@Berkeley (Mark Horton) Subject: mail as ftp Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jun-82 18:43:23-EDT (Sat) To: cbosgd!header-people@mit-mc@Berkeley I can speak with some experience here because I've seen mail used as FTP lots of times. You people on the arpanet have the luxury of an FTP protocol that can talk between any two hosts, so it's reasonable for someone who wants a file to just grab it directly via ftp. On the other hand, those of us on dialup networks, such as UUCP (and presumably Phonenet), have no way to request a file from a site more than one hop away. The sender can't send it over more than one hop, either. And when several networks are involved, it's downright hopeless. I am at least 4 hops and 3 networks away from the arpanet, and if I want a file without using mail, I have to log in on arpanet host ucb-c70, ftp the file to there, then berknet it to a machine on the UCB ethernet, ethernet it to a machine on uucp, and then uucp it to my home machine. (Whew!) The Berknet and UUCP hops are spooled, so it isn't even reasonable to wait around for them in real time. On the other hand, if I just have the person who posted the file mail it to me (or even log in on ucb-c70, ftp it over, and mail it to myself) life is much more manageable. People use mail to transfer (text) files because it works, even across network boundaries. It's not convenient, because the receiver has to unpackage the file or files. But it happens all the time. There is no need to have special provisions for FTP in any mail standard, as I see it, because it's easy to write a program to receive things automatically and store the contents in a file. (Easy if your mail system allows mail to a particular name to be processed automatically by a program - something that seems to be lacking in many mailers these days.) Also, unless all the networks involved supported these extra features, it would be worthless. Getting UUCP extended for such things is hopeless. By the way, I hope I made a point with these last paragraphs. If I have a wide terminal, I could easily generate huge lines. I suspect many of you were a bit annoyed by having to read text formatted like that. The 80 column assumption pervades almost everything we do (try logging in on one of those personal computer systems at 300 baud with 40 column screen formatting sometime to see what I mean) and it's essentially impossible to get rid of it. So let's encourage people to put out reasonably formatted lines, that will look decent on most screens. We're not requiring it, just recommending it. Mark  Date: 26 Jun 1982 23:47:19 EDT (Saturday) From: Dan Franklin Subject: Re: Unexplored Topic -- Length of Mail Message In-Reply-to: Your message of 26-Jun-82 14:02:33-EDT (Sat) To: mark at Berkeley (Mark Horton) Cc: header-people at mit-mc RFC733 is an entirely inappropriate place to address the issue of escape characters in mail messages which might conceivably cause harm. As RMS points out, the correct place to solve the problem is in the operating system, not an internet mail standard! In fact, my impression is that the only operating system RFC733 impinges upon which provides no way to display control characters as printing chars on output is standard UNIX. It is clearly wrong to patch RFC733 in order to get around a UNIX deficiency-- since it is both unnecessarily limiting (for users who use other operating systems or need to receive special characters for other reasons) and incomplete (it doesn't solve the problem for local mail, or files I get you to look at, or off-the-wall terminals that interpret printing characters). I do agree with Mark that it would be a good idea to include a "least upper bound" on message size, perhaps 4096 bytes. But this is probably more the province of the SMTP specification than RFC733. Dan Franklin  Date: 27 June 1982 0116-EDT (Sunday) From: Craig Everhart at CMU-10A To: Jon Solomon Subject: Re: Bogus characters in mail text CC: Header-People at MIT-MC Reply-To: Rdmail at CMU-10A In-Reply-To: Jon Solomon@USC-ECLC's message of 26 Jun 82 16:50-EST Message-Id: <27Jun82 011651 RD00@CMU-10A> Apparently, everybody's copy got mangled. The message I was answering was addressed to "Header-People@MIT-MC@UCB-C70", and I replied to that address without looking at it carefully. I tried to stop the mail delivery once I spotted the delivery to UCB-C70, but I didn't catch it in time. Here is a copy of the original header: Date: 26 June 1982 1621-EDT (Saturday) From: Craig Everhart at CMU-10A To: mark at UCB-C70 (Mark Horton) Subject: Bogus characters in mail text CC: Header-People@MIT-MC at UCB-C70 Reply-To: Rdmail at CMU-10A In-Reply-To: mark@Berkeley's message of 26 Jun 82 13:02-EST Message-Id: <26Jun82 162106 RD00@CMU-10A> The mailer at UCB-C70 (i.e. Berkeley) received this, munged the header lines somehow, and redistributed it to MIT-MC. Apparently the header line munging might have been appropriate had the mail been delivered from somewhere in UUCP-land, but was inappropriate as applied to this message from the Arpanet. While I'm here, I believe Ed Taft's message suggested that the mail readers do the breaking of words into lines, not the mail senders. This seems like an elegant extension of what we all mean by spaces and CRLFs in English (prose, poetry, and programs) text. I can only recommend wider usage of this interchange format.  Date: 27 June 1982 0202-EDT From: Rudy.Nedved at CMU-10A To: Header-People at MIT-MC Subject: two cents, problems Message-Id: <27Jun82 020229 EN10@CMU-10A> My two cents for the record: Can't we agree that the new RFC 733 is for sending TEXT and nothing else? I fail to understand why anyone would want to send escapes, control-c's or any other non-printable/non-formatting characters unless they are trying to do something fiendish or using the mail system in a bizarre and unintended way. As for the length of the message: If the file is huge, dequeue it until it is feasible to send it. People do send long answers or send drafts via the mail system.....consider it third class mail and let the first class mail get thru. Anyhow, could someone answer the following questions: How does one handle the Return-Path, Sender and From lines when a piece of mail goes thru a site which only supports FTP/MLFL but the sending site supports both FTP and SMTP? Is the sending site suppose to parse the message and munge a new sender line?..oops multiple at-signs are illegal...hmmm What about high priority messages versus low priority, like sending mail about a meeting that will happen in two days? If it gets caught on a host that tries for two weeks to send mail before sending an error message back to the sender, well that burns the sender....he could have called his friend/colleague and talk to him/them. -Rudy  Date: 27 Jun 1982 0000-PDT From: Richard Furuta Subject: Shuffled headers To: header-people at MIT-MC cc: Furuta at WASHINGTON, mark at UCB-C70 I wonder if someone out there in uucp-land might explain to me why it is that the shuffling of Craig Everhart's message header took place. Frankly, I have been mystified by the headers produced when using the "reply" command to respond to uucp mail. If I remember correctly, replying to a message from "harpo!groucho!gummo!chico" will generate responses to "harpo!groucho!gummo!chico", to "groucho!gummo!chico", to "gummo!chico" and to "chico". Why? And why did it take such an innocent looking header like Craig Everhart's and produce the mangled mess we all received? --Rick -------  Date: 27 Jun 1982 0514-PDT Sender: CERF at USC-ISI Subject: Re: Unexplored Topic -- Length of Mail Message From: CERF at USC-ISI To: JSol at USC-ECLC Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]27-Jun-82 05:14:08.CERF> In-Reply-To: Your message of 26 Jun 1982 0442-PDT I WILL CHEAT A LITTLE AND COMMENT ON THE MAIL AS FILE TRANSFER, DESPITE THE FACT THAT IT WILL PROBABLY HAVE MOVED TO MSGGROUP BY THE TIME THIS RESPONSE REACHES MOST PEOPLE. WE HAVE HAD THE LUXURY OF A FAIRLY ROBUST AND RELIABLE MAIL SYSTEM IN THE ARPANET ENVIRONMENT. THIS BIASES ME TOWARDS THE VIEW THAT PARTIAL MESSAGES OUGHT TO BE DISCARDED - ARBITRARY ACTION TO TRUNCATE MESSAGES MAY BE HARD FOR A SENDER TO COPE WITH, SINCE IT CANNOT NECESSARILY PREDICT WHICH INTERNEDIATE FORWARDERS WILL HANDLE THE MESSAGES NOR WHAT THEIR LIMITS MIGHT BE. I CONFESS, HOWEVER, THAT SINCE I HAVEN'T HAD TO LIVE IN THE PHONENET/UUCP WORLD (FOR WHICH I AM GRATEFUL), I DON'T APPRECIATE ALL THE THINGS WHICH EVIDENTLY LEAD THAT WORLD TO TRY TO DELIVER TRUNCATED MESSAGES. GENERALLY, I CONSIDER IT A RUDE ACT TO SEND OUT, UNBIDDEN, A REALLY BIG FILE/MESSAGE (SAY OVER 50000 TO 100000 CHARACTERS). SOME TIME AGO, A PERSON MAILED TO A SIGNIFICANT LIST A 250000 CHARACTER MESSAGE WHICH CLOGGED THINGS UP PRETTY BADLY. THE ADVICE AT THAT TIME WAS TO SEND NOTICES SO WE COULD FTP AT OUR CONVENIENCE. IN SYSTEMS WHICH HAVE NO DIRECT FTP SYSTEM, THIS STRATEGY ISN'T AVAILABLE. HOWEVER, IT DOES SEEM TO ME THAT ONE WANTS AN ANALOG - EVEN IF ONLY A MAILBOX WHICH CAN RESPOND TO FTP REQUESTS. HOW THIS WOULD WORK ISN'T CLEAR, SINCE SOME FTP SYSTEM WOULD LIKE PASSWORD/LOGIN AND ONE REALLY DOESN'T WANT TO LEAVE PASSWORDS AROUND IN MESSAGES. PERHAPS A MESSAGE-BASED "FTP" SYSTEM WOULD ONLY APPLY TO PUBLIC FILES? VINT CERF  Date: 27 Jun 1982 11:48:50-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 25 Jun 1982 1715-PDT (Friday). Yes indeed mail can be BIG!! If you don't have FTP to some random system (again, not ARPAnet, most likely), but DO have mail, you do a LOT with it, like abuse it into make-do FTP. It is crass, but it beats not getting the bits there! This can often be the case with site 2 networks away in the internet (note small "i"). While this shouldn't impact ARPAnet sites too much, if 733 is indeed something the larger world might look to for guidance, I would advocate JSol's position: Mail is another form of machine-machine communications, complete unto itself. As an example, the "net.sources" news topic on USENET routinely posts fixes and entire source listings of quite complex programs; and this is on a network with 300 or 1200 baud hop-by-hop links!! I am not saying this is the ulitimate solution, or that we should advocate such things, but it does indicate the tremendous utility of Mail in reducing the isolation of sites. -Mike  Date: 27 Jun 1982 1333-PDT From: Mark Crispin Subject: using mail as FTP Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am sympathetic to the people outside of ARPANET who aren't able to FTP files from the ARPANET. However, I still must disagree on the issue of whether or not it justifies using mail as an FTP. This is an issue which is -- and should be -- something which should be considered by each individual site's management. Many electronic mail systems are set up as single channel transmission entities. Also, there is the issue of who pays for this "FTPing". In a great many systems, electronic mail delivery is a service provided by the system as part of system overhead, under the presumptions that: (1) Electronic mail benefits all users of the system. (2) It is cheaper overall for electronic mail to be part of system overhead. (3) Electronic mail's cost to the system are small enough that it is acceptable to charge it to overhead. But once we leave the fantasy-land that is ARPANET, we have the problem of who pays for the service. In a commercial environment, the cost of electronic mail could be absorbed as part of system overhead. That system will just charge a little more, say for connect time; or perhaps the system sells electronic mail services. So the model is still valid. The model will break down, though, if electronic mail is used as an FTP service. A single-channel mail delivery process can be tied up for an inordinately long period of time with a long message. The data transmission costs of such a message are also significantly greater than the "typical" message. Commercial environments would feel the effects of this first, but even in our research world we aren't immune to the effects; even if the "only" effect is that mail is bogged-down for a few hours. I don't want to argue about whether or not the model is any good of what whizz-bang models people can think of to replace this. The fact is, this is not an uncommon model. A number of installations really do not want to pay hundreds of dollars in data transmission costs to provide somebody a free file transmission service. The advantage of FTP is that the agent who benefits from the transfer is generally the one that pays for it (or at least is chargable for it). This is at least one reason I believe we have not yet seen "FTP spoolers" in general use (they do exist on some other networks, mostly research fantasy-lands). The point to all this is, an installation must have, as its inalienable perogative, the right to set a maximum limit on the size of a message. Anything in the standard relating to this should merely be recommendations. I would be happy with wording such as: "It is recommended that there be no limit upon the size of an electronic mail message. However, if implementation considerations dictate that there be a limit, a minimum of ***** bytes is recommended." I think that 20,000 or 50,000 are good numbers to insert there, reflecting the great majority of electronic mail traffic. If this sounds heartless to those who can't get a 250,000 byte document any other way, I guess it is. They can either manually FTP it (in the painful way Mark Horton suggests), or they can get the document sent by US mail in hardcopy or on tape. If the document is large enough, it could very well be cheaper and faster to send it Federal Express on a tape! -- Mark -- -------  Date: Sunday, 27 Jun 1982 13:58-PDT To: Jon Solomon Cc: Header-People at MIT-MC Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 25 Jun 1982 1703-PDT. From: greep at RAND-UNIX If you want to send a long file via mail and your mailer doesn't let you, what is so hard about having a program to break it up into smaller files, putting the sequence numbers in the subject field, and repackaging them at the other end? This should be trivial compared with tasks such as parsing an address like: Phil O. (b@man) Dendron  Date: 27 Jun 1982 1509-PDT From: Jon Solomon Subject: Re: Unexplored Topic -- Length of Mail Message To: greep at RAND-UNIX cc: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 27-Jun-82 1409-PDT Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 25 Jun 1982 1703-PDT. From: greep at RAND-UNIX If you want to send a long file via mail and your mailer doesn't let you, what is so hard about having a program to break it up into smaller files, putting the sequence numbers in the subject field, and repackaging them at the other end? This should be trivial compared with tasks such as parsing an address like: Phil O. (b@man) Dendron What is missing is not a method for doing this, but a clear understanding of what to do if you have to deliver a large message and it times out while being delivered. We aren't imposing a limit on the size of a message network wide, and we (pretty much) are going to let the individual hosts determine what the maximum message will be. If your mailer won't receive large messages but my mail sender will, then there has to be some way for my mailer to ask your sender what the limit is, even if that means sending you the message, and waiting for an error reply from it saying something like "Sorry, message to large, please break it up". Currently that is pretty much the only way for a sender to know that the receiver has choked on the message. Also, it is not clear that current implementations are doing the right thing with incomplete messages. I think we all seem to agree that incomplete messages should be requeued by the sender and not sent on by the receiver program, not everybody's implementation does this. Should we REQUIRE that this happen? If so, in which RFC does it belong? Probably not Son-of-RFC733. What does perhaps belong there is a header which displays the length of a message. What do you think of having the sender process calculate the size of a message and put it in a field? TENEX and TOPS-20 do this, only it keeps this information separate from the message itself. I think it is such a good idea, and could help solve some of the problems with large messages (if coupled with support in SMTP to permit the sender to ask the receiver what its maximum message size is). Any comments? --Jsol -------  Date: 27 Jun 1982 1509-PDT From: Jon Solomon Subject: Re: Unexplored Topic -- Length of Mail Message To: greep at RAND-UNIX cc: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 27-Jun-82 1409-PDT Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 25 Jun 1982 1703-PDT. From: greep at RAND-UNIX If you want to send a long file via mail and your mailer doesn't let you, what is so hard about having a program to break it up into smaller files, putting the sequence numbers in the subject field, and repackaging them at the other end? This should be trivial compared with tasks such as parsing an address like: Phil O. (b@man) Dendron What is missing is not a method for doing this, but a clear understanding of what to do if you have to deliver a large message and it times out while being delivered. We aren't imposing a limit on the size of a message network wide, and we (pretty much) are going to let the individual hosts determine what the maximum message will be. If your mailer won't receive large messages but my mail sender will, then there has to be some way for my mailer to ask your sender what the limit is, even if that means sending you the message, and waiting for an error reply from it saying something like "Sorry, message to large, please break it up". Currently that is pretty much the only way for a sender to know that the receiver has choked on the message. Also, it is not clear that current implementations are doing the right thing with incomplete messages. I think we all seem to agree that incomplete messages should be requeued by the sender and not sent on by the receiver program, not everybody's implementation does this. Should we REQUIRE that this happen? If so, in which RFC does it belong? Probably not Son-of-RFC733. What does perhaps belong there is a header which displays the length of a message. What do you think of having the sender process calculate the size of a message and put it in a field? TENEX and TOPS-20 do this, only it keeps this information separate from the message itself. I think it is such a good idea, and could help solve some of the problems with large messages (if coupled with support in SMTP to permit the sender to ask the receiver what its maximum message size is). Any comments? --Jsol -------  Date: 27 Jun 82 17:21:08 EDT (Sun) From: Steve Bellovin Subject: Maximum lengths, robustness To: header-people at Mit-Mc Via: UNC; 27 Jun 82 18:56-EDT I agree that some sort of statement on length is needed, though I also agree that it's really in the province of SMTP. But I've broken assorted mail readers on PDP-11s by sending over files >64K bytes, which is probably an unreasonable thing to do to start with. The real question for this group, though, is what, if anything, 733' should contain to alleviate the problem. It probably shouldn't have a length field; SMTP should be able to calculate that for itself. But it might be reasonable for the header to contain information that would aid in recovery from problems. One way this can be done is to *require* a Message-Id field; that way, a mail receiver that constantly chokes on the same message can (in principle) detect the fact and finally reject it (at the SMTP level). Similarly, such a field could be used by SMTP' to segment messages. Finally -- and in a totally different vein -- the universal presence of such fields would vastly aid more sophisticated mail systems. The other field that might be helpful is a "Precedence" field, such as the one in the proposed NBS standard. It would allow mail senders and receivers to transmit high-priority messages first; these are especially useful when the note you want to send says "hey -- your mail system is locked up trying to send a 300K file here". Here, I speak from sad experience; our line to UDel-Relay was blocked last month when XMAILR kept sending the same large file fragment through them to us.  Date: 27 Jun 82 19:03:38 EDT (Sun) From: Steve Bellovin Subject: Re: Unexplored Topic -- Length of Mail Message To: CERF at Usc-Isi Cc: header-people at Mit-Mc In-Reply-To: CERF at USC-ISI's message of 27 Jun 1982 0514-PDT <[USC-ISI]27-Jun-82 05:14:08.CERF> References: Your message of 26 Jun 1982 0442-PDT Via: UNC; 27 Jun 82 19:40-EDT Yes, a message-based FTP can and should be implemented -- but it will depend on mail to send the files, and thus have to contend with any length or character set restrictions in the mailer.  Date: 27-Jun-82 22:26:55-EDT (Sun) From: cbosgd!mark@Berkeley (Mark Horton) Subject: mail as FTP Via: cbosgd.uucp (V3.94 [3/6/82]); 27-Jun-82 22:26:56-EDT (Sun) To: cbosgd!header-people@mit-mc@Berkeley Mark Crispin has misinterpreted what I said, leading me to believe that I said it wrong and others have misinterpreted me too. While many people use mail as ftp, simply because it works and nothing else does, most files transferred are quite small. These behave much like ordinary mail, passing through quickly and with no problem. Very few sites complain about passing such mail through. However, some people do on occasion abuse this priviledge by mailing themselves a huge file. (The Berkeley gateway was once shut down for many months because of one company on the east coast apparently mailing zillions of files from a UNIX machine on UUCP, through Berkeley, onto the ARPANET and to another machine at the original company on the east coast!) Obviously sites have the right to restrict forwarding if they feel they are being abused. By the way, it is probably not a good idea to put something in the standard implying a site is antisocial if it doesn't allow files at least X bytes through unrestricted. This just gives an abuser carte blanche to break up his file into lots of x-1 byte messages. This is even worse than one huge message in some ways, since shortest-job-first queuers will not give it the low priority it deserves. By the way, we do have an "ftp spooler" in uucp land - the original command "uucp" (unix to unix copy) spooled a file to be sent to another system. Everything else has been built up on top of that primitive operation, which has resulted in some rather strange software! It works over dialup lines. Phone costs aren't the problem (most of uucp is at Bell Labs, which has access to WATS lines and in general doesn't tend to be too worried about phone bills) - rather the problem is that (1) uucp won't copy files over indirect links, (2) uucp does not route or otherwise make indirect links appear direct, (3) there is no notion of an "ftp gateway" allowing different nets to transfer files, the way mail can be sent between networks. Mark  Date: 27 Jun 1982 19:10:52-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: smb.unc at UDel-Relay cc: header-people at Mit-Mc Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 27 Jun 1982 1737-PDT (Sunday). I second the motion for a mail-based FTP facility (such has been proposed for the UUCP world to deal with news archives). While the proposed "precendence" field might not always be honored, at least sites so concerned could have the information needed if they wanted to schedule such replies during off hours. Making the message-id field mandatory is also a good idea. "Netnews" in the UUCP world has used it to do "hot-potato broadcasts" for a long time. It would be a real debugging aid, also. -Mike  Date: 28 June 1982 1052-EDT (Monday) From: David.Lamb at CMU-10A To: header-people at MIT-MC Subject: Re: using mail as FTP and Unexplored Topic -- Length of Mail Message In-Reply-To: Mark Crispin@SU-SCORE's message of 27 Jun 82 15:33-EST, greep@RAND-UNIX's message of 27 Jun 82 15:58-EST Message-Id: <28Jun82 105221 DL10@CMU-10A> Mark Crispin raised the valid point that a site may not wish to pay the cost (or be able to pay the cost) of mail-as-FTP. However, given greep@RAND-UNIX' suggestion of splitting long messages into pieces, there is no way to avoid this - you can only make it inconvenient, not impossible, to do so. It's worthwhile discussing this kind of problem, but any decisions would more properly belong in whatever succeeds SMTP (Complex Mail Transfer Protocol, perhaps?) rather than Son-of-RFC733.  Date: 29 Jun 1982 1539-EDT From: Larry Campbell To: CERF at USC-ISI, JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: Unexplored Topic -- Length of Mail Message Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11835754168.33.71.28963 at DEC-MARLBORO> Regarding: Message from CERF at USC-ISI of 27-Jun-82 0814-EDT In-reply-to: <[USC-ISI]27-Jun-82 05:14:08.CERF> A simple solution to the large message problem would be to have, as part of the protocol, the sender inform the receiver of the size of the message BEFORE transmitting it. This gives the receiver an opportunity to say "Woops, no, that's way too big", before all the net traffic and disk space gets spent. That way it's up to each receiver; personal machines might refuse all but the smallest of messages, while giant mainframes with terabit memories might accept anything. --------  Date: 29 Jun 1982 1304-PDT From: POSTEL at USC-ISIF Subject: rfc 733 revision To: header-people at MIT-MC i vote for being able to send very large messages (say up to 250,000 characters), and i vote to allow any of the 128 ascii codes as data in messages. --jon. -------  Date: Tuesday, 29 Jun 1982 13:08-PDT To: Larry Campbell Cc: Header-People at MIT-MC Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 29 Jun 1982 1539-EDT. <"MS11(2224)+GLXLIB1(1056)" 11835754168.33.71.28963 at DEC-MARLBORO> From: greep at RAND-UNIX There is already a mechanism for doing this in FTP (the medium used for Arpanet mail under NCP) - the ALLO (allocate) command. Unfortunately some sites don't handle this command, even to the extent of telling you that they're ignoring it. For example, Tenex, which apparently doesn't care much about talking to anything besides other tenexes, requires logging in before accepting this command, and then returns a "not implemented" error message. It would be possible of course to pass the length as part of the header, but then the server has to (1) parse the header, and (2) be able to tell the sending host to stop transmitting if it decides that the message is too long.  Date: 29 Jun 1982 1346-PDT From: Mark Crispin Subject: message size/data Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In reply to Jon's message: I support allowing any of the 128 ASCII codes as data in messages. It irks the hell out of me that some TOPS-20 FTPSERs consider ASCII 003 as an interrupt command, as well as considering certain other characters as editing commands. At one time, XMAILR used MLFL to work around this problem, but it tickled a bug in the TOPS-20 NCP that nobody wanted to fix (the truncated large messages problem) so we reverted back to MAIL. The XMAILR world FTPSERs do allow all 128 ASCII codes in messages. XMAILR can/does/will support very large messages (the 250,000 characters Jon proposes), but will have a site-settable limit that can be smaller than that. 250,000 bytes is larger than some (minimum service) users' disk quotas! Actually, for us 250,000 characters isn't much of a hardship for incoming mail. Incoming mail goes through multiple channels (multiple FTP servers), and local disk access time isn't bad. The mailer queues at SCORE are audited enough so that if the message is a clear-cut loser it will be manually removed. It's outgoing mail that hurts us, or incoming mail that we are obligated to relay. A site ought to have the perogative to decline to relay a overly-large message, as well as to prevent its local users from sending messages larger than a certain size by management policy. -------  Date: 29 Jun 82 18:25:15-EDT (Tue) From: Dave Crocker To: Header-People at Mit-Mc Subject: More queries Folks -- I'd like some feedback on a couple more, relatively minor points. These are further changes that I would like to make to the standard: Allowing LWSP-chars on the header/body dividing lines. This is a common error and it might be best to make it legal. Specifically, some user software has put a space or tab on an otherwise empty line, which serves as the header/body delimiter. It seems to be a common enough implementation error that it might be worth defining it as legal. The modified syntax would be: message = fields (*LWSP-char CRLF *text) Getting some agreement on a standardized site mailbox name for the system administrator, so that people can know of at least one valid address for a site. I have no personal preference on the string, as long as it is written into the standard. In date/time, make seconds optional and prohibit any of the dashes as dividors. In the current draft, I took the dash from the time/timezone delimiter, but not between the date components. Might as well clean them up, too. Make the route sequence field look just like a domain sequence, with the combination looking like: Postel <@udel-relay.usc-isi:postel@usc-isi.arpanet> where the dots serve the same purpose as the commas, in the original route spec. This means that an at-sign introduces a reference-sequence and the context determines whether it is a domain or a route. The resulting syntax would be: route = at domain ":" Removing " at ". With the other requirements we are imposing, this is rather minor, but seems rather persistant as an irritant. In the scheme of pushing towards being an interchange standard, rather than heavily human-, and display-, oriented, this seems reasonable. It has, rather frequently, been pointed out that there is nothing to prevent user interface programs from accepting " at " and converting it. Note that this sort of thing is often done, already, for permitting short-form specification of local addresses. The user interface then adds on the local host name. (For reference, this is a reversal; I'm giving in to the arguments from Taft, et cie.) Dave  Date: 29 June 1982 19:55-EDT From: Earl A. Killian Subject: Unexplored Topic -- Length of Mail Message To: LCAMPBELL at DEC-MARLBORO cc: HEADER-PEOPLE at MIT-MC This was originally in the SMTP spec, or at least talked about. It was removed when it was pointed out that the sender might have to make a pass through to entire message in order to compute it (i.e. internally not every system stores its messages the same way they're transmitted). Nevertheless, I think the functionality is useful enough that it deserves to be an optional parameter in SMTP. For example, it would allow you to reject messages ahead of time that will fail later due to quota or disk space problems.  Date: 29 Jun 1982 1655-PDT From: Jon Solomon Subject: Re: More queries To: dcrocker at UDEL-RELAY cc: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 29-Jun-82 1525-PDT re: Allowing LWSP chars on the header/body dividing lines. I am concerned that the standard already considers a LWSP char to mean that this line is a continuation of the previous header line. This is a bit ambiguous, because it implies that either we can't continue the last line of the header, or we have to parse the line and if there are no characters on it then we know that it is the separator line. Re: Getting some agreement on a standardized site mailbox name for the system administrator I agree. LIASON is my choice of name. Date/time - I have no opinion on this and am content to go with the general consensus, however I would suggest if the trend is to structure such headers, make the structure as simple to handle as possible. The same argument for dashes applies to " at " in the mailbox addresses (see below). Route sequence - I am confused by reading this header, perhaps I'm not the only one. Do we really need @signs, .'s and :'s all in routine address? I'm not sure how to parse that route string. Removing " at ". In the interest of defining an interchange standard, I'll agree that it should be flushed. Cheers, --JSol -------  Date: 29 June 1982 2013-EDT (Tuesday) From: Craig Everhart at CMU-10A To: Header-People at Mit-Mc Subject: Re: More queries Reply-To: Rdmail at CMU-10A In-Reply-To: Dave Crocker\@UDel-Relay's message of 29 Jun 82 17:25-EST Message-Id: <29Jun82 201348 RD00@CMU-10A> I don't know why you want to remove the hyphen from date formats. It doesn't affect me or CMU much either way, as there are only a small number of date formats we'll put into mail, but we recognize lots of them--many non-standard! The idea of requiring some mailbox at all sites seems reasonable. Now, what's the function of this mailbox? Is it for when you're trying to find a person reputed to be at some site, but you don't know the mailbox name? Or, more generally, you're not sure how to spell their name? Or what names the mail server will accept for that person? Or is it to complain about, say, mail sent from a site, or bogus headers, or a bad implementation of protocol X, or like that? Ideally, it is all of these things, and is not the name of a person who is only politically responsible for a site. Actually, the Arpanet, and possibly the DoD Internet, has had a close relative of this facility in the NIC database. Our user Finger program recognizes the special host "NIC" to mean to consult the Network Information Center's database, rather than to use the Finger protocol on some matching host. Regardless of how we get at the protocol, this NIC service has proven to be valuable in just such circumstances: some other site is causing problems for a server or a daemon job, and to find out why you need to consult someone at the remote site. Finding out what NIC has to say about that site will usuallyu give you a code for the coordinator or liaison, and finding out what NIC has to say about that code usually gives a functional machine address of a responsible person. I believe the same information is in the Arpanet personnel handbook. About LWSP on the blank line between message header and body. I have seen more than one mail-generating program have a boundary condition wherein if a header line is just long enough, the program puts out a CRLF and some white space, in preparation for more list elements that never come. Then the next line to be generated starts a new header line fresh with a new CRLF. Mail readers I've used have had no trouble with such unaesthetic, but not ungrammatical, headers; they understand the white space characters between CRLFs not to indicate end-of-header. Changing the specification at this point might well ``break'' as many mail-generating programs as it ``fixes.'' Craig Everhart  Date: 29 Jun 1982 1742-PDT From: POSTEL at USC-ISIF Subject: rfc 733 revision To: header-people at MIT-MC Dave Crocker: re the route syntax HUH? how can one parse the route? if a message is explicitly routed via ISI.ARPA then FOO.DOD then X.Y.Z (all fully quallified domain named hosts, then does your proposed string read @ISI.ARPA.FOO.DOD.X.Y.Z: ??? --jon. -------  Date: 29 Jun 1982 1802-PDT From: POSTEL at USC-ISIF Subject: rfc 733 revision To: header-people at MIT-MC Dave Crocker: I think the requirement that the header be separated from the body by a null (not blank) line should be maintained as is. This is in the spirit of keeping things simple, and avoiding unnecessary variations and optional behavior. --jon. -------  Date: 29 Jun 1982 21:12:27 EDT (Tuesday) From: Dan Franklin Subject: standardized name To: header-people at mit-mc Re universal sitename: the word is actually spelled "liaison", not "liason", and that, I think, is a good reason to choose another name; there just aren't very many people who can spell it without a dictionary. (Unless you require the word AND two or three common misspellings...)  Date: 29 Jun 1982 2033-PDT Sender: GEOFF at SRI-CSL Subject: Re: standardized name From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: dan at BBN-UNIX Cc: header-people at MIT-MC Message-ID: <[SRI-CSL]29-Jun-82 20:33:17.GEOFF> In-Reply-To: Your message of 29 Jun 1982 21:12:27 EDT (Tuesday) Abrams' as NBS wrote RFC-763, "Role Mailboxes", on exactly this topic a number of years ago. I suggest it as the basis for `standardized names'.  Date: 29 Jun 82 20:43:44 EDT (Tue) From: Steve Bellovin Subject: Re: Unexplored Topic -- Length of Mail Message To: Earl A Killian , LCAMPBELL at Dec-Marlboro Cc: HEADER-PEOPLE at Mit-Mc In-Reply-To: Earl A. Killian 's message of 29 June 1982 19:55-EDT Via: UNC; 30 Jun 82 0:30-EDT We're getting a bit off the topic here, but.... one way to implement a size-limit that doesn't require an entire pass over the message first is for the SMTP server to give some special reply to MAIL (et al) indicating a quantum size -- after that many lines (or bytes; I'm not fussy), the sender must stop sending and read a go/nogo decision. Yes, that can clog things up while a big file is coming over, but as soon as a site discovers it can't handle it, it can wash its hands of the whole matter.  Date: 29 Jun 1982 22:28:38-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: More queries In-reply-to: Your message of 29 Jun 1982 1729-PDT (Tuesday). My vote for contact point is "liaison". -Mike  Date: Tuesday, 29 Jun 1982 23:00-PDT To: Admin.MRC at SU-SCORE Cc: Header-People at MIT-MC Subject: Re: using mail as FTP In-reply-to: Your message of 27 Jun 1982 1333-PDT. From: gaines at RAND-UNIX It is probably useless to set limits on the size of messages. Anyone wanting to transmit a large document via mail and faced with a limit will simply transmit the document in as many small peices as necessary.  Return-path: @USC-ISID,steve@ucl-cs Via: USC-ISID ; Wednesday, June 30, 1982 01:52:51-PDT Date: 30 Jun 82 8:19:36-BST (Wed) From: Steve Kille Reply-To: steve%ucl at isid To: Dave Crocker cc: Header-People at Mit-Mc, mailgroup at UCL-CS Subject: Re: More queries Dave, LSWP between header and body. Interestingly a group of UK implementors discussed this last week. There are problems relating to NIFTP which for some sites make it tricky to implement the specification as it stands. We suggested slackening the UK specification in this way. Therefore a definite vote for bringing this into RFC733. Steve Kille -------- Š  Date: 30 Jun 1982 8:12:09 EDT (Wednesday) From: Ken Pogran Subject: Contacting the administrator To: DCrocker@Udel-Relay Cc: Header-People@mit-mc Dave, Three suggestions come to mind: HELP is perhaps a little to obvious, and also doesn't carry the connotation of contacting an administrator (as opposed) to a consultant) LIAISON gets my personal vote. Except, it's hard to spell. Also, to what extent have nets outside the ARPANET carried over the ARPANET concept of a Liaison? ADMIN certainly gets the point across. But it's a little "jargon-ny". I might also point out that trying to come up with a "standard" mailbox for contacting the administrator could very well run afoul of names already in use at various hosts, possibly for other functions. Ken  Date: 30 Jun 1982 1027-PDT From: POSTEL at USC-ISIF Subject: rfc 763 To: header-people at MIT-MC Marshall Abrams NBS 7 May 80 Network Working Group Request for Comments: 763 ROLE MAILBOXES Occasionally it is necessary to send mail to someone on the net who is known only as the incumbent in an official position. Often the mail is undeliverable because of employee turnover. We have also had such a problem at NBS and have therefore created MAIL address synonyms such as SYSTEMS, MANAGEMENT, and LIAISON to ensure that mail is correctly delivered no matter who the incumbent happens to be. I suggest that all systems which permit MAIL address synonyms install them. I further suggest that the NIC or the ARPANet management select a standardized set of synonyms, thus increasing their utility. Marshall Abrams -------  Date: 30 Jun 82 10:52-PDT From: zsu at SRI-TSC To: dcrocker at Udel-Relay CC: Header-People at Mit-Mc, ZSu at SRI-TSC Subject: Re: More queries Dave, Your discussion of "route sequence" may deserve some attention. I am concerned with the impression we are leaving that route-based relative naming convention as that introduced in the "uucp" mail system is to be adopted in the Internet Naming Convention. The appearance of Section 6.2.7 "Explicit Path Specification" in the latest draft version of RFC733 revision I have (dated June 22, 1982, and I received from its distribution at the IFIP W.G. 6.5 NA System Group meeting in Boston) is especially disturbing. In that section you stated, and I quote, "At times, a message originator may wish to indicate the path that a message should follow. ... The portion ... specifies the sequence of hosts and/or transmission services, that are to be traversed. ... " In the message I am responding to you stated that "Make the route sequence field look just like a domain sequence, ... " It appears that you may be explicitly advocating relative naming. A point should be emphasized here is that what is allowed by the Internet Naming Convention should be strictly based on absolute (or sometimes referred to as "anchored") naming. We all know too well of the pitfalls of relative naming. Please correct me if I have misinterpreted your statements on relative naming. Also in your message, could you have mixed "relaying" with "route sequencing"? I believe only relaying is recommended in the SMTP specification. Relaying is distinctly different in nature from relative "route sequencing". The specification of SMTP relaying, to my knowledge, is for the purpose of providing interoperation capabilities. I don't believe source routing is one of its intentions. Regards, Zaw-Sing  Date: 30 Jun 1982 1418-EDT From: Dan Tappan Subject: Standard mailboxes To: header-people at MIT-MC A mailbox name that easy to remember, and impossible to misspell, is @ .... -------  Date: 30 June 1982 15:22 edt From: Charles Hornig at MIT-MULTICS Subject: Re: Standard mailboxes Sender: Hornig.Multics at MIT-MULTICS To: header-people at MIT-MC In-Reply-To: Message of 30 June 1982 14:18 edt from Dan Tappan @ has its problems too. MIT-devMultics (for which I am the liaison) is universally referred to as CISL. I think that few would remember to send mail to MIT-devMultics@CISL.  Date: 30 Jun 1982 1709-EDT From: Dan Tappan Subject: Re: Standard mailboxes To: BILLW at SRI-KL cc: Tappan at BBNG, header-people at MIT-MC In-Reply-To: Your message of 30-Jun-82 1451-EDT Date: 30 Jun 1982 1151-PDT Sender: BILLW at SRI-KL Subject: Re: Standard mailboxes From: BILLW at SRI-KL To: Tappan at BBNG Message-ID: <[SRI-KL]30-Jun-82 11:51:03.BILLW> In-Reply-To: Your message of 30 Jun 1982 1418-EDT A mailbox name that easy to remember, and impossible to misspell, is @ .... ------- You mean like AI@AI, or was it MIT-AI@MIT-AI ? WW _____ Both. -------  Date: 30 Jun 1982 1944-CDT From: ZELLICH at OFFICE-3 Subject: Re: Crocker's "More queries" To: Header-People at MIT-MC Message-ID: <30-Jun-82 19:43:48-CDT ZELLICH at OFFICE-3> Comments on Crocker's "More queries", 29 Jun 82 18:25:15-EDT Allowing LWSP in the header/body dividing lines: Basically, I'm against it. It would be replacing a check for a fixed character string with one that would have to allow virtually anything some warped imagination could come up with in the way of LWSP combinations. Standardized site mailbox name(s): I don't really see what this has to do with the scope of RFC 733, but it's a pretty good idea. The @ suggestion is a good one, and the objections for those hosts with multiple names is taken care of by specifying that they should support a synonym (or mail-forwarding, or duplicate mailboxes, or whatever) for each common host-name synonym (\at least/ for the official synonym(s) in the NIC ARPANET host-name table). Date/time format: I don't really care whether there are dashes in the date or not, and neither does my hosts date-conversion software, but I still don't see why the dash was removed from in front of the timezone; that's probably the \one/ place where it's almsot universally used. Route sequence field: I'm not following the arguments on this one too well, but have one comment: When parsing addresses, adding the colon as an address element makes it \very/ difficult to distinguish a route-form address from the name of a distribution list with a colon separating the listname from the component addresses. It can be done, I think, but the disambiguation logic gets really nasty - especially if the address form typed by the user isn't using the "<" and ">" delimiters around the address. Removing " at ": Again, I vote to leave it in. It looks a heck of a lot better than the "@" in a header, and an awful lot of systems (all?) already handle it. Requiring a mail-display program to reformat the header lines is a real lose on many systems; if I have to implement a filter to display everything in my mail environment, my system response is going to go straight to hell - it's adding another protrayal program on top of the system one that has to be used for the low-level formatting. For a general argument on not changing anything unnecessarily, let's remember that this is a change to the standard that all of \today's/ mail programs live by. When we discuss the multi-media mail standards, we're probably talking total replacement of many of our mail programs, and that's another ball game entirely; protrayal formats are definitely going to be divorced from internal content, etc. Cheers, Rich  Date: 1 Jul 1982 0915-PDT From: MILLS at USC-ISID Subject: Re: Standard mailboxes To: Hornig.Multics at MIT-MULTICS, header-people at MIT-MC cc: MILLS In response to the message sent 30 June 1982 15:22 edt from Hornig.Multics@MIT-MULTICS Charles, You seem to imply MIT-devMultics@MIT-devMultics would not be a mailbox acceptable to you, or that you wouldn't want to use it? When is a nickname not a nickname? Regards, Dave -------  Date: 1 July 1982 1331-EDT (Thursday) From: Richard H. Gumpertz To: MILLS at USC-ISID Subject: Re: Standard mailboxes CC: Header-People at MIT-MC In-Reply-To: MILLS@USC-ISID's message of 1 Jul 82 11:15-EST Message-Id: <01Jul82 133150 RG02@CMU-10A> What about sites which maintain "unofficial" nicknames for other sites? Should the mail senders which expand nicknames into full names also have to expand the user-name if it matches the host name? For example, should I be able to send mail to PI@PI or would I have to send it to CMU-20C@PI (with my mail sender expanding it to CMU-20C@CMU-20C)? What if I give a numeric host address to my mailer because it is a new host? I really think @ is a lousy idea. Besides, it gives absolutely NO clue as to what the function of that address is. A name like General Delivery at CMU-10A or Operations Manager@CMU-10B or Postmaster@CMUC at least would allow some distinction of mail according to the type of service that is needed. By the way, I think Liaison should be reserved for stuff being sent to the official Arpanet-defined Liaison. Rick  Date: 1 Jul 1982 1110-PDT From: Jon Solomon Subject: Re: Standard mailboxes To: Header-people at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 1-Jul-82 0915-PDT Standard mailboxes which are official (according to NIC) host names seems quite reasonable. -------  Date: Thursday, 1 July 1982, 16:40-EDT From: Mike McMahon Subject: @ To: HEADER-PEOPLE at MIT-MC For the record, SCRC@SCRC means everyone who works here. I'd be surprised if that's unique.  Date: 1 July 1982 1906-EDT (Thursday) From: Richard H. Gumpertz To: Jon Solomon Subject: Re: Standard mailboxes CC: Header-people at MIT-MC In-Reply-To: Jon Solomon@USC-ECLC's message of 1 Jul 82 13:10-EST Message-Id: <01Jul82 190647 RG02@CMU-10A> OK, quick, what is the official name of the NIC? I would have to look it up! I am sure there are many hosts out there which are known to at least some people only by a nickname. How about General Delivery and Postmaster as possible easy-to-remember FIXED names? Try to make the functionality of the address intuitive! Rick  Date: 1 Jul 1982 1633-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Standard Names To: Header-People at MIT-MC No matter what name(s) we might pick, it is going to conflict with current usage at one or more sites. The more logical names, such as SYSTEM, LIAISON, HELP, ADMIN, etc. are also the ones most likely to already be in use. Some of them might not be so easy to change, either (SYSTEM on the OFFICE-n machines is probably a good example of this). On people not knowing the proper host name or official nickname: that is probably not so much of a problem as might be expected. A good guess is that usually you will already have the real name of the host in front of you in a message or something. A good example is needing to contact a site liaison to complain about receiving strange mailer error messages from it. Also, doesn't anybody ever use those beautiful ARPANET Resource Handbooks and ARPANET Directories? If you don't have one yourself (and you should, because if you're an ARPANET user you're supposed to be registered in the NIC database, and if you're registered you get a personal copy of the Directory), then for sure your local Liaison has one or more copies. You've \got/ to know who your Liaison is, because you didn't get on the ARPANET with a mailbox all by yourself! Cheers, Rich -------  Date: 1 Jul 1982 1632-PDT From: Jon Solomon Subject: Re: Standard mailboxes To: Header-PEOPLE at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 1-Jul-82 1606-PDT I envisionned using the NIC query program or the whois server to determine the proper address. Then you would only need to know the NIC's address and not its official name. I guess the case where you are reporting problems to them about their machine could be dealt with by requiring NIC (as a special case) to have entries for all their nicknames. I think that expecting this of one host is easier to implement than requiring it for all hosts on the net. An extension of this could be to have a server on NIC that programs sending "gripes" to other hosts could ask about whom to send to, we could keep ACTION, someone else could use LIAISON, or whatever. Nit: "General Delivery" contains a space and is therefore (currently) illegal. General.Delivery (the CMU approach to this) would be "cute" and would probably not be suitable since you probably wouldn't think to put the space in as easily as you would have thought of the name in a pinch. Less-of-a-nit: Postmaster is fine, but that implies a restriction in responsibilities for this address to just include mail for whom you don't know the network address. I thought we also wanted to deal with problems like "strange mail error" or if your mail software is generating illegal headers. I would not have thought to send such reports to the Postmaster, but rather to the system support group. I'm not at all sure that one address can deal with both kinds of problems. Cheers, --JSol p.s. To Mike McMahon: I have seen other sites do the same thing as SCRC@SCRC, but typically it is ALL@, e.g. ALL@BRL. -------  Date: 1 Jul 82 19:33:40-EDT (Thu) From: Dave Crocker To: Header-People at Mit-Mc Subject: Two solid names The two suggestions that have been made, with no serious objections, are Postmaster and Liaison. The latter is subject to misspelling and one concern was that it be reserved for "Arpanet Liaison" role. I suggest that both be reserved and equated. Thoughts? Dave  Date: 1 Jul 1982 (Thursday) 1953-EDT From: HAGAN at Wharton-10 (John Hagan) Subject: My vote for site mail control mailbox To: header-people at MIT-MC I think that Postmaster@ is excellent - easy to spell, has a real meaning, and emulates the real model of "electronic" mail. --Kid.  Date: 1 July 1982 1954-EDT (Thursday) From: Richard H. Gumpertz To: Zellich at OFFICE-3 (Rich Zellich) Subject: Re: Standard Names In-Reply-To: Zellich@OFFICE-3's message of 1 Jul 82 18:33-EST Message-Id: <01Jul82 195429 RG02@CMU-10A> Remailed-To: Header-People at MIT-MC Remailed-From: Richard H. Gumpertz Remailed-Date: Thursday, 1 July 1982 1956-EDT 1) Liaisons CHANGE! I have been here almost 9 years, have served as a liaison myself, etc. Therefore, I should be well informed. I do not know, however, who is the liaison here at the moment. At best, I could make an educated guess. 2) Host names CHANGE! Often, during this change, old official names become new nicknames or vice versa. Should I have to know which name is official? No, all I should have to know is at least one way to name the host. 3) How many people have an Arpanet directory that: a) is available at all terminals that a person might use (e.g., at home and office) b) is completely up-to-date c) never goes down (e.g., the NIC) I certainly do not. A small set of fixed names beats a large set of changing names for ease of recall. Rick  Date: 1 July 1982 2133-EDT (Thursday) From: Richard H. Gumpertz To: Dan Tappan Subject: Re: Standard mailboxes CC: Header-People at MIT-MC In-Reply-To: Dan Tappan@BBNG's message of 1 Jul 82 19:11-EST Message-Id: <01Jul82 213357 RG02@CMU-10A> I was using NIC as an example -- it has changed official host names many times. Rick  Date: 1 July 1982 2142-EDT (Thursday) From: Richard H. Gumpertz To: Dave Crocker Subject: Re: Two solid names CC: Header-People at Mit-Mc In-Reply-To: Dave Crocker@UDel-Relay's message of 1 Jul 82 18:33-EST Message-Id: <01Jul82 214247 RG02@CMU-10A> I don't think Postmaster and Liaison should be synonymous! The former would be used for quite different functions than the latter. For example, the latter would deal only with mail-specific problems. In fact, General Delivery would deal specifically with unknown mailboxes. Personally, I very much dislike giving up spaces in names -- why must we go against centuries of usage. In any case, General-Delivery would certainly seem consistent with various field-names which use "-". By the way, should there be a standard capitalization or should all forms, including poSTmaSTer be accepted? Rick  Date: Thursday, 1 Jul 1982 19:25-PDT To: Dave Crocker Cc: Header-People at MIT-MC Subject: Re: Two solid names In-reply-to: Your message of 1 Jul 82 19:33:40-EDT (Thu). From: greep at RAND-UNIX How about using something like the ITS convention of BUG-, e.g. BUG-MAIL? This is unlikely to conflict with existing usage. The symbology does not necessarily imply that you are reporting bugs, it can also be interpreted as a way of bugging a person about something.  Date: 1 July 1982 2301-EDT (Thursday) From: Richard H. Gumpertz To: greep at RAND-UNIX Subject: BUG-mumble CC: Header-People at MIT-MC In-Reply-To: greep@RAND-UNIX's message of 1 Jul 82 21:25-EST Message-Id: <01Jul82 230125 RG02@CMU-10A> A problem with BUG-mumble is that it opens up a large number of possible values of mumble. If I have a problem, which mumble do I choose? BUG-FTP? BUG-MAIL? BUG-MLFL? BUG-MAILER? Another problem is getting names that every host can (and will) implement. Too many values for mumble might discourage implementation. If implemented, BUG-mumble is a winner. It is just too broad, however, for expecting everybody to implement -- a program is required rather than a few simple aliases. We need a SMALL set of names that can be universally expected. Rick  Date: 2 Jul 1982 0102-PDT From: Mark Crispin Subject: standard mailboxes Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think it's clear that @ is horrible. One name I can think of in semi-common use is ACTION. On some systems, a user can mail to ACTION with a problem and she'll get "action" on the problem. I suggest that the following "standard names" be defined: LIAISON (acknowledged are problems in misspellings) ACTION REMARKS (a documented mailbox for vanilla TOPS-20) HELP MANAGER OPERATOR ACCOUNTS SYSOP (an all-to-common jargon term, sigh!) The site would be free to decide upon any meaning for these names that it wants. However, any (and all) of these names should in one way or another be appropriate contact points. Even if the name is the wrong thing for the user's request, the person who receives it should know who to redirect the message to. An ARPANET liaison should know where to redirect an account request to even if she isn't the system manager or otherwise in charge of accounts. Even an operator should know about that, and if not should not receive OPERATOR mail. -- Mark -- -------  Date: 30-Jun-82 11:27:37-EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: standard contact name for system administrator Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 11:27:38-EDT (Wed) To: header-people@mit-mc Note that a system may have several administrators - sometimes all are "equal", other times they each have different functions. For example, the USENET contact for each site on USENET has the standard mailing address "usenet", which is normally USENET contact for each site on USENET has the standard mailing address "usenet", which is normally forwarded to the right person. In this case, I'm not sure what you're looking for. If you want the right person to report mail problems to, you might mail to "mail" or "mail-contact". In fact, the word "contact" might be useful by itself, since it's easy to spell and seems pretty catchy. Does the existance of such a standard name imply that each site has to be capable of forwarding mail to such generic names? I have gotten complaints from USENET sites that are unable to have mail sent to "usenet" because that would require creating a new user called "usenet" and there is no forwarding or aliasing capability. (This applies to UNIX systems inside Bell Labs, and a few backward non-BTL systems. I'm not too worried about them, since we can always mail to "root", and we have  Date: 30-Jun-82 11:27:37-EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: standard contact name for system administrator Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 11:27:38-EDT (Wed) To: header-people@mit-mc Note that a system may have several administrators - sometimes all are "equal", other times they each have different functions. For example, the USENET contact for each site on USENET has the standard mailing address "usenet", which is normally forwarded to the right person. In this case, I'm not sure what you're looking for. If you want the right person to report mail problems to, you might mail to "mail" or "mail-contact". In fact, the word "contact" might be useful by itself, since it's easy to spell and seems pretty catchy. Does the existance of such a standard name imply that each site has to be capable of forwarding mail to such generic names? I have gotten complaints from USENET sites that are unable to have mail sent to "usenet" because that would require creating a new user called "usenet" and there is no forwarding or aliasing capability. (This applies to UNIX systems inside Bell Labs, and a few backward non-BTL systems. I'm not too worried about them, since we can always mail to "root", and we have a directory of contact persons similar to the arpanet directory.) Does this problem apply to any arpanet systems as well? Mark  Date: 30-Jun-82 16:15:56-EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: @ Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 16:15:57-EDT (Wed) To: header-people@mit-mc Sounds good on the surface, but if is d.isi.arpa, would it be d@d.isi.arpa, d.isi@d.isi.arpa, or d.isi.arpa@d.isi.arpa? And what about host nicknames? Mark  Date: 2 Jul 1982 0918-EDT From: Dan Tappan Subject: Re: standard mailboxes To: Admin.MRC at SU-SCORE cc: Header-People at MIT-MC, Tappan at BBNG In-Reply-To: Your message of 2-Jul-82 0402-EDT The only way this is going to work is if every site implements every one of all possible variations on whatever theme is chosen. Remember, this isn't something someone uses every day (or every year) an year from now who's going to be able to remember offhand whether it was ACTION or HELP or POSTMASTER (or Postmaster). Either their going to pick one at random, or they'll look up the name in the Arpanet directory (in which case they can find the REAL name of the liaison). I, personally, don't care what is chosen [I was less than half serious in suggesting @, the only advantage of @ is that it cuts the set of contact names to ~2: official name and nickname, 4 if you include the name change that happened 3 years ago] because I don't think the gain from implementing this will be worth the effort that has gone into arguing about it so far. Consider mailing lists. Despite all the effort that has gone into publicizing -REQUEST as a general contact name, people still send requests to the list name (typically the day after a reminder about -REQUEST has gone out). People are lazy, if anything they will try to use whatever the contact name at their own site is. -------  Date: 2 Jul 1982 1309-EDT Sender: MOOERS at BBNA Subject: Re: standard mailboxes -- vote for HELP From: MOOERS at BBNA To: Header-people at MIT-MC, Tappan at BBNG Cc: Mooers at BBNA Message-ID: <[BBNA] 2-Jul-82 13:09:44.MOOERS> In-Reply-To: Your message of 2 Jul 1982 0918-EDT I vote for HELP -- It is short, simple, easy to spell, and people might guess it, and might even remember it easily. And it does describe the function that the user is looking for. I find I can't remember which site is ACTION and which is HOTLINE. I probably couldn't spell LIAISON when under stress. I have never communicated with a POSTMASTER, and although I have used GENERAL DELIVERY services, I don't associate them with help. ---Charlotte  Date: 2 Jul 1982 1316-EDT From: Larry Campbell To: Header-People at MIT-MC Subject: Re: Two solid names Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11836514595.22.71.11161 at DEC-MARLBORO> Regarding: Message from Dave Crocker of 1-Jul-82 1933-EDT I prefer "Postmaster". It's easy to remember (and spell), and even maps onto similar functions in the "real" world. --------  Date: Friday, 2 Jul 1982 11:15-PDT To: Richard H. Gumpertz Cc: Header-People at MIT-MC Subject: Re: BUG-mumble In-reply-to: Your message of 1 July 1982 2301-EDT (Thursday). <01Jul82 230125 RG02@CMU-10A> From: greep at RAND-UNIX I agree that we need a small set of names. I didn't mean to imply that the "mumble" in BUG-mumble should be a variable which could be replaced by anything, rather that having mailbox names start with a string like "bug-" was likely to reduce conflicts with sites that already have pre-assigned meanings to names like "system" which might not correspond to what we intended.  Date: 2 July 1982 17:27-EDT From: David A. Moon Subject: role mailboxes To: HEADER-PEOPLE at MIT-MC It has been NETWORK-LIAISON here for many years. The alternate spellings LIAISON and LIASON are also accepted. If I remember correctly we did this as a result of a general agreement that all hosts would do this, although I may be remembering wrong since apparently no one else did.  Date: 2 July 1982 17:30-EDT From: David A. Moon Subject: recent discussion To: HEADER-PEOPLE at MIT-MC I have been away for a week, so I have been seeing all of this stuff in one large dose. Now I understand why many people are afraid of what would happen if a US Constitutional Convention were called. Could we please leave RFC733 strictly alone except for the addition of host-naming domains?  Date: 3 Jul 1982 2254-PDT From: MILLS at USC-ISID Subject: Re: Standard mailboxes To: Rick.Gumpertz at CMU-10A cc: Header-People at MIT-MC, MILLS In response to your message sent 1 July 1982 1331-EDT (Thursday) Rick, If you advertise a "standard" nickname for an official name registered with the NCC, I hope you are prepared to accept that name everywhere in lieu of the registered name. Regards, Dave -------  Date: 5 Jul 1982 2310-PDT From: MILLS at USC-ISID Subject: Re: Standard mailboxes To: Rick.Gumpertz at CMU-10A cc: Header-People at MIT-MC, MILLS In response to your message sent 5 July 1982 1443-EDT (Monday) Rick, The moral is clear: never allow a local nickname to escape in a message bound outside the local domain. See RFC-799. Regards, Dave -------  Date: 5 July 1982 1443-EDT (Monday) From: Richard H. Gumpertz To: MILLS at USC-ISID Subject: Re: Standard mailboxes CC: Header-People at MIT-MC, MILLS at USC-ISID In-Reply-To: MILLS@USC-ISID's message of 4 Jul 82 00:54-EST Message-Id: <05Jul82 144309 RG02@CMU-10A> The problem is that site A might have a local nickname for site B. A user at site A might not realize that the name by which he knows B is actually a local nickname. For outgoiung mail, the mail sender can automatically translate because it is sure that the name is in fact a host name. On the other hand, translating a name found somewhere other than in a context requiring a hostname would be rather dangerous. Hence, NICNAME@NICKNAME might end up as NICKNAME@OFFICIAL which would then be meaningless to the addressed host. Rick  Date: 6 Jul 1982 2320-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Mailing-list for "List of lists" update notices To: All mailing-lists: cc: ZELLICH For those of you not previously aware of it, I maintain a master list of ARPANET mailing-lists/digests/discussion groups (currently 756 lines or ~29,000 characters) on OFFICE-3 in file: INTEREST-GROUPS.TXT For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS login within FTP, with any password. To keep people up to date on the large number of such lists, I have established a mailing list for list-of-lists \update notices/. I do not propose to send copies of the list itself to the world at large, but for those ARPANET users who seriously intend to FTP the updated versions when updated, I will send a brief notice that a new version is available. For those counterparts at internet sites who maintain or redistribute copies for their own networks (DECNet, Xerox, etc.) and can't reach the master by ARPANET FTP, I will send out the complete new file. I do \not/ intend to send file copies to individual users, either ARPANET or internet; our system is fairly heavily loaded, and we can't afford it. There is no particular pattern to the update frequency of INTEREST- GROUPS.TXT; I will occasionally receive a burst of new mailing-lists or perhaps a single change of address for a host or mailing-list coordinator, and then have a long period with no changes. To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the mailing-list this message appears in. Cheers, Rich -------  Redistributed-Date: 7 July 1982 13:57 edt Redistributed-By: TMPLee.DODCSC at MIT-MULTICS Redistributed-To: header-people at MIT-MC Date: 7 July 1982 09:53 edt From: TMPLee.DODCSC at MIT-MULTICS Subject: NetMail Security Vulnerability Query To: tcp-ip at BRL, MsgGroup at MIT-ML, Postel at USC-ISI, Cerf at USC-ISI When I distributed the most recent issue of the Computer-Security-Forum I encountered an apparent vulnerability, or weakness, in the way messages are handled by (at least) some mail handlers. I would appreciate it if someone who knows could confirm or deny that this is indeed a problem, whether it is site specific, and whether the new regime (TCP-IP) will have eliminated it. As some of you know, I use the UTexas mailer, since neither the BBN nor Multics systems that are my home bases have mailers good for large distribution lists. (mine now is about 120 names of primary distribution.) Anyway, when it tried delivering the message to one of the sites (Mitre-Bedford) apparently the Mitre-IMP was in what I am told is called "loop-back" mode. thus when Utexas thought it was connecting to Mitre it was in fact actually connecting back to itself. Also, apparently, there is no (easy?) way for a host to know this is happening. To make the long story shorter, it thus tried sending the messages intended for Mitre to itself. Fortunately, none of the mailbox names (user-id's) at Mitre matched any of those currently registered at Utexas. As I understand it, if, however, there happened to be a user at Utexas with the same name (same mailbox name) as one whom I was attempting to send the message to at Mitre, the user at Utexas would have received the message and no-one (except him, if he were honest) would know that anything had gone wrong. (I don't know if MsgGroup still lives; in any case, feel free to pass this on to anyone else who might know, within reason.) Ted Lee  Date: 8 July 1982 00:15 edt From: Frankston.SoftArts at MIT-MULTICS Subject: Comments on comments on RFC733 Sender: COMSAT.SoftArts at MIT-MULTICS Reply-To: Frankston at MIT-MULTICS (Bob Frankston) To: header-people at MIT-MC *from: BOB (Bob Frankston) Local: header-people at mit-mc Original-date: 07 JUL 1982 18:39:40 I've finally managed to at least scan the last month of header-people comments on the RFC 733. Unfortunately I don't have a copy of the NBS standard handy, nor do I have my SMTP writeup here (though I can skim parts of it at a slow 9600 bps). I will probably revise my comments after I look at them. I'll start out by discussing very specific issues and then more general philosophy. => To: THE TO FIELD CANNOT BE REQUIRED. I distinguish between the RFC-733 "To" line and forward path information (see below). The "To" field is a private communication between me and my mail sender. It need not contain any information useful to a third party? There is no reason why it cannot contain a name of a mail relaying service such as "whom-it-may-concern" or some name like "header-people". The BCC discussion illustrates this point very well. Why then do people insist on keeping it? A valid reason is to understand the context of the letter? Often this can be done by looking for magic words like "HeAdEr-PeoPle". The answer is not to require some meaningless "to:" field. It is to explicitly define fields for discussion groups that identify the discussion. I propose "Forum" for the general area such as "header-people". For a specific discussion, a "Discussion" field might be "RFC733 revision 5". Another valid is reason is to find out it the intended recipient. A number of parties can share a mailbox (because a mailbox is identical to a host -- more discussion on that later). Thus it become necessary to find out the intended recipient of a letter. This cannot be solved in the "To" field since a name like "header-people" simply does not provide that information? The answer lies in reexaming the purpose of the header field and the relationship between it and FTP/SMTP. My basic premise is that ALL INFORMATION MUST BE REPRESENTED IN THE TEXT OF THE MESSAGE. For this purpose we must look at the purpose of the header field. It is basically a scratchpad for communication. Some fields are used by the local mail sender (to:), some by the recipient (forum:) and some by the mail transport mechanism (FTP/SMTP destination). It is easy to justify a feature because it happens to work in the current environment -- a very simple and homogenous environment. Not only does the "to" field work for many of the current net hosts, but it is a useful feature allowing for some nice reply mechanisms. There is some recognition that things are more complicated and that a recipient cannot always interpret the to fields. The ability to associate an host name with a mailing list file is an attempt to deal with this. Fundamentally, however, the "to" field, as specified, is as meaningless to a given recipient as is the free text "from" field. There is no way that I can determine if a given letter came via info-terms, info-trs80, or header-people when they all appear in the header. Nor can I determine for which of my aliases the letter was intended. One improvement would be to take the forward and reverse path information of SMTP and place it in the header. Actually I would call this portion the "envelope" since it contains information primarily of interest to the transport mechanism. But the information must be in the text portion so that any mailbox can be a host. => What is a host? Since I have mentioned mailbox==host twice I should elaborate on it. When UDEL was added to the network as an off-net host, it had to cheat. Unfortunately, it got away with it. The problem is that it is kludged up to look like a direct host on the network. This was done in conspiracy with the its network host. The alternative is to have a network host serve as a gateway and use an extended addressing construct as user@host-a@host-b. (We'll get to @ @ later). This must be doable without any knowledge on the part of host-a. And it can be done simply by treating the mailbox as a host. The receiving FTP server would process the foward routing information normally and place the processed result in the mailbox as part of the letter. Some time later (or immediately) another program can examine the contents of the mailbox and forward the letter appropriately. This has implications on the domain scheme mentioned in the revision. It claims that there can be an absolute inertial reference frame. Or at least the ability to provide a rooted tree. How do I treat this machine sitting on my desk which is connected to the phone system or a leased line and which can also transmit information via floppy disk? It is also not the only computer on my disk. I know that RFC-733 mentioned something about routing, but I could not find any details. => Domain/routing syntax I still maintain that routing is fundamental and any absolute names are a convenience in a local context. The syntax of user@host-a@host-b is necessary to handle the general case. It does, however suffer from a syntax problem in that it must be scanned backwards so as not to make assumptions about the syntax used within host-b's domain. We should try to convert to host-b>host-a>user or some such forward syntax. (Does SMTP handle this well?) Part of the problem arises from quoting. Quoting does not nest well, though I guess it is possible to employ \" to pass one through. => Effective reply RFC733 should not be in the business of guaranteeing that the reply command will work well. It should make suggestions such as the Reply-To field and the use of a To field to allow for a simple reply command to work. If the sender does not cooperate, it is OK for it to fail. Remember also that the whole letter is generally forgeable. We should attack that problem before we get to concerned about banning what some might view as anti-social behavior (the ommission of a To: field). => Funny characters in letters I have two different comments. The first is that the mail standard has no business worrying about "funny" characters such as ESC sequences in letters. If it causes trouble on a host then that host damn well better protect itself. If someone wants to be malicious then RFC733 is not going to help. On the other hand, I think that it is wrong to require support for more than the printing graphics and the format effectors newline and backspace. Perhaps a return. Consenting hosts may use other characters among themselves but there should be no requirement that they be supported. This means that a relay need not support them. Next thing will be a request to support the fork, hook and chair characters in EBCDIC. If one wants to pass such characters, then they can be encoded via an escape sequence (not ESC sequence). For example Multics uses \ooo where ooo is the octal value of the character. There should be a standard convention which can be declared in the header. Thus: character-set-escape: backslash-octal The warning above replies. The recipient should still survive funny control characters in the mail stream, though reprimanding the sending FTP program is valid. One last comment on character sets. The standards should not use CRLF -- that is an artifact of TELNET. Instead NL (for newline) should be used for this sequence and declare that within the Arpanet TELNET protocol is used between the FTP programs. => FTP vs mail. Mail is the fundamental protocol on top of which FTP can be implemented. It is only an historical accident that the implementation of FTP was done first. It is proper etiquette to only send short letters to strangers, but among friends there should be limitation on the files that can be exchanged. There is a separate issue about file ACCESS protocols, but that is not for this discussion. => Accounting and accountability The issue of who should pay for mail is a serious, but is beyond the scope of RFC-733. It is proper for a host to refuse a large file until it negotiates with the sender for proper payment or permission. I discussed that in my Master's thesis in 1974 so will not go into detail here. It is true that much of the implemetantion of today's mail systems assume that it is a low cost feature that can be supported without a serious commitment on the part a host. To the extent that this is not true, then a host can and should put limits on its willingness to accept mail. A network such as UUCP might have to resort to only accepting mail from trusted senders if there is any serious overloading -- even if this overloading is not malicious. => Known names at hosts. How about "@HOST". The reasoning stems from the symmetry between mailboxes and hosts. For example, if "Crocker at UDEL at UDEL-Relay" then "UDEL at UDEL-Relay" is also valid. It can be interpretted as either a null name and rejected, or a request to send mail anyone at the host. Thus if one sends mail to "Workstation-3 at Frankston at MIT-Multics" it would go to a designated machine whereas "Frankston at MIT-Multics" would be to me whereever the mail system thinks it can find me. => Optional fields The standard should specify that a mail presentation program is allowed to ignore them. Thus one cannot send the body of a letter in the "comment:" field without knowing that the recipient is going to see that field. Otherwise one must always be teaching a screen program about new fields to ignore or else be at the mercy of each new and creative approach to header fields. => Message-ID's I would like to revive them. I just received (so far) 8 letters telling me about the master list of mailing lists. Each with a different time stamp. This makes it very hard to use heuristics for eliminating duplicates. ================>Why RFC-733 This all brings us to the fundamental question: What is the thing that RFC733 specifies. Judging from what I've said above, it should first identify the players. In this case it consists of mail servers which originate, transfer and present mail. The origination program takes information provided in a header in fields like "to", "cc" and "bcc" and translates it into envelope fields specify the forwarding path. It is this forward path that serves as the means of communication between these mail servers up to and including the presentation program. The presentation program makes use of fields such as "subject", "forum" and "reply-to" in presenting and acting upon a letter. Both the origination and destinatation might involve just other programs instead of human-users. The LIAISON (or however you spell it) may very well be a program that determines who is on-duty at the moment and sends a notification to that the person.  Date: 8 July 1982 20:05-EDT From: David A. Moon To: HEADER-PEOPLE at MIT-MC Please ignore this test message. Sorry to bother you all.  Date: 9 July 1982 1756-pdt From: Earl A. Killian Subject: people names To: Header-People at MIT-MC Let's put spaces back into mailbox names. Not being able to send mail to "John Smith @ Host" is horrible. I hope someday every host supports such human-oriented addresses. When RFC 733 first came out, not many people supported this, so there was a movement to outlaw it, which has apparently succeded. But in the mean time my impression is that most mail readers have been fixed, so the restriction is now obsolete.  Date: 11 Jul 1982 19:31:04-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: Killian at MIT-MULTICS cc: Header-People at MIT-MC Subject: Re: people names In-reply-to: Your message of 9 Jul 1982 1820-PDT (Friday). The elimination of the blanks and "at" are because the current consensus leans toward viewing 733 as an INTERCHANGE format, not a PRESENTATION format. Your reader/composer can allow or disallow whatever you wish to see when you read or compose mail. But when it gets put into the transport layers of the mail system, it should have been converted to the no-spaces "@" format. This is an optimization to make the lower level software simpler and more robust. The importance is the distiction between the levels. If you want to see/use "foo at bar", please, be my guest, but do it in the reader/composer. -Mike  Date: 11 July 1982 22:53 edt From: Barry Margolin at MIT-MULTICS Subject: Re: people names Sender: Margolin.Multics at MIT-MULTICS To: mo at LBL-UNIX (Mike O'Dell [system]) cc: Killian at MIT-MULTICS, Header-People at MIT-MC In-Reply-To: Message of 11 July 1982 22:31 edt from Mike O'Dell [system] Well, that is a fine excuse for getting rid of the " at ", but doesn't say much about the embedded blanks in the address. If my mailing address on a computer is "Barry Margolin", then there is good reason for me to want to put "Barry Margolin@MIT-Multics" in the header. barmar  Date: 12 July 1982 04:41-EDT From: Earl A. Killian Subject: people names To: mo at LBL-UNIX cc: HEADER-PEOPLE at MIT-MC You seem to have complete misunderstood my complaint: I'm refering to the ability to have a from field such as From: Earl Killian at MIT-MC  Date: 12 July 1982 1444-EDT (Monday) From: Richard H. Gumpertz To: mo at LBL-UNIX (Mike O'Dell [system]) Subject: Re: people names CC: Header-People at MIT-MC In-Reply-To: mo@LBL-UNIX's message of 11 Jul 82 21:31-EST Message-Id: <12Jul82 144453 RG02@CMU-10A> Elimination of " at " does not bother me -- the presentation can indeed be changed. Elimination of "Richard H. Gumpertz", however, does bother me. Why shouldn't it be legal. I HATE DOTS, especially Richard.H..Gumpertz because of the double dots. Rick  Date: 15-Jul-82 17:31:36-EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: people names Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 17:31:39-EDT (Thu) To: header-people@mit-mc Re: putting spaces in names While spaces look nice, the problem is not in mail readers but in mail senders. If you have a long list of people, currently I can type mail joe@site1 ucbvac!sam sally and it breaks the sites apart at the spaces. (This fits nicely with the UNIX convention of pre-parsing your input into white-space separated words, and I assume it doesn't matter on sites where you are forced to enter the names to prompts.) If you allow spaces in names, you are forced to type a comma, probably followed by a space. The problems this causes are: (1) This breaks existing usage conventions on UNIX systems. In fact, there is no way to upward compatibly implement a scheme allowing spaces, forcing a user interface change. I can promise you that the powers that control uucp will never install software that requires a sudden, incompatible, change to the user interface. (Don't yell at me, I'm not the powers that be.) (2) This is impossible to implement on UNIX systems if you allow more than one space together, or consider tabs and spaces different, since the program only sees a list of words. (3) is harder to type than . In fact, is harder to type than . I think how easy something is to type is more important than how sexy it is to read. Mark  Date: Thu 15-Jul-1982 18:41-EDT From: Stephen Tihor To: header-people at MIT-MC Subject: Re: Peoples Names and Unix Hum. I am not sure what system you were using but every Unix system I have used has had a quoting mechanism to pass arbitrary input to a program. Depending on the shell/CLI in use it is usually something involving one or more of `, ', ", or \ . Is this in fact just a local patch that happens to have shown up on each system I have happened to use? If not then significant spaces can be used albeit those network addresses will be more of a pain to reach from some sites than others. But then I occasionally have some difficulty with MIT-MULTICS since I have to submit mixed case usernames and the VMS system that I use as home base forces me to quote them if I put them on the command line. (Ditto with spaces, commas, quotes, etc.)  Date: 15 Jul 1982 1848-EDT From: Robert W. Kerns Subject: Re: people names To: cbosgd!mark at UCB-C70, header-people at MIT-MC cc: RWK at SCRC-TENEX In-Reply-To: Your message of 15-Jul-82 1814-EDT Date: 15-Jul-82 17:31:36-EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: people names Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 17:31:39-EDT (Thu) To: header-people@mit-mc Re: putting spaces in names While spaces look nice, the problem is not in mail readers but in mail senders. If you have a long list of people, currently I can type mail joe@site1 ucbvac!sam sally and it breaks the sites apart at the spaces. (This fits nicely with the UNIX convention of pre-parsing your input into white-space separated words, and I assume it doesn't matter on sites where you are forced to enter the names to prompts.) It also causes no problems on systems which take command-line arguments but which don't screw around with the user's input before the program gets to see it! If you allow spaces in names, you are forced to type a comma, probably followed by a space. The problems this causes are: (1) This breaks existing usage conventions on UNIX systems. In fact, there is no way to upward compatibly implement a scheme allowing spaces, forcing a user interface change. I can promise you that the powers that control uucp will never install software that requires a sudden, incompatible, change to the user interface. (Don't yell at me, I'm not the powers that be.) (2) This is impossible to implement on UNIX systems if you allow more than one space together, or consider tabs and spaces different, since the program only sees a list of words. (3) is harder to type than . In fact, is harder to type than . I think how easy something is to type is more important than how sexy it is to read. Mark Not even UNIX is as losing as you claim. While I don't use Unix often enough to remember how off the top of my head, I do recall that the shell does have means of quoting arguments to commands. What bothers me about this the usual unique form of Unix chauvenism displayed here. I don't see why everybody should be forced to accomodate this minor Unix quirk. If Unix users don't like having to quote the space in "Robert Kerns", they can put pressure on the Unix "powers that be" to be a bit less inconvenient. Say, by punting the doctrine of "one parser for all". In the meantime, I trust the rest of us won't be overly inconvenienced by having to type instead of , like we've been doing for years anyway, ever since we learned that lists in English were separated by commas. -------  Date: Thursday, 15 Jul 1982 16:31-PDT To: cbosgd!mark at UCB-C70 (Mark Horton) Cc: header-people at MIT-MC Subject: Re: people names In-reply-to: Your message of 15-Jul-82 17:31:36-EDT (Thu). From: greep at RAND-UNIX This is the same as with any other program on Unix. The shell always interprets unquoted spaces as separating arguments, and requires you to quote a space that is to be part of an argument. So where is the inconsistency? Anyway (as has already been pointed a number of times) what we are supposed to be discussing is a standard for transmission, not user interfaces.  Date: 15 July 1982 21:11-EDT From: Gail Zacharias Subject: people names To: CBOSGD!MARK at UCB-C70 cc: HEADER-PEOPLE at MIT-MC Gee, if we're gonna forbid spaces for the convenience of Unix users, then we should forbid all upper/lower case distinctions for the convenience of VMS users.  Date: 15-Jul-82 22:02:48-EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: spaces in people names Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 22:02:49-EDT (Thu) To: header-people@mit-mc Perhaps I can suggest a solution to keep everybody happy: All systems that accept spaces in their names should also accept the name if all spaces are turned into dots. I think this is what CMU does now. They can, of course, feel free to turn dots into spaces internally. We should agree on some character that systems should interpret as blank. We can't use dot because that's significant. (Although we might get away with defining dot and blank as equivalent in all places in the name, interchangeable - anyone know of something this might break?) Mail composers could accept and translate this character. Then we have the question of whether blanks are allowed in the headers themselves. (As opposed to the thing SMTP utters to get mail sent.) As long as there is a character reserved to be a blank equivalent, I see no problem for UNIX with allowing them in the header. Perhaps underscore could be the character? Or some control character? WRT PP 2 above, note that the header might ALWAYS say From: Mark R. Horton which mailers would interpret as equivalent to mark.r..horton, but there is no reason why the header would have to clobbered. Rather some internal copy of the addressee would be munged for mapping and comparison, perhaps even the SMTP utterance, but nothing a human non-guru would ever see. This would imply that dot=blank applies on the right of the at sign, too. Mark  Date: 16 July 1982 0138-EDT From: Rudy.Nedved at CMU-10A To: cbosgd!mark at UCB-C70 (Mark Horton) Subject: Re: spaces in people names CC: header-people at mit-mc In-Reply-To: cbosgd!mark@Berkeley's message of 15 Jul 82 21:02-EST Message-Id: <16Jul82 013845 EN0C@CMU-10A> That isn't a comprimise. What do you give up? If I send you mail with a header like "Mr. Rudy Nedved", your current mailer will still munge the headers. I fail to understand why someone can't construct an interface to delivermail that handles spaces. Why can't you tweak the argument code so it looks at the last character in each word and sees if it a comma or not and use that as the seperator. Commands like "mail Rudy Nedved@CMU-10A, foo@bad" will then start working. [I have to admit I haven't looked at the delivermail program enough to remember if that hack is as simple as it seems.] I can understand the need to reduce the amount of work but for who? the end user or the programmer? What it seems you want to do is reduce the work for the programmer. The user will still type spaces in until he understands that is a no-no under YOUR version of Unix. Stop worrying about spaces in names if the mail software is still being developed for your os. I can understand why someone on an IBM-360 somewhere would be upset if she had to change code that she has never seen before to use the new RFC. -Rudy  Date: 16 Jul 1982 1104-EDT From: Larry Campbell To: cbosgd!mark at UCB-C70, header-people at MIT-MC Subject: Re: spaces in people names Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11840160496.30.71.13061 at DEC-MARLBORO> Regarding: Message from cbosgd!mark@Berkeley (Mark Horton) of 15-Jul-82 2202-EDT What's wrong with just ALLOWING THE SPACES? You can't just map dots to spaces, because Mark.R..Horton shouldn't be treated as Mark R Horton If you just allow the spaces, you don't have to invent all kinds of crock quoting and mapping rules in order to be able to handle human names (after all, isn't all this software supposed to benefit humans?) --------  Date: 16 Jul 1982 09:10:58-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: RWK at SCRC-TENEX cc: cbosgd!mark at UCB-C70, header-people at MIT-MC Subject: Re: people names In-reply-to: Your message of 15 Jul 1982 1618-PDT (Thursday). The last time I had to "type commas like we have been doing for years" was 5 years ago when I was doing IBM "systems programming", but even then, TSO allowed white space as delimiters. I fully agree with the need to include the space. Since I still use @ as a line-kill character, I don't see anything wrong with either foo\ bar@randomhost or, better, "foo bar@randomhost" ---BUT!! Again, we are missing the point. The mail reader/composer is what determines what people can and must type. The issue is how to deal with it as an interchange standard, ie, the levels below the reader/composer. The important issue is how the blank is processed in the header lines inside. Since we already have a quoting convention in the proposal which looks like my first example, I don't think we really have a problem. If you want an address with a comma in it (no reason to discriminate against them, either) you have to escape it, so I don't see the problem, unless your lower level parsers break on whitespace. Then, the reader/composers must quote embedded white space. How does the user type it? That is an individual matter, but quoting isn't all that bad if (like me) you detest typing the commas. If you don't mind commas, then the reader/composer could honor whitespace in some way. But again, this is a reader/composer issue, NOT a 733 transport issue. -Mike  Date: 15 Jul 82 21:29:18 EDT (Thu) From: Steve Bellovin Subject: Re: people names To: (Mark Horton)cbosgd!mark at Ucb-C70, header-people at Mit-Mc In-Reply-To: (Mark Horton) cbosgd!mark@Berkeley's message of 15-Jul-82 17:31:36-EDT (Thu) Via: UNC; 16 Jul 82 0:23-EDT As several people have pointed out, UNIX does indeed allow quoting of spaces or other characters the shell considers odd; one could say: mail 'Mark Horton at Berkeley' Mark\ Horton@Berkeley etc. What's more of a problem is the vast number of UNIX mailers out there that don't insert commas in address lists. I've hacked the one I'm using now enough to understand 'Steve Bellovin ', 'lauren@ucla-security (Lauren Weinstein)', and lists like 'unc!smb duke!trt', but there's not a blessed thing I can do to disambiguate a 'To' line like To: host!user First Last@arpa-host Wrong? Sure! But the standard Berkeley UNIX mailer omits the commas if there are no '@'s in the address list, so I've got to handle it. (For reference purposes, my latest uucp database lists over 600 sites -- no way they're all gonna change.) UNIX chauvinism? Perhaps. But from here -- a non-ARPA site -- it seems that 90% of the ARPAnet is UNIX, TENEX, or ITS, and I've detected no lack of chauvinism on anyone's part. And UNIX is growing very rapidly. To ask UNIX-based ARPAnet hosts to cut themselves off from the uucp net doesn't make any sense either -- I can think of at least half-a-dozen sites that talk to both, and that's without digging out my antiquated ARPAnet directory. One other technical note about UNIX: if the mail-composer passes the letter on to a delivery system -- as all the better ones do -- the spaces may still cause trouble, especially if the delivery system is invoked via two very common subroutines (popen() and system()). If you add a local net to the picture, you're really tempting fate. (Again, I'm not defending this -- such practices are inadvisable for many other reasons; lot's of other characters will break the mailer if those techniques are used. But I'd hate to count up all the UNIX programs that *do* use them.)  Date: 16 Jul 82 13:30:59-EDT (Fri) From: Dave Crocker To: Header-People at Mit-Mc Subject: legal spaces Just for clarification, spaces are legal, as uninterpreted data, within quoted strings. A local-part may be a quoted string. Dave  Date: Fri 16-Jul-1982 16:42-EDT From: Stephen Tihor To: header-people at MIT-MC Subject: Re: People's Names In-Reply-To: 's message of 16-JUL-1982 14:41 I think that you are overestimating the impact of non-RFC733 mailers on the new standard. Granted there will be some work for gateway sites but that is why gateing is not something that people should do casually. Here at NYU we deal with three different mail formats regularly: RFC733, DEC MAIL, and UUCP mail. Although conversion is not always completely free it can be done fairly in a straightforwards way. We presume that mail comming from a given mail source will normally be in the standard format for that source and will need to be converted into the format for its destination. If some people insist on using a braindamaged mailer with can not send to people with the letter H in their names must I change my mailing address? As I pointed out earlier under VMS there are some difficulties sending mail to Multics sites which have case sensitive mailboxs and do not have the appropriate case-mapping code for the vast majority of cases where a mailbox is unique regardless of case. BUT I although I would suggest adding such code to the multics mail handler I would not argue that it should be forbidden to differentiate by case even though this would make life easier for many OS which might want to deal with them. I don't really care what characters are legal in mailbox names. Most systems either restrict them paiunfully or have a general quoting convention and thus do not care. While I would be delighted to see son-of-RFC733 compatible mailers available on all Unix sites, by definition a mailer on an ARPAnet Unix system must be ARPAnet mail compatible if it is to be very useful. Thus you seem to be arguing that we must restrict RFC733 to grandfather software on non-ARPAnet systems; and with an example of an operating system for which there will be compatible mailers available.  Date: Friday, 16 July 1982, 21:38-EDT From: Robert W. Kerns Subject: Re: people names To: Steve Bellovin Cc: header-people at MIT-MC In-reply-to: The message of 15 Jul 82 21:29-EDT from Steve Bellovin I don't see it as so much of a problem to convert Unix sites to a more reasonable mailer, once one exists. Particularly if it is distributed and supported by the people at Berkeley. The benefit to the Unix community in standardizing on mail software is very large, and the cost is no higher than for any other operating system. The current software (everybody's, not just Unix) is inadaquate for the multi-network environment we are in. That's the whole point of this discussion! It is not just the Arpanet sites involved in this, after all, but a myriad of other local networks which link up to each other in various ways. True, many uucp sites will be slow to switch over, for various good or bad reasons. They will be able to win most of the time at first. Later, as they get more involved in communicating with a wider variety of members in the inter-network community, there will be a greater incentive to bring their software up to date. And if the people at Berkeley are distributing a package that does the job, I don't think there will be much problem in most cases. If anything, the number of Unix sites makes it CHEAPER (per site) to do the conversion. Consider the case on ITS. There are only 4 of them in the world, and the manpower available to do the conversion is strictly limited and otherwise occupied.  Date: 16 July 1982 18:46-EDT From: Earl A. Killian Subject: spaces in names To: HEADER-PEOPLE at MIT-MC So far, the only argument for keeping spaces out of user names has concerned the Unix user interface, and that issue which can be dealt with easily. Dave Crocker has pointed out that you can use quoted strings, which is true, but is not an argument against allowing it. Is anyone going to defend the restriction? If not, let's punt it.  Date: 16 Jul 1982 19:58:33-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: EAK at MIT-MC cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names In-reply-to: Your message of 16 Jul 1982 1917-PDT (Friday). WAIT A MINUTE!!! Indeed, the largest problem is with some user interface programs, but the restriction is still important! What I have been proposing is that if blanks appear in the address, they MUST be quoted, either with \ or in a quoted string so the parsing is straightforward. (This is strictly at the transport level!) This is NOT the same thing as discarding the restriction!!! Unless the blanks are constrained, the parsing is very context sensitive, an issue we have bandered about before. (Note I didn't say it was impossible, just very hard to get right.) The restriction I would favor is flushing the comma separation of addresses, but I am not adamant about that. But if you disallow "bold blanks", the commas become redundant. -Mike  Mail-from: SU-NET host SU-SHASTA rcvd at 16-Jul-82 2340-PDT Date: Friday, 16 Jul 1982 23:39-PDT To: EAK at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names In-reply-to: Your message of 16 July 1982 18:46-EDT. From: Brian Reid Only the most primitive TTY-oriented mail programs on Unix use the shell as a user interface. The mail system that I use on my Unix (Rand MH) uses a display editor (Gosling EMACS) as its front end. I can type anything I want in a "To" field, and the mail system automatically does all of the quoting needed to get the names through delivermail. The whole issue of "we can't allow blanks because crufty old system XYZ can't cope with them" is stupid and we should stay away from it.  BH@MIT-AI 07/17/82 09:12:43 Re: spaces To: header-people at MIT-MC Allow me to join the long line of people pointing out that we are talking about a standard for transmission of information between two computers, and not about a user interface standard. 98% of the discussion about spaces in names has been irrelevant. I would also like to point out that this cuts both ways. Suppose you are a person who wants to be able to type spaces in names at the user level. You can type to your mail program mail Brian Harvey@AI and your mail program can establish a connection to AI and send down the line To: "Brian Harvey"@MIT-AI or perhaps To: Brian\ Harvey@MIT-AI or any other quoting convention one wants to adopt. Your mail program can just put quotes around all names, whether or not they contain spaces, if it wants. This allows users to use spaces while not hairing up the inter-system parser very much. On the other hand, suppose you are a person who wants spaces in your user command to separate addresses. You can type mail fred joe "Brian Harvey"@AI (note how this fits EXACTLY into the existing Unix convention for using quotes to allow spaces within a token) and your mail program could translate that to To: fred@MY-SITE,joe@MY-SITE,Brian Harvey@MIT-AI if it turns out that spaces are allowed unquoted in the inter-system protocol. In short, the ONLY relevant question for the inter-system protocol is what is easy to implement. Personally, I am worried about the following case: To:fred@MY-SITE, Brian Harvey@MIT-AI Now, if the space between Brian and Harvey is a legal part of a name, what about the space before Brian? Probably it was meant not to be part of the name, but who knows? If spaces are to be okay within a name it better be explicit which spaces are meaningful and which aren't. What about a space just before the atsign?  Date: 17-Jul-82 11:23:18-EDT (Sat) From: cbosgd!mark@Berkeley (Mark Horton) Subject: unix allowing quoting Via: cbosgd.uucp (V3.94 [3/6/82]); 17-Jul-82 11:23:19-EDT (Sat) To: header-people@mit-mc It is true that the UNIX shell (not the operating system or any particular subroutine library) allows quotes. However, my concern is that a typical random program does NOT allow quotes - for example, Mail's m command won't understand such addresses, making it impossible to send mail to such a person while inside the Mail system. This is not an overriding concern, but life will be somewhat harder if every little program that sends mail has to understand quotes. I still haven't been convinced that dots and spaces can't be considered the same. If I'm writing a system that takes spaces in names, presumably these names with spaces in them get mapped into login names or file names somewhere. There is no reason the mapping program can't turn all spaces into dots (in an internal buffer), possibly squash multiple dots into single ones (Mark.R..Horton=>Mark.R.Horton) and probably map everything into one case (unless it really wants to consider Horton different from horton or HORTON) and then look up the resulting string. Names could be stored in the table with dots. Of course, even though a human never sees the dots, if the guru thinks they are ugly, they can always map dots into spaces. Mark  Date: 17 Jul 1982 11:49:01-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: cbosgd!mark at Berkeley cc: header-people at mit-mc Subject: Re: unix allowing quoting In-reply-to: Your message of 17 Jul 1982 1047-PDT (Saturday). Mark, Once and for all, the blank-to-period mapping is WRONG! I cite a classic Berzerkelyism as an example. Berknet (for those of you who don't know) is an odd little network which strings machines together on the Berkeley campus, and other places not fortunate enough to have anything better. It works fine, but (one of) its address syntaxes is machine.person If you adopt "pointifying", how do intend to tell, other than by context sensitive crufty lookups, whether the period is meaingful or not?? Periods are already overloaded; they don't need to do the job for blanks too. If all this means that someone will have to fix Mail to handle quote strings in addresses, well, zemzabreaks. Nothing works forever, and Berkeley has never show excessive reserve over hacking "improvements" before. It would probably take Kurt about half an hour. -Mike O'Dell  Date: 18 Jul 1982 0733-PDT Sender: GEOFF at SRI-CSL Subject: I think these UUCP headers are getting out of hand . . . From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: Header-People at MC Message-ID: <[SRI-CSL]18-Jul-82 07:33:23.GEOFF> Notice the following header... i think it is so long, it is causing the UCB gateway software to muck up. When I rcvd the enclosed message (below), it caused HERMES to blow up with a BCPl STACK OVERFLOW. Could the appropriate UCB person please fix? Mail-From: ARPANET host MIT-AI rcvd at 18-Jul-82 0031-PDT Date: 16 Jul 82 13:19:54-PDT (Fri) From: menlo70!sri-unix!hplabs!menlo70!sytek!zehntel!teklabs!ucbcad!ARPAVAX.CSVAX.decvax!utzoo!watmath!dmmartindale@BerkeSubject: Re: type certificated lawn chairs Subject: Re: type certificated lawn chairs To: aviation@mit-ai Article-I.D.: watmath.3045 Via: news.usenet; 17 Jul 82 23:50-PDT Actually, don't you also need to have a VHF radio on board and be in communication with ATC to operate a lawnchair at that altitude? WRT to transponders, wouln't you need some sort of metallic shielding between yourself and the antenna just for safety? Also, aren't their rules covering the dropping of objects from aircraft? I seem to remember that he lost a pair of glasses at least and maybe his air rifle.  Date: Sat 17-Jul-1982 18:23-EDT From: Stephen Tihor To: header-people at MIT-MC Subject: re: quoting and non 1 case alpha names I suggest you speak to someone on a Multics system before you pull the usernames out from under them or insist that they rewrite their mailer because you don't think you can replace yours. As I said earlier I am not sure what people really need arbitrary 7-bit ASCII mailbox names for but this is not a real problem: the mail software will be rewritten to handle it. DARPA will see to that for BSD Unix and sensible people elsewhere will follow suit. Some won't. Since very few people use Mixed-case/Funny-Character mailboxes right now, it won't be that hard on those too lazy or sloopy to do it. (I just can't see defending that level of laziness or sloppiness with much vehemence.) But if it is desired that one be able to do this then the standard should either say so or say that it isn't saying so -- and thus warn people to expect anything quoted. The important question is will spaces be significant w/o quoting in son-of-RFC733 mailbox names. I don't really care. If someone with a technical reason ... such as "it makes the syntax ambiguous with the current whitespace definitions" ... says it is trouble fine. There should probably be a note to the effect that any of the characters are legal in a mailbox name but using any of the characters will require the name to be quoted or the character to be escaped. OK?  Date: Monday, 19 Jul 1982 10:32-PDT To: header-people at MIT-MC Subject: Re: people names In-reply-to: RWK's message of Friday, 16 July 1982, 21:38-EDT. From: greep at RAND-UNIX Just for the record, the stuff that comes from Berkeley is not the only Unix software that talks to Arpanet mail, as a number of messages have seemed to imply.  Date: Monday, 19 Jul 1982 10:36-PDT To: mo at LBL-UNIX (Mike O'Dell [system]) Cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names In-reply-to: Your message of 16 Jul 1982 19:58:33-PDT. From: greep at RAND-UNIX In regard to your argument about the difficulty of parsing names with unquoted spaces, I will reiterate my suggestion that the spec include an algorithm for parsing whatever it claims is legal. Then all this trickiness has to be taken into account only once, by the authors of the spec, and implementors have only to turn the algorithm into code for their systems. Does anybody have any comments on this idea?  Date: Mon 19-Jul-1982 22:06-EDT From: Stephen Tihor To: header-people at MIT-MC Subject: Re: Multics and Case Dependance The question of Case Dependance had already been argued out over the net once (in Human-Nets as regards variable names as I recall) and I have no desire to refight it; especially when I am in favor of maximal mixed case support. However I am of the faction which considers use of case for disambiguation dangerous. Not that it must NOT be done; just that it has many obvious risks and if one does not NEED to do it, one should not. Thus if the mail receiver at MIT-Multics does not map VONFOO@MIT-MULTICS into whichever of "VonFoo" and "vonFoo" is the actual mailbox it was very poorly designed. If the system administrator at MIT-Multics authorized both "VonFoo" and "vonFoo" as legal username/mailboxes then he/she was also very poorly designed.  Date: 20 July 1982 00:32 edt From: Frankston.SoftArts at MIT-MULTICS Subject: re: quoting and non 1 case alpha names Sender: COMSAT.SoftArts at MIT-MULTICS Reply-To: Frankston at MIT-MULTICS (Bob Frankston) To: Stephen Tihor , header-people at MIT-MC *from: BOB (Bob Frankston) Local: Stephen Tihor ,header-people at MIT-MC Original-date: 19 JUL 1982 07:56:12 For clarification about Multics mailbox names: In general, users who get mail from the Arpanet have simple mailbox aliases that are case insensitive. The Multics file system is case sensitive and the mapping of a mailbox name to a filename is straightfoward but might be ambiguous if case were ignored. One can argue that the Multics file system should or should not have been case sensitive, but it is one thing to require a mailer be modified, it is another thing to require an operating system be rewritten.  Date: 20-Jul-82 09:39:32-EDT (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: multics and case sensitivities Via: cbosgd.uucp (V3.94 [3/6/82]); 20-Jul-82 09:39:33-EDT (Tue) To: header-people@mit-mc What? I had always assumed that Multics had some good reason for insisting that I capitalize mailboxes exactly as it does. Now you're telling me that it's just because the filesystem supports mixed case? Good grief. The UNIX filesystem supports mixed case too. And there are zillions of UNIX sites around. But you'll notice this problem hasn't come up on UNIX. The reason is simple: all UNIX login names are always all lower case. Thus, if a mixed or upper case address comes in, it can be simply mapped to lower case before processing. Even if Multics logins have mixed case, the problem is easily solved by having the incoming mail program map the address into one case, the consult a table of similarly mapped local names. I got the impression from Bob Frankston's letter that this solution is already in effect on Multics systems. So why do we still have the restriction that case must match exactly? Mark  Date: 20 July 1982 11:19 edt From: Barry Margolin at MIT-MULTICS Subject: Re: multics and case sensitivities Sender: Margolin.Multics at MIT-MULTICS To: cbosgd!mark at UCB-C70 (Mark Horton) cc: header-people at MIT-MC In-Reply-To: Message of 20 July 1982 10:48 edt from Mark Horton The solution that Bob Frankston mentioned is a not-well-advertised kludge. It involves asking the system administrator to add you to the system mail-table (implemented as a link in a special directory). This mail-table is only consulted when names without projects (the part after the dot) come in, and it is checked without case-sensitivity. It doesn't do us much good to tell us that our System Administrator shouldn't have assigned both userids "VonFoo" and "vonFoo". Supposing that they both exist on the same project (admittedly, an unlikely occurrence) who should get the mail addressed to VONFOO.PROJECT@MIT-MULTICS? In addition, to be fully case-insensitive, the project name would have to be checked case-insensitively and this would end up being a severe system bottleneck (there are several hundred projects on MIT-Multics, and it is not a very large Multics), since the directory hashing is presumably case-sensitive. Let me ask you this. Full upper/lower-case ASCII has been around for a long time. Why are your systems still folding everything you type to uppercase? Why not just let the programs that want to be case-insensitive do their own mapping (where the netmail-sender is not one of these)? If it is the case that the command processor folds all the arguments to one case, then just teach your mail-sending program to prompt for the names without folding. How many times do we have to keep saying that we are trying to design an interchange standard here, not a user interface?. barmar  Date: Tue 20-Jul-1982 12:15-EDT From: Stephen Tihor To: header-people at MIT-MC Subject: Mail box names. Yes I know that "vonFoo" and "VonFoo" in the example were intended to be distinct users. And as I said, creating such ambiguous users is bad planning. I agree that a mailer should not guess with of two near spellings a name should be mapped into. That function should be left to a trusted person or not attempted at all. There are several related issues involved with MMDF and the CSnet 'address server' function and there are security issues involved. In general I prefer adoption of the fail-safe principle that it is better not to deliever a message than to misdeliver it where privacy concerns exist. And I find remembering exact spelling and cases a pain. But that does not excuse mail senders from allowing full ASCII (or whatever mailbox character set is permited in son-of-RFC733) nor should it excuse the mail receiver from trying to map them.  Date: 20 July 1982 20:17-EDT From: Earl A. Killian Subject: spaces in names To: mo at LBL-UNIX cc: HEADER-PEOPLE at MIT-MC Now you're finally complaining about something of merit. But you've given no detail. What parsing problems?  Date: 20 July 1982 20:24-EDT From: Earl A. Killian Subject: case sensitivity To: HEADER-PEOPLE at MIT-MC Since this issue has been discussed so many times in so many mailing lists, and since many people seem completely and utterly unable to control their output on this subject, I suggest that someone create a special mailing list where these people may flame to their hearts content and leave the rest of us alone.  Date: 21 Jul 1982 08:25:11-PDT From: lblg!j#j at LBL-UNIX Mail-From: DECNET host j received by lblg at Wednesday, 21 Jul 82 08:07:22 PDT Date: Wednesday, 21 Jul 82 08:05:29 PDT From: j (sventek j) @ j Subject: Blanks in addresses To: header-people at mit-mc, @, lblg!lbl-unix at LBL-UNIX, < at lbl-unix, header-people at mit-mc> It is quite clear from RFC733 and its proposed successor: lists of addresses in message headers are to be separated by commas. As such, parsing of blanks represents no (I repeat, NO) more problems than parsing the letter 'a'. It seems that all of this flaming about blanks in addresses is due to the fact that a large portion of the UNIX faction want ARPA message headers to conform to UUCP's format, and not vice versa. Those of us required to interface to mail systems which differ in internal format and addressing syntax from canonical RFC733 have been forced to provide gateway software to massage the messages, as mentioned in the previous entry from NYU. Since we are interested in a short-term modification to RFC733 for the ARPA Internet community, it seems perfectly reasonable to require that messages from other networks (UUCP included) be gatewayed to and from the Internet. As such, the messages should be modified to the format which conforms to RFC733+. The left to right address structure does not need to be converted, since everything to the left of the '@' is non-interpreted. Exactly the same treatment will be necessary to gateway to any other mail system, be it based upon the NBS standard or any other format which differs from RFC733+. As for the user composition utility interface for specifying addresses, I provide two in our Software Tools Mail System: a clone of sndmsg which requires that users specify separating commas between addresses, and an utility named mail which takes the addresses from the command line. As such, if the user wishes to embed a blank in the address, s/he must type % mail "user at host" Of course, the address will be properly formatted into the message, with '@' replacing " at " (as per RFC733+) and commas separating addresses, if more than one was specified. I, for one, am considering placing support for blanks in user names into my delivery system. I get the impression that CMU did this quite a while ago, and was forced to eliminate it. Since we are supposed to be progressing in this field, and since it seems totally reasonable to specify an address of the form Joe Sventek at j.lbl, it would seem that the more long term decision would be in favor of permitting blanks in addresses. If we dodge it this time, it will surface again later, when there will be even more inertia towards the modification of the existing mail delivery programs. Joe Sventek  Date: 21 Jul 1982 06:55:00-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: EAK at MIT-MC cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names In-reply-to: Your message of 20 Jul 1982 1725-PDT (Tuesday). The crux of the issue is "when is whitespace important". If the rule is that "whitespace embeded in an atom must be escaped" the the following are legal: "Random User"@SOMEHOST or Random\ User@SOMEHOST The following is also ILLEGAL (or subject to surprise interpretations): Random User@SOMEHOST They can also be parsed unambiguously. If, however, the "quoting rule" is not adopted, how is the following supposed to be parsed? "One User"@SOMEHOST, Another User@SOMEHOST Is the blank after the command and before the "A" part of the mailbox name?? If you say yes, then all whitespace is treated literally; we can't allow whitespace in the lists except where it is real. If you say "no", how do you have a mailbox name with leading whitespace? Not that I am suggesting mailbox names with leading whitespace are good, but somewhere someone will do it, and the code has to handle all the cases. The only solution I can see is to quote the leading whitespace, so why not be consistant and just require that whitespace embedded in an atom must be quoted somehow. Either quoting the whole atom, or escaping the single character would work, and while I would advocate only one of the two mechanism (single character quoting is slightly easier to parse and isn't a real aesthetic problem since this is an INTERCHANGE standard), but since the rest of the document has both "" and \ schemes, they should both be allowed. -Mike  Date: 21 July 1982 1256-EDT From: Rudy.Nedved at CMU-10A To: mo at LBL-UNIX (Mike O'Dell [system]) Subject: Re: spaces in names CC: HEADER-PEOPLE at MIT-MC In-Reply-To: mo@LBL-UNIX's message of 21 Jul 82 08:55-EST Message-Id: <21Jul82 125634 EN0C@CMU-10A> Mike, I agree that double quotes and the escape character should be allowed in names and that everyone should accept them. Fine with me but if a site has white space independent "white pages" name mapping functions then they should be allow to send out names with any amount of leading, intervening and trailing white space in a name. At CMU, we will soon be supporting names like: Dr. Raj Reddy Krafty Ken Wertz Rudy TTZ Twilight Zone The Twilight Zone which are horizontal white space independent since we look at each white space delimited token and find the common person. Admittedly we will be sending out a mailbox specifier like "" in our mail so that people like "John Smith" can still recieve mail if there are three of them. -Rudy  Date: 21 Jul 1982 10:46:56-PDT From: ARPAVAX.eric at Berkeley Mail-From: UCBARPA received by UCBVAX at 21-Jul-82 10:42:42-PDT (Wed) Date: 21-Jul-82 10:42:57-PDT (Wed) From: ARPAVAX:eric (Eric Allman) Subject: Re: spaces in names Via: ucbarpa.EtherNet (V3.146 [7/20/82]); 21-Jul-82 10:43:00-PDT (Wed) Via: ucbvax.EtherNet (V3.145 [7/14/82]); 21-Jul-82 10:42:42-PDT (Wed) Phone: (415) 548-3211 To: EAK@MIT-MC, mo@LBL-UNIX Cc: HEADER-PEOPLE@MIT-MC It seems amazing to me that everyone is arguing about the "right" way to handle spaces in names -- somewhat like arguing the "right" way to worship the diety of your choice. "Obviously" spaces should be eliminated -- if you view spaces as being part of an atom, then you get into the problem of leading spaces. Not to mention multiple spaces inside the name. How about the person who has the "user name" of space? I can't wait for " (Blankety B. Blank) at MIT-Multics"! [ed. note: is this two significant spaces followed by an insignificant space before the left paren, or three significant spaces?] Equally "obviously" a mailbox name should be a sequence of atoms, coincidently separated by spaces in some circumstances (or multiple spaces!), then the problem is "easy" -- or is the debate on how to write a scanner for Pascal still raging? But these are not the only issues. I certainly agree that we should be moving forward. But blindly moving forward can be dangerous. And besides, what is forward? For example, the Arpanet community is obviously moving away from NCP toward TCP. One approach would be to turn off NCP on January 1, 1988 and turn on TCP. Using a hardline approach, one can conclude that it would serve the *******'s right to get cut off if they were unable to convert in time. After all, why should they hold us back? But in a cooperating research community (we are cooperating, aren't we?) that kind of approach is not feasible. We all make compromises for the good of the whole. The transition plan is a pain, but it exemplifies the cooperative attitude. As for the issue of "what is forward," it seems clear to me [note my explicit assumption here] that the direction is away from huge mainframes. MIT and CMU may have PDP-10's, and Berkeley may have VAXes, but many compromises have been made in the SMTP protocol to permit "fuzzball" hosts. Such hosts may be assumed to have limited memory (16 bits, possibly even shared with the OS) and limited processing capability. I grant you that parsing a series of atoms is not conceptually difficult, but when you find yourself down to having 120 bytes to implement it in, this can look like an impossible task. In situations like this, it is not improbable that spaces will be treated as significant characters, rather than just as token separators. To the extent possible, we build protocols and standards that scale up and down conveniently. Domains, for example, give a fuzzball the opportunity to punt on everything -- just pass it to someone smarter. This doesn't restrict what that smarter host can do -- it can try to know the topology of the entire internet, if it wants. But sometimes absolute restrictions are necessary. Unpleasant, perhaps, but still necessary. This may be one of those times. I can certainly understand Earl Killian's position -- Mike looks pretty silly, especially in the face of the multiple space example. But Mike is injecting a bit of reality into these discussions that cannot be ignored -- given the opportunity, someone WILL have a mailbox name consisting of only a space. Or to put it another way, "if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's [hacker] logic." My intent here is not to come to any conclusions, but rather to present the issues as I see them. Maybe this will help the two factions talk a little more and scream a little less. eric  Date: 21 Jul 1982 1151-PDT From: Jon Solomon Subject: Re: spaces in names To: Header-people at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 21-Jul-82 0655-PDT Spaces could be permitted between tokens in a name, but could be considered ignored if after a separator (or even just before it). The parsing could look for a real character then stop parsing when he got an @, i.e. To: Foo@FOOHOST, Jimmy Jones@BARHOST It's pretty clear how to get Foo, you parse until the @, then you gobble down FOOHOST until you see the ",". Whats next is a space, throw it out. Then you see the J in Jimmy. Parse from there until you get to the @, including the whitespace. Finally gobble down the BARHOST until you see a newline character. This seems fairly simple, and also has the benefit of a real world mapping. To: D. Johnson, F. Bakeley Cc: All Staff Subject: Travel Reimbursement ..... This would be a reasonable header for a non network memo, and would be parsed similarly to the way I described above. The same could be said for whitespace which is located after the Jones but before the @ but since we really seem to want right to left parsing, I won't go into too much detail about it. Jon Solomon@USC-ECLC is reasonable, even though Jon Solomon @USC-ECLC would be better visually (I know, I can make my mailer visualize it anyway I want). I don't think this violates the transport protocol issues, while at the same time allows the feature of a username containing spaces. Which has the benefit of making computer mail in general more acceptable to the world (i.e. not just the Arpanet or Internet community). Down with usernames, up with Personal Names (am I dreaming again?). Cheers, --JSol -------  Date: 21 July 1982 17:38 edt From: Palter at MIT-MULTICS (Gary M. Palter) Subject: Re: spaces in names Sender: Palter.Multics at MIT-MULTICS To: Header-People at MIT-MC In-Reply-To: Message of 21 July 1982 09:55 edt from Mike O'Dell [system] The current draft standard does not allow: John\ Doe@MIT-Multics as a valid address. The left part of an address must consist of one or more words separated by dots. A word is either an atom or a quoted string. An atom can not contain space or any special characters. The backslash is a special character. Thus, you have to say: "John Doe"@MIT-Multics Note that you still have to understand whitespace in the local part of an address. The standard states that wherever a delimiter (and "." is a delimiter in the local-part) may appear, it may be surrounded by whitespace. Thefore, John . Doe@MIT-Multics is legal. Its canonical form is John.Doe which is used mostly when talking with systems which do not support this protocol. So you must still allow whitespace in addresses. However, the whitespace is now always thrown away.  Date: 21 July 1982 17:51 edt From: Frankston.SoftArts at MIT-MULTICS Subject: Re: multics and case sensitivities Sender: COMSAT.SoftArts at MIT-MULTICS Reply-To: Frankston at MIT-MULTICS (Bob Frankston) To: cbosgd!mark at UCB-C70, header-people at MIT-MC *from: BOB (Bob Frankston) Local: cbosgd!mark@Berkeley (Mark Horton),header-people@mit-mc Original-date: 21 JUL 1982 08:13:24 A Multics user can have a large number of names recognized but is not forced to do so.  Date: 21 July 1982 19:10-EDT From: Frank J. Wancho Subject: spaces in names To: HEADER-PEOPLE at MIT-MC How many people have noticed that the four TABs at the end of the Subject: line in EAK's original message (and this one) has been repropagated by each person replying to it, or that they were there in the first place? I doubt if it has any significance or if anybody cares - just thought it interesting. Earl: is this a test of some sort? --Frank  Date: 21 Jul 1982 17:01:14-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: Rudy.Nedved at CMU-10A cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names In-reply-to: Your message of 21 Jul 1982 1007-PDT (Wednesday). <21Jul82 125634 EN0C@CMU-10A> But how is my parser supposed to know that at site X blanks are significant and that at site Y they are not? -Mike  Date: 21 Jul 82 16:14:53-PST (Wed) From: Stef.uci at UDel-Relay To: header-people at Mit-Mc Subject: Re: case sensitivity Via: UCI; 21 Jul 82 20:05-EDT The Triumph of Technology! Can Implies Shall! Or was it: cAN iMPLIES sHALL? Or was it: ...  Date: 21 Jul 1982 17:22:39-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: header-people at mit-mc Subject: blanks If we can all agree JSol's algorithm embodies what we mean, the I, for one, am happy. (As if it matters much!) My concerns have centered around the need for a canonical form, or at least canonical interpretation of address form. JSol seems to be implying a canonification scheme where "leading spaces" disappear while embedded strings of spaces show up as at least one per string. If you want more bizarre things, quote them. I am repeating this to see if I understand the meaning of what is proposed. Is this right, or have I missed the boat again? -Mike  Date: 21 July 1982 2112-EDT From: Rudy.Nedved at CMU-10A To: mo at LBL-UNIX (Mike O'Dell [system]) Subject: Re: spaces in names CC: HEADER-PEOPLE at MIT-MC In-Reply-To: mo@LBL-UNIX's message of 21 Jul 82 19:01-EST Message-Id: <21Jul82 211258 EN0C@CMU-10A> Mike, You must be talking about a bad parser again or the Unix shell? Can I send mail to "Mike O'Dell"? You can send mail to "Rudy Nedved" at any of CMU's TOPS-10 and UNIX sites. Can't you write a parser that uses spaces and at-signs as delimiters instead of dots? I thought the problem was dealing with ids that have leading or trailing white space. (I can't believe someone would actually use such a feature but who knows?) This business with dots is left over from people unable to write parsers. Gee whiz a second year undergraduate at CMU can write a parser to do RFC733 in PASCAL! Why can't we look into the future and say UNIX and C is hot and that people will implement good mail systems. I know CMU and Standford will have such systems shortly (sooner the this spec gets released the better). Oh, I suppose you send mail to 'Dr\..Raj.Reddy" under your system? -Rudy  Date: 21 Jul 1982 1856-PDT Sender: CERF at USC-ISI Subject: Re: multics and case sensitivities From: CERF at USC-ISI To: Barry Margolin at MIT-MULTICS Cc: header-people at MIT-MC Message-ID: <[USC-ISI]21-Jul-82 18:56:12.CERF> In-Reply-To: Your message of 20 July 1982 11:19 edt Barry, it must be frustrating to have had upper/lower distinctions so long and to find that there is still a large community which cannot manage them - however, I find myself occasionally using terminal equipment which is still not upper/lower capable, and I am pretty sure the military has a lot of that stuff still around, so we have continued to fold up to upper case only to accommodate this large installed base. There may be other reasons as well, which others will be able to articulate, but this certainly will continue to be aproblem. Your solution would mke impossible the composition of messages to Multics users from terminals not easily able to generate lower case (or which do so very awkwardly, at least). Vint Cerf  Date: 21 Jul 1982 19:13:07-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: Rudy.Nedved at CMU-10A cc: HEADER-PEOPLE at MIT-MC Subject: Re: spaces in names: laboring under bad assumptions In-reply-to: Your message of 21 Jul 1982 1830-PDT (Wednesday). <21Jul82 211258 EN0C@CMU-10A> No, I was not talking about the period business (I already defended the position that blanks were good and period-mapping was evil), nor the difficulty of writing a parser. The sophomore will also admit the hard part is the semantics, not the syntax. However, I think I finally understand: my august collegue Joe Sventek was right in his comment; it doesn't matter! Before you blast, let me explain!!!! If we ignore where user aliasing is done for a moment, for a mail router to do its job, it really only needs to look at the RIGHT hand side of the address, ie, to the right of the at-sign. If you have a mail router which queues messages to different output channels for network mail-splicing (such as Delivermail, Sendmail, MMDF, and others), they should be able to tell what to do from the right hand side. If you decide a message needs "local delivery", then and only then do you need to interpret the left hand side. If the message isn't local delivery, just present the address as you got it, cracking on commas. Simple as "find the at-signs". If the message IS local delivery, then you implement whatever policy about name mapping your local host wants to implement. If you have white-pages service, wonderful. If you insists mailbox names be spelled backwards with opposite case, fine. But the only host this should bother is the one which will do "local delivery". Noone else need see that part anywhere else. This is complicated slightly if you are doing aliasing, but I don't think it is much harder. On our system at least, an alias, or sometimes known as an "exploding" mailing list, looks like a local address which is macro expanded lower. The macro expansion text is arbitrary addresses, so interpretation is an issue again only for local addresses. Does this sound reasonable?? -Mike  Date: 21 July 1982 22:43-EDT From: Earl A. Killian Subject: blanks To: mo at LBL-UNIX cc: HEADER-PEOPLE at MIT-MC The first thing to recognize is that you can always used a quoted string for weird things such as " Leading Space Willy". I was surprized that you can't use \ in atoms, as Palter points out, but on close reading of the BNF I find that he's right. As a completely separate issue what do people think of changing the syntax of atom to understand the quoted-pair convention? My original suggestion is to have a simpler syntax for the common case of addresses with blanks, not for the weird ones. There are currently two suggestions on how to do this, if that is what we decide to do. One, which Jon Solomon recently suggested is to have special parsing rules involving leading spaces and embedded blanks. The other, suggested by Eric Allman, is to change the syntax from local-part = word *("." word) to local-part = word *(["."] word) which is how I had always assumed it would be done. Thus an address sent as John Q. Doe is parsed as 4 tokens and the mailbox name used in SMTP is constructed from these tokens by rules added to the rules that already exist for multi-token local-parts (see section 6.2.4). Presumably, it would come out as the string "John Q. Doe".  Date: 22 July 1982 11:30 edt From: Palter at MIT-MULTICS (Gary M. Palter) Subject: Re: blanks Sender: Palter.Multics at MIT-MULTICS To: Header-People at MIT-MC In-Reply-To: Message of 21 July 1982 23:05 edt from Earl A. Killian If you make the definition of local-part be: local-part = word *(["."] word) then, according to the treatment of whitespace in section 3.4.1, the local-part: John Q. Public would have a canonical representation of: John Q.Public I think that we should simply eliminate any special treatment of periods within local-part and make the definition be: local-part = 1*word with the semantics that leading and trailing whitespace surrounding the local part is thrown away and all whitespace within the local-part is compressed to single spaces.  Date: 22 July 1982 1342-EDT (Thursday) From: Richard H. Gumpertz To: Header-People at mit-mc Subject: SPACES in names Message-Id: <22Jul82 134218 RG02@CMU-10A> It occurs to me that ALL communications require delimiters or counts for variable length fields. Why should mail be different? Therefore, given that this is just a TRANSPORT mechanism, and NOT a user interface, why not require quoting of ALL names? That simplifies parsing considerably -- all user names will be of the form "..."@site. Just look for the closing quote (skipping over \" if present) to find the user name. Of course, these quotes can be hidden from users by the user interfaces in any manner appropriate to a given system. Rick  Date: 22 Jul 1982 1242-PDT From: Craig Milo Rogers Subject: Re: SPACES in names To: Header-People at MIT-MC In-Reply-To: <22Jul82 134218 RG02@CMU-10A> I second the motion to use quoted strings for in child-of-RFC733. Similarly, in the current SMTP draft RFC should be restricted to a quoted string. Functionality is neither added nor lost (from the perspective of computer/computer interchange standards) by imposing these restrictions. The restricted forms carry the same information as the previous form, and are simpler to implement. Furthermore, it would be clearer in the RFCs how "special situations" (such as spaces within mailbox names) are handled (they turn out not to be special after all). Thus, the implementors might spend more time implementing, and less time dabating. The hard problems have not been eliminated; they've simply been pushed into another room. Mail composition programs will still have to allow a user to send messages to peculiar mailbox names. Mail reading programs will still have to decide how to display mailbox names with embedded terminal control sequences. Mail gateways will still have to transform mail between child-of-RFC733 and other standards in order to reach certain recipients. Certainly, people will have trouble communicating with each other if their mail systems apply sufficiently divergent transformations between the user representation and the interchange forms of their mail, such that they can't exchange mailbox names over the phone. Restrictions upon the content of mailbox names would greatly simplify these tasks. However, such restrictions can be adopted quite independently of novo-RFC733 and novo-SMTP. After all, what's another standard among friends? Craig Milo Rogers -------  Date: 24 Jul 1982 0039-PDT From: Stef Subject: [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:] To: header-people at MIT-AI I realize the the discussion of the need for a TO field may be passe by now, but his looks like a classic example for consideration. I think it argues quite eloquently for a standard requirement for some way to identify who might be the intended recipient. --------------- Mail-from: ARPANET site BRL rcvd at 23-Jul-82 2035-PDT Date: 22 Jul 1982 20:23:15-PDT From: npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70 Via: Mit-Mc; 23 Jul 82 16:19-EDT Via: Brl; 23 Jul 82 16:27-EDT Via: Brl-Bmd; 23 Jul 82 16:43-EDT I'd like a copy of the results, please. Lynda Feng --------------- We are concerned with an interchange standard, indeed, but it is a COMMUNICATIONS interchange standard. By the definitions I know, if there is no meaning transmitted, then there is also no communication, though bandwidth may have been consumed. I assume that we are concerned more with genuine communication than with achieving consumption of bandwidth. If my assumption is correct, then we should be less interested in the narrow view that "there is no technical need for a TO field," and more interested in the view that "the recipient NEEDS to know to whom the recieved item was addressed." I believe this is true even when the recipient is a process (agent) rather than a person. Indeed, at UCI we just ran into a serious design problem with some BBoard software because we were trying to sort mail into files based on the header information rather than the envelop information. This suggests two solutions: 1. Require that the envlope's delivery address must be included in th header fields. [Addition to 733+] 2. Improve our User Agents and Delivery Agents to record what was on the envelope. There should be nothing in the standard that requires that this information be discarded upon delivery! [733+ as is!] But, then there must be a requirement somewhere that this informtion will be preserved till delivery time so the User Agent may decide the disposition. There is a suggetion in this that the recipient has some rights in the data carried in (on) the envelope. Rather interesting, I'd say ... Stef -------  Date: 24 Jul 1982 0100-PDT From: Stef Subject: Whom To? To: header-people at MIT-AI I realize the the discussion of the need for a TO field may be passe by now, but his looks like a classic example for consideration. I think it argues quite eloquently for a standard requirement for some way to identify who might be the intended recipient. --------------- Mail-from: ARPANET site BRL rcvd at 23-Jul-82 2035-PDT Date: 22 Jul 1982 20:23:15-PDT From: npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70 Via: Mit-Mc; 23 Jul 82 16:19-EDT Via: Brl; 23 Jul 82 16:27-EDT Via: Brl-Bmd; 23 Jul 82 16:43-EDT I'd like a copy of the results, please. Lynda Feng --------------- We are concerned with an interchange standard, indeed, but it is a COMMUNICATIONS interchange standard. By the definitions I know, if there is no meaning transmitted, then there is also no communication, though bandwidth may have been consumed. I assume that we are concerned more with genuine communication than with achieving consumption of bandwidth. If my assumption is correct, then we should be less interested in the narrow view that "there is no technical need for a TO field," and more interested in the view that "the recipient NEEDS to know to whom the recieved item was addressed." I believe this is true even when the recipient is a process (agent) rather than a person. Indeed, at UCI we just ran into a serious design problem with some BBoard software because we were trying to sort mail into files based on the header information rather than the envelop information. This suggests two solutions: 1. Require that the envlope's delivery address must be included in th header fields. [Addition to 733+] 2. Improve our User Agents and Delivery Agents to record what was on the envelope. There should be nothing in the standard that requires that this information be discarded upon delivery! [733+ as is!] But, then there must be a requirement somewhere that this informtion will be preserved till delivery time so the User Agent may decide the disposition. There is a suggestion in this that the recipient has some rights in the data carried in (on) the envelope. Unfortunately, this is not simple, because aliasing systems can do many-to-one mapping with distruction of envelope information, just as occurs now with many group lists being delivered to one mailbox. In the narrow technical sense, I know that "it was TO the mailbox where I found it!" But, this is not what the recipient needs to know. Hmm, I feel more like I do today than I ever have! ... Stef -------  Date: 25 Jul 82 11:55:41-EDT (Sun) From: Dave Crocker To: Stef cc: header-people at Mit-Ai Subject: Re: [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:] For reference, the recent drafts of the standard have been requiring at least one "standard" address field. See the rule, in the spec. Dave  Date: Sunday, 25 Jul 1982 12:34-PDT To: Stef Cc: header-people at MIT-AI Subject: Re: [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:] In-reply-to: Your message of 24 Jul 1982 0039-PDT. From: gaines at RAND-UNIX There was an additional problem with the message from Feng: no "subject" entry in the header. The general problem is giving people enough information to deal well with the messages they receive. But I'm not sure the problem should be dealt with at the level of standards for message headers. In the cases that have been discussed lately, almost all the examples of problems have come from messages sent to broad lists of recipients. I suggest that the redistribution software for discussion groups, BBoards, etc., may be the right place to impose additional standards, applicable only to their needs. For these lists, both some indication of who is message is being sent to and what the subject of the message is should be required. The software that accepts and redistributes such messages could add a field such as "To: info-cpm", and return a message without a subject field to the sender. Since there may be valid situations for sending a message without a "to" or "subject" field, I would hesitate to require this in all messages.  Date: 25-Jul-82 18:27:39-EDT (Sun) From: cbosgd!mark@Berkeley (Mark Horton) Subject: to, subject, mailing lists Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jul-82 18:27:40-EDT (Sun) To: header-people@mit-mc.arpa If you're going to differentiate between mass mailings and personal mail, you might as well do it right and make them totally separate systems. It is important that it be obvious not only to whom/what the message was sent, what it is about, but also whether it is mail (e.g. addressed to a person) or news (e.g. a mass mailing). The easiest way to do this is to have separate systems for mail and news. (Tell me now, how many of you really think it's a winning feature that all your mass mailing lists get interspersed with your personal mail?) If this isn't done, there should at least be a header that indicates a mass mailing, so a program can tell the difference without knowing the names of every list in the world (and all the possible ways of spelling that list that will work). USENET has been running as a separate news system for years. Having mail and news grouped separately goes a long way toward solving the "Electronic Junk" problem in Denning's article. Mark  Date: 18 July 1982 22:13 edt From: Barry Margolin at MIT-MULTICS Subject: Re: quoting and non 1 case alpha names Sender: Margolin.Multics at MIT-MULTICS To: Stephen Tihor cc: header-people at MIT-MC In-Reply-To: Message of 18 July 1982 20:14 edt from Stephen Tihor The problem with mixed case on Multics has nothing to do with our mail system. It is in our usernames themselves. It is quite conceivable that there would be two users whose names differed only by case, i.e. "VonFoo" and "vonFoo". In this case the system distinguishes the users by their names with respect to case - who should get the mail addressed to "VONFOO@MIT-MULTICS"? barmar  Date: 26 July 1982 01:11-EDT From: David A. Moon Subject: personal mail vs mass mailings To: HEADER-PEOPLE at MIT-MC Date: 25-Jul-82 18:27:39-EDT (Sun) From: cbosgd!mark@Berkeley (Mark Horton) Subject: to, subject, mailing lists Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jul-82 18:27:40-EDT (Sun) To: header-people@mit-mc.arpa If you're going to differentiate between mass mailings and personal mail, you might as well do it right and make them totally separate systems. Both the ITS and 20X mail systems provide complete flexibility to the recipient of mail, such that personal mail and mailing-list mail can be delivered to the same mailbox or to separate mailboxes, as the user prefers. Different mailing lists can be delivered to different mailboxes. Many users have taken advantage of this capability in the ITS mail system for at least 5 years. If personal mail and mass mail were delivered by separate systems, it would not be possible to have flexibility so that the individual recipient of the mail could decide into how many and what categories his mail should be sorted by the delivery system. Anyway, this doesn't have anything to do with mail headers, nor with standards for intercomputer communication.  Date: 25 Jul 1982 2249-PDT From: Mark Crispin Subject: case in names Sender: ADMIN.MRC at SU-SCORE To: Header-People at MIT-MC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The problem with the "vonFoo" vs. "VonFoo" analogy is that the use of case sensitivity doesn't help enough! Most people would not see the difference on first glance; neither would it stick in most people's minds for long. This is similar to what I like to call the "Smith problem"; you want to send an urgent and confidential message to Joe Smith at FOO-HOST. The mailer at FOO-HOST recognizes a mailbox named "Smith", but how do you the sender know that it is the Smith you want? Many sites cop out by letting the first Smith on the system be Smith, then adding JSmith, DSmith, JASmith, and ultimately JA2Smith! Don't laugh, something like this really happened at a Stanford site. The problem with case sensitivity is that it could give a site and its users a false sense of uniqueness while at the same time causing needless inconvenience. Suppose there is only one "vonFoo". A case-sensitive mailer would reject VONFOO, VonFoo, Vonfoo, and vonfoo even though it is obvious to anyone that the intended recepient was vonFoo. At the very least VONFOO and vonfoo should always be recognized. In the first case you help people on upper-case only terminals; in the second you support the people who refuse to use upper case under any circumstances (it is, remember, an accepted if non-traditional writing style to use lower case exclusively). If there is a VonFoo and a vonFoo, it should be treated the same as if there were two vonFoo's; "vonFoo" should be considered ambiguous and more data be required. I'll confess that "more data be required" will make much more sense when we have mailbox name servers. -------  Date: 25 Jul 1982 2256-PDT From: Stef Subject: Re: to, subject, mailing lists To: header-people at MIT-AI In-Reply-To: Your message of 25-Jul-82 1527-PDT Hi Mark - Et al ... Regarding institutionalization of junk vs non-junk: I generally find it awkward to have to use different tools to process junk mail, which tends to be the result if they are really two different systems. I also see no problem with achieving separation based on use of different addresses for different functions . For myself, I have several different mailboxes which represent my different roles. One, NMAX@ECL, is used for groups lists. (I have learned not to call it my "junk mailbox" after Jon Postel challenged my request to have some of his TCP mail sent to NMAX if I was going to consider it JUNK!) One person's JUNK MAIL is another's GOLD! I have another mailbox for my "corporate offices" where I accumulate more or less official type stuff like invoices and contract messages. The fact is that there is no rule about "One Person, One Mailbox." I regard it as a rather adroit use of the mail system to automatically get my mail sorted by using different mailboxes for different roles, and in particular to get my "First Class Mail" directed to my primary mailbox, and other mail directed to lower priority mailboxes. I like to make a sharp distinction between urgent and important mail. Important mail can generally wait a bit for processing, but urgent mail should get through to get priority attention. I am often surprised by how many netmail users have only one mailbox, and then complain about having to sift the wheat from the chaff. The solution is quite obvious, and it does not require instiutional separation of all mail into junk/non-junk classes. I have already achieved this kind of separation, according to my values, and not deterimined by what someone else thinks is junk, or not junk. So, to end this missive, I want to clearly state that I do not think that the junk/non-junk mail issue belongs in a standards discussion, and certainly does not belong in a standards document. The means of separation are inherent in the whole scheme of things, and nothing special needs to be done. Best - Stef -------  Date: 26 July 1982 0447-EDT From: Rudy.Nedved at CMU-10A To: Header-People at MIT-MC Subject: spaces/dots in names Message-Id: <26Jul82 044736 EN0C@CMU-10A> It seems no one is talking about spaces and periods in names anymore. Does this mean the specification is as Gary Palter put it: local-part = 1*word meaning names like Rudy Nedved@CMU-10A "Dr. Raj Reddy"@CMU-10B work? Or did the RFC decision makers decide otherwise? -Rudy  Date: 26 Jul 82 6:50:24-EDT (Mon) From: Dave Crocker To: Rudy.Nedved at Cmu-10a cc: Header-People at Mit-Mc Subject: Re: spaces/dots in names The new syntax will permit/require: "Dr. Raj Reddy"@CMU-10A and Raj.Reddy@CMU-10A but will not permit: Raj Reddy@CMU-10A. Dave  Date: 26-Jul-82 10:55:33-EDT (Mon) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: to, subject, mailing lists Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jul-82 10:55:34-EDT (Mon) To: header-people@mit-mc.arpa Now hold on, I never said that different tools had to be used. All I said was that there be separate systems. Perhaps I should have said two "channels". There is a movement now to allow the same tools to be used to read news and mail. (Right now, the mail tools work with news, but not all that well.) However, when you think about it, there really are some things you want to do differently with news. At the transmission level, you don't want to send 50 copies of the same message over one link. You really want to pass one copy over each link and let the system on the other end of the link pass it on to its neighbors. Also, you don't want to store a separate copy of each message for each user who subscribes to it - that wastes disk space. You just want to store one copy on the system, and give each user some kind of record of what s/he has already seen. (This is the fundamental reason for having separate tools in the first place. A better solution might involve "read-only" mailboxes, something I think the Rand MH system has.) You also want some high level controls of which permit a system to decide which newsgroups (mailing lists in the arpanet jargon) to accept and which to forward on to each of its neighbors. At the user interface level, you find things are similar to, but not quite the same as, mail. Posting does not have to go through a mailing list bottleneck, so news goes out faster, in spite of the 1200 baud dialup links used on much of USENET. (It can be argued that the bottleneck has advantages, such as the ability to insert a moderator.) You don't have to (a) hear from the grapevine that a new list exists, (b) figure out who to ask to put you on the list, (c) wait for this person to add you to the mailing list, (d) miss out on all the "back-issues" that came out before you joined; many people on USENET just get "everything except for certain things they unsubscribe to" and automatically see new stuff. When replying, there are two common things to do. (1) send a reply back to the sender only, (2) post a followup to the entire list. Mail systems don't necessarily do either of these well, although most do (1) I don't know of one that has a command to do (2) without sending two copies to the original sender and messing up the header enough to cascade the effect. Also, mass mailings have the property that much is uninteresting, so the user wants to be able to look at the subject and decide not to bother to look at it. (Some mail software can do this decently but most require you to start reading it and then hit interrupt.) Finally, there is the issue of the order you read things in: it's silly to first see "I have a program that does 'x' if anyone's interested" then "814-555-1234" then "does anyone have a recipe for cheesecake?" then "what's the phone number for decvax?". It's important for news to be sorted into a reasonable order - something that even a separate "mass-mailing" mailbox for each user isn't going to do. It isn't all that easy for a random person to have several mailboxes. A typical system will require creating separate logins for each mailbox (although some won't insist on this) and many administratively won't let you have more than one login and/or more than one mailbox. Some people won't/can't pay for more than one. To site a couple arcane examples, Comp Center A uses a person's department number and initials as their login, e.g. 51423jmc, and forces them to receive mail as such. Comp Center B lets people choose their login name, but in order to implement load leveling, moves them around from one filesystem to another or even from one machine to another, without warning, and makes no effort to make this transparent. Mark  Date: 26 July 1982 11:27 edt From: Palter at MIT-MULTICS (Gary M. Palter) Subject: Re: spaces/dots in names Sender: Palter.Multics at MIT-MULTICS To: Header-People at MIT-MC In-Reply-To: Message of 26 July 1982 10:02 edt from Dave Crocker Someone recently suggested that since we are defining an interchange standard, we should change the definition of the local-part of an address to quoted-string. Additionally, SMTP commands would be changed to accept only quoted-strings. I would like to second this suggestion.  Date: 26 July 1982 18:58-EDT From: Gail Zacharias Subject: to, subject, mailing lists To: cbosgd!mark at UCB-C70 cc: HEADER-PEOPLE at MIT-MC As I understand it, the distinction you make between mail and "news" is that the recipients of "news" are unspecified, to-whom-it-may-concern. (This is not the same as mailing lists on the arpanet btw). Basically, you have a mailbox which is not read-protected, so anybody can peruse the incoming mail. I don't see how this has anything to do with the other things you mentioned. In terms of efficiency, if I send a message to 50 specifically listed recipients, the mailer should only transfer one copy per site, and there is some advantage to only storing one copy at the receiving site until the recipients attempt to read their mail, etc. In terms of convenience, all the tools you mentioned for managing mail ("back-issues", i.e. archives, sufficient flexibility in generation of reply headers, ability to survey just the subjects of incoming mail, ordering your mail by topic) are applicable to personal mail. I have most of them in my mail reader and use them all the time. I'd certainly hate to have them restricted to just publicly accessible mail. The only special thing that news needs is a database of per-user last-read dates; after that, your regular mail reader should be able to handle all your needs in reading the stuff.  Date: 27 July 1982 02:33-EDT From: V. Ellen Golden Subject: remailed for Stef... To: HEADER-PEOPLE at MIT-MC From: Stef Subject: Re: to, subject, mailing lists To: header-people at MIT-AI In-Reply-To: Your message of 25-Jul-82 1527-PDT Hi Mark - Et al ... Regarding institutionalization of junk vs non-junk: I generally find it awkward to have to use different tools to process junk mail, which tends to be the result if they are really two different systems. I also see no problem with achieving separation based on use of different addresses for different functions . For myself, I have several different mailboxes which represent my different roles. One, NMAX@ECL, is used for groups lists. (I have learned not to call it my "junk mailbox" after Jon Postel challenged my request to have some of his TCP mail sent to NMAX if I was going to consider it JUNK!) One person's JUNK MAIL is another's GOLD! I have another mailbox for my "corporate offices" where I accumulate more or less official type stuff like invoices and contract messages. The fact is that there is no rule about "One Person, One Mailbox." I regard it as a rather adroit use of the mail system to automatically get my mail sorted by using different mailboxes for different roles, and in particular to get my "First Class Mail" directed to my primary mailbox, and other mail directed to lower priority mailboxes. I like to make a sharp distinction between urgent and important mail. Important mail can generally wait a bit for processing, but urgent mail should get through to get priority attention. I am often surprised by how many netmail users have only one mailbox, and then complain about having to sift the wheat from the chaff. The solution is quite obvious, and it does not require instiutional separation of all mail into junk/non-junk classes. I have already achieved this kind of separation, according to my values, and not deterimined by what someone else thinks is junk, or not junk. So, to end this missive, I want to clearly state that I do not think that the junk/non-junk mail issue belongs in a standards discussion, and certainly does not belong in a standards document. The means of separation are inherent in the whole scheme of things, and nothing special needs to be done. Best - Stef -------  Date: 26 Jul 82 15:14:53 EDT (Mon) From: Steve Bellovin Subject: mailing lists To: header-people at unc Via: UNC; 26 Jul 82 19:27-EDT I don't agree that multiple user-ids or mailbox names is an adequate substitute for a news or bulletin board system. Consider: at the moment there are 142 USENET 'newsgroups' active on this machine. About 20 of them are copies of assorted ARPA mailings lists. There's no way our system administrator is going to maintain 142 -- or 20, or possibly even 2 or 3 -- different mailbox names for every user. Not that using two different mailboxes is a solution -- it makes it harder for to keep different lists grouped together -- but maybe I've been spoiled by the USENET system. (What I'd really like is a way to group *conversations*, so I could barely skim all the messages related to, say, spaces in user-names, but my proposal to make Message-Id mandatory doesn't seem to have gathered any support.) What we should be talking about here, though, is what set of facilities should be defined by the standard that would allow a user's mail-reader to classify letters. It doesn't do me any good if USC-ECLB adds a 'Class: junk' line if BRL uses 'Distribution: list' while MIT prefers 'Group: SF-LOVERS'. I suppose I could always rewrite our mail system to accept addresses like 'smb/header-people@unc', but that's almost a cop-out. Perhaps we should adopt the 'Priority' and 'Class' fields from the NBS standard. I'm not suggesting they be made mandatory, just that we agree on the syntax and semantics of such lines so that folks who want them can use them. --Steve  Date: 26 Jul 82 22:03:48-PST (Mon) From: Stef.uci at UDel-Relay To: header-people at Mit-Ai Subject: Re: separate systems for news and mail Via: UCI; 27 Jul 82 5:09-EDT Hi Mark - et al - Again on the "separate systems for news" question There is nothing in your long list of difficulties and advantages that requires, or really even suggests, that a separate system is needed. But, I will agree that news nets that use the same mail servers as first class mail uses, should indeed use different procedures for efficiency, et al. However, I still see nothing to suggest that this issue has any relationship to our standards discussion. There is nothing needed in 733+ to resolve any problems or to help implement the good things you want to promote. What I want to press for, is that we should not have separate mail servers for "news" and "mail" and that we should not have separate User Agents for handling "news" and "mail." As for systems where administrators only allow one login per user, I feel sorry for anyone who is subjected to such dumb administrative behavior. Clearly such rules are arbitrary and not technically required, and therefore, I hope we will not try to remedy such bad adiministration with glitches in 733+. Best - Stef  Date: 27 Jul 1982 08:52:59-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: Stef.uci at UDel-Relay cc: header-people at Mit-Ai Subject: Re: separate systems for news and mail In-reply-to: Your message of 27 Jul 1982 0628-PDT (Tuesday). The REAL problem mentioned in the USENET comments is the need for a SYSTEM ADMINISTRATOR to create mailboxes. If there were some way for a person who is authorized to have an net mailbox to create additional mailboxes, the administrator wouldn't have to get involved. (I understand the serious implications of this for a student timesharing system, but since I don't have to deal with that anymore, I can choose to ignore it.) -Mike  Date: 27 Jul 1982 1024-PDT From: Jon Solomon Subject: Re: mailing lists To: smb.unc at UDEL-RELAY cc: header-people at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 26-Jul-82 1514-PDT People have been known to have 2 or 3 mailboxes, one for All junk mail, one for all private mail, and one for all random mail (i.e. beyond control of the person involved). For example, JSOL@USC-ECLC *could* be a random mail repository, JSOL-JUNK@USC-ECLC could be my mailing list repository (except for those "important messages" which deserve higher status than JUNK, heh heh); and JON.SOLOMON@USC-ECLC could be my private mailbox. These names were arbitrary; and in fact do not exist, but they illustrate the point Stef was saying. I feel that it is probably again something reasonable to allow mailers to mail to arbitrary files (given certain conditions, like either the file is write enabled to the world, or is in a magic file maintained by the administrator for security reasons), but at the same time, voluntary classification of mail is another reasonable way to do the same thing. I don't think everyone would voluntarily classify junk mail as junk. Cheers, --JSol -------  Date: 27 Jul 82 22:57:03 EDT (Tue) From: Steve Bellovin Subject: Re: mailing lists To: Gail Zacharias , Jon Solomon Cc: cbosgd!mark at Ucb-C70, header-people at Mit-Mc Via: UNC; 27 Jul 82 23:05-EDT I think you're missing the point Mark and I are making. It's not that a mail-reader can't be used to read 'news' items; of course it can. In fact, I much prefer the interface my mail reader has to the one provided by 'netnews', and often use it to read news articles. The point is that there are inherent conceptual differences between mail to you as a person, and mail to you as a member of a large anonymous group. A good analogy is the difference between making a phone call (even a conference call), vs. making a radio broadcast. (Most participants in this discussion do seem to feel that there is such a distinction; almost every reply has gone to a specific individual as well as to the group. Why does everyone (including me) do this, considering that it generally means that the lucky person mentioned by name gets to see it twice?) Mark and I are asking for two things: a method of labelling broadcasts as such, and a method of distinguishing one station from another. (Most of the flaming about the lack of 'To' and 'Subject' fields really boiled down to this issue: letters were ending up in your mailbox, and you didn't know why.) I don't regard multiple mailboxes as a general solution, either. TO be sure, it's not hard to design a mailer that lets each user create an indefinite number of mailboxes. But that forces each user to know how to do that. A header line would allow the mail system to handle it. It also allows specialized administrative treatment of news items -- storing only one copy (a much different proposition than *receiving* only one copy), deletion after a few weeks (which you can't do to personal mail -- and given that we receive over 150 Usenent items a day, we can't let them build up indefinitely), etc.  Date: 27 Jul 1982 2100-PDT From: Jon Solomon Subject: Re: mailing lists To: Header-People at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 27-Jul-82 2257-PDT Most participants in this discussion do seem to feel that there is such a distinction; almost every reply has gone to a specific individual as well as to the group. Why does everyone (including me) do this, considering that it generally means that the lucky person mentioned by name gets to see it twice? I don't know about everybody, but I do this out of laziness, since my mailer defaults to REPLY-TO-ALL mode. ALL means you and of course the list since my mailer on ECLC can't figure out that you on UCB-C70 are on a mailing list on MIT-MC. SMTP is *supposed* to deal with this by allowing us to expand mailing lists and resolve duplicates, but its effectiveness remains to be seen (my opinion). There, just to demonstrate that I *can* be less lazy about replies this one is going just to the list. I am assuming that all the recipients are on the list (in the real world this is probably a bad assumption). Back to RTFC733', If we say that some header line will contain the address which the mail was sent to, that will only help you figure out a message whose meaning is lost in the multitudes IF the message was sent to a mailing list. If the message was sent directly to you using no list, yet you still can't figure out why you got it, and posting this information won't be of help. Let's say we require a SUBJECT: line, and perhaps a TO line. Note that the TO line will not help you if you are on the CC list, even the majority of mail systems which do give you the CC field don't give you the BCC field which can also get you upset. Which leads back to the original question; What sort of information should be required in a mail message? I claim that none of the schemes we have yet to come up with solve the WHOLE picture, or answer the question "Why did I get this" all of the time. Sooner or later you are going to have to either ignore the random trash or ask the person who sent it to you what it was for. I am willing to bet that if enough people sent "why did I get this" messages back to the originator of an obviously vague message that the person will be more specific about his problems the next time he asks! Cheers! --JSol -------  Date: 27-Jul-82 23:37:36-EDT (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: news vs mail Via: cbosgd.uucp (V3.94 [3/6/82]); 27-Jul-82 23:37:38-EDT (Tue) To: header-people@mit-mc.arpa GZ hits the nail on the head - while there will always be a need for mailing lists (small groups of people that all know one another) the mass-mailings of the human-nets/tcp genre all have the property that nobody has any idea who is on the list, because the lists are so huge. I also never called them "junk" - my experience is that there IS a lot of junk out there, but any given person considers about 50% (give or take some percentage) of the lists to be "junk" and the other 50% to be "work related", and every person draws the line differently. The point is that you treat a newletter from the auto club differently than a letter from your sister - personal mail is almost always of high enough priority to be checked for every (say) 10 minutes, but you don't want to read mass mail more often than (say) once a day. The creation of multiple mailboxes per person is also not a simple technical issue - you have to deal with permissions, forgeries, accounting, and the time drain on the administrator to create them. I also admire your claim that you have mail software that will sort your mail into discussion order - I have never seen such a mail system, nor an algorithm for determining what to sort by, and don't believe that such a system will be widely available on the average machine in the near future, UNLESS we standardize the headers enough to be able to reliably determine what's going on! THIS is the whole point. In USENET, we deliberately use RFC 733 headers in the hope of using mail tools on news. (I firmly believe that one tool should eventually be able to handle both, at least for a user interface. But not without extending the mail system!) However, it has become necessary to use some headers that are not in RFC 733. If arpanet mass mailing lists could be persuaded to use these (or functionally equivalent) headers, we could get somewhere. USENET messages have an Article-I.D.: header (Message-ID: could be used just as well). This string is SHORT and consists of a unique string that identifies the message. (USENET currently uses host.num, e.g. cbosgd.123 for the 123'ed message generated on site cbosgd.) It is a legal file name on UNIX systems, and that property has proved valuable. While I can't see preserving this property across ITS and VMS and TOPS 10 file systems, I feel that Message-ID should be made (1) mandatory for mass mailings, and (2) short - say limited to 32 printing characters. This makes it a manageable key for a person to ask for a message by ID. (The USENET article ID is essential to prevent loops from infinitely propagating articles - we long ago found out that sites go down, so we have at least two paths to each major node, and send news along all paths. Arpanet mailing lists seem to be tree structured, and if one site goes down, too bad.) Newsgroups: makes it possible to unambiguously determine (1) that it's a "mass mailing" (news) message, and (2) which newsgroup it belongs to. We have a standard list on USENET, or a standard ARPANET spelling could be agreed on. But having to pick through the TO list and recognize somebody's local alias for human-nets is beyond the capabilities of any mail system I've seen. Sample USENET newsgroup names are net.unix-wizards (the list is properly gatewayed into USENET at SRI), btl.general (general items only distributed to Bell Labs), and fa.human-nets (plain old mailing lists are fed into read-only fa "from arpa" newsgroups). References: lists the Article-ID of the item being replied to. Without this, there is no way to sort by discussion. (In-reply-to is not the same thing, both because there is no fixed format, and because if A replies to B's reply to C, A's References line should reference C's note, not B's.) Sorting by Subject won't do it, because people retype their own subjects all the time. The mail software should ENCOURAGE people to use built-in reply/followup commands, rather than compose a message from scratch. So, to boil this down, in order to properly support mass mailings, I propose addition of Newgroups, References, and either Article-ID or Message-ID, headers to all mass mailings. Mark  Date: 28 July 1982 0345-EDT From: Rudy.Nedved at CMU-10A To: Header-People at MIT-MC Subject: mucho mail and distribution Message-Id: <28Jul82 034509 EN0C@CMU-10A> The comment about loops and duplicates hit a nerve. Some important events to remeber: There was a "chain letter" a while back on the "network" which propagated thru the ARPANET, around UUCP (I heard rumors about it), up thru the tangled world of DEC coporate DECNet and local MIT, Standford, Berkley and CMU networks. It took up a large amount of "resources" in terms of cpu time, disk space and ftp resources. An extension of the above indicident was someone created a mailing list at MIT with all of CMU-10A's users and sent the "letter" to it....luckily a local mail wizard shot it down but not before it had cdr down half the list. CMU recently fixed a design flaw in one system and found another system punted the mail transfer after the mail was sent but before the mail was dequeued.....the failure is message length and system load dependent so a noticeable increase in duplicates occured during the day. There was the incident of the SU-ISL mailer cutting loose and spraying several mailing lists with mail from "greep@RAND...". I would like to see some mechanism by which a "fair share" of the mail relaying and acceptance gets done for each host (assuming the future has one host per person), a way of reducing duplicates (maybe an out-of-band message-id) at the end-site and a way of detecting mail system loops (yes, I know I can always look at my "/usr full, pausing" unix messages or my "quota or disk space exceeded" tops-10 messages). I think the "." id is good but not solid (host names have dots and maybe numbers). Given that SMTP and MTP currently support the "HELO" host identification, the host name business is redudant but where does one place the out-of-band message number? How many times does the number get incremented before an upper bound is exceeded -- maybe it should be a timestamp instead? Maybe the should only be in the envelope, maybe in both and maybe only in the out-of-band information? I must admit my experience with "news" and "bboard" systems is not as extensive as the uucp people. My apology for the length of the message. -Rudy  Date: 28 Jul 82 0:29:50-PST (Wed) From: Stef.uci at UDel-Relay To: header-people at Mit-Mc Subject: Re: separate systems for news and mail Via: UCI; 28 Jul 82 5:00-EDT Again, the fact that inadequate systems designs force administrators to manually create mailboxes, with all the bureaucratic drag that this entails, does not justify separate systems for news and mail. There is no way I can imagine that we can protect the world from bad administration, no matter how good or bad our systems. So lets not allow such considerations to warp our mail service designs. BTW, I am really a mangement consultant, not a hacker. Cheers - Stef  Date: 28 Jul 1982 0937-PDT From: Jon Solomon Subject: Re: separate systems for news and mail To: Header-PEOPLE at MIT-MC Address: 2817 Orchard Ave., Los Angeles, CA. 90007 Phone: (213) 732-3423 In-Reply-To: Your message of 28-Jul-82 0129-PDT What I would like to see is a design for a foolproof way for mail processing to insure that you don't need to ask "Why did I get this message" or worse "Why did I get this message TWICE (or three times or ...)". As long as my mail reader can filter out the Message-ID field, I don't mind using that as a starting point. Message-ID: Asciz-string.number is fine but number.asciz-string is better since most mail systems will be more interested in the number; and if the asciz-string is mapped to a host name, it too may contain a dot. So far nobody has really come up with this. RFC733 does state that you (Mark) can put anything you wish in the headers, as long as it is one-word: line-of-text (you can of course continue it). My point is, if we are going to suggest a \mandatory/ header for mail, it should address the real questions, rather than some subset of them. It's not all that clear that Message-ID will help in all cases, but it might be a start. Cheers, --JSol -------  Date: 28-Jul-82 12:39:29-EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: message ids Via: cbosgd.uucp (V3.94 [3/6/82]); 28-Jul-82 12:39:31-EDT (Wed) To: header-people@mit-mc.arpa The important thing about a message ID is that is must be unique across the world. To avoid having to get a unique number from one central server (remember, in the phone dialup world, this may be impossible, and at best will take at least a minute of real time to place a phone call) USENET includes the host name - then the rest only has to be unique for that host. There is no upper bound on the number in ., and in practice our numbers don't grow so fast as to be a problem (we're up to 2466 after one year on cbosgd), although that's just news, not mail. I could see 5 or 6 digits if mail was included for a heavily used system, and there's no reason a host couldn't reset its number every year. The problem with a timestamp is that it's long and hard to type, and has lots of special characters in it. There is no ambiguity with ., since even if the host has dots and numbers in its name, you just scan from the right for a dot. However, this scheme was chosen for convenience, not for universal suitability, and some other scheme could just as easily be used. What really matters is that it be a short, unique string. I think what Rudy Nedved is suggesting is that it may be worthwhile to make message-ID's mandatory for all mail. I have to admit that it would make catching runaway mail programs a bunch easier. Mark  Date: 28 Jul 82 12:34:52 EDT (Wed) From: Steve Bellovin Subject: YAHF (yet another header field)? To: header-people at unc Via: UNC; 28 Jul 82 19:34-EDT Here's a thought tangentially related to the mail-list discussion. At some point, some day, some folks may be asked to pay (shudder) real money for their mail traffic. In point of fact, CSnet is already planning for it. Who should pay for TCP-IP Digest? SF-LOVERS? A site may be willing to donate disk space, cycles, and net bandwidth, but draw the line at dollars. It would seem that another distinction between personal mail and list-mail is that the latter is sent primarily for the benefit of the recipient; the former tends to benefit the sender. We may need collect letters! To be sure, that issue fits in the SMTP protocol. But SMTP needs to get the information from someplace else -- the header. (I see this extending beyond mailing lists, of course. If someone asks me for the source of some program of mine, I'll be much more likely to send it if my site doesn't have to foot the bill.) I don't have a good syntax on tap; the best I can come up with is Postage: #address | "collect" | "sender" But that requires reserved words in a position syntactically reserved for addresses. Comments?  Date: 28 Jul 1982 21:03:43-PDT From: lblg!j#j at LBL-UNIX Subject: Extra header fields for a variety of uses To: smb.unc at udel-relay, header-people at mit-mc Steve, I think that it is very important that any information that might affect delivery, accounting, ... must be transmitted out-of-band from the text of the message, which includes the message header. One of the things that should be possible in any mail system is that the sender and receiver be able to end-to-end encrypt the message, if an extra level of security is desired. If the header cannot be encrypted due to its importance in routing and delivery, then this option is not available. Unfortunately, some of the information in the header may be sensitive, as was pointed out in one of the early notes in this discussion by one of the individuals at PARC-MAXC. This naturally leads into the discussion of mail delivery systems which choose to mung message headers to facilitate replies to all recipients of a message. I believe quite strongly that NO modifications to the headers should occur, and that all necessary information needed to facilitate higher level functions must be carried in the envelope information accompanying the message. This is not dissimilar from the options fields which are required to precede the message in the NBS standard, where the message (including the header lines) is considered free text, and may be encrypted, include binary data and be affected by a variety of value-added features. Without a fairly wholesale overhaul, SMTP and RFC733+ do not have sufficient horsepower built in to be able to handle many of these concerns. I have not seen the multi-media RFC by Jon Postel to know whether it will handle all of these necessary features for mail systems in the 80's. My understanding of the NBS proposals is that many of the more difficult problems are approached, especially non-textual data, data security via encryption options, accounting considerations, etc. This is not necessarily a plug for those proposals; I am simply saying that others have considered these problems in a different environment, and that many of these considerations may best be left until we tackle the multi-media problems, since that extension will wreak so much havoc that fixing a few more of the current problems will be easier at that time. As a final plug for the abolition of header-munging delivery software, might I suggest the following solution for the reply-to-all-recipients problem. SMTP requires that the "Return-Path:" field from the message envelope be placed in the message when delivered to a recipient. Since all addresses formatted into the message header were relative to the sender, it seems totally reasonable to send replies along the route specified in the return-path to the senders machine, which will then know how to get the message to the address specified in the original message header. Although this is not necessarily optimal (more on that below), it is certainly a workable solution 90% of the time, with the failures occurring if the connectivity of the net is not constant. Playing the devil's advocate, let's assume that the forwarding delivery software modifies the headers of each message that it handles. Unless the software includes a lot more AI than any that I have seen, the typical modifications will be to simply add it's host name to the end of the domain name as follows user@host.domain ==> user@host.domain.routing_host_name By so doing (which is equivalent to adding it's host name to the beginning of the return-path), it is assuming that the domain1.domain2...domainN structure is a right-to-left route (which is not an interpretation which is favored by many of the participants in the SMTP discussions), and gives no more information than the scheme I suggested above, since any reply will follow the reverse path of the original message. As a final comment in this long-winded diatribe, I would like to suggest an addition to the SMTP spec which would permit the addition of value added fields which could accompany the message in the "envelope". Why not add an ENVL command, which has the same control syntax as the DATA command (i.e. must be terminated by a . and must employ the period stuffing protocol at the beginning of lines for transparency). All additional "header" lines which could impact delivery, accounting, ... could be stored here, as well as the "Mail-From:" or "Received" timestamps required by SMTP and RFC733+, respectively. Then the delivery system which actually delivers the message to the user's mailbox can exercise control over display and placement of this additional information in the message header. Some systems may wish to make the information available as associated data with the message, not necessarily including it in the message itself. 'Nuff said. Joe Sventek  Date: 29 July 1982 10:55 edt From: Charles Hornig at MIT-MULTICS Subject: Re: quoting and non 1 case alpha names Sender: Hornig.Multics at MIT-MULTICS To: header-people at MIT-MC In-Reply-To: Message of 18 July 1982 22:13 edt from Barry Margolin A more interesting example of conflicting usernames would be that of "TSong" and "Tsong".  Date: 29 Jul 1982 1629-PDT From: Stef Subject: Re: quoting and non 1 case alpha names To: Header-People at MIT-MC I boil down the top level issues of case folding for mail box names to the following: If you want to receive mail in the current environment, where in fact some systems make it entirely impossible to either display multicase addresses in multicase , or to type MultiCase from the keyboard , then ... You should arrange for your mail delivery service to fold case to unicase for your incoming mail. If, on the other hand you don't want to receive mail from such handicapped senders, and if you don't mind failure to get mail from senders who are careless, or otherwise fail to send the address in precisely the correct case, then ... You should arrange for tricky casing requirements. As I see it, it is up to the receivers to decide these things for themselves. If your system administrators, or your system's implementation will not let you have these choices, then you should seek a new site on which to establish your mailbox. If you cannot change sites, then you better learn to live with what you have, or lead a revolution. For myself, I have a great deal of difficulty understanding why anyone would want to have a tricky case requirement on their address. My objective to to comunicate via mail. Any impediments to communication are regarded thus to be candidates for removal. I had a Multics mailbox once, and I demanded that it be set to fold case, or at least behave as though it folded case. Had this not been arranged, I would have simply not used it, ever. But, to each his own. I have no objections to some people being silly. As I have said before: "Can Implies Shall" is the Triumph of Technology. I would prefer to think that I am master of my mail domain. Best - Stef -------  Date: 29 Jul 82 20:24:01-PST (Thu) From: Stef.uci at UDel-Relay To: header-people at Mit-Mc Subject: Re: message ids Via: UCI; 30 Jul 82 1:55-EDT If it is genuine unicity that you want, with no troublesme characters, then how about a ... Or some concatenation like that which is a unique but simple number, followed by site based text and originator text. I would suggest that the date-time basis be Greenwich Mean Time, and organized so it will sort correctly by time with no transformations. It should carry lower order time digits to the degree needed to assure unicity for each given originator of mail. This suggests that a standard algorithm be established . This could avoid all problems with unpleasant characters by not allowing them in the standard. Such a well defined string would also prove useful for other purposes, though these should not be a factor in deciding on such a scheme. It should certainly make for easy identification of duplicates, etc. In any case, I see no reason for the ID field standard to allow unpleasnt characters, or complex construction rules, or nebulous meaning. Best - Stef  Date: 29-Jul-82 16:28:41-EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: news vs mail Via: cbosgd.uucp (V3.94 [3/6/82]); 29-Jul-82 16:28:43-EDT (Thu) To: header-people@mit-mc.arpa Nobody is saying that there aren't lots of similarities between news and mail. But they are different, by definition. A newsgroup is distinguished from a mailing list by appointment: mailing list x has gotten to the point where it costs too much to distribute it as a mailing list, so we make it a newsgroup. The ARPANET has been spoiled for a long time by having free, high bandwidth links between the hosts. This is wonderful, but it's only available to a select group of DOD contractors. Those of us that have to use 1200 baud (or even [gasp] 300 baud) dialup links to exchange mail and news have to look at the costs. The whole point of the new mail standard is to be universal, not only applying to the arpanet and local ethernets, but also to nets they talk to, such as CSNET and UUCP (both of which depend heavily on dialups.) The fact is that distributing high volume mass mailings costs a lot. Every copy that is sent out takes CPU cycles. Every copy that is stored on disk takes up space on a drive that is probably already nearly full. (If you have lots of empty disks, you are very lucky!) Every phone call that is placed costs money for long distance. USENET has a higher volume of news than the ARPANET mass mailing lists. (17 of the arpa lists - mostly the big highly visible ones - are fed into USENET newsgroups, and there are 87 USENET groups that do not go onto the ARPA mailing lists.) I don't have any figures on the total ARPANET volume, but July 27's USENET traffic on cbosgd (a slow day) had 135 items, taking 22.4 minutes to transmit at 1200 baud, amounting to about 145K characters. This total is manageable but still puts a pretty good drain on the system. The real drain is in the number of sites a given site sends news to. A leaf node gets news from one site: 22 minutes of time. A more central site may feed 5 other sites, for a total of 110 minutes. We notice a big difference - leaf sites don't feel much, if any, drain on the CPU, but central sites do. On the ARPANET, on the other hand, you have ONE central site that sends news (as mail) to EVERY SITE. (This assumes only one copy gets sent to each site - an optimistic assumption.) There are probably 100 sites represented on a typical mailing list. Result? Nobody wants an arpanet mailing list on THEIR site - people have to make special deals and promises to only send stuff at night, and even then it's a scramble to find a host. Only a few hosts are willing, and MIT-MC must spend a significant fraction of their cycles sending out mail. The situation is already getting bad, and this is with no phone bills and high speed links. When you consider that the ARPANET is growing (especially if you count the hosts on the internet) and the cost per host grows linearly with the number of hosts on the ARPANET, and the number of lists is also growing, it will eventually use up all the bandwidth on the ARPANET. (I bet already a significant chunk is used.) When you extrapolate that to dialup nets, it would be way past the breaking point. And what do you get for all this extra cost? Your typical ARPANET user who gets one of these mailing lists just has it merged in with his personal mail, and gets interrupted throughout the day by what is often "junk mail". (If you're reading this, you're in the elite group of people who MIGHT know how to get a separate mailbox. But I'll bet that at least half the people on this list have only one mailbox into which everything is fed.) You get a system where if one arpanet host goes down, or forbids a mailing list, the whole mailing list grinds to a halt. You probably have discussions interwoven with each other. And, every time you send mail to a big list, you get back 3 or 4 copies of it from various sites with error messages like "No such user as RANDOM@RHOST" or "GTJFN: operating system error". Certainly news can use a lot of existing mail technology! Many of the tools and formats are perfect for news. But mail can gain something from news technology, too. Checks to ensure that only one copy of an article is delivered, preventing 99 copies of the same message from being sent out, and allowing multiple paths for higher reliability. Smaller fan-out (each major site feeds 3 or 4 neighbors, which feed a few local sites), resulting in lower load on the machines. A better user interface (I said before what's wrong with mailing lists as a user interface, so I won't belabor that point). A central notion of what newsgroups exist (rather than word of mouth and one person who is kind enough to keep an unofficial list of the ones he's heard of.) If mail is such a wonderful user interface, how come so many sites on the ARPANET have bboards? USENET is really nothing more than a large, distributed, subscription bboard. (By subscription, I mean that each site can choose which newsgroups are forwarded to it, in case they can't handle the full load; also, this allows local and regional newsgroups.) So what am I saying the header standard should have? Basically this: (a) A mandatory Message-ID on every message, to prevent loops. The format should be part of the standard, and it should be short and unique across the internet. (b) A References field, mandatory (or at least strongly encouraged) on all replies. (That is, the reply command should generate this.) If the message being replied to has a References field, the reply should have the same References field (possibly followed by the message ID of the message being replied to), otherwise, a References field is generated with the Message-ID of the original message. This is to allow a mail user interface to sort a mailbox into a meaningful order. (c) A Newsgroups line on all mass mailings, inserted at the site where the mailing list originates. This makes it clear (even to a program that is trying to sort the input) why that mail was received. (A line such as To: cbosg!cbosgd!pit is perfectly legal right now, and doesn't provide any clue that the name is an alias for "post to info-terms", even to a human. A more likely form is: To: ihnss!ucbvax!c70:info-terms@Berkeley which could be figured out by a human, but not by very many programs.) Note that a message can be in more than one newsgroup. This cuts down on transmission overhead and on people having to read it twice. A typical user interface, being invoked on (say) a mailbox (or a read only mailbox, if only one copy is kept per system) might want to sort: (1) by Newsgroups (to get the main topic), then (2) by References (to get the sub-discussion), then (3) by Date (to get things in cronological order). I also encourage sites to increase the fanout of mailing lists (at least to the extent that current sites permit forwarding of mail), to try to send only one copy to each site (and develop whatever local tools they feel are necessary to have read only mailboxes) and to put in some loops for redundancy. And some thought needs to be put into creation of a new group (on USENET, one site administrator creates the group and immediately all sites get everything in the group). But this isn't a header-people issue. Sorry for the length of this. Mark  Date: 31 Jul 1982 (Saturday) 1331-EDT From: HAGAN at Wharton-10 (John Hagan) Subject: Question about the JSOL algorithm To: header-people at MIT-MC Is: John D. Hagan @Wharton John D. Hagan @Wharton John D.Hagan @Wharton All the same? I think they should be since the canonical representation is: John D.Hagan@Wharton If not, or yes for another reason, please explain the parsing algorithm as it applies to these three cases. --Kid.  Date: 27 Jul 1982 2155-PDT From: Stef Subject: Re: mailing lists To: header-people at MIT-MC I believe that we are converging on the idea that whatever mail transfer system we might employ for moving mail from senders to addressees, there is a class of mail items which should be handled differently by their recipients because they are actually newsletters, or "group" mail which can and should be processed differently in terms of posting to BBoards, and archived in publicly accessible tertiary files, et al. I claim that this need for separation can be achieved by mailing these "news" items to addresses where they will be received by processes that do things differently. The separator in this case is a distinctly different address from personal mail for other folks, though the "news" mailbox need not look different to an outsider, though making its name suggestive might be a nice gesture. I see no problem with installing a relay net that spreads the delivery load among a "tree" of cascaded sites. Indeed, we have installed exactly this arrangement at UCI, with all group lists aliased to a local list, and with a copy posted on a public BBoard for each group. Our local BBoard UA has been created out of a regular mail handler by adding a BB command that knows how to find the named group's BBoard file. It also only allows users to have read access, unless they are on a list of authorized "BBMasters." So, within the single system we have now, we are doing what is suggested, without asking permission, or needing any change to any mail standards. However, it would have been much easier to implement if the DELIVER program had copied the envelope's TO address to some (locally named) field for our local BBRCV program to find, since we want to divert all such group mail to a single process when it arrives. At this point, I want to establish that it is OK for the MSA to hand over some envelope information at deliver time. I don't think this requires any change to 733+. UNLESS, we are going to set a standard name, syntax, and semantics for the field that is created at deliver time to hold the TO information, in which case we might want to require that the sender correctly place this field in the header. The more I think about all this, I would be happy to just make sure I can get it from DELIVER. As I understand MMDF and its RCVMAIL hook, it now allows me to capture and record what I want as I want it. Other systems should consider enabling such a mechanism. So, maybe all is well as things are now? Stef -------  Date: 31 Jul 82 21:01:13 EDT (Sat) From: Steve Bellovin Subject: Re: mailing lists To: Stef , header-people at Mit-Mc In-Reply-To: Stef 's message of 27 Jul 1982 2155-PDT Via: UNC; 31 Jul 82 22:24-EDT I *almost* agree with Stef -- but I think that the newsgroup name should be inserted in the header to aid in situations where a private group sets up their own distribution list. The issues are the same, the need for separation is the same -- but they may not have access to the system lists. It also aids individuals at sites without centralized bulletin boards for mailing lists; indeed, it's my impression that very few of the mass-mailing lists' recipients are really programs. Even a dumb mailer can pick out articles with some unique header.  Date: 31 Jul 1982 2350-PDT Sender: ESTEFFERUD at USC-ECL Subject: Re: mailing lists From: ESTEFFERUD at USC-ECL To: header-people at MIT-MC Message-ID: <[USC-ECL]31-Jul-82 23:50:17.ESTEFFERUD> In-Reply-To: smb.unc's message of 31 Jul 82 21:01:13 EDT (Sat) I will agree with the idea that group lists should insert a self identifier, but I also think there is a deeper issue in here that needs attention. This has to do with where list expansion takes place. We have slipped into the habit of expanding lists in the delivery system, rather than in User Agents outside the delivery system. There is a real issue as to whether this is a correct implementation. I fear that we are now coming to a point where this must be decided. When expansion occurs inside the delivery system (inside MMDF or XMAILR for example) it seems to be very hard to assign responsibility for failures of addresses inserted in the expansion process. The needed mechanisms for repsonsibility management are simply not there! And, it requires system wizard privileges to set up aliases because of the sanctity of the mail, et al. We do not seem to have any way to attach information about where failure notices at later stages of delivery should be returned, without munging the internal header (Read Internal Letter Head). And, we all feel some revulsion about such munging of mail, especially private mail. But, if expansion is done in a UA outside the delivery system, then it is not violating anything to insert information about responsibility to accept notices and deal with failures of addresses it inserts "by expansion." For example, I have plans to modify the "relay" procedures for MsgGroup (assuming it has any life remaining in its old bones) to actually take possession of each relayed item, and resubmit it, as having SENDER be MsgGroup-request, and to have REPLY-TO be msgGroup, so that failures will go to MsgGroup-Request and recipients who reply will find their replies addressed to MsgGroup. I need to think about this some more before doing it to be it will achieve what I want. I also plan to let local hosts set up local distribution, as has been done at RAND-MSGGROUP@RAND-UNIX, UCI-MSGGROUP.UCI@UDEL-RELAY, and others. This is the beginning of a newsnet distribution system. I can agree that a general system of this nature would be a good idea for lots of lists, if not all of them. My only real concern then is that we use the regular mail delivery system to effect the results. At this point, I lean toward the idea of such a newsnet, using User Agents that are outside the mail system, to do the relaying, by taking possession of the news items at each expansion point, and deliberately placing relevant information into the header to leave a visible and machine processable trace for later recognition by recipients. If such a newsnet, riding on top of 733+ netmail, needs standards, then I expect that they belong in a newsnet standard, and that they are outside the purview of 733+. Well, this is all the time I will have for this discussion for the next week or so. See you then - Stef