Date: 6 Sep 1983 0945-EDT From: Greg Skinner Subject: Re: senders, originators and relays To: ROODE@SRI-NIC cc: header-people@MIT-MC In-Reply-To: Your message of 5-Sep-83 2020-EDT Return-path: <@MIT-MC:ROODE@SRI-NIC> Received: from MIT-MC by MIT-XX; Mon 5 Sep 83 20:15:43-EDT Date: Mon 5 Sep 83 17:07:02-PDT From: David Roode Subject: senders, originators and relays To: Header-People@MIT-MC Location: EJ286 Phone: (415) 859-2774 Consider: 3. In the TOPS-20 mailsystem, when you cause a "SENDER:" header to be generated by specifying the contents of the "FROM:" header, automatically, a "REPLY-TO:" header is generated to match the "SENDER:" header. There needs to be a convenient way to leave this off if the functionality of separating error reports from replies is to be achieved. Also, there is no way to set the SENDER to say "HEADER-PEOPLE-REQUEST@MIT-MC" because it is forced to be the user logged in sending the message. Well, by using the BABYL library (for tops-20 emacs) you can define your own header fields, or force the headers to whatever you want them to be. Once I wanted to anonymously mail a message to a group of people, so I made up false From: and Sender: addresses. The only problem with that is that the return path becomes NET-ORIGIN which is probably an "undeliverable, unclaimable mail" box. -------  Date: 6 Sep 1983 14:39:10 PDT From: POSTEL@USC-ISIF Subject: re: forwarding or remailing ? To: Header-People@MIT-MC I agree with Ed Taft. His statement is clear and to the point. My view is that mail sent via a mailing list is really two distinct and separate operations. 1. Author sends the message to a distribution service. 2. The distribution service send the message to the list. If anything goes wrong in step 1 the author ought to be told. If anything goes wrong in step 2 the operator of the distribution service ought to be told. --jon. -------  Date: 7 September 1983 08:39 edt From: TMPLee.DODCSC at MIT-MULTICS Subject: Query: GTE Telenet blk xfr protocol? To: Header-People at MIT-MC, Human-Nets at RUTGERS, info-pcnet at MIT-MC, protocols at RUTGERS cc: TMPLee.DODCSC at MIT-MULTICS (list moderators: please feel free to ignore this if you don't think it fits your list) Does anyone know the details (i.e., protocol) for doing block transfers to/from GTE Telenet public dial-up access points? I'm using a personal computer as my terminal and getting to an ARPAnet machine via gte-telenet. I'd like to be able to store/retrieve and local edit traffic from the net but to do that I have to have some kind of simple protocol for transmission of blocks of text to and from GTE Telenet. I think they support such a protocol, but have no information about it. (not asking for a reliable transmission protocol -- lines here are pretty good -- just one to do speed and buffer matching) Ted Lee  Received: by YALE-BULLDOG via CHAOS; Tue, 27 Sep 83 22:08:43 EDT Received: from YALE-RING by YALE-RES via CHAOS; Tue, 27 Sep 83 22:01:02 EDT Subject: A Random Gripe Date: Tue, 27 Sep 83 22:01:07 EDT From: Nathaniel Mishkin To: Header-People@MIT-MC.ARPA cc: Ellis@YALE.ARPA I figure this is a good a place as any to make this gripe...it is my understanding that the syntax of addresses prohibits "."s as in the following context: To: Elmer T. Fudd If you want "."s or other "special" characters, you're supposed to wrap the "phrase" with quotes. E.g.: To: "Elmer T. Fudd" I can't say that I can reconstruct the motivation for this restriction -- I suspect it has to do with not confusing the "."s with the "."s in a domain spec -- but in any case, a lot of systems don't follow the rule and it screws up our mail parser a bit. It's not a tragic or major problem, but I thought I would bring it to people's attention, since a lot of mail systems don't seem to wrap the phrase with quotes, as it should. -- Nat  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 28 Sep 83 01:13:59 PDT Via: 44a.Ucl-Cs.AC.UK; to 44b.Ucl-Cs.AC.UK over Inter-UNIX with SMTP; 28 Sep 83 9:12 BST Date: 28 Sep 83 8:39:15 BST (Wed) From: The Postmaster (44a) To: mailgroup@ucl-cs, header-people@mit-mc.arpa Subject: [Mark Crispin: "%" routing] [The Postmaster: Re: "%" routing] The following may be of interest. The problem arose when UCL-CS mapped an address like aaa%bbb@ccc into <@ccc:aaa@bbb>. SCORE could only interpret the first form. Whilst this is incorrect in a pure DARPA Internet context, note the problems in the UK context. Steve Kille ----- Forwarded message # 1: Via: 44b.Ucl-Cs.AC.UK; to 44a.Ucl-Cs.AC.UK over Inter-UNIX with SMTP; 27 Sep 83 20:00 BST Via: Su-Score.arpa; to 44b.Ucl-Cs.AC.UK over Satnet with SMTP; 27 Sep 83 19:56 BST Date: Tue 27 Sep 83 11:56:07-PDT From: Mark Crispin Subject: "%" routing To: mmdf@ARPA.Ucl-Cs Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Actually, the use of "%" as an alternative "@" was developed independently; I confess to not being the first person to ever use it as such though. The important thing, though, is no matter what the semantics of your local environment you should never make assumptions about foreign semantics. At best, you can assume the semantics of entities in your own local environment; for example, UK hosts may agree to use "%" as a source route just as non-IP hosts on the Stanford LAN (a 3MB Ethernet) must also do. But UK cannot make assumptions about Stanford's semantics, neither can Stanford do so about UK. The failure in your mailer was in not recognizing that the entity on the right half of the "@" was external to the UK and so it isn't correct to do any special handling of the left half other than to send it in "virgin" form. After all, for all you know "%" could be part of a user name at a Stanford computer! -- Mark -- ------- ----- Forwarded message # 2: Date: 28 Sep 83 8:15:23 BST (Wed) From: The Postmaster (44a) To: Mark Crispin cc: mmdf@UK.AC.Ucl-Cs Subject: Re: "%" routing I will not argue about the history of the % route. I suspect that you will find that the UK has been using it for a good deal longer than you think. (Although I do realise that the original suggestion came from the other side of the Atlantic). I do not regard the UK use of "%" as a local decision. The UK network is comparable in size to the DARPA Internet, and has its own mail protocol which happens to be based on RFC 822. The address syntax is different. (I will make the next revision available to the Internet community at some stage). Note that I am not in favour of the differences. However, they exist. I agree that I am being a little sloppy not to note which protocol environment a message comes from and handle it accordingly. The differences are subtle, and the effort would be non trivial. (There are many reasons why the UK cannot be treated as a local stub network). Note a much harder problem: If your message is relayed to a remote UK site, how can I tell what to do with the return path generated by such a site. The original specification may have been either as a % route or an 822 route. I am forced to always guess the latter. Having said all that, I have no immediate intentions to change our % handling. It should be regarded as a peculiarity of message relaying to the UK. I would encourage all Internet sites which use this format to only use it as an alternative specification of a source route. Steve ----- End of forwarded messages  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2611069409372234@MIT-MULTICS.ARPA>; 28 Sep 1983 13:03:29 edt Date: Wed, 28 Sep 83 11:11:46 EDT From: "Gavin Eadie"@UMich-MTS.Mailnet To: Mishkin@MIT-Multics.ARPA, header-people@MIT-MC.ARPA Message-ID: <239238@UMich-MTS.Mailnet> Subject: A Random Gripe For what it's worth, I'll add to Nat's plea for quoting names containing period characters. Our mail system allows names of the form he described which contain all sorts of strange things: Dr. Ding D'Ong Sr. We occasionally get incoming mail with names un-delimited and my RFC822 parser would have to be a lot smarter to deal with all the illegal possibilities!  Date: Thu 29 Sep 83 17:02:37-PDT From: Mark Crispin Subject: Re: [Mark Crispin: "%" routing] To: mmdf@UCL-CS.ARPA cc: mailgroup@UCL-CS.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "The Postmaster (44a)" of Wed 28 Sep 83 08:39:15-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is in response to Steve Kille's message regarding Score's apparently inability to interpret "<@ccc:aaa@bbb>" as being equivalent to "aaa%bbb@ccc". In the particular instance of this which came up, the bbb value was a site on Stanford's LAN in a naming registry external to Internet (what Steve refers to as a "local stub network"). For the lack of an official naming specification for stub networks, the TOPS-20 mailer has a concept of "relative domains". A "relative domain" is one which is relative to a single host, and is distinguished by the presence of a "#" symbol (which Jon Postel assured me would never be used by a real domain). Such "relative domains" are tied to the physical naming registry they refer to; consequently we have names such as #Pup, #Chaos, and #DECnet for Pup Ethernet, Chaosnet, and DECnet. There is no relative domain name for Internet because the absolute domain name ARPA exists. These relative domain names exist for the convenience of the TOPS-20 sites which act as mail bridges. They allow for an exact determination of what naming registry to look the host up in. Otherwise, a priority algorithm must be selected. For example, suppose a TOPS-20 site is on ARPANET, a Pup Ethernet, and a Chaosnet, and each of these networks have a member called FOO but they all refer to different systems! FOO.ARPA, FOO.#Pup, and FOO.#Chaos would each refer to a unique FOO host. Otherwise, given the name FOO it would have to guess; the current priority algorithm is to prefer FOO.ARPA. I forget the exact names now, but the address in question was something like JONES%GSB-How.#Pup@SU-SCORE.ARPA. This means "JONES@GSB-How on the Pup Ethernet that SU-SCORE.ARPA is connected to". GSB-How is not presently an Internet host and is not in the Internet host table, which is why the TOPS-20 mailer (whether at Score or GSB-How) used this address syntax. According to both the SMTP and the RFC 822 specifications, any host name entity must be a valid Internet host name. As a result the TOPS-20 mailer goes to great lengths to shield all external parties to this syntax by hiding it on the left hand side of the "@" where in theory nothing but the mailer on the entity identified by the right hand side has the right to parse. The UK mailer converted this address to something like @SU-SCORE.ARPA:JONES@GSB-How.#Pup, which the Score SMTP server declined to accept. This is because "GSB-How.#Pup" is not a valid Internet host name; it isn't until the message goes to the Score mailer daemon that concepts such as that are understood. This is what happened at Score's end. I don't wish to finger point so much as state that operationally, the TOPS-20 mailer depends very much upon its present behavior just as the UK mailer depends upon its behavior. We have encountered a conflict between the two and of course the Internet standards are on my side. I don't want to take the simplistic stand of "the UK mailer is at fault and they should fix their software." This is clearly desirable in the long-term, but sometimes various technical and political considerations make this difficult. After all, who am I to criticize when I have my own wars of this nature to fight? But, what will happen should a site appear which has the "%" character in its user names? Literally, the way relaying is done by the TOPS-20 mailer is to make "%" part of a pseudo-user name that only at a much lower level is interpreted as an "@". The Powers That Be state that Thou Shalt Not Have Non-Internet Names; I construe this as meaning that I cannot use source routing because the names I would use are non-Internet. I do in fact use source routing when I am dealing with Internet names. I look forward to an intelligent non-inflammatory exchange of messages on this subject. -- Mark -- -------  Received: from SCRC-YAMASKA by SCRC-SPANIEL with CHAOS; Fri 30-Sep-83 09:10:48-EDT Date: Fri, 30 Sep 83 09:11 EDT From: Charles Hornig Subject: Re: [Mark Crispin: "%" routing] To: Mark Crispin , mmdf%UCL-CS@MC.ARPA Cc: mailgroup%UCL-CS@MC.ARPA, header-people@MC.ARPA In-reply-to: The message of 29 Sep 83 20:02-EDT from Mark Crispin Message-ID: <830930091132.3.Hornig@SCRC.SCRC> As I remember, the "%" convention was adopted for the sole purpose of making the transition from old NCP-FTP mail to SMTP. The "%" was chosen precisely because it was unlikely to have any syntactic meaning in any existing mailers. After all, it only had to be interpreted in the NCP/TCP mail bridges, and then only for non-SMTP mail. A simple kludge to cover a simple problem. Things haven't worked out that way. Using "%" has become the standard way of specifying a mail route since we have been forbidden by the `powers' from using the RFC 822 syntax. While "%" may have been a good temporary solution to the NCP mail transition, it was not well thought out as a permanent routing mechanism. I think that it is showing its weaknesses here. I hope that I will soon be able to be "@MIT-MC.ARPA:Hornig@SCRC.SCRC" rather than the mess you see in the header. -- Charlie Hornig  Date: 1 October 1983 22:29 est From: DBrown.TSDC at HI-MULTICS Subject: % redux To: Header-People at MIT-MC I notice that the traditional "%" kludge is still acceptable to ARPAnet, even as domain-time draws near (well, at least I hope it draws near...). I also notice a definite similarity between the foo%bar@grud.arpa notation and the future foo@bar.grud.arpa notation, especially if the gateways to the domains are the machines currently interpreting the % and forwarding into their domains. I wonder if it is: (a) legal, and (b) advisable to use the % as an arpa-compatable notation to represent dots in the future domain notation. I should like to be able to send mail to idallen % watmath @ uucp . ARPA (without the spaces) and be able to interpret it as: @ . . ARPA even though it really means @ . . ARPA (Please note that this is subtely but definitely different from the % used as an explicit router, as in @grud.arpa:foo@bar.something_else) What say you all? --dave drbrown @ watbun.UUCP DBrown.TSDC @ HI-MULTICS.ARPA  Received: by YALE-BULLDOG via CHAOS; Sun, 2 Oct 83 11:14:37 EDT Received: from YALE-RING by YALE-RES via CHAOS; Sun, 2 Oct 83 11:10:54 EDT Subject: USENET vs. UUCP Date: Sun, 2 Oct 83 11:10:56 EDT From: Nathaniel Mishkin To: header-people@MIT-MC.ARPA Despite the apparent pessism of some people that "the powers that be" will ever deign to let the world have domain names of its own, I think that the day of domains will be on us sooner than we think. So, before things get completely messed up on one small front...is there a consensus on whether the DOMAIN of (typically Unix) machines passing around mail and news via a protocol called UUCP should be called "USENET" or "UUCP"? In the present world of unofficial domain names I have seen both names used. It seems that the right name is USENET. I don't really care which it is, just that a standard name be chosen. -- Nat  Date: Sun 2 Oct 83 17:13:50-PDT From: Mark Crispin Subject: Re: % redux To: DBrown.TSDC@HI-MULTICS.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "DBrown.TSDC at HI-MULTICS" of Sat 1 Oct 83 22:29:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It is my claim that a%b@c should be interpreted now as meaning "user a%b at host c". Any interpretation of routing belongs solely to host c. The problems the UK is having now with such messages illustrates the sort of fix you can get into. In the UK context, "%" is explicitly defined as meaning routing and there is apparently no means by which it can be an ordinary character. The TOPS-20 mailsystem uses "%" only because it has no choice. It uses source routing whenever it can, but it was decreed by The Powers That Be that one cannot have a non-Internet host name in a source route. Needless to say that pretty much makes source routes useless except perhaps as debugging traces. I would be happy to migrate to domains. But... there are still hosts which don't accept ".ARPA" and complain bitterly about mail with the ".ARPA" domain. A few sites, e.g. the NIC and ISI, made a local change to the TOPS-20 mailsystem not to generate ".ARPA" (the distributed version does). If the NIC and ISI are unwilling to support the standards, what hope is there for the rest of the world? -------  From: vortex!lauren at RAND-UNIX Date: Sunday, 2-Oct-83 23:19:03-PDT Sender: Lauren Weinstein Subject: UUCP domain To: HEADER-PEOPLE@MC CC: decvax!cbosgd!mark The domain should *definitely* be: UUCP "Usenet" is a logical information system of computers exchanging newsgroup information of various sorts, and is essentially separate from the mail transport network that lies underneath. Some sites which receive Usenet "netnews" newsgroups receive their groups via ARPA or other mechanisms, NOT necessarily via UUCP. On the other hand, all sites running UUCP (that are publicly connected, of course) can be considered to be part of the UUCP "domain" for mail exchange. In other words, UUCP is a transport mechanism and provides a physical network (and is rightly a domain) while "Usenet" is a collections of computers passing certain sorts of information between themselves, and is not an actual network in the normal sense of the word. Unfortunately, the two terms are often used interchangeably in messages -- a practice that is, admittedly, to be discouraged. --Lauren--  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 3 Oct 83 15:36:46 PDT Via: UNKNOWN-HOST; (src/csmail/listen); to 44d.Ucl-Cs.AC.UK over Sercnet with NIFTP; 3 Oct 83 20:19 BST From: Jonathan Mills (on GEC 4090 at Rutherford) To: Header-People Date: Mon, 3 Oct 83 15:30 BST Subject: Message-IDs Message-Id: <03 OCT 1983 15:38:44 NSIN24@RLGK> Cc: MsgGroup As I seem to get multiple copies of messages from the State's mailing list i decided to sit down today and write some code that eliminates duplicate messages. My code was based on the MESSAGE-ID field contents, and the idea was that if two MESSAGE-ID fields were the same, I could discard one of the messages. However, when I fired up the code, I set it to work on my collection of HEADER-PEOPLE and MSGGROUP mail, and it said it found 1 duplicate message. I then discovered that very few of the states mailers seem to stamp MESSAGE-ID fields - Is there a good reason for this? (Actual figures were that only 25 out of 80 messages had MESSAGE-IDs) Jonathan  Date: Mon, 3 Oct 83 22:18:29 EDT From: Doug Kingston To: DBrown.TSDC@hi-multics cc: Header-People@mit-mc Subject: Re: % redux Either I'm missing something (not likely), or the use of percent (%) is being blown out of proportion. The only valid use for % is to the left of the @ and it is only to be interpreted at the mail destination specified by the domain address to the right of the @. In the example: fred%destA@destB.subdom.ARPA "fred%destA" must not be modified or re-interpreted until given to the mail destination or mail forwarder specified by "destB.subdom.ARPA". You cannot assume anything about how the destination host will use the %. "fred%destA" must be treated as a local address at destB.subdom.ARPA until it reaches that destination at which point that host can do anything it cares to with the address. Remember, "destB.subdom.ARPA" may not even specify a host, it may specify only a logical mail destination which will map to more than one host via the nameserver mechanism. Cheers, -Doug-  Date: 4 Oct 1983 00:19-PDT Sender: ESTEFFERUD@USC-ECL Subject: Re: Message-IDs From: Einar Stefferud - Mssgroup Moderator Reply-To: Msggroup@BRL To: NSIN24%rlgk@BRL Cc: Header-People@MIT-MC, MsgGroup@BRL Message-ID: <[USC-ECL] 4-Oct-83 00:19:30.ESTEFFERUD> In-Reply-To: <03 OCT 1983 15:38:44 NSIN24@RLGK> With some fear and trepidation, I want to strongly suggest that this discussion of whether or not to ID messages should flow in Header-People only, since this is a relativley operational issue. The last time I requested this, I discovered an immense inertia among the contributors who basically ignored my request entirely. Lets not do that this time. Thanks - Stef  Date: Tue 4 Oct 83 04:01:36-PDT From: Mark Crispin Subject: Message-ID's To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have never been convinced of the real utility of Message-ID's. Several mailsystems which once generated them no longer do so, mostly because people found them obnoxious. It would be totally trivial for the TOPS-20 mailsystem to generate a Message-ID. It does not do so, mostly because I have the belief that the user feeling against Message-ID's is greater than that for them. My feeling has always been that Message-ID's are not the panacea that certain individuals think they are in removing duplicated messages. Sometimes messages get redistributed with additional comments but without altering the Message-ID. I've seen this happen enough to distrust any software which censors duplicate Message-ID messages, but I'll confess to an intrinsic distrust of all such "overly intelligent" (from my point of view) automation. I believe that a good pattern-matcher and discriminator would do a much better job of flushing extra copies of messages than anything which depends upon Message-ID's. -- Mark -- -------  Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 4-Oct-83 08:43:32-EDT Date: Tue, 4 Oct 83 08:40 EDT From: Robert W. Kerns Subject: Message-ID's To: Mark Crispin Cc: Header-People@MIT-MC In-reply-to: The message of 4 Oct 83 07:01-EDT from Mark Crispin Message-ID: <831004084004.9.RWK@SCRC.SCRC> Date: Tue 4 Oct 83 04:01:36-PDT From: Mark Crispin I have never been convinced of the real utility of Message-ID's. Several mailsystems which once generated them no longer do so, mostly because people found them obnoxious. Much less obnoxious than the following two! Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) But I only mention that to make the point that they aren't very obtrusive, especially given all the other header fields RFC822 stuffs in. It is becoming more and more useful for mail reading programs to filter what headers they actually show you. Given this capability, the "obnoxious" aspect is quite irrelevant. Granted, it may be ten years before everybody HAS that capability, but if they're obnoxed by Message Id, they're surely going to be obnoxed by Recieved: and Via: It would be totally trivial for the TOPS-20 mailsystem to generate a Message-ID. It does not do so, mostly because I have the belief that the user feeling against Message-ID's is greater than that for them. Might I suggest that this may no longer be true? Admittedly, this is based on a sample of one (me). I used to be quite opposed to them, but now my feelings are much closer to making them mandatory! (Relax, I would only argue for that in the context of a redesign with evelope/text distinctions). Eliminating of duplicated messages is only one use for Messages-ID's. Zmail has a command which tries to delete duplicated messages based on either the Message-ID if present, or a combination of Date and From. I can assure you that Message-ID is much safer. But anybody who redistributes messages with additional comments had better not expect any response from me, because he's got a 50% chance or less of my ever noticing that the length on one message is longer than on the other. I believe that a good pattern-matcher and discriminator would do a much better job of flushing extra copies of messages than anything which depends upon Message-ID's. Anything that has the same header fields stands a good chance to not be read by anyone using a mail reader that lets you pick and choose messages. I claim that comparing Message-ID's is substantially better than the human mechanism likely to already be in place. Of course, I have no objection to using a pattern matcher for final comparison, but I don't think it's worth the effort.  Date: 4 Oct 1983 1106-EDT From: Larry Campbell To: Mark Crispin cc: Header-People at MIT-MC Subject: Re: Message-ID's Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11956815040.31.71.26901 at DEC-MARLBORO> References: Message from Robert W. Kerns of 4-Oct-83 0850-EDT In-reply-to: <831004084004.9.RWK@SCRC.SCRC> Might I add that at least one mail system (MS) copies the original message-ID to the (I think) "In-reply-to" field of any replies you generate, and has a command ("read related-messages") to recursively trace back through a conversation. Very handy when you get a reply that says merely "yes", and have forgotten what the original message was. Of course, this is only useful if the people on the other end of your mail conversations are using a mail system that replicates the message-ID that way, but at DEC, anyway, everyone on a 20 (well, ALMOST everyone) uses MS. --------  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 4 Oct 83 08:52:52 PDT Via: 44a.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK over Inter-UNIX with SMTP; 4 Oct 83 16:46 BST Date: 4 Oct 83 16:40:06 BST (Tue) From: Steve Kille (44a) To: Doug Kingston cc: DBrown.TSDC@hi-multics.arpa, Header-People@mit-mc.arpa, mailgroup@ucl-cs Subject: Re: % redux In the Internet context, Doug is right. "%" should not be treated as a synonym for "@" or ".". I look forward to seeing the RFC 822 convention for source routes being used. In the UK context, "%" is treated differently. We have a different address syntax. To send a "%" from the UK to the Internet it must be quoted. Otherwise, the UK source route fred%domain1@domain2 should be transformed to the Internet source route <@domain2:fred@domain1>. UCL, being in both environments has a problem! I was using this as an excuse for behaving sloppily in the Internet environment. I have to admit that this won't do. I will thus be forced to use different parsers for the two environments. This will ensure correct behaviour in both environments. Steve  Date: 8 October 1983 03:58 edt From: Frankston.SoftArts at MIT-MULTICS Subject: Re: Message-ID's Sender: SAI-relay.SoftArts at MIT-MULTICS Reply-To: Frankston at MIT-MULTICS (Bob Frankston) To: Mark Crispin , Header-People at MIT-MC *from: BOB (Bob Frankston) Local: Mark Crispin ,Header-People@MIT-MC.ARPA, cc:BOB:sent.po Original-date: 08 OCT 1983 00:09:48 When half my screen is filled with something like: Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:MRC@SU-SCORE.ARPA> Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 04-Oct-1983 07:02:39-edt Date: Tue 4 Oct 83 04:01:36-PDT From: Mark Crispin Subject: Message-ID's To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I don't understand why people get upset with a single line of message-id added. PS: This is one of the shorter examples of headers. It seems that the mail-related mailing lists seem to have the largest and most encrusted mail headers on the network.  Date: 9 October 1983 10:29 edt From: Frankston.SoftArts at MIT-MULTICS Subject: Re: Message-ID's Sender: SAI-relay.SoftArts at MIT-MULTICS To: Brint Cooper , Mark Crispin , Header-People at MIT-MC Actually, mail reader doesn't happen strip header fields. But if the program did strip them, then it makes it even more obvious that there is no inconvenience to the user in having the good old message ID. PS: If this message doesn't have a message-id when you get it, then someone in the middle has stripped it -- I don't know who.  Date: Sat, 8 Oct 83 15:35:20 PDT From: Rich Wales To: Header-People@MIT-MC Subject: Multiple recipients/messages in SMTP *************************************************************** ** This is a request for information and comments directed ** ** specifically to implementors of SMTP server programs. ** *************************************************************** RFC821, the SMTP document, states that SMTP servers must be able to accept at least 100 recipients per message (see Section 4.5.3 on page 43). It also seems to imply that an SMTP server is supposed to be able to accept an unlimited number of separate messages in a single connec- tion with a foreign host (although I can't find any passage which ex- plicitly demands that this capability must exist). However, since many sender (mailer) programs currently used in the In- ternet apparently send only one message per connection and specify only one recipient per message, I am hesitant to assume that all SMTP server programs really do handle multiple messages and/or multiple recipients properly. I am therefore trying to construct an SMTP sender which can specify multiple recipients per message and send multiple messages per connection -- but which will downgrade gracefully to single-recipient and/or single-message mode when confronted with a "dumb" server. I designed a "sender" strategy which does not assume that a "dumb" SMTP server will act in any particularly predictable or coherent way when presented with multiple recipients per message or multiple messages per connection. Basically, if I were to get an error while doing multiple recipients and/or multiple messages, I would retry the rejected command in a single-message, single-recipient context before assuming that the error was permanent. Perhaps, though, I am being overly pessimistic as to the present state of SMTP servers. If I can make a few more assumptions regarding the way servers act in the face of errors, then I think I can relax my con- straints considerably. Therefore, I would like to know how the SMTP servers used by Internet hosts today rate with respect to the following suggested standards: ==> If a RCPT or DATA is received in an unexpected context (e.g., no message transaction in progress, or no valid recipients specified before a DATA command), the server will ALWAYS use a 503 reply code. ==> If a RCPT is received and the recipient address is acceptable, but no more recipients can be handled for this message, the server will use either a 400-series reply code (i.e., a reply code whose first digit is 4) or a 552 reply code. ==> If a MAIL command is received and the return path is acceptable, but the message cannot be handled for some reason (e.g., the server can only handle one message per connection), the server will use either a 400-series reply code or a 552 reply code. ==> The only reply codes which the server will ever use in response to a DATA command are 354 and 503 -- except if a temporary processing error arises, in which case a 400-series reply code will be used. ==> The server will use a 500-series reply code at the very end of a message transaction (i.e., after the text of the message has been transmitted by the sender) ONLY if the message is so unreasonably long that it would never be accepted even under ideal conditions. If the above properties hold for all SMTP servers on the Internet, then I believe I can safely assume that any MAIL or RCPT command rejected with a 500-series reply code other than 503 or 552 -- or any message text rejected with any 500-series reply code (including 552) -- would never be accepted by the server under any circumstances, and thus need not be retried later in a single-message/single-recipient scenario. I would particularly like to know if there are any SMTP servers on the Internet today which do NOT act as I have described above -- and if not, specifically how not. Also, if someone believes that SMTP servers should not act as I have described above, I would like to hear your reasons. Please reply to me directly if possible; I will summarize to the mail- ing list in a couple of weeks. -- Rich  Date: Mon, 10 Oct 83 22:00:04 EDT From: Mike Muuss To: Frankston.SoftArts@mit-multics cc: Header-People@mit-mc, abc@brl-vgr Subject: Filtering Headers on Display to User The mail reader used at BRL ("msg") by default removes many of the more "obnoxious" header fields. The user can easily tailor the list of fields to be displayed or removed, and the operation of the filter may be toggled at any time. This makes mail reading a real pleasure. Especially when on a slower terminal, such as dialing in from home, or when on travel. Our default list of fields to filter includes: via, remailed-from, remailed-to, message*, sender, mail*, article*, received*, origin*. (remailed-by is left in, to alert the reader to the extra step in his receiving the message). Message* matches message-id. -Mike  Date: Tue, 11 Oct 83 14:57:59 PDT From: Rich Wales To: Header-People@MIT-MC Subject: More on multiple recipients/messages in SMTP I have a couple of additional questions regarding the state of SMTP servers today. (1) Does anyone's SMTP server have a limit to the number of recipients it will accept per message transaction? If so: (a) What is your server's limit? (b) What reply code do you use when rejecting a RCPT command which attempts to go beyond the limit of your server? (c) Are you reasonably certain that your server will not "break" if presented with too many recipients in a transaction? (2) Same as (1), but this time regarding limits to the number of mes- sages which your SMTP server will accept per connection. (3) Are there any conditions under which your SMTP server will react to an error condition by aborting the entire transaction currently in progress and reverting to a "waiting for MAIL command" state? As with my previous inquiry, please respond directly to me if possible and I will summarize everything to the mailing list in a couple of weeks. Thanks. -- Rich  Date: 08 Oct 83 11:51:43 PDT (Sat) From: Marshall Rose Return-Path: Subject: Re: Message-ID's Reply-To: MRose@UCI Message-Id: <267.434487103@UCI> To: Frankston@Mit-Multics Cc: Mark Crispin , Header-People@Mit-Mc In-Reply-To: Your message of 8 October 1983 03:58 edt. Via: UCI; 8 Oct 83 12:00-PDT Well, I haven't seen a Message-ID, or Received, or ... header since I've been using Rand's MH. If I want to search on a pattern in them, however, I still can. These fields are useful, providing that I don't have to see them every time I look at a message, unless I explictly ask for them. I'd much rather see a push for everyone getting more sophisticated mail viewing software, than for us to scrutinize every byte in the headers. Just out of curiosity, how many people out there have the capability to view selected parts of the message header? Please reply directly to me, I don't want to clutter-up this list with a whimsical curiosity. /mtr  Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 11 Oct 83 4:41 EDT Date: Sat, 8 Oct 83 12:53:46 EDT From: Brint Cooper (CTAB) To: Bob Frankston cc: Mark Crispin , Header-People@mit-mc Subject: Re: Message-ID's PS: This is one of the shorter examples of headers. It seems that the mail-related mailing lists seem to have the largest and most encrusted mail headers on the network.  I know that this has been asked before, but doesn't your mail program strip all specified, unwanted header lines from what it displays to you? If you have this capability, you don't need to care how long the header is; you won't see it. Brint  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 12 Oct 83 03:03:38 PDT Via: 44c.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK over Inter-UNIX with SMTP; 12 Oct 83 10:51 BST Date: 12 Oct 83 10:37:29 BST (Wed) From: Bruce Skingle (44c) To: mrose.uci@rand-relay.arpa cc: Frankston@mit-multics.arpa, Mark Crispin , Header-People@mit-mc.arpa Subject: Re: Message-ID's and mail viewing software I was very interested to see your message about sophisticated mail viewing software, as I am about to embark upon a project to produce a new user interface for both the mail and news systems here at UCL. Presently we are using MSG for mail and READNEWS for news, and it is my intention to replace both of these with a single utility. I do have several ideas for what it should do but I will be grateful for any suggestions. Bruce Skingle.  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 10 Oct 83 14:38:45 EDT Date: 10 Oct 83 1449 EDT From: Rudy.Nedved@CMU-CS-A To: Rich Wales Subject: Re: Multiple recipients/messages in SMTP CC: Header-People@MIT-MC In-Reply-To: "Rich Wales's message of 8 Oct 83 17:35-EST" Message-Id: <10Oct83.144903.EN0C@CMU-CS-A> Rich, Please note a problem exists with "application level timeouts" versus "multiple recipients". Most Unix sites can accept a number of recipients but delivermail copies the data to each recipient while the SENDER WAITS. The result is when a mailing list like SF-Lovers sends out a large text message and the connected machine has alot of individuals receiving it...the sender timeouts waiting for the '250 ack' and punts. The sender retrys later, meanwhile delivermail is busy delivering mail. Voila, infinite duplicate mail until one of the mail maintainers sender or receiver fixes it. Probably using some formula for a timeout that is dependent on the size of the message and the number of recipients will do the trick. -Rudy  Received: from EDUCOM by MIT-MULTICS.ARPA with Mailnet id <2612381548701548@MIT-MULTICS.ARPA>; 13 Oct 1983 17:32:28 edt Date: 10-OCT-1983 17:56 EDT From: OBERST@EDUCOM To: Header-People@mit-mc.arpa Subject: Quoted @ in To: field From: MAILNET 9-OCT-1983 19:07 To: OBERST Subj: MAILNET MAIL From:<@MIT-MULTICS.ARPA:"Jacob Palme QZ"@ODEN.MAILNET> Received: from ODEN.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2612022005559524@MIT-MULTICS.ARPA>; 09 Oct 1983 13:40:05 edt Date: 09-Oct-83 12:29-+0100 From: "Jacob Palme QZ"@ODEN.MAILNET Reply-to: "Jacob Palme QZ"@ODEN.MAILNET, "Mail transfer (between) York (and) QZ COM/POST systems"@ ODEN.MAILNET To: "Mail transfer (between) York (and) QZ COM/POST systems"@ ODEN.MAILNET, OBERST@EDUCOM.MAILNET bcc: "Richard Edmiston CSNET" Subject: "Jacob Palme QZ@ODEN.MAILNET"@MIT-MULTICS.ARPA Message-ID: The subject of this message indicates a TO-field in an incoming message from SU-SCORE which I got via ARPANET-MAILNET. As I understand it, such a TO-field would indicate a person with the name "Jacob Palme QZ@ODEN.MAILNET" since the quotation marks would invalidate the interpretation of "@" as a "at-host" indication. However, obviously the person sending this message meant the "@" to be an at-host indication, even though it was inside quotation marks. How shall I handle this? Follows the RFC-standards, and getting false information in my data base. NOT POSSIBLE. Interpret "@" as an "at-host" sign even when it appears inside quotation marks, in flagrant violation of the RFC-standards, and get the COM-MAILNET interface working properly. I guess this is the only reasonable possibillity!! Should I also interpret "%" in incoming messages from JNT-mail as an "at-host" indication even when it appears inside quotation marks?? (Text 25995)------------------------------ (1 comment)  Date: Thu, 13 Oct 83 20:22:20 EDT From: Doug Kingston To: Header-People@mit-mc Subject: Re: [OBERST%educom: Quoted @ in To: field] The letter to Header-People was illegal in and of itself since "educom" is not a known Internet host and MC should not have allowed the address onto the Internet to begin with with out munging the address. BRL was forced to stick a "BRL.ARPA" on it to make it appear reasonable. Someone should fix MIT's mailer as a start. -Doug-  Date: Thu 13 Oct 83 19:18:00-PDT From: Mark Crispin Subject: Re: Quoted @ in To: field To: Header-People@MIT-MC.ARPA In-Reply-To: Message from "OBERST@EDUCOM" of Mon 10 Oct 83 17:56:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) So far as I understand, what is within a quoted string on the left half of the @ is strictly for the entity named in the right half of the @ to interpret. Score's software does not generate addresses such as "a@b"@c. However, a Score user (or another system relaying through Score) isn't prevented from doing this. Also, if you see an address such as a%b@c, you have no business trying to parse the "%b" as meaning "at host b" UNLESS you are entity c. If you are entity c, then you have total freedom to interpret it as whatever you like. a%b could mean "send to a but give user b a raise in salary" for all anybody other than c should know, or care. -- Mark -- -------  Date: Thu 13 Oct 83 19:18:00-PDT From: Mark Crispin Subject: Re: Quoted @ in To: field To: Header-People@MIT-MC.ARPA In-Reply-To: Message from "OBERST@EDUCOM" of Mon 10 Oct 83 17:56:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) So far as I understand, what is within a quoted string on the left half of the @ is strictly for the entity named in the right half of the @ to interpret. Score's software does not generate addresses such as "a@b"@c. However, a Score user (or another system relaying through Score) isn't prevented from doing this. Also, if you see an address such as a%b@c, you have no business trying to parse the "%b" as meaning "at host b" UNLESS you are entity c. If you are entity c, then you have total freedom to interpret it as whatever you like. a%b could mean "send to a but give user b a raise in salary" for all anybody other than c should know, or care. -- Mark -- -------  Date: Thu 13 Oct 83 19:24:31-PDT From: Mark Crispin Subject: Re: [OBERST%educom: Quoted @ in To: field] To: dpk@BRL-VGR.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Doug Kingston " of Thu 13 Oct 83 17:37:19-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Re: "MIT's mailer should mung the header" No! Header munging is a horrible idea. The source of the message should take responsibility for generating valid headers, without any second-guessing from various relays. Too many valid headers have been munged into nonsense by well-meaning, but incorrect, header munging algorithms. It is also impossible to debug a problem with an incorrect header if some host mungs it. Who can tell which part was done by the originating host, and which by the munging host? -------  Date: Thu, 13 Oct 83 22:43:17 EDT From: Doug Kingston To: Mark Crispin cc: dpk@brl-vgr.arpa, Header-People@mit-mc.arpa Subject: Re: [OBERST%educom: Quoted @ in To: field] I wish I didn't have to mung, but as long as people continue to generate illegal headers, or we must deal with primative mail systems, this will be a necessity if mail is to flow. You can always ask those involved. But not very many people appear to be interested in fixing their mailers. I expect that munging, as distasteful as it is, will continue until all hosts have transitioned to RFC822. -Doug-  Received: by ucbvax.ARPA (4.12/4.7) id AA03659; Thu, 13 Oct 83 20:57:25 PDT Date: 12 Oct 83 15:51:22 EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Usenet vs UUCP Message-Id: <8310121951.AA12255@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA12255; 12 Oct 83 15:51:22 EDT (Wed) To: header-people@mit-mc.ARPA (I've been out of town for a week, so to remind everyone:) So, before things get completely messed up on one small front...is there a consensus on whether the DOMAIN of (typically Unix) machines passing around mail and news via a protocol called UUCP should be called "USENET" or "UUCP"? In the present world of unofficial domain names I have seen both names used. It seems that the right name is USENET. I don't really care which it is, just that a standard name be chosen. I concur with Lauren. While many people refer to the UUCP net as Usenet, they are misusing the term. Usenet is defined as "all sites getting the network newsgroup net.announce", or loosely "all sites getting netnews". UUCP is defined as "all sites reachable by electronic mail from ucbvax via the hosta!hostb!...!hostn!user notation". What is important is that these two sets of machines are not the same. There are roughly 600 machines on Usenet. There are an estimated 2000 machines on UUCP. Almost every Usenet machine is also on UUCP, although many of them are on other networks (including the ARPANET) as well. Note that the definition for UUCP given here is a mail definition, e.g. the primary use of UUCP is for electronic mail. This defn does not imply that UUCP is actually used as a transport protocol. Some systems use some other LAN instead of UUCP. (E.g. in the United Kingdom they use something else; in Bell Labs some sites use RJE links via an IBM host.) A few systems even implement the UUCP protocol over some other transport protocol (e.g. over a TCP connection.) It seems like the "reachable via !" defn is more useful, since the primary thing one wants to do is send mail. The primary use for a central registry would be a mail routing program. (The other functions supported by the raw protocol, namely file transfer and remote execution, are only supported via direct links - no routing is allowed. Remote login is not supported at all by UUCP, making remote login or file transfer gateways from UUCP into an Internet impossible.) One concern that has been expressed is that there is a central contact person for Usenet, and a master list of sites kept up-to-date. There is no such person or list for UUCP, and these must exist to be allowed by ARPA as a top level domain. It has been suggested that since a domain is intended to be a registry and not a transport mechanism, it might make sense for Usenet to be a top level domain instead of UUCP. My main reason for disagreeing with this is that if Usenet were the top level domain, it would be impossible for those other 1400 sites to get mail. Since domain overlap is possible, I suppose it might make sense for BOTH Usenet and UUCP domains to exist. Since having a top level domain is a moot point right now (there is only one top level domain, no matter how qualified any other domain might be), it's really a matter of planning and naming of existing hosts. There is a plan being worked on for a central registry of UUCP hosts. If this plan is successful, it will make sense for UUCP to become a top level domain, or at least as high in the tree as the CSNET, ARPA, and X.25 domains are likely to become. (I am speculating about X.25 - perhaps there will be a PUBLIC domain or some other name to describe Tymnet, Telenet, Datapack, etc.) We expect to determine within about 3 months whether such a UUCP registry can be funded. If not, something else will have to be worked out, as I am convinced there is a strong need for such a registry. Mark Horton mark@Berkeley.ARPA mark@cbosgd.UUCP  Received: by ucbvax.ARPA (4.12/4.7) id AA03690; Thu, 13 Oct 83 20:58:45 PDT Date: 12 Oct 83 16:31:58 EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Message-ID's Message-Id: <8310122031.AA12563@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA12563; 12 Oct 83 16:31:58 EDT (Wed) To: header-people@mit-mc.ARPA Sometimes messages get redistributed with additional comments but without altering the Message-ID. Doesn't this violate RFC822? I fail to see why protection of implementations that violate the standard should be the reason for a policy decision. For what it's worth, in Usenet, the Message-ID is CRUCIAL. Without it we would be flooded with duplicate messages. (Sometimes we are anyway, but that's because some program has broken and keeps feeding the message to inews, which keeps generating a new Message-ID.) RFC850 requires the Message-ID on all Usenet (news) messages. Using the Message-ID to weed out duplicate mail at the transmission level (e.g. to prevent loops) is harder than with news, since mail is sent to a mailbox or person, but news is broadcast everywhere. With news, if you've seen the article before on this machine, you can toss it. With mail, you must remember the (Message-ID, To) pair (the "envelope" sense of "To") and only discard if the same pair arises, otherwise mailing lists and routed messages can cause messages to be lost. I personally would like to see Message-ID be made mandatory. Mark  Posted-Date: 13 October 1983 23:52 edt Acknowledge-To: Barry Margolin Date: Thursday, 13 October 1983 23:48 edt From: "Barry Margolin"@MIT-MULTICS.ARPA Subject: Re: Quoted @ in To: field To: Header-People@MIT-MC.ARPA Message-ID: <831014034818.442753@MIT-MULTICS.ARPA> Since the @ was quoted, it is part of the local-address portion, and no one except MIT-MULTICS (the hub of the Mailnet star) should be interpreting it. This is the "correct" way to do what everyone's been doing with % for a long time. Once it gets to Multics, it will strip off the quotes and recognize this as a message which should be forwarded to the Mailnet host, but that is its business, just as recognizing that "Margolin" means to send it to my mailbox. Please don't try to subvert this well-defined mechanism by interpreting stuff to the left of the @. barmar  Posted-Date: 14 October 1983 11:08 edt Date: Friday, 14 October 1983 11:05 edt From: "Jeffrey I. Schiller"@MIT-MULTICS.ARPA Subject: What to do about non-Internet mail hosts. To: Mark Crispin cc: dpk@BRL-VGR.ARPA, Header-People@MIT-MC.ARPA, Postel@USC-ISI.ARPA, Saltzer@MIT-MULTICS.ARPA, DClark@MIT-MULTICS.ARPA Message-ID: <831014150557.162930@MIT-MULTICS.ARPA> Lets get back to the original problem here. MIT-MULTICS is connected to several different networks. One of these is the "MAILNET" network, which is a mail only network based on autocall modems (and X.25 connections). Hosts on MAILNET can communicate with the ARPANET by routing their messages through MIT-MULTICS. MIT-MULTICS has one mailer that uses one combined host table for all the networks. It can either send mail directly to a host that it is directly connected to, or it can send mail to a "forwarding" host for networks it isn't directly connected to. Now the problem is what are we to do with MAILNET (the we here refers to the whole Internet world). Well there are several different solutions and each has its own problems. As I see it they are: 1) Implement DOMAINS. I have no idea why this isn't being persued! This appears to be the only good solution, furthermore if it is eventually done all the work (some mentioned below) to get around not having DOMAINS will have been effectively wasted. 2) Register all the MAILNET hosts with the NIC. I doubt the NIC would like this solution, not to mention that currently the NIC host table probably shouldn't have non-Internet hosts in it (nor is it clear that the format as implemented even supports this). 3) Have MIT's mailer rape the headers of messages originated on MAILNET. This solution really is a hard problem because of the diversity of header formats it would have to deal with. I agree with MRC that this is a non solution. 4) Have all the MAILNET subscriber hosts change their mailers so that they specify a from field of the form User%MailnetHost@MIT-MULTICS. This is hard because of the number of mailers involved, not to mention that it is a real kludge. 5) Have Internet hosts not communicate with non-Internet hosts. This seems silly, though I am sure there are people who probably think this is what should be done. Note that MIT-MULTICS does correctly generate a return path for mail originated on MAILNET. I am a relatively busy person and would rather not waste time implementing stop-gap solutions. My attitude so far has been a sit and wait for DOMAINS (or some similar general solution). I am still waiting... -Jeff  Date: Fri 14 Oct 83 12:35:23-PDT From: Mark Crispin Subject: HELO command in SMTP To: Header-People@MIT-MC.ARPA, MsgGroup@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I was reading through RFC 821 looking up the TURN command, and found a definite statement that HELO is required. On page 27 of 821, at the top (this is the last set of paragraphs in 4.1.1), it states: "The first command in a session must be the HELO command." If there are still any individuals who think the HELO command is optional and that the TOPS-20 mailer is wrong for requiring it, this should settle that. -------  Received: from USC-ECL by SU-SCORE.ARPA with TCP; Fri 14 Oct 83 14:47:51-PDT Date: 14 Oct 1983 14:43-PDT Sender: ESTEFFERUD@USC-ECL Subject: Re: HELO command in SMTP From: Einar Stefferud - MsgGroup Moderator Reply-To: msggroup-request@BRL To: MRC@SU-SCORE Cc: Header-People@MIT-MC, MsgGroup@MIT-MC Message-ID: <[USC-ECL]14-Oct-83 14:43:28.ESTEFFERUD> In-Reply-To: The message of Fri 14 Oct 83 12:35:23-PDT from Mark Crispin OK. Now lets keep the remaining traffic on ths topic in Header-People only, Please! Thanks - Stef  Received: by ucbvax.ARPA (4.12/4.7) id AA03740; Fri, 14 Oct 83 13:10:02 PDT Date: 14 Oct 83 16:06:54 EDT (Fri) From: ulysses!smb@Berkeley (Steven Bellovin) Subject: Re: [OBERST%educom: Quoted @ in To: field] Message-Id: <8310142006.AA16104@ulysses.UUCP> Received: by ulysses.UUCP (3.327/3.7) id AA16104; 14 Oct 83 16:06:54 EDT (Fri) To: header-people@mit-mc There's no way to avoid header-munging, even with 822-compatible mailers. Suppose, I, on host foo, send a letter to a mailing list address on bar. If foo and bar are in the same domain, my mailer should quite properly generate 'to: list@bar' and 'from: me@foo'. But suppose list@bar expands to user1@bar, user2@bletch.arpa? At that point, the list expander has to mung my perfectly legal headers to add domain qualifiers. Not that I like that -- you should see what the headers on these notes look like by the time they reach me....  Date: Friday, 14 October 1983 18:16 edt From: Gary M. Palter Subject: Re: [OBERST%educom: Quoted @ in To: field] To: Header-People@MIT-MC.ARPA In-Reply-To: Message of 14 October 1983 16:06 edt from "ulysses!smb at UCB-VAX (Steven Bellovin)" Message-ID: <831014221627.091947@MIT-MULTICS.ARPA> If you read RFC822 carefully, you will see that it requires that all domain names in messages that are actually transferred between systems be fully qualified.  Date: Fri 14 Oct 83 16:39:37-PDT From: Mark Crispin Subject: Re: [OBERST%educom: Quoted @ in To: field] To: ulysses!smb@UCB-VAX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "ulysses!smb@Berkeley (Steven Bellovin)" of Fri 14 Oct 83 16:06:54-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) So far as I'm concerned the issue about what happens with addresses getting indirectly expanded outside of a local domain is precisely the reason why mailsystems should never generate any address short of the fully specified domain address in headers. If this simple step is taken, there is no need to mung headers in the 822 world. -------  Acknowledge-To: Barry Margolin Date: Saturday, 15 October 1983 00:56 edt From: "Barry Margolin"@MIT-MULTICS.ARPA Subject: Re: What to do about non-Internet mail hosts. To: Schiller@MIT-MULTICS.ARPA cc: Header-People@MIT-MC.ARPA Message-ID: <831015045655.662311@MIT-MULTICS.ARPA> Date: Friday, 14 October 1983 11:05 edt From: Jeffrey I. Schiller 1) Implement DOMAINS. I have no idea why this isn't being persued! This appears to be the only good solution, furthermore if it is eventually done all the work (some mentioned below) to get around not having DOMAINS will have been effectively wasted. There is another whole mailing list devoted to review of domain implementation: NameDroppers. Recently three draft RFC's were announced to this group, one of which is a schedule of a phased switch to domain style addressing. The plan described is supposed to be completed in about a year. I think these drafts are available as RFC-XXX, RFC-YYY, and RFC-ZZZ from the NIC. barmar  Date: 4-Oct-83 10:50 PDT From: Kirk Kelley Subject: Re: Message-ID's To: Larry Campbell Cc: Header-People@MIT-MC Message-ID: <[OFFICE-2]TYM-KIRK-3A8B0> In-reply-to: <"MS11(2347)+GLXLIB1(1056)" 11956815040.31.71.26901 at DEC-MARLBORO> <831004084004.9.RWK@SCRC.SCRC> References-to: Message from Robert W. Kerns of 4-Oct-83 0850-EDT You will notice that the Augment mail system I'm using also uses the identifier field for traceing messages. It must create its own identifier for stuff coming from outside mail systems, like RFC-822, even if one already exists. Identifiers are used inside Augment mail in these fields among others: supersedes superseded part-of parts addendum-to addenda in-reply-to replies We are not currently attempting to delete duplicate messages but it would be nice if we could use identifiers to help do that. -- kirk  Date: 5 Oct 1983 0826-PDT Sender: WMARTIN at OFFICE-3 Subject: Unique identifier for messages From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN> Wouldn't a good way to uniquely identify messages, given the problem of changed messages having the Message-ID unchanged, be a combination of an originally-assigned Message-ID field and the number of characters in the Text field? Most duplicate messages I've seen have different character-counts for the entire message, because the header has more fields or more data in a field, but the Text is identical. Since most message-systems seem to use the character-count for various purposes, would it be hard to just count the characters in the Text field alone? I would think that it would be safe to program a system to assume duplicates exist if both the Message-ID and the Text field character-count were identical. If there was no Message-ID, of course, such a message wouldn't be considered as a candidate for being a duplicate, even if it was. (I doubt that it would be safe to consider messages to be duplicates if both had null Message-ID's and identical Text-field character-counts -- too much margin for error in that case.) Will Martin  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2612524176306174@MIT-MULTICS.ARPA>; 15 Oct 1983 09:09:36 edt Date: Sat, 15 Oct 83 00:02:16 EDT From: "Gavin Eadie"@UMich-MTS.Mailnet To: Header-People@MIT-MC.ARPA Message-ID: <249874@UMich-MTS.Mailnet> Subject: Puzzled thoughts from a non-Internetter This is a message displayed in the MTS (Michigan Terminal System) conference system FORUM for comment from the various people who are interested in such things. It follows on from (not coincidentally) recent discussions in this group. I implemented an RFC821/822 system recently and, though I would call myself a skilled and experienced programmer, I feel it is a small miracle that it works. I based my entire implementation on the RFCs, my header parser *IS* the grammar taken from 822, the MTS implementation of SMTP follows 821 slavishly ... The results of this are two: 1. The only SMTP code that I communicate with (other than copies of my own at other MTS sites) is that at MIT-Multics - which, sad to relate, doesn't quite manage to accept: RCPT TO:<@MIT-MULTICS:"John Doe"@RPI-MTS> and generates many wonderful variations on the headers in 822! Assuming that people in this business longer than me had got it right wasted lots of my time! 2. I never heard of the use of "%" till after my implementation was complete. Now (as you will read below) I have to decide to retrofit it - ugh. But wait, all this sounds like a complaint -- it is not, I've had lots of fun sorting this stuff out and appreciate all the help I had from the MIT folk and people in this group. All I'm trying to illustrate is how a newcomer sees some of this. ---------- U-M is a member of two mail networks (MAILNET and the 'MTSnet') and some other MTS sites are contemplating doing the same. This raises a few technical problems which I'd like to raise for discussion here between the mail-wizards. We could have this discussion via $MESSAGE but that means everyone keeps a wasteful archive. FORUM also helps to organise a single thread discussion. The mail protocols we use in Mailnet and MTSnet were developed and are used within the ARPA community. They are called RFC821 and RFC822 and, unlike most 'standards', were written as attempts to make a good summary of what everyone was already doing - rather than as a rulebook. The MTSnet (composed now of seven MTS installations) could happily use these protocols within a closed community with no problems. So could a closed Mailnet community and so, obviously, does the closed ARPA community. Severe problems arise as soon as mail has to move between any of these communities. The protocols include mechanisms for operating across 'community' borders, but (i) the 'powers that be' within ARPA do not recognise non-ARPA communities and (ii) few mailers have implemented the new scheme. The result is ad hoc mechanisms. There are no formal descriptions of these - they are strictly folk-lore. As one who is speaking from experience, implementing an ARPA mailer from only the protocol descriptions is impossible. We (the MTS folks) need to resolve this for ourselves. We cannot be too inventive, since several ad hoc schemes already exist, but we have to do something because we are moving rapidly towards needing some solution. The problem arises both as MTSnet communicates with Mailnet and as Mailnet communicates with ARPA. (It is compounded by needs for MTSnet to talk with CSnet, BITNET, UUCP, the UK mail net and (undoubtedly) others. The most popular ad hoc scheme involves the use of the percent (%) symbol to indicate explicit routing of mail - this kluge is used so widely that (i) some people think it is official and (ii) the UK mail net had adopted it in their standard. Let me draw one of my famous pictures: +------------------+ |community 'A' | | | | +----+ | | |X | +------|-----------+ | |fred| |+----+| | | +----+ ||Y || | | ||joan|| +----+ | | |+----+| |Z | | +------------------+ |rich| | | +----+ | | | | community 'B'| +------------------+ (((NB: In everything that follows my use of the prime (') is as a delimiter in my writing - it is never part of an address.))) We have three sites in two communities (the site 'Y' is a gateway). Within the 'A' community 'X' and 'Y' can exchange mail using the ARPA protocols. They refer to each other as 'X.A' and 'Y.A' (using their complete formal names) or just as 'X' and 'Y' (since all the host names in a community are known to the other hosts). A user at 'X' would send mail to 'joan@Y' or 'joan@Y.A' and when it arrived it would be from 'fred@X' or 'fred@X.A'. We would see an analogous process in the 'B' community. Now consider a message which must travel from 'X' to 'Z'. We assume that 'Z' is not known to the 'X' mail software (otherwise this is a silly example) and that the user must explicity tell the 'X' mailer to get the mail to 'Z' via 'Y'. One option is to change that assumption by extending the knowledge of site names so EVERY site in the universe knows the name of EVERY other one. We reject this as impractical! The next option is to use the protocol. This may seem obvious, but remember that virtually nobody does - if they did, a user at 'X' would send to '@Y.A:rich@Z.B' and it would turn up at 'Z' marked as being from '@Y.B:fred@Z.A'. In fact, what we often see is the use of the percent kluge, so the mail is sent to 'rich%Z.B@Y'. This is the popular solution - it is actually the formal solution in the UK - so we ought to adopt it. This need is most urgent for the RPI people - they are members of Mailnet but not MTSnet so they can get mail to UM (also in Mailnet) but no further becuase the NETMAIL program doesn't process the '%' kluge. As I've written this, I've become more convinced that my only 'out' is to implement the percent-kluge. I'm posting this here so that anyone has an change to comment. I'm posting it on the ARPAnet too so they can see the pickle I'm in. ---------- Due to the fact that my mailer isn't generating names with "%" in them, I've no idea what the 'From:' field on this will look like when you read this. I know at least one person who I upset when every message I send him has to be manually edited before he can reply ... I am: Gavin_Eadie%UMICH-MTS@MIT-MULTICS  Date: Sat 15 Oct 83 15:01:33-PDT From: Mark Crispin Subject: Re: Puzzled thoughts from a non-Internetter To: Gavin_Eadie%UMich-MTS@MIT-MULTICS.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from ""Gavin Eadie"@UMich-MTS.Mailnet" of Sat 15 Oct 83 06:32:12-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Hi. I'm the mailsystem developer for the TOPS-20 operating system, or at least the developer for the TOPS-20 SMTP software and one of the more popular mail composition/reading programs. Maybe I might be able to give you some info. Much of this is rather tutorial, so most of the Header-People members probably ought to ignore the rest of this message unless they're interested in some internals of the TOPS-20 mailer. The SMTP command: RCPT TO:<@MIT-MULTICS:"John Doe"@RPI-MTS> is syntactically correct and the TOPS-20 mailsystem does accept it. However, I should point out that the host name RPI-MTS is not an Internet host name. Unless MIT-MULTICS has extended its SMTP for use outside of Internet (I suspect it has) it would be quite correct in declining to accept the command on those grounds. There is but one reason why "%" exists, and that is to allow what we call "small-i internet" mailing -- that is, mail between Internet and other electronic mail communities. In the old days of RFC 733, a syntax called "multiple ats" existed, where you had addresses such as user at host1 at host2 Unknown to most of the world, it was decided that multiple ats were not a good idea and the syntax was pulled from the specification (although it was still in the published RFC 733 specification). I was one of the people who was caught unaware by this. I was forced to look for an alternative. For a while I considered SMTP source routing, but to my dismay discovered that it was invalid to have any host name other than a duly registered Internet host name in an SMTP path name. This has the effect of making source routes totally useless except for debugging traces (and the Received: header line is much more useful for this purpose). I therefore had to stick with "multiple at" syntax, but hide it within the present confines of RFC 822. Everything pointed me towards "%". For TOPS-20 systems, "%" is quite attractive as a special character in a mailbox name as it is guaranteed never to be part of a valid user name (it is a wildcard character and its use in a user name string when a wildcard is invalid will cause an invalid system call trap). The SU-AI mailsystem had used "%" for "@" in its user interface for a long time due to its gothic parser, and other software allowed "%" as an alternate for the benefit of TIP users. I was vaguely aware of the UK system, but what I did was really independent of what the UK had. The "%" syntax is a "multiple at" syntax hidden under RFC 822; the UK syntax, while (deceptively) similar, has several operational differences. There are two important things to realize. First, the "%" character is "official" only so far as the small-i internet mail bridge (some people call them "relays") you are using sets the rules. If you are using a TOPS-20 system as a mail bridge, you use "%" to relay through it. If you're using MMDF, the magic character is ".". UUCP uses "!", although in reverse order. Apparently Multics uses the same rule as TOPS-20. If you don't deal with a mail bridge, you have no reason to know about "%", ".", "!", etc. If you do, the responsibility for such knowledge lies with the user. Some software, such as TOPS-20's mailsystem, provides the service of registering small-i internet names so its users can say "user@host" but it will be magically transmogrified into the appropriate syntax for the appropriate relay. For example, the TOPS-20 mailsystem knows that: foo@arizona becomes foo.arizona@RAND-RELAY.ARPA but: foo@MIT-EECS becomes foo%MIT-EECS@MIT-MC.ARPA Some people would say the TOPS-20 mailsystem is presumptious in having this knowledge, but it is specified in a special registry and not wired into the software. This leads me to the second thing to remember: you have no business trying to pull apart an "%" address unless you are the mail bridge to the right of the "@". Under no circumstances does the TOPS-20 mailsystem ever pull such an address apart; it just has some clever code to help users put them together. If you see an address such as: foo%Shasta@SU-SCORE.ARPA your mailsystem shouldn't know or care if this is user "foo" at some machine called "Shasta" known to SU-SCORE.ARPA or if it is going to Charlie foo%Shasta, our exchange student from Upper Funnylastnameland. Your users, on the other hand, may know that the "%" syntax through SU-SCORE.ARPA enables them to send mail to sites on Stanford's LAN. Until such time as we have domains to validly specify small-i internet sites within the context of a valid host name in SMTP, you will have to use some kludge such as (but not necessarily) "%" to hide your host names inside a valid Internet host name. -- Mark -- PS: For your enjoyment, here's a list of the current TOPS-20 mailer automatic transmogrification rules for various mail bridges. I've been trying to get a list of the sites for Mailnet but haven't had much luck: ; This file defines the sites which can be accessed via a mail ; relay. Some liberties are taken with the concept of domains ; to make this work; a domain here must be thought of as a top- ; level domain in the Internet sense; in other words, a mail ; registry. ; ; This file contains text lines of the format: ;DOMAIN ,, ; or ;HOST ,, ; where: ; ; ::= domain name ; ::= character to use in transmogrification ; ::= host to use in transmogrification. This ; is text. It must have any domain names ; etc. that you want ; ::= list of relay hosts ; ::= primary host name, without domain ; ::= list of nicknames ; ; DOMAIN defines a domain, while HOST defines a host in a ; particular domain. Transmogrification refers to the necessary ; steps to coerce the given host name into a valid Internet name ; in the actual message header. As of this writing (3/19/83), ; ARPA is the only valid domain name. Consequently, an address ; such as MRC@MIT-EECS.MIT-CHAOS must be coerced into something ; like MRC%MIT-EECS@MIT-MC.ARPA. ; DOMAIN CCnet-Columbia,%COLUMBIA-20.ARPA,COLUMBIA-20,CMU-CS-C DOMAIN CCnet-CMU,%CMU-CS-C.ARPA,CMU-CS-C,COLUMBIA-20 DOMAIN CSnet-East,.UDEL-RELAY.ARPA,UDEL-RELAY DOMAIN CSnet-West,.RAND-RELAY.ARPA,RAND-RELAY DOMAIN MIT-Chaos,%MIT-MC.ARPA,MIT-MC,MIT-XX,MIT-ML DOMAIN NYU,.NYU.ARPA,NYU DOMAIN SU-Pup,%SU-SCORE.ARPA,SU-SCORE,SUMEX-AIM DOMAIN TLnet,%CMU-CS-C.ARPA,CMU-CS-C ; HOST CCnet-CMU,CMCCTA HOST CCnet-CMU,CMCCTB HOST CCnet-CMU,CMCCTC HOST CCnet-CMU,CMCCTD HOST CCnet-CMU,CMCCTE HOST CCnet-CMU,CMCCTF HOST CCnet-CMU,CMCSC HOST CCnet-Columbia,CU20A HOST CCnet-Columbia,CU20B HOST CCnet-Columbia,CU20C HOST CCnet-Columbia,CU20D HOST CCnet-Columbia,CUCS20 HOST CCnet-Columbia,CUTC20 HOST CCnet-CMU,CWR20B HOST CCnet-CMU,CWRU20 HOST CSnet-East,anad HOST CSnet-East,bci,ascii-network HOST CSnet-East,brandeis HOST CSnet-East,brown HOST CSnet-East,btl-mh,btlmh,btl-owl,owl,labs,bell-labs,belllabs HOST CSnet-East,buffalo-cs,bufcs,suny-buf,buffalo HOST CSnet-East,case,case-western,cwru HOST CSnet-East,ccp-onyx01,ccp-onyx1,ccp1 HOST CSnet-East,ccp-onyx02,ccp-onyx2,ccp2 HOST CSnet-East,cda-pdp01 HOST CSnet-East,cda-pdp1,cda HOST CSnet-East,cdrm-onyx01,cdrm-onyx1 HOST CSnet-East,cic-test HOST CSnet-East,cis-onyx01,cis-onyx1,cis1 HOST CSnet-East,cis-onyx02,cis-onyx2,cis2 HOST CSnet-East,clemson HOST CSnet-East,cms HOST CSnet-East,cms-onyx01 HOST CSnet-East,cms-onyx1 HOST CSnet-East,darcom-hq,darcom-dhq,dhq,darcom,hq HOST CSnet-East,darcom-o2,darcom2 HOST CSnet-East,digital,dec-csnet,dec-crg,dec-hudson HOST CSnet-East,duke HOST CSnet-East,gatech,ga-tech,georgia-tech,git,georgia,gatch HOST CSnet-East,hp-avn,mushroom,hp-avondale HOST CSnet-East,igw-onyx02,igw-onyx2,igw2 HOST CSnet-East,jhu,hopkins,johns-hopkins HOST CSnet-East,kentvax,kent,ksu HOST CSnet-East,mep-onyx01,mep-onyx1,mep1 HOST CSnet-East,micom,micom-onyx,micom1 HOST CSnet-East,northeastern,nuacs HOST CSnet-East,nsf-cs,nsf,onyx,nsfcs HOST CSnet-East,penn-state,psuvax1 HOST CSnet-East,pitt,upitt,pittsburgh,u-pitt HOST CSnet-East,pmdf-test HOST CSnet-East,princeton,princ,prin,prinu HOST CSnet-East,psp HOST CSnet-East,psp-onyx01 HOST CSnet-East,quaker,reilly-pc,philly HOST CSnet-East,qucis,queens,qu HOST CSnet-East,rpi,rensselaer,rip,tute HOST CSnet-East,scarolina,carolina,scar HOST CSnet-East,suny-sbcs,suny-sb,suny-stony,suny,sb-cs,sbcs,stony-brook HOST CSnet-East,syr HOST CSnet-East,udel-cc-relay HOST CSnet-East,udel-cc-vax1,udccvax1,udel-cc HOST CSnet-East,udel-cc-vax2,udccvax2,udelccvax2 HOST CSnet-East,udel-ee,eevax,udel-ee-vax,udvax,udel-vax,udee-vax,udel-eecis1 HOST CSnet-East,udel-eecis2 HOST CSnet-East,udel-eecis3,udel-ee70 HOST CSnet-East,umass-boston,umb,umass-boss,um-boston,umboston HOST CSnet-East,umass-cs,umass,umass-coins HOST CSnet-East,umass-ece,umass-ecs HOST CSnet-East,umcp-cs,umcp,umaryland-college-park,umaryland,umaryland-cp,maryland-cp HOST CSnet-East,umich-ciprnet,umich,umich-cv,umich-cipr,cipr HOST CSnet-East,unc,dopey,unc-dopey,unc-ch,uncch,chapel-hill HOST CSnet-East,unc-bashful,bashful HOST CSnet-East,unc-grumpy,unc-grumpey,grumpy,grumpey HOST CSnet-East,unc-happy,happy HOST CSnet-East,unc-sleepy,sleepy HOST CSnet-East,unh,unh-csvax HOST CSnet-East,upenn,penn,upenn-cs,upenn-cis,penn-cis,penn-cs HOST CSnet-East,upenn-750,penn-750,upenn750,penn750 HOST CSnet-East,uwmeecs,uwm-eecs,uwm HOST CSnet-East,virginia,uvirgin,uva,uva-cs,uvacs,uvirginia HOST CSnet-East,vlsivax,princeton-vlsi,prin-vlsi HOST CSnet-East,wang-inst,wang-igs,wang-institute HOST CSnet-East,xam-onyx01,xam,drxam HOST CSnet-East,xig-onyx01,xig-onyx1,xig1 HOST CSnet-East,xls-onyx03,xls-onyx3 HOST CSnet-East,xls-plexus01,xls-plexus1,plx1 HOST CSnet-East,xls-unix3,xls-unix03,pdp3,pdp03 HOST CSnet-East,xlslp-onyx01,xls-onyx01,chamb HOST CSnet-East,xmm-onyx01,xmm,xmm-onyx1 HOST CSnet-East,xos-onyx01,xos-onyx1,xos1 HOST CSnet-West,arizona,az HOST CSnet-West,atari HOST CSnet-West,boulder HOST CSnet-West,ct,ctvax HOST CSnet-West,depaul HOST CSnet-West,emory HOST CSnet-West,hp-hewey,hewey,hp-venus HOST CSnet-West,hp-hulk,hulk HOST CSnet-West,hp-labs,hp,hewlett-packard,hplabs,hpvax,hp-vax HOST CSnet-West,hp-mars HOST CSnet-West,hp-mercury HOST CSnet-West,hp-thor,thor HOST CSnet-West,ibm-sj,ibmsj,ibm-sjrlvm1,ibm,sjrl HOST CSnet-West,indiana,iuvax,iucs HOST CSnet-West,kansas-state,kanstate HOST CSnet-West,nmt,nmtvax,cerebus,newmexicotech,new-mexico-tech HOST CSnet-West,nwu HOST CSnet-West,ohio-state,osu-dbs,osu-cis HOST CSnet-West,oregon-grad,ogcvax,ogc,oregon HOST CSnet-West,oregon-state,orstcs HOST CSnet-West,portland HOST CSnet-West,rice HOST CSnet-West,tamu,texam HOST CSnet-West,tektronix,tek,tekcrd HOST CSnet-West,uabcs,alabama,alabama-cs,uab HOST CSnet-West,ubc,ubc-ean,ean HOST CSnet-West,ucf-cs,ucfl-cs,ucf,ucfl,central-florida,florida HOST CSnet-West,uci-20a HOST CSnet-West,uci-20b HOST CSnet-West,uci-750a HOST CSnet-West,uci-750b HOST CSnet-West,uci-vax HOST CSnet-West,uci HOST CSnet-West,ucsb,ucsbcsl,ucsbcsil HOST CSnet-West,ucsc,santacruz,ucsccis HOST CSnet-West,ufl,ufla HOST CSnet-West,uiowa,iowa HOST CSnet-West,uiuc,uiucdcs HOST CSnet-West,ukans,ku,ukan HOST CSnet-West,umiss,olemiss, HOST CSnet-West,umn-cs,mn-cs,minn-cs,min,minn,umncsci,umn-csci,uminn,umin,uminn-cs,minncs,mncs HOST CSnet-West,usc-cse,uscvax HOST CSnet-West,usl HOST CSnet-West,utd-cs,utd,dallas,ut-dallas,utexas-dallas HOST CSnet-West,vanderbilt,vand,vandy,vanderbuilt,vanderbiult,vu HOST MIT-Chaos,MIT-ALCATOR,ALCVAX,ALCATOR HOST MIT-Chaos,MIT-CCC,MITCCC,CCC HOST MIT-Chaos,MIT-CIPG,CIPG HOST MIT-Chaos,MIT-COG-SCI,MIT-COGS,COGS HOST MIT-Chaos,MIT-CORWIN,CORWIN HOST MIT-Chaos,MIT-DEVO,DEVO HOST MIT-Chaos,MIT-DSPG,DSPG HOST MIT-Chaos,MIT-EDDIE HOST MIT-Chaos,MIT-EECS,EE,EECS,MITEE,MIT-EE,MIT-DEEP-THOUGHT,DEEP-THOUGHT HOST MIT-Chaos,MIT-GOLEM,GOLEM,MIT-TALOS,TALOS HOST MIT-Chaos,MIT-HEART-OF-GOLD,HEART-OF-GOLD,MIT-HOG,HOG HOST MIT-Chaos,MIT-HEPHAESTUS,HEPHAESTUS,MIT-VULCAN,VULCAN HOST MIT-Chaos,MIT-HTJR,HTJR,HTBROKE HOST MIT-Chaos,MIT-HTVAX,HT,HTVAX,HTUNIX HOST MIT-Chaos,MIT-MARIE,MARIE,MIT-LNS HOST MIT-Chaos,MIT-MATH,MATH,MITMATH HOST MIT-Chaos,MIT-NICK,NICK HOST MIT-Chaos,MIT-OBERON,OBERON,OBI HOST MIT-Chaos,MIT-OZ,OZ,PUMPKIN,AI20,MIT-AI20,MIT-AI,AI,MITAI HOST MIT-Chaos,MIT-PAMELA,PAMELA,MIT-PAM,PAM HOST MIT-Chaos,MIT-PFC-VAX,PFCVAX,PFC-VAX HOST MIT-Chaos,MIT-PIERRE,PIERRE HOST MIT-Chaos,MIT-PREP-VAX,MIT-PREP,PREP HOST MIT-Chaos,MIT-PYGMALION,PYGMALION,MIT-ROBOTICS HOST MIT-Chaos,MIT-SPEECH,SPEECH,NSPEECH HOST MIT-Chaos,SCH-COYOTE,COYOTE HOST MIT-Chaos,SCH-LOKI,LOKI HOST MIT-Chaos,SCRC-COMET,COMET HOST MIT-Chaos,SCRC-CUPID,CUPID HOST MIT-Chaos,SCRC-TENEX,SCRC HOST MIT-Chaos,SCRC-VIXEN,VIXEN HOST NYU,NYU-ACF1,ACF1 HOST NYU,NYU-ACF2,ACF2,NYU-ADA HOST NYU,NYU-CMCL1,CMCL1 HOST NYU,NYU-CMCL2,CMCL2,NYU-UNIX HOST SU-Pup,SU-Ardvax,Ardvax HOST SU-Pup,SU-Carmel,Carmel HOST SU-Pup,SU-CIT,CIT-750,CIT HOST SU-Pup,SU-CIT1,CIT1 HOST SU-Pup,SU-CIT2,CIT2 HOST SU-Pup,SU-Fuji,Fuji HOST SU-Pup,SU-Glacier,Glacier,FTAL,FTAL-Vax HOST SU-Pup,SU-GSB-HOW,GSB-HOW,HOW HOST SU-Pup,SU-GSB-WHY,GSB-WHY,WHY HOST SU-Pup,SU-Helens,Helens HOST SU-Pup,SU-HNV,Diablo,HNV,SU-HPP-NG-VAX HOST SU-Pup,SU-ISL,ISL,Tamalpais,Tam,ISL-VAX HOST SU-Pup,SU-Lassen,Lassen,IFS HOST SU-Pup,SU-Navajo,Navajo,NA-VAX HOST SU-Pup,SU-Psych,Psych,Psych-Vax,SU-Tahoma,Tahoma,Turtle-Vax HOST SU-Pup,SU-Shasta,Shasta HOST SU-Pup,SU-Sierra,Sierra,SU-EE,EE HOST SU-Pup,SU-Whitney,Whitney,SU-Robotics HOST SU-Pup,SUMEX-2020,AIM-2020,Tiny HOST SU-Pup,SUMEX-VAX,SAFE,SU-SAFE HOST TLnet,TARTAN -------  Date: Sunday, 16 October 1983 14:02 edt From: Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller) Subject: Re: Puzzled thoughts from a non-Internetter To: Mark Crispin cc: Header-People@MIT-MC.ARPA, Gavin_Eadie@UMICH-MTS.MAILNET In-Reply-To: Message of 15 October 1983 18:01 edt from "Mark Crispin" Message-ID: <831016180220.545588@MIT-MULTICS.ARPA> The Multics mailer works very similarly to the TOPS-20 mailer. We accept both "%" and "@" characters as user/host separators. A user on Multics doesn't have to know on what network the host he is communicating with is connected. For example at the moment Multics isn't on the ChaosNet here at MIT (this is being worked on, but slowly) so when a user specifies mail say for MIT-EECS (which is only on the ChaosNet) the mail system automatically translates this to USER%MIT-EECS at MIT-MC (or whatever other host is in the host table as the chaos net forwarding host). The real problem comes in the from field. Gavin can send mail from his machine (which is on MAILNET) to any Internet/ChaosNet/Mailnet host without having to have any knowledge as to what network the host is actually connected. Because all of his MAILNET mail is routed through MIT-MULTICS (one of the specifications of MAILNET) MIT-MULTICS arranges to forward it on. HOWEVER UMich-MTS doesn't know what host is where, and assumes that ALL HOSTS (Internet and non-Internet alike) know of all other hosts and thus supplies Gavin_Eadis at UMich-MTS as the return address. Of course Multics (actually any Multics on the Internet running with the MIT-MULTICS host table) can deal with this because it knows about UMich-MTS. Of course not all Internet hosts have this knowledge. I could supply SCORE for example with the MAILNET host table and then users on SCORE will be able to reply directly to Gavin. However there are people out there who don't want to have to worry about picking up non-Internet host tables, and want the responsibility for the message header to be placed on the Mail bridge. Of course from my point of view (the mail bridge maintaner) I would rather not have my mail system parsing someone elses headers for a message not destined on my host. -Jeff  Date: Sun, 16 Oct 83 17:18:07 CDT From: Paul Milazzo Return-Path: Subject: Unofficial Domains To: Mark Crispin Cc: Header-People@MIT-MC Message-Id: <1983.10.16.17.18.07.050.02609@Rice-vms.rice> In-Reply-To: Mark Crispin's message of Sat 15 Oct 83 15:01:33-PDT Via: Rice; 16 Oct 83 18:02-PDT Mark, I strongly sympathize with your implementation of a private domain list for use by your local mailer, but I have two reservations: 1) You must insure that the private domain notation never escapes your local environment, as it did in the following header: > Date: Fri 9 Sep 83 07:42:38-PDT > From: Norm Kincl > Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 10:43:39-EDT > Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 9 Sep 83 08:34:17 PDT (Fri) > Subject: CPM/86, TELENET > To: Info-Kermit@COLUMBIA-20 > Reply-To: Kincl@HP-Labs.CSnet-West 2) Keeping the database current is difficult without outside help. For example, your table correctly contains the line: HOST CSnet-West,rice However, Rice will soon become an Internet site via CSNet/TELENET, and you will then be able to speak SMTP directly to my host. But will you do so? Your host-table update procedure may well include a scan of your unofficial domain list for hosts newly registered with the NIC, but will everyone to whom you have now distributed said list do the same? I believe I understand your motivations and I do not mean to denigrate your decision to allow the local use of unregistered host names and unofficial domains. After all, the CSNet/MMDF software does essentially the same thing for CSNet and ARPANET sites. Still, the CSNet CIC acts as a central naming and name distribution authority, something which you do not have. Simply compiling a static list of sites is, as I'm sure you realize, not the complete answer. Paul Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX  Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Mon 17-Oct-83 08:55:31-EDT Date: Mon, 17 Oct 83 08:51 EDT From: Charles Hornig Subject: Re: Puzzled thoughts from a non-Internetter To: Jeffrey I. Schiller , Mark Crispin Cc: Header-People@MIT-MC, Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS In-reply-to: <831016180220.545588@MIT-MULTICS.ARPA> Message-ID: <831017085117.2.Hornig@SCRC.SCRC> Date: Sunday, 16 October 1983 14:02 edt From: Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller) The real problem comes in the from field. Gavin can send mail from his machine (which is on MAILNET) to any Internet/ChaosNet/Mailnet host without having to have any knowledge as to what network the host is actually connected. Because all of his MAILNET mail is routed through MIT-MULTICS (one of the specifications of MAILNET) MIT-MULTICS arranges to forward it on. HOWEVER UMich-MTS doesn't know what host is where, and assumes that ALL HOSTS (Internet and non-Internet alike) know of all other hosts and thus supplies Gavin_Eadis at UMich-MTS as the return address. Of course Multics (actually any Multics on the Internet running with the MIT-MULTICS host table) can deal with this because it knows about UMich-MTS. Of course not all Internet hosts have this knowledge. I could supply SCORE for example with the MAILNET host table and then users on SCORE will be able to reply directly to Gavin. However there are people out there who don't want to have to worry about picking up non-Internet host tables, and want the responsibility for the message header to be placed on the Mail bridge. Of course from my point of view (the mail bridge maintaner) I would rather not have my mail system parsing someone elses headers for a message not destined on my host. Don't forget that ALL of the information needed to reply to a non-Internet mail address is contained in the Return-path: field. Just concatenate it with each address. If you know better, you can optimize this, but it will always work. I don't see why we must wait for the RFC-YYY system to be fully implemented when we can just fall back on this.  Date: Monday, 17 October 1983 12:49 edt From: "Barry Margolin"@MIT-MULTICS.ARPA Subject: NameDroppers To: Header-People@MIT-MC.ARPA Message-ID: <831017164901.388836@MIT-MULTICS.ARPA> I have gotten several messages requesting info about the NAMEDROPPERS mailing list. I believe that it comes from SRI-NIC, so sending mail to NAMEDROPPERS-REQUEST at SRI-NIC is the way to get onto the list. barmar  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 17 Oct 83 12:41:00 EDT Date: 17 Oct 83 1251 EDT (Monday) From: don.provan@CMU-CS-A Subject: Re: Puzzled thoughts from a non-Internetter CC: header-people@mit-mc In-Reply-To: <831017085117.2.Hornig@SCRC.SCRC> Message-Id: <17Oct83.125114.DP0N@CMU-CS-A> uh-oh. we're back to the return path again. the spec claims that there need be no relation between the return-path and the sender of the message. it fact, it specifically says that the return-path is where *errors* should be sent, *not* where replies should be sent. it's my understanding that if a mailer is following SMTP, it needs to produce an address that anyone who's legal in the SMTP world can understand. whether that's 'Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS.ARPA' or '@MIT-MULTICS.ARPA:Gavin_Eadie@UMICH-MTS.MAILNET' (although this format is frowned upon by the specs and, from what Mark is saying, is down right illegal because of the illegal address, although i can't see why anyone would care what that address is: i always assumed this format was designed for just such a situation) or 'Gavin_Eadie@UMICH-MTS.MAILNET.MIT-MULTICS.ARPA' (which, from time to time, has been declared "legal", although i believe current opinion considers it illegal) doesn't really concern me too much. they all have the same basic format: a part anyone should be able to understand, and a part almost noone will understand. however, if a mailer *doesn't* generate a universally understood address (and i wouldn't blame it, since universally understood addresses get longer in proportion to the distance from our egocentric network) then some interface is going to have to hack headers because the mailer just isn't playing SMTP. i don't quite know what the point of saying all this was. i guess i just want to spew the way i understand it so someone can correct the parts i misunderstand. don  Date: 17 Oct 1983 0813-PDT Sender: WMARTIN at OFFICE-3 Subject: Message-ID's Subject: [WMartin at Office-3 (Will Martin): Unique identifier for m...] From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Message-ID: <[OFFICE-3]17-Oct-83 08:13:22.WMARTIN> I tried sending this message to Header-People almost two weeks ago; it doesn't seem to have ever gotten there, as I never saw a remailed copy come back to me. I have had no response from an inquiry message about it that I sent to Header-People-Regquest@MIT-MC, either. (I am getting H-P mail from the list OK, as far as I can determine. If this one never shows up, the link from here TO MIT-MC must be down.) Begin forwarded message Date: 5 Oct 1983 0826-PDT From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Subject: Unique identifier for messages Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN> Wouldn't a good way to uniquely identify messages, given the problem of changed messages having the Message-ID unchanged, be a combination of an originally-assigned Message-ID field and the number of characters in the Text field? Most duplicate messages I've seen have different character-counts for the entire message, because the header has more fields or more data in a field, but the Text is identical. Since most message-systems seem to use the character-count for various purposes, would it be hard to just count the characters in the Text field alone? I would think that it would be safe to program a system to assume duplicates exist if both the Message-ID and the Text field character-count were identical. If there was no Message-ID, of course, such a message wouldn't be considered as a candidate for being a duplicate, even if it was. (I doubt that it would be safe to consider messages to be duplicates if both had null Message-ID's and identical Text-field character-counts -- too much margin for error in that case.) Will Martin -------------------- End forwarded message  Received: from USC-ISIF by MIT-XX; Mon 17 Oct 83 15:43:59-EDT Date: 17 Oct 1983 12:42:13 PDT From: POSTEL@USC-ISIF Subject: Draft Memos on Domains To: header-people@MIT-MC There are three draft memos on the DOMAINS system. These are in the files DOMAINS-XXX.DRAFT DOMAINS-YYY.DRAFT DOMAINS-ZZZ.DRAFT on USC-ISIF. These are public access files and may be copied via FTP. Please use the FTP username ANONYMOUS and password GUEST. The proper forum for discussion of these memos and related topics is the mailing list NAMEDROPPERS@SRI-NIC. To get on the list please send a request to NAMEDROPPERS-REQUEST@SRI-NIC. --jon. -------  Date: Mon 17 Oct 83 13:46:54-PDT From: Mark Crispin Subject: Re: Unofficial Domains To: milazzo.rice@RAND-RELAY.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Paul Milazzo " of Mon 17 Oct 83 00:19:03-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Paul - I couldn't agree with you more about preventing private domains from escaping. They don't in my software. However, I can't prevent users from generating a header line which refers to a private domain -- all I can do is educate them! In the example you gave, that Reply-To: line was in fact generated by the user explicitly using a power tool in the mailsystem that allows arbitrary text in headers. Power tools are useful to evade the normal header generating mechanisms and are essential with any experimentation, but they can be abused. I see no way to protect power tools without hampering their usefulness. Thanks for the note, though; I will tell G.Norm@SU-SCORE not to stick in "Reply-To: Kincl@HP-Labs.CSnet-West" in his headers. Your second point (regarding what happens when Rice goes on Internet) touches closer to home. You're right. The problem was that at the time we designed private domains, we confused the functionality of private domains with the functionality to disable delivery to an entity via a certain transport. In other words, consider the case where host FOO is listed in the Internet registry, but it is known that they aren't *really* on Internet and so must be mailed to via some other means such as CSnet. The DOMAINS.TXT entry would override the Internet lookup. Really, it should be the other way around; DOMAINS.TXT should be treated last and there should be a new mechanism to disable name lookups. I guess I ought to fix this. Note that this mechanism is layered on top of the official mechanisms. There is nothing keeping a user from using the syntax user.CSnet-host@RAND-RELAY; it's just to allow a user here to say user@CSnet-host. Hopefully real domains will come along soon and get rid of all this cruft. -- Mark -- -------  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 18 Oct 83 07:42:25 PDT Via: 44a.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK over Inter-UNIX with SMTP; 18 Oct 83 13:25 BST Date: 18 Oct 83 10:16:29 BST (Tue) From: Steve Kille (44a) To: header-people@mit-mc.arpa Subject: UK Mail Protocol The JNT Mail Protocol used in the UK Academic Community is being revised to follow the changes from RFC 733 -> 822. This protocol uses messages which are upwards compatible with RFC 822 bar a few small differences. The third draft is now available, and as most of you do not run NIFTP, I will be happy to mail copies to anyone interested. The final version (expected early next year) will also be announced over this list. Any comments are welcome, and should be sent to . This group is concerned with mail service developments in the UK, and I will be happy to add internet people to the list. Steve Kille  Date: Thu, 20 Oct 83 11:01:54 PDT From: Rich Wales To: Header-People@MIT-MC Subject: Results of SMTP server inquiries A while ago, I asked for information regarding the state of SMTP server implementations in the Internet. My purpose in doing this was to find out whether it was "safe" to assume that random Internet hosts can han- dle multiple recipients per message and multiple messages per connec- tion -- and if this were not a safe assumption, to design a "robust" SMTP sender (outgoing mailer) which would batch recipients of a single message and/or messages to a single host where possible, yet would suc- cessfully "degrade" to accommodate the limitations of SMTP servers with more limited capabilities. I received numerous replies; one implementor (Doug Kingston at BRL) even phoned me so we could discuss the issues at greater length. My thanks to all those who did reply to my inquiry. It appears that most SMTP servers in use on the Internet today imple- ment RFC821 rather well. In particular, everyone who replied to me indicated that their server should be able to handle at least 100 recipients per message, and an unlimited number of messages per con- nection, under normal circumstances. Two problem areas did surface and should probably be thought out and discussed further: (1) There is sharp disagreement as to what is the best reply code to use when the sender tries to specify "too many" RCPT commands for a message. RFC821 calls for the reply code 552 in this situation, but since many (maybe even all) mailers will interpret a 552 reply code as a permanent rejection of the last-specified recipient, a significant number of SMTP servers disregard this portion of RFC821 and reject excessive recipients with 452 rather than 552. Many servers have no explicit limit on the number of recipients, but will "bomb" in more-or-less messy ways after a (usually) unrea- sonable number of recipients cause virtual memory to fill up. Most of these servers, though, will probably accept preposterously large recipient lists before choking. I would therefore propose the following practices. Please note that these are my personal opinions and have no official sanction. (a) Mailers should attempt to negotiate no more than 100 recipients in a single message; longer recipient lists should be handled by splitting the transaction in two. A mailer which holds it- self to this limit probably does not have to worry about going over a server's limit on the number of recipients, since most (if not all) servers seem to be able to take 100 recipients in accordance with RFC821 (section 4.5.3, page 43). (b) Server implementors should give serious consideration to using a 400-series reply code (such as 452), rather than 552, when confronted with too many recipients in a single message -- in order to insure that the mailer will try the excess recipients later rather than permanently rejecting them. (2) Some hosts may run into problems when presented with lots of trans- actions with lots of recipients. Two syndromes were pointed out to me in this regard: (a) Some servers (evidently including the Berkeley 4.1c/4.2BSD "sendmail"-based system) may take so long to complete the mail- delivery process that the mailer may end up incorrectly assum- ing the server has met an untimely demise. Since the mailer under such circumstances will try to deliver the message again later (and will probably run into the same problem again and again), the result will be endless duplication of mail in the receivers' mailboxes. Note, by the way, that the mailer end cannot reliably "guess" how long to wait for delivery to complete based on the number of RCPT commands, since the server end may have expanded the original recipient list via aliasing. (b) Some other servers (such as BBN's system) wait a while for the mail-delivery process to finish; then, after 30 seconds or so, the server assumes that the mail will eventually be delivered and prematurely reports success back to the mailing end. A system whose server behaves in this way can quickly get swamped by a host with lots of mail to send; eventually, the receiving system may get "file table is full" or other problems and start dropping mail on the floor. MMDF-based SMTP servers are apparently immune to this difficulty, since the server simply stores incoming mail in a spool directory and relies on a daemon to deliver it later. (I suspect the Xerox Grapevine system works this way too, though I am not absolutely certain.) This is probably the best way to handle the problem, and I personally would urge people to give it serious consideration. People running servers such as BBN's might consider extending the "wait" time before reporting success prematurely beyond the dis- tributed 30 seconds. It would be good in this regard to know how long people's mailers will wait before assuming that the server has disappeared. I would suspect, though, that this "wait" time could be extended to at least 60 seconds without problems. It would be nice if there were some accepted "intermediate" reply code which a server could send back to the mailer periodically -- something like xxx Mail delivery is taking a while; please be patient ******************************************************************* *** This is ONLY an idea (that's one reason I used "xxx" rather *** *** than a real numeric code); it isn't part of the standard; *** *** so don't anyone go implement this in their SMTP server and *** *** then say that Rich Wales at UCLA told you to, eh? *** ******************************************************************* Something like this would get around all the timeout problems. Un- fortunately, RFC821 doesn't provide for such a facility, and I am enough of a realist not to hope too strongly for a revision of the current standard. -- Rich  Date: Thu, 20 Oct 83 15:53:43 EDT From: Dave Crocker To: Gary M. Palter cc: Header-People@mit-mc.arpa Subject: Re: [OBERST%educom: Quoted @ in To: field] I was under the impression that full domain qualification was only required if the message crossed domain boundaries, but that partial specification could be retained if the message was sent between systems in the same domain. Don't have the spec in front of me, though. Dave  Date: Thu 20 Oct 83 13:11:36-PDT From: Mark Crispin Subject: Re: Results of SMTP server inquiries To: v.wales@UCLA-LOCUS.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Rich Wales " of Thu 20 Oct 83 11:24:04-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 SMTP sender will time out a transaction after waiting 5 minutes for an SMTP reply (including the reply after the end-of-message signal in a DATA command). I decline to make that time out interval longer. I think it should be shorter, like 1-2 minutes. That time is time that other messages waiting to go out are delayed. Problem is, as Rich says, too many Unix sites run the SMTP server that makes you wait for each individual copy to be delivered. At the former 2 minute time out (in NCP days it was 1 minute!), messages simply weren't getting through to a number of these sites. I consider that behavior to be rather anti-social of an SMTP server. After all, by this time there is no way to report the failure of an individual recipient (e.g. disk allotment exceeded, etc.). To properly report the error the SMTP server's system will have to do it in a message to the Return-Path anyway! If it gave an error code at the end of the DATA command, the SMTP sender would have no choice but to assume that the entire message lost to all recipients and it needs to requeue it. What MMDF and TOPS-20 does -- that is, queueing the message to a spool area and have an independent mailer process deliver the message to all the recipients without delaying the SMTP server -- is the right thing. Could we see MMDF's SMTP server more widely distributed? -------  Date: Thu 20 Oct 83 13:20:46-PDT From: Mark Crispin Subject: Re: [OBERST%educom: Quoted @ in To: field] To: dcrocker@UDEL-RELAY.ARPA cc: Palter@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Dave Crocker " of Thu 20 Oct 83 13:04:45-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I think Dave Crocker is right that "full domain qualification [is] only required if the message crosse[s] domain boundaries". That is, according to RFC 822. Dave was certainly quite insistant upon this particular feature going into the spec (I don't have it in front of me just now either) and I'd be surprised if it slipped out. This isn't to mean this is a good idea. Any mailsystem which puts anything other than absolute domain names in a message header is guaranteed to have problems. Let's go back to the host-less header issue if you don't believe me. -------  Date: 21 Oct 1983 0705-PDT Sender: WMARTIN at OFFICE-3 Subject: "Anti-Social behavior" of mailers From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Message-ID: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN> This is peripheral to the SMTP server discussion, but the comment about messages to an individual recipient being rejected for such reasons as "disk allotment exceeded" strikes me as being an example of an institutionalized anti-social attitude in itself. (Let me first emphasize that I am not accusing the correspondents of anything; it was just the use of the particular example that led me into this train of thought.) As a message sender, I have nothing at all to do with the recipient's housekeeping or host administration's practices, yet, in this case, I am being imposed upon by having my message rejected because the recipent has reached some arbitrary quota limitation. It's like the USPS returning mail because the addressee's PO Box is crammed full! The principle to be followed is that "mail is sacred". If adding mail to a recipient's receiving message-file causes that person to be overallocated or exceed some quota, it should be added nonetheless. It is the responsibility of the recipient to do whatever housekeeping is necessary to avoid whatever problems his system causes by his being overallocated. I know that this has some unfortunate side effects. A malicious sender can cause trouble by filling up space with garbage messages. Some systems have a lot of trouble letting a user clean up his disk area. (Such as Tenex, when a user is overallocated and the system free space is below the Free Space Fence limit -- he can't delete and expunge messages from the message-file because the system doesn't let the program create the scratch file necessary for the update.) But these problems can be tolerated, while arbitrary rejection of mail back to a sender, which forces the sender to do something about it, cannot. That is truly "anti-social", as it makes what should be an individual internal problem spread its effects outside that individual's boundaries, on the same host or across the net(s). A system administrator has all sorts of local methods to force disk usage limitation, but exporting hassles to the outside world shouldn't be one of them. If my mail to someone is rejected for this reason, I either have to decide to not send it and forget it, try sending it later (how many times, and how often, if the rejections continue?), or try other addresses or paths to the person behind the address. Even if this is being done by a process, not by me personally, it is using resources better expended on other matters. I just can't see this as a valid reason for failing to deliver mail, and I hope that any protocols or documentation that might imply that this is valid (such as providing a specific reply code to cover this instance) should be amended to emphasize how "anti-social" this action is. Maybe this is a non-issue; I don't recall ever receiving a message back explicitly stating that delivery was refused because the recipient was overallocated or the like. If everybody agrees with what I have said already, maybe the problem never arises. If so, I'm glad, and I'll shut up. (If not, I can always rant and rave ineffectually over here in the corner...) Regards, Will Martin  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Oct 83 13:07:21 EDT Date: 21 Oct 83 1313 EDT From: Rudy.Nedved@CMU-CS-A To: WMartin@Office-3 (Will Martin) Subject: Re: "Anti-Social behavior" of mailers CC: Header-People@MIT-MC In-Reply-To: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN> Message-Id: <21Oct83.131321.EN0C@CMU-CS-A> CMU Computer Science and Robotics Institutue doesn't implement mail restrictions at the moment but sometimes it gets very tempting. CMU Computation Center on the other hand has 3000 students some of which abuse the mail system just like dorms. They like to have "fun" sending .EXE files and FORTRAN-77 documents to a friends mail box. CMU CC had to respond by cutting the ability off since their other options were ineffective. CMU CS/RI Operations got dragged into the undergrad education business and we have noticed abuses. We have had the same problem but because we are a more serious and smaller organization, we have the ability to say "you will lose your account and fail the course if you don't stop this abuse" and we can make it happen. So....have sympathy with people that restrict mail to the disk space people have....if you were in their shoes with their budgets, users and politics you would probably have the same problem. Rudy Nedved Research Systems Programmer Computer Science & Robotics Institute Operations Carnegie-Mellon University  Date: 21-Oct-83 10:31 PDT From: Bill Barns Subject: Re: "Anti-Social behavior" of mailers To: WMartin@Office-3 (Will Martin) Cc: Header-People@MIT-MC Message-ID: <[OFFICE-2]TYM-WWB-3E62A> In-reply-to: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN> The solution actually in force on Office-3 (and I should think in most places(?)) is that a 4xx reply code from the remote (receiving) host would cause the Office-3 SMTP sender to resend to the failing addresses periodically for some period of time. The particular sender which runs on Office-3 retries about every 5 minutes, and keeps trying forever. The key here is that a receiver which wants to reject for such reasons as lack of disk space should return a 400 series error code. I'm on travel and don't have an SMTP protocol document handy, but I think that is what it says to do. 400 series codes imply that the receiver program has reason to believe that things will work better in the future if the sender will just wait "a while". 500 series error codes imply a fundamental impossibility. I hope nobody returns a 5xx for "over allocation". I seem to remember reading that the USPS can refuse to deliver mail to people who don't comply with certain requirements, such as having the address displayed clearly and a suitable mail box (mail slot, ...) to put the mail in. I think they retain the mail at the post office for 30 days and after that, all bets are off. This is essentially analogous to what happens with a reasonable SMTP sender-receiver interaction... -b  Date: Fri 21 Oct 83 12:15:40-PDT From: Mark Crispin Subject: Re: "Anti-Social behavior" of mailers To: WMartin@OFFICE-3.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "WMartin at Office-3 (Will Martin)" of Fri 21 Oct 83 07:05:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bill - I beg to disagree. Just about every mail system (including the Postal system!) has a "no more space for additional mail" condition. In the case of the Postal system, the recipient is considered to be on vacation and an automatic hold is placed on his mail. After some time without being picked up the mail is either returned to sender, forwarded to the new address, or goes to the dead letter department. Some electronic mailsystems even have an explicit limitation on the number of messages in a user's "in box", especially the various microcomputer "bulletin board systems" (BBS) using floppy disks for storage. All mailsystems have some implicit limitation due to the size of various data structures and/or address space, but it is generally quite high. If nothing else there is a limit on the total amount of disk space available on the entire system. The point is, even without disk allocation enforcement some limit will always exist. The TOPS-20 mailsystem does enforce disk quotas on incoming messages. It does not reject the message right away. Rather, it holds the message for an interval (3 days as supplied by me) and retries every 30 minutes or so. The recipient is also notified that there is mail in the queues pending because it would exceed his/her disk quota. Only messages which would exceed the disk quota are held. Normally messages are delivered in the chronological order they were queued, but an exception is made in this case. For example, if a user has 10 free pages (TOPS-20 allocates disk space in "pages" of 512 36-bit words or 2560 characters) in his/her allocation and receives three messages of 11, 2, and 7 pages at that time, the 2 and 7 page messages will be delivered and only the 11 page message will be held. If after 3 days the message is still undeliverable it is then returned to the sender; the sender also receives daily notifications of the problem. Considering the proliferation of electronic junk mail, it shouldn't surprise anyone that most system managers have no intention of exempting electronic mail from disk quota limitations. Some systems are run on a "disk quota is your guaranteed maximum disk charges basis" and its system manager has not intention of dealing with an irate user upset because junk mail added a hefty chunk to the user's disk charges. Other systems just don't have enough disk space. Finally, it should be considered that if a message is held for 3 days before being returned as undeliverable, it is either much too large for the user's disk quota or the user isn't reading his/her mail. In the former case, I stand firm in my unequivocal condemnation of the user of electronic mail as an FTP and my contempt for network designers who fantasize that electronic mail is a perfectly acceptable FTP mechanism. In the latter case, it isn't likely the user is going to be reading the mail at all soon anyway, and the telephone is preferred if the message is really necessary. -- Mark -- -------  Date: 21 Oct 1983 1136-PDT Sender: WMARTIN at OFFICE-3 Subject: More on "anti-social behavior" of mail systems From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Message-ID: <[OFFICE-3]21-Oct-83 11:36:10.WMARTIN> I've gotten a couple of responses to my H-P msg on mail rejection for disk overallocation reasons that have forcibly reminded me of the wide disparity of user communities out there. I had thought of including some sort of distinction between computer systems serving undergraduate academic communities and those serving people (i.e., those who use these resources as tools to perform work) but did not, as the original message was long enough as it is. If you are talking of an actively hostile and inimical user base, as the academic environment seems to be, both in fable and in truth, your users are trying to destroy you and each other by mailing megabytes of garbage, hacking away at any privacy or protection facilities, and generally behaving like vermin. That isn't the environment I am addressing, nor have I any particular sympathy any more -- I'm too old and tired for such games. I just cannot relate to that sort of situation any longer, so I cannot empathize with those of you who have to work in such a depressing situation. My attention is devoted to a production-oriented world and that is where I aimed my remarks. I am addressing the working office automation environment and in particular the transfer of functions from desktop and paper-based modes to electronic automated tools. In that situation, I reiterate my concern -- a message I send to someone should NOT be returned to me because of the addressee's disk usage situation. If the entire destination system's disks were crammed full, yes, it couldn't deliver, but it also couldn't run ANYTHING, so that is a specious argument. The automated systems must be at least as reliable as the old-style systems they replace, in addition to having all the advantages we know about and I needn't dwell upon. If the sender does his part (essentially no more than spell the addressee correctly), he has done all he should be expected to do. To return a message (or, worse yet, to just inform him of non-delivery) because of something that is in no way his fault is an insult and NOT tolerable. The only valid return is if the address cannot be interpreted or no longer exists, and no forwarding path ever existed. (Note that this means that forwarding should last for longer than the USPS one-year standard -- a table of former user-id's and forwarding paths doesn't eat up enough space to justify purging after just a year, when the environment is the normal working organization with ordinary personnel turnover.) I suppose I'll have to emphasize the distinction between my concerns in a production OA environment and their inapplicability in the undergraduate academic world (what would be a good shorthand term for this? -- how about "sandbox"?) from now on... I guess this disparity is probably largely responsible for the MILNET/ARPANET split, and all the attendant problems THAT is causing... Will Martin USArmy DARCOM ALMSA  Date: Fri, 21 Oct 83 15:13:22 EDT From: Brinton Cooper To: WMartin@office-3 cc: Header-People@mit-mc Subject: Re: Anti-Social behavior of mailers. ********** As a message sender, I have nothing at all to do with the recipient's housekeeping or host administration's practices, yet, in this case, I am being imposed upon by having my message rejected because the recipent has reached some arbitrary quota limitation. It's like the USPS returning mail because the addressee's PO Box is crammed full! ********** And just what do you think the USPS will do with mail if your letter carrier finds your PO Box crammed full? Indeed, what CAN the USPS do but to return mail? Brint  Date: 21 Oct 1983 1337-PDT Sender: WMARTIN at OFFICE-3 Subject: Re: Anti-Social behavior of mailers. From: WMartin at Office-3 (Will Martin) To: abc at BRL-BMD Cc: header-people at MIT-MC Message-ID: <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN> In-Reply-To: Your message of Fri, 21 Oct 83 15:13:22 EDT For crying out loud... The USPS puts a notice in the box (taking back out 1 letter to make room if necessary) that more mail is waiting and must be called for at the window. Then all the extra incoming mail is bundled up and held in the sorting area. When the recipient opens his mailbox and pries out the wadded-up ball of mail that is in there, he takes the notice to the window during regular office hours and gets the extra mail. If this happens often, the USPS can insist (I believe on pain of cancelling the PO Box) that the recipient pay for a larger box or drawer which will hold the usual amount of mail, or arrange for service whereby all mail is called for instead of being put in a box at all. Note that the mail is NOT returned to sender; the recipient and the delivery service are the only ones involved. I thought that everybody knew this... The parallels with an automated system are obvious. If the system has to have fixed and not-exceedable disk quotas, incoming mail can be put into a system-level directory and flagged for the correct recipient mailbox. Delivery from there to the user could be automatic or not, depending on local policy. In a real work environment, if the users need more space than they are given, it is justification for buying more and bigger disks; then they can be given what they need or want. Or they can be made to justify larger requirements. (This is a mistake when implementing new OA systems, as you want to get them hooked on using the system and make it as easy and rewarding as possible. Only after they have used it and come to rely on it should you start turning the screws on them.) There are enough charge-back mechanisms for private or governmental organizations to make them pay for what they want, if you find that necessary. Martin  Date: 21 Oct 1983 1337-PDT Sender: WMARTIN at OFFICE-3 Subject: Re: Anti-Social behavior of mailers. From: WMartin at Office-3 (Will Martin) To: abc at BRL-BMD Cc: header-people at MIT-MC Message-ID: <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN> In-Reply-To: Your message of Fri, 21 Oct 83 15:13:22 EDT For crying out loud... The USPS puts a notice in the box (taking back out 1 letter to make room if necessary) that more mail is waiting and must be called for at the window. Then all the extra incoming mail is bundled up and held in the sorting area. When the recipient opens his mailbox and pries out the wadded-up ball of mail that is in there, he takes the notice to the window during regular office hours and gets the extra mail. If this happens often, the USPS can insist (I believe on pain of cancelling the PO Box) that the recipient pay for a larger box or drawer which will hold the usual amount of mail, or arrange for service whereby all mail is called for instead of being put in a box at all. Note that the mail is NOT returned to sender; the recipient and the delivery service are the only ones involved. I thought that everybody knew this... The parallels with an automated system are obvious. If the system has to have fixed and not-exceedable disk quotas, incoming mail can be put into a system-level directory and flagged for the correct recipient mailbox. Delivery from there to the user could be automatic or not, depending on local policy. In a real work environment, if the users need more space than they are given, it is justification for buying more and bigger disks; then they can be given what they need or want. Or they can be made to justify larger requirements. (This is a mistake when implementing new OA systems, as you want to get them hooked on using the system and make it as easy and rewarding as possible. Only after they have used it and come to rely on it should you start turning the screws on them.) There are enough charge-back mechanisms for private or governmental organizations to make them pay for what they want, if you find that necessary. Martin  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Oct 83 16:28:54 EDT Date: 21 Oct 83 1638 EDT From: Rudy.Nedved@CMU-CS-A To: WMartin@Office-3 (Will Martin) Subject: Re: More on "anti-social behavior" of mail systems CC: Header-People@MIT-MC In-Reply-To: <[OFFICE-3]21-Oct-83 11:36:10.WMARTIN> Message-Id: <21Oct83.163827.EN0C@CMU-CS-A> Will, Okay, ignore the problem of the unprofessional and/or discourteous world (ever encroaching because of PCs and better internetting capabilities). The problem with drawing analogies between the ARPANET/MILNET mail system and any known postal system is the cost is fixed for the former and not accountable to an individual mail box. If this condition existed in the real world, say that the goverment financed mail and no one paid postage what do you think would happen?? I suspect junk mail would be filling up people's mail boxes to the max and the post office would be going nuts with the load. I can start imagining regulations similiar to what happen during gas shortages....of course people could be required to fill out 20 forms in order to send mail...that "fixes" alot of problems. Anyhow, that argument is not hitting your "office world" but I can put it in perspective. What do you do when you want to send a large package?? Do you just do it?? or is there some limiting factor like a budget item or a boss?? If you took away that limiting factor, undoubtedly you would have problems. The disk space restriction is by no means the best way to handle things nor is the "mail is sacred" philosphy. The best model I know of which would be pretty hard to implement at the moment is "postage". MCI Mail and TELENET mail all cost something and when you want to send a letter, you think about those costs.... -Rudy  Date: 21 Oct 1983 17:30:39 EDT (Friday) From: Dan Franklin Subject: Re: Anti-Social behavior of mailers. In-Reply-to: Your message of 21 Oct 1983 13:37 PDT To: WMartin at Office-3 (Will Martin) Cc: header-people at MIT-MC You still need flow-control. Even if there is a spool directory, some provision must be made for its running out of space because of some runaway mailer which is delivering the same message over and over again. In this situation, the receiving host should not start scrounging for all the space it can find, because that WILL bring the system to a halt and prevent any work from getting done--an intolerable situation which is considerably worse to the host's users than the "insult" of getting mail returned is to you. The receiver must refuse to accept further mail which would cause its spool directory to become too large. But this doesn't mean that the original author of the message (you) should get the message back. Rather, the mailer that tried to send the message should now hold on to it and retry, forever--with a notification to the author that it's doing so (after some interval), because people expect timely delivery of electronic mail and should be informed when that's not the case. Even the sending mailer's spool area could become full. At that point it would have to start returning mail to you that it couldn't deliver immediately. At some level, this can't be avoided. It can only be made very unlikely. Dan Franklin  Date: Sat, 22 Oct 83 6:19:49 EDT From: Stephen Wolff To: Will Martin cc: Header-People@mit-mc Subject: Re: More on "anti-social behavior" of mail systems Dear Will, It was a mistake for me not to take your first letter on anti-social behaviour seriously; that error led to my "spontaneous generation of disk space" note for which I apologize. I should imagine that something very near to the delivery guarantee that you desire (even in a system with rigid quotas) can be had rather easily in a nice mail system such as mmdf that uses an off-line, trusted deliver daemon (local letter-carrier). While it would make his job somewhat longer, he COULD check disk space and, if delivery would put a user over quota, file the message in a special `pending' file and leave a brief note in the `motu' file (UNIX, sorry) that is displayed at the next log-in. Or you could exert some social pressure with a note in motg: "Mail is pending but cannot be delivered to the following group members because they are disk hogs: ........" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "I'm old, but not THAT tired," as the bishop said to the actress. -steve -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-  Date: Sat, 22 Oct 83 1:50:33 EDT From: Mike Muuss To: Will Martin cc: Header-People@mit-mc Subject: Re: "Anti-Social behavior" of mailers As a maintainer of large mailing lists, I get between 3 and 200 messages rejected, or warnings returned, because a subscriber did not have any disk quota left. It's hard to know how to deal with this in a fully general way, but overall, disk space is cheap enough these days that I vote in favor of Will Martin's suggestion to treat mail as sacred. I vote with my feet -- our mail system works that way. -Mike  Date: Sat, 22 Oct 83 16:02:22 EDT From: Ron Natalie To: Will Martin cc: Header-People@mit-mc Subject: Re: "Anti-Social behavior" of mailers Well, I'll tell you, as maintainer of several large mailing lists I can say that it does happen. The DEC-20's are the main cuprits. You don't know how really disappointing it is to get letters from remote mailers saying "user so and so is over quota so I haven't been able to deliver mail to him in over a day, but I will keep trying for two more days" for every single submission to lists with as much traffic as INFO-MICRO and INFO-CPM. I've had to adopt the rather hard-assed policy of dropping users from the lists as soon as this starts happeing. However, two days after the first message I get another message from the 20 mailer saying "sorry, still can't deliver to the bastard, I give up." I used to try to send mail to these sites and tell them (a note to postmaster, I obviously can't send mail to the user telling them that they can't recieve mail...it's like Les Nessman on WKRP announcing that the transmitter blew up and they were no longer on the air during one of his newscasts). You know what resulted from this...NOTHING. A majority of these sites do not respond to mail addressed to POSTMASTER. I finally broke down and started obtaining the host liasons from the NIC and contacting them. -Ron  Date: Sat, 22 Oct 83 16:06:46 EDT From: Ron Natalie To: Rudy.Nedved@cmu-cs-a cc: Will Martin , Header-People@mit-mc Subject: Re: "Anti-Social behavior" of mailers Then I assert, it would be less grief on my part if the remote mailer would return a 4XX error immediately rather than queuing the dumb letter up on the remote site to fail later, so that I can cancel it on my end. -Ron  Date: Sat, 22 Oct 83 16:11:20 EDT From: Ron Natalie To: Brinton Cooper cc: WMartin@office-3, Header-People@mit-mc Subject: Re: Anti-Social behavior of mailers. But the USPS doesn't return your mail. They just cram a little pink slip in your mailbox that tells you that you have more mail in a sack somewhere. Typically, you have only 7 days to claim it however. -Ron  Date: 22 Oct 1983 2138-EDT From: Greg Skinner Subject: Re: Computer Science Seminar at BU To: G.Bostonu=csc126 at UCB-VAX at MIT-ML cc: msggroup at MIT-OZ, header-people at MIT-MC Reply-To: ee.gds@oz In-Reply-To: Your message of 22-Oct-83 1825-EDT I am very curious. Why do bitnet addresses have the syntax ? -------  Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA29422; Sun, 23 Oct 83 14:54:49 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA02557; Sun, 23 Oct 83 15:03:23 pdt From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 23 Oct 1983 1503-PDT (Sunday) Message-Id: <2556.31.435794600@ucbarpa> To: Rich Wales Cc: Header-People@MIT-MC Subject: Re: Results of SMTP server inquiries In-Reply-To: Your message of Thu, 20 Oct 83 11:01:54 PDT. <8310201820.AA02312@ucbvax.ARPA> Fcc: mail Sendmail as distributed on 4.2 does not hold the connection open for delivery. It does expand aliases and verify addresses. In some cases (e.g., very large lists on a loaded machine) this can take a fairly long time, but far less than necessary for actual delivery. Sendmail on 4.1a did have the problem you describe. eric  Date: Sun, 23 Oct 83 1:13:49 EDT From: Brinton Cooper To: Ron Natalie cc: Brinton Cooper , WMartin@office-3, Header-People@mit-mc Subject: Re: Anti-Social behavior of mailers. And after 7 days...?  Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:02:01-edt Date: Fri 21 Oct 83 15:47:34-PDT From: Mark Crispin Subject: Re: More on "anti-social behavior" of mail systems To: WMartin@OFFICE-3.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "WMartin at Office-3 (Will Martin)" of Fri 21 Oct 83 11:36:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bill - There is a very simple way to have a "reliable automated system" of the sort you crave, with no mail rejections because of disk allocations. The site management should give all the users infinite disk allocations, or at least infinite "hard" disk allocations. TOPS-20 supports the concept of separate hard ("working") and soft ("permanent") disk allocations. Be advised that while you may feel "insulted" that your mail got rejected because the recipient's disk allocation was exceeded, most systems (e.g. TOPS-20) only do this when the condition is chronic for 3 days. 3 days is a parameter the site management can reconfigure to whatever value they please. There is every reason to believe that that user is not likely to see that message at all soon anyway! -- Mark -- -------  Received: from USC-ECL (usc-ecl.ARPA) by ucbvax.ARPA (4.16/4.11) id AA07248; Sun, 23 Oct 83 21:13:07 pdt Date: 23 Oct 1983 21:20-PDT Sender: ESTEFFERUD@USC-ECL Subject: RE: COMPUTER SCIENCE SEMINAR AT BU From: ESTEFFERUD@USC-ECL Reply-To: MSGGROUP-REQUEST@BRL To: EE.GDS%OZ@BRL Cc: G.BOSTONU=CSC126@Berkeley, MSGGROUP@BRL Cc: HEADER-PEOPLE@MIT-MC Message-Id: <[USC-ECL]23-Oct-83 21:20:20.ESTEFFERUD> In-Reply-To: THE MESSAGE OF 22 OCT 1983 2138-EDT FROM GREG SKINNER SIGH! PLEASE RESTRICT REPLIES TO HEADER-PEOPLE ONLY! STEF  Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:19:52-edt Date: Sat 22 Oct 83 17:56:10-PDT From: Mark Crispin Subject: Re: "Anti-Social behavior" of mailers To: ron@BRL-VGR.ARPA cc: WMartin@OFFICE-3.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Ron Natalie " of Sat 22 Oct 83 15:29:38-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I see nothing wrong with dropping the culprits from the large mailing lists. Anybody who doesn't keep their mailbox available shouldn't be on those lists. I actively encourage it; it seems to be the only way those lists ever get pruned of deadwood. -------  Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:43:22-edt Date: Sat 22 Oct 83 17:54:13-PDT From: Mark Crispin Subject: "Anti-Social behavior" of mailers To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The attitude that mail is sacred is fine in a fantasy world where nobody pays for their disk usage. I guess the military lives in that fantasy world. I knew some research organizations do. Somebody has to pay for the disk space used. An inactive non-paying user's account can trivially accumulate tons of junk mail. Stanford's Computer Science researchers are willing to pay for large chunks of disk space needed for their research work. They aren't willing to pay for large chunks so that some student helper can store thousands of messages about the latest in science-fiction novels and movies. Some accountability has to exist. I'll bet that most of the accounts that get "disk quota exceeded" return mail fall into a peripheral category of user. You know the type; some undergraduate who gets an account for a summer job and proceeds to get on every mailing list on the ARPANET. I'm sorry if DARCOM doesn't like this. But have I got a deal for DARCOM. We'll remove the restrictions if DARCOM is willing to pay for the disk usage of all such users. We'll be quite happy to take DARCOM's money to support unimpeded junk mail. Of course, the GAO may object. But that would be DARCOM's worry, wouldn't it? -------  Date: Sunday, 23 October 1983 23:00 edt From: "Jeffrey I. Schiller"@MIT-MULTICS.ARPA Subject: Re: "Anti-Social behavior" of mailers To: Mark Crispin cc: WMartin@OFFICE-3.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message of 21 October 1983 15:15 edt from "Mark Crispin" Message-ID: <831024030006.385023@MIT-MULTICS.ARPA> The Multics mailer behave exactly as MRC describes his TOPS-20 mailer (but silently, ie. when we receive mail for a user overquota it is silently queued for later delivery). If this mail isn't delivered in 5 days it will then be returned. The way we solve the system disk space problem (ie. a mailer goes nuts and starts sending tons of crap at us) is to make sure we have enough disk space around to absorb stuff for as long as it takes for a staff member here to notice the problem and remedy it (up to a day). -Jeff  Date: 23 Oct 1983 22:29-PDT Sender: GEOFF@SRI-CSL Subject: Re: "Anti-Social behavior" of mailers From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff@SRI-CSL To: header-people@MC Message-ID: <[SRI-CSL]23-Oct-83 22:29:52.GEOFF> I think the bulk of complaints could be solved if the TOPS-20 mailer (and others) only notified the message sender of its COMPLETE FAILURE to deliver the message after a certain time period (along with a copy of the undeliverable message). Instead, of its current practice of sending nuisance warning message after nuisance warning message and then eventually the failure to deliver message. I only want to be notified on COMPLETE FAILURES of an attempt to deliver a message, not a day-by-day count down of "n more days to go before I'll be returning your as yet undelivered message to you." --or at least there ought to be a way for the sender to notify foreign mailers to only tell them of COMPLETE FAILURES and suppress all the warning crap. Geoff  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.11) id AA06003; Mon, 24 Oct 83 08:32:55 pdt Received: from ucbjade.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.10/4.6) id AA27967; Mon, 24 Oct 83 08:41:43 PDT Message-Id: <8310241541.AA18440@ucbjade.CC.Berkeley.ARPA> Received: from UCBCMSA.BITnet by ucbjade.CC.Berkeley.ARPA (4.10/4.6) id AA18440; Mon, 24 Oct 83 08:41:29 PDT Date: Mon, 24 Oct 83 08:38:48 PDT From: SPGGGM%UCBCMSA.CC@Berkeley To: ee.gds@mit-oz.ARPA Cc: csc126%bostonu.BITNET@Berkeley, header-people@mit-mc.ARPA Subject: bitnet addresses Bitnet addresses are currently of two flavors. The addresses you will see on this message are the 'new' style. The addresses of form g.host=user are artefacts (and, in fact, rather embarrassing). Greg Minshall  Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA06495; Mon, 24 Oct 83 09:07:58 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA09909; Mon, 24 Oct 83 09:16:29 pdt From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 24 Oct 1983 0916-PDT (Monday) Message-Id: <9907.31.435860186@ucbarpa> To: WMartin@Office-3 (Will Martin) Cc: header-people@MIT-MC Subject: Re: Anti-Social behavior of mailers. In-Reply-To: Your message of 21 Oct 1983 1337-PDT. <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN> Fcc: mail A semi-naive user (i.e., someone who views a computer system as a tool that should work, rather than as a toy to tinker with) wants that tool to work. If the user is unfamiliar with the system, sending a simple message can be a major project. If that message is rejected with the not-so-obvious message "user allocation quota exceeded: message rejected" or some such (and the message is not returned!!), some people will never try again -- they will have been converted to subconcious saboteurs. I'm sure all of us have met the type at one time or another. This is especially prevalent in office automation environments. eric allman  Received: from merlin.ARPA by purdue.ARPA; Mon, 24 Oct 83 11:38:38 EST From: Christopher A Kent Message-Id: <8310241638.AA09743@merlin.ARPA> Received: by merlin.ARPA; Mon, 24 Oct 83 11:38:40 EST Date: 24 Oct 1983 1138-EST (Monday) To: eric%ucbarpa@Berkeley.ARPA (Eric Allman) Cc: header-people@MIT-MC.ARPA, WMartin@Office-3.ARPA (Will Martin) Subject: Re: Anti-Social behavior of mailers. In-Reply-To: Your message of 24 Oct 1983 0916-PDT (Monday). <9907.31.435860186@ucbarpa> MRC flamed a little while ago about users who use mail as a type of FTP. I agree that this is, in general, a bad thing. But what we are going to run into this all over again, and in massive proportions, when the MILNET mail bridges start enforcing the SMTP only fence. What then? Cheers, chris ----------  Date: Tue, 25 Oct 83 1:05:01 EDT From: Ron Natalie To: ee.gds%oz@brl.arpa cc: G.Bostonu=csc126@ucb-vax, msggroup%mit-oz@brl.arpa, header-people@mit-mc Subject: Re: Computer Science Seminar at BU Bitnet sites don't. This is a perterbation done by Berkeley sendmail program which is the most frequently used arpanet to bitnet gateway. BITNET addresses are rather bland RFC822 stuff like: FRED@PSUVAX BRUCE@UMDB etc...Within BITNET that address was likely: CSC126@BOSTONU. -Ron  Date: Tue, 25 Oct 83 1:29:37 EDT From: Ron Natalie To: Brinton Cooper cc: Ron Natalie , Brinton Cooper , WMartin@office-3, Header-People@mit-mc Subject: Re: Anti-Social behavior of mailers. Return to sender. Although as I recall, this may only apply to non-first class stuff. -Ron  Date: Tue, 25 Oct 83 2:00:42 EDT From: Ron Natalie To: Mark Crispin cc: ron@brl-vgr.arpa, WMartin@office-3.arpa, Header-People@mit-mc.arpa Subject: Re: "Anti-Social behavior" of mailers My major complaint is that when dealing with a list of over 200 adresses that handles over 20 pieces of mail a day, it takes very few people being "anti-social" to blast the REQUEST mailbox all to hell with failed mail requests. Currently I am helpless once some site tells me "couldn't do it in a day" for I know that in two more days I will get another answer "couldn't do it at all" and I am helpless to stop it. Perhaps the solution here is a class a service field? This would allow mail to be marked as "junk mail" (or perhaps "bulk mail" is more appropriate) and have the error processing behave differently. -Ron  Date: 24 Oct 83 19:46:20 PDT (Mon) From: Marshall Rose Return-Path: Subject: Re: Anti-Social behavior of mailers. Message-Id: <267.435897980@uci-750a> To: Christopher A Kent Cc: header-people@Mit-Mc, Will Martin In-Reply-To: Your message of 24 Oct 1983 1138-EST (Monday). <8310241638.AA09743@merlin.ARPA> Via: UCI; 24 Oct 83 20:21-PDT [N.B.: This message classifies as a flame since it takes a position somewhat different that those currently being espoused...] A couple of points: In principle I will agree that using mail services as an ftp facility is a bad idea. As someone who lives primarily in the CSnet world, though let me point out that we don't enjoy the type of connectivity that you ARPAnetters take for granted. We spend our time living at the end of a 1200-baud phone link, most of us connect to an ARPAnet site perhaps two to four times a day in the evening and early morning hours. Some of us are lucky enough to have a guest account floating about on a machine with ARPAnet access, so we can get to all kinds of information. UCI is lucky, we'll shortly become a member of the ARPA Internet community (but over a 9600 baud line, sigh...), but others are not. The point of this is that you really shouldn't try and judge those who are connectivity-poor by your standards. I don't know if you really appreciate your high-standard of communications-living. Second, do you people really have distribution list stuff delivered to your private mailboxes??? Although I read quite a few lists, none of it goes to my private mailbox. It all gets diverted to a common, public area, where a single copy is kept. This area is automatically cleaned out on a regular basis. Not only does this save gobs of disk space but it also keeps bulk-rate mail out of my private "post-office box". Since we're running BSD UNIX, we don't have disk-quotas, so I don't worry about having mail rejected for that reason (it is true we could run out of disk space, but that's another story). I would get very, very upset if my mail got returned because of some "administrative nonsense" about disk quotas. Once I log in, I should be responsible for trimming things to reach my quota, but until I do so, I DEMAND that my mail not be returned unless the disk is full. My extreme position is due, of course, to the fact that I know only IMPORTANT mail gets delivered to my private mailbox. Awaiting your equally hot rejoinder to my response, /mtr BTW - I'm giving people a few more days on the "Can your UA filter-out unwanted headers?" query before I post the summary.  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 25 Oct 83 09:24:00 EDT Date: 25 Oct 83 0932 EDT From: Rudy.Nedved@CMU-CS-A To: Marshall Rose Subject: Re: Anti-Social behavior of mailers. CC: Header-People@MIT-MC In-Reply-To: <267.435897980@uci-750a> Message-Id: <25Oct83.093228.EN0C@CMU-CS-A> In the world of 1200 UUCP/DIALNET links and 9600 IP links, there is also a world of private and ugly hacks that get mail thru. These ugly transfer hacks tend to clog up when they try to handle 1MB files since they were never designed to handle slow delivery processes and systems. I have a feeling that for every person that uses the system as a file transfer mechanism, there is a tenuous link between a two machines that can't handle a large file. Admittedly things are getting better when people use better hardware links and better software but things can't change over night. CMU Computer Science sites are constantly running out of disk space even though we have disks galore....People are just to lazy to clean up there disk space and be frugal about it. Hey like laser disks are around the corner!!! (If you believe that I have this bridge in Pittsburgh to sell you). I think a more constructive tack to take with this issue is the discussion of first class and second class mail. We will probably implement a mechanism that uses the size of the file to determine its priority since the mail world is expanding faster then the IP world and we do hit slow mail bridges. The question remains is it reasonable to expect some pieces of mail to be delivered to another site in the world within 10 minutes?? I have discovered people sending out mail to other people saying "Joe called a few minutes ago, he wants to talk to you before your meeting in an hour." -Rudy  Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA02389; Tue, 25 Oct 83 08:05:48 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA25935; Tue, 25 Oct 83 08:14:35 pdt From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 25 Oct 1983 0814-PDT (Tuesday) Message-Id: <25934.31.435942874@ucbarpa> To: Christopher A Kent Cc: header-people@MIT-MC.ARPA, WMartin@Office-3.ARPA (Will Martin) Subject: Re: Anti-Social behavior of mailers. In-Reply-To: Your message of 24 Oct 1983 1138-EST (Monday). <8310241638.AA09743@merlin.ARPA> Fcc: mail When mail is easy to use and FTP is hard to use, people will use mail instead of FTP. We can go on forever about how this is "the wrong way to do it" without changing this fundamental point of human nature. In many cases using Mail as FTP may even be correct -- e.g., when sending to some process that will consume the data and do something for you. The CSNET name server, MARS, and MOSIS are examples of this. Which still begs the question of how to handle the resulting disk space problem. My point is simply that we cannot ignore the issue in the hopes that we can convince people not to do it. eric  Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA02757; Tue, 25 Oct 83 08:22:32 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA26146; Tue, 25 Oct 83 08:31:25 pdt From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 25 Oct 1983 0831-PDT (Tuesday) Message-Id: <26145.31.435943884@ucbarpa> To: Ron Natalie Cc: WMartin@office-3.ARPA, Header-People@mit-mc.ARPA, Mark Crispin Subject: Re: "Anti-Social behavior" of mailers In-Reply-To: Your message of Tue, 25 Oct 83 2:00:42 EDT. <8310250631.AA24631@ucbvax.ARPA> Fcc: mail If you include a "Precedence: junk" field in the header, sendmail will throw away error messages rather than return them. This was intended to act like USPS "junk mail" service. eric  Date: Tuesday, 25 Oct 1983 10:45-PDT From: Steven Tepper To: header-people@MIT-MC Subject: "Precedence: junk" field Things like a "precedence" field aren't too useful if only one mail system knows about them. Maybe someone should send this, or other related suggestions, out as an RFC. Then if there is general agreement that it's a good idea, there is even some hope of it being implemented on enough systems to be of some real use.  Date: 25 Oct 1983 2143-EDT From: Greg Skinner Subject: Re: Anti-Social behavior of mailers. To: mrose.uci-750a@RAND-RELAY cc: header-people@MIT-MC In-Reply-To: Your message of 24-Oct-83 1946-EDT It's rather difficult to have public mail-archive files that everyone can use. If there isn't enough disk space for everyone to keep theeir own junk mail, there sure isn't enough space to keep public junk mail. MIT systems generally keep public bboards around and discourage users from having distribution lists come to their private mailboxes. However, some systems just can't (or don't) have public bboards, and those users who want junkmail have to use their private accounts to store it. Another issue -- if there was a public bboard for every distribution list in the Internet world, every machine on the Internet would be dedicated to mail processing and storage, and no other work would get done. The demand for certain mailing lists is low (e.g. AI-list would get lots less attention on one of our Internet vaxen used for networking or compiler research. The maintainers wouldn't be too happy about keeping a public bboard for it -- in fact, probably would wish people to have their junkmail forwarded to a machine on another system with more disk space. -------  Date: Tue, 25 Oct 83 22:31:18 EDT From: Ron Natalie To: Greg Skinner cc: mrose.uci-750a@rand-relay, header-people@mit-mc Subject: Re: Anti-Social behavior of mailers. The other advantage to having lower volume junk mail delivered to a user mailbox is that after he reads it he can delete it unless of significance to him. On a public BBOARD it must sit around for some period of time to allow everyone who may wish to see it to do so. -Ron  Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11) id AA05704; Tue, 25 Oct 83 23:13:16 pdt Received: by ucbarpa.ARPA (4.16/4.11) id AA09386; Tue, 25 Oct 83 23:22:04 pdt From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 25 Oct 1983 2322-PDT (Tuesday) Message-Id: <9385.31.435997321@ucbarpa> To: Mark Crispin Cc: Header-People@MIT-MC.ARPA Subject: Re: Results of SMTP server inquiries In-Reply-To: Your message of Thu 20 Oct 83 13:11:36-PDT. <8310240817.AA00221@ucbvax.ARPA> Fcc: mail I find your attitude rather offensive considering that the SMTP protocol does not specify timeouts. I agree that the protocol should specify some sort of timeout, and that real implementations should try to respond as quickly as possible, and even that real implementations need some sort of timeout for purely pragmatic reasons -- but two minutes?!? Sendmail uses a timeout of two hours (yes, hours), on the grounds that I never want to see a message trashing me for making the (apparently illegal) timeout too small. eric  Date: 26 Oct 83 13:29:10 PDT (Wed) From: Marshall Rose Return-Path: Subject: Re: Anti-Social behavior of mailers. Message-Id: <267.436048150@uci-750a> To: Greg Skinner Cc: header-people@Mit-Mc In-Reply-To: Your message of 25 Oct 1983 2143-EDT. Via: UCI; 26 Oct 83 19:24-PDT I'm not sure I understand what is meant by "enough disk space for everyone to keep their own junk mail", and "enough space to keep public junk mail". I don't consider anything sent to my private mailbox to be junk (though it does come close at times!), while I view everything sent to a public BBoard to be junk mail. Perhaps this is entirely a difference in perspective. Clearly though, it should be cheaper, in terms of disk space, to keep a single copy of a discussion group on a system than to replicate that copy several times over in various people's mailboxes. I wasn't suggesting that we should have copies of every discussion group on every system in the Internet: we have four machines locally, each with varying tastes, and they subscribe to different discussion groups. There is some overlap, but we never keep more than one copy of a particular message on a system unless a user specifically goes out of his/her way to duplicate it for his/her own, private purposes. It is also true that all systems can not support a public BBoard facility. This is unfortunate. But then its also true that a lot of systems don't support a lot of things that "sophisticated" mail users find to be "required", such as templates, good editor interfaces, etc., etc. I've always found it easier to code than to complain (no flames please), so it's my position to sigh and say, "Well, you could be doing X if you wanted to. We found that it solved a lot of problems, but do what you want with your system." /mtr PS - in a previous message I was't suggesting that CSnet people should be using mail for 1MB FTP:s or the like. I use mail for moving things like the smaller RFCs, etc. If it's something "really big", I'll FTP it "closer" to home, put it on tape, and then drive over.  Received: by ucbvax.ARPA (4.16/4.13) id AA01831; Thu, 27 Oct 83 17:34:42 pdt Date: 27 Oct 83 19:43:41 EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: Anti-Social behavior of mailers. Message-Id: <8310272343.AA05796@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA05796; 27 Oct 83 19:43:41 EDT (Thu) To: Gds@MIT-XX.ARPA Cc: header-people@mit-mc.ARPA Another issue -- if there was a public bboard for every distribution list in the Internet world, every machine on the Internet would be dedicated to mail processing and storage, and no other work would get done. The demand for certain mailing lists is low (e.g. AI-list would get lots less attention on one of our Internet vaxen used for networking or compiler research. The maintainers wouldn't be too happy about keeping a public bboard for it -- in fact, probably would wish people to have their junkmail forwarded to a machine on another system with more disk space. This is a reasonable guess, coming from a system that does not do this. But on Usenet, the situation is that every system gets (one copy of) every article. (There are exceptions - some systems refuse to accept certain newsgroups, others are tiny or phone-poor and can only get a handfull, but almost everybody gets everything.) We find that by treating each newsgroup as just another newsgroup (rather than having a list of 200 mailing lists that have to be maintained by a person) that the number of newsgroups is not really a limiting factor. The amount of traffic is the limiting factor. Not for the machine - when everything uses the same mechanism, you can find inefficiencies and streamline things - but for the people. No person has the time to read everything (not even Lauren) so we cut down what we don't want to read or don't have time to read. On cbosgd, we receive about 250 articles per week, with about 5 MB of text for a week. We receive each article from two (sometimes 3) different Usenet neighbors, and the first copy we get is forwarded to 8 other neighbors. Of course, things are batched - bulk mail is lower priority than people mail - this helps a lot. We also have various schemes to avoid keeping more than one copy on the disk at any time, so that if a neighboring machine goes down for a week, we don't fill up the disks with stuff for them. cbosgd is a VAX 11/750 running 4.1cBSD, and the load put on the machine by news is pretty insignificant. The major cost is having 10 MB of disk to keep 2 weeks of news around. I wonder if anyone has any figures on total traffic volume for the set of ARPANET mailing lists, or at least any estimates? I also wonder if there are any comparisons showing how many extra copies sit on machines where 2 or more people get a mailing list, compared to the savings from machines that only get some subset of the lists? Anyone know how much human effort is spent by people other than the master list moderator maintaining sublists? Mark Horton mark@Berkeley.ARPA  Date: Thu, 27 Oct 83 22:44:41 EDT From: Ron Natalie To: Mark Horton cc: Gds@mit-xx.arpa, header-people@mit-mc.arpa Subject: Re: Anti-Social behavior of mailers. You seem to be under the impression that delivering a copy of a bulk letter to multiple users on a machine induces more network traffic than delivering one copy to a billboard. Reasonable SMTP implementations deliver a single copy to remote site with multiple recipients so that it only transfers the message body once. -Ron  Date: 28 October 1983 22:55 edt From: Saltzer at MIT-MULTICS Subject: Re: What to do about non-Internet mail hosts. To: Schiller at MIT-MULTICS cc: Mark Crispin , dpk at BRL-VGR, Header-People at MIT-MC, Postel at USC-ISI, Saltzer at MIT-MULTICS, DClark at MIT-MULTICS In-Reply-To: Message of 14 October 1983 11:08 edt from Jeffrey I. Schiller Jeff, Are you sure that implementing domains completely solves the problem? It seems to me that depending on how far out of kilter the non-ARPA mail is that other hosts will still have trouble with the reply. I would have expected that it is inherent in the problem that a gateway that forwards mail from one system to another has to fabricate new headers as it goes across, unless it happens to get lucky. Jerry  Date: 29 Oct 1983 1055-EDT From: Greg Skinner Subject: Re: What to do about non-Internet mail hosts. To: Saltzer@MIT-MULTICS cc: header-people@MIT-MC In-Reply-To: Your message of 28-Oct-83 2255-EDT Domains actually could be a winning feature as far as reaching distant hosts on distant nets. Howerver, it seems that they are providing a current source of confusion. Some mailers (on uucp, for example) are trying to parse the domain field as just another host field, and run into trouble for replies (Unknown host: ARPA). As I understand it, domains are supposed to assist in the routing of messages to appropriate gateways. Thus, in the case of a host like MC, which talks to the Arpanet, LCSnet and Chaosnet, the domain field is pretty useful. But for non-Internet hosts which have no way of understanding this information (since they don't have our host tables) they can't handle the domain field correctly. From what I gather in your message, Internet hosts are having equal trouble with knowledge of unknown domains. (By the way, I heard that ARPA was the only recognized domain by the NIC -- what about UUCP, UCI, #Chaos etc. -- maybe unregistered domains cause the confusion.) It may be a bit much to ask for all mailers to adopt the same mail parsing, but I think we are rapidly approaching the point where if we want to be able to get a message from point to point, both points (as well as any intermediaries) should agree on how the message should be processed. --greg -------  Date: Saturday, 29 October 1983 12:34 edt From: "Jeffrey I. Schiller"@MIT-MULTICS.ARPA Subject: Re: What to do about non-Internet mail hosts. To: Saltzer@MIT-MULTICS.ARPA cc: Mark Crispin , dpk@BRL-VGR.ARPA, Header-People@MIT-MC.ARPA, Postel@USC-ISI.ARPA, DClark@MIT-MULTICS.ARPA In-Reply-To: Message of 28 October 1983 22:55 edt from Saltzer Message-ID: <831029163451.279380@MIT-MULTICS.ARPA> Indeed you are correct. What is needed is for the receiving host to know about all hosts in all domains. Alas this is what name servers are supposed to be from. So if a host received a piece of mail for FOOBAR.MAILNET and MAILNET was a registered domain (say with MIT-MULTICS as the home of the name server for that domain) then the receiving host could contact MIT-Multic's domain name server to get the forwarding host information (or failing that could merely send the mail to MIT-Multics for forwarding). -Jeff  Date: Sat 29 Oct 83 12:10:30-PDT From: Mark Crispin Subject: SMTP extension RFC To: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This Request for Comments suggests a potential extension to the SMTP standard (RFC 821). Should it be accepted, software designers are encouraged to support these optional extensions in order to gain the desired functionality. BACKGROUND Problems have come up with conflicting uses and needs of electronic mail. In particular, delivery or allocation considerations often conflict with a particular purpose electronic mail is put to, including: mailing lists, urgent messages, ordinary messages, etc. PROPOSAL RFC 821 is extended to add the CLAS command, for "class of service" for this message. CLAS takes at least one required argument, indicating the class of service. Future extensions may add subsequent arguments, or add additional classes of service. Should "too many arguments" be seen the excess arguments should be ignored by the SMTP receiver and the command accepted or rejected based on the SMTP receiver's willingness to accept the command and argument(s) it does recognize. CLAS is an optional command. An SMTP sender must be willing to accept a CLAS rejection. The default class is "CLAS 1", or "first class" mailing. The CLAS commands are: CLAS 1 - First class mail. This is a message on the level of a person-to-person message. Reasonable efforts should be made to deliver the message, and inform the sender (via the Return-Path) of any untoward delays. First class mail should not be rejected or returned to sender if it is reasonably possible to deliver the message within technical or managerial constraints. In particular, first class mail should not be rejected because that mailbox has a forwarding address to another mailbox elsewhere. Implementations should not reject first class mail based on allocation constraints without allowing at least a few days for the problem to clear up. CLAS 2 - Second class mail. This is a message on the level of a small or other "full participation" mailing list where all members can be expected to be interested in all the messages. Second class mail should be treated as first class mail in most respects, except that only non-delivery notifications should be made; no delayed delivery notifications are expected or desired. CLAS 3 - Third class or "junk" mail. This is a message for a large mailing list or other list in which only some of the messages may be of interest. Only non-delivery notifications should be made; return to sender is discouraged. Third class mail may be rejected immediately for forwarded addresses (see the SMTP specification for documentation of the 551 error) or insufficient allocation (see SMTP for 552). ** Note: First class mail should never be rejected because of 551 or 552 conditions. It is discouraged to use 551 or 552 for second class mail. ** CLAS 4 - Fourth class or "parcel post" mail. The message sent is large, e.g. a file or document being sent via a communication channel which does not support FTP. Fourth class mail is nominally treated as FIRST class mail. The receiver is strongly discouraged from rejecting or returning it to sender if it can be "reasonably" delivered. Fourth class mail exists to give the receiver warning of the large size of this message so that the receiver may deliver it separately and concurrantly with its normal mail delivery processes. CLAS P - Priority mail. This is the same as first class mail, but the receiver is asked to go to extra effort to deliver this message provided the receiver offers this service. For example, some receivers may allow allocations to be evaded via priority mail, but no receiver is obligated to do so. The receiver IS obligated to inform the sender promptly (e.g. within 30 minutes) of any delays in delivery. This differs from first class mail which should not start delay notifications until at least a day has elapsed. CLAS R - Registered mail. This is the same as priority mail, except that the receiver is obligated to give positive acknowledgement of delivery to the destination mailbox. This differs from positive acknowledgement of being read by the mailbox's owner, which would be implemented at the RFC 822 level. ERRORS 500 Command unrecognized 501 Syntax error 502 Command not implemented 503 Bad sequence; must give CLAS before recipients 503 Bad sequence; only one CLAS allowed for this transaction 504 CLAS type unknown, continuing to assume CLAS 1 ************************************************************************** I must apologize for any gothicness in this proposal. Obviously, it should be subjected to some modification prior to being adopted. I confess that this proposed implementation minimizes the amount of surgery required to the TOPS-20 mailsystem (in fact, very little would need to be done to do this), so there are probably some biases that need to be worked out. -------  Date: Sat, 29 Oct 83 17:02 EDT From: Robert W. Kerns Subject: SMTP extension RFC To: Mark Crispin Cc: Header-People@MIT-MC, Postel@USC-ISIF In-reply-to: The message of 29 Oct 83 15:10-EDT from Mark Crispin Message-ID: <831029170229.5.RWK@SCRC-YUKON> CLAS 3 - Third class or "junk" mail. This is a message for a large mailing list or other list in which only some of the messages may be of interest. Only non-delivery notifications should be made; return to sender is discouraged. Third class mail may be rejected immediately for forwarded addresses (see the SMTP specification for documentation of the 551 error) or insufficient allocation (see SMTP for 552). I don't think it is acceptable to not deliver so-called "junk" mail just because it requires forwarding. ALL of my mail in this class is forwarded by MIT-MC. MIT-MC serves as a central post-office relay facility in this, rather than as "moved, left forwarding address". And the so-called "junk mail", is actually closer to magazines than advertising flyers. Indeed, it is not clear from this what "forwarded" means. Is "RWK%SCRC-YUKON" at MIT-MC a forwarded address? How about RWK at MIT-MC, which is how my address appears on most mailing lists? Perhaps "forwarded" means simply an address that a mailer says to forward with a 551 response. Whatever THAT means; RFC-822 fails to assert this should be done only when a more direct path exists. And are user-end programs required to handle this by retransmitting to the new address? I'm not sure whether to change the statement of what's acceptable or the definition of "junk mail". I just want reliable delivery of mailing-list mail under ordinary circumstances.  Received: by ucbvax.ARPA (4.16/4.13) id AA16443; Sat, 29 Oct 83 19:07:42 pdt Date: 29 Oct 83 22:05:26 EDT (Sat) From: ulysses!smb@Berkeley (Steven Bellovin) Subject: SMTP Extension Message-Id: <8310300205.AA09044@ulysses.UUCP> Received: by ulysses.UUCP (3.327/3.7) id AA09044; 29 Oct 83 22:05:26 EDT (Sat) To: Header-People@MIT-MC, MRC@SU-SCORE Although I see why you want SMTP to know about mail classes, the user agent may need to know about them as well. In particular, I'd like my mail receiver or mail reader to be able to present my first-class mail first. Of course, this means that we need an RFC822-type header field as well. Any thoughts on how to integrate the two? --Steve Bellovin  Date: 29-Oct-83 22:45 PDT From: RICH.GVT@OFFICE-3 Subject: Re: SMTP extension RFC To: Header-People@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-3G4Z1> Integrating CLAS in the "envelope" and a new, matching, header field should be trivial. After all, it is from the user the information must come if other than the default class is to be used, and the user agent would both insert the Class: header field and pass the "envelope" information through the delivery slot to the User SMTP. -Rich Zellich  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 30 Oct 83 02:42:34 EST Date: 30 Oct 83 0247 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: SMTP extension RFC CC: Header-People@MIT-MC, Postel@USC-ISIF In-Reply-To: "Mark Crispin's message of 29 Oct 83 14:10-EST" Message-Id: <30Oct83.024718.EN0C@CMU-CS-A> Mark, Hopefully it would not be too much to ask to use keywords instead of numbers and single characters. I kinda like the future flexibility that keywords like "FIRST" or "THIRD" present over numbers like "1" and "3". Maybe only CMU'ers get burned because of our extremely non-homogenous enviroment with subtle design decisions like this one. -Rudy  Date: 30 Oct 1983 1132-EST From: Greg Skinner Subject: Re: SMTP extension RFC To: RWK@SCRC-YUKON cc: MRC@SU-SCORE, Header-People@MIT-MC, Postel@USC-ISIF In-Reply-To: Your message of 29-Oct-83 1707-EDT Perhaps instead of having immediate rejection of forwarded addresses, attempt to forward but do not return to sender if the ultimate destination is not reached. This way, for persons on remote nets who wish to receive mail from large distribution lists, they are not denied that privilege just because their net won't talk to ours. This also cuts down on the failed mail messages including text (which I find a pain, especially if a host tries for two weeks to forward a message and complains every day that it can't). Also, some forwarded messages are not relayed to other hosts -- for example, my address for MsgGroup (as far as BRL is concerned) is GDS-MSG@OZ which is forwarded to a mailbox especially for MsgGroup mail. I'd be very unhappy if because of class scheduling I couldn't get any MsgGroup mail anymore. -------  Date: Sun 30 Oct 83 10:49:30-PST From: Mark Crispin Subject: Re: SMTP Extension To: ulysses!smb@UCB-VAX.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "ulysses!smb@Berkeley (Steven Bellovin)" of Sat 29 Oct 83 22:05:26-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It strikes me that the presentation layer mail class may not necessarily be related to the transport layer mail class. I was, I confess, only addressing the transport layer issue. My suggestion would be to define a presentation layer mail class specification independently, and then consider how the two are best integrated. I suspect that their integration is best done as a user interface within the individual mail systems. -------  Date: Sun 30 Oct 83 10:56:04-PST From: Mark Crispin Subject: Re: SMTP extension RFC To: Rudy.Nedved@CMU-CS-A.ARPA cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 30 Oct 83 02:47:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I don't object to keywords at all, although there seems to be a tendency to use 1 or 4 character keywords. I was trying to follow the flavor of FTP and friends. My software would have no problem coping with any form of keywords, although it would be nice if they were 4 characters so that word comparisons would work nicely on all systems... -------  Date: Sun 30 Oct 83 11:03:24-PST From: Mark Crispin Subject: Re: SMTP extension RFC To: Gds@MIT-XX.ARPA cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA In-Reply-To: Message from "Greg Skinner " of Sun 30 Oct 83 08:32:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The intention is that a site which wishes to use the 551 error only do so for third class mail. A site or implementation which never wants to use 551 has no obligation to do so. In other words, I was trying to add a ban on using 551 for first class mail instead of a requirement that it be used for third class mail. Some distinction has to be made between forwardings within the same network registry and forwardings which exit it, of course. I doubt the TOPS-20 mailsystem will ever implement 551 errors unless some site explicitly requests it. -------  Date: Mon 31 Oct 83 01:04:06-PST From: David Roode Subject: Re: "Anti-Social behavior" of mailers To: MRC%SU-SCORE@SRI-NIC, Header-People%MIT-MC@SRI-NIC In-Reply-To: Message from "Mark Crispin " of Sun 23 Oct 83 21:55:16-PDT Location: EJ286 Phone: (415) 859-2774 May I suggest a buffer zone for use by system mail daemons. I.e., a users quota is n, but the mailer permits him to accumulate up to 110% of n in disk pages for its writes to his mail file. This should circumvent the problem with a departed user accumulating 1000's of pages of disk storage, and yet still permit a measure of flexibility to active users, avoiding a high proportion of the mail-rejection situations which are arguably subject to criticism without missing too many of the justifiable ones. -------  Date: 31 Oct 83 02:32:20 PST (Mon) From: Marshall Rose Return-Path: Subject: Summary of Filtering Message-Id: <267.436444340@uci-750a> To: header-people@Mit-Mc Via: UCI; 31 Oct 83 2:43-PST I got a total of 14 responses. Of the 12 systems mentioned, 8 give you full control over which headers you see, 3 give you partial control (e.g. verbose v. quiet mode), and 1 gives you no control at all. If anyone wants to see the data, send me (not the list) a message. Since the sampling size is so small, I conclude that either 1) there are only about 20 people reading Header-People, or 2) this issue isn't that important. Thanks to those who replied. /mtr  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 31 Oct 83 11:09:11 EST Date: 31 Oct 83 1120 EST (Monday) From: don.provan@CMU-CS-A To: Mark Crispin Subject: Re: SMTP extension RFC CC: Header-People@MIT-MC, Postel@USC-ISIF, In-Reply-To: "Mark Crispin's message of 29 Oct 83 14:10-EST" Message-Id: <31Oct83.112013.DP0N@CMU-CS-A> rather than add a command, maybe we should consider adding a field to the mail command. it already has one: "from". maybe we could add a class field. of course this would probably break every server there is, since no such extension is allowed according to the specs, but at least it would make me feel it would be worth the effort to check to see if the user process really said "from:". what was the idea behind that, anyway? i imagine most servers will take "quack:" instead, just like mine. if we aren't going to make use of the label, why not make it optional?  Date: Mon 31 Oct 83 10:33:44-PST From: Mark Crispin Subject: Re: SMTP extension RFC To: don.provan@CMU-CS-A.ARPA cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 31 Oct 83 11:20:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 SMTP server requires "from:" exactly as the spec states. It also requires the exact syntax as used in the spec, e.g. "MAIL FROM:<>" not "MAIL FROM:<>" or "MAIL" or "MAIL FROM: <>". It also validates the syntax of the paths used, although it does all the older form of source routing to coddle various Unix systems. -------  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 31 Oct 83 16:26:54 EST Date: 31 Oct 83 1417 EST (Monday) From: don.provan@CMU-CS-A To: Mark Crispin Subject: Re: SMTP extension RFC CC: Header-People@MIT-MC, Postel@USC-ISIF In-Reply-To: "Mark Crispin's message of 31 Oct 83 13:33-EST" Message-Id: <31Oct83.141749.DP0N@CMU-CS-A> i think mine just drops it into some handy parse-a-mailbox code, so it may even take "Mail foo@bar". it certainly takes "Mail ". if the "from:<>" isn't important, why should i look for it?  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13) id AA21202; Mon, 31 Oct 83 18:06:29 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.10/4.8) id AA04789; Mon, 31 Oct 83 18:06:21 PST Date: Mon, 31 Oct 83 18:06:54 PST From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311010206.AA10368@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.10/4.8) id AA10368; Mon, 31 Oct 83 18:06:54 PST To: Header-People@MIT-MC Subject: Re: SMTP extension RFC Cc: MRC@SU-SCORE, Postel@USC-ISIF In reply to: Date: Sat 29 Oct 83 12:10:30-PDT From: Mark Crispin Subject: SMTP extension RFC To: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA I do not believe that Mark Crispin's "potential extension" to the SMTP standard (RFC 821) will be acceptable for MILNET communications as currently proposed. The first problem is one of nomenclature. The chose of "CLAS" for "class of service" is likely to be confused with "classification" for information security "classification" (UNCLAS, CONFIDENTIAL, SECRET, or TOP SECRET). The second problem, is that there is more than one issue involved in his "class of service" command: delivery and receipt of messages (reliability), speed of service (precedence), and message content. Reliability of communications is the most important requirement of operational military communication systems. At the SMTP level, this means that the transmitting host must know whether the message has been received (or not) by the receiving host. Cancelling of message in route without notification to the originator should be allowed only in very specific situations. One is when the originator cancels the message, the another is if the message is self-cancelling. For example, weather forecasts might carry an instruction indicating that the message is to be cancelled at a specific time (the time when next forcast is issued). (We may want to discuss how to implement self-cancelling messages as a separate issue. I would not expect to even see a SMTP transmission started for a self-cancelling message which had expired.) A relaying host may indicate that it is unable to accept traffic for another host (eg. if it cannot relay to that host), but should accept messages for itself. If it cannot accept traffic for itself then it should tell the sending host to "wait and try again"; if the problem is not a temporary one, the receiving host should set off some local alarms to get a human to solve the problem. After a certain time (which might vary with the precedence of the message), the transmitting relay host should notify the originating host that it is unable to make delivery. On the issue of speed of service indicators, whatever is adopted by the Internet community should be compatible with the National Precedence System used by the US Government. The National Precedence System is documented in the U.S. Code of Federal Regulations, Title 47 - Telecommunications, Chapter 2, Part 213 - Government and Public Correspondence Telecommunications Precedence System. This system of Precedence Designators has four designator which are used to indicate the desired speed of service: FLASH, IMMEDIATE, PRIORITY, and ROUTINE. The military precedence system, which is likely to be adopted for MILNET use has one additional designator (ECP): Precedence Abbr. Speed of Service Objective (drafter to reader) ______________________________________________________ ECP Y As fast as possible FLASH Z As fast as possible, < 10 minutes IMMEDIATE O < 30 minutes PRIORITY P < 3 hours ROUTINE R < 6 hours ECP, FLASH, and IMMEDIATE are usually limited to government use. For purposes of compatibility I suggest that the precedence designators PRIORITY and ROUTINE be adopted for Internet use. For purposes of handling large data files, we may want to add a LOW precedence (L) with a speed of service objective of less than 24 hours. Thus, I recommend that the following Precedence Designators be adopted for Internet use: Internet Abbr. Speed of Service Objective Precedence (drafter to reader) ______________________________________________________ PRIORITY P < 3 hours ROUTINE R < 6 hours LOW L < 24 hours with ROUTINE being the default precedence if a precedence is not specified by the originator. With regard to Mark's proposed command name, I suggest that "PREC" for "precedence" be used at the SMTP level instead of the name "CLAS". I suspect we will want to reserve the command name "CLAS" for "classification" as used on DOD telecommunication systems. Now to the last issue, content designation. I do not think that content should be used as criteria as to whether a message should be relayed or delivered. However, it may be desirable to to have a content designator so that an automaticed mail box can determine what the text of the message is by reading the heading and then spool the text to a particular program. I would put this type of indicator in the message heading instead of the SMTP envelope. As a final comment. Let's try to keep the SMTP procedures simple. Bill Wells Computing Services, U. C. Berkeley  Date: 31 October 1983 23:26 est From: Kovalcik.Multics at MIT-MULTICS Subject: Re: SMTP extension RFC To: Mark Crispin cc: Header-People at MIT-MC, Postel at USC-ISIF In-Reply-To: Message of 29 October 1983 14:13 est from Mark Crispin Sigh. I don't see why class 3 mail should be rejected if it has to be forwarded elsewhere. It is very convenient to forward some mail to an alternate location for reading later when going on vacation and so on. Or, if I know I am going to be working on site X next week, I should be able to forward all my mail there and remove the forwarding when I get back. Forwarding in the sense of electronic mail is very often easier than informing the sender. Don't get caught in the trap of trying to emulate real mail classes.  Date: Tue, 1 Nov 83 0:47:41 EST From: Ron Natalie To: header-people@mit-mc, llp@mit-mc Subject: REQUEST vs. -POSTMASTER This is a trivial change and there is no point to it. The problem (as previously stated) is not what the maintenance address is called but convincing people to use it rather than just mailing to the list address. Since we already have a de facto standard I see no reason to change. Both are at best equally indicative of the function of the address, but personally I feel that "-REQUEST" is more appropriate. If the change is made, all the list maintainers would then have to support both -POSTMASTER and -REQUEST addresses because there would continue to be a high volume of traffic sent to the "-REQUEST" lists. Ron Natalie INFO-MICRO-REQUEST, INFO-CPM-REQUEST, INFO-MUSIC-REQUEST ...@BRL-VGR  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13) id AA25614; Mon, 31 Oct 83 22:51:46 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.10/4.8) id AA08971; Mon, 31 Oct 83 22:51:44 PST Date: Mon, 31 Oct 83 22:52:16 PST From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311010652.AA13900@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.10/4.8) id AA13900; Mon, 31 Oct 83 22:52:16 PST To: Header-People@MIT-MC Subject: Re: SMTP extension RFC Ref: Proposed Federal Information Processing Standard "Specification for message format for computer based message systems", National Bureau of Standards, Institute of Computer Science and Techmology, September, 1981. Here is an interesting extract from Section 3.1.7: ----------------------------------------------------------------------- 3.1.7 Message-handling fields Message-handling fields describe aspects of how a message is to be handled or categorized. Precedence (optional) This field indicates the precedence at which the message was posted. Ordinarily, message precedence or priority is a service request to a message transfer system. A message originator, however, can include precedence information in a message. One example of precedence categories are those used by the U.S. Military: "ROUTINE", "PRIORITY", "IMMEDIATE", "FLASH OVERRIDE" (actually "FLASH" - wcw), and "EMERGENCY COMMAND PRECEDENCE (previously "FLASH OVERRIDE" or "EMERGENCY" - wcw). Message-Class (optional) This field indicates the purpose of a message. For example, it might contain values indicating that the message is a memorandum or a data-base entry. (Footnote 1) ...... Footnote 1: The message format specification is not intended to be used as a specification for exchanging data-base records. Messages, however, sometimes contain data from or for a database. ----------------------------------------------------------------------- The two (...-wcw) notes are my own. Bill Wells UC Berkeley wcwells@Berkeley.ARPA  Received: by ucbvax.ARPA (4.16/4.13) id AA12932; Tue, 1 Nov 83 19:16:32 pst Date: 1 Nov 83 13:18:27 EST (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: self cancelling messages Message-Id: <8311011818.AA01899@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA01899; 1 Nov 83 13:18:27 EST (Tue) To: header-people@mit-mc.ARPA As long as self cancelling messages have been brought up, I'd like to mention that the Usenet standard (RFC850) has such a field, for example: Expires: Sun, 1-Jan-84 04:06:53 EST The semantics are the same, but the implementation is different. Messages are stored on line on each machine until they expire. A daemon checks every night for expired messages. An attempt to use this field to expire hourly weather forecasts failed because of the once-per-day granularity. Normally expiration dates are used to prolong the (normally two week) lifetime of a message, but can be used to shorten them as well, within the resolution of the expiration daemon. However, for mail purposes, since the semantics are identical to what would be needed for self cancelling mail, I'd like to encourage anyone who implements it to use the same Expires: header. This will probably simplify life in the longrun when mail and news headers are combined, and will also prevent 850 from suddenly being in violation of 822. By the way, please note that your 6 hour requirements for routine mail are somewhat optimistic for dialup networks. In a dialup world where some sites must wait for others to poll them (overnight), it's quite common to have 24 - 48 hour delivery times, and when something gets messed up (e.g. a forwarder is down or has a wedged dialup or dialer) even longer times - a week or two is not all that uncommon over some flakey links, and I've seen 3 month delays. Also, as long as we're talking about extending SMTP, I'd like to mention another feature that might be nice. SMTP seems well suited to exchanging mail over dialup phone links - you dial up a machine, log in as SMTP, say HELO to identify yourself, and transfer mail. This works great as long as you have a reliable channel (e.g. TCP or X.25). But dialups are noisy. Suppose a DLNK command were added to go into a "standard" (we pick one) data link layer? That is, a dialog might go like this: HELO FooVax response DLNK SDLC affirmative response The DLNK might go before HELO. The response comes back without the data link layer, in case it might fail. (The remote host might not know the named protocol, for example.) This would permit hosts to still send mail if they don't implement DLNK, although it could get noisy.) I'm not particularly suggesting SDLC, I don't have any preference. One final note: I do hope there will be a Class: or Priority: header field, since the SMTP envelope information will be lost on any message passing through some other mail system, such as UUCP. (UUCP should be able to handle the .ARPA domain, given a smart enough mailer - I have never seen a UUCP host try to get to host "ARPA".) Mark Horton  Received: from SCRC-YAMASKA by SCRC-QUABBIN with CHAOS; Wed 2-Nov-83 08:46:09-EST Date: Wed, 2 Nov 83 08:46 EST From: Charles Hornig Reply-to: CAH@MIT-MC.ARPA Subject: ["Robert W. Kerns" : Files restored to disk] To: "Robert W. Kerns" , Mark Crispin , header-people@MIT-MC.ARPA Cc: bug-Zmail@SCRC.SCRC.Symbolics, Hornig@YUKON.SCRC.Symbolics, Hornig@MIT-MULTICS.ARPA, bug-mailer@YUKON.SCRC.Symbolics In-reply-to: <831101192604.9.RWK@YUKON.SCRC.Symbolics> Message-ID: <831102084603.1.Hornig@QUABBIN.SCRC.Symbolics> Date: Tue, 1 Nov 83 19:26 EST From: "Robert W. Kerns" Date: Tue 1 Nov 83 12:55:08-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) So is your header (a non-ARPA domain is not yet valid on Internet). --------------- Return-Path: Received: from MIT-XX by SU-SCORE.ARPA with TCP; Tue 1 Nov 83 12:50:16-PST Date: Tue, 1 Nov 83 15:49 EST From: "Robert W. Kerns" Subject: Files restored to disk To: Operator@MIT-XX.ARPA Cc: bug-mail@MIT-XX.ARPA In-reply-to: The message of 1 Nov 83 04:07-EST from Operator Message-ID: <831101154911.6.RWK@YUKON.SCRC.Symbolics> Date: 1 Nov 1983 0407-EST From: Operator The following files have been restored on MIT-XX: PS:LOGIN.CMD.11 31-Oct-83 08:24:56 ------- Your headers are illegal (no host). ------- Excuse me. Why is it every time I turn around Zmail sends a different header? This was just "fixed", obviously wrongly. I think part of the problem here is that XMAILER is no longer involved in sending mail for me, and nobody has taken up the task of supplying the routing information. This is obviously unacceptable. We can fix Zmail up with the knowledge that's needed, if nobody has any better ideas, but I don't know if that's really where it should happen. This is about the fifth time someone has complained. Obviously, this one is more embarrassing than most... This has already been fixed in Zmail (84.44). The behaviour about which MRC is complaining is due to the insistance by the Internet community that we not put our host names in mail headers at all (since they are not on the Internet). Zmail has been taught to convert "RWK@Yukon.SCRC.Symbolics" to "RWK%SCRC-Yukon@MIT-MC". I bet you wouldn't want all your internal mail gatting routed through MC, though. If you look carefully, you will see that, as far as Zmail could tell, the message was not going to the Internet. It was going only to Chaosnet hosts (Yukon and XX). It counts as internal mail. If you are going to call the protocol police, complain to the people who run a mail forwarding gateway at XX without munging headers. Another example is this very message. MRC will get a "legal" Internet message with "%"'s in its addresses. Everyone else on header-people will get an illegal one because they get the MIT-internal copy since header-people is on MIT-MC. This exchange is why I waited so long to put in the "%" hack. As you have seen, it doesn't work much of the time. You can't tell where the message might end up. As long as the Internet won't admit the existance of our hosts, there's not much we can do. Do we really have to put up with this for another year?  Date: 2 November 1983 11:03 EST From: Gail Zacharias Subject: ["Robert W. Kerns" : Files restored to disk] To: CAH @ MIT-MC cc: HEADER-PEOPLE @ MIT-MC, Hornig @ MIT-MULTICS, MRC @ SU-SCORE, "bug-mailer@YUKON bug-Zmail" @ SCRC-TENEX, Hornig @ SCRC-YUKON, RWK @ SCRC-YUKON In-reply-to: Msg of Wed 2 Nov 83 08:46 EST from Charles Hornig Date: Wed, 2 Nov 83 08:46 EST From: Charles Hornig To: "Robert W. Kerns" , Mark Crispin , header-people@MIT-MC.ARPA cc: bug-Zmail@SCRC.SCRC.Symbolics, Hornig@YUKON.SCRC.Symbolics, Hornig@MIT-MULTICS.ARPA, bug-mailer@YUKON.SCRC.Symbolics ... It was going only to Chaosnet hosts (Yukon and XX). It counts as internal mail. If you are going to call the protocol police, complain to the people who run a mail forwarding gateway at XX without munging headers. Another example is this very message. MRC will get a "legal" Internet message with "%"'s in its addresses. Everyone else on header-people will get an illegal one because they get the MIT-internal copy since header-people is on MIT-MC. Since COMSAT doesn't understand .SCRC.Symbolics (and I bet neither does XX) this whole argument is spurious. You should at least convert these things to legal chaosnet addresses when going outside Symbolics, if you want to communicate with anybody but other Symbolics hosts.  Date: Wed 2 Nov 83 08:56:42-PST From: Mark Crispin Subject: Re: ["Robert W. Kerns" : Files restored to disk] To: CAH@MIT-MC.ARPA cc: RWK%SCRC-YUKON@MIT-MC.ARPA, header-people@MIT-MC.ARPA, bug-Zmail%SCRC-TENEX@MIT-MC.ARPA, Hornig%SCRC-YUKON@MIT-MC.ARPA, Hornig@MIT-MULTICS.ARPA, bug-mailer%SCRC-YUKON@MIT-MC.ARPA In-Reply-To: Message from "Charles Hornig " of Wed 2 Nov 83 05:57:06-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is a very simple way around the problem of "internal" vs small-i internet headers. That is, never consider any mail bridge host to be "internal"; always consider it to be small-i internet and require that it be an absolute (e.g. .ARPA form) address. Have you read RFC's XXX, YYY, and ZZZ? If not, please read before you flame. Something is being done but it takes time. I imagine you at SCRC wouldn't care to receive a message from Helens without having the slightest idea what a Helens is (it's a host on Stanford's local net only, no Internet support). The problem is much more complex than a HOSTS3 or whatever can solve. Of course, my "simple" solution doesn't help if a message gets delivered to a user who forwards his mail across a small-i internet boundary. But a user who does that should take responsibility for the possible consequences of his actions, at least until full domains take over. -------  Date: Wed, 2 Nov 83 13:33 EST From: "Robert W. Kerns" Subject: Re: ["Robert W. Kerns" : Files restored to disk] To: Mark Crispin Cc: CAH@MIT-MC.ARPA, RWK%SCRC-YUKON@MIT-MC.ARPA, header-people@MIT-MC.ARPA, bug-Zmail%SCRC-TENEX@MIT-MC.ARPA, Hornig%SCRC-YUKON@MIT-MC.ARPA, Hornig@MIT-MULTICS.ARPA, bug-mailer%SCRC-YUKON@MIT-MC.ARPA In-reply-to: The message of 2 Nov 83 11:56-EST from Mark Crispin Message-ID: <831102133341.1.RWK@YUKON.SCRC.Symbolics> Date: Wed 2 Nov 83 08:56:42-PST From: Mark Crispin Of course, my "simple" solution doesn't help if a message gets delivered to a user who forwards his mail across a small-i internet boundary. But a user who does that should take responsibility for the possible consequences of his actions, at least until full domains take over. It also doesn't help mailing lists. If I at YUKON send mail to a list on SCRC which includes a list on MC, the wrong headers result. If we avoid placing forwarding entries to mailing lists on non-gateway hosts, does this avoid the problem?  Received: from SCRC-YAMASKA by SCRC-QUABBIN with CHAOS; Wed 2-Nov-83 14:51:12-EST Date: Wed, 2 Nov 83 14:51 EST From: Charles Hornig Subject: Re: ["Robert W. Kerns" : Files restored to disk] To: Mark Crispin Cc: RWK%SCRC-YUKON@MIT-MC.ARPA, header-people@MIT-MC.ARPA, bug-Zmail%SCRC-TENEX@MIT-MC.ARPA In-reply-to: The message of 2 Nov 83 11:56-EST from Mark Crispin Message-ID: <831102145113.5.Hornig@QUABBIN.SCRC.Symbolics> Date: Wed 2 Nov 83 08:56:42-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Have you read RFC's XXX, YYY, and ZZZ? If not, please read before you flame. Something is being done but it takes time. I imagine you at SCRC wouldn't care to receive a message from Helens without having the slightest idea what a Helens is (it's a host on Stanford's local net only, no Internet support). The problem is much more complex than a HOSTS3 or whatever can solve. Yes, I have read them. That is where the "year" came from. As I understand it, non-ARPA domains will not be permitted until late Summer 1984. I would rather receive a message from Helens with a Return-path which made it clear that it was from Stanford somewhere than have all my local mail be routed through MIT-MC because I needed to supply a source route with %'s.  Date: 2 November 1983 15:39 EST From: Gail Zacharias Subject: ["Robert W. Kerns" : Files restored to disk] To: RWK @ SCRC-YUKON cc: CAH @ MIT-MC, HEADER-PEOPLE @ MIT-MC, Hornig @ MIT-MULTICS, MRC @ SU-SCORE, bug-Zmail @ SCRC-TENEX, bug-mailer @ SCRC-YUKON, Hornig @ SCRC-YUKON In-reply-to: Msg of Wed 2 Nov 83 13:33 EST from "Robert W. Kerns" There is only one way to insure that bad headers never get out and that is to always make the transformation (in effect adopting the current messy state of affairs as the local standard as well) and then make local mail tools recognize the "%locally-known-host@arpanet-gateway" construction and avoid the unnecessary routing... This could be made highly reliable if the hostname space of the arpanet gateway is well understood locally (which can be done for MC by reading the appropriate host table file).  Date: Wednesday, 2 November 1983 16:09 est From: "Barry Margolin"@MIT-MULTICS.ARPA Subject: Re: ["Robert W. Kerns" : Files To: rwk%scrc-yukon@MIT-MC.ARPA cc: mrc@SU-SCORE.ARPA, cah@MIT-MC.ARPA, header-people@MIT-MC.ARPA, bug-zmail%scrc@MIT-MC.ARPA, bug-mailer%scrc-yukon@MIT-MC.ARPA In-Reply-To: Message of 2 November 1983 15:55 est from "Barry Margolin" Message-ID: <831102210915.478487@MIT-MULTICS.ARPA> Until domains are fully implemented all over the place, header munging will have to take place. Nobody likes it, but that is life. There is only one "right" time and place for header munging to take place, and that is as the mail is crossing from a local network into the internet (big or little "i"). So, when a piece of mail is being transmitted from a Symbolics machine or a Stanford machine to a host which is not part of that local organization the header must be munged to conform to the Internet standard, which currently admits only one domain. barmar  Date: 2 Nov 1983 13:19:07-PST (Wednesday) From: David M. Alpern Return-Path: Subject: What does it mean to be an internet host? To: header-people@mit-mc Message-Id: Via: IBM-SJ; 2 Nov 83 15:27-PST I've noticed that MIT-VAX, MIT-OZ, and other machines which do not seem to accept mail directly from most Arpanet hosts are in the CSNET host table, and from what I've been told, in the Internet host table. (There may be other examples, I just happen to deal with these machines.) Is this simply a way of making legal constructs such as xxx@mit-oz@mit-mc, which "would not be legal" if mit-oz were not in the Internet host table, at the cost of confusion regarding which machines can actually be contacted?  Date: Wednesday, 2 November 1983, 19:19-EST From: Christopher C. Stacy Subject: What does it mean to be an internet host? To: David M. Alpern Cc: header-people at MIT-MC In-reply-to: Date: 2 Nov 1983 13:19:07-PST (Wednesday) From: David M. Alpern Via: IBM-SJ; 2 Nov 83 15:27-PST I've noticed that MIT-VAX, MIT-OZ, and other machines which do not seem to accept mail directly from most Arpanet hosts are in the CSNET host table, and from what I've been told, in the Internet host table. (There may be other examples, I just happen to deal with these machines.) MIT-VAX recently left the Internet, and is being removed from those host tables. MIT-OZ was supposed to be in the Internet host table, but since they have been unable for the past year to get their TCP/IP working they were commented out recently. I do not believe either MIT-VAX or MIT-OZ is in the latest CSNET host tables. MIT-MC is listed as an ARPANET site in the latest Internet and CSNET tables, however, and you can relay mail to OZ or VX through MC. Is this simply a way of making legal constructs such as xxx@mit-oz@mit-mc, which "would not be legal" if mit-oz were not in the Internet host table, at the cost of confusion regarding which machines can actually be contacted? No, this is just braindamage. Cheers, Chris  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 3-Nov-83 21:05:44-EST Date: Thu, 3 Nov 83 21:05 EST From: "David A. Moon" Subject: Question about suspected typographical error in RFC 822 To: DCrocker@UDEL-RELAY.ARPA Cc: Header-People@MC.ARPA Can you clarify this RFC-822 issue? I think that in the syntax on page 27, the definition of mailbox should be mailbox = addr-spec ; simple address / local-part route-addr ; name & addr-spec rather than what is actually in the document, namely mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec For reference, local-part is defined as local-part = word *("." word) ; uninterpreted ; case-preserved For an example of the effect of requiring a phrase there, rather than a local-part, see the header of this message. My personal name is enclosed in double quotes because period is not a legal character in a phrase. Is this ruling-out of period intentional or merely a typographical error in the syntax specification? I can find no other interpretation specified for period in the field of a mailbox that precedes the route-addr. It sure would be nice not to have to put those quotes around the name of anyone who has a middle initial. Thanks for any light you can shed on this matter.  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13) id AA27414; Fri, 4 Nov 83 10:34:38 pst Received: from ucbjade.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.10/4.8) id AA00461; Fri, 4 Nov 83 10:02:16 PST Message-Id: <8311041751.AA13925@ucbjade.CC.Berkeley.ARPA> Received: from UCBCMSA.BITnet by ucbjade.CC.Berkeley.ARPA (4.10/4.8) id AA13925; Fri, 4 Nov 83 09:51:50 PST Date: Fri, 04 Nov 83 09:46:44 PST From: SPGGGM%UCBCMSA.CC@Berkeley To: Moon%scrc-tenex@mit-mc.ARPA Cc: DCrocker@Udel-relay.ARPA, header-people@mit-mc.ARPA Subject: Phrase vs. local-part In fact, were it legal to use *David T. Moon*, then by the regeneration rules ('Note:' on page 8 of RFC822, section 3.1.4), your name would come out as *David T.Moon*. Is THAT what you want? Greg Minshall  Received: from merlin.ARPA by purdue.ARPA; Sat, 5 Nov 83 15:25:02 EST From: Christopher A Kent Message-Id: <8311052024.AA04011@merlin.ARPA> Received: by merlin.ARPA; Sat, 5 Nov 83 15:24:30 EST Date: 5 Nov 1983 1524-EST (Saturday) To: "David A. Moon" Cc: Header-People@MC.ARPA, DCrocker@UDEL-RELAY.ARPA Subject: Re: Question about suspected typographical error in RFC 822 In-Reply-To: Your message of Thu, 3 Nov 83 21:05 EST. <8311040308.AA01013> Unfortunately, this is not a typo. I've been through this once before. The real gripe that I have is that the line gets parsed and flagged as an error, even if you have <> on the line somewhere, which indicates that the phrase in <> is the address to be used, and the rest of the line is a comment. The normal solutions to this are: "Christopher A. Kent" Christopher A Kent cak@purdue (Christopher A. Kent) Come to think of it, I'm not sure if the last form is really legal. Cheers, chris ----------  Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 5-Nov-83 22:30:15-EST Date: Sat, 5 Nov 83 22:31 EST From: "David A. Moon" Subject: Question about suspected typographical error in RFC 822 To: DCrocker@UDEL-RELAY.ARPA Cc: Header-People@MIT-MC.ARPA References: The message of 3 Nov 83 21:05-EST from "David A. Moon" , The message of 4 Nov 83 11:35-EST from Karlton.PA at PARC-MAXC, <8311041751.AA13925@ucbjade.CC.Berkeley.ARPA>, <8311052024.AA04011@merlin.ARPA>, The message of 5 Nov 83 18:21-EST from John R Ellis Well, enough people have pointed out to me that local-part is not what I want. There were a couple of other replies that I didn't save, so they are not in the reference list of this message. Let me rephrase my question. The basic problem is that phrase is being parsed into atoms, and periods are not allowed in atoms because atoms are also used in domain names. This is simply an incorrect modularity in the syntax definition, if it is thought of as a program. If you look at the syntax definition in Appendix D of RFC 822, every use of phrase is something that should -not- be being parsed into individual words. A phrase is simply a piece of text not containing special characters. Therefore alter my suggestion to be: replace the definition in the document phrase = 1*word ; Sequence of words with the suggested replacement phrase = 1*(ptext / quoted-string) ptext = There may or may not be intended a restriction that a phrase may not consist solely of linear-white-space and that leading and trailing linear-white-space around a phrase is insignificant. I also suggest that the present definition of local-part be replaced with local-part = phrase because the contents of the local-part field should not be parsed in any way by any host other than the one named by the domain name to the right of the atsign. I would still like an official answer to my question of whether the standard was officially intended to expressly forbid people's names to include middle initials, or whether this was an unintended accidental result of the syntax definition that should be fixed.  Date: Sun, 6 Nov 83 12:05 PST From: Taft.PA@PARC-MAXC.ARPA Subject: Re: Question about suspected typographical error in RFC 822 In-reply-to: "Moon's message of Sat, 5 Nov 83 22:31 EST" To: Header-People@MIT-MC.ARPA From a technical standpoint, I am as mystified as you are about the restricted local-part syntax. I see no technical reason why a local-part can't be the same as a phrase. However, I can assure you that the restriction is not the result of a typographical error. There was an administrative decision made long ago that local-parts should not contain spaces. I don't know the exact details; but there were (and probably still are) various mail systems around the Arpanet that could not cope with recipient names containing spaces. When such names started appearing from CMU and other places, mail systems broke down, and this interfered seriously with the conduct of some important ARPA contract. As an expedient, spaces were outlawed from recipient names, and pressure was brought on CMU to change their mail system. The expedient has apparently been perpetuated for all time. There is a serious problem with your proposed redefinition of phrase, which is that it requires context-dependent lexical analysis. This is perhaps not bothersome for an ad-hoc scanner; but it causes difficulties for a real parser, which expects to be given a sequence of tokens that can be reduced according to the rules in the grammar. That is, if the lexical analyzer encounters a "." adjacent to an atom, should it include the "." in the atom or should it pass it on to the parser as a separate token? This can be determined only if the lexical analyzer knows what rules the parser is considering; and conventional parsers are generally not set up to provide that information. A better way to fix the definition of phrase is to permit it to include anything that looks like a local-part. That is, change phrase = 1*word ; Sequence of words to: phrase = 1*local-part ; Sequence of words and periods However, as a practical matter I don't see any pressing need to change the grammar. You can include anything you want in a phrase if you quote it. It is worth mentioning that there are quite a number of typographical errors in the body of RFC 822, especially in the examples. Also, the complete grammar in Appendix D is horribly ambiguous if used as it stands. However, if the grammar is divided into lexical analysis rules (the ones given in section 3.3) and parsing rules (all the others), everything works correctly. Ed Taft  Received: by YALE-BULLDOG via CHAOS; Sun, 6 Nov 83 20:28:19 EST Date: Sun, 6 Nov 83 20:28:50 EST From: John R Ellis Subject: Re: Question about suspected typographical error in RFC 822 To: Taft.PA@PARC-MAXC.ARPA Cc: Header-People@MIT-MC.ARPA In-Reply-To: Taft.PA@PARC-MAXC.ARPA, Sun, 6 Nov 83 12:05 PST A better way to fix the definition of phrase is to permit it to include anything that looks like a local-part. That is, change: phrase = 1*word ; Sequence of words to: phrase = 1*local-part ; Sequence of words and ; periods ------ This change would not allow periods at the end of a phrase, as in: Joe Hacker Ph.D. B.J. The latter example actually occurred here. A more general solution is: phrase = 0*("." / word) ; Sequence of words OR periods The problem with this modification is that the grammar is no longer even close to being LL(1) (i.e. one that can be parsed top-down easily); PHRASE and LOCAL-PART can derive arbitrarily long equal strings. I do think it is LALR(1) (i.e. parseable by bottom-up parser-generators such as YACC). To make the new language parseable by a non-backtracking recursive descent parser, one would have to do some extensive contortions to the grammar. (The current grammar is easily parsed with a recursive-descent parser.) But there is another annoying implementation issue with any scheme that allows the "." token in phrases: How do you pretty-print the phrase? For domains, there is a simple rule -- use no spaces. But there is no such easy rule for phrases. Consider these examples: I.B.M. System Administrator John R. Ellis B.J. People would get pretty peeved if mail services rearranged the spacing around their periods, just as some now get peeved that they have to quote periods. The only possible solution is to preserve the original spacing. One way to do that is to tag each lexical token with its character position in the input stream; when a phrase is parsed, the original input string can then be extracted and preserved. As for domains, this formatting rule would have to be described in the RFC. Ugh. I too would like periods in phrases. But I agree with Ed Taft: There is no pressing need at this late stage to go to all that effort for such little gain. -------  Received: from merlin.ARPA by purdue.ARPA; Mon, 7 Nov 83 09:02:44 EST From: Tim Korb Message-Id: <8311071402.AA23443@merlin.ARPA> Received: by merlin.ARPA; Mon, 7 Nov 83 09:02:14 EST Date: 7 Nov 1983 0902-EST (Monday) To: "David A. Moon" Cc: Header-People@MIT-MC.ARPA, DCrocker@UDEL-RELAY.ARPA Subject: Re: Question about suspected typographical error in RFC 822 In-Reply-To: Your message of Sat, 5 Nov 83 22:31 EST. I asked Dave Crocker about this problem some time ago. Dave told me that the grammar is restricted in this way to make it context-free, and hence, easy to parse. I would argue that the parsing problem is so trivial we should worry about user convenience and good taste rather than whether or not we'll be able to use yacc. In any event, that's the way the standard reads. Tim ----------  Date: 25-Oct-83 17:06:46-UT From: gross@dcn7 Subject: re: anti-social behavior of mailers To: wmartin@office-3 cc: header-people@mit-mc --- The principle to be followed is that "mail is sacred". ... ... It is the responsibility of the recipient to do whatever housekeeping is necessary to avoid whatever problems his system causes by his being overallocated. --- Seems to me that this is a contradiction?! I fully agree that mail should be sacred, but what if the 'problems his system causes' are to dump the mail into the bit bucket? I suspect that arguments claiming that 'It is the responsibility of the recipient ... ' will be non productive. I mean, after all, isn't this why we have machines and RFC's for anyway? Personally, I want to know if my message wasn't delivered to its intended recipient. Saves me drumming my fingers and waiting for an answer. Phill Gross -------  Date: Mon, 7 Nov 83 12:10:28 PST From: Rich Wales To: Header-People@MIT-MC Subject: Periods in full names in RFC822 Two comments -- one philosophical, one pragmatic. (1) I understand the problems involved in parsing entities like Richard B. Wales but I must still cast my vote in favor of making mailbox designa- tions such as the above legal as they stand -- even if somewhat more involved parsing techniques are required as a result. My impression was that RFC822 headers were designed to "look nice" as well as to be easily interpretable by programs. And no matter what anyone may say about ease of parsing, the mailbox designation "Richard B. Wales" does NOT look nearly as "nice" as the unquoted version. (2) One relatively simple way to get around the "prettyprinting" diffi- culty would be for your lexical analyzer to flag those tokens in an address which are followed by a space. If you carry these "space flags" around until you are ready to output the address again, you can use them to preserve the spacing (or lack of spacing) around the periods in a full name. I did just this kind of thing in an ad-hoc address parser I recent- ly wrote, but I'm sure it could be done with "lex" and "yacc" too (provided you pass a data structure around as the lexical value of each token, rather than just a character string). -- Rich  Date: 9 Nov 1983 13:22:32-PST (Wednesday) From: David M. Alpern Return-Path: Subject: Restrictive "i"-internet transfers To: header-people@mit-mc Message-Id: Via: IBM-SJ; 10 Nov 83 12:35-PST I've been noticing that "restrictive" gateway functions have been developing in some organizations for security or resource management purposes. What I mean is that there are some network environments in which one user can address anyone, either within the local network or in some "i"-internet community, but where some local network users cannot access/be accessed by users outside the local network. Let's say that such users not only cannot send mail outside, but cannot have mail sent to them from outside either. What if someone in this environment, who had the privilege, sent a message to a group which included restricted-access members of the local network as well as outside users. The header could be munged by the gateway to remove the addresses of the restricted-access local users, but this has all the problems header munging usually has, and in addition hides the involvement of the local recipients from the outside recipients. Is there/should there be some means of specifying an address that implies that it is a "private channel," which might not be available to all recipients? What would be the best way to handle such a circumstance? - Dave  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 11 Nov 83 00:27:29 EST Date: 11 Nov 83 0034 EST From: Rudy.Nedved@CMU-CS-A To: David M. Alpern Subject: Re: Restrictive "i"-internet transfers CC: header-people@mit-mc In-Reply-To: Message-Id: <11Nov83.003407.EN0C@CMU-CS-A> David, Thanks for pointing out that problem. It never occured to me that a local user could send to a non-local user and a local "restricted" user causing a reply to "all" by the non-local user to be rejected by the mail gateway. I don't see any solution that I would consider both correct and maintainable. I will chew on this...and will be happy to hear other solutions and request that if you get any solutions that are not sent to Header-People that you send me a copy. CMU-CS/RI is one such "domain" that has a restricted mail gateway. -Rudy  Date: 11 Nov 83 11:34 EST From: Stephen Tihor To: Rudy.Nedved@CMU-CS-A.ARPA Subject: RE: Restrictive "i"-internet transfers Cc: header-people@MIT-MC.ARPA Message-ID: <3153F9055.006F0024.1983@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <11Nov83.003407.EN0C@CMU-CS-A> ; Message of 11-NOV-1983 02:11 from Rudy.Nedved@CMU-CS-A Although we have a half restricted domain we allow incomming mail to anyone which eliminates the problem as stated. I haven't been able to formulate a version of the problem which fails other than in that a user not validated for the ARPAnet can not reply to mail from an ARPAnet site. Philosphically mail should be free and the "Can not send to ARPAnet" is mearly there because of the DCA restrictions. -------  Date: Fri 11 Nov 83 23:39:58-EST From: Greg Skinner Subject: Proposal for Arpa/Uucp mail routing To: header-people@MIT-MC.ARPA I would like to bounce this idea off of all of you as a possibility for extensions to mailers now running SMTP, a service to provide easier electronic mail access to the UUCP network. No flames, please. As many of you are aware, the Bell systems network (a.k.a UUCP and also called Usenet) is one of (if not the) hardest networks to reach directly via electronic mail. Due to their mail transport mechanism, ful pathnames to UUCP sites must be provided to effect successful transport. Knowledge of these pathnames is not commonly known to the Arpa/Internet community, not because of security reasons but because the network is in a constant state of change. Most messages are required to run through a centralized gateway (e.g ucbvax, sri-unix or cca) which results in high traffic through those gateways. In particular, ucbvax has excessively high traffic, since it is responsible for forwarding to Berknet and Bitnet sites also. Finally, knowledge of a pathname does not necessarily guarantee a successful mail transfer, as sites may be down along the path, or sites may elect to receive news only. This results in complicated returns (which sometimes fail). In addition, pathnames tend to be "long", involving hops across most of the country (sometimes multiple hops) to sites which are geographically close to the Arpa/Internet sender. My proposal is to have "local pathnames" of optimized paths to UUCP sites kept by Arpa/Internet hosts which act as gateways to the UUCP net. A registry could be kept of known UUCP gateways and sites which are geographically close to them, available to Arpa/Internet users, possibly FTPable from the NIC. The effect this would have is to reduce the load of traffic which major Arpa/Uucp gateway hosts support, and redistribute that traffic over all Arpa/Uucp gateways. The Arpa/Internet user would only have to address his message to user%uucp-destination-host@arpa/uucp-gateway and allow the gateway to relay the message to the destination host via the shortest path. The gateway may also choose to try alternate paths, and would guarantee (as much as is possible) a failed message reply should the destination host be unreachable. A further extension, pending the full integration of domains into Arpa/Internet mail transfer, would be for mail addressed to user@uucp-destination.UUCP to be appropriately routed (by the Arpa/Internet) to the most geographically close Arpa/Uucp gateway (or a suitably close one if the nearest one is not relaying), from which the gateway could take over and provide the optimal route to the UUCP destination host. This idea was motivated by a discussion of "superelastic plastic Usenet addresses" within the USENET net.mail discussion, a means of providing optimized intra-uucp mail transfer. I will share my thoughts on this with them, also. Greg Skinner (Gds@MIT-XX.ARPA, decvax!genrad!mit-eddie!gds, gds$mit-eddie@MIT-MC.ARPA) -------  Date: Saturday, 12 November 1983, 01:26-EST From: Christopher C. Stacy Subject: Periods in full names in RFC822 To: Header-People at MIT-DMS I think Rich Wales is right: if headers are supposed to be read by humans (as opposed to just presentation programs), the prettier unquoted syntax for mailbox specs ought to be legal. Many users at our site have asked me to send in this comment, to ensure that the protocol designers understand that the users are unhappy with the look of the quoted mailbox specs headers. (None of the mail readers at our sites have any difficulty with the less restricted syntax.)  Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 01:46:54 EST Date: Sat, 12 Nov 83 01:51:53 EST From: John R Ellis Subject: Re: Periods in full names in RFC822 To: Christopher C Stacy Cc: Header-People@MIT-MC.ARPA None of the mail readers at our sites have any difficulty with the less restricted syntax. For the benefit of the rest of us, perhaps you could give a formal definition of the syntax your programs accept and describe how your programs actually do the parsing? None of your mail programs have any difficulty in adhering to the new standard either, I see: Date: Saturday, 12 November 1983, 01:26-EST From: Christopher C. Stacy To: Header-People at MIT-DMS -------  Date: Sat, 12 Nov 83 02:15:24 EST From: "Christopher C. Stacy" To: Header-People at MIT-MC.ARPA Subject: Periods in full names in RFC822 Well, sigh, here we are in flame-city... Date: Sat, 12 Nov 83 01:51:53 EST From: John R Ellis To: Christopher C Stacy cc: Header-People at MIT-MC.ARPA Re: Periods in full names in RFC822 None of the mail readers at our sites have any difficulty with the less restricted syntax. For the benefit of the rest of us, perhaps you could give a formal definition of the syntax your programs accept and describe how your programs actually do the parsing? I don't know a whit about parsing, but I thought that someone already figured out how to do this (by having the lexical analyzer flag the tokens which are followed by a space.) None of your mail programs have any difficulty in adhering to the new standard either, I see: Date: Saturday, 12 November 1983, 01:26-EST From: Christopher C. Stacy To: Header-People at MIT-DMS That is right, they do not (as you can see from the header on the message you are reading.) To make it adhere to the current standard requires a two-instruction patch in the mailer; I went looking to see how hard it would be to fix the other day. This bug has not been installed, however. I recognize your name as one of the people who occasionaly sends notes to some of our users complaining that we are anti-social because you cannot parse our headers. But your software apparently really could parse the headers, since replies do in fact come back to us. There are at least six completely different mail reading systems in use at our site, and none of them has any difficulty parsing the less restricted syntax. (I did not implement these programs, but some of the other people on this list did.) Just exactly which mail systems are really unable to parse these headers anyway? Anyway, my point was that if headers are for USER convenience then they should look pretty. If we are interested in implementor convenience, why are we bothering to make them readable by humans at all? Come on, this can't be THAT big a deal, and it looks SO much nicer. Chris  From: vortex!lauren at RAND-UNIX Date: Friday, 11-Nov-83 21:19:13-PST Sender: Lauren Weinstein Subject: SMTP UUCP extensions To: HEADER-PEOPLE@MC The problem is not really a technical one, but is instead a political problem. The existing UUCP gateways and paths are not advertised not only due to pathname complexities but because there are no authorized gateways! Any gatewaying which actually takes place is on an unofficial basis and could theoretically be terminated totally at any time. Attempting to include "official" support for officially "non-existent" gateways could raise eyebrows among the "powers-that-be" and could result in a crackdown on those paths that *do* exist. Given the current security issues surrounding DDN, this may well be the wrong time to propose such extensions, as sensible as such extensions might be from a technical standpoint. Just an opinion. --Lauren--  From: vortex!lauren at RAND-UNIX Date: Friday, 11-Nov-83 21:19:13-PST Sender: Lauren Weinstein Subject: SMTP UUCP extensions To: HEADER-PEOPLE@MC The problem is not really a technical one, but is instead a political problem. The existing UUCP gateways and paths are not advertised not only due to pathname complexities but because there are no authorized gateways! Any gatewaying which actually takes place is on an unofficial basis and could theoretically be terminated totally at any time. Attempting to include "official" support for officially "non-existent" gateways could raise eyebrows among the "powers-that-be" and could result in a crackdown on those paths that *do* exist. Given the current security issues surrounding DDN, this may well be the wrong time to propose such extensions, as sensible as such extensions might be from a technical standpoint. Just an opinion. --Lauren--  Date: 12 Nov 83 14:36 EST From: Stephen Tihor To: Header-People@MIT-MC.ARPA Subject: RE: Periods in full names in RFC822 Message-ID: <316503B24.00400021.1983@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <8311120755.AA14832@NYU.ARPA> ; Message of 12-NOV-1983 02:57 from "Christopher C. Stacy" Subject: Re: Periods in full names in RFC822 To: Christopher C Stacy Cc: Header-People@MIT-MC.ARPA Anyway, my point was that if headers are for USER convenience then they should look pretty. If we are interested in implementor convenience, why are we bothering to make them readable by humans at all? Come on, this can't be THAT big a deal, and it looks SO much nicer. I like periods in fullnames. But when you propose a change to an existing standard for which there are already many implementations, one has to consider for the users' sake the likelihood that the changes will be incorporated. The point of a standard is that it allows everyone to communicate with minimum hassle. If some programs don't obey the standard, then users are inconvenienced. You could have the most flexible syntax possible (even free-form addresses like US mail) but if many programs didn't accept it, it would be pretty useless to users, no? Thus it is important for user convenience to consider current parsing technology when defining the standard. Most programmers are familiar only with the parsing techniques described in texts such as the Dragon book; there are widely available tools such as YACC based on those techniques that make parser construction trivial. If you define a language that is hard to parse using available tools, many implementors will take short cuts and parse a subset or write ad hoc parsers that aren't completely correct (e.g. how many programs correctly parsed the exact same subset of the old standard?). If no programs parse exactly the same subset, then users are inconvenienced. Most of the old mail programs at MIT and elsewhere use ad hoc parsers. I had the misfortune once to try and change one written in assembly language. The quality of an ad hoc parser is only as good as the implementor and his funding; MIT happens to have an abundance of good programmers, but most other institutions do not. Forcing implementors to use ad hoc techniques will not only waste scarce resources, but it will also inconvenience users when the pressured implementors take short cuts (as they did with the old standard, and as MIT and other institutions have done with the current standard). To add in periods, significant modifications would have to be made to the grammar, practically disallowing top-down parsers (the easiest to construct correctly without a parser generator). Extra work would be required at the tokenizing level to preserve spacing. These changes would consume a non-trivial amount of programming time. Many implementors, having implemented the current standard and moved on to other projects, would be tempted to ignore such changes, especially since they produce such little gain. Implementors of new systems would not be able to use simple recursive descent and would be forced to obtain either a parser generator or use ad hoc techniques. The probability of most programs implementing the standard would be reduced. Is all that effort worth it? Perhaps if periods were in the current standard from the beginning; but at this late stage, I think not. You and others should have spoken up earlier. -------  Date: Sat, 12 Nov 83 18:11:39 PST From: Rich Wales To: Header-People@MIT-MC Subject: Re: Periods in full names in RFC822 #flame on I cannot agree with suggestions that the issue of unquoted periods in full names is a minor issue; nor am I willing to docilely accept protestations that it is now too late to consider a change. As for the suggestion that people should have spoken up earlier, I think the widespread use (albeit illegal) of full names with un- quoted periods is a good indication that large numbers of people completely overlooked this fine point in the RFC until now. If it had been clear earlier that this restriction was part of the standard, I suspect there would have been plenty of complaints long ago. If the technical issues involved in modifying RFC822 to allow full names with periods are not oppressive, I am in favor of making the change. #flame off So far, the following technical assertions have been made in opposition to changing RFC822 to allow periods in full names without quoting same: (1) Either the lexical analysis would become context-dependent, or else simple (recursive-descent) parsers could no longer be used. (2) The spacing around the periods could not be easily reproduced from the tokenized and parsed form of the address. First, the parsing issues. It is indeed true that if you take the address grammar of RFC822, and change it only by allowing a "phrase" to consist of any combination of "word"s (atoms and quoted strings) and periods, the grammar becomes ambiguous (for bottom-up as well as top-down parsers). Specifically, you can't always distinguish between a "phrase" and a "local-part". My suggestion for getting around this problem is quite simple: get rid of the "local-part" token entirely, and use "phrase" in the definition of "addr-spec" instead of "local-part". Admittedly, this change does allow some illegal addresses to get by the parser (in particular, addresses with spaces in the local part), but these can easily be detected after the address has been parsed via a very simple ad-hoc examination of the local part. Here is an unambiguous YACC grammar which should parse addresses where an unquoted full name could contain periods. I believe this grammar is as easy to implement in a top-down parser as the original RFC822 gram- mar, but I would appreciate verification of this claim from anyone out there with access to a recursive-descent parser generator. Hopefully the YACC notation is clear enough so that even those not familiar with YACC can understand it. With the exception of the different "phrase" definition and the use of "phrase" instead of "local-part" for "addr-spec", this grammar is sup- posed to be equivalent to that shown on page 27 of RFC822. /* * YACC grammar for RFC822 address specification, * expanded to allow unquoted periods in phrases */ /* these are the terminals produced by the lexer */ %token ATOM %token QUOTED_STRING %token DOMAIN_LITERAL %% address: mailbox | group group: phrase ':' ';' | phrase ':' mailbox_list ';' mailbox_list: mailbox | mailbox_list ',' mailbox mailbox: addr_spec | phrase route_addr route_addr: '<' addr_spec '>' | '<' route addr_spec '>' route: at_domain_list ':' at_domain_list: '@' domain | at_domain_list ',' '@' domain addr_spec: phrase '@' domain /* NOTE CHANGE: "phrase" used here */ domain: subdomain | domain '.' subdomain subdomain: domain_ref | DOMAIN_LITERAL domain_ref: ATOM phrase: /* NOTE CHANGE: periods OK in phrase */ phrase_element | phrase phrase_element phrase_element: word | '.' word: ATOM | QUOTED_STRING Second, the spacing issues. As I mentioned in a previous message, this problem is quite simple to solve. Simply have the lexer flag each token which is followed by white space (the amount of white space is unimport- ant). When the time comes to "prettyprint" the address, use these flags to space out the full name properly. -- Rich  Date: Sat 12 Nov 83 18:54:47-PST From: Mark Crispin Subject: more flames To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I'm afraid this suggestion is much too sensible and simple to merit serious consideration. After all, it undoubtably offends the religion of certain individuals. I will not name those individuals, but it should be quite obvious who they are. Here goes: . remove "." from the definition of "specials" . add "." to the definition of "ALPHA" . "local-part" then becomes equivalent to "word"; remove "local-part" from the syntax and replace it with "word" every place it occurs This shouldn't break anyone's parser. In fact, this is precisely the sort of rule the TOPS-20 mailsystem (and I suspect Multics as well) would prefer to think of anyway. I fear what I will say next will bring cries of "heresy" upon me. I hope I won't be burnt at the stake: The only reason why "." is part of the definition of "special" that I can discern is to coddle a certain mailsystem which uses "." as a routing delimiter in the local part. Unfortunately, that mailsystem and the individuals involved are quite powerful with regard to the politics of what the standard looks like. They can put anything they want into the standard irregardless of what anyone else may want. The TOPS-20 mailsystem, and various others, use an entirely different routing delimiter, "%", even though it is not defined as a "special". We have never felt that we needed to have "%" defined as a "special", and have done fine without it. Why, pray tell, must a character that people do want to use as an "ALPHA" be defined as "special", considering that the only purpose for it is to pre-parse an entity for an entirely different level than the RFC 822 level? -- Mark -- -------  Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 22:55:37 EST Date: Sat, 12 Nov 83 22:57:54 EST From: John R Ellis Subject: Re: Periods in full names in RFC822 To: Rich Wales Cc: Header-People@MIT-MC.ARPA In-Reply-To: Rich Wales , Sat, 12 Nov 83 18:11:39 PST If the technical issues involved in modifying RFC822 to allow full names with periods are not oppressive, I am in favor of making the change. Good, the discussion is now rationale again: Figure out the technical costs of making the change and then decide if the costs are worth it. I like your suggestion for merging LOCAL-PART and PHRASE and implementing the "no spaces in local parts" rule as a post-parse semantic restriction. That grammar would be easily parseable by top-down parsers. So given those changes, is the effort of changing true parsers worth the benefit of periods? It would take me about 6 hours to change our recursive descent parser, rebuild all of its clients (user interfaces and mail server), distribute the programs, change documentation, etc. That's a non-trivial amount of time for Yale system programmers, though not great. How many other sites have recently implemented mail systems that are faithful to RFC 822 and would need to change? I guess I think that all those implementor-days or half-days hacking in periods retroactively could better be spent on new projects such as domain servers that will have much larger impact on mail services. (Of course, all the sites that never hacked their old ad hoc parsers in the first place wouldn't have to change a thing. But then that's why they didn't complain about RFC 822 when it was published -- they had no need for the actual grammar.) ---------------------------- A very minor technical point: A grammar is "ambiguous" if there are several possible complete parses of an input string. Just because a grammar is not LL(1) or LALR(1) does not mean that it is ambiguous. The proposed modification of PHRASE to be a sequence of words or periods would not have resulted in an ambigous grammar, just one that many parsing methods couldn't handle. -------  Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 23:22:09 EST Date: Sat, 12 Nov 83 23:26:54 EST From: John R Ellis Subject: Re: more flames To: Mark Crispin Cc: Header-People@MIT-MC.ARPA In-Reply-To: Mark Crispin , Sat 12 Nov 83 18:54:47-PST The only reason why "." is part of the definition of "special" that I can discern is to coddle a certain mailsystem which uses "." as a routing delimiter in the local part. ...considering that the only purpose for it [period] is to pre-parse an entity for an entirely different level than the RFC 822 level? Forget LOCAL-PARTs for the moment; "." also serves as a delimiter of subdomains. Are you suggesting that the definition of DOMAIN also be replaced by WORD? I find it entirely reasonable that domain syntax is described at the RFC 822 level. For example, the Yale mail system has a single parser/ mail-address package used by two user interfaces and a mail delivery daemon. That package operates essentially at the RFC 822 level, and it manipulates domains. -------  Date: Sun 13 Nov 83 11:56:01-PST From: Mark Crispin Subject: Re: more flames To: Ellis@YALE.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "John R Ellis " of Sat 12 Nov 83 20:33:18-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My belief is that the syntax of domains should not be defined at the RFC 822 level. Instead, domain syntax should be defined by the various domains RFC's. 822 should merely specify the means of obtaining the domain atom. If the developers of domain syntax ever decide they want to change the syntax of domains, e.g. to allow a null top-level domain as has been suggested, 822 should not get in the way. It offends my sense of structured programming to parse a domain twice; first at the 822 level and second in the domain lookup module. -------  Received: by YALE-BULLDOG via CHAOS; Sun, 13 Nov 83 16:38:49 EST Date: Sun, 13 Nov 83 16:45:39 EST From: John R Ellis Subject: What level domain syntax? To: Mark Crispin Cc: Header-People@MIT-MC.ARPA In-Reply-To: Mark Crispin , Sun 13 Nov 83 11:56:01-PST It offends my sense of structured programming to parse a domain twice; first at the 822 level and second in the domain lookup module. If that's the way you engineered your system, I would be offended too. However, there are better ways of building mail systems than at the string level encouraged by assembly language programming. We have a header and address package that parses headers and addresses into structured objects and performs operations on those objects. The package is shared by all components of the mail system: user interface, user-information database, and mail daemons. In any program domains are parsed exactly once at the time an address is parsed, and thereafter represented as structured vectors. One of the operations on an address is "normalize", which puts the address into cannonical form. For domains, this currently consists of fully qualifying the domain and replacing nicknames by official names. All the clients of the address package invoke normalize as a matter of course. For example, the user-information database normalizes addresses and checks for duplicates when members are added to a mailing list. The overall advantages of this methodology should be obvious. Describing the syntax of domains at the 822 level is entirely appropriate, since domains are manipulated at the same level as the other parts of addresses. It is better design to have the parsing and address manipulation concentrated in one package than scattered throughout the system. If the developers of domain syntax ever decide they want to change the syntax of domains, e.g. to allow a null top-level domain as has been suggested, 822 should not get in the way. Using this methodology, 822 won't "get in the way," either in defining the change or in retrofitting the existing address package. For example, to add the root domain as a trailing dot, it is trivial to change the syntax of domain to be: DOMAIN = WORD *("." WORD) ["."] Then the single address parser in the address package is changed to reflect the new syntax and the operations are changed accordingly. -------  Date: Sun 13 Nov 83 18:37:27-PST From: Mark Crispin Subject: Re: What level domain syntax? To: Ellis@YALE.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "John R Ellis " of Sun 13 Nov 83 17:55:48-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) John Ellis missed my point. By insisting that the RFC 822 level define what the syntax of the right half of the "@" is, RFC 822 is needlessly limiting itself. I prefer to think of the left half of the "@" as a "mailbox" identifier, and the right half as an "address" at which this mailbox can be found. Both "mailbox" and "address" are abstract concepts; today "mailbox" generally means "user ID on a particular computer" and "address" generally means "the NIC registered name of a particular computer". I believe that these concepts can, and should, be expanded. Because of this, I would prefer that 822 not specify anything about what the structure of the right half of the "@" is. I would prefer that to be in an entirely separate module. It has nothing to do with string processing or assembly language programming; it is an attempt to be modular and to use 822 in non-Internet applications where domains may be inappropriate or irrelevant. Given then that some module other than 822 would be enforcing the correct syntax of domains, there now seems to be no reason to continue making "." be a special. It would make a number of existing users (who detest quotes around their personal names) happy and should not add any particular difficulties to any YACC-based parser. -------  Received: by YALE-BULLDOG via CHAOS; Mon, 14 Nov 83 00:27:26 EST Date: Mon, 14 Nov 83 00:33:47 EST From: John R Ellis Subject: Re: What level domain syntax? To: Mark Crispin Cc: Header-People@MIT-MC.ARPA In-Reply-To: Mark Crispin , Sun 13 Nov 83 18:37:27-PST John Ellis missed my point. I didn't miss your point. One of your arguments against 822-specified domain syntax was that it would require domains to be parsed twice; I pointed out that was silly. Your other argument about decoupling the concept of domain and "address" is much more to the point. -------  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Nov 83 00:53:30 EST Date: 14 Nov 83 0105 EST (Monday) From: Richard H. Gumpertz To: John R Ellis Subject: Re: Periods in full names in RFC822 CC: Header-People@MIT-MC In-Reply-To: "John R Ellis's message of 12 Nov 83 14:58-EST" Message-Id: <14Nov83.010516.RG02@CMU-CS-A> I resent being told we should have spoken up earlier -- we have repeatedly been stomped on hard when we said anything about spaces and dots in names. Sigh. Rick Gumpertz  Received: by YALE-BULLDOG via CHAOS; Mon, 14 Nov 83 03:58:13 EST Date: Mon, 14 Nov 83 04:00:50 EST From: John R Ellis Subject: Re: Periods in full names in RFC822 To: Richard H Gumpertz Cc: Header-People@MIT-MC.ARPA I resent being told we should have spoken up earlier -- we have repeatedly been stomped on hard when we said anything about spaces and dots in names. Sigh. Out of curiosity, I went into the archives to see exactly what had been said about periods in PHRASE (full names). RFC 822 was published 15 months ago. Here is a summary of messages since then concerning periods in 822 PHRASE: 18-Oct-82 Chris Kent asks if periods are allowed in full names. 27-Oct-82 Tim Korb replies that the grammar really does disallow periods in full names. He suggests in passing that periods should be allowed "until this issue is resolved." 27-Oct-82 Dave Crocker replies that A E. Dupont is indeed legal. 27-Sep-83 Nat Mishkin complains that messages are still being sent with unquoted periods in full names. 28-Sep-83 Gavin Eadie complains about the same thing. present uproar So in 15 months, there was one mild complaint about the actual definition of PHRASE. The restriction on periods was immediately clear to those few sites that had implemented true parsers, but I guess none of them cared enough to complain. -------  Date: 5 Oct 1983 0826-PDT Sender: WMARTIN at OFFICE-3 Subject: Unique identifier for messages From: WMartin at Office-3 (Will Martin) To: Header-People at MIT-MC Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN> Wouldn't a good way to uniquely identify messages, given the problem of changed messages having the Message-ID unchanged, be a combination of an originally-assigned Message-ID field and the number of characters in the Text field? Most duplicate messages I've seen have different character-counts for the entire message, because the header has more fields or more data in a field, but the Text is identical. Since most message-systems seem to use the character-count for various purposes, would it be hard to just count the characters in the Text field alone? I would think that it would be safe to program a system to assume duplicates exist if both the Message-ID and the Text field character-count were identical. If there was no Message-ID, of course, such a message wouldn't be considered as a candidate for being a duplicate, even if it was. (I doubt that it would be safe to consider messages to be duplicates if both had null Message-ID's and identical Text-field character-counts -- too much margin for error in that case.) Will Martin  Received: from merlin.ARPA by purdue.ARPA; Mon, 14 Nov 83 12:16:46 EST From: Christopher A Kent Message-Id: <8311141616.AA01310@merlin.ARPA> Received: by merlin.ARPA; Mon, 14 Nov 83 11:16:37 EST Date: 14 Nov 1983 1116-EST (Monday) To: John R Ellis Cc: Header-People@MIT-MC.ARPA Subject: Re: Periods in full names in RFC822 In-Reply-To: Your message of Mon, 14 Nov 83 04:00:50 EST. <8311140911.AA15881> Now hold on a sec... 27-Oct-82 Dave Crocker replies that A E. Dupont is indeed legal. Maybe I'm just too lazy to dig this out, but should "legal" be "illegal" here? Cheers, chris ----------  Date: 14 Nov 1983 12:25:04 PST From: POSTEL@USC-ISIF Subject: re: Periods in Full Names in RFC822 To: Header-People@MIT-MC Rick Gumpertz is justified in saying that CMU was stomped on hard about spaces in names (not dots though), but it must be noted that the complaints were about spaces in the of the mailbox, not the now generally used for a full name. --jon. -------  Date: 14 Nov 1983 16:31-PST Sender: JKREYNOLDS@USC-ISIF Subject: re: Periods in Full Names in RFC 822 From: JKREYNOLDS@USC-ISIF To: Header-People@MIT-MC Message-ID: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS> In regards to the recent messages on periods in full names in RFC 822, we would like to propose an alternative: personal names with a new construct that would provide alot of variety without so many periods. It would be called ntext. The following represents the proposed construct: mailbox = addr-spec / [ntext] route-addr ntext = 1*", ",", or CTLs, but allowing BACKSPACE> BACKSPACE = ; (10, 8.) ntext would not only provide users who wish to use their full names or initials (i.e., Joyce K. Reynolds or J.K. Reynolds), but would also allow users with lower case characters in their names (Juanita y Cruz, Max de Trudeau) or apostrophes in their names (D'Vinet, d'Vinet). More complicated names that have slashes through letters, hats or apostrophes can also be used within the ntext construct. For example: ( = Backspace) J/ohansen (a slash would be through the letter o) ^Cot'e (a hat would be over the C and an accent would be over the letter e) This new construct provides better options and flexibility without creating major changes. Joyce Reynolds and Jon Postel  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Nov 83 23:34:03 EST Date: 14 Nov 83 2345 EST From: Rudy.Nedved@CMU-CS-A To: Stephen Tihor Subject: Re: Restrictive "i"-internet transfers CC: header-people@MIT-MC In-Reply-To: <3153F9055.006F0024.1983@CMCL1.NYU-CMCL1.ARPA> Message-Id: <14Nov83.234503.EN0C@CMU-CS-A> Umm...there are better reasons to not allow mail between certain entities and to not say "...mail should be free..." 1) As a taxpayer, I don't like to see non-contributing people use the ARPANET for personal gains. ARPANET was a research subject but has evolved into an effective "tool". I have benefitted from the quick and "personal" flow of mail. I fail to see the benefit of some person in UUCP land sending a mining proposal to someone in non-CMU-CS/RI land. The proposal is probably not bound for the goverment and it is doesn't contribute to CS/RI research. Purolator Courier, MCI Mail, GTE TELENET TELEMAIL, UPS, Federal Express and good old US Postal system are what people should use. 2) I tend to believe in competition creating better enviroments and in costs being seen by the users. The cost of using the ARPANET is rarely seen by the end-user...he or she never gets charge postage for the hardware and the software that is used. Commercial electronic mail systems on the other hand charge postage and are used more effectively by their users. 3) The ARPANET has at max it seems 50KBD links between IMPs and we have recently gone thru a protocol transition and a split which took a very large number of man hours, large expenditure of money on hardware and a large expenditure of money on support services (ma bell, clerical, answering users complaints, etc.) to get the thing working by many different organizations. To see Fortran manuals, special character files that draw funny pictures on Heathkit 19s, etc. sent thru the mail is disheartening. My apology for the length of the mail message. -Rudy  Date: Mon, 14 Nov 83 21:48:18 PST From: Rich Wales To: Header-People@MIT-MC Subject: Re: "ntext" answer to periods in full names In-reply-to: JKREYNOLDS@USC-ISIF's message of 14 Nov 1983 16:31-PST Joyce and Jon -- Regarding your "ntext" proposal, I believe it has some good points and some not-so-good points. My initial feeling is that, in its current form, it is not quite satisfactory; however, perhaps it can be refined. Some particulars: (1) I note with HEARTY APPROVAL that your proposed rule for "mailbox" -- mailbox = addr-spec / [ntext] route-addr -- would allow a bare "route-addr" (an address enclosed in angle brackets) without a preceding "full-name" string. Whatever form of full-name representation we end up with, I think this innovation should definitely be included. (2) I am concerned that your proposed rule for "ntext" -- ntext = 1*", ",", or CTLs, but allowing BACKSPACE> -- would complicate lexical analysis of an address. Specifically, the lexer would have no way of telling whether a "mailbox" started with an "ntext" or an "addr-spec" without performing a potentially unbounded lookahead. (3) You suggest that the "ntext" proposal would allow users to have apostrophes and/or uncapitalized words in their names (e.g., "Max de Trudeau" or "d'Vinet"). But constructions like these are al- ready permitted by RFC822. The apostrophe (single quote) is not designated as a special character and may freely occur in atoms, and no recapitalization of the full name is either required or ex- pected. (4) I am somewhat hesitant about the prospect of names with backspaces (to implement accents on letters via overstriking). Most users probably read their mail on CRT terminals without any overstriking capability, so such effects would be lost on them. However, this part of your proposal would not cause lexing or parsing problems as far as I can tell, since the backspace does not currently have any special function in an address. I would be interested in knowing whether you think the proposal I made last Saturday (12 Nov 83 18:11 PST) -- in which I suggested that the "phrase" nonterminal be redefined to allow a free mix of atoms, quoted strings, and periods; that "local-part" be replaced by "phrase" in the "addr-spec" rule; and that a post-parse scan be used to kick out mal- formed local parts -- would meet your concerns if the "atom" token were redefined to allow backspaces. -- Rich  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA25803; Mon, 14 Nov 83 21:16:16 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA03588; Mon, 14 Nov 83 21:23:23 pst Date: Mon, 14 Nov 83 21:24:22 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA23673; Mon, 14 Nov 83 21:24:22 pst To: header-people@mit-mc Subject: Errors-To Field Forwarded for your information from USENET News: From gnu@sun.UUCP Fri Nov 11 01:38:55 1983 Newsgroups: net.news,net.mail Subject: Fix for Arpanet junk deluges (at gateway) Article-ID: net.mail/190 If the news<->mail gateway would add "Errors-To: Unix-Emacs-Request@wherever" to the headers of newsitems which are being posted to the Arpanet, at least the volume of garbage coming back would be returned. If Sendmail can't deliver a message, and it contains an Errors-To line, it gets sent there rather than to the poor submitter. Of course, if the mailer which has trouble is not Sendmail, we're out of luck. Arpanet folks who maintain redistribution lists (eg, Unix-Emacs) are encouraged to add this line to each message you redistribute, too. And if many mailing lists start using Errors-To:, maybe some of the mailers other than sendmail will get modified to use it. Then we would all be happier.  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Nov 83 01:20:03 EST Date: 15 Nov 83 0132 EST From: Rudy.Nedved@CMU-CS-A To: wcwells%ucbopal.CC@UCB-VAX (Bill Wells) Subject: Re: Errors-To Field CC: header-people@mit-mc In-Reply-To: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA> Message-Id: <15Nov83.013202.EN0C@CMU-CS-A> Here is my response to James Gosling after he started getting pressure to put pressure on me to add Errors-To:. It is a highly undiplomatic message but I am tired and consider the case closed. Date: 14 Nov 83 2320 EST From: Rudy.Nedved@CMU-CS-A To: James Gosling Subject: Re: Unix.Emacs errors In-Reply-To: <437696282/jag@jag> Message-Id: <14Nov83.232035.EN0C@CMU-CS-A> I don't know where you picked up the "Errors-To" concept. It is wrong since most of the mailers on LANs and ARPANET-like enviroments use the out-of-band information to return mail. It has been spec'd by the ARPANET community (well an intelligent majority), that the out-of-band information be changed when a piece of mail comes to a mailbox that is a "mail exploder". The Return-Path information is supposed to be a local mailbox like "Unix-Emacs-Request". The problem at the moment for Unix-Emacs is that we have not made the change to the TOPS-20 mailer but it is in the works. For the time being, I suggest that you send out a test message and then zap anyone you get grief with and tell them that you will add them back when they get their mail system up to 99% working status or we get our mail system to send error messages to a local mail box...which ever comes first. -Rudy   Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 15 Nov 83 01:06:29 PST Date: 15 Nov 83 9:02:13 GMT (Tue) From: Steve Kille (44a) To: jkreynolds@usc-isif.arpa, postel@usc-isif.arpa cc: header-people@mit-mc.arpa, robert@ucl-cs, kirstein@ucl-cs Subject: Protocol stability I am a little concerned about the changes proposed to RFC 822. I think that the changes which you are proposing are an improvement. However, the issue is not vastly important. Since the move from RFC 733 -> 822 occurred, I spent quite some effort persuading the UK community that they should follow this change in the interests of compatability. There was a good deal of opposition. If changes such as this occur, it will be argued (quite reasonably), that it is not worth the effort of chasing protocols which will disappear under your feet. There are many groups outside of the DARPA Internet who use RFC 822 as a Message format, and compatability is of mutual benifit. I would like to keep RFC 822 as it stands - warts and all. Steve Kille  Date: 15 November 1983 01:36 pst From: Bakin.SSID at HI-MULTICS Subject: Re: Restrictive "i"-internet transfers To: header-people at MIT-MC Acknowledge-To: Bakin.SSID at HI-MULTICS I would like to pick at a point of Rudy.Nedved's message: I tend to believe in competition creating better enviroments and in costs being seen by the users. The cost of using the ARPANET is rarely seen by the end-user...he or she never gets charge postage for the hardware and the software that is used. Commercial electronic mail systems on the other hand charge postage and are used more effectively by their users. While I have never used a commercial service, I doubt that users use a service more effectively simply because they are charged for it. Again, I have never used a commercial service, but how many offer FTP, and telnet besides Mail Service? How many can be accessed as easily as the ARPAnet? More to the point, effectiveness is in the eye of the beholder: ::= 1. Having an intended effect. 2. Producing a desired impression; striking. 3. Operative; in effect. (This is from my American Heritage Dictionary of the English Language, not a great source, but it will do.) I fail to see a mechanism in charging users that creates more effective use of the net for that user. It is possible that charging users does create less traffic, and so the net response may improve for all, but this does not mean that the traffic that is out there will become more effective. Rather, projects who have little money to begin with will communicate poorly over the net, while those projects with Big Bucks will not suffer a whit, and will continue to send Fortran manuals, or human-nets-digest. This does not seem to create effective use of the ARPAnet at all! It doesn't even promote efficient use. I can understand the motives behind Rudy.Nedved's message, as an institution which is publicly supported, it is to be hoped that the ARPAnet is not abused. Nevertheless, charging users for its use, or the restriction of internet mail is like cutting off your nose to spite your face: a dubious method all around. Jerry Bakin  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Nov 83 05:25:38 EST Date: 15 Nov 83 0537 EST From: Rudy.Nedved@CMU-CS-A To: Bakin.SSID@HI-MULTICS Subject: Re: Restrictive "i"-internet transfers CC: header-people@MIT-MC In-Reply-To: "Bakin.SSID@HI-MULTICS's message of 15 Nov 83 04:36-EST" Message-Id: <15Nov83.053741.EN0C@CMU-CS-A> My comments are based on the following expectation...independent of who gets hurt...just simple trend watching: It is my expectation that one of these days gateways connected to the ARPANET will have to charge for access on some level to pay for the service. This is based on the ever growing CSNet which has to charge for the hardware, software and man power made available, increased knowledge of "private" computer links in public databases and in the increasing commercial electronic mail systems that would just love to boast of mail service to the ARPANET world. -Rudy  Received: from merlin.ARPA by purdue.ARPA; Tue, 15 Nov 83 07:37:49 EST Received: by merlin.ARPA; Tue, 15 Nov 83 07:37:02 est Date: 15 Nov 1983 0737-EST (Tuesday) Return-Path: <@MIT-MC:JKREYNOLDS@USC-ISIF> Received: from purdue.ARPA (purdue-arthur.ARPA) by merlin.ARPA; Mon, 14 Nov 83 20:19:57 est Received: from MIT-MC by purdue.ARPA; Mon, 14 Nov 83 20:20:34 EST Date: 14 Nov 1983 16:31-PST Sender: JKREYNOLDS@USC-ISIF.ARPA Subject: re: Periods in Full Names in RFC 822 From: JKREYNOLDS@USC-ISIF.ARPA To: Header-People@MIT-MC.ARPA Message-Id: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS> In regards to the recent messages on periods in full names in RFC 822, we would like to propose an alternative: personal names with a new construct that would provide alot of variety without so many periods. It would be called ntext. The following represents the proposed construct: mailbox = addr-spec / [ntext] route-addr ntext = 1*", ",", or CTLs, but allowing BACKSPACE> BACKSPACE = ; (10, 8.) ntext would not only provide users who wish to use their full names or initials (i.e., Joyce K. Reynolds or J.K. Reynolds), but would also allow users with lower case characters in their names (Juanita y Cruz, Max de Trudeau) or apostrophes in their names (D'Vinet, d'Vinet). More complicated names that have slashes through letters, hats or apostrophes can also be used within the ntext construct. For example: ( = Backspace) J/ohansen (a slash would be through the letter o) ^Cot'e (a hat would be over the C and an accent would be over the letter e) This new construct provides better options and flexibility without creating major changes. Joyce Reynolds and Jon Postel  Date: Tue, 15 Nov 83 10:25 PST From: Taft.PA@PARC-MAXC.ARPA Subject: Re: Periods in Full Names in RFC 822 In-reply-to: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS> To: Header-People@MIT-MC.ARPA Please add my vote in opposition to the "ntext" proposal. Rich Wales has done a good job of summarizing the technical problems with it. I would like to add two remarks: (1) The proposal involving and overstriking really amounts to an extension of the ASCII standard to enable foreign characters to be encoded. The fact that an ad-hoc encoding happens to "come out right" on some terminals does not make it a good encoding! And in any event, RFC 822 is not an appropriate place to specify an extension to ASCII. (2) I vote for no changes to RFC 822 other than to fix typographical errors in the specification (of which there are many) and to clarify matters that are now obscure. No amount of fiddling with the header syntax is going to make more than a negligible improvement in the overall standard. RFC 822's fundamental problems derive from the constraints imposed by the text memo header framework in which it has to fit. No real improvement will occur until that framework is junked and replaced by a structured format such as the NBS or CCITT message standard. I am dismayed over the amount of smoke and heat generated and brain cycles wasted in debates about header syntax. Let's declare a moratorium on twiddles to RFC 822 and move on to more difficult and more interesting problems such as implementation of the new domain names standard. Ed Taft  Received: by YALE-BULLDOG via CHAOS; Tue, 15 Nov 83 14:16:37 EST Date: Tue, 15 Nov 83 14:20:05 EST From: John R Ellis Subject: Re: Periods in Full Names in RFC 822 To: Taft.PA@PARC-MAXC.ARPA Cc: Header-People@MIT-MC.ARPA In-Reply-To: Taft.PA@PARC-MAXC.ARPA, Tue, 15 Nov 83 10:25 PST Let's declare a moratorium on twiddles to RFC 822 and move on to more difficult and more interesting problems such as implementation of the new domain names standard. Amen. -------  Date: 15 Nov 83 14:28 EST From: Stephen Tihor To: Taft.PA@PARC-MAXC.ARPA Subject: RE: Periods in Full Names in RFC 822 Cc: header-people@MIT-MC.ARPA Message-ID: <3194F8A4B.004C001D.1983@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <8311151902.AA15933@NYU.ARPA> ; Message of 15-NOV-1983 14:03 from Taft.PA@PARC-MAXC.ARPA A minor point perhaps but the use of backspace in the ntext proposal IS the ANSI/ISO character set specification of the correct way to produce the multistruck characters. A few special CRTs can interpret it properly even in the US and more elsewhere, it looks right on paper, and the order list in the examples will quite properly produce the usual colpasing of overstuck characters into their nearest non-overstruck alphabetic. -------  Date: Tue, 15 Nov 83 11:57:54 PST From: Rich Wales To: Header-People@MIT-MC Subject: Re: Moratorium on twiddles to RFC822 Wait a minute, folks. I, for one, do NOT consider the original sug- gestion (namely, modifying RFC822 to allow periods in unquoted full names) to be a "twiddle". Just because the Reynolds/Postel "ntext" proposal had some problems with it as originally presented, let's not all lose sight of what originally brought up the discussion. A suggestion has been made (my own proposal of 12 Nov 83) which seems to allow periods in unquoted full names without doing violence to any of the lexing/parsing methods reasonably available for handling head- ers. I believe that the degree of effort required to implement this, or a similar, proposal would be small. Many -- maybe even most -- of the mail-system implementors were probably not implementing the exact current standard via a grammar anyway; for most of them, the effort involved would likely be minimal to nil. To those in the UK/JNT community who hesitate to have any change, how- ever minor, in RFC822, let me again state my opinion (which I think is held by many other people) that I view the admission of periods in un- quoted full names to be more on the order of a "bug fix" to RFC822 than a true change. I dare say that if people had realized earlier that RFC- 822 required the quoting of full names which contained periods, this issue would have been discussed at length and ironed out long ago. This issue may not be as important as the distributed domain name serv- ers, but that doesn't mean it is utterly unimportant. -- Rich  Date: Tue, 15 Nov 83 14:28:08 EST From: Ron Natalie To: Rudy.Nedved@cmu-cs-a cc: Bakin.SSID@hi-multics, header-people@mit-mc Subject: Re: Restrictive "i"-internet transfers The charging software for DDN will be ready in 1986 (they claim). Nobody is sure what the details of charging will be (if any). -Ron  Date: Tue 15 Nov 83 13:46:35-PST From: Ken Harrenstien Subject: Bug fix to 822 To: Header-people@MIT-MC As one of the bloodied participants of past header format standard debates, I agree with those who contend that the illegality of "John R. Ellis" constitutes a bug, and should be fixed. Perhaps John R Ellis was not around at the time that RFC733 was being written. My personal recollection (which may vary from that of others) is that 733 absorbed a great deal of energy from many of the involved parties, and there was a feeling that it marked the end of things. When it appeared to Dave Crocker that domains were on the way and a revision was necessary, he produced 822 with little in the way of debate. The politics of ARPAnet protocol standardization are VERY muddy, but some people certainly felt "stomped on" during 733 (by what authority is irrelevant) and were either tired or didn't feel like being stomped on again during 822. The point is that the treatment of periods is one thing that was changed from 733 to 822, although there is no obvious reason for changing anything other than the stuff to the right of the @-sign. In fact, in the old 733 you can see examples such as Alfred E. Neuman In 822 this example became Alfred Neuman Is this a cop-out, or is it a cop-out? Who ever heard of Alfred Neuman? Finally, a word about parsers. It seems to me that those people who have implemented snazzy 600-horsepower full-bore parsers with racing stripes, fur-lined bucket seats, and mag wheels that blast you towards the uttermost reaches of 822 should be exactly those people who will find it EASIEST to accomodate any fixes. The usual trend is that people with crude parsers complain bitterly about changes that force them to once again fight intricate tangles of code, whereas the un-crude exclaim "oh my, what a trivial thing!". It's strange to find the roles reversed. --Ken P.S. Whatever the importance or results of the 822-period-bug debate, it does highlight the need for some clearer agreement (or policy statement) on the issue of protocol development and modification. What makes a protocol "official"? When are changes "authorized"? Who decides this, and what voice do network sites have in the process? Do people want a real "Protocol Police"? I don't want to spark a new discussion topic just now, but someday those questions ought to have written answers. -------  Date: Tue 15 Nov 83 13:55:11-PST From: Mark Crispin Subject: change RFC 822? To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Suppose we consider whether or not 822 should be changed based on these details: . Do we want the typos in 822 corrected? If so, we'd need a different RFC just for typo correction . How many implementations correctly quote personal names with imbedded periods? . How many implementations are dumb, and merely insert whatever string the user gives for a personal name? (I'm afraid MM falls into this category) . How many implementations get upset at seeing: From: J. Random Hacker Of those, how many implementations determine that "J. Random Hacker" should have been quoted and compensate for it? . How many implementations have some heuristic (crock) algorithm that completely ignores anything outside of angle brackets unless there is no angle-bracketed string? (MM falls into this category) . Of the faulty implementations, how many implementors would find themselves more willing to upgrade their software if the dot question was resolved in the way users seem to want it resolved? -- Mark -- -------  Received: by YALE-BULLDOG via CHAOS; Tue, 15 Nov 83 18:33:20 EST Date: Tue, 15 Nov 83 18:39:00 EST From: John R Ellis Subject: Re: Bug fix to 822 To: Ken Harrenstien Cc: Header-people@MIT-MC.ARPA In-Reply-To: Ken Harrenstien , Tue 15 Nov 83 13:46:35-PST The usual trend is that people with crude parsers complain bitterly about changes that force them to once again fight intricate tangles of code, whereas the un-crude exclaim "oh my, what a trivial thing!". It's strange to find the roles reversed. This is a distortion. Ed Taft neatly summarized my main objection: Now is not the time to change 822. No one disputes that Wales' suggested hack would be "easy" to implement in a true parser (though it would dirty the formal specification a little). -------  Date: Tue, 15 Nov 1983 10:32:13 PST From: David M Alpern Return-Path: Subject: Restrictive Gateways To: HEADER-PEOPLE@mit-mc Via: IBM-SJ; 15 Nov 83 15:36-PST I'm sorry to see that my question, of a technical nature, has yielded so much flaming and NO technical comments. Whether or not those of us who have lived with virtually unlimited network access want to realize it, restrictive gateways, as I described, already exist in many environments, some academic and some business. They are a reality, regardless of our philosophy as to whether such restrictions should exist. I would greatly appreciate a TECHNICAL response to my question: Is there/ should there be a means in the header of specifying to an outside recipient that he may not be able to contact (via the given address) a local recipient? Or should the header show nothing special, under the assumption that the outside recipient will find out for himself if and when he replies? - Dave  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA00277; Wed, 16 Nov 83 00:42:42 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA13030; Tue, 15 Nov 83 22:40:27 pst Date: Tue, 15 Nov 83 22:40:31 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311160640.AA19790@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA19790; Tue, 15 Nov 83 22:40:31 pst To: header-people@mit-mc Subject: Precedence In reply to: Date: 1 November 1983 00:43-PST (Tuesday) Sender: TLI@USC-ECLB From: Tony Li To: Wcwells@BERKELEY Subject: Re: SMTP extension RFC I'm sort of new at this, but wouldn't using a precedence field in the SMTP header be somewhat confusing? The precedence field that you suggest is already present in the internet datagram header. Creating another use for the same precedence scheme in the SMTP header would seem to lead to ambiguity when referring to the 'precedence field'.... Tony, I cannot assume that "Internet Protocol (IP) " will be running under SMTP. I know of at least one case where "IP" is not the protocol being used under SMTP and there may others. I am not proposing a new use of precedence, but pointing out that "precedence" as defined for US Government telecommunications needs to implimented in "Internet Mail". To be effective precedence must be used at various levels. To the drafter it may mean the desired speed of delivery. But for communications personnel and message systems it also indicates the order in which messages are to be handled. That is, higher precedence messages should be transmitted before lower precedence messages. Within the same precedence, messages are usually handled on a first-in first-out basis. The drafter should be able to specific the precedence of an Internet mail message. One method would be the use of a "Precedence:" field in the Internet mail message heading. Within SMTP, indicating the precedence of message(s) to be transmitted when establishing a SMTP communications link would be useful when a particular mail relay or network is heavily loaded. For example, an overloaded host or gateway (to another network) might respond that it can accept only PRIORITY and above precedence messages until the overload condition goes down. Bill Wells, U C Berkeley wcwells@Berkeley.ARPA  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA00274; Wed, 16 Nov 83 00:42:28 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA06888; Tue, 15 Nov 83 17:29:34 pst Date: Tue, 15 Nov 83 15:39:22 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311152339.AA11178@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA11178; Tue, 15 Nov 83 15:39:22 pst To: header-people@mit-mc Subject: Re: Errors-To Field Cc: decvax!decwrl!sun!gnu@Berkeley The following was submitted as an article to USENET News group net.mail and is forwarded for information to the Header-People mailing list: Bill Wells -------------- In reply to: Path: ucbopal!ucbtopaz!ucbvax!decvax!decwrl!sun!gnu From: gnu@sun.UUCP Newsgroups: net.news,net.mail Subject: Fix for Arpanet junk deluges (at gateway) Message-ID: <339@sun.UUCP> Date: Fri, 11-Nov-83 01:38:55 PST Article-I.D.: sun.339 Posted: Fri Nov 11 01:38:55 1983 Date-Received: Fri, 11-Nov-83 21:39:16 PST References: drux3.874 Lines: 13 If the news<->mail gateway would add "Errors-To: Unix-Emacs-Request@wherever" to the headers of newsitems which are being posted to the Arpanet, at least the volume of garbage coming back would be returned. If Sendmail can't deliver a message, and it contains an Errors-To line, it gets sent there rather than to the poor submitter. Of course, if the mailer which has trouble is not Sendmail, we're out of luck. Arpanet folks who maintain redistribution lists (eg, Unix-Emacs) are encouraged to add this line to each message you redistribute, too. And if many mailing lists start using Errors-To:, maybe some of the mailers other than sendmail will get modified to use it. Then we would all be happier. In May 1983, there was a long discussion on how to handle errors resulting from messages forwarded by mailing list "address exploders" on the Headers-People@MIT-MC mailing list. During this time the "Errors-to:" header field was suggested by Dr. Jon Postal of the Information Sciences Institute (Marina del Rey, CA). Dr. Postal is the author of the "Simple Mail Transfer Protocol" (SMTP) used by the Unix "sendmail" program. After many comments concerning the proposed "Errors-To:" header field and variations thereof, it was decided that messages sent by a "mail address exploder" should be a new message. As far as I know, the "Errors-To:" header field has never been implimented as a standard Internet mail message header. Here is an extract from Dr. Postel's message of 27 May 83: Date: 27 May 1983 2032-PDT From: POSTEL@USC-ISIF Subject: Errors-To, round 3 To: Header-People@MIT-MC Hi. Thanks for all your comments. I have been persuaded that the functional capability i wanted is best provided (in the context of the current system) by the SMTP procedures and requiring that sending to a mailing list via a mail exploder be treated a two transaction process. That is, when a user sends a message to a mail exploder there is one transaction when the message travels via SMTP from the user to the exploder. Any errors detected (e.g. misspelling the mailing list name) in this stage will go back to the user. When the mail exploder sends the message to the mailling list there is another transaction. Any errors detected at this stage (e.g. a mailbox on the list does not exist) will go back to the "owner" of the mailing list. ...... I submitted the gnu@sun article to the Headers-People mailing list and received the following in reply: Date: 15 Nov 83 0132 EST From: Rudy.Nedved@CMU-CS-A To: wcwells@ucbopal (Bill Wells) Subject: Re: Errors-To Field Cc: header-people@mit-mc In-Reply-To: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA> Message-Id: <15Nov83.013202.EN0C@CMU-CS-A> ...... (Header-People have seen it before so I won't repeat ...... it here-WCW) I hope this clears up why "Errors-to" is not being used on in the Internet community. Hopefully it will not be too long before all mail exploders in the Internet community quote the message sent to the exploder in the text of a new message which is sent to the mail distribution list. Bill Wells, U.C. Berkeley ucbvax!wcwells wcwells@Berkeley.ARPA  Received: by UCB-VAX.ARPA (4.21/4.15) id AA19349; Tue, 15 Nov 83 20:13:11 pst Date: 15 Nov 83 16:43:47 EST (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Rudy Nedved on mail forwarding Message-Id: <8311152143.AA20717@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA20717; 15 Nov 83 16:43:47 EST (Tue) To: header-people@mit-mc.ARPA re: As a taxpayer, I don't like to see non-contributing people use the ARPANET for personal gains. ARPANET was a research subject but has evolved into an effective "tool". I have benefitted from the quick and "personal" flow of mail. I fail to see the benefit of some person in UUCP land sending a mining proposal to someone in non-CMU-CS/RI land. I resent this. For your information, UUCP mail is sent over dialup telephone lines. These phone calls are usually long distance and cost REAL MONEY for the site placing the phone call. Frequently UUCP mail goes over several hops, resulting in several phone calls. All the sites along the way pay for the phone call, even though the message is for the person who originated the mail. Yet, each site in UUCP land is willing to pay for phone calls to forward other people's mail, in return for other sites being willing to pay for the phone call to send their mail. In addition, poor sites (like universities) that cannot afford any phone bills are often on the UUCP net out of the generousity of some commercial site polling them frequently. UUCP is also quite willing to forward mail from people on the ARPANET (or anywhere else) through the UUCP net, even if the final destination is on some other network somewhere. Now you're going to tell me that the ARPANET is populated by snobs who are unwilling to accept mail that originated on the UUCP net, at considerable cost to UUCP sites, destined for ARPANET users? Even though it doesn't cost you or ARPA ONE RED CENT additional for this mail to go through your fixed-rate lines? Tell me, do you have an in-box on your desk in your ARPA-funded office? Do you only accept paper mail from other ARPA-funded offices in this in-box? Do you send back mail from some other source, because you don't want your ARPA funding to pay for mail that isn't official ARPA mail? Now, suppose you quit/graduate and move elsewhere in the country. What happens when mail is sent to you at your ARPA-funded address? Do you expect this mail to be tossed into the trash instead of being forwarded to your new address? I'd like to point out that it takes two to use electronic mail - a sender and a receiver. To listen to you, if one of them is a sanctified ARPA funded person (all kneel!) the other one should not be allowed to even talk to this holy person without having equal status! Disclaimer: I am talking about personal electronic mail, short, low volume, and sent (most of the time) over the most reasonable route. I am NOT advocating shipping of large files over other people's networks (unless there is no other way to get it there, and the sites along the way consent) by hiding them in mail - this is just bad manners, and isn't very reliable either. (Spool areas tend to fill up.) Nor am I advocating shipping mail from one UUCP site, to an ARPA gateway, over the ARPANET, to another ARPA-UUCP gateway, then out to another UUCP site, at least not on a regular basis. (Occasionally mistakes will happen, especially in the case of forwarded mail when the sender does not know the new address of the addressee.) However, if some site is on a network that has only a connection to the ARPANET, and they want to send mail to UUCP or CSNET, they have little choice but to go through the ARPANET, and conversely for this same site receiving mail. I think the primary goal should be universal service. Let's first make it possible to get mail from anybody to anybody, then worry about the most efficient or lowest cost or most politically expedient way to get it there. Mark Horton  Date: Wed, 16 Nov 83 16:24:44 EST From: Ron Natalie To: header-people@mit-mc Subject: Re: Precedence Despite his work with mail protocols, it's still Postel not Postal. -Ron  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 16 Nov 83 17:42:44 EST Date: 16 Nov 83 1753 EST From: Rudy.Nedved@CMU-CS-A To: cbosgd!mark@UCB-VAX (Mark Horton) Subject: Re: Rudy Nedved on mail forwarding CC: header-people@MIT-MC In-Reply-To: <8311152143.AA20717@cbosgd.UUCP> Message-Id: <16Nov83.175318.EN0C@CMU-CS-A> I knew I blew the example. I meant someone in UUCP land sending a large document to someone in the CMU undergraduate land that had nothing to do with the UUCP land or with ARPANET land. A better example is sending H19 files from a CMU students account that just got job at some site hanging off of UUCP land. Anyhow... I am highly sympathetic with the expense behind UUCP transfers. I feel people should use the lines more effectively and not send "junk" mail on them. I suspect that one of the reasons people don't run USENET software that includes broadcasting of node information is that they arew afraid there "private" and "expensive" link will be used for purposes that they can not afford. I am not an ARPANET snob nor do I prefer ARPANET over other networks. I just try to do the best for everyone. It is too bad you got bent out of shape over my poorly written example. -Rudy P.S. When I leave I plan to NOT have my mail forwarded. I don't need the aggravation from bug reports.  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA00332; Wed, 16 Nov 83 00:45:24 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA11584; Tue, 15 Nov 83 21:12:45 pst Date: Tue, 15 Nov 83 21:12:48 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311160512.AA18180@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA18180; Tue, 15 Nov 83 21:12:48 pst To: header-people@mit-mc Subject: Precedence This discussion started with the subject line of "SMTP Extension RFC". With this message I am dividing the discussion into specific topics. -WCW. ---------- SURPRIZE! The National Precedence System designators are already specified in the IP Header Format (RFC-791 section 3.1) which has the following precedence designators: 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - FLASH 010 - IMMEDIATE 001 - PRIORITY 000 - ROUTINE So, that leaves us with: a. If, when and how should the precedence designators ECP, FLASH, IMMEDIATE, PRIORITY and ROUTINE be implimented at the mail transport (SMTP) and user levels? That is to say, how does the user specify the precedence of a Internet mail message and how should it be handled by SMTP and mail gateways. b. Should a LOW precedence designator be implimented for such things as mailing lists and news articles. (I assume LOW would be mapped to ROUTINE in the IP header, since 000 through 111 is used up). Bill Wells, UC Berkeley wcwells@Berkeley.ARPA P.S. Thanks, Tony. I had forgotten that there was a precedence field in the IP header format.  Date: Thu, 17 Nov 83 01:44 EST From: "Robert W. Kerns" Subject: Re: Periods in Full Names in RFC 822 To: John R Ellis Cc: Taft.PA@PARC-MAXC.ARPA, Header-People@MIT-MC.ARPA In-reply-to: The message of 15 Nov 83 14:20-EST from John R Ellis Message-ID: <831117014420.6.RWK@YUKON.SCRC.Symbolics> Date: Tue, 15 Nov 83 14:20:05 EST From: John R Ellis Let's declare a moratorium on twiddles to RFC 822 and move on to more difficult and more interesting problems such as implementation of the new domain names standard. Amen. ------- Well, yes. But let's also remember people's reactions to this issue and not make the same mistake again. It would have been much easier to have made the standard more sane in the beginning than to make every mail-reading program program in the world know how to reformat the From: field, as was done here. Next time let's worry more about human parsers than machine parsers, whenever we ask them both to parse the same material.  Date: 17 November 1983 01:06-PST (Thursday) Sender: TLI @ USC-ECLB From: Tony Li To: Header-people @ mit-mc Cc: Wcwells @ berkeley Subject: Re: Precedence and Errors Reply-to: Tli @ Usc-Eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 Let me put up some ideas for you to kick around regarding 'Precedence:' and error handling. I'm trying to approach this as a top-down design problem, and so I'm trying to figure out what user services we should be providing within SMTP. So, for the user level, we could have: Precedence: Priority or Personal or Mailing-List or Bulk The semantics of all of these should be obvious. If not, then I obviously haven't done enough thinking about the keywords. I don't really like the keyword 'Precedence' but I don't have any better suggestions yet. I like the suggestion of 'CLAS' even less. I think that the mapping of these precedence levels onto the IP Precedence field is irrelevant. I get the idea that the precedence field in SMTP should be exclusively for the use of the mailers, and that the IP Precedence field is for dealing with packets in general. How this mapping occurs is up to the source mailer. As to error handling, I would like to see the error handling for a particular message be totally divorced from all other parameters of the message. This might result in something like: Error-messages-on : All-Errors or Fatal-Errors or No-Errors This is intended to provide a modicum of flexibility without being impossible to implement. Cheers, Tony ;-)  Date: 17 Nov 1983 10:43:58 PST From: POSTEL@USC-ISIF Subject: Concerns about Getting it Right Next Time To: header-people@MIT-MC All of you who are concerned about getting the mail specifications right the next time should be involved in the development of the international standards for computer mail. I think the leading candidate draft standard in the one prepared by a CCITT committee. Jim White at XEROX seems to be the key player in that work. There is already a very substantial document on this proposal and it is on the verge of the final phases of being declared a standard. --jon. -------  Date: 17 Nov 1983 11:00:48 PST From: POSTEL@USC-ISIF Subject: re: Concerns About Getting It Right Next Time To: header-people@MIT-MC The draft specification i have seen is called "CCITT Draft Recommendations on Message Handling" and dated June 1983. It was assembled by Ian Cunningham of BNR. --jon. -------  Date: Thu, 17 Nov 83 18:31 EST From: "Robert W. Kerns" Subject: re: Concerns About Getting It Right Next Time To: POSTEL@USC-ISIF.ARPA Cc: header-people@MC.ARPA In-reply-to: The message of 17 Nov 83 14:00-EST from POSTEL at USC-ISIF Message-ID: <831117183128.6.RWK@YUKON.SCRC.Symbolics> Date: 17 Nov 1983 11:00:48 PST From: POSTEL@USC-ISIF The draft specification i have seen is called "CCITT Draft Recommendations on Message Handling" and dated June 1983. It was assembled by Ian Cunningham of BNR. --jon. ------- How does one get a copy of this?  Date: 17 Nov 1983 17:02:17 PST From: POSTEL@USC-ISIF Subject: re: Getting It Right Next Time To: header-people@MIT-MC ; Accessing NICNAME server at SRI-NIC... White, James E. (Jim) (JEW) White@PARC-MAXC Xerox Corporation Systems Development Department 3333 Coyote Hill Road Palo Alto, California 94304 Phone: (415) 494-4760 @ ; Accessing NICNAME server at SRI-NIC... Cunningham, Ian (IC) CUNNINGHAM@BBNC Bell Northern Research, Ltd. P.O. Box 3511, Station C Ottawa, Ontario K1Y 4H7 CANADA Phone: (613) 596-4234 @ --jon. -------  Date: 17 Nov 1983 18:27:26 PST From: POSTEL@USC-ISIF Subject: re: Getting It Right Next Time To: header-people@MIT-MC Date: 17 Nov 83 17:58:58 PST (Thursday) From: White.PA@PARC-MAXC.ARPA Subject: CCITT Recommendations on Message Handling To: POSTEL@USC-ISIF.ARPA Jon, FYI, the final drafts of the eight CCITT Recommendations on message handling systems were completed at a meeting in Brighton which ended 4 November. A one-year approval process within CCITT has already begun, and the specifications will become standards in October 1984. Meanwhile, a number of implementations are already well along and will be communicating with one another before October. The documents are in reproduction now and will be available about 28 November. I am willing to make hardcopy sets available to interested parties who supply me with their mailing address via Arpanet mail. Regards. /Jim -------  Date: Fri, 18 Nov 83 00:39:41 PST From: Rich Wales To: Header-People@MIT-MC Subject: No periods in unquoted full names, eh? Well, I suppose the issue of whether RFC822 should be modified to allow periods in unquoted full names is now dead due to lack of sufficient demand that it be changed. Too bad, I say; hoorah, some others may say. I wonder now, though: Assuming that this is the way things are to be, how are we going to get all those places out there that generate full names with periods (but no quotes) to fall in line? In case no one's noticed, there seem to be quite a few such places. (For that matter, my own mailer omits the quotes -- though I expect I'll fix that in the next two or three weeks.) Even if there aren't any instances of outright rebellion (places which adamantly refuse to make the change on aesthetic or other grounds), I would bet -- if I were a betting person, which I'm not -- that lots of sites will simply not consider it worth the bother to change their mail- ers. This must seemingly result in one of the following things happen- ing at each site which wants to conform to the standard exactly: (1) Simply reject incoming mail that doesn't conform, with a nasty note telling the poor user to go lean on his local wizard to get his mail software up to spec. (2) Make life very difficult for local users who try to reply to mail from sites that don't conform. (3) Implement "permissive" header parsers that will understand and ac- cept periods in unquoted full names, following the old maxim of "be liberal in what you accept and conservative in what you send out". I think (hope) that most people will reject option 1 as not doing anyone any real good. Hopefully, most people will also consider option 2 too repressive and user-unfriendly as well. But on the other hand, if everyone implements #3, then what was the point in requiring the quotes in the first place? This is a dilemma we face every time a question like this comes up, and I don't propose to have a solution to it. Then, of course, once we get everyone's "From" lines in conformity with the standard, we'll have to start working on people's "Date" lines. Lots more messages go out with invalid "Date" lines than ever have full names with periods and no quotes. The biggest offending areas (how does YOUR mailer rate?) are: (1) Names of days and months spelled out in full (RFC822 demands that three-letter abbreviations be used exclusively). (2) "1983" as the year (RFC822 allows only 2-digit years). (3) Time of day as a four-digit number (RFC822 insists that there be a colon between the hour and the minute). (4) Hyphen before the time zone (RFC822 forbids this, though constructs like 09:34PST without the space are apparently legal -- see the com- ment about white space at the top of page 12). -- Rich  Date: 18 Nov 83 06:31:01 CST (Fri) From: solomon@wisc-crys (Marvin Solomon) Subject: Whats wrong with RFC 822 Message-Id: <8311181231.AA06747@wisc-crys.ARPA> Received: by wisc-crys.ARPA (3.327/3.7) id AA06747; 18 Nov 83 06:31:01 CST (Fri) To: Header-People@mit-mc I, for one, couldn't care less whether periods are allowed in full names, but I still hope we might learn something from this exercise. I think the REAL problem RFC 822 is too much freedom. As I understand the history, RFC 733 was created to try to bring some semblence of order to a collection of existing mail programs, and therefore had to allow a variety of syntaxes to keep everyone interested. RFC 822 was an attempt to "clean up" 733 with a minimum of changes. I'm sorry Dave Crocker didn't go further in cleaning. For example, there are altogether too many allowed formats for dates. As to address syntax, there are  Date: 18 Nov 83 08:05:45 CST (Fri) From: solomon@wisc-crys (Marvin Solomon) Subject: What's wrong with RFC 822 Message-Id: <8311181405.AA07117@wisc-crys.ARPA> Received: by wisc-crys.ARPA (3.327/3.7) id AA07117; 18 Nov 83 08:05:45 CST (Fri) To: header-people@mit-mc.ARPA I, for one, couldn't care less whether periods are allowed in full names, but I think that before dropping this issue, we should try to learn something from it. As I understand the history, RFC 733 was created to bring some order to an informal standard represented by a collection of existing mailers, and as such had to be rather permissive to keep everyone happy. RFC 822 was a modest attempt to clean up 733. I wish Dave Crocker had gone a bit further in cleaning up. For example, there are altogether too many allowed formats for date. As for addresses, the REAL problem (as I see it) is that there are too many ways of including what is essentially a comment. The syntax of an address is: mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec addr-spec = local-part "@" domain ; global address route-addr = "<" [route] addr-spec ">" Unfortunately, a phrase and a local-part are almost identical, so a top-down parser can't distinguish the two alternatives for mailbox. You don't have to be an expert in parsing theory to understand the problem. If you start to read a mailbox from left to right, you don't know whether you are reading the beginning of an addr-spec (which is a very important thing) or a phrase (which is essentially a comment) until you look unboundedly far to the right and see whether there is a "<" somewhere. The solution taken: Banish a whole host of special characters from phrases so that local-part and phrase can be treated the same way and a parser doesn't have to make any decisions until it sees whether there is a "<" or a "@". Folding the definitions a bit, we have mailbox = word ("." word)* "@" domain / word (word)* "<" stuff ">" This can be made LL(1) (the formal version of top-down-parsable) by rephasing it as mailbox = word mailbox-tail mailbox-tail = addr-spec-tail / route-addr-tail addr-spec-tail = "." word addr-spec tail / "@" domain route-addr-tail = word route-addr-tail / "<" stuff ">" A top-down parser has no problem deciding what to do since an addr-spec-tail must start with a "." or a "@", whereas a route-addr-tail must start with a word or a "<". One change suggested in this discussion group was to eliminate the distinction between phrase and local part altogether, giving mailbox = phrase-or-local-part mailbox-tail phrase-or-local-part = word phrase-or-local-part / "." phrase-or-local-part / EMPTY mailbox-tail = "@" domain / "<" stuff ">" That gets rid of the problem with periods, but still banishes the rest of "specials" from phrases and doesn't come to grips with the problem that people want spaces to be significant in phrases but not in local-parts. I can think of two other ways around the problem that have much to recommend them. One is to get rid of this funny kind of comment. Make the syntax mailbox = local-part "@" domain / "<" stuff ">" If you really want your full name somewhere, you can write From: (Alfred E. Neumann (the guy from MAD Magazine)) or even From: The only problem with this suggestion is that a phrase is a special kind of comment that is supposed to be left untouched by header mungers and kept bound to the following route-addr (although, so far as I can see, the spec doesn't really say that--it's more of a tradition). Besides, if people were willing to put parentheses around full names, they wouldn't be complaining about putting quotes around them. Another attractive alternative is to abolish the "simple" kind of address and always require angle-brackets: mailbox = phrase "<" stuff "> The big advantage of this proposal is that now phrase can contain any character except "<" . Most of the addresses people are sending around would be allowed as is. It would also allow things like To: Mike O'Dell, Mike O'Brien [and various other mikes &c] Unfortunately, some "traditional" addresses become illegal. The spector of "upward compatibility" (also known as the "the-sins-of-the- fathers-shall-be-visited-on-the-children-unto-the-seventh-generation" phenomenon) rears its ugly head. In the ideal world, a "mailbox" would be a property list, containing the domain, a local part, perhaps a full name, and perhaps the importance ("if you can't deliver to this guy, I won't be too upset") or other info that pertains to this address rather than the message as a whole. I won't even try to suggest a syntax. I think the NBS standard does an excellent job by abandoning the silly notion that the best syntax for machine processing and the best syntax for human processing are the same. One final gripe. It would be very nice if the protocol spec had a single, formal specification of syntax in a standard notation (such as regular expressions for lexical syntax and BNF for context-free syntax) instead of a mixture of BNF, regular expressions, ad-hoc notation, and vague confusing English discussions about linear-white-space and folding. As an exercise, try to determine from RFC 822 exactly where in the following line spaces may be added From:MarvinSolomon  Date: Friday, 18 November 1983 10:29:25-PST To: solomon@Wisc-crys (Marvin Solomon) Cc: header-people@Mit-mc.ARPA Subject: Re: What's wrong with RFC 822 In-Reply-To: Your message of 18 Nov 83 08:05:45 CST (Fri). <8311181405.AA07117@wisc-crys.ARPA> From: Brian Reid Right on, Marvin! My opinion is that what's really wrong with RFC822 is that people insist on treating it as a presentation standard and not a transmission standard. I don't think there is any hope for the current ARPAnet community getting this right; anybody who cares at all whether the message file proper contains From: "Joe Q. Schmoe" or From: Joe Q. Schmoe is just on a different planet than the one I live on; my mail reading program edits the headers before it shows them to me so that they look like whatever I want. Unfortunately, the syntax of 822 messages is so bizzarre that the mail-reader has a great deal of trouble parsing them for me before it displays them. This is a variation on the sins-of-the-fathers-shall-be-visited syndrome; back in the dark ages people used to read mail by printing out the mail file with a "type" command, and so much of RFC822 is still devoted to solving this non-problem of making the transmission form of the message look "pretty" enough that people can just print the thing directly rather than process it first. There is no longer any excuse for not having a mail reading program smart enough to do this right, but enough people have such dumb mail reading programs that this ghost lingers on. Brian  Date: 18 Nov 83 1430 PST From: Gerald Neufeld Return-Path: Subject: A CCITT MHS implementation Message-Id: 287:neufeld@ubc-vision Received: by ubc-vision.CRNET (3.327/3.14) id AA00775; 18 Nov 83 14:30:43 PST (Fri) To: Via: ubc; 18 Nov 83 15:33-PST A number of people here are working on a CCITT Message Handling System implementation. The system is currently being developed on 4.1bsd and 4.1c. The work is well underway. We currently have a working MTA (Message Transfer Agent) and UA (User Agent). The current system is based on the June spec mentioned by Jon. As soon as we get the final spec from Jim we will be updating the system based on the modifications made at Brighton. The system uses all the CCITT protocols in the ISO model. Including X.25, ISO transport class 0, Session (S.62) and the MHS protocols themselves. We have also built a gateway between these protocols and ARPA 822. Hence, messages can pass back and forth between our domain and CSNET/ARPA. Since CCITT is very open with the addressing structure we have adopted the ARPA address structure to facilitate traffic between our domain and CSNET, ARPA, UUCP etc. The hope is (although as yet not certain) that this system (called EAN) will be used to interconnect Canadian universities, colleges and research companies using Datapac (Canada's public X.25 net). - Gerry University of British Columbia Dept. of Computer Science  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA13979; Fri, 18 Nov 83 22:53:25 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA12756; Fri, 18 Nov 83 22:53:41 pst Date: Fri, 18 Nov 83 22:53:50 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311190653.AA00621@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA00621; Fri, 18 Nov 83 22:53:50 pst To: header-people@mit-mc Subject: Re: Errors-To Field From: wcwells@ucbopal.CC.Berkeley.ARPA (Bill Wells) Newsgroups: net.mail Subject: Re: Fix to Arpanet junk deluges (at gateway) Message-ID: <108@ucbopal.CC.Berkeley.ARPA> Date: Fri, 18-Nov-83 22:32:34 PST Posted: Fri Nov 18 22:32:34 1983 Organization: Univ. of Calif., Berkeley CA USA Lines: 6 My apologies to Dr. Jon Postel at the USC Information Science Institute. Twice in the same paragraph I miss-spelt his name. The correct spelling is POSTEL not POSTAL. Bill Wells, U.C. Berkeley  Received: by UCB-VAX.ARPA (4.21/4.15) id AA24237; Sat, 19 Nov 83 08:08:12 pst Date: 19 Nov 83 09:45:04 EST (Sat) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: Rudy Nedved on mail forwarding Message-Id: <8311191445.AA05064@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA05064; 19 Nov 83 09:45:04 EST (Sat) To: header-people@mit-mc.ARPA Cc: Rudy.Nedved@CMU-CS-A.ARPA Thanks for clearing up the misunderstanding, Rudy. I guess the point I wanted to make (in between the flames) was that I am opposed to a whole network (such as the ARPANET) making a network-wide policy decision that says they refuse to forward mail (even junk mail) when as a network they are technically able to do so. I think this decision should be left up to the individual sites, since it is those sites that incur the expense of forwarding. (Of course, security considerations on a network such as MILNET are another story, but even they can probalby forward mail if they wish to.) It seems that very few UUCP sites refuse to forward mail, in spite of the expense. Mark  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA06598; Sun, 20 Nov 83 02:08:33 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA29883; Sun, 20 Nov 83 02:08:47 pst Date: Sun, 20 Nov 83 02:08:53 pst From: wcwells%ucbopal.CC@Berkeley (Bill Wells) Message-Id: <8311201008.AA14441@ucbopal.CC.Berkeley.ARPA> Received: by ucbopal.CC.Berkeley.ARPA (4.11/4.8) id AA14441; Sun, 20 Nov 83 02:08:53 pst To: header-people@mit-mc Subject: Re: Precedence and Errors In reply to: ------------------------------------------------------------------ Date: 17 November 1983 01:06-PST (Thursday) Sender: TLI@USC-ECLB From: Tony Li To: Header-people@mit-mc Cc: Wcwells@BERKELEY Subject: Re: Precedence and Errors Reply-To: Tli @ Usc-Eclb ------------------------------------------------------------------ I do not think error handling should be based on the content or type of message. It would be better to let the sender specify the type of error handling desired. Looking at it from the top, down, I also think SMTP needs a command to pass many different types of transmission and message handling instructions. (My suggestion for doing this is at the end of this message.) Here are my comments and suggestions in detail: ------------------------------------------------------------------ Let me put up some ideas for you to kick around regarding 'Precedence:' and error handling. I'm trying to approach this as a top-down design problem, and so I'm trying to figure out what user services we should be providing within SMTP. So, for the user level, we could have: Precedence: Priority or Personal or Mailing-List or Bulk The semantics of all of these should be obvious. If not, then I obviously haven't done enough thinking about the keywords. ------------------------------------------------------------------ I think we should "unbundle" this. I see four separate issues here: a. Services provided to users, eg. (1) Local services for different types of messages: Narrative messages Proforma messages Data-pattern messages (2) Mail distribution services Mailing list distribution Network news services Computer bulletin board services b. Speed of service (1) Order of message handing based on Precedence independent of the content of the message or mail service requested. (2) Should large routine messages be held until network(s) are not heavily loaded? c. Error handling based on content or service requested (or the wider issue of Communication Service Actions) I think we are going to have to leave "Precedence" as it is defined by the US Govt. "Precedence" could then be used to handle host and network loading problems. It would also permit MINIMIZE to be applied to mail services on the MILNET. (MINIMIZE is a procedure where users are restricted from sending routine messages when a communications network (or circuit) is overloaded or expected to be overloaded.) With regards to: Precedence: Priority or Personal or Mailing-List or Bulk I think the following would be more acceptable to DCA: Precedence Type of message ECP Operational messages FLASH IMMEDIATE PRIORITY Operational, administrative, and personal messages ROUTINE with non-government and government administrative/research networks and/or hosts limited to sending ROUTINE and PRIORITY messages. We could further break down ROUTINE and PRIORITY into: Precedence Size of message PRIORITY Small messages only ROUTINE Small messages Large messages (Bulk messages) but I do not think that speed of service should be based on the size of a message in addition to precedence in SMTP. However some local networks that are heavily loaded or have slow transmission channels may want to do this locally. (The Berknet, a non-packet network at UC Berkeley holds files larger than 200,000 characters for relay after midnight.) I have left out "mailing list" because it just complicates the issue and I have another solution for ensuring "mailing list" address errors go back to the mailing list maintainer. Mailing lists would not be a problem if the original message is quoted in the text of a new message (with a new RFC 822 heading) when it is forwarded to the list. Then errors would go back to the sender of the new message (the list maintainer), not the sender of the original message. That is to say, mailing list distribution should be an user agent service, not a mail transport agent service. ------------------------------------------------------------------ I don't really like the keyword 'Precedence' but I don't have any better suggestions yet. I like the suggestion of 'CLAS' even less. ------------------------------------------------------------------ I agree with you that Precedence and CLAS are not good choses. Is "Message Content" the term you want? ------------------------------------------------------------------ I think that the mapping of these precedence levels onto the IP Precedence field is irrelevant. I get the idea that the precedence field in SMTP should be exclusively for the use of the mailers, and that the IP Precedence field is for dealing with packets in general. How this mapping occurs is up to the source mailer. ------------------------------------------------------------------ If they are exclusive, how does a user request a higher speed of service? Are you saying SMTP should have only one precedence? I think that would defeat the purpose of the Precedence system. Do you expect a mail program at the user level to pass the precedence directly to the packet level? I don't (maybe for a single user system, but not multi-user systems). It is more likely that the user level program will be putting messages on a SMTP input spool so that the SMTP mail agent program can handle them in turn. ---- Maybe I am miss-reading you here. Are you saying we don't need a precedence system at the mail transport level. There are several reasons why I think we should, the most importantant being improved speed of service for high precedence messages when there are heavy message traffic loads. ------------------------------------------------------------------ As to error handling, I would like to see the error handling for a particular message be totally divorced from all other parameters of the message. This might result in something like: Error-messages-on : All-Errors or Fatal-Errors or No-Errors This is intended to provide a modicum of flexibility without being impossible to implement. ------------------------------------------------------------------ Let's make it more flexibility and let the sender specify if error messages are desired. That is simple compared to trying to support different levels of error handling based on the content or size of a message. Now, that brings up the problem of not having a generalized procedure in SMTP for passing transmission instructions or message handling instructions. Transmission instructions are communication instructions or advisory information that are of concern to relaying mail transport agents and may or may not be passed on to the user agent recipient of the message (cf. format line 4 of a military message). Message handling instructions are communication instructions or advisory information that are passed on to the user agent (cf. format line 5 of a military message). Here are some examples of transmission instructions and message handling instructions that are used with military message: This message is a suspected duplicate. Do not forward this message on non-cryptographic-protected circuits. This message is being retransmitted in response to your request for retransmission. This high precedence message was received garbled. A good copy has been requested and will be forwarded when received. This is a book message. Other addresses may be omitted from heading when relaying this message to another network. Cancel this message at _____. (You can stop attempting to relay this message after _____.) There are several hundred operating signals that may be used with military messages as abbreviations for communication instructions and advisories. I suspect that MILNET users are going to want to have many of them supported by, or at least passed on by SMTP. Rather that coming up with a separate SMTP command for each, let's define a single command, eg. INST Then define the common set of INST "strings" (and appropriate responses) that are required or optional for SMTP. Other "strings" should be permitted and passed on to the recipient of the message unchanged by relaying SMTP mail transport agents. For MILNET, I think we will need to define a PREC command for Precedence (as defined by the US Govt.) and CLAS for information security classification (as defined by the US Govt.). But those are issues that should be discussed separately. Comments? Bill Wells, U.C. Berkeley wcwells@Berkeley.ARPA  Date: Mon, 21 Nov 83 13:35:52 EST From: Ron Natalie To: Mark Horton cc: header-people@mit-mc.arpa, Rudy.Nedved@cmu-cs-a.arpa Subject: Re: Rudy Nedved on mail forwarding Let me point out, that despite what ARPANET (and MILNET) has become, they enjoy some operating benefits that are legally unavailable to commercial telecommunications and computer services. This is THE major reason for the anti-commercial restriction on these nets for it has always been stated in the first few lines of every ARPANet policy statement that the net is not to be used to compete with comparable commercial service. Second policy is that the network must be used solely for the conduct of or in support of official U.S. Government business. This is a wide area. All the discussions about things like Apple computers are in support of the US Gov. because (unfortunately maybe?) the government has bought a lot of Apple computers. DCA has left it up to the host administrators at each site to protect the network with "adequate" access control procedures. In this case you are right, let the host administrators determine what level of interaction he wants to support, but it is not just a question of what money he is paying for his network service. -Ron  Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15) id AA00164; Fri, 25 Nov 83 18:58:08 pst Received: from ucbtopaz.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA (4.11/4.8) id AA12978; Fri, 25 Nov 83 18:58:48 pst Date: Fri, 25 Nov 83 18:58:46 pst From: usenet%ucbtopaz.CC@Berkeley (Users' Network) Message-Id: <8311260258.AA00669@ucbtopaz.CC.Berkeley.ARPA> Received: by ucbtopaz.CC.Berkeley.ARPA (4.11/4.8) id AA00669; Fri, 25 Nov 83 18:58:46 pst To: header-people@mit-mc Subject: UUCP Net Information Cc: consult%ucbtopaz.CC@Berkeley, wcwells%ucbtopaz.CC@Berkeley It looks like a few people in UUCP net land are trying to make order out of chaos. The following from the USENET news group "net.mail" is forwarded for information. Path: decvax!harpo!floyd!clyde!ihnp4!inuxc!pur-ee!uiucdcs! parsec!kolstad From: kolstad@parsec.UUCP Newsgroups: net.mail Subject: High Quality Routing Database - (nf) Message-ID: <4076@uiucdcs.UUCP> Date: Tue, 22-Nov-83 19:45:54 PST Article-I.D.: uiucdcs.4076 Posted: Tue Nov 22 19:45:54 1983 Lines: 25 #N:parsec:37900002:000:1051 parsec!kolstad Nov 22 14:35:00 1983 Some of us are making the first big pass on our project to collect accurate routing and site information on the 1600+ sites connected by the UUCP network (which includes but is not limited to USENET, the 650+ news network). Within the month, all site directors (or root at sites with unknown-to-us site directors) will receive a mechanically generated form letter with a cybernetic plea for information. Response is entirely voluntary. An accurate database will allow routers to make reasonable decisions about sending mail and other goodies. The current plan includes myself (parsec!kolstad) and Scott Bradner (wjh12!sob) who will be editing the returned form letters into the database. This database will then (with high probability) be handed off to the network database support group for the infinite time consuming job of maintenance. The information you recieve for editing will include everything our database currently knows about your site. We hope everyone will benefit by any data you wish to disclose. Thanks in advance... Rob  Date: Tue, 29 Nov 83 7:58:15 EST From: R. Bruce Natalie (CTAB) To: postel@usc-isif cc: header-people@mit-mc, postmaster@hi-multics Subject: MULTICS MAIL MESSAGES Once again I find 72 failed mail messages from some cryptic user in MULTICS land and once more I get 72 more unidentified flying letters. Forwarded message number one is the failed mail message from MULTICS. Note the non-compliance with RFC822 as there is no destination line (in the form of TO, CC, or BCC) and no date. Note also the obsolete "at" in the from line. Other multics sites not on the ARPANET directly also place illegal host names in their from lines. The message is sketchy to say the least ("unable to deliver mail") and it may be amusing to discover that the letter was sent to "EATON.HFED@ HI-MULTICS" which is not easily ascertained by the misplaced "TO" line. The second forwarded message is a copy of the original letter reflected back along the return path to the sender. Note that there is no indication in that letter as to why it is being delivered to the user. The RECEIVED lines at the top are the only indication as to what is going on. It takes carefull inspection of these letters to figure out where they are coming from. I feel while this is perhaps not an explicitly prohibitted action, it is not a good idea. I have communicated with the Multics sites several times with respect to these problems but nothing has happened. Looking for a solution... -Ron ----- Forwarded message # 1: Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 29 Nov 83 6:57 EST From: Network_Server.Daemon at HI-MULTICS.ARPA Subject: Unable to deliver mail from info-micro-request@BRL-VGR.ARPA@BRL-VGR Message will be returned under separate cover. To: >udd>HFED>Eaton>Eaton.mbx at HI-MULTICS.ARPA: ----- Forwarded message # 2: Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 29 Nov 83 6:57 EST Received: from BRL-VGR by HI-MULTICS.ARPA TCP; 29-Nov-1983 05:57:45-cst Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 6:09 EST Received: From Sri-Unix.ARPA by BRL via smtp; 29 Nov 83 4:36 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Nov 83 1:10-PST Date: 27 Nov 83 15:47:17-PST (Sun) To: info-micro@brl From: decvax!ittvax!dcdwest!sdcsvax!sdccsu3!brian@ucb-vax Subject: Re: ss vice ds disks Article-I.D.: sdccsu3.1327 In-Reply-To: Article <13926@sri-arpa.UUCP> The reason the index hole is in a different place for SS and DS 8" disks is so that the drive hardware can report to the controller whether there is a single sided or double sided disk in the drive. Since most if not all of the popular 8" computers retain compatability with IBM 3740 format, this can assist the disk controller software in making a more intelligent decision. Some cp/m bios don't even ask what kind of a disk is in the drive - the make the proper settings based on an identity sector and the single/double hardware indication (Jade DD is an example of this). Sure is convenient! -- -Brian Kantor, UC San Diego {decvax,ucbvax} !sdcsvax!sdccsu3!brian Kantor@Nosc ----- End of forwarded messages  Date: 29 November 1983 09:30 cst From: RLee.SysAdmin at HI-MULTICS Subject: Re: MULTICS MAIL MESSAGES To: R. Bruce Natalie (CTAB) cc: postel at USC-ISIF, header-people at MIT-MC In-Reply-To: Message of 29 November 1983 08:12 cst from R. Bruce Natalie The problem is known to the Multics developers and will be corrected in the next release. Until I receive that release, there is not a lot I can do about the problem. --Randy Lee (Liaison/Postmaster@HI-Multics.ARPA)  Date: Tuesday, 29 November 1983 15:16 est From: Kovalcik@MIT-MULTICS.ARPA (Rick Kovalcik) Subject: Re: MULTICS MAIL MESSAGES To: R. Bruce Natalie (CTAB) cc: postel@USC-ISIF.ARPA, header-people@MIT-MC.ARPA, postmaster@HI-MULTICS.ARPA, Kovalcik@MIT-MULTICS.ARPA In-Reply-To: Message of 29 November 1983 07:58 est from "R. Bruce Natalie" Message-ID: <831129201627.544190@MIT-MULTICS.ARPA> Ron, I am getting really tired of this. In a piece of mail sent 10/26/83 to you and a couple of other people I said: Various mailers behave in different ways. The Multics mailer currently returns failed mail in two parts. The BRL mailer mungs headers. I find the later much more objectionable. As soon as CISL comes back on the ARPANET you will see that the CISL mailer is now returning failed mail in one piece ((and in valid RFC822 format. I forgot to mention that at the time. By now this has all happened.)) Other Multics mailers will probably pick ((it)) up eventually. Now if the BRL mailer was only made to work I would be happy. (( )) indicate comments by me today, 11/29/83. As the above demonstrates (I will forward the complete mail if anyone cares), you have been told that we are fixing the problem (two messages returned) even though it is a matter of taste. I neglected to mention that we were fixing the format of the message at the time. If you really cared, you could have sent me another message back asking what we were doing about the format. Or you could have asked the various sites when they would be installing the new mailer. You did not reply. This leads me to believe that you are more interested in causing trouble than fixing problems. Please start acting in a responsible manner and get off of this out-to-get-Multics kick. It is really annoying and a waste of our time. -Rick Kovalcik, Honeywell, Cambridge, MA, Kovalcik -at MIT-Multics, 617-492-9300, Liaison CISL-SERVICE-MULTICS, part of Postmaster CISL-SERVICE-MULTICS, HIS-PHOENIX-MULTICS, HIS-BILLERICA-MULTICS  Date: Wed, 30 Nov 83 15:32:37 EST From: Ron Natalie To: Rick Kovalcik cc: Header-People@mit-mc Subject: Re: MULTICS MAIL MESSAGES I sorry if Rick was offended, but it has been a while since the bugs were promissed to be fixed and they are still happening. I also have been informing individual users when illegal formatted messages have been coming out and I believe I have also been notifying the corresponding postmasters. I am content to wait for the new version but you'll have to excuse my impatient when my mail reader explodes with 72 illegally formatted messages (it really is a pain). With respect to BRL's mailer (which is MMDF), the only thing it is really guilty of is getting confused by illegal addresses. I'm not going to argue the virtues, but am just describing the way it is for the other recipients of the message as Rick made a passing shot about it. Since the mailer is multichannel (the is the first M in MMDF) it can receive mail from a number of paths (SMTP, PHONENET, UUCP, and others to humerous to mention). It makes the rather bad assumption when relaying a message back out on the arpanet that if a letter was received at BRL with a illegal arpanet address it must be from some channel that BRL knows how to talk to. It therefore translates FOO@UNKNOWN-HOST to FOO%UNKNOWN-HOST@BRL. Works most of the time but really gets things messed up if we didn't know how to talk to UNKNOWN-HOST at all. Remember, the only think we changed in the headers were the FROM lines when they illegal to begin with. The mailer felt a moral obligation not to retransmit illegal addresses so it made them legal (yes, but incorrect). Hopefully this whole problem will go away when DOMAINS get nailed down and people like the MULTICS community, the UUCP Community, the BRL community, etc...will have defined methods of answering inter-community mail. I have nothing against MULTICS, we've always stolen some great ideas for our other operating systems from there. -Ron  Date: Wed, 30 Nov 83 16:35:41 EST From: Ron Natalie To: header-people@mit-mc Subject: TWO mail points to consider. I have two problems that have been mentioned before on this list sporadically, but would like to hear about again and possibly see some proposals for RFC's or ideas to be incorporated into an RFC on crossnetwork mail relaying. 1. When a header is recieved that is in illegal format (according to 822) but deliverable to another site (as the relay can determine who it is addressed to despite the noncompliance with 822), should the relaying host attempt to correct it to make it legal? The other options is to just forwarded the letter verbatim or to add additional header lines to help ease problems with processing the illegal headers. Or do your sites just drop these letters? (FORMAT CONVERSION) 2. Do relaying sites have an obligation to transform the addresses in a header when crossing mail systems boundries to those that are legal on the destination network? For example, should: FROM: MANNY@BARFNET-HOST TO: MOE@APRA-HOST relayed through the host BARF-ARPA be changed to something like: FROM: MANNY%BARFNET-HOST@BARF-ARPA TO: MOE@ARPA-HOST Or should it just hope that if the user really wanted to get a response from MOE that he either did his from line in ARPANET relative terms or MOE is smart enough to know how to route to BARFNET-HOST. -Ron  Date: Sun 4 Dec 83 20:24:51-EST From: Greg Skinner Subject: where is btl To: header-people@MIT-MC.ARPA Which UUCP host do you arrive at when you send mail to .btl@csnet-relay? (in other words, which uucp node is btl?) --greg ...decvax!genrad!mit-eddie!gds (uucp) gds@mit-xx (arpa) -------  Date: 8 Dec 1983 15:22-EST Sender: MOOERS@BBNA Subject: The groupname "NAME: ;" From: MOOERS@BBNA To: header-people@MIT-MC Cc: DODDS%SCRC-TENEX@MIT-MC, BILLW@SRI-CSL Cc: Sarvela@SRI-KL, Mooers@BBNA Message-ID: <[BBNA] 8-Dec-83 15:22:38.MOOERS> Messages from some groups -- the FORTH interest group is an example -- have been appearing with a groupname of the form: To: Name: ; On pages 26 and 44, RFC 822 specifies the syntax for "group" as group = phrase ":" [#mailbox] ";" and on page 31, RFC 822 gives the example name:; The Hermes message system can handle "name:;" with no problems, but cannot select on "name: ;". With the clear documentation in RFC 822, we did not anticipate that the standard would be interpreted to produce such a string, with a space between the ":" and ";". May we respectfully suggest that whoever is producing those groupnames modify them to conform to "name:;" ? Thank you for your help. ---Charlotte Mooers Hermes staff Bolt Beranek and Newman, Inc.  Date: 08 Dec 83 18:59:06 PST (Thu) From: Marshall Rose Return-Path: Subject: Re: The groupname "NAME: ;" Message-Id: <267.439786746@uci-750a> To: MOOERS@Bbna Cc: header-people@Mit-Mc, DODDS%SCRC-TENEX@Mit-Mc, BILLW@Sri-Csl, Sarvela@Sri-Kl In-Reply-To: Your message of 8 Dec 1983 15:22-EST. <[BBNA] 8-Dec-83 15:22:38.MOOERS> Via: UCI; 8 Dec 83 23:12-PST Well, since UCI is such an offending site, I should respond: Perhaps I've mis-read the 822 spec, but it doesn't say that name: ; is illegal, quite the contrary. At several points in the standard (e.g., "3.4.2 WHITE SPACE") the use of white space is discussed. With the exception of forbidding space between "."/"@" and a in a structured component, the 822 spec does not prohibit the practice of using white space between the ":" and ";". The problem with your interpretation of group = phrase ":" [#mailbox] ";" meaning NO SPACE BETWEEN ":" and ";" is that, one should also interpret orig-date = "Date" ":" date-time as meaning NO SPACE BETWEEN the ":" and the date-time string. I think we can agree that this isn't what the standard means. [If it is, we are all it a LOT of trouble... :-)] /mtr