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" <Harvey@HIS-PHOENIX-MULTICS.ARPA>
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" <Harvey@HIS-PHOENIX-MULTICS.ARPA>
Date:  Wed, 24 Jul 85 16:16 MST
From:  "Ronald B. Harvey" <Harvey%pco@CISL-SERVICE-MULTICS.ARPA>
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 <alt%sri-lanka@sri-tsc>
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 <alt%sri-lanka@sri-tsc>
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 <salex@rice.ARPA>
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 <alt%sri-lanka@sri-tsc> 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 <salex@rice.arpa>
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 <stef@uci-icsa>
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 <header-people@MIT-MC.ARPA>
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 <stokes%cmc.cdn%ubc.csnet@csnet-relay.arpa>
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 <wales@LOCUS.UCLA.EDU>
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: <mcb@lll-tis-b>
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 <albitz@Purdue.EDU>


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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.arpa>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <hpccc!mcgregor%hplabs.csnet@csnet-relay.ARPA>
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 <JSOL%BUCS20%bostonu.csnet@csnet-relay.arpa>
To: Scott McGregor <hpccc!mcgregor%hplabs.csnet@csnet-relay.arpa>
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 <hpccc!mcgregor%hplabs.csnet%csnet-relay.csnet at bu-cs>

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:

	<local-part>@RELAY-FOREIGN

This in turn could resolve to any of the following:

	<local-part>@RELAY-PATH-1
	<local-part>@RELAY-PATH-2
		.
		.
		.
	<local-part>@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
  <GRZ027%DBNGMD21.BITNET@WISCVM.ARPA>
To: Header People <header-people@mit-mc.ARPA>
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 <wales@LOCUS.UCLA.EDU>
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 <Crispin@SUMEX-AIM.ARPA>
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  <vshank%weizmann.BITNET@WISCVM.ARPA>
Subject:      RFC920 country codes
To:  <header-people@mit-mc.ARPA>

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 <COMSAT@MIT-MC.ARPA>
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 <stef@uci-icse>
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 <ZELLICH@SRI-NIC.ARPA>
	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 <Crispin@SUMEX-AIM.ARPA>
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 <jordan@ames.ARPA>
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 <Crispin@SUMEX-AIM.ARPA>
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 <Crispin@SUMEX-AIM.ARPA>
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 <Crispin@SUMEX-AIM.ARPA>'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 <Crispin@SUMEX-AIM.ARPA>
	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 <Crispin@SUMEX-AIM.ARPA>
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: <mcb@lll-tis-b>
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 <mcb@lll-tis-b>
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 <Crispin@SUMEX-AIM.ARPA>
> . . .
>      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 <houxm!gregbo> 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 <Crispin@SUMEX-AIM.ARPA>
	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 <wales@LOCUS.UCLA.EDU>
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 <jordan@ames.ARPA>"
                    <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 <ROODE@SUMEX-AIM.ARPA>
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 <leiner@RIACS.ARPA>
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 <wales@LOCUS.UCLA.EDU>
	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 <netinfo%ucbjade@ucbvax.berkeley.edu>
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 <netinfo%ucbjade@ucb-vax.arpa>
             <8510170411.AA16956@ucbjade.Berkeley.Edu>
Date: 17 Oct 85 10:25:29 EDT (Thu)
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA>

	From: Postmaster + BITINFO <netinfo%ucbjade@ucb-vax.arpa>
	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 <KLH@SRI-NIC.ARPA>
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 <KLH@SRI-NIC.ARPA>
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 <MRC@SIMTEL20.ARPA>
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 <Geoff@SRI-CSL.ARPA>
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 <Header-People@mit-mc.arpa>
From:      Doron Shikmoni  <P85025%BARILAN.BITNET@WISCVM.ARPA>
Reply-To: Header-People Forum <Header-People@mit-mc.arpa>
Subject: Columbia usage of internet domain
CC:  sy.ken%cu20b.BITNET@WISCVM.ARPA ,
   Gadi Maoz <P85026%BARILAN.BITNET@WISCVM.ARPA>

   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 <sy.Ken@CU20B>
Subject: Re: Mail bounced from UCB.
To: P85025, netinfo@UCBJADE
cc: P85026, sy.Ken@CU20B
In-Reply-To: Message from "Doron Shikmoni <P85025@BARILAN>" 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 <Geoff@SRI-CSL.ARPA>
	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:
<user%host@ucb-vax.ARPA>. 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
     <cic@csnet-sh>.

     [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 <Header-People@mit-mc.arpa>
Subject: Re: Columbia usage of internet domain
CC: sy.ken%cu20b.BITNET@WISCVM.WISC.EDU,
    Gadi Maoz <P85026%BARILAN.BITNET@WISCVM.WISC.EDU>,
    Doron Shikmoni <P85025%BARILAN.BITNET@WISCVM.WISC.EDU>
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 <leiner@RIACS.ARPA>
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 <desJardins@USC-ISI.ARPA>,
        Dennis Perry <Perry@IPTO.ARPA>
Cc: Bob Baker <Baker@IPTO.ARPA>
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" <jad@Purdue.EDU>


	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 <craig@LOKI.ARPA>


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" <cak@Purdue.EDU>

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 <ron@BRL.ARPA>
To:       Mark Crispin <MRC@simtel20.arpa>
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 <ron@brl.ARPA>
cc: Mark Crispin <MRC@simtel20.ARPA>, Header-People@mit-mc.ARPA
Reply-To: Directly to Header People and NOT to me <heder-people@mit-mc.ARPA>
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 <mrose@dewey.udel.EDU>

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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      Re: Columbia usage of internet domain
To:  <Rudy.Nedved@A.CS.CMU.EDU>
In-Reply-To:  Your message of 30 Oct 85 09:45 EST
cc:  <header-people@mit-mc.arpa> ,
   Reg Quinton <a362%uwocc1.BITNET@WISCVM.ARPA> ,
   Alan Crosswell <eacus%cuvma.BITNET@WISCVM.ARPA> ,
   Jeffrey Honig <netmaint%clvm.BITNET@WISCVM.ARPA>


> 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 <Geoff@SRI-CSL.ARPA>
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 <header-people@MIT-MC.ARPA>
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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      Domains and servers
To:  <header-people@mit-mc.ARPA>

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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      .US domain and why isn't it the top level domain
To: Domain Hostmaster <hostmaster@sri-nic.arpa>
cc:  <header-people@mit-mc.ARPA>

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 <ron@BRL.ARPA>
To:       Henry Nussbacher <Vshank%Weizmann.BITNET@wiscvm.wisc.edu>
cc:       Domain Hostmaster <hostmaster@sri-nic.arpa>, 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 <SY.Ken%CU20B.BITNET@WISCVM.ARPA> ,
   Jon Solomon <JSol%BUCS20@BostonU.CSnet>
From:      Doron Shikmoni  <P85025%BARILAN.BITNET@WISCVM.ARPA>
Subject: Re: EDU problems in Bitnet.
CC: Header-People Forum <Header-People@mit-mc.arpa> ,
   Info-Nets distribution <info-nets%mit-oz@mit-mc.arpa>

(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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      Re: .US domain and why isn't it the top level domain
To: Ron Natalie <ron@BRL.ARPA>
In-Reply-To:  Your message of Sun 17 Nov 85 16:05:21 EST
cc:  <header-people@mit-mc.ARPA> ,
    <hostmaster@sri-nic.arpa>

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 <stokes%cmc.cdn%ubc.csnet@CSNET-RELAY.ARPA>
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 <JSOL%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA>
To: Doron Shikmoni <P85025%BARILAN.BITNET@wiscvm.wisc.edu>
Cc: Header-People Forum <Header-People@mit-mc.ARPA>, 
    Info-Nets distribution <info-nets%mit-oz@mit-mc.ARPA>, 
    Ken Rossman <SY.Ken@cu20b.columbia.edu>
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 <harvard!WISCVM.ARPA!P85025%BARILAN.BITNET at bu-cs>


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 <jsol%bostonu.csnet@CSNET-RELAY.ARPA>
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 .<network-name> 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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      .US as an upper level domain
To:  <header-people@mit-mc.ARPA>

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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Resent-To:  <header-people@mit-mc.ARPA>

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: <Postmaster@ADA-VAX>

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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      .US as an upper level domain
To:  <header-people@mit-mc.ARPA>

-------

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" <jad@Purdue.EDU>


	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:<person%local@arpa>).  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 <jordan@ucbarpa.berkeley.edu>
cc: header-people@mit-mc.ARPA, cic@CSNET-SH.ARPA
Subject: Re: CSNET ...
In-reply-to: 
    Message from Jordan Hayes <jordan@ucbarpa.berkeley.edu>
             <8511242104.AA00486@ucbarpa>
Date: 25 Nov 85 16:42:34 EST (Mon)
From: Dennis Rockwell <dennis@CSNET-SH.ARPA>

	From: Jordan Hayes <jordan@ucbarpa.berkeley.edu>
	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:<person%local@arpa>).  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 <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
To: Header-People <Header-People@MIT-MC.ARPA>
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:<Dave-Platt@LADC>

   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 <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
   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 <header-people@MIT-MC.ARPA>
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  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
Subject:      Need for new field in RFC and MHS standards
To:  <MHS_implementation@wisc-rsch.ARPA> ,
    <header-people@mit-mc.ARPA> ,
    <ARPA-mhs@BRL.ARPA>

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 <mal%cornella.bitnet@Wiscvm.Wisc.Edu>
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: <value>

  <value> can be any of:

	Autoreply Daemon [<prog name/version/etc>]
	<system> Gateway [<prog name/version/etc>]
	Program <prog name/version/etc>
	<???>

  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 <Vshank%Weizmann.BITNET@WISCVM.WISC.EDU>
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 <mrose%NRTC@USC-ECL.ARPA>
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 <mrose%NRTC@USC-ECL.ARPA>
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 <header-people@MIT-MC.ARPA>,
             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:  <MHS_implementation@wisc-rsch.ARPA> ,
    <header-people@mit-mc.ARPA> ,
    <ARPA-mhs@BRL.ARPA>
From:      Peter Sylvester +49 228 303245
  <GRZ027%DBNGMD21.BITNET@WISCVM.ARPA>
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?:
    <MHS_implementation@wisc-rsch.ARPA> ,
    <ARPA-mhs@BRL.ARPA>
..
QUIT

Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 06:30:52 EST
Return-Path: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!teus@seismo.CSS.GOV>

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: <mcvax!ace!teus>
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: <mcvax!ace!teus>
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 <header-people@mit-mc.arpa>,

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  <DLS.MDC@OFFICE-1.ARPA>
Subject: Re: help!
To: ken@CIT-Hamlet.ARPA
Cc: header-people@mit-mc.arpa
Message-ID: <MDC-DLS-882ER@OFFICE-1>
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: <rick>
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 <rick@seismo.CSS.GOV>
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: <mcvax!ace!henk>
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 <header-people@mit-mc.arpa>,
        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 <mcvax!ace!henk@seismo.CSS.GOV>

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

