Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA 24 Jul 85 18:01:05 EDT Received: FROM HIS-PHOENIX-MULTICS.ARPA BY CISL-SERVICE-MULTICS.ARPA WITH dial; 24 JUL 1985 09:26:30 EDT Date: Tue, 23 Jul 85 21:43 MST From: "Ronald B. Harvey" Subject: US participation in ISO SC18/WG4 To: header-people@MIT-MC.ARPA Message-ID: <850724044330.414447@HIS-PHOENIX-MULTICS.ARPA> There was no US representation at the group comm ad hoc because the US representative was very non-communicative and then dropped out of the work (by changing jobs and leaving the country). I am now the US rep for SC18/WG4, and I did just attend the recent meeting in Paris. I would welcome participation from other people interested or experienced in electronic mail systems. The next meeting of the US group is August 26-30 in Waltham, Mass. If you send mail, I will give you more info (as it becomes available). The US group is ANSI committee X3V1, task group 4.  Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA 24 Jul 85 19:22:27 EDT Received: FROM HIS-PHOENIX-MULTICS.ARPA BY CISL-SERVICE-MULTICS.ARPA WITH dial; 24 JUL 1985 19:16:34 EDT Sender: "Ronald B. Harvey" Date: Wed, 24 Jul 85 16:16 MST From: "Ronald B. Harvey" Subject: ANSI participation on messaging/conferencing To: header-people@MIT-MC.ARPA Message-ID: <850724231620.057466@HIS-PHOENIX-MULTICS.ARPA> I neglected to make sure that my mail system would give a valid address for me on my previous message. Sorry. For more information on ANSI participation, you might try contacting the chairman of X3V1 or the chairman of the task group on messaging. They are, respectively: L.M. Collins Chair, X3V1 IBM Corporation IBM Tower at Williams Sq. 5205 N. O'Connor Road Suit 200 Irving, Texas 75039-5050 (214) 556-7690 R. H. Christie Control Data 304 North Dale Street St. Paul, MN 55103 (612) 292-2183  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 30 Jul 85 13:32:53 EDT Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2669033252113154@MIT-MULTICS.ARPA>; 30 Jul 1985 10:07:32 edt Date: Tue, 30 Jul 85 08:48:42 EDT From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: header-people@MIT-MC.ARPA Message-ID: <848983@UMich-MTS.Mailnet> Subject: SMTP source verification. Lots of people appear to be thinking that a verification of IP addresses, e.g., in the case of SMTP is not necessary. I am not sure whether and where this was already discussed before, but I get the impression that the proliferation of low cost workstations connected to, say, campus computer networks might change our minds in two to three years in an environment where most of the power (besides parts of routing) will go to these hosts. I presume that this will be a newly evolving problem which could not easily show up so far. What are the suggested measures against faked message headers in that case? IP source verification? Something else? Or is this considered to be no problem at all? -- Hans-Werner  Received: from sri-lanka.ARPA by MIT-MC.ARPA 30 Jul 85 15:48:24 EDT Received: by sri-lanka.ARPA at Tue, 30 Jul 85 12:44:20 pdt Date: Tue, 30 Jul 85 12:44:20 pdt From: E. Howard Alt Message-Id: <8507301944.AA01567@sri-lanka.ARPA> To: header-people@mit-mc.ARPA Subject: Re: SMTP source verification. One good way to do authentication is with encryption of the public key variety. The person would encrypt the message with his private key, and people would decrypt the information with his public key (carried along with the message) to read the headers and text. No one can change the headers of text of the message, because they can't make ciphertext that will be decrypted with his public key. You can't lie about who sent the message because you wouldn't be able to decrypt the message. Simple, eh? The logistics are a bit more complicated... Howard.  Received: from sri-tsc by MIT-MC.ARPA 30 Jul 85 17:35:13 EDT Received: from sri-lanka.ARPA by sri-tsc at Tue, 30 Jul 85 12:13:05 pdt Received: by sri-lanka.ARPA at Tue, 30 Jul 85 12:00:48 pdt Date: Tue, 30 Jul 85 12:00:48 pdt From: E. Howard Alt Message-Id: <8507301900.AA01495@sri-lanka.ARPA> To: header-people@mit-mc.ARPA Subject: Re: SMTP source verification. One good way to do authentication is with encryption of the public key variety. The person would encrypt the message with his private key, and people would decrypt the information with his public key (carried along with the message) to read the headers and text. No one can change the headers of text of the message, because they can't make ciphertext that will be decrypted with his public key. You can't lie about who sent the message because you wouldn't be able to decrypt the message. Simple, eh? The logistics are a bit more complicated... Howard.  Received: from rice.ARPA by MIT-MC.ARPA 30 Jul 85 20:49:06 EDT Received: from iapetus by rice.ARPA (AA16206); Tue, 30 Jul 85 19:45:56 CDT Received: by iapetus (AA09123); Tue, 30 Jul 85 19:37:18 CDT Date: Tue, 30 Jul 85 19:31:06 CST From: Scott Alexander Subject: Re: SMTP source verification. To: header-people@mit-mc.ARPA Message-Id: <491617866.salex@Iapetus.ARPA> In-Reply-To: a message from E. Howard Alt dated Tue, 30 Jul 85 12:00:48 pdt So you check my ip addr and it agrees with my name in the host table. But if this is my workstation, I can cause it to build ip packets w/ any addr I like. So now instead of just faking the HELO command I have to fake ip packets, too. On an ethernet, even checking the ethernet addr doesn't tell you anything since I can often reset it. There is no way to get around faking mail. You can make it harder. The people with whom I have dealt who are willing to go to the trouble to fake mail are willing to format ip packets also. Scott Alexander Rice University salex@rice (713) 527-6012  Received: from UCI-ICSA by MIT-MC.ARPA 31 Jul 85 03:06:36 EDT To: Scott Alexander cc: header-people@mit-mc.arpa, stef@uci-icsa Subject: Re: SMTP source verification. In-reply-to: Message of 30 Jul 85 19:31:06 CST <491617866.salex@Iapetus.ARPA> Date: 31 Jul 85 00:02:55 PDT (Wed) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 31 Jul 85 00:04:16 PDT (Wed) The authentication of network mail issue has been discussed many times over the last decade, in various discussion lists, including header-people and msggroup. Each such discussion has ended by recognizing that authenication always requires some kind of out-of-band verification mechanism, like the county recorder for property deeds and important legal documents. Use of encryption fits this solution. The keys are issued/distriuted out of band (or you have done something magic to include the key in the message in such a way that it cannot be faked). Sending the public key in the message is not the case I mean here. it is the private keys that go out of band. It is important to note that the need for authentication is relative to the cost of being unsure of a sender's identity. In most netmail cases, it is easy to verify by checking back via reply mail (or forwarding back a copy) to the supposed sender. This is going out of band again though. And, I must agree that SMTP is rather too promiscuous for me as we populate our local area networks with Unix Class Workstations which are administered by whoever happens to be at the console in too many cases. I worry about them in more ways than just mail! In too many cases, anyone can become root and can then use those privs to attack other hosts, and ... Sigh! Stef  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 31 Jul 85 09:51:36 EDT Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2669118556261255@MIT-MULTICS.ARPA>; 31 Jul 1985 09:49:16 edt Date: Wed, 31 Jul 85 06:56:42 EDT From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: header-people@MIT-MC.ARPA, salex@rice.ARPA Message-ID: <850391@UMich-MTS.Mailnet> Subject: Re: SMTP source verification. Ok, but you'd have to be careful not to mess up IP routing back to you. I was not intending to say that IP source verification would resolve all the SMTP authentication problems but rather asking what others think whether it would be a worthwile thing to do to improve the situation to some extend, even while confusing layering. -- Hans-Werner  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 6 Aug 85 15:52:31 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2669658086551778@MIT-MULTICS.ARPA>; 06 Aug 1985 15:41:26 edt Date: 06 Aug 85 16:46 +0100 From: Mats_Ohlin_FOA2%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Mats_Ohlin_FOA2%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, Bengt_Olsen_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Gun_Robertsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Cc: Bengt_Olsen_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Gun_Robertsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: SMTP source verification. Message-ID: <117042@QZCOM> In-Reply-To: <491617866.salex@Iapetus.ARPA> Within the Commission of the European Communities there is a project OSIS (Open Shops for Information Services) that aims to develop a "smart card" including a chips for RSA-encryption used so that (only) the legitimate user could produce (using the secret key) signed (and timestamped) messages that anyone could decrypt (using the public key) thus verifying the identity of the sender. The interational banking organisations are very interested as well - even if the first step aims to provide a simple, non-contract technique for data base users to get access. The OSIS project also includes contracting procedures via electronic media.  Received: from csnet-relay by MIT-MC.ARPA 7 Aug 85 12:37:55 EDT Received: from ubc by csnet-relay.csnet id a022573; 7 Aug 85 9:18 EDT Date: Wed, 7 Aug 85 06:13:25 pdt Received: by ubc.csnet id AA13034; Wed, 7 Aug 85 06:13:25 pdt From: Peter Stokes To: header-people@MIT-MC.ARPA Message-Id: <195:stokes@cmc.cdn> Subject: Please remove Please remove me from the Header-People distribution list. Thanks in advance  Received: from locus.ucla.edu by MIT-MC.ARPA 8 Aug 85 20:58:23 EDT Date: Thu, 8 Aug 85 17:30:47 PDT From: Rich Wales To: HEADER-PEOPLE@MIT-MC.ARPA Subject: Non-domain-style nicknames in outgoing mail Message-ID: <492395447-12731-wales@DIANA.LOCUS.UCLA.EDU> I know this topic is probably more appropriate for NAMEDROPPERS than HEADER-PEOPLE -- but I've already mentioned it twice to NAMEDROPPERS, and I have a feeling that the people who need to see this message most badly are not on that list. So . . . Even though it is now almost four weeks since the scheduled date for making the distributed domain data base official, there are still quite a few hosts on the net which continue to use old, non-domain-style nick- names in the return addresses of their outgoing mail. Here is a partial set of such hosts, based on analysis of a log of incoming mail arriving at LOCUS.UCLA.EDU during the past week: ACC CVL MARYLAND ORNL-MSR UCI-ICSA AERO2 CWRU-20B MIT-CCC PESCADERO UCI-ICSD AEROSPACE DEC-HUDSON MIT-COMET SDAMOS UCI-ICSE AIDS-UNIX DIABLO MIT-MC SDCSVAX UW-BEAVER ANAD EDN-VAX MIT-OZ SRI-TSC WHITNEY BBN-SPCA ISI-HOBGOBLIN MITRE-BEDFORD SRI-UNIX YALE-APVAX BERKELEY ISI-VAXA NBS-VMS STAT-L YUMA CCA-UNIX JPL-VLSI NOSC SU-SHASTA CIT-VAX LELAND NRL-AIC TOVE CSNET-RELAY LLL-CRG NTA-VAX UCBMONET In case there are some system administrators out there who are still not aware of recent and not-so-recent developments, the problem is that ALL of the old, non-domain-style host nicknames will become obsolete as the net converts over to the new distributed domain data base which is going to replace the HOSTS.TXT file. This means that your users are going to find out the hard way that more and more people around the net are not going to be able to reply to their mail any more. ************************************************************************ * QUICK RULE-OF-THUMB TEST: If the host name in the "From:" line of * * mail sent by your host does not have at least ONE period in it, it * * is one of these "old, non-domain-style nicknames" that is going to * * become obsolete and meaningless VERY soon. * ************************************************************************ Anyone who still does not understand what I am talking about should get a copy of ARPA RFC921 and read it very carefully. I am aware that some of the hosts listed above already know about the problem and are working on fixing it. I also accept the possibility that some of the hosts listed above may be the innocent victims of some other relay host (say, the residing place of a mailing list) which is munging their return addresses as it sends the mail along. However, if your host is listed above, you should check RIGHT AWAY to see if in fact your mail system is generating the old-style host names. If it is, you should modify it ASAP to use your host's official name (which in most cases ends in the five characters ".ARPA"). Just to set the record straight, I am NOT a card-carrying member of the mythical Network Police :-}. All I'm trying to do is help avert a growing crisis as more and more hosts (eventually the whole net) convert to the domain data base, thereby losing the ability to send mail to the old, non-domain-style host names. I would much rather see the problem fixed at its sources than spend all my time trying to explain to all the users on the host I play "mail guru" for why the return addresses in the mail they get are no good -- and I hope other people feel the same way. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales  Received: from lll-tis-b.ARPA by MIT-MC.ARPA 23 Aug 85 20:06:14 EDT Return-Path: Received: by lll-tis-b.ARPA; Fri, 23 Aug 85 17:05:53 pdt Message-Id: <8508240005.AA23144@lll-tis-b.ARPA> Date: Fri Aug 23 17:05:51 1985 From: mcb@lll-tis-b (Michael C. Berch) Subject: PROFS to RFC822/SMTP conversion? To: header-people@mit-mc.ARPA, msggroup@brl.ARPA Status: N We're looking for a way to connect IBM systems using the PROFS mail system to the DDN. This presumably would involve producing RFC822 headers and running a SMTP server/client process. Does a product exist that accomplishes either or both of these? This assumes that the IBM system either has a TCP/IP implementation or talks to a gateway that provides TCP/IP service for it. Any information, anecdotes, vendor names, or suggestions gratefully appreciated. Thanks in advance. ----- Michael C. Berch Control Data Corp. / Lawrence Livermore Natl. Laboratory mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb  Received: from gwen.ARPA by MIT-MC.ARPA 26 Aug 85 13:10:16 EDT Message-Id: <8508261710.AA00243@gwen.ARPA> Received: by gwen.ARPA; Mon, 26 Aug 85 12:10:24 EST To: tcp-ip@sri-nic.arpa, header-people@mit-mc.arpa Subject: mail getting to purdue Date: 26 Aug 85 12:10:21 EST (Mon) From: Paul M. Albitz I understand there are some sites that are having trouble mailing to purdue. We have moved to a new building and have lost one imp connection and its associated address (10.0.0.37). The names purdue.arpa and purdue.edu are now associated with the machine purdue-mordred with the address 128.10.0.2. If you are having trouble mailing to us, please update your files. Paul Albitz  Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:19:48 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023674; 7 Sep 85 11:04 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:34:53 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023885; 7 Sep 85 11:34 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:19:48 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023674; 7 Sep 85 11:04 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 12:12:13 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a024092; 7 Sep 85 12:06 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:34:53 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023885; 7 Sep 85 11:34 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:19:48 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023674; 7 Sep 85 11:04 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 15:02:04 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a024377; 7 Sep 85 12:50 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 12:12:13 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a024092; 7 Sep 85 12:06 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:34:53 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023885; 7 Sep 85 11:34 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:19:48 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023674; 7 Sep 85 11:04 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 15:02:04 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a024377; 7 Sep 85 12:50 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 12:12:13 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a024092; 7 Sep 85 12:06 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:34:53 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023885; 7 Sep 85 11:34 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 11:19:48 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id a023674; 7 Sep 85 11:04 EDT Received: from Louie.UDEL.EDU by MIT-MC.ARPA 7 Sep 85 10:57:27 EDT Received: from mit-mc.arpa by .Louie.UDEL.EDU id ab23454; 7 Sep 85 10:45 EDT Received: from csnet-relay by MIT-MC.ARPA 7 Sep 85 05:56:52 EDT Received: from hplabs by csnet-relay.csnet id a021203; 7 Sep 85 5:54 EDT Received: by HP-VENUS id AA24832; Fri, 6 Sep 85 19:30:49 pdt Date: Fri, 6 Sep 85 19:27:16 PDT From: Scott McGregor Received: by hpccc id AA18557; Fri, 6 Sep 85 19:27:16 PDT Message-Id: <8509061827.AA18557@hpccc> Return-Receipt-To: hpccc!mcgregor@HP-LABS Telephone: (415) 857-5875 Postal-Address: Scott McGregor, Hewlett-Packard, PO Box 10301, Mail stop 20CH, Palo Alto CA 94303-0890 Origin: tty622 on hpccc; Fri, 6 Sep 85 19:27:16 PDT To: hplabs!HEADER-PEOPLE@mit-mc.ARPA Subject: Sendmail munges addresses containing dollar signs. Cc: mcgregor@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 8 Sep 85 09:43:18 EDT Received: by UCB-VAX.ARPA (4.24/5.3) id AA08617; Sun, 8 Sep 85 06:38:11 pdt From: decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!hpccc!mcgregor%hplabs.csnet@CSNET-RELAY.ARPA Date: 7 Sep 85 19:49:04 GMT Subject: Sendmail munges addresses containing dollar signs. Message-Id: <1312@brl-tgr.ARPA> Sender: usenet-admin@Berkeley Errors-To: usenet-admin@Berkeley To: header-people@Berkeley ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 8 Sep 85 09:43:31 EDT Received: by UCB-VAX.ARPA (4.24/5.3) id AA08630; Sun, 8 Sep 85 06:38:34 pdt From: decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!hpccc!mcgregor%hplabs.csnet@CSNET-RELAY.ARPA Date: 7 Sep 85 19:51:16 GMT Subject: Sendmail munges addresses containing dollar signs. Message-Id: <1314@brl-tgr.ARPA> Sender: usenet-admin@Berkeley Errors-To: usenet-admin@Berkeley To: header-people@Berkeley ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 8 Sep 85 10:12:29 EDT Received: by UCB-VAX.ARPA (4.24/5.3) id AA08702; Sun, 8 Sep 85 06:43:59 pdt From: decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!hpccc!mcgregor%hplabs.csnet@CSNET-RELAY.ARPA Date: 7 Sep 85 19:54:47 GMT Subject: Sendmail munges addresses containing dollar signs. Message-Id: <1328@brl-tgr.ARPA> Sender: usenet-admin@Berkeley Errors-To: usenet-admin@Berkeley To: header-people@Berkeley ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 8 Sep 85 10:12:41 EDT Received: by UCB-VAX.ARPA (4.24/5.3) id AA08767; Sun, 8 Sep 85 06:45:31 pdt From: decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!hpccc!mcgregor%hplabs.csnet@CSNET-RELAY.ARPA Date: 7 Sep 85 20:00:18 GMT Subject: Sendmail munges addresses containing dollar signs. Message-Id: <1337@brl-tgr.ARPA> Sender: usenet-admin@Berkeley Errors-To: usenet-admin@Berkeley To: header-people@Berkeley ---------- "Sendmail munges addrs containing dollar signs" ---------- We have begun mail service with a mail system in which users names contain dollar signs ($). We are using Sendmail on an Amdahl 470 running V.2 Unix. Whenever we mail to an address containing a dollar sign, or receive mail which contains a dollar sign in the To address field it gets munged by Sendmail. Specifically, the mail will be delivered with the TO field slightly altered. For example, mail to going into sendmail like this, To: mvs!$scott becomes To: mvs!cott while To: mvs!$will becomes To: mvs!hpcccill The reason for this strange behavior is that sendmail is interpretting the imbedded dollar sign and trailing character as a sendmail macro. "$s" in our sendmail.cf file isn't defined, so it comes out null, while "$w" is our local host name, so it comes out expanded as the host name. Now, only the text of the TO message is munged, the user name and host name passed as parameters to the mailer get the original name containing the dollar sign. Thus, at present, we can get the right parameter but the wrong text, or, by using sending to $$scott we can get $scott to appear in the To: field, but then the parameter (still $$scott) is wrong. Our question is how to get sendmail to pass the dollar sign containing addresses without munging them. We have already identified ways of dealing with these dollar sign addresses non-transparently, but we are still wondering if we can pass mail containing dollar signs without munging them. If anyone has already done this and can send me the proper sendmail.cf config definitions, I would appreciate a copy. Also, if someone hasn't done this but finds this an interesting puzzle and comes up with something that should work send me a copy. (I doubt that others in this forum would have much interest, so it is probably best to mail to me directly.) Thanks! Scott McGregor ...!hplabs!hpccc!mcgregor HP Corporate Computing Center  Received: from csnet-relay by MIT-MC.ARPA 8 Sep 85 12:46:04 EDT Received: from bostonu by csnet-relay.csnet id av07018; 8 Sep 85 12:42 EDT Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA24256; Sun, 8 Sep 85 01:21:28 edt Date: Sun, 8 Sep 1985 01:19 EDT Message-Id: <[BUCS20].JSOL. 8-Sep-85 01:19:42> From: Jon Solomon To: Scott McGregor Cc: HEADER-PEOPLE@MIT-MC.ARPA Subject: Sendmail munges addresses containing dollar signs. Phase-Of-The-Moon: LQ+1D.7H.34M.19S. In-Reply-To: Msg of 6 Sep 1985 22:27-EDT from Scott McGregor You probably can't get the sendmail.cf file to deal with this, as it is the primary reason for the $'s existance in the parsing rules. Like any "quote character", sending two of them generally allows one to pass through. You will probably have to modify the source to sendmail (if you have it) to explicitely copy the To: field byte by byte, adding an extra $ for each $ encountered. Such a fix is trivial: fix_to_line(to_line) char *to_line; { char line[MAX]; int i, len, j = 0; len = strlen(to_line); for (i = 0; i < len; i++) { if (to_line[i] == '$') line[j++] = '$'; line[j++] = to_line[i]; } return(&line); Cheers, --JSol  Received: from isi-vaxa.ARPA by MIT-MC.ARPA 10 Sep 85 19:25:20 EDT Received: by isi-vaxa.ARPA (4.12/4.7) id AA06400; Tue, 10 Sep 85 16:27:19 pdt From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) Message-Id: <8509102327.AA06400@isi-vaxa.ARPA> Date: 10 Sep 1985 1627-PDT (Tuesday) To: Header-People@MIT-MC.ARPA Cc: Subject: AUTOMATED ROUTE CHOICES Are there any ARPA INTERNET standards regarding automated routing decisions for mail messages based upon factors such as availability, load, geographic location, etc. ? For example, I am currently developing an ARPA-to-FOREIGN mail relay. Depending on system use, there may be more than one instance of a relay path between the ARPA and FOREIGN mail systems. It would be nice if one could use something like the following for the destination: @RELAY-FOREIGN This in turn could resolve to any of the following: @RELAY-PATH-1 @RELAY-PATH-2 . . . @RELAY-PATH-n The transport mechanism involved would perform geographic priority selection, queries for loading and availability, or some such thing, in order to select the actual relay path used. Is this do-able, has it been done, has there been any discussion ... ??? Jeff  Received: from WISCVM.ARPA by MIT-MC.ARPA 11 Sep 85 18:18:23 EDT Received: from (MAILER)DBNGMD21.BITNET by WISCVM.ARPA on 09/11/85 at 17:19:44 CDT Date: Wed, 11 Sep 85 21:35 CET From: Peter Sylvester To: Header People Subject: Echos Hi folks, I already have eight copies of Scott MCGregor's "letter" in mailbox. It seems to me that the mailing systems are very noisy and there are high mountains around in the ARPA, UCCP countries. I'm looking forward of the copies of this message. Peter (working late as usual)  Received: from locus.ucla.edu by MIT-MC.ARPA 18 Sep 85 14:42:23 EDT Date: Wed, 18 Sep 85 11:35:07 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Invalid/questionable host names in mail Message-ID: <495916507-12612-wales@DIANA.LOCUS.UCLA.EDU> The following summary of invalid or questionable usage of host names in outgoing mail is based on approximately 5,700 ARPANET messages received at LOCUS.UCLA.EDU between 14-Aug-85 and 11-Sep-85. I analyzed the host names used in the "return path" addresses of incoming messages (SMTP "MAIL" commands), as well as the names which the remote hosts used to identify themselves (SMTP "HELO" commands). Specifically, I attempted to find two different usage patterns for host names: (1) Host names which did not appear in the official NIC host name table, HOSTS.TXT -- since addresses with such names cannot be replied to. (2) Non-domain-style "nicknames" which appear in the NIC table. Since these names are not going to be carried over to the new distributed domain data base, addresses with such names cannot be replied to from hosts which have converted their software to use the data base. For this study, I used Version 481 of the host name table (12-Sep-85). I would make the following recommendations based on this study. Keep in mind, please, that I am only a "private citizen" and do not hold any net-wide position of responsibility; these are only suggestions, not commands from on high. (1) EVERY host responsible for one of the undefined return-path host names in Section 1 below should take IMMEDIATE steps to correct the situation -- either by using the correct host name in outgoing mail, or by having their name of choice registered with the NIC so that it will be added to the host name table. Hosts whose names are in the domain data base, but not in the NIC table, should consider the fact that -- whether we like it or not -- a sizable fraction of the net has not yet converted to the domain data base, is not liable to do so for some time to come, and will thus continue for the time being to be totally dependent on the NIC table for name->address mappings. You may not like this fact -- indeed, you may consider it to be a bletcherous and utterly irre- sponsible state of affairs -- but it is nevertheless the way things are, at least right now. Refusals "on principle" by isolated indi- vidual hosts to deal with those that are still using the NIC table is unlikely to accomplish anything (except to make it harder for people to send mail to each other). (2) EVERY host responsible for one of the non-domain-style nicknames in Section 2 below should convert over to the appropriate domain-style name as soon as possible. Since NO non-domain-style nicknames (i.e., host names without at least one period) will EVER be listed in the domain data base, these nicknames -- however near and dear they may be to the hearts of their users -- will slowly become useless as more and more hosts wean themselves from the NIC table and convert over to the domain data base. No ifs, ands, or buts, folks -- this is REALITY. (3) Hosts listed in Sections 3 and 4 below should take steps to make their "SMTP sender" or "net mailer" programs use a correct, domain- style host name in the SMTP HELO command. As in the case of return addresses, it is probably advisable (for the time being, at least) that new domain-style names be registered in the NIC table as well as in the domain data base. Although most SMTP servers in use today make no serious attempt to validate the HELO argument, some people have proposed to check the sending host's name and to reject the HELO command (thus blocking mail transfer) if the name is unknown. It therefore makes sense to ensure that the correct host name appears in the HELO. (4) Hosts who have converted over to using the domain data base may want to consider modifying their name->address mapping routines to try adding ".ARPA" to the end of a non-domain-style host name if it can- not be found in their tables "as is". (I.e.: if presented with the host name "PODUNK", try looking up "PODUNK.ARPA" before giving up.) This will let you make sense of most (though unfortunately not all) non-domain-style nicknames. I suggest this (admittedly disgusting) "hack" only because Murphy's Law dictates that lots of hosts will probably continue to use their old non-domain-style nicknames until the bitter end -- and maybe even beyond. Again, our first priority should hopefully be to max- imize the probabilities that mail will get through -- since large numbers of users on many systems are mail-naive in the extreme and will have absolutely not a clue as to what alternatives to try if the return address on a piece of incoming mail can't be replied to. Since much of the following summary was processed by hand, it may con- tain some minor errors. I take full responsibility for these and apolo- gize in advance to any hosts which I might have inadvertently pointed an accusing finger at. Also, I realize that many hosts listed below may already be aware of the fact that they are using an incorrect host name in their mail -- and are either at work on the problem, or are looking for a solution. Or, some hosts may have been using an incorrect name until very recently, but have now fixed things. My intent in posting this list is not to badger or criticize anyone; I am simply trying to help make sure everyone is aware of the problem and is doing whatever they can to resolve it. Further, let me emphasize that this summary covers only those hosts which have sent mail to LOCUS.UCLA.EDU during the past month. Just because a host is not listed does not necessarily mean that they are doing the right thing with regard to host names in mail. Since many of the people who most need to read this message probably do not subscribe to this list, I will also be sending individual messages to "postmaster" at each affected host (where the identity of said host can be determined). My apologies in advance to anyone who thereby gets a "double whammy" (or even a "triple whammy") from me on this subject. Unfortunately, I am not able to offer any specific help to anyone who is trying to fix their mail software. In particular, I am not a "sendmail" guru, and I do not have any fixes to "sendmail" which might be required in order to make it conform to current name requirements. If anyone has devised such fixes to various widely used mail systems, it might be nice if said fixes (or pointers to them) could be posted. ======================================================================== (1) The host name in the return-path address (SMTP MAIL command) is not in the NIC table. Return-Path Host Name Host Sending Mail EAERO2 AERO2.ARPA EAR.BERKELEY.EDU UCB-VAX.BERKELEY.EDU HOTDOG.ARPA DECWRL.ARPA IC.BERKELEY.EDU UCB-VAX.BERKELEY.EDU IPTO-VAX.ARPA IPTO.ARPA ISI-DAWN.ARPA.ARPA ISI-DAWN.ARPA MIRO.BERKELEY.EDU SEISMO.CSS.GOV MIT-BORAX.MIT.EDU MORDRED.PURDUE.EDU, SEISMO.CSS.GOV MIT-CLIO.ARPA SEISMO.CSS.GOV PLAYFAIR 36.10.0.171 SALLY.LOCAL SALLY.UTEXAS.EDU TP4 192.5.14.154 NOTES: (a) The names {EAR,IC,MIRO}.BERKELEY.EDU and MIT-BORAX.MIT.EDU do appear in the domain data base (but not in the NIC table). Hence, only hosts which have converted over to the domain data base can send mail to these places. The wizards at these places should seriously consider having these names listed in the NIC table, as well as in the domain data base. (b) In certain cases above, the "host sending mail" may have been acting as a relay for the actual originating host. Hence, the "host sending mail" is not necessarily the correct, official substitute for the undefined "return-path host name". (c) I have nary a clue as to the identity of "HOTDOG.ARPA". The full address was "sci!kuo@HOTDOG.ARPA". Ideas, anyone? (2) The host name in the return-path address (SMTP MAIL command) is listed in the NIC table -- but it is a non-domain-style nickname (and thus will never be in the domain data base). AERO2 GE-CRD MITRE-BEDFORD SRI-UNIX AERO3 GLACIER NLM-VAX SU-STAR AIDS-UNIX GREGORIO NRL-CSS TALCOTT BBN-UNIX IPTO-VAX NTA-VAX TOVE BBNCCV ISI-ELVIRA NYU-CMCL2 UCI-ICSA BERKELEY ISI-HOBGOBLIN OMNILAX UCI-ICSD CCA-UNIX ISI-VAXA ORNL-MSR UCI-ICSE CIT-750 JPL-MILVAX PESCADERO WHITNEY CIT-VAX LLL-CRG ROCKEFELLER YALE-APVAX DIABLO MARYLAND SAFE EDN-VAX MIT-EDDIE SRI-SPAM NOTES: (a) Berkeley was using domain-style names for a time, but was forced to switch back to using "Berkeley" for the time being due to some kind of software problem. The last word I had from them was that they were hoping to be using domain-style names again in another month or so. (b) Most of the above names can be converted to valid domain-style host names simply by adding ".ARPA". Exceptions to this rule are the Stanford hosts DIABLO, GLACIER, GREGORIO, PESCADERO, SAFE, and WHITNEY (whose official domain-style names are, respectively, SU-AIMVAX.ARPA, SU-GLACIER.ARPA, SU-GREGORIO.ARPA, SU-PESCADERO.ARPA, SU-SAFE.ARPA, and SU-WHITNEY.ARPA); IPTO-VAX, whose official domain-style name is IPTO.ARPA; and NYU-CMCL2, whose official name is NYU.ARPA. (c) Lots of messages relayed through mailing lists on YALE.ARPA showed non-domain-style nicknames in return-path addresses -- even though mail arriving directly from the hosts in question used the official names. I suspect the YALE.ARPA software may be rewriting the addresses as the mail is relayed through. I did not include any mail relayed through YALE.ARPA when putting together the above list on non-domain-style nicknames. (3) The host name given in the SMTP HELO command is not defined in the NIC table. (Some of the hosts in this category are not in the NIC table at all; one is listed only as a gateway.) The "official name/address" info below is derived from the Internet address of the host which actually made the SMTP connection. Official Name/Address Name in HELO Command AERO2.ARPA EAERO2.ARPA AIDS-UNIX.ARPA AIDS-GRAPE.ARPA IPTO.ARPA IPTO-VAX.ARPA ISI-DAWN.ARPA ISI-DAWN.ARPA.ARPA MIMSY.UMD.EDU MARYLAND.ARPA.ARPA MIT-MC.ARPA MIT-OZ MORDRED.PURDUE.EDU MORDRED.ARPA NYU.ARPA NYU-CMCL2.ARPA OMNILAX.ARPA OMNILAX.UUCP RIACS.ARPA RIACS-GW.ARPA THINK.COM GODOT.THINK.COM UCSF-CGL.ARPA UCSF-CGL.UCSF USC-OBERON.ARPA OBERON.ARPA YALE-COMIX.ARPA YALE-COMIX.YALE.ARPA YALE-MTRANS.ARPA YALE-MTRANS.YALE.ARPA 36.10.0.171 PLAYFAIR.ARPA 192.5.14.154 TP4.UUCP NOTES: (a) Despite their domain-like appearance, YALE-COMIX.YALE.ARPA and YALE-MTRANS.YALE.ARPA do not appear in the domain data base. (b) The name GODOT.THINK.COM is in the domain data base, but not in the NIC table. (d) As far as I can tell, MIT-MC.ARPA calls itself "MIT-MC.ARPA" most of the time. We recorded only two instances in which it called itself "MIT-OZ"; both times, it was acting as a mail relay for MIT-OZ (an internal MIT site, not on the Internet). (4) The host name in the SMTP HELO command is listed in the NIC table -- but it is a non-domain-style nickname (and thus will never be in the domain data base). As above, the "official name" info below is derived from the Inter- net address of the host which actually made the SMTP connection. Official Name Name in HELO Command AEROSPACE.ARPA AEROSPACE AMSAA.ARPA AMSAA BBNCCM.ARPA BBNCCM CSNET-RELAY.ARPA CSNET-RELAY IPTO.ARPA IPTO-VAX SU-AIMVAX.ARPA DIABLO SU-GLACIER.ARPA GLACIER SU-GREGORIO.ARPA GREGORIO MITRE-BEDFORD.ARPA MITRE-BEDFORD NRL-CSS.ARPA NRL-CSS SU-PESCADERO.ARPA PESCADERO SU-SAFE.ARPA SAFE TYCHO.ARPA TYCHO UCI-ICSA.ARPA UCI-ICSA UCI-ICSD.ARPA UCI-ICSD UCI-ICSE.ARPA UCI-ICSE UCL-CS.ARPA UCL-CS SU-WHITNEY.ARPA WHITNEY YALE.ARPA YALE ======================================================================== Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 18 Sep 85 18:06:04 EDT Date: Wed 18 Sep 85 15:07:03-PDT From: Mark Crispin Subject: proposed Mail Transfer Protocol To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Message-ID: <12144324527.25.CRISPIN@SUMEX-AIM.ARPA> Folks - I propose the formation of a committee to specify and design an Internet Mail Transfer Protocol to extend and ultimately replace SMTP/RFC822. I suggest that the various mail system implementors form a committee to meet at Stanford or ISI and subsequently carry on the discussion via netmail. My thoughts along this line are that a new command, XMTP, be defined in the SMTP command set. A successful response to an XMTP command will indicate the SMTP server's willingness to become an MTP server. This is upwards-compatible with the existing SMTP world, since a server that does not support MTP will reject the XMTP command and the transaction will proceed using SMTP. It is also superior to establishing a separate MTP service port, which would force every mail sender to try two ports before giving up. The MTP will have two goals: . expanded and completely machine-readable envelope . support for multi-media mail What I wish to do with the envelope is to completely eliminate the RFC822 header and have all information which was previously transmitted in the header appear in the envelope that is transmitted via MTP commands. This data will be completely machine-readable (esthetics as to what constitutes a "pretty header" will NOT be considered). Compatibility with CCITT and other mail transmission standards will be a strong consideration. Message headers transmitted over the network as we now know them will cease to exist. This information would be presented to users in a way determined by the local mail software. The local message system at the receiver's end would be free to write messages in RFC822 format in the user's mail file for the convenience of existing software. Or, it could use some completely different format; the protocol couldn't care less. The entire issue of whether or not mail relays should "reformat headers" will be laid to rest. There are no headers to reformat, and there will be well-defined heuristics on how the envelope is altered when it passes a relay. My ideas for multi-media mail are less well-defined, and could use input from the MMM folks. I am seriously planning on implementing this as a private protocol between TOPS-20's and other cooperating systems. I would like to see this be made an official experiment. I don't really want to write up an RFC yet because I feel it should be a group effort. Looking for a positive response! -- Mark -- -------  Received: from GODOT.THINK.COM by MIT-MC.ARPA 18 Sep 85 21:38:45 EDT Received: by GODOT.THINK.COM; Wed, 18 Sep 85 21:38:20 edt Date: Wed, 18 Sep 85 21:38:20 edt From: bruce@THINK.COM (Bruce Nemnich) Message-Id: <8509190138.AA10240@GODOT.THINK.COM> To: wales@LOCUS.UCLA.EDU Cc: header-people@mit-mc.ARPA, hostmaster@sri-nic.ARPA In-Reply-To: Rich Wales's message of Wed, 18 Sep 85 12:06:01 PDT Subject: Host name "GODOT.THINK.COM" in SMTP HELO command Rich, I tried, but the NIC seems to have a policy of only allowing one "domain" name per host in the host table. Specifically, they refused to include GODOT.THINK.COM as a nicname for THINK.COM. I definitely want an entry in the NIC host table for THINK.COM, since I want to use that name as a site gateway, regardless of what machine within THINK.COM it actually points to (so people can send mail here without knowing specific host names). I also make mail from this site to appear to come from USER@THINK.COM, regardless of the machine on which it was written, to provide a simple interface from the outside. GODOT.THINK.COM is the canonical name for the host which happens to be doing all the work of delivering mail at the moment. Why the NIC doesn't want aliases within domains is beyond me. It should be set up correctly in our nameserver. --bruce  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 19 Sep 85 16:02:35 EDT Date: 19 Sep 1985 13:00:25 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: invalid names & multiple names & Godot To: Header-People@MIT-MC.ARPA, Hostmaster@SRI-NIC.ARPA Well, it seems inconsistent to allow a host two have two names like FOO-BAR.ARPA and BAR.FOO.EDU but not allow it to have two names like GODOT.THINK.COM and THINK.COM So, i agree that the NIC is at least confused about what it is trying to do with naming policy. --jon. -------  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 19 Sep 85 22:18:18 EDT Date: 19 Sep 1985 19:14:37 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: proposed mail transfer protocol - multimedia To: header-people@MIT-MC.ARPA Mark Crispin: Mark, I think your proposal is a terrific idea! It clearly is time to move beyond the current mail procedures and modes used in the ARPA community. The goals of having machine oriented envelope and headers, and multimedia data in messages are really good ones. My thoughts on how to do it differ slightly from yours, though. I see no point in tying ourselves to the dead weight of 821/822. What we need to do is different enough that, i think, we should start with a clean slate. We should use a different protocol, a completely new server implementation, and a different contact address (e.g., TCP port). Among the difficulties in attempting to evolve into a multimedia mail system from the current 821/822 system is the issue of eight bit bytes. There are a lot of implementations out there that some how don't preserve all eight bits of the data bytes transmitted. To support multimedia in any reasonable way all eight bits have to be preserved. One of the lessons learned is that it takes a lot of energy and time to evolve a mass of existing programs from one level of functionality to another. Sometimes it is much easier to start with a clean slate. The point of compatibility with CCITT is a good one, too. In fact the X.400/MHS proposals provide a lot of what we want. It might be that the best thing to do next is to implement an X.400/MHS mail service for the ARPA community, that is implement X.400/MHS on top of TCP. Then to really push this to support all the functionality of our old 821/822 system and to try out a lot of multimedia features. Of course, there is the problem of intercommunicating between the new system and the old system. There are people trying to figure out how to transform mail between the X.400/MHS system and the 821/822 system already. I am sure some transforms can be developed and relays for such mail interoperation will appear. I am also sure that some thing will be lost in the transformation (in each direction). Also, most people like to have one mailbox, so a user of the new system will want any mail that arrives via the old system automatically converted and entered into his new-system mailbox, and vice versa. There are a few people that have been playing with multimedia mail for a few years already. It is time to put some more energy into this activity or to get some other people to do something. We should take a good look at what they have, use the good parts, fix the bad parts, make it compatible with X.400/MHS if possible, and run with it. ISI would be happy to host a meeting of interested parties to further discuss this topic and outline some plan of attack. If we do enough homework before such a meeting we might even be able to agree on a draft protocol. ISI has the right facilities to give some demonstrations of what has been done aleady in experiments with multimedia mail. I think it might be helpful to move this discussion to the MMM-People list. Anyone that wants to follow it is welcome to join. Just send your name and mailbox to MMM-PEOPLE-REQUEST@USC-ISIB.ARPA. --jon. -------  Received: from WISCVM.ARPA by MIT-MC.ARPA 20 Sep 85 04:01:50 EDT Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 09/20/85 at 03:00:26 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6986; Fri, 20 Sep 85 09:50:45 O Date: Fri, 20 Sep 85 09:48 O From: Henry Nussbacher Subject: RFC920 country codes To: Can someone please post a list of all upper level domain names? I know of those published in RFC920 (.EDU, .GOV, .MIL, .COM, .ORG) but others were alluded to such as country codes - i.e. .UK. Thanks, Hank  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 22 Sep 85 17:06:45 EDT Received: by UCB-VAX.ARPA (5.22/5.9) id AA25424; Sun, 22 Sep 85 14:07:08 PDT Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA02857; Sun, 22 Sep 85 14:06:45 pdt Message-Id: <8509222106.AA02857@ucbjade.Berkeley.Edu> Date: 22 September 85 17:05 EDT From: RMXJ%CORNELLA.BITNET@Berkeley.EDU Subject: X.400/MHS implementation To: HEADER-PEOPLE@mit-mc.arpa To Jon Postel, Mark Crispin and other interested parties: At the EARN (European Academic Research Network) Technical Meeting in Geneve, Switzerland last Thursday and Friday, we discussed moving EARN (which connects to BITNET via two international lines paid for by IBM) to X.400. In fact, we *MUST* do so. The PTTs (Post Office, Telephone, and Telegraph) which own and operate *ALL* the lines in Western Europe have demanded that EARN migrate to an X.400 network in conformation with the ISO and CCITT recommendations. EARN has until the end of 1987 to accomplish this. Work has started to be progressed in this area. It was decided to use a product that is coming out of Heidelberg to accomplish this migration. EARN is almost in every country in Western Europe. By the end of the month, the final connections to the remaining countries will be complete. On Monday, Greece will connect from Crete to Italy, and Finland will connect from FINHUT (the Finnish Helsinki Institute of Technology) to Stockholm, Sweden and Belgium will connect up from Brussels to Paris, France. Anyone interested in communicating with the technical coordinators in EARN should write to me and I will put you in touch with them. There is one technical coordinator in each country as well as a European Master Coordinator (EMC). -- Gligor Tashkovich EARN Internetwork Consultant  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 23 Sep 85 02:44:53 EDT Received: by UCB-VAX.ARPA (5.22/5.9) id AA02626; Sun, 22 Sep 85 23:45:09 PDT Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA07701; Sun, 22 Sep 85 23:44:46 pdt Message-Id: <8509230644.AA07701@ucbjade.Berkeley.Edu> Date: 23 September 85 02:44 EDT From: RMXJ%CORNELLA.BITNET@Berkeley.EDU Subject: (copy) Msg of Sunday, 22 September 1985 17: To: HEADER-PEOPLE@mit-mc.arpa Originally sent from: COMSAT@MIT-MC.ARPA Originally sent to: RMXJ@CORNELLA Return-Path: <> Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA07607; Sun, 22 Sep 85 23:27:03 pdt Received: by UCB-VAX.ARPA (5.22/5.9) id AA02305; Sun, 22 Sep 85 23:27:06 PDT Date: Mon, 23 Sep 85 02:26:27 EDT From: Communications Satellite Subject: Msg of Sunday, 22 September 1985 17:06-EDT To: "RMXJ%CORNELLA.BITNET@Berkeley.EDU"@BERKELEY Message-Id: <[MIT-MC.ARPA].654616.850923> FAILED: header-people-post at LBL.ARPA; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Received: from UCB-VAX.ARPA by MIT-MC.ARPA 22 Sep 85 17:06:45 EDT Received: by UCB-VAX.ARPA (5.22/5.9) id AA25424; Sun, 22 Sep 85 14:07:08 PDT Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA02857; Sun, 22 Sep 85 14:06:45 pdt Message-Id: <8509222106.AA02857@ucbjade.Berkeley.Edu> Date: 22 September 85 17:05 EDT From: RMXJ%CORNELLA.BITNET@Berkeley.EDU Subject: X.400/MHS implementation To: HEADER-PEOPLE@mit-mc.arpa To Jon Postel, Mark Crispin and other interested parties: At the EARN (European Academic Research Network) Technical Meeting in Geneve, Switzerland last Thursday and Friday, we discussed moving EARN (which connects to BITNET via two international lines paid for by IBM) to X.400. In fact, we *MUST* do so. The PTTs (Post Office, Telephone, and Telegraph) which own and operate *ALL* the lines in Western Europe have demanded that EARN migrate to an X.400 network in conformation with the ISO and CCITT recommendations. EARN has until the end of 1987 to accomplish this. Work has started to be progressed in this area. It was decided to use a product that is coming out of Heidelberg to accomplish this migration. EARN is almost in every country in Western Europe. By the end of the month, the final connections to the remaining countries will be complete. On Monday, Greece will connect from Crete to Italy, and Finland will connect from FINHUT (the Finnish Helsinki Institute of Technology) to Stockholm, Sweden and Belgium will connect up from Brussels to Paris, France. Anyone interested in communicating with the technical coordinators in EARN should write to me and I will put you in touch with them. There is one technical coordinator in each country as well as a European Master Coordinator (EMC). -- Gligor Tashkovich EARN Internetwork Consultant  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 24 Sep 85 23:34:34 EDT Received: by UCB-VAX.ARPA (5.25/5.9) id AA19940; Tue, 24 Sep 85 20:33:16 PDT Received: from ucbopal.Berkeley.Edu (ucbopal.ARPA) by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA19519; Tue, 24 Sep 85 20:32:37 pdt Received: by ucbopal.Berkeley.Edu (4.19/4.39.1) id AA09331; Tue, 24 Sep 85 20:32:45 pdt Date: Tue, 24 Sep 85 20:32:45 pdt From: wcwells%ucbopal.CC@Berkeley.EDU (William C. Wells) Message-Id: <8509250332.AA09331@ucbopal.Berkeley.Edu> To: Crispin@sumex-aim.arpa, Header-People@mit-mc.arpa Subject: Re: proposed Mail Transfer Protocol I agree that SMTP/RFC-822 needs to be updated. For example, current standards and supporting software do not provide for proper handling of Precedence and Classification (needed by MILNET and federal government Internet users). A multi-media envelope is a good idea. I suggest having a content indicator code in the envelope to identify the type of data being relayed (this is done on AUTODIN to differentiate between narrative, service, and data-pattern messages). Having such a code does not lock us into a particular message (or data) format, but also several types to be handled by the same envelope. Adding a language-media code to indicate how the message was sent and is intended to be received (eg. punched cards, magnetic tape, terminal, graphics device, etc.) would be a good idea. Within the Internet mail system, once the change over to full-domain names is completed, there should be no need to change internet addresses. The intent of domain addresses to have an address that is not changed as it is relayed within the Internet mail world. However, gatewaying to other mail systems remains a problem. What we need is better defined rules for gatewaying between Internet mail and other mail systems, and better compliance with the Internet standards by sites in the Internet mail world. I do not beleive DoD will be receptive to removing the RFC-822 mail header on a narrative message. The main problem I can see would be the loss of being able to handle multiple addressee messages if you only have one address list in the envelope where an address is modified or removed as it is relayed. The envelope (transmission instructions) are suppose to contain the relay instructions for addressees to which the message has not yet been delivered, while the message header (RFC 822) remains the same. Also, RFC-822 "Resent" fields need to be looked at. I would like to see a distinction made between readdressal (to external sites) and internal redistribution. Bill Wells, RMC, USNR-R wcwells@ucbopal.Berkeley.EDU  Received: from UCI-ICSE by MIT-MC.ARPA 25 Sep 85 15:51:10 EDT To: header-people@mit-mc cc: stef@uci-icse Subject: MIT-Multics Failed Mail handling, again ... Re: Unable to deliver mail from stef@uci-icse.arpa@wisc-rsch.arpa In-reply-to: 25 Sep 85 08:55:38 cdt <8509251355.AA16336@wisc-rsch.arpa> Date: 25 Sep 85 12:31:36 PDT (Wed) Message-ID: <227.496524696@uci-icse> From: Einar Stefferud Received: from Localhost by UCI-ICSE; 25 Sep 85 12:32:01 PDT (Wed) Please correct me if I am wrong, but I thought that MIT-Multics had corrected its bizarre behavior of returning failed mail "under separate cover" and then returning the failed items separately without any way to connect it with the failure notice. What do you all suppose we can (or should) do to induce MIT-Multics to conform to the rules, and become a good netmail citizen? Sorry if some are offended by revisiting this again in 1985. Cheers - Stef ----- Begin Offending Failure Notice Date: Wed, 25 Sep 85 08:55:38 cdt Message-Id: <8509251355.AA16336@wisc-rsch.arpa> Received: from MIT-MULTICS.ARPA by wisc-rsch.arpa; Wed, 25 Sep 85 08:55:42 cdt From: Network_Server.Daemon.at.MIT-MULTICS.ARPA@wisc-rsch.arpa Subject: Unable to deliver mail from stef@uci-icse.arpa@wisc-rsch.arpa Apparently-To: <@WISC-RSCH.ARPA:stef@uci-icse.arpa> Received: from Wisc-Rsch by UCI-ICSE; 25 Sep 85 06:57:02 PDT (Wed) Message will be returned under separate cover. To: Loveluck.CII-HB%HIS-PHOENIX-MULTICS at CISL-SERVICE-MULTICS.ARPA: The requested action was not performed. Insufficient access to return any information. Insufficient access to return any informa ----- End Offending Failure Notice  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 25 Sep 85 22:49:18 EDT Date: 25 Sep 1985 19:44:47 PDT From: POSTEL@USC-ISIB.ARPA Subject: MHS/X.400 <--> ARPA-mail To: header-people@MIT-MC.ARPA, arpa-mhs@BRL.ARPA, To: mmm-people@USC-ISIB.ARPA This is what i think should be going on with regard to developments for interoperation between MHS/X.400 and ARPA-mail, and where the various aspects should be discussed. The ARPA-mail system (821/822) is very wide spread and should be interconnected to the MHS/X.400 world by some simple and straight forward mail relays. The procedures in these relays should be simple. There will be some things that don't make it through the relays. For example, the 821/822 world is 7-bit ASCII text only, and if a MHS/X.400 message has some other type of data in it we should not go to heroic measures to encode it or translate it to text. There are some details about translating addresses and mapping headers to be worked out. I think the "arpa-mhs" mailing list is the right place to discuss these issues and work up a draft RFC on the specifics. To get on (or off) this list send a note to ARPA-MHS-REQUEST@BRL.ARPA. The MHS/X.400 system capability to carry other types of data (besides text) and its structured data types in general make in much more like the initial system developed for experiments in multimedia mail in the ARPA community. I feel that any discussion of how to support the features of MHS/X.400 that go beyond the current text mail system (821/822) should be focused into the multimedia community (with added interested people, of course). I think the right place for this discussion is the "mmm-people" list. To get on (or off) this list send a note to MMM-PEOPLE-REQUEST@USC-ISIB.ARPA. This means that in the short term and for the majority of users there will be a relay between MHS/X.400 and 821/822 mail. In the medium term and for relatively few users (now, but begining to grow) there will be a relay between MHS/X.400 and ARPA-multimedia mail (759/767). Of course, there will also have to be a relay (or other form of interoperation) between 821/822 mail and 759/767 mail. This leaves "header-people" as a place to discuss issues that are simply to do with 821/822. To get on (or off) this list send a note to HEADER-PEOPLE-REQUEST@MIT-MC.ARPA. I do not think it is useful to spend our time and energy in small additions to the 821/822 mail system. I think we should communicate the lessons learned in the 821/822 system, especially about the things we left out, to the MHS/X.400 people. I am one of those people that really dislike getting the same messages two or three times because it is sent to several mailing lists. My excuse for sending this one to several lists is that it is intended to sort out what is being discussed in which list. --jon. -------  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 11 Oct 85 01:23:57 EDT Received: by UCB-VAX.ARPA (5.28/5.11) id AA05922; Thu, 10 Oct 85 22:23:00 PDT Received: from ucbopal.Berkeley.Edu (ucbopal.ARPA) by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA04143; Thu, 10 Oct 85 22:22:06 pdt Received: by ucbopal.Berkeley.Edu (4.19/4.39.1) id AA09537; Thu, 10 Oct 85 22:22:14 pdt Date: Thu, 10 Oct 85 22:22:14 pdt From: wcwells@ucbopal.CC.Berkeley.EDU (William C. Wells) Message-Id: <8510110522.AA09537@ucbopal.Berkeley.Edu> To: Header-People@mit-mc.arpa Subject: nameservers do not know about domains Date: Thu, 10 Oct 85 17:58:50 pdt From: wcwells@ucbopal (William C. Wells) Message-Id: <8510110058.AA07761@ucbopal.Berkeley.Edu> To: ZELLICH@SRI-NIC.ARPA Subject: nameservers do not know about domains In reply to: From ZELLICH@SRI-NIC.ARPA Sat Oct 5 01:12:40 1985 Date: Sat 5 Oct 85 00:13:07-PDT From: Rich Zellich Subject: Re: List-of-lists distribution To: wcwells@BERKELEY Message-Id: <12148618239.12.ZELLICH@SRI-NIC.ARPA> Status: O Looks like I can't; SRI-NIC's mailer doesn't like most of your domain-style addresses, including ucbjade.Berkeley.EDU. Do you have a non-domain-style address for netinfo@...? -Rich ------- For Header-People: Ha. So much for a domain mailing system. What happen to the idea that the nameserver was suppose to check the next level up in the domain address "Berkeley.EDU" to find a nameserver for unknown lower domain levels, eg. if "local-address@unknown.BERKELEY.EDU" is not known, look for "BERKELEY.EDU" which should point to a nameserver on UCBVAX or UCBARPA. Do we have a software problem here? I also heard rumors that SRI was not allowing both a third level and second level domain name to be registered for a host. This would policy if true, distroys the concept of having distributed domain nameservers, since there is no pointer to a remote nameserver. Comments? For Rich: Try the old gateway format: netinfo%ucbjade@Berkeley.EDU for the List of Lists distribution. Bill Wells  Received: from A.CS.CMU.EDU by MIT-MC.ARPA 11 Oct 85 10:31:54 EDT Date: 11 Oct 85 10:29 EDT From: Rudy.Nedved@A.CS.CMU.EDU To: wcwells%ucbopal@UCB-VAX.ARPA (William C. Wells) Subject: Re: nameservers do not know about domains CC: Header-People@mit-mc.arpa In-Reply-To: <8510110522.AA09537@ucbopal.Berkeley.Edu> Message-Id: <11Oct85.102952.EN0C@A.CS.CMU.EDU> There seems to be some confusion. When I looked into the UCBJADE case and talked to the UCBJADE postmaster, I found out UCB was not interested in sending a huge list of sites to NIC. Therefore, the domain system knows about UCBJADE but the old host table does not. It also seems that some people don't understand how to deal with distributed name service...SRI-NIC domain server is NOT going to know about UCBjADE.BERKELEY.EDU...It does however know about BERKELEY.EDU and CMU.EDU and MIT.EDU and so on. Given my understanding of the situation, I am glad a good number of Berkeley hosts are not in the old host table. It motivates people to get their domain resolvers up (like me) and the rest to do some creative hacks like local additions to their host table which will one day blow up in their face. Effectively both MIT with their CHAOSNET problem and Berkeley with many hosts not listed in the table are aiding in the developement of the domain system. Now all that has to be done is get people of the belief system of trying to use a domain name as a routing address straigten out...[Some people around CMU thought, well the mail goes to the EDU mail relay which goes to the CMU mail relay which goes to the CS mail relay for addresses like ....CS.CMU.EDU...] Rudy Nedved CMU Postmaster  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 11 Oct 85 12:56:34 EDT Date: Fri 11 Oct 85 09:55:07-PDT From: Mark Crispin Subject: non-additions to host tables To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-ID: <12150297053.19.CRISPIN@SUMEX-AIM.ARPA> NO!!!!!!!!!!!!!!! Not all of the Internet has committed to using the domain system. In fact, officially the domain system is an EXPERIMENT, and the Milnet (and several other government stub networks) will NOT be adopting it until such time as the "experiment" proves itself. Hosts which are not in the NIC host table "to force losers to implement domains" will be sending INVALID message headers to the Milnet. -- Mark -- who is trying to maintain mail software on Milnet -------  Received: from ames.ARPA by MIT-MC.ARPA 11 Oct 85 21:29:33 EDT Received: by ames.ARPA (4.24/4.47) id AA00702; Fri, 11 Oct 85 18:28:59 pdt Date: Fri, 11 Oct 85 18:28:59 pdt From: Jordan Hayes Message-Id: <8510120128.AA00702@ames.ARPA> Organization: NASA Ames Research Center - Code EDN Office-Phone: (415) 694-7267 (FTS) 464-7267 Home-Phone: (415) 835-8767 To: header-people@mit-mc.ARPA From @MIT-MC.ARPA:CRISPIN@SUMEX-AIM.ARPA Fri Oct 11 16:04:26 1985 Subject: non-additions to host tables NO!!!!!!!!!!!!!!! Not all of the Internet has committed to using the domain system. In fact, officially the domain system is an EXPERIMENT, and the Milnet (and several other government stub networks) will NOT be adopting it until such time as the "experiment" proves itself. Hosts which are not in the NIC host table "to force losers to implement domains" will be sending INVALID message headers to the Milnet. -- Mark -- who is trying to maintain mail software on Milnet Oh Mark, take a valium already... For what it's worth, I too am maintaining mail at a site on the MILNET (luckily I have sendmail at my disposal ... too bad Mark is running stops-20 ... but that's a subject for discussion at parties ...) The way my table gets made up I still have to deal with domains, and I see no reason why the MILNET won't go for full domaining anyways, so you better get some experience with it now before the flood (and maybe learn something from people like Rich Wales). Since you get mail *IN* from the EDU sites (and whathaveu), ya gotta send it back, right? For instance, at Berkeley, traditionally UCB-VAX (now aka UCB-VAX.BERKELEY.EDU) has done *all* the tcp mailing, and munged the outgoing header to look like (for instance... your mileage may vary) jordan%ucbarpa@BERKELEY ... very gross. Especially since ucbarpa (my home machine) has been in the NIC tables for what seems like forever, and even has its own imp port. Anyways, they decided to do this because then it presented a uniform interface to any berkeley host (i.e., user%ucbhost@BERKELEY ...) and they didn't have to put all of our hosts in the table, and could in fact move them around at will with no fear of losing incoming mail. This was important enough, said they, to trash poor little (a 750) UCB-VAX. Well, that's all gotta go now, since these here domains are mandated for Berkeley (since we're not MILNET, we do what they tell us...) Now, my mail goes out saying "jordan@UCBARPA.BERKELEY.EDU" and it does its own mailing (fun stuff!) ... what will Mark (and the rest of the MILNET) do if I send him mail from my "hidden" accounts at Berkeley like MIRO.BERKELEY.EDU ...? I think the MILNET will go to domains as soon as people start figuring out that domained addresses are smarter than the table way, and suddenly their mailer is stupid. Making your mailer understand domains is a _good_thing(). Way to go, Rich !!! It's all about transitioning anyways. Besides... I hate those bloody NIC tables ... "you can pay me now or..." /jordan  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 11 Oct 85 22:20:41 EDT Date: Fri 11 Oct 85 19:19:13-PDT From: Mark Crispin To: jordan@AMES.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: <8510120128.AA00702@ames.ARPA> Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-ID: <12150399743.19.CRISPIN@SUMEX-AIM.ARPA> Jordan Hayes - Read the appropriate documents regarding the status of domains on the Milnet. Domains have *not* been officially adopted as a naming registry that the entire Internet must use. You can NOT go sending out headers with non-registered names to Milnet. I would appreciate not hearing your ignorant flaming on how wonderful domains are. I was a member of the committee that invented domains. Whether or not domains are wonderful is irrelevant; while some part of the network is stuck with the host table as a registration authority the maintainers of software on that network have to continue to support that environment. Your idiotic insults about software aren't worth answering. For the information of the Header-People community, I will announce that the TOPS-20 mail software has been "ready" for domains using the BBN/ISI GTHST/GTDOM interface for over a year now. -- Mark -- -------  Received: from UCB-VAX by MIT-MC.ARPA 12 Oct 85 09:52:16 EDT Received: by UCB-VAX (5.28/5.12) id AA09619; Sat, 12 Oct 85 06:50:55 PDT Received: by arpa (5.28/5.12) id AA12584; Sat, 12 Oct 85 06:50:51 PDT Date: Sat, 12 Oct 85 06:50:51 PDT From: fair@arpa.Berkeley.EDU (Erik E. Fair) Message-Id: <8510121350.AA12584@arpa> To: header-people@mit-mc.arpa Subject: hosts.txt & the new domain names I just saw Mark Crispin's quick flame in Header-People, and I applaud the sentiment, but thought the message needed to be expanded upon slightly. So I have extracted the relevant paragraph from the page break between pages 5 & 6 of RFC921, to wit: There are two communities that are taking slightly different courses in this transition. The DARPA research community is making the full transition. The DDN operational community is making the change in naming on the same schedule, but is not requiring hosts in the DDN operational community make the change to using servers at the same time (they can if they want to). The DDN PMO will establish a schedule for that change at a later time. The NIC will maintain a central table of all DDN operational hosts. This is restated a number of times throughout the document. The way I read this, the NIC really has to continue to maintain the entire host table until such time as the DDN PMO decrees conversion to domains for the MILNET also, in order for MILNET hosts to be able to reach hosts on the ARPANET. In turn, ARPANET hosts must continue to register their names with the NIC Hostmaster when they make changes, which includes the change to the new domain names. Further, I have a quick awk script that counts how many hosts are in each top level domain (according to the official name of the host, from hosts.txt), and here is the count from host table # 487 (10-Oct-85): arpa 1481 edu 317 com 33 uk 19 gov 11 org 8 To be fair, a number of hosts have their new domain name in as an alias, which indicates that they're in process of converting, and some of those `arpa' hosts are really MILNET sites, but this still ain't so hot, considering that the `arpa' domain was supposed to vanish on 15-Sep-85... glad I'm not a postmaster or liaison, Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 12 Oct 85 13:56:40 EDT Date: Sat 12 Oct 85 10:55:19-PDT From: Mark Crispin Subject: Re: Implementing Mail Domain Addresses and Nameservers To: header-people@MIT-MC.ARPA In-Reply-To: <8510120929.AA09637@ucbjade.Berkeley.Edu> Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-ID: <12150570156.19.CRISPIN@SUMEX-AIM.ARPA> Two suggestions: 1) avoid provoking the issue during a transition period; retain some set of names that are major mail agents and use those names. Address other problems as they come up, and otherwise make the software reliable enough that widespread adoption of domains can be done with confidence. Attempting to "force" production networks into using unproven software is a waste. 2) flush mailboxes such as netinfo@ucbjade.Berkeley.EDU which are completely ridiculous to mail to. A more reasonable address would be "Bill Wells"@Berkeley.EDU, which hopefully some reasonable mail user interface can arrive at by sending mail to "Bill Wells"@Berkeley. Of course, this means thinking about the semantics of mailboxes as something other than login user names. It also means fixing Unix to comprehend spaces in mailbox names, something that appears impossible to do (even though every other operating system has). -------  Received: from Xerox.ARPA by MIT-MC.ARPA 12 Oct 85 15:56:52 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 85 12:54:44 PDT Date: 12 Oct 85 12:54 PDT From: Lovstrand.pa@Xerox.ARPA Subject: Re: Implementing Mail Domain Addresses and Nameservers In-reply-to: Mark Crispin 's message of Sat, 12 Oct 85 10:55:19 PDT To: header-people@MIT-MC.ARPA Message-ID: <851012-125444-3469@Xerox> > 2) flush mailboxes such as netinfo@ucbjade.Berkeley.EDU which are > completely ridiculous to mail to. A more reasonable address would be > "Bill Wells"@Berkeley.EDU, which hopefully some reasonable mail user > interface can arrive at by sending mail to "Bill Wells"@Berkeley. Of > course, this means thinking about the semantics of mailboxes as > something other than login user names. It also means fixing Unix to > comprehend spaces in mailbox names, something that appears impossible > to do (even though every other operating system has). Although I definitely agree with Mark that RealName@Organization is better than RandomUser@SomeLocalHost.Organization, I don't like to rule out the possibility of sending explicitly addressed mail. IF there exist some local organizational space THEN you should be able to explicitly address some random recepient in that space. In the case of Berkeley, they happen to have a bunch of physical machines in their local space, so alright, why not be able to use that? When it comes to choosing between different formats for RealUser, I prefer Lennart.Lovstrand@LiUIDA.UUCP (which is my home address (yes, I *do* know that UUCP is not a "real" domain)) in favor of "Lennart Lovstrand"@LiUIDA.UUCP. I know that both are perfectly legal with respect to RFC822, but the former feels more in the flavor of the format ...and is perfectly simple to use with Unix/Sendmail. ;-) --Lennart (Postmaster@LiUIDA.UUCP when not at Xerox PARC) The previous statements are of my personal opinion and has no connection to those of Xerox Corp.  Received: from UCB-VAX by MIT-MC.ARPA 13 Oct 85 19:44:17 EDT Received: by UCB-VAX (5.28/5.12) id AA29463; Sun, 13 Oct 85 16:42:29 PDT Received: by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA04632; Sun, 13 Oct 85 16:42:19 pdt Date: Sun, 13 Oct 85 16:42:19 pdt From: netinfo@ucbjade.Berkeley.EDU (Postmaster + BITINFO) Message-Id: <8510132342.AA04632@ucbjade.Berkeley.Edu> To: Crispin@sumex-aim.arpa, header-people@mit-mc.arpa Subject: Re: Implementing Mail Domain Addresses and Nameservers Mark, First I would like to say that I am not flaming but trying to find solutions to a problem that affects all users of the Internet mail system. In reply to: From @MIT-MC.ARPA:CRISPIN@SUMEX-AIM.ARPA Sat Oct 12 11:11:36 1985 Date: Sat 12 Oct 85 10:55:19-PDT From: Mark Crispin Subject: Re: Implementing Mail Domain Addresses and Nameservers To: header-people@MIT-MC.ARPA In-Reply-To: <8510120929.AA09637@ucbjade.Berkeley.Edu> Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-Id: <12150570156.19.CRISPIN@SUMEX-AIM.ARPA> Two suggestions: 1) avoid provoking the issue during a transition period; Which issue? Are referring to the mail addressing problem created by the partial transition to full domain names? (I would prefer to recognize that we have a major network problem and try to find some solutions, rather than closing my eyes to problem and praying that it will go away.) retain some set of names that are major mail agents and use those names. Please explain in more detail. If there is a solution here, I am interested. Address other problems as they come up, Isn't that what I am doing? and otherwise make the software reliable enough that widespread adoption of domains can be done with confidence. I do not have control over any of the software being developped, but I hope the developpers are listening. Attempting to "force" production networks into using unproven software is a waste. Where did you get the idea that I was trying to do this? The local internet and the systems I use at Berkeley are production systems. (By the way I have the same reaction to some of the software that comes out of AT&T and Berkeley's CSRG group. It took one of our system programmers 6 months to debug BSD 4.2 Mail version 2.18 so that it would work in our local mail environment.) As a Naval Reserve communications specialist I am very concerned about anything that degrades service on the DDN. I made two suggestions that should not affect DDN. I am interested in hearing comments on these suggestions. Are they workable? (1) A source routing addressing kludge affecting the MAIL FROM and From: fields which defeats domain addressing between local domains (and between the DARPA research community sites and DDN sites), but permits full domain names within the local mail domain and does not require all local hosts to be registered in the master host table, for example: From: Bill Wells <@Berkeley.EDU:wcwells@ucbopal.Berkeley.EDU> (2) Establishing Mail Transport Agents (Mail Gateways) on the DARPA/DDN "mail bridges" to handle the differences in mail addressing between the two parts of the Internet mail system. That is, instead of the Berkeley mail transport agent adding the source routing, the mail bridge gateways would add the source routing. This would allow the DARPA research community part of the Internet mail system to use nameservers without affecting the DDN. 2) flush mailboxes such as netinfo@ucbjade.Berkeley.EDU which are completely ridiculous to mail to. A more reasonable address would be "Bill Wells"@Berkeley.EDU, which hopefully some reasonable mail user interface can arrive at by sending mail to "Bill Wells"@Berkeley. Of course, this means thinking about the semantics of mailboxes as something other than login user names. Well dreams are nice. But the reality is that even the US Postal Service needs a post office box or street address. This suggestion ignores the fact that there might be more than one "Bill Wells" at Berkeley. (There were two in the dorms at my undergraduate university, and five at the Naval Training Center when I went through boot camp -- That is the reason why service numbers are reguired in mail to members of the Armed Forces). I think RFC 822 had the right idea when they left the proper name out of the address used for transmission of the message. It also means fixing Unix to comprehend spaces in mailbox names, something that appears impossible to do (even though every other operating system has). Why should an operating system be changed to conform to the needs of a single application? I believe mail software here handles quoted strings, however I do not have a way of getting all the vendors that distribute the various versions of Unix to update their software to solve the problem at the mail transport level. The the user agent interface level, the problem is one of user documentation and education. By the way, if you want to flame about the features (good or bad) of Unix, I can recommend the Info-Unix mailing list as a good place to do that. Can we keep this discussion to the problems and solutions for implimenting the full domain addresses in the DARPA research community while not implimenting them in the Defense Data Network? Bill Wells, RMC, USNR postmaster%ucbjade@Berkley.EDU postmaster@ucbjade.Berkley.EDU BITINFO@UCBJADE.BITNET PS. For Rudy, you must have talked to the postmaster at UCBVAX or our network manager, I am the postmaster at UCBJADE.  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 14 Oct 85 14:37:11 EDT Date: Mon 14 Oct 85 11:35:42-PDT From: Mark Crispin Subject: mail domain addresses To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-ID: <12151101794.48.CRISPIN@SUMEX-AIM.ARPA> Bill Wells - I can't reply to your message because Stanford doesn't have a resolver up yet (promised Real Soon Now) and UCBJADE.BERKELEY.EDU isn't in the NIC host table. I suspect that Stanford is at fault for not having a resolver running yet. This ISN'T my problem; I only do the mailsystem and domain solving is external to the mailsystem. The mailsystem has been ready for a domain solver for months. On DDN networks, it isn't anybody's problem; they aren't required to do anything about domains. My initial flame was in reaction to a comment which had the attitude "if you can't reply to mail it is a good thing and it will make you work harder." Bullsh-t. It is not a good thing that users who have nothing to do with the domain solver software (a category I happily place myself even though I hack mailers) can't reply to mail. Basically, I am saying that since UCBJADE.BERKELEY.EDU seems to be sending lots of messages, it should be in the NIC host table. If there is a space problem, domains can eliminate a lot of the random IBM PC's, etc. that are listed there. -- Mark -- -------  Received: from lll-tis-b.ARPA by MIT-MC.ARPA 14 Oct 85 19:48:50 EDT Return-Path: Received: by lll-tis-b.ARPA; Mon, 14 Oct 85 16:47:13 pdt Date: Mon, 14 Oct 85 16:47:13 pdt From: Michael C. Berch Message-Id: <8510142347.AA05241@lll-tis-b.ARPA> To: header-people@mit-mc.ARPA Subject: Re: Implementing Mail Domain Addresses and Nameservers Summary: Leave the local-parts alone. Newsgroups: local.header-people In-Reply-To: <14098@styx.UUCP> Organization: Lawrence Livermore Laboratory, Livermore CA Cc: > From: Mark Crispin > . . . > 1) avoid provoking the issue during a transition period . . . > > 2) flush mailboxes such as netinfo@ucbjade.Berkeley.EDU which are > completely ridiculous to mail to. A more reasonable address would be > "Bill Wells"@Berkeley.EDU, which hopefully some reasonable mail user > interface can arrive at by sending mail to "Bill Wells"@Berkeley. Of > course, this means thinking about the semantics of mailboxes as > something other than login user names. It also means fixing Unix to > comprehend spaces in mailbox names, something that appears impossible > to do (even though every other operating system has). I'd also avoid provoking the issue of mailbox names (local-parts) during a transition period. Notwithstanding the differences between the right-hand-parts of the two examples given, why is it necessary to deal with the local-part at this point? What is the matter with a symbolic mailbox name? I agree that UNIX mailers should be able to reliably deal with spaces in local-parts, but what does this have to do with doing away with symbolic mailbox names, such as those interpreted by sendmail? We use dozens of them for mailing lists and so forth. As in the netinfo example, they might also be useful for shared "official" accounts. What's the problem? I'd rather send mail to "netinfo" and have it answered, than sent to "Bill Wells" and find out he's on vacation. Michael C. Berch mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb  Received: from sri-spam.arpa by MIT-MC.ARPA 14 Oct 85 20:25:14 EDT Received: by sri-spam.arpa (5.4/4.16) id AA12396; Mon, 14 Oct 85 17:22:50 PDT Date: Mon, 14 Oct 85 17:22:50 PDT From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8510150022.AA12396@sri-spam.arpa> To: header-people@mc  Received: from sri-spam.arpa by MIT-MC.ARPA 14 Oct 85 21:04:56 EDT Received: by sri-spam.arpa (5.4/4.16) id AA12553; Mon, 14 Oct 85 17:44:40 PDT Date: Mon, 14 Oct 85 17:44:40 PDT From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8510150044.AA12553@sri-spam.arpa> To: header-people@mc Subject: name servers (involves VRFY command) Sorry that I let that one get out by mistake. Anyway, this is a suggestion for anyone who is implementing a name service that runs in conjunction with SMTP, such as the pathalias uucp-path server on harvard. I propose that when handed foreign addresses, it queries the server *before* attempting the delivery. For example, I have handed to the SMTP server at harvard addresses of the form: VRFY houxm!gregbo and gotten a 250 response. When the attempt to actually deliver the mail is made, however, I have received lines of the form: bad system name: houxm uux failed: code 68 which leads me to believe that the name server is not operating. What I would like to see is some interaction with the name server before an OK response is made, so that in case a server is down, a message such as: 550 Requested action not taken: Name service unavailable or at least a 251 User not local; trying houxm!gregbo so when the RCPT TO: command is sent the name server will have already failed, and can return with the 550 command. This is not intended to be specific to Unix (although this problem may very well be) but generalizable to all name service (for example, bitnet may wish to provide a service at wiscvm). Comments are welcome. Criticisms of Unix are not, let's please keep to the subject. --gregbo  Received: from UCB-VAX by MIT-MC.ARPA 12 Oct 85 05:31:49 EDT Received: by UCB-VAX (5.28/5.12) id AA06877; Sat, 12 Oct 85 02:30:31 PDT Received: by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA09637; Sat, 12 Oct 85 02:29:46 pdt Date: Sat, 12 Oct 85 02:29:46 pdt From: netinfo@ucbjade.Berkeley.EDU (Postmaster + BITINFO) Message-Id: <8510120929.AA09637@ucbjade.Berkeley.Edu> To: Crispin@sumex-aim.arpa, jordan@ames.arpa Subject: Implementing Mail Domain Addresses and Nameservers Cc: header-people@mit-mc.arpa Would MAIL FROM:<@Berkeley.EDU:unknownhost.Berkeley.EDU> be an acceptable short term solution for mail sent from UC Berkeley? ----- Now, in reply to: Date: Fri 11 Oct 85 19:19:13-PDT From: Mark Crispin Cc: header-people@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-Id: <12150399743.19.CRISPIN@SUMEX-AIM.ARPA> Rather than flaming about flaming, lets come up with some solutions. A centrally maintained host table is soon going to become to big to manage effectively. (At Berkeley we expect to have over 3000 "hosts" in the next couple of years.) So the Internet world is moving towards distributed nameservers. General working policy is that the experimental side of the Internet (the ARPANET backbone and friends) develops and debugs the system before it is adopted by the operational side of the Internet (the Milnet backbone and friends). This is the assumption of RFC 921 which planned for completion of the Domain Naming System by 15 July 1985 and decommissioning of the host tables for the DARPA research community (non-DDN) on 15 September 1985. Up to 15 Sep 85 we could have software that assumed the Internet mail system was one mail system. That is no longer true. Read the appropriate documents regarding the status of domains on the Milnet. I would not assume that the DARPA research community gets all the documents about the DDN. (Which documents by the way? DDN newsletter?) Domains have *not* been officially adopted as a naming registry that the entire Internet must use. I am not sure what you are trying to say here. Domain "host" names are being put in both the host table and nameservers for use by the entire Internet. So I must assume you are saying that domain nameservers are not currently operational on the DDN and implementation may, or may not be scheduled for the DDN. You can NOT go sending out headers with non-registered names to Milnet. Here is where we have a problem. First, lets change Milnet to all DDN operational nets and ask how a non-DDN site determines if a host is a DDN host. What about hosts that are on both a DDN net and on a DARPA research community net, how do you determine which type of address to send. The world is not simple anymore. Add another complication, with the implementation of domain name servers the Internet mail system now extends beyond the physical Internet. Second, according to RFC 921 on 15 Sep 85 "the master host table maintained by the NIC need no longer be complete for the DARPA research community. A full table of the DDN hosts will be maintained by the NIC." To me, that means that DARPA research community sites only need to register names of mail domains and their nameservers. Now if NIC deletes all non-DDN hosts from the host table used by a DDN host, how is that host going to know if the return mail domain is registered or not? Somewhere along the line, I think the Internet mail developers forgot to deal with this issue. ... while some part of the network is stuck with the host table as a registration authority the maintainers of software on that network have to continue to support that environment. True, within that part of the network, but not necessarily for the rest of the Internet. What if we follow the original plan and have two logical Internet mail systems, one using host tables and one using nameservers? Is the source routing kludge <@known-nameserver-domain-host:localmailbox@unknowndomain> sufficent, or do we implement Mail Transport Agents on "mail-bridge gateway" hosts that know about both sides of the Internet mail world? Bill Wells postmaster%ucbjade@Berkeley.EDU BITINFO@UCBJADE.BITNET <@Berkeley.EDU:postmaster@ucbjade.Berkeley.EDU> ??  Received: from LOCUS.UCLA.EDU by MIT-MC.ARPA 14 Oct 85 22:55:42 EDT Date: Mon, 14 Oct 85 17:54:21 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Re: Domain names in the NIC table References: Message of Thu, 10 Oct 85 22:22:14 pdt from "wcwells@ucbopal.CC.Berkeley.EDU (William C. Wells)" <8510110522.AA09537@ucbopal.Berkeley.Edu> Message of 11 Oct 85 10:29 EDT from "Rudy.Nedved@A.CS.CMU.EDU" <11Oct85.102952.EN0C@A.CS.CMU.EDU> Message of Fri, 11 Oct 85 18:28:59 pdt from "Jordan Hayes " <8510120128.AA00702@ames.ARPA> Message-ID: <498185661-12673-wales@DIANA.LOCUS.UCLA.EDU> In connection with the recent discussion on whether or not all the new domain-style host names should be in the NIC table, my name was invoked in such a way as to suggest that I supported a position which in fact I oppose. I am certain this was simply an innocent misunderstanding. In any case, let me set the record straight. (1) I believe that EVERY host name which is used in a mailing address should appear in BOTH the domain data base AND the NIC host name table. Any host which doesn't have its name in both places is inev- itably going to encounter problems getting mail from some portion of the net. When I posted my celebrated host-name study (and the accompanying set of messages to individual errant hosts) last month, by the way, among the kinds of hosts I flagged were those using domain-style names that didn't appear in the NIC table. I do NOT support the idea that hosts should be kept out of the NIC host name table in order to put pressure on hosts which haven't yet converted their software. (a) Just because a given host is still using the NIC table does not necessarily mean that its administrators are lazy, apathetic, or incompetent. (b) In the case of the MILNET, for instance, it has been correctly pointed out that MILNET hosts are not required to convert (or is it, "are required not to convert"?) to the domain system for some time yet. (c) And in any case, whenever we try to exert pressure in this way, the real losers in the end are the end users who are unable to get their mail through. (2) If an organization has a second-level domain, I believe that they should be allowed to assign that second-level name to one of their hosts (so that it can act as a mail gateway for the organization) and have that name listed in the NIC table in addition to the host's regular third- or lower-level name. I am aware of at least one organization whose mail guru told me that the NIC had refused to list both "xxx.COM" and "yyy.xxx.COM" (for the appropriate values of "xxx" and "yyy") as host names for its mail gateway machine. Perhaps this request was refused for some other, unrelated reason. If, however, it is in fact the NIC policy to turn down such requests on princple, I believe this policy should either be defended publicly and cogently, or else discarded. Actually, I suspect this policy is no longer being enforced by the NIC (if indeed it ever was) -- since a quick scan of the newest host name table shows several instances of second- and third-level names for the same host -- including at least one recent addition. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales  Received: from A.CS.CMU.EDU by MIT-MC.ARPA 12 Oct 85 17:01:11 EDT Date: 12 Oct 85 16:57 EDT From: Rudy.Nedved@A.CS.CMU.EDU To: header-people@MIT-MC.ARPA Subject: domains Message-Id: <12Oct85.165734.EN0C@A.CS.CMU.EDU> First off, the domain system is a step in the right direction as compared to the centralized host table mechanism. Just like in the telephone system, you call the area code you are interested in, specify the city and then query about a name for a telephone number. It would be unmanageable and extremely slow to have a centralized telephone directory. Second, the point about domains is an experiment is misleading. The subtle issue here is that the research side of the ARPA Internet known as ARPANET has somewhat formally adopted domains. This is almost a given. Life does not contain absolutes so people can say otherwise. The production side of the ARPA Internet known as MILNET has formally indicated in one of the implementation notes a "wait and see" with no commitment. In other words, while the ARPANET is fighting over domains...they can continuing doing work....which is a good for a production enviroment...they can not fight with the problems...they have other problems. Third, the hosts in the domain system but not in the old host table are not incorrect or illegal as far as any specification is concerned. The real question is one of practicality. If a non-domain system host MUST talk to a host not listed in the domain system, then the postmasters involved or liaisons should communicate and find a solution. If these types of comprimises don't exist then the ARPANET can not experiment and the MILNET can not get work done. Given I live and maintain a very large and rapidly expanding computer system enviroment, I have to deal with both of these issues every day. At the moment, CS is experimenting and developing solutions to problems and creating reliable software. If other departments want to add people or systems to our experiements...great. When we feel things are at a production level then we expand man power and other resources to get the system installed all over. This seems to be the same thing the ARPA Internet is doing in a larger scale... -Rudy  Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA 13 Oct 85 20:40:17 EDT Date: Sun 13 Oct 85 17:38:53-PDT From: David Roode Subject: Host names To: Hostmaster@SRI-NIC.ARPA cc: Header-People@MIT-MC.ARPA Message-ID: <12150905765.58.ROODE@SUMEX-AIM.ARPA> People are observing that many host names (specifically those at Berkeley) are not included in the central host table which you still maintain for MILNET. Some people thought MILNET sites should all be running name resolvers so this was not a problem, but the consensus seems to be that the policy is that MILNET sites are not required to do this. Are they even allowed to do this? Erik Fair forwarded a statement of policy to Header People. It states that the NIC will continue to maintain a host table for MILNET. Is there any policy statement which explains how this will happen? Are hosts changing from their .ARPA domain name required to notify Hostmaster@NIC of the new name as well as registering with the particular domain or domains of which they will be a part? Whose "fault" is it that certain Berkeley sites are not in the host table, but are nonetheless transmitting mail to certain MILNET sites who then cannot conveniently deal with the mail? Perhaps people at Berkeley thought they could simply elect not to be a part of the NIC host table, but where does this leave MILNET? -------  Received: from hydra.ARPA by MIT-MC.ARPA 15 Oct 85 17:43:25 EDT From: Barry Leiner Message-Id: <8510152141.AA04790@hydra.ARPA> Received: by hydra.ARPA (4.12/4.01) Tue, 15 Oct 85 14:41:54 pdt Date: 15 Oct 1985 1441-PDT (Tuesday) To: header-people@mit-mc.ARPA Subject: domain questions Folks, After watching the discussion recently on domains, it is apparent that there are some misconceptions and confusion about the current and planned state of affairs with respect to domains, milnet, etc. As the situation is fairly simple to understand, let me try to state it clearly. 1. There are two separable issues: domain names and domain servers. 2. The issue of domain names has to do with recognizing and being able to deal with names in the domain name format, i.e. ...@host.D1.D2.D3 where Dx are domains and subdomains. a. The current policy is that ALL hosts on the internet MUST be able to deal with such names. That is, they must have a way of recognizing such names and converting such names to internet addresses. b. There are two ways of doing this. The first and "current" (as of last year) is to simply have host names in that format be the entries in the host.txt table. The second method is to use the domain server approach (see below). 3. The issue of domain servers has to do with the method for conversion of names to addresses. a. The "official" position is that the milnet/DDN side of the world will be supported by the NIC generating a HOST.TXT file that contains all such names (or at least as many as they are prepared to deal with at any time) and providing this table to the milnet/DDN hosts. (This allows such hosts to continue to operate with minimal (non-zero) change. The hosts that are not supported otherwise by the name server system will be considered by the name server system to all be in a single top level domain with server at the NIC. The name of this domain is TBD, but will probably evolve from .ARPA to something like .DDN . b. The "research" side of the world (roughly those hosts on the ARpanet side of the mail bridges, rather than the milnet side), are expected to use the domain servers to convert host names to internet addresses. c. Hosts on the milnet side of the world are allowed to use domain servers and be part of a domain, and in fact are encouraged to do so, as that is the only way they can expect to reach all internet hosts. Bottom line: ALL HOSTS MUST DEAL WITH DOMAIN STYLE NAMES IF YOU WANT TO BE ABLE TO DEAL WITH ALL HOSTS, YOU MUST USE NAME SERVER SYSTEM. Hope this helps. Barry ----------  Received: from UCB-VAX by MIT-MC.ARPA 17 Oct 85 00:22:01 EDT Received: by UCB-VAX (5.28/5.13) id AA06477; Wed, 16 Oct 85 21:23:25 PDT Received: by ucbjade.Berkeley.Edu (4.19/4.39.1) id AA16956; Wed, 16 Oct 85 21:11:54 pdt Date: Wed, 16 Oct 85 21:11:54 pdt From: netinfo@jade (Postmaster + BITINFO) Message-Id: <8510170411.AA16956@ucbjade.Berkeley.Edu> To: Header-People@mit-mc.arpa, wales@locus.ucla.edu Subject: Re: Domain names in the NIC table In reply to: Date: Mon, 14 Oct 85 17:54:21 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: Re: Domain names in the NIC table ... (1) I believe that EVERY host name which is used in a mailing address should appear in BOTH the domain data base AND the NIC host name table. Any host which doesn't have its name in both places is inev- itably going to encounter problems getting mail from some portion of the net. ... At Berkeley we have run into the problem of not all hosts being on a packet (eg. TCP/IP) net. In addition to hosts on our local ethernets, we support mail service to hosts that are only on our BERKNET, BITNET, or linked by dialup UUCP connections. These hosts are in the Berkeley.EDU mail domain, but we cannot register them in the NIC host table because they do not have Internet network addresses, nor can they support SMTP. However, they can be supported by a mail domain nameserver. Prehaps we need a separate nameserver for mail domains, or away of indicating a domain name is not on the physical internet? Bill Wells  Received: from UCB-VAX by MIT-MC.ARPA 17 Oct 85 05:35:48 EDT Received: by UCB-VAX (5.28/5.13) id AA11303; Thu, 17 Oct 85 02:37:39 PDT Received: by ucbarpa (5.28/5.12) id AA04823; Thu, 17 Oct 85 02:37:34 PDT Date: Thu, 17 Oct 85 02:37:34 PDT From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) Message-Id: <8510170937.AA04823@ucbarpa> To: header-people@mit-mc.arpa Subject: what berkeley has been doing As I understand it (since I don't make or execute policy around here) in order to relieve the NIC of having to register all the hosts at Berkeley, Berkeley has registered only 26 of the ~300 hosts that are on the class B network here (I might add that there are several subnets as well). This is also an inter-organizational issue, since we have a research community and a computer center. The research community has the IMP, and all of the registered hosts. The computer center has chosen not to register at all (Mr. Wells works for the Computer Center). In order that mail can get in and out of here reliably from all hosts, all of the hosts have been set up so that they forward outgoing internet mail to one central host (UCB-VAX.ARPA), which is registered, and which (until recently [grrr]) changed the outgoing address from user@ucbhost to user%ucbhost@ucb-vax.arpa. If an outside organization wished to telnet or FTP to/from one of the unregistered hosts, it was expected that they would either add the unregistered hosts to their host table, or use the appropriate internet address number. My view, (and I shall reiterate it) is that all ARPANET hosts should continue to have their current name(s) registered with the NIC Hostmaster, regardless of whether they are currently using a domain resolver or not, because interoperation with the MILNET is important, and when you send unregistered names over there, they will not be able to get back. While the MILNET hosts have been ENCOURAGED to use domain resolvers, they are specifically not REQUIRED to do so until DDN-PMO specifies a conversion schedule, and it is a mistake to attempt to force it on them since they can legitimately refuse to do so. still glad I'm not a postmaster or liaison, Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU  Received: from CSNET-SH.ARPA by MIT-MC.ARPA 17 Oct 85 10:34:47 EDT To: Postmaster + BITINFO cc: Header-People@mit-mc.ARPA, wales@locus.ucla.edu, cic@CSNET-SH.ARPA Subject: Re: Domain names in the NIC table In-reply-to: Message from Postmaster + BITINFO <8510170411.AA16956@ucbjade.Berkeley.Edu> Date: 17 Oct 85 10:25:29 EDT (Thu) From: Dennis Rockwell From: Postmaster + BITINFO Date: Wed, 16 Oct 85 21:11:54 pdt Subject: Re: Domain names in the NIC table [ ... ] Prehaps we need a separate nameserver for mail domains, or away of indicating a domain name is not on the physical internet? Bill Wells There already is: the domain servers for those hosts should set up MF records pointing to the relay host that is on the Internet. CSNET plans to use this mechanism to support our hosts on PhoneNet (with the MF pointing to RELAY.CS.NET aka CSNET-RELAY.ARPA). Thus, people using resolvers can send mail to, for instance, JoeStudent@Foo-U.EDU, and their mailer should ship the message off to CSNET-RELAY. This implies that everybody who is rewriting their mailers to use a resolver should cause them to ask for type=MAILA records *first*, then type=A records. This way we can give the appearance of connectivity for mail hosts not directly on the Internet. Of course, this can used for UUCP, BITNET, MAILNET and whoever else wants to do this. Berkeley can put in an MF record for, say ERNIE.BERKELEY.EDU, which points to BERKELEY.EDU, or whatever. We (BBN) are considering using this mechanism to keep people from trying to send mail to TACs (yes, it happens). Our local TACs would have MF records pointing to BBN-UNIX (aka UNIX.BBN.COM), but PTR and A records giving their IP address, so that telnet servers can discover the name of the source of new connections. Let me repeat, because it's *important*: mailers should look for MAIL records first, address records second. Dennis Rockwell CSNET Technical Staff  Received: from SRI-NIC.ARPA by MIT-MC.ARPA 22 Oct 85 20:50:28 EDT Date: Tue 22 Oct 85 17:53:08-PDT From: Ken Harrenstien Subject: Registering subdomain hosts To: namedroppers@SRI-NIC.ARPA, header-people@MIT-MC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12153267656.21.KLH@SRI-NIC.ARPA> On the subject of registering host names (domain style names) with the NIC: Please do so, for the time being. As several people have pointed out, the MILNET is not required to make use of domain name servers. If you wish a MILNET host to talk with you, you must register your host with the NIC (send a message to HOSTMASTER@SRI-NIC.ARPA). However, this does not necessarily mean that you have to wait for an indefinite MILNET transition date before you can stop sending your hostname changes to the NIC. Since the NIC is responsible for bridging the gap between the current MILNET "flat" host table and the still-evolving ARPANET domain name system, we have been working on a survey program which will periodically query the servers for all known domains in order to build a near-complete host table. This "snapshot" can then be used in the usual way by any systems which rely on the simple table lookup method. Currently there are some problems which are preventing this strategy from working, and which need to be resolved by people outside of the NIC. Here is a partial list from Mark Lottor (MKL@SRI-NIC.ARPA); please contact him if you are in a position to help. ------------ - Some domains do not support or answer zone transfer requests; e.g. CMU has 3 servers but none do zone transfers. - Some domain servers do not send back host-info (CPU and OS types) for zone transfers. - Most domain servers do not send back WKS records (protocol lists) for zone transfers. ------------------ Note that the domain name system does not now support any consistent way of obtaining information about networks or network names. (These are represented by NET entries in the host table, which the NIC will continue to maintain as a global network number registry.) But since NET information can be useful when trying to figure out where an unknown internet connection is coming from, it seems as if there should be a better way of finding this than by either searching HOSTS.TXT or putting together a fake IN-ADDR "domain name". Who does one ask about the latter? The NIC? But isn't the NIC eventually supposed to NOT know about all Internet addresses? I have a feeling our survey program will be around for a long time... -------  Received: from SRI-NIC.ARPA by MIT-MC.ARPA 22 Oct 85 21:03:02 EDT Date: Tue 22 Oct 85 17:55:21-PDT From: Ken Harrenstien Subject: NIC nickname policy To: namedroppers@SRI-NIC.ARPA, header-people@MIT-MC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12153268060.21.KLH@SRI-NIC.ARPA> Several people have expressed confusion about the NIC's policy for registering host nicknames, and have somehow been led to believe that the NIC has something against second or third-level domain names. This message is an attempt to clarify our position and explain where the issue started. As far as the NIC host table is concerned, there is no distinction between a domain style name and and "old" host name; they are both just names. The level, or number of domains in a name, is completely irrelevant. The first name in a host entry is the official name which must be used in any external references to that host. All other names are considered "nicknames". In order to reduce the size of the host table, we strongly discourage nicknames. In general, the only valid reason for a nickname to exist is the fact that the nickname once was, or may become, the official name for that host. When official names change, some period of overlapping existence is needed to allow time for the change to propagate to all hosts; not every site updates their copy of the host table every night. Thus, a more accurate term for NIC "nicknames" would be "alternate names", since these are only intended to keep things working, rather than to allow everyone to use their favorite hosts on a first-name basis. Nicknames intended for the latter purpose are best handled locally. There are still many old, short "first-name" nicknames which remain for various historical reasons. The advent of the domain name system, with the mandatory change-over to domain-style names, is a great opportunity to start getting rid of them. Meanwhile, we try to make sure that any new entries have no nicknames whenever possible. One of the philosophical goals we were aiming for while working out the structure of the domain name system was to end up with only ONE name for any particular host, even though this site might exist on different networks. By using neutral top-level domains of COM, EDU, and the like, we hoped to avoid a multiplicity of names resulting from political claim staking (MC.MIT.ARPA = MC.MIT.CHAOS = MC.MIT.CSNET = MC.MIT.DOE = etc etc) and to encourage the selection of just one name which could then be used by all (or most) organizations and networks using a particular host. This is the underlying basis for the "no domain nicknames" policy; it is not a technical problem, but rather a philosophy which we think will make life easier in the long run (and having maintained these lists for years, we do speak from experience). What is now causing confusion is the fact that many people have used the NIC host table as a way of vectoring their mail to different places at different times, by shuffling nicknames around. This is not really how the table was meant to be used, and the creation of MF type records in the domain name system is a reflection of the fact that mail addressing is not the same as TELNET or FTP host addressing. In the particular case that started all this, Bruce Nemnich wanted to register GODOT.THINK.COM as an official name, with THINK.COM as a nickname. The intent here was to have every machine in the THINK.COM domain fake up their return-path and sender-address to xyz@THINK.COM which would then relay responses to the appropriate place. Now, there is no inherent technical problem with simply sticking those names in our database. However, this request was initially rejected, on the basis of our simple "no domain nickname" guideline, by the staff members who serve as HOSTMASTER. When later they anxiously asked me for confirmation, I allowed as how "we could do it-- but it would be wrong." Remember, mailers are still required to use official host names in anything which goes out. Supposing that we carried out the THINK.COM request, the THINK.COM hosts would be violating the requirement by using the "THINK.COM" nickname as part of the return address in their outgoing mail. If they did this anyway, then any host which DOES follow the rules when responding to these messages will generate headers addressed NOT to THINK.COM, but to GODOT.THINK.COM. And, of course, anyone responding to the secondary headers will never have seen any THINK.COM addresses! The solution that was adopted was simply to make THINK.COM the official name for one of their hosts. No nicknames. Note that as long as mail addresses are the equivalent of host addresses, the domain name system will still need to remember "old" names, so that the stuff in your mail files remains useful for a reasonable time after some host has changed its name. If people would like to discuss this further, I suggest using the HEADER-PEOPLE mailing list, as the problem is slightly more related to mail than to the workings of domain name servers. But since I used NAMEDROPPERS too for this message, I'll understand if others go through the same vacillation and settle on both... -------  Received: from SIMTEL20.ARPA by MIT-MC.ARPA 28 Oct 85 10:55:23 EST Date: Mon 28 Oct 85 08:54:59-MST From: Mark Crispin Subject: mail from Berkeley hosts To: Header-People@MIT-MC.ARPA, Postmaster@UCBVAX.BERKELEY.EDU Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12154742554.17.MRC@SIMTEL20.ARPA> Would somebody PLEASE fix the Berkeley mail software to generate message headers that Milnet sites can reply to? Milnet is not adopting domains at the present time; either those sites should be added to the NIC host table or they should use "%" or some similar kludge. I am tired of not being able to reply to urgent correspondence. It is NOT alright to shut off mail access to non-domain sites! -------  Received: from ucbvax by MIT-MC.ARPA 29 Oct 85 01:36:04 EST Received: by ucbvax (5.31/1.2) id AA08101; Mon, 28 Oct 85 16:00:45 PST Received: by ucbjade.Berkeley.Edu (4.19/4.40) id AA28981; Mon, 28 Oct 85 15:52:53 pst Date: Mon, 28 Oct 85 15:52:53 pst From: netinfo@jade.berkeley.edu (Postmaster + BITINFO) Message-Id: <8510282352.AA28981@ucbjade.Berkeley.Edu> To: Header-People@mit-mc.arpa, MRC@simtel20.arpa, Postmaster@ucbvax Subject: Mail to UC Berkeley hosts MILNET sites not using nameservers to resolve mail domain names may send to UC Berkeley hosts by using one of the following: user%host@ucbvax.Berkeley.EDU user%host@Berkeley.EDU user%host@Berkeley.ARPA Provided "host" is a local UC Berkeley host. There are a few UUCP sites at Berkeley that cannot be reached by the above address, but which may be addressed by: uhost!user@ucbvax.Berkeley.EDU or uhost1!uhost2!ucbvax.Berkeley.EDU The domain part of the address is from the Interhost table entry: 10.2.0.78 ucbvax.berkeley.edu ucb-vax.arpa ucb-vax berkeley berkeley.arpa ucbvax berkeley.edu ucb-vax.berkeley.edu 128.32.0.10 ucbvax.berkeley.edu ucb-vax.arpa ucb-vax berkeley berkeley.arpa ucbvax berkeley.edu ucb-vax.berkeley.edu Bill Wells postmaster@ucbjade.Berkeley.EDU postmaster%ucbjade@Berkeley.EDU postmaster%ucbjade@ucbvax.Berkeley.EDU ucbjade!postmaster@ucbvax.Berkley.EDU ucbvax!ucbjade!postmaster BITINFO@UCBJADE.BITNET  Received: from SRI-CSL.ARPA by MIT-MC.ARPA 29 Oct 85 02:17:54 EST Date: 28 Oct 1985 23:17-PST Sender: GEOFF@SRI-CSL.ARPA Subject: Re: Mail to UC Berkeley hosts From: the tty of Geoffrey S. Goodfellow Cc: Header-People@MIT-MC.ARPA, MRC@SIMTEL20.ARPA Cc: Postmaster@UCBVAX.BERKELEY.EDU Message-ID: <[SRI-CSL.ARPA]28-Oct-85 23:17:44.GEOFF> In-Reply-To: <8510282352.AA28981@ucbjade.Berkeley.Edu> netinfo@jade.berkeley.edu, that's dumb thinking. do you honestly expect every single user on the Internet to know about your local routing hacks thru user%host@ucbvax.Berkeley.EDU or ...@Berkeley.EDU or ...Berkeley.ARPA?? Really!? heck, i couldn't even reply to your message because your ...@jade.berkeley.edu host isn't registered in the NIC. Foo! what do you think someone like Bob Kahn or some other money bags source on a MILNET host is going to do when he can't reply to messages originated by hosts like yours at UCB which isn't registed in the NIC's host tables (and doesn't know about your special address "hack")?? Damn it, why don't you just register your hosts with the NIC and make it easy for yourself, your correspondents and the rest of the net?? i seem to be gaining increased appreciation every day for SMTP servers on hosts which *reject* incoming mail from hosts they doesn't know about. SRI-CSL will join the ranks as soon as i field one question from a user on how do they reply to a message from one of your unknown hosts. -------  Received: from WISCVM.ARPA by MIT-MC.ARPA 30 Oct 85 03:30:02 EST Received: from (MAILER)BARILAN.BITNET by WISCVM.ARPA on 10/30/85 at 02:29:40 CST Date: Wed, 30 Oct 85 10:24 IST To: Header-People Forum From: Doron Shikmoni Reply-To: Header-People Forum Subject: Columbia usage of internet domain CC: sy.ken%cu20b.BITNET@WISCVM.ARPA , Gadi Maoz The following is a note I've received from the Postmaster at Columbia University, in reply to a former discussion. The issue with relevance to this list, is my pointing (started as a query to the UCB gateway staff) that Columbia's CCnet nodes (CU20A-CU20B-CU20C-CU20D and many others) have started to generate "From:" lines like: "user@CU20A.COLUMBIA.EDU". The former format was: "user@CU20A" (that's on Bitnet; internet addressing obvious). Another piece of fact is that a Bitnet Mailer, wishing to send Mail to any of these hosts, has to send it to MAILER@CUVMA which is the CCnet gateway (regardless to the new "problem"). And (most important): "CU20A.COLUMBIA.EDU" is NOT an Internet host. Neither is it registered in the NIC, Nor is there a domain server for any of those levels which can point to a direction. The only "real" internet (registered) host is CU20B. The principal issue I would like to raise: would this forum agree that using an internet-like (...) addresses can be seen as only a way of indicating the "administrative domain" in which a host resides ? Should we continue to fill up our Mailers with host-specific hacks like the one suggested ? (Note: the suggested solution is having a table with all "CU20x.COLUMBIA.EDU"s that will change them into CU20x only; THEN, go over a table (same ? another ?) to make sure mail to CU20x goes actually to MAILER@CUVMA --> the gateway). Aren't we striving towards SIMPLER, domain-driven mailing systems? Doron ---------------------------- Text of forwarded message ----------------------- Received: (from MAILER@CUVMA for P85025@BARILAN via NJE) (RSCS6294-6294; 47 LINES); Wed, 30 Oct 85 09:15:42 IST Received: from CCNET(MAILER) by CUVMA (Mailer X1.21) id 6293; Wed, 30 Oct 85 02:15:03 EST Date: Wed 30 Oct 85 02:15:26-EST From: Ken Rossman Subject: Re: Mail bounced from UCB. To: P85025, netinfo@UCBJADE cc: P85026, sy.Ken@CU20B In-Reply-To: Message from "Doron Shikmoni " of Wed 30 Oct 85 01: Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12155172261.17.SY.KEN@CU20B.COLUMBIA.EDU> While CU20A is not "on BITnet", neither is it on the Internet. It is on something we call CCnet, though it also does happen to talk TCP/IP, and is on a local net which is connected to an Internet (ARPAnet) gateway. Whether it's entirely our problem is a point of debate, I think. Just because we have started using domain style names does not automatically mean we should be considered an Internet host, or for that matter a BITnet host, or CCnet host, or any-net host in particular. The idea behind the domain naming scheme (or at least perhaps one of the ideas) was to allow hosts to be given names which gave a fairly clear indication of what "administrative domain" the machine belonged to. We think that in general it is a good idea to go with this scheme (particularly since Internet is switching over to this naming scheme, and someday, all of our 20's, not just CU20B, may become official Internet hosts). In any case, CMU hosts have been using this format for some time now. How do you deal with those hosts (e.g. TE.CC.CMU.EDU)? I would suggest that if you have any type of host alias lookup table, that the CU20x.COLUMBIA.EDU machine be entered in the table, and that the official BITnet host name for these hosts be returned as CU20x (CU20A, CU20B, CU20C, CU20D). The mail should go back through the (stupid, losing, bogus) HASP mail gateway here if addressed using the shorter names. If I can do anything here that will help fix things more (short of changing our host names back to the short forms), please let me know. By the way, as for truncated lines (particularly header lines), the (stupid, losing, bogus) HASP mail gateway currently in use here knows how to wrap lines around so instead of being truncated, they are wrapped and indented (though not neatly on a word boundary -- sorry), for outbound mail anyway. Inbound, I don't know what happens. Ken Rossman, Postmaster Columbia Computer Center -------  Received: from ucbvax.berkeley.edu by MIT-MC.ARPA 30 Oct 85 04:47:06 EST Received: by ucbvax.berkeley.edu (5.31/1.2) id AA23388; Wed, 30 Oct 85 00:33:39 PST Received: by ucbjade.Berkeley.Edu (4.19/4.40.1) id AA04408; Wed, 30 Oct 85 00:18:25 pst Date: Wed, 30 Oct 85 00:18:25 pst From: netinfo%jade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8510300818.AA04408@ucbjade.Berkeley.Edu> To: Geoff@sri-csl.arpa Subject: Mail Domain Names: Host table vs. Nameservers Cc: Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucbvax.berkeley.edu In reply to: From @MIT-MC.ARPA:GEOFF@SRI-CSL.ARPA Tue Oct 29 00:06:43 1985 Date: 28 Oct 1985 23:17-PST Sender: GEOFF@SRI-CSL.ARPA Subject: Re: Mail to UC Berkeley hosts From: the tty of Geoffrey S. Goodfellow Cc: Header-People@MIT-MC.ARPA, MRC@SIMTEL20.ARPA Cc: Postmaster@UCBVAX Message-Id: <[SRI-CSL.ARPA]28-Oct-85 23:17:44.GEOFF> In-Reply-To: <8510282352.AA28981@ucbjade.Berkeley.Edu> First of all. Let's stop the shouting match. Shouting at me (postmaster@ucbjade) is not going to solve anything. I do not control the Internet gateway software at Berkeley, "postmaster@ucbvax.Berkeley.EDU" does. netinfo@jade.berkeley.edu, that's dumb thinking. Sorry, but what is dumb? Certainly not full domain names which the Internet has been working towards for years. (Read the RFC's for more information.) Unfortunately, sites in the DARPA research community are caught in the middle. One side we are being told to use full domain names (which by the way we have been using within the BERKELEY.EDU mail domain for years while we have waited for the rest of the Internet to get their act together.) On the other hand, when UCBVAX switched to full domain names names as mandated in RFC 920 and RFC 921, we found that even though RFC 921 was published in October 1984, software developers did not meet the scheduled dates for implimentation of nameservers, and did not recognize the problems of having part of the Internet using the nameservers and part using host tables. Also sites have been slow in registering their new domain names. The DARPA research community's shift to full mail domain names is based on the following from RFC 921: 15 Jul 85 Implementation of the Domain Naming System Completed The goal is to complete the switch over to the domain style names and the use of the servers by this date. All programs that translate host name to Internet addresses should now use procedures based on the use of the domain style names system of resolvers and servers and the distributed data base. 15 Sep 85 Decommission Host Table At this point the master host table maintained by the NIC need no longer be complete for the DARPA research community. A full table of the DDN operational hosts will be maintained by the NIC. 15 Oct 85 DDN Plan for Domains Name Service The DDN PMO may establish a plan for the future support of name to address translations in the DDN community. Note the actions scheduled for 15 Jul 85 and 15 Sep 85. I interprete the actions that were scheduled to apply to all Internet mail hosts, not just the sites in the research community. For example, if the research community hosts are deleted from the master host table, how are other sites on the Internet going to know what they are unless they use a nameserver? My interpretation of the 15 Oct 85 was that this refers to MILNET and other non-research sites changing their names from @something.ARPA to @something.MIL, etc. Unfortunately, some non-research sites interprete this to mean that they do not have to switch over to using software that uses nameservers. Note that the issue of switching to using nameservers is separate from the issue of changing @something.ARPA to one of the new top domain name addresses. do you honestly expect every single user on the Internet to know about your local routing hacks thru user%host@ucbvax.Berkeley.EDU or ...@Berkeley.EDU or ...Berkeley.ARPA?? Really!? You must be a newcomer to the net, for years UC Berkeley has been using the % hack and until recently, our "From:" line addresses had the format: . One solution for Berkeley, MIT, Columbia, and other sites having hosts in their mail domain is to go back to using the % kludge address, but this solution is in conflict with RFC 921 which call for a "complete the switch over to the domain style names". (See how the research sites are caught in the middle again.) heck, i couldn't even reply to your message because your ...@jade.berkeley.edu host isn't registered in the NIC. Foo! Now for a legal issue. The 26 research hosts out of 300 plus hosts at Berkeley that are registered are systems involved with ARPA grants or other computer science research. Most of the users on these systems are hopefully legal users of the US Defense Communications Agency Internet. Most of the users on other systems at Berkeley are not. Host administrators are suppose to restrict access to the USDCA Internet. How can we do that if we register all hosts at Berkeley in the Internet host table? The answer is (with current software) we can't. Nameservers offer a method of registering hosts as mail only sites and permit hosts which are in the local mail domain, but not on the physical Internet, to be addressed. The host table restricts the mail domain to hosts on the physical Internet. Even with nameservers we have a problem. At Berkeley, the Berkeley Internet is interconnected with the UCSF Internet. There are no "US Government Business Only" restrictions between these nets. We want full network services between these nets, but need to have mail only to other "government" nets. So we can even put them in the nameserver as mail only sites. I do not think anyone has come up with a solution to this problem yet. In fact, the domain naming scheme does not offer a solution for EDU sites. How do you determine which hosts we are to restrict access to. (Actual we do not want to restrict access but the only guidance I have seen is the DDN directory which says to restrict access.) Perhaps that policy should be rewriten identifying specific domains (eg. GOV, MIL) or specific nets (eg. MILNET). what do you think someone like Bob Kahn or some other money bags source on a MILNET host is going to do when he can't reply to messages originated by hosts like yours at UCB which isn't registed in the NIC's host tables (and doesn't know about your special address "hack")?? I am flustrated by not being to use an automatic reply feature too. Damn it, why don't you just register your hosts with the NIC and make it easy for yourself, your correspondents and the rest of the net?? See legal issue above. Of course I could ask the opposite question, why don't you switch to software that uses a nameserver as mandated by RFC 921? (No need to reply to that, I have already seen all the answers to that earlier in this discussion.) i seem to be gaining increased appreciation every day for SMTP servers on hosts which *reject* incoming mail from hosts they doesn't know about. SRI-CSL will join the ranks as soon as i field one question from a user on how do they reply to a message from one of your unknown hosts. ------- I think the Internet world needs to recognized that the Internet Mail world extends beyond the physical Internet. I think we can declare RFC 921 a failure and recognize that having part of the Internet using not using full domain names and a host table and the other half using full domain names and nameservers is not going to work. So it looks like it is back to % sign address kludges and "no progress" in the implimentation of distributed domain servers and full domain names until the whole internet starts using name servers. I think some practical ideas for how to test out the name server software with out a "complete shift" to full domain names is in order. Also a revision to RFC 921 is needed. Bill Wells postmaster%ucbjade@Berkeley.EDU PS. For those of you who want to do more reading about domains, is a list of references. ----------- RFC "Request for Comments" reports from the DDN Network Information Center, SRI International, Menlo Park, CA are available to Internet hosts by FTP from the ARPANET host SRI-NIC, and to CSNET members as either electronic messages or paper copies from the CSNET CIC . [1] RFC 822 "Standard for the Format of ARPA Internet Text Messages", David H. Crocker, August 13, 1982. (Replaces RFC 733.) [2] RFC 920 "Domain Requirements", J. Postel, J. Reynolds, October 1984. This memo restates and refines the requirements on establishing a Domain first described in RFC-881. It adds considerable detail to that discussion, and introduces the limited set of top level domains. [3] RFC 921 "Domain Name System Implementation Schedule - Revised", Jon Postel, October 1984. (Updates RFC 897.) [4] RFC-881 "The Domain Names Plan and Schedule", J. Postel, November 1983. [5] RFC 882 "Domain Names - Concepts and Facilities", P. Mockapetris, November 1983. [6] RFC 883 "Domain Names - Implementation and Specification", P. Mockapetris, November 1983. [7] RFC 733 "Standard for the Format of ARPA Network Text Messages", David H. Crocker, John J. Vittal, Kenneth T. Progran, D. Austin Henderson, Jr., 21 November 1977. [8] 921ISO, "Codes for the Representation of Names of Countries", ISO-3166, International Standards Organization, May 1981.  Received: from A.CS.CMU.EDU by MIT-MC.ARPA 30 Oct 85 09:55:08 EST Date: 30 Oct 85 09:45 EST From: Rudy.Nedved@A.CS.CMU.EDU To: Header-People Forum Subject: Re: Columbia usage of internet domain CC: sy.ken%cu20b.BITNET@WISCVM.WISC.EDU, Gadi Maoz , Doron Shikmoni In-Reply-To: "Doron Shikmoni's message of 30 Oct 85 10:24-EST" Message-Id: <30Oct85.094541.EN0C@A.CS.CMU.EDU> Some significant points: 1) Yep, domain names are administrative and have nothing to do with networking. A name like CU20A.COLUMBAI.EDU does NOT mean it is on the ARPA Internet. 2) The BITNET RSCS mail files are nice but they are glorified fancy host tables. In the long run, some type of general gateway hack will have to be added or better yet an distributed database mechanism will be added since BITNET+Internet+UUCP+CSNET+MAILNET+etc. will be too much to keep updating and storing on every single BITNET site. 4) There is a domain transition going on so things are going to be rocky for a while. Some domains do not have sites listed in the old table, domain servers are inconsitent, confused and unreliable. Resolvers evaluate a name wrong and so forth. The problem with CU20A at the moment is that given you can not access it from the ARPA Internet, it should have an MF record for some host that will accept mail for CU20A. Also CCNet which is based on DECNet should probably have a CLASS of DN (DecNet) or something. Things are fuzzy. Hopefully when CHAOSNet and CSNET gets into the domain system, CCNet and BITNET will follow... -Rudy  Received: from hydra.ARPA by MIT-MC.ARPA 30 Oct 85 11:42:32 EST From: Barry Leiner Message-Id: <8510301641.AA03838@hydra.ARPA> Received: by hydra.ARPA (4.12/4.01) Wed, 30 Oct 85 08:41:05 pst Date: 30 Oct 1985 0841-PST (Wednesday) To: netinfo%jade@BERKELEY.EDU (Postmaster + BITINFO) Cc: Header-People@mit-mc.ARPA, MRC@simtel20.ARPA, postmaster@ucbvax.berkeley.edu, Geoff@sri-csl.ARPA Cc: Richard desJardins , Dennis Perry Cc: Bob Baker Subject: Re: Mail Domain Names: Host table vs. Nameservers In-Reply-To: Your message of Wed, 30 Oct 85 00:18:25 pst. <8510300818.AA04408@ucbjade.Berkeley.Edu> Bill, You have it basically correct. However, let me once again (see my note of a few weeks ago) try to explain what is supposed to be happening. 1. ALL hosts on the internet have to be able to deal with domain style names if they want to be able to talk with anyone else. Therefore, there should not be a part of the internet that uses a host table and not full domain names. 2. Hosts that rely on using the host table may not have the capability of communications with all hosts (particularly some of those that rely on host tables rather than domain servers). This is mainly due to limitations of the host table paradigm and is the main reason for going to domain servers in the first place. 3. The NIC is doing what they can to mitigate the effects of (2). However, they clearly are not going to be successful in achieving full capability between all hosts using domain servers and all hosts using host tables. Therefore, once the "research" community has proven the concept of domain servers, I would anticipate many if not most of the remaining sites will switch to using domain servers. 4. In the meantime, users that are on hosts that rely on host tables and that want to communicate with sites that are not in the host tables really have no option other than to push their system developer/maintainer to put in place domain nameserver capability. Hope this helps. Barry ----------  Received: from mordred.Purdue.EDU by MIT-MC.ARPA 30 Oct 85 12:14:13 EST Message-Id: <8510301706.AA12627@mordred.Purdue.EDU> Received: by mordred.Purdue.EDU; Wed, 30 Oct 85 12:06:00 EST To: netinfo%jade@BERKELEY.EDU (Postmaster + BITINFO) Cc: Geoff@sri-csl.arpa, Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucbvax.berkeley.edu Subject: Re: Mail Domain Names: Host table vs. Nameservers Phase-Of-The-Moon: Waning Gibbous (97% of Full) In-Reply-To: Your message of Wed, 30 Oct 85 00:18:25 pst. <8510300818.AA04408@ucbjade.Berkeley.Edu> Date: 30 Oct 85 12:05:49 EST (Wed) From: "John A. Dilley" Well, looks like this one was able to be replied to. Good. So how about if some diligent persons on the Internet implement and debug name servers, and then pass the source to other sites? With any luck, the (already overworked) sys.admins will be able to bring it up without too much trouble; not nearly as much as having to implement it all themselves, which admittedly is quite a task. I suspect that there are enough sites short of manpower to keep this thing from getting off the ground on schedule. Am I right, or are there [research community] hosts that just don't *want* to convert? For now, of course, the undesirable '%' kludge *must* be used. It's nice that Cal is so far ahead of the game that they've had domains working locally for years. But as we've seen you can't force it on the Internet, even if it should be out there and working weeks ago (according to RFC 921). Is it possible for those who are with it to help out those behind? If we could do this it might even convince the DDN people that it can be done smoothly, and that our national defense systems won't be out to lunch for a month cause nobody can look up hosts ;-) Of course there are serious problems to be worked out (some local ones which you pointed out, and others)... I know that research community is stuck in the middle, it's not their fault, etc. etc. How can we help get this worked out? We don't need any more finger pointing, name calling, or blame shifting. We do need working electronic communication networks. -- jad -- John A Dilley ----------  Received: from LOKI.ARPA by MIT-MC.ARPA 30 Oct 85 13:33:24 EST To: jad@purdue.edu cc: header-people@mit-mc.arpa Subject: re: Mail Domain Names, etc. Date: 30 Oct 85 13:27:16 EST (Wed) From: Craig Partridge John, I think you are being too hard on the research community. Work is going ahead on the domain conversion, it is just taking longer than the implementation schedule is allowing for. But this is not a trivial change. Large programs like mail systems do not change overnight. Releases tend to come on the order of once every two years, not every 3 months, as the conversion schedule might seem to demand. What is more, this is an experiment, and we are still tripping over problems with domain names that people did not forsee -- which means more work on the complex software that takes a long time to change anyway. From where I sit (one of the people responsible for keeping a highly connected, very complex mail system running) I actually think things are going pretty well, and expect you'll see a lot of good domain software coming down the pike shortly.... (famous last words). Craig Partridge CSNET Technical Staff craig@csnet-sh (CSNET) craig@loki (ARPA) {decvax,ihnp4,wjh12}!bbncca!craig (USENET)  Received: from A.CS.CMU.EDU by MIT-MC.ARPA 30 Oct 85 13:35:23 EST Date: Wed, 30 Oct 85 12:40 EST From: don.provan@A.CS.CMU.EDU To: netinfo%jade@UCBVAX.BERKELEY.EDU (Postmaster + BITINFO) Subject: Re: Mail Domain Names: Host table vs. Nameservers CC: Geoff@sri-csl.arpa, Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucbvax.berkeley.edu In-Reply-To: <8510300818.AA04408@ucbjade.Berkeley.Edu> Message-Id: <30Oct85.124052.DP0N@A.CS.CMU.EDU> I think it's safe to say that Mr. Goodfellow has been active in the network long enough to know about Berkeley's "%" hack. How long have *you* been around that you aren't aware of how long Mr. Goodfellow's been around? At any rate, he isn't concerned about mail he receives. He's concerned about mail his users receive, even the ones that have been around many years but don't happen to read lists like this. In fact, I think it's insulting to try to trivialize this problem to a claim that "any smart person should know how to do it. Don't you?" As to the legal aspects, you obviously are failing completely on that score. You've already allowed a piece of mail to go out from an unauthorized user. Now you claim that, since that user is unauthorized, an authorized user should not be allowed to reply? Get your head out of your. If you've taken steps to prevent access without a name, it shouldn't matter whether or not I have a name. If you haven't taken such steps, then it doesn't matter whether or not I have a name, since I can use a number. But to try to claim that mail sent out should be allowed to have illegal names because the sites are illegal shows some sort of brain damage. I'd say that schedule is obsolete. That doesn't mean the project's been dropped, it just means it's behind schedule. If I were you, I'd be more concerned with providing good service than with standing on a soap box.  Received: from merlin.Purdue.EDU by MIT-MC.ARPA 30 Oct 85 15:23:54 EST Message-Id: <8510301910.AA20851@merlin.Purdue.EDU> Received: by merlin.Purdue.EDU; Wed, 30 Oct 85 14:10:46 EST To: netinfo%jade@BERKELEY.EDU (Postmaster + BITINFO) Cc: Header-People@mit-mc.arpa, postmaster@ucbvax.berkeley.edu Subject: Re: Mail Domain Names: Host table vs. Nameservers In-Reply-To: netinfo's message of Wed, 30 Oct 85 00:18:25 pst. <8510300818.AA04408@ucbjade.Berkeley.Edu> Date: 30 Oct 85 14:10:42 EST (Wed) From: "Christopher A. Kent" This is, I hope, not just a further contribution to the shouting match, but rather an attempt to examine "what's so" about the situation with nameservers, the lack of them on DDN hosts, and Berkeley's headers. First, some bottom line assertions/facts: * Berkeley is sending mail that cannot be replied to. * There is a solution to this that does not require the % hack. * MILNET/DDN hosts aren't required to run domain-based mail. I don't think anyone will argue with the first point -- Berkeley hosts are sending out mail from sites that aren't in the NIC's host table, and there are many hosts that rely on this host table as their only method of mapping from name to Internet number, and *are not required to do otherwise.* Therefore solutions of the form "why don't you switch to software that uses domain namesolvers" are not acceptable. A solution to the problem is for Berkeley to register hosts that are going to originate Internet mail with the NIC. (Please note that I make a distinction between Internet and internet -- Internet is the DARPA-funded collection of networks; internet is any collection of interconnected networks, not necessarily restricted to those running the IP family of protocols.) The argument made by Bill Wells against this was that there are 300 or more hosts on the Berkeley internet, and that many/all of the users on those hosts are not authorized users of the DARPA Internet, so he doesn't want to register all those hosts. I couldn't agree more. But the next step must also be taken -- if the users aren't authorized, don't let their mail (or packets) leak into the Internet. Do whatever you like in your internet or any internets to which you are connected, but observe the ground rules of being part of the Internet. Admittedly, this is not easy in the 4.2 world, because the software isn't set up to do it. We at Purdue are in a similar situation, and have two partial solutions: networks that are comprised entirely of non-authorized hosts don't get routing information about anything outside of our internet. Hosts that have a mix of authorized and non-authorized users have software that checks each user's authority to send packets off-internet (to be specific, there's a group "arpa" and if you are authorized, you're in it; there's a table of nets in the kernel that are off-limits to non-members.) It's ugly, but it works. I, too, would prefer not to have to restrict access. But that is one of the rules of the game, and it can't just be wished away. We must abide by it. This doesn't cover all the cases -- unfortunately, mail addressing formats are rich enough that relaying is possible, and it doesn't always get caught. People here are working on changes to sendmail to allow these cases to be trapped automatically; until then, we are vigilant and pounce on violators. Saying "users need to know how to turn netinfo@jade.BERKELEY.EDU into netinfo%jade@BERKELEY.EDU" is just plain unfriendly, and not a workable solution. I don't think I need to say more about it. On to the third point. DARPA research internet hosts are required to convert to using domain names and domain namesolvers. The DDN/MILNET hosts aren't. The implementation schedule in RFC921 has slipped a bit. Those are a few more facts of life for the time being. Rather than throwing up our hands and saying "it won't work unless everyone runs domain namesolvers", why not take this on as a challenge -- see what we can do to make it all work within the rules? Cheers, chris ----------  Received: from BRL-SEM.ARPA by MIT-MC.ARPA 30 Oct 85 18:30:27 EST Date: Wed, 30 Oct 85 14:14:54 EST From: Ron Natalie To: Mark Crispin cc: Header-People@mit-mc.arpa Subject: Re: mail from Berkeley hosts Great, and fix TOPS-20 mailers so they do a date line that people who obey the RFC can parse. -Ron  Received: from Dewey.UDEL.EDU by MIT-MC.ARPA 30 Oct 85 21:39:27 EST Received: from localhost by Dewey.UDEL.EDU id a009479; 30 Oct 85 21:31 EST To: Ron Natalie cc: Mark Crispin , Header-People@mit-mc.ARPA Reply-To: Directly to Header People and NOT to me Subject: Re: mail from Berkeley hosts In-reply-to: Your message of Wed, 30 Oct 85 14:14:54 EST. Date: 30 Oct 85 21:31:05 EST (Wed) Message-ID: <4057.499573865@dewey> From: Marshall Rose Here we go again. Let's point the fingers at the keyboards and solve the problems instead of pointing them at each other and raising our blood pressure. And now, a joke: a couple of months back I presented a paper at an electronic mail conference. For a slide or two I was talking about header munging and why it was a bad thing. I used a rhyme to sum it all up: Humpty Dumpty went through a relay, Humpty Dumpty was munged in the melee; And Hermes, and MH, and Crispin's MM, Couldn't put Humpty back together again. (it didn't go over well there either...) /mtr  Received: from WISCVM.ARPA by MIT-MC.ARPA 31 Oct 85 03:40:37 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 10/31/85 at 02:40:14 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 3075; Thu, 31 Oct 85 09:59:26 O Date: Thu, 31 Oct 85 09:36 O From: Henry Nussbacher Subject: Re: Columbia usage of internet domain To: In-Reply-To: Your message of 30 Oct 85 09:45 EST cc: , Reg Quinton , Alan Crosswell , Jeffrey Honig > 2) The BITNET RSCS mail files are nice but they are glorified fancy > host tables. In the long run, some type of general gateway hack > will have to be added or better yet an distributed database > mechanism will be added since BITNET+Internet+UUCP+CSNET+MAILNET+etc. > will be too much to keep updating and storing on every single > BITNET site. VM sites that run with a mailer do *not* keep all network tables. They keep the Bitnet tables and when sending to a site the mailer scans the address following the last '.' for a domain name like: ARPA, EDU, GOV, MAILNET, etc. Bitnet sites need to keep a list of all CCnet sites since the gateway did not accept an upper level domain like: user@cwr20b.CCNET Now with CCnet accepting upper level domains, the mailer will need to scan backwards to a second level '.' to see if the mail shouldn't be routed to the normal '.EDU' gateway (currently UCBJADE - soon to become WISCVM) but rather to the CUVMA CCNET gateway. Henry Nussbacher  Received: from ucb-vax.berkeley.edu by MIT-MC.ARPA 31 Oct 85 04:37:34 EST Received: by ucb-vax.berkeley.edu (5.31/1.2) id AA03421; Wed, 30 Oct 85 19:37:13 PST Received: by ucbjade.Berkeley.Edu (4.19/4.40.1) id AA20012; Wed, 30 Oct 85 19:37:07 pst Date: Wed, 30 Oct 85 19:37:07 pst From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8510310337.AA20012@ucbjade.Berkeley.Edu> To: don.provan@a.cs.cmu.edu, netinfo%jade@ucb-vax.berkeley.edu Subject: Re: Mail Domain Names: Host table vs. Nameservers Cc: Geoff@sri-csl.arpa, Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucb-vax.berkeley.edu In reply to: Date: Wed, 30 Oct 85 12:40 EST From: don.provan@a.cs.cmu.edu Message-Id: <30Oct85.124052.DP0N@A.CS.CMU.EDU> .... But to try to claim that mail sent out should be allowed to have illegal names because the sites are illegal shows some sort of brain damage. Where did you get the idea that I was saying that? The point that I was trying to make was that RFC 921 put use in the position of implimenting one set of addresses on one part of the internet mail system, and another set on the other part of the internet mail system, without separating the the mail system into two separate functioning parts. This has cause several problems. One solution I offered earlier was to logically separate the two system and have mail gateway(s) between the two which would put full domain addresses in messages going to the non-nameserver side into an form acceptable to the side of the mail system using host tables. One method to do this is to source route the addresses going to host table sites with the @domain-address of the mail gateway (which would be registered in host table). Does anyone have any comments on using this method to test out the nameservers on the research side of the house without interferring with the operational side of the house? Bill Wells postmaster%ucbjade@ucbvax.Berkeley.EDU  Received: from ucb-vax.berkeley.edu by MIT-MC.ARPA 31 Oct 85 05:28:56 EST Received: by ucb-vax.berkeley.edu (5.31/1.2) id AA04099; Wed, 30 Oct 85 20:08:55 PST Received: by ucbjade.Berkeley.Edu (4.19/4.40.1) id AA20418; Wed, 30 Oct 85 20:08:40 pst Date: Wed, 30 Oct 85 20:08:40 pst From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8510310408.AA20418@ucbjade.Berkeley.Edu> To: don.provan@a.cs.cmu.edu, netinfo%jade@ucb-vax.berkeley.edu Subject: Re: Mail Domain Names: Host table vs. Nameservers Cc: Geoff@sri-csl.arpa, Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucb-vax.berkeley.edu Good news. I have been advised by a mail systems guru at UCBVAX that UCBVAX is now sending out mail from hosts not in the NIC host table in the format: user%host@Berkeley.EDU At least that solves the short-term problem for the sites still using the NIC host tables. Bill Wells postmaster%ucbjade@Berkeley.EDU  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 31 Oct 85 20:16:57 EST Date: 31 Oct 1985 16:52:23 PST From: POSTEL@USC-ISIB.ARPA Subject: repeated text in message problem To: header-people@MIT-MC.ARPA Hi. I occasionally receive a message that has the last few to 200 or so characters repeated. A few months ago i started to note the occurance of this. In June and July i noted 6 times, in September none, and in October 5 times. This is a pretty small percentage of the messages i receive. As far as i can tell, the only thing in common is that all the messages originated on Unix machines (i think). In all there were 8 different originating machines. Can anyone spot the common thread in this problem? Can anyone describe the fix? The eight machines are: MITRE.ARPA, WISC-RSCH.ARPA, NAVAJO.ARPA, ISI-HOBGOBLIN.ARPA, DCN9.ARPA, EDN-VAX.ARPA, BORAX.MIT.EDU, and SRI-TSC.ARPA. --jon. -------  Received: from ucb-vax.berkeley.edu by MIT-MC.ARPA 1 Nov 85 17:08:17 EST Received: by ucb-vax.berkeley.edu (5.31/1.2) id AA03008; Wed, 30 Oct 85 19:19:42 PST Received: by ucbjade.Berkeley.Edu (4.19/4.40.1) id AA19714; Wed, 30 Oct 85 19:19:25 pst Date: Wed, 30 Oct 85 19:19:25 pst From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8510310319.AA19714@ucbjade.Berkeley.Edu> To: don.provan@a.cs.cmu.edu, netinfo%jade@ucb-vax.berkeley.edu Subject: Re: Mail Domain Names: Host table vs. Nameservers Cc: Geoff@sri-csl.arpa, Header-People@mit-mc.arpa, MRC@simtel20.arpa, postmaster@ucb-vax.berkeley.edu I am not soapboxing. But it is interesting to note that when I asked for solutions, I received "flaming" messages; and when I tried to help a remote user with mailing to Berkeley, I got blasted. I think all of us are flustrated by problems caused in part by different interpretations of RFC 921. I am also concerned about the mail that my users are receiving or not receiving. I also recognize the changes happening on UCBVAX which cause problems to the mail system are hurting the users at Berkeley more than they are the rest of the net. Believe me, I get it from both sides because I am the primary person at Berkeley answering users' questions about network mail. Enough said about that. --------- Now on to solutions. A) In regards to: <@nic-host-table-domain-address:user@unknown-domain-name> or <@ucbvax.Berkeley.EDU:user@unknown-host.Berkeley.EDU> One solution I suggested for fixing UCBVAX's "From" lines was to do source routing, however I received a reply from software implimenter that all hosts had to be registered in because his software validated both sides of the colon in a source routed address. Unfortunately, this restriction presents a problem for sites that have more than one type of network. (Here at Berkeley we have hosts linked by local IP nets, UUCP, HASP, and Berknet links. Columbia has their CCnet. LBL/SLAC have sites on the PhysNet DECNET) It is not possible for non-internet nodes to be registered in the host table since they do not have an Internet network address. I prefer source routing to the % sign addressing kludge, so I suggest that domain name validation only be do on the first @domain-name in the "route" part of source routed address. This change would greatly help mail gateways to other networks that do not support Internet domain address, for example: <@wiscvm.wisc.edu:user@node.BITNET> or <@CS.NET:user@host> B) Although the mail only entry in nameserver data base can be used to identify the internet gateway for a non-internet host, I would also like to be able to tag certain internet hosts as not being able to receive mail to prevent SMTP process from being attempted. And then use an mail only entry to specify the mail route to be taken. I am not sure if the first is currently possible, the latter can be accomplished through requiring MTA programs to check for mail only records in the nameserver first. This is important for us and other sites that have low speed IP links so that mail traffic can be routed not to fill up a narrow channel and degrade other network services across that channel. For example, a site may want to give better service to "ftp" and route mail traffic via an alternate route. Bill Wells postmaster%ucbjade@ucbvax.Berkeley.EDU  Received: from SRI-CSL.ARPA by MIT-MC.ARPA 1 Nov 85 17:23:21 EST Date: 1 Nov 1985 14:21-PST Sender: GEOFF@SRI-CSL.ARPA Subject: Re: Mail Domain Names: Host table vs. Nameservers From: the tty of Geoffrey S. Goodfellow To: netinfo%ucbjade@UCBVAX.BERKELEY.EDU Cc: don.provan@A.CS.CMU.EDU Cc: netinfo%jade@UCBVAX.BERKELEY.EDU Cc: Header-People@MIT-MC.ARPA, MRC@SIMTEL20.ARPA Cc: postmaster@UCBVAX.BERKELEY.EDU Message-ID: <[SRI-CSL.ARPA] 1-Nov-85 14:21:02.GEOFF> In-Reply-To: <8510310319.AA19714@ucbjade.Berkeley.Edu> Bill Wells: Being equally concerned as you are with the mail your users are receiving or not receiving (and their ability to reply or not to reply), i'm appreciative the fix recently (re-?)installed at UCB allowing me (as well as my users) to reply to messages like yours. A hearty thanks for the prompt action taken (in spite of flames). Yours in new and better ARPANETing, (since '73), g  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 4 Nov 85 14:37:10 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2677433404686025@MIT-MULTICS.ARPA>; 04 Nov 1985 14:30:04 est Date: 04 Nov 85 15:41 +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: Re: Mail Domain Names: Host table vs. Nameservers Message-ID: <132230@QZCOM> In-Reply-To: <8510301910.AA20851@merlin.Purdue.EDU> Chris, watching the discussion from the side I think that your major problem is that you (using the RFC protocols) are trying to solve two problems: 1 - aid in routing matters 2 - impose political restrictions In (1) you will certainly get a situation that is easier to manage when we see more names of the form Don.Provan@A.CS.CMU.EDU, the more levels in the naming hierarchy the higher degree of freedom to implement msg transportation rules for real INTERnetworking. But there is a drawback that is soon (if not already) going to show up: your host tables will grow immensely if you everywhere are required to retain all the information everywhere. Given that you could consider CMU (as an example) infrastructure as an internal matter there would not be a need for you at Purdue to know more than the ADDRESS of CMU.EDU, further distribution is a matter of CMU (as in the case John-Doe%A.CS@CMU.ADU). Comparison with the %-convention reveals that the @-sign should neither have to be that holy, could be interchanged with a dot and there we would have a simpler name structure. Problem (2) is (if I haven't completely misunderstood everything) being imposed (or intended to be) by the fact that all legal hosts should be in some specific host table, thereby disallowing non-registred ones. This can work as long as the number of hosts is small enough, but again (considering workstations etc) is rapidly growing. I agree completely with you that it should be a responsibility of the gatewaying host that grants or denies certain accesses, distribution being the key-word. Finally, I assume that you all know about the CCITT activities on Directory Systems? Two of the members in that Special Rapporteur group are Jim White and Dave Crocker, a fact that should guarantee that experiences and requirements from the DoD Internet environment are considered. I am rather optimistic about that they can come up with a Recommendation that could be universally useable, just WE ALL make sure to give contributions in appropriate ways in time. Cheers, Tommy  Received: from WISCVM.ARPA by MIT-MC.ARPA 14 Nov 85 10:12:42 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/14/85 at 06:59:10 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 4601; Thu, 14 Nov 85 14:54:00 O Date: Thu, 14 Nov 1985 14:42 O From: Henry Nussbacher Subject: Domains and servers To: I just looked at netinfo:domain.txt (on SRI-NIC) and saw the following: For the domains ARPA, GOV, EDU, COM, MIL and ORG the following are registered as domain name servers: SRI-NIC, USC-ISIC, USC-ISIB, BRL-AOS. For .US, it is only SRI-NIC and USC-ISIF, for .UK it is UCL-NS2 and UCL-NS1 and for .NET it is SRI-NIC and USC-ISIB. That's it? Or am I missing something about the intention of this file. Hank  Received: from ucbvax.berkeley.edu by MIT-MC.ARPA 15 Nov 85 14:15:20 EST Received: by ucbvax.berkeley.edu (5.31/1.2) id AA20277; Fri, 15 Nov 85 11:09:17 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA03799; Fri, 15 Nov 85 11:12:05 pst Message-Id: <8511151912.AA03799@ucbjade.Berkeley.Edu> Date: 15 November 85 14:09 EST From: RMXJ%CORNELLA.BITNET@ucbvax.berkeley.edu Subject: (copy) Re: .EDU problems in Bitnet To: HEADER-PEOPLE@mit-mc.arpa Originally sent from: RMXJ@CORNELLA.BITNET Originally sent to: RMXJ@CORNELLA This message is from Ken Rossman at Columbia: SY.KEN @ CU20B. BITNET What some of the folks arguing against our new naming convention fail to realize is that the domain style name has nothing specifically to do with: a) Specific networks. b) TCP/IP or ARPAnet. Specific networks in domain names: The network name does not necessarily need to be somewhere within the name, and in most cases, isn't. Many hosts are also on several networks, for example (like CU20B or COLUMBIA), so how could it make sense to stick a network name somewhere in the domain name for the host? This would have to mean that such hosts would have to have different names for different networks, while the domain naming concept was created for exactly the opposite reason -- so that every host, no matter what network or networks it was on, could have ONE name which described it (the name should describe the administrative domain within which it resides, not (necessarily) the network domain). Network protocols: Here again, even though early on, domain names had .ARPA tacked onto them, they no longer will have them. The highest level domains are names like EDU (the research/educational segment of the Internet), MIL (the military segment), and COM (commercial). So even though we use domain style names for both our Internet and non Internet systems, it shouldn't matter, and the NIC host tables (which are disappearing sometime soon anyway!) don't need to know about some of these (and shouldn't). So, once the smoke clears, the name is neither related to the protocol nor the network, and the answer as to how one picks the return network path does not lie in parsing the name. Apparently, until recently, many BITnet sites would assume that if a domain style name was used, it should go back through the Wisconsin Internet gateway, and of course, this worked for most cases up to now. Since the face of networks and network names is changing rapidly now (and NOT just here at CU either!), BITnet folks are just going to have to figure a different way out of the dilemma. The recoommended way to do this, of course, is through the use of a name server. However, since these don't exist widely yet, the next best thing I can think of is to stick aliases into your host tables, with the older short-form BITnet host names as the official names. These should still work in the reverse direction, since they are still used as aliases on this side. As for being reluctant to send mail from here to BITnet with alternate names in the mail headers, this would mean major hacks to our mail system software, which naturally I am rather reluctant to do (not even having enough time to do the other things I should already be doing here). Also, folks on BITnet might as well get used to having to deal with the domain style names, as more and more hosts are using them, and they are becoming the standard on more than a few networks. Additionally, it is a bad idea to change the contents of mail headers or text while in transit through, say, a DECnet-BITnet gateway. Remember, we didn't cook up the concept of the domain name -- the folks writing the RFC's did. As far as I can tell, we're going by the rules. Please feel free to redistribute this to other interested parties, and I welcome further debate on the matter. /Ken -------  Received: from WISCVM.ARPA by MIT-MC.ARPA 17 Nov 85 08:30:11 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/17/85 at 07:26:49 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 1045; Sun, 17 Nov 85 14:36:07 O Date: Sun, 17 Nov 1985 14:28 O From: Henry Nussbacher Subject: .US domain and why isn't it the top level domain To: Domain Hostmaster cc: If you have been following the discussion in Arpa-Mhs this will not be new to you: Since Europe and the rest of the world is adopting upper level domain names corresponding to their country (i.e node.AC.UK or node.AC.IL) then why can't the Internet adopt the standard that the .US is the upperlevel domain? What is wrong with: SEISMO.CSS.GOV.US (Examples) BITNIC.BITNET.US CSNET-SH.CSNET.US AOS.BRL.MIL.US MCC-AI.MCC.COM.US Hank  Received: from BRL-SEM.ARPA by MIT-MC.ARPA 17 Nov 85 16:16:25 EST Date: Sun, 17 Nov 85 16:05:21 EST From: Ron Natalie To: Henry Nussbacher cc: Domain Hostmaster , header-people@mit-mc.arpa Subject: Re: .US domain and why isn't it the top level domain You presume that SEISMO.CSS.GOV is part of our government!  Received: from WISCVM.ARPA by MIT-MC.ARPA 17 Nov 85 21:17:02 EST Received: from (MAILER)BARILAN.BITNET by WISCVM.ARPA on 11/17/85 at 20:12:54 CST Date: Sun, 17 Nov 85 23:40 O To: Ken Rossman , Jon Solomon From: Doron Shikmoni Subject: Re: EDU problems in Bitnet. CC: Header-People Forum , Info-Nets distribution (This should reply Ken Rossman's and Jon Solomon's recent notes). Before we go on with this issue, the distribution of this Mail exchange is getting a bit out of hand (and I guess some of you are already getting more than one copy of each...). I'd suggest to move it all to one list, and I think Header-People is the right forum - please correct me if I'm wrong and somewhere else is more appropriate. I'll accept anything as long as it's ONE LIST... Ken Rossman: I'll use your invitation for further debate.. RFC920-style addresses have all the properties you're pointing at. Yes. But it seems there's one thing you keep forgetting: Bitnet does not comply with DARPA RFC's (at least not for now). "Domain-style name has nothing specifically to do with specific networks or networking protocol (TCP/IP or ARPA)" (Ken Rossman) - this is only partialy correct. I'd agree it has nothing to do with TCP/IP and these layers of the networking machanism protocols. But you simply CAN'T say it's "network independent". It is such only as far as a network accepts and handles "things" like RFC920 (or RFC822, or anything). You wouldn't claim, I guess, that the RFC920-style addresses "should" be recognized and handled correctly by ANY arbitrary electronic Mail network. For one thing, the addresses you generate may even be *invalid* in "another" network. Gateway-ing Mail into a Mail exchange system X requires that you send in Mail that agrees with system X's internal rules and capabilities (at least pack it in an envelope). That's part of a gateway function - not just moving Mail files from TCP/IP system (or whatever) to RSCS/NJE system (or whatever). You simply can't jump in and say "you must follow MY rules". Domain names are NOT a standard rule in Bitnet. Yes, a host may have several addresses, dependent on the NETWORKING ENVIRONMENT. My host name is "Barilan" in Bitnet, yet some "Barilan.Bitnet@Wiscvm.Wisc.Edu" in the Internet. And this is NATURAL. And here we get to an important point: YES it would have been nice if Bitnet would support RFC920 (fully). YES it would be good and effective if we had a nice hierarchy of domain servers. YES it would be great if our mail software could handle these things properly. BUT ALL THESE ARE NOT TRUE. Not for the moment, and (if I'm guessing right) not in the near future. It may be right to follow DARPA community's footsteps in planning the future of Bitnet (and then, it may not..); but that's well beyond the scope of our discussions. Having a one-network "image" with cross-network addressing conventions is SF, yet. What we are dealing with is current Mail transfer. And the point raised was exchanging Mail between a domain-driven system (I guess you can now call CCnet this) and another system which does not support or use domains. Using domains in Bitnet is an old issue, discussed in a few Bitnet forums. Yet FACTS are that most Bitnet hosts today will not even recognize the ".Bitnet" pseudo-domain name, suggested for use a long time ago (please don't attack me on THAT one; I know ".Bitnet" contradicts the "independency" path taken by RFC920). FACT is that although a few Bitnet Mail software packages can recognize top-most domain names and make some (primitive) decisions - this is more a sort of a hack, with hardcoded tables and very little "intelligence". So you're coming now, saying "I KNOW I'm using the right philosophy" (which is probably correct), and changing a working environment into a non-working one. The net result of this, is that Bitnet users have lost the capability to use the addresses they receive to reply. They have to know (Jon Solomon), that when they see "user@CU20A.COLUMBIA.EDU", they have to send replies to "user@CU20A" (utilizing another system hack - since CU20A is also not a Bitnet site..). Some of the Bitnet Mail software packages can fairly easily be further hacked, to contain a list of ALL Columbia sites, with their "new" names and the Columbia Bitnet-CCnet gateway address (CUVMA). Some others will require a lot of effort for this hack. Is that "correct"? of course not. By the way: the ".Bitnet" pseudo domain name is used today in many places to relay Mail from Internet into Bitnet. Should this stop too ? NOW ? "it should work - NOW". I think that's a good guideline. Sure, you must be prepared for the future with a full scheme of implementation phases. Yet I think it's not to anyone's interests to bring working Mail exchange to a halt due to a "GOOD" addressing approach. But I'm repeating myself already (sorry - it's getting late..). Doesn't all this sound surprizingly similar to the fight that took place recently between (mainly) Berkeley and the military branch of DARPA about RFC920 implementation? the research community said "but it's good for us". The military side said "yeah - but it doesn't work TODAY, and I can't sit down NOW and rework my mail software". I guess that's enuf for now. But I'd appreciate if we could all think in a constructive direction and find out how this can be solved - to WORK, not just to be academically "proper". Columbia absorbed some fire for going first; it happens... Solutions, however, should be general. (I'm certainly not interested in "flaming" for its own - I really have better things to do...). Thank you for your time and patience Doron.  Received: from WISCVM.ARPA by MIT-MC.ARPA 18 Nov 85 01:47:53 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/18/85 at 00:44:31 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6068; Mon, 18 Nov 85 08:17:43 O Date: Mon, 18 Nov 1985 07:50 O From: Henry Nussbacher Subject: Re: .US domain and why isn't it the top level domain To: Ron Natalie In-Reply-To: Your message of Sun 17 Nov 85 16:05:21 EST cc: , Well, under the current set up, SEISMO.CSS.GOV is considered a government site by its .GOV suffix. There would have to be some body that assigns country upper level suffixs and then one 'entity' (let's say SRI-NIC) is responsible for all second level suffixes (as it is now with GOV and EDU and MIL, etc.). The only problem (which perhaps you were alluding to) would be American military bases in Europe. The question would be do they get a country upper level suffix of .US or the country they are in? I would say they should get US. American embassies throughout the world are considered American property (as are all embassies). Why not give American military bases overseas and address of: FORTNORTH.OVERSEAS.MIL.US The people responsible for the .MIL domain would assign third level domains and would be able to specify that a site is in America or overseas by controlling the third level qualifier. It shouldn't by SRI-NIC that is responsible for that. Hank  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 18 Nov 85 15:43:16 EST Received: from ubc by csnet-relay.csnet id a020258; 18 Nov 85 9:11 EST Date: Mon, 18 Nov 85 06:08:21 pst Received: by ubc.csnet id AA01503; Mon, 18 Nov 85 06:08:21 pst From: Peter Stokes To: header-people@mit-mc.ARPA Message-Id: <402:stokes@cmc.cdn> Subject: Please remove I don't like to ask to be removed from a BB by writing to the BB but I seem to be on a redistribution point that I don't know about! Please remove me. Thanks in advance, Peter Stokes CMC  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 19 Nov 85 05:52:59 EST Received: from bostonu by csnet-relay.csnet id ab29225; 19 Nov 85 5:35 EST Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA24039; Mon, 18 Nov 85 21:56:54 est Date: Mon, 18 Nov 1985 21:58 EST Message-Id: <[BUCS20].JSOL.18-Nov-85 21:58:35> From: Jon Solomon To: Doron Shikmoni Cc: Header-People Forum , Info-Nets distribution , Ken Rossman Subject: EDU problems in Bitnet. Phase-Of-The-Moon: NM+6D.18H.27M.33S. In-Reply-To: Msg of Sun 17 Nov 85 23:40 O from Doron Shikmoni No matter what direction is taken, significant rewriting of some parts of BITNET software will be required. That's life. Maybe we can set you on a direction that has proven useful for us. Conceptually the gateway responsibility issue is not new. Most of us have lived with the use of a % hack for years. My header is officially sepearated into "jsol%bucs20%bostonu.csnet"@"csnet-relay.arpa", abstractly: local-part@network-part. What is in the "network-part" must conform to the network standards, and what is in the "local-part" is open to negotiation (on a host by host basis). It is within the scope of the gateway to modify the headers to conform to each networks' protocols. The gateway adds or removes its name from the address and changes the last % to an @ (or removes the first @ leaving only one). This is considered messy, because it requires the gateway to parse the headers, nonetheless it is practical for the present. This will require changing the mail software not to use % as an indicator that the address should go to WISCVM. The software will have to parse the line and send the mail to the host indicated. Strictly speaking, this is probably the best you can do until someone comes along with a brilliant idea for a centralized name protocol (i.e. domains or something). Note: If using % is too complicated, you can use some other character(?) as the indicator for CCNET. Didn't mean to scorch you. Sorry. --JSol  Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 19 Nov 85 10:59:36 EST Received: from bostonu by csnet-relay.csnet id ad01544; 19 Nov 85 10:43 EST Received: by bu-cs.ARPA (4.12/4.7) id AA29203; Tue, 19 Nov 85 10:20:38 est Date: Tue, 19 Nov 85 10:20:38 est From: Jon Solomon Apparently-To: header-people@Mit-mc Okay, I still claim that BITNET should increase its awareness of mail service, but you're right. Intelligent protocols need not take over the world. Then who draws the line? The Internet community can not stand having non replyable mail messges either. The only reason your mail gets transmuted from "user@HOST" to "User%HOST.BITNET@WISCVM" is that Internet community insists on it so its users can reply to mail. But don't point the finger of blame on the Internet, or on the CCNET for that matter. CCNET should be free to use whatever names it wants to, separate from the issue of whether BITNET should use domains (if you want to discuss that, I have a ton of arguments for that as well...). Anyway -- Our mail protocols allow for a "local part" and a "domain part". Domain is a misnomer here, used to imply that the domain system was on its way... The local part has been used for *years* as a way of doing forwarding across network boundaries. Some people don't like the use of the %, or the .(csnet), or the !(uucp), or the choose-your-character, so it was never written into the spec. The concept is simple. The domain part is the networks responsibility, and the local part is the host's. BITNET seems to think that addresses that contain a % are *just* Internet hosts. Fine. No problem here. The fact that it also thinks that hosts ending in .EDU are also Internet sites is both conflictory and unsightly because it implies a policy that BITNET has no control over. The key issue here is that gateways have a special responsibility to insure the replyability of their messages. Whatever policy is adopted to control this must allow the gateways the ability to manipulate the addresses, this includes providing the gateways with addresses that don't need to be modified, which is preferred. The FACT is that BITNET seems to believe that the repliability of each of its messages is the responsibility of the mail user interface. This can (as we Internet folk have found out) lead to very complicated user interfaces which don't keep up with changing times. I think BITNET is trying to answer the same question ARPA is trying to answer, the fact that at the moment, we need to know alot more about a user's location than we should need to. The telephone system *nationally* is quite simple, 3 digits for an area code, and 7 for a telephone number. There is some DDD number meaning dial long distance (usually 1 - which happens to be the country code for the United States), and some number meaning get the operator, some special code for directory assistance. The operator can give you the area code, 1-(area-code)-555-1212 can get you the person's number (for a small fee). Simple. Really? AT&T Spent MILLIONS of dollers educating the public on how to use the national phone system. How many of us (not me...) were around when you could pick up your phone and tell the operator to "Hi mabel, let me talk to mary..." and Mabel, being the nosey operator she was, knew that Mary was over at Tom's house making nookie... Those days are long gone... Why did AT&T spend all that money, because it was too expensive to maintain all those operators. The concepts are the same almost everywhere there is telephone service, but the names have been changed to protect the innocent. If you want to make an International call from any point to any other point you need to know *alot* of information. In some countries, you need the City code, the Routing code, and the telephone number, which are all not the same length. You also need to know the access number to get international calling (011 here). That's sort of like a gateway. Interestingly enough, the only thing that is mutually agreed upon between the countries is that telephone numbers are NUMBERS, and that they can be translated into any language. The fact that US numbers can have letters in them is merely a local convention. The telephone switching system knows nothing about them. How you "specify" them is up to you (some people like using hyphens some don't... e.g. 201 555 2368, (201) 555 2368, 201-555-2368, (201) 555-2368), but you dial them into the telephone as a sequence of numbers (where oh where is the "hyphen key on the telepone...") Some amount of education is necessary. Similarly, we can specify that user names are alphabetical characters translatable into any language (well abstractly at least). How we specify them is up to us, but there must be software in the gateway which knows how to route the information. The fact is, the Internet has always had multiple gateways. Back in the NCP days, the BBN-NET (an NCP clone of the ARPANET for internal BBN use) had a gateway (in fact two) at BBN-UNIX (and BBNA, I believe). They solved the gateway problem by registering every single user in the community as an address on BBN-UNIX. Mail to "user@BBN-UNIX" was all you needed to know. Similarly they changed their addressing so that every message sent out had "user@BBN-UNIX" as their address. While this helped the ARPANET people keep in contact with the BBN people, it quickly swamped BBN-UNIX with "BBN-NET Internal traffic" because they chose to implement it in the local mail software rather than in the gateway. MIT-MC, Rutgers.ARPA, USC-ECL, Stanford, the University of Texas, and a host of other Internet sites have used the % convention to forward mail between networks which were not connectable to the ARPANET (now the Internet). The MIT-Chaosnet is *still* using MIT-MC (and a host of other MIT computers which reside on both networks), to communicate with the Internet. Host names are transmuted by the software on the various gateways (at least most of the time...) It has normally been required that people know what gateway they need to forward through or abstractly know what network they need to send to). Some networks have more than one gateway to the Internet, that information is useful to someone planning a route for mail, (I'm thinking of UUCP, since they are geographically centered. (Mail for Boston UUCP sites might go through MIT-EDDIE.MIT.EDU, mail for DC sites might go through SEISMO.CSS.GOV, etc. etc., let's not mention Berkeley... oops, I mentionned it). There are basically two problems being addressed: 1) How to route mail through a gateway so that it is replyable, and 2) how to recognize which gateway to send mail to given a host name. Solving one does not imply solving the other. The problem with simple software is that it does not take into account the abstractions involved. Trying to solve them both using the same mechanism is not what you had intended, I hope. Solving the host/gateway problem has also been done, and it has in fact used the . convention. MIT-OZ.MIT-CHAOS, for example. This is known only to a segment of the population (but technically speaking it can be taught to most of the population) of the Internet. While it was a good idea, it still required the maintainence of host tables on each host for all the networks involved. If you think keeping a table of the Internet hosts is hard, try to keep track of all Internet, CSNET, CCNET, BITNET, MAILNET, UUCPNET, *everything* and keep it up to date. Every time a user cannot send mail using this strategy, we will ask ourselves why we are using it. Name servers, *currently* only work for hosts directly connected to the network involved because they are dependent on the protocols of the network. BITNET is free to go and create a name service system, but that will only be useful to BITNET sites. Users on the Internet will still have to rely on the "mail it to WISCVM and see if WISCVM likes it" strategy. This is incomplete, and still requires that the users on the Internet know that WISCVM is the BITNET gateway. Most of us manually type in the forwarding path. I still don't have any reasonable way of finding out what your address is, but that's not generally the problem. I still have to know what network you are on. Two people trying to find out how to send mail to each other (with the help of their mail guru's) can usually figure out a path. Sometimes sending mail to something like INFO-NETS is a good possibility. There is a "net.path" or something on USENET for their network as well. Why not change sendgate so that it does this: $ sendgate File: Foo.foo;1 Address: JSOL%BUCS20%BOSTONU.CSNET%CSNET-RELAY.ARPA@WISCVM [Message will be PUNCHED to SMTPUSER at WISCVM] Fix the header so that the address is JSOL%BUCS20%BOSTONU.CSNET@CSNET-RELAY.ARPA and send it to WISCVM. You will also need to change WISCVM, to remove the @CSNET-RELAY and change the last % in the line to an @ and ship it off to CSNET-RELAY. CSNET-RELAY will do the same, and lo' and behold the message gets to me. The general message is that unless everybody adopts the same mail addressing scheme (e.g. domains), you can't get around the fact that you need to know *more* than the users name and his host (such as network, gateway, and forwarding protocol) to send him mail. Sendgate tries to solve this problem, but doesn't completely address it. A possible solution is to use the telephone networks philosophy of intelligent switches connected to intelligent "gateways" (toll centers if you please). Have the gateways and the user processes mangle the addresses so that they are replyable. I would still like to be able to use sendgate to mail to more than one person. While it is possible for me to mail the message more than once, it is not possible for one of my recipients to automatically generate a reply to that message which will go to all recipients. BITNET: Welcome to the world of networking. It is truly an enjoyable place to be.  Received: from MIT-SLOAN.MIT.EDU by MIT-MC.ARPA 19 Nov 85 18:23:13 EST Subject: Please remove, Please remove To: header-people-incoming@MIT-SLOAN.MIT.EDU, header-people@mit-mc.ARPA From: stokes%cmc.cdn%ubc.csnet@CSNET-RELAY.ARPA Sender: Date: Mon, 18 Nov 85 06:08:21 pst, 18 Nov 85 16:04  Received: from sri-spam.arpa by MIT-MC.ARPA 23 Nov 85 14:00:31 EST Received: by sri-spam.arpa (5.4/4.16) id AA22973; Sat, 23 Nov 85 10:56:57 PST Date: Sat, 23 Nov 85 10:56:57 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8511231856.AA22973@sri-spam.arpa> To: header-people@mc Subject: Re: .US domain and why isn't it the top level domain This would not be accomplishable with certain registries, such as CSNET, which fall into multiple countries. CSNET would have to divide itself into subdomains of .US or .CAN or whatever other countries CSNET has hosts in, and CSNET could no longer be a subdomain of any country, lest we have these types of problems waterloo.csnet.can csnet-sh.csnet.us the tree shouldn't be allowed to look like can us . . csnet . . csnet-sh waterloo Perhaps this is allowed in the spec, but I don't think this is what was desired, to see domains registering under multiple top-level domains. It would be a better solution to allow registries which have international bounaries to register the countries underneath them, and the hosts afterwards, so waterloo.can.csnet and csnet-sh.us.csnet would be more acceptible and in keeping with a rooted tree structure for domains, but I don't know if this is what is desired. Even better still, just throw .csnet out of the picture, and register former CSNET hosts as host.country (for those hosts which do not wish to fall into .edu, .com, or .org) and have the appropriate nameservers resolve those names to actual CSNET hosts, without making any explicit references to a network known as CSNET. --gregbo  Received: from Xerox.ARPA by MIT-MC.ARPA 23 Nov 85 22:56:53 EST Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 85 19:53:07 PST Date: 23 Nov 85 19:52 PST From: Lovstrand.pa@Xerox.ARPA Subject: Re: .US domain and why isn't it the top level domain In-reply-to: gds@sri-spam.ARPA (Greg Skinner)'s message of Sat, 23 Nov 85 10:56:57 PST To: gds@sri-spam.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <851123-195307-1856@Xerox> I'm sorry, but I could no longer hold myself... @Begin Flame Why on earth must the domain world be divided into geographical boundaries XOR .edu/.com/.org/etc XOR physical networks XOR whatever categorization? RFC822 (this magic paper) says nothing of how to divide the world; let's keep it that way! Let any reasonable organization (large enough, responsible enough, etc.) register itself as a top level domain. This might leave us with .us AND .edu AND .csnet AND .mhs, etc., but what's wrong with that? Wasn't the domain system supposed to become a tool with which we would be able to manage the rising addressing problems of the ol' flat ARPAnet domain? Instead, it seems like it is being used as a medium for expressing each flamers personal opinion about What The World Really Looks Like (or Should Look Like). Well, the "World" isn't homogeneous and will never so be. No single partitioning scheme will ever hold; it'll just be a barrier instead. @End Flame Seriously, I think that Einar Stefferud's [16 Nov 85] attempt to summarize the domain discussion is by far one of the best things said in this debate. Humbly, --Lennart  Received: from WISCVM.ARPA by MIT-MC.ARPA 24 Nov 85 03:13:54 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/24/85 at 02:10:26 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 8114; Sun, 24 Nov 85 10:07:42 O Date: Sun, 24 Nov 1985 09:32 O From: Henry Nussbacher Subject: .US as an upper level domain To: Let us just look at the facts and come to some conclusion. 1) Europe and the rest of the world will be using 2 letter country codes as their upper level domains and something known as "Administrartion Domain Name" as their 2nd level qualifier. 2) Some domains currently in existence span many countries. Now let us look a little down the road (say, 3 years): X400 and RFC822/920 have a number of gateways in existence. A piece of mail arrives from user@seismo.css.gov and is destined for someplace in X400-land. Do you know what the gateway will end up doing? It will add in a .US after gov so the people in x400-land will know which gateway to send their mail back to. They will not recognize gov and edu and org and all the other upper level domains that Arpanet has decided on. Let us look at some international mailing examples: 1) Telephone: Whereever you are in the world (and you have direct dialing) and you want to call another country, you specify 4 numbers: a - a number(s) to get the internation exchange b - some number or numbers to specify the country code c - some number or numbers to spcify the area within the country d - the actual number you are calling Just imagine if country XYZZY said we wish our politicians to have a seperate b-number different from our country code since that is the way we like it and since we have a very valid technical need for it. b) Mail: Whenever you send postal mail overseas, you have to specify a country at the bottom of the envelope. Not the person's work organization - no matter how big or important it may be. Europe and America have been at odds on many standards and all that has resulted from it is nothing! American TV's cannot be plugged into a German outlet and a French wrench doesn't do much good on an American bicycle. Here we have a chance to start something new and have everyone agree on an international standard. Multinational domains (like Csnet and Bitnet) will have to learn to live with upper level addresses like csnet.US or bitnet.IL. Let's not blow it now and make the same mistakes all over again. Hank  Received: from WISCVM.ARPA by MIT-MC.ARPA 24 Nov 85 05:52:31 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/24/85 at 04:49:01 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 9610; Sun, 24 Nov 85 12:48:02 O Resent-Date: Sun, 24 Nov 1985 12:42 O Resent-From: Henry Nussbacher Resent-To: For your viewing pleasure... Received: from MIT-MC.ARPA by wiscvm.arpa on 11/24/85 at 03:57:34 CST Received: from ADA-VAX by MIT-MC.ARPA 24 Nov 85 05:00:52 EST Date: Sun 24 Nov 85 01:58:39-PST From: Pony Express Mailer at ADA-VAX Subject: Undeliverable message To: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA@MIT-MC Reply-To: Pony Express was unable to deliver mail to the following recipients: FINN @ USC-ISIF JKReynolds @ USC-ISIF Mockapetris @ USC-ISIF Reason for failure is: Unable to connect to host usc-isif Pony Express will continue trying to deliver your message for 70 more hours. The first 10 lines of the undelivered message follow: ---------------------------------------- Received: from MIT-MC.ARPA by ADA-VAX via SMTP with TCP; Sun 24 Nov 85 00:55:01-PST Received: from WISCVM.ARPA by MIT-MC.ARPA 24 Nov 85 03:13:54 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/24/85 at 02:10:26 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 8114; Sun, 24 Nov 85 10:07:42 O Date: Sun, 24 Nov 1985 09:32 O From: Henry Nussbacher Subject: .US as an upper level domain To: -------  Received: from sri-spam.arpa by MIT-MC.ARPA 24 Nov 85 14:29:04 EST Received: by sri-spam.arpa (5.4/4.16) id AA26510; Sun, 24 Nov 85 11:25:34 PST Date: Sun, 24 Nov 85 11:25:34 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8511241925.AA26510@sri-spam.arpa> To: header-people@mc In-Reply-To: Lovstrand.pa@Xerox.ARPA's message of 23 Nov 85 19:52 PST Subject: Re: .US domain and why isn't it the top level domain Actually, RFC822 says nothing about how to divide the world because it's purpose was not to define a structure for the domain system, but a structure for the content and form of an ARPA Internet mail message. Secondly, it was the purpose of creating .org, .com, etc. for the purposes of subdividing the ARPA Internet. Registries external to the ARPA Internet (such as .uk, .csnet, etc.) are permitted to register as top-level domains for the purposes of mail addressing outside the ARPA Internet, but there's nothing that says that in networks outside the ARPA Internet the domain naming scheme can't be country based (or even network based), as long as the appropriate transformations are done to mail messages at the mail bridges between the ARPA Internet and other networks or internetworks. --gregbo  Received: from ucbarpa by MIT-MC.ARPA 24 Nov 85 16:06:55 EST Received: by ucbarpa (5.31/1.7) id AA00486; Sun, 24 Nov 85 13:04:20 PST Date: Sun, 24 Nov 85 13:04:20 PST From: jordan@ucbarpa.BERKELEY.EDU (Jordan Hayes) Message-Id: <8511242104.AA00486@ucbarpa> To: header-people@mit-mc.arpa Subject: Re: CSNET ... Hmmm... I still don't understand why a host like buffalo.cs.net couldn't be something like buffalo.suny.edu and why someone like stony-brook couldn't provide name-service for a suny domain and include an MF for buffalo pointing to the csnet-relay and an MF for, oh, say, binghampton pointing to the bitnet relay, etc... am I missing something, or shouldn't the hosts with the network connections provide this service for those less fortunate? Things would look helluvbetter. Are you listening stony-brook? /jordan ps: sorry to rag about a personal beef ... I have an account on buffalo.csnet ... my home town, doncha know ...  Received: from mordred.Purdue.EDU by MIT-MC.ARPA 25 Nov 85 09:10:56 EST Message-Id: <8511251404.AA01232@mordred.Purdue.EDU> Received: by mordred.Purdue.EDU; Mon, 25 Nov 85 09:04:37 EST To: gds@sri-spam.arpa (Greg Skinner) Cc: header-people@mit-mc.arpa Subject: Re: .US domain and why isn't it the top level domain Phase-Of-The-Moon: Waxing Gibbous (97% of Full) In-Reply-To: Your message of Sun, 24 Nov 85 11:25:34 PST. <8511241925.AA26510@sri-spam.arpa> Date: 25 Nov 85 09:04:30 EST (Mon) From: "John A. Dilley" Is there something fundamental I'm missing? If we want to have these .org, .com, .edu, .mil, .etc domains, and Europe and the rest of the world are set up with countrys at the top level, why don't we just make the above domains second level under the .us domain? If we're *in* this domain, we don't even have to say .us, thus making it look like these are at the top level. For those outside the .us domain, they'll have to specify .mil.us or something. Which makes a lot of sense; why can't there be a .mil.fr? Or .com.UK? Ideas? -- jad -- John A Dilley ----------  Received: from harvard.HARVARD.EDU by MIT-MC.ARPA 25 Nov 85 12:28:12 EST Date: Mon, 25 Nov 85 12:27:42 EST From: kevin@harvard.HARVARD.EDU (Kevin Crowston) To: header-people@mit-mc.arpa Subject: Correct header for "%" hack I'm trying to write an SMTP server for our local network and have a question about return addresses. The machine that hosts the SMTP server is registered with the local domain server, but not with the NIC, (a situation that is unlikely to change in the near future due to some political problems here). We can receive mail using the "%" hack, by sending it first to a local machine that is registered with the NIC and which does the domain trick and sends it on to us. My question is, what should I put in the headers of our outgoing mail? Currently I use person%localhost@arpahost in both the header and in the SMTP dialogue (ie. I send MAIL FROM:). Is this okay? It seems to give slightly weird headers in the received mail; I get both a From: line and a From_: line, the first of which lists the arpa host twice (I think an example will be clearest: From :kevin%MIT-SLOAN.MIT.EDU@MIT-MC.ARPA@MIT-MC.ARPA Mon Nov 25 12:19:42 1985 Received: from MIT-SLOAN.MIT.EDU by MIT-MC.ARPA 25 Nov 85 12:19:32 EST Received: from MITMS1-E52: by MIT-SLOAN.MIT.EDU; 25-Nov-85 12:19:32 Message-Id: <531756324.262448728@MIT-SLOAN.MIT.EDU> From: kevin%MIT-SLOAN.MIT.EDU@MIT-MC.ARPA To: kevin@harvard.ARPA Subject: This is a test Sender: Date: 25 Nov 85 12:18 Status: R This is a brief example. Kevin Any suggestions about the "right" thing to do will be greatly appreciated. Kevin Crowston MIT Sloan School of Management kevin%mit-sloan.mit.edu@mit-mc.arpa kevin@harvard.arpa  Received: from CSNET-SH.ARPA by MIT-MC.ARPA 25 Nov 85 16:49:32 EST To: Jordan Hayes cc: header-people@mit-mc.ARPA, cic@CSNET-SH.ARPA Subject: Re: CSNET ... In-reply-to: Message from Jordan Hayes <8511242104.AA00486@ucbarpa> Date: 25 Nov 85 16:42:34 EST (Mon) From: Dennis Rockwell From: Jordan Hayes Date: Sun, 24 Nov 85 13:04:20 PST Subject: Re: CSNET ... Hmmm... I still don't understand why a host like buffalo.cs.net couldn't be something like buffalo.suny.edu and why someone like stony-brook couldn't provide name-service for a suny domain and include an MF for buffalo pointing to the csnet-relay and an MF [ ... ] The CS.NET domain will never (and does not now) contain any hosts other than those here at the CSNET CIC; we decided awhile ago not to try to perpetuate the .CSNET hack (which is really what all these .UUCP and .BITNET et.al. "domains" are) and instead offer to advertise our members with MF records as suggested above. We are using CS.NET now only because RELAY.CSNET.BBN.COM lacked that instant recognizability that we now have (RELAY.CS.NET is at least close to, and intuitively associated with, CSNET-RELAY.ARPA). Whether buffalo.csnet becomes buffalo.suny.edu or something else similar is pretty much up to them; however, the NIC has yet to answer our query about whether they could accept requests for something like 100 second-level .EDU domains. We're even ready, in principle, to be the primary or secondary domain server for most of our members (SUNY Stony Brook and SH.CS.NET backing each other up is the right approach, by the way). We're ready to do it, for the most part. If only BIND didn't occasionally decide that the rest of the world had gone away.... Dennis Rockwell CSNET Technical Staff  Received: from MIT-SLOAN.MIT.EDU by MIT-MC.ARPA 25 Nov 85 17:39:01 EST Received: from MITMS1-E52: by MIT-SLOAN.MIT.EDU; 25-Nov-85 17:37:52 Message-id: <531775424.1940714@MIT-SLOAN.MIT.EDU> Subject: Correct header for "%" hack, Correct header for "%" hack To: header-people-incoming%MIT-SLOAN.MIT.EDU@MIT-MC.ARPA, header-people@mit-mc.ARPA From: kevin@harvard.HARVARD.EDU, kevin Sender: Date: Mon, 25 Nov 85 12:27:42 EST, 25 Nov 85 13:18 I'm trying to write an SMTP server for our local network and have a question about return addresses. The machine that hosts the SMTP server is registered with the local domain server, but not with the NIC, (a situation that is unlikely to change in the near future due to some political problems here). We can receive mail using the "%" hack, by sending it first to a local machine that is registered with the NIC and which does the domain trick and sends it on to us. My question is, what should I put in the headers of our outgoing mail? Currently I use person%localhost@arpahost in both the header and in the SMTP dialogue (ie. I send MAIL FROM:). Is this okay? It seems to give slightly weird headers in the received mail; I get both a From: line and a From_: line, the first of which lists the arpa host twice (I think an example will be clearest: From :kevin%MIT-SLOAN.MIT.EDU@MIT-MC.ARPA@MIT-MC.ARPA Mon Nov 25 12:19:42 1985 Received: from MIT-SLOAN.MIT.EDU by MIT-MC.ARPA 25 Nov 85 12:19:32 EST Received: from MITMS1-E52: by MIT-SLOAN.MIT.EDU; 25-Nov-85 12:19:32 Message-Id: <531756324.262448728@MIT-SLOAN.MIT.EDU> From: kevin%MIT-SLOAN.MIT.EDU@MIT-MC.ARPA To: kevin@harvard.ARPA Subject: This is a test Sender: Date: 25 Nov 85 12:18 Status: R This is a brief example. Kevin Any suggestions about the "right" thing to do will be greatly appreciated. Kevin Crowston MIT Sloan School of Management kevin%mit-sloan.mit.edu@mit-mc.arpa kevin@harvard.arpa  Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA 26 Nov 85 15:09:07 EST Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 26 NOV 1985 15:04:03 EST Date: Tue, 26 Nov 85 11:46 PST From: Dave Platt To: Header-People Subject: Headers using % hack References: Kevin Crowston's questions re % hack Random-Quote: To his dog, every man is a Napoleon. Hence the popularity of dogs. ALDOUS HUXLEY I have an implementation similar in some respects to the one that Kevin Crowston mentioned. My system (a Honeywell CP-6 mainframe) talks to the universe via CISL (aka CISL-SERVICE-MULTICS.ARPA). We're known to CISL as "LADC" (also as HIS-LA-CP6.ARPA, but I don't like to use that name since we are NOT connected to the ARPANET itself). I use a hybrid approach: - In the "From:" field in the RFC822 header, my SMTP mailer uses the construct "persons-name%LADC@CISL-SERVICE-MULTICS.ARPA". Anyone on the ARPANET can respond to this address (unless their mailer has a serious local limitation on address length) because it points to a registered ARPA host (CISL). - In the RFC 821 (SMTP) conversation with CISL, the mailer names itself "LADC". For example, HELO LADC MAIL FROM: This results in the eventual creation of a return-path which looks (to the destination host) like: MAIL FROM:<@CISL-SERVICE-MULTICS.ARPA:Dave-Platt@LADC> According to my reading of the SMTP spec, this is quite legitimate and results in an address that any RFC821/822-compliant mailer should be able to use as a return-address, should it desire to do so. If the mailer tries to "short cut" the delivery (bypassing CISL and trying for LADC directly) it won't work, of course. SMTP doesn't seem to require that the original sender identify itself (in the HELO and MAIL FROM commands) with a full ARPANET-usable %-hack, but only with a hostname that's recognized by the host it's speaking with. The RFC822 header seen by the receiver generally looks like: Received: from CISL-SERVICE-MULTICS by (whomever) (date) (time) Received: from LADC by CISL-SERVICE-MULTICS.ARPA (date) (time) From: Dave Platt Return-path: <@CISL-SERVICE-MULTICS.ARPA:Dave-Platt@LADC> Naturally, this varies with the characteristics of the receiving mailer(s).  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 26 Nov 85 16:50:45 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2679342081717539@MIT-MULTICS.ARPA>; 26 Nov 1985 16:41:21 est Date: 26 Nov 85 06:45 +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: .US domain and why isn't it the top level domain Message-ID: <137364@QZCOM> In-Reply-To: <8511231856.AA22973@sri-spam.arpa> The situation here in Europe is that we mostly have not diveded our networks into discipline specific ones, therefore no need for introducing things like "CSNET". But, stepping out of the academic community, most EU countries have their national academic projects (Sunet, Janet, DFN, etc.) and - since we all "go ISO" and public lines (X.25) - one might really ask why! There IS no need from an addressing/routing point of view, but it is - at present - rather convenient from the NAMING pov. (In Europe, that is.) Your last suggestion ("just throw .csnet out of the picture, and register former CSNET hosts as host.country") is good. And it will still be possible to create things like CSNET using a forthcoming directory standard and let CSNET be the name of a group containing the relavant names of affiliated institutions (worldwide) - or their "host names" for the time being. Tommy  Received: from WISCVM.ARPA by MIT-MC.ARPA 8 Dec 85 08:16:14 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 12/08/85 at 07:13:37 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6543; Sun, 08 Dec 85 15:13:28 O Date: Sun, 8 Dec 1985 15:06 O From: Henry Nussbacher Subject: Need for new field in RFC and MHS standards To: , , Does a field exist in the MHS specification to specify whether a program has created the mail? Allow me to give an example: More and more programs (call it server machines or deamons or whathaveyou) are learning to process RFC822 (RFC920) mail and to perform some function for the user (Database search, batch FTP request, auto-reply, gateways, etc.). Another feature becoming more common is for mail systems to return bounced mail to the original user for various reasons (userid no longer valid, disk quota used up, unable to connect to host, etc.) We have all seen these bounced mail files. We read them and can discern right away that the mail arrived via program generation and not via a human being. Scenerio: user@Uclamvs.Bitnet sends mail to a server/deamon. The server/daemon processes the request and sends some output back to the user. For some reason the mail software at Uclamvs cannot deliver the mail and rejects it back to the sender. The mailer builds a From:, To: and Subject: line in most cases and then imbeds the rejected mail inside its own envelope. The mail is sent back to the server/daemon which doesn't know that the incoming mail was computer generated and attempts a reply. In most cases the syntax/format will not be valid and the server/daemon will generate a piece of mail giving some error message back to the mail system at Uclamvs. Infinite network loop. Currently, I have a table built into my software; if mail arrives with a character string of Daemon, Mailer, Mailman, Postmast, System, Smtpuser (just to name a few of those I have observed) then my software throws the mail into a wastebasket for human processing at a later date. But quite often, some new node in some network comes online and decides to send out it's mailer generated mail with a From: line that is foreign to my table. Network loop - until I spot it and add it in. Users are starting to write programs/daemons to run on their ids while they are away for vacation that sends out a predefined piece of mail saying that they are on vacation until mm/dd/yy but don't worry, your mail has been logged and will be read when they return. What is needed is an additional field in RFC822 and a field in MHS that indicates that the mail was computer generated rather than human generated and therefore do not reply to it. Example: From: Network Mailer Auto: MAILER where Auto: could be one of the following values: MAILER REPLY PROGRAM or anything else people could think of. In Kille's chapter 2.3 he discusses Non-Delivery Notification and Prevention of Non-Delivery Notification. If these fields are standard X.400 then perhaps it is just the Internet that needs to come up with a new field. Comments encouraged. Hank  Received: from WISCVM.ARPA by MIT-MC.ARPA 8 Dec 85 19:34:50 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.ARPA on 12/08/85 at 18:32:14 CST Date: 8-Dec-1985 19.25.54. EST From: JCURRAN%UMASS.BITNET@WISCVM.ARPA To: HEADER-PEOPLE@MIT-MC.ARPA Subject: Rcf822 extension fields Are there plans for standard extension sets to the rcf822 standard?? So far, I've seen at least 8 "extension-fields" which have been quite useful, and none of which include the user-defined extension prefix of "X-".. Examples are VSHANK%WEIZMANN.bitnet's 'auto' field, our own "end-date" field.. If anyone knows of a extension to rcf822 in the works, speak.. John  Received: from hplabsd by MIT-MC.ARPA 8 Dec 85 20:27:02 EST Received: by hplabsd ; Sun, 8 Dec 85 17:22:06 pst To: veeger!hpcnof!hplabs!Header-People@MIT-MC.ARPA Date: Sun, 8 Dec 85 17:23:30 MST From: hpcnou!dat@hplabsd (Dave Taylor) Subject: Thoughts on the new field request Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3] Henry Nussbacher has hit the proverbial nail square on the head! I firmly agree that we do indeed need a specific header added to the list of headers that deals with the problem of human generated versus software generated mail! Henry suggests the following: > Auto: MAILER > > where Auto: could be one of the following values: > MAILER > REPLY > PROGRAM I personally opt for the following, as being more in the spirit of the other existing headers: Generated-By: can be any of: Autoreply Daemon [] Gateway [] Program If this field is present at all, it means that the mail was generated by some sort of software system - any information contained within is for further reference... If NOT present, it means that the associated message is in fact a valid "human" message and can be replied to, or what-have-you. Perhaps in the future mailers will actually be able to treat automated mail differently (hmmm...) Examples: Mail generated by my autoreply program could contain: Generated-By: Autoreply Daemon [HP Autoreply, version 1.0] Mail bouncing off the CSNET gateway (say) could be something like: Generated-By: ARPA->CSNET Gateway [MMDF transport 4.5.a @ ucb] and, finally, mail from some program or 'tother could be: Generated-By: Program "doctor" [see doctor(6)] I welcome thoughts, comments, reactions, and so on. Good stuff, Henry!! -- Dave Taylor Hewlett Packard, Colorado Networks Op. at hpcnou!dat@HPLABS  Received: from CIT-Hamlet.ARPA by MIT-MC.ARPA 8 Dec 85 22:38:45 EST Date: Sun, 8 Dec 85 19:18:19 PST From: ken@CIT-Hamlet.ARPA Message-Id: <851208191819.002@Hamlet> Subject: Re: new rfc822 header To: header-people@mit-mc.arpa Before we jump and add something to RFC822 lets not forget that you can solve the "mail loop" problem (at least in an SMTP or BSMTP system) by specifing a null MAIL FROM line, i.e. MAIL FROM:<>. Ken Adelman Caltech  Received: from USC-ECL.ARPA by MIT-MC.ARPA 9 Dec 85 02:20:45 EST Received: From nrtc-gremlin by NRTC id a003630 ;8 Dec 85 22:48 PST To: Henry Nussbacher cc: header-people@MIT-MC.ARPA reply-to: header-people@MIT-MC.ARPA Subject: Re: Need for new field in RFC and MHS standards In-reply-to: Your message of Sun, 8 Dec 1985 15:06 O. Date: Sun, 08 Dec 85 22:47:49 -0800 Message-ID: <286.502958869@nrtc> From: Marshall Rose Via: Nrtc; 08 Dec 85 23:13:04 In addition, MHS has the notion of a protocol field which says what type of protocol is being used. The only defined value is "P2" which stands for InterPersonalMessage. Other values will probably be defined in the future. In the standard 821 world, there is NO need for what you suggest. The message's envelope contains (among other things) a return-address. What programs which generate messages should do (if they don't want to see a failure notice) is simply leave the return-address blank. This is understood to mean "don't tell me about it if it loses". /mtr  Received: from USC-ECL.ARPA by MIT-MC.ARPA 9 Dec 85 02:21:14 EST Received: From nrtc-gremlin by NRTC id a003639 ;8 Dec 85 22:55 PST To: JCURRAN%UMASS.BITNET@WISCVM.WISC.EDU cc: HEADER-PEOPLE@MIT-MC.ARPA Reply-to: HEADER-PEOPLE@MIT-MC.ARPA Subject: Re: Rcf822 extension fields In-reply-to: Your message of 8-Dec-1985 19.25.54. EST. Date: Sun, 08 Dec 85 22:55:21 -0800 Message-ID: <286.502959321@nrtc> From: Marshall Rose Via: Nrtc; 08 Dec 85 23:13:25 Header fields starting with "X-" are SPECIFICALLY prohbitited from being used in an official capacity--they are USER-extensibility fields. Please find the mailsystem maintainer on your system who is responsible for the date field your message had. Please threaten them with great harm. Use only 822-conformant dates in your messages. The date: field of 8-Dec-1985 19.25.54. EST in your message defines description. Thank you, /mtr  Received: from WISCVM.ARPA by MIT-MC.ARPA 9 Dec 85 10:36:55 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.ARPA on 12/09/85 at 09:34:20 CST Date: 9-Dec-1985 04.26.39. EST From: JCURRAN%UMASS.BITNET@WISCVM.ARPA To: HEADER-PEOPLE@MIT-MC.ARPA Subject: generated-by fields In keeping with the terminology of rfc822, the "generated-by" field could be simply the "agent" field; which would express the nature of the sender (person, system, or process): Sender: Autoreply%umass.bitnet@wiscvm.arpa Agent: process The only difficulties with this is that the "sender" and/or "from" fields must be valid addresses by rfc822, and not all sites allow servers to recieve mail; and also that any additional comments on the sender (such as version, etc) would have to be included as comments (). - John Curran - Umass/Amherst  Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 9 Dec 85 21:20:58 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2680481589959601@MIT-MULTICS.ARPA>; 09 Dec 1985 21:13:09 est Date: 08 Dec 85 23:48 +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, MHS_implementation_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, MHS_implementation_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , mhs_implementation@RSCH.WISC.EDU Subject: Need for new field in RFC and MHS standards Message-ID: <140033@QZCOM> In-Reply-To: <140022@QZCOM> <8512081313.AA29855@rsch.wisc.edu> Not only do we need a way to indicate WHO/WHAT has created a message, but also the TYPE of a NAME. Example: in X.400 the current definition of an O/R name cannot be used (properly) to refer to a distribution list (sending to it) or a distributor (after expansion). As for personal agents issuing On-Holiday messages I would like to have possibilities to adding things to a PersonalName, e.g. US.mumble.mumble.PersonalName.WatchDog or .FolderName which would allow easier mapping onto some well-known existing mail systems. Tommy  Received: from WISCVM.ARPA by MIT-MC.ARPA 10 Dec 85 00:25:34 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.ARPA on 12/09/85 at 23:22:53 CST Date: 9-Dec-1985 23.03.33. EST From: JCURRAN%UMASS.BITNET@WISCVM.ARPA To: HEADER-PEOPLE@MIT-MC.ARPA Subject: extension fields I have seen several user-extension fields that lack the "X-" prefix (making them simply extension-fields; subject to being redefined) in hopes that other sites might employ them. Since some extension fields (user or other) involved the processing of incoming mail, it only makes sense for a site which supports such fields to inform others so that the incoming mail it recieves may contain such information. If, for example, a mail system supported field yyyyy, how would/could it tell other mail system programmers about it? Is any agent maintaining a lists of'commonly used rfc822 extension fields? -- John Curran -- Umass/Amherst  Received: from WISCVM.ARPA by MIT-MC.ARPA 10 Dec 85 05:32:56 EST Received: from (MAILER)DBNGMD21.BITNET by WISCVM.ARPA on 12/10/85 at 04:29:37 CST Date: Tue, 10 Dec 85 11:26 CET To: , , From: Peter Sylvester +49 228 303245 Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Message from Hank. A comment to Hanks message: Scenerio: user@Uclamvs.Bitnet sends mail to a server/deamon. The server/daemon processes the request and sends some output back to the user. For some reason the mail software at Uclamvs cannot deliver the mail and rejects it back to the sender. The mailer builds a From:, To: and Subject: line in most cases and then imbeds the rejected mail inside its own envelope. The mail is sent back to the server/daemon which doesn't know that the incoming mail was computer generated and attempts a reply. In most cases the syntax/format will not be valid and the server/daemon will generate a piece of mail giving some error message back to the mail system at Uclamvs. Infinite network loop. Currently, I have a table built into my software; if mail arrives with a character string of Daemon, Mailer, Mailman, Postmast, System, Smtpuser (just to name a few of those I have observed) then my software throws the mail into a wastebasket for human processing at a later date. But quite often, some new node in some network comes online and decides to send out it's mailer generated mail with a From: line that is foreign to my table. Network loop - until I spot it and add it in. The describe scenario is not true from the design point: When the UCLAMAIL-mailer returns a message via the "RETURN TO SENDER" feature, it uses a from: address as POSTMAN. In the NJE header the Origin user is set to MAILER. When the second invalid message is return it gets to either MAILER or POSTMAN depending on what the server machine uses. Therefore no loop will occur if server machines are "replying" correctly. The error is that the UCLA-MAIL sets MAILER as NJE header. I will change that in my version: For a "RETURN-TO SENDER" message POSTMAN will be used in both fields. That problem also applies to VM-Mailers I guess. Hank: (please describe the LOOP situation in detail to ME.) Users are starting to write programs/daemons to run on their ids while they are away for vacation that sends out a predefined piece of mail saying that they are on vacation until mm/dd/yy but don't worry, your mail has been logged and will be read when they return. What is needed is an additional field in RFC822 and a field in MHS that indicates that the mail was computer generated rather than human generated and therefore do not reply to it. This problem cannot be cured by a new RFC822 fields. The EARN network server uses another approach. It keeps a log of invalid requests for any user. If a threshold is reached (like HOT IO ERRORS) no further requests are accepted from this user. The node manager of the users node has the ability to reset that state. For interactive REPLY-MESSAGES (Gone, will be back in...) there is a convention that they should start with an asterisk. SERVER machines should not react on messages with *. A good combination of SENDER/FROM-fields and NJE-header can help: I discovered a problem with some server machines that if a mailer is used, the server sends the reply to the MAILER and not to the user. I.e. it uses the NJE-headers in those cases. Two interpretation are possible: IF the server machine CLAIMS to use RFC822 it should respond to the FROM/REPLY-TO address. If the server is not able, it should reply to to the NJE sender and put itself as FROM: field into the message. If the MAILER does not claim to use RFC822, it is a problem of the sending MAILER. Many server use the NJE-origin userid field (display as user in a VM RDRLIST). In general VM-MAILER and and also the UCLA-Mail mailer set the NJE filename to the userid. In case of MAILER, these two fields are different. SERVER machines could either reject such messages or send it to any of the two userids. If it uses the SERVER userid the message will normally be put in the target servers box (=postman's box.) Kille's report only handle RFC822 mailers. The approach there is obvoiusly the right one. BUT: MOST SERVER machines DO NOT know anything about RFC822. Comments encouraged. Peter BTW: if the following addresses are "distribution list" or conferences, would anyone be so kind to add me?: , .. QUIT  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:30:52 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:20:56 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 11:47:04 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 11:44:51 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01150; Tue, 10 Dec 85 11:31:27+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:31:26 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:21:46 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 11:48:10 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 11:45:22 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01107; Tue, 10 Dec 85 11:21:48+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:50:42 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:33:27 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:18:32 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:16:14 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01297; Tue, 10 Dec 85 11:50:19+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:51:47 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:31:27 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:16:47 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:15:33 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01245; Tue, 10 Dec 85 11:48:08+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:53:14 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:32:28 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:17:53 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:15:49 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01276; Tue, 10 Dec 85 11:49:14+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:53:22 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:26:20 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 11:53:18 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 11:51:13 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01190; Tue, 10 Dec 85 11:44:33+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 07:15:05 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 07:06:28 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:46:29 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:44:42 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01515; Tue, 10 Dec 85 12:40:17+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 07:15:11 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 07:04:46 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:45:44 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:44:29 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01348; Tue, 10 Dec 85 12:13:47+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 12:41:41 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:20:30 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:12:26 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 17:00:58 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00721; Tue, 10 Dec 85 15:42:32+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 12:49:06 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:26:56 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 16:57:20 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 16:55:31 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00475; Tue, 10 Dec 85 14:46:22+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 12:50:48 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:31:22 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 16:58:40 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 16:56:19 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00515; Tue, 10 Dec 85 14:52:38+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:01:36 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:33:06 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:44:26 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 17:43:19 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01038; Tue, 10 Dec 85 16:54:14+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:01:51 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:33:59 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:45:05 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 17:43:54 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01350; Tue, 10 Dec 85 17:40:15+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:02:01 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:26:37 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:14:19 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 16:59:57 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00710; Tue, 10 Dec 85 15:41:27+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:02:14 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:23:20 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:13:20 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 16:57:31 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00542; Tue, 10 Dec 85 14:56:36+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:02:30 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:18:48 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:11:09 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 16:59:00 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00571; Tue, 10 Dec 85 15:03:19+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:02:47 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 12:16:11 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 17:10:21 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 17:01:53 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00732; Tue, 10 Dec 85 15:43:38+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:04:43 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 10:39:49 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 14:47:37 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 14:45:46 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00257; Tue, 10 Dec 85 14:04:04+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 14:05:09 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 10:40:04 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 14:48:17 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 14:46:12 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA00351; Tue, 10 Dec 85 14:36:20+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:27:20 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 17:03:11 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 21:46:48 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 21:45:42 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA02208; Tue, 10 Dec 85 21:40:14+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:09 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 16:57:29 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 21:45:31 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 21:44:06 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA02070; Tue, 10 Dec 85 20:43:41+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 16:56:41 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 21:44:45 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 21:43:54 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA02048; Tue, 10 Dec 85 20:42:18+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:29:52 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 17:01:05 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 21:46:02 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 21:44:30 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA02088; Tue, 10 Dec 85 20:44:51+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards In-Reply-To: Your message of 08 Dec 85 23:48 +0100. Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen I agree with Tommy that besides the identification of an automaton, which created the the message, there is a need for an identification of an automaton as receiver. I do think that this should not be mixed (as not is done currently with the From and To/Cc identifications. I do not agree with the proposal to mix it in the address. An address is a mailbox, which can (and is I think) handledd by some automaton on the receivers site. What the automaton on the receivers site actual should do is in the rest of the header. This means that the To/From-automaton identification carries a message for the automaton. Ie the identifications is just a keyword that the message is meant for the automaton. Foldering is already used: Fcc or Folder-cc keywords are know to me, but not in X.400. Sender automaton identification is not known to me.  Received: from CIT-Hamlet.ARPA by MIT-MC.ARPA 10 Dec 85 19:31:11 EST Date: Tue, 10 Dec 85 15:49:49 PST From: ken@CIT-Hamlet.ARPA Message-Id: <851210154949.003@Hamlet> Subject: help! To: header-people@mit-mc.arpa Is anyone besides our site getting infinite copies of Teus Hagen's message? If it helps anyone debug this problem the Received: line all show different date/time except for the first one: Return-path: <@MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV> Received: from MIT-MC.ARPA by CIT-Hamlet.ARPA with INTERNET ; Tue, 10 Dec 85 04:55:45 PST Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:50:42 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:33:27 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:18:32 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:16:14 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01297; Tue, 10 Dec 85 11:50:19+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> Return-path: <@MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV> Received: from MIT-MC.ARPA by CIT-Hamlet.ARPA with INTERNET ; Tue, 10 Dec 85 05:19:38 PST Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:51:47 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 06:31:27 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 12:16:47 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 12:15:33 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA01245; Tue, 10 Dec 85 11:48:08+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people ,  Received: from OFFICE-1.ARPA by MIT-MC.ARPA 10 Dec 85 21:17:40 EST Date: 10 Dec 85 21:01 EST From: Duane Stone / McDonnell Douglas / CSC-ASD Subject: Re: help! To: ken@CIT-Hamlet.ARPA Cc: header-people@mit-mc.arpa Message-ID: In-reply-to: <851210154949.003@Hamlet> Yes -- Office-1 has received a few dozen copies today. I've just been throwing my copies away away -- hoping someone else would discover the problem and turn off the tap. Header-people messages coming to Office-1 get redistributed around other Office machines and out to ONTYME mailboxes on Tymnet -- so if the repeats don't stop pretty soon, we'll have to turn off the mailbox on our end temporarily until things clear up. Stoney  Received: from seismo.CSS.GOV by MIT-MC.ARPA 11 Dec 85 01:00:44 EST Return-Path: Received: by seismo.CSS.GOV; Wed, 11 Dec 85 00:25:13 EST Date: Wed, 11 Dec 85 00:25:13 EST From: Rick Adams Message-Id: <8512110525.AA05485@seismo.CSS.GOV> To: header-people@mit-mc.arpa Subject: mail from ace!tues Cc: mhs_implementation@rsch.wisc.edu The mail is originating in Holland at machine ace. This makes it difficult to stop except from there. I have already removed over 50 more copies from the mail queues at seismo, so you've been lucky with "only" getting 25. I'm doing as much as I can, but the problem is "upsteam". ---rick  Received: from seismo.CSS.GOV by MIT-MC.ARPA 11 Dec 85 01:00:55 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 11 Dec 85 00:33:11 EST Received: by mcvax.UUCP; Wed, 11 Dec 85 03:05:25 +0100 (MET) Received: by mcvax.UUCP; Wed, 11 Dec 85 03:05:09 +0100 (MET) Received: by ace (4.40/1.10) with SMTP id AA03579; Wed, 11 Dec 85 02:51:35+0100 (MET) Organisation: ACE Associated Computer Experts bv. Amsterdam, The Netherlands. Phone: +31 20 262400 Telex: 11702 ace nl To: mit-multics.arpa!Tommy_Ericson__QZ@QZCOM.MAILNET, mit-multics.arpa!Header_People_mailing_lists@QZCOM.MAILNET, mit-multics.arpa!MHS_implementation_mailing_list@QZCOM.MAILNET, header-people , mhs_implementation@rsch.wisc.edu Subject: multiple mails from teus@ace.uucp Date: 11 Dec 85 02:51:31 N (Wed) Message-Id: <44.503113891@ace> From: Henk Hesselink My apologies for yesterday's flood of mails from our site. The problem was a fixed-size array for recipient addresses in the uucp uuxqt program (will they never learn ...). The long list of addresses in the original mail overflowed this, causing the mail to be sent without the spool files being removed. Henk Hesselink