Date: 3 AUG 1977 0916-PDT From: POSTEL at USC-ISIB Subject: "certified mail" To: Header-People at MIT-MC cc: postel oops rfc 644, was written in 1974 (not this year). Also it unfortunately is not in the online collection of the NIC. --jon. -------  Date: 7 AUG 1977 2124-EDT From: MOON at MIT-MC (David A. Moon) Subject: I hate to do this to all of you, but the mail must go through.... To: HEADER-PEOPLE at MIT-MC (Bob, it's a hyphen not an underscore.) -- From: Frankston at MIT-Multics (Robert M. Frankston) Date: 2 August 1977 0624-edt Subject: what, message-id again, oh no! but yes, here we go... Message-ID: [MIT-Multics]1.2.BBBJGjDhXDxZqM To: mrc at SU-AI cc: header_people at MIT-MC In reply to the following: << Mail from Network host SU-AI (Network_Server.CNet) 08/02/77 0516.7 edt Tue >> Date: 2 Aug 1977 0211-PDT From: MRC at SU-AI (Mark Crispin) Subject: mail header cruft To: Frankston at MIT-MULTICS Please explain to me how [MIT-Multics].1.2.BBJGjDNmklMXN helps me in reading my mail. And my point still is that it is objectionable to get a 10 line mail header for a 2-line message text. ------- 1. There is no need for me to explain it -- simply that a number of people find it useful in constructing message systems so that you as a member of the community of message system programmers provide it as a courTesy to those who in their mysterious wys find it useful. Please excuse my tone, but I have explained this many times and will do so below. The point is, however, that anyone system may not use all the features. 2. One simple use of message-id is to screen out multiple path messages. I often have a few coies of the same letter in mailbox and need to screen it. Multics is shutting down now -- gotta logoff.  Date: 9 AUG 1977 1453-PDT From: POSTEL at USC-ISIB Subject: RFC 724 Status To: Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX, To: Henderson at BBNA cc: Header-People at MIT-MC, Postel The preface of rfc 724 indicates that comments are to be incorporated and somehow agreed to by 1 september 77. Thus i expect that a revised document is in the works someplace. I have had some recent inquires about the wisdom of implemeting something based of rfc 724. To these inquiries i have said "wait - it is not agreed to yet, there should be a revision comming". If my model of the state of rfc 724, and of mail format standard is wrong please let me know. --jon. -------  Date: 9 Aug 1977 at 1657-PDT Subject: Re: RFC 724 Status From: Dcrocker at Rand-Unix To: POSTEL at Usc-Isib cc: Pogran at Mit-Multics, Vittal at Bbn, Dcrocker at Rand-Unix, cc: Henderson at Bbna, Header-People at Mit-Mc, Postel at Usc-Isib Message-ID: <[Rand-Unix] 9-Aug-77 16:57:03.Dcrocker> In-Reply-To: Your Message of 9 AUG 1977 1453-PDT Jon -- To date we have received only a few comments. All are extremely minor, except for the multi-net specification problem and 724's deviation from NBS date/time form. Therefore, our plan is to put a small bit of work in soon, meet in the middle of September to have a face-to-face blessing ceremony and then to issue the spec as a "standard", publishing through assorted mechanisms. Along with publishing the spec, we will describe an adoption sequence and, I suspect, a plan for monitoring adoption of the spec by systems, primarily so that we can keep track of when sites can expect to generate (rather than simply accept) 724-text. Also, I expect we will issue a document describing the relationship between existing system's conventions and those in 724, so that people will have an idea of how much disparity actually exists and how difficult the changeover should be. Is this what you had in mind? With reference to beginning implementation before the final spec is released, I predict that the spec will differ from 724 only trivially. Dave.  Date: 9 Aug 1977 1741-PDT From: MRC at SU-AI (Mark Crispin) Subject: RFC 724 To: DCrocker at USC-ISI, Postel at USC-ISI CC: Header-People at MIT-MC I appreciate the attitude that all the objections that people have made to the proposed standards and all the garbage in mail headers is to be so casally dismissed as "minor". At SU-AI, work has begun on a mailer which will generate 100 line message headers for all mail, including such useful information as saying who the sender is 10 times, the last and next five high and low tides in San Francisco bay, the phase of the moon, the local weather, SAIL's uptime in nanoseconds, the latitude and longitude, etc... -------  Date: 9 Aug 1977 1857-PDT Sender: GEOFF at SRI-KA Subject: Re: RFC 724 From: GEOFF at SRI-KA To: Mrc at SAIL Cc: DCrocker at USC-ISI, Postel at USC-ISI, Cc: Header-People at MIT-MC Message-ID: <[SRI-KA] 9-Aug-77 18:57:45.GEOFF> In-Reply-To: Your message of August 9, 1977 Don't forget to include the amount of money spent in the Stanford AI lab PONY vending machine for the current month in the header too. Really, I think dismissing all of the cmments recieved as 'minor' was pretty blecherious too. I myself would certinaly want to see any document spread around the network before it became any type of standard that everyone has to follow. -------  Date: 9 Aug 1977 2111-EDT From: Brian Reid at CMU-10A Subject: Missing feature from ARPAnet mail To: Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 9 Aug 1977 21:11:12 Brian Reid In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin I just thought of something else that netmail should have. We need an option, like the Post Office has, whereby you can request that obscene mail from certain senders not be delivered. -------  Date: 10 AUG 1977 1146-PDT From: POSTEL at USC-ISIB Subject: Re: Missing feature from ARPAnet mail To: BrianReid at CMU-10A, Header-People at MIT-MC, To: DCrocker at USC-ISI, Postel at USC-ISI cc: POSTEL In response to the message sent 9 Aug 1977 2111-EDT from Brian Reid at CMU-10A Brian: it seems that it should be easy to add such a filter to your mail receiving program. Give a list of senders that you dont want stuff from and have your receiver file messages from senders on the list in the bit bucket instead of your mailbox. --jon. -------  Date: 10 Aug 1977 2135-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC Date: 9 Aug 1977 2111-EDT From: Brian Reid at CMU-10A Subject: Missing feature from ARPAnet mail To: Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 9 Aug 1977 21:11:12 Brian Reid In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin I just thought of something else that netmail should have. We need an option, like the Post Office has, whereby you can request that obscene mail from certain senders not be delivered. ------- [Perhaps we need something else added to mail headers; the emotional maturity quotient of the sender. All I am doing is making a plea for simplicity AND more importantly, to keep things as they are. It seems that the people who like hairy mail headers tend to treat it as (1) a personal matter, and (2) the only right thing. My point has never been that the hairy mail header people's opinions are uninportant, however, it seems that the people who want hairy mail headers dismiss the opinions of those who want to leave things alone as "minor". No, wait, now the term is "obscene". Gee, how many things that term covers now!] -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 10 August 1977 1851-edt Subject: obscene mail Message-ID: [MIT-Multics]1.2.BBBJGjlDwDjNgd To: reid at CMU-10a, dcrocker at USC-ISI To: usc-isi at USC-ISI cc: header-people at MIT-MC Multics has such as facility, one can set the access control list for on'e's mailbox. But over the net, without certified mail ....... Perhaps the alternative is something similar to the federal legislation that (I think) says that you may somehow declare to the world that you do not want obscene mail and thus anyone who is so foolish to send you mail that you personally find offesive is breaking the law. Of course, this has the side effect of making much of the dialogue in header-people questionable.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 August 1977 0128-edt Subject: hairy headers Message-ID: [MIT-Multics]1.2.BBBJGjlmDDQgcc To: mrc at SU-AI cc: header-people at MIT-MC Mark, you have the hairiest headers in header-people. The complete contents of the letter you are replying to makes a moby subject field that is not even parsable as such.  Date: 9 AUG 1977 1453-PDT From: POSTEL at USC-ISIB Subject: RFC 724 Status To: Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX, To: Henderson at BBNA cc: Header-People at MIT-MC, Postel The preface of rfc 724 indicates that comments are to be incorporated and somehow agreed to by 1 september 77. Thus i expect that a revised document is in the works someplace. I have had some recent inquires about the wisdom of implemeting something based of rfc 724. To these inquiries i have said "wait - it is not agreed to yet, there should be a revision comming". If my model of the state of rfc 724, and of mail format standard is wrong please let me know. --jon. -------  Date: 9 Aug 1977 at 1657-PDT Subject: Re: RFC 724 Status From: Dcrocker at Rand-Unix To: POSTEL at Usc-Isib cc: Pogran at Mit-Multics, Vittal at Bbn, Dcrocker at Rand-Unix, cc: Henderson at Bbna, Header-People at Mit-Mc, Postel at Usc-Isib Message-ID: <[Rand-Unix] 9-Aug-77 16:57:03.Dcrocker> In-Reply-To: Your Message of 9 AUG 1977 1453-PDT Jon -- To date we have received only a few comments. All are extremely minor, except for the multi-net specification problem and 724's deviation from NBS date/time form. Therefore, our plan is to put a small bit of work in soon, meet in the middle of September to have a face-to-face blessing ceremony and then to issue the spec as a "standard", publishing through assorted mechanisms. Along with publishing the spec, we will describe an adoption sequence and, I suspect, a plan for monitoring adoption of the spec by systems, primarily so that we can keep track of when sites can expect to generate (rather than simply accept) 724-text. Also, I expect we will issue a document describing the relationship between existing system's conventions and those in 724, so that people will have an idea of how much disparity actually exists and how difficult the changeover should be. Is this what you had in mind? With reference to beginning implementation before the final spec is released, I predict that the spec will differ from 724 only trivially. Dave.  Date: 9 Aug 1977 1741-PDT From: MRC at SU-AI (Mark Crispin) Subject: RFC 724 To: DCrocker at USC-ISI, Postel at USC-ISI CC: Header-People at MIT-MC I appreciate the attitude that all the objections that people have made to the proposed standards and all the garbage in mail headers is to be so casally dismissed as "minor". At SU-AI, work has begun on a mailer which will generate 100 line message headers for all mail, including such useful information as saying who the sender is 10 times, the last and next five high and low tides in San Francisco bay, the phase of the moon, the local weather, SAIL's uptime in nanoseconds, the latitude and longitude, etc... -------  Date: 10 AUG 1977 1146-PDT From: POSTEL at USC-ISIB Subject: Re: Missing feature from ARPAnet mail To: BrianReid at CMU-10A, Header-People at MIT-MC, To: DCrocker at USC-ISI, Postel at USC-ISI cc: POSTEL In response to the message sent 9 Aug 1977 2111-EDT from Brian Reid at CMU-10A Brian: it seems that it should be easy to add such a filter to your mail receiving program. Give a list of senders that you dont want stuff from and have your receiver file messages from senders on the list in the bit bucket instead of your mailbox. --jon. -------  Date: 10 Aug 1977 2135-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC Date: 9 Aug 1977 2111-EDT From: Brian Reid at CMU-10A Subject: Missing feature from ARPAnet mail To: Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 9 Aug 1977 21:11:12 Brian Reid In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin I just thought of something else that netmail should have. We need an option, like the Post Office has, whereby you can request that obscene mail from certain senders not be delivered. ------- [Perhaps we need something else added to mail headers; the emotional maturity quotient of the sender. All I am doing is making a plea for simplicity AND more importantly, to keep things as they are. It seems that the people who like hairy mail headers tend to treat it as (1) a personal matter, and (2) the only right thing. My point has never been that the hairy mail header people's opinions are uninportant, however, it seems that the people who want hairy mail headers dismiss the opinions of those who want to leave things alone as "minor". No, wait, now the term is "obscene". Gee, how many things that term covers now!] -------  Date: 9 AUG 1977 1453-PDT From: POSTEL at USC-ISIB Subject: RFC 724 Status To: Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX, To: Henderson at BBNA cc: Header-People at MIT-MC, Postel The preface of rfc 724 indicates that comments are to be incorporated and somehow agreed to by 1 september 77. Thus i expect that a revised document is in the works someplace. I have had some recent inquires about the wisdom of implemeting something based of rfc 724. To these inquiries i have said "wait - it is not agreed to yet, there should be a revision comming". If my model of the state of rfc 724, and of mail format standard is wrong please let me know. --jon. -------  Date: 11 Aug 1977 1347-EDT Reply-To: Header-People at MIT-MC Subject: Re: Leaving things as they are To: MRC at SU-AI (Mark Crispin) CC: Header-People@MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Aug 1977 13:47:21 Philip Karlton In-Reply-To: MRC's message of August 10, 1977 The problem with leaving things as they is that different sites have different conventions concerning the format of items that programs are currently trying to parse. (If you want some examples, here are 2: One site puts no "," at the end of each line of an address list that is continued on the next line; some sites (programs) insist that embedded blanks in names should be thrown away and at least one site uses both first and last names (separated by a space) to disambiguate addresees for delivery.) RFC 724 is, at least as far as I understand it, an attempt to make a standard syntax and semantics for all the things that people are sticking into their mail headers already. I think that the authors have bent over backwards to allow almost all of the things that mail creating programs are currently doing. Why else would they choose to allow both the type of date given in the header of this message and "slash" dates which are ambiguous if a European is reading the letter? I do not know what it is specifically that you object to in RFC 724. If you had the authority would you just disallow all but a few items in the header? DO you not think a standard syntax and semantics for those items in headers likely to be parsed by programs is desirable? My apologies; I should not get facetious. I expect that your answers to these particular questions are the same as mine. Do you have some concrete suggestions for changes to RFC 724? Phil Karlton -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 August 1977 0128-edt Subject: hairy headers Message-ID: [MIT-Multics]1.2.BBBJGjlmDDQgcc To: mrc at SU-AI cc: header-people at MIT-MC Mark, you have the hairiest headers in header-people. The complete contents of the letter you are replying to makes a moby subject field that is not even parsable as such.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 10 August 1977 1851-edt Subject: obscene mail Message-ID: [MIT-Multics]1.2.BBBJGjlDwDjNgd To: reid at CMU-10a, dcrocker at USC-ISI To: usc-isi at USC-ISI cc: header-people at MIT-MC Multics has such as facility, one can set the access control list for on'e's mailbox. But over the net, without certified mail ....... Perhaps the alternative is something similar to the federal legislation that (I think) says that you may somehow declare to the world that you do not want obscene mail and thus anyone who is so foolish to send you mail that you personally find offesive is breaking the law. Of course, this has the side effect of making much of the dialogue in header-people questionable.  Date: 9 Aug 1977 2111-EDT From: Brian Reid at CMU-10A Subject: Missing feature from ARPAnet mail To: Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 9 Aug 1977 21:11:12 Brian Reid In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin I just thought of something else that netmail should have. We need an option, like the Post Office has, whereby you can request that obscene mail from certain senders not be delivered. -------  Date: 11 AUG 1977 1104-PDT Sender: DCROCKER at USC-ISI Subject: Re: obscene mail From: DCROCKER at USC-ISI To: Frankston at MULTICS, postel at ISIB Cc: reid at CMU-10A, dcrocker, header-people at MIT-MC Message-ID: <[USC-ISI]11-AUG-77 11:04:00.DCROCKER> In-Reply-To: [MIT-Multics]1.2.BBBJGjlDwDjNgd I have a file of messages and responses that I send (and received) last Christmas which you might appreciate. I will try to fetch it and send you each a copy. Keep in mind the Postal Inspector idea. Dave. -------  Date: 11 AUG 1977 1437-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: loops in HEADER-PEOPLE To: HEADER-PEOPLE at MIT-MC CC: (BUG MAIL) at MIT-MC MAIL on MC was horribly backed up today, and while looking through the queue I discerned an number of messages from 2 days ago making the rounds again. I hope that someone will find this loop and kill it, because it appears to require a fair amount of time to foward mail to HEADER-PEOPLE due to the large amount of network sending required. I suspect that the HEADER-PEOPLE list is largly responsible for the backlog. (I hope that this one doesn't loop!)  Date: 11 AUG 1977 1550-EDT From: MOON at MIT-MC (David A. Moon) Subject: Re: RFC 724 Status To: Dcrocker at RAND-UNIX, POSTEL at USC-ISIB CC: HEADER-PEOPLE at MIT-MC, Pogran at MIT-MULTICS CC: Henderson at BBN-TENEXA, Vittal at BBN-TENEX I just looked over some of the comments on RFC724 that were sent to Header-People last spring, after seeing Dave Crocker's letter saying that it was planned to ignore most of the comments. I think there are two issues here that strongly affect MIT-{AI ML MC}. One is that in order to continue services we already provide, we need a way to include complex structured text in recipient names we include in outgoing headers. Other hosts need to be able to send this complex text back intact, without parsing it, when replying to mail originating from us. I expect that other sophisticated mail systems either need such a feature now or would like to have features which would require such a thing. For example, mail sent from Tenex via a distribution list cannot currently be automatically replied to, because the name of the distribution list is not in a format which can be sent back to that same site as a recipient name and cause forwarding through the distribution list. We currently represent structured text by text enclosed in balanced parentheses. RFC724 disallows this by using parentheses for comments, which is all right, but does not suggest an alternative, such as balanced brackets. Note that the "balanced" part is vital. Also a quote-the-next character convention that was standardized would help a great deal. Related to this is that RFC724 should include a guideline to implementors saying how to turn a "To:" field into a recipient for replies. For instance, should comments be deleted or should they be left in place? Should sites be required to accept all "To:" fields that they generate? The second issue is that I had hoped that RFC724 would provide the necessary standardization to allow our mailer to successfully parse headers on mail incoming from the network. For instance, if we get an error in delivery of mail, it is currently impossible to inform the author because there is no way to find out who the author is. This leads to a lot of unreliability. The reason we accept this, rather than parsing headers, is that currently header formats are too variable. It looks like RFC724, if the final version is essentially the same as the draft we have already seen, is not going to be much help with this. The clarification of From, Author, Sent-by, and Reply-to is certainly helpful. But RFC724 introduces even more recipient name formats, and some of the formats it allows are not machine parseable. Consider the problems with the comma in To: Jonathon Q. Public, Jr. which seems to be a proposed replacement for To: JQPublic@Site (Jonathon Q. Public, Jr.) which most (but not all) sites currently parse reasonably. RFC724 should make some recommendation about this. One final complaint about rfc724 which I have, and which I think is not trivial, is that it does not contain hints to implementors of the form "the way to do this is this" or "if this situation happens, you should inform the Sent-by, not the Author". I have a feeling that in its present form not everyone would agree on what it means, and the "724-compatible" mail systems may be just as incompatible as the present ones, in which case all the work that has gone into RFC724 will have accomplished very little.  Date: 11 Aug 1977 2003-EDT From: Brian Reid at CMU-10A Subject: Re: obscene mail To: Frankston at MIT-Multics (Robert M. Frankston) CC: reid at CMU-10a, dcrocker at USC-ISI usc-isi at USC-ISI, CC: header-people at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 11 Aug 1977 20:03:48 Brian Reid In-Reply-To: [MIT-Multics]1.2.BBBJGjlDwDjNgd Most of the dialogue in Header-People is already questionable. -------  Date: 11 Aug 1977 1903-PDT Sender: GEOFF at SRI-KA Subject: Re: Re: obscene mail From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: BRIAN.REID at CMU-10A Cc: reid at CMU-10A, header-people at MIT-MC Message-ID: <[SRI-KA]11-Aug-77 19:03:51.GEOFF> In-Reply-To: [CMU-10A] 11 Aug 1977 20:03:48 Brian Reid I like the 'Cc: dcrocker at USC-ISI usc-isi at USC-ISI' part the best. of your message. -------  Date: 12 AUG 1977 1235-PDT Sender: DCROCKER at USC-ISI Subject: Response to Moon, et al., Re: RFC 724 From: DCROCKER at USC-ISI To: Header-People at MIT-MC Message-ID: <[USC-ISI]12-AUG-77 12:35:20.DCROCKER> David Moon's note was too rational in style and moderate in tone for me to feel comfortable allowing it to pass unanswered. My response to Jon Postel's query has been misunderstood by enough people that I will hereby retract the phrasing of the sentence that has bothered so many of you and will replace it with the following: There have been relatively few comments generated, SINCE RFC724 WAS RELEASED and which introduce NEW material. Now on to David's substantive criticisms... Inclusion of random text (e.g., "complex structured text") is fully supported for the "person's name" part of an address. That portion is specified to be a in the second alternative of . Note that a consists of a series of s and that a may consist of a . Now a begins with a double-quote and ends with a double quote. In between may be ANY character. Lexical analysis is defined in a way which prevents rules from noticing but an implemented parser can avoid this problem. (The limitation exists for the convenience of specifying the standard; it turns out that it is really a false limitation.) I had originally thought that the only real limitation was that empty strings could not be specified, since two adjacent double-quotes are used to specify a double-quote to be used as data and not as a delimiter. Austin Henderson has pointed out that even this limitation is not present. The first double-quote is unambiguously taken as "beginning of string" and the meaning of the second is determined by the third character. Since the third character will not be a double quote (i.e., you must have SOME separation between strings), the second double-quote is taken to be the ending delimiter. Note that double-quote is the only character that NEEDS an escaping mechanism, within a . Also note that the facility eliminates the "Jonathon Q. Public, Jr." problem cited by David. It would be specifed inside the double quotes, as I have done in the previous sentence. With regard to determination of actual "responsible person" (to avoid calling that person the "author"), the spec is quite specific. If a Sender field is present, it must contain an unambiguous which will allow the referenced host to contact the PERSON who sent the note. If no Sender field is present, then the From field must satisfy this requirement. 724 uses different text than I just used, but I believe it to be no less clear. Note that the syntax of the source-indication field (Sender or From) is EXTREMELY simple. Complex syntax is supported for OTHER address fields. Sometimes the address list is a "mach-addr" list, rather than a simple "addr" list. The former requires that at least one member of the list be a valid machine-processable address. Processing of the "To" field: The standard is for SYNTAX and SEMANTICS and cannot reasonably place requirements upon how implementors choose to USE the standard, as long as what they generate is valid. In particular, comments are, by definition, superfluous to the "processability" of an address and therefore may be included or not, at the discretion of the creator. As a personal observation, I would say that passing a comment on would be a friendly thing to do, since the comment was presumably included for a reason. However the spec is clear that comments are not to be used in the FTP MAIL or MLFL commands, since that text is NOT part of the processable address. I think that the question about the responsibility of hosts to honor references to addresses they generate ("...required to accept all 'To:' fields that they generate") is an excellent one. In checking section II.C.1.a, I find that the spec makes no statement about the absolute responsibility of the generating host, although there are several statements which fairly strongly imply that responsibility. In particular, subsection 2) says that the part of a is "...whatever the receiving FTP Server allows...". In the final draft, I'll try to have us tighten up that loop-hole. There have been several calls for the inclusion of "hints to implementors". We think that this would be entirely innappropriate for inclusion in the specification of a standard. It is entirely appropriate for inclusion in papers discussing the standard. The role of a spec is to specify. Explanations in a spec should only clarify meaning. E.g., I suspect we had better clarify parsing of . Hmmm, seem to have finished the list. Now for another personal observation. Standards specifications cannot be taken as light reading. RFC 724 contains around 70 bnf rules. A rule-set that large must be analyzed VERY carefully, with a great deal of cross-referencing to the semantics section. While many of you have obviously put in a large amount of time and made excellent observations, suggestions, and criticisms, too often a criticism is based upon insufficiently careful reading. Besides the fact that that is leading to an enormous number of unnecessary misinterpretations, it means that the proposal is not getting the kind of critical review that it needs. It was the absence of additional (i.e., new) substantive commentary of this sort that I was saying was lacking. Prior to the issuance of 724, there was also a great deal of noise in the discussion, but there was also a significant number of excellent content reviews. I believe that 724 reflects most of the resulting suggestions which we could resolve. Since 724 was issued, only the multi-net and the date/time questions have been newly raised. Just so that no one will think that I am putting all the responsibility upon the readers and none upon us, the writers, I want to make clear that finding out now about the parts of the spec which simply are not comprehensible is extremely important. Parsing of is one example. One of you tried to understand the From/Sender/Reply-to stuff and finally broke down, requesting that we give more examples, etc. That was extremely valuable input; I'd like more. Dave. -------  Date: 16 Aug 1977 1033-PDT From: Klh at SRI-KL Subject: Mental malnutrition - we need meat... To: Header-People at MIT-MC With hours drawing nigh, it seems time for me to contribute something. I had collected a number of comments about RFC 724 but never sent them; although I will include them eventually, in this message I wish to explain the reason behind the reticence. As people have noted, there is often a lot of superficial arguing and proselytizing among Header-People. However, I don't mind this - at best it introduces interesting ideas, at worst it's amusing, and always it reminds one that something is supposed to be happening. What upset me when RFC 724 came out, invited a "why bother" stance, and has gnawed at me since, is the apparent invisibility of CAHCOM. The message from Dave Crocker mentioning "extremely minor" comments rekindled my ire, but not for the same reason that it did others; what hit me was the bulk of the message, into which I read the appearance of arrogance. Dave is right that the comments specifically addressing RFC 724 after its release have been few; anyone looking over the transcripts can see that. What was NOT minor was the total exchange around 724, its draft, and what constraints it should or shouldn't have; this, indeed, seems to be ignored. Basically, CAHCOM has blundered disappointingly for lack of *F!E!E!D!B!A!C!K* -- I don't mean feedback from the Header-People, but from CAHCOM itself. From the time that RFC 724 was released on May 13, to the time I write this, there have been exactly 3 messages from any of the CAHCOM people -- all from DCrocker. (Thank you, Dave.) The first merely mentioned that RFC 730 existed and was sent May 25. The second was Aug. 2 on "What is a Message?". The third was the reply to Postel that sparked another flurry of unfiltered mail. Before that, we had the draft release on Oct 29; the last note I can find from CAHCOM about it is dated 9 Nov from Vittal. Between then and May 13, nothing. This is just the quantitative basis supporting the qualitative impression that CAHCOM people give no explanations for what they do, provide scant acknowledgement of suggestions or comments, don't bother to respond to questions or criticisms, make no arguments comparing their schemes with others, and on this basis have the effrontery to dictate what is and is not to be in our collective mail-world. According to the latest news, 724 will not be seen again until it is stamped "official" in September (violators shot at dawn); nor will the adoption/monitoring scheme see the light before 724 is finalized. It is also rather galling that CAHCOM thinks they understand the relationship between "existing system's conventions and those in 724" well enough to tell the maintainers of said systems "how difficult the changeover should be". Isn't that for the maintainers, in Header-People, to figure out? By virtue (?) of delay and disinterest, might it be surmised that most CAHCOM people are disqualifying themselves from participation? Hard to tell... I am getting overly sarcastic perhaps. What I would have liked (and would still like) to see is some more constructive discussion, not one-way glass; there were many suggestions made about the draft of 724 last fall which I thought were very reasonable, which I don't see much trace of in 724, and I would like to know why; what is it exactly that CAHCOM thinks is wrong with them? Even the post-724 comments have no counterpoint to them; I would have loved to see the replies to Postel's 724 comments (May 23), and Moon's (May 14), as well as some word about ANSI standard dates/zones as described by Rick Gumpertz. Much of these were actually QUESTIONS. I see neither the answers nor the revised 724 that incorporates the answers, if any. But there is hope. Moon recently sent a message raising some of the same issues I had on my list, and DCrocker has replied in exactly the way I have been wishing CAHCOM people would (that makes 4). If this can be extended retroactively, I would be much more comfortable, much less depressed, and some of this bureaucratic blatherousness could be dispensed with. So, here are some procedural desires: When a message is clearly asking for some clarification, or making a suggestion for change, it should be replied to in a reasonable time. It is perfectly OK for more than one person to reply to the same things, especially if opinions are somewhat divided; the worst case would be a "you first" deadlock. Perhaps some one person (Dcrocker? Henderson?) should be responsible for delegating replies. The current version of 724 should be generally available, whatever shape it happens to be in. I would very much like my comments about BNF to be made on the basis of the latest typo fixes, clarifications, etc... It would be nice if CAHCOM people felt free to take informal surveys; e.g. "how many of you really like/dislike this neat hack" or "does anyone really depend on this kludge now" etc... I don't remember if this was ever done. If it were something directly tied to 724, the response might be much wider than what currently greets very random "surveys", since on many issues people just let someone else say it for them. There may be some feeling that anything not directly connected to SYNTAX, specifically of 724, is out of order. I disagree; 724 does have more general implications that can bear discussion, whether of semantics or wording or philosophy. The RFC itself cannot exist on its syntax alone (witness 1st section), why should CAHCOM? This is it for now -- I have a headache and will try to shove out the 724-specific stuff in a day or two. Probably also have some words for a couple of the auxiliary issues that have been banged around this summer. -------  Date: 16 Aug 1977 1711-EDT From: Rick Gumpertz at CMU-10A Subject: Re: Mental malnutrition - we need meat... To: Klh at SRI-KL CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 16 Aug 1977 17:11:43 Rick Gumpertz In-Reply-To: Your message of August 16, 1977 I agree with Ken totally. Much of what I would have criticized RFC 724 for had already been brought up (though perhaps never answered) and so I did not bring them up again. This seems to have had the effect that they just disappeared in some bit bucket. I would like to see someone (from the RFC 724 committee) go down all the points brought up in Header-people discussions (ther aren't all that many unique topics) and explain WHY things were chosen or dismissed. I also disagree with the comment that "Hints to implementers" should not be part of RFC724. Perhaps they should be in an appendix, with the notation like that in an appendix to EIA RS-232C, that they are not part of the official standard. If they are not part of the RFC-724 document, however, they are likely to get separated and misplaced, or worse yet, never produced. I personally would consider RFC 724 acceptable for official approval ONLY if such hints are available. Where are they now? Is anyone working on them? Rick -------  DLW@MIT-AI 08/16/77 22:04:21 Re: Following letter from Rick Gumpertz of 16 aug 77 Let me chime in: I agree that "hints to implementors" should in some way be appended to RFC724. I understand why they should not be part of the text of the official standard; but I think anyone who requests a copy of RFC724 should somehow ALSO get the "hints" section. This will go a long way towards settling disputes about the "right" way to treat various fields, and also may provide a suitable place to store semi-official agreements about issues not specifically covered the standard itself. I would very much like to see this put in. -- Dan.  Date: 17 AUG 1977 0122-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I think people have the unfortunate idea that a "standard" must be expressed in an abstract mathematical form, the idea being that anything mathematically abstract must be unambiguous. This results in a standard which is as hard to comprehend as a poorly-written math textbook. What a standard should actually be is whatever is most effective for conveying the precise meaning intended. Examples of how a certain part of a data structure are intended to be used are an extremely good way to explain what the "meaning" of the contents of the data structure is. A mail header standard should not ignore their usefulness out of a desire to appear to be made out of pure, incorruptible, platinum mathematics.  Date: 24 Aug 1977 0546-PDT From: Klh at SRI-KL Subject: New representation of 724 syntax To: Header-People at MC While crawling over 724 in an attempt to make sure I knew what I was talking about, I finally decided that part of the whole problem was the particular representation used. People have complained that BNF is basically a pretty horrible way to specify this stuff, but nobody seems to really know how else to do it. I don't either, but it seemed that with the application of a few ideas from a local meta-compiler, things could be improved. Rather than just suggest them, I went ahead and did them; header-people in general and cahcom people in particular can find the overhauled syntax living in either of two places: [MIT-MC] KLH;NEWSYN > requires no login [SRI-KL] NEWSYN.TXT login as anonymous, pw anything. I showed this to several people for comments, and it seems to be a win. With a better idea of what the syntax is asking for, people can presumably form more useful opinions about it. This is NOT a revised syntax, it is a revised representation of RFC 724, and is not meant to introduce anything other than a better notation. Consequently, apart from comments on its clarity, it needs to be checked by 724's authors for consistency -- but I think it's fairly accurate. The actual criticisms/suggestions I have will follow in another message; whipping NEWSYN up took some time. Would like to hear from people meanwhile. --Ken -------  Date: 25 AUG 1977 1642-PDT Sender: DCROCKER at USC-ISI Subject: Pending availability of report on Unix message system From: DCROCKER at USC-ISI To: header-people at MIT-MC, [ISI]Mailing.List: Message-ID: <[USC-ISI]25-AUG-77 16:42:18.DCROCKER> In the near future, my Rand report on our Unix-based message system (called "MS", which is pronounced "mizz") will be available and I am compiling a list of people who want copies. If you do, please tell me your U.S. Postal address. For those who are not sure, a brief description of the report is located in [ISIA]MS.Blurb and is accessible through FTP using the user name ANONYMOUS and any password. Dave Crocker. -------  Date: 26 Aug 1977 1018-PDT From: BH at SU-AI (Brian Harvey) Subject: If you're going to have a blarney can I hold your coat? To: header-people at MIT-MC 1. I am now back in California and would like to be added to the mailing list, please, whoever is in charge. 2. Aside to DCROCKER: Has anyone suggested to you that MS pronounced mizz as the name for a message system is sexist? (Women as secretaries.) 3. About the verboseness controversy. We seem to be divided in camps based on the use we make of the mail facility, as someone or other has suggested. (I suspect that the division is roughly based on whether or not one has a secretary who sends one's mail!) I would like to suggest that at least some of the difficulty could be resolved by a bit more tightness about the conditions under which various fields are used. In particular, it would help a lot if the standard outlawed the use of FROM and SENDER fields which are otherwise identical; the thing that annoys me the most is seeing From: FOO at MIT-MC Sender: FOO at MIT-MC Author: FOO at MIT-MC Originator: FOO at MIT-MC Reply-to: FOO at MIT-MC Copyright-by: FOO at MIT-MC and so on. Perhaps another way to put it would be that there would be only a few fields which a mail sending program would put in on its own initiative, and you'd have to ask for the others explicitly. 4. What a message is: I agree this is an important thing to discuss, and I'd like to argue for the view that we should think of it as being ASCII text directed toward a human being, rather than some abstract message to an abstract entity. My argument is basically that there is enough human-to-human traffic that it is worth treating that as a separate case. You abstract-entity people, I think, are really reacting to deficiencies in the file transfer protocol, which ought perhaps to be more powerful than it is to allow inter-program cooperation. The scheme used among the ITS systems to allow a program on one machine to read files on another machine is a good example of the sort of facility we need, but this should not be allowed to hair up our notion of mail! 5. Another side comment, about the style of the committee: I suspect a lot of the heat in this discussion comes from the fact that this is (I think) the first (proposed) standard which talks about things like everyone being REQUIRED to conform by such-and-such a date. Past standards just sort of sat there, and you could conform to them if you wanted to. I can sympathize with the thinking behind this requirement business, but it raises practical as well as emotional problems. SAIL, for example, has much more system programming to be done than people to do it, and Arpanet protocols are pretty low on the priority list. (My opinion, not to be construed as a SAIL policy statement.) Nobody is being funded specifically for Arpanet work; it has to slip into spare moments. (I have heard a similar remark from someone at BBN, by the way.) Consider the "new FTP", which has certainly not taken over the world. Given this situation, we must understand that many implementations will probably be quite minimal, and when users of such systems get annoyed at all the header text which should have been filtered out but isn't, it will not be constructive to argue about whether the blame lies with the standard or the local wizards. -------  Date: 26 Aug 1977 1703-PDT From: MRC at SU-AI (Mark Crispin) Subject: BH's message irt headers or First and 10, Let's do it again To: Header-people at MIT-MC I hope the people out there are listening, and aren't going to continue to simply ignore what may well be at least 50% of the ARPAnet community. Brian's message presents my major objections to what RFC 724 stands for, and possibly in a more coherant and constructive way. I still don't understand why I get mail with 15-line headers and 2 line messages, especially telling me that FOO @ FOO-SECURITY sent me the message 4 times. It seems that the amount of information gained by all the extra stuff decreases proportionally with the amount of increase in the header, so while a 3 line header gives you n bits of information, a 6 line header gives you n+n/2, a 12 line header gives you n+n/2+n/4, etc... What are all those fields for anyway? To ensure that a message isn't forged? I really don't think that prevents it. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 27 August 1977 0136-edt Subject: Abstractions versus ftp Message-ID: [MIT-Multics]1.2.BBBJGlCBzPjcBX To: bh at SU-AI cc: header-people at MIT-MC Brian, I agree with you that there is a basic problem steming from the shortage of programmers with time to work on ftp or mailsystems. It is from this observation that some of us abstract-data-type people wish to work within the context of the current ftp and mail programs and thus are forced to use the text of the message to represent the abstractions we envision in the form of an ASCII string. As a compromise this string is readable by people, though ideally it is processed by your local deabstractor (mail reading program). As long as we have people who want info in the headers for the mail reading programs to munch (such as my plea for message-id's) and others who wish to readmail with the type (or print) statement on a slow terminal we are going to have strong feelings about the size of headers.  Date: 28 AUG 1977 2200-PDT Sender: STEFFERUD at USC-ISI Subject: Re: Pending availability of report on Unix message system From: STEFFERUD at USC-ISI To: DCROCKER Cc: header-people at MIT-MC, Cc: Stef at KA Message-ID: <[USC-ISI]28-AUG-77 22:00:27.STEFFERUD> In-Reply-To: <[USC-ISI]25-AUG-77 16:42:18.DCROCKER> Hi Dave, Just to close the loop, please sned my copy to Einar Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA 92647 -------  Date: 29 Aug 1977 0140-EDT From: Brian Reid at CMU-10A Reply-To: Header-People at MIT-MC Subject: once more, with feeling. To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 29 Aug 1977 01:40:55 Brian Reid In-Reply-To: MRC's message of August 26, 1977 Louis Armstrong was once asked by a reporter, "What is jazz?" He is reputed to have answered, "If you gotta ask, you ain't never gonna understand anyhow." -------  Date: 29 AUG 1977 1242-PDT Sender: DCROCKER at USC-ISI Subject: Social Statistic of Computer-based Human Communication From: DCROCKER at USC-ISI To: Header-People at MIT-MC, [ISI]Mailing.List: Message-ID: <[USC-ISI]29-AUG-77 12:42:58.DCROCKER> Last Thrusday evening, at about 5pm Pacific time, I sent a note to approximately 130 people around the country. The response statistics are, to me, a little scary: Even though I sent the note at the end of the day, I had 7 responses within 90 minutes ((6 west-coasters and one mid-westerner). Within 24 hours, I had received 28 responses, or approximately 20 per cent of the people I polled. This sort of two-way connectivity is incredible. Since I know of no other hard data on the subject, I thought you might like to have the above available for citing. Dave. -------  From: Pogran.CompNet at MIT-Multics Date: 08/29/77 1149-edt Subject: A precedent for setting protocol changeover dates To: BH at SU-AI cc: Header-People at MIT-MC Brian, Believe it or not, there IS a precedent in the ARPANET for establishing a date by which everyone is REQUIRED to conform. It's New TELNET. The original "release" of the New TELNET document, RFC 495, NIC 15371, by Alex McKenzie, dated 1 May 1973, indicates that by 1 July 1973 all sites should be able to accept, without generating error responses, the New TELNET control codes (IAC XXX), and that by 1 January 1974 everyone should have implemented New TELNET and sites need not support Old TELNET any longer. Of course, those dates weren't met. Some sites still complain when sent New TELNET controls over an Old TELNET connection; most likely, some sites still don't implement New TELNET. The point is, though, that the CONCEPT of "required" dates of implementation is not new to 724 -- and the authors of 724, the rest of CAHCOM, and Steve Walker of ARPA were all well aware of this when it was first brought up in the context of 724. Regards, Ken  Date: 11 Aug 1977 1347-EDT Reply-To: Header-People at MIT-MC Subject: Re: Leaving things as they are To: MRC at SU-AI (Mark Crispin) CC: Header-People@MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Aug 1977 13:47:21 Philip Karlton In-Reply-To: MRC's message of August 10, 1977 The problem with leaving things as they is that different sites have different conventions concerning the format of items that programs are currently trying to parse. (If you want some examples, here are 2: One site puts no "," at the end of each line of an address list that is continued on the next line; some sites (programs) insist that embedded blanks in names should be thrown away and at least one site uses both first and last names (separated by a space) to disambiguate addresees for delivery.) RFC 724 is, at least as far as I understand it, an attempt to make a standard syntax and semantics for all the things that people are sticking into their mail headers already. I think that the authors have bent over backwards to allow almost all of the things that mail creating programs are currently doing. Why else would they choose to allow both the type of date given in the header of this message and "slash" dates which are ambiguous if a European is reading the letter? I do not know what it is specifically that you object to in RFC 724. If you had the authority would you just disallow all but a few items in the header? DO you not think a standard syntax and semantics for those items in headers likely to be parsed by programs is desirable? My apologies; I should not get facetious. I expect that your answers to these particular questions are the same as mine. Do you have some concrete suggestions for changes to RFC 724? Phil Karlton -------  Date: 29 Aug 1977 1500-PDT From: ME at SU-AI (Martin Frost) Subject: Slow loop in net mail? To: header-people at MIT-MC Why is Philip Karlton's message of 11 Aug 77 making the rounds again? -------  Date: 29 AUG 1977 2114-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: Slow loop? To: HEADER-PEOPLE at MIT-MC According to the stats, that odd repeat message from Karlton to MRC arrived from CMU-A about 17:51:31 today (29 Aug). As to why and how, I think the CMU people will have to answer that.  Date: 29 Aug 1977 2131-EDT From: Brian Reid at CMU-10A Subject: Re: Slow loop? To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 29 Aug 1977 21:31:48 Brian Reid In-Reply-To: KLH's message of August 29, 1977 As many of you have probably noticed, the CMU mail system has been having its ups and downs lately. Philip Karlton asked me to comment on his message of 11 August, and upon checking my message file, I found no such message. We had no way between us of telling whether it had not ever gone out, or whether it had gone out but just nobody at CMU received it. So, I suspect, he shoved it out again. Sigh. Sorry about whatever part I had in this mixup. yours for a junk-mail-free network, Brian -------  Date: 29 Aug 1977 2158-PDT From: MRC at SU-AI (Mark Crispin) Subject: Slow loop To: Reid at CMU-10A CC: Header-People at MIT-MC A touch of humor; since CMU apparently was guilty of the previous loop (so I was told anyway): Maybe if CMU concentrating on making their mailer WORK they wouldn't be so fired up on making their headers so hairy. For example, Brian's last message told me that he, Brian Reid, sent the message; THREE times. It also included the date of sending, TWICE. I've also noticed that some CMU mail has no "From:" field. C'mon, CMU'ers, you can do better than that! In response to BH's comments earlier; ok, I admit to my everlasting shame that I am not one of the mandarins with a secretary, and actually type my mail myself, with my own 10 (or 9 right now) fingers. So, if we are going to be hairy, as it seems is going to happen in spite of everything, why don't we require as part of 724 that we have a list of everybody on the ARPAnet (the NIC directory is a good start), and whether or not they have a secretary. Every host will have to have this list, as with the host tables, and maintain it. People who are not privileged to have secretaries are not privileged to get long mail with hairy headers. THEN EVERYBODY WILL BE HAPPY! Btw, as the author of ITS user TELNET (a new TELNET protocol program), yes, indeed many hosts do not implement it, although that situation is not nearly as bad as with new FTP, which shall stand as a monument to human time-wasting. Not that HEADER-PEOPLE is far behind; we're sure to win in the long run. -------  Date: 30 Aug 1977 at 1529-PDT Subject: Host reference, in a multi-net environment From: Dcrocker at Rand-Unix To: header-people at Mit-Mc cc: Postel at Isib, Sunshine at Isd, Dcrocker at Rand-Unix Message-ID: <[Rand-Unix]30-Aug-77 15:29:26.Dcrocker> The following represents my current thinking with regards to referencing specific hosts which are part of a multi-net environment. I would appreciate comments. Carl Sunshine(1) distinguished between "source" (relative) and "global" (absolute?) path names. Relative pathnames will get the message from the current location to the destination. However, when the pathname is recorded as data in a message and the message later migrates around to other places, the context which explains the pathname is lost. For example, "go down the hall and turn left, stopping at the first door on the right" is great if you start from my office, but terrible if you are in Boston. Since we are expecting hosts to come and go with much (ir-)regularity and we are specifically not willing to have all hosts know about all other hosts (that have ever existed???), then we cannot use simple global names. If we could predict a tree (approximately) of networks, rather than a full and messy network of networks, then we could use the solution employed by Unix, Multics and others for their file systems: A pathname which begins at the root node and works down. This would uniquely identify hosts, allowing each node to process that part of the address which is knows about. (Postel has pointed out, however, that it doesn't begin to help you figure out how to actually route the message, since routing everything according to its absolute path guarantees that you do not take advantage of any short-cuts in the system; here, I am concerned with specifying the address in a context-independent manner, and not with optimally using the address specification. Unfortunately, the claim is that we will really have full network structuring. Having said that, I will now suggest that we will really have a more tree-flavored situation, with a top-level of networks that will be as dominant and continuing as countries, and therefore will recommend using Jon Postel's suggestion(2). That is, I suspect that we will have a relatively few international networks which represent the root (more like a ring) of the "tree" and which WILL know about each other (tho not necessarily know about each other's constituent hosts) and that it is reasonable to expect the constituents to know what international net they are part of. This latter requirement is necessary so that hosts can take a pathname which references the root network and do something reasonable with it, like send it to a node which is the gateway to the international system. Specifically, I suggest that when the data of a message contain a host reference outside of the local net that the FULL pathname always be used. Within Postel's scheme, this would require that the text always begin with "NET" (or "INET", since we need to distinguish between local nets and larger international nets). This is tantamount to requiring that all mail which goes out of the city must include country, as well as state, indication. For the purposes of computer mail, I think the requirement is reasonable. Postel used keywords to indicate the level of specification. For mail usage, we need only distinguish between simple local references and full global paths. Postel suggests slash ("/") as the field separator, so it seems reasonable to merely have a beginning slash indicate root-references quite easy. Ergo, my Rand address might be: /Arpa/Rand/Unix-70A. (And I apologize profusely for the fact that this coincidentally is the way Unix does it.) I am not thrilled with the aesthetics of slash, but it works; most alternative graphic characters might not be noticed at the beginning of a string. The above is mostly intended to stimulate some responses from y'all. Please let me know of alternate approaches and/or minor variations you recommend. (1) Sunshine, C. Source routine in computer networks. Computer Communication Review, Vol. 7 No. 1 1977, pp. 29-33. (2) Postel, J. Extensible field addressing. Arpanet RFC 730. 20 May 1977.  MRC@MIT-AI 08/31/77 02:24:54 Re: Inter-network mail; response to proposal from DCrocker As the implementor of DIALnet, I would prefer that the inter-network mail protocol be as simple as possible. If a hairy protocol results in spite of my efforts that appears to be more than most DIALnet sites will be willing to implement (as hair on the level of 724 is), I shall ignore it and establish a private protocol to be used by DIALnet and cooperating ARPAnet sites; there are precedents for ignoring the official protocols and hopefully the message-entity people will be willing to see other's points of view in this matter. I would prefer that the official mail protocols do the right thing to begin with. Now that I have gotten that off my chest, let me present my suggestion: Inter-network mail is specified by a pathname which contains the destination address IN THE OTHER NETWORK'S FORMAT, delimited by parentheses, with quoting applied in the possible but unlikely case of unbalancedness. In the event of multi-network forwarding, cooperation between the networks in doing this is encouraged. By this, I mean the following: take the example of a message being sent to FOO-SECURITY, which is on the FOOnet. There are no connections between the ARPAnet and the FOOnet, but the BARnet is connected to the ARPAnet at host BAR-AI and to the FOOnet at host FOO-DMS. The message is to go to user Fred Foobar at FOO-SECURITY, and the FOOnet uses mail formats of an arrow made of dashes and a greater than sign for destination. The pathname is built additively: 1. FOO-SECURITY --> Fred Foobar (initial) 2. (FOO-SECURITY --> Fred Foobar) @ FOOnet 3. ((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS 4. (((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS) @ BARnet 5. ((((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS) @ BARnet) @ BAR-AI The last pathname is the ARPAnet pathname. Each level strips off the parentheses to derive its next path. No processing is done to the innter levels. And, none of this appears in the message header. The use of at-signs was to provide some consistency and to establish a universal convention. It is quite reasonable that at-signs be used for each level of the path including the innermost; it is certainly a reasonable character to use. The example presented was picked as a hairy example. In practice, I would expect that they be much simpler. The basic idea behind off of this is that a host gets the path with the CAR being the pathname to which it should send the message, and the CDR being its own ID. The pathname, if atomic, means it should stop there. If non-atomic, it means further forwarding, the CAR being the next pathname, the CDR being the destination. If the destination is a network rather than a host name, the message is passed next to the host's own NCP for the other network, whcih then does similar sorts of processing. Note that there is no protection offered against a malicious or idiotic pathname specification. If a host feels it is in danger of such, it is its responsibility to protect itself against this. Any such "protection" should not prevent normal nesting.  Date: 31 Aug 1977 1434-EDT From: Rick Gumpertz at CMU-10A Subject: Re the CAR/CDR addresses To: mrc@mit-ai CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 31 Aug 1977 14:34:22 Rick Gumpertz In-Reply-To: Your message of August 31, 1977 In your example the paths were always left associative. Therefore, why have the parens at all?? @ can still be quoted in some manner if necessary. Thus your example becomes: FOO-SECURITY --> Fred Foobar @ FOOnet @ FOO-DMS @ BARnet @ BAR-AI Admittedly this might be a bit more restrictive in how names are constructed, but really not very much so. Rick -------  Date: 31 Aug 1977 1517-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC Actually, for consistency I would recommend this form, simply assigning @'s as THE delimiter. Fred Foobar @ FOO-SECURITY @ FOOnet @ FOO-DMS @ BARnet @ BAR-AI I selected parentheses, however, since it would be too open to ambiguities; LISP-type CAR and CDR forms are much easier for programs to parse and snarf off the information (in my opinion of course). It is also my dislike for APL-style thinking; I think the parens make it better for use faulty humans to parse as well. My intention is that Fred only sees his actual address, Fred Foobar @ FOO-SECURITY, and not the whole hairy path. Also I postulated this example as being quite hairy and unlikely in practise. What I consider more likely is something like a message being sent to a DIALnet user from the nearest ARPAnet site that supports DIALnet as well; this might mean something like a message going to me at Stanford LOTS looking like: ((MRC @ SU-LOTS) @ DIALnet) @ SU-AI This assumes that SU-AI knows SU-LOTS's DIALnet phone number (it will, of course). You can add some more smarts; assume SU-AI knows that it has to use DIALnet to go to LOTS (it will). The address can be made even simpler by using: (MRC @ SU-LOTS) @ SU-AI and the simpler, the better. Peace, Mark -------  Date: 31 Aug 1977 1821-EDT From: Brian Reid at CMU-10A Subject: Re: Re the CAR/CDR addresses To: RICK.GUMPERTZ at CMU-10A CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 31 Aug 1977 18:21:41 Brian Reid In-Reply-To: [CMU-10A] 31 Aug 1977 14:34:22 Rick Gumpertz Just throw quotes around any address that doesn't parse as an identifier: FOO-SECURITY-->Fred Foobar @ "Foo\\Net" @ Foo-DMS etc etc etc. The CAR/CDR notation is at best difficult to read, and it is slightly surprising to see something so ornate coming from the strongest proponent of simplified and human-readable headers. Brian -------  Date: 31 Aug 1977 1537-PDT From: MRC at SU-AI (Mark Crispin) Subject: To paren or not to paren, that is the question To: Header-People at MIT-MC The problem with not paren-ing is that you can introduce ambiguities; I called the notation CAR/CDR ala LISP, but I was also sort of expressing it in FORTRANese, using @ as an operator. It is also my intent that humans see little of this; I expect that this does not show up in the message header. -------  Date: 31 Aug 1977 2113-EDT From: Brian Reid at CMU-10A Reply-To: Header-People at MIT-MC Subject: Parenthesized fields that the user never sees To: Header-People@MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 31 Aug 1977 21:13:56 Brian Reid In-Reply-To: MRC's message of August 31, 1977 I see. Well, I'll tell you what: Please take this enchanted place that users will never see and that is not a message header, and put my Message-ID and Sender and Reply-to fields in that box. Then we'll both be happy: I will get all of my header fields, and you won't have to look at them. -------  Date: 31 Aug 1977 2056-PDT From: MRC at SU-AI (Mark Crispin) Subject: magic place To: Header-People at MIT-MC Better yet, limit mail headers to "Date:", "From:", "Subject:", and (only in the case of multiple recepients) "To:"; and sites that like such hairy stuff can have their mail server add them on! I'm sorry, Brian, but I feel that a Date/From specification, especially when the time is reported to the second (on the sender's computer's time, which of course has no relation to real time) is enough to uniquely identify a message; and that your own mail server or reader can add that stuff on! Since mail can be forged anyway, I think having a From: field being merely who the sender alleges to be and where replies should go is enough. Of course, those people with secretaries want to show off that they have a secretary, so they want that "information" in the header. I wonder how the secretary feels on the subject; perhaps if s/he knew that his/her name appearing in the header was considered junk by a non-trivial portion of the ARPAnet community s/he would prefer anonyminity! -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 1 September 1977 0015-edt Subject: The umpteenth time. Message-ID: [MIT-Multics]1.2.BBBJGlWXmZPcpM To: mrc at SU-AI cc: header-people at MIT-MC A second is a very very very very long time. About a million operations on your average run of the mill computer sytem.  Date: 31 Aug 1977 2114-PDT From: MRC at SU-AI (Mark Crispin) Subject: seconds To: Header-People at MIT-MC C'mon, Bob. A computer may do a million operations a second or whatever, but we humans can't. My point stands that the info in the From and Date fields are enough to uniquely identify a message. -------  DLW@MIT-AI 09/01/77 00:26:49 Re: Relevancy. To: MRC@SUAI at MIT-AI, Header-People at MIT-MC In reply to your suggestion: Better yet, limit mail headers to "Date:", "From:", "Subject:", and (only in the case of multiple recepients) "To:"; and sites that like such hairy stuff can have their mail server add them on! There are 130 blocks of text which have been sent to the Header-People mailing list. You are welcome to read them at your leisure if you want an explanation of why there must be more fields than these. There has been a GREAT deal of discussion already and this suggestion completely ignores all that has gone before. The minutes can be found on MIT-MC's KSC directory, and I, for one, read through all of them before attempting to add my own comments; if you do the same you will know why more fields are important.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 1 September 1977 0031-edt Message-ID: [MIT-Multics]1.2.BBBJGlWZhdCBLg To: dlw at MIT-MC Cc: header-people at MIT-MC Thank you. PS: One of your ill formated headers just escaped.  Date: 1 Sep 1977 0114-EDT From: Brian Reid at CMU-10A Subject: Re: To: Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 1 Sep 1977 01:14:11 Brian Reid In-Reply-To: Your message of September 1, 1977 Who is DLW@MIT-AI? -------  4613 Filmore St. Pittsburgh, PA 15213 1 September, 1977 In reply refer to: 0901301B Mr. Mark Crispin 807 Laurel Ave. Menlo Park, CA 94025 Dear Mr. Crispin: I don't have a secretary, and I probably don't ever want one, as I feel confident that with a video terminal and a good editor (neither of which I have here with my DECwriter) I can get mail out faster by typing it in myself, but I still feel that some of the header fields will benefit me. For many years, business concerns who care about reliability and efficiency have used the equivalent of the Message-ID field in their correspondence. True, we in the academic world don't need the precision so vital to business correspondence, for it is not commerce but flakey ideas that our mail promotes. Perhaps it is unfortunate that the explanation in RFC724 of the "Sender:" field used the secretary example, and perhaps it is unfortunate that early implementations of 724-like headers (CMU's, for instance) did not take the trouble to strip out the Sender field when it was equal to the From field. But this shouldn't mean that these fields are bad, only that they are currently being misused. And just think: even as you can look at my computer mail to you and find out that it says "Brian Reid" in 3 different places, you can also look at the "inside address" of this letter to find out where you live. O, the world is full of redundancy. Sincerely, X (his mark) Brian K. Reid  Date: 1 SEP 1977 0257-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: In further reply to your message of 2056-PDT To: MRC at SU-AI, HEADER-PEOPLE at MIT-MC about your letter: its subject is "magic place", and yet it does not address itself to Brian Reid's question, which I will repeat: Where is this magic place? Wherever it is, I want to put Message IDs there. I will also take this opportunity to mention that my first message to header-people proposed a very cheapo implementation of the "magic place" which would be attained by having mail receivers do a very trivial header parse. I still think this was a good idea, what do people think about adding it to RFC724? P.S. Sorry that I let an ITS internal header out. This happened because I sent the mail to "HEADER-PEOPLE at MIT-MC" from MIT-AI. As far as the MIT-AI mailer was concerned, HEADER-PEOPLE is a simple recipient at an ITS host, and so the mail should be given an ITS header. The right way to fix this would be for MIT-MC to parse the incoming header and fix it up. This is yet another example of why it is important for mail headers to be parseable. P.P.S One reason that the date/time is not sufficient as a Message-ID is that PROGRAMS can generate and send mail very quickly. This was mentioned very early in the Header-People discussion; as I pointed out, you should read what has gone before and stop wasting everyone's time with repetitions.  Date: 1 Sep 1977 0003-PDT From: MRC at SU-AI (Mark Crispin) Subject: magic place To: DLW at MIT-AI CC: Header-People at MIT-MC Dan, you were inattentive to my message. Perhaps I generated too much text and obscured my point. You would have noticed that I mentioned that mail service programs could do the header parse. In fact, SAIL's mail server does that; it parses the ARPAnet header as well as it can and puts a SAIL-style header at the beginning of the mail that it puts in the mail file, making the ARPAnet headers almost useless (except for the To:/Cc: lines which sometimes have a good reason to be there). There is of course the problem of a malicious mail user sending mail with an unparseable header; apparently to retaliate to an argument for smaller headers as one reason. A mail server should be prepared to flush randomness. In any case, I think that something that the user SEES should not be bloated by long headers. I think most sensible people would agree it is silly to receive a message with a (as once happened to me) 15 line mail header, and 0 (!!) line message text; my correspondent typed the whole body of her message in a few words in the Subject: line! If this stuff is included in a "no op" type FTP protocol message which servers can ignore or use as they see fit, then perhaps everybody would be happy. I don't care how much garbage you want to send along with the message, just so long as I don't have to see anything other than: date/time of message who sent it (valid arpanet address) one line subject (optional) other recepients of the message -------  Date: 1 Sep 1977 0224-PDT Sender: GEOFF at SRI-KA Subject: Re: magic place From: GEOFF at SRI-KA To: MRC at SAIL Cc: DLW at MIT-AI, Header-People at MIT-MC Message-ID: <[SRI-KA] 1-Sep-77 02:24:32.GEOFF> In-Reply-To: Your message of September 1, 1977 Mark, Your points are well taken, but it seems this is the day and age where we are going to have to live with (many) message headers to keep 'everyone' happy, and that the filtering of headers is going to have to be on the readers end with his message reading program. HERMES is very well suited for this, since you can set up things called TEMPLATES and see JUST what you want to see (or don't want to see) in the order you want to see them. I personally never have the MESSAGE-ID and SENDER: fields printed out as a default when reading my mail, but on occasion I have found it useful to 'see them' when I needed too. Therefore, no matter how many ill-fated message headers you many put in your message I am only going to see the ones I am interested in. Weither this filtering of message headers belongs in the FTP protocol or in the users message reading program (like HERMES) is debatable topic. The main gripe I have toward for something like HERMES is that it doesn't let me turn off sending the SENDER and MESSAGEID fields, so i am sorry that those who don't have header filtering hack that HERMES has to see them. [Geoff] -------  Date: 1 Sep 1977 1243-EDT From: Rick Gumpertz at CMU-10A Subject: Re CAR/CDR To: MRC at SU-AI (Mark Crispin) CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 1 Sep 1977 12:43:18 Rick Gumpertz In-Reply-To: Your message of August 31, 1977 But it can't really be that hard to search for the last @ which is not quoted and split the string there, can it?? Rick -------  Date: 1 SEP 1977 1625-EDT From: RMS at MIT-AI (Richard M. Stallman) To: MRC at MIT-AI, reid at CMU-10A I am not sure what Brian Reid thought he was going to prove with his message sent in ordinary letter form. Perhaps he is saying, "See, you have used bloated headers all your life in US mail, and never objected, so how dare you object to them in network mail". To that, my reply is that US mail is transmitted on paper, which medium provides much faster random access and much more text visible at one time than any computer terminal I have ever seen. There is no reason to expect that information which is marginally useful on paper will remain at all desirable in a slower medium. Of course, he might just have been saying, "US mail imposes bloated headers on you, so why should I be any more considerate?".  Date: 1 SEP 1977 1716-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: header-people at MIT-MC If you are wondering why you got a message whose header stated that it was from RMS@MIT-AI to MRC and REID@CMUA: What happened is that RMS sent the mail from MIT-AI at 16:25, and it was send off to MRC at MIT-AI and REID at CMUA. Then at 16:44, the MIT-MC mailer received the same message from CMUA addresses to HEADER-PEOPLE. So either the CMUA mailer decided that the message was of interest to all of us and sent it off, or Brian Reid sent it to everyone without any additional header or warning.  Date: 1 Sep 1977 1720-EDT From: Brian Reid at CMU-10A Subject: 3 guesses To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 1 Sep 1977 17:20:47 Brian Reid The business world has through several thousand years of written correspondence managed to evolve a fairly efficient and fairly uniform scheme for written communication. There is a very good reason for every part of a business letter. Perhaps a bunch of hackers and graduate students can't see, from their vantage point, what the utility might be. And from current usage of the ARPAnet, as a toy for overprivileged CS students and systems hackers, there probably isn't a reason. But while we all sit in our packet-switched playpen and talk about whether or not graduate students and hackers need message-id fields on their correspondence, there are people out there who need networks, either this one or others like it, for real commercial and military correspondence. It is to the needs of real people doing real correspondence, and not just to our own toy needs, that RFC724 is addressed. -------  Date: 1 Sep 1977 1724-EDT From: Brian Reid at CMU-10A Subject: header question To: DLW at MIT-AI (Daniel L. Weinreb) CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 1 Sep 1977 17:24:45 Brian Reid In-Reply-To: Your message of September 1, 1977 Now if we had some tight header standards, we might be able to figure this out. Yes, I sent it to Header-People; I don't like private sub-discussions. -------  Date: 1 Sep 1977 1724-EDT From: Brian Reid at CMU-10A Subject: header question To: DLW at MIT-AI (Daniel L. Weinreb) CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 1 Sep 1977 17:24:45 Brian Reid In-Reply-To: Your message of September 1, 1977 Now if we had some tight header standards, we might be able to figure this out. Yes, I sent it to Header-People; I don't like private sub-discussions. -------  Date: 1 Sep 1977 1507-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC 01-Sep-77 1436 FTP: Brian Reid at CMU-10A header question Now if we had some tight header standards, we might be able to figure this out. [MRC - What utter hypocracy! You deliberately violate what is considered courtesy under current mail standards, and you say your discourtesy is due to people not being forced to be courteous.] Yes, I sent it to Header-People; I don't like private sub-discussions. [MRC - Yes, we must annoy other people with messages that the message author considered either irrelevant to the whole group, or discourteous to hassle everybody with a special interest message, or had reasons for wanting the message to be off the record. Thank you, Brian, for showing us how to further stuff our mailboxes with more garbage so that we can show off "see, look how important I am; I get 60K of mail daily" -- all we have to do is be discourteous.] ------- -------  From: Pogran.CompNet at MIT-Multics Date: 09/01/77 1135-edt Subject: On "From", "Sender", and secretaries To: Header-People at MIT-MC I'd like to respond to the recent discussion about "From", "Sender", and secretaries. In developing those parts of RFC 724, we (the authors) were responding to a need expressed by some people using the "ARPANET Message Service" in a manner similar to the "commercial" use described by Brian Reid. To be sure, that sort of use isn't very common among the members of Header-People; systems programmers, graduate students, computer scientists, and hackers (have I left anyone out?) AREN'T the sort of people, generally, who would find a use for it, as Brian also points out in his letter (0901301B). But, over the LONG TERM, it's quite likely that there will be a much larger number of commercial and military users of 724-compliant Message Services who WILL find these features useful than there will be systems programmer, graduate student, computer scientist, and hacker types! So, we're trying to provide for an eventual broader spectrum of user types than Header-People constitutes. Please keep that in mind. Regards, Ken Pogran  Date: 1 Sep 1977 2006-PDT From: MRC at SU-AI (Brian McCune) Subject: CMU hacker's habits To: Header-People at MIT-MC Why is it that CMU hackers, who argue for the most hairy headers, insist upon sending mail without headers when they want to express irritation at people? They also forward mail without any header of their own indicating who actually sent the message on; which I believe can come under the heading of "falseified (or forged) mail headers". Thank you, CMU hackers, for providing such outstanding examples of maturity that more weight is added to my arguments than I could have possibly have done with all my attempts at exhorting the world towards common sense (or what is common sense in my opinion). (My apologies to my friends who are CMU hackers) -------  Date: 1 Sep 1977 2012-PDT From: MRC at SU-AI (Mark Crispin) Subject: Mail about CMU hacker's habits To: Header-People at MIT-MC, BPM I don't know why, but SAIL suddenly confused BPM and me. I haven't changed my name or anything. -------  Date: 2 Sep 1977 0224-EDT From: Brian Reid at CMU-10A Subject: since it seems to have come to this... To: MRC at SAIL CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 2 Sep 1977 02:24:09 Brian Reid Your mother wears combat boots. -------  1 Sept. 1977 Dear Brian [Reid], I think the point you made in your business letter was well taken. However, most informal correspondence is carried out with a minimal amount of information as to who is writing to whom. The recipient knows very well who sent it from the first name signed at the bottom, and has no need to repeat the address s/he has seen many times before. There is no need for all that formality. Sincerely, Tovar P.S. My apologies to those people whose programs I have confused, that is, those programs which remove all that verbage which I always have to see.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 2 September 1977 0252-edt Subject: Tovar Message-ID: [MIT-Multics]1.2.BBBJGlbLCClfkl To: header-people at MIT-MC Who what or where (or why?) is a Tovar?  Date: 2 Sep 1977 0018-PDT From: TVR at SU-AI (Tovar) Subject: It is a free-for-all, isn't it? To: Header-people at MIT-MC To Frankston: Sorry, you type too fast. My well addressed message was on it's way. Message-ID's For human written messages, i know of few people that can send more that one per second and it is rare that more than one per minute are sent. Thus, for most purposes, the FROM, TO, DATE and SUBJECT should be enough to disambiguate. Now, it has been suggested that programs which automatically send messages can generate a large number per second. I agree that they can, and they can also put in message-ID, as an optional field. [Hey, what a neat way of sorting out junk mail!] Thus, when a message is recieved, a message-ID is constructed as the message is received and is replaced by an explicit one if such is given. Messages to other nets: This one can be handled simply as well. Just allow anything in front of '@' preceding the ARPANET sitename. The recieving site strips that off and if it is a portal into another net, looks at it for external host specification and if one is found, hands it, less the ARPA sitename, to that net's interface program. Our responsibility ends there. We can hope that other nets will have similar protocols and will find our headers of use to them, but we shouldn't depend on it. (What is TO: in French, anyway?) Here's another can of worms: What should we do about headers send from other nets? Full pathnames? How about something like a host list instead. I doubt if we will end up with more very many networks with the same name. The list consists of names and default short pathname. Perhaps someone will even volunteer to make a program to generate minimal travel time pathnames for each network sites. So you want all these hairy headers? Well, perhaps putting this stuff as part of the FTP sequence for mailing might not that horrible an idea. By the way, what ever happened to the envelope idea that was kicking arould a while back (while we resurrecting old ghosts). "What is jass?" You have to learn sometime; but a "master" won't tell you. By the way, insults will rarely get you anywhere, especially with MRC. Now come on, kids. Army boots? I'm sure everyone's got there guns out by now so enjoy shooting this all down. Tovar (TVR @ SU-AI) -------  From: Frankston.ECDports (Robert M. Frankston) Date: 2 September 1977 0325-edt Subject: replies to Tovar Message-ID: [MIT-Multics]1.2.BBBJGlbMpLfghb To: header-people at mit-mc 1. Please note that my secretary is not human. It is (obviously) a machine. 2. Wouldn't it simplify the world if there were a standard for generating message-id's without having to go through complicated algorithms that would have to exist in all reading and sending programs. 3. anyway, how is the sender supposed to know that it is sending a message for which the id will be ambiguouis and result in the letter being automatically discarded. Obviously you consider the human originated mail to be discardable junk. 4. Agree that pathnames obey principle of parsing the known part and just passing the rest on to the next level. 5. Seeing examples of foreign use of programming languages, one can expect the keywords of the mailsystem to be kept in English. It is likely that French will be a special case and the French words may be accepted as alternates (particularly in Quebec). 6. The FTP and envelope ideas go around and around and are basically reasonable. However, in keeping with the principle of least change to existing cruft, you can, if you wish consider the hairy header to be simply part of the ftp or envelope protocols that leaked through. That is basically what is meant by the abstract representation view. Just because it is part of the same ascii string as the rest of the letter does not mean it need be considered as such.  Date: 2 SEP 1977 0346-EDT From: DLW at MIT-AI (Daniel L. Weinreb) To: HEADER-PEOPLE at MIT-MC as I keep saying, that little suggestion I made about a trivial header parser would solve this messaged ID problem. We are all spending much too much of our time on this one silly issue about "I want those useful fields" versus "I don't want to see those ugly fields", and this trivially solves it. As far as I can see it would make everybody happy, and no one has objected to it as yet. Maybe putting the stuff into FTP is conceptually nicer, but you know as well as I that this network has not even implemented a years-old "new" FTP and the chances that we can convince every host to put in all this mail stuff is negligible.  Date: 3 Sep 1977 0942-PDT From: TVR at SU-AI (Tovar) Subject: One more time, with feeling To: RMF at MIT-MC, Header-people at MIT-MC Construction of local message-IDs I guess I wasn't clear enough about what I was suggesting. I was suggesting that for 98% of message traffic, the message-ID could be calculated by the recieving site, if desired, from the DATE, the FROM, the TO, and the SUBJECT entries. I think that most of us are capable of creating hashing functions, but if you want, you can concatenate these fields. I'm sorry about that junk mail comment as it was definitely out of place. However, I think we can avoid discarding non-duplicate messages using the scheme above (considering the probability of a human sending more than one message per second to the same people with the same subject). If anyone doubts this, they can include the length of the text in their hashing function. Yes, but we can write filtering programs at each site to flush headers... Are you volunteering? I ask that because changes to things like the mail programs are often only done by volunteers. There are objections And I am not the only one. I have also observed that there are a few, good men [/women] fighting for the long headers. But how much support is there for them? I am not suggesting that we abandon all those wonderful fields. I agree that they all have uses, some of the time. I am suggesting that a minimal set be used as a default with the addition of others as requested. Let's not use the full, bloody header for informal communication. One, small request? Could we ask that headers not contain redundant information, like FROM and SENDER as the same person? --- Tovar -------  Date: 3 Sep 1977 1707-PDT From: BH at SU-AI (Brian Harvey) To: header-people at MIT-MC I suggest that the committee issue an official document to the effect that redundant header entries (e.g., equal From and Sender) and message-id not be allowed unless explicitly requested by the sending human being, and that everybody then shut up. This is getting boring. By the way, somewhere in there somebody (I forget who) at Multix sent out a message with a From field not containing his host name, so if I had had a spiffy automatic reply program it wouldn't have found him. A sociological aside: no doubt it is partly the thought of all that important military mail which is causing all this heat. I certainly feel that anything I can do to sabotage the U.S. war machine is a patriotic duty, and I imagine many of the rest of us hackers feel likewise. Or, how dare those outsider warmongers hair up OUR nice simple mail protocol for THEIR nefarious correspondence? Indeed, the argument against putting the header stuff in new FTP commands cuts both ways since mail readers aren't any easier to modify. (Harder in fact since it is much easier for me simply to add a bunch of no-ops to my FTP server than to write a parser for my mail reader. But I don't think anyone would mind seeing those fields in those cases where they really added some information. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 3 September 1977 2232-edt Subject: Missing "At Multics" Message-ID: [MIT-Multics]1.2.BBBJGlgnXNPjjm To: header-people at MIT-MC sorry about that, the local mail sending program attepts to give a shorter header for local mail, but I changed to a network destination after the header was composed. So much for filtering at the source end. I also got Tovar's message twice, but the redundancy was not caught by my receiver do to the lack of message id {please don't reply to that remark, I handle message-id's and would appreciate those sending mail to me to use it}.  Date: 3 Sep 1977 1953-PDT From: MRC at SU-AI (Mark Crispin) Subject: Message ID catching To: Header-People at MIT-MC Just what do you do to prevent two different pieces of mail getting having a message flushed because they happen to have the same message ID? -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 3 September 1977 2258-edt Subject: message id Message-ID: [MIT-Multics]1.2.BBBJGlgpqfCCZL To: mrc at SU-AI, mrc at SU-AI To: header-people at MIT-MC It is with deep embarassement that I answer MRC's letter. The technology exists to generate unique ID's. Why do you think that I generate such an ooxious message id!!! It is better than giving you the number of microseconds since January 1, 1901 GMT in decimal. An the host name uniquizes the ID so that another host won't be able to generate the same one. In general a unqiue ID can be generated by concatenating a generator id with a number guaranteed by that genearator to be unique. A simple counter is sufficient. Uniqueness among generator's is guaranteed by a central registry, in this case, the arpa-net host table. Unique id's are a very fundamental concept and all this hassling about message-id's seems to be generated by a lack of appreciation of the universailty (and if I may be permitted a little exageration) the fundamentalness of this concept! I want the message id in the header because it is the basic concept that can be used to manage messages.  Date: 3 Sep 1977 2043-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC RMF ignores totally the problem of malicious hosts, FTP servers, or other network saboteurs mangling the message ID. That is why I do not trust computer programs to censor my mail. -------  Date: 3 Sep 1977 2059-PDT From: Su-Ai at SRI-KL Subject: Message-ID, yet another time To: RMF at AI cc: Header-people at MC Why is it not sufficient to use the DATE, FROM, TO, SUBJECT and a hashing of the message text (i.e. what's after the header) to determine duplications? --- Tovar P.S. I hope you weren't responsible for Multics' Message-ID as they are about the most cretinous looking thing i've seen in years! -------  From: MRC at SU-AI (Mark Crispin) Date: 4 September 1776 0118-edt Subject: Malicious? Who me? Message-ID: [SU-AI]1.2.BBBJGlhFjQbXbH To: header-people at MIT-MC A Sail/ITS person really claiming to care and/or cope with malicious users.? So what?  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 0124-edt Subject: apologies Message-ID: [MIT-Multics]1.2.BBBJGlhGCMzLxk To: header-people at MIT-MC I apologize to those to whom I have just sent some junk mail and am tempted in the future to use a more restricted list for such "proof by scenario"s and also apologize for giving in to temptation and frustration.  Date: 3 Sep 1977 2224-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC [MRC - I did not send this message. This message is a a clear example of the sort of forgery that I am talking about. Since from the crufty characteristics of the header it is obviously from Multics, it is obvious who the child was that sent it.] 03-Sep-77 2219 FTP: MRC at SU-AI (Mark Crispin) Malicious? Who me? From: MRC at SU-AI (Mark Crispin) Date: 4 September 1776 0118-edt Subject: Malicious? Who me? Message-ID: [SU-AI]1.2.BBBJGlhFjQbXbH To: header-people at MIT-MC A Sail/ITS person really claiming to care and/or cope with malicious users.? So what? -------  Sender: Frankston at MIT-Multics (Robert M.Frankston) Via: The playground. Date: 4 September 1977 0131-edt Subject: Lesson for today Message-ID: [MIT-Multics]1.2.BBBJGlhGWMnHkP To: header-people at MIT-MC All I was trying to show was that your comment on maliciousness was totally irrelevent (sp?) to the discussion of message id's.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 0123-edt To: header-people at MIT-MC Letter 3  Date: 3 Sep 1977 2238-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC 03-Sep-77 2223 FTP: Frankston at MIT-Multics (Robert M. Frankston) apologies I apologize to those to whom I have just sent some junk mail [MRC - Your apology is NOT accepted. I think you have adequately demonstrated, between you and "Army boots", that you are totally intolerant of any opinions other than your own. Your only point is "If I don't get my own way I am going to call the people who disagree with me nasty names and send garbage mail and then accuse them of doing that to confuse them more." I have gotten to the point where I almost do not care any more. ARPAnet mail is soon going to be useless and worse than useless, and eventually nobody is going to use it. It is a shame; since mailing was once a useful facility. I guess I'll have to roll back to US mail, since my attempt to establish a private mail protocol met in evident failure.] ...apologize for giving :n to temptation and frustration. [MRC - I was on the verge of sending a very nasty reply to one of your earlier messages but thought better of it since all you would do is send a computer equivalent of giving the finger. In your world, it is perfectly alright to send as many nasty things as you want without respect to other's opinions and feelings, but you forbid others to have their own thoughts. This is a classic case of bureaucratitis.] -------  Date: 4 SEP 1977 0144-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I think the idea that the message ID DEFAULTS to (STRING-APPEND sender date time hostname) if there is no message-ID field is a good one. Mail senders could omit the explicit message-ID field when they were sure that the default one would be unique. Any program that was afraid it would send messages so fast that they would have identical default message IDs could either determine when that happened and give the nearly simultaneous messages explicit IDs, or just put explicit IDs in all messages it sends. But a human sending mail will know that the default is good enough, and not put in an explicit field. I do not believe that RMF has any legitimate reason to object to this. If his mail reader simply figures out the default message ID when there is no explicit field, it will provide him with just as much service with this scheme as it now does with mandatory message IDs. And 99% of all messages would cease to have one field that USUALLY conveys no added information. In fact, rather than exhorting us all to send message ID fields, RMF should just implement this feature in his own mail reader and then he will have the benefit of message IDs even in messages we continue to send which lack the field. I am sure he would obtain much more satisfaction this way than he will from his exhortations. RMF can safely implement this on his own because there is no reason for us to standardize on exactly HOW the default message ID is built out of the sender, date, time and host name, as long as a given host always does it the same way and never loses any of the information, and never considers an explicit message ID to match an implicit one.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 0123-edt To: header-people at MIT-MC Letter 2  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 0123-edt Message-ID: [MIT-Multics]1.2.BBBJGlhFxzGdlN To: header-people at MIT-MC Letter 1  Date: 4 SEP 1977 0405-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC So what do people think of KLH's new formulation of 724 syntax? Has everyone read it? I myself think it is a vast improvement over the BNF.  Date: 4 SEP 1977 1202-EDT From: MOON at MIT-MC (David A. Moon) Subject: Congratulations to Mark and Bob for solving the alleged "header problem" To: HEADER-PEOPLE at MIT-MC The problem of large headers consisting of mostly useless information, followed by 2 lines of useful text, has been replaced by the problem of mailboxes consisting of large numbers of completely useless messages, followed by 2 messages of interest. I hope this isn't going to be permanent.  Date: 4 SEP 1977 1106-PDT Sender: DCROCKER at USC-ISI Subject: Revised 724 syntax representation From: DCROCKER at USC-ISI To: Header-People at MIT-MC Message-ID: <[USC-ISI] 4-SEP-77 11:06:25.DCROCKER> This is not official -- little I ever say is -- but I believe we will use KLH's suggestion, rather than pure BNF, for the final form of the mail syntax specification. Ken, I'd like to enthusiastically thank you for offering it. In the early days of our work, I had been tempted to suggest an improved notation, but gave in to our reactionary tendency to "keep things simple". In general, the public is only familiar (at some level) with bnf, and not with improved versions of it. And I do not think that an augmented bnf solves all the problems. It is still quite easy to write convoluted and virtually incomprehensible rules; e.g., with too much parenthisized nesting. Also, I believe we should retain the lexical analyzer as distinct from the main syntax. The construct appears to be well- intrenched in the language-processing world (I sampled three Introduction-to-Compilers books.) and I believe it makes the primary syntax much cleaner. Dave. -------  Date: 4 Sep 1977 1455-EDT From: PK01 at CMU-10A (Phil Karlton) Reply-To: Header-People at MIT-MC Subject: The last week's mail To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 4 Sep 1977 14:55:38 Philip Karlton I want to make a couple of comments about all the mail I have received over the past week. (Yes, it was quite a shock to have to actually read all that mail after being camping in the quiet of the mountains.) I am another person who likes Ken's new formulation of 724 syntax. Please, can everyone refrain from name calling for a while? I must admit that I am one of those people who do not mind the long headers. There is information in them sometimes and I have found that I can ignore the lines I have no interest in. This is in preface to my plea for people to please address themselves to the issue which we should be discussing: the explicit requirements and suggestions of 724. I would like to point out that at least one line of header can be eliminated from CMU sites when RFC-724 is accepted. Currently there are mail reading programs (at least I have been told so) that look only for the "Sender" field and others that only look for a "From" field. Both of the mail generating programs here at CMU generate both of these lines to try to please all the mail reading programs. The message-id was added because we were asked to add it. It just does not take that long to have that line typed out and for a person to ignore it. Please do not forget DCrocker's message about how little 724 really requires. Are the "short-header" people advocating removing the optional header lines from all mail? Do the "long-header" people want to make message-id's a requirement for all mail? Would it be a good idea if 724 gave more hints on when certain fields would be a good idea or when they should be omitted? Should all mail reading programs give the sender the opportunity to edit the headers at will? Including allowing the sender to suppress the date field? I want to see what people think should be changed about 724 before it is accepted as a network standard. I have rambled long enough. Phil Karlton -------  Date: 4 SEP 1977 1505-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC RMF has recently adopted my suggestion of generating a default message ID from the sender, date-time, and host name (and also the subject). I think this means that we have an effective concensus on the issue: it should be "standard" that, when there is no explicit message-ID field, there is a default message ID which is composed of the sender and date fields, in some standard way. This provides all the utility of explicit message-ID fields for those who have a use for them, without burdening others. It should be required that an explicit message ID appear whenever there is doubt that the default one will serve to identify the message uniquely. However, RMF pointed out a problem in that the date-time in most network mail includes only the minute, not the second. I agree that a human, even, might accidentally send two messages within a minute. Since intra-AIMLMC mail includes the second, I had assumes wrongly that network mail did too. This problem could be solved by including the second in the time field. Of course, to the human reader that would usually be uninteresting and therefore garbage. But if we don't include it, then those who benefit from message IDs have some cause for wanting explicit ones, and those are an even larger amount of garbage. I would think that putting the second in the time is better than having to put in an explicit message ID. What do you think?  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 1910-edt Subject: correction Message-ID: [MIT-Multics]1.2.BBBJGljzdbQPgb To: header-people at MIT-MC Though RMS points out that I have modified my program to generate a message-id substitute, this was done under protest and at the risk of losing multiple letters sent within the same interval. While I won't go so far as to say that a message-id should be reuired, I do feel that a system that does not provide them is putting the burden of making sure that two message don't happen to look similar and threby be discarded, on the user when the task should be performed by the system. I confess to have gotten way off from RFC 724 central issues, but do give in to temptations to duel.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 1927-edt Subject: and on and on Classification: useless cruft Message-ID: [MIT-Multics]1.2.BBBJGlkBcxclFz To: header-people at MIT-MC Oh yeah, I hate to keep reminding people but machines do compose and send messages on their own, eaisily more than one a second. ok now? {this was in reply to an internal communication from RMS who refuses to generate message-id's because he personally doesn't send more than one a second}  RMS@MIT-AI 09/04/77 19:35:34 I am sorry to have to bother all of you with this. I sent my last message to RMF only because I thought I had made my point clearly enough in Header-peope already. But since RMF is still barfing about the fact that programs can send messages faster than once a second, I wish to point out once again that THAT is no reason why a message sent by ME, who can't send more than one message per second, ought to have a message ID. Only a message sent by a program which thinks it might send more than one message per second needs to have an explicit message ID.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 2001-edt Subject: army boots Message-ID: [MIT-Multics]1.2.BBBJGlkDWwGnKz To: header-people at MIT-MC They'd be your messages I lose.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 2001-edt Subject: ignore last letter Message-ID: [MIT-Multics]1.2.BBBJGlkDZFqgKG To: header-people at MIT-MC It was meant for RMS personally, no need to bother all you good people with some inhouse cursing.  Date: 4 Sep 1977 1722-PDT From: Klh at SRI-KL Subject: Review and Preview To: Header-People at MC I want to thank Phil for sending that message, since it allows me to cut the length of mine considerably. I will, however, repeat one key sentence: "Please do not forget Dcrocker's message about how little 724 really requires". All his questions are good ones. And there is one thing I need to add weight to. I admit to having waxed fanatical myself on occassion, but the recent exchanges have gotten somewhat out of hand; it is time to bring them back. I ask that people not respond to seemingly provocative or insulting messages, if indeed there is a reason for them, by sending similar ones. This serves no useful purpose and damages all participants involved, as well as lowering the credibility of Header-People in general to the point where no one will pay serious attention to the genuinely valid points we raise. In a succeeding message I will include the complete list of Header-People; this seems appropriate for a number of reasons. To those people who have asked: Yes, I do have a list of specific 724 comments and suggestions, including the internetwork address ideas. It is almost finished; I hope to send it before Tuesday. To those who may have lost their pointer to the new syntax: it can be found on MIT-MC as "KLH;NEWSYN >" and is slightly different from the original. For one thing, 724 specifies "Reply-To" whereas I had it as "Reply To". No one seems to have caught that, but I changed it back; I hope there are no other variances from 724. Once it is agreed that the representation is correct, we can discuss improvements to the syntax. --Ken -------  Date: 4 SEP 1977 2041-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: List of Header-People To: Header-People at MIT-MC Here is the complete Header-People mailing list, as inserted from the file KSC;HEADER PEOPLE on MIT-MC. The intent in mailing it is not to distribute copies, but to show exactly what the group's composition is. The original purpose when I formed the group was to collect all people directly involved in actual implementation of mail-related systems, to encourage quick resolution of inter-site confusions. I also felt that such people would have the best ideas of the ease or difficulty of implementing suggested features, and could truly stand behind any promises of action. Be as that may. Here's the list: -------------------- ; This is the HEADER-PEOPLE mailing list, with comments ; which may or may not be accurate. (HEADER-MINS @MC) ; Record of messages -> File "KSC;HEADER MINS" (DM-HEADER-PEOPLE @DM) ; COMSYS/MSGDMS (PDL, JFH, MSB) (JHAVERTY @BBN-E) ; 'JFH@DM, TIRED OF GETTING MSGS THIRD! HAND" (KLH @AI)(MOON @MC)(DLW @AI) ; COMSAT (RMS @AI)(CBFX @MC) ; RMAIL, and that is cbfX dammit, not CBF. (Postel @ISIB) ; Protocols (Stefferud @Multics) ; MSGGROUP gateway (actually Stefferud@ISI) (Farber @ISI) ; CAHCOM chairman (Message Services (sub)Committee) (Farber @SRI-KL) ; wants two copies (Henderson @BBN-A) ; HERMES, MSrvComm (Vittal @BBN-A) ; MSG, MSrvComm ;(French @BBN-A) ; SNDMSG bug fixer (DCrocker @ISI) ; MSrvComm (Pogran @Multics) ; Multics mail, MSrvComm (ME @SAIL) (BH @SAIL) ; SAIL mail (Geoff @SRI-AI) ; SRI-AI mail, FTP (AVS @LONDON) ; Illegal mail (CRD @MC) ; Multics Read_mail (Bajzek @CMUB) ; CMU mail, FTP (Gumpertz @CMUA) ; CMU C.mmp (PK01 @CMUA) ; CMU RDMAIL (Philip Karlton) (Brian.Reid @CMUA) ; Interested CMU person (AWH @AMES-67) ; AMES-67 mail (Greep @RAND-UNIX) ; UNIX mail (Mike @RAND-UNIX) ; He asked for it! ;(Mark @UCLA-ATS) ; " ----- commented out 3/17/77 by dam. host seems busted. (tvr @MIT-AI) ; " (actually tovar@UCB) (Haines @LL) ; Lincoln mail, FTP (Robertson @RUTGERS) ; Mail on Rutgers, Harv, NBS (JWALKER @BBN-C) ; Interested NBS person (Steckel @HARV-10) ; HARV contact (Frankston @MIT-Multics) ; Misc Hacking esp. on Multics (header-discussion @MIT-Multics) ; For general perusal (EAKX @MC) ; random observer ;(RICART @DEC-Marlboro) ; NIH, non-Arpanet Tops-10 mail systems. (NIH @NBS-10) ; Glenn Ricart, non-Arpanet Tops-10 mail systems. (Feinler @SRI-KL) ; NIC (MRC @SAIL) ; DIALnet(definitely), CCA(maybe) mail hacker (GMP @MC) ; Who knows? Someone put him in the wrong list so I moved him here - dam ----------------- As before, if anyone knows of a site/mail system not represented by these people, let me know and I will do my best to track down the right person. --Ken  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 September 1977 2117-edt Subject: CRLFs (in Ken's and maybe RFC 724's syntax) Message-ID: [MIT-Multics]1.2.BBBJGlkJjZZxDG To: header-people at MIT-MC If one wants to include a US Mail address in a header how does one achieve the equivalent of a multiple line address. Some convetion should be established. This is relevent to internetworking since the US Postal system is a very large and important network to be connected to.  Date: 4 Sep 1977 2010-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC I think that having the seconds in network mail is a lesser evil than the message ID. I never advocated flushing the extra information when the extra information really gave more information. However, when the extra header lines either gave no extra information, or when the extra information was of marginal value, I objected. NO EXTRA INFORMATION: Sender: FOO at FOO-SECURITY From: FOO at FOO-SECURITY Message-ID: (containing just date/time/sender info) MARGINAL INFORMATION: Multics-style unique message ID Indication that the mail was a proxy message, ie that it is from FOO but BAR really sent it. Since proxy messages can be faked anyway, unless BAR has an active interest in the message and isn't just a secretary (or, FOO couldn't get a console and borrowed BAR's!!), this is marginal. The NO EXTRA INFORMATION lines, in my opinion, should not be there. The MARGINAL INFORMATION lines, again in my opinion, should be there ONLY if the mail sender SPECIFICALLY instructs the mailer that they should be there; so if they really are marginal it was direct human intervention that added the garbage and not some silly computer program. -- Mark -------  Date: 5 Sep 1977 1253-EDT From: Rick Gumpertz at CMU-10A Subject: header field names To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Sep 1977 12:53:42 Rick Gumpertz Why are there hyphens in Reply-To and such anyway?? Why not use spaces -- the colon is a fine delimiter!!! Why bastardize traditional English usage?? Rick -------  Date: 5 Sep 1977 1343-EDT From: Brian Reid at CMU-10A Subject: RMS's comment on message ID's To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 5 Sep 1977 13:43:56 Brian Reid I don't think that it means much to say, "It [the message id] should be required whenever there is doubt that the default one will serve to identify the message uniquely." Requirements predicated on doubt are not very enforceable, and if it's not enforceable, it really shouldn't be a requirement. -------  Date: 5 SEP 1977 1305-PDT Sender: DCROCKER at USC-ISI Subject: Re: CRLFs (in Ken's and maybe RFC 724's syntax) From: DCROCKER at USC-ISI To: Frankston at MIT-MULTICS Cc: header-people at MIT-MC Message-ID: <[USC-ISI] 5-SEP-77 13:05:19.DCROCKER> In-Reply-To: [MIT-Multics]1.2.BBBJGlkJjZZxDG Comma is the standard replacement character for newline, when forced to put addresses on a single line. Dave. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 5 September 1977 1645-edt Subject: comma as newline. Message-ID: [MIT-Multics]1.2.BBBJGlmKzpcGjz To: header-people at MIT-MC By "comma is standard replacement for newline", I take it that this is a usage standard as opposed to a technical standard. My porsonal preference is for semi-colon since comma can be a legitimate component of an address. For internetworking an extended quoting convention like used in some programming languages would be useful. For example the "J~" character within a quoted string can take the next character as a name of a chaacter such as ~n meaning newline. If the other net is nonascii (for example, EBDIC or US Post office) other conventions would be useful such as ~d for a degree sign. We don't have to resolve that issu in detail now, though accepting the concept of such an escape convention and maybe the designation of a character would be useful in providing for future expansion. I realize that an escape character within a quoted string has the effect of making a quoted string require parsing. The alternative is to require that such escapes be coutside of quotes. This means that a quoted string is not an atomic unit,but can be concatenated to form an atomic unit. Just checked the syntax again (KLH's) an noticed that doubling quotes is permitted in quoted strings. Perhaps then using ~ is not in violation of the spirit of quoting and allowing ~" might be cleaner than pl1's "".  From: Pogran.CompNet at MIT-Multics Date: 09/05/77 1822-edt Subject: Re: Brian's sociological aside To: BH at SU-AI cc: Header-People at MIT-MC Brian, I guess the ARPANET system hacker community has always been a little schizophrenic with respect to the fact that the money for our system hacking comes from D. o. D. But it DOES, and they're going to be unhappy if what is produced isn't suitable for them. The "ARPANET Message Service" is of sufficiently high visibility that it will be pretty damned OBVIOUS if what is produced isn't suitable for "THEIR nefarious corrspondence". Maybe we should apply to NSF for money to develop "OUR nice simple mail protocol"? Meanwhile, it's D. o. D.'s football. Regards, Ken  Date: 6 Sep 1977 0850-PDT From: TVR at SU-AI (Tovar) Subject: General comments To: Header-people at MIT-MC I think if you look carefully at 724, a short header (i.e. just FROM and DATE) is quite acceptable and correspond fairly well, except in subtle details, with what most sites send out as a header. In another message, I have included some specific changes to 724 which I hope will satisfy both the short and long header advocates. What I think we are quarreling about is what will be RECOMMENDED as a DEFAULT header. It is an implementation decision, that is, what J. Random User gets when s/he sends you a simple message. One of the questions crucial to some of us is how to detect duplicate messages. It was generally thought for a while that Message-ID's were required to do that. Now, the addition of a field containing seconds will handle 98% of the mail with a burden of only three characters instead of a whole line. The second question is how to get both a FORMAL and an INFORMAL header out of the same system. Now, someone suggested using HERMES for that purpose, but not all of us are so fortunate, especially those using 16 bits machines! Perhaps we could RECOMMEND two forms of header, a formal header and an informal header. The user could choose when the message was send (either by using a switch, being asked and/or by remembering the preferences of this user from a file or other form of permanent memory. A serious question seems to rearing its ugly head during this discussion: that is, message authentication. It appears that at least twice in the past quarter, a person or person(s) have sent messages using another name in a personally damaging fashion. I think that this is a grave matter. I would hate to see the message system burdened with the new authentication technology. But if this keeps up, I think we should give it serious consideration. --- Tovar -------  Date: 6 Sep 1977 0901-PDT From: TVR at SU-AI (Tovar) Subject: Specific suggestions for modifying 724. To: Header-people at MIT-MC I think the following tightening of 724 could make the short header people happy. - - - - Page 21, 2) Sender: Paragraph 1, replace word 'need' with 'should'. Page 21, 2) Sender: Paragraph 1, insert following text after first sentence: The intent of this field should be to indicate the person actually responsible for sending this message when it is not that mentioned in the 'From: ' field; Or to indicate who among a jointly authored message had actually sent it. Page 21, 3) Reply-to: Append to paragraph 2 The 'Reply-to' field should not be the same as the 'From: ' field unless it is to designate a different machine address. Page 23, a. Message-Id: Add new paragraph at after first: It is hoped that this will only be generated when messages would be difficult to distinguish in other manners. In Appendix X, there is an algorithm for generating a message-ID at the recieving end for handling rejection of duplicate message. Appendix X is not written, but would describe two algorithms for generating a message-ID at the recieving end. The first algorithm would describe a method whereby the FROM, SUBJECT, DATE and TO fields would be concatenated to form a simple message-ID. The second algorithm would describe a message for using the same fields plus a means of checksuming the message to produce a complicated but very reliable means of detecting duplications. - - - - The effect of these changes would be remove redundancies from the header and will typically give a four line header. It does not add or delete anything meaningful from the header, but it does request that mail programs should not make headers with fields of no information value. Respectfully, Tovar -------  Date: 6 SEP 1977 1758-EDT From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-MC 1) Checksumming a message can be a screw when a host changes the contents of the message. For example, AIMLMC will probably change any ^_ character encountered into an ^ and a _. This is because ^_ is used to separate messages in our mail files. Other systems may add some extra data to the front of the message (such as whether it has been read yet) and then gradually mung it. The checksum of the message might change over time. I think that rejection of duplicates can work just fine without any checksumming, so we might as well just forget about it. 2) A message ID can be used for more things than just rejection of duplicate messages. For example, it can be used to refer to a message you are replying to or a previous message you sent. So we need not just a way to detect duplicate messages with no explicit message ID fields, but an actual algorithm to construct a default message ID out of the other fields. 3) Point 2 also argues that the default message ID should not be so long that one would be ashamed to mention it. Thus, it should not include more than the bare minimum of information necessary to disambiguate messages sent by humans actually typing on their terminals. Only the date-time and From should be used. (I can't remember 724 well enough to remember whether From is really what I mean. It should be something that identifies the sender and ALWAYS contains a host name. Perhaps it should use the Sender if there is one, otherwise the From). 4) Does 724 allow the seconds to be included in the time of day? How should they look? Without the seconds, the time of day will not be enough to disambiguate the message.  Date: 6 SEP 1977 1542-PDT Sender: DCROCKER at USC-ISI From: DCROCKER at USC-ISI To: header-people at MIT-MC Message-ID: <[USC-ISI] 6-SEP-77 15:42:13.DCROCKER> In-Reply-To: Your message of SEPTEMBER 6, 1977 The final form of 724 will probably allow (but not require) seconds and will not provide for sub-seconds. Dave. -------  Date: 6 SEP 1977 2251-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: Warning... next message is moby... To: HEADER-PEOPLE at MIT-MC I've decided to send my comments, approx 9 printed pages, via mail. I hope this isn't a mistake; for those whom it is, you can find a separate file on MIT-MC as KLH;COMMEN > (No password necessary) and can FTP that, ignoring my next message. Not as early as I had hoped, but at least it's still Tuesday...  Date: 6 SEP 1977 2257-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: Here 'tis. To: HEADER-PEOPLE at MIT-MC Lead-in In the following paragraphs I will be moving from the very specific to the very general; usually, to each problem, a solution or two will be suggested -- if not, most likely I ran out of think time, since I do try to think about other ways to do things. (One thing that annoys me about some complaints I see is the complete lack of suggested alternatives...). To summarize, most of my unease with the current 724 lies with addressee syntax and the lack of any compatible way to bring 724 up, in the absence of syntax versions. And one other note before embarking. I am slightly depressed that many of the things I am citing here were cited, in much the same words, in the reactions to the original first-draft 724. This time, it would be nice to have the explanations or replies that we never had to them. Trivia There are various little things wrong with 724 as it is, much of which others have already pointed out - stuff like typos (zero of more), inconsistent element names ( vs , vs ), and other less glaring oversights which seem to indicate that even the authors tend to lose track of the BNF. How else can you explain a message-ID in the examples which has neither of the required angle brackets surrounding it? My hope is that with a better representation (such as previously suggested), these will be lessened. In any case, all easily fixed. Little Stuff [L1] Put day-of-week into comment I suggest that the day-of-week (Monday, Tues, etc) be flushed as an explicit item, and allowed to exist as a comment if so desired. It (a) makes the parsing slightly hairier, (b) provides more opportunities for error (are mail-readers supposed to check it?), and (c) furnishes no information useful to the machine, since the day-of-week can be trivially determined from the date itself. Hence that field would never be used except by a human, which is exactly what comments are for... finally, if the reader explicitly wanted to see it, it would certainly be better done by parsing the date and deriving it thereby, so as to provide it for ALL headers, not just the ones it happens to come with; and if this is done, what good is having it as an explicit field? [L2] Date format What is the currently proposed revision to this, or is ANSI format excluded, or what? While parsers should probably continue to understand slash-day format, does anyone object to a strong recommendation that it not be used? [L3] Recommendations about text 724 mentions on page 13 that a CR must be followed by either LF or NULL. This is all right for headers, but not for message text; once the message text starts, I don't think any restrictions whatsoever should be put on the contents. It is OK to make recommendations here (as for tabs, length of a line, etc), but only that and nothing more. Incidentally, how long can a line be before folding is desirable? Page 14 doesn't say; how about 71 columns? [L4] Improvement to "From" It seems to me that the originator hair can be further simplified if you specify that it is OK to have multiple addresses in a "From:", and NOT have a "Sender:" field, provided that the FIRST machine address in the "From" indicates the sender. This lops off one of the most common cases I can think of, and the syntax then becomes: originator-fields = ("From". ":" mach-addr *(.",". address) CRLF ["Sender". ":" host-phrase CRLF] ; Only if not = 1st mach-addr ["Reply-To".":" mach-addr *(.",". address) CRLF]) / ("From". ":" 1#address CRLF ; Can only use random addr "Sender". ":" host-phrase CRLF ; if using BOTH other fields "Reply-To". ":" mach-addr *(.",". address) CRLF) Naturally, it should be recommended that "Sender" be used only when the sender is not in the "From"; and putting the sender's address in other but FIRST place in the "From" would be very bad etiquette, as it would then necessitate an explicit "Sender" field. [L5] Bug in addressee syntax? It is possible to have a null group, eg "Group: ;" -- shouldn't the definition require at least one address inside the group, or is this deliberate? If not, #address in the current definition should be changed to 1#address. My general comments about groups are in [A1]. [L6] Multiples There really should be some discussion about the meanings of multiply occurring fields; either there should be a recognized interpretation, or a field should be unique. For example, "Message ID" should be unique, whereas "To" is cumulative; all the "To"s taken together specify the same thing as a single long "To". Suggest that the unique fields be "Subject", "Date", "Sender", and "Message-ID". Or it could be required that long fields always be hacked with continuation lines, rather than breaking them into separate fields, so that (nearly?) everything is unique. [L7] Ordering While there should not be a required ordering for the fields, there should be some strong recommendations about a preferred order. For example, it would be good if "Date" and "From" in that order were the first two fields in a header; maintaining some consistency makes life easier for people without hairy programs to shuffle the fields around. See also the section about DLW's scheme ("Ease of Filtering"), in which fields would be sorted differently. Not-so-little stuff [N1] Unfolding There is a general problem with "unfolding" when you consider a text-line, quoted-string, or msgid. This is how to deal with the leading whitespace on the next line; the CRLF is obviously thrown away, but what about the leading spaces? Do you compress them all into one representative SP, or ignore all but the first character of the whitespace (or the last), or simply slurp them up? The examples seem to be fond of column justification, which is going to make a quoted string look pretty gross if unfolded without any compression. I realize that there seems to be a definite algorithm for this, but my confusion engenders the suggestion: make it very clear what the unfolded result should look like when dealing with quoted strings - flushing only the CRLF is OK, except that Dave Crocker made some comments that imply one can, in fact, have quoted CRLF's. Please explain further? Dave Moon has suggested that the best scheme may be to say that all indentation is removed (whether or not in a quoted string) and all CRLF's are retained, then in the syntax CRLF is generally to be treated the same as space, except that CRLF ought not be allowed inside addresses (only after the comma, if an address list is folded). It would certainly be nice to allow quoted CRLF's, but these need to be very distinct from CRLF's starting a field name. Perhaps with more explanation from the inventors of folding/quoted strings, all will be made clear. [N2] Quote character R. Frankston and D. Moon have already suggested that some quote character be used for purposes of simplifying some quoting and escape problems. This seems reasonable, and could certainly be used in conjunction with the quoted-string syntax; not to replace it, but augment it. This would firstly solve the problem of including ")" in a comment (consider the example (Re use of ")" in comments)), as well as that of quoting CRLF's, since it is an extremely simple check and imposes very little on any scanner. I expect there would be more argument about the choice of character than the idea of using one; but IS there anyone who dislikes it? [N3] Message-ID strings etc [N3a] Canonicality One problem with the msgid string is that when you want to compare it to another msgid (checking for identical messages), then what canonical form should you convert it into? Any sort of conversion is going to be a pain; for example, there are several different ways to specify an equivalent host. I would suggest either that everything between the angle-brackets be treated as a quoted string (although maintaining a host-phrase syntax), or doing away with the use of host-phrase in this situation, and specifying something much more rigorous that lends itself to conversion-less scanning. Either way, a criteria for canonicality is needed. [N3b] Forming ID by concatenation Recently, people have come up with a fairly specific scheme for avoiding the use of explicit message ID's in most cases. It is truly remarkable how much of this has been said before; nearly every one of the points in [N3] has been brought up since Stefferud first suggested this idea last October. Others (RMS, Tovar, Macrak, etc) have had the same ideas independently. One problem with it is that it IS possible to have different messages with identical headers. In fact, it is possible right now for HERMES msg-ID's to be identical, in spite of including the seconds field. This is because more than one person on TENEX may be using the same login name, and it is well within the realm of possibility that two people, sharing an account, will reply to a message simultaneously. However, the "From" should distinguish them, and in this sense the scheme Tovar, RMS, etc propose is actually better! Anyway, I rather suspect that infinitely more messages will be lost from disk crashes than would ever vanish in this curious fashion. [N3c] Forwarding problems (some of) There is a somewhat more obscure problem that rises when one considers the use of ID's to prevent forwarding loops, rather than to eliminate duplicates in a mailbox. Namely, it is wasteful to compare the whole of an incoming message with previously sent ones, so some ID, however concocted, is necessary; but if the other site(s) MODIFY the header before forwarding the message back, an ID not based on an explicitly preserved message ID could easily NOT be matched, and the loop would continue. RMF pointed this out in October (10/20/76 1049-edt) also. A "Forwarded-from" (or to, or by, etc) scheme could actually hurt, since it does not prevent duplicates although it can be used to stop a loop, and sticking this field in the header implies that the header is re-generated; parsing and re-writing a header is unlikely to produce exactly the same thing, so that a message ID formed from header fields rather than a explicitly furnished one is likely to be different in each site it gets crunched through. I suggest that more specifics be settled -- for example, what should the format be for a time that includes seconds? Who will be the first to write Appendix X describing two schemes? And don't we need to haggle a little more on how automatic message forwarding should work? (One interesting observation: Suppose FOO forwards to BAR which forwards back to FOO. The message will disappear entirely without being sent anyplace.) ----------------------------------------------------------------------- ADDRESSES ----------------------------------------------------------------------- General The syntax of addresses, as it currently stands, is not really very good; the problem is difficult, but it does seem as if 724's is not the best scheme possible. Some points follow; I apologize in advance for their somewhat incoherent presentation, as I lacked the time to propose unified and consistent alternatives. [A1] Group names It's not clear what the intent of group names is. For all practical purposes they seem to be ignored, in which case they might be put into comments, or expressed by indentation levels. I would like some elaboration on what their intended use is, particularly since they tie up two special characters. Might one not, rather than saying Group: foo@here, bar@there; Use instead: (Group:) foo@here, bar@there (;) Or another scheme is to use brackets, such as Group or or even [group: Group ]. I haven't completely thought out the alternatives, since these would need to be part of a more general scheme which takes care of mach-addr, etc. [A2] File pathnames The use of "Fcc" seems like a crock; all it is doing is to distinguish between a file which contains messages and a file which contains a list of addresses. This is much better done with address types, discussed below. The provision for a list of "alternative" filenames doesn't make a whole lot of sense - are all these files assumed to be identical? If not, why pick only one, presumably at random? If alternatives appear in a "Fcc", does that mean the message got sent to just one of the files, guess which one? Are they serious about retrieving and processing file names?? [A3] Responsibility for generated addresses This was brought up by Dave Moon, but was somewhat limited both originally and in Dave Crocker's reply. A more appropriate statement would be that "when a program or file specifies a in which refers to the local host (where the program is running or the file resides), the MUST be an valid address at that host, which its FTP server will accept." This seems to express the basic idea and still cover all the bases, whether the address is in a "To:" or "From:" or whatever. (except for one qualification Moon adds: Should acceptability mean that the form of the name, rather than the name itself, is OK for the FTP server? Mailboxes do go away. Perhaps something like "at that point in time" should be added. Ugh, legalese.) [A4] Addressee files I think there should be equal mention given to an alternative scheme of mailing to addresses in such files. 724 talks about FTP'ing over the file and then scanning it, but there is another method which is more convenient - give the pathname a type of "indirect file" or "@file", which when specified as a recipient will cause the receiving site to automatically distribute the message to everyone in the file. Since this type of address will not be put in a header unless the generating site is in fact able to handle such things, there is no implied requirement to support this. [A5] Nesting and breaking - avoidance of quoting It seems to me that quite a bit of elegance can be gained by adopting a long-ago suggestion of RMS that open-brackets seen in the scan of an atom should gobble everything up to their matching close-brackets, with one addition: close-brackets seen which don't match the current level are legal and included in the text. (Brackets: [],{},<>. Not sure about parens.) This is an interesting form of "quoting", as the brackets themselves are included in the text and are not delimiters, of themselves; most filenames then need no quoting: foobar.txt[13,13] - Tops-10; the "," is safely within brackets. foo>bar>whatever - Multics; the ">"s are ok. [foo;bar >] - common ITS file reference. With the addition of a rule that ">", ";" and ":" not cause a break - the actual breaking for mach-addrs and the like would be done by whitespace or a comma - one can also have the very common Tenex filenames without pain, as in: bar.txt;23, which is clearly different from , as mach-addrs. Note that ":" is used in an odd way for :File: and Group: -- these uses might well be done differently. See [A1] and address types. [A6] If you want to know... There is an interesting section in the new Arpanet Directory (not yet distributed) which lists mailboxes alphabetically. A programmed search through this data base reveals that currently the only special characters which appear to be used are "." by Multics addresses, and ";", "(", and ")" by UCLA-CCN mailboxes (eg "FOO;BIN(0836)@UCLA-CCN") [A7] Parsing an address Looking over the rather hairy forms possible, it seems to me that if anyone wants to do some people a big favor, an appendix could be added to 724 suggesting the best way to parse addresses. Address Types I want to suggest, again, that explicit provision be made for giving addresses a "type", allowing new types to be created just like new header fields. This will allow elimination of "Fcc" since that is just a particular type of address. AND US mail addresses can be processed specifically as such, rather than as random text which merely might be. Again, I have not had sufficient time to formulate this as well as it should be. 724 has a hint of "typing" in it by means of double ":"s; that is, ":File: ", which can be generalized to ":"":" -- this is almost exactly what I suggested before, using ":" instead of "*" -- but I think now that something which uses brackets might be preferable. (Curly brackets, since these are so little used - I just hope not TOO little used...): :File: foo>bar>far at Multix {File foo>bar>far} at Multix By means of the nesting convention suggested in [A5], no special parser will be needed, and addresses would, I think, be somewhat clearer. For example, the type is clearly associated with the name, and the host is comfortably separate. I am quite strongly against the idea of providing "alternates" in a as 724 suggests, not only because of previously voiced criticisms but because the type is not well associated with the alternate host-phrases. Moreover, again due to the nesting convention, it is very painless to include several things inside the brackets; you might want to include not only the file/rcpt name, but some additional info which depends on the specific type. Typed names would need to be distinguished from untyped names by virtue of the initial bracket char (here, "{") -- but for purists, "Name" can be the "type" of the latter; "Foo" = "{Name Foo}". Whatever scheme is used, the concept of typing in general does need some expostulation in 724. Internet addressing Basically, I don't think a quick resolution of this issue is at hand, and I would not like the lack of same to hold up implementation of the rest of the standard. It would be nice if 724 had everything, but we shouldn't delay it several more months just to make sure that internetwork addressing is correctly handled. The reason I am somewhat dubious is that it's simply not clear what should actually happen with such addresses. Both suggestions, (using "/" and "@") are reasonable enough, but I have a nagging feeling that something is still missing -- allow me to elaborate. It certainly sounds nice and elegant to have a host "pass on" an internet address minus its own particular part of it; but exactly HOW is this to be done? Let's assume that something like "Foo at Bar@Bnet@Host" is given to a mail sending program. Okay, under our current mail transmission scheme, what exactly gets sent to Host? That is, are we talking to Host's FTP server and sending it a string like "Foo" (where's the address?) or "Foo@Bar@Bnet"? If so, does that mean an FTP server will have to do address parsing? One then needs to have quoting, since it is legit to have, say "@" as a character in the actual mailbox name, and so forth -- it might be more general if this is done with address types, such as {Nonlocal }. Then I wonder which program does the forwarding (the FTP server?) and whether a positive acknowledgement is delayed until the message has actually reached its destination, or sent immediately and the message queued if the other network is down (in which case one needs a demon)... It just seems as if actually implementing this will require something considerably different from the current scheme -- more like a structured message protocol, in fact. At which point the precise representation of the address becomes much less important, and we are getting outside of 724. So I suggest not worrying too much about the issue right now, and just providing for quoted-strings as "hostnames", as well as address types; between those two, we should have quite enough flexibility to adapt to whatever future, post-724 discussion brings. ----------------------------------------------------------------------- IMPLEMENTATION ----------------------------------------------------------------------- At the risk of appearing excessively negative, I want to ask if 724 is really the right thing; the trouble is that it tries to introduce new features at the same time it solves old problems, and the amount of change may from some viewpoints be excessive for the amount of benefit. Here are some possible problems with implementation: [I1] Conflict with old schemes There are some new features of 724 which will directly conflict with old ways of parsing messages, and I am sure that we will see both old and new headers in the same mailbox, which the same mail reader will have to parse, as conversion proceeds. It may be that most messages will work, but many of them will certainly not, and I have not seen any notes about a scheme to resolve these conflicts. New FTP and new TELNET at least had different sockets; I, Moon, and JFH jointly argued that we need some way of distinguishing between syntax versions, and some suggestions such as "S:" or an FTP command XHDR were proposed (references/copies provided if requested), but 724 has no trace of these, or indeed anything else. It would be very helpful to know what the authors had in mind, however dimly. [I2] Caution! User interface! 724 claims that it is not intended to dictate user interfaces. However, on page 26, section h, there is an example which seems to indicate that the user in fact types in quite a bit of the 724 syntax; there are other implications lying around which ominously hint at the same thing. It might be best to just admit that 724 in fact WILL have a large effect on what the user sees and types, although probably not on the set of conceptual commands. A more subtle example of lossage can be seen in the case of distribution list files; ITS mail might well want to include such filenames in a "To:", but if anyone actually tries to access them they will find something similar to the Header-People list, in a format which 724 will violently disagree with. I am sure this will confuse people, particularly those making up such files, and there is no immediately obvious solution since using 724's format would place restrictions on current capabilities. General bracketed address typing might, however, achieve a sufficiently close resemblance for existing files to be converted practically. [I3] Ease of filtering There has been a considerable amount of bickering about large headers, which WILL in fact occur despite our compression techniques; it seems that a scheme which makes the "extra" stuff easily filterable will be much more acceptable than one which doesn't. Accordingly I would suggest either or preferably both of two schemes: [1] Adopt DLW's suggestion that all fields other than Date/From/Subject/To be grouped together with appropriate delimiters, so that a very simple printing hack can easily ignore them. One possible way of doing this would be to have them at the beginning of the header, and search for the sequence "Date" (or Date) after which everything would be printed. The only screw would be a (n illegal) message without a date, in which case the scan must be backed up and the message printed completely. [2] Adopt RMF's suggestion that field names be identified and discarded/printed individually, BUT ONLY IF something is done to make it very easy to do such semi-parsing. At the moment, field-name keywords can be separated by whitespace/comments, which is really somewhat unnecessary; I propose that field names be more strictly defined, so that the string between a and the colon matches a template exactly after case conversion. The first four characters should also be unique, for even easier identification. This implies that if a space occurs in a field name (which is fine with me) then there should be only ONE space, not several. Remember that both of these imply that field names must be EASY to find, and folded lines or quoted CRLF's (if any) EASY to ignore. I would even recommend that a basic algorithm for doing this be included in a 724 appendix. This filtering can be done by the FTP server if there is no way to delimit messages in a mail file. To avoid losing anything that might be important, the ignored text could conceivably be stuck into a "garbage" file parallel to the mail file, which the user can examine if necessary and flush occasionally. [I4] One last comment. Achieving a consistent syntax would be nice. But 724 will take a lot of work to fully implement, and will we really be that much better off compared to our current situation? Would the same time that 724 gobbles be better invested in a true mail protocol on a different socket? Jack Haverty's RFC 713 proposes a message data transmssion protocol (MSDTP) which a DM hacker brought up in a afternoon's work -- and indeed the basics are pretty simple and fast. I hesitate to say that 724 should be dumped or trimmed down to introduce NO "new" features not already in use, and time invested instead on MSDTP. Rather, I strongly suggest that items [I1] and [I3] above be given a lot of serious thought; if they can be resolved satisfactorily, I have no qualms about advocating as general a 724 as possible (full speed ahead!), after which those of us who want can continue the investigation into MSDTP-like schemes. Since I think the reassurance of these two points is so valuable to have, I will repeat them: RESOLVE SCHEME/VERSION CONFLICTS (I1) MAKE FILTERING EASY AS POSSIBLE (I3) ------------- --Ken  Date: 7 Sep 1977 0130-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC My set of bad ideas, replying to Ken's. 06-Sep-77 2104 FTP:KLH at MIT-MC (Ken Harrenstien) [L1] Put day-of-week into comment Agreed; although it is somewhat marginal to have it at all. [L2] Date format Suggestion; why not have HUMAN dates rather than computer ones? The Tenex/1050 style dates are oppressive. I suggest that "September 7, 1977" is better than "7-SEP-77". The European-style "7 September, 1977" is alright too, however which way should be agreed upon; since this is the US I would prefer American-style but the majority should rule on this. The simple 9/7/77 which I prefer can't be used, since it would confuse European-style hackers (sigh). In any case, I think we shouldn't be stuck with SIXBIT month names! [L3] Recommendations about text I think there should be no restrictions on text other than agreement between the parties involved. 724 should only make recommendations on what is courteous; for example, lines should be limited to 70 characters for people on inferior consoles, no ASCII character whose graphic cannot be reasonably reproduced on inferior consoles (for example, no grave accents or ITS/SAIL extended ASCII, etc.) and so on. Tabs are a nasty problem since Multics likes 10 character tabs and PDP-10's like 8-character tabs, and I don't know what IBM systems like. I think that if Multics converts their tabs to spaces and incoming net mail tabs to 8-space indentations (I think somebody said that once upon a time) then it should be alright all around; PDP-10's can win without screwing Multics users. To summarize, I don't think there should be any restrictions on the text but that the message sender should be considerate of the message receiver. [L4] Improvement to "From" I agree. I still think that even with proxy messages the Sender: and Reply-To: fields should not be included unless the sender specifically says they should be. This is more an implementation manner; but I think it is worthwhile to state that these fields don't have to be there. If FOO's secretary actually typed the message, I am not interested unless FOO's secretary is to get a copy of the reply. Similarly, if FOO borrows my console to send a message since there are none free, I am not interested in getting replies unless I am specifically involved in the message. [L7] Ordering I see nothing wrong with required ordering. I suggest Date:, From:, Subject:, To:, Sender:, Reply-To, Message-ID, (plus whatever else there is...). The general point is that Date:, From:, and Subject: should be FIRST. This is to make mail reading programs which print the first n lines (usually up to the subject) of a message and then pause (allowing the user to decide whether or not to see the rest of the message) to win. This also makes it easier for people who edit the mail headers in mail they keep in their mail archives to maintain a consistant format. The secondary point is that the Message-ID, if it MUST be there, should be last out of esthetics or something. [N2] Quote character Has this problem actually come up in the real world? Could I be given an example? [N3] Message-ID strings etc I agree with the RMS/Tovar suggestions. Since I do not trust computer programs to delete messages from my mail file without my consent, I don't have the problem of duplicate message ID's. If somebody really wants to have a program to automatically flush messages that appear to be duplicate, Message-ID's don't seem to be enough; I would do some text comparison in the body of the message. 'nuff said. [A2] File pathnames [Are they serious about retrieving and processing file names??] Hope not. [A6] If you want to know... [refering to . ; ( ) being the only special characters that are currently used] I wonder if some of the hairier aspects in 724 will ever be used, not because of non-implementation, but because the case never comes up? I hope there is some thought on this. Internet addressing I agree that this should wait until the other networks start talking to the ARPAnet and their own folklore is established. For networks still in development (such as DIALnet (ta da!)), I think it is only fair that they have a chance to have their own bad ideas instead of having the ARPAnet dictate its bad ideas. DIALnet will have short (possibly one-line), very strictly formed headers. The semantics are unknown at the present times, as only the Host-Host protocol has been "written" in any sense of the word. However, the current theory is that the header (ie, the thing that is actually IN the message) will be minimal, and that hairier information will occur in the protocol, where it can be processed (or ignored) by the mail server. -------  Date: 7 Sep 1977 1427-EDT From: Philip Karlton at CMU-10A Subject: Re: Recent suggestions about From and Sender To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 7 Sep 1977 14:27:22 Philip Karlton In-Reply-To: MRC's message of September 7, 1977 If the user is allowed to edit the From: field then it might become difficult for the sending program to guarantee that the address is a legitimate network address. Is this a real problem?? PK -------  Date: 7 Sep 1977 1434-EDT Subject: Re: Long default Message IDs To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 7 Sep 1977 14:34:37 Philip Karlton In-Reply-To: Stallman's message of September 6, 1977 I agree. The default IDs should be short enough to normally fit on one line with a field name. In addition, the algorithm for generating it should probably strip leading (and trailing) blanks. PK -------  Date: 7 Sep 1977 1139-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC 07-Sep-77 1133 FTP: Philip Karlton at CMU-10A Re: Recent suggestions about From and Sender If the user is allowed to edit the From: field then it might become difficult for the sending program to guarantee that the address is a legitimate network address. Is this a real problem?? [MRC - It seems to me that if a user edits the From: field and loses then s/he is to blame for any confusion which results, not the mail subsystems. In any case subsystems shouldn't blindly assume that the From: field is correct since any number of things could screw it up.] -------  Date: 7 Sep 1977 1138-PDT From: BH at SU-AI (Brian Harvey) To: header-people at MIT-MC Thank you, Tovar. Thank you, Ken. If our luck holds, we seem to have discovered a domain in which Gresham's law doesn't apply. I too would like to repeat a previous comment, namely: message IDs are not useful for the purpose of referring to a message in a reply, since the (human) sender of the original message never saw the ID and wouldn't remember it if s/he did. Even "Subject: Re:" is better than the ID for that particular purpose. As for forwarding loops, I would like to know if this has ever been a problem in the past. I suspect that a bit of vigilance in the setting up of forwarding in the first place will do more good than automated control, but I could be wrong. -------  Date: 7 SEP 1977 1635-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Reply to several letters. To: HEADER-PEOPLE at MIT-MC In reply to MRC's letter (which was a reply to KLH's long letter): In choosing that date format it would be desirable to keep the format easily parsable by programs. A mail reading program might want to be able to place messages in order by date, among other things. A quote character is certainly important. I am not familiar enough with the rules of 724 to come up with an examply in which bracketing is insufficient to serve that purpose, but we should anticipate that there might be one. An important point to be considered when designing any protocol for the ARPA net is that a major goal of the net is to allow computers of any differnt type, useing any kind of strange software conventions (within limits, of course) to operate fully. In reply to Philip Karlton's letter, it is important to allow a user to alter the "From" field since he might be sending mail from a console at which some one else is logged in. However, there is no reason that the mail system would not still append its host name, and check to see if quoting is needed, etc. In reply to Brian Harvey's letter, message ID's ARE useful in just the way you described in the context of an advanced mail system: I can easily envision a command to "Fetch the letter I sent out to which he is replying", which would certainly want to work be checking the In-reply-to field, and then looking up that message ID. One of the primary reasons that message ID's are useful is in this kind of system; I think this is what Bob Frankston was referring to when he said that message ID's are a very fundamental kind of thing. -- Dan  Date: 8 Sep 1977 (Thursday) 0034-Est From: NIH at NBS-10 Subject: Suggestion for guaranteeing reciver's unique generation of Msg-ID To: Header-People at MIT-MC As nearly as I can tell the main advantage of message ID's is to allow automated filing and retrieval of messages in a consistent way. If message ID's are sent as part of the header or constructed by the receiver using a known algorithm, cross-site filing is possible. In deferrence to the "short header" faction, I can certainly see the advantages of making the receiver generate an ID if the receiver wants one. The problem is that it is possible for program-generated messages to have identical headers though the messages differ. The proposed suggestions so far are (1) Count characters and use that too (2) Calculate message checksum and use that too (3) Compare text portion of the message (only applicable to the duplicate msg problem) and (4) Allow the sender to send an ID only in the case that the sender thinks one is needed. Here is another idea that descended upon me while in a strange mood no doubt caused by reading 68 straight Header-People messages: The mailer knows when a header is about to be duplicated. It can refuse to send a new message with identical header until the date/time clock has been incremented, thereby making the new header unique. I doubt that we have need to send messages on the same subject from the same people to the same people more often than once a second. An extremely simple implementation can be had by making the mailer sleep for one second after every message sent (probably adequate for most volumes); higher volume shops can do header comparison and only delay possible infractions. As to the length of the generated ID--hopefully we can organize some convention for ID's so that they can be used like NLS "links". (This raises all kinds of questions on message filing--I'm not trying to open that subject; just suggest that there will be interconnections.) . . . Glenn  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 8 September 1977 0142-edt Subject: Once more, you've heard it before. Message-ID: [MIT-Multics]1.2.BBBJGlzJwklpnX To: header-people at MIT-MC 1. A UID generator is the simplest way of generating a UID. By making it independent of the rest of the header one does not run into problems of side effects resulting from variations in the content and form of other fields in instances and copies of letters. 2. How can a system know that it is generating two messages that may imply the same message ID if it is not using a shared UID generator. In a distributed system in which I am logged in as Frankston twice and am sending messages from both instances of myself (I have two hands for typing on two keyboards and often use them both!!!) then unless the system goes through the hair of a central database how is it going to know about the potential conflict and the central database option may conflict with either access control requirements or system architecture imposed limitations. Of course one can append a uniqueinstance ID to differntiaate the two in case of a potential conflict, but that is silly since a UID is a UID so why concatentate the insance ID with anything else when one can do better by generating a new virgin UID by simply reaching nto the humongous bag of UIDs and just get a new one. 3. As demonstrated by the Multics message-id, the message ID so generated is relatively small and therefore simpler to store and manipulate by a autoated message system. 4. It is a bug in current message systems that they bother users with message-id's when printing mail. This should be reported as a bug on the local system and fixed! {I hve been attempting to do so local and am awaiting improvements} 5. And even from one terminal I can send more than one message a second. Trivial example is a mailsystem (such as RMS's RMAIL) in which I can define single letter macro commands such as Y for reply yes and N for reply N and give a quick series of replies. 6. In conclusion. Message-id's generated by a UID generator are necessary for advanced mail sytems. Those users willing to risk loss of their messages by mail systems that automatically discard duplicates will probably continue to refuse to send message-id's to each other. But it is irresponsable for writers of mail sending programs to require that the sender be cocerned with ID generation and potential conflicts. It should just tag a message with a UID generated by an independent UID generator. 7. Post script. I feel that many of the complaints about UID's so generated are "well they look ugly and my scheme works almost all the time and fits my needs". I am attempting to suggest a scheme that doesn't fail (and least within its domain of expected usage) and which fits a much wider set of needs, especially those of advanced message systems which I hope we are attempting to pave the way for. OK, now, anyone have anything new to say?  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 8 September 1977 0221-edt Subject: In reply to invitation to be executed Message-ID: [MIT-Multics]1.2.BBBJGlzMDcWfHL To: mrc at SU-AI cc: header-people at MIT-MC So, there are many venerable bugs that will never get fixed. Try APARing (IBMese for reporting bugs) bugs in your 7094 Fortran II compiler.  Date: 8 SEP 1977 0954-PDT From: POSTEL at USC-ISIB Subject: re: message identifiers To: header-people at MIT-MC message identifiers can be useful for referencing messages. in the nls environment the use of unique simple identifies assigned to messages and documents has been extremely useful. but the key work is "simple". if identifiers are to be used for refering to messages they must be short, and easy to communicate, e.g. case distinctions should not be important. nls uses sequential numbers obtained from a single source. for the larger volume in the general network one might use "host-year-sequentialnumber". the potential for developing message filing and retrieval programs based on the use of a message identifier should not be forclosed. --jon. -------  Date: 8 SEP 1977 1510-EDT From: MOON at MIT-MC (David A. Moon) Subject: Brief note about forwarding loops To: HEADER-PEOPLE at MIT-MC In our system, where we allow (and encourage) users who are naive about the mail system to specify where their mail is to be forwarded to, it is not feasible to exercise "vigilance" over the setting up of forwarding. Forwarding loops have not been a serious problem, but they have occurred a number of times. Typically the message makes 500 to 1000 trips before someone notices, tying up a lot of machine time and logging console paper continually logging in FTP servers (we can tell how many because there seems to be a bug that puts an extra CRLF on the end each time.)  Date: 8 SEP 1977 1747-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I can see that there are many systems on which NIH's suggestion can't be implemented. But so what? If there is one that can and would like to, that should be considered acceptable by the standards. The others can do one of the other thins already suggested.  Date: 8 SEP 1977 2357-PDT From: Tovar Subject: Oh, God. Here we go again with Message-ID To: RMF @ MIT-AI, NIH @ NBS-10, Postel @ USC-ISIB cc: Header-people @ MIT-MC Message-ID: ----- In reply to your message '1.2.BBBJGlkDWwGnK' [in which you suggested that you might lose a few messages from MIT due to using the DATE-TO-FROM-SUBJECT instead of message-ID] and '1.2.BBBJGlzJwklpnX' [further comments and point about two instances of a user] Also in reply to NIH and Postel: First, I hope you understand that I am not advocated the prohibition of message-IDs but rather temperance in their use. Postel's comment about being handy to reference with is a good one. But the ones generated by Multics are unwieldy at best. Again, both a generated and a reasonable-appearing unique message-ID would be handy in referring to past correspondence. But the ones I've seen so far are either equivalent to a generated one (i.e. CMU's) or ridiculous to use (Multics). I welcome a better message-ID, but as an option as opposed to something tacked on every message. I asked a couple people to send me mail as fast as they could, from MIT-AI to MIT-AI, to see how fast humans can generate messages (with merely nonsensical content). The closest messages from RMS and were two seconds apart, which required type-ahead and no body at all to achieve. Using SAIL's line-editor to stuff commands at MIT-MC, I sent some nearly identical one word messages, to check to see if the CPU speed had anything to do with it. (I considered that cheating slightly, as the use of the line editor to send variations on the same message made them nearly machine generated. As it was MC couldn't quite keep up). In spite of that, I was able only once to get two messages with time-stamps of only a second apart. In this same trial (14 messages total), I got three pairs of two seconds apart. As I typed this in, I came up with a much simpler argument: it's just too hard to type that fast. Consider a simple message, like the simple answer, NO. That would be require ':MAIL TVR NO^C' to send this on ITS, one of the more terse systems around. That is 13 characters per second! As far as RMF's comment about RMAIL is concerned, two things can be said. First, I think that is in the realm of machine-generated mail and perhaps it should get a message-ID (but read on). However, RMAIL cannot switch messages all that fast, nor can a human read and generate a reasonable response, so the example is a poor one. The point about two instances of a user is a good one, although not exactly in terms which RMF put forth. The more serious one is that of two users sharing an account and sending mail to the same person at the same time. An obscure case, at that. Perhaps mail programs could be wary of this and check for another mail process (by for example, the existence of a temperary file). In this case, a message-ID might be generated. Another solution might be to put more resolution in the time field, so that it is only possible for one process to have been running at a given time. (Multiple-CPU systems would have to do other mail process check though). 1. The addition of seconds to date of systems not having them is much nicer than a whole, redundant or unintelligible line. 2. Programs which rapidly generate messages should use Message-IDs, 3. Humans need not. One would have to continuously type 30% faster than a Teletype to get even one message per second. 4. Paranoid, duplicate message flushing programs could simply checksum the message if they wanted a fool-proof means of detecting duplications.  Date: 9 Sep 1977 0540-PDT From: MRC at SU-AI (Mark Crispin) Subject: Checksumming the message To: Header-People at MIT-MC This is the only "safe" way to flush duplicate messages since no message ID is safe enough; a message could be replied to and sent back and have the same message ID. If I used a message flushing program I would not want it to flush a message with a unique checksum since that means the message is different in some way and I would want to investigate further to be sure it is truly redundant. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 9 September 1977 1216-edt Subject: checksumming and them some Message-ID: [MIT-Multics]1.2.BBBJGmDnmQpLGF To: header-people at MIT-MC 1. It won't work, my two copies of the messages from Tovar have a different number of lines. 2. A reply will not have the same message ID as the original letter. 3. All my messages are machine generated. 4. 13 cps is not all that fast to type. (Really!!!! especially for a secretary or someone who has spent over a decade on time sharing systems and uses terminal without the mechanical limitations of a TTY33 for a short burst of typing. 5. Just because RMAIL is slow is no reason to limit your imagination.  Date: 9 Sep 1977 1253-EDT From: Brian Reid at CMU-10A Reply-To: Header-People at MIT-MC Subject: Re: Checksumming the message To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 9 Sep 1977 12:53:54 Brian Reid In-Reply-To: MRC's message of September 9, 1977 For once, I agree with Mark. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 9 September 1977 1659-edt Subject: checksumming Message-ID: [MIT-Multics]1.2.BBBJGmFNgFMBkj To: reid at CMU-10a cc: header-people at MIT-MC Mark and Brian, 1. Do you intend to include the header when checksumming 2. If so, then you disallow for a program that parses headers as it reads the mail and regenerates a header when it sends the mail. 2. I you are still talking about the body, then there are still possible transformations that occur such as -----'s that some systems put in letters. Note that some of the letters I get would be manually forwarded versions of earlier letters. These may very likely contain cruft like the ----'s and white space transformations.  RMS@MIT-AI 09/09/77 19:29:41 Re: checksumming 2. If so, then you disallow for a program that parses headers as it reads the mail and regenerates a header when it sends the mail. What sort of a program are you talking about? What is it doing? I can only guess that it is either forwarding a message or replying to one. If it is replying, then this is irrelevant, since the reply is not the same message as what it is replying to. If it is forwarding, then I definitely consider it immoral for it to alter anything, except perhaps in a standard way such as to add a Forwarded-via field, which can easily be ignored by anyone who is checksumming. However, I think that there is no good reason for anybody to be interested in checksumming messages. While maliciousness or accident can certainly generate confusing messages, who cares what happens to them? There is no reason to orient the whole working of the system around the goal of not losing malicious messages.  Date: 9 SEP 1977 1941-EDT From: RMS at MIT-AI (Richard M. Stallman) To: frankston at MIT-MULTICS CC: header-people at MIT-MC I don't see why you feel that it makes any difference whether we can imagine systems on which we can send messages faster than RMAIL can. Any reason, no matter how silly or absurd, which nevertheless guarantees that my messages will be unique without message IDs, ought to entitle me to leave out message IDs. Even if it is just that my computer or my typing is slow. And if someone else's computer or typing might be faster, that is relevant only for him. It can't possible make MY messages fail to be unique.  Date: 9 SEP 1977 1941-EDT From: RMS at MIT-AI (Richard M. Stallman) To: frankston at MIT-MULTICS CC: header-people at MIT-MC I don't see why you feel that it makes any difference whether we can imagine systems on which we can send messages faster than RMAIL can. Any reason, no matter how silly or absurd, which nevertheless guarantees that my messages will be unique without message IDs, ought to entitle me to leave out message IDs. Even if it is just that my computer or my typing is slow. And if someone else's computer or typing might be faster, that is relevant only for him. It can't possible make MY messages fail to be unique.  Date: 9 SEP 1977 1952-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: Alternative to 724 proposed To: header-people at MIT-MC In RMS;XSYN > on MIT-AI you can find a file describing, in the language of KLH;NEWSYN >, a complete alternative proposal to the syntax of RFC 724 (actually, a few things from KLH;NEWSYN that are not changed are merely cited, not reproduced, so you should get a copy of NEWSYN for reference, and for comparison). It also contains a couple of ideas for making formal language specifications simpler, and a running commentary describing what effect was desired from each set of changes made and what the reasons behind it were.  Date: 9 SEP 1977 2307-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I would like to know whether there is anyone who has a need for the recipient-group feature of RFC 724. Is this something actually useful to people I don't know, or is it something being kept because tenex mailing lists happen to have them?  Date: 10 Sep 1977 0022-EDT From: Brian Reid at CMU-10A Subject: Message ID fields To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 10 Sep 1977 00:22:55 Brian Reid After brooding about message id's for a while, I think that we are confusing two separate uses of the message-id concept. Message-id fields generated by the sender of a message are intended to be used for the bookkeeping purposes of the sender. Thus, for example, in commercial offices where correspondence is filed, outgoing correspondence is often filed under what amounts to a message-id. The message-id is included in the output text in order that the correspondent can refer to a particular letter (the In-reply-to stuff). I am heartily in favor of message-id fields like this. They are a very useful tool for the organization of mail and replies. However, the presence or absence of a message-id field should be entirely up to the sender. Requiring one in the message standard would be ridiculous. Message-id fields generated by the receiver of a message are an entirely different animal. Their uses might be to detect duplicate messages, or to aid in the classification of messages in the recipient's message system. They can in no way substitute for message-ids generated by the sender. A program to compare two messages to determine if they are equal is laughably simple. Complaints like "my two copies had different numbers of lines" or "they checksums were different" are just noise. Of course a mail receiving program can do this comparison. And when I said that I agreed with Mark, which I still do, what I meant by that was that I see the detection of duplicate messages to be the recipient's job and not the mail protocol's job. And the message id has nothing to do with it. Brian -------  Date: 10 Sep 1977 0030-EDT From: Brian Reid at CMU-10A Subject: Recipient groups To: RMS at MIT-AI (Richard M. Stallman) CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 10 Sep 1977 00:30:54 Brian Reid In-Reply-To: Your message of September 9, 1977 Isn't Header-People a recipient group? -------  Date: 10 SEP 1977 0037-EDT From: RMS at MIT-AI (Richard M. Stallman) To: brian.reid at CMU-10A CC: header-people at MIT-MC By recipient groups, I mean things of the form FOO: so-and-so@host, who-else@host; in To fields - the things that 724 calls "groups". header-people@ms is simply an address, which happens to forward to other names. But that forwarding is somethign totally outside what RFC 724 or XSYN tries to talk about.  Date: 10 SEP 1977 0048-EDT From: MOON at MIT-MC (David A. Moon) To: HEADER-PEOPLE at MIT-MC Reply to MRC's question about whether quoting characters are needed in the real world. They are used all the time in inter-ITS mail, where many recipient names are actually file names and often contain funny characters. This isn't really relevant to RFC 724 since I doubt that we would use that protocol for talking to ourselves, but the point is that you certainly need it.  Date: 11 Sep 1977 1016-PDT From: BH at SU-AI (Brian Harvey) Subject: An embarrassing confession To: header-people at MIT-ML It's been a while since I first read 724, and apparently I didn't read it too carefully, but I've just re-read it, and I find the following paragraph which indicates to me that 724 already supports in principle the short-header camp's position on avoiding redundant information in the header: I. Problems with ARPANET Message Standards / 5 B. Issues and Conclusions 7. Received messages are capable of being read by humans without a program having to parse the message (or parts of it) before presenting the message to the user; however there is sufficient formal syntax to enable a parsing program to modify the appearance and content of material presented to users. Although message-display software may exercise considerable control over message appearance, the degree to which a message's actual format is PLEASANT for humans to read is entirely the responsibility of the message creation program. This seems to me to be a remarkably statesmanlike presentation of the idea that, on the one hand, the standard should encourage the development of clever mail systems, but on the other hand, "If you had as good a mail reader as HERMES you wouldn't be complaining" is not an acceptable answer to the request to avoid things like identical From and Sender fields. ------- (Message manually forwarded by Moon at MIT-MC. Had been sent to Trailer-People at the wrong host.)  Date: 12 Sep 1977 2259-PDT From: MRC at SU-AI (Mark Crispin) Subject: 724's support of short headers To: Header-People at MIT-MC There's this little bug in that though; you have these people who will want to include every option in a message header just because "it's there". I hope that if and when 724 happens that the default will be the minimal header and the sender will have to specify that the extra header information is included. Do others in the pro-724 agree with me on the default being just Date/From + To/Subject if applicable? Note to Bob Frankston; I hope Multics' mailer checks for obscenities in the generated message-ID, especially if it is included in all Multics network mail! What would Colonel Russell say if Multics started being (horrors!) "without redeeming social value"? [Wow, that would be FUN!] -------  Date: 13 SEP 1977 0535-EDT From: KLH at MIT-AI (Ken Harrenstien) To: Header-people at MIT-MC Now, I don't really care about message ID formats too much, but there's one strategem that nobody else has proposed yet. It might be reasonable to extend the "Date" field into a full postmark; that is, include the originating location as well as originating time. Such an extension would be useful in its own right as a simple way to get the sending-site name, and all it needs to make itself a message-ID is a additional, optional uniquizing field. I can't think of any such uniquizer which would not fit nicely on the rest of the "Date" line; Multics for example could even dump the whole of its weirdness there, if it can't give just enough letters to round off a second. To equal a HERMES id, the uniquizer is just the sender name; to equal a MIT id, just a small nmber; etc. Date: 13 Sep 1977 (Tuesday) 0223:24-PDT [SRI-KL] 31415 Personally I think a slightly longer line (particularly this field) is vastly less obnoxious than an extra line which usually coms between the important fields and the message. At any rate, this scheme provides for a explicit uniquizer that doesn7t ned an extra field at all.  From: Pogran at MIT-Multics Date: 09/13/77 1129-edt Subject: Obscenity-screening To: MRC at SU-AI cc: Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJGmQnCXPDXm Mark, Turns out that the Multics Unique ID generator has always created all-consonant strings for just that reason! Ken  Date: 14 SEP 1977 0951-PDT From: POSTEL at USC-ISIB Subject: NEWSYN & XSYN To: header-people at MIT-MC the effort that KLH and RMS have made to produce NEWSYN and XSYN requires the close examination of the proposed standard that is necessary to engage in reasoned discussions of various features and discrepancies in the draft document. in particular the items that these proposals suggest could be dropped should indeed be critically examined since they are either ill formed, or ill motivated. i also feel that the introduction of type specific specifications as RMS has made can help to clarify some otherwise fuzzy notions. --jon. -------  Date: 14 SEP 1977 0951-PDT From: POSTEL at USC-ISIB Subject: NEWSYN & XSYN To: header-people at MIT-MC the effort that KLH and RMS have made to produce NEWSYN and XSYN requires the close examination of the proposed standard that is necessary to engage in reasoned discussions of various features and discrepancies in the draft document. in particular the items that these proposals suggest could be dropped should indeed be critically examined since they are either ill formed, or ill motivated. i also feel that the introduction of type specific specifications as RMS has made can help to clarify some otherwise fuzzy notions. --jon. -------  Date: 16 SEP 1977 1054-PDT Sender: DCROCKER at USC-ISI From: DCROCKER at USC-ISI To: rms at MIT-MC Cc: brian.reid at CMU-10A, header-people at MIT-MC Message-ID: <[USC-ISI]16-SEP-77 10:54:05.DCROCKER> In-Reply-To: Your message of SEPTEMBER 10, 1977 The utility of having group names is in the resulting ability to send around the entire mailing list, but only print its name to the user. Therefore, if header-people, as a single address, did not exist, but I did have the addressess of its constituents, I could do header-people: 3000 addresses...; and you r display program would only show "header-people:". This is useful in the case of very temporary groups and groups which are spontaneously-generated by an individual. Having a distribution mechanism like mit/mc... has is an extremely high degree of formality, in an organizational sense. Group names are useful in less formal situations. Dave. -------  Date: 22 Sep 1977 1050-EDT From: Brian Reid at CMU-10A Subject: Mail privacy -- an informal survey To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 22 Sep 1977 10:50:02 Brian Reid I just found out, sort of the hard way, that on MIT's ITS systems everybody can (and does) read everybody else's mail. I find that this is not in keeping with my notion of `proper implementation'. Here at CMU, for example, mail is as private as the operating system will allow, which means that only operators can read others' mail, and they are strongly discouraged from doing so. I wonder just what the story is out there? How many sites see mail as public a la ITS and allow anybody to read others' mail, and how many want mail to be private and use the operating system's best privacy features to ensure that. Brian -------  Date: 22 SEP 1977 1245-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: Security, and XSYN To: HEADER-PEOPLE at MIT-MC, Brian.Reid at CMU-10A It's not really true that ITS considers mail files to be public; rather, there is no security whatsoever on the system, and mail files simply happen to be like all other files. Other people can give much more impassioned declarations of why ITS has been and will continue to be this way, so I will defer to their eloquence if reasons are needed. I would of course prefer that my mail not be read by others, and I can't imagine anyone who would not like this option available. Very few people here are habitual snoops, though I suppose that doesn't help you much. ------------- With regard to XSYN; RMS didn7t announce that a slightly different, tighter version is available (from RMS;XSYN > on MIT-AI as before), and I like this very much. Have Dcrocker, pogran, etc noticed that groups are still compatible with this new addressee syntax, and using comments serves just as well as delimiting machine addresses with angle brackets? If you think about how an address with a phrase AND a mach-addr needs to be hacked, you'll see that an address with comments requires the same sort of storage, filtering for FTP, etc. For example, Ken Harrenstien requires about the same processing as KLH at MIT-AI (Ken Harrenstien) and amounts to a simplification. I can't think of any very good argument for the former as opposed to the latter; if someone has one, bring it up and I will either accept it or rebuke it. (Note that there is no requirement that I use my full name in the former; that is, I could just as easily say "Hungry Coeurl ", which is just as descriptive to my friends (and as confusing to computers as to human strangers)). To get back to groups: they are all right with me, I guess; as I said, they won't conflict with the basic ideas in XSYN of bracketing and typing. Any news from cahcom?  Date: 22 SEP 1977 1339-EDT From: MRC at MIT-AI (Mark Crispin) Subject: Message security To: Header-People at MIT-MC CC: WD at SU-AI, RWG at SU-AI, JZS at CCA-TENEX I am of the opinion that the only "secure" mailbox is an encrypted mailbox. Trusting the operating system is faulty; system programmers and operators can evade the restrictions if they so desire. No protection mechanism can stand long against an inquisitive wheel. An incident last July where a message was copied from a protected mailbox on a Tenex site and was forwarded along to certain parties with many political reprecussions following underscores this. There is another problem -- a legitimate receiver forwarding the message without your consent. This is perhaps even more serious since no protection mechanism can help you in this case. I consider my ITS and SAIL mailboxes to be as secure as my allegedly protected mailboxes on Tenex, TOPS-10, and Multics sites. The protection mechanism just creates a privileged class of people who can spy on mailboxes. I'm afraid human nature comes into it; being privileged encourages one to use the privileges even though before the person had no need for them, and there is a thin line between use and abuse. The person who spies on another prior to linking to see if the other person is at an inconvenient point to get a link is being courteous--but another person spying to "flip the channels" is a spy, even though both are doing the same thing! I don't want to argue about the morality of spying vs. not spying; it's clear that invasion of privacy will never totally cease. What you can do is either put up the equivalent of "no trespassing" signs and hope they are respected (my usual approach) or find a method that is more powerful than the spy's for hiding your mail. Encryption seems to be the only safe thing. A new algorithm proposed by Diffe (I think) et al uses the product of two large primes as the encryption key; however the algorithm is irreversible. Decryption requires knowing the factors. An enhancement suggested by McCarthy which lowers security only slightly is to have a key phrase be the seed for the prime number generator (the primes are on the order of 10 to the 60th I believe) so that instead of a large number can be used. As far as I know this algorithm does not have any known method of breaking it, and is much more secure than the NBS standard. The beauty of the scheme is that the encryption key is public knowledge! Then the only worries you have are making sure you are not tapped or other- wise spied upon when you are decrypting and examining your mail. How you do this is up to you and depends on your operating system (one thing nice about non-protected systems is that spies have a hard time hiding themselves too!!) and your adversaries and is not a suitable topic for this forum. I proposed encryption as part of a mail system independant of ARPAnet mail (using a mail protocol rather than headers, and actual headers being minimal of course!!), but the people whom I spoke to on this didn't give it the favorable reaction I had hoped for and eventually I was forced to abandon the idea. I envision that DIALnet mail will have two mailing services, one of normal semi-protected mail, and the other of encrypted mail, probably using keys between clusters of users and not the network as a whole.  Date: 22 SEP 1977 1205-PDT Sender: DCROCKER at USC-ISI Subject: Re: Mail privacy -- an informal survey From: DCROCKER at USC-ISI To: BRIAN.REID at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]22-SEP-77 12:05:54.DCROCKER> In-Reply-To: [CMU-10A] 22 Sep 1977 10:50:02 Brian Reid The original implementation of MS, our Unix message system, had completely open delivery mailboxes, for a short-term convenience, but otherwise closes all read/write access to outsiders (i.e., other than owner's) for other message folders. A recent mod will allow closing the hole at the delivery mailbox. Dave. -------  Date: 22 SEP 1977 1621-EDT From: JZS at CCA Subject: Joining the group To: Header-People at MIT-MC cc: MARS-Filer at CCA Over the last few weeks, several people in their correspondence to me have alluded to the "header people" -- but it wasn't until a couple of days ago that I learned (from Dave Crocker during his last visit here) that a group, with ARPANET mailbox, really existed. He mentioned that there was at least a year's worth of interesting mail regarding various aspects of developing message-handling programs. I have been developing a message archiving package for CCA's Datacomputer -- and would like to (1) join the group (2) read the group's messages, and (3) investigate filing the messages on the Datacomputer. Thanks in advance for any information you can offer along these lines. Joanne Z. Sattley Sponsored Research Staff Computer Corporation of America -------  Date: 22 SEP 1977 1711-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: $ Have added JZS@CCA, pointed at files, etc. $ To: HEADER-PEOPLE at MIT-MC (Aside to Stef: useful little convention isn't it?)  Date: 22 Sep 1977 1723-EDT From: Brian Reid at CMU-10A Subject: Filing Header-people on the Datacomputer To: JZS at CCA CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 22 Sep 1977 17:23:06 Brian Reid In-Reply-To: Your message of September 22, 1977 Hmmm. Read through the Header-people archives before you get any ideas about wanting to stash them away in some permanent storage spot. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 22 September 1977 1738-edt Subject: Privacy of Mail Message-ID: [MIT-Multics]1.2.BBBJGnGDnxxQhh To: header-people at MIT-MC Need I say what Multic's attitude is.  Date: 22 Sep 1977 1736-EDT From: Brian Reid at CMU-10A Subject: mail privacy To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 22 Sep 1977 17:36:12 Brian Reid Hmm. I think that mailboxes differ fundamentally from files in that they are in a sense the property of the person who sent the message. The disk files on my account at CMU are not protected, and never will be. I put them there, and I understand the various ways that the masses can read them, if they should be so foolish as to want to. But my MAILBOX is another story. The mailbox is protected as a courtesy to the people who send me mail. I think that reasonable privacy is an extremely important part of a message system. With regard to MRC's remarks, it's true that privacy is relative; regular mail can be steamed open, for example. The way that people use a mail system will change dramatically if they don't believe that there will be reasonable privacy on the other end. Diffie's encryption algorithm (as written up in Scientific American a few months ago) seems ideal in that respect. A mail delivery program can use the (public) encryption key to encrypt a user's mail as it appends it to his mailbox. This can be purely local-option, and not at all a part of any message standard. On the other hand, I find it very annoying, for example, that I cannot send a message to a person at an ITS site without feeling that anybody else at that ITS site will be able to read it. If the recipient of the mail wants to unprotect it, or send it around the net, or put it on the bulletin board, that's the breaks. But it sure is a pain to have other people reading X's mail before X sees it, even. Richelieu once said "Never destroy a letter, and never write one." Maybe that's the best ploy. Brian -------  Date: 22 Sep 1977 1430-PDT Sender: GEOFF at SRI-KA Subject: Re: Security, and XSYN From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: KLH at MIT-MC Cc: HEADER-PEOPLE at MIT-MC, Brian.Reid at CMU-10A Message-ID: <[SRI-KA]22-Sep-77 14:30:14.GEOFF> In-Reply-To: Your message of September 22, 1977 I for one am against the form: From: Geoff Goodfellow because most systems don't have the personell data base that will contain all the names of their users, and some systems in fact may not want that to exist either (although I can't imagine why), and as far as I know the only systems that do this on a regular basis are the ITS sites, and SAIL, and the SRI machines have it optionaly available, so then you are going to end up getting: From: most of the time for everyone. I think it is MUCH more easyer (and looks better too!) to have it of the form: From: Geoff at SRI-KA (Geoff Goodfellow) and have the mail program just flush anything after the host name, and if you don't have the personell name data it looks much more pleasing, becuase the person's 'real address' is in the same place. I think it is much nicer to stick optional things after objects, rather than in front of them, because then it doesn7t change the ordering of things. [Geoff] -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 22 September 1977 1751-edt Subject: filing header people mail Message-ID: [MIT-Multics]1.2.BBBJGnGFfJxLPC To: jzs at CCA-TENEX, brian.reid at CMU-10a cc: header-people at MIT-MC Actually, it would be very nice to have a standard place to refer back to old mail. Something a long the lines of a mailbox-id on CCA that writes to a DFTP-readable file would probably be most useful. A line with the subject and message-id written to a file also stored would provide a way of getting at a desired message. There are also archive files on ITS containing old header-people mail and a more recent one (last year or so) on Multics.  Date: 22 Sep 1977 1455-PDT Sender: GEOFF at SRI-KA Subject: Re: Message security From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: MRC at MIT-AI Cc: Header-People at MIT-MC, WD at SU-AI, RWG at SU-AI, Cc: JZS at CCA-TENEX Message-ID: <[SRI-KA]22-Sep-77 14:55:41.GEOFF> In-Reply-To: Your message of September 22, 1977 You spent the major part of your message saying that encryption is the only way to send mail to people so that nosy wheels and flaws of the operting system can't be exploited in snooping in on your mail. The best line is "No protection mechanism can stand long against an inquisitive wheel" I certinly hope you included your encryption scheme in that list of 'protection mechanisms'. Even though you maybe able to prevent me from reading your mail at my convinece, but sooner or later you are going to get around to printing that mail (to see it yourself!) and if I am clever enough I can just have the system set up so that all output you might generate goes into some file somewhere, including your de-ciphered message, as well as any keyboard input you may enter. Basicly, there are a 69 ways to make it harder for me to get at your mail using the computer, but it is clearly impossible for you to prevent that 'inquisitive wheel' from doing so. If you are concerned about bad guys looking in our you mail, you should do what they have done down at NOSC in San Diego, all terminals and computers are in a lead room, and you have to have TOP SECRET clearnce to gain access; but then again, what keeps the people with top secret clearence from being bad.... You can certinly take measures to prevent lots of people from gaining access to 'secure' data, but there isn't a snoballs chance in hell of keeping that inqiuisitve wheel from it. -------  Date: 22 Sep 1977 (Thursday) 2202-Est From: STECKEL at HARV-10 Subject: COMPLEAT SECURITY To: HEADER-PEOPLE at MIT-MC IN REFERENCE TO ENCRYPTION & SECURITY, THE MICROCOMPUTER CERTAINLY GIVES US THE REMOTE POWER THAT IS NECESSARY TO HIDE OUR MESSAGES AT HOME. THE NBS STANDARD (MAY IT WITHER AWAY) HAS ALREADY BEEN COMMITTED TO SILICON WHICH ONE MIGHT PLUG INTO ONE'S TERMINAL. THE TI'S, DIABLO'S ETC. WHICH CONTAIN 8080'S (MAY THEY ALSO GO BACK TO PROCESS CONTROL LIKE THEY WERE DESIGNED FOR) WHICH ARE QUITE SMART ENOUGH TO PROCESS THE ALGORITHM DESCRIBE  Date: 22 Sep 1977 (Thursday) 2211-Est From: STECKEL at HARV-10 Subject: INCOMPLETE MESSAGE To: HEADER-PEOPLE at MIT-MC ...DESCRIBED IN MARTIN GARDNER'S COLUMN. THE LEAD ROOM CRACK IS TOO GRANDIOSE; A BATTERY-POWERED MICRO IN A COPPER BOX THE SIZE OF A BREADBOX IS QUITE SUFFICIENT; THE MESSAGE COULD BE RECORDED ON CASSETTE OVAR THE PHONE LINE, PLACED INSIDE DECRYPTED (PROBABLY OVERNIGHT) AND HARD-COPY TAKEN OUT WHEN DONE. SERVE HOT. THE DIALNET FOLKS WILL PROBABLY HAVE SOME WAY TO DO IT SOON... AND ANY WHEEL WHO WANTS TO SEE MY MAIL WILL HAVE TO KNOCK ON MY DOOR FOR IT, JUST LIKE ANY OTHER AGENCY. HOWEVER, AS LONG AS I KEEP MAIL ON MY TOPS-10, IT WILL BE THUMBED THROUGH BY ANYONE WITH THE INCLINATION AND ENOUGH ENERGY TO WALK TO THE OPERATOR'S CONSOLE. MEANWHILE, THERE IS SOME CONSOLATION THAT (ACCORDING TO CONGRESSIONAL HEARINGS BROADCAST OVER A LOCAL STATION) THE NSA HAS INSUFFICIENT LISTENERS OR COMPUTER POWER TO LISTEN TO ALL PHONE CALLS SO (ITALICS) THEY HAVE BEEN SPREADING THE RUMOR THAT THEY (THE NSA) HAVE DONE SO TO DISCO  Date: 22 Sep 1977 (Thursday) 2215-Est From: STECKEL at HARV-10 Subject: LAST COUPLE OF LINES To: HEADER-PEOPLE at MIT-MC ...DISCOURAGE FOREIGN AGENTS FROM USING THE TELEPHONE. OH WELL, RUMOR OR FACT, THE POSSIBILITY IS AWESOME: TO ENSURE PRIVACY, TALK ALL THE TIME SO THAT THERE WILL BE NO WAY FOR ANYONE TO LISTEN; SEND YOURSELF 10 TO THE 10'S OF MESSAGES AND NO-ONE WILL EVER BE ABLE TO GET ANY INFORMATION OUT OF THEM. (CNSIDER THE LAST 1 1/2 OF MINE IN THAT CLASS IF YOU LIKE)  From: Pogran at MIT-Multics Date: 09/23/77 1103-edt Subject: Mailbox security and our model of computer-based mail systems To: Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJGnHwKZkJdl Just a few words (paragraphs?) about mailbox security, etc.: The model that most of us have in our minds for how private our computer mail should be is that of First Class US Postal Service mail which is delivered to our (hopefully locked) home mailbox, and we've been discussing how close our various host systems can come to treating our computer mailboxes that way. The positions range from, "Can't come close at all, because our system has no file security", to "Comes close; mailboxes are secure on my system" (but then paranoia strikes: "A wheel can breach mailbox security if he wants to snoop"). I originally started out writing a note about mailbox security, but eventually ceased, as I wasn't saying anything new, other than to note that Saltzer has pointed out in some paper or other (I'll dig it up if anyone's interested) that, in the appropriate environment, a system wheel (whom he calls a "locksmith") can be bonded, just as a real-life locksmith is bonded, to guarantee, for example, that he will NOT snoop around your apartment when he picks your lock to let you in after you lost your key. What I want to address in this note is the notion that perhaps our model is wrong; perhaps our model should be that of the corporate mail room, where mail is only as private as corporate policy allows it to be. To illustrate: I remember reading somewhere, just a few days ago, that an employee sued his employer for opening a piece of mail which arrived, via USPS, at his company address. It was first class mail, it was marked "private" on the outside, but the corporate mail room opened it -- which was corporate policy. Apparently, the employee claimed to have suffered some loss due to the fact that his ostensibly private mail was opened. The employee lost; the law is that ANY mail addressed to someone at his business address may be treated by the business's mail-receiving entity as the business sees fit, because legally the mail is deemed to be addressed to the business. By analogy, then, even if the ARPANET could guarantee to deliver mail to a host in a secure fashion (which it can't), we have no right (though we may have the desire) to have our mail kept private by our host system. The mail is delivered to the host. We could envision a system which offers a "secure mailbox service", with which users could contract, which would contractually obligate itself to keep received mail secure. Then, if a system wheel spied on a user's mailbox, the "secure mailbox service" would be liable for breach of contract. It COULD be done, in the context of the ARPANET. It COULD be done, with operating systems which exist today. I suspect that it WILL be done, when there is a public network on which electronic mail is a tarriffed service. To summarize: We should keep straight in our minds what the MODEL for computer mail service should be, what is TECHNICALLY feasible, either today or in the future, what is practiced ADMINISTRATIVELY today (i.e., Do you trust your local "system wheel"?), and what can be achieved LEGALLY or via CONTRACTUAL OBLIGATION. 'Nuff said. Ken Pogran  Date: 23 Sep 1977 0802-PDT From: MRC at SU-AI (Mark Crispin) Subject: How secure is secure? To: Header-People at MIT-MC I agree with Geoff (Steckel) that the best way is not to decrypt at the computer, but at the terminal, where presumably the terminal's owner is the only wheel. Generating the primes should be done there too to plug that problem as well. I don't trust the sanctity of anything unless it is locked up at home. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 23 September 1977 1121-edt Subject: cryption Message-ID: [MIT-Multics]1.2.BBBJGnHxKnBckf To: header-people at MIT-MC Encryption is not the solution to the world's problems. While it is useful for communication lines and maybe mass storage devices, it is difficult to keep data encrypted while processing it. For example, one would want to at least keep the header in clear text so that one's mail processing program might have access to it. Also a letter must be recrypted each time it is passed between domains of authorization. If A sends B 3 a letter who decides the encryption key. If I have to remember more than one encryption key I must rely on the computer to manage them and thus ultimately rely on the computer for keeping them secure. This is the same problem that occurs on systems that rely on passwords for each file for security -- you can't reemember them all so you keep them in a file or worse, on a piece of paper.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 23 September 1977 1121-edt Subject: cryption Message-ID: [MIT-Multics]1.2.BBBJGnHxKnBckf To: header-people at MIT-MC Encryption is not the solution to the world's problems. While it is useful for communication lines and maybe mass storage devices, it is difficult to keep data encrypted while processing it. For example, one would want to at least keep the header in clear text so that one's mail processing program might have access to it. Also a letter must be recrypted each time it is passed between domains of authorization. If A sends B a letter who decides the encryption key. If I have to remember more than one encryption key I must rely on the computer to manage them and thus ultimately rely on the computer for keeping them secure. This is the same problem that occurs on systems that rely on passwords for each file for security -- you can't reemember them all so you keep them in a file or worse, on a piece of paper.  Date: 23 Sep 1977 1151-EDT From: Philip Karlton at CMU-10A Subject: Re: How secure is secure? To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 23 Sep 1977 11:51:21 Philip Karlton If people are really going to worry about security then they should take the time to read some of the procedures used by the military. Things like who is talking to whom or even the frequency with which one party sends or receives messages must often be hidden. The thing that the military probably does best is deal with information hiding. I actually do not think this discussion belongs in Header-People and invite all you Security-People to start a new group somewhere else. PK -------  Date: 23 Sep 1977 1139-PDT From: BH at SU-AI (Brian Harvey) Subject: security To: header-people at MIT-MC The trouble with Brian Reid's notion of security as a courtesy to the sender is the same as the trouble with message-id's as a courtesy to the receiver: the decision must be made at the wrong end of the chain. If there were some practical way for the sender's computer to secure a message, that'd be nice. (I just thought of one: put the thing in your own file directory, call up your corrrespondent on the telephone and tell him your password.) (Yes I know, telephones aren't secure.) I think what we should learn from the military, actually, is to treat computer mail the way they treat autovon: their phone books say THE TELEPHONE IS NOT A SECURE MEDIUM in great big letters and they leave it at that. Personally I can't understand how anybody who has ever tried to get any work done on a computer with security can possibly want any. -------  Date: 24 Sep 1977 1042-PDT From: Feinler at SRI-KL Subject: 'Secure' mail To: header-people at MIT-MC cc: feinler I think Ken Pogran pointed out that what most of us are thinking of in terms of network mail is something as secure as First Class U.S. Postal Mail, but if one thinks about it U.S. First Class mail is really secure mostly by agreement and etiquette since it is certainly physically possible to get at almost anyone's mail (on my street we don't have locked mailboxes and even if we did they wouldn't present much of a challenge to someone who was really intent on opening them. On the other hand there is a very strong sense of agreement that reading someone else's mail is a pretty rotten thing to do unless you have that person's permission. I have often wondered why that etiquette and agreement breaks down so badly on computers. Anyway, I feel the same kind of restraints should be applied to computer mail, if possible, as to hardcopy mail. If someone tampers (i.e., reads) my mail I would like to see some message that 'XYZ has accessed your mail file' if that person is known. Otherwise I would like a message saying when was the last time my mail file was accessed. Presumably if it is accessed frequently by someone using my password who is not me, I can note this and either change the password or set my own kinds of traps to try to find who it is. It would be useful to note from which host the access was made. This would probably be enough security for most cases. If someone is found to be a bad offender, drum him out of the corps by refusing him mail service on all hosts (hmmmm, could we call this 'arresting' him/her?). Really secure mail should be a separate issue in my estimation, since 95% of anybody's correspondence (including corporate and military) doesn't need to be guaranteed secure. The sheer volume of computer mail traffic means that it would be a drag to monitor very many person's messages surreptitiously and my suspicion is that most people monitoring mail that doesn't belong to them are doing it on their local host and can be dealt with locally. (As mail goes, consider this 2 cents worth) Jake -------  Date: 24 Sep 1977 (Saturday) 1446-Est From: STECKEL at HARV-10 Subject: discusive digression To: header-people at MIT-MC Jake Feinler's comments seem to the point. What we have on the net is much closer to the "corporate" aspect though. I received a warning about 18 months (+ - 10) ago that all net traffic through RAND was being monitored, especially network mail. However, I also have people on my host who strongly believe that they have some sort of contractual relationship which makes Harvard liable for the security of their net mail. Schizophrenic situation, no? The normal courtesies seem to break down for several reasons, perhaps most of all that there is nothing either tangible or "personal" about a bit pattern on a disk surface. If I'm using this >shared< machine, I can wander all over it, and I'll share the pieces I want to share... Anyway, I gotta go read latest update to XSYN of however many days ago.  Geoff Steckel  Date: 24 Sep 1977 at 1148-PDT Subject: re: mail security From: Mike at Rand-Unix To: Header-People at Mit-Mc Message-ID: <[Rand-Unix]24-Sep-77 11:48:12.Mike> I have never assumed that any communication system is secure, whether it be Network mail, Ma Bell, or the US Postal Service. All evidence is strongly to the contrary. When Rand started spying on netmail on a regular basis as a part of corporate policy, I thought it was tacky, but I didn't change my mailing habits much. [Just a bit more discretion perhaps, which is not a bad thing in itself.] Thus, the fact that network mail is not completely secure and probably never will be does not surprise or dismay me even a little bit. On the other hand, there is a very large difference between a corporation inspecting incoming mail on a professional level, and some random hacker munging around through someone else's files to see what is going on. Further, I think that any wheel which is going to read someone else's mail without permission is not mature or professional enough to be a wheel on a system where work is being done. If your system has some reasonably secure file system, then protect the mail files and, beyond that, encourage the notion of respecting the privacy of other people within the community. Once you get more complicated than this (encryption of every message, etc.), you may get more security, but only at the cost of making a mail system expensive and difficult to use. Mike Wahrman.  Date: 24 Sep 1977 1202-PDT Sender: GEOFF at SRI-KA Subject: Re: discusive digression From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: STECKEL at HARV-10 Cc: header-people at MIT-MC Message-ID: <[SRI-KA]24-Sep-77 12:02:49.GEOFF> In-Reply-To: Your message of September 24, 1977 The reason why network mail (both in and out) is monitored at the RAND hosts is because it is corporate policy to open all incoming mail unless it is marked personnel, and we all know that the network is not to be used for communications of that nature, and that was another way of making sure that RAND people were "good boys" in that respect. In lieu of an unfortunate incident that happen about a year and a half ago, they saw the network as a "hole" in their corporation wide policy, they instantiated the mail spy.... -------  From: Pogran at MIT-Multics Date: 09/26/77 1043-edt Subject: Responses to Feinler and Wahrman To: Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJGnWWbzjLJn I agree with Mike Wahrman's comments regarding the maturity of system wheels. Jake, did you ever stop to think that if a system were capable of reliably placing a message in your mailbox saying, "So-and-so has accessed your mailbox", that system is also likely to have the capability to prevent So-and-so from accessing your mailbox in the first place? That is, if the system can guarantee that if someone accesses your mailbox, that fact will be recorded, and the accessor's identity will be unforgeably recorded, then the system must be capable of guaranteeing that the mailbox cannot be accessed without that record being made. If a system can guarantee that, then it essentially guarantees that its access constraints cannot be violated. If this is so, then the system security design must contain all the essentials for controlling access to objects in the first place -- and could have been implemented so as to keep your mailbox as secure as you'd like! Moral: If a system can't provide mailbox security, it isn't going to be able to tell you who's accessed your mailbox, either. Regards, Ken