Date: Fri 9 Nov 84 04:28:46-EST From: Greg Skinner Subject: Re: mail address parsing To: header-people@MIT-MC.ARPA In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Wed 24 Oct 84 02:24:44-EDT The reason why you can't use () for specifying precedence in routing, is, I believe, that () are used for comments in an RFC822 header. At least, in the local Chaosnet mailers it is. However, user-specified precedence seems to me to be a good idea, instead of having all these path servers all over the place. Path servers which do relays only to hosts they know about are fine, but path servers which carry the full UUCP database can get out of whack, causing strange things to happen. From my UUCP experience at work (houxm), a number of machines have different ideas of who they talk to, and how they talk to who they talk to. As an aside, what's the socket number for the UUCP path server? (Mail only, please, and you can send it to ihnp4!houxm!gregbo if you want.) --gregbo -------  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647192586063412@MIT-MULTICS.ARPA>; 19 Nov 1984 14:16:26 est Date: 19 Nov 84 18:00 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people Subject: Long names Message-ID: <79307@QZCOM> A message which was sent out from us, contained in the TO field the following text: TO: This message was obviously truncated by some relayer on the way, so that some characters at the end were deleted including the final >, and we got an error message back saying that some system got an RFC822 header with unbalanced <>-s. Should we stop using such long names? We could alternatively use names of the format: TO: Message Group at BRL mailing list Advantage: Would not get those truncation problems Disadvantage: The text within <> says nothing on what it is Note: "Message Group at BRL mailing list" is our local conference which receives entries sent to us from the MSGGROUP @ BRL-AOS.ARPA.  Delivery-Date: 19 Nov 84 10:47 EST Delivery-By: Network_Server.Daemon@MIT-MULTICS.ARPA (ihnp4!gatech!mmdf@Berkeley@UCB-V) Date: Mon, 19 Nov 84 08:04 EST From: ihnp4!gatech!mmdf@UCB-VAX.ARPA Subject: Illegal Address (gitpry!robert) To: Schauble.PDO1@MIT-MULTICS.ARPA cc: postmaster@UCB-VAX.ARPA Message-ID: <8411191549.AA24629@UCB-VAX.ARPA> Resent-Date: 20 Nov 84 00:49 EST Resent-From: Paul Schauble Resent-To: Header-People@MIT-MC.ARPA Resent-Comment: I just got this message back from an attempt to mail to a usenet address through Berkeley. Has this stopped working? If not, could someone please explain what's happening here? -- Thanks, Paul Resent-Message-ID: <841120054958.570873@MIT-MULTICS.ARPA> Your letter has been intercepted trying to access a restricted access host (e.g. an ARPANET host). A copy of your letter has been sent to the system administrators. The text of your letter follows. --------------- Returned Mail Follows -------------- >From ucbvax!Schauble.PDO1@MIT-MULTICS.ARPA Sun Nov 18 05:38:49 1984 remote from ihnp4 Received: by ihnp4.ATT.UUCP; id AA23151; 18 Nov 84 05:38:49 CST (Sun) Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA07391; Fri, 16 Nov 84 17:10:47 pst Date: Fri, 16 Nov 84 20:02 EST From: Paul Schauble Subject: Your conversion of ogre to printf To: ihnp4!gatech!gitpry!robert@BERKELEY Message-Id: <841117010220.841626@MIT-MULTICS.ARPA> Would you please post the result to net.sources when finished? Thanks, Paul --------------- End of Returned Mail ---------------  Date: 20 Nov 1984 18:38:59 PST From: POSTEL@USC-ISIF.ARPA Subject: re: long names To: header-people@MIT-MC.ARPA Jacob Palme: It probably does not matter so much how many characters are inside the angle brackets (<>), but rather the total length of the line. I would suggest you both use a shorter name inside the angle brackets and a shorter line. In any case the truncation is a bug in some program, it would be nice if that program could be identified and then fixed. --jon. -------  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647709795468488@MIT-MULTICS.ARPA>; 25 Nov 1984 13:56:35 est Date: 25 Nov 84 16:21 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA To: MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA Bcc: Announcement_conferences%QZCOM.MAILNET@MIT-MULTICS.ARPA, MHS_subsetting_group_%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , msggroup@BRL-AOS.ARPA, mailgroup@UCL-CS..ARPA, Mailnet_implementation_and_JNT-MAIL%QZCOM.MAILNET@MIT-MULTICS.ARPA, External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: MHS (X.400) implementation Message-ID: <80073@QZCOM> A new QZCOM conference with the name "MHS (X.400) implementation" has been started. The conference will to mail networks have the name "MHS_(X.400)_implemenetation", in most cases postfixed by "%QZCOM@MIT-MULTICS.ARPA". The conference/mailing list is open for anyone who is seriously interested in implementing the CCITT X.400 (MHS) message handling protocols or gateways to these protocols. In the conference/mailing list we can for example discuss how to understand and interpret the MHS recommendation, how to map existing mail system and mail network features onto the MHS structure etc. To join the conference do as follows: QZCOM users: Use the "member" command. Users at other sites: Write a letter to me personally, "Jacob_Palme_QZ %QZCOM.MAILNET@MIT-MULTICS.ARPA", do NOT write to the conference itself.  Received: from Cabernet.MS by ArpaGateway.ms ; 24 NOV 84 15:41:14 PST Date: 24 Nov 84 15:41:04 PST From: Murray.pa@XEROX.ARPA Subject: Re: Long names In-reply-to: <79307@QZCOM> To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Murray.pa@XEROX.ARPA, header-people Why did you put <>s around that name? I thought that format was intended for source routing, and I don't see any interesting routing in your example. I think the spec requires a noise word is between the "To:" and the "<".  Received: from Cabernet.MS by ArpaGateway.ms ; 24 NOV 84 15:43:02 PST Date: 24 Nov 84 15:42:56 PST From: Murray.pa@XEROX.ARPA Subject: Re: Long names In-reply-to: <79307@QZCOM> To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Murray.pa@XEROX.ARPA, header-people Grapevine (our internal mail system) has a limit of 64 characters. If I counted right, your example is exactly 64 characters long. This limit is in the envelope, not the header. I have a mild preference for doing whatever is easy/reasonable to avoid long names. Your C153 suggestion looks fine. Our Arpa-Grapevine mail gateway will correctly deliver messages with long names. If the return-path is too long, it substitues something legal as it passes the message to Grapevine. The only problem is that our users won't be able to reply to the message.  Received: from Aurora.ms by ArpaGateway.ms ; 25 NOV 84 22:57:07 PST From: DonWinter.pasa@XEROX.ARPA Date: 26 Nov 84 1:56:43 EST Subject: Re: Long names In-reply-to: Murray.pa's message of 24 Nov 84 15:42:56 PST To: Murray.pa@XEROX.ARPA cc: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Interestingly enough, since Lily (the Grapevine's Terminal Service) uses the Return-Path in the Table of Contents (I don't know why), I received Jacob's original message with the Sender listed as "Name-too-Long"!!! Don  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647976203558355@MIT-MULTICS.ARPA>; 28 Nov 1984 15:56:43 est Date: 28 Nov 84 12:31 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: header-people Subject: Re: Long names Message-ID: <80597@QZCOM> In-Reply-To: <80334@QZCOM> The ideal way if your local net or system cannot handle long names, would of course be to create a data base of the long names versus the abbreviated names you use locally, so that names can be translated to the long format again externally. I have done it that way in the COM-RFC-mail interface.  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA14458; Sun, 9 Dec 84 12:17:15 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.30) id AA02180; Sun, 9 Dec 84 12:18:36 pst Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.30) id AA01056; Sun, 9 Dec 84 12:18:11 pst Date: Sun, 9 Dec 84 12:18:11 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8412092018.AA01056@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: New "Top-name" Domain Names Does anyone know yet what the initial set of new top-name domains will be? What happens 15 Dec 84? When do the host/domain name tables need to be changed? Bill  Date: 13 Dec 1984 15:34-PST Sender: WESTINE@USC-ISIF.ARPA Subject: New "Top-name" Domain Names From: Postel@isif To: Header-people@MIT-MC.ARPA Message-ID: <[USC-ISIF.ARPA]13-Dec-84 15:34:52.WESTINE> Bill Wells et al: Please read RFCs, 920 and 921 very carefully. The new top-level domain names are discussed there. The procedure for registering new names is also described. --jon.  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2649676128111791@MIT-MULTICS.ARPA>; 18 Dec 1984 08:08:48 est Date: 05 Dec 84 01:13 +0100 From: -KPJ_Jaakkola_QZ_private%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: -KPJ_Jaakkola_QZ_private%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA, Postel@USC-ISIF Subject: re: long names Message-ID: <82112@QZCOM> In-Reply-To: <79583@QZCOM> Could the problem maybe be that some UNIX mail handling programs truncate lines to 40 characters?  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA01965; Mon, 17 Dec 84 18:57:32 pst Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.31) id AA16155; Mon, 17 Dec 84 18:57:23 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.19/4.31) id AA20909; Mon, 17 Dec 84 18:56:49 pst Message-Id: <8412180256.AA20909@ucbpopuli.CC.Berkeley.ARPA> Date: 17 December 84 21:56 EST From: RMXJARTJ%CORNELLA.BITNET@Berkeley To: HEADER-PEOPLE@MIT-MC Subject: Request to add user Hello, Could you please add my userid to "THE LIST?" Thank you, Gligor Tashkovich (But everyone calls me "G") RMXJARTJ @ CORNELLA.BITNET  Date: 19-Dec-84 12:42 PST From: Kirk Kelley Subject: Body line length To: HEADER-PEOPLE@MIT-MC Message-ID: Our message converter to RFC 822 folds everything in the body at 80 columns as a default (our paragraphs normally have no CRLFs in them). We use 80 columns instead of something shorter because our customers send tables formatted for 80 characters. We would prefer not placing ANY line breaks in the paragraphs of the body. [We would also prefer not getting ANY line breaks in paragrahs FROM the Internet, but thats another story.] This would mean we would send some "lines" in the body thousands of characters long. Are people going to suffer more from this as the default or from forcing line breaks at 80 or 72 or 60 or ???? Assuming SMTP knows how to deal with long lines, will mailers and mail readers break, or is this just a display aesthetics problem? We aim to please. -- kirk  Date: 20 Dec 84 0558 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Kirk Kelley Subject: Re: Body line length CC: HEADER-PEOPLE@MIT-MC.ARPA In-Reply-To: Message-Id: <20Dec84.055825.EN0C@CMU-CS-A.ARPA> Kirk, I have had system give me huge lines, specifing a bad recipient address and then not accept what they sent me. I have system that get weird error failures....and if I look it turns out one of our users is sending a message with long lines...he or she generated because the terminal they have did auto-crlf...so they typed until they were done with the message. It sounds like you are hitting what Xerox hit along time ago. I would suggest that you either avoid sending out long lines or have a table of sites that "work" and wrap for all the other ones....I doubt you will get mail to work for more then 55% of the hosts....It is just to easy to have a static character buffer of a 1000 characters. I know our CMU Unix code does that (the subtle thing is it does not fail...it just adds new lines). Good luck, -Rudy  Received: from Salvador.ms by ArpaGateway.ms ; 20 DEC 84 04:35:03 PST Date: 20 Dec 84 04:34:55 PST From: Murray.pa@XEROX.ARPA Subject: Names with spaces To: Header-People@MIT-MC.ARPA Cc: Murray.pa@XEROX.ARPA We are in the final stages of bringing up a mail gateway between Grapevine, our research mail system, with names like "Murray.PA" and our product mail system with names like "Hallam G. Murray:OSBU North". Note the nasty things like periods and spaces in the new names. Does anybody out there have a system that will get in serious trouble if we send you a message with a return-path containing spaces? By "serious" I mean crash your system or break your mail server rather than generating obscure error messages when somebody tries to reply to a message with an unparsable header. Do I need to drop everything and hack our mail gateway to prevent names with spaces from escaping into the internet? A few people have been testing things for the past month. So far, nobody has complained to me that their new name was causing unreasonable problems, like preventing them from exchanging mail with somebody else. I am expecting to encounter some rough edges. I won't get upset if a few users can't exchange mail with a few obscure sites, but I will have to do something if too many sites can't live with our new names. Assuming that our names contain spaces, will you be able to send mail to us? Assuming that we get the quotes right and such, will you be able to receive mail from us? Will the corner of your mail processing software that automatically generates headers to help you answer a message still work? Should I send a test case? Anybody want a summary of the answers I get back? Do you know of any other pitfalls in this area that I might have overlooked?  Date: 20 Dec 84 1323 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Murray.pa@XEROX.ARPA Subject: Re: Names with spaces CC: Header-People@MIT-MC.ARPA In-Reply-To: "Murray.pa@XEROX.ARPA's message of 20 Dec 84 07:34-EST" Message-Id: <20Dec84.132343.EN0C@CMU-CS-A.ARPA> You should not have any problems with any CMU sites that are in the NIC host table with double quoted names that have spaces...However don't expect the single character slash quoting mechanism to work. I would be interested in what sites/mailers you have problems with. Many CMU users still send out names with spaces...It has been a while since I have heard complaints. Good luck...I hope you get 90% or better. -Rudy  Date: Thu 20 Dec 84 11:29:58-MST From: William G. Martin Subject: Re: Body line length To: KIRK.TYM@OFFICE-2.ARPA cc: HEADER-PEOPLE@MIT-MC.ARPA, WMartin@SIMTEL20.ARPA In-Reply-To: Message from "Kirk Kelley " of Wed 19 Dec 84 12:42:00-MST Ugh! I have long wished for some sort of automatic filter on both mail traffic and USENET postings that would automatically break any long lines at 80 cols. Such long-lined messages and items look OK on terminals that wrap the long line, and only give a clue to their bad nature by the fact that some words are broken or other formatting is damaged. But when they get sent to a printer, all of a sudden we discover that the middle of a many-paged output has to be edited out and reprinted through a folding filter because a batch of long lines printed merrily out to an infinite right margin. Yes, I know that I could put in automatic checks for such things, like piping all printer output through "fold" (under UNIX). I don't want to. The normal convention is 80 columns wide. Everything is set up to expect that. Most sources abide by that and generate suitably-formatted product. Why should everybody have to build in extra checks and processing to catch the few systems that generate long-lined output? When such special terminals and systems become commonplace, when there are clear advantages to having unformatted text blocks transmitted for formatted display at the receiving end, then it will be worth it for simpler systems to expect such and build in the traps and checks and fixes needed to view and process such text in an otherwise-80-column environment. That time has not yet arrived. Please make sure your output formatter breaks long-lined text into 80-column material before releasing it to the Internet. Will Martin Host Administrator, ALMSA-1 US Army Mat'l Command -------  Date: 20 Dec 1984 12:24 MST (Thu) Message-ID: From: "Frank J. Wancho" To: "William G. Martin" Cc: HEADER-PEOPLE@MIT-MC, KIRK.TYM@OFFICE-2 Subject: Body line length In-reply-to: Msg of 20 Dec 1984 11:29-MST from William G. Martin Will, As I, and perhaps others have pointed out already to Kirk, there are many brain-damaged terminals we have no choice in using that do an auto-wrap when anything appears in column 80. With a fill to 80, those lines with something in 80 will be followed by a single blank line. This appearance was surely not the format intended by the author. The alternative that such terminals offer is to shut that "feature" off and have all the overflow characters overwrite each other on column 80! Thus, I have pleaded for pre-wrapping at 79, which is exactly the width our people prefer for 12 pitch hardcopy. (For 10 pitch, well, that's another story.) (I also won't bring up the discussion rehashed many times on MSGGROUP about the "readability" of messages read on the standard CRT when filled to 70.) BTW, BABYL will refill the body of a message to the default 70 (optionally to any width) with a single keystroke...and is "undoable" in case the message contained specially formatted material that got garbled in the fill process. --Frank  Date: 20 December 1984 15:17-EST From: Christopher C. Stacy Subject: Body line length To: WMartin @ SIMTEL20 cc: HEADER-PEOPLE @ MIT-MC, KIRK.TYM @ OFFICE-2 If the limit were 72 columns wide then I could read my mail on punched cards. I could even read those obnoxiously long-lined messages which people compose on punched paper tape! On the other hand, printer widths are usually 120 or 132, so maybe the limit should be 120. Some VT100s are that wide too. An APPLE has 40 columns, so maybe that should be the common denomentator. While we are on the subject, perhaps we should limit the vertical length of messages too, since many people have 300 baud modems. Anyway, if wide terminals are not commonplace, then why are you receiving so many messages which don't fit on your screen? There are certainly many (commercially available) wide screen terminals at my site, and we regularly send messages which look much nicer when they are not scrunched down into 80 columns. A more basic point is that the specification for textual messages does not attempt to implicitly define what sorts of textually oriented devices may be used for composing or reading the mail. Your complaint is that your user interface is inadequate for communication with many other people who are operating under the same messaging protocol. Perhaps you should consider fixing this by changing or upgrading your mail reading software, rather than by imposing an arbitrary restriction on the rest of the world. The BABYL mail reader (an EMACS library), which has been around for years, has a single keystroke command which will instantly reformat the message on the screen to make the lines fit more nicely on the screen. It even has heuristics for not destroying the indentation of any included messages or program code. About half the time I read long messages on an 80 column screen, and BABYL's text reformation command works just fine. Chris  Date: Thu 20 Dec 84 13:32:22-MST From: William G. Martin Subject: Re: Body line length To: WANCHO@SIMTEL20.ARPA cc: HEADER-PEOPLE@MIT-MC.ARPA, KIRK.TYM@OFFICE-2.ARPA, WMartin@SIMTEL20.ARPA In-Reply-To: Message from ""Frank J. Wancho" " of Thu 20 Dec 84 12:24:00-MST Frank makes a good point; I used "80" in a rather generic sense in my comments -- consider everywhere I said "80" to really mean "79". My usual terminal (an ADM42) produces the "following-blank-line" glitch Frank described, so I am familiar with these ill effects. However, where I really suffer from long lines is on printed output, as I stated before. If I have to, I can live with extra blank lines on my screen; there's no recovery from having data printed on the platen. Will -------  Date: Thu 20 Dec 84 14:17:30-MST From: William G. Martin Subject: Re: Body line length To: CSTACY@MIT-MC.ARPA cc: HEADER-PEOPLE@MIT-MC.ARPA, KIRK.TYM@OFFICE-2.ARPA, WMartin@SIMTEL20.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Thu 20 Dec 84 13:17:00-MST Chris, The point is that we (at least at this end of the Internet) DON'T get "many" messages with over-80-column lines in them. (Or 79, as per the preceeding discussion!) If we got "many", it would be worth the effort to "change or upgrade" the mail software, though, if you would re-read my posting, you would discover that I was NOT discussing the mail-reading display; I had based my objection on the effect of dumping un-processed messages/postings to 80-column-wide printers. Because we don't get "many", we are talking about avoiding an occasional minor irritation. Because so few are now being sent, I believe that this 80/79-column convention is being adhered to already by the majority of sites and/or people. So the discussion is an attempt to avoid an INCREASE in this anomaly; I'm not asking everyone to change their methods or behavior; they are now doing what is right! Only a few long-lined postings or messages show up now, so few that I never mentioned it or expressed my desire to have those few eradicated until the original posting of this exchange threw open the prospect of a lot more of them suddenly appearing. We are in an environment now where some people have fancy bit-mapped displays in which they can send mail with Old English titles and various font sizes in the text, and include graphs, digitized images, and, for all I know, tastes and smells. Others are making do with TI 745 printing terminals. It is fine for those with the facilities to do so to interchange documents and mail with any and all of their special capabilities. When we speak of generically communicating with arbitrary addressee "x" in the Internet environment, however, we HAVE to go back to the lowest common denominator. That means straight text, minimal fanciness with formatting (avoid even character-^H-underscore!), and limit lines to 79 (a tip of the hat to Frank!) characters long. Once you have determined that you are communicating with specific individual "y", who has this and that capabilities in his equipment, THEN go ahead and ship him messages with twelve fonts, unbroken text blocks, and animation embedded in it. Until then, or when you are addressing the unknown capabilities of the world (as you are when sending to a mailing list or posting to a USENET newsgroup), keep it simplistic. As I tried to make obvious before, when the pendulum has swung so that the majority (or at least a lot of the highly-communicative) of the Internet folk have the facilities to interpret what sort of fancy machine this particular message came from, and then display it in the particular format it was intended to be viewed in, and also produce paper copies of it with better technologies than serial ASCII daisywheel printers or the equivalent, THEN lets throw away the the 79-column convention (remember that we are talking here only about a voluntary self-limitation!), because then we would be limiting ourselves severely for the sake of the poor or the cheap (individuals or organizations :-). I don't think that is yet the case. I don't see this sort of capability anywhere on the MILNET to any great extent (I actually don't know of any at all, but I'm sure there is SOME somewhere...); if you want to speed this up, mail your congresscritter a request to divert the funds from a couple of F-15's or the like to instead go to DoD workplace automation. (Though they'll probably just spend it on another batch of low-bidder terminals, which is the cause of all this fuss in the first place... :-) In the real world, Will Martin Host Administrator, ALMSA-1 -------  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2649882381394887@MIT-MULTICS.ARPA>; 20 Dec 1984 17:26:21 est Date: Thu, 20 Dec 84 11:45:54 EST From: Steve_Rothwell%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: KELLEY@OFFICE-2.ARPA, HEADER-PEOPLE@MIT-MC.ARPA Message-ID: <593610@UMich-MTS.Mailnet> Subject: Body line length Re: Message-ID: From: Kirk Kelley Kirk, Why do you reformat the body of the message at all? We present whatever you send to the recipient. If you send 1000 character lines that's what they see. Why not send it the way you want it seen and assume others have done the same?  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA11974; Thu, 20 Dec 84 18:43:09 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.31) id AA17066; Thu, 20 Dec 84 18:50:44 pst Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.31) id AA14990; Thu, 20 Dec 84 18:50:31 pst Date: Thu, 20 Dec 84 18:50:31 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8412210250.AA14990@ucbopal.CC.Berkeley.ARPA> To: Murray.pa@XEROX.ARPA Subject: Re: Names with spaces Cc: Header-People@mit-mc.ARPA I am not confident that quotes will make it through all Unix mail systems. If a csh shell is called to process a mail command at the command interpreter level the quotes may be lost unless action has been taken to prevent this lost. I suggest translating spaces to underlines going to Internet, and underlines to spaces going in reverse. This means you would not be allowed to have underline(s) in local grapevine address. This fix also allows local addresses with spaces to be sent via other (non-Internet) mail networks (eg. UUCP) which used space(s) as a delimiter between addresses. Bill Wells ucbvax!wcwells wcwells@Berkeley.ARPA  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA12510; Thu, 20 Dec 84 19:22:46 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.31) id AA17704; Thu, 20 Dec 84 19:30:25 pst Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.31) id AA15450; Thu, 20 Dec 84 19:30:15 pst Date: Thu, 20 Dec 84 19:30:15 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8412210330.AA15450@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: Re: Body line length AUTODIN (JANAP 128) limits: 72 max characters per line for narrative messages (for all those model 28 Teletypes still in military service) and 80 (ie. punched card) for data messages. I think there may also still be a 100 line limit. PS. Message header fields can be greater that 80 characters. Watch out for long from addresses in "Received:" header fields.  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2650562939819468@MIT-MULTICS.ARPA>; 28 Dec 1984 14:28:59 est Date: 25 Dec 84 14:23 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA Subject: Names with spaces Message-ID: <84081@QZCOM> In-Reply-To: <83786@QZCOM> COM also has spaces in the names of people. If this is nasty or not is something you can discuss. I think it is natural that my name is "Jacob Palme" and would regard names like "JPALME" or "P3" as unnatural and nasty. With the COM RFCMail interface, we began sending out our names as they were, with spaces in them, but then according to RFC821/822 with quotes on the names. This got us into many problems, since many systems could not handle such names. So now, we translate all spaces to underlines when sending out names. My name is thus sent as Jacob_Palme%QZCOM@MIT-MULTICS, and not as "Jacob Palme"%QZCOM@MIT-MULTICS. When getting a name from the network, we translate underlines into spaces before entering the names into the COM data base. This has worked fairly well, except for one person who complained she could not write to us because there was no way to generate underlines on the keyboard of her IBM PC. Is this really true of IBM PC-s?  Date: 31 Dec 1984 21:33:43 EST (Monday) From: Marshall Abrams Subject: Soliciting members for a computer services committee To: header-people@mit-mc, info-printers@mit-mc, info-rsts@mit-mc, info-terms@mit-mc, info-unix@brl, info-vax@sri-csl Cc: self:@mitre, abrams@mitre I am soliciting members for the IEEE Computer Society's Computer Services Advisory Committee (CSAC). The function of the committee is to advise the President and Governing Board on hardware, software, and services to support office operations, provide member services, and provide electronic mail services to members and officers. There are two items presently on the agenda which might interest you and would profit from your experience: (1) The PDP 11/44 in the East Coast office and the Microdata in the West Coast office are both approaching saturation. A suggestion being considered is to purchase additional 11s. This would permit utilization of existing software (which has proven satisfactory) and DECNet interconnection when necessary. Replacing these existing computers with VAXs has been suggested, but is currently not favored. People experienced with DEC products would be quite valuable. (2) The Computer Society provides an electronic mail service called CompMail+ to its officers and employees to conduct Society business and to members as an extra-cost benefit of membership. Quite favorable rates were obtained as a result of a competative procurement. This CompMail+ service as provided by Dialcom is in the process of being re-evaluated. The contract may be re-competed. There is a very strong interest in establishing a gateway between CompMail+, CSNet, and ARPANET. Several alternatives are under investigation. I hope to conduct as much committee business as possible via electronic mail, so physical location should not be too much of a problem. I think each of the two items discussed above will be handled by separate sub-committees. A person could belong to either or both. It is desirable, but not absolutely necessary, that volunteers be members of the Computer Society. Let me hear from you if you are interested. Marshall Abrams abrams@mitre.arpa 64:M.ABRAMS (on Dialcom) phone: 703/883-6938  Date: 2 Jan 1985 16:12:40 PST From: POSTEL@USC-ISIF.ARPA Subject: Domain Style Names To: Header-People@MIT-MC.ARPA Hi. We are getting ready to start using Domain Style Names. Please see RFCs 920 and 921 for the procedures and schedule. Anyone planing on using a new name should prepare an application as indicated in RFC 920 and send it to HOSTMASTER@SRI-NIC.ARPA on or after 15-Jan-85 (according to the schedule in RFC 921). New names may not be used until they are registered (you get a note back from Hostmaster saying it is ok), and the new name is listed in the data base of some domain name servers. --jon. -------  Date: 3 Jan 1985 16:44:47 PST From: POSTEL@USC-ISIF.ARPA Subject: What Domain For Me ? To: header-people@MIT-MC.ARPA What domain name should i choose? Suppose i am Fred Smith of Northern Oklahoma Technical University (known far and wide as "N.O. Tech"). Suppose that N.O. Tech is connected to the Internet world via CSNET. That is, suppose i have a little VAX running Berkeley 4.2 Unix as a "phone net" site of CSNET. That means that a user on a typical Internet host currently can send mail to me using the address: Fred%NO-TECH@CSNET-RELAY.ARPA Domain style names are coming. What should i do about it? In fact, i can get away with doing nothing. The current address will probably work ok for some time to come. And the CSNET management will almost certainly do someting about getting "CSNET" registered as a top-level or second-level domain (e.g., ".CSNET" or ".CSNET.EDU"). Let us assume that the CSNET management does get ".CSNET" registered as a top-level domain name. In that case, users at typical internet hosts would be able to send me messages using the address: Fred@NO-TECH.CSNET That looks like a great improvement! It is a lot shorter. It leaves out the business about a relay, and does not have any gratuitous mention of ARPA. It does somewhat imply that N.O. Tech is a member of (subservient to ?) CSNET. Let us take a minute to review (generally) what happens when an Internet host sends a message to the address "Fred@NO-TECH.CSNET". First, the sending host looks up an internet address for "NO-TECH.CSNET". It does this by asking a domain server about a mail address for "NO-TECH.CSNET". The domain server replies (approximately) "mail for '*.CSNET' should be sent to 'RELAY.CSNET' at '10.4.0.5'". Then the mail sending host opens an SMTP/TCP/IP connection to "RELAY.CSNET" and sends the mail to recipient "Fred@NO-TECH.CSNET". Notice that there is nothing wired in about names ending in ".CSNET" using the relay host. The lookup went through a perfectly general mapping in the server data base. If i decided that N.O. Tech was the important thing , and that the fact that electronic mail got to me via CSNET was a mere technicality, i might want to down play the CSNET affiliation (or hide it completely). I could do this by applying to the management of the Education domain to become "NO-TECH.EDU". If this were approved my mail address would be: Fred@NO-TECH.EDU The typical internet host would treat this in the same way as the previous case. First, the sending host looks up an internet address for "NO-TECH.EDU". It does this by asking a domain server about a mail address for "NO-TECH.EDU". The domain server replies (approximately) "mail for 'NO-TECH.EDU' should be sent to 'RELAY.CSNET' at '10.4.0.5'". Then the mail sending host opens an SMTP/TCP/IP connection to "RELAY.CSNET" and sends the mail to recipient "Fred@NO-TECH.EDU". If, as is typical of important universities, N.O. Tech is affiliated with several electronic mail systems (e.g., MAILNET, BITNET, CSNET, UUCP, even ARPA-Internet), it would be somewhat difficult to choose one of them to be my primary address. It will probably work for people to send me messages as "Fred@NO-TECH.BITNET" and "Fred@NO-TECH.MAILNET", etc (provided those are registered top-level domains). But, what should i put in as my "From:" address on mail i send out? What should i put on my business cards? The solution is "Fred@NO-TECH.EDU". This points out the advantage of using the domain style names as an administrative structure, independent of network topologies or protocol environments. --jon. -------  Received: from vax2.ucl-cs.ac.uk by 44a.Ucl-Cs.AC.UK with SMTP id a012554; 4 Jan 85 17:35 GMT To: POSTEL@usc-isif.arpa cc: header-people@mit-mc.arpa Subject: Re: What Domain For Me ? Phone: +44-1-387-7050 ext 773 In-reply-to: Your message of 3 Jan 1985 16:44:47 PST. Date: 04 Jan 85 16:56:09 GMT (Fri) Message-ID: <1360.473705769@UCL-CS.AC.UK> From: Steve Kille Jon, The administrative model you put forward is surely what the user wants to see. Thinking in terms of academic institutions, rather than arpanet, csnet, foonet etc. is good from the user's viewpoint. An interesting, and common, case is how does joe@no-tech.edu (connected say to csnet + mailnet) communicate with fred@so-tech.edu (connected say to usenet + bitnet). A simple approach is for all mail to pass thru a host with direct access to a domain name server, with local table/nameserver entries giving better paths to frequently used domains. My suspicion is that there are not enough hosts with direct access to domain nameservers to make this workable. Use of a more physical domain structuring (unfortunately) makes things just a little easier for a host which only has dialup links to a few other places. A pointer to an entry point (e.g. which of two dialout links should be used) to csnet (for example) can be determined (implicitly) from the domain structure no-tech.csnet. Routing within csnet is then a private problem for the csnet administration. Ideally, administrators of csnet, usenet, mailnet, bitnet, janet, arpanet, etc. would be evolving a solution appropriate to the needs and realities of ALL the networks. What is missing with the Darpa scheme is a mechanism for deriving sensible tables (nasty reality) to control a partially connected network such as Usenet. If the domain EDU (and other top levels) were to be managed by an organisation which could deal with all the nets, then it might be possible to build a mechanism which has no 'phsical' domains (such as csnet) and still avoid the problem noted in the previous paragraph. Steve  Date: Fri 4 Jan 85 10:56:01-PST From: David Roode Subject: Re: What Domain For Me ? To: steve@UCL-CS.ARPA, POSTEL@USC-ISIF.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "Steve Kille " of Fri 4 Jan 85 16:56:09-PST Location: EJ286 Phone: (415) 859-2774 Regarding the taxonomical scheme for assigning top level domains, it would be nice if it were planned to work according to Steve Kille's example, but I think it is planned to have names more along the lines of "joe@no-tech.csnet.edu", i.e. the user has to be concerned BOTH with the physically-relevant domain structuring and the taxonomical one. I think this is clumsy, since it would be possible for the currently proposed second-level domains to maintain an attribute specifying taxonomical grouping, and then to dispense with the use of the top-levels as domains at all. The advantages of administrative separation to be had by partitioning the world into groupings is not significant when the number of groupings is so small (four). The naming is unnecessarily lengthened for the user. Supposedly, users won't have to concern themselves with these names. This remains to be seen. -------  Date: Sat 5 Jan 85 02:21:08-EST From: Greg Skinner Subject: Re: Names with spaces To: header-people@MIT-MC.ARPA In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Thu 20 Dec 84 21:55:13-EST Message-Id: <8412210250.AA14990@ucbopal.CC.Berkeley.ARPA> I am not confident that quotes will make it through all Unix mail systems. If a csh shell is called to process a mail command at the command interpreter level the quotes may be lost unless action has been taken to prevent this lost. The Unix mailers around me *only* execute scripts with /bin/sh. This is pretty standard and should be adhered to everywhere. The uux commands are also executed with /bin/sh. Greg Skinner Gds@MIT-XX.ARPA {allegra,cbosgd,ihnp4}!houxm!gregbo (UUCP) -------  Date: Sat 5 Jan 85 03:01:58-EST From: Greg Skinner Subject: Re: What Domain For Me ? To: header-people@MIT-MC.ARPA In-Reply-To: Message from "Steve Kille " of Fri 4 Jan 85 16:56:09-EST From: Steve Kille What is missing with the Darpa scheme is a mechanism for deriving sensible tables (nasty reality) to control a partially connected network such as Usenet. If the domain EDU (and other top levels) were to be managed by an organisation which could deal with all the nets, then it might be possible to build a mechanism which has no 'phsical' domains (such as csnet) and still avoid the problem noted in the previous paragraph. The problem with deriving sensible tables for USENET (UUCP acutally) will be solved by the relay hosts between ARPA and UUCP. As I understand it, this is how things will work: A user sends mail to gregbo@houxm.UUCP from somewhere.ARPA. An SMTP connection is made to relay.UUCP (this may be harvard.ARPA or ucbvax.ARPA -- I don't know). The message is delivered to relay.UUCP and marked for further delivery to houxm.UUCP. (Here's where things get interesting.) There is a piece of Unix software which doubtless you have heard of called pathalias, which takes information in the form of the most up-to-date UUCP host tables and provides least-cost paths from the site to all other UUCP sites. At any rate, relay.UUCP will invoke pathalias (or a reasonable front-end for it) requesting a least-cost path from relay to houxm. The message can then be delivered to gregbo@houxm. Most likely the cheapest path will be ihnp4!houxm!gregbo (at least it ought to be). UUCP will most likely be subdomained, so it may be possible to send mail from ARPA to gregbo@houxm.ATT. The SMTP connection should probably still be to relay.UUCP since ATT will be a proper subset of UUCP. It is unlikely at first that relay.UUCP will open a UUCP connection to relay.ATT (because it may actually be cheaper for relay.UUCP to deliver a message to some-other-machine.UUCP which can deliver a message cheaply to gregbo@houxm.ATT) but as I understand it there is a UUCP project which will handle such subdomaining. The main point of this, I guess, is that just like the rest of the top-level domains, the UUCP domain, if it ever comes into existence will utilize mail software at the gateways for relaying mail. UUCP will, for all intents and purposes, appear as a fully-connected network. As an example, send mail someday to houxm!gregbo@harvard.ARPA (which is rather close to what the acutal address should look like -- gregbo@houxm.UUCP) and it will be delivered to me at houxm. Note that there is no harvard->houxm UUCP connection (there is, however, an houxm->harvard connection) so the pathalias software will provide a cheap route from harvard to houxm, and it will be invisible to the sender of mail. I hope this clears things up. Greg Skinner Gds@MIT-XX.ARPA {allegra,cbosgd,ihnp4}!houxm!gregbo or should I say houxm!gregbo@harvard.ARPA? -------  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2651167399472676@MIT-MULTICS.ARPA>; 04 Jan 1985 14:23:19 est Date: 04 Jan 85 13:44 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Kirk Kelley" , "William G. Martin" Cc: HEADER-PEOPLE@MIT-MC.ARPA Subject: Re: Body line length Message-ID: <84819@QZCOM> In-Reply-To: <83790@QZCOM> I don't agree with your wish to see all messages cut down to 80 col's. I might want to use the message network to send a document that is to be output on a lineprinter (or a 132-wide screen), I do not want the transporting network to intervene. The funtion of re-formatting a document should be a user-level application level feature, I might use different output medias from time to time.  Date: Tue, 8 Jan 85 11:28:42 EST From: Ron Natalie To: Greg Skinner cc: header-people@MIT-MC.ARPA Subject: Re: What Domain For Me ? Actually a better scenario is that if you want to send mail to the houxm.UUCP, you connect to the UUCP domain name server host. It returns you the address of the most appropriate relay machine. After it gets plopped onto the relay mahine, the rest of your message about what the relay host decides to do with the message holds. -ron  Date: Wed 9 Jan 85 08:43:41-PST From: Mark Crispin Subject: bug in Berkeley To: Postmaster@UCB-VAX.ARPA, Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) UCB-VAX is now sending messages with "Berkeley.ARPA" in its message headers. I would appreciate it if this was fixed; this is INVALID since Berkeley is a nickname and Berkeley.ARPA is undefined. -------  Received: from 44d.ucl-cs.ac.uk by 44a.Ucl-Cs.AC.UK with SMTP id a025719; 22 Jan 85 12:47 GMT Received: from hcig.nott.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a004773; 22 Jan 85 12:45 GMT Received: from CS.Nott.AC.UK by Hcig.Nott.AC.UK via Phonenet id a004304; 22 Jan 85 12:41 GMT Received: from Tuck.Maths.Nott.AC.UK by Robin.Cs.Nott.AC.UK via PHONENET id a016599; 22 Jan 85 12:39 WET Date: 22 Jan 85 12:38:22 UT (Tue) To: header-people@mit-mc.arpa Subject: The MODEM communications package From: Tim Lee Sender: Tdl%maths.nott.ac.uk@ucl-cs.arpa I am trying to trace a public domain communications package for CP/M machines and MS-DOS. The different versions of the suite are called MODEM and MODEM7, and appear to have been written by Irvin Hoff and Christopher Rhodes. Does anyone know of a supplier/distributer of this for the Osborne Executive, Epsons and IBM clones. Sorry if this is not the best list to mail. Tim Lee  Date: Tue, 22 Jan 85 19:38:35 est From: ukma!david@ANL-MCS.ARPA (David Herron, NPR Lover) Subject: Re: The MODEM communications package. Return-Path: Message-Id: <8501230038.AA15502@ukma.UUCP> Received: by ukma.UUCP (4.12/4.7) id AA15502; Tue, 22 Jan 85 19:38:35 est To: header-people@MIT-MC.ARPA Since the headers gave no clue on how to get back to this person.... I am trying to trace a public domain communications package for CP/M machines and MS-DOS. The different versions of the suite are called MODEM and MODEM7, and appear to have been written by Irvin Hoff and Christopher Rhodes. Does anyone know of a supplier/distributer of this for the Osborne Executive, Epsons and IBM clones. Sorry if this is not the best list to mail. Tim Lee They were actually written by Randy and Ward Christiansen. They run on CP/M machines. You can call up an RBBS somewhere and they might have a copy. Or you can get ahold of the CP/M users group and they have it on one of their disks. (Or there is a similar group for IBM users). Failing all that, SIMTEL-20.ARPA keeps archives of micro stuff. They may be able to help you. (Keith Peterson is the keeper of the archives there). David Herron david%ukma.uucp@anl-mcs.arpa cbosgd!qusavx!ukma  Date: 5 Feb 85 13:49:52 EST From: dca-pgs @ DDN1.ARPA Subject: Question on Probability of Keyboard Error To: works @ rutgers.arpa, sun-spots @ rice.arpa, apollo @ yale.arpa, header-people @ mit-mc.arpa CC: dca-pgs @ DDN1.ARPA Is there a widely accepted human-factors number on probability of typing error with either/both of the density variables being (1)time, (2)characters to be typed? Are there any good references on the subject? Thank you, Pat Sullivan DCEC Reston, VA  Return-Path: Received: from hadron.UUCP by seismo.ARPA with UUCP; Wed, 6 Feb 85 13:32:18 EST Received: by hadron.UUCP (4.12/4.7) id AA28095; Wed, 6 Feb 85 12:25:52 est Date: Wed, 6 Feb 85 12:25:52 est From: hadron!jsdy@seismo.ARPA (Joseph S. D. Yao) Message-Id: <8502061725.AA28095@hadron.UUCP> To: seismo!HEADER-PEOPLE@MIT-MC.ARPA, seismo!MMM-PEOPLE@USC-ISIF.ARPA, seismo!MsgGroup@BRL.ARPA Subject: Sendmail-like entity on System V? I'm not (yet) on this newsgroup, so any responders will have to mail to me directly at the address below. We very much like the way that sendmail on 4BSD works (at least, usually). One of our folk, however, has to use some System V machines. I was wondering if there was a version of sendmail for S-V? (He wants it last week, of course.) Appreciate any info. If this hasn't already been on the net, I'll summarise and put it back out. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}  Date: Wed, 6 Feb 85 16:36:00 EST From: Doug Kingston To: "Joseph S. D. Yao" cc: header-people@mit-mc.ARPA, mmm-people@usc-isif.ARPA, msggroup@brl.ARPA Subject: Re: Sendmail-like entity on System V? MMDFII has been ported to System V on the Vax. I suspect it will also work with little work on other 32bit System V implementatins. MMDFII will be released in the near future through BRL and UCL-CS under minimal licensing. Stay tuned for an announcement (1 - 2 weeks from now). MMDFII in a entire mail system including an MSG/SEND style user interface, (Cap)Mail user interface, a uucp channel, a TCP/SMTP channel, an EAN channel, a NIFTP channel, a list-processor, a Phonenet channel, and a powerful local delivery facility. -Doug-  Received: from Mission.ms by ArpaGateway.ms ; 08 FEB 85 10:09:56 PST Date: 8 Feb 85 10:09:53 PST (Friday) Subject: Re: problem with WISCVM gateway In-reply-to: F33PAP%DHHDESY3.BITNET's message of 850208.082825 GMT To: F33PAP%DHHDESY3.BITNET@WISCVM.ARPA cc: HEADER-PEOPLE@MIT-MC.ARPA, INFO-NETS%MIT-OZ@MIT-MC.ARPA, Hamilton.ES@XEROX.ARPA From: Bruce Hamilton [Sorry if this has been thrashed out already on HEADER-PEOPLE; I'm not on that list.] For what it's worth, the "Date" field in your msg: Subject: European Internal Networks Date: 850208.082825 GMT in your header probably does not meet any of the various ARPAnet RFC822-acceptable formats, because my mail program can't handle it. Is there somebody at WISCVM who can upgrade their gateway software from BITNET to munge the date properly? --Bruce  Received: from (ARNOLD)WISCPSLB.BITNET by WISCVM.ARPA on 02/08/85 at 14:21:52 CST Date: 8 FEB 85 14:05-CDT From: ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA To: header-people@mit-mc Cc: ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA Subject: Please add me to the list Please add me to the list. Steve Arnold, Joiner Associates Inc. ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA  Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/08/85 at 16:05:22 CST Date: Fri, 8 Feb 85 13:56:27 PST From: David Alpern To: Header-People@MIT-MC.ARPA cc: stef@udel.arpa , mrose@udel.arpa Subject: RFC 934 - Message Encapsulation I'm bothered by the choice made in the message separator (EB) as described in this document. Most digests currently do hold quite well to a standard of using either 70 or 30 hyphens alone on a line, with a blank line on either side. This is specific enough to avoid confusing user text with separators. Defining a hyphen in the first column of a line, with no other restrictions, as a separator seems like asking for ambiguity. Most front end programs will not be changed to "stuff" mail being sent for the first time, nor will most mail reader software "unstuff". As a proposal, may I suggest a line which starts with 5 hyphens in sequence followed by a space and an asterisk, ends with the reverse, and has a total length of 68. This is much harder for a user to hit randomly, would be easy for the user to avoid, and yet still allows for some text field within the separator. I think it would be worthwhile to define the standard in such a way that mail reading programs could tell, almost without ambiguity, if a message contained embedded messages. Then, depending on the user interface and the user's desires, the system could either break such messages automatically or on user command. Using the single hyphen separator it will be too likely for a single message to get broken at a list bullet or just above a "signature" (notice my own, which I've used this way for ages - if "unstuffed", this hyphen will disappear -and if I forget the space, the file gets split). - Dave David Alpern IBM San Jose Research Laboratory, K65/282 5600 Cottle Road, San Jose, CA 95193 Phone: (408) 284-6521 Bitnet: ALPERN@SJRLVM4 CSnet: ALPERN@IBM-SJ  Received: From udel-dewey.ARPA by udel-louie.ARPA id a017133 ;8 Feb 85 23:15 EST To: David Alpern cc: Header-People@MIT-MC.ARPA Reply-To: header-people@MIT-MC.ARPA Subject: Re: RFC 934 - Message Encapsulation In-reply-to: Your message of Fri, 8 Feb 85 13:56:27 PST. Date: 08 Feb 85 23:16:57 EST (Fri) Message-ID: <4057.476770617@udel-dewey> From: Marshall Rose Unfortunately, requiring more dashes just makes the problem harder and introduces additional ambiguity. Let me explain. A primary motivation for writing that RFC was that I was getting tired of constantly modifying the bursting agent in MH. First, I tried looking for 5 dashes at the beginning of a line. Sure enough, some digests let that through. Then I upped it to 30. Sure enough, some digests let that through. Then I got clever and introduced special heuristics based on the number of blank lines both preceeding and following the line that started with the dashes. Still not good enough. I then decided to look at least TWO LINES ahead and see if I could find what looked like a header. Still no good, one day someone just happened to have a couple of blank lines, a line of dashes, a couple of blank lines, all followed by a line that looked like a header. Brute force and extremely clever coding just can't compete. So, I decided that we need to bit (well, byte) stuff. This is the ONLY way to unambiguously separate messages in a digest (or a forwarding of messages, in general). So, if you're going to change all that software in net to be considerate and generate digests etc., that other software can burst, then you might as well make the change as simple as possible. Hence, the choice of a single dash for the EB. The RFC contains very simple algorithms to byte-stuff on encapsulation and to burst on decapsulation. The latter algorithm, in fact, needs only one character look-ahead. The point of all this is that I want to get painless bursting with the absolute LEAST amount of effort on the part of the mail hackers in the net. I really don't think it's too difficult to look at the beginning of each line and output a "- " if it starts with a "-". /mtr  Date: Fri, 8 Feb 85 20:31:50 EST From: Ron Natalie To: Bruce Hamilton cc: F33PAP%DHHDESY3.BITNET@WISCVM.ARPA, HEADER-PEOPLE@MIT-MC.ARPA, INFO-NETS%MIT-OZ@MIT-MC.ARPA, Hamilton.ES@XEROX.ARPA Subject: Re: problem with WISCVM gateway Various ARPAnet format? There is only 1.  Date: Sat, 9 Feb 85 17:05 EST From: Barry Margolin Subject: Re: RFC 934 - Message Encapsulation To: mrose%udel-eecis2.delaware@UDEL-LOUIE.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <850209220524.599492@MIT-MULTICS.ARPA> I have to agree with David Alpern. A common two-character sequence should not be pre-empted this way. A longer sequence is less likely to be used in messages. Actually, the problem is not in the sequence chosen. The problem is that it is not possible for the Bursting Agent to tell whether the sending software includes an Forwarding Agent. If not, then the sender won't have translated lines beginning with a hyphen, but your reader will decide that the message contains encapsulated messages and burst it. The right solution is to require Encapsulation Agents to add a header field, such as Encapsulation-Boundary: If this header field is not present, then the message does not contain an RFC934-conformant encapsulation, and the Bursting Agent should just pass it through unchanged. If it does, then a line beginning with is an encapsulation boundary. As in the original RFC, if the is followed immediately by a space then it is an escape prefix and the Bursting Agent should merely remove it from the text. I don't really think it is important that the EB be variable, as in my example. The only reason I included that capability was because I was inventing a header field and I couldn't think of anything else to put there. Another possibility is: Encapsulation-Mode: RFC-934 which allows for future enhancement of this protocol. barmar  Date: 9 Feb 1985 16:31 MST (Sat) Message-ID: From: "Frank J. Wancho" To: mrose%udel-eecis2.delaware@UDEL-LOUIE Cc: header-people@MIT-MC Subject: RFC 934 - Message Encapsulation Marshall, Notwithstanding the relative merits of certain portions of this RFC, I was rather surprised that you cited the lack of a standard format, particularly the Encapsulation Boundary, as the primary motivation to write this RFC in the first place. There has been a de-facto standard in use since the first digest appeared several years ago, and a complementary UnDigestify command by Gail Zacharias (GZ@MC) for those of us who use BABYL. A couple of years ago, Mike Muuss (mike @BRL) developed an UnDigestify for Unix/MMDF msg. (There is even an option to permit automatic detection and UnDigestification along with an UnDo, just in case it guessed wrong.) Whenever a new digest appears, the moderator soon finds out whether or not the digest message was formatted correctly. Thus, although the original digests came first, it has been those of us who have an UnDigestify command who tend to "enforce" conformance to this "standard" format. I suspect that had you asked, you would have been able to develop a similar UnDigestify command for your mail handler instead of producing yet another proposed standard that seems to ignore the existing one. All of the above is not meant to say that the entire RFC is not without merit. There is something to be said in favor of the proposed method of handling Bcc:s, Forwarded, and ReMailed messages, and the implied extension of the UnDigestify command to handle the latter two cases. However, please don't overlook the fact that an extension to an existing command has a better chance of being acceptable to the community than a rewrite would... --Frank  Received: from Cabernet.MS by ArpaGateway.ms ; 09 FEB 85 15:42:35 PST Date: 9 Feb 85 15:42:23 PST From: Murray.pa@XEROX.ARPA Subject: Re: problem with WISCVM gateway In-reply-to: "ron@BRL-TGR.ARPA's message of Fri, 8 Feb 85 20:31:50 EST" To: Ron Natalie Cc: Bruce Hamilton , F33PAP%DHHDESY3.BITNET@WISCVM.ARPA, HEADER-PEOPLE@MIT-MC.ARPA There may be only one date format in the specs, but reality is a lot different. When our header munger encounters a header that it can't parse, it can send me a message including a copy of the pesky header. Occasionally it's a bug in the parser. Normally it's a mail generating program that doesn't play by the rules. Crazy dates are quite common, and this is after our parser has been patched to know about the common illegal formats. I'll collect some samples if you want any data. (I'll even unpatch the parser if you want a lot of data.) And if you think there is a standard for dates.... I'm still amazed at the number of messages that come through with "at" where there should be an "@".  Date: Sun, 10 Feb 85 1:33:28 EST From: Doug Kingston To: "Frank J. Wancho" cc: mrose%udel-eecis2.delaware@UDEL-LOUIE.ARPA, header-people@MIT-MC.ARPA Subject: Re: RFC 934 - Message Encapsulation I agree with many of the comments made so far on RFC924. First, their is a defacto standard for which there exists working software. Second, a single dash is a poor choice of separater since it is highly likely that a) it will be used in message text by the user in such a way as to be mistaken for a separator, and b) unbursting will not be universially installed. People who don't unburst will use "-" poorly and the bursters will burst badly. I like the stuff on handling bursted contents. -Doug-  Received: From udel-dewey.ARPA by udel-louie.ARPA id a006628 ;10 Feb 85 22:14 EST Reply-To: header-people@MIT-MC.ARPA To: "Frank J. Wancho" , Doug Kingston cc: header-people@MIT-MC.ARPA Subject: Re: RFC 934 - Message Encapsulation In-reply-to: Your message of Sun, 10 Feb 85 1:33:28 EST. Date: 10 Feb 85 22:16:03 EST (Sun) Message-ID: <4057.476939763@udel-dewey> From: Marshall Rose Frank, I am aware of the software you mentioned (in particular Mike's code), and it is true that everyone who posts digests seems to be using the same rules for encapsulating messages into digests. In this case perhaps the use of the term "pseudo-standard" by the RFC is unfortunate. Stef and I did not (at least intentionally) ignore what others had done and decide to introduce "Yet Another Standard" that ignores what's working now. We went to great lengths to try and remain compatible with existing Internet software to minimize compliance problems. However, there is a larger issue which I am apparently missing in the your and Doug's and Barry's comments: It really is unimportant as to the precise string that is used for an EB. The important thing is that when that string appears in a message being encapsulated into a digest (or forwarding in general), that the encapsulation agent use some escape mechanism to prevent the bursting agent from declaring an end-of-message prematurely. Now, if the BABYL software (and any other software used to do encapsulation) does that correctly, then the primary motivation for the RFC is a non-problem. Hurrah. However, I have noticed in the past that every now and then a message containing a blank line, a line of dashes, another blank line, and a line with something that remotely looks like a header slips through digests like HUMAN-NETS and TELECOM. (This isn't an attack against either group, I just happen to recall a couple of instances in each list about six to eight months ago where this happened). So, there might exist "working software", but if EBs aren't byte-stuffed then you can't unambiguously de-capsulated messages and "it doesn't work right". To repeat (though re-phrase) what the RFCs says and what my last message said: All I really want is encapsulation agents to byte-stuff their EBs. If you want to use 30 or 50 dashes on a line as an EB fine. That isn't prohibited by the RFC. If everyone does the byte-stuffing, then the choice of an EB becomes moot. As I clear my throat to change the subject, I'm interested if there are comments on the unification of forwardings, distributions, and blind-carbon-copies. The latest (and hopefully last) release of MH, MH.5 uses encapsulation in the generation of Forwardings and BCC:s. Although it sounds esoteric, being able to recursively forward forwarded messages is rather neat. /mtr  Received: from (F33PAP)DHHDESY3.BITNET by WISCVM.ARPA on 02/11/85 at 02:53:31 CST Date: 11 FEB 85 09:36:21 MEZ From: F33PAP%DHHDESY3.BITNET@WISCVM.ARPA To: INFO-NETS%MIT-OZ@MIT-MC.ARPA Cc: HEADER-PEOPLE@MIT-MC.ARPA Subject: DATE STAMPING O.K. P.S.: Sorry my header generator cannot make small letters in the text.  Date: 11 Feb 1985 11:04:37 EST (Mon) From: Dan Hoey Subject: Re: RFC 934 - Message Encapsulation To: Marshall Rose Cc: Header-People@MIT-MC.ARPA In-Reply-To: Marshall Rose's message <4057.476770617@udel-dewey> Message-Id: <476985877/hoey@nrl-aic> Marshall, I am surprised that you say ... we need to bit (well, byte) stuff. This is the ONLY way to unambiguously separate messages in a digest (or a forwarding of messages, in general). I have previously indicated to you that there is a way to entirely avoid modification of the text of messages. Header People, The method I proposed was for the Forwarding Agent to choose an encapsulation boundary that does not occur in the messages to be encapsulated. Barry Margolin's proposal of indicating the chosen EB in the header is an appropriate way of communicating the choice to the Bursting Agent. However, the use of this boundary followed by a space for stuffing is not necessary. An algorithm for choosing the EB: 1. Form a list of trial EB's. I suggest the trial EB's be - twenty hyphens, - twenty hyphens followed by the current date and time, and - twenty hyphens followed by twenty randomly-chosen alphanumeric characters. 2. Scan the messages to be encapsulated for occurrences of the trial EB's. 3. If all of the trial EB's were found, fail. (If messages are being encapsulated at a rate of a megabyte per second, this step should be taken fewer than once every quintillion centuries, barring hardware failure.) 4. Return the first of the trial EB's not found in any message. Dan  Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/11/85 at 11:35:38 CST Date: Mon, 11 Feb 85 09:11:13 PST From: David Alpern To: header-people@MIT-MC.ARPA cc: Marshall Rose Subject: Re: RFC 934 - Message Encapsulation In-Reply-To: Message of 08 Feb 85 23:16:57 EST (Fri) from Marshall Rose References: <4057.476770617@udel-dewey>, and My message of Fri, 8 Feb 85 13:56:27 PST. Marshall, I understand your point, in that no digests that I know of prevent a message sender from including a line of 30 hyphens that is not meant as a separator. On the other hand, I don't forsee us ever getting all mail sending and reading programs on the net to "stuff". To do this properly, it would have to be not only digestifiers/ undigestifiers, but all sending/receiving programs since nothing other than the presence of a separator indicates a forwarded message. I disagree that one could use the 30 hyphen field simply as one special case of the single hyphen definition. The problem here is that not all software will be changed at once - you will be lucky if most ever is. How will the first "unstuffer" tell if it has a separator or a text hyphen - i.e. if the sender "stuffed"? Maybe the right thing is to ask all digest creators and mail forwarders to add a hyphen to any line containing exactly 30 hyphens alone in an entering message. This will help avoid the ambiguity, and will be useful even if accomplished in a very gradual manner. I doubt many will care if a line they send as 30 hyphens gets seen as 31, although there always will be somebody. This does lead to a question however -- how do we want to handle a forwarded message being sent to a digest, or otherwise reforwarded? I, for one, would first want to see the complete message (both forwarded and surrounding) as a single entity within a burst digest, and yet would like the ability to burst it again when I desired. Any bright ideas? Maybe using Barry Margolin's header-line specification of separator, combined with some "lenghten the separator for each embedded message level" algorithm will permit this. Regarding the other aspects of the RFC, i.e. treating forwarded messages in the same manner as digests -- I LIKE! I agree that currently forwarded messages are not too useful until one does separate the original text from the surrounding message. There are, however, cases where one would like to reply to both the original sender and the forwarder at once, which is not easy with your scheme as is. As an informal suggestion, I'll comment that both my undigestifier and the similar code I use for forwarded messages (less useful because of less of a pseudo-standard) add a LIST: field to the header of the embedded messages to specify either the discussion group or the forwarding sender, and my reply code notices this. - Dave David Alpern IBM San Jose Research Laboratory, K65/282 5600 Cottle Road, San Jose, CA 95193 Phone: (408) 284-6521 Bitnet: ALPERN@SJRLVM4 CSnet: ALPERN@IBM-SJ  Date: 11 Feb 1985 12:09 MST (Mon) Message-ID: From: "Frank J. Wancho" To: Header-People@MIT-MC Subject: Message Encapsulation The digests originating from Rutgers use a program to generate them. The program produces a line of 70 hyphens as the Topic Separator, and a line of 30 dashes as the Message Separator. Each Separator includes a blank line before and after the line of hyphens. As it processes each message to be encapsulated, it removes any trailing lines of hyphens. BABYL's UnDigestify command takes the first occurrance of a line of 65 to 85 hyphens as the Topic Separator and automatically flushes any immediately preceding blank lines. The remainder of the message is assumed to be a collection of one or more encapsulated messages separated by a line of 27 to 33 hyphens. Blank lines following the separator are also removed in the process. Other trailing blank lines that occurred before the Message Separator in the resulting messages are discarded as an inherent part of the normal BABYL message processing. --Frank  Date: 11 February 1985 15:59-EST From: Gail Zacharias Subject: Message Encapsulation To: HEADER-PEOPLE @ MIT-MC In-reply-to: Msg of 11 Feb 1985 12:09 MST (Mon) from Frank J. Wancho A minor correction to Frank's description: Babyl's UnDigestify command assumes that the encapsulated messages are separated by a blank line followed by a line of 27-33 dashes. The reason for the blank line is to allow one of the most common in-text use of dash sequences, which is to underline portions of the text. --------- Note that this underlining usage is one example of a situation where the user would indeed object to the mail system changing the exact number of dashes or inserting spaces or other characters in front of the dashes. I have to agree that the most important thing is to have the fact of encapsulation noted somewhere in the message, like in the header. If the sender can communicate the encapsulation method to the recipient, the actual method used is less of an issue. It should be up to the sender to decide whether to make the EB unique by varying the EB or munging the messages.  Date: Mon 11 Feb 85 18:25:20-PST From: Mark Crispin Subject: lowercase host names 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 would like to consign to eternal damnation all these mailers which think it is cute to use lowercase in host names. Perhaps their implementors should also suffer such damnation, but I'll settle for mandatory schooling in human factors. Many terminals do not satisfactorily show the difference between "1" (the numeral) and "l" (the letter). On the terminal I'm using, the difference is a single pixel. It is not at all obvious that "nyu-cmcl2" is "NYU-CMCL2" instead of "NYU-CMC12". Those long UUCP addresses get even worse. Getting a terminal with a better font is NOT the answer. -------  Date: Mon 11 Feb 85 18:39:32-PST From: David Roode Subject: Re: lowercase host names To: MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 11 Feb 85 18:31:52-PST Location: EJ286 Phone: (415) 859-2774 I would like to agree with Mark. It has long been the custom that acronyms are capitalized. Why should Massachussetts Institute of Technology, Macsyma Consortium (MIT-MC), Stanford University, Artificial Intelligence (SU-AI), Bolt, Beranek and Newman Communications Corporation-F (BBNCCF), and the like NOTE be subject to conventions that have been established since the middle ages. (Did they have Acronyms in the Middle Ages? Did they name things with contractions composed of the first letter of each word in a title?) has anyone looked at host names and considered how high a percentage are ACRONYM-based? -------  Received: from SCRC-HUDSON by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 176804; Tue 12-Feb-85 11:14:49-EST Date: Tue, 12 Feb 85 11:10 EST From: hornig@SCRC-QUABBIN.ARPA Sender: joseph@SCRC-QUABBIN.ARPA Subject: Re: lowercase host names To: David Roode , MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: The message of 11 Feb 85 21:39-EST from David Roode Message-ID: <850212111029.5.JOSEPH@HUDSON.SCRC.Symbolics.COM> Date: Mon 11 Feb 85 18:39:32-PST From: David Roode I would like to agree with Mark. It has long been the custom that acronyms are capitalized. Why should Massachussetts Institute of Technology, Macsyma Consortium (MIT-MC), Stanford University, Artificial Intelligence (SU-AI), Bolt, Beranek and Newman Communications Corporation-F (BBNCCF), and the like NOTE be subject to conventions that have been established since the middle ages. (Did they have Acronyms in the Middle Ages? Did they name things with contractions composed of the first letter of each word in a title?) has anyone looked at host names and considered how high a percentage are ACRONYM-based? ------- I will accept this line of reasoning only if people are also willing to allow hosts with names which are not acronyms to not be capitalized as if they were. I used to be the liaison for MIT-devMultics (capitalized just so). It was generally referred to by other hosts as MIT-DEVMULTICS or Mit-Devmultics, both incorrect. My mailbox now lives on SCRC-Stony-Brook.ARPA (soon to be Stony-Brook.SCRC.Symbolics.COM). I haven't even bothered to make our own mailer deal with that.  Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/12/85 at 12:09:25 CST Date: Tue, 12 Feb 85 09:58:09 PST From: David Alpern To: Header-People@MIT-MC.ARPA Subject: Forwarded mail from Kenneth Sloan === Begin message text === Date: 11 Feb 1985 17:03-PST From: Kenneth Sloan Subject: Re: RFC 934 - Message Encapsulation To: David Alpern In-Reply-To: David Alpern's message of Mon, 11 Feb 85 130843 PST David- Well, I probably don't have my note anymore - sadly, I find that I don't have time to participate in these RFC debates. If you still have a copy, you may do with it what you want, including posting it. As for "how to break from" in-band signalling, I support the idea of using a unique (to a particular message) character sequence, which is specified in a header field. I reject (on principle) any scheme which requires modifying the text of a message. I would prefer a scheme in which the message breaks were listed in the header (say, by line number). Something like: Break-On: 1, 53, 105, 259, 711, 911 However, that seems to be politically incorrect... Keep on fighting the good fight. -Ken Sloan === End message text ===  Date: Tue, 12 Feb 85 14:40 EST From: "Benson I. Margulies" Subject: capitalization To: header-people@MIT-MC.ARPA Message-ID: <850212194020.750425@CISL-SERVICE-MULTICS.ARPA> Why in seven hells do these cute-as-a-shithouse-rat mailers insist on touching the text of the destination host name at all? Why not make the rules be "match case insensitive, but preserve what the sender sent?"  Date: 12 Feb 1985 13:26-PST Sender: GEOFF@SRI-CSL Subject: Re: capitalization From: the tty of Geoffrey S. Goodfellow To: Margulies@CISL-SERVICE-MULTICS Cc: header-people@MIT-MC Message-ID: <[SRI-CSL]12-Feb-85 13:26:06.GEOFF> In-Reply-To: <850212194020.750425@CISL-SERVICE-MULTICS.ARPA> I'm with you Benson. As I recall, it all started years ago when Dave Crocker thought it was a "good idea" to cutesy-up host names and put code in the MMDF mailer. Since then, the affliction seems to have grown and spread. Can we kill the epidemic before it becomes inter galactically offensive? g  Date: 12 Feb 1985 20:23:38 PST From: POSTEL@USC-ISIF.ARPA Subject: re: lower case host names To: header-people@MIT-MC.ARPA The case of characters in hosts names is not significant. That is, names are to be recognized independent of case. If some host likes to use its name in a mixed case style (e.g., MIT-devMultics), that is fine, but it can't complain that some other caseification makes it's name somehow wrong (e.g., MIT-DEVMULTICS or Mit-Devmultics are still legal names for that host). [As an aside, for years the Multics hosts insisted that the name of my host was "USC-ISIf" (note the lower case f). No one at ISI ever suggested or liked that name. And for a long time we couldn't get the Multics people to change it. As far as i can tell it was the Multics people who started silly caseification of host names.] One thing that does happen to host names is that they are required to be the official names, not nick names or locally used aliases. Sometimes a program fixes this by using the host tables to convert the given name into a number (internet address) then convert the number into the official name. Thus you end up with the caseification that was in the host table on the host where the fix was performed. --jon. -------  Date: Wed 13 Feb 85 01:20:12-EST From: Greg Skinner Subject: capitalization To: header-people@MIT-MC.ARPA I agree with what was said about retaining case insensitivity while also retaining the original header information. A friend of mine was unkindly flamed at by the mailer at ihnp4 which had rejected a legal address sent to me at houxm via ihnp4, excepting the fact that all the host names had been capitalized. The mail software running at ihnp4 was case sensitive, causing the messages to fail, however the sending agent (the VMS mailer on mit-jcf) had no business capitalizing the address my friend supplied, which was in lowercase. --gregbo gds@mit-xx.arpa gregbo%houxm.uucp@harvard.arpa {allegra,cbogsd,ihnp4}!houxm!gregbo -------  Date: Wed 13 Feb 85 00:45:45-PST From: Mark Crispin Subject: nicknames not allowed in headers 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) Let's not forget the offically sanctioned exception to this, BERKELEY.ARPA which is now listed in the NIC host table as a nickname for UCB-VAX.ARPA. Rather than fix their software so that it didn't say "user@Berkeley.ARPA", they hacked the host table. In a way, I'm glad they did. At least it stopped the flood of hysterical and abusive mail I got claimed that the TOPS-20 mailsystem was broken because it didn't recognize "Berkeley.ARPA" as a host. -------  Received: from Cabernet.MS by ArpaGateway.ms ; 13 FEB 85 02:04:25 PST Date: 13 Feb 85 01:57:46 PST From: Murray.pa@XEROX.ARPA Subject: Re: lowercase host names In-reply-to: <850212111029.5.JOSEPH@HUDSON.SCRC.Symbolics.COM> To: hornig@SCRC-QUABBIN.ARPA Cc: David Roode , MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA There is a slight complication here. Somebody along the way is supposed to change nicnames into official names before a message goes out over the net. That means if a user types in a nicname, the message goes out with the capitalization that's in the official host name table... Will the new domain based scheme support lower case letters?  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA01534; Wed, 13 Feb 85 10:13:26 pst Received: from CORNELLA.BITNET by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1) id AA02047; Wed, 13 Feb 85 10:13:58 pst Message-Id: <8502131813.AA02047@ucbjade.CC.Berkeley.ARPA> Date: 13 February 85 13:08 EST From: RMXJITRY%CORNELLA.BITNET@Berkeley Subject: DOMAINS and lower case addressing To: HEADER-PEOPLE@MIT-MC.ARPA I sincerely hope that the new DOMAIN scheme will not support lower case letters. THe only immediate problem with that is that would (probably) interfere greatly with sending mail on usenet. -- Gligor RMXJITRY%CORNELLA@WISCVM.ARPA  Date: 13 Feb 1985 11:00:47 PST From: POSTEL@USC-ISIF.ARPA Subject: re: lower case host names To: header-people@MIT-MC.ARPA The Domain server implemented for TOPS20 at ISI stores the names in its database with whatever case the names have in the master file. The server recognizes names on a case independent basis. And, it reports names with the case they have in the database. So who ever it is that prepares the master files gets to set the case used for the names. --jon. -------  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2654659062681411@MIT-MULTICS.ARPA>; 14 Feb 1985 00:17:42 est Received: from Wayne-MTS by UMich-MTS.Mailnet via MTS-Net; Wed, 13 Feb 85 22:45:17 EST From: Michael_D'Alessandro@Wayne-MTS Message-ID: <32767@Wayne-MTS> Date: Wed, 13 Feb 85 17:19:50 EST From: Michael_D'Alessandro%Wayne-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: header-people@MIT-MC.ARPA Please remove me from your mailing list. My address is: Michael_D'Alessandro%Wayne-MTS%Umich-MTS.Mailnet@MIT-Multics.ARPA  Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2654670288730861@MIT-MULTICS.ARPA>; 14 Feb 1985 03:24:48 est Date: Wed, 13 Feb 85 23:39:49 EST From: "GO CCITT GO - X.400" <995@NJIT-EIES.MAILNET> To: Header-People@MIT-MC In-Reply-To:The last stream of messages Subject: message formats Message-ID: Won't it be nice when MHS gets up and running then we won't have to worry how each system handles message separation. a message is a message part (and data type)  Date: Thu, 14 Feb 85 11:43:49 est From: Mark Shoemaker Message-Id: <8502141643.AA17187@purdue.ARPA> Received: by purdue.ARPA; Thu, 14 Feb 85 11:43:49 est To: header-people@MIT-MC.ARPA Subject: Firewalls in sendmail Has anyone hacked sendmail to prevent non-local or unauthorized users from using a host as a mail relay? Our specific problem is that we have one system designated for research use that has an IMP connection and several other systems connected to it used solely for instruction, and we would very much like to keep student users from sending/receiving ARPAnet mail. I'm aware of the checkcompat() routine, but it looks like it will be very difficult to make it handle the non-trivial cases (like a resarcher who forwards his/her mail off-host). I'm hoping we can avoid re-inventing the wheel. Any suggestions/advice would be most welcome. Thanks, Mark Shoemaker  Received: by UCB-VAX.ARPA (4.24/4.41) id AA01276; Thu, 14 Feb 85 09:28:13 pst Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7) id AA29926; Thu, 14 Feb 85 10:18:09 est Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) id AA14535; Thu, 14 Feb 85 10:12:52 est Date: Thu, 14 Feb 85 10:12:52 est From: cbosgd!mark@Berkeley (Mark Horton) Message-Id: <8502141512.AA14535@cbpavo.cbosgd.ATT.UUCP> To: RMXJITRY%CORNELLA.BITNET@Berkeley, header-people@mit-mc.ARPA Subject: Re: DOMAINS and lower case addressing Cc: vortex!lauren@Berkeley I sincerely hope that the new DOMAIN scheme will not support lower case letters. THe only immediate problem with that is that would (probably) interfere greatly with sending mail on usenet. I have no idea what brought this on, but I can assure you that not only do Usenet and UUCP have no trouble with lower case, but in fact by convention nearly EVERYTHING is in lower case. The domain rules state that to the right of the @ sign, case is to be ignored. We intend to follow this on UUCP. The current UUCP transport layer software is case sensitive, that is, Shasta and shasta might be considered different on some machines (but sendmail ususally hides this.) The mail layer being developed will ignore case. Of course, Usenet is not a mail network, just a news network. It has very little interaction with the mail or domain systems, and the interaction it has will not care about upper or lower case. Mark Horton  Received: by lll-tis.ARPA (4.30/4.7) id AA21899; Fri, 15 Feb 85 14:44:49 pst Message-Id: <8502152244.AA21899@lll-tis.ARPA> Date: Fri Feb 15 14:44:43 1985 From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch) Subject: Re: Firewalls in sendmail To: mas@Purdue.ARPA Cc: header-people@MIT-MC.ARPA X-Orig-Date: Thu, 14 Feb 85 11:43:49 est X-Orig-From: Mark Shoemaker X-Orig-Message-Id: <8502141643.AA17187@purdue.ARPA> Status: N > Has anyone hacked sendmail to prevent non-local or unauthorized users > from using a host as a mail relay? Our specific problem is that we have > one system designated for research use that has an IMP connection and > several other systems connected to it used solely for instruction, and > we would very much like to keep student users from sending/receiving > ARPAnet mail. Why not relax and enjoy it? The entire scheme of internetwork mail forwarding is based on the ideas of comity, cooperation, and freedom of information flow. Now, if student mail traffic was overloading your poor research machine, you might want to modify your host and routing tables, to have the flow go somewhere else. If you were talking about preventing the escape of sensitive information, it might be worth doing, but just to cut off students' internet mail access? (Remind me where NOT to apply to get MY next degree! :-) ) Access to the various lists, both technical and nontechnical, is a worthwhile use of resources. Why not buy 'em a cheap gateway instead? Michael C. Berch mcb@lll-tis.ARPA {akgua,ihnp4,sun}!idi!lll-tis!mcb  Date: 16 February 1985 12:13-EST From: "Lyman R. Hazelton, Jr." To: HEADER-PEOPLE @ MIT-MC Please take me off the Header-People mailing list. I have other fish to fry now. Thanks to all of you for the lively debate and interesting viewpoints over the years. I learned a lot. Lyman  Message-Id: <8502170613.AA05778@merlin.ARPA> Received: by merlin.ARPA; Sun, 17 Feb 85 01:13:16 est To: mcb%lll-tis.ARPA@lll-tis.ARPA (Michael C. Berch) Cc: mas@Purdue.ARPA, header-people@MIT-MC.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of Fri Feb 15 14:44:43 1985. <8502152244.AA21899@lll-tis.ARPA> Date: 17 Feb 85 01:13:13 EST (Sun) From: Christopher A Kent From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch) Subject: Re: Firewalls in sendmail Why not relax and enjoy it? The entire scheme of internetwork mail forwarding is based on the ideas of comity, cooperation, and freedom of information flow. It's late, and maybe I shouldn't be responding in my tired state, because I'm going to flame, but why did you send such a useless reply to the list? We have a real problem, need some help, and you try to tell us that we should just ignore it. Why must you question our motives? Maybe it's escaped you, but the DARPA Internet is a *research* network. Our sponsoring agent has specified that ONLY research users should be allowed access. Therefore we have to put together some firewalls. It's not a question of cycles or bandwidth. It's policy. chris  Received: FROM UCL-CS.ARPA BY USC-ISID.ARPA WITH TCP ; 18 Feb 85 05:14:55 EST To: Mark Shoemaker cc: header-people@mit-mc.arpa Subject: Re: Firewalls in sendmail Phone: +44-1-387-7050 ext 773 In-reply-to: Your message of Thu, 14 Feb 85 11:43:49 est. <8502141643.AA17187@purdue.ARPA> Date: 18 Feb 85 10:08:13 GMT (Mon) Message-ID: <1360.477569293@UCL-CS.AC.UK> From: Steve Kille Although not answering your question directly, you might be interested in MMDF II (which you sould be able to get from BRL in the near future), which has a number of features to provide access control. We (UCL) are beginning to use these controls to restrict message flow between the Internet and the UK. Currently, if you attempt to loop a message back to yourself thru UCL, you will receive a warning message telling you to become authorised (for the UK -> US hop)! This is done on the basis sender, recipient, and connect hosts, to determine which networks may be accessed. Steve  Received: by lll-tis.ARPA (4.30/4.7) id AA03271; Mon, 18 Feb 85 21:24:40 pst Message-Id: <8502190524.AA03271@lll-tis.ARPA> Date: Mon Feb 18 21:24:36 1985 From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch) Subject: Firewalls (and flames) in sendmail To: header-people@MIT-MC.ARPA Cc: cak@Purdue, mas@Purdue Status: N Well, my posting about denying Internet access to students seemed to hit a raw nerve at many sites. Mail is running about 70% in favor of my comments (the tenor of which were to leave well enough alone) and the remainder were opposed, on the various grounds of security, network/gateway capacity, policy, or DoD-related rules. From cak@Purdue: > It's late, and maybe I shouldn't be responding in my tired state, because > I'm going to flame, but why did you send such a useless reply to the list? > We have a real problem, need some help, and you try to tell us that we > should just ignore it. Why must you question our motives? The reply WAS meant to be useful, and I stand by it. My comment was that you may not have a problem. Many times I have posted a question of the form, "How can I do X?", and gotten the reply that for whatever technical/administrative/commonsense reason, I really DON'T want to do X. And I am thankful for it. > Maybe it's escaped you, but the DARPA Internet is a *research* network. > Our sponsoring agent has specified that ONLY research users should be > allowed access. Therefore we have to put together some firewalls. It's > not a question of cycles or bandwidth. It's policy. I can understand that if you have an ARPANET sponsor breathing down your necks, yelling, "GET THOSE %#$@&#@ STUDENTS OFF THE NET!!" and threatening to yank your funding and DARPA authorization, that's one thing. If that's the case, you truly have my sympathy, and I agree that you certainly don't need my smug assertions about comity. But if not, I'd wonder why you would want to make it an issue. It doesn't take too much close reading of the headers of many of these lists to determine that many institutions have granted more or less general access to the Internet -- for mail purposes -- to their local networks. It is also evident that ARPANET and MILNET gateways and hosts are carrying a fair amount of off-net traffic, much of it destined for UUCP, CSNET, and BITNET nodes. Anyway, the volume of mail (and the intensity of the opinions expressed therein) leads me to believe that student/casual access to internetwork mail service is a problem that isn't going to go away. I believe, as many do, that freedom of information flow should be paramount, and that the value of an internet increases with the number of persons accessible. On the other hand, there are real concerns about resource consumption, security, and network sponsor policy involved. So, what are people doing about this? Are there alternatives that preserve access to the internetwork community while balancing policy concerns? Is this a problem or a non-problem? My apologies for the long posting. Perhaps this discussion should move elsewhere, like info-nets? ---- Michael C. Berch mcb@lll-tis.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb ...!idi!lll-tis!mcb  Date: Sat, 16 Feb 85 01:19:06 est From: Mark Shoemaker Message-Id: <8502160619.AA00638@purdue.ARPA> Received: by purdue.ARPA; Sat, 16 Feb 85 01:19:06 est To: mcb@lll-tis.ARPA (Michael C. Berch) Cc: header-people@MIT-MC.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of Fri Feb 15 14:44:43 1985. <8502152244.AA21899@lll-tis.ARPA> ---------- > Why not relax and enjoy it? I wish we could -- but allowing approximately 4500 undergraduate students access to the ARPAnet (even if only through mail) seems, uh, unwise. I'm curious: are there any schools out there that give unrestricted ARPA mail access to all their students (and will admit it)? Mark  Received: from (BSD)PSUVM.BITNET by WISCVM.ARPA on 02/19/85 at 10:32:01 CST Date: Tue, 19 Feb 1985 11:06:55 EST From: BSD%PSUVM.BITNET@WISCVM.ARPA Subject: Re: Firewalls and flames in sendmail To: header-people@MIT-MC.ARPA One thing to think about before denying students access to the various networks is the fact that much of the net depends on students. How many of you who are in favor of stopping student access to the networks (Not just the ARPA Internet, but all nets. This is an idea that is gaining popularity at Universities.) have ever sent mail from Usenet to BITNET via psuvax1? How many of you knew that the mail software there is maintained not by systems administrators or computer professionals, but by a HIGH SCHOOL STUDENT? He helped in the writing of the initial gateway, and has done much development on it since the real developer has been on leave. I'm sure that there are a lot of other instances where 'THOSE #*&$%#&$ STUDENTS' have made useful contributions to the network. And after all, how does one become a computer professional if not by first being a student? --Scott Dickson User Consultant uucp: {ihnp4, allegra, akgua}!psuvax1!BSD%PSUVM.BITNET Bitnet: BSD@PSUVM.BITNET Arpa: BSD%PSUVM.BITNET@WISCVM.ARPA  Date: 19 Feb 85 1205 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Mark Shoemaker Subject: Re: Firewalls in sendmail CC: header-people@MIT-MC.ARPA In-Reply-To: <8502160619.AA00638@purdue.ARPA> Message-Id: <19Feb85.120510.EN0C@CMU-CS-A.ARPA> Mark, If you are all for free mail and everything...I have some internal sites you could pay for leased lines to and set up mail connections and get mail working to. You can deal with the fun that some students and people have at attacking ARPANET sites, sending large binary files thru the mail and other nice unconstructive ways of gumming up the works. We have had people read the Unix documentation of things that are quite obvious "security holes" in Unix and procedure to do them... including the (while (1) mkdir foo; cd foo; end) hack. The eventual change was to disable most of the commands...I disagree with that approach...I am old fashioned...I would had his hands cut off. The other reality is that the ARPANET is paid for by tax money, if people want general access to the ARPANET that other people don't have....I will be glad to help 60 minutes or whatever set of news organization help scream about misuse of goverment resources. There is alot of good in computer science proffessionals talking over networks...but the ARPANET is not a replacement for GTE TELEMAIL, MCI mail and the such....Joe Blow should use those service...not a goverment research network. -Rudy  Received: by bbnccv.ARPA (4.12/4.7) id AA00736; Tue, 19 Feb 85 12:51:59 est Message-Id: <8502191751.AA00736@bbnccv.ARPA> To: Rudy.Nedved@cmu-cs-a.ARPA Cc: Mark Shoemaker , header-people@mit-mc.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of 19 Feb 85 1205 EST. <19Feb85.120510.EN0C@CMU-CS-A.ARPA> Date: 19 Feb 85 12:51:50 EST (Tue) From: jsol@bbnccv Date: 19 Feb 85 1205 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Mark Shoemaker Subject: Re: Firewalls in sendmail Cc: header-people@MIT-MC.ARPA There is alot of good in computer science proffessionals talking over networks...but the ARPANET is not a replacement for GTE TELEMAIL, MCI mail and the such....Joe Blow should use those service...not a goverment research network. I agree, but of course you realize that if Joe Blow want's to send mail to someone on the Internet he is basically out of luck. This is unfortunate since electronic mail is fast becoming the latest form of communication (it is cheaper to send an electronic mail message than to call someone on the phone and say basically the same thing). When I was working for Rutgers, I found that the administration there was also not into letting students send mail to the arpanet. For the most part I agree with the idea that "Joe Student" shouldn't be able to send mail to the arpanet, but I was never a "joe typical student" either. I was fascinated by electronic mail systems, and enjoyed the conversations I had with other people via the net and the electronic mailing lists were absolutely awesome! Look at me now, I work for a software house maintaining the electronic mail system (amongst other things), and I maintain the TELECOM mailing list (digest). I would say that I was contributing to the welfare of the ARPANET since I was in college, and I would say that if I hadn't had access to the ARPANET, I would probably not be where I am today. As I am trying to say, I don't think all students should be encouraged to send mail on the arpanet, but if someone gets interested, I think their interest should be encouraged, to the point of hiring the person to maintain the mail system or something else. It would be sad to hear that some site was not permitting someone who wants to get involved to do so, that's the sort of person we need here, someone who will contribute to the well-being of the net. This sort of consideration should be set up in the software. At Rutgers, there is a priviledge bit on the systems which allows users to send mail over the ARPANET, and in addition, there are selected addresses (such as mine) which send mail over the arpanet to me even though users at Rutgers specify local addresses (the wonders of mail forwarding). One more thing, I recall that an authorized mail message is defined by the DCA as being authenticated either at the sender end or the receiver end. In short, that means that I should be able to send mail to anyone on the net because I am authenticated, and anyone on the net should be able to send mail to me, regardless of authentication. Too bad the protocol doesn't make this easy to implement. Joe Student should be able to send mail to me, since I'm authorized to receive mail. I would like to see more work devoted to that form of authentication before tackling the less important problem of keeping students off the net. Cheers, --JSol  Message-Id: <8502191952.AA11779@merlin.ARPA> Received: by merlin.ARPA; Tue, 19 Feb 85 14:52:07 est To: jsol@bbnccv.ARPA Cc: Rudy.Nedved@cmu-cs-a.ARPA, Mark Shoemaker , header-people@mit-mc.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of 19 Feb 85 12:51:50 EST (Tue). <8502191751.AA00736@bbnccv> Date: 19 Feb 85 14:52:04 EST (Tue) From: Christopher A Kent We *do* have such authentication, and it is used for telnet, ftp, etc. What we're trying to come up with is a solution to allow us to use it for mail. Let's quit discussing the hows and whys -- just take it as given that there is a certain class of user here that, for whatever reason, may not send or receive mail on the Arpanet. Back to the original question: how can we enforce this in sendmail? chris P.S. I agree that there are students and students. I'm a student; I also maintain the network systems in the CS department, and do research. The students we're talking about are beginning programming undergrads that are supposed to be using our terribly overloaded instructional machines JUST for their programming homework, not flooding the mailer or the arpanet with digest mail. If they want to get involved in hacking network systems, there are venues for doing so. Enough already! ----------  Date: 19 Feb 85 1543 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: jsol@BBNCCV.ARPA Subject: Re: Firewalls in sendmail CC: Mark Shoemaker , header-people@mit-mc.ARPA In-Reply-To: <8502191751.AA00736@bbnccv.ARPA> Message-Id: <19Feb85.154337.2@CMU-CS-A.ARPA> If I sounded anti-student...I am not. In general, I am anti-abuse. I don't like people screwing things up and if there is no recourse to reprimand that abuse....I handle it via software. I work for the CS department and the Robotics Institute. If you abuse the priv of having ARPANET access....we nail your account. Simple and effective. The majority of the students use other facilities and the adminstration until last year was extremely lax in dealing with system crashers. The "discipline" council did not understand computers and the representative for the general computing facility seems to be afraid of restricting anyone's freedom even though the individual has caused harm to other individuals. Therefore....system crashing, deleting files, stealing accounts, sending huge mail and other destructive actions were rampant. The result was the software people quickly learned to build bigger and better walls that didn't allow crashes, that discouraged password stealing, limited mail sending sizes and mail receiving sizes....The students got smarter and so did the system support people...it was an all out war. The wind has changed and things are taking a more professional attitude. Many students have accounts at CS or other departments and do very good work. They have their privs but heaven help them if they blow it. Basically I put in restrictions according to whether it causes me or other people grief. If a mail system I maintain slows down and I get complaints that meetings are being missed or whatever because mail is taking 30 minutes instead of 5....I look at it...If I find 40 people getting junk mail or two people having a mail war...I come down on them like a ton a bricks. I don't care if it is some employee from some company that sprouted from CMU or some guest professors or some graduate student....(all of which have done there fair share of abuse) Rudy Nedved Undergraduate Applied Math Major (full time for two years, part-time now) CMU CS/RI Research Systems Programmer Facilities Staff  Received: from iapetus by rice.ARPA (AA04888); Tue, 19 Feb 85 18:47:43 CST Received: by iapetus (AA05177); Tue, 19 Feb 85 18:50:32 CST Date: Tue, 19 Feb 85 18:35:40 CST From: Scott Alexander Subject: Re: Firewalls in sendmail To: header-people@mit-mc.ARPA Message-Id: <477707741.salex@Iapetus.ARPA> In-Reply-To: a message from jsol@bbnccv dated 19 Feb 85 12:51:50 EST (Tue) Firstly, my situation is somewhat unique in that although we have transparent access (well, fairly transparent) to the arpanet, we pay per packet charges to GTE. Thus, if joe random decides to send mail to his friend on the arpanet, and his friend's site is down, we pay to check every ten minutes to see if that site has come back up. Second, on the subject of undergraduates and other random students using the network. I am an undergraduate and am in charge of rice's network. I agree that letting *some* students have access to the arpanet is good. However, I see an increasing number of students (with the increasing enrollment) who do not see the community of computer scientists which has bred a sense of fair play in the past. I feel that I have some resonsibility to the rest of the arpanet community to prevent students from attempting to cause problems to other machines. Locally, this is easy to deal with and I take the attitude which Rudy suggests. However, if someone from a rice machine uses the arpanet to conduct mail wars, it is difficult for me to discover this in time to substantially prevent it without preventing all mail from students to the outside world. If a student has the promise, an effort is made to hire him into a position which gives him access to the arpanet. Locally, educational sites can be lenient if they desire, but we have a greater responsibility to the arpanet (even if one is willing to ignore the clauses of the arpanet agreement about research use only). Scott Alexander postmaster Rice University  Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 02/20/85 at 02:18:18 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN id 2074; Wed, 20 Feb 85 10:10:48 IST Date: Wed, 20 Feb 85 10:10 IST From: Henry Nussbacher Subject: Firewalls To: Restricting student access to Arpanet: very interesting. I don't know what the solution is. How to restrict access? By userid? By password? Since Arpanet is for research do you also restrict access to administrators and secretaries who run each shop but are not involved with strict research? My belief is that any tool will be abused. A hammer can be used for hammering nails or for taking someones head off. The trick is to convince the abusers that they will be punished. I have had a problem off and on with students (specifically - high school students) sending chain letters through BITNET (if you think Digest mail is bad, you ought to see what happens with chain letters in a network!). The simple solution is that if a user will send out a chain letter, they will have their account suspended, and all their files erased. We have also threatened to shut off the link to the outside world if some sort of abuse of the network is found (obscene mail, junk mail, chain letters) and to publish in the system the name of the user who is responsible for the disruption in service. We have never had to do this but have come close at times. The threat of it is enough to control even 12 year old kids! We have managed to keep digest mail levels down by only allowing one subscriber on our node and placing the various interesting digests on a local Bulletin Board. This way we only get one copy of SF-Lovers and not 30 or 40. In addition, the BITNET mailer will send only one copy of a piece of mail to a node even if there are many recipients for that node. The mailer at the destination will then fan it out to the recipients. In this fashion, we have also cut down the number of mail files that travel through the network. These are solutions to congested network problems. Student abuse will only aggravate the problem. I am not sure if there are any easy solutions. In reference to the person who threw in PSUVAX1 as a good example of a high school student writing the gateway: bad example! PSUVAX1 has one of the worst reputations on BITNET for flaky software. That is what you get when you place a clever high schooler to do the work of a qualified systems programmer. All gateways in BITNET accept mail from "trusted" second party mail handlers. Except PSUVAX1. It rejects mail from "trusted" mailers and has been like this for the past 6 weeks. I would prefer to get a qualified systems programmer at PSUVAX1 to fix it so BITNET can finally use the "official" UUCP gateway. So much for the merits of high school written code! Hank Weizmann Institute of Science Rehovot, Israel  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA12284; Wed, 20 Feb 85 23:38:20 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1) id AA14547; Wed, 20 Feb 85 23:14:41 pst Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.33) id AA26651; Wed, 20 Feb 85 23:14:19 pst Date: Wed, 20 Feb 85 23:14:19 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8502210714.AA26651@ucbopal.CC.Berkeley.ARPA> To: HEADER-PEOPLE@MIT-MC.ARPA, RMXJITRY%CORNELLA.BITNET@Berkeley Subject: Re: DOMAINS and lower case addressing Some Unix systems with uucp links are case sensitive. Unix sendmail converts all addresses to one case when comparing domain-name and userid information. It should leave the case the way in was sent in the header when it forwards a message. We recently had a problem on a Unix system here because a userid (login name) had been created that contained upper and lower case letters. The result was that the user could not receive mail because sendmail was looking for a lower-case only login name. Thus mail to "UsEr" would be forwarded to "user" (if "user" existed) or generate an unknown user error. So case is also an issue with the local part of the address on some systems. Bill Wells wcwells@Berkeley.ARPA  Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655274531772228@MIT-MULTICS.ARPA>; 21 Feb 1985 03:15:31 est Date: Wed, 20 Feb 85 14:22:17 EST From: "Thomas A. Moulton" <995@NJIT-EIES.MAILNET> To: Header-People@MIT-MC.ARPA In-Reply-To:<19Feb85.120510.EN0C@CMU-CS-A.ARPA> Subject: Firewalls in mail senders Message-ID: If you think about it, these "Mail Wars" and system crashing and other damaging system hacking is not a professional way for students to act. Once you take that perspective the student accounts are No problem, if a student steps to far out of line he gets yelled at, hand slapped and warned that they could lose their entire college career, I have heard that if a student gets thrown out of school by the Committee for Professional Conduct they might as well decide to either pump gas for the rest of their lives or just start over from scratch. Once you make an example of one or two students your problems are solved. On the school's main computer (the dumb one, no mail system) there was even a student who was making lots of money on the cpu time allocated to him for classes, needless to say he's history... It's kinda fun to watch a student hang himself by ignoring such warnings, you know the kind, they wimper when you take away your account and then once they get it back they act like a hot shot in the terminal room as they go to crash the system one final time...  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655278688719196@MIT-MULTICS.ARPA>; 21 Feb 1985 04:24:48 est Date: 21 Feb 85 00:36 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: RFC 934 - Message Encapsulation Message-ID: <91867@QZCOM> In-Reply-To: <90500@QZCOM> David, I think that trying to enforce rules on Digestors like "Insert a line of 30 hyphens as message separator" would never work, for example, my keyboard cannot count. The right way of handling this would be to elaborate the Multi-Media and Script concepts, work that is currently going on (e.g. in IFIP). The X.400 way may also work. It may look cumbersome but it should be remembered that the user interface is completely left out from the recommendation, leaving it up to all and everyone to tackle the User-Presentation problem as he wishes. - Tommy  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2655298608378532@MIT-MULTICS.ARPA>; 21 Feb 1985 09:56:48 est Date: Wed, 20 Feb 85 09:02:02 EST From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: header-people@MIT-MC.ARPA, Bernard_Galler@UMich-MTS.Mailnet Message-ID: <655931@UMich-MTS.Mailnet> Subject: Firewalls etc. Hi: Are there any "official" policies around about how local institutions handle their access to Internet and/or CSNET facilities? Do people have to sign a written down form? Do any of these forms exist on file so that you could send me a copy by electronic mail? I'd suggest that if you have such a policy that you send it just in a message to me, since the Firewall discussion is already beginning to get out of hand. I'd appreciate any responses! -- Hans-Werner HWB%UMICH-MTS.MAILNET@MIT-MULTICS.ARPA  Date: Sun 24 Feb 85 12:07:04-EST From: Greg Skinner Subject: Re: Firewalls in sendmail To: header-people@MIT-MC.ARPA In-Reply-To: Message from "Mark Shoemaker " of Tue 19 Feb 85 08:26:22-EST From: Mark Shoemaker > Why not relax and enjoy it? I wish we could -- but allowing approximately 4500 undergraduate students access to the ARPAnet (even if only through mail) seems, uh, unwise. I'm curious: are there any schools out there that give unrestricted ARPA mail access to all their students (and will admit it)? Mark I think your problem lies not in restricting mail access through purdue to ARPA hosts, but in restricting mail access between machines. At MIT's undergraduate comp center (mit-eecs) students often need to communicate with their TA's via mail, who often keep accounts on other research machines on the chaosnet. Therefore, mail access to the chaosnet is allowed. It so happens that mail access to the ARPAnet is done via the chaosnet, so students have mail access to the ARPAnet as well. It seems that mail is considered generally harmless to the ARPAnet by those in a position to control access to it, so it was not disallowed. It certainly could have been disallowed, since general use of the chaosnet is not permitted for undergraduates (it requires a special bit which enables one to write to the cha: device which is the chaos network device on a DEC-20). Undergraduates are not allowed to make file transfers, telnet to other hosts, etc. unless they have that bit. Since mail works the same way, it could have been restricted the same way. The policy of the undergraduate comp center was (at least up until a couple of years ago) to deny chaosnet access to any undegraduates using the 20 unless they actually worked there as staff, consultant, or some other software support. With the growing number of undergraduate research opportunities at MIT, the number of chaosnet access bits increased (the only other way to get chaosnet access was to justify the need for it by having a non-guest account on another chaosnet machine). Nowadays many undergrads get chaosnet bits -- I'm not saying this is right or wrong, just the way things are. Speaking personally, having chaosnet access (implying ARPA access) benefitted me greatly as an undergrad because I was able to get useful technical information (unix-wizards, header-people, etc.) which I wouldn't have got otherwise until my undergrad years had just about ended. I wouldn't have known half of what I knew coming out of school without those bits. Many other MIT undergrads feel the same way -- I'll forward the question to some of them so you can hear from them. --gregbo gds@mit-xx.arpa gregbo%houxm.uucp@harvard.arpa {allegra,cbosgd,ihnp4}!houxm!gregbo -------  Message-Id: <8502241827.AA19782@merlin.ARPA> Received: by merlin.ARPA; Sun, 24 Feb 85 13:27:45 est To: Greg Skinner Cc: header-people@MIT-MC.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of Sun 24 Feb 85 12:07:04-EST. <8502241707.AA26342> Date: 24 Feb 85 13:27:40 EST (Sun) From: Christopher A Kent PLEASE! No more bleeding heart messages about why we shouldn't bother. If you have an answer to our question (that is, how do we erect firewalls in sendmail for those users that are not to have arpa access), please respond. Otherwise, don't waste our mailbox bandwidth. The decision to restrict or not to restrict is solely our own. We aren't fascists -- we merely know our user community. You don't. So let us make the decisions. As it is, all the users in question have access to Usenet, so they can get all the neat mailing lists that people have flamed about, at much less mailer bandwidth (one copy per site). Still looking for a technical answer, chris ----------  Date: Sun 24 Feb 85 13:20:43-PST From: David Roode Subject: Re: Firewalls in sendmail To: cak@PURDUE.ARPA, Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "Christopher A Kent " of Sun 24 Feb 85 13:27:40-PST Location: EJ286 Phone: (415) 859-2774 Many TOPS-20 sites establish BBOARD's which bring Unix-wizards, header-people, etc. to the user community in the same low-bandwidth way referred to in the last message as inherent in Usenet. Also, I think CAK missed the fact that GDS's message explained a different approach to accomplishing Purdue's goal. Namely users on backend machines can be blocked from network access (to local as well as ARPANET sites) either in general or according to type of network service (mail, FTP, Telnet, etc.) Even if this does not solve Purdue's problem, it seems like it might be useful information for other sites, and it does not say Purdue should not control access. -------  Date: Sun 24 Feb 85 13:20:43-PST From: David Roode Subject: Re: Firewalls in sendmail To: cak@PURDUE.ARPA, Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "Christopher A Kent " of Sun 24 Feb 85 13:27:40-PST Location: EJ286 Phone: (415) 859-2774 Many TOPS-20 sites establish BBOARD's which bring Unix-wizards, header-people, etc. to the user community in the same low-bandwidth way referred to in the last message as inherent in Usenet. Also, I think CAK missed the fact that GDS's message explained a different approach to accomplishing Purdue's goal. Namely users on backend machines can be blocked from network access (to local as well as ARPANET sites) either in general or according to type of network service (mail, FTP, Telnet, etc.) Even if this does not solve Purdue's problem, it seems like it might be useful information for other sites, and it does not say Purdue should not control access. -------  Message-Id: <8502242138.AA24713@merlin.ARPA> Received: by merlin.ARPA; Sun, 24 Feb 85 16:38:08 est To: David Roode Cc: header-people@MIT-MC.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of Sun 24 Feb 85 13:20:43-PST. <8502242121.AA01008> Date: 24 Feb 85 16:38:03 EST (Sun) From: Christopher A Kent To make things painfully clear: we have access control in place for all services except mail. We can't just turn off mail access, because we are a very "distributed" environment -- network mail is a basic fact of life for getting work done on campus. We need to be able to restrict mail from a certain class of users to a certain class of hosts, in sendmail. Does anyone have a method of doing this? chris ----------  Received: by bbnccv.ARPA (4.12/4.7) id AA07476; Sun, 24 Feb 85 20:17:23 est Message-Id: <8502250117.AA07476@bbnccv.ARPA> To: David Roode Cc: cak@purdue.ARPA, Gds@mit-xx.ARPA, header-people@mit-mc.ARPA Subject: Re: Firewalls in sendmail In-Reply-To: Your message of Sun 24 Feb 85 13:20:43-PST. <8502242134.AA06551@bbnccv.ARPA> Date: 24 Feb 85 20:17:19 EST (Sun) From: jsol@bbnccv The problem with using network access bits to control mail access is that you have to modify the deamon mailer to check each user for the bits involved. Without modifying sendmail source you will not be able to accomplish this. The configuration file simply doesn't take this into account. Before you go off writing patches to sendmail, think about the structure of sendmail and try to make something we can all use (i.e. make it a new feature to the sendmail.cf file). Cheers, --JSol  Received: from SCRC-CROW by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 184636; Mon 25-Feb-85 15:04:38-EST Date: Mon, 25 Feb 85 15:01 EST From: Robert W. Kerns Subject: Firewalls in sendmail To: GDS@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <850225150112.0.RWK@CROW.SCRC.Symbolics.COM> Date: Sun 24 Feb 85 12:07:04-EST From: Greg Skinner A minor problem with this first statement... It [CHAOS mail access] certainly could have been disallowed, since general use of the chaosnet is not permitted for undergraduates (it requires a special bit which enables one to write to the cha: device which is the chaos network device on a DEC-20). Undergraduates are not allowed to make file transfers, telnet to other hosts, etc. unless they have that bit. Since mail works the same way, it could have been restricted the same way. Untrue! Mail does not work the same way! The (implementation) reason students can send mail via the CHAOSnet is because it isn't THEY who send the mail, it's the mailer daemon, which is a part of the system. It would be rather difficult to restrict some people and not others, involving all sorts of issues of validation, etc. TOPS-20 is by no means unique in this regard, at MIT or elsewhere, nor is TOPS-20 the only system that undergraduates use. Putting in firewalls into every operating system on every machine that undergraduates have occasion to use is not likely to be worth the work, especially on systems that don't give you the sources to their mailer! And personal computers really make a mockery of these efforts, unless you care to forbid the connection of personal coputers to the network. This would certainly NOT be feasible at MIT! Also, it is not clear just what constitutes "undergrad use of the arpanet". If an undergrad sends mail to his TA, and his TA forwards his mail to MIT-Multics (quite reasonable), is it the undergrad or the TA that's using the network. What if the undergrad sends mail to HEADER-PEOPLE@XX, assuming XX has such a forwarding entry to MC? The policy of the undergraduate comp center was (at least up until a couple of years ago) to deny chaosnet access to any undegraduates using the 20 unless they actually worked there as staff, consultant, or some other software support. With the growing number of undergraduate research opportunities at MIT, the number of chaosnet access bits increased (the only other way to get chaosnet access was to justify the need for it by having a non-guest account on another chaosnet machine). Nowadays many undergrads get chaosnet bits -- I'm not saying this is right or wrong, just the way things are. Indeed, forbidding access on the basis of restricting individuals to mail between certain groups of users, certain machines, certain networks, or using any other arbitrary predetermined boundaries, is doomed to perpetual inappropriateness. Either you have to restrict communications that would be better left unrestricted, or you have to permit ones you did not intend. Speaking personally, having chaosnet access (implying ARPA access) benefitted me greatly as an undergrad because I was able to get useful technical information (unix-wizards, header-people, etc.) which I wouldn't have got otherwise until my undergrad years had just about ended. I wouldn't have known half of what I knew coming out of school without those bits. Many other MIT undergrads feel the same way -- I'll forward the question to some of them so you can hear from them. This is right on, although I don't think you made the point strongly enough. I think mail access is an ESSENTIAL part of the undergraduate curriculum. I don't want to hire a new grad who has just been exposed to the little world on MIT-EE, and who has no idea how to behave in the larger world. --gregbo gds@mit-xx.arpa gregbo%houxm.uucp@harvard.arpa {allegra,cbosgd,ihnp4}!houxm!gregbo -------  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 7 MAR 85 17:44:51 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656535304832326@MIT-MULTICS.ARPA>; 07 Mar 1985 17:28:24 est Date: 07 Mar 85 17:06 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA Cc: GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Checksum as a replacement for missing Message-ID. Message-ID: <94759@QZCOM> Checksum as a replacement for missing Message-ID. ------------------------------------------------ The Message-ID is a very useful field for many purposes: (a) To preserve In-reply-to references between transferred messages. (b) To stop loops by not accepting the same message to the same recipient more than once. (c) To be able to identify that several copies of the same message are the same, which will save disk space and provide better user functionality in some systems. The problem is that many messages do not have any Message-ID-s. I am planning to modify the COM network mail interface to generate Message-ID-s for messages which lack such ID-s. These generated ID-s will be used internally in COM and will be affixed to a message if it is sent out to the networks again, e.g. by a conference/mailing list residing on a COM system. The Message-ID should uniquely identify one message, so that all copies of the same message will get the same Message-ID. Thus, if two systems independently generate a Message-ID for a message, they should produce the same message. To achieve this goal, I suggest to generate the Message-ID as a checksum of the message. If two systems independently generate a Message-ID for a message, they should preferably produce the same ID. Thus, the ID should *not* refer to the host name of the message system generating the ID, if this is not the system where the message originated. Thus, I propose to generate Message-ID-s of the format where the host name in RFC822 is replaced by the word "CHECKSUM". This will tell recieving systems that this is a CHECKSUM-ed ID, so that they can identify it with other CHECKSUM-ed ID-s. The alternative would be to produce ID-s in the format . However, it does not seem nice to generate ID-s purporting to come from a host which did not in reality generate this ID. Selection of CHECKSUM algorithm: ------------------------------- The algorithm should uniquely identify a message with very low probability of different messages getting the same ID. On the other hand, the checksum should not change for common modifications to a message, like additions of new recipients in the RFC822 header, different line foldings or conversions of TAB-s to SPACE-s. The following algorithm is proposed: The CHECKSUM contains 15 characters, in three groups of five characters. The first group is computed from the name in the FROM field, the second group from the value in the DATE field, the third group is computed from the textual contents of the message. Each group should have a checksum algorithm suitable for that group. For the FROM field, I suggest the following: (a) Use only the value of the "addr-spec" part of the FROM field (delete the "phrase" part and the <>-s, if any). (b) Upcase the characters A-Z before checksum computation. (c) Only include characters A-Z and digits 0-9 in checksum computation. (d) Compute the checksum by summation of the characters, with the weight 1 to the first character, 2 for the second, 4 for the third etc. up to 2^16 for the sixteenth character, then 1 for the seventeenth etc. (e) Take the remainder of the checksum modulo 2^24. Translate this remainder to five characters in a 32-based number system with the digits 0...9, A..V. Rationale: This checksum should be easy to compute on any computer with 32-bit word integer arithmetic. For the DATE field, I suggest as checksum the number (((YEAR+SECOND+MONTH)*31+DAY)*24+HOUR)*60+MINUTE This number is again translated to a five character string as described in (e) above. For the contents of the message, all non-printable characters, including tab and space, should be disregarded when computing the checksum. The checksum is computed using the algorithm in stage (d) and (e) described above (but not stages a-b-c). Rationale: Disregarding all non-printable characters, including tab and space, is necessary to ensure that line folding will not change the checksum.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 7 MAR 85 17:45:09 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656535379002246@MIT-MULTICS.ARPA>; 07 Mar 1985 17:29:39 est Date: 07 Mar 85 22:16 +0100 From: Torgny_Tholerus_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Torgny_Tholerus_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA Cc: GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Checksum as a replacement for missing Message-ID. Message-ID: <94851@QZCOM> In-Reply-To: <94759@QZCOM> One problem I can see, is the DATE field. This field might look like: 13 Apr 83 17:43 BST. or: Wed Feb 20 16:07:15 1985 How do I do to find the year field or the month field? Perhaps is the best thing to treat the DATE field just like a string, in the same way as the FROM field is treated.  Received: from CMU-CS-A.ARPA by MIT-MC.ARPA; 8 MAR 85 11:24:12 EST Date: 8 Mar 85 1011 EST (Friday) From: Craig.Everhart@CMU-CS-A.ARPA To: Header-People@MIT-MC.ARPA Subject: Re: Checksum as a replacement for missing Message-ID. Sender: RdMail@CMU-CS-A.ARPA Reply-To: RdMail@CMU-CS-A.ARPA In-Reply-To: <94851@QZCOM> Message-Id: <08Mar85.101138.RD00@CMU-CS-A.ARPA> Why use the From: or Date: fields at all? The From: field is a popular candidate for editing by automatic agents; I'm not convinced that Mr. Palme's algorithm will remove all traces of that editing. The Date:-field algorithm was underspecified (year in century, as SMTP would have? What is the origin for months? Any use of time zone information?). For that matter, I'm not sure that all agents would agree on the concept of ``printing character'' in the body of the message. Why not use an algorithm based solely on the body of the message? It can ignore characters outside the range [33,126] (decimal, inclusive); obviously it would only count characters in that range when incrementing the checksum counter. It may be less expensive to use something other than multiplication as a basis for the checksum on many small machines. Are there suitable algorithms based on bit rotations or shifts? And perhaps the whole discussion should be moved into an RFC.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 8 MAR 85 21:53:54 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656633759076531@MIT-MULTICS.ARPA>; 08 Mar 1985 20:49:19 est Date: 08 Mar 85 18:44 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA Cc: GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Checksum as a replacement for missing Message-ID. Message-ID: <95013@QZCOM> In-Reply-To: <94851@QZCOM> The reason I choose not to treat the date field as a string, is that the checksum should not change if the date field is translated from one format to another, e.g. from the format in RFC822 to the format in X.400. This of course requires that the date field is parseable. But every single message should, when you get it, have a header in one given standard and thus date fields not belonging to this standard should not occur. One problem is the time zone. Since the format of this seems to be often wrong, I did not include it in the checksum. This means that if the time is translated to another time zone, e.g. if the date "25 Feb 85 15:01 EST" is translated by some agent handling the message into "25 Feb 85 12:01 PST" then the algorithm will create a different checksum. Question: Would such translations of dates by message handling agents be expected to occur?  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 9 MAR 85 15:09:14 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656699596857652@MIT-MULTICS.ARPA>; 09 Mar 1985 15:06:36 est Date: 09 Mar 85 12:55 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Checksum as a replacement for missing Message-ID. Message-ID: <95136@QZCOM> In-Reply-To: <08Mar85.101138.RD00@CMU-CS-A.ARPA> FROM: William "Chops" Westfield Why is it necessary for two hosts trying to create a MESSAGE- ID to come up with the same result? I dont understand why anyone but the original host would try to create a message id... If the original host always created Message-Id-s, this would be a better solution. We will however have to accept the fact that some hosts do not create globally unique Message-ID-s. Neither RFC822 nor X.400 unfortunately require mandatory globally unique Message- ID-s (IPMessageID-s in X.400 terminology). Suppose one and the same message gets forwarded, directly or indirectly, to two different mailing lists, and that a certain user is a member of both lists. If the intermediate hosts handling the mailing list created a checksum, this could be used by the host for the recipient user to stop displaying the same message twice, or, to tell him that it is the same message which he gets twice. Why should the intermediate host add a Message-ID to a message lacking such an ID? Because the ID is very useful for loop control. If two mailing lists are members of each other (which has advantages, but cannot be done with present practices on Arpanet because of the risk for loops) then if the list maintaining program kept a list of the ID-s of messages sent via the list (COM does this) then it could stop re-sending the message when it comes around the second time. FROM: Craig.Everhart@CMU-CS-A.ARPA Why use the From: or Date: fields at all? The From: field is a popular candidate for editing by automatic agents; I'm not convinced that Mr. Palme's algorithm will remove all traces of that editing. The Date:-field algorithm was underspecified (year in century, as SMTP would have? What is the origin for months? Any use of time zone information?). The goal of course is to find an algorithm with a very very low probability of getting the same ID for two different messages, but also with low probability of giving different ID-s for the same message because of some transformation on the message. Only using TEXT CONTENT is NOT acceptable. Suppose in a voting application that two people wrote messages with the only content being the word "Yes!". Only using TEXT CONTENT would hide the very important fact of the names of the people who voted "Yes!". Not using Date/time is also not acceptable, suppose the same person voted "Yes!" on two different issues, this fact would then be hidden. FROM: Craig.Everhart@CMU-CS-A.ARPA It may be less expensive multiplication as a basis for the checksum on many small machines. Are there suitable algorithms based on bit rotations or shifts? Most of the multiplications in my algorithm (all of those in processing the body of the message) were by powers of 2 thus can be implemented by shifts.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 12 MAR 85 05:11:58 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656923154852744@MIT-MULTICS.ARPA>; 12 Mar 1985 05:12:34 est Date: 11 Mar 85 01:57 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Checksum as a replacement for missing Message-ID. Message-ID: <95256@QZCOM> In-Reply-To: <95136@QZCOM> A further reason why it is necessary to create a Message-ID for a message which does not have any: Checksums are necessary in order to preserve in-reply-to-relations between pairs of messages which may be transmitted between hosts via different routs. Example: Host A sends out a message M1 to hosts B and C. at host B, a reply M2 is written and sent to host B. In order for host B to be able to recognize that M2 is a reply to M1, A and B must independently generate the same Message-ID on M1. Question: Why did I not include the value of the in-reply-to field in the creation of the checksum. Answer: Because some systems may allow the addition of an in-reply-to field after the creation of a message. (At least we do. We sometimes get messages which clearly are replies to other messages, but which do not have in-reply-to fields. I sometimes then add an in-reply-to reference to the incoming message, since the sorting of the message data base through in-reply-to-relations makes it easier to use.)  Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAR 85 01:26:11 EST Date: Tue 19 Mar 85 01:26:34-EST From: Gregbo Subject: arpa/usenet gatewaying To: info-nets%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC Could we hack inews and sendmail so that if there is a user-created Newsgroups: header that it would forward through the arpa/usenet gateway and be picked up by inews, to distribute the mail in the specified newsgroup? It doesn't sound like too hard a thing to do, and it would solve the problem of people sending things to info-micro from ARPA but really want them in net.micro.xxx. Actually, I should include MMDF, since the primary gatewaying host runs it, however I don't know MMDF. typical scenario: To: info-micro@brl.arpa Subject: 6809 article Newsgroups: net.micro.6809 ... text ... when it passes to the gateway, sendmail picks it up, notices that it has a Newsgroups: line in it (maybe /bin/mail could do this, instead), and forks inews -h -n with the mail as the standard input. (For those not in the know, inews is the program which is run that installs a news article at a site and causes the article to propagate around the net. the -h flag indicates that the file contains headers, which should come from the mail.) If no one has tried this, I might fool around with the idea, to see if it has any merit. --gregbo gds@mit-xx.arpa gregbo%houxm.uucp@harvard.arpa {allegra,cbosgd,ihnp4}!houxm!gregbo -------  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 21 MAR 85 09:28:59 EST Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2657693370179793@MIT-MULTICS.ARPA>; 21 Mar 1985 03:09:30 est Date: Wed, 20 Mar 85 17:02:56 EST From: "J. Gordon Beattie Jr." <2990@NJIT-EIES.MAILNET> To: header-people@mit-mc Subject: TCP/IP: How to make it go ? Message-ID: I have a few questions for the TCP/IP jockeys. I would greatly appreciate any answers. 1. What link level protocols are typically used under IP ? 2. What link level protocols are used in the ARPANET ? 3. What link level protocols are used in the Defense Data Network ? 4. What upper level protocols are used on the above to handle any of the following: 1. Host to Host batch file transfers 2. User terminal to Host file transfers (or the reverse) 3. Interactive user terminal to host transfers 4. Mail 5. Shared database transfers ? I am also curious to know how two TCP's arbitrate the size of the total message sent. If segmented can it get large ? If yes then how does it keep from getting too large for the machine ? Does any of this matter ? Thanks for your assistance and time. Gordon Beattie 2990@NJIT-EIES.MAILNET  Received: from USC-ISIF.ARPA by MIT-MC.ARPA; 12 APR 85 21:13:48 EST Date: 12 Apr 1985 18:07:19 PST From: POSTEL@USC-ISIF.ARPA Subject: SMTP for WANG ??? To: header-people@MIT-MC.ARPA Return-Path: Received: FROM HI-MULTICS.ARPA BY USC-ISIF.ARPA WITH TCP ; 12 Apr 85 09:17:54 PST Posted-Date: 12 Apr 85 11:17 CST Date: Fri, 12 Apr 85 11:14 CST From: "Paul D. Stachour" Subject: Info on SMTP interface with WANG To: POSTEL@USC-ISIF.ARPA Message-ID: <850412171433.023457@HI-MULTICS.ARPA> Jon, I've had a query from a fellow Honeyweller who use a WANG OIS. He'd like to know if there is a SMTP interface available, either for that or Wang's WPS or VS, which he also has access to. While he'd perfer to know about an offically supported one, or plans for same, he'd like to know about in user-effortt as well. Can you give me a pointer, or tell me which mailing-list would be best for me to send the query to? Thanks, ...Paul Stachour -------  Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 21 May 85 17:49:12 EST Date: Tue 21 May 85 14:45:59-PDT From: Mark Crispin Subject: AMES-VMSB and ".decnet" domain To: Header-People@MIT-MC.ARPA cc: Postmaster@AMES-VMSB.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Calling the Protocol Police! See enclosed message header. Can't SOMEBODY talk to the AMES people and convince them that "max.decnet" is not a valid domain name? According to Hartman, the AMES mail maintainer insists that "max.decnet" is the right thing to be sending out. I have no idea who this shadowy person is -- I asked Hartman to put me in touch with this individual back when it was first announced that they were going to "upgrade" their mailer to one which had the "official" Internet mailboxes in "<@ames-vmsb.arpa:hartman@max.decnet>" format. No luck. The most I heard was a nasty comment to the effect that I obviously had not read RFC 821/822. Folks, I think it is time to revise the mailer standards again. Not change anything (let's have that as an EXPLICIT instruction for the committee), just to rewrite out the ambiguities which lead to this sort of lossage. -- Mark -- Enclosure, for your inspection and amusement: Return-Path: <@ames-vmsb.arpa:hartman@max.decnet> Received: from ames-vmsb.arpa.ARPA (AMES-VMSB.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Tue 21 May 85 11:37:42-PDT Date: 21 May 85 10:00:00 PDT From: MAX::HARTMAN Subject: --- checksumming --- To: info-atari Reply-To: MAX::HARTMAN [Message text deleted] -Richard Hartman max.hartman@ames-vmsb ------ -------  Received: from USC-ISIF.ARPA by MIT-MC.ARPA; 21 May 85 19:02:29 EST Date: 21 May 1985 15:21:58 PDT From: POSTEL@USC-ISIF.ARPA Subject: re: strange domains (e.g., "decnet") To: header-people@MIT-MC.ARPA cc: postmaster@AMES-VMSB.ARPA All domain names must be registered with the NIC and meet some other requirements. The requirements are spelled out in RFC-920. --jon. -------  Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 21 May 85 19:10:16 EST Date: Tue 21 May 85 15:44:15-PDT From: Mark Crispin Subject: Re: AMES-VMSB and ".decnet" domain To: ron@BRL.ARPA cc: Header-People@MIT-MC.ARPA, Postmaster@AMES-VMSB.ARPA In-Reply-To: Message from "Ron Natalie " of Tue 21 May 85 15:43:14-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Ron - You know that, I know that, but try to convince the AMES people of that!!! -- Mark -- -------  Received: from BRL by MIT-MC.ARPA; 21 May 85 20:29:32 EST Date: Tue, 21 May 85 18:10:39 EDT From: Ron Natalie To: Mark Crispin cc: Header-People@MIT-MC.ARPA, Postmaster@AMES-VMSB.ARPA Subject: Re: AMES-VMSB and ".decnet" domain "<@ames-vmsb.arpa:hartman@max.decnet>" is no more legal than  Received: from Xerox.ARPA by MIT-MC.ARPA; 22 May 85 04:11:18 EST Received: from Cabernet.MS by ArpaGateway.ms ; 22 MAY 85 01:08:02 PDT Date: 22 May 85 01:06:43 PDT From: Murray.pa@Xerox.ARPA Subject: Domain names In-reply-to: "MRC@SU-SCORE.ARPA's message of Tue, 21 May 85 14:45:59 PDT" To: Header-People@MIT-MC.ARPA Cc: Murray.pa@Xerox.ARPA As long as we are screaming about bogus names, I'll remind everybody that there are lots and lots of systems out there that still think their name is foo rather than foo.ARPA. Anybody fixing their code to use domain names had better include some hackery to default things to .ARPA if nothing better makes sense.  Received: from Xerox.ARPA by MIT-MC.ARPA; 22 May 85 15:46:02 EST Received: from Cabernet.MS by ArpaGateway.ms ; 22 MAY 85 12:40:19 PDT Date: 22 May 85 12:40:11 PDT From: Murray.pa@Xerox.ARPA Subject: Names with spaces To: INFO-NETS@MIT-MC.ARPA, Postmaster@MIT-MC.ARPA, MsgGroup@BRL.ARPA, HEADER-PEOPLE@MIT-MC.ARPA Cc: Murray.pa@Xerox.ARPA, Hamilton.OSBUSouth@Xerox.ARPA A month or so ago, Bruce sent an innocent msg to INFO-NETS that caused a lot of confusion. It seems as though lots of systems out there crashed every half-hour or so whenever MC tried to (re)transmit Bruces' msg on to them. The error message was something like "no closing quote". I think some systems can't tolerate mismatched quotes in the From field of the header, and MC managed to drop one. I think the From line looked like this when it left here: From: "Bruce A. Hamilton.OsbuSouth"@Xerox.ARPA The line that was killing CIT-VAX was: From: Can anybody fill me in on the fine print? Is there something special about the From line, or will any header line containing mismatched quotes cause the same problem? Any reason why it crashes the system instead of logging a message and blundering on? The only victim I've been in contact with is CIT-VAX. I think they are running a vanilla 4.2BSD. How many other systems got cought by the same bug? Did your system crash? Is there a reasonable bug fix? Any hope of fixing MC? ... Sending mail that crashes systems is high on my list of things not to do, especially when you can kill many systems with only one message. Currently, I have a filter installed that rejects any outgoing msg if the From field needs quoting. Is that good enough? (If you want a test case, just let me know.) ----- Part of our mail system makes heavy use of spaces in names. I'm getting a lot of flak about rejecting all these messages. We started seriously using quoted names with spaces early this year. There were various bugs that had to be fixed, both here and at other sites nearby where we exchange lots of mail. Things calmed down after a while. Then Brian Reid started complaining. He is the postmaster at a site that was relaying some of our mail on to the UUCP world. Several of the next layer of machines didn't know about quotes, and the rejections were landing in Brian's mailbox. I "solved" that one by translating all the spaces to underbars in the return-path in the envelope. I did that because I "knew" that none of our names contained any underbars so I could make the reverse translation without fear of breaking anything. Is the space/underbar substitution universal enough that I can do it to the whole header without fear of mangling some address that really should have a space in it? I haven't yet managed to convince myself that I won't provoke a really obscure problem if I just blindly "fix" all the quoted spaces to/from underbars. Have all the (flakey) Unix systems out there established a de-facto addendum to RFCs 821/822 that prohibits quoted strings? ----- Does/will the X400 world have spaces in names, or will there be spaces in names by the time they get mapped/translated into RFC 821/822 format?  Received: from SRI-CSL.ARPA by MIT-MC.ARPA; 22 May 85 17:24:07 EST Date: 22 May 1985 14:11-PDT Sender: GEOFF@SRI-CSL Subject: Re: Names with spaces From: the tty of Geoffrey S. Goodfellow To: Murray.pa@XEROX Cc: INFO-NETS@MIT-MC, Postmaster@MIT-MC, MsgGroup@BRL Cc: HEADER-PEOPLE@MIT-MC, Hamilton.OSBUSouth@XEROX Message-ID: <[SRI-CSL]22-May-85 14:11:11.GEOFF> In-Reply-To: The message of 22 May 85 12:40:11 PDT from Murray.pa@XEROX.ARPA Hal Implementing "solutions" like changing spaces to underbars just to keep people's mailers which can't grok legal protocol from crashing seems inappropriate to me, at least in the long term. If quoted spaces are indeed legal to send, well send them for heavens sakes. If they crash people's mailers, then those mailers should be fixed -- plain and simple. All it takes is one wizard to discern the fix, post it, and everyone else should follow suit. Thank goodness its a solid bug you've found, and not one that would cause peoples mailer's to crash on every 3rd message to come by with a quoted space when there's a full moon out or something like that. g  Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA; 22 May 85 19:47:12 EST Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 22 MAY 1985 19:38:38 EDT Date: Wed, 22 May 85 16:14 PST From: Dave Platt To: Header-People Subject: Names with spaces, underscores, quoted names, etc. We've had a slightly similar experience with our SMTP interface. By way of introduction: we (Honeywell's Los Angeles Development Center) run our own O/S (CP-6) and mail package ("MAIL" - clever, no?) and speak to the outside world via SMTP over an X.29 link to an ARPA-node Multics site in Cambridge. We look to the outside world like a "local part" of CISL-SERVICE-MULTICS. From what I've learned, the Multics SMTP software has only a partial implementation of quoted names... it can accept quoted names in the "local part" of a simple address, but not in a more complex address with routing information included. Eg., <"Dave Platt"@LADC> will work, but their receiver barfs on <@CISL-SERVICE-MULTICS.ARPA:"Dave Platt"@LADC>. Their software doesn't crash, it just rejects the address as being illegal. For this reason (and because we've been told that many mailers cannot generate quoted names or handle names that contain blanks) we've gone to a scheme such as that mentioned earlier - when we send mail outwards, our mailer converts all embedded blanks into hyphens; when we receive, the receiver looks up the name as given by the sender, and if it doesn't find it then maps hyphens into blanks and tries again. Most mailers seem to be able to handle names with hyphens, and we've had generally good luck with this scheme. It does seem a shame, though, that so many mailers don't accept a legal construct. We've found it much more practical to modify our own software so that its output is acceptable to the "lowest common denominator", rather than expecting everybody to handle every construct permitted by the RFCs... unfortunate, but that seems to be the way the world is working these days.  Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA; 22 May 85 21:06:13 EST Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 22 MAY 1985 21:02:30 EDT Date: Wed, 22 May 85 17:56 PST From: Dave Platt To: Header-People Subject: And, speaking of bad headers (blush!) my flying fingers put a bug into our mailer's configuration file; it decided that MIT-MC (which uses the ARPA node tables) is the same thing as MIT-MULTICS (which knows about us of its own free will), so my previous mailgram had a From: address which isn't usable by anybody on the net. Sorry, folks.  Received: from rand-unix.ARPA by MIT-MC.ARPA; 22 May 85 21:36:42 EST Received: by rand-unix.ARPA; Wed, 22 May 85 18:07:23 pdt From: Steve Tepper Message-Id: <8505230107.AA22510@rand-unix.ARPA> Date: 22 May 85 18:07:15 PDT (Wed) To: INFO-NETS@mit-mc, MsgGroup@brl, HEADER-PEOPLE@mit-mc Subject: Re: Names with spaces I will seize the current fracas about spaces in names as an opportunity to give vent to a long-standing gripe, which has to to with network protocols in general but is a particularly sore point when it comes to mail. My complaint is that, given the lack of any network police, the decision as to who has to change what to make it work with something else is often more of a political question than a technical one. Typically the scenario is something like this: User Foo@FooHost wants to send mail to Bar@BarHost. Now it turns out that the person who maintains the software used at BarHost (who likely doesn't even work there, unless BarHost is a one-of-a-kind operating system) has decided to "improve" the mail system in some way which is uncontestably at variance with the standard, with the result that some mail breaks. A cleanliness freak would, justifiedly, state flatly that the burden is on either BarHost or their software maintainer to get it fixed. The reality is unfortunately different. It may be that Bar@Barhost is Foo's project sponsor, or someone else of sufficient stature that Foo considers the ability to communicate electronically with Bar a high-priority matter. Complaining that the problem is at BarHost may be morally satisfying but does not get the message delivered, especially if the person who made the offending change is obstinate and claims that his "improved" version is so obviously superior that it is incumbent on the rest of the world to mimic his changes until they become a de facto standard. The outcome: some poor soul at FooHost has to figure out what BarHost's mail server is now willing to accept and hack up FooHost's mailer to accomodate it, without disrupting other mail services from FooHost in the process. I am exerting considerable restraint here by refraining from mentioning the names of any guilty parties (and all the cases I dealt with were too far in the past to be of any immediate concern), but I'm sure other people have also found themselves in the unpleasant situation of being the person who had to "fix" something to accomodate someone else's non-standard "improvements".  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 23 May 85 00:38:04 EST Date: Thu, 23 May 85 00:18 EDT From: Barry Margolin Subject: Re: Names with spaces To: Murray.pa@XEROX.ARPA cc: info-nets@MIT-MC.ARPA, MsgGroup@BRL.ARPA, header-people@MIT-MC.ARPA, Hamilton.OSBUSouth@XEROX.ARPA Message-ID: <850523041830.813992@MIT-MULTICS.ARPA> To answer the question that appeared at the end of the original message, X.400 should not have any problems in this respect. X.400 messages are binary data structures, and the protocols between mailer processes are also binary messages. There is no text parsing involved. For instance, rather than having a mailer daemon transmit Character strings are encoded as a type word followed by a length byte followed by the specified number of characters (I am purposely simplifying, leaving out things like the character set identifier). No ambiguity is possible within the protocol (of course, user interfaces are another problem, as they must translate between this form and printed form). barmar  Received: from WISCVM.ARPA by MIT-MC.ARPA; 23 May 85 03:00:17 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 05/23/85 at 01:57:45 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 7444; Thu, 23 May 85 09:41:21 IDT Date: Thu, 23 May 85 09:33 IDT From: Henry Nussbacher Subject: Lack of domain name To: , Steve, I couldn't agree with you more. But when I tried to send a reply to you, I looked at the the header I received: > Received: from MIT-MC by wiscvm.arpa on 05/22/85 at 20:51:13 CDT > Received: from rand-unix.ARPA by MIT-MC.ARPA; 22 May 85 21:36:42 EST > Received: by rand-unix.ARPA; Wed, 22 May 85 18:07:23 pdt > From: Steve Tepper > Message-Id: <8505230107.AA22510@rand-unix.ARPA> > Date: 22 May 85 18:07:15 PDT (Wed) > To: INFO-NETS@mit-mc, MsgGroup@brl, HEADER-PEOPLE@mit-mc > Subject: Re: Names with spaces My mailer (and I doubt any mailer), can discern who 'rand-unix' is. It could be a node in csnet, it could be a node in mailnet but it happens to be a node in Arpanet. I have found very often that nodenames in Bitnet are the same as nodenames in Arpanet and quite often they are not on the same host. A fully qualified return address to you is 'greep@rand-unix.arpa'. I'm sure mail handlers in other domains other than Arpanet have the same problem and usually the user either hand massages the 'To:' field or the mail gets bounced because rand-unix is undefined. People who live in accelerators shouldn't throw electrons! Hank  Received: from BRL by MIT-MC.ARPA; 23 May 85 16:15:42 EST Date: Thu, 23 May 85 14:18:45 EDT From: Ron Natalie To: Steve Tepper cc: INFO-NETS@MIT-MC.ARPA, MsgGroup@BRL.ARPA, HEADER-PEOPLE@MIT-MC.ARPA Subject: Re: Names with spaces AHEM. Can we please get this discussion down to only one group please.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 24 May 85 19:58:51 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2663279796372244@MIT-MULTICS.ARPA>; 24 May 1985 19:56:36 edt Date: 24 May 85 09:10 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Domain names defaulting Message-ID: <106044@QZCOM> In-Reply-To: <105893@QZCOM> Exactly! And the most important mailers to be fixed are the ones acting as gateways into other netoworks - compared to postal addresses we all know that Country is only required when addressing someone outside current country, and can well be left out while inside. This simple analogy should hold for E-mail too.  Received: from WISCVM.ARPA by MIT-MC.ARPA 29 May 85 11:25:04 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 05/29/85 at 10:05:02 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6389; Wed, 29 May 85 17:53:09 IDT Date: Wed, 29 May 85 17:46 IDT From: Henry Nussbacher Subject: Fully qualified nodenames To: For your amusement: > ----------------------- > Received: from NYU-CMCL2.ARPA by wiscvm.arpa on 05/29/85 at 08:57:34 CDT > Received: from NYU-CSD2.ARPA (nyu-csd2.arpa.ARPA) by NYU-CMCL2.ARPA; Wed, 29 > May 85 09:56:57 edt > Message-Id: <8505291356.AA29206@NYU-CMCL2.ARPA> > Received: by NYU-CSD2.ARPA; Wed, 29 May 85 09:55:11 edt > Date: Wed, 29 May 85 09:55:11 edt > From: xxxxxx@NYU-CSD2 > To: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA > Subject: Re: VMNAMES & fully qualified return paths. > > > I am sorry that I have used VMNAMES from a node which does not supply a > fully qualified return address. Sorry for inconvenience. > > > However, it might be interesting for you to know that some Bitnet sites > have mailers capable of recognizing Arpanet (& other) addresses, though > they are not actually residing at gateway nodes. > A primary example of that is MAILER@CUNYVM (and, for that matter, MAILER@ > BITNIC). It would be helpful if more Bitnet nodes had this capability. > It is also very reassuring to know that, as soon as the VMNAMES program > is "migrated" to Bitnic, all the poor people from Arpanet whose mailers > don't specify a fully qualified return address will be able to get their > information painlessly. (Moreover, as Bitnic becomes an Arpanet node in the > near future, the whole procedure will be simplified considerably). > > > ------------------------- > Date: Wed, 29 May 85 17:24 IDT > From: Henry Nussbacher > Subject: Re: VMNAMES & fully qualified return paths. > To: > In-Reply-To: Your message of Wed 29 May 85 09:55:11 edt > > I accept your answer but still think NYU is wrong. What CUNYVM and > BITNIC do is a crutch and a harmful one at that. When I send a letter > from NYC to Cambridge England, I had better put in the country - England, > otherwise the postman will assume I mean Cambridge, Mass. Most postmen > will just make the letter - 'return to sender' and not try to make > "assumptions" about what country the person meant. > > This becomes very painful when a node on Arpanet has the same name as > a node on Bitnet. Example: RICE. It is a valid node in Bitnet and > a completely different machine and host in Arpanet. I don't think > Arpanet and Bitnet care to have their hostnames validated by each other. > > Still think NYU-CSD2 is better (and easier) than NYU-CSD2.ARPA? > > Hank There you have it. Please note that it is not CUNYVM's fault for accepting unqualified nodenames. It is just that since one node has the capability of doing it (and only getting it right 95% of the time - due to duplicates of nodenames and the constant problem of having to update their tables to reflect new Arpanet sites), people assume all sites in Bitnet can do it. Someone joked before about 'network police'; maybe there should be some network header police and those nodes that don't conform to standards be dropped from the Internet Host Table. Hank  Received: from decwrl.ARPA by MIT-MC.ARPA 30 May 85 11:46:34 EST Received: by decwrl.ARPA (4.22.01/4.7.34) id AA06731; Thu, 30 May 85 08:46:43 pdt Received: by deccra.hudson (4.12/5.1.GaTech) id AA08099; Thu, 30 May 85 10:09:48 edt Date: Thu, 30 May 85 10:09:48 edt From: System Manager Posted-Date: Thu, 30 May 85 10:09:48 edt Message-Id: <8505301409.AA08099@deccra.hudson> To: header-people@mit-mc.ARPA Subject: address change If you have a ...!maynard!campbell on your mailing list, please change it to LCampbell@mit-mc (it may have been changed or deleted already, in which case please ignore this message). Thanks!  Received: from Xerox.ARPA by MIT-MC.ARPA 30 May 85 15:43:14 EST Received: from Semillon.ms by ArpaGateway.ms ; 30 MAY 85 12:41:05 PDT Sender: "Albert C. Hall.osbunorth"@Xerox.ARPA Date: 30 May 85 12:40:52 PDT (Thursday) Subject: Header-People and X.400 From: AlHall.osbunorth@Xerox.ARPA To: Header-People@MIT-MC.Arpa cc: AlHall.osbunorth@Xerox.ARPA Message-ID: <850530-124105-1371@Xerox> Do any of you depend upon the ordering of ARPA headers ? The answer to this question would help me decide how much of the "extra" information of the ARPA header needs to be preserved when the header is parsed into X.400 Attributes. For example, I assume that a set of Received: fields should be kept in order, but does it make a difference to anyone if the entire block was moved to, say, the end of the ARPA header ? Thanks, Al  Received: from USC-ISIF.ARPA by MIT-MC.ARPA 30 May 85 17:08:25 EST Date: 30 May 1985 14:00:34 PDT From: POSTEL@USC-ISIF.ARPA Subject: ARPA-Mail and X.400-Mail To: Header-People@MIT-MC.ARPA Al Hall: I am not sure i followed your question, but if you mean something like "Is it ok to send a message via ARPA-mail with a block of "Recieved" lines at the end of the header instead of the beginning of the header?", then I'd say no. One common problem in the world of mail is that each person that builds a relay or forwarder asssumes that his relay is the one making the "final" delivery to the end recipient, so it doesn't matter if he bends the rules a little. --jon. -------  Received: from BRL-SEM.ARPA by MIT-MC.ARPA 30 May 85 18:05:13 EST Date: Thu, 30 May 85 16:13:06 EDT From: Doug Kingston To: "Albert C. Hall.osbunorth"@xerox.ARPA cc: Header-People@mit-mc.ARPA, AlHall.osbunorth@xerox.ARPA Subject: Re: Header-People and X.400 Ordering of Received lines should be preserved. Although they are normally dated, having them in order prevents confusion and protects against bad dates. -Doug-  Received: from rand-unix.ARPA by MIT-MC.ARPA 1 Jun 85 02:25:00 EST Received: by rand-unix.ARPA; Fri, 31 May 85 23:18:23 pdt From: Steve Tepper Message-Id: <8506010618.AA09711@rand-unix.ARPA> Date: 31 May 85 23:18:16 PDT (Fri) To: AlHall.osbunorth@xerox.ARPA Cc: Header-People@mit-mc Subject: Re: Header-People and X.400 In-Reply-To: Your message of 30 May 85 12:40:52 PDT (Thursday). <850530-124105-1371@Xerox> Following the general guidelines about being a "strict constructionist" about what you send but a "liberal" about what you accept, you should be prepared to accept out-of-order "received" fields from other hosts. I'm pretty sure I've seen mail come in with "received" fields out of order (i.e. after other fields, not just out of chronological order among themselves), so it's a pretty safe bet that you'll get in trouble if you count on everyone doing the right thing.  Received: from ucla-locus.arpa by MIT-MC.ARPA 1 Jun 85 16:03:28 EST Date: Sat, 1 Jun 85 12:45:23 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Re: RFC822/X.400 header transformations References: Message of 30 May 85 12:40:52 PDT (Thursday) from "AlHall.osbunorth@Xerox.ARPA" <850530-124105-1371@Xerox> Message-ID: <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU> I believe that anyone who realistically hopes to take an RFC822-style header, translate it into another form (X.400, internal data structure, etc.), and then later translate that other form back into the original RFC822-style header (or a completely equivalent header -- whatever THAT means!), is taking his life in his hands. The main problem is that RFC822 is an attempted compromise between a mail-agent "transmission" standard (i.e., program-oriented) and a user- agent "presentation" standard (i.e., human-oriented). In actual prac- tice, neither need is really fulfilled satisfactorily. Please understand that I am not criticizing those involved in designing RFC822 for doing things this way. When 822 was being put together, the realities of the ARPANET E-mail world were such that any radical effort to introduce a totally new "transmission" format along the lines of the NBS or X.400 standards would have been violently opposed -- or simply ignored. (Witness the fact that many sites, even now, continue to dis- regard the proper RFC822 format of a "Date:" line!) What I think we really need is an eventual conversion to a fixed-form "transmission" standard for electronic mail. The X.400 standard, which seems to be gaining popularity elsewhere, might be a good choice (though I admit I haven't thoroughly studied X.400 yet and cannot say for sure whether it truly meets our community's needs). Being (or at least try- ing to be) a realist, however, I understand that a conversion to X.400 is not liable to happen very soon (and, inertia in certain circles being what it is, may possibly never happen at all). I would therefore propose as a stopgap measure that the existing RFC822 format be "tightened" by defining a complete, exact mapping between RFC822 headers and X.400 headers. Such a definition would specifically allow any host, anywhere along the line of delivery of a given message (including relay hosts), to convert any RFC822-style header into the equivalent X.400 form -- and back again -- without any loss of essential information. (1) An exact definition of the semantics of RFC822, and a strict policy on what details are and are not important in a header, would enable a host (if it wished) to store the header ONLY in an internal form. The current philosophy that a relay should not "digest" and later "reconstruct" a header is, I feel, symptomatic of the fact that there is currently no agreement on precisely what the various parts of an RFC822 header really mean. (2) Another reason to define an exact RFC822<->X.400 mapping is that, in the next several years, we might find ourselves obligated (either by practicality concerns or decrees from above) to conform to X.400 or some other "international" standard. Witness, for instance, the current talk about eventual abandonment of TCP in favor of ISO TP-4 (see RFC942). Defining a detailed correspondence between RFC822 and X.400 -- NOW -- would help bring to light any aspects of RFC822 which we have up to now considered indispensable, but which are not adequately ad- dressed by the X.400 standard. One example which comes to mind is the question of time zones in date/time strings (X.400 doesn't provide for the commonly used time zone abbreviations, allowing instead only the letter "Z" for UTC, or a "+/-hhmm" numeric zone specifier for other zones). What should we do about the fact that an X.400 time strings cannot distinguish, for instance, between PDT and MST (since both have to be changed to the single form "-0700")? We owe it to ourselves to be fully aware of all such issues now. We might or might not be able to change the character of the eventual standard to better suit our tastes and needs, but we certainly are not going to be able to have any say if we don't even know where all the problem areas are. Some issues which should probably be addressed when defining the "offi- cial" correspondence between RFC822 and X.400 headers are the following. (This is NOT intended to be an all-inclusive list.) (1) Ordering of lines in a header. Line order should certainly be preserved in some cases (e.g., the relative order of "Received:" lines should be preserved) -- but I am hard pressed to think of a convincing technical reason why the rela- tive ordering of such lines as "Date:", "From:", and "Subject:" is critical. For that matter, I don't see any reason why the placement of the block of "Received:" lines in the header (at the beginning, at the end, or in the middle) should be important at all from the stand- point of a transmission standard. In most cases, I suspect we will find that the relative sequence of header lines of different types is really completely unimportant. (2) Date lines. I already mentioned the question of representation of time zones in X.400. My other "pet peeve" is that I simply don't understand what excuse anyone has for continuing to output date strings that don't conform exactly to RFC822. At the VERY least, no one who generates a nonstandard date string format should have any right to complain if a relaying site converts such a date string into the standard form (or even if the relaying site kicks the whole message back in the face of the sending site because of a fatal format error!). (3) Comments in header lines. This, I think, is one of the most difficult aspects of RFC822 to deal with. In theory, comments are supposed to be absolutely and completely equivalent to white space. In actual practice, however, "comments" are used to supply full names, portions of full names, days of the week, additional host ID information in "Received:" lines, and who knows what other kinds of essential data. The problem is compounded by the fact that RFC822 allows comments to be used virtually anywhere at all in a header line. This renders any serious attempt to parse a header, while retaining all the data contained therein (comments included), ludicrously awkward. I would strongly advocate that ALL such "semantic" uses of comments in RFC822 headers be phased out. When converting an RFC822 header into another form, a receiving or relaying host should be able to simply throw away comments, without worrying that something valuable (such as the sender's full name) has thereby been lost. Let me emphasize that I am NOT advocating the introduction of new fea- tures or constructions not already in RFC822. I am simply suggesting the formulation of a "standard" or "canonical" subset of RFC822, into which any header could safely/legally be mapped without loss of any im- portant information. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@UCLA-LOCUS.ARPA -or- wales@LOCUS.UCLA.EDU UUCP: ...!(ihnp4,ucbvax)!ucla-cs!wales  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 2 Jun 85 15:33:44 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664041458856405@MIT-MULTICS.ARPA>; 02 Jun 1985 15:30:58 edt Date: 02 Jun 85 13:56 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Cc: COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: RFC822/X.400 header transformations Message-ID: <107311@QZCOM> In-Reply-To: <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU> Thank you for your presentation on the problem of RFC822/X.400 header transformation, where you gave lots of valuable ideas. Here are some additional points to think about in this area: EXISTING IMPLEMENTATIONS: There are several existing projects working on such transformation. There is the EAN system, and there are projects in Germany and the U.K. to make gateways between EARN/BITNET, which uses RFC822 headers, into X.400. It would be very valuable if the people behind these projects would produce a paper describing how they have chosen to map RFC822 to X.400 and why. COMMENTS IN NAMES: X.400 has in the IPMessageHeading fields for originator and recipients. The value of each of these fields has three elements: ORName, freeformName and telephoneNumber. A good choice may be to map the exact address (addr-spec in RFC822 terminology) onto the ORName, and map the comment in the name (phrase in RFC822 terminology) onto the freeformName. MESSAGE-ID-S: It is very important to ensure that these ID-s can be transformed in a one-to-one manner, so that the same ID will come back the same after transformation from RFC822 to X.400 and back to RFC822 or the other way around. This will not be simple, since the exact syntax for MESSAGE-ID-S is different. In X.400, MESSAGE-ID-S are compulsory. Thus, for RFC822 messages lacking such an idea, one has to be generated. I suggest that this is done using the algorithm for producing a Message-ID by a hasked checksum of the originator, the date of writing and the contents, which I suggested in a message a couple of months back. The RFC822 Message-ID corresponds best to the IPMessageID in X.400. X.400 also has several other kinds of MessageID-s. There are so-called "event-id"-s, which are of a transitory nature and need not have any RFC822 translation. There is something called "UA-content-id", which should probably also be mapped from the RFC822 Message-ID, although the IPMessageID is more important. Robert Babatz and Manfred Bogen at the GMD in Germany have in a paper entitled "Semantic Relations in Message Handling Systems" (Their address, if you want a copy, is Scholls Birlinghoven, D-5205 Sankt Augustin, Germany) have pointed out and clarified the problems caused by the fact that X.400 provides a new IPMessage Heading envelope around the old message (including all old envelopes) when the message is forwarde (by e.g. a mailing list) and clarified which of these IPMessageId-s (the innermost) really refers to the content of the message - it is this innermost Id which should be mapped in most cases to/from RFC822 Message-id-s.  Received: from csnet-relay by MIT-MC.ARPA 2 Jun 85 20:14:40 EST Received: from buffalo by csnet-relay.csnet id aa11283; 2 Jun 85 20:09 EDT Received: by gort.SUNYAB (4.12/4.7) id AA00958; Sat, 1 Jun 85 20:59:34 edt Date: Sat, 1 Jun 85 20:59:34 edt From: John Robert LoVerso Word-Of-The-Day: Odin To: Header-People@mit-mc.ARPA Subject: Re: Header-People and X.400 > I'm pretty sure I've seen mail come in with "received" fields out of > order (i.e. after other fields, not just out of chronological order > among themselves) Its already happening. For example, PMDF 4.2v3 (the software distributed for 4.2 CSNET Phonenet sites) places the "received" line at the END of the header. John  Received: from MIT-XX.ARPA by MIT-MC.ARPA 3 Jun 85 21:55:24 EST Date: Mon 3 Jun 85 21:55:02-EDT From: Bard Bloom Subject: Directory To: header-people@MIT-MC.ARPA Are there network directories on-line anywhere? (Reply to BARD@MIT-XX, please.) Thanks; Bard "Obviously a novice" Bloom -------  Received: from decwrl.ARPA by MIT-MC.ARPA 4 Jun 85 02:42:44 EST Received: by decwrl.ARPA (4.22.01/4.7.34) id AA07318; Mon, 3 Jun 85 23:42:58 pdt Received: by deccra.hudson (4.12/5.1.GaTech) id AA07292; Tue, 4 Jun 85 02:38:33 edt Date: Tue, 4 Jun 85 02:38:33 edt From: System Manager Posted-Date: Tue, 4 Jun 85 02:38:33 edt Message-Id: <8506040638.AA07292@deccra.hudson> To: header-people@mit-mc.ARPA Subject: please remove campbell@maynard.uucp from this list He is no longer accessible via that path. From MAILER-DAEMON@decwrl.UUCP Tue Jun 4 02:32:01 1985 Received: by deccra.hudson (4.12/5.1.GaTech) id AA07246; Tue, 4 Jun 85 02:31:56 edt Posted-Date: Sat, 1 Jun 85 20:59:34 edt Received: by decwrl.ARPA (4.22.01/4.7.34) id AA19551; Mon, 3 Jun 85 03:33:56 pdt Date: Sat, 1 Jun 85 20:59:34 edt From: MAILER-DAEMON@decwrl.UUCP (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8506031033.AA19551@decwrl.ARPA> To: MAILER-DAEMON@deccra.hudson Status: O ----- Transcript of session follows ----- >>> RCPT To: <<< 550 Unable to parse address 550 decwrl!@MIT-MC.ARPA:loverso%buffalo.csnet%csnet-relay.ARPA... User unknown ----- Unsent message follows ----- Received: by decwrl.ARPA (4.22.01/4.7.34) id AA19549; Mon, 3 Jun 85 03:33:56 pdt Received: by deccra.hudson (4.12/5.1.GaTech) id AA02316; Mon, 3 Jun 85 06:04:09 edt Date: Sat, 1 Jun 85 20:59:34 edt From: Mail Delivery Subsystem Subject: Returned mail: unknown mailer error 101 Posted-Date: Sat, 1 Jun 85 20:59:34 edt Message-Id: <8506031004.AA02316@deccra.hudson> To: %MIT-MC.ARPA:loverso@buffalo.CSNet@decwrl ----- Transcript of session follows ----- unknown flag -L unknown flag -adecwrl!@MIT-MC.ARPA:loverso%buffalo.csnet@csnet-relay.arpa bad system name: maynard uux failed. code 101 554 maynard!campbell... unknown mailer error 101 ----- Unsent message follows ----- Received: by deccra.hudson (4.12/5.1.GaTech) id AA02308; Mon, 3 Jun 85 06:04:09 edt Posted-Date: Sat, 1 Jun 85 20:59:34 edt Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by decwrl.ARPA (4.22.01/4.7.34) id AA14193; Sun, 2 Jun 85 17:28:29 pdt Message-Id: <8506030028.AA14193@decwrl.ARPA> Received: from csnet-relay by MIT-MC.ARPA 2 Jun 85 20:14:40 EST Received: from buffalo by csnet-relay.csnet id aa11283; 2 Jun 85 20:09 EDT Received: by gort.SUNYAB (4.12/4.7) id AA00958; Sat, 1 Jun 85 20:59:34 edt Date: Sat, 1 Jun 85 20:59:34 edt From: John Robert LoVerso Word-Of-The-Day: Odin To: Header-People@mit-mc.ARPA Subject: Re: Header-People and X.400 > I'm pretty sure I've seen mail come in with "received" fields out of > order (i.e. after other fields, not just out of chronological order > among themselves) Its already happening. For example, PMDF 4.2v3 (the software distributed for 4.2 CSNET Phonenet sites) places the "received" line at the END of the header. John  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 4 Jun 85 15:25:18 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664213453834463@MIT-MULTICS.ARPA>; 04 Jun 1985 15:17:33 edt Date: 04 Jun 85 18:24 +0100 From: Paul_Bryant%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA, Academic_network_cooperation_group%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Cc: COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA, Academic_network_cooperation_group%QZCOM.MAILNET@MIT-MULTICS.ARPA, academic_network_cooperation@WISC-RSCH.ARPA Subject: Re: RFC822/X.400 header transformations Message-ID: <107603@QZCOM> In-Reply-To: <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU> Without having had time to digest your comment fully I support your concern and need to define how X400 and RFC822 should interwork. Some preliminary work along these lines has been done in the UK but the work would benifit from being international. I am not so pessamistic as you are on the difficulties as I suspect that unless you are a purist you should normally be able to get mail through with a somewhat relaxed attitude to ignoring the curiosities and keeping the fingers crossed. Certainly the current gateways between so called RFC822 offerings leave a lot to be desired and it should not take too much effort to reach that low level although I would certainly like to see high quality gateways which where not hacked together on a wet Sunday afternoon. This should be a topic for the Stockholm meeting.  Received: from WISCVM.ARPA by MIT-MC.ARPA 5 Jun 85 10:03:53 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 06/05/85 at 06:51:19 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6302; Wed, 05 Jun 85 14:36:25 GMT Date: Wed, 5 Jun 85 14:33 GMT From: Henry Nussbacher To: I really hate users who send mail with the following format: user (John Q. Public) @ node Can anyone please elucidate as to why this format is quite popular among a number of nodes? Are they all running the same bad software? Is this format a forerunner to the current RFC822 format and these sites don't wish to give it up?  Received: from nrl-aic by MIT-MC.ARPA 6 Jun 85 00:29:55 EST Date: 5 Jun 1985 23:01:37 EDT (Wed) From: Dan Hoey Subject: Hateful users To: Henry Nussbacher Cc: Header-People@MIT-MC.ARPA Message-Id: <486874897/hoey@nrl-aic> In-Reply-To: Henry Nussbacher's message of Wed, 5 Jun 85 1433 GMT Date: Wed, 5 Jun 85 14:33 GMT From: Henry Nussbacher To: I really hate users who send mail with the following format: user (John Q. Public) @ node I, on the other hand, reserve my displeasure for people who send mail without specifying a subject. Perhaps we can discuss the technical aspects despite our mutual animosity. Can anyone please elucidate as to why this format is quite popular among a number of nodes? Possibly because it conforms to RFC822. The popular alternative, ``John Q. Public '', while used by quite a few sites, does not conform. In RFC822, 3.4.3. COMMENTS A comment is a set of ASCII characters, which is enclosed in matching parentheses and which is not within a quoted-string The comment construct permits message originators to add text which will be useful for human readers, but which will be ignored by the formal semantics. seems to allow the form you cite. My reading of this is supported by examples such as A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US The "(the Stilt)" is a comment, which is NOT included in the destination mailbox address handed to the originating system's mailer. The local-part of the address is the string "Wilt.Chamberlain", with NO space between the first and second words. However, the rules mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" phrase = 1*word ; Sequence of words word = atom / quoted-string atom = 1* specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. prohibit the alternative from, because a may not contain any "." characters. Dan Hoey  Received: from BRL-TGR.ARPA by MIT-MC.ARPA 6 Jun 85 01:06:14 EST Date: Wed, 5 Jun 85 11:04:27 EDT From: Ron Natalie To: Henry Nussbacher cc: header-people@MIT-MC.ARPA That address is perfectly valid RFC822. -Ron  Received: from WISCVM.ARPA by MIT-MC.ARPA 6 Jun 85 02:47:03 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 06/06/85 at 01:45:15 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 2115; Thu, 06 Jun 85 09:30:05 GMT Date: Thu, 6 Jun 85 09:29 GMT From: Henry Nussbacher To: Subject: Sorry 1) I am sorry for not including a Subject field 2) I am sorry for not reading fully the RFC822 standard and understanding that user (name) @ node is valid RFC822. 3) I am a bit confused on what you had to say: Possibly because it conforms to RFC822. The popular alternative, ``John Q. Public '', while used by quite a few sites, does not conform. In RFC822, Does that mean that my From: field is incorrect? A.1. ADDRESSES A.1.1. Alfred Neuman A.1.2. Neuman@BBN-TENEXA These two "Alfred Neuman" examples have identical seman- tics, as far as the operation of the local host's mail sending (distribution) program (also sometimes called its "mailer") and the remote host's mail protocol server are concerned. In the first example, the "Alfred Neuman" is ignored by the mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- pient. The second example contains no superfluous informa- tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- pient. Is the '.' in the John Q. Public that is invalid or is it the '.' within the '<>' (i.e. .ARPA) that is invalid? An aside: I now realize how poor a medium electronic mail is. My comment of 'I really hate users...' was said with a different tone of voice than was construed. I felt like I was sitting around a table and drinking some beer and talking to friends and saying, 'Don't you just hate it when...'. I'll be more careful in the future. Hank  Received: from ucla-locus.arpa by MIT-MC.ARPA 6 Jun 85 18:38:47 EST Date: Thu, 6 Jun 85 15:25:21 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Re: "user (John Q. Public) @ node" References: Message of Wed, 5 Jun 85 14:33 GMT from "Henry Nussbacher " Message-ID: <486944721-3999-wales@MEDEA.LOCUS.UCLA.EDU> As has been noted several times already, an address of the form user (John Q. Public) @ node is perfectly valid according to the syntax requirements of RFC822. Any site whose mail software cannot recognize that the above is equivalent to the address "user@node" should definitely upgrade their software. For that matter, of course, an address of the form user@node (John Q. Public) -- which is apparently the format preferred by "sendmail" -- is also legal, and completely equivalent in meaning to the first form with the embedded comment. However, I have serious objections to the idea of enclosing the full name in a comment at all. I would MUCH rather see all sites use the facility which RFC822 has already provided for representing full names in addresses -- namely, the prepended phrase: "John Q. Public" (Note that the quotes are required in this particular case ONLY because the full name in question contains a period.) If the full name were always represented as a prepended phrase, then it would be trivial to pick it out of the header. An RFC822 parser quickly becomes VERY messy, on the other hand, when you have to hang on to all the comments until the bitter end -- on the off-chance (or likelihood!) that one of these may contain the "full name" portion of an address. I, for one, would vastly prefer to be able to treat comments as abso- lutely equivalent to white space (as they are supposed to be in RFC822), and simply toss them out during the lexical-analysis phase of a header- cruncher. But it's sheer folly to even think of doing this when so many sites insist on putting people's full names in comments. Please understand that what I am taking issue with is NOT the syntactic legality of an address with a "full-name comment". Without question, such an address is "legal" according to RFC822. What I am objecting to is the expectation that my (or anyone's) software should have to recog- nize said "full-name comment" as containing a user's full name. Actually, I frequently think that comments in headers are more trouble than they're worth, and that RFC822 might have been better off without providing for them at all. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@UCLA-LOCUS.ARPA -or- wales@LOCUS.UCLA.EDU UUCP: ...!(ihnp4,ucbvax)!ucla-cs!wales  Received: from rand-unix.ARPA by MIT-MC.ARPA 7 Jun 85 00:39:38 EST Received: from vortex.UUCP by rand-unix.ARPA; Thu, 6 Jun 85 21:30:49 pdt Date: Thu, 6-Jun-85 20:38:32 PDT From: vortex!lauren@rand-unix (Lauren Weinstein) Subject: Re: "user (John Q. Public) @ node" Message-Id: <8506062038.2663.1.VT1.00C@vortex.UUCP> To: wales@UCLA-LOCUS.ARPA Cc: header-people@MC.ARPA In-Reply-To: Your message of Thu, 6 Jun 85 15:25:21 PDT I also prefer: Lauren Weinstein on the From: line. However, every damn time I've tried turning on the #ifdef in my code that enables it, I get flooded with mail from sites which can only handle the "( )" comment form. I finally gave up. --Lauren--  Received: from Xerox.ARPA by MIT-MC.ARPA 12 Jun 85 21:23:28 EST Received: from Salvador.ms by ArpaGateway.ms ; 12 JUN 85 18:21:08 PDT Sender: "Albert C. Hall.osbunorth"@Xerox.ARPA Date: 12 Jun 85 18:20:46 PDT (Wednesday) Subject: Re: RFC822/X.400 header transformations From: AlHall.osbunorth@Xerox.ARPA To: wales@UCLA-LOCUS.Arpa cc: Header-People@MIT-MC.Arpa, AlHall.osbunorth@Xerox.ARPA In-Reply-to: wales%UCLA-LOCUS:ARPA's message of 1 Jun 85 13:14:42 PDT (Saturday) Message-ID: <850612-182108-1114@Xerox> Rich: I agree that a fixed-form version of RFC822 would be easier to convert to and from X.400-style Attributes, but I don't see this as being a good short-term solution; I doubt that it will be any easier to get people to adapt to a structured version of RFC822 than it is to get them to format their dates correctly in the current RFC822. On the other hand, I would guess that existing X.400/Arpa gateway implementations take an approach similar to another point you made: any non-structured information such as comments are regarded as unimportant and are simply thrown away. Since I believe comments to be quite valuable in providing context for often-nonsensical address strings, I would prefer to see the comments, etc. placed in some secondary part of the message. This way, the choice of whether the information is displayed is up to the destination User Agent, and the information is available to be recovered in the case that the message passes back into ArpaLand. -- Al  Received: from UCI-ICSA by MIT-MC.ARPA 13 Jun 85 04:16:09 EST To: Header-People@mit-mc cc: stef@uci-icsa Subject: Re: RFC822/X.400 header transformations In-reply-to: Message of 12 Jun 85 18:20:46 PDT () <850612-182108-1114@Xerox> Date: 12 Jun 85 22:50:05 PDT (Wed) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 12 Jun 85 22:51:06 PDT (Wed) It seems to me that a little redundancy might solve some problems here. How about putting the entire commented address in the FreeFormName X.400 subfield and the netted-out (comments removed) address in the ORName subfield, so that no information is lost to the recipient, going in either direction. This means that a message going from 822 to X./400 and back to 8922 will have a new additional field called "FreeFormName: " but no information will be deliberately tossed. I find that redundancy is useful for people, though I know that programmers do not like to find it in parsable address fields. My point is that the FreeFormName subfield is there primarily for human consumption to help recipients relate to an addressees identity, so lets put it to its intended purpose. ===== As for the ordering of header fields in 822, it seems to me that only the Received fields are defined to lend meaning by their ordering, and it is well known that having them stacked in reverse order at the top (last-first) is the most helpful in case of recipient need. The reason for this is that Recieved fields are really "postmarks" written onto the "envelope" (which in 822 is mixed with the other header fields for lack of a separate place to put them). So, it should suffice to retain the order for Recieved fields in going from 822 to X.400. Going the other way should not be a problem, because X.400 has a separate place to to carry them and as long as they are stashed into the 822 headers in order, that should be all that is needed. Stef  Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 16:29:29 EST To: header-people@mit-mc cc: iglesias@uci-icsa Subject: Parser for RFC822 headers wanted Date: 18 Jun 85 13:28:20 PDT (Tue) From: Mike Iglesias Received: from Localhost by UCI-ICSA for iglesias; 18 Jun 85 13:28:45 PDT (Tue) Does anybody have a parser that parses RFC822 style headers, especially addresses? I don't want to reinvent the wheel. I'd prefer something that is not written in C, as I don't know C and don't have the time to learn it. I'm going to be interfacing a Honeywell CP-6 system to several other systems/nets (BITNET for example). I already have Dave Platt's (Dave-Platt%LADC@CISL) code, but it doesn't do everything that I need. Thanks for your help, Mike Iglesias University of California, Irvine  Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 16:29:29 EST To: header-people@mit-mc cc: iglesias@uci-icsa Subject: Parser for RFC822 headers wanted Date: 18 Jun 85 13:28:20 PDT (Tue) From: Mike Iglesias Received: from Localhost by UCI-ICSA for iglesias; 18 Jun 85 13:28:45 PDT (Tue) Does anybody have a parser that parses RFC822 style headers, especially addresses? I don't want to reinvent the wheel. I'd prefer something that is not written in C, as I don't know C and don't have the time to learn it. I'm going to be interfacing a Honeywell CP-6 system to several other systems/nets (BITNET for example). I already have Dave Platt's (Dave-Platt%LADC@CISL) code, but it doesn't do everything that I need. Thanks for your help, Mike Iglesias University of California, Irvine  Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 18:40:56 EST To: header-people@mit-mc Subject: Parser for RFC822 headers wanted (addendum) Date: 18 Jun 85 15:39:58 PDT (Tue) From: Mike Iglesias Received: from Localhost by UCI-ICSA; 18 Jun 85 15:40:10 PDT (Tue) I may have been unclear in my last message. What I want is a working parser that I can use as a guide, not one that works on a CP6 system. Mike Iglesias University of California, Irvine  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 22 Jun 85 14:51:55 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665767126122366@MIT-MULTICS.ARPA>; 22 Jun 1985 14:52:06 edt Date: 21 Jun 85 13:42 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Parser for RFC822 headers wanted (addendum) Message-ID: <109974@QZCOM> In-Reply-To: <109733@QZCOM> A general advice: Do not write a parser which parses the RFC822 standard as written in the RFC822 paper. You will then have to re-write everything. Write a parser which parses the existing de-facto-standard, which is in some cases different from RFC822, and which is very permissive in accepting and trying to understand all possible reasonable and unreasonable variants of RFC822. For example, the standard in RFC822 says that the character "@", if occuring inside a quoted string, is not significant. Do not believe it. The standard further says that a lot of characters, including spaces, are legal in mames if you put double-quotes around them. Do not believe that either. De-facto-standard seems to be that spaces are translated into under-lines to create legal RFC822 names, not by embedding in double-quotes as the standard says. Further, you will encounter and have to be able to parse name strings like mcvax!inria!gipsy!ch@seismo which is a mixture of UUCP and ARPA notations. The correct RFC-format should be: @seismo,@mcvax,@inria,@gipsy:ch@gipsy but that format is NEVER used in this case. Finally, you will find that what according to the standard should be written as e.g.: @MIT-MULTICS.ARPA,@QZCOM.MAILNET:Jacob_Palme@QZCOM.MAILNET is very often instead written as: Jacob_Palme%QZCOM.MAILNET@MIT-MULTICS.ARPA  Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 23 Jun 85 01:43:34 EST Date: Sun, 23 Jun 85 01:42 EDT From: don.provan@CMU-CS-A.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) CC: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , In-Reply-To: <109974@QZCOM> Message-Id: <23Jun85.014250.DP0N@CMU-CS-A.ARPA> Allow me to be the first to shout BULLSH*T very loud in your ear. Do *NOT*, repeat, do *NOT* write a parser which cannot properly parse quoted strings, including quoted spaces and at signs. The reason there are all these idiotic de facto standards is because so many people wrote poor parsers. All parsers, even ones already running, must be able to handle every example you mention properly. If they don't they have bugs and should be fixed immediately. None of the examples you give involving host names should be any business whatsoever of a parser. All of them are examples of legal addresses designed to get accross the maze of networks to anyone who can properly parse an 822 addresses and allow for replies. In fact, the two alternates you suggest aren't legal because of a restriction against non-internet host names.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 23 Jun 85 14:10:18 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665850640639152@MIT-MULTICS.ARPA>; 23 Jun 1985 14:04:00 edt Date: 23 Jun 85 14:25 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Message-ID: <110185@QZCOM> In-Reply-To: <23Jun85.014250.DP0N@CMU-CS-A.ARPA> FROM: don.provan@CMU-CS-A.ARPA Allow me to be the first to shout BULLSH*T very loud in your ear. Do *NOT*, repeat, do *NOT* write a parser which cannot properly parse quoted strings, including quoted spaces and at signs... None of the examples you give involving host names should be any business whatsoever of a parser.... Well, that depends on the goal of your parser. For my message system, an important goal of the parser is to be able to identify uniquely the name of a mailbox, so that occurence of the same mailbox in several incoming messages can be identified to refer to the same mailbox. This is important, in order for example to make it easy for our users to search in the message data base for a message written by or to a certain external mailbox. And if that is your goal, then the kind of deep parsing I do is necessary. Of course, if you only want to do a superficial parsing, not extracting full information from the header, then a more limited parsing of the kind you suggest is acceptable.  Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 23 Jun 85 19:17:30 EST Date: Sun, 23 Jun 85 17:27 EDT From: don.provan@CMU-CS-A.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) CC: , Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people In-Reply-To: <110185@QZCOM> Message-Id: <23Jun85.172707.DP0N@CMU-CS-A.ARPA> I disagree. The "external mailbox" in 822 format for you, for example, is Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA. Your mailer should always generate that name in the from field of messages if you wish it to be used to identify you. Any attempt by any entity other than your mail system to parse your address in any way but 822 format is doomed to failure. 822 is the rule book for the game. If you try to put additional rules onto your parser, then no one can make any guarentee about whether or not you'll be able to identify the sending person. My point is that we can all go out and spend the rest of lives trying to cover situation where stupid mail systems on UUCP give route dependent from IDs, but the best thing to do is fix the stupid senders, not teach every mail system in the world that this stupid mail system does this and that stupid mailer does that. Just because in your mail system, spaces and underlines are equivalent, don't assume they're equivalent in my mail system. I'll return the favour by not assuming that hash marks and spaces are equivalent in your system.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 16:27:04 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665944679317771@MIT-MULTICS.ARPA>; 24 Jun 1985 16:11:19 edt Date: 24 Jun 85 17:00 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Message-ID: <110264@QZCOM> In-Reply-To: <23Jun85.172707.DP0N@CMU-CS-A.ARPA> When a message written by me is transferred to you via MIT-MULTICS, then my mailbox name is Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA But a message written by me might also get sent first to some host on JANET, and then forwarded to you from JANET, and then you would get my mailbox name as Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA If your mail system did not parse the complete address string, it might have trouble performing commands such as "Find me the last three messages I got written by the person who wrote the last message I got". This is a matter of what your goal is. If your goal is to extract exactly and only the information defined in the RFC822 syntax, then you are right. If your goal is to extract all the information given in the message headers which you can use to help the users of your mail system, then for some mail systems at least a fuller analysis is better. On the matter of underscore=space: I did not want to translate spaces to underscores. I would much better prefer to send out my name as "Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA or as "Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA The reason I am not doing that is that many mail systems are not able to handle that kind of constructs!  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 16:27:04 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665944679317771@MIT-MULTICS.ARPA>; 24 Jun 1985 16:11:19 edt Date: 24 Jun 85 17:00 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Message-ID: <110264@QZCOM> In-Reply-To: <23Jun85.172707.DP0N@CMU-CS-A.ARPA> When a message written by me is transferred to you via MIT-MULTICS, then my mailbox name is Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA But a message written by me might also get sent first to some host on JANET, and then forwarded to you from JANET, and then you would get my mailbox name as Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA If your mail system did not parse the complete address string, it might have trouble performing commands such as "Find me the last three messages I got written by the person who wrote the last message I got". This is a matter of what your goal is. If your goal is to extract exactly and only the information defined in the RFC822 syntax, then you are right. If your goal is to extract all the information given in the message headers which you can use to help the users of your mail system, then for some mail systems at least a fuller analysis is better. On the matter of underscore=space: I did not want to translate spaces to underscores. I would much better prefer to send out my name as "Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA or as "Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA The reason I am not doing that is that many mail systems are not able to handle that kind of constructs!  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 18:25:59 EST Date: Mon, 24 Jun 85 18:24 EDT From: Barry Margolin Subject: Re: Parser for RFC822 headers wanted (addendum) To: header-people@MIT-MC.ARPA Message-ID: <850624222459.771443@MIT-MULTICS.ARPA> I agree with Don Provan on this. No host has any business parsing the local-part of an address but that host. To give a concrete example where this would screw up, consider the character "." in a local-part, i.e. the address foo.bar @ host If host is CSNET-RELAY then this refers to the user foo on the host bar.CSNET. However, if host is a Multics or TOPS-20 it means the user foo.bar. Also, there is no well-defined precedence for many of the combinations; for instance, does host1!host2!user@host3 mean host3 -> host1 -> host2 -> user or host1 -> host2 -> host3 -> user or host1 -> host3 -> host2 -> user ? All three are possible depending on the configuration files at the host that sent the message and host1 and host3, and there is no way for anyone else's parser to know which it will be. Is this a mess? You bet! But don't make it messier by writing a parser that tries to second-guess the rest of the network. barmar  Received: from ucla-locus.arpa by MIT-MC.ARPA 24 Jun 85 20:19:09 EST Date: Mon, 24 Jun 85 17:08:23 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) In-reply-to: Message of 24 Jun 85 17:00 +0100 from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" <110264@QZCOM> Message-ID: <488506103-12477-wales@DIANA.LOCUS.UCLA.EDU> Jacob -- Replying to your message: When a message written by me is transferred to you via MIT-MULTICS, then my mailbox name is Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA But a message written by me might also get sent first to some host on JANET, and then forwarded to you from JANET, and then you would get my mailbox name as Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA If your mail system did not parse the complete address string, it might have trouble performing commands such as "Find me the last three messages I got written by the person who wrote the last message I got". This is a matter of what your goal is. If your goal is to extract exactly and only the information defined in the RFC822 syntax, then you are right. If your goal is to extract all the information given in the message headers which you can use to help the users of your mail system, then for some mail systems at least a fuller analysis is better. Two comments: (1) The use of "%" as a special character, denoting subnetting or source-routing ("user%route" format), is of course official in the JANET system (JNT Mail Protocol, Revision 1.0, Section 2.2.4). RFC822, on the other hand, does not assign any special meaning to "%". Everything to the left of the "@" is, from the RFC822 stand- point, a monolithic object called a "local part", the interpretation of which is left entirely up to the destination host. "%" as a subnetting symbol is, in actual practice, a widespread "de facto" convention in the ARPA Internet world. Although there is nothing in RFC822 which demands that it be used in this way and no other way, I am not aware of any host which uses "%" in its local addressing scheme to mean anything other than subnetting. Note that a host can use "%" as a subnetting symbol without any other host having to know (or care) what the notation means -- since the interpretation of the text to the left of the "@" is completely up to the destination host. All that is required is that all hosts be able to pass an address with "%" on to another host without mangling it in the process. So, you are probably safe in assuming that an address of the form "a%b@c" refers to someone named "a", at some location named "b", which in turn is reached via "c" -- even though RFC822 doesn't officially recognize this convention. Although some host could in theory decide to use "%" in some totally different fashion, in actual fact this is quite unlikely to happen. (2) However, even if you do succeed in analyzing an address still fur- ther by recognizing the "de facto" use of the percent sign, you are still going to run into a major problem. Consider the two addresses that you cited in your message: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA On what grounds can I conclude that these two addresses refer to the same user? Maybe there are two "Jacob_Palme_QZ"'s, for all I know. Even if I note the "subnetting" structure of each address, and see a "QZCOM" mentioned in both places, how am I to know for sure that the "QZCOM.MAILNET" reached from MIT-MULTICS.ARPA is the same place as the "QZCOM" reached from UCL-CS.ARPA via its subhost "YORK"? You might be getting lulled into a false sense of security because of the familiarity -- and seeming "inherent uniqueness" -- of enti- ties like "Jacob_Palme_QZ" and "QZCOM". But if you substitute less meaningful values such as "John_Doe" and "FOO", respectively, into the two different addresses you gave in your message, I think you'll see my point. So, to summarize: Yes, you can probably get away with treating "%" as a subnetting symbol -- provided, of course, that you do this only for your own private computations and don't modify the stuff to the left of the "@" in any way before using the address to send mail. However, unless you can think of a solution to the issue of global uniqueness of local parts, I hardly see the point of going to the trouble of a compli- cated analysis of address substructure -- and I think the only really safe criterion for concluding that two addresses refer to the same per- son is if they are identical, byte for byte. This is, of course, a very powerful argument in favor of a globally unique domain naming scheme which would make this whole set of issues -- multiple route-based addresses, subnetting, and what-not -- completely irrelevant. So be it. On the matter of underscore=space: I did not want to translate spaces to underscores. I would much better prefer to send out my name as "Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA or as "Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA The reason I am not doing that is that many mail systems are not able to handle that kind of constructs! Your point is well taken. It is unfortunate that many mail systems cannot adequately handle spaces in local parts -- especially since this problem has been known for several years. Some places have been using spaces in addresses for local mail for ages -- but when they used such addresses in network mail, they got their hands slapped pretty badly because some "important" sites choked on the spaces and were unable or unwilling to fix their software to conform to the official specs. You should, though, be careful in assuming any particular substitution convention to handle spaces in names. Unlike the situation with "%" and subnetting, there simply is no accepted "de facto" convention for spaces in addresses; some places use underscores, others use periods, and maybe still other places use still other characters for all I know. If there were a possibility of establishing a convention, I would prefer the underscore from an aesthetic point of view. Others, however, would no doubt argue just as passionately for the period (which is admittedly easier to type on most keyboards). Still others would insist on no sub- stitutions at all -- in order to pressure those sites which still can't handle spaces in names to fix their software. The result is that agre- ement on a standard in this area is unlikely. Further, the period is heavily used for subnetting in some circles (some places say "site.user", while others say "user.site"). Any attempt on your part to pressure any of these places for some kind of netwide uni- formity in this area is doomed; again, the format of the "local part" of an address (to the left of the "@") is completely up to the destination host, and anyone else who tries to second-guess what is going on there does so at his own risk. Of course, it's quite possible that the "sub- netting" use of the period will gradually decrease in favor of increased use of subdomains; this will take time, however. Please understand that I'm not trying to discourage you from putting as much intelligence as possible in your mail-handling tools. I'm simply trying to point out that, given the current far-less-than-ideal situa- tion, some of the things you propose to do are at best quite difficult. -- Rich  Received: from BRL-TGR.ARPA by MIT-MC.ARPA 24 Jun 85 23:36:42 EST Date: Mon, 24 Jun 85 15:45:29 EDT From: Ron Natalie To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Unfortunately there are two problems here: 1. The specification RFC822 form of addresses and its corrections. RFC822 ain't so bad, but, 2. The DOD Internet view of hostname requires the "to the right of the @" domain names to things it knows about, precluding the .UUCP and .MAILNET domains (at least for the time being). In addition there exists problems with the implementation of the new domain schemes. -Ron  Received: from lll-tis-b.ARPA by MIT-MC.ARPA 25 Jun 85 01:11:19 EST Return-Path: Received: by lll-tis-b.ARPA; Mon, 24 Jun 85 22:11:37 pdt Date: Mon, 24 Jun 85 22:11:37 pdt From: Michael C. Berch Message-Id: <8506250511.AA20349@lll-tis-b.ARPA> To: header-people@mit-mc.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) References: <7037@styx.UUCP> Depends what you want to use the local part of the address for. If your interest is for transport purposes (routing, forwarding etc.) you'd better stick to the protocol and provide support for whatever de facto stuff is thrown at your mailer. You'd also better not mess around with the local part. But if your interest is for a user-agent type program or message handler (which would deal with queries like "show me the last three messages from this correspondent") there are a couple of things you can do to make life easier: 1. Adopt the user-host binding as the sole information-bearing part of the address, and discard all routing information but retain the domain name (even if it's a default, unstated domain). Obviously this works best in a flat name space since you need not query name servers, etc., to find out the "true" domain name of a given host. But it CAN work anywhere. 2. Canonicalize all addresses, e.g. in the form "user@host.domain". Thus joe%foo.mailnet@relayhost.arpa and joe%foo.mailnet@other-relay.arpa are canonicalized as "joe@foo.mailnet". If you have appropriate name tables, you can turn "decnethost::user" into "user@host.whatever" and foo!bar!zot!joe into "joe@zot.uucp". --- Michael C. Berch mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb  Received: from WISCVM.ARPA by MIT-MC.ARPA 25 Jun 85 11:49:09 EST Received: from (MAILER)NJECNVM.BITNET by WISCVM.ARPA on 06/25/85 at 10:48:47 CDT Return-path: VMSYS3%NJECNVM.BITNET@WISCVM.ARPA Received: by NJECNVM (Mailer X1.21) id 4581; Tue, 25 Jun 85 11:49:08 EDT Date: Tue, 25 Jun 85 11:42 EDT From: Ross A. Patterson Subject: Re: Parser for RFC822, etc. To: In-Reply-To: Your message of 24 Jun 85 17:00 +0100 cc: I suppose others have already spotted this, but I find it rather humorous that a message sent via HEADER-PEOPLE should be lacking a "To:" field, as your last two messages were. This is especially interesting because the subject of both messages was that the header data should be heavily interpreted, to provide a nicer user interface. My mail system, for instance, describes these messages as "Note is of unrecognizale form (xx lines)", since it can't parse a non-existant "To:" field.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 25 Jun 85 13:51:46 EST Received: from NJECNVM(MAILER) by MITVMA (Mailer X1.21) id 2036; Tue, 25 Jun 85 11:47:58 EDT Received: by NJECNVM (Mailer X1.21) id 4581; Tue, 25 Jun 85 11:49:07 EDT Date: Tue, 25 Jun 85 11:42 EDT From: Ross A. Patterson Subject: Re: Parser for RFC822, etc. To: In-Reply-To: Your message of 24 Jun 85 17:00 +0100 cc: I suppose others have already spotted this, but I find it rather humorous that a message sent via HEADER-PEOPLE should be lacking a "To:" field, as your last two messages were. This is especially interesting because the subject of both messages was that the header data should be heavily interpreted, to provide a nicer user interface. My mail system, for instance, describes these messages as "Note is of unrecognizale form (xx lines)", since it can't parse a non-existant "To:" field.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 25 Jun 85 15:08:26 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2666027279988225@MIT-MULTICS.ARPA>; 25 Jun 1985 15:07:59 edt Date: 25 Jun 85 18:49 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Message-ID: <110579@QZCOM> In-Reply-To: <488506103-12477-wales@DIANA.LOCUS.UCLA.EDU> Comment on a message from wales @ UCLA-LOCUS.ARPA (Rich Wales) Yes, you are quite right that our way of parsing addresses means that if two people are called "A" at two different sites, in different nets, with the same site name "B", then we would wrongly assume that they are one and the same person. However, this has, to my knowledge, never happended any time during the two years we have had connections to JANET and MAILNET and thereby indirectly to ARPANET, BITNET, CSNET etc. The identification of two names as referring to the same mailbox even though the RFC822 name was different (because it contained relative adressing information using the "!" or "%" convetions) has however worked correctly many times and been of value to our users.  Received: from UDel-Dewey.ARPA by MIT-MC.ARPA 25 Jun 85 16:34:37 EST Received: from localhost by UDel-Louie.UDel-Dewey.ARPA id a021510; 25 Jun 85 16:29 EDT To: Iglesias@uci-icsa.ARPA cc: header-people@mit-mc.ARPA Subject: 822 parsers Reply-To: header-people@mit-mc.ARPA Date: 25 Jun 85 16:29:16 EDT (Tue) Message-ID: <4057.488579356@udel-dewey> From: Marshall Rose Mike - isn't it amazing how when you ask a simple question on the net, you can get 20 replies which don't answer the question you asked? [ Header-People pay attention: ] The question was, are there any non-C 822-style address parsers out there, preferably, though not necessarily, for a CP-6 environment. As far as the current discussion goes (to throw in my two cents worth): writing an 822 parser is EASY. Modifying it to handle the slop which gets put on the net is a HARD part. One of two things should be done: either make the standards so simple that no one could botch it (good luck), or get some enforcement. I realize that this isn't popular, but I don't see us making any progess by policing ourselves. /mtr  Received: from rand-unix.ARPA by MIT-MC.ARPA 26 Jun 85 03:51:36 EST Received: by rand-unix.ARPA; Wed, 26 Jun 85 00:50:57 pdt From: Steve Tepper Message-Id: <8506260750.AA25679@rand-unix.ARPA> Date: 26 Jun 85 00:50:44 PDT (Wed) To: header-people@mit-mc Subject: rfc822 Possibly it has been forgotten that rfc822 (originally 733) is as complicated and bulky as it is mainly because it was an attempt to codify existing practices into a standard, and there was a wide range of formats in use.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 26 Jun 85 19:55:38 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.48) id AA06837; Wed, 26 Jun 85 16:50:07 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.36) id AA17662; Wed, 26 Jun 85 16:55:30 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.36.1) id AA10382; Wed, 26 Jun 85 16:54:04 pdt Date: Wed, 26 Jun 85 16:54:04 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8506262354.AA10382@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) I am amazed by computer sites that want to continue mixing mail address formats. Any site that is connected to more than one type of mail system, needs to convert addresses a common format as they come in or go out of the local mail domain. To not do so will get you in to trouble fast: the rules for parsing addresses in different mail networks are different and may be incompatible (eg. a!b@c in UUCP and RFC-822); and duplicate host names can occur (to name a few problems). At Berkeley, we operate in local Intermail environment that has special top-domain names to identify non-Internet mail networks (such as UUCP and BITNET). For example the UUCP address: a!b!c!d is converted to b!c!d@a.UUCP for identification within the Berkeley mail domain. All UUCP addresses in this local internet format are relative to UCB-VAX, our UUCP gateway. If a message containing this address is relayed to the DOD internet then it is changed to a!b!c!d@Berkeley.ARPA. The flow diagram for message address processing is: ----------- --------- ---------- --------- -------------- |UUCP Mail|-->|Mail |-->|Local |-->|Mail |-->|DoD Internet| |System |<--|Gateway|<--|Internet|<--|Gateway|<--|Mail | ----------- --------- |Mail | --------- -------------- ---------- The important thing to remember in using this method is that there is a separate mail gateway for each external mail system and on each gateway there are separate rule sets for each direction and for the originator (From:) and the destination addresses (To:, Cc:, etc.) for each direction. (4 rule sets for each mail gateway). Regards, Bill Wells P.S. For those of you that still are confused about "a!b@c": UUCP mail transport agents always parse on the ! (ie. "b@c" is the local address at UUCP host a). Internet mail transport agents always parse on the @ (ie. "a!b" is local address in mail domain c). You cannot have it both ways in the same local mail domain. (ie. There is no such thing as an Internet/UUCP mail transport agent. There can be an Internet/UUCP mail gateway.)  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 26 Jun 85 20:05:03 EST Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.48) id AA06988; Wed, 26 Jun 85 16:59:41 pdt Received: by ucbarpa.ARPA (4.24/4.46) id AA18630; Wed, 26 Jun 85 17:03:48 pdt Date: Wed, 26 Jun 85 17:03:48 pdt From: Jordan Hayes Message-Id: <8506270003.AA18630@ucbarpa.ARPA> Organization: Computer Systems Research Group Home-Phone: (415) 835-8767 Uucp-Path: ...ucbvax!jordan To: Header-People@mit-mc.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) Re: internet/uucp "transport agent" It certainly is possible, but UUCP has to get out of the stone age and adopt 822 addressing... Why aren't more people "waving that banner" ?? The "bang" convention is way outdated (I don't think I'll get any objections on that one) and needs to be scrapped. Why doesn't someone just put their foot down ?? /jordan  Received: from Cornell.ARPA by MIT-MC.ARPA 25 Jun 85 11:38:57 EST Date: Tue, 25 Jun 85 11:37:34 EDT From: bill@Cornell.ARPA (William A. Nesheim) Message-Id: <8506251537.AA13730@Cornell.ARPA> Received: by Cornell.ARPA (4.53/4.30) id AA13730; Tue, 25 Jun 85 11:37:34 EDT To: 4bsd-bugs@Berkeley.ARPA, HEADER-PEOPLE@MIT-MC.ARPA, UNIX-WIZARDS@BRL.ARPA Subject: Spaces in names (in quoted strings) Index: /usr/src/ucb/Mail 4.2bsd Description: While on the subject of blanks in quoted strings, perhaps we all could start with fixing unix's /usr/ucb/Mail! I got frustrated recently with trying to reply to mail from LLL's mfe-net. Mail would always split the address at the blank, despite the quotes. Repeat-by: Send mail to someone with a space in their name. Fix: a diff follows: (/usr/src/ucb/Mail, 4.2bsd) RCS file: RCS/names.c,v retrieving revision 1.1 diff -c -r1.1 names.c *** /tmp/,RCSt1013587 Tue Jun 25 11:24:16 1985 --- names.c Wed Jun 19 17:04:57 1985 *************** *** 73,78 top = NIL; np = NIL; cp = line; while ((cp = yankword(cp, nbuf)) != NOSTR) { if (np != NIL && equal(nbuf, "at")) { strcpy(abuf, nbuf); --- 73,80 ----- top = NIL; np = NIL; cp = line; + if(debug) fprintf(stderr,"extract: line = %s, ntype=%d\n", + line, ntype); while ((cp = yankword(cp, nbuf)) != NOSTR) { if (np != NIL && equal(nbuf, "at")) { strcpy(abuf, nbuf); *************** *** 157,162 register char *cp, *cp2; do { for (cp = ap; *cp && any(*cp, " \t,"); cp++) ; if (*cp == '(') { --- 159,165 ----- register char *cp, *cp2; do { + /* skip leading blanks & tabs */ for (cp = ap; *cp && any(*cp, " \t,"); cp++) ; /* remove comments in () */ *************** *** 159,164 do { for (cp = ap; *cp && any(*cp, " \t,"); cp++) ; if (*cp == '(') { while (*cp && *cp != ')') cp++; --- 162,168 ----- /* skip leading blanks & tabs */ for (cp = ap; *cp && any(*cp, " \t,"); cp++) ; + /* remove comments in () */ if (*cp == '(') { while (*cp && *cp != ')') cp++; *************** *** 168,175 if (*cp == '\0') return(NOSTR); } while (any(*cp, " \t,(")); ! for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++) ! ; *cp2 = '\0'; return(cp); } --- 172,190 ----- if (*cp == '\0') return(NOSTR); } while (any(*cp, " \t,(")); ! ! /* cp now points to the start of a word. */ ! for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++) { ! if( *cp == '"') { /* found opening quote, look for closing */ ! *cp2++ = *cp++; ! while ( *cp && *cp != '"') *cp2++ = *cp++; ! if (*cp == '\0') { ! fprintf(stderr,"Unmatched \" in address.\n"); ! return(NOSTR); ! } ! } ! } ! *cp2 = '\0'; if (debug) fprintf(stderr,"yankword returns wbuf = %s\n", wbuf); return(cp); *************** *** 171,176 for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++) ; *cp2 = '\0'; return(cp); } --- 186,192 ----- } *cp2 = '\0'; + if (debug) fprintf(stderr,"yankword returns wbuf = %s\n", wbuf); return(cp); }  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 27 Jun 85 15:02:39 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2666199305148321@MIT-MULTICS.ARPA>; 27 Jun 1985 14:55:05 edt Date: 27 Jun 85 12:45 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: header-people Subject: Subject: Is it legal with no "TO:" field in a message? Message-ID: <110848@QZCOM> In-Reply-To: <110640@QZCOM> I have now investigated why an outgoing message from us did not contain any "TO:" field? The story is rather long and complex... In general, our system allows our users freely to link an outgoing message to any number (0, 1 or more) of "TO:", "CC:" and "BCC:" recipients. Is this against the standard? Does RFC822 require that there should at least one "TO:" field? In this special case, what happened was the following: >>>>> Here is an outgoing message from me which started it all. Date: 21 Jun 85 13:42 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Parser for RFC822 headers wanted (addendum) Message-ID: <109974@QZCOM> In-Reply-To: <109733@QZCOM> >>>>> Here is the reply to the above message from don.provan. >>>>> Note that don's mailsystem apparently sends the reply >>>>> with a "TO:" reference to the "REPLY-TO:" of the incoming message, >>>>> and a "CC:" reference to the "TO:" field of the incoming message. >>>>> Is this standard practice? >>>>> >>>>> Thus, one mailbox occurs twice in the header of the message >>>>> below, both in the "TO:" and in the "CC:" field. >>>>> Our message system was not willing to accept the same recipient >>>>> in both the "TO:" and the "CC:" field, and thus, when the message >>>>> below was entered into our data base, it only got one link to >>>>> that mailbox, a "CC:" reference ("TO:" would have been better, I will >>>>> modify our message system so that if a message has both a >>>>> "TO:" and a "CC:" reference, the "TO:", and not the "CC:" reference >>>>> will be entered in our data base!). Date: Sun, 23 Jun 85 01:42 EDT From: don.provan@CMU-CS-A.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Parser for RFC822 headers wanted (addendum) CC: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , In-Reply-To: <109974@QZCOM> Message-Id: <23Jun85.014250.DP0N@CMU-CS-A.ARPA> >>>>> Here is a reply written by me to the above message. >>>>> If an incoming message has no "REPLY-TO" field, our system >>>>> copies the "TO:" and "CC:" fields from the commented message >>>>> to the reply (Unless the writer of the reply gives commands >>>>> to remove or add recipients). Thus, the outgoing message >>>>> got to have no "TO:" field. Date: 23 Jun 85 14:25 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Parser for RFC822 headers wanted (addendum) Message-ID: <110185@QZCOM> In-Reply-To: <23Jun85.014250.DP0N@CMU-CS-A.ARPA>  Received: from nrl-aic by MIT-MC.ARPA.ARPA; 28 Jun 85 05:55:45 EDT Date: 28 Jun 1985 02:22:20 EDT (Fri) From: Dan Hoey Subject: Re: Subject: Is it legal with no "TO:" field in a message? To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header-People@MIT-MC.ARPA, DCrocker@UDEL-HUEY.ARPA, "Ross A. Patterson" Message-Id: <488787741/hoey@nrl-aic> In-Reply-To: Jacob Palme QZ's message of 27 Jun 85 1245 +0100 Date: 27 Jun 85 12:45 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA ... In general, our system allows our users freely to link an outgoing message to any number (0, 1 or more) of "TO:", "CC:" and "BCC:" recipients. Is this against the standard? Does RFC822 require that there should at least one "TO:" field? I thought so, but checking the document, I find rather that RFC822 requires only that there be at least one destination address field. There may in fact be no destination addresses at all provided that an empty Bcc: field is included, though such a message probably wouldn't get delivered. [RFC822, Section 4.1. SYNTAX] fields = dates ; Creation time, source ; author id & one 1*destination ; address required *optional-field ; others optional destination = "To" ":" 1#address ; Primary / "Resent-To" ":" 1#address / "cc" ":" 1#address ; Secondary / "Resent-cc" ":" 1#address / "bcc" ":" #address ; Blind carbon / "Resent-bcc" ":" #address I include a copy to David H. Crocker for verification that this is the intent of RFC822. Date: Tue, 25 Jun 85 11:42 EDT From: Ross A. Patterson ... I find it rather humorous that a message sent via HEADER-PEOPLE should be lacking a "To:" field.... My mail system, for instance, describes these messages as "Note is of unrecognizale form (xx lines)", since it can't parse a non-existant "To:" field. So does anyone know how Ross A. Patterson's spurious complaint about Jacob Palme QZ's syntax got to Header-People with a from field having invalid syntax (the unquoted . strikes again) and a host name unknown to the Internet? Where, oh where, are the Protocol Police when you need them? If anyone knows a better way than %'ing through MIT-MULTICS, please send him a copy of this note so he can know to fix his mail system's parser. He might want to spruce up its error messages while he's at it. Dan Hoey Navy Center for Applied Research in Artificial Intelligence Hoey@NRL-AIC.ARPA  Received: from seismo.ARPA by MIT-MC.ARPA.ARPA; 30 Jun 85 01:58:50 EDT Return-Path: Received: from cbosgd.UUCP by seismo.ARPA with UUCP; Sun, 30 Jun 85 01:57:36 EDT Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/0.98.UUCP-CS.beta.4-27-85) id AA23902; Sun, 30 Jun 85 01:37:00 edt Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) id AA06297; Sun, 30 Jun 85 01:43:55 edt Date: Sun, 30 Jun 85 01:43:55 edt From: cbosgd.ATT!mark@seismo (Mark Horton) Message-Id: <8506300543.AA06297@cbpavo.cbosgd.ATT.UUCP> To: header-people@mit-mc.arpa Subject: reordering header lines I seem to recall someone a while back asking if it bothered anybody for header liens to be reordered. The feeling, as I recall, is it didn't. I've just come across a case where it may matter. When one builds a gateway into MHS, there are separate envelope, header, and body parts to a message. I am looking at a proposal suggesting that a TEXT style message look essentially like this: Envelope headers, like Date, From, To, Received, etc End-Of-Header: Body headers, like Subject, etc blank line Body The "End-Of-Header:" line (with a null content) would serve to delimit the boundary between the envelope and the body. Obviously, reordering of such a header would cause problems. Is there any existing standard for separating the two parts? If not, is there any interest in a special header such as this? Any problems I'm missing? (Personally, I might guess that "End-Of-Envelope" might be a better name.) Do null header contents bother anyone? The effect of this on existing software would be that, if reordering is to be done, it stop before this delimeter, and not touch the stuff beyond. Presumably the mail transport layer should not look beyond it, but it probably wouldn't hurt to do so. It would be nice if Received lines were added only before such a delimiter. Mark P.S. Are people aware that the BODIES of MHS messages are not plain text, but are documents with paragraph and indenting information in them, so they can be reformatted on whatever terminal they are to be displayed on? I'm worried about the gateway function from 822 to MHS, trying to intuit this information. Is this a solved problem? Xerox must have such a gateway - how well does it work? P.P.S. Would anyone working on 822-MHS gateway issues please drop me a line, I'd like to find out what's being done so far.  Received: from USC-ISIF.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 19:43:33 EDT Date: 1 Jul 1985 16:40:22 PDT From: POSTEL@USC-ISIF.ARPA Subject: reordering header lines To: header-people@MIT-MC.ARPA Mark Horton: The RECEIVED lines are to be at the begining of the header in most recent first order. --jon. -------  Received: from UCI-ICSA by MIT-MC.ARPA.ARPA; 2 Jul 85 16:04:02 EDT To: POSTEL@usc-isif.arpa cc: header-people@mit-mc.arpa, stef@uci-icsa Subject: Re: reordering header lines In-reply-to: Jon Postel message of 1 Jul 1985 16:40:22 PDT. Date: 02 Jul 85 13:01:11 PDT (Tue) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 02 Jul 85 13:02:03 PDT (Tue) Hi Jon -- You say: "The RECEIVED lines are to be at the begining of the header in most recent first order." I would translate this to mean that in an X.400 <=> 822 Mail Gateway, the behavior of a "transformer" should be to collect all the 822 Recieved: Header Lines (or their equivalent from an X.400 envelope) from the original and place them at the beginning of the transformed message, in exactly the order they were found in the original. The only logical assumption that I can see is to believe the order found in the original. If some prior agent screwed up the order, it should not be the duty of the "transformer" to reorder as a remedy to an implied prior error. This could only introduce gross uncertainty throughout the net, and serve to prevent tracking down errant Received: line inserters for repair. I just want to make the point that the standards for original postmark inserters must be different than the standards for gateway transformations on them. Stef  Received: from UCI-ICSA by MIT-MC.ARPA.ARPA; 2 Jul 85 16:04:02 EDT To: POSTEL@usc-isif.arpa cc: header-people@mit-mc.arpa, stef@uci-icsa Subject: Re: reordering header lines In-reply-to: Jon Postel message of 1 Jul 1985 16:40:22 PDT. Date: 02 Jul 85 13:01:11 PDT (Tue) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 02 Jul 85 13:02:03 PDT (Tue) Hi Jon -- You say: "The RECEIVED lines are to be at the begining of the header in most recent first order." I would translate this to mean that in an X.400 <=> 822 Mail Gateway, the behavior of a "transformer" should be to collect all the 822 Recieved: Header Lines (or their equivalent from an X.400 envelope) from the original and place them at the beginning of the transformed message, in exactly the order they were found in the original. The only logical assumption that I can see is to believe the order found in the original. If some prior agent screwed up the order, it should not be the duty of the "transformer" to reorder as a remedy to an implied prior error. This could only introduce gross uncertainty throughout the net, and serve to prevent tracking down errant Received: line inserters for repair. I just want to make the point that the standards for original postmark inserters must be different than the standards for gateway transformations on them. Stef  Received: from nrl-aic by MIT-MC.ARPA.ARPA; 2 Jul 85 21:56:31 EDT Date: 2 Jul 1985 21:44:26 EDT (Tue) From: Dan Hoey Subject: Re: reordering header lines To: Einar Stefferud Cc: Header-People@MIT-MC.ARPA Message-Id: <489203066/hoey@nrl-aic> In-Reply-To: Einar Stefferud's message of 02 Jul 85 130111 PDT (Tue) Date: 02 Jul 85 13:01:11 PDT (Tue) From: Einar Stefferud ... "The RECEIVED lines are to be at the begining of the header in most recent first order." I would translate this to mean that in an X.400 <=> 822 Mail Gateway, the behavior of a "transformer" should be to collect all the 822 Recieved: Header Lines (or their equivalent from an X.400 envelope) from the original and place them at the beginning of the transformed message, in exactly the order they were found in the original. ... If some prior agent screwed up the order, it should not be the duty of the "transformer" to reorder as a remedy to an implied prior error. This could only introduce gross uncertainty throughout the net, and serve to prevent tracking down errant Received: line inserters for repair. For the reasons stated, I would advocate that the gateway only collect those ``Received:'' lines that appear at the beginning of the header. The presence and contents of other ``Received:'' lines, and their position relative to other header lines, should be provided as an error message, either inserted as some sort of comment in the header or sent to the mail system maintainer. Dan  Received: from UCI-ICSE by MIT-MC.ARPA.ARPA; 4 Jul 85 11:11:45 EDT To: Dan Hoey cc: Einar Stefferud , Header-People@mit-mc.arpa Subject: Re: reordering header lines In-reply-to: Message of 2 Jul 1985 21:44:26 EDT (Tue) <489203066/hoey@nrl-aic> Date: 03 Jul 85 01:03:59 PDT (Wed) From: Einar Stefferud Received: from Localhost by UCI-ICSE; 03 Jul 85 01:05:05 PDT (Wed) Please correct me if I am wrong, but I understand that there is a problem with finding a place in the X.400 "header" part for fields named "Received" and that they need to be carried in the "envelope" part, or tossed out during a transformation from 822 to X.400. Thus, I believe it will be proper to collect all "received" headers, in the order of appearance in the 822 headers, whether all nicely grouped at the beginning or not. Why do you object to collecting them all together? I don't understand the problem. Stef  Received: from nrl-aic by MIT-MC.ARPA.ARPA; 11 Jul 85 10:51:39 EDT Date: 8 Jul 1985 13:49:20 EDT (Mon) From: Dan Hoey Subject: Re: reordering header lines To: Einar Stefferud Message-Id: <489692960/hoey@nrl-aic> In-Reply-To: Einar Stefferud's message of 03 Jul 85 010359 PDT (Wed) Cc: Header-people@MIT-MC.ARPA Date: 03 Jul 85 01:03:59 PDT (Wed) From: Einar Stefferud Please correct me if I am wrong, but I understand that there is a problem with finding a place in the X.400 "header" part for fields named "Received" and that they need to be carried in the "envelope" part, or tossed out during a transformation from 822 to X.400. They can always be stuffed into the body if you're concerned about them. Thus, I believe it will be proper to collect all "received" headers, in the order of appearance in the 822 headers, whether all nicely grouped at the beginning or not. Why do you object to collecting them all together? I don't understand the problem. You were saying that reordering the ``Received:'' lines was not a good idea, because it loses information that might be useful in tracking down bugs. I just pointed out that collecting them together loses information, too. The whole point, I guess, is whether you want to be able to debug 822 through the gateway. If so, you probably have to preserve the entire header somewhere. If not, I don't really see why you want to preserve the ``Received:'' lines at all. Dan  Received: from UCI-ICSE by MIT-MC.ARPA.ARPA; 11 Jul 85 14:15:53 EDT To: Dan Hoey cc: Einar Stefferud , Header-people@mit-mc.arpa Subject: Re: reordering header lines In-reply-to: Message of 8 Jul 1985 13:49:20 EDT (Mon) <489692960/hoey@nrl-aic> Date: 11 Jul 85 11:12:08 PDT (Thu) From: Einar Stefferud Received: from Localhost by UCI-ICSE; 11 Jul 85 11:13:09 PDT (Thu) I think we are splitting hairs. I don't understand what informatrion gets lost if we use the following procedure going from 822 => X.400. 1. Collect all non-X400 headers, in their order of appearance (especially required for "Received" headers) and carry them into an appropriate X.400 "EnvelopePart" or "BodyPart". Perhaps these get split between "EnvelopePart" and some "BodyPart". (How might this lose information?) 2. Put the rest of the headers in the X.400 header. I am not trying to be able to debug 822 MTAs from X.400 headers, but I am trying to assure preservation of potentially useful information for recipients. I refuse to believe that we should proceed into 822 => X.400 gateway operations on the assumption that we do not need this information to assist X.400 recipients to deciepher what happened to their mail in certain interesting cases. We will need the "Received" information just as much then as we did when "Received" headers were invented in 822land, and as much as we need them now in 822land. The logical end-argument is to ask why we keep Receivced lines around if they are not worth preserving at a gateway? Why not just eliminate them altogether in 822land too? Best - Stef  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 19:16:06 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667510475031112@MIT-MULTICS.ARPA>; 12 Jul 1985 19:07:55 edt Date: 12 Jul 85 15:21 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Steve Kille" To: header-people Cc: "Steve Kille" Subject: Subject: Ambiguity with the REPLY-TO field Message-ID: <113307@QZCOM> RFC822 says that the REPLY-TO field can be used in three different ways: (a) Author wants his return mail to some other mailbox somewhere (b) Author may want additional people to get replies (c) Replies should be sent to a distribution list The problem with this is that many mail systems have two commands for writing replies. The name of these commands are different in different mail systems, I will here call them "personal reply" and "group reply". A "personal reply" is only sent to the author of a message, a "group reply" is sent to a group of people, usually all the recipients of the commented message. Now, the first of the three uses of the REPLY-TO field given above corresponds to "personal reply" while the other two corresponds to "group reply". Thus, a mail system implementing both the "personal reply" and the "group reply" command will find it difficult to know whether the reply-to field is of type (a), (b) or (c). I have got complaints from some people that COM consistently produces REPLY-TO fields of type (b) and (c). The complainers have mail systems, which apparently interprets the REPLY-TO field to always be of type (a), and thus use this in their "personal reply" command. However, I have strong reasons in COM for using the REPLY-TO field in the (b) and (c) sense. The reason for this is that I want to distinguish between the case when the author is a member of a conference to which the message is sent and not. When the author is a member of such a conference, replies should NOT be sent personally to the author, but rather to the conference. But if the author is not a member of the conference, replies should be sent both to the author and the conference. (The same principle, of course, would apply to mailing lists.) COM indicates this by including the author in the REPLY-TO field if he is not a member of any conference also receiving the message, but otherwise not including the author in the REPLY-TO field. Is this wrong?  Received: from ucla-locus.arpa by MIT-MC.ARPA.ARPA; 12 Jul 85 20:19:35 EDT Date: Fri, 12 Jul 85 17:15:09 PDT From: Rich Wales To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Steve Kille" CC: Header-People@MIT-MC.ARPA Subject: Re: Subject: Ambiguity with the REPLY-TO field In-reply-to: Message of 12 Jul 85 15:21 +0100 from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" <113307@QZCOM> Message-ID: <490061709-13202-wales@DIANA.LOCUS.UCLA.EDU> Jacob -- I believe that the three "typical uses" of REPLY-TO spelled out in RFC822 (Section 4.4.3, page 22) are intended as three different motiva- tions for using the feature -- NOT three different possible semantics. My understanding of the semantics of the REPLY-TO field is that, if it is present, it is to be used as a substitute for the FROM field when composing replies to the message. That is, if a REPLY-TO field exists in a header, an automatic "reply" operation should ignore the FROM field completely, under all circumstances, and use the REPLY-TO data instead. If the sender of the message needs to use a REPLY-TO field, but also wants to be one of the recipients of any reply, he must include his own address in the REPLY-TO field along with the addresses of the other intended recipients. I am not 100% sure I understood your description of the criteria used by COM in deciding whether to include the sender in the REPLY-TO field, so I am not sure whether COM uses REPLY-TO correctly or not. If you would like to try again to explain what COM does with REPLY-TO, I will gladly try to help you figure out whether its use of REPLY-TO follows the RFC822 semantics, and if it doesn't, whether there is some alternative approach that would do what you want. -- Rich  Received: from CMU-CS-A.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 21:22:33 EDT Date: Fri, 12 Jul 85 21:20 EDT From: don.provan@CMU-CS-A.ARPA To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Steve Kille" Subject: Re: Subject: Ambiguity with the REPLY-TO field CC: header-people , "Steve Kille" In-Reply-To: <113307@QZCOM> Message-Id: <12Jul85.212034.DP0N@CMU-CS-A.ARPA> One problem here is that there are really three types of replies: the personal and group replies you mentioned, and then a third one that might be called a message directed reply or a default reply or a normal reply. The first sends the reply to the person who sent the message, so I'd be tempted to use the From: field for that, although I believe the From: field need not be legal if there's a Reply-to: field. The second sends the reply to everyone who saw the original message. The third sends the reply to anyone the sender thought should see a reply. The Reply-To: field was provided for this use. So my feeling is that the people with the "personal reply" command are trying to do something that isn't supported by the protocol. If it's supported at all, they should be replying to the From: field, not the Reply-To: field.  Received: from UCI-ICSA by MIT-MC.ARPA.ARPA; 13 Jul 85 03:26:22 EDT To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.arpa cc: don.provan@cmu-cs-a.arpa, "Steve Kille" , header-people , stef@uci-icsa Subject: Re: Subject: Ambiguity with the REPLY-TO field In-reply-to: Msg of 12 Jul 85 21:20 EDT <12Jul85.212034.DP0N@CMU-CS-A.ARPA> Date: 13 Jul 85 00:19:55 PDT (Sat) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 13 Jul 85 00:23:06 PDT (Sat) Rich Wales has it right! REPLY-TO is a replacement for FROM (and SENDER), if REPLY-TO exists, and then "personal reply" should use whatever is in REPLY-TO "as requested by the originator", no matter what REPLY-TO contains. Jacob's use to direct replies to whomever he (as the conference chair) wants replies to go to is technically correct, though perhaps he may be overusing it. But this is a social question of good chairmanship. I would tend to be less demanding of recipients who might very well want to make personal replies, and find themselves either thwarted, or bothered by the need to manually edit the address fields of a reply to achieve their desires. However, at times I like to force replies to a whole group by putting the groupname in a REPLY-TO field. I think it is customary in the Internet for recipients who want to reply to all addressees to not use the "personal reply" form of the reply command, and thus they will reply to the whole collection of REPLY-TO/FROM/SENDER, TO, and CC addressees. However, I know a number people who frustrate me continually by (unconciously?) omitting other addreessees, which forces me to manually relay to them when I am trying to promote a group discussion. I wish they would cooperate more. In a way, Jacob's use suggests that he may not trust recipients to use the "group reply" when they should. If a Conference Chair does not trust recipients, then it may be correct to force the issue on them. If the Chair does trust them, then they should really be trusted, by not forcing the issue with such intractable REPLY-TO fields. Please do not take these comments as personally directed. As I see it, we are caught among varying semantic interpretations and social customs, and it will take us a while to get things sorted out. Jacob is trying to cope with a blend of Structured Conference services and Unstructured Internet Mail services to conduct conferences. I don't know anyone else who is even trying this, so I am interested in helping Jacob to understand the Internet side of things (even if I have to shout from time). We really do need to be able to accomodate COM type User Agents in our growing Mail Internet. The trick is to get them to behave in concert with other practices in other contexts. Peace - Stef  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 13 Jul 85 15:26:46 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667583178095756@MIT-MULTICS.ARPA>; 13 Jul 1985 15:19:38 edt Date: 13 Jul 85 15:27 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Rich Wales" , Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: header-people Subject: Re: Subject: Ambiguity with the REPLY-TO field Message-ID: <113649@QZCOM> In-Reply-To: <490061709-13202-wales@DIANA.LOCUS.UCLA.EDU> > FROM: Rich Wales > My understanding of the semantics of the REPLY-TO field is that, if it > is present, it is to be used as a substitute for the FROM field when > composing replies to the message. A message system which has two reply commands, called "personal reply" and "group reply", would for a message without any REPLY-TO field use the "FROM" field when the "personal reply" is used, and would perhaps combine the "FROM", "TO", "CC" and "SENDER" fields when the "group reply" command is used. Thus if, as you say, the "REPLY-TO" field is to be used as a replacement for the "FROM" field, this seems to indicate that maybe the "REPLY-TO" field is mostly to be used for "personal reply" commands. However, the text in RFC822, which says that "REPLY-TO" can be used when you want answers to be sent to a group, seems to indicate that the "REPLY-TO" field is to be used also for "group reply" uses. > FROM: Rich Wales > I am not 100% sure I understood your description of the criteria used by > COM in deciding whether to include the sender in the REPLY-TO field. An example: Suppose we have a mailing list called III@JJJ with three members: - AAA@BBB - CCC@DDD - EEE@FFF Suppose a message written by GGG@HHH, who is not a member of the list, is sent to this mailing list. Then I would make the following REPLY-TO clause: REPLY-TO: III@JJJ, GGG@HHH This would ensure that GGG@HHH would get the replies, even though GGG@HHH is not a member of the list. If however, AAA@BBB sends a message to the list, I would create the following REPLY-TO clause: REPLY-TO: III@JJJ AAA@BBB would *not* be included in the REPLY-TO clause, since AAA@BBB is a member of the mailing list, and will receive the message via the list. If in this case AAA@BBB was included in the REPLY-TO clause, AAA@BBB might get two copies of the replies, one directly and one via the list (an intelligent system might be able to merge the two copies before displaying them to the user, but still the two copies would increase transmission cost and would confuse COM, since COM would not know whether to regard it as a personal message or a mailing list message - COM allows users to give different priority to incoming messages belonging to different mailing lists.  Received: from ucla-locus.arpa by MIT-MC.ARPA.ARPA; 13 Jul 85 16:44:50 EDT Date: Sat, 13 Jul 85 13:40:44 PDT From: Rich Wales To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA CC: Header-People@MIT-MC.ARPA Subject: Re: Subject: Ambiguity with the REPLY-TO field In-reply-to: Message of 13 Jul 85 15:27 +0100 from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" <113649@QZCOM> Message-ID: <490135244-13242-wales@DIANA.LOCUS.UCLA.EDU> Jacob -- I thought of another way of describing the RFC822 semantics of REPLY-TO last night, after I sent my reply to your original message. It may seem a bit backwards at first, but I think it makes the situation somewhat clearer than the traditional perspective. (1) Think of *every* message as *always* having a REPLY-TO field -- at least conceptually. Consider that RFC822 has provided a short-cut in the interests of brevity and non-redundancy in message headers. Namely, if the "Reply-to:" header line contents are identical to the "From:" line contents, then the "Reply-to:" line can be (and probably will be) omitted from the header when the message is sent. The receiving end, on finding that a message has no "Reply-to:" line in its header, will implicitly create a REPLY-TO field by copying the FROM field. If you assume in this way that *all* messages have REPLY-TO fields, the rules for constructing the recipient lists for replies suddenly become much simpler and more straightforward. (2) Automatic replies *always* go to the addresses in the REPLY-TO field (which, by the above assumption, always exists in every message). The FROM field is *never* considered when addressing a reply. To be sure, the REPLY-TO field may have been implicitly derived from the FROM field when the message was originally read and the header was parsed -- but once this operation has been done, we simply concen- trate on the fact that the message has a REPLY-TO field, forgetting completely about where it came from. (3) You can then distinguish, if you wish to, between "personal" and "group" replies in the following way: (a) "Personal" replies would go only to the address(es) in the REPLY-TO field. (b) "Group" replies would go to the address(es) in the REPLY-TO, TO, and CC fields. It is debatable, by the way, whether a "group" reply should also go to the SENDER address(es); Section 4.4.4 (page 22) of RFC822 states that the SENDER field should never be used automatically when replying to a message. I would suggest that the SENDER field be included in the address list of a "group" reply only through invocation of a non-default option, if indeed at all. You expressed some confusion/concern over whether RFC822's semantics of the REPLY-TO field envision the use of this field in "personal" replies or in "group" replies. I think what happened was that RFC822 assumed that the message *author* -- *not* the recipient -- would make the deci- sion as to who would receive replies. At the time (and probably even now), most people were accustomed to mail systems where the only kind of reply was what you term a "personal" reply (i.e., to the author of the message and no one else). The REPLY- TO field was apparently envisioned as a way to allow the message sender to specify a wider audience for any replies to his message, without having to assume that the person at the other end had a mail system capable of automatically constructing a "group" reply (since most people didn't have such mail systems anyway). Hence, RFC822 does not really seem to provide for the kind of distinc- tion between "personal" and "group" replies which you would like to make. Clearly, the issues involved were not fully appreciated, and had not been thoroughly thought out, when the standard was written. My making this observation is not so much an indictment of the people responsible for RFC822 (who, I think, did a very good job considering the constraints they were working under) as it is a realization that our understanding of the possibilities of electronic mail has kept on expanding. I think this is a good occasion to renew my suggestion that some person or group should investigate issues such as these, and make sure that the various kinds of recipient lists (personal replies, group replies, con- ferences, etc.) can be adequately represented in X.400 or other appro- priate international standards. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@UCLA-LOCUS.ARPA -or- wales@LOCUS.UCLA.EDU UUCP: ...!(ihnp4,ucbvax)!ucla-cs!wales  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA.ARPA; 14 Jul 85 16:55:31 EDT Date: Sun 14 Jul 85 13:53:17-PDT From: Mark Crispin Subject: REPLY-TO field To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Message-ID: <12127009593.13.CRISPIN@SUMEX-AIM.ARPA> As I understand it, REPLY-TO was created for the common office situation in which some other person (e.g. a secretary) handles the individual's mail. The message would be "from" the person, but the secretary would be the "sender" and possibly also the "reply to". -------  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 16 Jul 85 06:43:28 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667811068292437@MIT-MULTICS.ARPA>; 16 Jul 1985 06:37:48 edt Date: 16 Jul 85 03:15 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people , Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: > %FROM: Rich Wales Message-ID: <113894@QZCOM> In-Reply-To: <490135244-13242-wales@DIANA.LOCUS.UCLA.EDU> > > I think this is a good occasion to renew my suggestion that some person > or group should investigate issues such as these, and make sure that the > various kinds of recipient lists (personal replies, group replies, con- > ferences, etc.) can be adequately represented in X.400 or other appro- > priate international standards. ISO will maybe do some work in this area. ISO has sent out a vote to member countries of whether ISO should consider this topic, if positive, ISO will begin working on it. There are some other people in Europe working in this area too, to provide input to ISO, within the European COST-11-ter project. Unfortunately, few Americans have participated in this work so far. At the last ISO meeting on the subject, there was no American represen- tative at all. Another problem is that CCITT is much more important for future standards in this area than ISO, and there is an obvious risk that CCITT will standardize distribution lists in a way which does not understand these problems. If any of you have any influence on CCITT work, please try to use it to get CCITT to accept that group communication is more complex than they may believe, and that they should consider the work being done in ISO in this area.  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 17 Jul 85 14:09:18 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667923885722126@MIT-MULTICS.ARPA>; 17 Jul 1985 13:58:05 edt Date: 17 Jul 85 18:14 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: Subject: Ambiguity with the REPLY-TO field Message-ID: <114355@QZCOM> In-Reply-To: <8507170110.AA03575@ucbmonet.ARPA> The solution proposed by kre@ucb-vax.arpa is neat, but I am not sure that it will work. Many mailing lists distribute to sub- mailing-lists in many stages, and it will be difficult to arrange for the personal copy and the list copy to follow the same path through the hosts with the sub-lists. Another problem is that users may not always, generally, want their personal copies to be discarded if the message will reach them via a bulletin-board. In COM, where all mailing list messages are read via computer conferences, we have found it very useful to have a facility to send a message in exceptional cases both to the conference and at the same time to a personal mailbox of a member of that conference. (COM will then normally only show him the message in his mailbox, not in the conference.) The reason for this is that he may delay reading the conference if he has much to do, and our users usually read their personal mailboxes first, so this is a way of giving priority to certain conference messages to certain members of those conferences.