Acknowledge-To:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Date:  Sun, 18 Mar 84 17:25 EST
From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Subject:  Rochester SMTP server complaint
To:  Postmaster@ROCHESTER.ARPA, Liason@ROCHESTER.ARPA
cc:  header-people@MIT-MC.ARPA
Message-ID:  <840318222540.999839@MIT-MULTICS.ARPA>

VRFY appears to eat ANYTHING, valid, deliverable, or not.  So does EXPN.

Date:     Tue, 20 Mar 84 11:06:09 GMT
From:     Steve Kille <steve@ucl-cs.arpa>
To:       postel@usc-isif.arpa
cc:       header-people@mit-mc.arpa
Subject:  dhosts.txt

I note that the new format nhosts.txt contains only the official name
with .ARPA appended (e.g. it has USC-ISID.ARPA but not ISID.ARPA).
It would be more helpful (to our system at least), if the set of
entries were orthogonal.

Steve


Date:  Tue, 20 Mar 84 16:28 EST
From:  Network_Server.Daemon@MIT-MULTICS.ARPA (mmdf@Ucl-Cs.ARPA@Ucl-Cs)
Message-ID:  <840320212813.970083@MIT-MULTICS.ARPA>
Resent-Date:  20 Mar 84 17:55 EST
Resent-From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Resent-To:  header-people@MIT-MC.ARPA
Resent-Comment:
          Anybody know what provoked THIS?
Resent-Message-ID:  <840320225523.986628@MIT-MULTICS.ARPA>

Return-Path: <@MIT-MULTICS.ARPA,@Ucl-Cs:mmdf@Ucl-Cs.ARPA>
Received: from Ucl-Cs by MIT-MULTICS.ARPA TCP; 20-Mar-1984 16:28:07-est
Received: from rlgk.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          20 Mar 84 19:48 GMT
To:      "Benson I. Margulies" <Margulies@mit-multics.arpa>,
         ZUXA.UCL-CS.FTP@ucl-cs.arpa
MMDF-Warning:  Parse error in preceding line at 44d.Ucl-Cs.AC.UK
Date:    Tue, 20 Mar 84 12:50 GMT
References: <840318222540.999839@MIT-MULTICS.ARPA>
Message-Id: <20 MAR 1984 12:50:32 NSAU01@RLGK>
Subject: Message acknowledgement
Authentic-sender:   NSAU01@RLGK

Your message dated Sun, 18 Mar 84 17:25 EST
Subject "Rochester SMTP server complaint", has been accepted
by user Neil Davies (on GEC 4090 at Rutherford) <NSAU01@RLGK> using
Mail Vn 3


Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.25)
	id AA04113; Tue, 20 Mar 84 15:22:57 pst
Received: by ucbjade.CC.Berkeley.ARPA
	(4.14.noSUID/4.14.4) id AA06664; Tue, 20 Mar 84 15:23:02 pst
Message-Id: <8403202323.AA06664@ucbjade.CC.Berkeley.ARPA>
Date:     Tue, 20-MAR-1984 18:10 EST
From: Ronald A. Jarrell <TSDTEST%VPIVAX3.BITNET@Berkeley>
To: Margulies@Mit-Multics.ARPA
Cc: Header-People@mit-mc.ARPA
Reply-To: TSDTEST%VPIVAX3.BITNET@BERKELEY.ARPA
Subject:  ack's..


Moral of the story: Don't try to get an Ack across the network.
You never know what might turn up...

        Ron Jarrell

Date:  Wed, 21 Mar 84 09:59 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  re: that amazing ack
To:  header-people@MIT-MC.ARPA
Message-ID:  <840321145911.850332@CISL-SERVICE-MULTICS.ARPA>

1) Once again, the distinction between a mailing list and a
redistributor rears it head.  I think header-people should ack mail, not
the individuals.

2) Something is wrong with that header (MMDF seems to agree) such that
our mail server rejected it, so I did not immediately see the subject
and detect that it was an ack.

Date:  Wed, 21 Mar 84 12:12 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  That ferocious ack
To:  header-people@MIT-MC.ARPA
Message-ID:  <840321171211.369245@CISL-SERVICE-MULTICS.ARPA>

The local SMTP maintainer points out that that so-called ack has neigher
a From nor a Sender field, and is therefore invalid.

Would the responsable implementation (COM?)  stand up?

Date:     Wed, 21 Mar 84 18:09:07 GMT
From:     Steve Kille <steve@ucl-cs.arpa>
To:       "Benson I. Margulies" <Margulies@cisl-service-multics.arpa>
cc:       header-people@mit-mc.arpa
Subject:  Re:  That ferocious ack

For its sins, "Acknowledge-To:" is specified by the JNT Mail protocol
as generating an end to end acknowlegement.  There are dire
warnings about its use with distribution lists.   The element is
intended for human rather than machine processing (i.e. to give
confidence as to a messages arrival).  Many UK sites would send
an ack if such a field is in the original message.  UCL will send
one ONLY if the message arrives by the JNT Mail Protocol.

Steve



From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8404041704.AA07376@merlin.ARPA>
Received: by merlin.ARPA; Wed, 4 Apr 84 12:04:05 est
Date:  4 Apr 1984 1204-EST (Wednesday)
To: cowan@udel-relay.ARPA, postmaster@udel-relay.ARPA
Subject: losing header munging at udel relay
Cc: header-people@mc.ARPA, cic@csnet-cic.ARPA

(Background -- purdue-merlin is acting as a mail relay on behalf of
decwrl until their X.25/IP connection is fully straightened out.)

I recently saw a message in my outbound mail queue with a recipient of
<@Purdue-Merlin.ARPA:hobday@algol.dec-marlboro.ARPA>. This looked
rather bogus, so I thought I'd dig into it a bit farther. I looked at
the header file (not the data, of course), and found that the message
had the following lines:

From: Ken Cowan <cowan@udel-relay>
To: Ken Hobday ZKO2-3/K23 881-2214 <hobday%algol.DEC@purdue-merlin.arpa>

Hmm. How did that get turned into the recipient above? Decwrl is acting
as a mail relay for the DEC Engineering network, and uses the .DEC
domain internally to indicate this. (Several internet sites currently
understand that the .DEC domain is handled by decwrl, by the way.)
However, "dec" is also a nickname for "dec-marlboro" in the NIC host
table. So it looks like udel-relay, which runs MMDF, is peeking at the
left hand side of headers not destined for itself and munging them (for
shame!). I know that it used to use the . specifier as an indicator
that this should be relayed (this from the old phonenet software), and
MMDF has this wonderful habit of expanding nicknames (and capitalizing
host names!) in headers that it munges....

So that's what I think happened. Udel-relay peeked at the header and
munged it as if it were relaying the note, but it doesn't really end up
being relayed after all. The letter didn't make it through. 

Would the postmaster at Udel-Relay please fix this bogosity? Would
other folks running the same mail software (you presumably know who you
are) check to make sure that you're not doing the same thing? 

Cheers,
chris
----------

Date:  6 Apr 1984 08:34:14 PST
From: POSTEL@USC-ISIF
Subject: name@XEROX
To:   header-people@MIT-MC

Date: 6 Apr 84 08:11:21 PST (Friday)
From: owen.PA@Xerox.ARPA
Subject: name@XEROX

Hi,

Arpanet address name change.

"...New Gateway (Xerox.ARPA)

For many years, MAXC has been our connection to the Arpanet.  Although
it has served us well, we are planning to retire it.  The new Arpanet
mail gateway code now runs on a Dorado computer in the Cedar
environment.  Telnet and FTP are still available through MAXC but will
be supported by other facilities in the near future.  Please replace
"Name@PARC-MAXC" or "Name@PARC" with "Name@Xerox" in future Arpanet
correspondence.  Persons in charge of distribution lists should update
their lists accordingly. ..."


meg
-------

Delivery-Date:  9 Apr 84 09:18 EST
Delivery-By:  Network_Server.Daemon@MIT-MULTICS.ARPA (msggroup-request@BRL-MIS.ARPA@BR)
Date:  Fri, 6 Apr 84 15:03 EST
From:  Liudvikas Bukys <bukys@ROCHESTER.ARPA>
Subject:  looking for etiquette documents
To:  MsgGroup@BRL.ARPA
Message-ID:  <8404062003.10794@SEN.ROCHESTER>
Resent-Date:  9 Apr 84 09:46 EST
Resent-From:  Steven Schwartz <SSchwartz@MIT-MULTICS.ARPA>
Resent-To:  header-people@MIT-MC.ARPA
Resent-Message-ID:  <840409144641.104484@MIT-MULTICS.ARPA>

Can anyone direct me to a "network mail etiquette" document suitable
for instruction of new users?  I'm looking for something more
fleshed-out than "no commercial use, no vulgarity, no chain letters".
I already have a copy of "Emily Post for Usenet".  I'm looking for
something with an Arpanet orientation.

Liudvikas Bukys
bukys@rochester.arpa

Date: Wed 11 Apr 84 04:46:56-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: losing header munging at udel relay
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Christopher A Kent <cak@Purdue.ARPA>" of Wed 4 Apr 84 12:04:00-EST

I have noticed a similar obscurity: when a mail message passes between 
decwrl and rhea (as in a UUCP <--> DEC ENET mail message with a
pathname ...!decwrl!rhea!...), the headers are munged(?) to look like:

Received: from DECWRL.ARPA by RHEA.ARPA with <something or other>

where as I understand it, Rhea should be Rhea.DEC.  When attempting to
send mail through RICE-RHEA (that's what RHEA.ARPA) is, I got
undeliverable mail messages stating that the host was down or not
accepting mail.

Curiouser and curiouser ...
-------

Date: Wed 11 Apr 84 07:24:34-EST
From: covert%castor.DEC@Purdue-Merlin.ARPA
Subject: Re: losing header munging at udel relay
Sender: RSX-DEV@DEC-MARLBORO.ARPA
To: Gds@MIT-XX.ARPA
cc: header-people@MIT-MC.ARPA
Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA
In-Reply-To: Message from "Greg Skinner <Gds@MIT-XX.ARPA>" of Wed 11 Apr 84 04:48:59-EST
UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"

The addition of the spurious ".ARPA" seems to be a "feature" of all
4.2 BSD Unix mailers, added to be sure that the now required ".ARPA" is
there.

There was some discussion a while back (either here on on USENET; I've
forgotten where) about how this was hard-coded into the 4.2 BSD mailer.
-------

Date: Wed, 11 Apr 84 08:18 EST
From: Dennis Rockwell <drockwel@BBN-VAX>
Subject: Re: losing header munging at udel relay
To: Greg Skinner <Gds@MIT-XX.ARPA>, header-people@MIT-MC.ARPA
Cc: postmaster@decwrl

Yes, RHEA.ARPA is RICE-RHEA, and is a completely different host from
decwrl!rhea.  The reason mail doesn't get through to RICE-RHEA is that
they are on a net that is unknown to the core gateways at this point.
Of course, when domains are real, this name collision will go away,
right, folks?  Right?

Date: Wed 11 Apr 84 23:12:40-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: observation
To: Header-people@MIT-MC.ARPA
Location:  EJ286    Phone: (415) 859-2774

The headers on the following message display a nightmarish combination
of domain-style host names and routing-style recipient addresses.
I cannot help making this observation.  A previous message
referred to confusion between RHEA.DEC and RHEA.ARPA (RICE-RHEA).
What gives the domain "DEC" legitimacy?
  
    Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA>
    Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST
    Date: Wed 11 Apr 84 07:24:34-EST
    From: covert%castor.DEC@Purdue-Merlin.ARPA
    Subject: Re: losing header munging at udel relay
    Sender: RSX-DEV@DEC-MARLBORO.ARPA
    To: Gds@MIT-XX.ARPA
    cc: header-people@MIT-MC.ARPA
    Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA
    In-Reply-To: Message from "Greg Skinner <Gds@MIT-XX.ARPA>" of Wed 11 Apr 84 04:48:59-EST
    UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
    ENET-address: "Castor::Covert"
    Phone: "(603) 884-8271 or DTN 264-8271"
  
  
-------

From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8404121537.AA15118@merlin.ARPA>
Received: by merlin.ARPA; Thu, 12 Apr 84 10:37:30 est
Date: 12 Apr 1984 1037-EST (Thursday)
To: David Roode <ROODE@SRI-NIC.ARPA>
Cc: Header-people@MIT-MC.ARPA
Subject: Re: observation
In-Reply-To: Your message of Wed 11 Apr 84 23:12:40-PST.
             <8404120713.AA17639>

Note that the DEC domain appears only on the left hand side of the @,
so it's a local convention. I haven't seen any letters come out that
have just "user@host.DEC" as the return address, and I don't expect to
until (if) .DEC becomes a top-level domain.

It's really unfortunate that a) DECNET uses :: as the user/host
separator, and b) rfc822 is so written that this can't be properly
parsed.

    Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA>
    Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST
    Date: Wed 11 Apr 84 07:24:34-EST
    From: covert%castor.DEC@Purdue-Merlin.ARPA
    Subject: Re: losing header munging at udel relay
    Sender: RSX-DEV@DEC-MARLBORO.ARPA
    To: Gds@MIT-XX.ARPA
    cc: header-people@MIT-MC.ARPA
    Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA
    In-Reply-To: Message from "Greg Skinner <Gds@MIT-XX.ARPA>" of Wed 11 Apr 84 04:48:59-EST
    UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
    ENET-address: "Castor::Covert"
    Phone: "(603) 884-8271 or DTN 264-8271"


----------

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.25)
	id AA10440; Thu, 12 Apr 84 12:17:58 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14.noSUID/4.16) id AA16572; Thu, 12 Apr 84 12:18:51 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.16) id AA28059; Thu, 12 Apr 84 12:03:26 pst
Date: Thu, 12 Apr 84 12:03:26 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8404122003.AA28059@ucbopal.CC.Berkeley.ARPA>
To: Header-people@MIT-MC.ARPA
Subject: Re: observation

In reply to:

   Date: Wed 11 Apr 84 23:12:40-PST
   From: David Roode <ROODE@SRI-NIC.ARPA>
   Subject: observation
   To: Header-people@MIT-MC.ARPA
   Location:  EJ286    Phone: (415) 859-2774

   The headers on the following message display a nightmarish combination
   of domain-style host names and routing-style recipient addresses.
   I cannot help making this observation.  A previous message
   referred to confusion between RHEA.DEC and RHEA.ARPA (RICE-RHEA).
   What gives the domain "DEC" legitimacy?
     
       Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA>
       Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST
       Date: Wed 11 Apr 84 07:24:34-EST
       From: covert%castor.DEC@Purdue-Merlin.ARPA
       Subject: Re: losing header munging at udel relay
       Sender: RSX-DEV@DEC-MARLBORO.ARPA
       To: Gds@MIT-XX.ARPA
       cc: header-people@MIT-MC.ARPA
       Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA
       In-Reply-To: Message from "Greg Skinner <Gds@MIT-XX.ARPA>" of Wed 11 Apr 84 04:48:59-EST
       UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
       ENET-address: "Castor::Covert"
       Phone: "(603) 884-8271 or DTN 264-8271"
     
   -------

I don't see any problem with the above header.  The "DEC" is part of
the local address (not the domain). The UUCP-address and ENET-address
fields are user comments since they are not defined in RFC-822.
What the problem?

Assuming the gateway from DEC to ARPA mail domain puts the DEC address
in the Internet local address and adds a valid Internet domain name
to the right of the "@" there is no problem for the Internet mail world.

Bill Wells
wcwells@Berkeley.ARPA


Received: from RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.15)
	id AA12194; Thu, 12 Apr 84 12:49:48 pst
Message-Id: <8404122049.AA12194@decwrl.ARPA>
Date: 12-Apr-1984 1548
From: covert%castor.DEC@decwrl.ARPA  (John Covert)
To: header-people@mit-mc.ARPA
Subject: What DEC domain?

In the address "covert%castor.DEC@Purdue-Merlin.ARPA" I don't see
a DEC domain.
 
The ".DEC" appears in the local part, and is therefore perfectly legit.
 
/john

Date: Thu 12 Apr 84 20:02:49-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: What DEC domain?
To: covert%castor.DEC@DECWRL.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "covert%castor.DEC@decwrl.ARPA  (John Covert)" of Thu 12 Apr 84 15:48:00-PST
Location:  EJ286    Phone: (415) 859-2774

OK, OK, the ".DEC" is "legit."  The address is nevertheless
complicated. There are 5 parseable tokens separated by 3 different
delimiters.  I just hope this is the darkness before
the dawn, and we don't soon see 8 tokens and 6 different delimiters
in the address.
-------

Date: 14 Apr 1984 03:17:32-EST
From: allegra!hou3c!burl!we13!ihnp4!cbosgd!mark at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA21423; Sat, 14 Apr 84 01:17:18 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP
From: allegra!cbosgd!mark (Mark Horton)
Subject: Re: observation
Message-Id: <1260@cbosgd.UUCP>
Date: Thu, 12-Apr-84 17:32:01 EST
Received: by hou3c.UUCP; Fri, 13-Apr-84 01:34:14 EST
References: <459@hou3c.UUCP>
In-Reply-To: <459@hou3c.UUCP>
Organization: AT&T Bell Laboratories, Columbus


	What gives the domain "DEC" legitimacy?

DEC is as legitimate a domain as any of the others (UUCP, CSNET)
that are currently being used.  ARPA is not recognizing any domains
other than ARPA right now, although they have published dates by
which they are willing to consider them.  However, these domains
exist and are being used, whether or not ARPA recognizes them.

That particular message header you showed had the DEC domain entirely
hidden on the LHS, e.g.
    From: covert%castor.DEC@Purdue-Merlin.ARPA
This is entirely within 822 guidelines even if DEC is not known on ARPA,
as long as Purdue-Merlin knows how to gateway it.  From all appearances,
the gateway is doing fine.

	Mark Horton


Return-Path: <Postmaster@csnet-relay.arpa>
Received: from csnet-relay by WASHINGTON.ARPA with TCP; Sat 14 Apr 84 04:06:24-PST
Received: by csnet-relay via xucsc;  14 Apr 84 6:09 EST
Date:     13 Apr 84 21:27:25-PST (Fri)
From:     MEMO SERVICE (MMDF) <mmdf%ucsc.csnet@csnet-relay.arpa>
Subject:  Waiting mail
To:       FURUTA@washington.arpa
ReSent-date: Sat 14 Apr 84 11:46:25-PST
ReSent-from: Richard Furuta <Furuta@WASHINGTON.ARPA>
ReSent-to: header-people@MIT-MC.ARPA

    After -112 days, your message has not yet been fully delivered.
Mail is not returned until it is in the queue for at least 11 days.

    Delivery attempts are still pending for the following address(es):

	laser

    This usually is due to service interruptions at the
receiving machine.  Less often, there are problems with the
communications system.

    Your message begins as follows:

Received: From washington.arpa.arpa by csnet-relay via smtp; 
          12 Apr 84 18:16 EST
Return-Path: <dave@wisc-rsch.arpa>
Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST
Date: Thu, 12 Apr 84 16:21:25 cst
From: Dave Cohrs <dave%wisc-rsch.arpa@csnet-relay.csnet>
Message-Id: <8404122221.AA11640@wisc-rsch.arpa>
Received: by wisc-rsch.arpa (4.22/3.7)
	id AA11640; Thu, 12 Apr 84 16:21:25 cst
To: laser-lovers%washington.arpa@csnet-relay.csnet
Subject: ln01 fonts and programs available
ReSent-date: Thu 12 Apr 84 15:04:27-PST
ReSent-from: Richard Furuta <Furuta%washington.arpa@csnet-relay.csnet>
ReSent-to: "Laser Lovers": ;
Via:  rand-relay; 5 Aug 84 15:44-PDT

ditroff filter, versatec ==> ln01 font conversion (and support programs) 
available from University of Wisconsin Computer Science Dept.
...

Date: Sat 14 Apr 84 11:50:48-PST
From: Richard Furuta <Furuta@WASHINGTON.ARPA>
Subject: Friday the 13th
To: header-people@MIT-MC.ARPA
cc: Furuta@WASHINGTON.ARPA

Let me submit the following as an example of "Friday the 13th
behavior."  Note how long mmdf thinks the message has been in the
queue.

Another instance of this kind of behavior showed up here yesterday.
We have a hung job on one of our systems that we cannot log out.  It
was started on Friday the 13th, is job number 13, and is on terminal
line number 13.

Unfortunately, I also provided another example of "Friday the 13th"
behavior in formulating this message by accidentally forwarding a copy
of the enclosed without any commentary.  Sorry.

					--Rick

                              ----------
Return-Path: <Postmaster@csnet-relay.arpa>
Received: from csnet-relay by WASHINGTON.ARPA with TCP; Sat 14 Apr 84 04:06:24-PST
Received: by csnet-relay via xucsc;  14 Apr 84 6:09 EST
Date:     13 Apr 84 21:27:25-PST (Fri)
From:     MEMO SERVICE (MMDF) <mmdf%ucsc.csnet@csnet-relay.arpa>
Subject:  Waiting mail
To:       FURUTA@washington.arpa

    After -112 days, your message has not yet been fully delivered.
Mail is not returned until it is in the queue for at least 11 days.

    Delivery attempts are still pending for the following address(es):

	laser

    This usually is due to service interruptions at the
receiving machine.  Less often, there are problems with the
communications system.

    Your message begins as follows:

Received: From washington.arpa.arpa by csnet-relay via smtp; 
          12 Apr 84 18:16 EST
Return-Path: <dave@wisc-rsch.arpa>
Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST
Date: Thu, 12 Apr 84 16:21:25 cst
From: Dave Cohrs <dave%wisc-rsch.arpa@csnet-relay.csnet>
Message-Id: <8404122221.AA11640@wisc-rsch.arpa>
Received: by wisc-rsch.arpa (4.22/3.7)
	id AA11640; Thu, 12 Apr 84 16:21:25 cst
To: laser-lovers%washington.arpa@csnet-relay.csnet
Subject: ln01 fonts and programs available
ReSent-date: Thu 12 Apr 84 15:04:27-PST
ReSent-from: Richard Furuta <Furuta%washington.arpa@csnet-relay.csnet>
ReSent-to: "Laser Lovers": ;
Via:  rand-relay; 5 Aug 84 15:44-PDT

ditroff filter, versatec ==> ln01 font conversion (and support programs) 
available from University of Wisconsin Computer Science Dept.
...
-------

Date: Sat, 14 Apr 84 15:15:25 EST
From: Daniel Long <long@BBN-UNIX>
Subject: Re: Friday the 13th
In-Reply-To: Your message of Sat 14 Apr 84 11:50:48-PST
To: Richard Furuta <Furuta@WASHINGTON>
Cc: header-people@MIT-MC, cic@BBN-UNIX

This one is fairly straightforward.  MMDF returns mail after it has been queued
for some amount of time.  Things get interesting when someone sets the system
date far ahead of the present.  Note the date on the Via: line.

Received: From washington.arpa.arpa by csnet-relay via smtp; 
          12 Apr 84 18:16 EST
Return-Path: <dave@wisc-rsch.arpa>
Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST
Date: Thu, 12 Apr 84 16:21:25 cst
From: Dave Cohrs <dave%wisc-rsch.arpa@csnet-relay.csnet>
Message-Id: <8404122221.AA11640@wisc-rsch.arpa>
Received: by wisc-rsch.arpa (4.22/3.7)
	id AA11640; Thu, 12 Apr 84 16:21:25 cst
To: laser-lovers%washington.arpa@csnet-relay.csnet
Subject: ln01 fonts and programs available
ReSent-date: Thu 12 Apr 84 15:04:27-PST
ReSent-from: Richard Furuta <Furuta%washington.arpa@csnet-relay.csnet>
ReSent-to: "Laser Lovers": ;
Via:  rand-relay; 5 Aug 84 15:44-PDT



Here's March's entry in the contest:

Date:     Tue, 13 Mar 84 6:58:04 EST
From:     CSNET-RELAY Memo Service (MMDF) <mmdf@CSNET-RELAY>
Subject:  Waiting mail
To:       chris%umcp-cs@Csnet-Relay.ARPA
Via:  CSNet-Relay; 13 Mar 84 22:51-EDT

    After 9 days (194 hours), your message has not yet been
fully delivered.  Attempts to deliver the message will continue
for 178956969 more days.  No further action is required by you.

    Delivery attempts are still pending for the following address(es):

	eggert @ Ucsb (queue: ucsb)

    Problems usually are due to service interruptions at the receiving
machine.  Less often, they are caused by the communication system.


			-- Dan

Date: 15 Apr 1984 01:45:31-EST
From: allegra!hou3c!burl!ulysses!harpo!seismo!uwvax!dave at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA03837; Sat, 14 Apr 84 21:56:32 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA
From: allegra!dave@uwvax.ARPA
Subject: Re: What DEC domain?
Message-Id: <201@uwvax.ARPA>
Date: Sat, 14-Apr-84 03:02:48 EST
Received: by hou3c.UUCP; Sat, 14-Apr-84 11:24:25 EST
References: <467@hou3c.UUCP>
In-Reply-To: <467@hou3c.UUCP>
Organization: U of Wisconsin CS Dept

> OK, OK, the ".DEC" is "legit."  The address is nevertheless
> complicated. There are 5 parseable tokens separated by 3 different
> delimiters.  I just hope this is the darkness before
> the dawn, and we don't soon see 8 tokens and 6 different delimiters
> in the address.

If its number of tokens and delimiters you're worried about, I have bad
news for you.  The new ARPAnet standard has domains and subdomains,
etc, etc.  The number of tokens is bound to increase for a while.

-- 
Dave Cohrs @ wisconsin
...!{allegra,eagle,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave
dave@wisc-rsch.arpa


Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.17)
	id AA01284; Mon, 16 Apr 84 13:00:05 pst
Message-Id: <8404162100.AA01284@decwrl.ARPA>
Date: Monday, 16 Apr 1984 11:47:08-PST
From: lipman%rhea.DEC@decwrl.ARPA
To: header-people@mit-mc.ARPA
Subject: More on RHEA.DEC

     In my previous submission to header-people, I noted that I had
eliminated identifying RHEA.DEC as RHEA.ARPA in the "Received: "
headers.  I had chosen to identify RHEA.DEC as DEC-RHEA.ARPA at
least partially due to the way 4.2 BSD sendmail generates that
Received header message.

     A second reason for changing the host name and not just the
domain was the argument that user@rhea, user@rhea.ARPA, and
user@rice-rhea.ARPA should all be equivalent.  I based this feeling
on the argument that I and my user community wanted user@Shasta,
user@Shasta.ARPA, and user@SU-Shasta.ARPA to all be equivalent.
Consistency might even make some of this obscure junk understandable.

     But Brian Reid points out in the note enclosed below that
neither user@rhea, nor user@rhea.ARPA should be arriving at decwrl
from the outside world.  Nicknames are not supposed to leave the
local machine on which they are used, they are supposed to be
converted into the real host name.  Note that I believe 4.2 BSD
Sendmail violates this rule.

     If this is indeed the case, then it is only my local user
community I should be concerned about and for them, user@rhea should
mean dec-rhea.

     I'll bet there is a mailbag worth of opinions out there!

Peter Lipman
DEC Western Research Laboratory
4410 El Camino Real
Los Altos, California 94022
(415) 949-0776

uucp:     {decvax, ucbvax, ihnp4, allegra} decwrl!lipman
ARPA net: lipman@decwrl.ARPA
DEC-Enet: RHEA::LIPMAN

--------------- Note from Brian Reid ------------------------

From:	RHEA::DECWRL::"reid@Glacier.ARPA" "Brian Reid"   15-APR-1984 16:21  
To:	Peter Lipman <lipman@decwrl>
Subj:	rhea and domains

Received: from DECWRL by DEC-RHEA with SMTP; Sun, 15 Apr 84 16:21-PST
Received: from Glacier (su-glacier.arpa.ARPA) by decwrl.ARPA (4.22.01/4.7.16)
	id AA24254; Sun, 15 Apr 84 16:18:03 pst
Date: Sun, 15 Apr 84 16:16:11 pst
Cc: Forest Baskett <baskett@decwrl>
Message-Id: <8404160018.AA24254@decwrl.ARPA>

Peter, 
  I saw a message on acetes that there is a naming conflict between
rice-rhea and DEC's rhea.
  I don't think there should be a need to panic. One of the main
purposes for having domains in symbolic addressing is to provide a way
of circumventing this problem.
  The main use, so far, of domain addressing in the internet has been
to assist subnet routing of mail. Perhaps this has obscured the more
important use of domains for name qualification.
  Thus, the name RHEA.DEC is a different name from RHEA.ARPA. As it
turns out, if you read the fine print in RFC822, it is illegal to put
domain qualifications on nicknames, e.g. RHEA.ARPA is not a legal name,
but RICE-RHEA.ARPA is a legal name. Furthermore, the standard requires
that all exported text contain only fully-qualified names. This means
that once a message leaves the .ARPA domain, it cannot contain the name
"RHEA" anywhere in it, or even "RHEA.ARPA". 
  This important restriction provides the basis for making your system
do what you want. When you are on, say, Acetes, and you reference a
name "RHEA", you are allowed to assume that you are in some domain
besides the .ARPA domain. Specifically, you are in the .DEC domain.
You can think of the task of name resolution as being like looking down
a search path of domains: first you check your own home domain, then
you check neighboring domains, and so forth. If you did it this way,
then the name "rhea" would always resolve to RHEA.DEC and not
RICE-RHEA.ARPA when it was used in an unqualified context on any
machine in the DEC domain.
  The moral: you don't have to change the name of your machine unless
you want to.
		Brian

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA00430; Tue, 17 Apr 84 13:13:25 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14.noSUID/4.16) id AA23442; Tue, 17 Apr 84 12:01:44 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.16) id AA18530; Tue, 17 Apr 84 12:01:05 pst
Date: Tue, 17 Apr 84 12:01:05 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8404172001.AA18530@ucbopal.CC.Berkeley.ARPA>
To: header-people@mit-mc.ARPA
Subject: Re: More on RHEA.DEC

In reply to:

	Message-Id: <8404162100.AA01284@decwrl.ARPA>
	Date: Monday, 16 Apr 1984 11:47:08-PST
	From: lipman%rhea.DEC@decwrl.ARPA
	To: header-people@mit-mc.ARPA
	Subject: More on RHEA.DEC

	.....  Nicknames are not supposed to leave the local machine
	on which they are used, they are supposed to be converted into
	the real host name.  Note that I believe 4.2 BSD
	Sendmail violates this rule. .....

	Peter Lipman
	DEC Western Research Laboratory
	4410 El Camino Real
	Los Altos, California 94022
	(415) 949-0776

Let's stop blaming the Unix sendmail program and work toward getting
local sendmail configuration files fixed so gatewaying is handled properly.
At Berkeley we permit users to use different nicknames and top-domain
names with sendmail. Our mail system also transforms non-Internet
addresses into Internet addresses of before transmitting the message
to an Internet mail site.

Bill Wells
wcwells@Berkeley.ARPA

Date: Tue 17 Apr 84 13:30:29-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: "blaming Unix SendMail"
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I will probably regret this, but I couldn't help myself.  It seems
that any program which requires configuration files of such complexity
that just about every site gets them wrong is sadly lacking in the most
basic principles of good software design.  Unix SendMail seems to be
such a program.

     Tell me, why does SendMail need such complex configuration files?
Wouldn't a preferable scheme be to look at ones environment at runtime
and do the right thing by default?

     I guess I'm wedged.  After all, I program on dinosaurs using the
obsolete thinking that software should do the right thing in its default
unmodified state without requiring such elaborate configuration procedures.
-------

Date: 18 Apr 1984 22:26:39-EST
From: allegra!hou3c!burl!ulysses!allegra!princeton!down!honey at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA18518; Wed, 18 Apr 84 22:20:42 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site down.UUCP
From: allegra!down!honey (code 101)
Subject: Re: "blaming Unix SendMail"
Message-Id: <140@down.UUCP>
Date: Tue, 17-Apr-84 20:20:30 EST
Received: by hou3c.UUCP; Tue, 17-Apr-84 23:19:11 EST
References: <474@hou3c.UUCP>
In-Reply-To: <474@hou3c.UUCP>
Organization: Princeton Univ. EECS

why does sendmail require such complex configuration tables, you ask?
read the documentation (sendmail/doc/op.me):

	There is one point that should be made clear immediately:  the
	syntax of the configuration file is designed to be reasonably
	easy to parse, since this is done every time sendmail starts
	up, rather than easy for a human to read or write.

let's just ignore the fact that parsing was made trivial by geniuses of
decades past, and go blithely along, prematurely optimizing.  progress?
who needs it?  feh.
	peter honeyman


Date: 18 Apr 1984 22:26:46-EST
From: allegra!hou3c!burl!ulysses!harpo!seismo!rlgvax!guy at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA18539; Wed, 18 Apr 84 22:22:25 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
From: allegra!rlgvax!guy (Guy Harris)
Subject: Re: "blaming Unix SendMail"
Message-Id: <1871@rlgvax.UUCP>
Date: Wed, 18-Apr-84 00:03:37 EST
Received: by hou3c.UUCP; Wed, 18-Apr-84 03:16:59 EST
References: <474@hou3c.UUCP> <140@down.UUCP>
In-Reply-To: <140@down.UUCP>
Organization: CCI Office Systems Group, Reston, VA

>why does sendmail require such complex configuration tables, you ask?
>read the documentation (sendmail/doc/op.me):

>	There is one point that should be made clear immediately:  the
>	syntax of the configuration file is designed to be reasonably
>	easy to parse, since this is done every time sendmail starts
>	up, rather than easy for a human to read or write.

>let's just ignore the fact that parsing was made trivial by geniuses of
>decades past, and go blithely along, prematurely optimizing.  progress?
>who needs it?  feh.

Not entirely fair; the comment in the documentation refers to the *syntax*
of a configuration file (which is, admittedly, baroque) but the person
who complained about "sendmail" was complaining about the baroque *semantics*
of the configuration file.  Unfortunately, if you want a program which is
all things to all people (like "sendmail" is) you aren't going to get
something which is straightforward.  Frankly, I bless "sendmail"s ability
to be made to do lots of mail handling tasks without having to dive into
the source code (which is a poor idea because 1) it's complicated and you
may break it, 2) it means you've got private versions of "sendmail" running
around all over the place - Allman's paper on "sendmail" points out that
the "sendmail" configuration file was intended to make it possible to run
the same binary everywhere, and 3) lots of people out there don't have
source anyway).  I wish it were more straightforward, but I don't know
whether that's possible.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy


Date: Wed 18 Apr 84 21:16:33-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "blaming Unix SendMail"
To: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "allegra!hou3c!burl!ulysses!harpo!seismo!rlgvax!guy at mit-vax" of Wed 18 Apr 84 19:26:46-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Perfectly fair.  It doesn't matter whether one refers to syntax or
semantics of the configuration files.  The fact is that it is very
hard to respect a mailsystem which engages in idiotic behavior because
the case of one of single-letter options in the configuration file was
lower case instead of upper.  This has happened repeatedly in systems
across the ARPANET, and in-house at Stanford a number of times.

The developers and users of Unix and its software loudly proclaim how
advanced their software is and how it is the "clean non-kludgy" way
into the future (compared with systems such as DEC-20's which are
presumably "unclean and kludgy").  It seems quite fair to call SendMail
on this sort of thing.  If Unix wants to be more than a toy system it
has got to recognize that ergonomics is part of software engineering.
-------

From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8404190535.AA11042@merlin.ARPA>
Received: by merlin.ARPA; Thu, 19 Apr 84 00:35:39 est
Date: 19 Apr 1984 0035-EST (Thursday)
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: Header-People@MIT-MC.ARPA
Subject: Re: "blaming Unix SendMail"
In-Reply-To: Your message of Wed 18 Apr 84 21:16:33-PST.
             <8404190521.AA12910>

Header-People seems hardly to be the place to launch into TOPS-20 vs.
Unix flamage. Please desist.

Cheers,
chris
----------

Message-Id: <8404191218.AA26607@harvard.UUCP>
From: lhasa!stew@harv-10
Date: 	19-apr-1984 07:12
To: harvard!header-people@mit-mc
Subj: 	Malformed headers

I have recently been involved in setting up a mailsystem connecting HARVARD,
a 4.2BSD Unix 780 on the internet, to other machines here at Harvard.
All this guff about sendmail config files is starting to hit me;  This is
a problem we're faced with here.

Here is an example of a recent incoming message that illustrates some
of the problems.  Perhaps someone out there can make some suggestions
as to who is to blame for the following headers, and what can be done.

The first message is in the exact form that harvard transmitted it.
To harvard, our machine appears as a "fake" uucp address;  LHASA is a
VAX/VMS machine running software which I wrote to pick the necessary
files out of Harvard's uucp spool directories and deliver them on
the VMS machine.

--------------- Begin forwarded message #1 -----------------

From @MIT-MC.ARPA:@SRI-KL.ARPA:engvax!KVC@cit-vax  Thu Apr 19 02:26:57 1984 remote from harvard
Received: from cit-vax.ARPA by SRI-KL.ARPA with TCP; Wed 18 Apr 84 22:36:18-PST
Received: by cit-vax.ARPA id AA03064 at Wed, 18 Apr 84 16:09:33 pst
Date: Wed, 18 Apr 84 16:09:33 pst
From: harvard!engvax!KVC@cit-vax.ARPA
Message-Id: <8404190009.AA03064@cit-vax.ARPA>
To: ."cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA
Subject: Re: lost batch jobs...

<body of message deleted>

	/Kevin Carosso                  engvax!kvc @ CIT-VAX
	 Hughes Aircraft Co.

---------------  End forwarded message #1  -----------------

For those who are interested, this is the form the message takes when
it appears in my VMS mail file.

--------------- Begin forwarded message #2 -----------------
From:	HARVARD!@MIT-MC.ARPA:@SRI-KL.ARPA:engvax!KVC@cit-vax 19-Apr-1984 02:26
To:	."cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA
Subj:	Re: lost batch jobs...
Received: by lhasa via VAXNET; Thu Apr 19 02:44:15 1984
Received: from cit-vax.ARPA by SRI-KL.ARPA with TCP; Wed 18 Apr 84 22:36:18-PST
Received: by cit-vax.ARPA id AA03064 at Wed, 18 Apr 84 16:09:33 pst
Date: Wed, 18 Apr 84 16:09:33 pst
From: harvard!engvax!KVC@cit-vax.ARPA
Message-Id: <8404190009.AA03064@cit-vax.ARPA>

<body of message deleted>

	/Kevin Carosso                  engvax!kvc @ CIT-VAX
	 Hughes Aircraft Co.

---------------  End forwarded message #2  -----------------

Now.  The problems should be obvious.  I want to respond to an address
something like harvard!"engvax!kvc"@cit-vax, I think.  And if I want to
CC the list, it does NOT want to go to

"cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA

ENGVAX isn't even on ARPA!!!

Someone has to translate these to things like:

	<@HARVARD: engvax!kvc@CIT-VAX.ARPA>

and

	<@CIT-VAX: INFO-VAX@SRI-KL.ARPA>.

Are my interpretations of RFC822 correct?  I assume that the problems
on both ends could be corrected by changes to the sendmail config files...
I should of course say that I am not blaming anyone at CIT;  the same
sort of malformed header will be visible on the message that you
receive from me.

Stew Rubenstein

ARPA: lhasa!stew@harvard.arpa
UUCP: {allegra!ima,decvax!genrad!wjh12}!harvard!lhasa!stew
MAIL: Harvard University Chemical Labs
      12 Oxford St.  Box 100
      Cambridge, MA  02138


Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA12770; Thu, 19 Apr 84 11:04:25 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14.noSUID/4.16) id AA14654; Thu, 19 Apr 84 11:06:07 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.16) id AA15115; Thu, 19 Apr 84 11:05:27 pst
Date: Thu, 19 Apr 84 11:05:27 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8404191905.AA15115@ucbopal.CC.Berkeley.ARPA>
To: Header-People@MIT-MC.ARPA
Subject: Re: "blaming Unix SendMail"

I think we can agree that "machine readable" files are not necessarily
"human readable".  Yes, the sendmail configuration file is susceptible
to human error because it is complex, terse, and has to be manually
edited for installation.  I think the BSD Unix development group could
make installation easier by supplying more examples of sendmail
configuration files (eg. one for a site in one mail domain, one for a
site in a subdomain, one for a site in a gateway domain [multiple local
domains], etc.).  A program that asks the installer appropriate
questions and generates a configuration file for the more common types
of installations might reduce the number of errors being made.

Bill Wells
wcwells@Berkeley.ARPA
ucbvax!wcwells

Received: ID <VAF@CMU-CS-C.ARPA>; Thu 19 Apr 84 15:56:56-EST
Date: Thu 19 Apr 84 15:56:53-EST
From: Vince Fuller <VAF@CMU-CS-C.ARPA>
Subject: Re: "blaming Unix SendMail"
To: MRC@SU-SCORE.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Thu 19 Apr 84 07:39:20-EST

One of the things that has continually amazed me about Unix is the steadfast
refusal to implement anything as something other than a text file. This whole
argument is silly. Why does sendmail (or the termcap library, or anything else
in Unixland for that matter) have to parse a rarely-changing text file every
time it is started? Why not have the file preparsed into a binary file that
imposes structure on the options for ease of access? This kind of simple
optimization (which is the way the TOPS-20 mailsystem handles address lists)
satisfies both requirements: the text file "source" can be easy for humans
to read - it doesn't have to be parsed often - so what it parsing takes a
little while longer, and the binary can be optimized for speed (probably would
do a lot better than the current approach). I'm sorry, but I won't buy the
"it has to be parsed quickly" argument.

--Vince

P.S. My apology to those offending by the flaming tone of the message. I am
     just tired of seeing so much braindamage like this in Unix - it really
     isn't that hard to sit down and THINK about how to implement something
     before you go out and do it.
-------

Date: Fri, 20 Apr 84 10:01:01 cst
From: solomon@wisc-crys.arpa (Marvin Solomon)
Message-Id: <8404201601.AA05840@wisc-crys.arpa>
Received: by wisc-crys.arpa (4.22/3.7)
	id AA05840; Fri, 20 Apr 84 10:01:01 cst
To: lhasa!stew@harv-10
Subject: Re:  Malformed headers
Cc: header-people@mit-mc
Sender: forwarder@wisc-crys.arpa

This has all been said before, so I'll try to be brief, but it keeps
coming up, so I think it's worth repeating.

The problem is conflicting and ambiguous syntax for addresses between
RFC 822 and UUCP.  The UUCP syntax is host!localpart, while the 822
syntax is localpart@host.  When you try to put an address into
"localpart" to simulate source routing, you get ambiguity.  Does
"a!b@c" mean "a!(b@c)" (use UUCP to send to host a, which hopefully is
on Arpanet and can send to b@c), or does it mean "(a!b)@c" (send over
Arpanet to host c, which will forward using uucp).  The ad hoc solution
seems to be context-sensitive parsing, using info like whether I'm on
Arpanet, whether Arpanet contains a host named "c", etc.  Usually some
sort of local kludge can be worked out.  But when a message crosses
back and forth between worlds more than once (as the message in
question seems to have done), I have very little hope that anything
will work.  Some UUCP sites are trying to move to the 822 syntax with
hacks like munging host!user to user@host.UUCP.  Sometimes that helps,
and sometimes it makes things worse.

My own personal opinion is that source-routing is a necessary evil that
will be with us for some time.  The best syntax I've seen is the RFC821
syntax:  <@host1,@host2,...,@hostN-1:user@hostN>.  I've seen some
evidence that more software packages are supporting it, not only in the
SMTP envelope, but in headers and in user agents.

When putting together independantly planned (or unplanned) systems and
trying to make a consistent whole, we must strike a delicate balence:
We must be understanding and sympathetic with sites running obsolete
software, while continuing to urge them and help them to change.
In this case, we can help by moving quickly towards putting the domain
system in place and setting up some sort of "official" UUCP domain.

Date: Fri, 20 Apr 84 10:31:40 cst
From: solomon@wisc-crys.arpa (Marvin Solomon)
Message-Id: <8404201631.AA06136@wisc-crys.arpa>
Received: by wisc-crys.arpa (4.22/3.7)
	id AA06136; Fri, 20 Apr 84 10:31:40 cst
To: VAF@CMU-CS-C.ARPA
Subject: Re: "blaming Unix SendMail"
Cc: Header-People@MIT-MC.ARPA
Sender: forwarder@wisc-crys.arpa

The change you suggested is already in sendmail (the version distributed
with 4.2 UNIX).  I believe I was the one who suggested the particular
"trick" now used.  I thought of it years ago while trying to make Adventure
start up more quickly.  Take ANY program that has a complicated and
time-consuming startup and add two options:  When the program is called
with the first option, it goes through the initialization, then dumps
everything willy-nilly into a file.  (In C, that can usually be done
by simply dumping bss: everything from _edata to _end; in FORTRAN it
can be done by dumping COMMON).  When called with the second option, the
program skips the initialization and simply loads the file.

Now the bad news:  The syntax for sendmail configuration files was designed
before the "freeze-file" idea was incorporated, but even though the
justification is now gone, nobody is very anxious to change it.
I think the best course is simply to improve the instructions for creating
configuration files, but that's much more boring that creating more software
:-)

Sendmail was designed and implemented by Eric Allman.  If you disagree
with some aspect of its design, argue with him.  I believe he's already
stated publicly that he's sorry he made the configuration file so cryptic,
and if he had it to do over, he'd do it differently.  

Comments like "I'm just tired of seeing so much braindamage like this in
Unix" are really off the mark.  I'm tired of seeing so much sectarian strife.

Date: 20 Apr 1984 12:42:08-EST
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!intelca!t4test!lew at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA11289; Fri, 20 Apr 84 10:56:01 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site t4test.UUCP
From: allegra!t4test!lew (Lew Mullen)
Subject: Re: "blaming Unix SendMail"
Message-Id: <518@t4test.UUCP>
Date: Thu, 19-Apr-84 12:40:24 EST
Received: by hou3c.UUCP; Fri, 20-Apr-84 09:21:51 EST
References: <474@hou3c.UUCP>
In-Reply-To: <474@hou3c.UUCP>
Organization: Intel, Santa Clara, Ca.

So that's why it doesn't work ... what configuration files ?

				t4test!lew
				lew mullen


Date: 20 Apr 1984 12:42:20-EST
From: allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA11346; Fri, 20 Apr 84 10:58:42 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP
From: allegra!ut-sally!smoot (Smoot Carl-Mitchell)
Reply-To: smoot@ut-sally.ARPA (Smoot Carl-Mitchell)
Subject: Re: "blaming Unix SendMail"
Message-Id: <2003@ut-sally.UUCP>
Date: Thu, 19-Apr-84 13:30:56 EST
Received: by hou3c.UUCP; Thu, 19-Apr-84 20:34:58 EST
References: <474@hou3c.UUCP>
In-Reply-To: <474@hou3c.UUCP>
Organization: U. Texas CS Dept., Austin, Texas

As the local "sendmail hacker" here at UT, I do find the configuration
file syntax to be difficult to understand at times.  Fortunately,
Eric Allman did provide some pretty good template files to get users
started and I greatly appreciated that.  Most of the configuration
files I have modified are based upon one or more of Eric's files.
Without those files I would have spent a great deal more time
writing the configuration files we need.

In defense of sendmail it was designed to operate in a heterogenous
network mail environment and serve as a bridge between user 
communities using  different mail address syntax.  As a first stab
at trying to address the problem, I think Eric did a fine job.
It can be improved.  A more "user friendly" syntax would certainly
be useful and while not an easy job it is not impossible.
-- 
Smoot Carl-Mitchell, CS Dept. University of Texas at Austin
{seismo, ctvax, ihnp4}!ut-sally!smoot, smoot@ut-sally.{ARPA, UUCP}


Date: 20 Apr 1984 12:42:26-EST
From: allegra!hou3c!burl!ulysses!harpo!ihnp4!cbosgd!mark at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA13227; Fri, 20 Apr 84 12:35:22 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP
From: allegra!cbosgd!mark (Mark Horton)
Subject: Re: "blaming Unix SendMail"
Message-Id: <1291@cbosgd.UUCP>
Date: Thu, 26-Apr-84 00:41:20 EST
Received: by hou3c.UUCP; Fri, 20-Apr-84 07:15:36 EST
References: <487@hou3c.UUCP>
In-Reply-To: <487@hou3c.UUCP>
Organization: AT&T Bell Laboratories, Columbus


	Why does sendmail (or the termcap library, or anything else
	in Unixland for that matter) have to parse a rarely-changing
	text file every time it is started?

Check out the following
	/usr/lib/sendmail -bz
This creates a binary file for quick startup.

Termcap is being replaced by terminfo, which also uses binary files.

So of course it doesn't have to.  But it's great for prototyping when
the first stab is in a text format.

	Mark


From: Mark Shoemaker <mas@Purdue.ARPA>
Message-Id: <8404202031.AA26150@mordred.ARPA>
Received: by mordred.ARPA; Fri, 20 Apr 84 15:31:48 est
Date: 20 Apr 1984 1531-EST (Friday)
To: header-people@mit-mc.ARPA
Subject: arcane sendmail configuration tables


	Why doesn't someone (with lots of spare time) design a more
	reasonable syntax for describing a sendmail configuration and
	then implement a translator from it to the current syntax?

	While they're at it, they could write a translator
	(disassmbler?) from the old syntax to the new to aid in
	incorporating updates.

		I'd do it if I had the time (really!),
		Mark Shoemaker		mas@purdue

Date: Fri 20 Apr 84 13:31:17-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "blaming Unix SendMail"
To: smoot@UT-SALLY.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax" of Fri 20 Apr 84 09:42:20-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     To answer smoot@UT-SALLY's defense of Sendmail, I should point
out that the TOPS-20 mailsystem (in particular, its MMailr module)
also operates in a heterogenous network mail environment.  MMailr
doesn't require gothic configuration files to do the right thing.

     I will confess that MMailr doesn't try to bridge between different
mail syntaxes.  user@host is a perfectly reasonable syntax to standardize
on, and I see no particular reason to encourage relative addressing
unless it is absolutely necessary.  What does
	foo!bar!rag!zowie
mean when host bar knows of TWO DIFFERENT machines called rag?  Can't
happen, you say?  Nonsense; it is a real problem between Internet and
several University LAN's right now.  In other words, relative addressing
is only safe to use in the cases where it is unnecessary!
-------

Date: Fri, 20 Apr 84 15:06:05 pst
From: Joseph I. Pallas <pallas@Pescadero>
Subject: Re: "blaming Unix SendMail"
To: MRC@SU-Score, smoot@UT-SALLY.ARPA
Cc: Header-People@MIT-MC.ARPA

Sorry, MRC, but relative addressing is still necessary even when it is
safe to use.  In your example,

		foo!bar!rag!zowie

it's still possible that foo doesn't know how to talk to ANY machine
named rag, let alone two of them.  That's why SMTP supports source
routing.  Of course, domains will change all that Real Soon Now.

joe
	
	

Date: Fri 20 Apr 84 16:20:01-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "blaming Unix SendMail"
To: pallas@PESCADERO.ARPA
cc: smoot@UT-SALLY.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Joseph I. Pallas <pallas@Pescadero>" of Fri 20 Apr 84 15:06:26-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

SMTP source routing is completely useless, due to restrictions on
what may be in the SMTP source route.  It might as well not exist.

My point was that relative addressing is not at all a desirable
thing.  It should only be looked at as a last resort.  Within a
single naming registry, it should be possible to use absolute
addressing.  Between naming registries, it should be possible to
give "an absolute address within an absolute registry" -- this
was the original concept behind domains although now domains refer
to administrative rather than technical entities (naming registries
traditionally have followed the latter rather than the former).
-------

Date: 21 Apr 1984 16:39:07 PST
From: POSTEL@USC-ISIF
Subject: RFC 821 Documentation Bug
To:   header-people@MIT-MC

Date: Wed, 18 Apr 84 21:36:07 pst
From: spgggm%ucbopal.CC@Berkeley (Greg Minshall)
To: postel@isif.ARPA
Subject: rfc821 question...

Hi,

Is it true that 'postel@f.isi.arpa' is illegal by rfc821, since
             <name> ::= <a> <ldh-str> <let-dig>
is at least three characters long?  Or, should it be like
     <name> ::= <a> | <a> <let-dig> | <a> <ldh-str> <let-dig>
?

Thanks,  Greg Minshall
 
Subject: RFC821 Question
From: Postel@isif
To: spggm%ucbopal.cc@BERKELEY

Greg:

That is a documentation bug.  What is needed is a nested set of
option brackets.

<name> ::= <a> [[<ldh-str>] <let-dig>].

--jon.
-------

Date: Sat, 21 Apr 84 22:03:47 cst
From: smoot@ut-sally.ARPA (Smoot Carl-Mitchell)
Posted-Date: Sat, 21 Apr 84 22:03:47 cst
Message-Id: <8404220403.AA23099@ut-sally.ARPA>
Received: by ut-sally.ARPA (4.22/4.22)
	id AA23099; Sat, 21 Apr 84 22:03:47 cst
To: MRC@SU-SCORE.ARPA
Subject: Re: "blaming Unix SendMail"
Cc: Header-People@MIT-MC.ARPA

Certainly life will be simpler when the ARPA domain addressing
is adopted as a standard.  I do know that UUCP addressing was
a consideration in sendmail's design.  Also it was designed to
operate in a heterogenous mail syntax environment.  I'll be happy
when the ARPA domain addressing with nameservers becomes the standard
because then the software becomes a lot simpler.

I agree that relative addressing is a drag and I'll be happy when
UUCP adopts absolute addressing.  

I might point out that I have used sendmail to implement a local
mail domain here at the University of Texas connecting 4 Vaxen, one 11/70,
four SUNs and a DEC-20 (the DEC-20 did not use sendmail).  Our network situation
is very ad-hoc.  We have three machines on the internet and currently
have two discontiguous ethernets.  The two ethernets are linked via
a UUCP link.  Yet with this situation I was able to quickly build
sendmail configuration files for all the systems which allows 
absolute addressing between all these machines, no matter 
what the underlining routing which could include routing over a dialup
line, through our IMP, or via an ethernet.  I would certainly 
like to know if other mail delivery systems have that flexibility. 

Date: 24 Apr 1984 02:22:53-EST
From: allegra!hou3c!ka at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA04407; Mon, 23 Apr 84 15:46:26 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
From: allegra!hou3c!ka (Kenneth Almquist)
Subject: Re:  Malformed headers
Message-Id: <479@hou3c.UUCP>
Date: Fri, 20-Apr-84 18:24:10 EST
In-Reply-To: <8404201601.AA05840@wisc-crys.arpa>
Organization: Bell Labs, Holmdel, NJ

UUCP mail does not conform to RFC 822.  (Actually, no written standard
for UUCP mail exists, which is one reason for trying to phase it out.)
Context-sensitive parsing is not an "ad hoc" solution; it is a recog-
nition of this situation.

It should be possible to write mail gateway software that will leave
all the exclamation points on the UUCP side.  E. g. this mail could
be given a from line reading "From: ka@hou3c.UUCP" and a return path
reading "Return-Path: <@mit-vax.ARPA,@allegra.UUCP:ka@hou3c.UUCP>".
Alternatively, the full return path could be included in the from line
as well as the return path line.  Are either of these approaches reason-
able?  How many existing mailers will be able to reply to such letters?
				Kenneth Almquist


Date: 24 Apr 1984 02:22:59-EST
From: allegra!hou3c!burl!ulysses!harpo!seismo!uwvax!dave at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA04538; Mon, 23 Apr 84 15:51:19 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA
From: allegra!dave@uwvax.ARPA
Subject: Re:  Malformed headers
Message-Id: <217@uwvax.ARPA>
Date: Sat, 21-Apr-84 08:36:01 EST
Received: by hou3c.UUCP; Mon, 23-Apr-84 15:24:35 EST
References: <479@hou3c.UUCP>
In-Reply-To: <479@hou3c.UUCP>
Organization: U of Wisconsin CS Dept

You probably shouldn't change the 'From:' line if the mailers *all*
understand the 'Return-Path' (remember, not everyone conforms to standards).

4.2BSD sendmail sites should all be able to understand that syntax.  A
site just running uucp.....  I don't know.  I doubt it (our 11/70 w/2.8bsd
couldn't understand that without some serious work on my part).

What's this about phasing out uucp addresses?  I vaguely remember seeing, a
month or so ago, a message stating that uucp was going to be released for
*micros* in the very near future.  Once this is released, uucp addresses will
be permanant, more permanant than even ARPAnet addresses.  If any phasing out
is going to happen, it had better happen fast!
-- 
Dave Cohrs @ wisconsin
...!{allegra,eagle,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave
dave@wisc-rsch.arpa


Date: 24 Apr 1984 02:23:06-EST
From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!hao!hplabs!nsc!chuqui at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA08780; Mon, 23 Apr 84 18:37:37 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1.chuqui 4/7/84; site nsc.UUCP
From: allegra!nsc!chuqui (Chuq Von Rospach)
Subject: Re: "blaming Unix SendMail"
Message-Id: <866@nsc.UUCP>
Date: Sat, 21-Apr-84 12:50:38 EST
Received: by hou3c.UUCP; Mon, 23-Apr-84 18:30:56 EST
References: <8404201631.AA06136@wisc-crys.arpa>
In-Reply-To: <8404201631.AA06136@wisc-crys.arpa>
Organization: National Semiconductor, Sunnyvale

What I've wondered is why someone hasn't simply written a front end that
creates sendmail files. Isn't that what computers are for? (Hmm, with the
complexity of sendmail files, we are probably talking about one whale of a
parser/compiler.... Hmmm... )
-- 
>From under the bar at Callahan's:		Chuq Von Rospach
{amd70,fortune,hplabs,menlo70}!nsc!chuqui	(408) 733-2600 x242

Never give your heart to a stranger, unless you are sure that you are dead.


Date: 24 Apr 1984 02:23:12-EST
From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!ut-sally!jsq at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA08990; Mon, 23 Apr 84 18:43:02 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP
From: allegra!ut-sally!jsq (John Quarterman)
Subject: Re: "blaming Unix SendMail"
Message-Id: <2048@ut-sally.UUCP>
Date: Sat, 21-Apr-84 23:55:26 EST
Received: by hou3c.UUCP; Mon, 23-Apr-84 18:31:22 EST
References: <491@hou3c.UUCP>
In-Reply-To: <491@hou3c.UUCP>
Organization: U. Texas CS Dept., Austin, Texas

There is no advantage in UUCP style a!b!c relative addressing:  it
exists for historical reasons and those of us who deal with the UUCP
network as it stands are forced to deal with it because many (most?)
UUCP sites do not have any way of dealing with Internet-style
addresses.  One hopes the UUCP domain project will allow the phasing
out of the old-style relative addressing, but until then hosts that
deal with both UUCP and the Internet (and CSNET and several local
networks in ut-sally's case) must be able to map between addressing
syntaxes.  We at ut-sally encourage users to enter addresses in
Internet domain syntax and let sendmail call a program to look up a
UUCP route and convert to relative form.  We do not encourage the use
of the relative form; we tolerate it because we still have to.

The problem of bang!decwrl!rhea!bang!user having bang in there
twice was quite common for a while.  DEC's ENET was hooked up to
UUCP in a fashion that pretended all DEC's machines were actually
UUCP sites.  Yet there were at least 20 name duplications:  vortex,
for instance, existed on both sides of the gateway.  The DEC domain
has lately taken on some solidity and addresses now tend to appear
more like bang!decwrl!user%bang.DEC, which removes the problem.
Until the UUCP domain exists, there will always be the possibility
of duplicate sites within the UUCP network proper (seems like there
used to be two machines named "turtlevax").

Religious arguments about "TOPS-20 does it better" are beside the
point:  I've never run across anybody who likes sendmail's configuration
syntax, and I wish somebody *would* write a compiler to convert from
some more reasonable language, but sendmail does get the job done.
(At least when there's somebody as patient as Smoot to make it do it.)
Part of the job *is* converting among diverse addressing syntaxes.
-- 
John Quarterman, CS Dept., University of Texas, Austin, Texas 78712 USA
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsq
					moskvax!kgbvax!mcc!ut-sally!jsq


Date: 24 Apr 1984 02:23:19-EST
From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!rlgvax!cvl!umcp-cs!chris at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA08950; Mon, 23 Apr 84 18:41:47 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
From: allegra!umcp-cs!chris
Subject: Re: "blaming Unix SendMail"
Message-Id: <6689@umcp-cs.UUCP>
Date: Sat, 21-Apr-84 19:01:25 EST
Received: by hou3c.UUCP; Mon, 23-Apr-84 18:32:56 EST
References: <491@hou3c.UUCP>
In-Reply-To: <491@hou3c.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.

Time to toss in another couple of pennies' worth of thought here:

MMDF (the Multi-Channel Memo Distribution Facility) has in interesting
way of "dealing with" UUCP syntax.  The basic idea behind MMDF is
actually quite similar to the ideas now in use in networking,
compiler design, computer design, microprocessor architecture, ...
(i.e., a lot of stuff).  That is:  do things modularly.

MMDF has a central input program (called submit).  This is not
(repeat NOT) a good user interface; all it's good for (and it's
pretty good for it) is taking a mail message (with a sender and a
list of addressees) and putting it into a queue.

It also has a central delivery program (called deliver).  This is
not an SMTP mailer, nor a UUCP mailer, nor anything else, all it's
good for is looking at queued messages and asking another program
to deliver them (or to tell it why it can't deliver them).

It then has a bunch of (mostly tiny) programs to do delivery for
various "channel"s.  There is one for local mail (delivery to
user's mailboxes).  There is another for CSNet PhoneNet mail [which
seems to be by far the buggiest, by the way].  I suppose that by
now there is one for X.25net mail.

And of course, there is one for UUCP mail.  It takes a message and
a list of addressees, breaks up the message (one for each address
as required by some older versions of /bin/rmail), and hands it to
the "uux" program, after editing message headers to match UUCP
requirements.

On the input side, the "/bin/rmail" program is completely rewritten.
It takes in a UUCP mail message and figures out the sender's name,
and the destination address.  It hands to submit a suitably edited
message for delivery to the destination.

-----------------
The interesting point about this whole system is that UUCP-style
addresses are meaningless to the MMDF system and never appear inside
it.  This really has quite a bit of flexibility, because with small
changes to the UUCP-in and UUCP-out programs, you can change the
way the UUCP-world sees you.  You never have to touch the queueing
system.  It also means that one can get rid of UUCP syntax in small,
relatively painless bits at a time.

-----------------
This is not to say that MMDF is the best system there is.  There
were a few bugs in the original distribution, some serious, some
minor, and the code is incredibly inefficient in some respects.
To mail to a mere hundred people takes it many CPU-minutes, inspecting
your five hundred line alias file a hundred times.  A hundred and
fifty messages in the queue, and it takes ten minutes for deliver
to even start delivering.  And to look up a host name alone in the
four or five alias tables can take seconds.  If you put this together
on a Vax 11/780 whose afternoon load average is over 35, you can
have lots of fun trying to send mail.

But on the other hand, there's a new version that uses better
database schemes, multiple queues, etc., which gets around most of
that.  (And I've done some work myself; things are much better now
here.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay


Received: from Semillon.ms by ArpaGateway.ms ; 24 APR 84 01:03:41 PST
Date: 24 Apr 84 01:03:28 PST
From: Murray.pa@XEROX.ARPA
Subject: Re: How many existing mailers will be able to reply to such
 letters?
In-reply-to: <479@hou3c.UUCP>
To: allegra!hou3c!ka@mit-vax.ARPA
Cc: Header-People@MIT-MC.ARPA

I don't know, but I have a data point that might shed some light on the
scene. There is code in our header munger that translates "at" to "@".
It's there because lots of mail software still generates that form of
header.

Your suggestion raises an interesting question. I don't know of any mail
software around here that inspects the Return-Path line. Our mail
gateway adds it, but it also munges the headers well enough so that the
info in the Return-Path line isn't normally needed. Is this the normal
approach? Do any programs out there actually use the info in the
Return-Path line?

Date: 24 Apr 1984 21:00:19-EST
From: allegra!hou3c!burl!we13!ihnp4!drutx!houxe!hogpc!houti!ariel!vax135!floyd!clyde!lda at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA04315; Tue, 24 Apr 84 20:56:13 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site clyde.UUCP
From: allegra!clyde!lda
Subject: Re: arcane sendmail configuration tables
Message-Id: <412@clyde.UUCP>
Date: Sun, 22-Apr-84 16:56:28 EST
Received: by hou3c.UUCP; Mon, 23-Apr-84 21:39:15 EST
References: <8404202031.AA26150@mordred.ARPA>
In-Reply-To: <8404202031.AA26150@mordred.ARPA>
Organization: AT&T Bell Laboratories Whippany NJ


		Why doesn't someone (with lots of spare time) design a more
		reasonable syntax for describing a sendmail configuration and
		then implement a translator from it to the current syntax?

		While they're at it, they could write a translator
		(disassmbler?) from the old syntax to the new to aid in
		incorporating updates.

			I'd do it if I had the time (really!),
			Mark Shoemaker		mas@purdue

As one of my roomates used to say to me when *I* made a statment like that:

	"And if I had a rocket ship, I'd fly to the moon!"
-- 
Larry D. Auton  AT&T Technologies WH 2C-122 (201)386-4272 ihnp4!clyde!lda


Date: 25 Apr 1984 16:57:40-EST
From: allegra!hou3c!burl!rcj at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA18194; Wed, 25 Apr 84 12:46:16 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site burl.UUCP
From: allegra!burl!rcj (R. Curtis Jackson)
Subject: network fans check this out...
Message-Id: <447@burl.UUCP>
Date: Tue, 24-Apr-84 12:06:35 EST
Received: by hou3c.UUCP; Tue, 24-Apr-84 13:45:31 EST
Organization: AT&T Technologies; Burlington, NC

The guy who sent me this is on a broadband cable network with a wide
variety of terminals, micros, minis, and dialups.  Note the double
'ihnss':

>>> From ihnp4!ihnss!ihnss!stevenso Tue Apr 24 09:57:34 1984
>>> Date: 24 Apr 84 09:57:34 CST (Tue)
>>> From: ihnp4!ihnss!ihnss!stevenso
>>> Message-Id: <8404241557.AA14981@ihnp4.ATT.UUCP>
>>> Received: by ihnp4.ATT.UUCP; id AA14981; 24 Apr 84 09:57:34 CST (Tue)
>>> To: ihnss!ihnp4!we13!burl!rcj
>>> Re: micro networks

Hmmm, I wonder what the address would have been from the far side
of a ring network.....
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd clyde ]!burl!rcj


Received: from Semillon.ms by ArpaGateway.ms ; 28 APR 84 19:47:49 PST
Date: 28 Apr 84 19:47:40 PST
From: Murray.pa@XEROX.ARPA
Subject: RFC821/822 updates/extensions
To: Header-People@MIT-MC.ARPA
Cc: Murray.pa@XEROX.ARPA

Does anybody have a collection of updates and/or extensions to
RFC821/822 that are needed by a real world mail system? I already know
about SMTP reply code of 050, MAIL FROM <>, full words for days and
months, BST for a time zone, "."s in the phrase part of a route-addr,
and name "at" host. How many more krocks/tweaks are there in common use
that I don't (yet) know about?



Date: 29 Apr 1984 01:06:02-EST
From: allegra!hou3c!burl!ulysses!harpo!decvax!ittvax!dcdwest!sdcsvax!bmcg!cepu!scw at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA23439; Wed, 25 Apr 84 18:06:02 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site cepu.UUCP
From: allegra!cepu!scw
Subject: Re:  Malformed headers
Message-Id: <233@cepu.UUCP>
Date: Tue, 24-Apr-84 15:51:14 EST
Received: by hou3c.UUCP; Wed, 25-Apr-84 13:13:55 EST
References: <488@hou3c.UUCP>
In-Reply-To: <488@hou3c.UUCP>
Organization: VA Wadsworth Med. Center, LA CA

There is another way:
Mail that goes to ARPA net sites should just be forwarded to (or
torwards a ARPA site), putting your site name in the return path, and
without modifying the destination path. Once the message reaches an
ARPA site the @site.ARPA is removed and the ARPA site turns
the return path into an arpa address by putting @orig.ARPA at the end
of the path, this MUST inhibit the uucp forwarder(s) (once back in uucp
land) from further munging the path.  The message is then forwarded to
the appropiate ARPA (from the To: field) site, from there it is treated
as a normal uucp message.

synopsis:
a message from litvax!sender to dartvax!user via arpa land
step 0 (original message):
	to:	decvax!dartvax!user@ucbvax.ARPA
	from:	sender
-------the litvax mailer forwards mail to a cooperating system (cepu)

step 1 (as recieved by cepu):
	to:	decvax!datrvax!user@ucbvax.ARPA
	from:	litvax!sender
-------cepu forwards to a known ARPA site (ucla-locus)

step 2 (as recieved by ucla-locus):
	to:	decvax!dartvax!user@ucbvax.ARPA
	from:	cepu!litvax!sender

-------message goes via ARPA (unspecified path) to ucb-vax

step 3 (As recieved by ucbvax):
	to:	decvax!dartvax!user
	from cepu!litvax!sender@ucla-locus.ARPA

-------ucbvax forwards to next site (decvax)

step 4 (as recieved by decvax):
	to:	dartvax!user
	from:	cepu!litvax!sender@ucla-locus.ARPA

-------decvax forwards to dartvax

step 5 (as recieved by dartvax):
	to:	user
	from:	cepu!litvax!sender@ucla-locus.ARPA

The nice thing about this is that systems only need to know 2 things about
the ARPA net.  (1) it exsists, and (2) the name of a site closer to the
ARPA net than they are.  Smart sites could rerout ARPA bound mail to a
host known to be up, dumb sites would just try to send to to a fixed host.
mail headers of course must conform to RFC822 (or which ever) but it doesn't
require a WHOLE lot of hacking to postman/deliver_mail/what_ever to add
the ability to reconize a ARPA style address and to not mung forward path,
forward with back path or mung address, not touch back path.
Note that mail systems on the ARPA net seem to handle mail like this already
(I have succesfully send mail to decvax from cepu) in addition litvax and
ucla-cime both forward mail to/from ARPA land through my site.  
-- 
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp:	{ {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus       location: N 34 06'37" W 118 25'43"


Date: 29 Apr 1984 01:06:09-EST
From: allegra!hou3c!burl!ulysses!harpo!decvax!mcvax!enea!erix!robert at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA09340; Fri, 27 Apr 84 19:59:52 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site erix.UUCP
From: allegra!erix!robert (Robert Virding)
Subject: Re: "blaming Unix SendMail"
Message-Id: <343@erix.UUCP>
Date: Wed, 25-Apr-84 13:52:00 EST
Received: by hou3c.UUCP; Thu, 26-Apr-84 20:17:19 EST
References: <487@hou3c.UUCP>
In-Reply-To: <487@hou3c.UUCP>
Organization: L M Ericsson, Stockholm, Sweden

Of course the best method is to have a human readable form which is then
parsed into a binary file which sendmail can read. The advantages are
obvious.

Is there any valid reason why this hasn't been done?  "We don't do things
int that way on UNIX" is not a valid reason!

				Robert Virding


Date: 29 Apr 1984 01:06:15-EST
From: allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA09349; Fri, 27 Apr 84 20:00:02 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP
From: allegra!ut-sally!smoot (Smoot Carl-Mitchell)
Subject: Re: "blaming Unix SendMail"
Message-Id: <2137@ut-sally.UUCP>
Date: Fri, 27-Apr-84 09:44:57 EST
Received: by hou3c.UUCP; Fri, 27-Apr-84 13:49:07 EST
References: <487@hou3c.UUCP> <343@erix.UUCP>
In-Reply-To: <343@erix.UUCP>
Organization: U. Texas CS Dept., Austin, Texas

> Of course the best method is to have a human readable form which is then
> parsed into a binary file which sendmail can read. The advantages are
> obvious.
> 
> Is there any valid reason why this hasn't been done?  "We don't do things
> int that way on UNIX" is not a valid reason!
> 
> 				Robert Virding

I think this is a good idea in general.  I have some thoughts on such
an endeavor, but do not have the time to devote to it.  I also
want to see how domain based addressing evolves before tackling such
a task.  I think it is comparatively easy to at least make the
syntax of a configuration file human readable.  I too get tired
of all the "$*$-$+" stuff.
-- 
Smoot Carl-Mitchell, CS Dept. University of Texas at Austin
{seismo, ctvax, ihnp4}!ut-sally!smoot, smoot@ut-sally.{ARPA, UUCP}


Date:     Mon, 30 Apr 84 9:52:22 EDT
From:     Ron Natalie <ron@Brl-Tgr.ARPA>
To:       Header-People@Mit-Mc.ARPA
Subject:  Re:  Malformed headers

This is fine except that in STEP 3, you've saddled UCB-VAX with an
illegal "TO" line as far as the 822 spec goes (although I'm pretty
sure UCB vax can handle it).

-Ron

Date:  Tue, 1 May 84 03:33 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Malformed headers
To:  ron@BRL-TGR.ARPA
cc:  header-people@MIT-MC.ARPA
Message-ID:  <840501073320.124744@MIT-MULTICS.ARPA>

Ron, there is nothing wrong with the TO line in step 3.  There is
nothing in RFC822 that prohibits a local-part of the form
"string1!string2!string3", and UCB-VAX is free to interpret it any way
it wishes, and it wishes to interpret it as a Usenet address.
                                        barmar

Date:  Tue, 1 May 84 03:39 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Malformed headers
To:  header-people@MIT-MC.ARPA
Message-ID:  <840501073922.688491@MIT-MULTICS.ARPA>

Of course, the real problem with Stephen Woods' suggestion is that it
assumes that a Usenet site can figure out how to get the mail to the
UUCP-Arpa gateway without requiring the user to specify the route
explicitly.  If they had this capability then it would only be a small
step to not requiring explicit paths for anything, and they could then
use domain addressing, and there would be no problem of ambiguous syntax
to solve.
                                        barmar

Date:     Tue, 1 May 84 16:10:25 EDT
From:     Ron Natalie <ron@Brl-Tgr.ARPA>
To:       Barry Margolin <Margolin@mit-multics.arpa>
cc:       ron@brl-tgr.arpa, header-people@mit-mc.arpa
Subject:  Re:  Malformed headers

But an address must have soething to the right of the "@" and must
contain the "@" as well!

-Ron

Date:  Tue, 1 May 84 16:44 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Malformed headers
To:  Ron Natalie <ron@BRL-TGR.ARPA>
cc:  header-people@MIT-MC.ARPA
In-Reply-To:  Message of 1 May 84 16:10 EDT from "Ron Natalie"
Message-ID:  <840501204450.711421@MIT-MULTICS.ARPA>

    Date:  1 May 1984 16:10 edt
    From:  Ron Natalie <ron at BRL-TGR>
    Subject:  Re: Malformed headers

    But an address must have soething to the right of the "@" and must
    contain the "@" as well!

    -Ron

Once a messagessed to foo@bar is received by bar it may convert the
address into any internal form it pleases, which generally begins by
removing the "@bar".  After UCLA-LOCUS forwards the message to UCB-VAX
it is no longer in an SMTP environment, so @'s are no longer needed.

Perhaps the wording of the steps was misleading, and I was inferring
something different from you.  It says that the header in step 3 was the
way the message was received by UCB-VAX.  I interpreted that to mean
that this was what the header looked like after UCB-VAX received and
munged it.

Anyway, we are arguing minor semantics.  The point of the message is
obvious:  UUCP hosts are all expected to know a route to an Arpa
gateway, so the explicit route (with !'s) only has to be specified for
the part of the route after traversing the Arpanet.  As I said in a
previous message, this is not realistic.  What is to stop hosta from
thinking hostb is closer to the Arpanet and vice-versa, causing all Arpa
mail from or thru either host to loop forever?
                                        barmar

Received: by sri-tsc.arpa at Thu, 3 May 84 01:14:10 pdt
Message-Id: <8405030814.AA04439@sri-tsc.arpa>
Date:  3 May 1984 0114-PDT (Thursday)
From: Greg Satz <Satz@SRI-TSC>
To: header-people@mc
Cc: 
Subject: bogus headers

Why are illegal mail headers being sent out by MIT-VAX?  Particularily,
the dual from line is rather annoying.
------- Forwarded Message
Return-Path: <@MIT-MC:allegra!hou3c!ka@MIT-VAX>
Received: from MIT-MC (mit-mc.arpa) by sri-tsc.arpa at Tue, 24 Apr 84 00:03:44 pst
Date: 24 Apr 1984 02:22:53-EST
From: allegra!hou3c!ka@mit-vax
Received: by allegra.UUCP (4.12/4.7)	id AA04407; Mon, 23 Apr 84 15:46:26 est
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
From: allegra!hou3c!ka (Kenneth Almquist)
Subject: Re:  Malformed headers
Message-Id: <479@hou3c.UUCP>
Date: Fri, 20-Apr-84 18:24:10 EST
In-Reply-To: <8404201601.AA05840@wisc-crys.arpa>
Organization: Bell Labs, Holmdel, NJ

UUCP mail does not conform to RFC 822.  (Actually, no written standard
for UUCP mail exists, which is one reason for trying to phase it out.)
Context-sensitive parsing is not an "ad hoc" solution; it is a recog-
nition of this situation.

It should be possible to write mail gateway software that will leave
all the exclamation points on the UUCP side.  E. g. this mail could
be given a from line reading "From: ka@hou3c.UUCP" and a return path
reading "Return-Path: <@mit-vax.ARPA,@allegra.UUCP:ka@hou3c.UUCP>".
Alternatively, the full return path could be included in the from line
as well as the return path line.  Are either of these approaches reason-
able?  How many existing mailers will be able to reply to such letters?
				Kenneth Almquist



------- End of Forwarded Message

Date: 3 May 1984 05:23:01-EDT
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!drutx!houxe!hogpc!pegasus!hocsd!jis at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA21566; Wed, 2 May 84 23:55:22 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.PCS 1/10/84; site hocsd.UUCP
From: allegra!hocsd!jis
Subject: Re: Malformed headers
Message-Id: <229@hocsd.UUCP>
Date: Wed, 2-May-84 13:10:28 EDT
Received: by hou3c.UUCP; Wed, 2-May-84 22:11:01 EDT
Organization: AT&T Information Systems Labs, Holmdel NJ

SENT-BY: j.mukerji
CC: Margolin@MIT-MULTICS.ARPA

---------------------------------------------------------------------------

	Of course, the real problem with Stephen Woods' suggestion is that it
	assumes that a Usenet site can figure out how to get the mail to the
	UUCP-Arpa gateway without requiring the user to specify the route
	explicitly.  If they had this capability then it would only be a
	small step to not requiring explicit paths for anything, and they 
	could then use 	domain addressing, and there would be no problem of
	ambiguous syntax to solve.

---------------------------------------------------------------------------

Some mailers in the UUCP world already do that, like the one that is being
used for mailing this message does. This one is driven by a set of network
configuration tables, which are updated periodically.

Jishnu Mukerji
AT&T ISLab
Holmdel NJ
jis@hocsd.UUCP


Received: by harvard.UUCP (4.12/4.27)
	id AA13807; Sun, 6 May 84 14:36:15 edt
Date: Sun, 6 May 84 14:36:15 edt
From: morris@harvard (Free Advice)
Message-Id: <8405061836.AA13807@harvard.UUCP>
To: header-people@mit-mc

What are the prospects on official words about top-level domains
other than ARPA? Seems to me there is a conflict here. In order to
make addresses absolute, all hosts have to know about all top-level domains.
If more domains, eg BITNET, UUCP, etc., are officially added, then
official recognition, if not permission, between the Arpanet and
non-DDN nets is implied. If no domains at the level of ARPA are added,
then the domain naming scheme is almost worthless. People on the
arpanet don't need domains, since .ARPA is default and each host knows
about every other one (not strictly true, but mosher%ucbarpa@Berkeley
is absolute without being domain based). Addresses bound from the
arpanet to nets which aren't subsets of the arpanet will either
be absolute without being domain based (uucphost!user@Berkeley),
or will be domain based but not absolute (user@host.BITNET works
from here, but not from most arpanet  hosts).

Any ideas on how this may be resolved?

Robert Morris, morris@harv-10.

Date:  7 May 1984 11:12:36 PDT
From: POSTEL@USC-ISIF
Subject: re: Domains
To:   morris@HARVARD
cc:   header-people@MIT-MC


Robert Morris:

Have your read the RFCs on domains (881, 882, 883, 879)?

Other top level domains will be added.  There are several
requirements that have to be met for something to be a domain.
First, since domains are administrative entities they have to
have a responsible management -  there has to be an individual
in charge of the domain.  Second,  there have to be lookup
servers for the domain data provided - this has to be very
robust.  Third, the domain must have some minimum size - at the
top level probably 100s of hosts.  Fourth,  the top level domains
have to be registered with the NIC.

Another RFC on "domain requirements" is in the works.

--jon.
-------

Received: by harvard.UUCP (4.12/4.27)
	id AA04840; Mon, 7 May 84 20:55:02 edt
Date: Mon, 7 May 84 20:55:02 edt
From: morris@harvard (Robert Morris)
Message-Id: <8405080055.AA04840@harvard.UUCP>
To: postel@isif
Subject: Domains.
Cc: header-people@mc

Thank you, Jon, for your letter and information. I read rfc883 and
admit to being confused. How much of 883 deals with looking up host
numbers (possibly to send mail), and how much deals strictly with
mail? For instance, does one really need a name server for a domain
which is not on the internet, and thus only accessible through a
mail (only) gateway.

In particular, I would like to register a top level domain with a
couple of hundred hosts. There are a few people here who
already have big databases describing it, and are trying to keep
them up to date. We can control the format and so forth of messages
going onto the arpanet.
What I need is clarification of what the name servers are for; I'm
not sure what in rfc883 applies to domains with a single gateway
and no internet host tables.

				Thank you,
					Robert Morris (morris@harv-10)

Date:  7 May 1984 19:47:40 PDT
From: POSTEL@USC-ISIF
Subject: re: domains
To:   morris@HARVARD
cc:   header-people@MIT-MC


Robert:

Enclosed is a note i recently sent to the Namedroppers list that addresses
the point you raise.  (To join Namedroppers send a request to 
"Namedroppers-Request@SRI-NIC.ARPA".)  In general, what ever information
you want hosts in the ARPA-Internet to be able to resolve has to be available
in lookup name servers accessible via ARPA-Internet protocols.  If it is
sufficient that the only thing that can be done is find the Internet Address
of the relay host into your domain then the database is simply the entry
mapping "*.DOMAIN" into "Relay-Host-Address".  If you want ARPA-Internet
hosts to be able to determine before sending mail that the destination host
actually exists, then a full database to the host level is needed. If you
want ARPA-Internet hosts to be able to check if the recipient mailbox is
valid and to determine if there is a forwarding address etc, then a database to that level of detail must be available.

--jon.

Date:  3 May 1984 20:07:38 PDT
From: POSTEL@USC-ISIF
Subject: Inter-Enviromnent Name Service

Hi:

There are two parts to the domain name system.  The first is the 
introduction of domain style names.  The second is the introduction of 
domain name lookup service.

In both cases, the design is intended to be widely applicable in a 
variety of communication environments, not just the ARPA-Internet.

We have a reasonable expectation that the domain style names will be 
used in a variety of environments.  We have (so far) little reason to 
expect that the domain name lookup service will be implemented in any 
environment other than the ARPA-Internet.

However, for a host in the ARPA-Internet to make use of a domain style 
name (from any environment) that host must be able to lookup that name 
using the domain name service via ARPA-Internet protocols.

This means that every domain style name from any environment that is to 
be meaningfull to ARPA-Internet hosts must be listed in some domain name
lookup server in the ARPA-Internet.

Suppose there were some domain (let us call it XYZ) in some environment 
(let us call it PQR) not even sharing any common element with the 
ARPA-Internet or any of the domains overlapping the ARPA-Internet, yet 
communication between hosts in XYZ and hosts in the ARPA-Internet is 
possible via some third parties.  For this communication to be possible,
some domain name lookup servers in the ARPA-Internet would have to be 
able to answer queries about host names in the XYZ domain.

At first blush, this would seem to require that a complete detailed and 
up-to-date copy of the database of hosts from the XYZ domain would have 
to be maintained in a domain name lookup server in the ARPA-Internet, at
locations possibly far removed from any part of the XYZ domain.

But, what is the necessary information in this database?  If, as is 
likely, all the communication between ARPA-Internet hosts and hosts in 
the XYZ domain is routed via a particular relay host, then all the 
entries in the database will point to that relay host.

If it is desired to verify that a particular host name in the XYZ domain
is valid, then the full database is required.  If it is sufficient to 
find the address of the relay to the XYZ domain, then the database can 
be a single entry for the name "*.XYZ" with the address of the relay 
host.  That is, any query with a domain style name ending in ".XYZ" will
match the entry, and will receive a reply indicating the relay host.

Please notice that the situation is symmetric.  If the XYZ domain hosts 
used a procedure similar to that of the ARPA-Internet hosts in resolving
host names then the domains overlapping the ARPA-Internet would have to 
provide databases describing their domains in a form suitable to the 
name servers of the PQR environment. 

--jon.
-------

Date: 7 May 1984 23:00:56-EDT
From: allegra!hou3c!burl!clyde!akgua!sdcsvax!bmcg!cepu!scw at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA03641; Sun, 6 May 84 13:10:57 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site cepu.UUCP
From: allegra!cepu!scw
Subject: Re: routing *TO* ARPA.NET (changed title)
Message-Id: <249@cepu.UUCP>
Date: Fri, 11-May-84 01:09:08 EDT
Received: by hou3c.UUCP; Sat, 5-May-84 22:23:08 EDT
References: <229@hocsd.UUCP>
In-Reply-To: <229@hocsd.UUCP>
Organization: VA Wadsworth Med. Center; LA CA

Two reasonable points have already been raised about my proposal.

  1) What is to keep site a from thinking that site b is a vector to the
     ARPA-net and vice-versa, causing a loop.

Well, I can think of several (1) cooperating systems with hardwired paths
(not elegant but it works reasonably well, this is what is currently in
use around ucla). (2) Looking at the path (don't send it back to someone
that just (or somewhere) had it) this is reasonable, and perhaps should be a
part of any system (3) Routing tables, updated regulary/periodicly.

I would suspect that (3) is the best way to go. Especially if we can implement
some reasonable mechanisim for detecting undelivered messages, picking them
up and forwarding/rerouting them, and perhaps a method of automagicly 
reconfigureing the routing tables.

 2)  This implies that any site need to know how to get to any site on the
    ARPA-NET.  The implication is that this is most of the intra-uucp routing
    problem.

The nice part of this delivery system is that there is NO one ARPA-NET routing
center, by definition *ANY* ARPA host has a complete routing table.  This is
possiable for several reasons. (1) A limited (semi-fixed) number of sites,
unlike uucp.anarchy where systems come and go almost at will, it takes:
(2) A central control point that assigns site numbers (and approves names??),
and limits access to (membership on) the net. (3) Each site has a FIXED name
(number actually) and there is hardware (IMPs?/TIPs?) that does the actual
routing of packets (this is all hearsay, from quite a while ago, and third hand
at that).


NOTE:  This is not attempting to address the problem of intra-uucp domain
addressing, it is only a suggestion for the problem of inter-domain
communications (messages that cross the ARPA-NET/uucp.anarchy) boundry with
some specific path information.
-- 
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp:	{ {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus       location: N 34 06'37" W 118 25'43"


Date: 7 May 1984 23:01:00-EDT
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!stolaf!sys at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA03655; Sun, 6 May 84 13:11:07 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site stolaf.UUCP
From: allegra!stolaf!sys (System Management)
Subject: UUCP style From lines
Message-Id: <1687@stolaf.UUCP>
Date: Sat, 5-May-84 14:46:30 EDT
Received: by hou3c.UUCP; Sun, 6-May-84 07:00:53 EDT
Organization: St. Olaf College, Northfield MN

I am trying to bring sendmail up at stolaf and am having problems with
the UUCP from lines.  I can't seem to get sendmail to either (a) keep the
old From lines or (b) build a From line with what is on the From: line.
I am using 4.2 Mail as rmail.  Can any one out there give me some help?

				Thanks in advance,
				-Paul R Borman
				 St. Olaf College
				 ...{ihnp4,decvax}!stolaf!agnes!paul


Date: 10 May 1984 16:56:01 PDT
From: POSTEL@USC-ISIF
Subject: BATCH SMTP ?
To:   header-people@MIT-MC


I remember talking to some people about a "batch mode" for smtp.  I can't
find my notes about it any more.  Does anyone remember it? Can you give
me a pointer to the people who were working on it?

--jon.
-------

Date:     Fri, 11 May 84 16:11:42 PDT
From:     sventek@lbl-ws.arpa
Message-Id: <840511161118.001@lbl-ws.arpa>
Subject:  Re: Batch SMTP?
To:       postel@usc-isif.arpa
cc:       header-people@mit-mc.arpa, mo@lbl-csam.arpa

Jon,

     The original proposal for batch mode SMTP was made by Mike O'Dell while
he was here at LBL.  He can be reached at mo@lbl-csam.arpa.  It turns out
that his ideas were adopted for use in BITNET.  Maybe someone else on the
list can point you to the document describing their batch mode variant.

                                           Joe Sventek

Date:     Fri, 11 May 84 19:48:44 EDT
From:     Ron Natalie <ron@Brl-Tgr.ARPA>
To:       POSTEL@usc-isif.arpa
cc:       header-people@mit-mc.arpa
Subject:  Re:  BATCH SMTP ?

What I recall is that the BITNET mailer uses something called BSMTP.
Since all they have is file transfer, they transfer a file with the
SMTP commands and then get one back with the replies.  Solomon from
UWISC mentioned it at the gateway meeting.  It comes to mind that it
was Alan Crosswell from Columbia (EACUS@CUVMB on bitnet) who wrote it.

-Ron

Date:     Mon, 14 May 84 16:35:20 PDT
From:     sventek@lbl-ws.arpa
Message-Id: <840514163434.005@lbl-ws.arpa>
Subject:  RFC822 clarification
To:       header-people@mit-mc.arpa

While using a compiler-compiler to replace my ad hoc address parser with a
complete one, I came across an aspect of the RFC822 address specification
which puzzles me.  The offending lines follow

mailbox		= addr-spec
		| phrase route-addr

route-addr	= "<" [route] addr-spec ">"

phrase		= 1*word

word		= atom
		| quoted-string

This indicates that if an user wishes to use a "route-addr" form of address,
at lease one "word" must precede it.  This seems rather silly, since the
"phrase" preceeding the "route-addr" has no semantic value what-so-ever.
What have others done in this case?  In my current ad hoc parser, I do not
require it, in apparent violation of the specification.  I suppose I can
force this restriction upon my users, or automatically generate the atom
Useless Atoms preceeding each "route-addr".

                                     Joe Sventek <sventek@lbl-ws.arpa>

Date:     Mon, 14 May 84 22:04:00 EDT
From:     Doug Kingston <dpk@Brl-Tgr.ARPA>
To:       sventek@lbl-ws.arpa
cc:       header-people@mit-mc.arpa
Subject:  Re:  RFC822 clarification

	The MMDF parser does indeed enforce the restriction that
there be at least one atom before a route-addre specification.
If you don't require this, you are asking for trouble when the
mail leaves your host.  It may be silly, but its in the spec, Sigh.

					Cheers,
						-Doug-

PS.  When you get your parser done, I'd love to see it....

Date: 14 May 1984 21:09:31 PDT
From: POSTEL@USC-ISIF
Subject: Batch SMTP
To:   header-people@MIT-MC


Thanks to all those who sent me information or references for Batch SMTP.

It is indeed a batch style use of SMTP to deliver a bunch of messages in
one direction and sometime later receive a bunch of responses.

It was created and evolved by Mike O'Dell, Greg Minshall, and Alan Crosswell.

It is used in some parts of BITNET, particularly at Berkeley.

A six page description of it was prepared by Alan Crosswell.

--jon.
-------

Date:     Tue, 15 May 84 11:08:38 EDT
From:     Ron Natalie <ron@Brl-Tgr.ARPA>
To:       sventek@lbl-ws.arpa
cc:       header-people@mit-mc.arpa
Subject:  Re:  RFC822 clarification

Your understanding is correct. I've run into machines that gag when you
give the address inside "< >" and don't have the phrase in front.

-Ron

Date: Tue, 15 May 84 16:00:39 cdt
From: smoot@ut-sally.ARPA (Smoot Carl-Mitchell)
Posted-Date: Tue, 15 May 84 16:00:39 cdt
Message-Id: <8405152100.AA23211@ut-sally.ARPA>
Received: by ut-sally.ARPA (4.22/4.22)
	id AA23211; Tue, 15 May 84 16:00:39 cdt
To: header-people@mit-mc.ARPA
Subject: add to mailing list

Please add me to the mailing list.

Date:           Tue, 15 May 84 19:24:28 PDT
From:           Rich Wales <v.wales@UCLA-LOCUS.ARPA>
To:             Joe Sventek <sventek@LBL-WS.ARPA>
CC:             Header-People@MIT-MC.ARPA
Subject:        Re: RFC822 clarification (token before "route-addr")
In-reply-to:    Joe Sventek's message of Mon, 14 May 84 16:35:20 PDT

Joe --

I agree with you that requiring a "phrase" token before a "route-addr"
makes no sense.  This was almost certainly an oversight in the specifi-
cation.  However, the fact remains that this is the way the standard was
written, and some mail systems (such as MMDF, apparently) do demand that
this part of the standard be obeyed strictly.  At this stage of the
game, I'm afraid that no amount of protest is going to result in any
changes to RFC822, however trivial they may seem (I know -- I've tried).

Given this reality, I would suggest the following course of action:

(1) When analyzing the headers in incoming mail, if you see an address
    consisting of a "route-addr" without a preceding "phrase", go ahead
    and accept it.  Some people, I know, may protest that the only way
    to enforce compliance with the standard is to adamantly complain
    about any and all violations; I choose not to take such a stand.

(2) When processing outgoing mail, if you see an address consisting of
    a "route-addr" without a preceding "phrase":

    (a) If the address is not a "source route" of the form <@A:B@C>,
	simply strip off the angle brackets; they are unnecessary.

    (b) If the address is a "source route", then you really should add
	something in front of the address; for lack of anything better,
	I would suggest copying the "local-part" of the address.  That
	is, an address like

		<@UCLA-LOCUS.ARPA:wales@UCLA-CS.ARPA>

	would become

		wales <@UCLA-LOCUS.ARPA:wales@UCLA-CS.ARPA>

While you're at it, by the way, I would suggest a similar approach to
the question of "phrase"s with periods in them.  That is, an address
like

		Richard B. Wales <wales@UCLA-LOCUS.ARPA>

violates the standard because of the period after the initial.  This
restriction has a little bit more to say in its favor (it seems that
allowing the period would complicate the parser and/or the lexer), but
enough hosts still generate such constructions -- whether out of lazi-
ness, rebellion, or lack of time, I will not venture a guess -- that it
is reasonable to recognize and accept them on incoming mail if possible.
(The appropriate action in the case of outgoing mail is to put double
quotes around the "phrase".)

-- Rich <wales@UCLA-LOCUS.ARPA>

Date: Wed, 16 May 84 08:36:46 cdt
Message-Id: <8405161336.AA10157@wisc-crys.arpa>
Received: by wisc-crys.arpa (4.22/3.7)
	id AA10157; Wed, 16 May 84 08:36:46 cdt
To: header-people@mit-mc.arpa
Subject: what to do with (as yet) illegal domains
Cc: ibm-project@wisc-crys.arpa
Sender: forwarder@wisc-crys.arpa
From: solomon@wisc-crys.arpa

We are in the process of setting up a BITNET/CSNET mail forwarder
and are trying to figure out the best way to munge addresses of
mail from BITNET to ARPANET.  When we get the mail, we expect it
to have an 822 header (actually 733, but that's another story) with
something like USER@BNETHOST in the From: field.  We intend to
munge it to something like EITHER

	(1) <@WISCVM.ARPA:USER@BNETHOST.BITNET>
(yes, I guess with some noise before the "<"), OR
	(2) USER%BNETHOST.BITNET@WISCVM.ARPA

(Of course, we expect to accept either form.) Alternative (1) adheres
better to the spirit of current Arpanet standards, while (2) adheres to
de facto current practice, as well as the current letter of the law,
since the "illegal" domain ".BITNET" appears only as part of the local
part of the address.  Ultimately, of course, we'd like to set up a
BITNET domain (I don't care if it's a top-level or lower-level domain)
complete with a full Domain Name Server, and allow Internet users
simply to type USER@BNETHOST.BITNET.EDU (or whatever).

Does anybody have any opinions about this?  Would anybody mind if
a source-route has an unknown domain in other than the first position?

Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2631046869802761@MIT-MULTICS.ARPA>; 16 May 1984 18:21:09 edt
Date:     15-MAY-1984 12:45 EST
From:     OBERST%EDUCOM.MAILNET@MIT-MULTICS
To:       HEADER-PEOPLE@MIT-MC.ARPA
Subject:  REF: SVENTEK@LBL-WS.ARPA "RFC822 clarification"

there was a heated exchange a while back on header-people on the point
you raised.  It got started off with complaints about having to quote
names which used middle initials (and a period) as the phrase.  You're
right, if you want to used a rout-addr, you should put a 'phrase' in front.
Thus if you want to construct a path for a reply from header information,
you would be forced to insert 'phrase'.  Normally this is a person's
first&last name, but I suppose one could put in something like
   The following is a route address <route-addr>

******

Date:     Wed, 16 May 84 13:45:02 EDT
From:     G B Reilly  <reilly@udel-relay>
To:       solomon@wisc-crys.arpa
cc:       header-people@mit-mc.arpa, ibm-project@wisc-crys.arpa
Subject:  Re:  what to do with (as yet) illegal domains

We've been set up to accept both BITNET and MAILNET addresses for
some time now.  The position we take is that addresses destined for 
the Internet should be of the form:

	name%BTHOST.BITNET@UDEL-RELAY.ARPA

But, in inbound mail we accept this form, and the "name@BTHOST.BITNET"
as destined for the mailnet site (remember that all that is left of the ":"
is informational only.)


Brendan

Date: 17 May 1984 23:35:37-EDT
From: allegra!hou3c!burl!clyde!akgua!psuvax!jdi at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA00340; Thu, 17 May 84 17:34:45 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.08 10/3/83; site psuvax.UUCP
From: allegra!psuvax!jdi (John D. Irwin)
Subject: Re: Batch SMTP
Message-Id: <1061@psuvax.UUCP>
Date: Wed, 16-May-84 13:39:09 EDT
Received: by hou3c.UUCP; Thu, 17-May-84 07:30:29 EDT
References: <573@hou3c.UUCP>
In-Reply-To: <573@hou3c.UUCP>
Organization: Pennsylvania State Univ.

I really must mention here that one of the developers of BSMTP (Batch
Simple) is Dr. Robert Owens here at PSU.  He wrote it mainly to handle
mail through the BITNET, since he also wrote the Unix BITNET software.

Unfortunately, it doesn't handle non-smart uucp sites very well so we
still run delivermail (or sendmail).
-- 
Spoken:	John D. Irwin
AT&T:	814-237-5068
Bitnet:	jdi@psuvax1.BITNET
Csnet:	jdi@penn-state.CSNET
Uucp:	{akgua, allegra, cornell, princeton, ihnp4, burdvax}!psuvax!jdi


Date: 19 May 1984 18:46:52-EDT
From: allegra!hou3c!burl!mgnetp!ihnp4!fortune!rpw3 at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA08992; Sat, 19 May 84 14:13:47 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
From: allegra!fortune!rpw3
Subject: Re: what to do with (as yet) illegal dom - (nf)
Message-Id: <3358@fortune.UUCP>
Date: Sat, 19-May-84 04:04:47 EDT
Received: by hou3c.UUCP; Sat, 19-May-84 12:49:55 EDT
Sender: allegra!fortune!notes
Organization: Fortune Systems, Redwood City, CA

#R:wisc-cry:1297456416:fortune:28400003:000:716
fortune!rpw3    May 18 21:17:00 1984

+---------------
| ...We intend to munge it to something like EITHER
| 
| (1) <@WISCVM.ARPA:USER@BNETHOST.BITNET>
| (yes, I guess with some noise before the "<"), OR
| (2) USER%BNETHOST.BITNET@WISCVM.ARPA
| 
| ...Does anybody have any opinions about this?  Would anybody mind if
| a source-route has an unknown domain in other than the first position?
+---------------

Having just composed a long ramble in "net.mail" on quoting, I wonder why
the following would not be both legal and preferred:

  (3) "USER@BNETHOST.BITNET"@WISCVM.ARPA


Rob Warnock

UUCP:	{ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065


Date: Sun, 20 May 84 07:51:53 cdt
Message-Id: <8405201251.AA29512@wisc-crys.arpa>
Received: by wisc-crys.arpa (4.22/3.7)
	id AA29512; Sun, 20 May 84 07:51:53 cdt
To: header-people@mit-mc.arpa
Subject: Internet->USENET gatewaying
Cc: dave@wisc-crys.arpa
Sender: forwarder@wisc-crys.arpa
From: solomon@wisc-crys.arpa

I submitted an item to this group (header-people@mit-mc.arpa) and got
an echo back through the net.mail.headers USENET group.  (For anyone
who doesn't know, USENET is a sort of distributed bulletin-board system
largely (but not entirely) supported by UNIX hosts and the UUCP mail
network).  From the USENET header (cf. RFC850), it appears that the
message was relayed into the USENET system by UUCP host hou3c:

	Path: crystal!uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa

(the entire header is reproduced below).

My question is this whether anyone in UUCP-land can reply to me by mail
based on the information in the header.  Assuming you could somehow get mail
to hou3c with my ARPANET address in the header and/or envelope,
would hou3c be able to send it to me through the Internet?  More specifically,
if someone at (say) ihnp4 sent mail to
	
	mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa

what would happen?  I can't run the experiment here because of the well-known
problem with the ambiguity of a!b@c:  If I send to the path mentioned above,
my local mail system would parse it as "host: wisc-crys.arpa;
local-part: crystal! ... !burl!hou3c!solomon".  Since I don't have an
account at hou3c, that's surely not right.

If you want to reply to me, try:

	Internet or CSNET: solomon@uwisc
	UUCP: ... !{allegra,seismo,ihnp4,ucbvax}!uwvax!solomon

From uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa Wed May 16 08:36:46 1984
Relay-Version: version B 2.10.1 6/24/83; site crystal.ARPA
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
Path: crystal!uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa
From: solomon@wisc-crys.arpa
Newsgroups: net.mail.headers
Subject: what to do with (as yet) illegal domains
Message-ID: <8405161336.AA10157@wisc-crys.arpa>
Date: Wed, 16-May-84 08:36:46 CDT
Date-Received: Wed, 16-May-84 19:55:54 CDT
Sender: ka@hou3c.UUCP (Kenneth Almquist)
Lines: 22
To: header-people@mit-mc.arpa
Cc: ibm-project@wisc-crys.arpa

< body deleted >

Date: 22 May 1984 23:25:17-EDT
From: allegra!hou3c!burl!ulysses!allegra!princeton!tilt!smw at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA16772; Mon, 21 May 84 15:17:06 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site tilt.UUCP
From: allegra!tilt!smw (Stewart Wiener)
Subject: new BITNET site
Message-Id: <122@tilt.UUCP>
Date: Sun, 20-May-84 15:34:56 EDT
Received: by hou3c.UUCP; Mon, 21-May-84 14:56:53 EDT
Organization: Princeton Univ. EECS

Just a friendly reminder to the BITNET gateways out there -- especially Penn
State and Berkeley! -- do you have the new BITNET site PUCCUTS in your site
tables?  It's a satellite of PUCC, running Amdahl UTS.
--
Stewart Wiener / Princeton Univ. EECS / UUCP:	 princeton!tilt!smw
					ARPA:	 princeton!tilt!smw@seismo
					BITNET:  q2933@puccuts


Received: from NJIT-EIES by MIT-MULTICS.ARPA with Mailnet id <2631638850747017@MIT-MULTICS.ARPA>; 23 May 1984 14:47:30 edt
Date:       Wed, 23 May 84  8:42:45 EDT
From:       "Thomas A. Moulton" <995@NJIT-EIES>
To:         @MIT-MULTICS:Header-People@MIT-MC.ARPA
Subject:    BBS/CBMS Confiscation
Message-ID: <M17.7818@NJIT-EIES>

This is totally off the subject, but i just wanted to get a copy of this
out into arpa, etc
and is FYI
(this also may show that the US laws need work...)
C685 CC944  JACK POWERS (JACKP,218)   5/22/84   8:06 PM  L:30
KEYS:/1984 IS HERE/EIES COULD BE A VICTIM TOO!/


 -------------------- begin forwarded message --------------------
 Subject: BBS Confiscation

 I think the following message retrieved from Compuserve deserves
 widespread circulation; no further explanation needed:
 ---
  #: 91655      Sec. 0 - Communications
 Sb: Important warning! 20-May-84  00:48:44
 Fm: - tom tcimpidis 70250,323
 To: all

 On May 16 I was served with a search warrant and my system seized because of a
 message that allegedly had been left, unknown to me, on one of the public
 boards. This was done by the L.A.P.D. under direction of a complaint by Pacific
 telephone. All Sysop's should be warned that under present law (or at least the
 present interpetation) they are now responsible for ALL information that is
 left or exchanged on their system and that ANY illegal or even questionable
 activities, messages or even public outpourings are their direct legal
 responsibility and that they will be held directly accountable regardless of
 wether or not they knew of it, used it, and regardless of any other
 circumstances! Yes, it is unjust. Yes, it is legally questionable. But it, for
 the moment, seems to be enforcable and is being "actively pursued" as a felony.
 Tom Tcimpidis - Sysop of The MOG-UR's HBBS (366-1238).  Mailing: P.O. Box 5236,
 Mission Hills, CA 91345.

         I would appreciate it if this message was spread to as many systems as
 possible so that the word may be spread to the greatest number of Sysops.  1984
 may, indeed, be here...
 ----

Received: from NJIT-EIES by MIT-MULTICS.ARPA with Mailnet id <2631686117243561@MIT-MULTICS.ARPA>; 24 May 1984 03:55:17 edt
Date:       Wed, 23 May 84 15:46:06 EDT
From:       "Thomas A. Moulton" <995@NJIT-EIES>
To:         @MIT-MULTICS:Header-People@MIT-MC.ARPA
Subject:    Addressing people across networks
Message-ID: <M17.7996@NJIT-EIES>

I like @HOSTA:USER@HOSTB best of the choices...

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA16681; Tue, 29 May 84 14:35:56 pdt
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14.3/4.16) id AA11252; Tue, 29 May 84 14:36:36 pdt
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.16) id AA09099; Tue, 29 May 84 14:36:02 pdt
Date: Tue, 29 May 84 14:36:02 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8405292136.AA09099@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: SMTP for IBM VM

It looks like there may finally be a SMTP for the IBM VM world.
Bill Wells
wcwells@Berkeley.ARPA
ucbvax!wcwells
------------------------------------------------------------------------------
Message-Id:  <8405290304.AA21094@wisc-rsch.arpa>
Date:  Mon, 28 May 84 22:04:16 cdt
From: lhl @ wisc-rsch.arpa
Sender:  forwarder@wisc-rsch.arpa
To: TCP-IP @ SRI-NIC
Subject:  Networking Software Available for IBM VM Computers

Text: 
     The University of Wisconsin has implemented the DOD Internet
protocols  (FTP/SMTP/Telnet/TCP/IP) for IBM VM systems under con-
tract to IBM.  This software package, called WISCNET, is owned by
IBM.  IBM has licensed Wisconsin to distribute WISCNET to univer-
sities and colleges.  Source code will be included with the  dis-
tribution, which will begin in mid-June.

     To receive WISCNET, a university  or  college  must  sign  a
license  agreement  with  the  University  of Wisconsin and pay a
one-time distribution fee of $500.  Licenses may be obtained from
and should be returned to:

     Lawrence H. Landweber
     Computer Science Department
     University of Wisconsin - Madison
     1210 W. Dayton St.
     Madison, WI 53706

     ARPANET, CSNET: landweber@wisc-rsch.ARPA
     UUCP:           ...!{seismo,allegra,ihnp4}!uwvax!landweber

Documents describing WISCNET will be sent with licenses.

BRIEF OVERVIEW OF WISCNET

WISCNET includes:

(1)  An implementation of the standard DOD protocols TCP  and  IP
     under VM/SP Release 2 or 3.

(2)  Implementations of the higher-level DOD protocols FTP, SMTP,
     and Telnet.

(3)  An interface between SENDFILE and SMTP.

(4)  Interfaces from IP to the Ethernet  and  Pronet  local  area
     networks (using a DACU as described below).

(5)  An interace from IP  to  the  Telenet  public  data  network
     (using a Series/1 as described below).

     TCP/IP runs in a separate disconnected  virtual  machine  on
the  VM  host.   Similarly,  each of SMTP, server FTP, and server
Telnet occupies a dedicated virtual machine.  User FTP  and  user
Telnet  run  within  a user's virtual machine under CMS.  Virtual
machines communicate with one another using the  Virtual  Machine
Communication Facility (VMCF).

     The VM software is written almost entirely in Pascal, with a
small amount of assembler-language support. Standard IBM-released
software is used throughout (i.e., no modified or unreleased sys-
tem software has been employed).

     Local area network interfaces are available for Pronet (Pro-
teon  Corp. - 10 Megabit/sec token ring) and Ethernet (Interlan -
10 Megabit/sec). The IBM host is connected to  these  local  area
networks  via  a  Device  Access  Control Unit (DACU), which is a
UNIBUS-to-channel adapter sold by IBM.  There is also  an  inter-
face  to the Telenet public data network, using an X.25 implemen-
tation running on a channel-attached Series/1 front  end  running
the  RPS operating system.  The latter interface allows CSNET IBM
VM hosts to connect to the DARPA Internet via Telenet.
 
-------------END OF FORWARDED MESSAGE(S)-------------

Received: by mit-eddie.Mit-chaos.Arpa id AA10839; Sat, 2 Jun 84 03:17:19 edt
Date: Sat, 2 Jun 84 03:17:19 edt
From: Greg Skinner <gds@mit-eddie>
To: header-people@mc
Subject: Date: field in UUCP mail

I don't know if this has been discussed before, but has anyone noticed
that mail sent between certain UUCP sites (I think the ones that run the
4.12/4.7 version) do not leave the original Date: filed of the sender but
replace it with the Date: field of the relaying site?

using arpanet mail because (sigh) our news link is converting to 4.2 ...
--gregbo

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632700137010041@MIT-MULTICS.ARPA>; 04 Jun 1984 21:35:37 edt
Date:        01 Jun 84 16:18 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@MIT-MC.ARPA
Subject:     Multiple SENDER-s?
Message-ID:  <57547@QZCOM>

How strict is the RFC822 rule that a message can only have one
SENDER.

Example: User A forwards a message to RA, and user B forwards
the same message to RB. To save transfer costs across the Atlantic,
only one copy of the message is transferred, with both RA and
RB as SMTP-receivers, and included in TO, CC or BCC fields.
How would you advise me to handle this case?

(At present I never generate any SENDER fields, just because
I do not understand how to handle multiple sender-s.)



Date:  5 Jun 1984 11:29:06 PDT
From: POSTEL@USC-ISIF
Subject: multiple senders ?
To:   header-people@MIT-MC


In the RFC 822 world a message has one sender.  The "from" is the author or
authors of the message.  The "sender" is the clerk that pushed the final
button that sent the message.  When a message is forwarded it is really a
new message and should have (at least) additional header fields added to
indicate who did the forwarding and when (resent-sender, resent-from, 
resent-date).  If two different people (say, Fred and Sam) get copies of a
message and both forward it to a third person (say, Joe), then the third
person (Joe) will get two copies -- but, he (Joe) will be able to see 
when and by whom each copy was forwarded.

--jon.
-------

Date:     Thu, 7 Jun 84 16:42:04 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       header-people@mit-mc.ARPA
cc:       postmaster@rutgers.ARPA, postmaster@purdue.ARPA, postmaster@usc-eclb.ARPA, 
          postmaster@dec-marlboro.ARPA, postmaster@bnl.ARPA, 
          sun!l5!gnu@ucb-vax.ARPA
Subject:  Date format survey.

Well, I thought I had a program for parsing RFC822 dates that worked
pretty well incorporating some of the common illegal formats that are
being used such as out of order days of week (I through it away), years
greater than 100, spelled out month names, misplaced commas, etc...
but I ran it on my current mail and the following hosts got caught:

	sun!l5@ucb-vax
	RUTGERS,
	PURDUE,
	USC-ECLB,
	DEC-MARLBORO,
	BNL

The errors in these cases were either the lack of separation between
the hours and minutes of the time (the colons are obligatory) or using
hyphens to separate the day of month and year from the month name.

-Ron

Received: by YALE-BULLDOG via CHAOS; Wed, 13 Jun 84 21:48:22 EDT
Received: from YALE-RING by YALE-RES via CHAOS; Wed, 13 Jun 84 21:36:47 EDT
Subject: SMTP "MAIL FROM:"
Date: Wed, 13 Jun 84 21:36:53 EDT
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: header-people@MIT-MC.ARPA

The SU-SHASTA.ARPA SMTP mailer likes to send out SMTP MAIL commands
that look like:

    MAIL FROM:<foo@shasta>

It turns out that for obscure reasons (that probably indicate a
deficiency in my own mail system), the fact that it says "shasta"
and not "su-shasta.arpa" screws me up.  But is it not reasonable to
expect that all addresses presented in the SMTP transaction are the
official names, not nicknames?

                    -- Nat

Date: Thursday, 14 Jun 1984 00:32-PDT
To: Nathaniel Mishkin <Mishkin@YALE.ARPA>
Cc: header-people at MIT-MC.ARPA <header-people@MIT-MC.ARPA>,
        mann at Pescadero <mann@Pescadero>
Subject: Re: SMTP "MAIL FROM:"
In-Reply-To: Your message of Wed, 13 Jun 84 21:36:53 EDT.
From: Steve Hartwell <hartwell@Shasta>

>>  The SU-SHASTA.ARPA SMTP mailer likes to send out SMTP MAIL commands
>>  that look like:
>>
>>	MAIL FROM:<foo@shasta>

Not anymore.  It now uses official names only.

Yours ever vigilante,

    Steve Hartwell, Stanford	(Hartwell@SU-SHASTA.ARPA, formerly Shasta)

Date: 6 Jul 1984 02:35:27-EDT
From: allegra!hou3c!burl!we13!ihnp4!cbosgd!mark at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA06253; Fri, 6 Jul 84 01:11:47 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP
From: allegra!cbosgd!mark (Mark Horton)
Subject: Re: "blaming Unix SendMail"
Message-Id: <1279@cbosgd.UUCP>
Date: Tue, 17-Apr-84 20:23:25 EDT
Received: by hou3c.UUCP; Thu, 5-Jul-84 23:37:45 EDT
References: <474@hou3c.UUCP>
In-Reply-To: <474@hou3c.UUCP>
Organization: AT&T Bell Laboratories, Columbus


	     Tell me, why does SendMail need such complex configuration files?
	Wouldn't a preferable scheme be to look at ones environment at runtime
	and do the right thing by default?

This is a little like claiming your computer should "do the right thing
by default" when presented with a null program.  "The right thing" is
highly subjective, and probably depends on reading someones mind.  For
example, how should "a!b@c" be interpreted?  "(a!b)@c" as required by
the ARPANET?  "a!(b@c)" as required by existing UUCP software?  Someone
has to make a decision, and this decision must be implemented in the
sendmail config file.  In fact, "looking in ones environment" is done on
UNIX largely by reading a file.  Wouldn't such a file be called a config file?

Sure, sendmail configuration files are complex.  So is machine language.
It doesn't mean that you shouldn't have any machine language on your
machine.  It means you write a compiler from a high level language.

Sendmail's config files are very complex because they do so much.  What
should be done is for someone to write a simple compiler or interactive
front end that asks a few questions and generates the appropriate file.


Date: 7 Jul 1984 22:06:36-EDT
From: allegra!hou3c!burl!mgnetp!ihnp4!stolaf!sys at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA01318; Sat, 7 Jul 84 21:57:30 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site stolaf.UUCP
From: allegra!stolaf!sys (System Management)
Subject: double home address in From: line
Message-Id: <1755@stolaf.UUCP>
Date: Sat, 30-Jun-84 08:17:15 EDT
Received: by hou3c.UUCP; Fri, 6-Jul-84 14:51:52 EDT
Organization: St. Olaf College, Northfield MN

In bringing up sendmail on a v7 machine, I did not define DAEMON,
the result is that whenever I activate the "From:" line in the headers
and send out mail, I get something like "From: stolaf!stolaf!bob (Bob)"
instead of the appropriate "From: stolaf!bob (Bob)".  (Also, on v7, doing
"H?F?From: $q" and putting 'F' in the flags line for the mailer does not
seem to work, I have to nuke the From: line by using "HFrom: $q".  Has
anyone else out there had these problems?  (And preferable, if someone
has, how do I fix them?)

				-Paul R Borman
				 St. Olaf College
				 {decvax,ihnp4}!stolaf!agnes!paul


Date:     Mon, 9 Jul 84 7:15:26 EDT
From:     Dave Crocker <dcrocker%udel-eecis3.delaware@udel-relay.ARPA>
To:       Header-People@mit-mc.ARPA
Subject:  RFC 822 history

Over the past few months, there were some items about the history of
some decisions that were made in 822.  While you all have not doubt
moved on to more weighty matters, I just read the messages and thought
a bit of clarification might be useful.  In a feeble attempt to head
off some of the likely comments, let me add the caveat that what follows
is reporting, only.  The hindsight of experience may well lead you to
(continue to) wish for different choices.

The naming of 'Resent-X' was the result of a small effort at
political sensitivity.  'Remail-xx' and 'Redistribute-xx' were already
in use and the choice of either one could have led the other to have
felt slighted.  In retrospect, I rather like the source of humor that
seems to have resulted.

Requiring a phrase, before a route-address was a more personal (and
obscure) choice.  My feeling was that addresses which have as much
text as an address with full routing information would be
essentially unreadable.  It therefore would be considerate to the
recipient(s) to separate the address information from the reference
to the 'name' of the person owning the cited mailbox.  One note on
this issue indicated that the prefatory phrase had no semantics; that
is not strictly true.  It is supposed to be a string that names 
(as opposed to addressing) a person/process/role.  While this has no
semantics for mail-handling software, people tend to find it useful.

The hack of filling in the local-part, in the absence of a sender-provided
string, into the phrase, sounds like an excellent idea.

Well, this ended up as more than reporting.  Still, if anyone responds to
this, note that I am tending to read my mail about once a month, if
that.

Dave

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA21189; Mon, 9 Jul 84 19:24:02 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA
	(4.14/4.20) id AA11373; Mon, 9 Jul 84 19:23:34 pdt
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.20) id AA18079; Mon, 9 Jul 84 19:23:29 pdt
Date: Mon, 9 Jul 84 19:23:29 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8407100223.AA18079@ucbopal.CC.Berkeley.ARPA>
To: Header-People@MIT-MC.ARPA
Subject: Re: "blaming Unix SendMail"
Cc: postmaster@Berkeley

I would like to add to Mark Horton's reply:

	... For example, how should "a!b@c" be interpreted?
	"(a!b)@c" as required by the ARPANET?  "a!(b@c)" as required by
	existing UUCP software?

UUCP and Internet (ARPANET) mail address formats are not compatible.
Note that the "@" has is the primary delimiter in the
Internet mail world and that "!" is the primary delimiter in
the UUCP mail world.

UUCP Mail/Internet Mail gateways should be doing the address conversion
as follows: UUCP to LOCAL, then LOCAL to DOD Internet; and DOD Internet
to LOCAL, then LOCAL to DOD Internet (where LOCAL is a gateway domain
addressing scheme that provides for identification of different
external mail addresses).

If you are using sendmail, I suggest that you adopt the Internet
mail address format as your LOCAL format. Then in the
local mail domain you can use <uucp-address@uucp-neighbor.UUCP>
to identify UUCP addresses locally.

Here are some basic rules that a sendmail mail transport agent
acting as a gateway can follow to handle different address formats.

In the following examples "ucbvax" (@Berkeley) is a UUCP/Internet mail
gateway. And "b@c" is a valid Internet mail address. Note that
mail addresses are modified both at entering the local (gateway) mail
domain and when leaving the local mail domain.


Incoming from 		In the LOCAL		Outgoing to
UUCP mail		gateway domain		DOD Internet mail

From: x!y!z		From: y!z@x.UUCP	From: x!y!z@Berkeley.ARPA
To:   ucbvax!b@c	To:   b@c		To: b@c


Incoming from 		In the LOCAL		Outgoing to
DOD Internet mail 	gateway domain		UUCP mail

From: b@c		From: b@c		From: ucbvax!b@c
To: x!y!z@Berkeley.ARPA To:   y!z@x.UUCP	To: x!y!z


Note that there are two steps in the address conversion. First
the local mail agent information "ucbvax!" (from UUCP) or
"@Berkeley.ARPA" (from Internet) is stripped off, then the local
address remaining is interpreted.

For mail moving across the gateway, "@c" must be a full Internet mail
domain name.  That is a UUCP/Internet gateway should be strict about
only accepting complete addresses from non-local mail transport agents.
If "@c" is not a full domain name, then the gateway can only assume
that "@c" is in the local domain of the mail gateway.

Bill Wells
wcwells@Berkeley.ARPA
WCWELLS@UCBJADE.BITNET
ucbvax!wcwells

Date: 11-Jul-84 18:13:09-UT
From: gross@dcn7
Subject: internetwork addressing questions
To:   header-people@mit-mc


	I have a question or two for the mail wizards out there.  Some of
my concerns are probably old hat and I suspect you old-timers may be tired 
of answering them for us relative newcomers to net-hopping.  Some of these 
questions, however, may actually be interesting.  If there is a document 
(or 2 or 3, like the 'emily post' series), please feel free to point me 
that direction.  Otherwise, I volunteer to collect and summarize all 
responses to produce such a document.  All my questions evolved from the
following situation:
	I occassionally send mail from our ARPANET host to PSUVAX1, which 
is a USENET and BITNET host but not an ARPANET host.  I've used BERKELEY
as my point of departure from Arpaland to Usenet, with an address like

	<U1!U2!...!psuvax1!user@berkeley>, 

which uses the familiar USENET source route as the 'local part' of the 
RFC822 'addr-spec'.  Recently, PSUVAX1 made some changes and I began using 
an address like 

	<user%psuvax1.bitnet@berkeley>, 

which uses the '%' convention and BITNET neither of which I am familiar 
with.  Now I would like to send mail to BURDVAX, which I know that I 
can reach through PSUVAX1 via USENET.  The smart money addressing choice was

	<U1!U2!...!psuvax1!burdvax!user2@berkeley>,

however, I couldn't resist trying

	<burdvax!user2%psuvax1.bitnet@berkeley>,
		or
	<USEnetaddr % BITnetaddr @ ARPAnet>.

I was pretty sure the second would fail because the '%' is nowhere to
be found in RFC822, which means there's no formal operator precedence
between '!', '%', and '@', which means all bets are off.  Sure enough, 
BERKELEY took the first choice but flung the second back into my face.
The second addressing choice (or some legal variant) is my favorite 
because if BITNET is the path of choice to get to PSUVAX1 from here (perhaps
because it's not restricted to source routing like USENET), then I 
shouldn't be forced to use USENET for the whole trip simply due to 
addressing hassles.  I also like it because it uses 3 dissimilar, 
non-traditional-arpa-internet nets (Anyone know a better route involving 
CSNET?).
	My smorgasbord of resulting questions are below.  Again, I will
summarize the results and produce a document that we can point guys
like me toward in the future (unless, of course, one already exists).
To avoid cluttering mailboxes with possibly old issues, replies should 
come directly to me (gross@dcn7), unless of general interest to the group.

	1) I'm familiar with USENET (although a clarification between
UUCP and USENET would be useful), but not with BITNET.  Are there
articles descibing it (like the 10/83 CACM or Sigcomm '83 Proceeeding
articles on CSNET) or can someone give me a paragraph or two.

	2) Since '%' (percent) it isn't part of the RFC822 grammer, what 
does it mean and what is the convention for parsing it?  

	3) Is the "usenetroute@arpahost" convention a Berkeley kludge or
is it a recognized de facto standard of some sort?  

	4) Is there a permissable way to do the ARPA-to-BIT-to-USEnet
addressing implied in the second choice above?  In other words, is there
an accepted way to parse a mixture of '!', '%' and '@' together.  If so, 
how widely would it be accepted?

	5) Who develops these conventions for non-Arpa-Internet inter-
networking and how are they documented?

	6) How do people determine efficient UUCP/USENET source routes?

	7) Are Arpanauts guilty of a narrow worldview or should
non-arpanoids accept the one true way?  (I've asbestos lined my mailbox
for this one, just in case.)  This is another way of asking whether there
may ever be an ecumenical 'son of 822' to codify some of this stuff?

Awaiting Enlightenment,
Phill Gross

-------

Date: 11 July 1984 21:59-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: faulty address change
To: TSDTEST%VPIVAX3.BITNET @ UCB-VAX
cc: HEADER-PEOPLE @ MIT-MC

    Date: 11 July 1984 21:16-EDT
    From: MAILER-DAEMON%ucbjade.CC@Berkeley (Mail Delivery Subsystem)
    Subject: Returned mail: User unknown
    To: <CENT@MIT-MC>
       ----- Transcript of session follows -----
    >>> RCPT To:<JARRELLRA@VPIVAX3>
    <<< 550 Illegal userid for RSCS network.
    550 <JARRELLRA@VPIVAX3.BITNET>... User unknown
       ----- Unsent message follows -----
    Received: from ucblapis.CC.Berkeley.ARPA (ucblapis.ARPA) by ucbjade.CC.Berkeley.ARPA
	    (4.14/4.20) id AA24504; Wed, 11 Jul 84 18:16:58 pdt
    Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucblapis.CC.Berkeley.ARPA
	    (4.14/4.20) id AA16005; Wed, 11 Jul 84 18:16:32 pdt
    Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	    id AA26166; Wed, 11 Jul 84 18:16:33 pdt
    Message-Id: <8407120116.AA26166@UCB-VAX.ARPA>
    Date: 11 July 1984 21:16-EDT
    From: Pandora B. Berman <CENT@MIT-MC>
    Subject: address change
    To: JARRELLRA@VPIVAX3.BITNET
    Cc: HEADER-PEOPLE-REQUEST@MIT-MC
	Date:     Mon,  9-JUL-1984 08:14 EDT
	From: Ronald A. Jarrell <TSDTEST%VPIVAX3.BITNET@Berkeley>
	To: Header-People-Request@mit-mc.ARPA
	Subject:  address change.
	Please change TSDTEST%VPIVAX3.BITNET@berkeley to
	JARRELLRA%VPIVAX3.BITNET at Berkeley.

    done..

well, i did, and tried sending to you at that address, but it didn't work
(UNIX fucked with the header, too). when it does work, please let us know
and we'll try again.

Date: Thu, 19 Jul 84 14:17 PDT
From: Postmaster@LLL-MFE.ARPA
Subject: embedded spaces in mail addresses
To: header-people@mit-mc.arpa

i'm so sick of mailers complaining about quoted addresses with embedded
blanks i could scream.  is it possible to get unix fixed so that it
understands addresses of the form '"provan don"@lll-mfe.arpa', or
should we just flush this syntax?  as long as my syntax is legal, i find
it real hard to justify going to the lengths i'd have to go to make it
some address without any blanks in it.  i've been waiting since i first
brought up SMTP in march '83 for unix to be fixed, but i think it's
time to give up waiting.  i used to send notes to postmasters telling
them we were having problems, but i always got the response that it was
purchased software so they couldn't fix it.  it wasn't so bad when it
was just a couple of cases a month.  i could tell someone to use a user
number instead of a name or change a name to not have a blank in a few
cases.  but now there's been a great surge of interest in the arpanet
mail system so something has to be done.  should i give up?  should i
consider that syntax obsolete and unsupported?  should i just not let my
users communicate with unix sites?

well, to start with, i guess i'll get mad....

Date: 19 Jul 84 1749 EDT (Thursday)
From: don.provan@CMU-CS-A.ARPA
To: header-people@MIT-MC.ARPA
Subject: Re: embedded spaces in mail addresses
In-Reply-To: "Postmaster@LLL-MFE.ARPA's message of 19 Jul 84 16:17-EST"
Message-Id: <19Jul84.174950.DP0N@CMU-CS-A.ARPA>

i forgot i was in an anonymous account when i send the message titled
"embedded spaces in mail addresses."  i hereby accept responsibility
for that message.

Return-Path:<@MIT-MULTICS.ARPA:WILLUT@EDUCOM.MAILNET>
Received: from MIT-MULTICS.ARPA by CMU-CS-A.ARPA; 20 Jul 84 19:09:31 EDT
Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2636665689992730@MIT-MULTICS.ARPA>; 20 Jul 1984 19:08:09 edt
Date:     20-JUL-1984 13:39 EDT
From:     WILLUT%EDUCOM.MAILNET@MIT-MULTICS
To:       DON.PROVAN@CMU-CS-A.ARPA
Subject:  Quotes and spaces in usernames
Resent-To: header-people@MIT-MC.ARPA
Resent-From: don.provan@CMU-CS-A.ARPA
Resent-Date: 20 Jul 84 1932 EDT (Friday)

Some of our MAILNET sites have had a great deal of trouble with quoted
usernames, too.  Thought you might enjoy Alan Hunter's assessment of
the problem (they have now, by the way, changed their system to send
out usernames in the firstname_lastname format)
                                                  --Candy Willut
----------------------------------------
From:     MAILNET        18-MAY-1984 13:11
To:       WILLUT
Subj:     From:<@MIT-MULTICS.ARPA:"Alan Hunter"@Newcastle.Mailnet>

Received: from Newcastle.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2631138437336308@MIT-MULTICS.ARPA>; 17 May 1984 19:47:17 edt
Date: Thu, 17 May 84 16:02:38 BST
From: "Alan Hunter"@Newcastle.Mailnet
To: Steve_Rothwell@UMICH-MTS.MAILNET,
    Gavin_Eadie@UMICH-MTS.MAILNET,
    WILLUT@EDUCOM.MAILNET,
    RUSHBY@SRI-CSL.ARPA
Message-ID: <79269@Newcastle.Mailnet>
Subject: MTS network mail addresses

Steve, Gav:                        cc: Candy, John Rushby

 I spend a lot of time explaining this sort of thing (see following
 message) to users.  I think perhaps the MTS NETMAIL program ought to
 throw in the sponge and sign outgoing messages in the First_Last@Site
 form rather than the equally correct "First Last"@Site.  A lot of our
 mail is to ARPA and CSNET, and UNIX, TOPS and RSX systems in use on
 those nets don't seem to like quotes, even now.  I doubt they ever will.

 I have actually had complaints from SRI-CSL (a Foonly TOPS system)
 saying we send them illegally formatted messages!  So much for the
 success of the #822 revision!

     - Alan
---(Forwarded from: "Alan Hunter"@Newcastle, Dated: Thu, 17 May 84 15:37:28 BST
Brian:                cc: sundry others

 Once upon a time there was a mail system called ARPA.  It had network
 mail gurus who designed a protocol for the presentation of network
 mail messages.  They called this RFC #733 so that everyone would
 instantly know what it was, and respect it as The Truth.

 In the course of time, the gurus found that a number of groups among
 the ARPA proletariat had actually ignored the words of wisdom, and
 implemented what they thought it ought to be rather than what it was
 supposed to be.  Most of these illiterate programmers ran a young
 upstart operating system (the name escapes me) and knew, of course,
 that personal names were things like 'brian' and 'lindsay' and never
 had spaces in them.  So a message to:

     brian randell@newcastle

 clearly had two recipients; some local guy called 'brian' and somebody
 over the net called 'randell'.  Obvious isn't it?  (Actually they were
 supposed to use commas as separators for this case but these people
 never did that at home and didn't see why users of lesser systems
 should need to.)

 Eventually things got so bad that the gurus got together five years
 later and rewrote RFC #733, fixing all the problems and calling it
 RFC #822 which is a much better title.  They said that if a local part
 (that's what gurus have instead of names) had certain characters in
 it, it had to be surrounded by quotes (").  Spaces are one of these
 specials; underbars are not.

 So your messages from MTS go out signed correctly as:

     "Brian Randell"@Newcastle.Mailnet

 Meanwhile the mail types who used that operating system had heard from
 a friend of a friend that 822 wasn't much different to 733, so they
 changed the comment at the head of their mail program to say '822'
 instead of '733'.  All their friends used the same system (other
 people didn't seem to want to talk to them) and anyway they had much
 more fun things to do, because they'd discovered RPCs.

 The gurus got very annoyed with this and have spent the last two years
 issuing RFC's with ever more impressive numbers on them giving ever
 receding dates by which they must comply.  Since the mail implementors
 think they are complying they don't read these either.  They have even
 been known to complain when more up to date sites send them correctly
 formatted messages!

 The MTS mail people, being kind, are prepared to accept recipient's
 names with underbars representing the spaces.  Nor do they care if
 people shout at you and call you BRIAN RANDELL at the top of their
 voice.  Both quoted and underbarred forms are equally valid.  Few
 non-MAILNET-or-BITNET sites can generate our (correct) quoted
 signatures as return addresses.  So I always tell people to quote the
 underbarred form in the message text when establishing a connection.
 You are:

     Brian_Randell@NEWCASTLE.MAILNET

 but these people don't know where that is, so tell them you are:

     Brian_Randell%NEWCASTLE@MIT-MULTICS.ARPA

 They'll think you are being pedantic putting the ".ARPA" on the end
 because they don't believe there is anybody else out there.  They'll
 also think you have a funny name and must live in or near Cambridge,
 Mass., BUT THEIR MESSAGES WILL GET THROUGH.

 I suppose MTS will be reduced to signing messages with underbars one
 day.  Sigh....

       - Alan

Date: Mon, 23 Jul 84 10:12 PDT
From: Postmaster@LLL-MFE.ARPA
Subject: where do error reports go now?
To: header-people@mit-mc.arpa

it has been pointed out to me that RFC822 (4.4.4) says that reports
for undeliverable mail should be sent to the Sender: field (or the
From: field if there's no sender field).  RFC821 (4.1.1, Mail command)
says that non-delivery notices should be sent to the return path passed
in the SMTP Mail command, which, of course, ends up as the Return-Path:
header in the mail.  i'm sure this has been argued about before.  i don't
remember the argument.  anyway, i'm not feeling very argumentative, so i
just want to know which field i should use in my implementation.  presumably
they both point back to the same mailbox, but if they don't, which should
i choose?
						don provan
						provan@cmu-cs-a
						postmaster@lll-mfe

Date:     Mon, 23 Jul 84 21:08:56 EDT
From:     Doug Kingston <dpk@BRL-TGR.ARPA>
To:       Postmaster@LLL-MFE.ARPA
cc:       header-people@MIT-MC.ARPA
Subject:  Re:  where do error reports go now?

	The address given in the SMTP MAIL FROM: command
is the prefered return address for errors.

					-Doug-

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637018731564431@MIT-MULTICS.ARPA>; 24 Jul 1984 21:12:11 edt
Date:        24 Jul 84 15:47 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>,
             Postmaster@LLL-MFE.ARPA
Subject:     embedded spaces in mail addresses
Message-ID:  <63316@QZCOM>
In-Reply-To: <63030@QZCOM>

In the QZCOM mail network interface, I translate internal COM
names of the format "Jacob Palme QZ" into the external mail format
Jacob_Palme_QZ so as to avoid quotes and spaces which some mail
systems cannot handle.

I have never in my life come across a "standard" which in actual
implementation is to blatantly disregarded as RFC822.



Date: 25 Jul 84 1151 EDT (Wednesday)
From: don.provan@CMU-CS-A.ARPA
To: header-people@MIT-MC.ARPA
Subject: re: embedded spaces in mail addresses
Message-Id: <25Jul84.115112.DP0N@CMU-CS-A.ARPA>

I went into the lll-mfe mail server to put in a underbar-equals-space hack
and found i'd already given up on UNIX and put a hash-equals-space
hack (hash because it's the standard around my network) in.
i wonder how many other sites have done the same thing just to
relieve UNIX of the need to fix it.  CMU uses a dot-equals-space
hack, as i'm sure many other sites do from the rfc722 days, but
that's because it's been in so long no one would think of taking
it out.  (it's become a standard all the way to user level.)  everytime
i bitch to a UNIX site, they say, "gee, you're the first site we've
dealt with that had spaces in their user names."  i suspect i'm just
the first to complain about it.

the thing that pisses me off most is that i need to add hashes on
the return addresses of out-going mail even for sites that can handle
spaces.  i think we should all boycott UNIX until the mail system's
fixed.

Date: 25 Jul 84 1954 EDT
From: Rudy.Nedved@CMU-CS-A.ARPA
To: header-people@MIT-MC.ARPA
Subject: Re: embedded spaces in mail addresses
In-Reply-To: <25Jul84.115112.DP0N@CMU-CS-A.ARPA>
Message-Id: <25Jul84.195452.EN0C@CMU-CS-A.ARPA>

For the record:

CMU supports the dot-equals-space hack and actually uses it as "the
way to go" for non-CMU sites because of the belief that most sites do
not have lexically powerful mail systems and can only handle simple
single lexical token <user> @ <host> mail addresses.

We advocate internal CMU mail to use quoted names and that mail user
interfaces/composers are expected to work very hard to resolve a
"name" or "nickname" into an electronic mail address (i.e. 'Mr. E. R.
Nedved' turns into '"Rudy Nedved"@CMU-CS-A.CMU.ARPA').

CMU's 4.1BSD Unix mail system (the majority around here) supports
spaces in names and quoted names. When we upgrade to 4.2BSD or
whatever, the mail system will support quoted names also.

What you want to do is boycott simple mail delivery software that
tries to use a hacked up version of the COPY or CAT program to
move mail around. Given the growing importance of eletronic mail
systems it is amazing that managers have not allocated more
software developement resources into this area.....it still seems
to be under the "general software maintainence" for most sites.

Rudy Nedved
CMU CS/RI Facilities Staff

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637130622486575@MIT-MULTICS.ARPA>; 26 Jul 1984 04:17:02 edt
Date:        25 Jul 84 16:29 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>,
             Postmaster@LLL-MFE.ARPA
Subject:     where do error reports go now?
Message-ID:  <63545@QZCOM>
In-Reply-To: <63431@QZCOM>

I would strongly urge you to send reports for undeliverable mail
to the SMTP sender, not to the FROM or the SENDER in the RFC822
header.

When a mailing list resends a message, it usually will not munge
the RFC822 header, but most mailing list implementations will
put the list maintainer as the SMTP SENDER, and it is the list
maintainer, not the original author, who should get these kind
of messages.

At the same time, I would warn you against doing what some mail
systems do: They send a message saying that "the next message
is a returned undeliverable mail" and then they send the undeliverable
mail as a separate message.

This causes problems at least in my mail system (QZCOM) because
when I get the second message, I immediately note that I already
have that message in my data base, and since there are no new
recipients on it, I will just disregard it. Thus, people will
get a message saying "the next message is an undeliverable mail",
and then they will not get any next message at all.

The principle of sending undeliverable mail as two separate
messages, one with the error message and one with the returned
message, would be a good idea, but only if the first of these
two messages, the error message, contained some identification
of the returned message, the message-id of it and the author
and date fields for example.



Date: Thu, 26 Jul 84 07:53:46 cdt
Message-Id: <8407261253.AA21469@wisc-crys.arpa>
Received: by wisc-crys.arpa; Thu, 26 Jul 84 07:53:46 cdt
To: header-people@mit-mc.arpa
Subject: returned mail under separate cover
Cc: implementors@csnet-sh
Sender: forwarder@wisc-crys.arpa
From: solomon@wisc-crys.arpa

Jacob Palme points out one problem with returning undeliverable mail
in a separate message from the error report (what I'll call "two-message
error reports" or TMER).  I would go further than he did and assert that TMER
is an extremely bad idea.  Another facility interfered with by TMER is 
automated handling of errors.  Error recovery is difficult enough
in the current chaotic mail world; TMER makes it almost impossible.  The
latest version of the CSNET nameserver software provides an example.

The software intercepts outgoing mail and tries to give the sender
additional assistance in getting it to its destination.  It puts
"forwarder" in the "sender" field (and in the SMTP envelope)
so that error reports are returned to a program rather than the original
author (see the header of this message for an example).  This program
queries a central database to see if the failure was due to stale
information (for example, because the recipient has moved).  Only if such
attempts fail does it return the message to the author.  The information
necessary to query the database, and indeed the identity of the original
author is only in the original message.  At the very least, TMER introduces a
headache:  One error message must be queued until the other arrives (note that
there is no guarantee on order of delivery, so the returned mail may precede
the error message!)  In the absence of any standards on how the two messages
identify each other, it is impossible to deal with TMER in any reasonable way.

By the way, another bogosity at some sites pointed up by the new nameserver
software is sites that send replies (mail generated by humans using a "reply"
command in their mail-reading software) to the address in the "sender"
field or the SMTP envelope in clear violation of RFC 822.  From time
to time we get mail addressed to "forwarder" with contents like
"You're right Jim, but I disagree with the third paragraph."  In some
cases it is impossible to figure out who the sender was trying to reach
and we are reduced to returning the mail (by hand) to the sender,
along with a nasty note to the postmaster at the sending site.  Luckily, 
postmasters seem to be reasonably willing to clean up their acts when
they have the problem pointed out.  We haven't had too many try to tell us
they're right and we're wrong.

Received: From hp-labs.csnet by csnet-relay;  27 Jul 84 14:48 EDT
Received: by HP-VENUS id AA02239; Fri, 27 Jul 84 09:44:48 pdt
Date: Fri, 27 Jul 84 09:44:42 pdt
From: Mark Laubach <laubach%hp-labs.csnet@csnet-relay.arpa>
Received: by HP-MARS id AA01099; Fri, 27 Jul 84 09:44:42 pdt
Message-Id: <8407271644.AA01099@HP-MARS>
To: header-people%mit-mc.arpa@csnet-relay.arpa
Subject: embedded blanks in multi-part local names
Source-Info:  From (or Sender) name not authenticated.

While 4.XXBSD might be able to handle quoted strings properly, we've
found some problems dealing with them in the Bell System III and V
OS's.  For that reason, the general consensous among the "mail experts"
within HP, is that we will use the underscore to delimit <first>_<last>
name pairs and do away with the quote problem altogether.

We have a significantly large problem within HP as we support two
completely different mailing domains, the HPDeskManager world,
where everyone has a first and last name, and the HP-UX/Unix world,
which we all know and love.  I'm in the process of completing a
gateway between the two and have come up against this problem.  The
underscore solution seems to be the best alternative.

Mark Laubach
HP Labs Corporate Engineering


Date: 27 Jul 84 1902 EDT (Friday)
From: don.provan@CMU-CS-A.ARPA
To: header-people@MIT-MC.ARPA
Subject: embedded blanks, round two
Message-Id: <27Jul84.190259.DP0N@CMU-CS-A.ARPA>

didn't UNIX SMTP servers used to reject the Mail command if it had
a from field it couldn't send back to?  i just added code to try
a non-quoted from field (with blanks replaced) if the mail command
was rejected with a quoted blanky from field, but now i can find
any mailers that will reject such a mail command.  is this reasonable
behavior?

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637271950399124@MIT-MULTICS.ARPA>; 27 Jul 1984 19:32:30 edt
Date:        27 Jul 84 17:40 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>,
             don.provan@CMU-CS-A.ARPA
Subject:     re: embedded spaces in mail addresses
Message-ID:  <63810@QZCOM>
In-Reply-To: <25Jul84.115112.DP0N@CMU-CS-A.ARPA>

If you want to know if spaces in names are to be recommended,
the right person to ask would be the English language department
at your university. I am quite sure what they would reply!



Date: Fri 27 Jul 84 23:18:04-PDT
From: Charles Hedrick <HEDRICK@SUMEX-AIM.ARPA>
Subject: Rutgers is temporarily off the net
To: tops-20@SU-SCORE.ARPA, header-people@MIT-MC.ARPA,
    paetzold@DEC-MARLBORO.ARPA

Rutgers is in the process of moving from NYU (a DDN node) to
Columbia (an Arpnaet node).  Unfortunately, only half of the necessary
workorders were issued, so our phone line has now been moved, but
not the equipment necessary for us to connect to the IMP.  We hope to
be back on the net sometime this week.  You can contact us via
UUCP through allegra:
  ... allegra!ru-blue!user@color
where color is one of Red, Blue, or Green.  (the Arpanet node is Red.)
You can also send mail to HEDRICK@SUMEX.  I will log in here at least
once a day, and will forward message to others at Rutgers.  However
I will forward them by writing them down and resending them, so please
only use this for critical cases.
-------

Date:     Sun, 29 Jul 84 15:45:01 PDT
From:     sventek@lbl-ws.arpa
Message-Id: <840729154437.002@lbl-ws.arpa>
Subject:  Group addresses
To:       header-people@mit-mc.arpa

How do others handle the <group> construct in their parsers?  Since the body
of the group can be 0 or more <mailbox>s separated by commas, 822 requires that
the parser be able to handle an unlimited amount of input before determining
that there is an error.  If one is trying to do a parser for use in non-virtual
memory systems, one cannot count on being able to buffer all input until the
trailing ';' is seen.

By the way, for our own system, we do not use the group:; construct for
distribution lists.  We maintain a set of system alias definitions which are
referred to in the same way as user mailboxes.

Please address replies to me, and I will summarize for the list, if there is
interest.

                                Joe Sventek <sventek@lbl-ws.arpa>

Date: 1 Aug 1984 08:57:24-EDT
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!dual!amd!decwrl!decvax!harpo!whuxle!akgua!psuvax1 at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA12765; Wed, 1 Aug 84 08:47:19 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.08 10/3/83; site psuvax1.UUCP
From: allegra!psuvax1!jdi (John D. Irwin)
Subject: Re: internetwork addressing questions
Message-Id: <1102@psuvax1.UUCP>
Date: Thu, 19-Jul-84 10:06:03 EDT
Received: by hou3c.UUCP; Tue, 31-Jul-84 23:31:21 EDT
References: <694@hou3c.UUCP>
In-Reply-To: <694@hou3c.UUCP>
Organization: Pennsylvania State Univ.


	Speaking as psuvax1, first I'd like to clear up a couple of mis-
conceptions.  First of all, our switch to 4.2 OBVIATED the need for a '%',
not required it.  Currently if you can get mail to us through whatever
net that is 822 we will send it on (except for a teeny uucp problem we're
working on)

Thus        djb@burdvax.UUCP.BITNET

sent to us would work.  However, you have a problem in specifying HOW to
get it from Berkeley to us.  Mark, any answers?

-- 
Spoken:	John D. Irwin
AT&T:	814-237-5068
Nets:	jdi@psuvax1.{BITNET,CSNET}
Uucp:	{akgua, allegra, cornell, pitt, purdue, ihnp4, burdvax}!psuvax1!jdi


Date:  1 Aug 1984 at 2334-PDT
From: Andrew Knutsen <knutsen at SRI-UNIX>
To: allegra!psuvax1!jdi at BERKELEY (John D. Irwin)
Cc: Header-People at MIT-MC.ARPA
Subject: Re: internetwork addressing questions
In-reply-to: Your message of 1 Aug 1984 08:57:24-EDT
 Thu, 19-Jul-84 10:06:03 EDT.
             <1102@psuvax1.UUCP>
Sender: knutsen at Sri-Unix

	The basic problem is that ARPA (the US gov't) hasnt declared any
"official" domains other than ARPA. An official domain implys the existence
of a well-maintained nameserver service, and this does not exist for
uucp, or bitnet for all I know. Thus on the arpanet, ARPA must be top
level, and subdomains must be in the "local part".

	Kind of a silly situation, but the good side is that it encourges
the formation of the nameservers. Apparently things are coming along on
the uucp and csnet fronts.

AK

Date: 2 Aug 1984 16:40:29-EDT
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!cbosgd!mark at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA18393; Thu, 2 Aug 84 09:22:53 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP
From: allegra!cbosgd!mark (Mark Horton)
Subject: Re: internetwork addressing questions
Message-Id: <160@cbosgd.UUCP>
Date: Thu, 26-Jul-84 23:16:14 EDT
Received: by hou3c.UUCP; Wed, 1-Aug-84 09:30:56 EDT
References: <694@hou3c.UUCP>, <1102@psuvax1.UUCP>
In-Reply-To: <1102@psuvax1.UUCP>
Organization: AT&T Bell Laboratories, Columbus

There must be lots of machines that talk to both ucbvax and
psuvax1 - cbosgd for example.

But I confess I can't understand why djb@burdvax.UUCP.BITNET
would be a useful address.  If your system understands BITNET
but not UUCP, then djb%burdvax.UUCP@psuvax1.BITNET or the
more intended @psuvax1.BITNET:djb@burdvax.UUCP ought to work.
>From the ARPANET I think Berkeley will gateway to BITNET,
from CSNET there's probably a gateway somewhere too.
>From UUCP it depends on what software you have and where you
want to send the mail.


Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637963057983948@MIT-MULTICS.ARPA>; 04 Aug 1984 19:30:57 edt
Date:        04 Aug 84 18:27 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             "(John D. Irwin)" <allegra!psuvax1!jdi@BERKELEY>,
             "Andrew Knutsen" <knutsen@SRI-UNIX>
cc:          header-people <header-people@MIT-MC.ARPA>
Subject:     Re: internetwork addressing questions
Message-ID:  <64745@QZCOM>
In-Reply-To: <64572@QZCOM>

Why does an official domain imply the existence of a well-maintained
nameserver service.

I can understand that they may require that an official domain
implies the existence of a well-maintained nameserver service
for host names (and in the case of relative nets like UUCP also
pathes to them), but a name server for user names within a host
does not seem to be necessary.



Date: 6 Aug 1984 13:09:00-EDT
From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hao!seismo!uwvax!dave at mit-vax
Received: by allegra.UUCP (4.12/4.7)
	id AA03652; Mon, 6 Aug 84 09:47:11 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA
From: allegra!dave@uwvax.ARPA
Subject: Re: embedded spaces in mail addresses
Message-Id: <361@uwvax.ARPA>
Date: Wed, 1-Aug-84 10:02:38 EDT
Received: by hou3c.UUCP; Fri, 3-Aug-84 18:18:58 EDT
References: <703@hou3c.UUCP>
In-Reply-To: <703@hou3c.UUCP>
Organization: U of Wisconsin CS Dept

>                         is it possible to get unix fixed so that it
> understands addresses of the form '"provan don"@lll-mfe.arpa', or
> should we just flush this syntax?  as long as my syntax is legal, i find
> it real hard to justify going to the lengths i'd have to go to make it
> some address without any blanks in it.

First of all, UNIX* doesn't know what mail is.  UNIX is an operating system,
not a mailer.  On 4.2BSD, the standard mailer is sendmail.  This mailer
understands spaces in names (you must quote the name, of course, like your
example shows).  Another mailer which runs on 4.2, MMDF, also understands
spaces in names.

If there are any sites out there running out-of-date and incorrect software,
mail them.  They should want to know their mailer doesn't conform to the
RFC 822/823 standards.  You say some sites buy their software (Unix sites
without source?  Who *are* these people?), have they notified the manufacturer
of the problem?  Maybe a solution here is to post the name of the manufacturer
to the net, after giving them a chance to remedy the problem.  This should
cause prompt attention to the problem.

*UNIX is a trademark of AT&T Bell Laboratories
-- 
Dave Cohrs @ wisconsin
...!{allegra,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave
dave@wisc-rsch.arpa


Date: 7 Aug 84 9:32-PDT
From: mclure @ Sri-Unix.arpa
To: header-people @ Mit-Mc.arpa
Subject: RFC822 parser

I am looking for C routines to parse an RFC822 address.
Does anyone out there have one? I'm looking for
a comprehensive implementation that works well.

Replies to mclure@sri-unix.

	Stuart

Received: by YALE-BULLDOG.YALE.ARPA; 8 Aug 84 22:40:13 EDT (Wed)
Date: 8 Aug 84 22:40:13 EDT (Wed)
From: Dan Glasser <dglasser%YALE-BULLDOG@YALE.ARPA>
To: Header-People@MIT-MC.ARPA
Subject: Sendmail problem: UUCP headers

    I'm having a problem getting sendmail to properly rewrite headers
on messages going out to UUCP.  Let's say that I compose a message
with the following header fields:

	From: dglasser
	To: decvax!foo, apollo!bar
	Cc: decvax!harpo!blah

    The copy of the message spooled for decvax!foo and decvax!harpo!blah
should have the headers rewritten as follows:

	From: yale!dglasser
	To: foo, yale!apollo!bar
	Cc: harpo!blah

    The copy of the message spooled for apollo!bar should have the
headers rewritten as follows:

	From: yale!dglasser
	To: yale!decvax!foo, bar
	Cc: yale!decvax!harpo!blah

    In other words, what we want to do is the following:

	1) Prepend "yale!" to the sender address.
	2) For recipient address a!b!c:
	   a) For copies of the message going to a, strip "a!"
	   b) For copies of the message NOT going to a, prepend "yale!".


    Now, I have two important questions:

    1) Is my description of how the headers should be rewritten correct?
       (I think it is, but I'd be interested to hear disagreements)
    2) Has anyone successfully implemented this sort of rewriting in
       sendmail?  (I tried doing it by using the $h macro in the UUCP
       recipient rewriting ruleset, but it didn't work)


					Danny Glasser

					decvax!yale!dglasser
					(formerly yale-comix!dglasser)

					Glasser-Daniel@YALE.ARPA

Received: From hp-labs.csnet by csnet-relay;  10 Aug 84 19:58 EDT
Date: Wed, 8 Aug 84 15:34:36 pdt
From: Stan Isaacs <isaacs%hp-labs.csnet@csnet-relay.arpa>
Received: by HP-VENUS id AA07360; Wed, 8 Aug 84 15:34:36 pdt
Message-Id: <8408082234.AA07360@HP-VENUS>
To: header-people%mit-mc.arpa@csnet-relay.arpa, 
    mclure%sri-unix.arpa@csnet-relay.arpa
Subject: Re:  RFC822 parser
Cc: isaacs@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

Hi, Stuart:
  I am currently trying to write a lex/yacc parser for 822.  I'll send it to
you when I get it done and checked.  If you get any responses from someone
who has already done that, please let me know.
  Also, we are looking for a C compiler for a large IBM (running MVS or VM).
Do you know of any?
  How are you doing?  Are you back at SRI?  Last I heard, you were graduate-
studenting at Stanford.  Are you still?  Where are you living?  I've been
meaning to write since I found you had come back to this area, but have just
bought a new house and am busy moving in.  I saw Ole a few weeks ago (that's
how I found you were back).  I'm now over at HP, and enjoying myself.  I'm
working on UNIX, IBM, HP3000, and other systems.  Very confusing, but a lot
of fun.
  See you one of these days 
    -- Stan Isaacs

Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA11542; Wed, 15 Aug 84 15:19:56 edt
Received: by allegra.UUCP (4.12/4.7)
	id AA12088; Mon, 13 Aug 84 11:09:48 edt
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP
From: allegra!cbosgd!mark@mit-vax (Mark Horton)
Subject: Re: Sendmail problem: UUCP headers
Message-Id: <232@cbosgd.UUCP>
Date: Fri, 10-Aug-84 18:40:59 EDT
Received: by hou3c.UUCP; Sat, 11-Aug-84 02:18:22 EDT
References: <745@hou3c.UUCP>
In-Reply-To: <745@hou3c.UUCP>
Organization: AT&T Bell Laboratories, Columbus

No, that's not "the right thing" to do.

Of course, I should mention that RFC822 requires that all such
addresses in mail headers (From, To, Cc, etc) should be in the
	user@domain
form, so that nobody has to go around rewriting them.  So to
conform to 822, you should be sending out @ addresses.  (This
is the direction being taken by the UUCP project.  Having to
change headers at every machine the mail passes through is an
ugly proposition which is best avoided.)

According to "de-facto" convention, there really aren't any rules.
Any given machine does pretty much whatever it wants.  So by this
rule, I suppose you're fine too.

However, some software takes the position that addresses without
@'s in them are as typed on the sending host, and must be interpreted
relative to that host.  Thus if you send mail to
	decvax!foo
and it arrives on decvax reading
	To: foo
there will be software that will assume this means "foo on host yale".
(Assuming yale sent it.)

	Mark


Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA25697; Thu, 16 Aug 84 14:58:52 edt
Received: by ihnp4.ATT.UUCP; id AA22746; 16 Aug 84 14:03:57 CDT (Thu)
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site hou2e.UUCP
From: ihnp4!hou2e!gregbo@mit-eddie (Greg Skinner)
Subject: user-editable mail headers
Message-Id: <243@hou2e.UUCP>
Date: Thu, 16-Aug-84 11:45:25 EDT
Received: by hou3c.UUCP; Thu, 16-Aug-84 14:49:03 EDT
Organization: Bell Labs, Holmdel NJ

Is there any interest in Unix Mailers which support user-editable headers
like tops20 MM supports them?  The new exptools version of Mail doesn't
seem to support them and I don't know of any other Unix Mailers offhand 
that do.

Note that I am not talking about editing just the to, from, cc, bcc and 
subject fields ... I am talking about putting anything in your header which
RFC822 will parse.
-- 
Hug me till you drug me, honey!

Greg Skinner (gregbo)
{allegra,cbosgd,ihnp4}!hou2e!gregbo


Received: by YALE-BULLDOG.YALE.ARPA; 17 Aug 84 17:12:17 EDT (Fri)
Message-Id: <8408172112.AA16150@YALE-BULLDOG.YALE.ARPA>
Received: by YALE-COMIX.YALE.ARPA; 17 Aug 84 17:04:05 EDT (Fri)
Received: by MULTIFLOW.UUCP; 17 Aug 84 16:45:37 EDT (Fri)
Date: 17 Aug 84 16:45:37 EDT (Fri)
From: Ben Cutler <multiflow!cutler%UUCP@YALE.ARPA>
Subject: Re: user-editable mail headers
To: ihnp4!hou2e!gregbo@MIT-EDDIE.ARPA
Cc: Header-People@MIT-MC.ARPA
In-Reply-To: ihnp4!hou2e!gregbo@MIT-EDDIE.ARPA (?Invalid domain (host)), Thu, 16-Aug-84 11:45:25 EDT

    Is there any interest in Unix Mailers which support user-editable headers
    like tops20 MM supports them?  The new exptools version of Mail doesn't
    seem to support them and I don't know of any other Unix Mailers offhand 
    that do.
    
    Note that I am not talking about editing just the to, from, cc, bcc and 
    subject fields ... I am talking about putting anything in your header which
    RFC822 will parse.
    
I have written a portable mailer called AZ.  It's very similar to Tops-20 OZ  
written by John Ellis.  AZ runs on Apollos, and Unix and VMS Vaxen at Yale and 
at several other sites.  You can edit the basic header fields (To, Cc, Bcc, 
Subject) directly using simple commands or using a full screen editor (if you
have one).  AZ doesn't support user-editing of the wide variety of possible 
header fields, but this capability would be very easy to add.

                                            Ben Cutler
                                            Cutler@YALE.ARPA
                                            decvax!yale!multiflow!cutler
    
    
-------


Date:  Sat, 18 Aug 84 15:43 EDT
From:  Paul Schauble <Schauble@MIT-MULTICS.ARPA>
Subject:  List address change
To:  Header-People@MIT-MC.ARPA, Header-People-Request@MIT-MC.ARPA
Message-ID:  <840818194344.843492@MIT-MULTICS.ARPA>

I apologize for bothering the entire list with this, but...

I have requested this address change several times before, both to the
-request address and to the list. So far, nothing has happened. It seems
like communications with the list maintainer have broken down somehow.

So, could anyone who is able please make this change:

          DELETE Schauble at MIT-Multics,
          ADD    Header-People-disty at MIT-Multics

          Thanks you,
          Paul

Date:     Sat, 18 Aug 84 21:57:27 EDT
From:     Stephen Wolff <steve@BRL-BMD.ARPA>
To:       header-people@mit-mc.ARPA
Subject:  Re:  user-editable mail headers

Can anyone explicate an honest reason for editing the From: line of a
message?  It is certainly not possible in our mailer without exercising
privilege, and I had blithely assumed that to be universally the case.

I should hate to have to regard every message as a potential forgery.


Date: 18 Aug 1984 20:24-PDT
Sender: GEOFF@SRI-CSL
Subject:  Re:  user-editable mail headers
From: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL>
To: steve@BRL-BMD
Cc: header-people@MIT-MC
Message-ID: <[SRI-CSL]18-Aug-84 20:24:46.GEOFF>
In-Reply-To: The message of     Sat, 18 Aug 84 21:57:27 EDT from     Stephen Wolff <steve@BRL-BMD.ARPA>

Oh please, let's not rehash THIS issue again!

If you're interested in past discussions in this area I suggest
you retrieve and peruse the archives for this list as well as
MsgGroup.

It's not possible, using the current in place methods for
delivering netmail to prevent any such unauthenticated and/or
unauthorized mangling of message headers.  I would even go so far
as to say that if I had an an account on your system (without the
ability to exercise privilege) I could still edit the From: line
of a message.

You should always regard every message as a potential forgery,
since the ability to perpetrate a forgery is no great act of
chicanery.

g

Date: Sun 19 Aug 84 10:46:52-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  user-editable mail headers
To: steve@BRL-BMD.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Stephen Wolff <steve@BRL-BMD.ARPA>" of Sat 18 Aug 84 19:18:24-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The TOPS-20 MM mailsystem allows editing the From: line of a message.
This is to support some of the hairier aspects of office automation;
e.g. models where some other person (e.g. a secretary) sends mail for
another.  MM also has the capability to be run in a mode where you
can "become" another user for reading/sending mail, but this needs
access to that user's directory (MM will ask for the user's password
if necessary to obtain that access).

The security problems with forged mail are there to be sure, BUT...
unlike TOPS-10 or Unix, programs on TOPS-20 NEVER run with "temporary"
privileges.  It is therefore impossible to enforce any security at the
level of a program run by users, because any security enforcement done
by such a program can be evaded simply by building one's private copy
of the program without the check.  Even leaving aside the issue of a
patched copy of the program, you must also consider the possibility of
other message composition programs being developed to run concurrantly
on the same system; whether to evade the security check or simply to
experiment with alternative interfaces.

That leaves security enforcement to a privileged agent, that is, the
mailer.  The problem here is that at the present time the TOPS-20
mailer doesn't have the slightest idea what RFC 822 is.  It doesn't
deal at that level; it deals with SMTP.  When RFC 1234 comes out that
completely changes the standards, not only would the message composition
program require changing but also the mailer.  Ugh.

Personally, I believe that security against forged mail is a fantasy.
The best you can do is validate that a message clearly came from such-
and-such a host, or for locally-originated mail, that a message was
composed by a certain user (provided your operating system supports a
"file author" word that unprivileged users can't modify).  In TOPS-20,
this is done via Received: and Mail-From: lines.
-------

Received: by YALE-BULLDOG.YALE.ARPA; 19 Aug 84 14:51:57 EDT (Sun)
Message-Id: <8408191851.AA10995@YALE-BULLDOG.YALE.ARPA>
Date:    Sun, 19 Aug 84 14:37:02 EDT
From: John R Ellis <Ellis@YALE.ARPA>
Subject: Re:  user-editable mail headers
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: steve@BRL-BMD.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Sun 19 Aug 84 10:46:52-PDT

    Personally, I believe that security against forged mail is a fantasy.
    The best you can do is validate that a message clearly came from such-
    and-such a host, or for locally-originated mail, that a message was
    composed by a certain user.

It's quite easy to do much better than this for local networks, using
standard operating systems like TOPS-20 and Unix.  At Yale, our Chaosnet
implementation provides a server with the user id and host of the program
at the other end of the connection.  The operating systems provide this
information; user-state programs cannot forge it.  (It isn't hard to modify
TOPS-20 and Unix implementations of Chaosnet to provide this capability.)
Thus our mail system knows reliably who sent local-network mail.

Of course, if someone broke into the operating systems, they could forge
the mail.  So what?  Computer people often talk about "security" as if
it were an all-or-nothing proposition.  But as in the physical world,
there are varying degrees of computer security, depending on how much
the security is worth to you.  Show me a particular computer security
method, and I'll show you a (possibly very expensive) way to circumvent
it (including non-electronic methods).

Just as most of us prefer moderately secure locks on the doors of our
homes in preference to no locks at all, most computer users would prefer
protection against easy forgery rather than no protection at all.  I was
once told the government's sensible definition of security:  Make it more
expensive for the spies to break security of your particular system than
it would cost them to achieve their goals by some other means.
-------

Received: by sri-prism.ARPA (4.12/4.16)
	id AA05721; Mon, 20 Aug 84 22:39:32 pdt
Message-Id: <8408210539.AA05721@sri-prism.ARPA>
Date: Mon Aug 20 22:37:55 1984
From: mclure@sri-prism
To: header-people@mit-mc
Subject: RFC822 parser needed

This is a repeat of an earlier message.

I need an RFC822 parser in C for Unix. I could steal code from
various public routines, but I'm looking for a separate piece of
code so I don't have to disentangle code from some mammoth program.

If you have such a parser (a good one) and are willing to release it,
please contact me. (mclure@sri-prism)

	Stuart

Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17488; Tue, 21 Aug 84 06:49:26 edt
Received: by ihnp4.ATT.UUCP; id AA01693; 20 Aug 84 16:09:36 CDT (Mon)
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 exptools 1/6/84; site ihuxl.UUCP
From: ihnp4!ihuxl!bamford@mit-eddie (bamford)
Subject: Re: user-editable mail headers
Message-Id: <1293@ihuxl.UUCP>
Date: Thu, 16-Aug-84 15:54:39 EDT
Received: by hou3c.UUCP; Thu, 16-Aug-84 22:46:27 EDT
References: <243@hou2e.UUCP>
In-Reply-To: <243@hou2e.UUCP>
Organization: AT&T Bell Labs, Naperville, IL

Y E S ! ! !  I am very interested in a well supported mailer program
that allows editing of the headers.  I very much liked what the TOPS20
machine at Stanford had.


Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17500; Tue, 21 Aug 84 06:49:39 edt
Received: by ihnp4.ATT.UUCP; id AA01715; 20 Aug 84 16:09:52 CDT (Mon)
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ulysses.UUCP
From: ihnp4!ulysses!smb@mit-eddie (Steven Bellovin)
Subject: Re: user-editable mail headers
Message-Id: <969@ulysses.UUCP>
Date: Thu, 16-Aug-84 22:42:47 EDT
Received: by hou3c.UUCP; Fri, 17-Aug-84 11:24:23 EDT
References: <1293@ihuxl.UUCP>
In-Reply-To: <1293@ihuxl.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill

Please note that the Rand MH system -- distributed with 4.2bsd -- has had
that ability for years.  When you want to send a letter, it pops you into
the editor of your choice; when you're done, it parses the header to see
who it's addressed to.


Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17511; Tue, 21 Aug 84 06:49:51 edt
Received: by ihnp4.ATT.UUCP; id AA02254; 20 Aug 84 16:17:50 CDT (Mon)
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
From: ihnp4!dual!fair@mit-eddie (Erik E. Fair)
Subject: Re: user-editable mail headers
Message-Id: <772@dual.UUCP>
Date: Sat, 18-Aug-84 17:42:27 EDT
Received: by hou3c.UUCP; Sat, 18-Aug-84 22:46:52 EDT
References: <1293@ihuxl.UUCP> <969@ulysses.UUCP>
In-Reply-To: <969@ulysses.UUCP>
Organization: Dual Systems, Berkeley, CA

The recmail program from the netnews distribution does similar things.
Standard procedure is to make a prototype header for the user, fire
up an editor, and when it exits, hand the text to recmail. It picks out
the To: and Cc: fields and mails off the letter with /bin/mail, which
will accept *anything* as input. Voila! Editable headers.

	Erik E. Fair	ucbvax!fair	fair@ucb-arpa.ARPA

	dual!fair@BERKELEY.ARPA
	{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
	Dual Systems Corporation, Berkeley, California


Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17528; Tue, 21 Aug 84 06:50:04 edt
Received: by ihnp4.ATT.UUCP; id AA03069; 20 Aug 84 16:33:32 CDT (Mon)
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
From: ihnp4!utzoo!henry@mit-eddie (Henry Spencer)
Subject: Re: user-editable mail headers
Message-Id: <4231@utzoo.UUCP>
Date: Sat, 18-Aug-84 18:10:02 EDT
Received: by hou3c.UUCP; Sun, 19-Aug-84 19:00:22 EDT
References: <1293@ihuxl.UUCP>, <969@ulysses.UUCP>
In-Reply-To: <969@ulysses.UUCP>
Organization: U of Toronto Zoology

> Please note that the Rand MH system -- distributed with 4.2bsd -- has had
> that ability for years.  When you want to send a letter, it pops you into
> the editor of your choice; when you're done, it parses the header to see
> who it's addressed to.

I have no direct experience with MH, but this is *clearly* the right way
to do letter composition.  A mail system is a mail system:  it should not
try to be a text editor as well.  Partly because it complicates the mail
system unnecessarily, partly because it means the poor user has to learn
two different editors, but mostly because mail-system editors are lousy
editors!  Text editing is a complex task; writing a good text editor is
not easy.  Mail-system authors should leave this job to specialists.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry


Date: Tue 21 Aug 84 08:27:06-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: user-editable headers
Sender: CRISPIN@SU-SCORE.ARPA
To: Header-People@MIT-MC.ARPA
Reply-To: MRC@SU-SCORE.ARPA
Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107
Phone: (415) 442-1500 x31

     The main objection I have to the idea of popping you into an
editor to compose the message and then parsing the header to see
where the message goes to is that there is not necessarily a
correspondence between the header of a message and its envelope!
Just about every mail system (including TOPS-20's MM) I am aware
of which has this capability has this fundamental flaw.

     The problem is what you do about things which do not conform
to the definition of 822 but are still valid under it.  The best
example I can think of is the tradition of using group names to
hide a recipient list (this is the original usage of group names
from long long ago and, I imagine, still its primary usage).
bcc's present another problem; there are several theories on the
correct bcc behavior which can only be determined at mailer
instead of editor level.
-------

Date:  Tue, 21 Aug 84 11:49 EDT
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  parsing headers
To:  Header-People@MIT-MC.ARPA
Message-ID:  <840821154949.966446@CISL-SERVICE-MULTICS.ARPA>

I disagree with Mr.Crispin's comments.  There is a distinction between
text and envelope.  However, a mail header is a sensible printed
representation of the envelope of a new, outgoing message.  It is also a
sensible representation to edit.

Multics allows users to "edit" the header, parses it, and then carefully
prevents the user from forging those fields that are (a) part of the
envelope and (b) a communication from agent to agent rather than from
user to user.

Date: Tue 21 Aug 84 10:17:18-PDT
From: Mark R. Crispin <Crispin@SU-SCORE.ARPA>
Subject: Re: parsing headers
To: Margulies@CISL-SERVICE-MULTICS.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from ""Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>" of Tue 21 Aug 84 09:06:09-PDT
Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107
Phone: (415) 442-1500 x31

     The difference between my position and Benson's seems to be
philsophical.  I mostly agree with him on his points that:
 . a text/envelope distinction exists
 . a header is a sensible printed representation of the envelope of a
   freshly-composed message
 . a header is a sensible representation to edit

     Where I disagree is that I do not see the necessity to require
that the post-editing header remain a respresentation of the envelope.
This introduces the problem which I referred to: if an "edit headers"
functionality exists, which parts of that functionality affect the
envelope and which don't?

     MM's approach to the problem is less than satisfactory.  It has
an "edit headers" functionality which is parsed by the reply processor
with the added twist that unknown header items are treated as user-
defined headers (neither good nor very robust).  It then has various
power tool commands to alter the headers from MM context, which know
what should alter the envelope and what shouldn't.
-------

Date:  Tue, 21 Aug 84 19:08 EDT
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Re: Editing Headers
To:  header-people@MIT-MC.ARPA
Message-ID:  <840821230804.729547@CISL-SERVICE-MULTICS.ARPA>

I, and Multics, DO NOT require/guarantee that the header in the text
retain the identical form that the user edits it into.  In fact, if the
user tries to add certain fields that we reserve as envelope
reflections, we rename the fields.  (We add X- to the front).  Thus it
seems that Mr.  C.  and I agree, but that I accidently implied that I
agreed with an feature that I don't.

Date: Tue 21 Aug 84 19:59:48-EDT
From: Gregbo
Subject: Re:  user-editable mail headers
Sender: GDS@MIT-XX.ARPA
To: header-people@MIT-MC.ARPA
Reply-To: Gds@MIT-XX.ARPA
In-Reply-To: Message from "Stephen Wolff <steve@BRL-BMD.ARPA>" of Sat 18 Aug 84 22:12:45-EDT

    From:     Stephen Wolff <steve@BRL-BMD.ARPA>

    Can anyone explicate an honest reason for editing the From: line of a
    message?  It is certainly not possible in our mailer without exercising
    privilege, and I had blithely assumed that to be universally the case.

    I should hate to have to regard every message as a potential forgery.


I often use my nickname (gregbo) in the From: field and use my real
name in the Sender: field.  It's not to be fraudulent, just to have a
little fun.

--gregbo
-------

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA20435; Wed, 22 Aug 84 10:33:31 pdt
Received: from SJRLVM4.BITNET
	by ucbjade.CC.Berkeley.ARPA (4.14/4.23.5)
	id AA23132; Wed, 22 Aug 84 10:32:52 pdt
Message-Id: <8408221732.AA23132@ucbjade.CC.Berkeley.ARPA>
Date: Wed, 22 Aug 84 10:30:45 PDT
From: David Alpern <ALPERN%SJRLVM4.BITNET@Berkeley>
To: MRC@SU-SCORE.ARPA
Cc: Header-People@MIT-MC.ARPA
Subject: Re: user-editable headers
In-Reply-To: Message of Tue 21 Aug 84 08:27:06-PDT from Mark Crispin
     <MRC@SU-SCORE.ARPA>

Both the problem of BCCs and of recipient lists can be dealt
with reasonably by having the "header template" creator include
all of the addressees (all members of the group, all BCC entries)
in the header as seen within the editor, and then "hiding" the
appropriate entries as the header is parsed to create the envelope.
The only difficulty is how to separate those groups whose members
the user wants seen from those whose recipient list is to be hidden.
Our choice was to hide all group recipient lists, since people did
not seem to be using any group names in situations where the recipient
list was wanted.  Another possibility would be a syntactic distinction
(e.g. a * instead of a : after the group name) between the two uses.

The only problem this seems to leave is that the user might edit a
group recipient list which gets hidden, yielding misleading information
about who the recipients were.  Since group names really have no
semantic meaning from a recipient's viewpoint anyhow, this seems mute.

Is there a side to this problem I've missed?

- Dave

     David Alpern
     IBM San Jose Research Laboratory, K65/282
     5600 Cottle Road, San Jose, CA 95193
     Phone: (408) 284-6521
     Internet: Alpern%IBM-SJ@CSnet-Relay.ARPA
               Alpern@SJRLVM4.BITNET

Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA01745; Thu, 23 Aug 84 19:24:53 edt
Received: by ihnp4.ATT.UUCP; id AA10992; 23 Aug 84 10:39:00 CDT (Thu)
To: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
From: ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)
Subject: Re:  user-editable mail headers
Message-Id: <775@hou3c.UUCP>
Date: Thu, 23-Aug-84 11:30:43 EDT
Received: by hou3c.UUCP; Thu, 23-Aug-84 11:30:43 EDT
References: <773@hou3c.UUCP>
In-Reply-To: <773@hou3c.UUCP>
Organization: Bell Labs, Holmdel, NJ


	I often use my nickname (gregbo) in the From: field and use my real
	name in the Sender: field.  It's not to be fraudulent, just to have a
	little fun.

What you may not realize is that you are having fun in a way that
violates RFC 822.  (I sometimes wonder whether anyone in Arpaland
has ever read that document.)  RFC 822 requires that all addresses
contain at signs, as your mail program should know but apparently
doesn't.  Therefore, when your letter arrived here, I had to manually
edit the header to replace
	From: Grebo
with
	From: GDS@MIT-XX.ARPA
So nobody on the USENET side of the gateway got to see your little
joke.
				Kenneth Almquist


Date:  Thu, 23 Aug 84 20:57 EDT
From:  "Jon A. Rochlis" <Rochlis@MIT-MULTICS.ARPA>
Subject:  editing the from field
To:  steve@BRL-BMD.ARPA
cc:  header-people@MIT-MC.ARPA, gds@MIT-XX.ARPA
Message-ID:  <840824005720.556900@MIT-MULTICS.ARPA>

A better reason for editing the from field, is that the message may be
"from" more than one person.  For example, a friend and I write a neat
hack and we send out a piece of mail describing it and make it from both
of us.  (It is true though, that only one process is the "sender" and an
explicit sender:  field seems appropriate when the from field has been
hacked by the user.)

                    -- Jon

Date: 23 Aug 1984  19:26 MDT (Thu)
Message-ID: <WANCHO.12041862597.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To:   ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)
Cc:   GDS@MIT-XX, Header-People@MIT-MC
Subject: user-editable mail headers
In-reply-to: Msg of 23 Aug 1984  09:30-MDT from ihnp4!hou3c!ka at mit-eddie (Kenneth Almquist)

Kenneth,

RFC822 says many things in different places.  One of them says that
the Sender: field MUST appear if the From: field is not "correct".
Another says that the Reply-to: supercedes the From: field.  So, in
spite of the "illegality" of the From: field, both the Sender: and the
Reply-to: fields were legal.  Your complaint should have been made to
the maintainer of your mail handler.

--Frank

Date:     Thu, 23 Aug 84 21:53:53 PDT
From:     sventek@lbl-ws.arpa
Message-Id: <840823215307.007@lbl-ws.arpa>
Subject:  Re: edited header fields
To:       header-people@mit-mc.arpa

I hate to enter the fray, but it seems that the appropriate chapter and
verse need to be quoted concerning the precise syntax required of the
From: field in RFC822.  The first quote comes from page 18 of RFC822:

     originator  =   authentic                   ; authenticated addr
                   [ "Reply-To"   ":" 1#address] )

     authentic   =   "From"       ":"   mailbox  ; Single author
                 / ( "Sender"     ":"   mailbox  ; Actual submittor
                     "From"       ":" 1#mailbox) ; Multiple authors
                                                 ;  or not sender

As you can see from these two productions, the From field is required to
have a single token of type "mailbox" if the sender is the same person
that the message is from.  If the sender is different, or there are
multiple authors, then the sender must contain a single token of type
"mailbox" indicating the sender, and the From field must contain one
(or more) token of type "mailbox".

The next quote provides the productions for "mailbox", and is extracted
from page 27 of RFC822:

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec

     route-addr  =  "<" [route] addr-spec ">"

     route       =  1#("@" domain) ":"           ; path-relative

     addr-spec   =  local-part "@" domain        ; global address

These productions indicate that the mailbox token is always of the form

                          local-part@domain

or

                   phrase <[route]local-part@domain>

The moral of the story (as I see it) is that if you let your users
edit their own headers, then the composition utility must then check
all of the headers which have precisely defined syntax requirements
(such as From) for compliance with the spec.  If there is an illegal
header field, then two courses of action can be followed: the composer
can try to set things right, or the message can be tossed back at the
user.  I think most systems opt for the first possibility.  Regardless
of the method used, the message must be made RFC822 compliant before
the message leaves the composer's machine.

                                   Joe Sventek <sventek@lbl-ws.arpa>

Date:     Fri, 24 Aug 84 9:33:45 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
cc:       header-people@mit-mc.ARPA
Subject:  Re:  user-editable mail headers

However, there is a difference between not being correct (having the
wrong or non-existant user name) than having the wrong syntax.  People
who have illegally formatted header lines should be shot.

-Ron


Date: Fri 24 Aug 84 08:15:01-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  user-editable mail headers
To: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA
cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)" of Thu 23 Aug 84 16:43:40-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The command which GDS uses to generate "From: Gregbo" is a power
tool in MM and not a result of any failure in it.  There are
other commands which can be used to "become" some other user which
do ensure valid RFC 822 header lines.  A "power tool" is something
which lets the user go beyond the program's (narrow) interpretation
of whatever standard...either to use some unimplemented or new
feature...or in this case to violate it.

Just like somebody can hurt themselves with a chain saw, one can
abuse a mailsystem power tool.  But blame the user, not the tool.
-------

Date: Fri 24 Aug 84 08:24:17-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: illegality
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I sure wish that people would use "invalid" instead of
"illegal" when referring to syntax validity checking or other
forms of user-error checking on computers.  "Illegal" should
be reserved for things which are against the law; e.g. theft
of services, vandalism, fraudulent usage, etc.

     I still remember the day a few years ago when I found a
newly-hired secretary at Stanford CSD crying.  You see, it was
her first day on the computer, and shortly after being left
alone with a zillion things to enter in she made some trivial
error which rewarded her with an "Illegal syntax" error message.
She was terrified that the FBI was going to come and arrest her!
[The fact that "syntax" itself is a horrible word to use in an
error message in any program a novice might use is beside the
point]

     I firmly believe that computers should be made more accessible
to the general public, not less, and we should start by not
misusing the term "illegal."  I start feeling ill every time I
see some message saying so-and-so's "header is ILLEGAL"!
-------

Date: Fri, 24 Aug 84 09:04:50 pdt
From: Joseph I. Pallas <pallas@Pescadero>
Subject: Re:  user-editable mail headers
To: MRC@SU-Score, ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA
Cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA

"MM doesn't shoot RFC822, people shoot RFC822."  Sorry, by no stretch of
the imagination can your "power tool" argument justify sending illegal
(I mean, invalid) headers out into world.  MM can do whatever it wants,
but your SMTP mailer is responsible for supplying the safety glasses if
MM doesn't.

joe

Date:     Fri, 24 Aug 84 12:06:40 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       Mark Crispin <MRC@SU-SCORE.ARPA>
cc:       Header-People@MIT-MC.ARPA
Subject:  Re:  illegality

Of course, if you use illegal headers the Protocol Police will come
and arrest you.

-Ron

Date: 24 Aug 84 1313 EDT (Friday)
From: don.provan@CMU-CS-A.ARPA
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: illegality
CC: Header-People@MIT-MC.ARPA,
In-Reply-To: "Mark Crispin's message of 24 Aug 84 10:24-EST"
Message-Id: <24Aug84.131355.DP0N@CMU-CS-A.ARPA>

gee, does that mean we have to stop threatening to call out the
protocol police, too?

Received: by YALE-BULLDOG.YALE.ARPA; 24 Aug 84 13:53:55 EDT (Fri)
Message-Id: <8408241753.AA06954@YALE-BULLDOG.YALE.ARPA>
Date:    Fri, 24 Aug 84 13:47:01 EDT
From: John R Ellis <Ellis@YALE.ARPA>
Subject: Re: illegality
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: Header-People@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Fri 24 Aug 84 08:24:17-PDT

    I sure wish that people would use "invalid" instead of "illegal" when
    referring to syntax validity checking or other forms of user-error
    checking on computers.  "Illegal" should be reserved for things which
    are against the law; e.g. theft of services, vandalism, fraudulent
    usage, etc.

"Illegal" more accurately describes a message with bad syntax than
"invalid".  From my Random House College Dictionary (a mediocre
dictionary):

    illegal: 1. not legal; contrary to existing statutes, regulations,
                etc.; unauthorized.

    invalid: 1. not valid; without force or foundation; indefensible.
             2. deficient in substance or cogency; weak.
             3. void or without legal force, as a contract.

    valid:   1. sound; just; well-founded:  "a valid objection."
             2. producing the desired result; effective:  "a valid remedy."
             3. having force, weight, or cogency; authoritative.
             4. Logic.  (of an argument) so constructed that if the
                premises are jointly asserted the conclusion cannot be
                denied without contradition.

"Illegal" merely implies some non-conformance with a regulation or statute
or rule.  There is no necessary requirement that there be the force of
government behind the rule.  For example, it is common usage to say that
a move in a game is illegal, i.e. doesn't conform to the rules.

"Invalid" on the other hand is mainly used to refer to arguments and
methods, especially those involving logic (thinking).  For example, you
might describe a possible compiler source transformation as invalid.

So "illegal" accurrately describes a header that does not conform to the
rules of RFC822, rules laid down by a supposedly authoritative agency,
DARPA.  "Invalid" wouldn't be nearly as good an adjective, since a message
header is not an argument or method.

It's pretty much mom and apple pie these days that error messages such
as "Illegal syntax" or "Invalid header format" are pretty useless to a
novice (as Mark points out in with his anecdote).  On the other hand,
there need be little relation between what our programs say to users and
the terminology we used to describe the implementation of the program.
-------

Date: Fri 24 Aug 84 12:49:24-PDT
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: illegality
To: MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Fri 24 Aug 84 08:50:20-PDT
Location:  EJ286    Phone: (415) 859-2774

Mark's explication of illegality reminds me of a solution one
computer facility had.  The also had a lot of novice users.
One of their programs would print:

UNASSIGNED JFN AT 321222, FATAL ERROR  (That's not so bad.)
-------

Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA11501; Fri, 24 Aug 84 17:01:26 edt
From: ihnp4!hou3c!ka@mit-eddie
Date: 24 Aug 84 15:59:34 CDT (Fri)
Message-Id: <8408242059.AA08504@ihnp4.ATT.UUCP>
Received: by ihnp4.ATT.UUCP; id AA08504; 24 Aug 84 15:59:34 CDT (Fri)
To: WANCHO@SIMTEL20.ARPA
Cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
Subject: user-editable mail headers
In-Reply-To: <WANCHO.12041862597.BABYL@SIMTEL20>

Frank,
   I disagree with the way you interpret standards.  If you write a
program with a syntactically incorrect statement in it, would you
try to tell the compiler writer that the compiler should accept the
program anyway as long as the statement was not executed?  It is true
that the message in question had a Sender: field which indicated the
real sender of the message and a Reply-to: field which indicated where
replies were to be sent to.  The fact that the From: field was not
used for these purposes does not mean that it is OK for the From:
field to be syntactically incorrect.

I do not check the syntax of every entry in a mail header.  However,
RFC 822 requires gateways to parse From: fields.  In section 6.2.2 it
says:
	This standard permits abbreviated domain specification....
        When a message crosses a domain boundary, all  addresses  must
        be  specified  in  the  full format, ending with the top-level
        name-domain in the right-most field.  It is the responsibility
        of  mail  forwarding services to ensure that addresses conform
        with this requirement.  In the case of abbreviated  addresses,
        the  relaying  service must make the necessary expansions.


Presumably RFC 822 is intended to specify the format of ARPANET mail.
It follows that any mailer which sends out nonconforming messages
is broken.  I should not be told to fix *my* software to deal with such
messages.  I gather that the mailer on MIT-XX doesn't bother to check
the syntax of user specified From: lines on the grounds that users are
not supposed to make mistakes.  That is not the mark of a quality piece
of software.
				Kenneth Almquist


Date: Fri 24 Aug 84 16:54:05-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: user-editable mail headers
To: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA
cc: WANCHO@SIMTEL20.ARPA, GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie" of Fri 24 Aug 84 15:59:34-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Whether or not software is "quality" or no depends upon whether
or not it does what it is intended to do.  It is pretty silly to
expect Visicalc to execute PL/I programs.

     The TOPS-20 mailer agrees to act as a mail bridge only, not as
a "mail gateway".  It is the responsibility of the originating entity
to generate a message to the destination in correct format.  Similar,
all entities should use the same standard for message headers.  The
mailer (MMailr) knows nothing about RFC 822; its expertise is with
RFC 821 and other transport-level protocols.  It is completely
separate from any message composition agent.

     Any user agent which does not wish to take the responsibility
of composing a valid message for the destination agent should simply
not use a mail bridge.  Most of the TOPS-20 mail bridges would be
happy to have less traffic; they provide it only as a courtesy and
not as a guaranteed service.
-------

Date:     Fri, 24 Aug 84 20:27:17 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       Mark Crispin <MRC@SU-SCORE.ARPA>
cc:       ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA, WANCHO@SIMTEL20.ARPA, 
          GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
Subject:  Re:  user-editable mail headers

Then you are saying that TOPS-20 users should either get smarter user
agents or not use MMailr.  Sounds good, when is it likely to happen?

-Ron

Date: Sat 25 Aug 84 06:43:53-EDT
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re:  user-editable mail headers
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Fri 24 Aug 84 11:28:27-EDT

    From: Mark Crispin <MRC@SU-SCORE.ARPA>

    The command which GDS uses to generate "From: Gregbo" is a power
    tool in MM and not a result of any failure in it.  There are
    other commands which can be used to "become" some other user which
    do ensure valid RFC 822 header lines.  A "power tool" is something
    which lets the user go beyond the program's (narrow) interpretation
    of whatever standard...either to use some unimplemented or new
    feature...or in this case to violate it.

Now hold on!  Just because I like to modify my headers, it doesn't
mean that I am violating the mailsystem!  I've seen some really
ridiculous headers in my day, and mine is quite reasonable compared to
those! 

Greg Skinner
Gds@MIT-XX.ARPA
ihnp4!houxm!gregbo (UUCP)
-------

Date: Sat 25 Aug 84 07:04:02-EDT
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re:  user-editable mail headers
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)" of Thu 23 Aug 84 19:33:05-EDT

    From: ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)

    	I often use my nickname (gregbo) in the From: field and use my real
    	name in the Sender: field.  It's not to be fraudulent, just to have a
    	little fun.

    What you may not realize is that you are having fun in a way that
    violates RFC 822.  (I sometimes wonder whether anyone in Arpaland
    has ever read that document.)  RFC 822 requires that all addresses
    contain at signs, as your mail program should know but apparently
    doesn't.  Therefore, when your letter arrived here, I had to manually
    edit the header to replace
    	From: Grebo
    with
    	From: GDS@MIT-XX.ARPA
    So nobody on the USENET side of the gateway got to see your little
    joke.
    				Kenneth Almquist


People on the more civilized side of ucbvax do read RFC 822.
I have read it also.
All you had to do was delete the From: line and take what was in the
Sender: line and manually replace it.
Since there is an authenticated Sender: field generated whenever a
From: field is munged, the message still stays within legality of
RFC822. 
The only problem is readnews' and its brothers' inabilities to read
Arpanet mail.  Simple fix to readnews -- just have the Sender: field
examined if the From: field is unparseable.
One more thing, in case you didn't know, I work at Bell Labs also, so
I have the experience of both ARPA and Usenet message composition.
Don't blame the user, blame the standards' (RFC850 and RFC822)
different interpretation of From:

Greg Skinner (I do read RFCs!)
Gds@MIT-XX.ARPA
ihnp4!houxm!gregbo (UUCP)

p.s. perhaps mit-vax is at fault also!
-------

Date: Sat 25 Aug 84 09:12:21-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  user-editable mail headers
To: ron@BRL-TGR.ARPA
cc: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA, WANCHO@SIMTEL20.ARPA,
    GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Ron Natalie <ron@BRL-TGR.ARPA>" of Fri 24 Aug 84 17:29:28-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Well, in fact, I have started the specification for a
smarter user agent than MM.  MM has reached the end of its useful
lifetime.  There are other user agents of varying strengths and
weaknesses for TOPS-20 that interact with MMailr: Babyl and
Hermes come immediately to mind.

     Many of the messages that people have complained about did
not, in fact, originate at a TOPS-20 system.  Many of them did,
in fact, originate on a Unix system!  You see, while there are
very good mailers on Unix there are very poor ones.  Some of the
latter think it is alright to send a letter out on the Internet
simply by bouncing it to a TOPS-20 system after having appended
"@host" (where host is the name of the TOPS-20 system) to the
From: line.

     I feel it violates all concepts of modularity to have the
mail delivery agent know about whatever is inside the message.
Part of the problem is that the Internet mail protocols still
insist upon having syntax-checking of this thing called a
"message header" inside the message, instead of having all that
stuff be external and/or obtained from the envelope at the
transport level where it belongs.
-------

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA03190; Sat, 25 Aug 84 10:42:55 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.14/4.23.5)
	id AA00422; Sat, 25 Aug 84 10:44:34 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.5)
	id AA10519; Sat, 25 Aug 84 10:44:18 pdt
Date: Sat, 25 Aug 84 10:44:18 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8408251744.AA10519@ucbopal.CC.Berkeley.ARPA>
To: MRC@SU-SCORE.ARPA
Subject: Re: user-editable mail headers
Cc: header-people@mit-mc.ARPA


In reply to:

	Date: Sat 25 Aug 84 09:12:21-PDT
	From: Mark Crispin <MRC@SU-SCORE.ARPA>
	Subject: Re:  user-editable mail headers

	....

	     I feel it violates all concepts of modularity to have the
	mail delivery agent know about whatever is inside the message.
	Part of the problem is that the Internet mail protocols still
	insist upon having syntax-checking of this thing called a
	"message header" inside the message, instead of having all that
	stuff be external and/or obtained from the envelope at the
	transport level where it belongs.
	-------

Lets be clear about whether you are talking about mail user agent
or mail transport agent functions. A message composed by a user should
have its headers validated before it is passed to a mail transport
agent to be transmitted.  That is, the header should be full and
complete before it is passed to the envelope builder.

I concur that the envelope should contain the information it needs
to the job.  For example, Precedence and Classification should be
part of the SMTP envelope. But since those fields are user defined
(in the DOD community), they first have to be in the "contents" header.

Within the same mail system, it should not be necessary for intermediate
mail agent program to check or modify the "contents" message header
(with the exception of adding the "Received" audit trail).  However,
when the message is gatewayed into another mail system, format and
address conversion may need to be preformed.

I think some of the problems we have been having are a result of the
unofficial policy of making mail programs liberal in what they are
willing to receive and (hopefully) strict about what they transmit.

I would like to suggest that gateway mail agents enforce the rules.
If you are a gateway into the Internet mail community, you should have
a syntax and address checker between the Internet mail agent program
and the non-Internet mail system. Of course, if you want to be kind
to your non-Internet neighbor, you can put a conversion program
between the non-Internet mail system and the check program.

Bill Wells
wcwells@Berkeley.ARPA
ucbvax!wcwells
WCWELLS@UCBJADE.BITNET

Date: Sun 26 Aug 84 12:36:29-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: user-editable mail headers
To: wcwells%ucbopal.CC@UCB-VAX.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Sat 25 Aug 84 10:53:22-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Let's get some other things straight.

What is the point of a power tool to create arbitrary headers if some
process (be it composition or transport) decides to "correct" them?
It means that you cannot experiment with new header syntaxes without
writing code to do so.

I am greatly prejudiced against having mail transport agents (or even
mail bridges -- which some call "mail gateways") know about RFC 822.
Time and time again I have seen perfectly valid headers munged into
unrecognizability by such overly-"helpful" bridges.

Personally, I consider mail bridges in general to be a crock.  If it
weren't for every trivial entity which strings up a network thinking
they have God's gift for designing the perfect network protocols, we
wouldn't have this plethoria of different network protocols that
require mail bridges.
-------

Date: 27 August 1984 00:13-EDT
From: header-people-request @ MIT-MC
Sender: CENT @ MIT-MC
Subject: this is a test
To: HEADER-PEOPLE @ MIT-MC
cc: HEADER-PEOPLE-REQUEST @ MIT-MC

of the early warning mailing list error msg system. do not respond unless
you do not receive this msg.

Date: 28 August 1984 01:51-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: Re: test
To: ihnp4!garfield!tag @ UCB-VAX
cc: HEADER-PEOPLE @ MIT-MC

    Date: Tue, 28 Aug 84 00:31:38-0330
    From: ihnp4!garfield!tag@Berkeley (Terry Greening)
    To: CENT@MIT-MC.ARPA
    Subject: Re:  test
	Date: 27 August 1984 00:45-EDT
	From: Pandora B. Berman <ihnp4!ucbvax!CENT@MIT-MC.ARPA>
	Subject: test
	To: ihnpa!garfield!tag@BERKELEY, ihnp4!garfield!tag@BERKELEY
	this is a test. we have some problems with your address on the
	HEADER-PEOPLE list. if you get this msg please respond indicating
	your correct address. thank you..

    As you can see I did receive your test message.  The correct path is
    through site "ihnp4".  I would like you to send mail to a group called
    "header-people" on our system.  The correct address should be:
    ihnp4!garfield!header-people@BERKELEY Once again, thank-you.

aha. somehow i had originally entered you as at ihnpA!..., which caused a
host-unknown msg from berkeley when i sent a recent test msg. you are fixed
now, and i have added the local redistribution list you requested.  are you
going to read from that (should i remove you from the list here), or do you
want to continue to get header-people mail directly from MC?

Received: From hp-labs.csnet by csnet-relay;  29 Aug 84 17:16 EDT
Received: by HP-VENUS id AA24117; Wed, 29 Aug 84 12:32:20 pdt
Message-Id: <8408291932.AA24117@HP-VENUS>
Date: Wed 29 Aug 84 12:32:03-PDT
From: Scott L. McGregor <MCGREGOR%hp-labs.csnet@csnet-relay.arpa>
Subject: [Scott L. McGregor <MCGREGOR@HP-HULK>: Re:  illegality]
To: header-people@mit-mc.arpa
Source-Info:  From (or Sender) name not authenticated.

Mail-From: MCGREGOR created at 29-Aug-84 12:28:10
Date: Wed 29 Aug 84 12:28:09-PDT
From: Scott L. McGregor <MCGREGOR@HP-HULK>
Subject: Re:  illegality
To: ron%brl-tgr.arpa@csnet-relay
cc: MCGREGOR@HP-HULK
In-Reply-To: Message from "Ron Natalie <ron%brl-tgr.arpa@csnet-relay.csnet>" of Fri 24 Aug 84 14:19:49-PDT

I will just make a few observations on "illegality","protocol police",
and "shooting mail system administrators who allow illegal headers to
leave their mailsystems", and then I will step out of the fray.	

It is ironic that a document called RFC (request for comment) is regarded
as a law that some would have treated as a capital offence and to be 
policed by protocol police.

While I don't regard the violations of the guidelines proposed in RFC822
as quite as serious as some do, I do recognize that there is much a human
problem here as a machine or program problem. Here's my analysis:

Many people see great benefits in reaching the Internet community by mail.
This makes it desirable for them to get up a mail bridge to get into the
system as quick as possible, and as is equally human, with the least amount
of effort required.  There are two strategies in building such a mail
connection that are particularly of interest: 1) saving on building a
input checking routine (assuming everyone follows the standard) and 2)
saving on building an output checking routine (assuming that no one will
hand you bad stuff to send out).  

Some sites seem to have adopted one strategy or the other. Some have even
adopted both. Whenever someone who doesn't do output checking sends some
garbage to someone who doesn't do input checking, the fur starts to fly
in header-people.

RFC733 and 822 have something to recommend about this, and there has long
been a policy recommended by header-people and others that goes something
like this (in various variants): 'It is good courtesy (and smart practice)
to make your mail interface to the net as strict as possible about what
it transmits (outbound) and as flexible as possible about what it will
receive (inbound).'  This is of course entirely contrary to the two strategies
described above (don't input check and don't output check).

For a real problem to exist there have to be two systems at fault, the one	
who sent the garbage and the one who received it and belched.  Both sides
have failed to meet the courtesy standard, and so argue about who is more
at fault, and who should have to do something about it in the future.  I
don't find this kind of discussion very helpful. Both systems need to change.
Given human organizations, the one who doesn't change is just asking for
another problem in the future. Both systems should be made more error
tolerant in my opinion.

Of course, any changes that need to happen, won't happen overnight. Thats
just how organizations and people work. But there are things that can be
done to speed up these changes, and I find discussing these much more
productive.  In particular, there seems to be precious little discussion
on how to do better error checking on output and how to do correction on
input.  What we mainly hear is that we should all just do a better job
of it.

I must admit that in my mail interface programs I have made many mistakes
in the past and that these have been pointed out to me by angry mail
administrators.  I have tried to address them as quickly as possible, but
I'll let you all in on a hint to quicker fixes.  I have always responded
faster to complaints that suggested how the actual repair could be 
accomplished (in code or pseudo code) than I have to those that just
said that it needed to be fixed and that I should do it now.

In the interest of more robust systems everywhere, I would like to see
much more code sharing.

recklessly yours,

Scott McGregor
-------
-------


Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2640159562548570@MIT-MULTICS.ARPA>; 30 Aug 1984 05:39:22 edt
Date:        29 Aug 84 23:47 +0200
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 <header-people@MIT-MC.ARPA>,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re:  user-editable mail headers
Message-ID:  <68007@QZCOM>
In-Reply-To: <66788@QZCOM>


   (Text 66788) 84-08-22  11.39  GDS @ MIT-XX.ARPA
   %Original date: Tue 21 Aug 84 19:59:48-EDT.
   %FROM: Gregbo
   %In-reply-to: Message from "Stephen Wolff <steve@BRL-BMD.ARPA>"
                 of Sat 18 Aug 84 22:12:45-EDT
   %SMTP sender: @MIT-MULTICS.ARPA,@MIT-MC:GDS@MIT-XX.ARPA

   I often use my nickname (gregbo) in the From: field and use my real
   name in the Sender: field.  It's not to be fraudulent, just to have a
   little fun.

In our COM computer conferencing system we want to retain as
much security and stringency as possible. Therefore we select
the sender name from the SMTP-sender field but adds a different
From field right into the text just for user information.
I.E. with reliable (in some measure) mail agents consistency
is retained as far as possible.

Nicknames: we don't have'm. But we allow sort of fuzzy matching:
"t er q", "ericson qz" and "zeke" (just for fun) are valid local
parts.

To MRC: Yes, TOPS-20 does not allow user programs to get "temporary"
privs. But it is rather easy to install a monitor call that will
allow a certain program to access a certain file safe, we have
done this to ensure that only THE (execute-only) program may
access the message data base.




Date:  Thu, 30 Aug 84 09:04 EDT
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Sender versus the envelope
To:  header-people@MIT-MC.ARPA
Message-ID:  <840830130411.326570@CISL-SERVICE-MULTICS.ARPA>

Proposition:  To the extent that a mailsystem is secure, that security
is asssured by careful maintenance of envelope information by servers.

If this statement is correct, then it follows:

The presence of a Sender field prepared by the sending agent in the text
is a convienience to aid in replies, but is not any good for security.

Thus, a mail reading program should by default show the From field,
which is the sender's advertised name, and the Envelope Sender in
formation, which is the trustworthy name.

The Sender field should only be used to send replies, or if the user
explicitly asks after it.

Is this consistent with other people's interpretations?

  --benson

Date:           Mon, 3 Sep 84 14:55:54 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header-People@MIT-MC.ARPA
Subject:        "bare CR" and "bare LF" in RFC822 headers

RFC822 says you can have "bare" CR's and LF's in header text.  For
example, the definition of the lexical token "text" (Section 3.3, page
10) reads as follows:

    text  =  <any CHAR, including bare    ; => atoms, specials,
	      CR & bare LF, but NOT       ;  comments and
	      including CRLF>             ;  quoted-strings are
					  ;  NOT recognized.

Also, the discussion on quoting (Section 3.4.1, page 11) mentions that a
CR must be quoted (i.e., preceded by a backslash) if it occurs within a
quoted string, domain literal, or comment.  This is, I suppose, implicit
evidence that someone thinks CR's or CRLF's could appear in addresses.

What I want to know is -- does ANYONE, ANYWHERE, use (or intend to use)
"bare" CR's or LF's in addresses, or indeed anywhere else in a header?
(I am, of course, not talking about the CRLF end-of-line delimiter.)

    Rich Wales
    UCLA Computer Science Department
    3531 Boelter Hall // Los Angeles, CA 90024 // (213) 825-5683
    ARPA:  wales@UCLA-LOCUS.ARPA
    UUCP:  ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!wales

Date:  3 Sep 84 1926 EDT
From: Rudy.Nedved@CMU-CS-A.ARPA
To: Rich Wales <wales@UCLA-LOCUS.ARPA>
Subject: Re: "bare CR" and "bare LF" in RFC822 headers
CC: Header-People@MIT-MC.ARPA
In-Reply-To: "Rich Wales's message of 3 Sep 84 16:55-EST"
Message-Id: <03Sep84.192613.EN0C@CMU-CS-A.ARPA>

Rich,

CMU does not use the bare cr or bar lf BUT it handles cr, lf and crlf
all the same...they are treated as end-of-line and are converted to
whatever the local end-of-line convention is.

"...be conservative in what you send and liberal in what you receive..."

-Rudy

Received: from Gamay.ms by ArpaGateway.ms ; 03 SEP 84 22:17:27 PDT
From: DonWinter.pasa@XEROX.ARPA
Date: 3 Sep 84 22:17:09 PDT
Subject: Re: [Scott L. McGregor <MCGREGOR@HP-HULK>: Re:  illegality]
In-reply-to: MCGREGOR%hp-labs.csnet@CSNET-RELAY.ARPA's message of Wed,
 29 Aug 84 12:32:03 PDT, <8408291932.AA24117@HP-VENUS>
To: Scott L. McGregor <MCGREGOR%hp-labs.csnet@CSNET-RELAY.ARPA>
cc: header-people@MIT-MC.ARPA

Scott,

I'm pleased to see a little sanity injected into this political
discussion. Of course, I expect it to have as much impact as sanity
injected into any other political discussion. Sigh.

				Don

Date:  4 Sep 84 1154 EDT (Tuesday)
From: Craig.Everhart@CMU-CS-A.ARPA
To: Header-People@MIT-MC.ARPA
Subject: Re: "bare CR" and "bare LF" in RFC822 headers
In-Reply-To: "Rich Wales's message of 3 Sep 84 16:55-EST"
Message-Id: <04Sep84.115407.RD00@CMU-CS-A.ARPA>

Even if your poll shows that nobody polled intended to use bare CRs or LFs in
their addresses, would you feel justified in not providing support for them in
your mail handling software?  After all, if you fail to support that part of
the standard, you can't claim that you follow it.  Who knows what somebody
will try to use as an address some day?  For whatever reason?

It sure sounds like interpreting quoted CRs and LFs as other than text (e.g.,
as a line break) is a bad idea, also.

Received: from [mrxa] by 44d.Ucl-Cs.AC.UK   via Janet with NIFTP; 
          10 Sep 84 12:46 BST
Received: from Maths.Nott.AC.UK by Hcig.Nott.AC.UK   via Phonenet; 
          10 Sep 84 12:45 BST
Date: 10 Sep 84 12:35:44 BST (Mon)
To: header-people-request@mit-mc.arpa
CC: HEADER-PEOPLE@mit-mc.arpa, tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa
Subject: Re: this is a test
In-reply-to: Your message of 27 August 1984 00:13-EDT.
From: Tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa
Sender: Tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa

test


Date:           Sat, 15 Sep 84 14:39:52 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header-People@MIT-MC.ARPA
Subject:        What are SMTP commands "EXPN" and "VRFY" good for?

I would like to hear some other people's opinions on the SMTP "EXPN" and
"VRFY" commands.  I seriously wonder what, if anything, these commands
are good for.  As everyone probably knows, they are not required in the
"minimum" SMTP server implementation, and I can think of very few situ-
ations in which a mailer program would ever need (or want) to use them.

First, my gripes with EXPN.

The problem with using EXPN to expand a remote mailing list is that this
spoils any attempt by the receiving host to direct "undeliverable mail"
messages to someone who can fix the problem.

I think everyone by now agrees that problems relating to an invalid
address on a mailing list should be reported to whoever is responsible
for maintaining the mailing list -- NOT to the person who sent a message
to the list.  But there is no provision in the EXPN command for the
server to pass this information back to the requesting host.

Hence, any host which used EXPN in order to send directly to everyone on
a remote mailing list would defeat any attempt by the remote host to
direct error messages to the right place (by substituting a new "return
path" as the list was expanded).

Admittedly, mailing lists could be flagged in some way so that an EXPN
on the name would return only one line (namely, the address of the list)
-- but if you do this, what's the point in having EXPN at all?

Now, the problems with VRFY.

I have seen only one ARPANET host whose mailer routinely uses VRFY
(namely, MIT-MULTICS).  Even MIT-MULTICS appears to use VRFY only when
relaying mail originating on MAILNET.  The scenario seems to be as fol-
lows (based on an examination of the various system logs kept by our
SMTP server):

(1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is
    rejected with a 502 ("command not implemented") reply code.

(2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner,
    does a QUIT and closes the connection.

(3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP
    server again and, without trying another VRFY, sends mail to the
    user named in the previous session's unsuccessful VRFY.

I sent a message to Postmaster@MIT-MULTICS a little while ago asking
about this strange behavior, but never received a reply.  I also re-
cently added code to our SMTP server to implement VRFY (for local user
names and mailing lists only), and I'm waiting to see what happens if
MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far,
there have been no takers.

The idea of doing a VRFY on a user name before trying to send mail to
that name disturbs me.  RFC821's description of VRFY is vague enough to
make it unreliable as a means for validating an address before mailing
to it.  This is particularly true when non-local user names are involved
(if someone wants to send to "podunk!fred@UCLA-LOCUS.ARPA", there is no
way we can validate a command like "VRFY podunk!fred").  In any case,
I thought that validation of a recipient address -- if done by the SMTP
server at all -- belonged in the processing of the RCPT command.

The only scenario I can currently think of where a mailer program might
want to use VRFY is if a RCPT command is rejected and the mailer wants
to get as much info as possible to send back to the user.  For example,
assume I call up the PODUNK.ARPA SMTP server and try to send mail to
"fred@PODUNK.ARPA":

    220 PODUNK.ARPA SMTP server ready
    helo UCLA-LOCUS.ARPA
    250 PODUNK.ARPA (hi there, UCLA-LOCUS.ARPA)
    mail from:<john@UCLA-LOCUS.ARPA>
    250 OK
    rcpt to:<fred@PODUNK.ARPA>
    550 Sorry, no one named <fred@PODUNK.ARPA> here

At this point, I could do a VRFY and see if I get anything interesting:

    vrfy fred
    553-Ambiguous user name; try one of:
    553-Fred Jones <jones@PODUNK.ARPA>
    553 Fred Smith <smith@PODUNK.ARPA>
    quit
    221 PODUNK.ARPA SMTP server says bye-bye

Now, when I send the obligatory "rejection notice" back to the message
sender, I can include the reply to the VRFY in the message -- perhaps
like this:

    Date:       Sat, 15 Sep 84 14:20:10 PDT
    From:       UCLA-LOCUS Mail System <Postmaster@UCLA-LOCUS.ARPA>
    To:         John Jones <john@UCLA-LOCUS.ARPA>
    Subject:    Undeliverable mail to <fred@PODUNK.ARPA>

    ===== transcript of mailer session follows =====

	rcpt to:<fred@PODUNK.ARPA>
	550 Sorry, no one named <fred@PODUNK.ARPA> here
	vrfy fred
	553-Ambiguous user name; try one of:
	553-Fred Jones <jones@PODUNK.ARPA>
	553 Fred Smith <smith@PODUNK.ARPA>

    ===== unsent message follows =====

    . . .

Other than this, I really can't think of a good use for VRFY.

-- Rich

Received: by UCB-VAX.ARPA (4.24/4.31)
	id AA22333; Sat, 15 Sep 84 19:10:25 pdt
Received: by ulysses.UUCP; Sat, 15 Sep 84 22:06:02 edt
Received: by kalypso.UUCP; Sat, 15 Sep 84 22:05:49 edt
Date: Sat, 15 Sep 84 22:05:49 edt
From: ulysses!smb@Berkeley (Steven Bellovin)
Message-Id: <8409160205.AA15551@kalypso.UUCP>
To: header-people@mit-mc.ARPA, wales@ucla-locus.ARPA
Subject: Re:  What are SMTP commands "EXPN" and "VRFY" good for?

Except for the problem of failed mail in a list expansion -- on which
matter I agree with Rich Wales -- EXPN struck me as a good idea for
handling mail to multiple lists, or to a person and a list.  As is,
Rich is going to receive two copies of this letter -- one direct, and
one via the list expansion.  A sufficiently smart mailer could use
EXPN to discover that Rich is on the list, and not send him a separate
copy.  (We'll ignore the fact that this particular note is going via
uucp to an SMTP host; it wouldn't really change anything if it weren't.)


	--Steve Bellovin
	AT&T Bell Laboratories

	ulysses!smb@berkeley.arpa
	smb.ulysses.btl@csnet-relay	(should work, but probably doesn't)
	smb.research.btl@csnet-relay	(works more often)

Date: 16 Sep 84 18:27:56 EDT
From: jpm@BNL
To: Header-People@MIT-MC
Subject: Distribution lists

I'm very new at this so please forgive me if this is obvious to the rest
of you, it sure isnt to me.

I want to implement a way for users to send to a mailing list stored in
a file. I dont want to update the system alias table every time somebody
creates a mailing list, and I dont want to implement private alias tables
for each user.

I have seen messages with a format something like

	To: My-Dist-List: :INCLUDE: "DISK:MYLIST.DST"@MYHOST.ARPA ;

This seems to be what I want, but I cant find that format in RFC822.
Is this a hack by a particular host to do file includes or is it the
standard way of doing it?


			John McNamee
			jpm@Bnl.Arpa

Date: Mon, 17 Sep 84 08:18:48 pdt
From: Steven Tepper <greep@SU-Russell>
Subject: VRFY
To: wales@ucla-locus
Cc: greep@su-russell, header-people@mit-mc

One potential use of VRFY is to check that all addresses are valid before
trying to deliver to any of them, for example in case the sender might have
mistyped one of them and doesn't want address errors to be propogated in
replies to the original message.  But this doesn't work unless all the
hosts at which you want to verify an address implement VRFY and are up when
you try doing the VRFY (unless you want to wait for them all to be up
before sending to any of them).  Even if they all implement VRFY, they may
not be able to do it in real time for addresses which are not local, as you
point out with the case of uucp.

Date:  Mon, 17 Sep 84 11:35 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Distribution lists
To:  jpm@BNL.ARPA
cc:  header-people@MIT-MC.ARPA
Message-ID:  <840917153533.394324@MIT-MULTICS.ARPA>

The :INCLUDE:  syntax is an obsolete syntax that may have been in
RFC733, but is not in RFC822.  It is still in use, however, by some of
the older mailers.  There is no standardized syntax for mailing lists.
On Multics we have a number of address types for which there is no
standard syntax, and we handle them by using a special syntax in the
local-part of addresses.  In particular, we use the syntax
          To: "{list PATHNAME}"@MYHOST.ARPA
 for mailing lists.  Since the string is quoted it is treated as an
ordinary local-part by properly functioning software on other hosts.
                                        barmar

From: Larry Peterson <llp@Purdue.ARPA>
Message-Id: <8409171559.AA20944@merlin.ARPA>
Received: by merlin.ARPA; Mon, 17 Sep 84 10:59:07 est
Date: 17 Sep 1984 1059-EST (Monday)
To: Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Cc: header-people@MIT-MC.ARPA, jpm@BNL.ARPA
Subject: Re: Distribution lists
In-Reply-To: Your message of Mon, 17 Sep 84 11:35 EDT.
             <840917153533.394324@MIT-MULTICS.ARPA>


Sendmail gives you an easy mechanism for implementing mailing
lists defined outside of /usr/lib/aliases. You just tag the list's
alias to indirectly point to a file, where the file contains
the members of the group.

Larry

Date: 17 Sep 84 1208 EDT (Monday)
From: Craig Everhart@CMU-CS-A.ARPA
To: Header-People@MIT-MC.ARPA
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
Sender: Craig.Everhart@CMU-CS-A.ARPA
Reply-To: Craig.Everhart@CMU-CS-A.ARPA
In-Reply-To: "Rich Wales's message of 15 Sep 84 16:39-EST"
Message-Id: <17Sep84.120838.RD00@CMU-CS-A.ARPA>

I can think of several uses for EXPN and VRFY.  As Rich notices, it's too bad
that EXPN doesn't have more options to handle mailing-list exploders and
the destinations for error replies.  Surely EXPN was conceived without
taking such issues real seriously.

EXPN can be used, as has already been noted, to suppress sending private
copies of messages that are also destined for mailing list delivery.
Of course, the client of a mailer that does such suppression must accept
that he will not necessarily be notified on late or failed delivery.

Then again, even though it goes against our images of what all mailing lists
``should'' be like, there can easily be (small) lists that have no particular
maintainer; they act as simple address exploders rather than as redistributors
that take responsibility for the redistribution.  With such lists (which seem
to be the sort of list for which EXPN in its present form was designed),
EXPN has obvious use both in eliminating duplicate delivery and in reducing
the number of forwarding hops necessary.

I can see several uses for VRFY, also.  Let's suppose that a user agent for
electronic mail wanted its client (a user) to know about misspellings of
names that he typed in, and that it wanted him to know about them right away.
It could connect to the proposed destination host and try to VRFY the addresses
that the user gave.  Then, once the mail was to be delivered, the user agent
might just let a daemon process do that.  (Rationale?  Not easy, until you
think that maybe the user doesn't really care if the mail goes out immediately
or in several minutes; maybe the user wants to do something else right now.)

Another use of VRFY could be as follows.  Suppose a program maintains
distribution lists for people.  Suppose that it has a command to validate the
addressees named in the list; perhaps this is to update the list to account
for new forwarding links or new host names that have been established since
the list entry was made.  What better tool is there than VRFY, which checks
addressees on foreign hosts without actually sending mail?

When a feature is being used, it's a good bet that it's a usable and useful
feature.  However, just because a feature isn't much used yet doesn't mean
that it's not both usable and useful.  Give it time!

		Craig Everhart

Date: 17 Sep 84 1337 EDT (Monday)
From: don.provan@CMU-CS-A.ARPA
To: Rich Wales <wales@UCLA-LOCUS.ARPA>
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
CC: Header-People@MIT-MC.ARPA,
In-Reply-To: "Rich Wales's message of 15 Sep 84 16:39-EST"
Message-Id: <17Sep84.133744.DP0N@CMU-CS-A.ARPA>

i've always assumed that VRFY would be used only in reaction to a
user's request.  in other words, a user would say "verify
jones@cmu-10a" and the program would run out and check on the
existence of such a user.  there are any number of reasons a person
may want to check an address in such a way.  for me, it's usually
because i can't remember whether jones has his mailbox on cmu-10a or
cmu-10b.  VRFY allows me to check this without actually sending mail.

i assume EXPN is for similar purposes.  it's not intended to be used
to deliver mail to the list.  it allows a user to find out who's on
the list.

i didn't have anything to do with designing this protocol, so i'm
guessing when i say "intended", but it certainly seems like the more
obvious use of optional commands.  i'd also like to point out that
i talk big, but none of my software uses or supports these
two commands in any way.

Received: from SCRC-PEACE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 92095; Mon 17-Sep-84 12:21:19-EDT
Date: Mon, 17 Sep 84 12:20 EDT
From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>
Subject: What are SMTP commands "EXPN" and "VRFY" good for?
To: Rich Wales <wales@UCLA-LOCUS.ARPA>, Header-People@MIT-MC.ARPA
In-Reply-To: The message of 15 Sep 84 17:39-EDT from Rich Wales <wales@UCLA-LOCUS.ARPA>
Message-ID: <840917122038.0.HORNIG@PEACE.SCRC.Symbolics>

    Date:           Sat, 15 Sep 84 14:39:52 PDT
    From:           Rich Wales <wales@UCLA-LOCUS.ARPA>

    I would like to hear some other people's opinions on the SMTP "EXPN" and
    "VRFY" commands.  I seriously wonder what, if anything, these commands
    are good for.  As everyone probably knows, they are not required in the
    "minimum" SMTP server implementation, and I can think of very few situ-
    ations in which a mailer program would ever need (or want) to use them.

    First, my gripes with EXPN.

We (Symbolics) use EXPN solely to support our user-level "Show Mailing
List" command.  The actual sending of mail does not use it.

    Now, the problems with VRFY.

    I have seen only one ARPANET host whose mailer routinely uses VRFY
    (namely, MIT-MULTICS).  Even MIT-MULTICS appears to use VRFY only when
    relaying mail originating on MAILNET.  The scenario seems to be as fol-
    lows (based on an examination of the various system logs kept by our
    SMTP server):

    (1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is
	rejected with a 502 ("command not implemented") reply code.

    (2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner,
	does a QUIT and closes the connection.

    (3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP
	server again and, without trying another VRFY, sends mail to the
	user named in the previous session's unsuccessful VRFY.

    I sent a message to Postmaster@MIT-MULTICS a little while ago asking
    about this strange behavior, but never received a reply.  I also re-
    cently added code to our SMTP server to implement VRFY (for local user
    names and mailing lists only), and I'm waiting to see what happens if
    MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far,
    there have been no takers.

Multics systems send a VRFY when they are acting as a mail relay and
receive a RCPT for a non-local recipient.  The idea is to make a best
effort to get the appropriate error back to the sender syncronously.  If
the VRFY command is not completed successfully (as was the case above)
the mail is accepted anyway for forwarding.

Date: 17 Sep 84 16:30:11 EDT
From: jpm@BNL
To: Header-People@MIT-MC
Subject: Thanks for distribution list info

Thank you to the people who sent me information on including files of
mailboxes. I've decided to implement it using ":INCLUDE: file"@Host.
This should keep it from blowing the mind of of some other mailer.

				John McNamee

Date:  Mon, 17 Sep 84 17:46 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Distribution lists
To:  Larry Peterson <llp@PURDUE.ARPA>
cc:  header-people@MIT-MC.ARPA, jpm@BNL.ARPA
In-Reply-To:  Message of 17 Sep 84 11:59 EDT from "Larry Peterson"
Message-ID:  <840917214620.110302@MIT-MULTICS.ARPA>

Larry Peterson's response is not apropos to the question.  jpm
specifically asked for a mechanism that did not require updating the
central alias file when a user creates a personal mailing list.  It
sounds like your sendmail mechanism doesn't fit the bill.  The only
advantage that indirection provides is that the user doesn't have to
modify the alias file to modify the mailing list.  However, that isn't
what he asked for.
                                        barmar

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807270918172@MIT-MULTICS.ARPA>; 18 Sep 1984 07:21:10 edt
Date:        15 Sep 84 15:46 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: illegality
Message-ID:  <69859@QZCOM>
In-Reply-To: <67429@QZCOM>

How many books do you want? FIVE
%XYZ123 ILLEGAL NUMERIC ITEM

A more suitable error message text would be
Sorry, the computer does not understand this!



Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807392228511@MIT-MULTICS.ARPA>; 18 Sep 1984 07:23:12 edt
Date:        16 Sep 84 05:04 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people <header-people@MIT-MC.ARPA>
bcc:         Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Name data base or Name and Host data base
Message-ID:  <69941@QZCOM>

I have an important design question for a future interface to
RFC mail, where I would like the advice of other people in the
header-people group.

I would like to automatically build up a data base of people,
with whom our users often communicate, from the names and
adresses of people in the header fields of incoming messages.

This data base can be organized in two ways:

(1) A data base of names of people. For each name, the full
return path to that person is stored.

(2) A data base of hosts and names. For each name, only the
host name is stored. The return path to that host is then
stored on the host.

Note that there are in-between alternatives. For a name like
AAA!BBB!CCC%DDD@EEE this could be stored as
(a) the name "AAA!BBB!CCC%DDD" at the host "EEE", or as
(b) the name "AAA!BBB"CCC" at the host "DDD" or as
(c) the name "CCC" at the host "BBB".
Of those three alternatives, I would much prefer alternative
(c) with the real name and the real host.

But my main problem is selection between alternatives (1) and
(2) above. Some arguments:

Arguments for (1):

This solution will not cause any problem if two hosts have the
same name (except if two people have both the same name and the
same host, but this has VERY low probability). Also, faulty path
information for one person will only affect the return path to
that person, not to anyone else. It will thus be easier to
create the data base automatically from pathes in incoming
messages. With solution (2), a new return path for a host in a
new incoming message cannot immediately be stored on that host,
since the faulty path will then cause all messages to that host
to go wrong. Thus, solution (2) will require more manual
checking.

Arguments for (2):

The correct and proved path to a certain host need only be
stored once in the data base, and will then be available for all
messages to be sent to anyone at that host in the future.
Less information is duplicated in the data base with this
solution.

Note: We presently are using solution (1) and it works rather
well. But since we plan to re-write everything, we can decide
on solution (2) when design the next version of the program.

What is your opinions? Please help me!




Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807439242285@MIT-MULTICS.ARPA>; 18 Sep 1984 07:23:59 edt
Date:        16 Sep 84 11:53 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Illegality in from fields
Message-ID:  <69950@QZCOM>
In-Reply-To: <8408291932.AA24117@HP-VENUS>


     Original date: Wed 29 Aug 84 12:32:03-PDT.
     FROM: Scott L. McGregor <MCGREGOR%hp-labs.csnet@csnet-relay.arpa>

     For a real problem to exist there have to be two systems at fault, the
     one who sent the garbage and the one who received it and belched. Both
     sides have failed to meet the courtesy standard, and so argue about who
     is more at fault, and who should have to do something about it in the
     future.

I do not agree. Our interface is certainly written according to the
principle: Accept much in input, follow standards strict on output.
(With some small exceptions, we are misusing the BCC field on output.)

But in our system, we have a special command to make it easy to send a
message to the author of a previous message. If the RFC822 header does not
contain the necessary information to implement such a command, then the
system which created this header is to be blamed.

Also, I would certainly prefer not to have to have two different algorithms
in order to find out where to send a reply to the author, one for headers
from some systems and one for headers from another system.

No field except the FROM field gives information about where to send
a reply to the author of a message except possibly the REPLY-TO field.

Also, we have another command in our system to send a reply to everyone
who received a certain previous message. For that command to work,
we need correct machine addresses in the TO, CC and BCC fields.
Some systems include unexpanded local macro calls in these fields,
and only expand these macros to correct machine addresses in the
SMTP-RECEIVER fields. We do not like this. And that is not because
we are unliberal or narrowminded, but only because we want to provide
a good service to our users with these two replying commands which
we have.



Date: Tue 18 Sep 84 08:31:39-MDT
From: William G. Martin <WMartin@SIMTEL20.ARPA>
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
To: header-people@MIT-MC.ARPA
cc: wmartin@ALMSA-1.ARPA
In-Reply-To: Message from "Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>" of Mon 17 Sep 84 14:08:00-MDT

The recent discussion of the EXPN and VRFY commands included a couple
mentions of using EXPN to implement a command that would let a user
discover who is on a remote mailing list. I had never heard of such
a command before, but, now that I know it is possible, I want it!

As a contact point at my Activity for message-system problems and advice,
I have often been asked by various users who send mail to a remote
mailing list how to find out the actual recipients of such mail.
For lists with regular maintainers and "list-Request" addresses,
it is often possible to either write the request address or locate
and read the actual file of addresses via FTPing to the distribution
host. (This was easy on MIT-based distributions, but not possible on
BRL-based distributions, where anonymous FTP login is not allowed.)
For other lists, where the maintainer is not known, it is difficult.

So, if a simple, user-executable command exists that I can tell a
secretary to use to find out who is on the "DMIS-Chiefs@BRL" list,
I need to know it! I need such a command for our 4.2 BSD UNIX main
host (ALMSA-1), which runs mmdf mail. I'd also like to find it on
this TOPS-20 host from which I am sending this message. Is it there,
already existing, and I just don't know what the command is? Or do
I have to get the command implementation from somewhere and have our
operating systems people install it? Or is this only implemented
by a couple people out there and it isn't really available at all?

And does this discussion, in which most people say that their host
ignores the "EXPN" command anyhow, mean that, even if I located and
installed the user-command to perform this function, it wouldn't
work in most cases anyway?

(Caught up to the heights of joy, and then cruelly dashed on the
rocks of despair...)

Will Martin
USArmy AMC ALMSA, St. Louis, MO
-------

Date: Tue 18 Sep 84 08:45:21-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
To: WMartin@SIMTEL20.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "William G. Martin <WMartin@SIMTEL20.ARPA>" of Tue 18 Sep 84 07:47:08-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     The distributed version of the TOPS-20 SMTP server (MAISER) supports
both the VRFY and the EXPN commands.  For local mailing list expansion
lookups, you can run the MMailbox program (or XMailbox for very old systems).

     It would not be too difficult to write a network "remote mailing list
query" program for TOPS-20 or for that manner any operating system.  I'd be
surprised if it took a junior programmer more than 15 minutes to do it.  I've
always been lazy and TELNET'd to the SMTP server.
-------

Date:     Tue, 18 Sep 84 12:50:49 EDT
From:     G B Reilly <reilly%udel-eecis3.delaware@udel-relay.ARPA>
To:       Header-People@mit-mc.ARPA
Subject:  MCI Mail

Recently I was on a business trip to complete a contract with a three-letter
government agency.  Since I had no stationery with me at the time, I decided
to use MCI Mail to send in the invoice.  Well, a month passed, and I called
down to the Finance office, who told me 'We never received it.'  This didn't
sound right - I had never had MCI lose mail before.  A few days later, the
Finance people called, telling me they had found the invoice.  After some
questions, I found that the bright orange invoice had been placed, UNOPENED,
on the desk with ADVERTISEMENTS.  By coincidence, I had called just before
someone got around to opening the "ad" - my invoice.

So much for casting "leading technology" onto those who know nothing about it.


Date:  Wed, 19 Sep 84 02:43 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Name data base or Name and Host data base
To:  Jacob_Palme_QZ@QZCOM.MAILNET
cc:  header-people@MIT-MC.ARPA
Message-ID:  <840919064304.199768@MIT-MULTICS.ARPA>

A problem with your proposals (2) and (3) is that they violate the
sanctity of the local-part.  Your software that might try to recognize
          AAA!BBB!CCC%DDD@EEE
 as meaning the user CCC on Usenet host BBB would be making possibly
incorrect assumptions about how EEE parses its local parts.  On a
suitably unusual computer "AAA!BBB!CCC%DDD" could be a local user name;
there is no way for your site to know how what those special characters
mean to EEE.  If, perhaps, you know that EEE treats % in the local part
as synonymous with @, then you have the next level of assumption, about
how DDD parses ITS local-part, and then AAA.
                                        barmar

From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8409202127.AA13887@merlin.ARPA>
Received: by merlin.ARPA; Thu, 20 Sep 84 16:27:29 est
Date: 20 Sep 1984 1627-EST (Thursday)
To: William G. Martin <WMartin@SIMTEL20.ARPA>
Cc: wmartin@ALMSA-1.ARPA, header-people@MIT-MC.ARPA
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
In-Reply-To: Your message of Tue 18 Sep 84 08:31:39-MDT.
             <8409181438.AA07422>

	From: William G. Martin <WMartin@SIMTEL20>
	Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
	
	The recent discussion of the EXPN and VRFY commands included a couple
	mentions of using EXPN to implement a command that would let a user
	discover who is on a remote mailing list. I had never heard of such
	a command before, but, now that I know it is possible, I want it!
	
My implementation of the finger protocol for Unix has this feature; if
you finger a mailing list on a remote site, the server will expand it
and finger all the individual members (recursively following lists, of
course).

As a separate issure, I'd like to see this kind of behaviour more
formally described with a new finger protocol spec (there are a number
of problems with the current one). Anyone interested in collaborating?

chris
----------

Date: 18-Oct-84 19:33:35-UT
From: little@dcn5
Subject: Virtual Terminal Protocol
To:   header-people@mit-mc.arpa, msggroup@brl, tcp-ip@sri-nic.arpa

 
I am attempting to create a virtual terminal protocol (VTP) with emphasis
on solving problems created by forms mode type terminals (eg-3270).  I
currently view the problem with the following breakdown -

		Graphical (Character) Representation
			code for information exchange (agreement)

		Control Domain and Exercising
			modal operation
			transfer requests
			function keys
			out-of-band signals

		Display 
			cursor addressing
			end-of-line/screen condition
			presentation attributes

Does anyone have any interesting thoughts or know of problems they are having
in this area?? (or are header/TCPIP/msg people the right people for this sort
of thing?)

Specifically - what problems do you have with TELNET??

Are there deficiencies you would like to overcome with TELNET or RFC 731?

Also, does anyone have access to the new VTP spec put out recently by the
Terminal Repertoire Committee of ANSI (chaired by Henry Lowe -DEC)?

						Mike Little - LINKABIT@DCN5
-------

Date:     Thu, 18 Oct 84 20:10:05 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       little@DCN5.ARPA
cc:       header-people@MIT-MC.ARPA, msggroup@BRL.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:  Re:  Virtual Terminal Protocol

Actually, the WISCNET software that allows you to use TCP/IP to IBM-370
series machines running VM/CMS does this.  They have an option negotiation
that says "do 3270 style stuff" and from then on send 3270 control messages.

I have been meaning to try to simulate the user end on UNIX with a termcap
driven user telnet, but haven't gotten around to it.

-Ron

Date: 19 Oct 1984 01:11-PDT
Sender: ESTEFFERUD@USC-ECL
Subject: Re: Virtual Terminal Protocol
From: ESTEFFERUD@USC-ECL
To: little@DCN5
Cc: header-people@MIT-MC, msggroup@BRL, tcp-ip@SRI-NIC
Message-ID: <[USC-ECL]19-Oct-84 01:11:57.ESTEFFERUD>
In-Reply-To: The message of 18-Oct-84 19:33:35-UT from little@dcn5.ARPA

Msggroup and header-people are both the wrong lists for this topic.

Please, everyone (and especially those of you who we all know know better),
refrain from dumbly copying these two lists on replies, just because
the originator did not know better.

I can understand innocent new netmail users making such an error, but
I cannot understand why knowlegeable people blindly continue?

Thanks for your forebearance, and your consideration.  Stef

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA07932; Tue, 23 Oct 84 21:20:24 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.17/4.26)
	id AA19997; Tue, 23 Oct 84 21:28:08 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26)
	id AA03712; Tue, 23 Oct 84 21:28:04 pdt
Date: Tue, 23 Oct 84 21:28:04 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8410240428.AA03712@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: UUCP/Internet - Handing Local Domain Addresses

Forwarded from USENET "net.mail" news group:
-----------
From gnu@sun.uucp Wed Oct 17 00:00:13 1984
Newsgroups: net.mail
Subject: uucp!user%localnet, etc, with a Free Surprise Present!
Article-ID: net.mail/529

sdcsvax!brian suggests:

> 	when I send mail from one of our campus machines ('wizard', for
> 	example), the address will appear as follows:
> 		sdcsvax!brian%wizard
> 	since 'sdcsvax' is our portal to the world.

A better choice is to output your local addresses as
		sdcsvax!wizard!brian
since there is a firmly defined parsing order for that, while there
is no firmly defined precedence between ! and %.

> UCSD is our local domain.  (We have a ucsd net registered with the NIC).
> 
> When we get full sub-subdomains installed (there are about 50 machines
> on campus that can send/receive mail), split along administrative or
> departmental lines, each sub-subdomain(ssd) will have a name, and a mail
> server that can route mail within that ssd.  So, for example, the
> machines in the computer center will generate addresses of the sort
> 	brian%sdcc9.cc.ucsd
> as a return address.  Mail entering our portal at sdcsvax can be
> addressed using this address, eg
> 	sdcsvax!brian%sdcc9.cc.ucsd

I would think that for internal use you'd have
	brian@sdcc9.cc.ucsd   .
When accepting mail from outside to get to such a place, it looks like
the uucp mail project has settled on this syntax:
	sdcsvax!sdcc9.cc.ucsd!brian
because we know of no Unix mailers that will munge an address like
this unless the dotted "hostname" is the first hostname in the list.
Also note that this is the same convention used for "brian@wizard" above.

> If/when we get on the Internet, the above composite address
> (user%machine  or user%ssd) will simply be the mailbox part of a
> standard RFC822 address, such as brian%wizard.cglab@UCSD, or more
> simply, brian%cglab@UCSD.

The standard Internet address should have the subdomains and hosts
on the RIGHT side of the @ -- that's what it's there for, to separate the
username from the host&domain.  Thus you'd be:
				    brian@wizard.cglab.ucsd
   or     brian@cglab.ucsd

There's an outstanding question in my mind whether "ucsd" should be
a top level domain (Sun has a network registered at the NIC too, but
that doesn't make us one of a few dozen names that every site in the
world should know how to route to).  There should be no problem tucking
it under the uucp, csnet, or arpa domains though.  Or whatever strange
world domain naming scheme the ISI folks have dreamed up this season.

------------------ The Free Surprise!

What follows below is excerpts from our local sendmail.cf file which
implement rewriting of local addresses into uucp-like addresses as
described above.  As an added feature, the stuff at the bottom
(rule 8) hacks mail relayed from our Arpanet relay (ucbvax) to make
the relay transparent (i.e. to make the return address "foo@bar.arpa"
rather than "ucbvax!foo@bar.arpa").

You'll have to merge these into your sendmail.cf file.  The best way
I've found is to print both on fanfold paper and spread them out on 
a table.  Diffs don't usually work very well because of the cryptic
and very context-sensitive nature of the file.

One more thing.  I've used rewriting rule numbers greater than 30 for
convenience (mine, not yours).  The standard sendmail only allows 30
rules.  You'll have to either recompile your sendmail with this silly
limit raised, or change rules 30, 38, etc. to have smaller (otherwise
unused) numbers.  Search for all the "30"s in the file and fix them
all, don't just change the number in the "S" line and expect it to
work.  If you don't do either, your sendmail will point out the
rewriting rule numbers it can't deal with, when you first test the
merged config file.

I'll answer questions, but remember -- NO WARRANTEES!


############################################################
###	local info
############################################################

# my official hostname
# You have two choices here.  If you want the gateway machine to identify
# itself as the DOMAIN, use this line:
Dj$D.$U
# If you want the gateway machine to appear to be INSIDE the domain, use:
#Dj$w.$D.$U

# major relay mailer
DMuucp

# major relay host
DR ucbvax
CR ucbvax

# local domain names
DDsun
CDsun

# domain-spec for local domain within universe (eg, what domains are above?)
DUuucp

# known SMTP/ethernet hosts (this domain only)
FS/etc/hosts.equiv
FS/usr/lib/mailhosts

# my name
DnMAILER-DAEMON

#################################
#  Final Output Post-rewriting  #
#################################

S4
R$+<@$+.uucp>		$2!$1				u@h.uucp => h!u
R$+			$: $>9 $1			Clean up addr
R$*<$+>$*		$1$2$3				defocus


################################################
#  Clean up an address for passing to a mailer #
#  (but leave it focused)		       #
################################################

S9
# externalize internal forms which don't meet external specs
R@			$@$n				handle <> error addr
R$*<$*LOCAL>$*		$1<$2$D.$U>$3			change local info
R<@$+>$*:$+:$+		<@$1>$2,$3:$4			<route-addr> canonical


###########################
#  Name Canonicalization  #
###########################

# Internal format of addresses within the rewriting rules is:
# 	anything<@host.domain.domain...>anything
# We try to get every kind of address into this format, except for local
# addresses, which have no host part.  The reason for the "<>" stuff is
# that the relevant host name could be on the front of the address (for
# source routing), or on the back (normal form).  We enclose the one that
# we want to route on in the <>'s to make it easy to find.
# 

S3

# handle "from:<>" special case
R<>			$@@				turn into magic token

# basic textual canonicalization
R$*<$+>$*		$2				basic RFC821/822 parsing
R$+ at $+		$1@$2				"at" -> "@" for RFC 822

# make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later
R@$+,$+:$+		@$1:$2:$3			change all "," to ":"
R@$+:$+			$@$>6<@$1>:$2			src route is canonical

# more miscellaneous cleanup
R$+			$:$>8$1				host dependent cleanup
R$+:$*;@$+		$@$1:$2;@$3			list syntax
R$+@$+			$:$1<@$2>			focus on domain
R$+<$+@$+>		$1$2<@$3>			move gaze right
R$+<@$+>		$@$>6$1<@$2>			already canonical

# convert old-style addresses to domain-based addresses
# All old-style addresses parse from left to right, without precedence.
# Note that the left side of '%' is a username; it is matched with $+ so
# that complex names like "john.gilmore%l5" will be caught and translated.
# The rest can only have an atom as the host name (left of the symbol).
R$-:$+			$@$>3$2@$1			host:user
R$-^$+			$1!$2				convert ^ to !
R$-!$+			$@$>6$2<@$1.uucp>		uucphost!user
R$-=$+			$@$>6$2<@$1.bitnet>		bitnethost=user
R$-.$+!$+		$@$>6$3<@$1.$2>			host.domain!user
R$+%$+			$@$>3$1@$2			user%host


#######################
#   Rewriting rules   #
#######################

##### special local conversions
S6
R$*<@$*$=D>$*		$1<@$2LOCAL>$4			convert local domain
R$*<@$*$=D.$U>$*	$1<@$2LOCAL>$4			or full domain name


############################################################
############################################################
#####
#####		UUCP Mailer specification
#####
#####		@(#)uucpm.m4 1.3 84/03/23 SMI; from UCB	3.6	3/26/83
#####
############################################################
############################################################

############################################################
############################################################
#####
#####		Provide Backward Compatibility
#####
#####		@(#)compat.m4 1.3 84/03/23 SMI; from UCB	3.3	2/24/83
#####
############################################################
############################################################



##########################################################
#  General code to convert back to old style UUCP names  #
##########################################################

S5
R$+<@LOCAL>		$@ $D!$1			name@LOCAL => sun!name
R$+<@$-.LOCAL>		$@ $2!$1			u@h.LOCAL => h!u
R$+<@$+.uucp>		$@ $2!$1			u@h.uucp => h!u
R$+<@$=S>		$@ $2!$1			u@etherh => etherh!u
R$+<@$+>		$@ $1%$2			u@any => u%any
# Route-addrs do not work here.  Punt til uucp-mail comes up with something.
R<@$+>$*		$@ @$1$2			just defocus and punt
R$*<$*>$*		$@ $1$2$3			Defocus strange stuff

Muucp,	P=/usr/bin/uux, F=sDFMhuU, S=13, R=23,
	A=uux - -r $h!rmail ($u)

# Convert uucp sender (From) field
S13
R$+			$:$>5$1				convert to old style
R$=w!$+			$2				strip local name
R$+			$:$w!$1				stick on real host name

# Convert uucp recipient (To, Cc) fields
S23
R$+			$:$>5$1				convert to old style



############################################################
############################################################
#####
#####		RULESET ZERO
#####
#####	domain.cf has a totally custom Ruleset Zero.
#####
############################################################
############################################################

# Ruleset 30 just calls rulesets 3 then 0.
S30
R$*			$: $>3 $1			First canonicalize
R$*			$@ $>0 $1			Then rerun ruleset 0

S0
# On entry, the address has been canonicalized and focused by ruleset 3.
# Handle special cases.....
R@			$#local $:$n			handle <> form
# For numeric spec, you can't pass spec on to receiver, since rcvr's
# are not smart enough to know that [x.y.z.a] is their own name.
R<@[$+]>:$*		$:$>9 <@[$1]>:$2		Clean it up, then...
R<@[$+]>:$*		$#ether $@[$1] $:$2		numeric internet spec
R<@[$+]>,$*		$#ether $@[$1] $:$2		numeric internet spec
R$*<@[$+]>		$#ether $@[$2] $:$1		numeric internet spec

# resolve the local hostname to "LOCAL".
R$*<$*$=w.LOCAL>$*	$1<$2LOCAL>$4			thishost.LOCAL
R$*<$*$=w.uucp>$*	$1<$2LOCAL>$4			thishost.uucp
R$*<$*$=w>$*		$1<$2LOCAL>$4			thishost

# Mail addressed explicitly to the domain gateway (us)
R$*<@LOCAL>		$@$>30$1			strip our name, retry
R<@LOCAL>:$+		$@$>30$1			retry after route strip

# deliver to known ethernet hosts explicitly specified in our domain
R$*<@$*$=S.LOCAL>$*	$#ether $@$3 $:$1@$2$3.$D.$U$4	user@etherhost.sun.uucp

# etherhost.uucp is treated as etherhost.$D.$U for now.
# This allows them to be addressed from uucpnet as foo!sun!etherhost!user.
R$*<@$*$=S.uucp>$*	$#ether $@$3 $:$1@$2$3.$D.$U$4	user@etherhost.uucp

# Explicitly specified names in our domain -- that we've never heard of
R$*<@$*.LOCAL>$*	$#error $:Never heard of host $2 in domain $D.$U

# Clean up addresses for external use -- kills LOCAL, route-addr ,=>: and etc.
R$*			$:$>9 $1			Then continue...

# resolve UUCP domain
R<@$-.uucp>:$+		$#uucp  $@$1 $:$2		@host.uucp:...
R$+<@$-.uucp>		$#uucp  $@$2 $:$1		user@host.uucp

# Pass Arpanet and Bitnet names up the ladder to our forwarder
R$*<@$*$-.arpa>$*	$#$M    $@$R $:$1@$2$3.arpa$4	user@anything.arpa
R$*<@$*$-.bitnet>$*	$#$M    $@$R $:$1@$2$3.bitnet$4	user@anything.bitnet

# All addresses in the rules ABOVE are absolute (fully qualified domains).
# (Note that all patterns end in a word, not a multi-matcher).
# Addresses BELOW can be partially qualified.

# deliver to known ethernet hosts
R$*<@$*$=S>$*		$#ether $@$3 $:$1@$2$3$4	user@etherhost

# other non-local names have nowhere to go; return them to sender.
R$*<@$+.$->$*		$#error $:Unknown domain $3
R$*<@$+>$*		$#error $:Never heard of $2; maybe you mean $2.arpa ?
R$*@$*			$#error $:I don't understand $1@$2

# Local names with % are really not local!
R$+%$+			$@$>30$1@$2			turn % => @, retry

# everything else is a local name
R$+			$#local $:$1			local names


#
# Host-dependent address cleanup:  strip Berkeley! relay off Arpanet mail
#
S8
#
# Handle from addresses that arrive over uucp from our Arpanet relay
# site.  They are passed to us in the -f argument from rmail, when uucp
# hands us the message.  Since many Arpa hosts are not qualifying their
# domains yet, we have to tack on ".arpa" if no domain is specified.
#
# If there's no atsign in the name, just let it on thru -- it's being
# relayed from a uucp site.
#
# THIS IS A KLUDGE OF THE EMERGENCY BROADCAST SYSTEM.  THIS IS ONLY A KLUDGE.
# It will have to stay around until our relay site passes us real
# domain-based addresses, at which point all we have to do is strip off
# the uucp garbage on the front.
#
R$=R!$*			$@ $>38 $2		Run thru 38 if came from relay!
# Otherwise, the address is OK as it stands.

# This address is from our Arpa relay site.  Fix it for slow Arpanauts.
S38
R$*			$: $>3 $1		Canonicalize, focus rest of it
R$*<@$-.uucp>		$@ $2!$1@$R.uucp	If uucp addr, leave relay on.
R$*<@$*LOCAL>$*		$@ @$R.uucp:$1@$2$D.$U$3	If LOCAL, deloc&relay
R$*<@$+.$*>$*		$@ $1@$2.$3$4		If domain known, defocus&return
R$*<@$+>$*		$@ $1@$2.arpa$3		If not, "arpa", defocus&return
R$*<$*>$*		$@ $R!$1$2$3		Restore unknown strangenesses
R$*			$@ $R!$1		Restore unknown strangenesses

# Kludge to deal with non-UGLYUUCP mail from our relay site.
# Adds host "somewhere" to the class containing our relay site.  It will
# be translated to the real name, or removed, by the S8 code.
CRsomewhere



Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA08063; Tue, 23 Oct 84 21:26:36 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.17/4.26)
	id AA20225; Tue, 23 Oct 84 21:34:21 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26)
	id AA03783; Tue, 23 Oct 84 21:34:18 pdt
Date: Tue, 23 Oct 84 21:34:18 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8410240434.AA03783@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: UUCP mail addresses

Forwarded from USENET "net.mail" news group:
------
From hokey@plus5.UUCP Tue Oct 16 20:47:42 1984
Newsgroups: net.mail
Subject: Re: parsing host1!user@host2 - a new idea
Article-ID: net.mail/533

I was hoping I could stay out of this.  Where do you want to use
these headers?  In the transport address (the stuff sent to rmail)?
what about the addresses used in the From: and To: lines?

The uucp-mail project has addresses these issues in gory detail.  I will
tell you the decisions that have been reached.  I hope I don't get a lot
of mail on this issue because I need to get the new mail software out in
a hurry.  I believe the issues should be aired ASAP.  Many of the others
on the project would rather wait until the software is ready before mouths
are opened.  I am not always wasy to work with.  Many are concerned that
rehashing these issues will unnecessarily delay the project.  I hope I
am not the only one from the project addressing these issues, because I
have code to write.

First, all addresses sent *from* the new software across uucp will be in
strictly bang format.  Mail to user@dom.ain will be converted to dom.ain!user.
This works for almost all of the cases (the exception being explicitly
routed RFC822 addresses across gateways, near as I can tell).  Mail sent
*to* the new software will accept non-hybrid addresses only, because of
the parsing ambiguity.  This means mail to a!b@c.d will be rejected by
the new rmail.  This is necessary because the mail must go through, and
If, Someday, we all end up with RFC mailers, the parsing of addresses
will change and then we are all in trouble again.

Sendmail sites should leave the From: and To: lines *alone*.  There is
a difference between an address and a route.  Non-RFC mailers won't
look at these lines for replies, and they certainly won't update them
when the mail passes through their site!  These addresses should be
in RFC822 format *if you are using an RFC mailer*.  If a non-RFC
mail message passes through an RFC mailer, it *might* add a From:
line and an Apparently-to: line.  The >addresses< on these lines should
probably take the form  "a!b!c"@thissite  and thissite should be qualified
(site.UUCP) if the site is registered with the Uucp Site Registry
(lauren@vortex.UUCP).

This implies that the mailers invoked by sendmail should be able to
handle routing to non-neighbors, by using things like pathalias.  Note
that routing information is added, the addresses are not changed.  Rob
Warnock wrote a very clear discussion on the issue of route optimization
which clearly states the conditions under which paths may be rerouted.

Sites like ihnp4 optimize paths because many people do not have access
to RFC mailers or routing software, so when people reply to news articles
the mail goes along a path which is usually absurd.  My solution to
the problem of Path: replies to mail is for (at least) the first "smart"
registered site in the path to use its fully-qualified name.  This means
it is safe for any other "smart" mailer to optimize directly to the last
fully-rooted machine on the path.  This may be enough to prevent the
"optimization" of explicitly specified paths.  Chuqui can still send
out his looping paths to check path validity and the speed with which
the message travels, without worrying that the path will be "fixed"
for him.

This also means that these smartmailers will handle mail to other domains
as well as recognizing subdomains.  Just think, no more problems with
the duplicate named machines gang, vortex{.DEC,.UUCP}, rigel{.sun.UUCP,
.oddjob.UUCP}, regina{.DEC,.UUCP}, and a host (no pun...) of others!
Leaves you kind of breathless, huh?  This also means that you could
send mail to, say, ucbvax!site.CSNET!user and not have to worry about
the hilarious contortions with csnet-relay.  Specifically, you would
only have to address the mail to *any* convenient smarthost!do.ma.in!user
and it will get there (assuming the addressee exists!).

I have left out a lot of points in my discussion.  These ideas have been
gone over quite thoroughly by many people, and I have done a mediocre
job of covering the issue.  Many of the problems must be solved in
specific places.  The use of parentheses in an address will mess up
most sendmail sites in the universe.  We can leave most of the routing
software alone if we have user-interface mailers which do the job they
are supposed to do, specifically, produce an *appropriately* formatted
mail message with the help of the user.  This stuff must be easy to use,
and should not get in our way.  We are getting there.
-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492


Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA07823; Tue, 23 Oct 84 21:15:01 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.17/4.26)
	id AA19925; Tue, 23 Oct 84 21:22:48 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26)
	id AA03686; Tue, 23 Oct 84 21:22:49 pdt
Date: Tue, 23 Oct 84 21:22:49 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8410240422.AA03686@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: mail address parsing

Forwarded from Usenet "net.mail" news group:
---------
From gnu@sun.uucp Tue Oct 16 23:14:12 1984
Newsgroups: net.mail
Subject: Re: parsing host1!user@host2 -- the real fix
Article-ID: net.mail/528

Several people have recently suggested that ( and ) be used in
addresses to define precedence.  While this would be a great idea
if it had been standardized, instead most of the left- and right-
matching characters have been standardized in the Arpanet formats
to mean various other things:

	address (comments)
	comments <address>

We could perhaps use [ ] or { } to accomplish this, but this will not
work unless every host we go through uses the same conventions.  The
only precedence conventions defined in the Arpanet RFC's do it by
quoting; if you want to nest quoted things you have to double all the
internal quotes.  Needless to say this makes for very messy looking
addresses which are easy to type wrong.  This is one of the failings
of the Arpanet RFC's and one I hope they'll address in the future.

Most people have come around to agreeing that if we all standardized on
one naming convention, rather than mixing two or more conventions
using ! @ : ^ . % etc, we could all talk to each other.  Furthermore, 
that the Arpanet domain naming convention is reasonable enough to use.
The rest of the question as far as UUCP mail is concerned revolves
around two implementation questions:

     *	How do we take an address like mark@cbosgd.att.uucp and deliver
	the mail to the right place (routing)
     *	How do we implement the above without breaking all the existing
	uucp sites?  (eg, avoid routing mail which should not get
	rerouted; avoid generating return addresses old sites can't handle)

There's a task force (cbosgd!uucp-mail) working on these issues now and
software is being readied for eventual release in net.sources.  Stay tuned.



Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA07788; Tue, 23 Oct 84 21:12:14 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.17/4.26)
	id AA19889; Tue, 23 Oct 84 21:19:55 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26)
	id AA03666; Tue, 23 Oct 84 21:19:52 pdt
Date: Tue, 23 Oct 84 21:19:52 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8410240419.AA03666@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: mail address parsing

Forwarded from USENET news group "net.mail". (Note "From" line is not
a full UUCP mail address, so don't try to reply to ...@nsc.uucp unless
you have a UUCP path expansion server.)

------------
From chongo@nsc.UUCP Tue Oct 16 02:11:14 1984
Newsgroups: net.mail
Subject: Re: parsing host1!user@host2 - a new idea
Article-ID: net.mail/526

Chuqui has some good points in his article.  To remove confusion, why not
allow '('s?  You could say:

		(host1!user)@host2  -or-  host1!(user@host2)

The '(' is your friend.  (and so is ')')


Always keep in the message, where the message has gone.  If a message hits
a dead/wrong end, DONT opt. the path of the return message.


On another point, I think each site should not just blindly adjust the
path of a message.  Here are some reasons why:

	1) I don't want site foo to receive my letter because the uucp
	   manager just learned how to monitor letters and kills messages
	   which he/she does not like.  (this actually happened in a
	   local S.F. site)  The normal path might be:
			   a!bletch!foo!bar!mojo
	   but I want:
			a!bletch!curds!and!whey!bar!mojo. 

	
	2) There are too sites named foo.  I send a letter to:
			    a!bletch!c!d!e!foo!mojo
	   but bletch changes the path to:
				a!bletch!foo!mojo
	   where e!foo is not the same site as bletch!foo.



I can see a site adjusting a domain directed message path if it is a gateway,
or sending it on to a gateway site if it is not.  The cases where you want
a forced path are few.  Most of the time, mailer path opt. does help.
But there ARE reasons who you might want to force a given path.


I have a suggestion and another use for the '(' in a path.  Let the
'(' guide you on which paths NOT to touch.   For example:

	a!b!c!(x!y!z)!d!e!foo!mojo  where (x!y!z) is a path expression.

We will talk about this path below, so keep it in mind.

Here is some ideas on how to treat this path expression:

	- Deal with the path  c!(expression)!d  as a glued in path and
	  NOT subject to change.  That is,  c  MUST receive the message and
	  pass it along to the leftmost site inside the expression.  The
	  rightmost site MUST send the message to site  d.  In other words,
	  c!x and z!d are 'glued' in.

	- Disallow a site to change the path to the right of any expression.
	  That is, site  b  can not change the  d!e!foo!mojo path because
	  it is to the right of the path expression.

	- Allow any site within an expression to ONLY change the path inside
	  that expression.  That is,  x  can send it along to  z  and bypass
	  site  y  if it wants to, but dont allow  x  to send it to  d  or  e.

	- Pull the left '('s along until you reach a right ')'.  The life
	  of the path could go like:

	  a!b!c!(x!y!z)!d!e!foo!mojo	- as sent by the user
	    b!c!(x!y!z)!d!e!foo!mojo    - the users site talks directly to the
					  site  b, so  a  is bypassed.  The
					  users site also talks to e, but
					  sending directly to  e  would bypass
					  the expression.
	      c!(x!y!z)!d!e!foo!mojo    - b sent it to c.
		(x!y!z)!d!e!foo!mojo    - c is FORCED to send it to x.
		  (y!z)!d!e!foo!mojo	- x sends it to y.
		    (z)!d!e!foo!mojo	- y sends it to z.
			d!e!foo!mojo	- z is FORCED to send it to d.  The
					  '('s meet and they go away.
			    foo!mojo	- d can send directly to foo, and does.
					  here mojo gets the message.


Some additional notes, expressions can be nested.  Such as:

		a!(b!c!(x!y!z))!d!e!(foo)!g!mojo

a MUST send to b;  c MUST send to x;  z MUST send to d;  e MUST send to foo;
foo MUST send to g.


chongo <nsc!(chongo)!bats> /\(--)/\
-- 
 ~ Imagine UN*X source, being in the public domain... ~ 
					J. Alton 84'



Date:     Thu, 25 Oct 84 7:57:02 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       header-people@mit-mc.ARPA
cc:       gurus@BRL-TGR.ARPA
Subject:  Domain Specification


Date:     Thu, 25 Oct 84 11:20:25 EDT
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       header-people@mit-mc.ARPA
cc:       gurus@BRL-TGR.ARPA
Subject:  Domain Specification

Well, I was trying to mail to

	princeton!down!north@seismo.ARPA

But what he received was

	Date:     Wed, 24 Oct 84 10:11:51 EDT
	From: Ron Natalie <princeton!seismo!ron@BRL-TGR.ARPA>
	To: princeton!down!north@seismo.domain
	Subject:  Re:  windham hill

Obviously some aspect of "domain" specification that I overlooked while
reading the RFC.

-Ron

Date: 31 October 1984 21:06-EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Interesting bug
To: HEADER-PEOPLE @ MIT-MC

There are really two bugs here, but it's the sendmail one that seems
to need publicizing so all the sites using it can fix their programs.
	--Ken

Received: by rand-unix.ARPA; Mon, 29 Oct 84 11:14:15 pst
From: Terry West <terry@rand-unix>
Message-Id: <8410291914.AA15962@rand-unix.ARPA>
Date: 29 Oct 84 11:14:11 PST (Mon)
To: postmaster@mit-mc
Cc: guyton@rand-unix, terry@rand-unix
Subject: Mail Problem

Hi,
   Last night we had a problem with a msg from your site that caused
our SMTP server (sendmail) to loop.  The problem appears to be a bogus
MAIL FROM line "<Eliot Moore <Elmo@Mit-MC>@MIT-MC>".  This morning
I changed the config file to prevent the loop, and successfully
received the problem msg.  If this msg is being sent to any other
sites running sendmail, I'd suspect they're also having problems.
Here's an extract from our log file.

P347
T467924367
DdfAA15710
S<Eliot Moore <Elmo@Mit-MC>@MIT-MC>
Rwescourt@isi
H?P?return-path: <Elmo@Mit-MC>
Hreceived: from mit-mc.arpa by rand-unix.ARPA; Mon, 29 Oct 84 10:59:27 pst
H?x?full-name: 
H?M?message-id: <8410291859.AA15710@rand-unix.ARPA>
Hdate: 28 October 1984 04:12-EDT
HFrom: Eliot Moore <Elmo@Mit-MC>
HSender: ELMO @ MIT-MC
Hsubject:  Special K's
HTo: HEATH-PEOPLE @ MIT-MC
Hreply-to: Elmo@USC-ISIB

   Thanks,

      Terry West

