Date:           Mon, 23 Jan 84 10:38:40 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Funny headers from LBL-CSAM

For some time now, whenever someone at LBL-CSAM has made a contribution
to the UNIX-Wizards mailing list, the "From" line of the header has been
munged.  Here is a recent example (note particularly the lines I have
indicated with arrows on the left):

    Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  22 Jan 84 12:55 EST
    Received: From Lbl-Csam.ARPA by BRL via smtp;  22 Jan 84 12:44 EST
    Return-Path: <mo@LBL-CSAM>
    Received: by lbl-csam.ARPA ; Sun, 22 Jan 84 09:45:37 pst
    Date: Sun, 22 Jan 84 09:45:37 pst
==> From: Mike O'Dell@BRL-VGR.ARPA, mo@lbl-csam
==> MMDF-Warning:  Parse error in preceeding line at BRL-VGR.ARPA
    Message-Id: <8401221745.AA21328@lbl-csam.ARPA>
    To: unix-wizards@brl
    Subject: NULL pointers

Note that the "From" line in the above header is invalid according to
RFC822, since the first address (Mike O'Dell@BRL-VGR.ARPA) contains a
space in its "local-part".  Further, of course, this first address is
incorrect, since Mike O'Dell is in fact not at BRL.

I assume the munging in question is probably taking place at BRL-VGR
(based on the "MMDF-Warning" line).  I know it is not happening here
at UCLA-LOCUS, since we do not use MMDF and our mail handler does not
modify "From" lines of incoming ARPANET mail in any way.

On several occasions, I have asked various people at LBL-CSAM to send me
test messages so that I could see what their "From" lines looked like
(again, hoping to take advantage of the fact that my system's mailer
doesn't munge "From" lines).  I have never succeeded in getting any
reply.  I don't know whether this is because the people I have asked
thought I was a busybody or a crackpot, or because my messages simply
never arrived.

Can someone (at BRL and/or at LBL) explain and/or fix this problem?

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

P.S. to MMDF gurus:
    "Preceeding" is a misspelling.  It should be "preceding", since the
    base form of the word is "precede".

Date:           Wed, 25 Jan 84 20:36:35 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        What time zone is Alaska in?

A few weeks ago, I thought I heard a fleeting news item on the radio to
the effect that Alaska was changing its time zone.  Rather than continue
to be split across three zones (Yukon, Alaska/Hawaii, and Bering) -- so
the story went -- all parts of Alaska would henceforth keep Yukon time
(GMT-9; GMT-8 in summer).

Is the above actually the case, or was I suffering from a sophisticated
aural hallucination?

If this is true, then I suppose the long-standing confusion between BST
(Bering Standard Time) and BST (British Summer Time) no longer exists.
I wonder whether the Alaska Legislature contains any mail hackers.

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

Date: 26 Jan 1984 0102-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: v.wales at UCLA-LOCUS, Header-People at MIT-MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: Re:        What time zone is Alaska in?
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11986600382.12.132.8699 at DEC-MARLBORO>
Regarding: Message from           Rich Wales <v.wales@UCLA-LOCUS>
              of 25-Jan-84 2343-EST

What you heard on the radio is almost true.

Alaska used to have FOUR time zones:  Bering for the Aleutian Islands
and the mainland points along the Bering Sea and Strait, Alaska for
most of the state, Yukon for ONLY Yakutat, and Pacific for the area
around Juneau.

Now there are two.  All the mainland points (including Juneau!) have
moved to Yukon time (UCT-9).  The Aleutians are now on what used to
be Alaska time (UCT-10) -- the same as Hawaii time.

But the people at the Weather Station at Shemya don't know what the
name of their timezone is.  Since this was done on the day they would
have otherwise dropped from BDT back to BST, they think they're still
on Bering Time (since they didn't change time).
   --------

Date:     Thu, 26 Jan 84 12:57:32 EST
From:     BRINT <abc@brl-bmd>
To:       header-people@mit-mc
Subject:  [Makey.DODCSC:  Faster-Than-Light Travel Demonstrated]


----- Forwarded message # 1:

Received: From Brl.ARPA by BRL-BMD via smtp;  26 Jan 84 3:57 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  26 Jan 84 4:06 EST
Received: from Mit-Multics.arpa by sri-unix.arpa with TCP; 25 Jan 84 7:48-PST
Date:  25 January 1984 10:41 est
From:  Makey.DODCSC@mit-multics
Subject:  Faster-Than-Light Travel Demonstrated
To:  Physics@sri-unix

(enter Sarcasm mode)

>>> Subject:  Question about Helmut Schmidt's PSI experiment
>>> Date:  Sunday, 29 January 1984 21:26 est
>>> From:  ihnp4!ihuxr!lew at UCB-VAX
>>> To:  physics at SRI-UNIX
>>> Article-I.d.:  ihuxr.855

     At last!  The above is conclusive evidence that faster-than-light
travel is possible.  The message with the above header was received
more than four days *BEFORE* it was sent.  The only way this could
conceiveably have happened is if the message traveled faster than
light from ihuxr to SRI-UNIX.  (If there were only some way to get this
kind of network thruput on a regular basis!)  This is the kind of scoop
that the National Inquirer pays big bucks for, but you saw it first on
net.physics!

			:: Jeff Makey

----- End of forwarded messages

Date:           Sat, 28 Jan 84 01:24:39 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Several questions/comments on time zones

Here are several questions/comments on time zone abbreviations and
usages.  I am including all of this in one message for the sake of con-
venience.  Please feel free to comment on only some of what I say below,
even if you don't have anything to say about all my points.

Also, I would especially like some feedback from the people who live
(or have lived) in the areas involved, and who therefore have first-
hand knowledge.

Some of this material may seem out of place, given that we haven't been
arguing these issues lately.  However, I hope that whoever out there is
planning possible future revisions of mail standards will take note of
this message and any authoritative answers it generates.

(1) It has been suggested a few times that time stamps be expressed
    either in UTC or as the number of seconds past a given starting
    point.

    I feel, however, that such an approach would be less than ideal,
    because the sender's local time of day may be a useful piece of
    information for the recipient to have.
    
    For example, suppose all "Date" lines had to show time in UTC.  If
    I were to send a message between 1600 and midnight (according to my
    local time, PST), the "Date" line would indicate the next day, since
    1600 PST = 0000 UTC.  If my message's body contained a "relative"
    time expression such as "today", the recipient might be confused as
    to which day I meant unless he knew my physical location (and thus
    my local time zone).

    (Admittedly, this same problem could occur today, in cases where a
    user and his computer are widely separated.  However, I would assume
    that the local time of the user and the computer are the same more
    often than not.)

(2) People have discussed which term is "most" correct for the standard
    time zone around the prime meridian -- UTC, UT, or GMT.

    (a) What do the British, Irish, and whoever else falls in this time
	zone call their time?  (Judging from "Date" lines in messages
	from UCL-CS, I would assume the answer to my question is "GMT";
	however, could someone from the UK or Ireland speak up and say
	definitively?)

    (b) Assuming that "Date" lines are to reflect the sender's local
	time, it seems wrong to make the British and Irish say "UT" or
	"UTC" if their local custom is to say "GMT".  If other people
	somewhere want to use "UT" or "UTC", maybe the only equitable
	solution is to give all three abbreviations equal status.

    (c) This entire discussion becomes moot, of course, if we all end
	up using numeric offsets instead of time-zone abbreviations.

(3) Would some Canadian on this list confirm or correct the following
    time zone abbreviations:  NST/NDT (Newfoundland); AST/ADT (Atlan-
    tic); and YST/YDT (Yukon)?

    Also, am I correct in assuming that the Alaskans too use YST/YDT
    for Yukon time?

(4) Does Hawaii use the abbreviations HST and HDT?  For that matter, do
    they even have daylight savings time in Hawaii?  (Hawaii's close
    enough to the equator that I suppose it might not make sense for
    them to use daylight savings time.)

(5) According to John Covert at DEC-Marlboro (message of 26 Jan 84),
    Alaska is down to two time zones now (UTC-10 for the Aleutians and
    UTC-9 for the rest of the state).  Are the people in the Aleutians
    going to end up calling their time zone HST/HDT (since it's the same
    as Hawaii time)?  Or will they use AHST/AHDT ("Alaska/Hawaii")?  Or
    even AST/ADT ("Alaska", or "Aleutian")?
    
    If they decide to call it AST/ADT (and thus create a conflict with
    Atlantic time), I say forget it -- the Atlantic time zone has first
    dibs on the abbreviation (and more people, too!), and the Aleutians
    can use a numeric offset if they don't like HST/HDT.

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

Date: 29 Jan 1984 0018-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: header-people at MC
cc: v.wales at UCLA-LOCUS
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: Time Zones
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11987378875.24.132.12239 at DEC-MARLBORO>

I would strongly support use of the ISO standard with local time and
a numeric offset.  As Rich says, the local time is an important piece
of mail context.  The offset allows it to be easily compared to the
recipient's local time or any other time.

I'd like to see the name of the zone as well (as a comment, like John
Covert is a comment in the From: header).  We can't expect standardi-
zation of time zone names, because you aren't going to get people in
Paris and Munich to agree on only one of HEC and MEZ.  The German
abbreviation in the summer is MESZ; I don't remember the French.

As an aside, remember that all locations that use Daylight Savings
time do not switch on the same date.

Hawaii does not observe Daylight Savings time.  Note that the historical
information I've provided on time zones in the North American integrated
telepone numbering zone comes from the V&H tape.  Since I don't have a
new tape yet, my info on Alaska came from making several phone calls to
police and weather stations.

Prior to the switch in Alaska, there were only THREE locations with
dial telephones on Yukon time (one in Alaska and two in the Yukon
Territory) and twelve more ringdown call boxes in the Yukon Territory.
Whitehorse, YT is on Pacific time.
   --------

Date: 29 Jan 84 0035 EST
From: Rudy.Nedved@CMU-CS-A
To: Rich Wales <v.wales@UCLA-LOCUS>
Subject: Re: Several questions/comments on time zones
CC: Header-People@MIT-MC
In-Reply-To: "Rich Wales's message of 28 Jan 84 04:24-EST"
Message-Id: <29Jan84.003557.EN0C@CMU-CS-A>

Rich,

I have two views of mail:

1) What you see on your screen is what is actually sent. Therefore
   the time zone is that time zone that you are in including daylight
   savings problems. If you send to another zone, you may or may not
   have problems but I don't see any simple solution because I feel
   the philosphy used by the composer and delivery agents is wrong...

2) What you see on your screen is encoded into a recusive data structure
   that is handled a specified way at each interface but the representation
   can be changed as it is moved until it reaches another software
   interface. The time zone should be displayed as the local time zone but
   stored in the encoded version as an absolute offset of GMT time. When it is
   displayed in the new zone, you get the readers time zone instead of the
   senders time zone information. The senders time zone information (offset) should
   be included so that some set of users can change the "local time zone" and
   see what time the sender sent the mail at (in case you want to know if the
   guy was working late before giving him a call).

The RFC822/RFC733 is mostly of philosphy (1) even though I and other
people at CMU wish it was different. There are just too many mail
systems out in the internet that have simple/trivial mail
composers/readers. I don't expect this to change given there is no
motivating force that if people don't add code things do not work.

I am waiting for multimedia mail and therefore philosphy (2) to
happen.  There however is some confusion in the world that I wish DCA
or DARPA would clear up: Which multimedia specification should people
follow??  I hear of one being created by DARPA, one at NBS and one at
CCITT. If the issue every comes up around CMU...I am pushing for the
CCITT one since Xerox has picked it and it is a more complete
specification then the NBS one.

-Rudy

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA08870; Sat, 28 Jan 84 21:15:46 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.11) id AA21448; Sat, 28 Jan 84 21:10:09 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.13/4.11) id AA03216; Sat, 28 Jan 84 21:01:58 pst
Date: Sat, 28 Jan 84 21:01:58 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8401290501.AA03216@ucbopal.CC.Berkeley.ARPA>
To: Header-People@MIT-MC, v.wales@UCLA-LOCUS
Subject: Re:  Several questions/comments on time zones

On zero time zone designators:

In addition to UT, UTC, Z, and GMT, I have also heard of GCT
(C for Civil).

Z ("Zulu" or "Zero" time zone) is the military term. As far as US Armed
Forces is concerned, it is the time transmitted by the Dept. of
Commerce radios stations WWV and WWVH (hope I got the call signs
correct). WWV previously transmitted GMT time, but since the early/mid
70's has been transmitting Coordinated Universal Time(UTC). Perhaps
someone can give us some history of the name change. GMT, GCT, PST/PDT,
etc.  are local Civil time designators. UT and UTC maybe defined by
international treaty/agreement (anybody know?).

I also suspect that UTC is not the same as GMT (seconds apart?).

Does any one have the name of time used by the "star gazers"?

On date/time stamping of message:

Things would be a lot easier if messages on the network would be dated
and time stamped with UTC (or "Z") time. If you want local time and
date presented/used by your users, convert the time and date in your
presentation (user interface) program(s). The military, and I think,
most international communications companies use only one time zone to
identify messages.  Why can't we?

On converting UTC to/from local time:

	01:00:01 01 Jan 84 UTC	is	17:00:01 31 Dec 83 PST

Note the day and year difference. When converting local time to UTC,
the day and year must be converted as well.  It's not hard to do. For
PST, the rule is to add 8 hours to the current time (since the sun
comes up 8 hours earlier in England than it does on the U.S. West
Coast). If the resulting hour is greater that 24, subtract 24 hours
from the hours and add 01 to the day (and add 1 to the year if the
original day is 31 Dec).  (For PDT add 7 instead of 8 hours to get
UTC). I will let you figure out how to convert the other way.

New subject: When does the day change?

Or is 00:00:00 today, really 24:00:00 yesterday?
I think the military avoids the issue by never using 00:00 or 24:00
(hours and minutes) to identify messages.

Bill Wells
wcwells@Berkeley.ARPA

Date: 29 Jan 1984 0138-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: header-people at MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: GMT vs UCT
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11987393385.24.132.7490 at DEC-MARLBORO>

Greenwich Mean Time is solar time at the the Greenwich Meridian; it varies
with the variations in the rotation of the the earth.

Coordinated Universal Time is an absolute time which can differ from GMT
by almost a second.  Leap seconds are inserted when convenient to keep UTC
within one second of GMT.

UTC is easier to track at independent locations on earth because all you
need is the proper oscillator (I think the element used recently changed).
To track GMT, you need an observatory.

I've never heard GCT used related to time (I always thought it was Grand
Central Terminal :-)
   --------

Date: Sun, 29 Jan 84 08:35:43 cst
From: solomon@wisc-crys (Marvin Solomon)
Message-Id: <8401291435.AA00179@wisc-crys.ARPA>
Received: by wisc-crys.ARPA (4.22/3.7)
	id AA00179; Sun, 29 Jan 84 08:35:43 cst
To: header-people@mit-mc
Subject: Re: Several questions/comments on time zones

This is another example of the pitfalls of confusing an interchange
standard with a user-interface standard.  Users would prefer to
see dates in local-time format, but interchange programs would prefer
something a bit more uniform and structured.  If RFC 733 (and its successor,
822) had not made the mistake of defining a mail header in such a way as to
make it appear to be designed to be read, the header could encode dates in
any form convenient for exchange (some encoding of UT), and users who
wanted to read or send mail would be FORCED to write or have written
a program to translate to/from local time.  (You may interpret this as
a plug for the new NBS standard).

By the way, in most cases, the "local time" the user would prefer to
see in messages is his OWN local time.  For example, when I'm reading
a message from somebody and want to know whether he wrote it before
or after some particular event (for example, I want to know whether
he wrote it early enough that it's likely he saw a particular message
from me), I'd rather see the Date line expressed in my own local time.
Whenever I have to look at Received lines, I find that even to sort them in
chronlogical order, I have to mentally convert to local time (or some other
fixed time zone).  Offhand, I cannot think of any situation where I want
to see the Date line in the sender's local time, and I would argue that
NOBODY wants to see maintenance timestamps (such as Received) expressed
in the time zone where they were inserted.

Date:  Sun, 29 Jan 84 10:03 EST
From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Subject:  Re: Several questions/comments on time zones
To:  header-people@MIT-MC.ARPA
In-Reply-To:  Message of 29 Jan 84 09:35 EST from "solomon at WISC-CRYS (Marvin Solomon)"
Message-ID:  <840129150352.738172@MIT-MULTICS.ARPA>

I find it helpful to get a hint of where in the world a correspondant
is.  The time zone does that.

Further, I confess that the precise time of a message is a much better
indicator of the prospective state of mind of the sender than it is
anything else.  I like to know that it was 9am from the senders point of
view and not, for example, midnight.

Finally, I think your argument is moot.  pseudo-readable or not, 733
date-times are quite definitely parsable.  Your user interface program
is welcome to digest them and re-present hem in local time.  rfc733
times are no more or less "standard", iff a reasonable set of zone
appreviations is in use.

Date: 29-Jan-84 11:14 PST
From: Rich Zellich  <RICH.GVT@OFFICE-3>
Subject: Re: Sender's time zone
To: Header-People@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-408G1>

I, too, sometimes use the sender's date/time field to get an idea of when the 
author sent the message, but you must remember that it can't be relied upon 
because of networking.  I, for instance, am in St. Louis on CST but the host I 
usually send mail from is in Cupertino, CA and is on PST; you will therefore see
PST time-stamps on some messages I send (and CST on others, because one of my 
mail systems allows me to specify which time-zone to use).  Seeing PST time 
stamps on my messages won't much help anyone tell when I sent it (if they want 
to know if it's too early/late to phone me, or something like tht).

-Rich


Date: Sun 29 Jan 84 13:26:36-PST
From: David Roode <ROODE@SRI-NIC>
Subject: Re: Sender's time zone
To: RICH.GVT@OFFICE-3, Header-People@MIT-MC
In-Reply-To: Message from "Rich Zellich  <RICH.GVT@OFFICE-3>" of Sun 29 Jan 84 11:14:00-PST
Location:  EJ286    Phone: (415) 859-2774

I think that a user's time zone should be settable, at least for
message timestamps, on a system which serves more than one zone.  Thus
he should be able to insure that messages will be stamped with the
time he was experiencing as he set them.  Failing that, maybe the
system in Cupertino could keep Eastern time.  I know of one
information retrieval utility that uses Eastern time on its system
(for everyone) allthough it is located in the Pacific time zone.
-------

Received: by RICE (AA22355); Sun, 29 Jan 84 17:06:09 cst
Received: by RICE-JANUS (AA00566); Sun, 29 Jan 84 16:56:29 cst
Date:     Sun, 29 Jan 84 16:39:59 CST
From: Paul Milazzo <milazzo@rice>
Subject:  Re: Several questions/comments on time zones
To: solomon@wisc-crys (Marvin Solomon)
Cc: header-people@mit-mc
Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice>
In-Reply-To: a message from Marvin Solomon dated Sun, 29 Jan 84 08:35:43 cst

	"If RFC 733 (and its successor, 822) had not made the mistake
	of defining a mail header in such a way as to make it appear to
	be designed to be read, the header could encode dates in any
	form convenient for exchange (some encoding of UT) [...]."

It is my understanding that RFC 733 did not invent the contents of a
mail header; similar formats had been in use for some time.  RFC 733
simply tried to make known (and perhaps official) the various de facto
standards which had sprung up in the Internet community.  Thus it
became a sort of "conglomerate standard".  I consider this effort a
noble one, if perhaps incompletely successful.

				Paul G. Milazzo <milazzo@rice>
				Dept. of Mathematical Sciences
				Rice University, Houston, TX

Date:     Mon, 30 Jan 84 11:08:26 EST
From:     BRINT <abc@brl-bmd>
To:       header-people@mit-mc
Subject:  Sender's Time Zone

For what it's worth, I use the sender's date/time field for nearly all the
reasons mentioned by others. 

The application most-often invoked, however, seems to be to identify duplicate
messages (suspected) when reading mail.

Brint

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA25935; Mon, 30 Jan 84 16:06:35 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.11) id AA13154; Mon, 30 Jan 84 15:56:58 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.13/4.11) id AA09824; Mon, 30 Jan 84 15:40:24 pst
Date: Mon, 30 Jan 84 15:40:24 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8401302340.AA09824@ucbopal.CC.Berkeley.ARPA>
To: header-people@MIT-MC.ARPA
Subject: Re: Several questions/comments on time zones

I believe we need to have two types of date-time stamps:  UTC (or Z)
and local. Machine readable date-time fields of messages in transit
should be in UTC to make programming easier for mail transport
programs. The senders local time stamp could be added as a comment when
message is transmitted. Simple mailers could be required to use UTC,
more complex mail programs could do local time conversion.

Here is an example of how dates could be changed when displayed to
the user and when passed to the mail transport system:

        a. Mailer/Mail composition program using local date displays:

	Date:  Sun, 29 Jan 84 10:03 EST

or
	
	Date:  Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)

(I prefer the latter) but transmits:

	Date:  Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)

to the mail transport system.

        b. Relaying and receiving hosts would use only UTC at the mail
transport level. Thus with a "received" field added the header might
become:

	Date:  Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
	Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
		id AA00611; Sun, 29 Jan 84 17:53:41 utc

       c. The receiver (addressee) of the message should have the option
of displaying "Date" and "Resent-Date" in either the transmittted
mail transport form:

	Date:  Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
	Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
		id AA00611; Sun, 29 Jan 84 17:53:41 utc

or with the UTC part of the "Date" and "Resent-Date" changed to the
receiver's local time:

	Date:  Sun, 29 Jan 84 07:03 PST (Sun, 29 Jan 84 10:03 EST)
	Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
		id AA00611; Sun, 29 Jan 84 17:53:41 utc

(Note that the "received" field date-time remains in UTC. The message
should be stored in its "mail transport form".)

	d. Referencing of the received message would use the full
date-time field:

	In-Reply-To:  Message of Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
		from "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>

The nice thing about the above scheme is that only one time zone is
used at the mail transport level and we do not have to change RFC822
to implement the above since a () comment field maybe used now with any
header field.

Bill Wells
wcwells@Berkeley.ARPA

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA26612; Mon, 30 Jan 84 16:58:12 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.11) id AA13388; Mon, 30 Jan 84 16:37:42 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.13/4.11) id AA10569; Mon, 30 Jan 84 16:26:51 pst
Date: Mon, 30 Jan 84 16:26:51 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8401310026.AA10569@ucbopal.CC.Berkeley.ARPA>
To: header-people@MIT-MC.ARPA
Subject: Re: Several questions/comments on time zones

It looks like UT (or maybe UTC) = GMT = GCT = Z. 

Here is a reply I received from David J. Bryant via Mark Horton
<cbosgd!mark@Berkeley.ARPA>:
-------
Date: Sun, 29 Jan 84 18:56:43 est; From: mark@cbosgd.UUCP (Mark Horton)
To: wcwells@ucbopal; Subject: star gazers time

Here is an answer to your star gazers questions

Date: Sun, 29 Jan 84 18:21:08 est; From: djb (David J. Bryant)
To: mark; Subject: Re: can you please answer the "star gazers" question in this?

Astronomers time stamp observations and events according to Universal
Time (abbreviated UT).  This is based on atomic clocks and mathematical
standards according to definition of the International Astromical Union
(I.A.U.).  Further, Greenwich Mean Time (GMT) is defined to be the same 
as UT, and applies to the standard meridian (longitude 0 degrees).  Greenwich
Civil Time (GCT) is synonymous with GMT.

WWV and WBS (in England) broadcast UT (which is therefore also GMT, and
for the military, Z ("Zulu") time.  This is a worldwide standard reference,
and probably the best for your purposes.  (Elaine says that CompuServe
used UT for ALL their record keeping, login accounting, etc.)

There are other time schemes as follows:

	Apparent Time - The time indicated by a sundial.  Because the
		     Sun's speed across the sky is not uniform, this
		     varies throughout the year, and is useless for
		     time reckoning.
	Mean Time  - To avoid the non-uniformities of Apparent Time, a
		     fictitious "mean sun" is invoked; this moves across
		     the sky at a constant rate throughout the year.  Mean
		     Time, like Apparent Time, is purely a function of your
		     longitude, and so is too variable for much civil use.
	Civil Time - This is what the clock on the wall is set to.  It
		     is based on the concept of Time Zones, Daylight
		     Saving Time, etc.  Each time zone is homed on a
		     central meridian, and the mean time for that meridian
		     is used as the civil time throughout the time zone.
		     Other adjustments (Daylight Saving Time) apply as
		     required.
	Sideral Time - Unlike all the above, which is based on the 24 hour
		     solar day, Sideral Time is based on the 23h 56min
		     "star" day.  There are numerous flavors of Sideral
		     Time that compensate for variations, but I don't
		     see any real reason to go into much detail.  This is
		     not a time scheme you want to use.

Interestingly, all time schemes can be converted to any other time scheme,
provided you specify latitude, date, etc.

If you would like a more thorough, informative description of these (and
other) time systems, let me know.  I think this should be enough to answer
your question about "star gazing" time.  Personally, I encourage you to
use UT, and to follow other standard astronomical (I.A.U.) conventions to
deal with issues associated with time/date stamping, since astronomers have
already worked out these problems.

	David



-------
Now why UT and UTC?  I suspect that UT is the time based on the atomic
clock from a specific point in time and that UTC is UT which has been
leap second adjusted.

Bill Wells
wcwells@Berkeley.ARPA

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA12643; Tue, 31 Jan 84 11:10:52 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.11) id AA01413; Tue, 31 Jan 84 11:09:20 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.13/4.11) id AA20314; Tue, 31 Jan 84 11:05:36 pst
Date: Tue, 31 Jan 84 11:05:36 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8401311905.AA20314@ucbopal.CC.Berkeley.ARPA>
To: Margulies@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA
Subject: From Where ?

In reply to:

	Date:  Sun, 29 Jan 84 10:03 EST
	From: "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>

	I find it helpful to get a hint of where in the world a
	correspondant is.  The time zone does that.

I think "where" should be in the address, but since Internet mail box
addresses are relatively long (with Agent Names), perhaps we should
have a "From-Location:" header field with a geographical location.
For example:

	From: "William C Wells" <wcwells@Berkeley.ARPA>
	From-Location: Berkeley CA USA

Bill Wells
wcwells@Berkeley.ARPA


Date: Tuesday, 31 Jan 1984 12:11-PST
To: "Benson I. Margulies" <Margulies@MIT-MULTICS>
Cc: header-people@MIT-MC
Subject: Re:  Re: Several questions/comments on time zones
In-reply-to: Your message of  Sun, 29 Jan 84 10:03 EST.
              <840129150352.738172@MIT-MULTICS.ARPA>
From: greep@SU-DSN

The time zone may indicate where the machine is, but that isn't necessarily
the same as where the user is.  For example, there is someone in Australia
who uses a machine in California to send mail.  More commonly, a lot of
people in Washington seem to use machines at ISI to send mail.

What's going to happen to time zones when we have people sending messages
from Mars or manned space stations?  Will they use the time zone of their
country's capital?

Date: Tue, 31 Jan 84 13:19:48 PST
From: David Alpern <Alpern.Ibm-Sj@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: UTC Time stamping
To: Header-People@Mit-Mc
Via:  IBM-SJ; 31 Jan 84 16:16-PST

Pardon me, but I think we have a while before we have to worry
about how people on Mars would timestamp their messages.
 
Like Benson, I as well use the zone in the timestamp to get an
idea of the location of the sender.  Sure, it's not 100% accurate,
and maybe it'd be nice if a user could specify the zone that would
be best to use on messages he's sending.  This is something we
might consider when writing mail sending programs.  No change to
any of the "standards" is involved here.
 
However, I somehow missed hearing about the problem that the use
of zones other than UTC leads to.  Was there one?  If so, someone
please resend a copy of the original message to me.
 
If not:  Many of the mailers around are used more for internal (within
some school or company) than external mailing.  If I'm on MIT-EECS, and
get a message from someone on MIT-ML, I care how recently he sent the
message (local time) more than I do what Universal Time it was.
 
RFC 822 does specify a human readable header, and not a machine readable
one, in general.  For example, consider the usefulness of the "name:;"
nomenclature for a distribution list to any program without access to
the original list file.  I would much prefer if any program that tried
to deal with the time for some reason (does anyone???) had to convert
than that the mail sending program and mail reading program had to
convert at either end for human use.
 
Again, I'd be interested in hearing why this discussion seems important,
i.e. what we're trying to prevent or solve.  So many mailers aren't
even 822 compatible when it comes to dates that I would think the zone
issue would be rather minor.
 
With apologies for flaming,
 
Dave

Date:  Wed, 1 Feb 84 19:44 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Re: UTC Time stamping
Reply-To:  bim@MIT-MULTICS.ARPA
To:  David Alpern <Alpern.Ibm-Sj@RAND-RELAY.ARPA>
cc:  header-people@MIT-MC.ARPA
In-Reply-To:  Message of 31 Jan 84 16:19 EST from "David Alpern"
Message-ID:  <840202004417.738587@CISL-SERVICE-MULTICS.ARPA>

The problem is that we do not have an agreed upon unique list of time
zone identifiers.  Thus the ISO date standard calls for both the zone
abbreviation and its offset from UTC.

I still do not see why that is not an adequate solution, though.

Date:  1 Feb 84 2128 EST (Wednesday)
From: Richard H. Gumpertz <Rick.Gumpertz@CMU-CS-A>
To: Header-People@MIT-MC
Subject: Re: Several questions/comments on time zones
In-Reply-To: "Rich Wales's message of 28 Jan 84 04:24-EST"
Message-Id: <01Feb84.212859.RG02@CMU-CS-A>

Parsing time zones is not hard for a computer to do.  Let's not waste time
on this area that works fine; instead let's fix the things that aren't easy!

Date:  1 Feb 1984 18:59:44 PST
From: POSTEL@USC-ISIF
Subject: Re: UTC Time stamping
To:   bim@MIT-MULTICS, Alpern.Ibm-Sj@RAND-RELAY
cc:   header-people@MIT-MC, POSTEL@USC-ISIF

In response to the message sent   Wed, 1 Feb 84 19:44 EST from   bim@MIT-MULTICS.ARPA


I don't think i have ever seen a list of international standard time zone
designators from ISO or CCITT or any standards organization.  I think the
only official international standard way to indicate a time zone is by
a numeric offset.

--jon.
-------

Date:  1 Feb 84 2221 EST (Wednesday)
From: Richard H. Gumpertz <Rick.Gumpertz@CMU-CS-A>
To: POSTEL@USC-ISIF
Subject: Re: UTC Time stamping
CC: header-people@MIT-MC, POSTEL@USC-ISIF
In-Reply-To: "POSTEL@USC-ISIF's message of 1 Feb 84 21:59-EST"
Message-Id: <01Feb84.222129.RG02@CMU-CS-A>

So we use ANSI (because we are Americans, mostly) for American time zones
in alphanumeric and other time zones in numeric.  As I recall, this is
a superset of the ISO standard but conveys more information (CDT differs from
EST but are numerically equal).


Via:  unknown-host; (pss/csmail/listen); to 44d.Ucl-Cs.AC.UK 
           over PSS with NIFTP;  2 Feb 84 12:32 GMT
Date:  2 February 1984 12:21 gmt
From:  "Neil Davies%aucc"@ucl-cs.arpa
Subject:  Re: UTC Time stamping
Sender:  DaviesNJ.SysMaint%aucc@ucl-cs.arpa
To:  POSTEL@usc-isif.arpa
cc:  header-people@mit-mc.arpa
In-Reply-To:  Message of 2 February 1984 02:59 gmt from POSTEL

    Date:  1 Feb 1984 18:59:44 PST
    From:  POSTEL@arpa.usc-isif
    Subject:  Re: UTC Time stamping

    In response to the message sent   Wed, 1 Feb 84 19:44 EST from   bim@MIT-MULTICS.ARPA


    I don't think i have ever seen a list of international standard time zone
    designators from ISO or CCITT or any standards organization.  I think the
    only official international standard way to indicate a time zone is by
    a numeric offset.

    --jon.
    -------


Jumping ot the filling cabinet. He gets out X.409 CCITT Message handling
systems presentaion Trasfer syntax and Notation) or at least a draft of
it.
 One of the sections refers to "UTC", and the presentation layer
representation of it.
 In the references section there are three ISO refernces namely:
	ISO 2014, Writing Calendar dates in all-numeric form.
	ISO 3307, Information interchange- representation of time of the day.
	ISO 4031, Information interchange- representation of local time differentials.

also one to
	B.11, Legal time; use of the term UTC
 (don't know who origniated that one).
	'Fraid I don't happen to have copies of those standards.
	Neil Davies.


Date:  2 Feb 1984 09:32:31 PST
From: POSTEL@USC-ISIF
Subject: re: UTC time stamping & time zone designators
To:   header-people@MIT-MC


Neil Davies:

Great citations. But no time zone designators (e.g., BST) in them only
numeric offsets from UCT.

--jon.
-------

Date: 2 Feb 1984 1438-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: POSTEL at USC-ISIF, header-people at MIT-MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: re: UTC time stamping & time zone designators
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11988583907.27.132.15425 at DEC-MARLBORO>
Regarding: Message from POSTEL@USC-ISIF of 2-Feb-84 0932-EST

I wouldn't expect to find time zone designators in an ISO standard.
ISO rarely resolves issues as complex as whether to call the time zone
used in continental Europe HEC or MEZ.  When dealing with an issue as
close to the heart as the native tongue of the ISO member nations,
only numbers can win the votes necessary to pass.

We can banty this around forever without getting anywhere.

Based on the inputs we have heard local time is the only thing we can be
guaranteed will be put into a header because many machines and interfaces
are purposefully simple to allow them access to the market and the net.

A qualification by zone name is only useful visually since the zone
names are not standardized.  But this visual identification is useful
to the reader.

A qualification by UTC offset is nice and is an ISO standard.

Since we aren't going to get every mailer to conform, we should state
levels of conformance.  At the lowest level, simply local time is
provided.  At the next level, local time is qualified by the UTC offset
in the ISO format.

At either level a text time zone identification can be added with the
understanding that it has purely the effect of a comment and may not
be parsed.

   --------

Date:  Thu, 2 Feb 84 12:58 EST
From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Subject:  reams and reams of failed mail notifications
To:  header-people@MIT-MC.ARPA
Message-ID:  <840202175812.997294@MIT-MULTICS.ARPA>

Whenever I send a message to header-people, I get about a dozen messages
from various mailers about their inability to forwward the message
someplace.  Woundn't they be better directed at the list administrator?

Date:  2 Feb 84 1938 EST (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz@CMU-CS-A>
To: "Neil Davies%aucc"@UCL-CS
Subject: Re: UTC Time stamping
CC: header-people@MIT-MC
In-Reply-To: "\"Neil Davies%aucc\"@ucl-cs.arpa's message of 2 Feb 84
             07:21-EST"
Message-Id: <02Feb84.193839.RG02@CMU-CS-A>

The relevant ANSI standard (which we ought to use in America) DOES
specify standard alphabetic time zone designations for the USA.  I
forget the standard number, but it is either X3.30-1971 or X3.51-1975.
The other number is for the date standard.

Received: by YALE-BULLDOG via CHAOS; Mon, 6 Feb 84 15:23:07 EST
Received: from YALE-RING by YALE-RES via CHAOS; Mon, 6 Feb 84 15:18:57 EST
Subject: "Return-Path" vs. "From"
Date: Mon, 6 Feb 84 15:19:01 EST
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
to: header-people@MIT-MC.ARPA
cc: Ellis@YALE.ARPA

Flame on:

I just saw a message that had the following 2 header lines in it:

    Return-Path: <ER90@CMU-CS-A>
    From: Elaine.Newborn@CMU-CS-A.ARPA                           
    
The "Return-Path" is being generated from data passed in the envelope
(SMTP "MAIL FROM").  It seems to me that it's not unreasonable for
the "Return-Path" to bear some resemblance to the "From", no?  It's
bad enough that the two addresses are sometimes trivially different:
I've seen mail from many sites in which the case differs (I'm not
advocating case sensitivity in user IDs, but some sites DO rely on
it).  But the case above seems pretty extreme.  Which address am I
supposed to reply to?  If the answer is "either works", why can't
the software arrange to give the more sensible one (I'll give you
a hint about which I think is the more sensible one:  it doesn't have
numbers in it; bonus points: why is it ER90 instead of EN90?).

        -- Nat

Date: Mon 6 Feb 84 13:35:15-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To: Mishkin@YALE.ARPA
cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA
In-Reply-To: Message from "Nathaniel Mishkin <Mishkin@YALE.ARPA>" of Mon 6 Feb 84 12:36:45-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I have seen the question of replying to the Return-Path come up
zillions of times.  Why won't people read RFC 821 and 822 instead of
asking this question (or complaining about software which does not
reply to the Return-Path)?

     You *never* reply to the Return-Path.  The Return-Path is merely
the "return address" for a message if it is undeliverable.  It may be
the sender of the message.  It may be the author of the message.  It
may be the reply address of the message.  It may be the mailer process
at the sending site.  It may be null.  It may be none of these.  There
is NO relationship between the Return-Path and any reply address.  The
fact that actual usage patterns very often establish such a relationship
is irrelevant.

-- Mark --
-------

Date:     Mon, 6 Feb 84 22:56:28 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Nathaniel Mishkin <Mishkin@yale.arpa>
cc:       header-people@mit-mc.arpa, Ellis@yale.arpa
Subject:  Re:  "Return-Path" vs. "From"

Answer "FROM".


The SMTP "MAIL FROM" is for ERRORS!

-Ron

Date:  7 Feb 84 0049 EST
From: Rudy.Nedved@CMU-CS-A
To: Nathaniel Mishkin <Mishkin@YALE>
Subject: Re: "Return-Path" vs. "From"
CC: header-people@MIT-MC
In-Reply-To: "Nathaniel Mishkin's message of 6 Feb 84 15:19-EST"
Message-Id: <07Feb84.004916.EN0C@CMU-CS-A>

Nat,

The return path is the route the mail message took including getting bounced
off mars, jupiter and venus. It is not what a mail composer uses to for a
return path....it is also quite possible that the reverse path is slower. The
return path is only for mail delivery errors.

The mail composers should "reply" or "answer" based on the From, Sender and
Reply-To fields as specified in RFC822.

Admittedly, it is bizzarre that the return-path mailbox specifier is different
from the from mailbox specifier but there isn't a quick fix that will 1) get
what you want and 2) generate a valid return path.

I have plans to fix it but I don't expect it fixed for at least a couple of
months. At that point, CMU should have a global distributed name datanase so
that anyone on any of our hosts can just say "mail rudy nedved" and it will get
to the right mail box. It is all a matter of priorities.

-Rudy

Received: by YALE-BULLDOG via CHAOS; Tue, 7 Feb 84 06:39:14 EST
Received: from YALE-RING by YALE-RES via CHAOS; Mon, 6 Feb 84 23:05:25 EST
Subject: Re: "Return-Path" vs. "From"
Date: Mon, 6 Feb 84 23:05:26 EST
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: Mark Crispin <MRC@SU-SCORE.ARPA>
cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Mon 6 Feb 84 13:35:15-PST

    I have seen the question of replying to the Return-Path come up
    zillions of times.  Why won't people read RFC 821 and 822 instead
    of asking this question (or complaining about software which does
    not reply to the Return-Path)?

I am perfectly well aware of the fact that the Return-Path CAN be
different from the From and that there are good reasons why it sometimes
is.  And I'm not talking about what address should be used for replies.

What I want to know is WHY in the obvious cases (like the one I showed)
IS it different.  Given that the sender of a message generally does
not (manually) specify the contents of either the Return-Path or From,
why do the two fields end up being different in the way they are in
the example I gave?  I am hardpressed to believe that it is a desirable,
intentional, or rational feature that the 2 should be different in
the trivial case.  I find it hard to believe that whoever wrote the
software that caused the behavior I saw considers the difference
anything less than a misfeature, if not an outright bug.

What I'm really talking about here is the confusion factor:  seeing
a Return-Path and From that do not agree might lead one to believe
that there is some significance in the difference -- otherwise, why
would they be presented differently?

From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8402071306.AA15144@merlin.ARPA>
Received: by merlin.ARPA; Tue, 7 Feb 84 08:06:17 est
Date:  7 Feb 1984 0806-EST (Tuesday)
To: Rudy.Nedved@CMU-CS-A.ARPA
Cc: header-people@MIT-MC.ARPA
Subject: Re: "Return-Path" vs. "From"
In-Reply-To: Your message of 7 Feb 84 0049 EST.
             <07Feb84.004916.EN0C@CMU-CS-A>

Would someone please grab Eric Allman, give him a swift kick, and point
him at this dialogue? His sendmail program insists on using the string
supplied in the SMTP MAIL FROM:<> command as the "Unix-style" from
line, which most Unix mail readers pay attention to in preference to
the RFC822 From: line when generating a reply address. It is a
completely different bogosity that the situation with Unix mail readers
comes up at all, but that is a historical dreg and not Eric's fault.
But the fact that he ignores it is incomprehensible.

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

Date:     Tue, 7 Feb 84 10:37:43 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Nathaniel Mishkin <Mishkin@yale.arpa>
cc:       Mark Crispin <MRC@su-score.arpa>, header-people@mit-mc.arpa, 
          Ellis@yale.arpa
Subject:  Re:  "Return-Path" vs. "From"

The confusion factor is minimized by not looking at RETURN-PATH.
If you must, configure your mail reader such that the RETURN-PATH
lines are deleted.  The reason in you case (although I am not certain)
is probably one of human engineering.  At BRL, for the sake of user
friendliness, a user is allowed to specify any return address in his
FROM or SENDER line that will legally get the letter back to him
(the validation on this is interesting but too lengthy to discuss here).
However, the return path is always set to the address that the system
determines is the mail invoker really is associated with.  This also
allows getting around the multiple FROM list problem.  For example:
I can send a letter with "FROM: Ronald.Natalie@BRL" but the mail system
recognizes me as the "ron" user on the BRL-VGR host and my return path
gets marked as "ron@Brl-Vgr".

RETURN-PATH should probably not be in the header at all, except that
mail does get out of the SMTP environment and it's nice to propagate
the information along to the non-SMTP environments.

The other major use (other than setting return path to null to avoid
error messages entirely) is with large mailing lists.  If you look
carefully at the large lists maintained at BRL (INFO-{MICRO,UNIX,CPM,APPLE},
UNIX-WIZARDS, MSGGROUP).  You will find that although these appear to
be simple mail exploders (an incoming letter immediately gets turned around
and sent out to the list), a transformation occurs.  The RETURN-PATH
is changed from what it was to the appropriate -REQUEST list.  This keeps
the list submitters from seeing errors that are beyond their control
to fix and forwards them to the people who might be able to fix them who
would ordinarily have seen them.

-Ron

Date: Tue, 7 Feb 84 12:10:46 cst
From: solomon@wisc-crys (Marvin Solomon)
Message-Id: <8402071810.AA14416@wisc-crys.ARPA>
Received: by wisc-crys.ARPA (4.22/3.7)
	id AA14416; Tue, 7 Feb 84 12:10:46 cst
To: milazzo@RICE-JANUS
Subject: Re: Several questions/comments on time zones
Cc: header-people@mit-mc, solomon@wisc-crys

Re:
	Date:     Sun, 29 Jan 84 16:39:59 CST
	From: Paul Milazzo <milazzo@rice>
	Subject:  Re: Several questions/comments on time zones
	To: solomon@wisc-crys (Marvin Solomon)
	Cc: header-people@mit-mc
	Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice>
	
		"If RFC 733 (and its successor, 822) had not made the mistake
		of defining a mail header in such a way as to make it appear to
		be designed to be read, the header could encode dates in any
		form convenient for exchange (some encoding of UT) [...]."
	
	It is my understanding that RFC 733 did not invent the contents of a
	mail header; similar formats had been in use for some time.  RFC 733
	simply tried to make known (and perhaps official) the various de facto
	standards which had sprung up in the Internet community.  Thus it
	became a sort of "conglomerate standard".  I consider this effort a
	noble one, if perhaps incompletely successful.
	
					Paul G. Milazzo <milazzo@rice>
					Dept. of Mathematical Sciences
					Rice University, Houston, TX
	
Several people have misuderstood various aspects of this comment, so
I must have not made myself clear.  First, I do understand the history
of 733.  One reason standards are hard to write it that you must make a choice
between two unpleasent courses:  On one hand you can wait until there are
(incompatible) implementations and then try to come up with some sort of
compromise that won't break too many existing programs.  On the other hand
you can try to write a spec for something that doesn't
exist yet and run the risk of specifying something that is unimplementable.

Perhaps I should have said that the choice of making headers human-readable
was "unfortunate" rather than "a mistake".   Several people have pointed
out that while non-human-readable (binary) headers can only be read by
programs, human-readable (text) headers can be read by both humans AND
programs (using a little compiler technology) and thus would appear to be
preferable.  My point wasn't that parsing text headers is too hard, but
rather that reading text headers is too easy, so that people tend to
write mail-reading programs that simply show the headers to users.
From time to time, someone flames that "you wouldn't have [whatever your
favorite problem is] if you had a decent mail-reading program".  If binary
headers were the standard, there would be no question but that a reasonable
mail-reading program was required, and there would be much less confusion
between trans-port level information (in both the envelope and header)
and end-user information.

Date:  7 Feb 84 1400 EST (Tuesday)
From: Craig Everhart@CMU-CS-A
To: Nathaniel Mishkin <Mishkin@YALE>
Subject: Re: "Return-Path" vs. "From"
CC: Header-People@MIT-MC
Reply-To: Rdmail@CMU-CS-A
In-Reply-To: "Nathaniel Mishkin's message of 6 Feb 84 15:19-EST"
Message-Id: <07Feb84.140020.RD00@CMU-CS-A>

It just doesn't matter, period, that the two are different.  I don't care what
you think of the aesthetics of each individual field--whether it was a design
choice that those two fields look as they do, or (as is the case) that their
current appearance is an accident of history.  That's none of your business!
Obviously, your mailer should NEVER use the Return-Path: field in composing
replies (except for error notification).  Both addresses work.  I could even
argue that using a Return-Path identifier that doesn't look like a name is a
good idea, precisely to discourage people from using it for ordinary replies.

A local (CMU-CS-A) mail system user might have some cause to complain about
the aesthetics of the outgoing fields.  However, you aren't such, and have no
business making that complaint.

		Craig Everhart

Date: Tue 7 Feb 84 12:29:30-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To: Mishkin@YALE.ARPA
cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA
In-Reply-To: Message from "Nathaniel Mishkin <Mishkin@YALE.ARPA>" of Tue 7 Feb 84 03:45:41-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

It isn't totally unreasonable for the From or Reply fields to be a
"meaningful" address, such as "Mark.Crispin@Stanford" (which we fully
intend to support in the near future) while the "Return-Path" would be
a "machine" address incorporating a login name and physical machine,
such as "MRC@SU-SCORE".  CMU TOPS-10 has particularly nasty usernames;
I'm MC0R@CMU-CS-A but anybody seriously sending mail to me there would
use "Mark.Crispin@CMU-CS-A".
-------

Date: 8 Feb 1984 09:20-EST
Sender: MOOERS@BBNA
Subject: Re: "Return-Path" vs. "From"
From: MOOERS@BBNA
To: MRC@SU-SCORE
Cc: header-people@MIT-MC, cic@CSNET-CIC, Mooers@BBNA
Message-ID: <[BBNA] 8-Feb-84 09:20:34.MOOERS>
In-Reply-To: The message of Tue 7 Feb 84 12:29:30-PST from Mark Crispin <MRC@SU-SCORE.ARPA>

	
    From: Mark Crispin <MRC@SU-SCORE.ARPA> ...
    
    It isn't totally unreasonable for the From or Reply fields to be a
    "meaningful" address, such as "Mark.Crispin@Stanford" (which we fully
    intend to support in the near future) ...
              --------------------
		
How soon do you expect to support such an address?  Is this
"institutional" host-alias name, "Stanford", likely to become a
sub-domain in a reasonable length of time?  How many other
institutions have, or are planning, the same kind of
host-aliases?  (We have two at BBN -- BBN, for the TENEX/TOPS-20
hosts and BBN-UNIX.  There is also "OFFICE" at TYMSHARE.)

---Charlotte

Date: Wed 8 Feb 84 22:00:30-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To: MOOERS@BBNA.ARPA
cc: header-people@MIT-MC.ARPA, cic@CSNET-CIC.ARPA
In-Reply-To: Message from "MOOERS@BBNA" of Wed 8 Feb 84 06:20:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

It's our intention to have a single contact point for mail directed to
all individuals at Stanford.  It'll probably be a dedicated VAX.  I'm
not sure how it will come about yet; probably it will start as a host
named "STANFORD" and eventually it'll be a sub-domain.
-------

Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 10:28:37 EST
Received: from YALE-RING by YALE-RES via CHAOS; Thu, 9 Feb 84 10:25:59 EST
Subject: Re: "Return-Path" vs. "From"
Date: Thu, 9 Feb 84 10:26:04 EST
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: Mark Crispin <MRC@SU-SCORE.ARPA>
cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Tue 7 Feb 84 12:29:30-PST

    It isn't totally unreasonable for the From or Reply fields to
    be a "meaningful" address, such as "Mark.Crispin@Stanford" (which
    we fully intend to support in the near future) while the
    "Return-Path" would be a "machine" address incorporating a login
    name and physical machine, such as "MRC@SU-SCORE".
    
I completely agree with the goal of using "logical" names.  However,
this doesn't make a virtue out of the strangeness of the "Return-Path".
If you want the functionality you say (i.e. that the recipient can
see both the user ID and the logical name of the sender), it seems
like you should use a "Sender" line and not rely on the behavior of
the "Return-Path" (whose contents are presumably not under the control
of the person/mailsystem that decides that presenting both the user
ID and the logical name is a good idea).

Date: Thu 9 Feb 84 11:51:55-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To: Mishkin@YALE.ARPA
cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA
In-Reply-To: Message from "Nathaniel Mishkin <Mishkin@YALE.ARPA>" of Thu 9 Feb 84 07:30:50-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Your message implies that for some reason you actually care what
is in the Return-Path header line.  You shouldn't.  I can put whatever
I damn well please in there.  If it pleases me to put in the physical
login-id/host-name in there, that's my business not yours.  Any
presumption on your part that there is any relation between the
Return-Path and any other header line (including Sender!) is faulty.

     It can also be argued that your mail reader is faulty for even
presenting the Return-Path information to the user.  Return-Path is
in the header only to assist mail transports which don't have the
concept of out-of-band envelopes.  Since you're on ARPANET, it's
irrelevant.
-------

Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 15:15:29 EST
Date:    Thu, 9 Feb 84 15:16:25 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To:      Mark Crispin <MRC@SU-SCORE.ARPA>
Cc:      Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Thu 9 Feb 84 11:51:55-PST

    It can also be argued that your mail reader is faulty for even
    presenting the Return-Path information to the user.  Return-Path is
    in the header only to assist mail transports which don't have the
    concept of out-of-band envelopes.  Since you're on ARPANET, it's
    irrelevant.

If only it were irrelevant.  Unfortunately, we get a fair amount of mail
forwarded from other APRANET hosts (maybe a few messages a week) in which
the From address is unrepliable but for which the Return-Path is correct
(or at least useable).  E.g.

    Return-Path: <joe%NON-ARPA-HOST@HOST.ARPA>
    From:        joe blow <joe@NON-ARPA-HOST>

Sometimes we get mail with no From/Sender/Reply-To at all.

As long as we continue to receive mail in which the 822 text doesn't
contain a correct reply address, it is necessary for users to see the
STMP Return-Path so that they can attempt replies to such mail.
-------

Date: Thu 9 Feb 84 12:34:40-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To: Ellis@YALE.ARPA
cc: Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "John R Ellis <Ellis@YALE.ARPA>" of Thu 9 Feb 84 12:17:26-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

John -

     Good point.  However, it does not mean that it is correct for a
mailsystem's Reply command to use the Return-Path.  The correct behavior
is to give an error message, and let the human user figure out that
maybe the information in the Return-Path is useful.  I am sick and tired
of people claiming it should be done automatically - all that would
accomplish is an ad hoc modification to the standard.  That'll make the
standard even more worthless than it already is.

-- Mark --
-------

Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 16:09:39 EST
Date:    Thu, 9 Feb 84 16:09:20 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: "Return-Path" vs. "From"
To:      Mark Crispin <MRC@SU-SCORE.ARPA>
Cc:      Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Thu 9 Feb 84 12:34:40-PST

    However, it does not mean that it is correct for a mailsystem's Reply
    command to use the Return-Path.

In this discussion, no one, including Mishkin, has argued for this.
-------

Date: Thu, 9 Feb 84 15:12:54 PST
From: David Alpern <Alpern.Ibm-Sj@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: Re: "Return-Path" vs. "From"
To: Header-People@Mit-Mc
In-Reply-To: Message of Thu, 9 Feb 84 15:16:25 EST
      from John R Ellis <Ellis@YALE>
Via:  IBM-SJ; 9 Feb 84 16:29-PST

     If only it were irrelevant.  Unfortunately, we get a fair amount of mail
     forwarded from other APRANET hosts (maybe a few messages a week) in which
     the From address is unrepliable but for which the Return-Path is correct
     (or at least useable).
 
Which strikes me as exactly the best reason for the Return-Path to
specify a physical mailbox, rather than a logical username.  This
secures the same "realness" on the local part as the host name has.
John, it seems you have provided the best answer yet to your and
Nathanial Mishkin's original question.
 
- Dave

Received: by RICE (AA11064); Fri, 10 Feb 84 02:58:36 cst
Date:     Fri, 10 Feb 84 02:33:10 CST
From: Scott Alexander <salex@rice>
Subject:  Re: "Return-Path" vs. "From"
To: Header-People@Mit-Mc
Message-Id: <301.salex.dione@rice>
In-Reply-To: a message from David Alpern dated Thu, 9 Feb 84 15:12:54 PST

From RFC822 Section 4.3.1 RETURN-PATH:

     4.3.1.  RETURN-PATH

        This field  is  added  by  the  final  transport  system  that
        delivers  the message to its recipient.  The field is intended
        to contain definitive information about the address and  route
        back to the message's originator.

        Note:  The "Reply-To" field is added  by  the  originator  and
               serves  to  direct  replies,  whereas the "Return-Path"
               field is used to identify a path back to  the  origina-
               tor.

        While the syntax  indicates  that  a  route  specification  is
        optional,  every attempt should be made to provide that infor-
        mation in this field.
        
Section 4.4.3 REPLY-TO...:

        Note:  The "Return-Path" field is added by the mail  transport
               service,  at the time of final deliver.  It is intended
               to identify a path back to the orginator  of  the  mes-
               sage.   The  "Reply-To"  field  is added by the message
               originator and is intended to direct replies.

It would seem fairly clear that this field can have any sort of bogosity
in it that the final mailer decides to put into it to give a "definitive"
information.  It would seem equally clear that there is NO mention here 
of to what use return-path is to be put.  In Section 6.2.2,  it does
state that return-path may be useful for finding out the proper place to
reply to if a message has crossed domain barriers without proper
expansion of addresses.

                                Scott Alexander
                                Rice University
                                salex@rice
                                lbl-csam!rice!salex

Date:  Fri, 10 Feb 84 09:45 EST
From:  "Jeffrey I. Schiller" <Schiller@MIT-MULTICS.ARPA>
Subject:  Re: "Return-Path" vs. "From"
To:  Header-People@MIT-MC.ARPA
cc:  Rudy.Nedved@CMU-CS-A.ARPA
In-Reply-To:  Message of 7 Feb 84 00:49 EST from "Rudy.Nedved at CMU-CS-A"
Message-ID:  <840210144557.064505@MIT-MULTICS.ARPA>

Why is there a problem here? Answer: We don't yet have DOMAINS. 

          It would be pretty clear to me that you have to use the "From"
field when replying to mail, however there is one major problem, namely
the host in the "From" field may not be in your local system's host
table.  This can happen due to a number of reasons (non-Internet hosts,
slow updating of the NIC host table, slow updating of the local host
table).  When faced with this situation what I personally do is look at
the "Return-Path" and try sending a reply back thataway.  It is the best
that I can do under the circumstances.

          Imagine the Internet that didn't have a gateway table, but
every datagram had a source route.  The same heuristic would begin to
develope in people's Internet implementation (and in fac the Multics
Internet implementation will soon have this feature, namely the use of
the source route in incoming datagrams if no better way can be used to
determine where to send a datagram).

          If DOMAINS worked, then when faced with an unknown host in a
"from" field users/host software would have an alternative to peeking at
the "Return-path" field, namely querying the appropriate DOMAIN's name
server.

                    -Jeff

Date:  Sat, 11 Feb 84 13:41 EST
From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Subject:  return-path versus reply-to/from
To:  header-people@MIT-MC.ARPA
Message-ID:  <840211184108.489092@MIT-MULTICS.ARPA>

How about the following observation:

   Reply-to and From are what gets filled in when the sender fo the mail
indicates where replies are to go.  They are most likely the addresses
relative to the sending host.

   Rather than assume a bunch of clutter of the form of changing the
reply-to and from fields as messages pass through various domains, why
not perserve them as is?  If a replying host does not understand a name
in a from or reply to, she can always send it back along the return
path, and assume that the originating host will be willing to send it
along.  After all, most froms and return-tos are the user that sent the
mail, and them that ain't are usually (though not always) at the same
host.

   This should make the uucp-jockeys happy, since the return path is the
only way to find an arbitrarily hidden uucp host.

   On the internet, return paths are generally trivial.  IP gateways do
not play with mail headers.  Only mail gateways do.  Generally, then, an
IP host would want to use the "send it back down the return path" trich
whenver the name in the from/reply-to could not be resolved via whatever
domain name scheme we have going.

   Remember, the mail-catanet has ALWAYS been much larger than the
ARPA/IP-datagram-catanet.  The Domain scheme does not claim to cover the
entire mail-catanet, just deal much better with the IP-catanet (and
possibly some other parts of the world).

I guess I could summarize my position by:

   Return paths are concerned with hosts and gateways, NOT users.  The
user to be replied to should always be a part of the from/reply-to
address.  The Return-path is available to aid a mail agent in responding
to mail that does not come from its host-name universe.

Date: 11 Feb 84 15:24 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: header-people@MIT-MC.ARPA
Subject: return-path versus repl-to/from
Message-ID: <4254996F.012E0021.1984@CMCL1.NYU-CMCL1.ARPA>


I have been following this discussion with some interest and while I personally
am an advocate having the domain-catenet over the mail-catenet (even if much of
this is implemented by mail-gateways that convert 822 letters into uucp/NBS/DEC
mail/arbitrary local mail system protocol letters) I am surprised that no one
mentions the scheme that the NYU mailer uses to make a stab at replying to
message which arrive on an 822 mail path with a bad "reply address" (
by which I mean whichever header [from, reply-to, etc.] applies under 822
for a letter with that combination of headers).  It then looks at
the RETURN-PATH and makes the assumption that the "reply address" is some
address in a local non-internet but in.ternet-like domain, and replaces the
final mail box in the Return-Path, which as people have pointed out COULD
be anything from the bit bucket to the mail system maintainer, with the
"reply address" to produce a <@X,@Y,@Z:reply address> source routing path.
Shudder, but this seems to have handled a few strange cases we got from 
"alternet" internets early in RFC822's reign.
 
-------

Date: Sat 11 Feb 84 13:26:13-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: return path
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)

Once upon a time, there was From.  Then came Reply, which parsed From
to send an answer back.  And the world saw that it was good.  But then
it was seen that it needed to be possible to reply to a different
address than the From, and that people with secretaries may have their
secretaries do the actual sending.  So Sender and Reply-To were invented.
And the world saw that it was complicated.  Then came the realization
that it wasn't always clear where to send error reports to, and that the
Sender was not always the right place.  So Return-Path came into being.
And the world became hopelessly confused.

Whither now, SMTP?

I must say, everything up to now has seemed necessary to add necessary
functionality to Internet mail.  But I fail to see why Internet mail must
be made unimplementable to support non-Internet mail.  It seems to me
that the non-Internet networks should conform to Internet mailing
conventions and not the other way around.

The right fix is to remove "From", "Sender", and "Reply-To" from the
message header and put it in the envelope.
-------

Date:  Sat, 11 Feb 84 19:18 EST
From:  "Jeffrey I. Schiller" <Schiller@MIT-MULTICS.ARPA>
Subject:  Re: return path
To:  Mark Crispin <MRC@SU-SCORE.ARPA>
cc:  Header-People@MIT-MC.ARPA
In-Reply-To:  Message of 11 Feb 84 16:26 EST from "Mark Crispin"
Message-ID:  <840212001844.303119@MIT-MULTICS.ARPA>

Now now, Mark, network chauvinism is not the answer. Maybe the Internet
should be forced to adopt uucp style mail names, they certainly work
better given that they sort of work in a non-host-table environment.
And although the Internet does have a host table, it doesn't tend to
be very accurate.

You also left out in your "history of mail" the fact that in the beginning
there were very few hosts, and they were connected to the relatively
homogeneous ArapNet. Today things are more complicated simply because
there is more out there to talk to, and not all of it connected together
in an ideal fashion (1200 or 300 baud phone lines on UUCP networks).

                    -Jeff

Date: Sun 12 Feb 84 19:02:36-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: return path
To: Schiller@MIT-MULTICS.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from ""Jeffrey I. Schiller" <Schiller@MIT-MULTICS.ARPA>" of Sat 11 Feb 84 16:24:17-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Network chauvinism has nothing to do with it.  We ARE supposed to
get Internet mail - domains and all - working.  This includes the
migration to a world where a monolithic Internet host table no longer
exists: a world of name servers.

     It seems awfully presumptious for individuals in other worlds to
dictate to us what Internet standards or implementations should look
like, especially when accompanied with vieled (sometimes no so vieled)
threats that if we don't do as they please, "the world will pass [us]
by."

     It is my contention that nobody has the complete understanding,
much less a monopoly on such understanding, what a "WorldNet" of
electronic mail will look like.

     I think we (the Internet community) try.  We try to understand,
and we try to strike a balance between global connectivity and a set
of de facto "non-standards" which are difficult if not impossible to
document, much less implement.

     There's nothing wonderful about UUCP "!" syntax.  It does pretty
much the same thing as "." with MMDF or "%" with TOPS-20 and other
systems.  UUCP just replaces the "@" as well and has the names in
reverse order.  I thought we were above talking about trite syntax
details anyway.
-------

Date:  Mon, 13 Feb 84 15:22 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  header reply fields
To:  header-people@MIT-MC.ARPA
Message-ID:  <840213202228.415255@CISL-SERVICE-MULTICS.ARPA>

Mark,

    I think you berate the UUCP dept. without good reason.

There are implementation reasons why participation in the domain mail
system may be impractical for many itty-bitty hosts.  That protocol is
HAIR.  It requires a database, someplace, to list everyone.  (That it,
everyone has to be in one or another domain database RR record).

It seems to me that if there is a simple, clear, set of header fields
(envelope, message, or stamp) that allow non-IP-universe mail players to
function well, then we should go for it.

If return-path was invented for error replies, then I humbly suggest
that it was misnamed.

Call that field "error-reply-to" or "responable-mailer-maintainer".

Use return-path as I and the person from NY described -- as a hop-hop
description to be used when the from/reply-to information is not
usuable.

Date: Mon 13 Feb 84 14:09:18-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: header reply fields
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from ""Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>" of Mon 13 Feb 84 12:41:29-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     RFC 821 and RFC 822 both define what the "return path" is
quite specifically.  I refuse to argue about whether or not the
name is a good one; I personally detest "resent-from".  However,
this shouldn't matter.  As several people repeatedly point out,
what is in the header isn't necessarily what should be presented
to the user.

     The whole purpose of domains is to make it easier for small
hosts, by providing a distributed database of host names.  At no
single point is "everyone" listed.  Nor is it the intention of
domains to have validation at the sending end.  A message
crossing complex domain boundaries may not have its full domain
path validated until final delivery.

     Consider mail to MRC@Score.Stanford.ARPA - this is a fully
qualified domain address (although "Mark Crispin"@Stanford would
probably be the preferred mailing address).  If the Stanford name
server is down or temporarily inaccessible, there would be no way
to validate the existance of Score from the sending end.  That
does not mean the message should be rejected.  The ARPA name
server should validate whether or not Stanford is a valid name.

     An itty-bitty host can win by passing on all host names to a
more intelligent agent.  For example, a very simple mailing
strategy would be to send all mail to the nearest name server (or
even to the root name server).  In my example, the sending host
could perhaps trace all the way down to Score, but it doesn't
have to.  It could stop at Stanford and deliver it there.  It
could stop at ARPA and deliver it there.  Or, if it was external
to ARPA, it could deliver it to some agent which is in some way
closer to delivering to ARPA.

     The point is, you don't need to implement the full domain
protocol to use domains.  You merely need to know somebody who
does, or rather does so more than you do.

     I am quite opposed to adding yet another header field to
reply to.  From and Reply-to are quite enough.  If you want to
have a reply address which is maintained by the transport
mechanism, put it in the envelope (the way Return-Path is) where
it belongs.

-- Mark --
-------

Date:  Mon, 13 Feb 84 18:41 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  return path etc.
To:  header-people@MIT-MC.ARPA
Message-ID:  <840213234100.476146@CISL-SERVICE-MULTICS.ARPA>

What does envelope-ness have to do with this?

A PC with a single 300 baud modem is not going to be pleased to have to
go calling up name servers for each address it wants to send mail to.
Period.

I just checked, and the Multics mailer in fact implements my proposed
use of return-path -- as a way to send a reply back if the available
name resolving services don't make it.

Thus there seems to be a non-problem here.

The envelope contains return-path, which is one way to get back to the
source host of the mail.

All that I (and some others, it seems) are asking is for the RFC's to
say explicitly that if a host puts some other hostname in a from or
reply-to field, that it better be prepared to act as a mail gateway to
that host.

Return-path is already defined as the path back to the source, so no
change in its definition is needed.

From/Reply to should have a user name and a host, and trust to the
domain services and the return path to allow mail agentas to reply.

A mail agent that really wants to be verbose could show the user the
return path, but probably don't want to.

The issue of "what mailbox at the source host to send errors to" as
opposed to "how did this mail get here" seems to deserve a seperate
field, probably in the envelope.  The name return-path certainly
suggests my interpretation.

Date: 13 Feb 84 19:46 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: Margulies@CISL-SERVICE-MULTICS.ARPA
Subject: RE: return path etc.
Cc: header-people@MIT-MC.ARPA
Message-ID: <446C83C0.000E0021.1984@CMCL1.NYU-CMCL1.ARPA>
In-Reply-To: <840213234100.476146@CISL-SERVICE-MULTICS.ARPA> 	;
	Message of 13-FEB-1984 19:02 from "Benson I. Margulies" <Margulie

	A PC with a single 300 baud modem is not going to be pleased to have to
	go calling up name servers for each address it wants to send mail to.
	Period.

Fine. Period.  But who proposed that?  My apple will call NYU-GW for all SMTP
mail and will only validate addresses to the level of domain (ARPA, UUCP, NYU)
in real time.  Anything else will have to be done asyncronously since I can't
guarentee continous virtual circuit to the destination mail box. 

	All that I (and some others, it seems) are asking is for the RFC's to
	say explicitly that if a host puts some other hostname in a from or
	reply-to field, that it better be prepared to act as a mail gateway to
	that host.

No a bad requirement.  By as I argued last year, only to be used in EMERGENCIES,
as when the host table does not contain a host name, not as a subsititue for 
registering with a Domain or subdomain name server.


Further note that to avoid excessive nastyness the NYU mail can eliminate 
all but the last known hostname from a generated route, otherwise mail
bounced off dumb reflectors would tend to burn grouves in the network.

BUT mailbox should remain absolute addresses not relative ones.  A mailer is
not using absolute addresses if it always generates paths for messages to 
any host.
 
-------

Received: by YALE-BULLDOG via CHAOS; Mon, 13 Feb 84 21:24:48 EST
Received: from YALE-RING by YALE-RES via CHAOS; Mon, 13 Feb 84 21:26:02 EST
Subject: Re: header reply fields
Date: Mon, 13 Feb 84 21:26:05 EST
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: header-people@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Mon 13 Feb 84 14:09:18-PST

    The point is, you don't need to implement the full domain protocol
    to use domains.  You merely need to know somebody who does, or
    rather does so more than you do.
    
Amazingly enough, there is already a model for this kind of service.    
It is called the U.S. Postal Service.  It seems to work tolerably
well (and presumably better than a scheme in which I have to know
the name and route of every mailman from here to California).

I am quite concerned by the prospect of the non-Internet world and
the Internet world having a large enough "paradigm split" so as to
preclude anything better than almost completely awful solutions to
the mail delivery problem.  The microworld has to get away from explicit
routing and the Internet world has to get away from the notion that
everyone can always connect to (almost) anyone else.

A fleshed out notion of a delivery hierarchy (where to send mail to
when I can't understand the address) and its relationship (if any)
to a naming hierarchy seems like a good idea:  it would tend to engage
both the "microworld" and the Internet world in a mutually beneficial
discussion.  The problem with a delivery hierarchy is that some machines
have to be willing to do work for others.  Who pays and how?  Which
will come first:  our solution to these problems or AT&T's (or the
USPS's or whoever's)?  Do we care?

Sorry if this is too much "Worldnetbabble".  I just find the prospect
of all the good work and thought about mail going down the tubes to
be depressing.

        -- Nat

Date: Mon 13 Feb 84 23:51:34-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: header reply fields
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 Mon 13 Feb 84 16:32:16-EST

I noticed in the conversion tables for domain-style to Arpa-style host
identifications a number of conventions for an MIT Chaos host to be
converted to an ARPA-style looking host.  For example, if I sent a
message to you from MIT-OZ (the mailsystem where I saw this), I'd be
creating an MIT Chaos From: address that looked like:

From:  GDS@MIT-OZ.#Chaos

whereas when it actually leaves the Chaosnet to the ARPANet it is
transformed to 

From:  GDS%MIT-OZ@MIT-MC.ARPA

Wouldn't it be feasible for non-Internet hosts to do some sort of
conversion from non-Internet to Internet syntax as they cross their
mail gateways into the Internet?

-------

From: vortex!lauren at RAND-UNIX
Date: Mon, 13-Feb-84 18:54:49-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: return paths and small machines
Message-ID: <8402131854.9111.0.VT2.2@vortex.UUCP>
To: header-people@MIT-MC

I hate to tell you this friends, but within the next few months I'm
going to let my MSDOS UUCP and related mail programs out of the bag,
and indications are strong that there could be MANY, MANY machines
running this code very quickly.  The decisions I make RIGHT NOW
regarding domain handling and the like will probably affect more machines
than everything else put together for quite some time.

I feel VERY strongly that absolute routing must always be available
when DESIRED or MOST ECONOMICAL/FASTEST -- not just in "emergencies".
Masses of little machines trying to concentrate mail into a relatively
few "smart" gateway hosts would quickly swamp those systems and also
result in much longer mail delivery times in many cases.  These systems
will have a very limited ability to hold large (or even small) databases,
but will NOT be willing to forward all their mail through inefficient
paths just for the sake of naming, especially in those cases where
many fast direct or semi-direct routes are available (very often the case
with UUCP routings).  

Once these programs are out the door, I have no way to force everyone to
get updates later -- so before long there could be many 1000's of these
things floating around that will depend on absolute routing for many
situations and have only limited (or no) domain knowledge.  You can try
ignore them if you wish, but judging from the organizations that are
screaming at me to release these programs, many of you will end up ignoring
yourselves!

Let's try for a compromise.  I can't hold this stuff back much longer,
and any decisions must be made right now or it'll be too late as
far as the 10's of 1000's of smaller machines are concerned.

--Lauren--


Date: 13-Feb-84 22:27 PST
From: Rich Zellich  <RICH.GVT@OFFICE-3>
Subject: Re: return paths and small machines
To: header-people@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-442TE>
In-reply-to: <8402131854.9111.0.VT2.2@vortex.UUCP>

As far as I can see, there is no reason to try to stamp out uucp "routing" 
addresses, because to the non-uucp Internet, one of those long strings with all 
the !s in it is just a mailbox name at some host in some domain.  As long as 
that host can recognize that it is receiving a uucp route/address and can 
appropriately route it via uucp instead of Internet SMTP or whatever, who cares?
(At least as long as messages coming OUT of the uucp context get properly 
transformed so the DCA-specification Internet programs can understand the return
addresses.)

-Rich Zellich


Date:  Tue, 14 Feb 84 10:26 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  lauren's manifesto
To:  header-people@MIT-MC.ARPA
Message-ID:  <840214152600.810167@CISL-SERVICE-MULTICS.ARPA>

Lauren --

   I may be confused ---

Could UUCP do all its !'ing in the return path instead of the
From/Reply-to/To field?

That way, any individual little beastie that could be found via the
domain system would be, but the little beasties and the big beasties
could still communicate via the complete route in the return path.

I.E., move the path information to the envelope.


Received: by YALE-BULLDOG via CHAOS; Tue, 14 Feb 84 16:40:04 EST
Received: from YALE-RING by YALE-RES via CHAOS; Tue, 14 Feb 84 16:40:18 EST
Subject: Re: return paths and small machines
Date: Tue, 14 Feb 84 16:40:21 EST
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: vortex!lauren@RAND-UNIX.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: vortex!lauren at RAND-UNIX, Mon, 13-Feb-84 18:54:49-PST

    I hate to tell you this friends, but within the next few months
    I'm going to let my MSDOS UUCP and related mail programs out of
    the bag, and indications are strong that there could be MANY,
    MANY machines running this code very quickly.  The decisions I
    make RIGHT NOW regarding domain handling and the like will probably
    affect more machines than everything else put together for quite
    some time.
    
    I feel VERY strongly that absolute routing must always be available
    when DESIRED or MOST ECONOMICAL/FASTEST -- not just in
    "emergencies".  ...

I'm glad that you're worried about the issues.

The problem I have with UUCP is not so much that absolute routing
is evil, but that everything in the present UUCP systems I've seen
seems so ad hoc.  Ad hoc names, ad hoc routing, ad hoc "parsers".
I think the most important aspect of any mail system that is distributed
to the masses is that it doesn't forclose future possibilities.  If
your version handles names up to only 10 characters, that's what we'll
be stuck with forever.  If your version picks one of the 2 possible
interpretations of "a!b!c@x" (i.e. "a!b!c" at "x", or "a!b" ! "c@x")
instead of defining some reasonable syntax to determine which you
mean, then we'll be stuck with that.

    Masses of little machines trying to concentrate mail into a
    relatively few "smart" gateway hosts would quickly swamp those
    systems and also result in much longer mail delivery times in
    many cases.  These systems will have a very limited ability to
    hold large (or even small) databases, but will NOT be willing
    to forward all their mail through inefficient paths just for the
    sake of naming, especially in those cases where many fast direct
    or semi-direct routes are available (very often the case with
    UUCP routings).
    
In the short run, this all is quite true.  In the long run, clearly
it can't be or the whole thing will collapse.  The time will come
when people will choose reliability and ease of use over direct manual
routing and speed.  They'll make that choice even if they have to
PAY for that less speedy system.  People don't (by and large) put
up their own satellite dishes -- they pay a cable TV company to do
it.  The problem is to design the system now so that the transition
to the inevitable will be as painless as possible.  Perhaps it's not
do-able.

            -- Nat

Date:  14 February 1984 18:50 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Re: Return path and small machines
To:  HEADER-PEOPLE at MIT-MC
cc:  DSullivan.CSC_SDO at HI-MULTICS, 
     Winterton.HISCAN at HIS-PHOENIX-MULTICS, 
     Stachour.CSCswtec at HI-MULTICS

  Well, it does look like something of an "envelope" issue.  On one of
the systems I'm familiar with there is a small host-table which takes a
fully specified domain name and returns a best way to get there. Since
the system in question only *has* about three ways of getting mail out,
it tends to be rather trivial.
  The envelope gets marked "send via HI-MULTICS.ARPA" most of the time,
and presumably the path it followed to get wherever it was goung
reflects this, despite the fact that my real address is "Dave
Brown"@CCSC-SDO.Minneapolis.Honeywell, and gets put in as "who I am".
  It strike me that the algorithm the oracle (which owns the host table)
was published here about six months ago.  By Bill Wells, maybe?
  In any case, it was and is a trivial name server, necessary and
sufficent to get a message out on the most suitable path to a particular
sub-domain.
  --dave
    DBrown.TSDC @ HI-MULTICS.ARPA
    watbun!drbrown @ watmath.UUCP
    "Dave Brown" @ CCSC-SDO.Minneapolis.Honeywell(. maybe ARPA someday)

Date: Tue 14 Feb 84 19:49:05-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: return path etc.
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 Mon 13 Feb 84 15:57:52-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

    From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
    Subject:  return path etc.

    What does envelope-ness have to do with this?
Simple.  Concepts such as the "origin address", the "composer
address", the "reply address", and the "return address [as
distinct from reply address]" should be specified in the message
envelope.  At present SMTP only puts the "return address" and the
"destination address" in the envelope.  The Return-Path header
line is generated by whatever process finally delivers the
message to the destination user (often the SMTP server but not
necessarily; in TOPS-20 it's the mailer), solely for the benefit
of other networks which don't have envelopes and depend upon the
header for everything.

    A PC with a single 300 baud modem is not going to be pleased to have to
    go calling up name servers for each address it wants to send mail to.
Of course not.  But it is going to have to call up somebody to
start the message on its way.  That somebody could also be the
name server.  I'd rather have my PC calling up an intelligent
delivery agent that knows what I'm talking about than some stupid
forwarder that insists that I tell it everything.

    I just checked, and the Multics mailer in fact implements my proposed
    use of return-path -- as a way to send a reply back if the available
    name resolving services don't make it.
Multics is not the specification.  RFC's 821 and 822 are the
specification.  All you've said is that the Multics mailer has a
bug that some individuals perceive as a feature.  Past archives
of Header-People will document bugs in the TOPS-20 mailer that I
would protest is a feature.

    The issue of "what mailbox at the source host to send errors to" as
    opposed to "how did this mail get here" seems to deserve a seperate
    field, probably in the envelope.  The name return-path certainly
    suggests my interpretation.
I'm afraid that RFC's 821 and 822 use Return-Path to mean the
former.  And a non-trivial amount of software on a non-trivial
number of hosts implement it as this.

I'll tell you what.  I'll agree to lobby with you to change the
meaning of Return-Path if you lobby to get the syntax of dates to
not require a comma after the day or week and to require a hyphen
before the time zone.  It may sound silly to you, but it means a
good deal to TOPS-20.

Needless to say, both ideas probably would be rejected - and
should be.
-------

From: vortex!lauren at RAND-UNIX
Date: Wed, 15-Feb-84 00:22:21-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: manifesto
Message-ID: <8402150022.11658.0.VT2.2@vortex.UUCP>
To: header-people@MC

No manifesto intended!  I'm just desperate for a reasonable solution
that will be acceptable to everyone involved.  The little machines
are going to (apparently) be used heavily by corporate and other
large entities who will be communicating with sites scattered
across the world, and will (for speed and money reasons) want to
route mail via the overall "best" route, taking full advantage
of the high interconnectivity of the Internet.

Would you really expect someone to send their mail to a "smart" name
server, perhaps knowing that the server is topologically far away
from the desired destination, if the sender knows of a more or less direct
route that it can use easily?  I just don't think that the concentration
required by the forced use of name servers is practical or desirable.

You might argue that uucp sites can do what they want and should leave
everyone else alone.  I would claim that is impossible.  There are
gateways springing up everywhere, and any attempt to "control" their
use would just result in more "unofficial" hacks appearing to 
replace them.  There's going to be one hell of a lot of traffic between
the uucp net and everything else!

One thing about the return path -- it is useful for addressing
information only as a last resort in many cases.  Especially for mail
routed through centralized machines, the return path may well
indicate a route that is far more costly (in terms of time and money)
than many other (topologically shorter) routes.

This really is a desperate situation.  We probably have no more than
a couple of months before I'll have to start releasing the package,
and my time for major code modifications at this point is quite small.
Can't we come up with something that we can all live with and that
has a reasonable chance of working when scaled up pretty massively?

Thanks much, all.

--Lauren--


Date:  Wed, 15 Feb 84 09:34 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Definition of Return-Path
To:  header-people@MIT-MC.ARPA
Message-ID:  <840215143408.115972@CISL-SERVICE-MULTICS.ARPA>

I think there is a compatable re-definition of the return path.

Define the user-name/mailbox part of the return path to be, indeed, the
correct destination of error messages.  Not wonderful, but effective.
The rest of the return path is still a way back to some host that is
guaranteed to be will ing to act as a mail gateway to the host names in
the from and/or reply-to fields.


Date: 15 Feb 84 1251 EST (Wednesday)
From: don.provan@CMU-CS-A
To: vortex!lauren@RAND-UNIX
Subject: Re: manifesto
CC: header-people@MIT-MC,
In-Reply-To: <8402150022.11658.0.VT2.2@vortex.UUCP>
Message-Id: <15Feb84.125107.DP0N@CMU-CS-A>

but it's the corporations and other large entities that i would
expect to go out and buy a name server/best route finder to plug
into their local net.  you make it sound as if they'll have to route
mail through sri-nic.  if a site needs effecient routing and can afford
it, it should buy it.  if it doesn't need it or can't afford it, it may
send some mail via a non-optimal path.  what's so bad about that?  what
is it that uucp people feel smtp is lacking?  i don't see that the path
back to the originator really solves any uucp problems.  there no reason
to think that the sending site knows any more about the best route than the
replying site does.  you may increase ineffeciency by encouraging software
to use longer than necessary routes just because that's the way the mail
came in.

maybe the problem is that us arpa types (well, this arpa type, anyway) don't
understand enough about how uucp works to understand the problem.  there's
no doubt that there are serious routing problems when each link runs at
a different speed, has a different amount of traffic, and is up for
different periods in a day.  i don't see how making changes in the mail
delivery scheme lessens those problems.  no matter how many hooks you
put in, SOMEBODY has to know that his link is only up for 10 minutes a
week and runs at 300 baud or that this link is no longer available.
your PC isn't going to.  is your PC going to come up with the route, or
is the user responsible for that?  how did either of them discover the route.
i, for one, am so baffled by these questions that i can't hope to understand
what you think a mail delivery scheme can have to make these problems go
away.

i don't think the two sides swatting at each other is going to get us
very far.  maybe a few lessons will help.

							don

Date: 15 Feb 84 14:18 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: <@MIT-MC:vortex!lauren@RAND-UNIX>
Subject: RE: manifesto
Cc: header-people@MIT-MC.ARPA
Message-ID: <464E7CA5.008A0022.1984@CMCL1.NYU-CMCL1.ARPA>
In-Reply-To: <8402150022.11658.0.VT2.2@vortex.UUCP> 	;
	Message of 15-FEB-1984 04:24 from vortex!lauren@RAND-UNIX

I am not quite sure what the problem is, exactly.  It sounds like Lauren
is wants to know where in an RFC822 mail file he should put the cached
routing information from the envelope of the incomming message that is
being replied to.  Conceptually RFC822 didn't need to include any 
envelope information, but a few fields were copied in simplify life for 
people converting 733 mailers (sort of, I guess, although I was never
really clear on this even when people were discussing it.)

But the envelope infomation mat need to be kept somewhere and could be 
used to update a reverse path routing database for UUCP style delivery
agents.   Such a database really doesn't take up too much room since 
you eliminate the path information from the message and just leave
the alsolute address, the added cost should be on the close order of
the size of the absolute address even in a naive implementation.   

Is the propblem that you want equal shot at putting stuff into the 822
mail format to make this implementation easier?  Or that you don't
want to added an envelope section to the users mail file?  Or that you
don't want to write the trivial name server to cache this infomation on 
the PC?  {Sigh I can see it now RFC987: Trivial Name Server 
Implementation.}
 
-------

Date: Wed, 15 Feb 84 12:24:27 pst
To: vortex!lauren@RAND-UNIX
Cc: header-people@MC
Subject: Re: manifesto
In-Reply-To: Your message of Wed, 15-Feb-84 00:22:21-PST.
             <8402150022.11658.0.VT2.2@vortex.UUCP>
From: Tim Mann <mann@diablo>

The idea of a domain name server is to make life easier, not
harder.  If you don't know how to get to some site, you can
ask a name server.  There is no reason not to cache knowledge
of how to get to certain sites on your own machine.  Roughly
speaking, I think the new Internet RFC's are basically
intended to formalize this notion.  The major problem here is
that non-Internet mailers have to worry about routing to the
destination, not just addressing it.  Nevertheless, I think
it's possible to use the Internet scheme in a
non-fully-connected network by using source routing (Internet
syntax, not ...!...!...) when you know or can construct a good
path to the destination, otherwise sending the mail on to a
"smarter" host which runs the software to do the job.  The
step of constructing a route should be done by the mail
software, not the user, whenever possible, using whatever
information is available.  One source of information could be
a nearby host running a full-blown name server -- if there is
no such host nearby, or it doesn't make sense to query it
rather than just sending the mail to it (perhaps because the
information would only be used once), the mailer would fall
back on the second approach, forwarding the mail to someone
smarter.

I'm assuming here that there are roughtly 3 classes of
machines involved -- small personal computers, which are not
necessarily up all the time and don't have much disk space or
processor power, but nonetheless want to participate; larger
computers that are up fairly reliably, have dialins and
dialouts but are not on the ARPA Internet; and Internet
machines.  The first class is, I think, what your software is
directed toward, while the second class is the sort of machine
that's on the uucp net now.

	--Tim

Date: Wed, 15 Feb 84 12:25:49 PST
From: David Alpern <Alpern.Ibm-Sj@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: What am I missing?  (Domains vs. Return-path discussion)
To: Header-People@Mit-Mc
Via:  IBM-SJ; 15 Feb 84 15:18-PST

Ok, somewhere I missed something.
 
I thought the idea behind domains was to make all Internet addressing
absolute, and remove the need to specify routes to a host that knows of
the host you really wish to address.
 
The use of the host portion of return-path, which is frequently a non-822
compatible multiple '@' form, as a route to a gateway as something to try
when all else fails seems reasonable to me only when all else fails.
 
Where I'm lost is how the two combine.  When domains happen, won't the
problem of unknown hosts in a FROM go away, unless a mailer is really
broken or does something weird at a gateway?  I thought all FROMs, etc.,
were supposed to be qualified so that at least the domain specified
would be known to all recipients.
 
 

From: vortex!lauren at RAND-UNIX
Date: Wed, 15-Feb-84 16:30:46-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Re: manifesto
Message-ID: <8402151630.13019.1.VT2.2@vortex.UUCP>
To: mann@diablo
CC: header-people@MC
In-Reply-To: Your message of Wed, 15 Feb 84 12:24:27 pst

I'm afraid that a lot of people are going to be using PC's as class
(2) machines -- up all the time for mail and servicing a fairly
large number of class (3) machines (and other class (2) machines).
In any case, these PC's will all be running my software, and I doubt
very much if all of the name server issues could possibly be worked
out and implemented before the software hits the street.  Therefore,
I'm looking for a "fallback" solution that will be practical.

--Lauren--


From: vortex!lauren at RAND-UNIX
Date: Wed, 15-Feb-84 16:23:55-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: uucp
Message-ID: <8402151623.13001.1.VT2.2@vortex.UUCP>
To: don.provan@CMU-CS-A
CC: header-people@MC
In-Reply-To: Your message of 15 Feb 84 1251 EST (Wednesday)

The issues are complex.  I'm not sure that this is the right place
for a uucp tutorial, even if I had the time to write one at this point.
There is plenty of arguing going on over on uucp as well about 
handling growth WITHIN the uucp network itself.  

A couple of points though.  First of all, your expectation that
large entities will make the investment in name servers and such
assumes more organization that these people usually have in this
area.  They just want to get a WHOLE BUNCH of PC's talking to each
other and the Internet as quickly as possible.  Maybe someday they'll
want to make bigger investments in more sophisticated hardware/software, but
for now they want quick and easy access to the nets.  Anything more
than that requires bigger initial investments and is harder for them
to justify since they want to "build up" to a big operation after a
period of time.

My point is that the software I give them NOW for their immediate needs
is going to probably be running for a long time, so I want to make
sure that it's as reasonable as possible.  Your model of 300 baud systems
only up 10 minutes a day is inaccurate.  Most systems run at 1200 baud
and will be up 24 hours a day in some mode or another.  Some PC's will 
be mail-only machines of a sort for local areas and will do nothing
else.  But they STILL will have limited capabilities compared with
a 780 running sendmail.  This does NOT mean that they might not be in
contact with dozens of major hosts via dialed-in or dialed-out calls,
and have access to a vast number of direct and indirect routing choices,
that could allow speedy mail delivery.

Given that some uucp sites only talk to each other once a day, knowing the
most direct path to a site can make the difference between getting
a message through in 24 hours vs. getting it through in a week.  The
degree of centralization encouraged by the name server sort of 
scenario would tend to add more hops to the average message, and could
slow delivery to an extent as to make it pretty much useless.

By the way, are we sure that we're arguing about the same thing?

--Lauren--


Date:  Wed, 15 Feb 84 20:46 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Alpern's and Lauren's last notes
To:  header-people@MIT-MC.ARPA
Message-ID:  <840216014632.516417@CISL-SERVICE-MULTICS.ARPA>

It is not clear that we are arguing about the same thing.

Try these cases:

1) PC originating new mail to host, someplace.  Lauren, now do you
imagine that it figures out how to send it?  Does the user inform the
program?

2) PC replying to mail that came it.  I don't see why the return-path
should be so substantially non-optimal.

Or these questions:

Do UUCP hosts (PC's expecially) typically store a bunch of !-ity-!
routes to popular destinations, so the user don't have to type them?

Where do they keep this database?

Date:  Wed, 15 Feb 84 20:47 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  envelopes versus messages
To:  header-people@MIT-MC.ARPA
Message-ID:  <840216014745.993851@CISL-SERVICE-MULTICS.ARPA>

It seems to me that some of the cross purposes of this discussion relate
to the role of envelopes.  I always have assumed that the content of the
envelope is available to the mail agent (mail reading program, if you
like) of the recipient.  Am I out-to-lunch on that?

Date: 16 Feb 84 0021 EST (Thursday)
From: don.provan@CMU-CS-A
To: vortex!lauren@RAND-UNIX
Subject: Re: uucp
CC: header-people@MIT-MC
In-Reply-To: <8402151623.13001.1.VT2.2@vortex.UUCP>
Message-Id: <16Feb84.002138.DP0N@CMU-CS-A>

i guess that's my problem: i don't really understand what we're arguing
about, and it feels like i'm not the only arpa type that doesn't.
i thought your point was that return-path needs to get messages back
to the originator for uucp type network.  am i crossing arguments?

Date: 16 Feb 1984 1228-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: namedroppers at SRI-NIC, header-people at MIT-MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: Addressing in international environments
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11992230303.17.132.27001 at DEC-MARLBORO>

Unfortunately, due to CCITT recommendations dealing with carrying
traffic for "others," top-level domains do not provide enough information
to route messages in the international environment (or even the national
environment within some countries).

For example, let's assume that someone at UCL-CS.ARPA wants to send a
message to a user on ZAPHOD.DIGITAL (assuming the top-level domain DIGITAL
is established).  If UCL-CS believes that the correct method for sending
to domain DIGITAL is to establish a PSS call to a DIGITAL host which is
located in the U.K. and is capable of accepting mail, everything is ok
in this case, since ZAPHOD is located in Reading, Berks.

If the same person also wants to send to someone at VORTEX.DIGITAL, located
in Nashua, New Hampshire, the same route may or may not be legal, depending
on British regulations.  It may also be permitted to send the message via
the ARPAnet to a gateway in the U.S.

However, if the same person at UCL wants to send to a user on MUN02.DIGITAL,
neither of the above routes are permitted.  The UCL sender must send to MUN02
directly (or at least to a host located in the same building as MUN02); since
Germany strictly interprets the CCITT reccomendations prohibiting the use of
private data networks for carrying traffic to or from an outside entity.

This could be interpreted as requiring top-level domains to not extend past
the boundaries recognized by PTTs.  The extent of a top-level domain would
vary from country to country.  In the U.S., DIGITAL-US could cover the whole
country.  In Germany, a domain would have to be established for each separate
piece of property.

If MUN02 is not to be further qualified than with the domain DIGITAL, then
UCL-CS (or any other mail originator, e.g. a CSNET host, a PC running Lauren's
UUCP software) has to be able to do one of the following:

	1. Contact a name server to find out the correct gateway to use to
	   reach MUN02.DIGITAL.

or	2. Require (or allow) the user to specify an explicit path.

The restrictions placed on interconnection of public and private networks
in some countries may seem bizarre to those of us in the U.S., but they are
based upon CCITT recommendations.  Though we can take the attitude that
"these countries will suffer the economic consequences of restrictive
regulations as businesses relocate to other countries" this attitude is
not conducive to the success of electronic mail.
   --------

Date: 16 Feb 1984 13:26-EST
Sender: DDEUTSCH@BBNA
Subject: Re: Addressing in international environments
From: DDEUTSCH@BBNA
To: decwrl!rhea!castor!covert@SHASTA, RSX-DEV@DEC-MARLBORO(Attn: Covert)
Cc: namedroppers@SRI-NIC, header-people@MIT-MC, DDeutsch@BBNA
Message-ID: <[BBNA]16-Feb-84 13:26:04.DDEUTSCH>
In-Reply-To: <"MS10(2124)+GLXLIB1(1136)" 11992230303.17.132.27001 at DEC-MARLBORO>

To which CCITT recommendations do you refer?  Normally CCITT
recommendations are not concerned with the operation of private
networks, though they do regulate the connection of private networks
to public networks.  As you noted, individual countries take differing
approaches towards internal telecommunications regulations.  

Also, the draft CCITT recommendations on message handling systems (the
X.400 series) put countries at the top level of the addressing
hierarchy.  The draft recommendations do not constrain the routing of
messages between countries.  They do say, however, that a private
management domain (i.e. a message-relaying system, possibly spanning
many nodes, controlled by a private organization) cannot be used to
link two public management domains.  This is regardless of whether the
private management domain is built upon a public or private data
network.

Your message raises some deeper questions.  Given a hierarchical
naming/addressing scheme, how closely should that scheme follow the
network architecture?  Should it always be possible to directly derive
the route from the name?  

It is my contention that no matter how arbitrarily telecommunications
regulations may interfere with routing, naming should be sufficiently
orthogonal to routing in order to allow a reasonable naming hierarchy
(i.e.  DIGITAL-GERMANY, or even DIGITAL-WORLD).

Debbie Deutsch

Date: 16 Feb 1984  12:57 MST (Thu)
Message-ID: <WANCHO.11992257478.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To:   Header-People@MC
Subject: Does Guinness accept these?

Return-Path: <@COLUMBIA-20.ARPA:pourne@Mit-Mc.ARPA>
Received: from COLUMBIA-20.ARPA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 12:42:34-MST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 13:20:25-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP; 
          16 Feb 84 18:16 GMT
Via:	UCL-CS; Date:	Wednesday, 15-Feb-84  16:28:40-GMT
Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK   via Satnet with SMTP; 
          15 Feb 84 13:17 GMT
Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:04:49 PST
Date: 15 February 1984 04:06 EST
From: "Jerry E. Pournelle" <POURNE@mit-mc.arpa>
Subject:  Let's spread the good news!
To: Per_Lindberg_QZ <Per_Lindberg_QZ%qzcom@ucl-cs.arpa>, 
    KERMIT_implementation_and_experience <KERMIT_implementation_and_experience%qzcom@ucl-cs.arpa>
cc: info-kermit <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa@ucl-cs.arpa>
In-reply-to: Msg of 13 Feb 84 13:29 +0100 from Per_Lindberg_QZ%qzcom at ucl-cs.arpa
Sender: POURNE <POURNE%mit-mc.arpa@usc-isid.arpa>

what's that supposed to mean?  I do not know anything about
KERMIT either.  How should I?  There have been drearily long
expositions on the net at 300 baud;  I have yet to see anything
in print or in my mail.
If Kermit is available for any machine I know of, I'd like to
see it run.  can it work on a Compupro?  Z-80 or Dual Processor?
Ot what does it take to make it run?  Is there a way I can get a
copy  mailed to 
J E Pournelle
BYTe
POB 372
Hancock NH 03449
	Or at least some description of what it is?

    Date: 13 Feb 84 13:29 +0100
    From: Per_Lindberg_QZ%qzcom at ucl-cs.arpa
    Reply-To: Per_Lindberg_QZ%qzcom at ucl-cs.arpa,
          KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa
    To:   KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa,
          info-kermit <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa at ucl-cs.arpa>
    Re:   Let's spread the good news!
    Remailed-From: Billy <BRACKENRIDGE@USC-ISIB>
    Remailed-To: pourne@MIT-MC

    It seems to me that there is a lot of people with personal computers
    Out There who has never heard of KERMIT, and probably would be very
    happy to. And I think KERMIT deserves more publicity. So, who writes
    an article in BYTE?

    	- Per Lindberg, QZ -

    (Text 41569)------------------------------



Date: Thu, 16 Feb 84 16:14:46 est
From: Mark Shoemaker <mas@Purdue.ARPA>
Message-Id: <8402162114.AA17984@mordred.ARPA>
Received: by mordred.ARPA; Thu, 16 Feb 84 16:14:46 est
To: header-people@mit-mc.ARPA
Subject: PC node names
Cc: vortex!lauren@rand-unix.ARPA

When the hords of PC's (that Lauren will be providing software for)
come on-line, how will they be addressed?

Perhaps I'm paranoid, but as the UUCP network has been having site
(node?) name conflict problems for some time now, what's going to
happen when Lauren's (or someone else's) clever comm. software is made
available and everyone with a moderately powerful micro wants to be
networked?

So far, the discussion has concerned reasonable ways for them to send
mail (or whatever) out to the rest of the world; how will the inverse
work?

		shoe

Date:  Thu, 16 Feb 84 13:40 EST
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Addressing in international environments
To:  Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc:  RSX-DEV@DEC-MARLBORO.ARPA, namedroppers@SRI-NIC.ARPA, 
     header-people@MIT-MC.ARPA
In-Reply-To:  Message of 16 Feb 84 13:16 EST from "Charles Hedrick"
Message-ID:  <840216184025.532046@MIT-MULTICS.ARPA>

    From:  Charles Hedrick <HEDRICK at RUTGERS>

    The only regulations that
    would make Arpanet domains illegal would be a regulation that prevents
    DEC from having a single nameserver that gives out routings to all of
    its machines.  Surely even Europe won't do that.

Even that isn't a real problem, as a domain may have more than one name
server.  Indeed, for purposes of reliability and reduction of network
congestion, large domains SHOULD have more than one.
                                        barmar

Date: 16 Feb 1984 14:04-PST
Sender: GEOFF@SRI-CSL
Subject: glop.
From: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL>
To: Header-People@MC
Message-ID: <[SRI-CSL]16-Feb-84 14:04:44.GEOFF>

I've seen a lot of these type of addresses recently.  Dose anyone
have any ideas where they come from and what they mean?  In the
egregious case (below) I have no idea where the username ends and
the host address begins!  What would someone do if they needed to
reply to this person?

P.S.  What about all this "(Text
41915)-------------------------......"  bad breath we are
starting to see at the end of messages emitting from Xerox
recently?  It looks like header field pollution has become
contagious, moved down and invaded the message body.

	
    Received:  from SU-SCORE by SRI-CSL via DDN;  16 Feb 84 13:47:37-PST
              from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Feb 84 13:10:42-PST
              from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623256738786884@MIT-MULTICS.ARPA>; 16 Feb 1984 13:25:38 est
    Date:        15 Feb 84 01:46 +0100
    From:        KPJ_Jaakkola_QZ@QZCOM
    Subject:     interrupt at 20?
    To:          TOPS-10/20_SIG@QZCOM
    Cc:          tops-20 <Tops-20@SU-SCORE.ARPA>
    In-Reply-To: <41882@QZCOM>
    
    Top fork stops at address 20, either due to a HALTF% or an error.
    Job lacks privileges, monitor Mini-EXEC (MEXEC) displays the
    message, and logs out the job.
    (Text 41915)------------------------------
    
		

-------

Date:  Thu, 16 Feb 84 18:23 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Is someone trying to prove a point?
To:  header-people@MIT-MC.ARPA
Message-ID:  <840216232352.436538@CISL-SERVICE-MULTICS.ARPA>

I have gotten several messages from person_%_arpa.Mit-Xx.ARPA%yorkcom at
UCL-CS that were copies of mail sent to header people.

Now, that set of % will produce a pretty indirect route to begin with.
But worse yet, the mail from me seems to be sent from UCL-CS to
something.UK over SATNET!

Is this an exercise in pessimal routing of mail?  A demonstration of the
return-path problem?  ???

From: DonWinter.pasa@PARC-MAXC.ARPA
Date: 16 Feb 84 16:02:48 PST
Subject: Re: glop.
In-reply-to: GEOFF@SRI-CSL.ARPA's message of 16 Feb 84 14:04 PST,
 <[SRI-CSL]16-Feb-84 14:04:44.GEOFF>
To: GEOFF@SRI-CSL.ARPA
cc: Header-People@MC.ARPA

Just exactly what leads you to associate the (Text 41915) tag with
XEROX? The message you forwarded did not emanate from within Xerox. Does
THIS message have such a tag on it? (I will see when it gets back to
me.)

Date: 16 Feb 84 1926 EST
From: Rudy.Nedved@CMU-CS-A
To: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL>
Subject: Re: glop.
CC: Header-People@MIT-MC
In-Reply-To: <[SRI-CSL]16-Feb-84 14:04:44.GEOFF>
Message-Id: <16Feb84.192639.EN0C@CMU-CS-A>

I suspect it is MAILNET software. I started seeing this stuff come out
of MIT's mailnet connection a few months ago.
-Rudy

Date: Thu 16 Feb 84 19:51:37-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Is someone trying to prove a point?
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 Thu 16 Feb 84 15:44:20-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

It's a great example of why domains are a good idea and why using the
return-path or other relative routes is a bad idea.  Domains or any
other absolute addressing system would have optimized the delivery
route.  You can't optimize relative routes, because there is absolutely
no guarantee that the FOOBAR host at one part in the route equals the
FOOBAR host on some other portion of the route.
-------

From: vortex!lauren at RAND-UNIX
Date: Thu, 16-Feb-84 22:18:49-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Re: PC node names
Message-ID: <8402162218.2113.1.VT2.2@vortex.UUCP>
To: mas@Purdue.ARPA
CC: header-people@MC
In-Reply-To: Your message of Thu, 16 Feb 84 16:14:46 est

Well, as a practical matter, there is no way to totally FORCE someone
to not pick a name already in use.  However, it is quite possible
to refuse to deal with such a site -- thusly effectively isolating
it from the rest of the network.  As it happens, I will shortly be
announcing the Global UUCP Sitename Registry, which will perform
verification and basic registration of UUCP sitenames.  This work
will be done by myself in conjunction with other persons who are
handling the nitty-gritty of maintaining UUCP map/routing
databases.  Hopefully this will all help keep the situation under
control.  It will still be tricky, however, and will have to be
watched carefully...

--Lauren--


Date:     Fri, 17 Feb 84 11:10:03 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:  Is someone trying to prove a point?

As there have been several comments on this, let me explain a little
of what is going on.

The critical system involved is COM, a conferencing system developed by
Jacb Palme in Stockholm.   There are two instantiations of this, which
interact with the Arpanet: one at York, UK (yorkcom) which will send and
receive using UCL as a relay;  and one at QZ, Stockhom, Sweden  (qzcom
/ oden.mailnet), which is a mailnet host using mit-multics  as a relay.
Both UCL and MIT use the '%' notation to hide  non-arpa domains/hosts.

There are some relevant points:
1) COM adds the _____(text123456) which Geoff noted.   The
number refers to the COM entry.

2) COM usernames have spaces.  Palme found that simply quoting
these caused a lot of problems with many Arpa sites (!!).  Thus
he chose to map spaces into underscores.  Unfortuantely, the
software is not perfect, and often lexical separators, as well
as spaces embedded in usernames get mapped.  This may be fixed
at qz, but certainly not at york.

3) When generating reply addresses, the full trace information
associated with the message is used to generate a humongous
source route (which will get worse when a message is repeatedly
answered).  Attempts are then made to eliminate redundant
components.  (As can be seen from the phrasing of this, I
believe it to be an inappropriate approach).

4) There is a bug/configuration problem at Yrokcom, which
can cause cause strange messages to be sent to an address
approximately relating to recipients in the message to: list.
If this is not fixed soon, the York header-people entry
will be removed from the UCL list expansion.

Steve


Date:  Fri, 17 Feb 84 08:34 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Re: Is someone trying to prove a point?
Reply-To:  header-people@MIT-MC.ARPA
To:  header-people@MIT-MC.ARPA
In-Reply-To:  Message of 16 Feb 84 22:51 EST from "Mark Crispin"
Message-ID:  <840217133410.140836@CISL-SERVICE-MULTICS.ARPA>

Mark,

   I agree. What I am still perplexed about is

(1) why all that crap couldn't continue to stick around, quietly, in the
envelope (and in a much more compact form)

(2) if its in the envelope, why it is evil for not-very-clever hosts to
use it if they are unwilling or unable to do better.

 --benson

Date:  16 February 1984 17:01 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Re: Addressing in international environments
To:  John R. Covert <RSX-DEV at DEC-MARLBORO>
cc:  Header-People at MIT-MC, namedroppers at SRI-NIC
In-Reply-To:  Message of 16 February 1984 12:28 est from John R. Covert

  With respect, I disagree.
  My understanding of the domain/nameserver scheme is that Vortex's
machine sends to a machine which knows about the domain "DEC",
(hopefully almost anyone), and that machine, if it does not *itself*
know how to reach the DEC net, passes it on to a host which it has
listed in its' local name server as accepting responsability for mail to
all of DECNET.
  That machine, presumably a DEC mail gateway, then has the
responsability of forwarding (or refusing) the mail to the proper site
in the proper country, obeying all the trans-border data-flow
regulations then in force.
  So Lauren's machine (and my baby bun) need not know any explicit paths
or mailing heuristics because of the "domain of responsability" design
of the ARPA Internet.
  --dave (why should *i* understand DECNET?) brown

Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.22)
	id AA06274; Thu, 16 Feb 84 17:04:50 pst
Received: by ucbarpa.ARPA (4.22/4.22)
	id AA05640; Thu, 16 Feb 84 17:05:25 pst
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 16 Feb 1984 1705-PST (Thursday)
Message-Id: <5638.31.445827921@ucbarpa>
To: Christopher A Kent <cak@Purdue.ARPA>
Cc: header-people@MIT-MC.ARPA
Subject: Re: "Return-Path" vs. "From"
In-Reply-To: Your message of 7 Feb 1984 0806-EST (Tuesday).
             <8402071306.AA15144@merlin.ARPA>
Fcc: mail

Gosh Chris, I'm awfully sorry that I have tried to do the right
thing instead of perpetuating the insanity that has characterized
(and sadly, continues to characterize) the UNIX mail system.

Sendmail passes the information it gets from the received envelope
into the transmitted envelope.  If the mailer is a program rather
than an SMTP channel, the "envelope" consists of the command line
arguments.

The version of Mail that comes with sendmail works, as does MH.
This seems to cover 90% of the 4.2 users.

eric

Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623342751739532@MIT-MULTICS.ARPA>; 17 Feb 1984 13:19:11 est
Date:     17-FEB-1984 11:15 EST
From:     OBERST%EDUCOM.MAILNET@MIT-MULTICS
To:       HEADER-PEOPLE@MIT-MC.ARPA
Subject:  RE: glop.


     I've seen a lot of these type of addresses recently.  ...

    Received:  from SU-SCORE by SRI-CSL via DDN;  16 Feb 84 13:47:37-PST
              from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Feb 84 13:10:42-PST
              from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623256738786884@MIT-MULTICS.ARPA>; 16 Feb 1984 13:25:38 est
    Date:        15 Feb 84 01:46 +0100
    From:        KPJ_Jaakkola_QZ@QZCOM


The message presented came from the QZ Computing Centre in Stockholm.  If
"these type of addresses" refers to the use of underscores in the
local-part of the mailbox, they are being generated by QZ in place of
blanks, since MIT-MULTICS (which relays QZ's messages to a number of
MAILNET and other sites) had not been able to properly handle quoted
strings in SMTP paths.  For consistency, they made both the SMTP and the
822-header local-parts translate blanks to underscores.  In any case
the @ is the delimiter separating local-part ('user-name') and domain
('host').

As for the "(Text 41915)-------------------------", QZ's local mail system
is actually a conferencing system, which associates a numeric ID with all
'text'--as opposed to messages which can contain text(s)--and thus tags each
text with the offending 'breath.'  QZ converts their 'headers' into RFC822
format in messages that get sent out, but since the Text ID can refer to
part(s) of the message they decided to keep it in the text/message-body part
of the message.  Apologies to Xerox for having been named as co-polluters.

Some Background:

     MAILNET uses the Phonenet strategy of autocall modems over phone lines
(and outbound Telenet/TYMNET) to connect to remote hosts for the pick-up and
delivery of electronic mail.  MIT-MULTICS is the 'hub', and there are currently
15 universities so connected (including the U of Stockholm's QZ).  We have a
gateway under development to BITNET and several universities accept and forward
mail to/from other networks that they are connected to.  For telephone dial-up
sites we run the mmdf link-level protocol (Phonenet's) and X.25 as llp for most
of the Telenet sites.  We have adopted to use SMTP for mail transfer and
attempt to use RFC822 for message format.

     We have attempted to act as if DOMAINS existed, but use the % routing
convention whenever sites send messages to non-MAILNET sites.  Thus most
sites append '.MAILNET' to their site-name, but we encourage/require routing
information for messages that go beyond MAILNET sites.  (Thus in this message,
the OBERST%EDUCOM.MAILNET@MIT-MULTICS should allow ARPA readers to reply
in the absence of a MAILNET domain name-server).  There has been reluctance
in some quarters to implementing temporary hacks (like %'s) with the result
that most sites have half-implemented temporary hacks.

     I have followed the domain/reverse-path/RFC733-still-lives-on-with-%
discussions on Header-People, and would be happy to hear other suggestions
about what to do while we wait for DOMAINS and name-servers to appear.

Dan Oberst
MAILNET Director

Date:  Fri, 17 Feb 84 15:37 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  return-path
To:  header-people@MIT-MC.ARPA
Message-ID:  <840217203723.729084@CISL-SERVICE-MULTICS.ARPA>

Well, if the return path is supposed to be where errors end up, could
someone please fix the tops-20 mailer so that the return path for all
mail to tcp-ip at NIC would be tcp-ip-request at NIC, and not the
originator of the mail?

Date:     17 February 1984 1338-pst
From:     Jerry Bakin    <Bakin @ HI-MULTICS>
Subject:  Overloading the UUCP network. (Keep this message away from flammables.)
To:       HEADER-PEOPLE @ MIT-MC

Am I alone, or have other people experienced:

 o  Mail lost in UUCP.
 o  Mail successfully transmitted but received too late to be of use.
    (One week or more delay interval between sending and receiving)
 o  A from path which is useless (no pun intended) as a reply path, and
    no reply path explicitly given.
 o  No idea of a path from host A to host 2, much less knowledge of an
    optimal route between the two.
 o  A previously known host in a path between two hosts going down for an
    unknown amount of time forcing a completely new path to be worked out.
 o  A previously known gateway between two networks going down for an
    unknown amount of time forcing completely new paths to be figured out.
 o  The name of a host in a path changing.

It is my understanding UUCP was intended to be used on the very low
scale.  Now, what is already an overloaded net is threatened to be
completely inundated by the release (neither good nor bad) of a version
of UUCP for the PC.  Am I to believe that industry, faced with KNOWLEDGE
of the above problems, and needing a mail which is reliable, is
screaming for Lauren to release his PC UUCP?   
 
Yes, I do believe they are screaming, but for two reasons: I) They have
no knowledge of the problems, II) Cheap is CHEAP.

However, with the possible trebling of the load on the UUCP net due to
commercial use, can we expect intolerable problems?  Perhaps such sites
as Berkeley, a taxpayer funded gateway, will stop being a gateway,
because there is only so much subsizing of a commercial net their
administration will allow (not to mention the possible trebling costs)?
Or, other gateway sites which are already commercial, but support CS
use, will stop being allowed to be used as gates due to increased costs
and loads on their systems.

Lauren, we all want to become rich and help mankind, let me make a
suggestion that you design a net which runs on phone lines at 1200 baud,
is domain like in its addresses, dynamically rerouting based upon cost,
and speed, delivers mail, registered mail, and secure mail, (all with
acknowledgement of receipt available.)  Start it for the PC, (call it
Personnel Computer Protocal --  PCP), design it so anyone can adopt it,
and market this.  Businesses will pay the added phone costs in much the
same way that they pay for business calls now, so the cost of calling
cross country via cross town will not be as important as getting the
mail there this hour versus this month. In the mean time, UUCP will not
become anymore bogged down than it is, nor will I or any of us have to
subsidize Charlie Chaplan's Hat Business anymore than we currently do.
And if you really want to become rich, you'll lease own cross country
lines, (They're only 3K a month) and run your net yourself at higher
speeds and charging people by the message.

Jerry.

Date:  Fri, 17 Feb 84 19:57 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  PCP proposal
To:  header-people@MIT-MC.ARPA
Message-ID:  <840218005705.697379@CISL-SERVICE-MULTICS.ARPA>

It exists.  Its called MCI-Mail.  If businesses want reliable, cheap,
addressed delivery to PCs they just buy MCI Mail advanced service for
each one and MCI endeavours to disambiguat the names.  No domains yet,
but I bet they could be convinced ...

Return-Path: <harpo!hou3c!ka>
Received: by seismo.ARPA ; Fri, 17 Feb 84 20:21:34 est
Date: Fri, 17 Feb 84 20:21:34 est
From: harpo!hou3c!ka@SEISMO
Message-Id: <8402180121.AA08809@seismo.ARPA>
To: MRC@SU-SCORE.ARPA
Cc: header-people@mit-mc.ARPA
Subject: Paths vs. Domains
In-Reply-To: Your letter of Thu, 16-Feb-84 22:51:37 EST

This actually covers several different issues.  First, relative naming
vs. each machine having a unique name.  Second, the specification of
routes vs. the specification final destination only.  Finally, if you
have routes, the use of a host specific syntax vs. a single route
syntax.

I agree that machine names should be unique.  The domain scheme pro-
vides a way to do this.  One problem with the scheme is that  it was
designed to handle naming on the Internet.  Thus last I heard the plan
was to have DARPA register register domains that met certain require-
ments (including having two nameservers on the Internet).  The result
has been that people have gone ahead and announced the existance of
domains like MAILNET and UUCP which are not registered anywhere, so
name conflicts are possible.

I also agree that it would be better if users did not have to specify
routes, but it is difficult to avoid the necessity.  What is worse is
that the routes are currently buried into the domain specific string in
many cases.  For example, mail from CSNET has a return addresses like
"spaf.gatech@CSNet-Relay.ARPA".  My mailer will use an efficient route
to reply to this, but only because of a hack I put in my mailer to
rewrite this address as "spaf@gatech.csnet".  Recently CSNet has been
replacing the dot with a percent sign so that the code I wrote no
longer works.

I don't think that the necessity for providing explicit routes will
disappear any time soon.  There are lots of problems, depending on the
domain (including, as I mentioned, the lack of even a registery of top
level domains that don't talk to the Internet.)  What I do hope is
achievable in the relatively near term is the use of explicit routes
as opposed to placing routing information in the domain specific string.
With the former a mailer approach it is easy to determine the original
address; with the latter it is necessary to know the peculiarities of
particular hosts.
				Kenneth Almquist



Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP; 
          18 Feb 84 1:00 GMT
Via:	UCL-CS.; Date:	Saturday, 18-Feb-84  00:57:34-GMT
Date:        18-Feb-84 00:25-BST
From:        vortex!lauren_ <vortex!lauren_%_rand-unix%yorkcom@ucl-cs.arpa>
Reply-to:    vortex!lauren_ <vortex!lauren_%_rand-unix%yorkcom@ucl-cs.arpa>, 
             ARPA_Header-People%yorkcom@ucl-cs.arpa
To:          ARPA_Header-People%yorkcom@ucl-cs.arpa, 
             header-people <header-people%mit-mc.arpa@ucl-cs.arpa>, 
             vortex!lauren <vortex!lauren%rand-unix.arpa@ucl-cs.arpa>
Subject:     manifesto
Message-ID:  <3649@YORKCOM>

Transfer file: DSKA:PST011.COM[3,5]
Via: UCL-C   ; 1984-02-18  00:24:12-BST
Date:   Friday, 17-Feb-84  19:35:47-GMT
Received: from Ucl-Cs.AC.UK by 44d.Ucl-Cs.AC.UK   via List-Channel;
          15 Feb 84 16:06 GMT
Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK   via Satnet with SMTP;
          15 Feb 84 13:18 GMT
Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:23:58 PST
From: vortex!lauren at RAND-UNIX
Date: Wed, 15-Feb-84 00:22:21-PST
Original-Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: manifesto
Message-ID: <8402150022.11658.0.VT2.2@vortex.UUCP>
To: header-people@MC
Sender: header-people-request@ucl-cs

No manifesto intended!  I'm just desperate for a reasonable solution
that will be acceptable to everyone involved.  The little machines
are going to (apparently) be used heavily by corporate and other
large entities who will be communicating with sites scattered
across the world, and will (for speed and money reasons) want to
route mail via the overall "best" route, taking full advantage
of the high interconnectivity of the Internet.

Would you really expect someone to send their mail to a "smart" name
server, perhaps knowing that the server is topologically far away
from the desired destination, if the sender knows of a more or less direct
route that it can use easily?  I just don't think that the concentration
required by the forced use of name servers is practical or desirable.

You might argue that uucp sites can do what they want and should leave
everyone else alone.  I would claim that is impossible.  There are
gateways springing up everywhere, and any attempt to "control" their
use would just result in more "unofficial" hacks appearing to
replace them.  There's going to be one hell of a lot of traffic between
the uucp net and everything else!

One thing about the return path -- it is useful for addressing
information only as a last resort in many cases.  Especially for mail
routed through centralized machines, the return path may well
indicate a route that is far more costly (in terms of time and money)
than many other (topologically shorter) routes.

This really is a desperate situation.  We probably have no more than
a couple of months before I'll have to start releasing the package,
and my time for major code modifications at this point is quite small.
Can't we come up with something that we can all live with and that
has a reasonable chance of working when scaled up pretty massively?

Thanks much, all.

--Lauren--



(Text 3649)------------------------------


From: vortex!lauren at RAND-UNIX
Date: Fri, 17-Feb-84 18:22:51-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: It's coming.
Message-ID: <8402171822.3626.1.VT2.2@vortex.UUCP>
To: Bakin@HI-MULTICS
CC: header-people@MC

Sorry Jerry, but you lose.  Most of the problems with UUCP aren't really
with UUCP at all, but with other software (mail delivery software, for
example) which in many cases didn't have the facilities for properly
handling exception conditions.  This is certainly getting better rapidly.

In any case, 90%+ of the 1000's of Unix boxes being sold now have
UUCP capability.  This makes it pretty much a universal, for better
or worse.  I'm not interested at this time in trying to force through some-
thing new -- I want to give people something that they can plug in and use,
right now, to communicate with the most other people possible.  This
means UUCP.  You might be interested to know that 99% of the businesses
that want my UUCP are already involved in UUCP in one respect or another
and are fully aware of both the positive and negative benefits.  People
don't want to be restricted to a subset of sites running some new 
software -- they want to communicate with the 1000's of sites that exist
now.

You might as well resign yourself to the fact that it's coming, 'cause
it is!  As an aside, I think I've worked out a reasonable solution to the
domain handling for my related mail software, and that will hopefully
help to keep things under control.

--Lauren--

P.S.  Keep in mind that I straddle both sides of the fence.  I've been
an ARPANET user for far longer than the vast majority of others on the net,
and I also am heavily involved in Usenet activities.  This allows me to
see both sides of the issue, though I can't claim to have magic wands
for every situation.

--LW--


From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8402180354.AA03461@merlin.ARPA>
Received: by merlin.ARPA; Fri, 17 Feb 84 22:54:43 est
Date: 17 Feb 1984 2254-EST (Friday)
To: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Cc: header-people@MIT-MC.ARPA
Subject: Re: PCP proposal
In-Reply-To: Your message of Fri, 17 Feb 84 19:57 EST.
             <840218005705.697379@CISL-SERVICE-MULTICS.ARPA>

Ugh. At $1/message, it's hard for me to think of MCI Mail as cheap...

chris
----------

From: vortex!lauren at RAND-UNIX
Date: Fri, 17-Feb-84 18:34:47-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Swedish mail loop?
Message-ID: <8402171834.3661.0.VT2.2@vortex.UUCP>
To: header-people@MC

I just saw one of my messages from a few days ago come bouncing back
into header-people through that (mailnet?) gateway (in Sweden?)
Can someone in charge of that thing please try to avoid this?  Thanks.

--Lauren--


From: vortex!lauren at RAND-UNIX
Date: Fri, 17-Feb-84 21:10:22-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: $1/message
Message-ID: <8402172110.3840.0.VT2.2@vortex.UUCP>
To: header-people@MC

Or to put it another way, would you be willing to subscribe to
HEADER-PEOPLE if you had to put a dollar into your terminal for
each message received?

--Lauren--


Date: Sat 18 Feb 84 01:18:39-PST
From: David Roode <ROODE@SRI-NIC>
Subject: Re: $1/message
To: vortex!lauren@RAND-UNIX, header-people@MIT-MC
In-Reply-To: Message from "vortex!lauren at RAND-UNIX" of Fri 17 Feb 84 22:51:43-PST
Location:  EJ286    Phone: (415) 859-2774

I think that bulk mailing lists could be argued to be cheaper,
so I think a comparable rate would be $.60 to receive Header-people.
I think that MCI Mail is probably already entertaining the notion
of providing an interface to a processor of some sort
at the user's modem, but I have no specific knowledge.
If this service is offered, it should likewise be cheaper.
-------

Date:  Sat, 18 Feb 84 09:52 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  More spacewarp from York
To:  header-people@MIT-MC.ARPA
Message-ID:  <840218145247.590195@CISL-SERVICE-MULTICS.ARPA>

Why do extra copies of Lauren's mail come back to haunt us days later
courtesy of YorkCOM?

  --benson

Date:  Sat, 18 Feb 84 09:56 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  COM versus Case Sensitivity
To:  header-people@MIT-MC.ARPA
Message-ID:  <840218145631.915725@CISL-SERVICE-MULTICS.ARPA>

Folks,

  We here in Multics have always wanted to see a rule that hostnames may
be translated to upper case, but that the original case be preserved if
possible.

We are good losers, though, so the tendency to uppercase everything
don't bother us too much.

The random initial capitalization intruduced by, for example, YorkCOM,
is a bit too much.  Mit-Xx?  Someone has got to be joshing me.

Either we allow case of names of people and hosts to be meaningful, or
not.  If the answer is no, this pseudo-heuristic is pretty silly.


    --benson

Date:  Sat, 18 Feb 84 17:23 EST
From:  "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
Subject:  my note on MCI mail
To:  header-people@MIT-MC.ARPA
Message-ID:  <840218222344.582791@MIT-MULTICS.ARPA>

It occurs to me that I was at least half serious.  Note:

I.  The argument from Political Economics

We are told that large corporate organizations want to use PC sized
machines to store and process data.

We are told that these organizations want to interchange information
amongst widely seperated examples of these machines.

We know that a large corporation will have very little tolerance for
insecurity, unreliability, and general flakeyness.

THEREFORE, we conclude that large organizations will have little use for
UUCP as we know it today.

We know that corporations have money to spend to soolve their problems.
They bought the PC's.  They buy federal express packets for big bucks.

We know that where there is a demand for a service, and money to pay
(generously) for it, that the service will usually spring up, unless
trampled by state intervention.

THEREFORE, we expect some large organization to offer a means by which
an organization with many scattered machines can reliably and securely
deliver information amongst them.

Is it any surprise that MCI mail already is claiming to offer this
service, even if it isn't all there yet?

II.  An argument about "randoms"

Now, what about the intrepid explorers?  Today, the intrepid explorers
use UUCP and phone-net and friends.  What choice have they?  Given a
nice, reliable, organized alternative, will they use it?  If its cheap
enough they sure will.  Phone calls ain't free either.  Why should I
leave my PC sitting around dialing the phone like a little "daemon" if I
could hand the delivery problem off to someone else?

III.  But still, we have to design ...

Of course, a system like MCI, let alone a bunch of competing systems
like MCI, will need to deal with name resolution and all those wonders.
The domain scheme is a pretty reasonable approach.  Let's hope that the
commercial entities buy in before the chaos gets out of hand.

But I think that the scenerio of 47million PC all tryping to figure out
what phone number to call to reach each other is silly.  They will call
up MCI, or SPC, or the PostalService, and let it worry, for a fee.

So to get really contentious:

  UUCP will die under its own weight, and be replaced by commercial
carriers who have the resources to apply Internet/CCITT style solutions
to naming and routing problems.

Date: 18 Feb 1984 17:05-PST
Sender: GEOFF@SRI-CSL
Subject: Re: $1/message
From: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL>
To: vortex!lauren@RAND-UNIX
Cc: header-people@MC
Message-ID: <[SRI-CSL]18-Feb-84 17:05:24.GEOFF>
In-Reply-To: <8402172110.3840.0.VT2.2@vortex.UUCP>

	
    Received:  from MIT-MC by SRI-CSL via DDN;  18 Feb 84 16:51:20-PST
    Date: Fri, 17-Feb-84 21:10:22-PST
    From: vortex!lauren at RAND-UNIX
    Subject: $1/message
    To: header-people@MC
    
    Or to put it another way, would you be willing to subscribe to
    HEADER-PEOPLE if you had to put a dollar into your terminal for
    each message received?
    
    --Lauren--
    
    
		
That's cheating, Lauren, since on MCI Mail it costs nothing to
receive a message (nor for that matter to compose one, login,
check for mail, etc), it only costs money when you actually SEND
something.  At that price, I think it's pretty cheap, especially
when you consider ancillary benefits like being able to receive
TELEX and TWX's at no cost.

g

From: vortex!lauren at RAND-UNIX
Date: Sun, 19-Feb-84 00:15:11-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Re: my note on MCI mail
Message-ID: <8402190015.6178.1.VT2.2@vortex.UUCP>
To: Margulies@MIT-MULTICS.ARPA
CC: header-people@MC
In-Reply-To: Your message of Sat, 18 Feb 84 17:23 EST

The flaw in your argument is assuming that "corporate"-type entities
demand that ALL of their communications be super reliable and
secure.  In fact, what many of them want is to be able to carry
on much the same sorts of "non-critical" applications that we currently
base on ARPANET, UUCP, etc.  They want to chat among themselves, "talk"
informally with researchers at other locations, tell jokes, and otherwise
do the sorts of things the rest of us do now.  For these sorts of
applications, security and reliability are not critical, nor are such
communications worth a lot of money.  

Force people to pay more than a very modest amount for such services,
and they won't participate at all, or only participate for very
"high-value" type communications.  It's specifically the "lower-value",
more informal sorts of communications that I consider to be of
importance and that I'm trying to promote.  Most businesses are not
yet willing to entrust important communications to electronic mail
(for a number of technical and legal reasons -- have you read MCI's
disclaimer for MCI mail?) and I don't intend to try change their mind
at this point.  Nor am I offering a UUCP electronic funds transfer
service...  so don't panic!

--Lauren--


From: vortex!lauren at RAND-UNIX
Date: Sun, 19-Feb-84 00:26:02-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Re: $1/message
Message-ID: <8402190026.6184.1.VT2.2@vortex.UUCP>
To: Geoff@SRI-CSL
CC: header-people@MC
In-Reply-To: Your message of 18 Feb 1984 17:05-PST

Well, I can put it another way, would you be willing to SEND a message
to header-people if you had to pay $1 for each person who would
be RECEIVING it?  This is even worse!  How likely would people
be to contribute their expertise on various subjects if they had to 
PAY to send that information to the people who would benefit?  Few of
our large mailing lists would survive under such a scheme.

Two specific points about MCI Mail:

1) Their technique of forcing you to use inane and time-consuming
   menus UNLESS you're willing to pay them money is pretty 
   low are far as I'm concerned.

2) I am convinced that their "free access" policy will not last.
   I'd be happy to give odds that somewhere not too far down the
   line, all "free" users will receive a notice telling them that
   if they want to keep their access, they will have to start paying
   a monthly fee and/or pay minimum amounts per month.  Clearly MCI
   has the right to do this, but the people who think the service
   is going to stay free forever are kidding themselves, I suspect.

--Lauren--


Date:     Sun, 19 Feb 84 10:14:35 EST
From:     Dave Farber <farber@udel-ee.arpa>
To:       vortex!lauren@rand-unix.arpa
cc:       Geoff@sri-csl.arpa, header-people@mit-mc.arpa
Subject:  Re:  $1/message

While I hate to get involved but ...


I have been using a package called TRANSEND for my IBM PC. It allows 
a reasonable PC-PC mail transefer with "attachments" that can be com files
etc. It used the modem7 protocol. Its human interface is very nice and
easily learned by simple managers. It can also relay mail though 
mail systems like the the SOURCE and Ontyme . So I can compose a 
lot of mail on my PC send some of it via pc-pc communications and
some via the source etc. While the mail part is not up to
arpanet standards (by a long shot) you would be surprised at how
useful it is. Clearly as soon as MCI gets their protocol
public, it too will be a vehicle for this type of usage
with a lot more flexibilty since I can telex etc.

Dave

Date: Mon 20 Feb 84 03:31:03-PST
From: David Roode <ROODE@SRI-NIC>
Subject: envelope information
To: Header-People@MIT-MC
Location:  EJ286    Phone: (415) 859-2774

I sometimes wish the so-called envelope information on an SMTP
transaction coming into my host were retained once the message was
delivered to its appropriate mailbox.  The motivation is that there
are multiple names by which my mailbox may be refered to.  Sometimes
it would be useful to be able to identify which was used for a
particular message, but that information is not listed in the standard
headers.  This would be the case for example when an alias had been
placed on a mailing list at another site.  The complete
distribution is not shown in the message body because it is too
long.

I mention this because some people seem to feel that the user
wishes to be saved from ever seeing the envelope, which is
currently generally only partially available (in the form
of the return path).  I contend that full retention of envelope
information is necessary for the user agent to function fully.
-------

Date:     Mon, 20 Feb 84 9:43:22 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:  More spacewarp from York

The relevant implementor knows.  I have broken the loop by removing
an entry from my sublist expansion.  

Steve Kille



Date: Mon 20 Feb 84 07:02:32-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: envelope information
To: ROODE@SRI-NIC.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "David Roode <ROODE@SRI-NIC>" of Mon 20 Feb 84 03:38:14-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     You cannot retain all the envelope information in a user-accessible
place, because this would defeat the purpose of bcc's.
-------

Date:  Mon, 20 Feb 84 12:43 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  security of envelopes
To:  header-people@MIT-MC.ARPA
Message-ID:  <840220174339.717329@CISL-SERVICE-MULTICS.ARPA>

No PC (or anything else) is secure.  If you really believe in the
security of BCC, the information had better never leave the sending host
in envelope or message..

Date: 20 Feb 1984 18:12:28-EST
From: eagle!hou3c!ka at mit-vax
Posting-Version: version B 2.10.1 6/24/83; site dartvax.UUCP
Path: hou3c!burl!clyde!floyd!harpo!decvax!dartvax!davidk
From: davidk@dartvax.UUCP (David C. Kovar)
Comments: The real from line reads
          From: davidk@dartvax.UUCP (David C. Kovar)
          Do not accept an substitutes.
Resent-From: ka@hou3c.UUCP
To: Header-People@MIT-MC.ARPA
Subject: Re: Overloading the UUCP network. (Keep this message away from flammables.)
Message-ID: <742@dartvax.UUCP>
Date: Sat, 18-Feb-84 15:18:44 EST
Received: by hou3c.UUCP; Sat, 18-Feb-84 21:45:38 EST
References: <290@hou3c.UUCP>
Organization: Dartmouth College
Lines: 59


	You suggest that Lauren go off and start up his own PCP network
so that UUCP will not become anymore bogged down than it is. You also
state that most of your problems with UUCP involve hosts going down,
causing you to reroute via other sites or networks. No where do you 
mention that the problems with UUCP involve overuse. Now I agree that
UUCP handles one hell of a lot of traffic, and I also agree that adding
PC sites will add more of a load to the net, but I fail to agree that
switching the PC's to another net will solve the problem.

	First off, I am going to send news and mail even if I do not
have UUCP running on my IBM XT. With it, I can compose on my own system
and free ports up on the colleges system. Without it, I will be composing
and thinking on the college's VAX and tying up their resources. Either
way, that article/mail is going out on the net. So in this case, I see
a PLUS in releasing UUCP for the PC, not a minus. The net load stays
about the same and my host system gets me off on my own.

	Secondly, the only people who can tie into an existing nodes
will have to request permission to do so from that site. Same process
that you have to go through for an account. This means that every PC
owner and their brother will not go out an join the net, they can't
get at it. They will all be paying for their own phone calls, not
the rest of the network. (I already ventured that their postings
to the net would stay the same, keeping that cost to the net even.)
Now each site might not want 40 PC UUCP sites calling in, but they
can deal with that on their own, that will not affect the net as a
whole.

	But, we will have a large number of new site names, and that
must be dealt with. And I also would not want to route my mail/news
through a PC site. To this end, we might add a 'pc' to the site name,
indicating that it was a leaf and should not be included in internal
paths. This would also help keep the site names unique.

	I wrap this up with one question: Who owns the net? If you
do not want to subsidize IBM, do not permit PC UUCP's at your site.
Each particular 'you' out there can refuse to subsidize in this way
but I would be rather upset if you decided to prevent me from posting
just because I own a IBM and you get paid $30K a year to hack UNIX.
If worst comes to worst, I'll go buy PC/IX and then be a 'real' site.
And by damned, if you do not like that, I can probably manage to
trade my car in on a MicroVax. If you want to keep VAX sites off of
the net, I wish you luck.

	Sorry about the flame, all.


-- 
David C. Kovar    
	    Usenet:	{linus | decvax | cornell}!dartvax!davidk
	    ARPA:	kovar@MIT-ML  (Infrequent)

	    U.S. Snail  HB 3140
			Dartmouth College
			Hanover NH
			03755

"The difficult we did yesterday, the impossible we are doing now."



Return-Path: <harpo!hou3c!ka@SEISMO>
Received: by seismo.ARPA ; Tue, 21 Feb 84 00:01:03 est
To: Header-People@MIT-MC.ARPA
From: hou3c!ka@SEISMO (Kenneth Almquist)
Subject: Re: envelope information
Message-Id: <313@hou3c.UUCP>
Date: Mon, 20-Feb-84 23:49:37 EST
References: <308@hou3c.UUCP>
Organization: Bell Labs, Holmdel, NJ

It seems to me that the controversy over what belongs in the envelope
and stuff that "has to be in the header for the benefit of networks
that don't have any concept of 'envelope' information" is due to
confusion over what RFC 822 is attempting to define.

If RFC 822 is supposed to define a general purpose, network independent
standard for mail transfer, then it should be complete.  This implies
that a "Currently-To:" field should be added to it so that a piece of
mail can be sent to another system without providing a destination
separately.

A lower level protocal must be used underneath RFC 822 to actually
transfer the mail.  In the case of the ARPANET, that lower level
transport could remove the "Return-Path:" and "Currently-To:" fields
from the header and transmit them in the envelope.  The receiving
process would then restore the values to the header.

Is there any explanation (other than confusion on the part of the
writers about what they were trying to do) why RFC 822 contains
"Return-Path:" but not "Currently-To:"?
  				Kenneth Almquist



From: vortex!lauren at RAND-UNIX
Date: Mon, 20-Feb-84 17:00:36-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: PC UUCP
Message-ID: <8402201700.1851.0.VT2.2@vortex.UUCP>
To: header-people@MC

By the way, my current code has full capabilities for forwarding mail
through to other sites in the typical UUCP manner -- in fact, vortex
handles quite a bit of West Coast traffic right now without any
problems at all.  The capacity for a PC to act as a mail server seems
to be quite high.  On the other hand, my current netnews handling
code is designed NOT to allow forwarding of Usenet netnews articles.
This was a conscious decision on my part based on the assumption that
few PC's would have enough disk space to handle such a potentially
voluminous task. 

--Lauren--


Date:     Tue, 21 Feb 84 15:30:21 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Mark Crispin <MRC@su-score.arpa>
cc:       ROODE@sri-nic.arpa, Header-People@mit-mc.arpa
Subject:  Re:  envelope information

I endorse the Currently-To: idea.  It can be done without destroying
the BCC protection for example it could be intermixed with the Recieved
lines.

   Delivering-To:  ron@Brl-Vgr
   Received: From BRL.ARPA by BRL-VGR via smtp;  20 Feb 84 21:38 EST
   Delivering-To:  info-unix@Brl-Vgr
   Received: From Brl-Vld.ARPA by BRL via smtp;  20 Feb 84 21:30 EST
   Date:     Mon, 20 Feb 84 21:29:06 EST
   From:     Doug Gwyn (VLD/VMB) <gwyn@brl-vld>
   To:       hnij@bnl
   cc:       info-unix@brl
   Subject:  Re:  file descriptors --> filenames

In the above example the letter was Recieved on BRL from the user on
the host BRL-VLD.  INFO-UNIX@BRL routes to INFO-UNIX@BRL-VGR.  It is
the received there.  INFO-UNIX is expanded and in turn delivered to
me (RON@BRL-VGR).

Our mail system, as well as others tries to keep the number of copies
of a message down, this might be circumvented by adding these extra
lines which make several slightly subtle changes.

-Ron

Date: 21 Feb 1984 23:09:47-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Subject: Strange Message
Posting-Version: version B 2.10.1 6/24/83; site sjuvax.UUCP
Path: hou3c!burl!clyde!akgua!sb1!sb6!bpa!burdvax!sjuvax!bbanerje
Comments: Beware of wolves in sheep's clothing; the real "From:" line reads
          From: bbanerje@sjuvax.UUCP
From: bbanerje@sjuvax.UUCP
Resent-From: ka@hou3c.UUCP
Resent-Date: Tue, 21-Feb-84 22:05:03 EST
Message-ID: <170@sjuvax.UUCP>
Date: Mon, 20-Feb-84 17:44:51 EST
Received: by hou3c.UUCP; Tue, 21-Feb-84 18:30:51 EST
Distribution: net
Organization: Saint Josephs Univ. Phila., Pa.

My apologies if this is in the wrong Newsgroup.  Anyhow, the
following in its entirety is a message I received  in the Mail.
Apparently a message I had posted to net.unix didn't make the
jump over to the ARPA-NET.

QUESTIONS - Is this due to one of the Hosts being dead, or is
this a usual occurence?  I'm only on the UUCP network.

	  - The body of my article didn't come back with the header.
Does this mean that it didn't make it out? Or does this mean that the
software only mails back Headers.

Any and all answers gratefully received.

			Binayak Banerjee
{ allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje
********************************************************************
>From burdvax!bpa!sb1!burl!Mailer@CMU-CS-C.ARPA Thu Feb 16 14:52:17 1984
Received: by sjuvax.UUCP (4.12/4.7)
	id AA11419; Thu, 16 Feb 84 14:52:08 est
Via: ulysses!mhuxl!eagle!harpo!ucbvax
Received: by ulysses.UUCP (4.12/4.7)
	id AA00975; Thu, 16 Feb 84 13:01:21 est
Received: from CMU-CS-C.ARPA by UCB-VAX.ARPA (4.22/4.22)
	id AA01766; Wed, 15 Feb 84 13:27:26 pst
Message-Id: <8402152127.AA01766@UCB-VAX.ARPA>
Date: Tue 14 Feb 84 08:20:05-EST
From: The Mailer Daemon <ulysses!ucbvax!Mailer@CMU-CS-C.ARPA>
To: harpo!eagle!mhuxl!ulysses!burl!clyde!akgua!psuvax!burdvax!sjuvax!bbanerje@BERKELEY.ARPA
Subject: Message of 14-Feb-84 08:19:35
Status: RO

Message undelivered after 0 days -- will try for another 0 days:
BBoard.Unix-Wizard@Tartan.TARTAN: Cannot connect to host.
	    ------------
Received: from BRL-VGR by CMU-CS-C with TCP; Tue 14 Feb 84 08:19:38-EST
Received: From Sri-Unix.ARPA by BRL-VGR via smtp;  9 Feb 84 8:48 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 5:41-PST
Date: 6 Feb 84 17:05:26-PST (Mon)
To: info-unix@brl-vgr
From:  harpo!eagle!mhuxl!ulysses!burl!clyde!akgua!psuvax!burdvax!sjuvax!bbanerje@ucb-vax
Subject: Re: Area-code as uucp domains
Article-I.D.: sjuvax.143
In-Reply-To: Article <458@houxe.UUCP> <1062@utah-gr.UUCP> <325@hogpc.UUCP> <173@lzmi.UUCP>, <247@dual.UUCP>

-------





-- 


				Binayak Banerjee
		{allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje



Date: 21 Feb 84 2327 EST
From: Rudy.Nedved@CMU-CS-A
To: eagle!hou3c!ka%mit-vax@mit-mc
Subject: Re: Strange Message
CC: Header-People@MIT-MC
In-Reply-To: <170@sjuvax.UUCP>
Message-Id: <21Feb84.232723.MA1L@CMU-CS-A>

It is a warning message from CMU-CS-C trying to send mail off of the
ARPANET to a host on a serial line called TARTAN. The warning
messages about unable to deliver mail contains ONLY the header and
not the body of the message.  The message has either been delivered
or is still pending to be delivered.

I would think it would be better to send a message to Postmaster@BRL
thru some common uucp address then it would be to broadcast this type
of thing to the entire header-people mailing list.

Rudy Nedved
A CMU Postmaster

Date: Tue 21 Feb 84 20:45:23-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: "Unable to deliver after 0 days"
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     The particular strangeness about the message (that is, it is
unable to deliver after no time at all) is due to a fencepost error
in older versions of the TOPS-20 mailer.  It was fixed a while ago --
it now tries for at least a day before reporting an error -- but the
distribution of the new software is quite irregular.
-------

Received: by UCB-VAX.ARPA (4.22/4.22)
	id AA14399; Tue, 21 Feb 84 22:35:17 pst
Date: Tue, 21 Feb 84 22:43:48 est
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8402220343.AA11347@cbosgd.UUCP>
Received: by cbosgd.UUCP (4.12/3.7)
	id AA11347; Tue, 21 Feb 84 22:43:48 est
To: header-people@mit-mc.ARPA
Subject: Re:  envelope information

If we're going to go this far:
	Delivering-To:  ron@Brl-Vgr
	Received: From BRL.ARPA by BRL-VGR via smtp;  20 Feb 84 21:38 EST
	Delivering-To:  info-unix@Brl-Vgr
	Received: From Brl-Vld.ARPA by BRL via smtp;  20 Feb 84 21:30 EST
why not just use the existing "for" subfield of Received,
as provided in RFC822:
	Received: From BRL.ARPA by BRL-VGR for ron@Brl-Bgr
		via smtp;  20 Feb 84 21:38 EST
	Received: From Brl-Vld.ARPA by BRL for info-unix@Brl-Vgr
		via smtp;  20 Feb 84 21:30 EST
By the way, this DOES seem like a good idea.
	
	Mark

From: Christopher A Kent <cak@Purdue.ARPA>
Message-Id: <8402231923.AA01007@merlin.ARPA>
Received: by merlin.ARPA; Thu, 23 Feb 84 14:23:55 est
Date: 23 Feb 1984 1423-EST (Thursday)
To: eric%ucbarpa@Berkeley.ARPA (Eric Allman)
Cc: header-people@MIT-MC.ARPA
Subject: Re: "Return-Path" vs. "From"
In-Reply-To: Your message of 16 Feb 1984 1705-PST (Thursday).
             <5638.31.445827921@ucbarpa>

Eric,

I stand only mildly rebuked. I agree that it is a bad thing to
perpetuate the insanity that is Unix mail. (Unix vendors could note
that they would do well to concentrate on developing a totally new mail
system -- grad student hacking doesn't seem to be enough.)

Unfortunately, the envelope information that you pass around is
misleading to the many other programs that parse Unix mailboxes. It
would have been simple to just use the true From address, rather than
the SMTP sender information, which is of little use to 90% of the users.
Programs which filter incoming mail (like msgs) present confusing
return/from addresses. 

It seems like the whole thing could have been solved/avoided by fixing
sendmail rather than having to hack on each of the programs that gets
confused.

chris
----------

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
	id AA08239; Thu, 23 Feb 84 23:52:33 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA08448; Thu, 23 Feb 84 23:42:31 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA16931; Thu, 23 Feb 84 23:35:49 pst
Date: Thu, 23 Feb 84 23:35:49 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8402240735.AA16931@ucbopal.CC.Berkeley.ARPA>
To: header-people@mit-mc
Subject: Re: envelope information

Since D.Brown has dropped by name into the pot, I guess it is time
to dust off my "Basic Message Format" again. The "Currently-to"
concept is the about the same as the "Relay-to" header field in my basic
message format.  I prefer "Relay-to" since it is already defined
for military messages.

For those that have not kept a copy of my basic message format header
fields, here is a summary of the header fields.

The "envelope information" is contained in the postal heading.

-----


Basic Message Format - 2 - "Heading Components"
Version 3 - 23 Feb 84

1. Basic Message Structure:

	Parts: 		Sub-parts:

	HEADING		Transmission Heading
			Batch Heading
			Postal Heading
			Message Heading

	TEXT		Message Text (Body of Message)

	ENDING		Message Ending
			Postal Ending
			Batch Ending
			Transmission Ending

The Internet text message format as defined by the "Standard for the
Format of ARPA Internet Text Messages" (RFC 822) has a heading and a
text. No ending is defined.

Basic message format classifies header fields into two groups, Message
Heading and Postal Heading fields.  In addition to RFC 822 header
fields there are additional header for use in the Postal Heading. No
attempt has been made to define "Batch" or "Transmission" fields since
these are more the concern of the network and the transport system being
used.

"Classification", "Precedence" and "Resent-Precedence" have been added
to the Message Heading to permit user definition of these fields.

2. Basic Message Format Header Fields by Sub-Part and Component.


                        POSTAL HEADING

     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Postal        Postmark             Posted-Date:
     Heading                            Posted-From:
                                        Post-ID:
                                        Postmaster:

                   Return Field         Return-Path:

                   Relay Instructions   Relay-To:
                                        Do-Not-Relay-To:

                   Trace Fields         Received:
     _____________________________________________________



                        MESSAGE HEADING

     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Readdressal   Date-Time            Resent-Date:
     Message
     Heading(s)    Originator's         Resent-From:
                   Address              Resent-Sender:
                                        Resent-Reply-To:

                   Originator's         Resent-Message-ID:
                   Message ID.

                   Precedence           Resent-Precedence:

                   Receiver's           Resent-To:
                   Address              Resent-cc:
                                        Resent-bcc:
                                        Resent-Exempt:
     _____________________________________________________

     Original      Date-Time            Date:
     Message
     Heading       Originator's         From:
                   Address              Sender:
                                        Reply-To:

                   Originator's         Message-ID:
                   Message ID.

                   Precedence           Precedence:

                   Receiver's           To:
                   Address              cc:
                                        bcc:
                                        Exempt:

                   Security             Classification:
                   Classification

                   Content              Subject:
                   Information          Keywords:
                                        In-Reply-To:
                                        References:

                   Encryption           Encrypted:
                   Field
     _____________________________________________________

     Heading       Comments             Comments:
     Comments      Field
     _____________________________________________________


Notes:

(a) Fields not defined  in  RFC  822  are:  Posted-Date,  Posted-From,
Post-ID,  Postmaster,  Relay-To,  Do-Not-Relay-To,  Resent-Precedence,
Precedence, Resent-Exempt, Exempt, Classification.  The order of  sub-
parts differs from RFC 822 Article 4.1 in that "source" is defined as:

           source = [trace]
                    [resent]
                    originator

(b) Each sub-part of the heading begins with its  corresponding  date-
time  field.  Fields  pertaining  to one sub-part may not be placed in
another sub-part. With the exception  of  the  date-time  field  which
begins  the  sub-part,  the order of fields within the sub-part is not
defined.  However the above order is recommended.

(c) There may be none, one or more "readdressal message heading"  sub-
parts  in  the message heading. If there is more than one "readdressal
message heading" the later ones precede the earlier ones.

(d) "Relay-To" fields may be deleted by relaying hosts (Mail Transport
Agent  programs)  when  delivery  has been made (or protected) by that
host (MTA).

(e) Relaying hosts (MTA's)  will  not  make  changes  to  the  Message
Heading  within an mail system using basic message format. Gateways to
non-basic message format mail systems,  may  translate  header  fields
into  other  formats.  However,  if  the other mail system's format is
incompatible with the basic message  format,  the  message  should  be
quoted  in the text of the other systems message.  The same applies to
incompatible messages being entered into an  a  basic  message  format
mail system.

(f) There may be only one "Date:", "From:",  "Sender:"  and  "Message-
ID:"  field per original message. Relaying hosts may not add or change
the "Message-ID" field.

(g) "Exempt" and "Resent-Exempt" fields are optional user fields  that
may be used with collective addresses to indicate that the drafter (or
user resending the message) does not want the message sent to  one  or
more addressees in the collective address.  Syntax is same as "To":

           exempt = "Exempt" ":" 1#address

           resent-exempt = "Resent-Exempt" ":" 1#address

-----

Comments?

Bill Wells, RMC, USNR-R

wcwells@BERKELEY.ARPA
ucbvax!wcwells

Computing Services, 297 Evans Hall,
University of California, Berkeley CA 94720


Date: 24 Feb 1984 1315-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: Header-People at MIT-MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: Domains, PTTs, Lauren's PC/UUCP, and the WorldNet
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11994335995.26.132.97343 at DEC-MARLBORO>

It is clear that the domain mechanism is the right mechanism for solving
the addressing problem in a world internet.

My earlier message on "addressing in the international environment" was
misunderstood by many, though I did get quite a few useful responses.

I wrote the message primarily in response to Lauren's message asking for an
interim mechanism for dealing with domains and name servers in an environment
where lots of UUCP(Lauren) systems are originating mail.  Though many of these
systems may be PCs, many more of them may be larger timesharing machines with
hundreds of users.

Lauren is correct in stating that once his software hits the streets, it will
become a defacto standard.

His implementation needs to be either sufficiently general to solve the
whole problem or must be guaranteed to be upgraded at a future time.
Guaranteeing upgrade is probably not realistic.  Producing sufficient
generality is also unlikely, so maybe all that can be hoped for is that we
understand the problems in the international market.

The international market has some special requirements caused by the
fact that in most of the rest of the world (outside the U.S.) there is a
monopoly on communications.  All communications.

One of the flaming responses I received asked "Why should I have to understand
DECNET?"  I went back and re-read the message I had sent, and nowhere had I
even mentioned DECNET.

Regardless of the protocol used, the rules for getting from point A to
point B (if one of those points is in a country which does not permit
the unrestricted interconnection of communications networks) can not
permit a host to simply dump the message on another host and expect it to
take care of all the PTT requirements, when a basic requirement is that no
one may carry someone else's traffic.  By carrying someone else's
traffic, the monopoly of the PTT on message transport (whether the message
is voice, data, or paper -- yes, I can't even legally hand carry someone
else's letter part of the way towards its destination) has been damaged.

For example, if machine X, located in country Y, wants to send a message
to SRI-NIC.ARPA and UCL-CS.ARPA, country Y may require that the message
be routed differently for each destination.  Country Y may not permit
messages to the U.S. to be routed via the U.K., or messages to the U.K.
to be routed via the U.S.

I'm not confusing domains with routing.  Both of the names in the example
above contain enough information to allow the host in country Y to do the
right thing.  But only after the names are further resolved.

The machine in country Y cannot send the mail to a single known system which
handles all mail to any ARPA host.  The names have to somehow be resolved by
a name server which is able to tell machine X the correct route for mail to
each of the machines based on the location of machine X and the locations
of SRI-NIC.ARPA and UCL-CS.ARPA.

The domain system can handle this.  Referencing both of these hosts
with just ".ARPA" is a valid interim solution as we migrate to the
domain structure.  Eventually, just .ARPA is not enough to allow the
host in country Y to deal with its PTT regulations.

Within the ARPAnet we may want to be able to always specify just .ARPA and
not be required to specify .ARPA.USA and .ARPA.GB (for example).  Software which
creates the headers in a message may have to be able to add country designators
so that a "Reply all" command issued by a machine in country Y can function
without involving name servers.

Though there is little relationship between what goes on within the ARPAnet
and what CCITT bodies do (since the ARPAnet is a research network), as the
connections between the ARPAnet and external networks become common, the
creators of these connections have to be sure that international agreements
allowing the ARPAnet to extend beyond the boundaries of the U.S. are not
violated.

The ARPAnet is not the only network which is international in scope.  DEC,
IBM, and many other companies have built such networks.  PTTs are within
the rights granted to them by their monopoly status to refuse to allow any
host on a private network to be connected to the public network unless the
software in use on those hosts is demonstrated to obey the rules imposed
by the monopoly.

A UUCP host might, for example, be required to demonstrate to the PTT, before
a modem could be connected to it, that it will only forward messages which
originated within the organization owning the machine.  Descriptions of the
protocol to be used may be required to be submitted with the application for
a modem connection license.

As a final note, I should state that most of my experience has come
from studying the requirements in Germany, primarily dealing with the
interconnection of public and private networks.  Remember that a network
is a private network even if it operates only over public network facilities.
It is private if the switching function is provided by a private entity.

All of this discussion took place prior to the completion of the
recommendations in the X.400 series.  How the X.400 series will affect
the environment in Germany is at the moment unknown.

One of the more interesting requirements under the German Telecommunications
Law is that if a new public service becomes available, private networks which
provide the equivalent service must be taken out of service.

As of last year, the DBP seemed to consider the Teletex service (which is an
upgraded version of Telex with a larger character set and higher speed data
transmission) as the service which would meet the electronic message needs
of the future.  They insisted that the service was a point-to-point service,
i.e. a Teletex line could not be connected to a data processing system to
allow distribution of messages within an organization.

Other countries may have less restrictive, some may have similar, and
some may have more restrictive regulations than Germany.  And Lauren may
have no plans for his product to be used outside the U.S.

Be glad these problems don't exist in the U.S.
   --------

Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25)
	id AA22044; Fri, 24 Feb 84 11:30:51 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.22)
	id AA22377; Fri, 24 Feb 84 11:31:54 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA20770; Fri, 24 Feb 84 11:30:26 pst
Date: Fri, 24 Feb 84 11:30:26 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA>
To: header-people@mit-mc.ARPA
Subject: Re: envelope information


Envelope Information - 1.1

Now that I have sent out my summary of basic message format header
fields I would like to limit the discussion to "envelope information"
(ie. my "postal heading" fields) in this discussion group
(header-people@mit-mc/net.mail.headers).  Discussion of the format in
general and other headings should be in the "MsgGroup@brl/
net.mail.msggroup" where basic message format was discussed last year.
To forestall some comments:  Yes, I know that "stacked" Resent headings
are incompatible with RFC 822.

Now back to "envelope information". In defining the "postal heading" I
was concerned with making a distinction between mail transport agent
functions and user agent functions (a distinction that is not clear in
RFC 822).  At the time I was aware that the mail formatting/generation
program could be different from the mail transport program(s) and that
the mail formatting/generating program might be spooling output to the
mail transport program for posting. I was thinking of the programs
being on the same host, but the introduction of smart workstations (and
personal microcomputers [pc]) adds a new twist to the problem. That is,
how to identify mail transmissions and handle error messages when the
user originates the message on a work station or pc and the mail
transport agent (ie. "post office") is on another host.
I do not think this latest twist is a problem if we make a clear
distinction between mail transport agent header fields and user
agent header fields. We will also have fewer problems if the
fields that are allowed to be changed by the mail transport
agent are limited. (Note: header munging or refiling messages across
mail system gateways is a separate issue.)

I think my postal heading fields can solve a number of these problems.
In my postal heading I have defined the following fields:

     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Postal        Postmark             Posted-Date:
     Heading                            Posted-From:
                                        Post-ID:
                                        Postmaster:

                   Return Field         Return-Path:

                   Relay Instructions   Relay-To:
                                        Do-Not-Relay-To:

                   Trace Fields         Received:
     _____________________________________________________

The "Postmark" fields serve to identify each message transmission.
--- My assumption is that a unique message identified by "Date"
"From" and "Message-ID" (fields added by the user agent mail
formatting/generation program) might be retransmitted to one
or more addresses of the original message (for example, when the
original message was returned to sender due to a host being down).

The "Postmaster" field serves to identify the Postmaster of the
of the originating mail transport agent. This is needed where one
mail transport agent is serving several hosts, workstations and
microcomputers. (This should handle the case where the originator
of a message is not in the same mail domain as the Postmaster of
the originating mail transport agent.)

"Return-path" - same as RFC 822, with one note: In addition to the
last mail transport agent adding this field, I think "gateway"
mail transport agents should also add/modify this field.



Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25)
	id AA25582; Fri, 24 Feb 84 15:10:11 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.25)
	id AA03091; Fri, 24 Feb 84 15:11:13 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA24196; Fri, 24 Feb 84 15:09:49 pst
Date: Fri, 24 Feb 84 15:09:49 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8402242309.AA24196@ucbopal.CC.Berkeley.ARPA>
To: header-people@MIT-MC.ARPA
Subject: Re:  envelopes versus messages

In reply to:

	Date:  Wed, 15 Feb 84 20:47 EST
	From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
	Subject:  envelopes versus messages
	To: header-people@MIT-MC.ARPA
	Message-Id:  <840216014745.993851@CISL-SERVICE-MULTICS.ARPA>

	It seems to me that some of the cross purposes of this
	discussion relate to the role of envelopes.  I always have
	assumed that the content of the envelope is available to the
	mail agent (mail reading program, if you like) of the
	recipient.  Am I out-to-lunch on that?

There is a problem with the definition of envelope. We each seem to have
our own definition. "envelope" information, that is information used or
added by the mail transport agents, should be passed on to the addressees
of a message, but may not be. The mail transport agents job ends when
the message has been spooled to (placed in) the addressees mail box.
Certain information available to the mail transport agent may not be
added to the heading of the message prior to being delivered to the
mail box.  Trace information and other information added by the mail
transport agents should be available to the receiving user agent,
though not necessarily displayed by default.  In the case of SMTP, much
of the SMTP envelope information may also need to be passed on to
a non-SMTP mail transport programs in the heading of the message.

The information also needs to flow in the opposite direction, from the
user agent (the mail formatting/generation program) to the mail
transport agent, and in some cases even down to lower levels.  For
example, the "precedence" and "classification" of a government message
is defined by the user agent, but does not look like the RFC 822 or
SMTP provides for precedence or classification information to be passed
from the user agent down to the IP Header "Type of Service" Precedence
bit and the Security field of the IP Header "Security" Option (see RFC
791 section 3.1).

Bill Wells
wcwells@Berkeley.ARPA
ucbvax!wcwells

Date: 24 Feb 1984 18:28:00-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: hou3c!burl!ulysses!harpo!decvax!decwrl!sun!gnu
From: gnu@sun.uucp (John Gilmore)
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <450@sun.uucp>
Date: Thu, 23-Feb-84 21:39:17 EST
References: <5638.31.445827921@ucbarpa>
In-Reply-To: <5638.31.445827921@ucbarpa>
Organization: Sun Microsystems, Inc.


	From: eric%ucbarpa@Berkeley.ARPA (Eric Allman)
	Subject: Re: "Return-Path" vs. "From"

	Gosh Chris, I'm awfully sorry that I have tried to do the right
	thing instead of perpetuating the insanity that has characterized
	(and sadly, continues to characterize) the UNIX mail system.

	Sendmail passes the information it gets from the received envelope
	into the transmitted envelope.  If the mailer is a program rather
	than an SMTP channel, the "envelope" consists of the command line
	arguments.

Unfortunately the information provided by uucp in the "envelope" is
often wrong.  This causes the "From " line and the "From:" line to
differ, which is very confusing to the end-users, mail-readers, etc.

For mail generated on the Arpanet and relayed to Sun via uucp, the
From: line is right (or at least can be munged to be right, by adding
".arpa"), but the "From " line often claims the message is from
"daemon" or "uucp" or whatever user happened to do something that
started this uucp connection.  E.g.:
	From uucp Thu Feb 23 00:27:47 1984
	From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
	To: "sun!gnu@shasta"@SUMEX-AIM.ARPA

For mail which has been passed solely thru uucp sites, the "From " line
is clearly correct, since the "From:" line has not been maintained at
(all) intermediate sites.  E.g.:
	From dual!allegra!cbosgd!fair Thu Feb 23 17:01:34 1984
	From: dual!cbosgd!fair

The win would have been to make the envelope right for all uucp
traffic, (which it already was for strictly-uucp traffic) and have
sendmail fix the From: line to match the "From " line.  This has not
been done -- yet.  Is there a uucp/mail expert in the house who can tell
us WHY the envelope is "uucp" or some user, instead of the right thing?



Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25)
	id AA02070; Fri, 24 Feb 84 18:29:44 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.25)
	id AA07483; Fri, 24 Feb 84 18:30:40 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA27344; Fri, 24 Feb 84 18:29:18 pst
Date: Fri, 24 Feb 84 18:29:18 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8402250229.AA27344@ucbopal.CC.Berkeley.ARPA>
To: header-people@mit-mc.ARPA
Subject: Re: envelope information


Envelope Information - 1.1 correction

Oh joy. My last message:
	Date: Fri, 24 Feb 84 11:30:26 pst
	From: wcwells@ucbopal (William C. Wells)
	Message-Id: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA>
	Subject: Re: envelope information
was truncated when it was transmitted locally.

Here is the bottom part again. Sorry for the repeat.

----


     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Postal        Postmark             Posted-Date:
     Heading                            Posted-From:
                                        Post-ID:
                                        Postmaster:

                   Return Field         Return-Path:

                   Relay Instructions   Relay-To:
                                        Do-Not-Relay-To:

                   Trace Fields         Received:
     _____________________________________________________

The "Postmark" fields serve to identify each message transmission.
--- My assumption is that a unique message identified by "Date"
"From" and "Message-ID" (fields added by the user agent mail
formatting/generation program) might be retransmitted to one
or more addresses of the original message (for example, when the
original message was returned to sender due to a host being down).

The "Postmaster" field serves to identify the Postmaster of the
of the originating mail transport agent. This is needed where one
mail transport agent is serving several hosts, workstations and
microcomputers. (This should handle the case where the originator
of a message is not in the same mail domain as the Postmaster of
the originating mail transport agent.)

"Return-path" - same as RFC 822, with one note: In addition to the
last mail transport agent adding(/modifying?) this field, I think
"gateway" mail transport agents should also add/modify this field.

The "Relay-to" field tells the receiving mail transport agent that
he(/she?) is responsible only for forwarding the message to a
specific list of addressee (not all addressee in the message heading).
It takes precedence over addresses in the message heading.
It may be used by either the mail transport agent or the user agent.
One example of user agent use would be in the retransmission of
a message which was returned to the sender, and the sender does not
want to retransmit to all addressees but only to the addressee that
did not get the message.

The "Do-not-relay-to" field is intended to be used with collective
addresses where mail transport agent has or is making delivery to
specific member(s) of the collective address via other means (for
example via an alternate mail system). This assumes the mail transport
agent applying this field knows the composition of the collective
address. "header-people@mit-mc.ARPA" is an example of a collective
addresss.

"Received" - same as RFC 822.


Bill Wells, U.C. Berkeley
wcwells@Berkeley.ARPA or ucbvax!wcwells


Date: 27 Feb 1984 18:23:15-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP
Path: hou3c!burl!ulysses!harpo!decvax!ucbvax!fair
From: fair@ucbvax.UUCP (Erik E. Fair)
Reply-To: fair@Berkeley.ARPA (Erik E. Fair)
Subject: Re: my note on MCI mail
Message-ID: <110@ucbvax.UUCP>
Date: Sun, 19-Feb-84 23:48:16 EST
References: <840218222344.582791@MIT-MULTICS.ARPA>
In-Reply-To: <840218222344.582791@MIT-MULTICS.ARPA>
Organization: U.C. Berkeley

This is a refutation to the notion that UUCP/USENET will collapse,
contained in the conclusion of the referenced news article. In brief:

1. Assume that all UUCP/USENET sites must do computation that is useful
	to the owners of said site, in addition to the UUCP/USENET
	traffic that they carry.

2. Given 1., when traffic increases to a point where the `useful' work
	is not being done, excess traffic will be offloaded or cut off
	by the owners of the site.

3. Given 2., how & when does UUCP/USENET collapse?

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



Date: 27 Feb 1984 18:23:29-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP
Path: hou3c!burl!ulysses!mhuxl!ihnp4!harpo!idi!ios!qubix!sun!decwrl!decvax!ucbvax!fair
From: fair@ucbvax.UUCP
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <163@ucbvax.UUCP>
Date: Sat, 25-Feb-84 16:26:05 EST
Received: by hou3c.UUCP;  Sun, 26-Feb-84 05:31:20 EST
References: <450@sun.uucp>
In-Reply-To: <450@sun.uucp>
Organization: U.C. Berkeley


Uh, I have a small nit to pick with John Gilmore. The example he used
for showing the proper interpretation of `correct' mail headers from
the UUCP land was wrong:

>>For mail which has been passed solely thru uucp sites, the "From " line
>>is clearly correct, since the "From:" line has not been maintained at
>>(all) intermediate sites.  E.g.:
>>	From dual!allegra!cbosgd!fair Thu Feb 23 17:01:34 1984
>>	From: dual!cbosgd!fair
>>
>>The win would have been to make the envelope right for all uucp
>>traffic, (which it already was for strictly-uucp traffic) and have
>>sendmail fix the From: line to match the "From " line.  This has not
>>been done -- yet.  Is there a uucp/mail expert in the house who can tell
>>us WHY the envelope is "uucp" or some user, instead of the right thing?

I have been many things in my time, but never have I been cbosgd!fair.
I'm dual!fair or ucbvax!fair or fair@ucb-arpa.ARPA. The problem is that
some 4.2 BSD sites out there are running bogus versions of sendmail which
puts out the return address in the envelope in domain format. It gets
worse when the letter passes through a working sendmail sites, because
they try and undo the damage, and only succeed in hiding it. That letter
there started life

	From dual!fair

cbosgd changed that to

	From cbosgd!fair@dual.UUCP

and allegra changed that to 

	From dual!allegra!cbosgd!fair

It gets really fun when someone tries to reply to that. This bug
has been fixed by steve@nbires.UUCP, tjt@masscomp.UUCP,
postmaster@uwisc-rsch.ARPA, and eric@BERKELEY.ARPA
Some by my prodding them, some not.

If you spot one of these, complain until it gets fixed, because
all mail passing through the suspect site will have bogus return
addreses, and only the silly people who keep the entire routing map in
their heads (like me) will be able to get anything through the Emails.
(Mark Horton, are you listening? Do I have to beat this to death?)

	Please, Help Stamp Out Sendmail Errors by sending your
	tax deductible contributions to 

		Save the Network
		Box 10.2.0.78
		Berkeley, California 94720

Thank you.

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

P.S.	For those on USENET: 10.2.0.78 is ucbvax's ARPANET address. :-)



Date: 27 Feb 1984 21:53:09-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: hou3c!burl!ulysses!harpo!decvax!genrad!grkermit!masscomp!kobold!tjt
From: tjt@kobold.UUCP
Reply-To: eagle!masscomp!kobold!tjt%mit-vax@mit-mc (hopefully works)
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <277@kobold.UUCP>
Date: Mon, 27-Feb-84 00:46:45 EST
Received: by hou3c.UUCP; Mon, 27-Feb-84 15:47:46 EST
References: <450@sun.uucp> <163@ucbvax.UUCP>
In-Reply-To: <163@ucbvax.UUCP>
Organization: Masscomp, Westford, MA

For anyone who is interested:

I fixed the sendmail bug described by Erik Fair (sending out domain
based address in the unix-style "From " line) by switching from the
4.1c version of sendmail to the 4.2 version.  Looking at the Version.c
file indicated that this was explicitly fixed and is not an artifact of
an aberrant configuration file.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax}!masscomp!tjt   (617) 692-6200 x275



Sender: Hamilton.ES@PARC-MAXC.ARPA
Date: 27 Feb 84 20:05:41 PST (Monday)
Subject: Bogus "Arpanet hosts"
To: Header-People@mit-mc.ARPA
cc: Hamilton.ES@PARC-MAXC.ARPA
From: Bruce Hamilton <Hamilton.ES@PARC-MAXC.ARPA>
Reply-To: Hamilton.ES@PARC-MAXC.ARPA

It seems like every few days lately I try to reply to somebody, and the
address on their "From" or "Reply-To" is phony.  Maybe we have no right
to expect usable return addresses from Usenet and CSNet (although I
would contest even that premise), but certainly places like Columbia and
CMU (to name two places where this has happened to me) ought to be able
to munge any headers they fling out onto the Arpanet to reflect a valid
Arpanet address, and NOT some bogus internal network address.  Xerox's
Grapevine software is very clever this way, so that insiders don't have
to wade through @PARC-MAXC.ARPA, but outsiders do.

Below is an example of the sort of thing I'm talking about:

--Bruce

----------------------------------------------------------------
The message sent by Hamilton.ES at 27-Feb-84 14:53:47 PST could not be
delivered to the following recipients because they were rejected by the
MTP server "Maxc".  The reason given was: Sorry, I never heard of an
ARPA domain named "cmu-psy-a"

shrager@cmu-psy-a.ARPA

Original msg header being replied to:

Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 27 FEB 84 13:50:19 PST
Return-path: <@SUMEX-AIM.ARPA:shrager@cmu-psy-a>
Redistributed: Xerox1100UsersGroup^.PA
Received: from CMU-CS-PT by SUMEX-AIM.ARPA with TCP; Mon 27 Feb 84
13:26:07-PST
Received: from CMU-PSY-A by CMU-CS-PT with CMUFTP; 27 Feb 84 16:20:59
EST
Date: Mon, 27 Feb 84 16:15:52 EST
From: shrager@cmu-psy-a.ARPA
Subject:  Touch Screen
To: 1100users@sumex.ARPA

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

Date: 27 Feb 1984 23:18:51-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP
Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm
From: gjm@ihnp4.UUCP (Gary J. Murakami)
Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami)
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <555@ihnp4.UUCP>
Date: Mon, 27-Feb-84 20:24:48 EST
Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST
References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP>
In-Reply-To: <277@kobold.UUCP>
Organization: AT&T Bell Labs, Naperville, IL

Last time I looked at cbosgd's config file, my analysis agreed with Erik
Fair's analysis of the situation.  Empirical evidence seems to point out
that the path reversal problem still exists at more than one host.  Part
of the problem stems from the inconsistent treatment of a!b@c. 
Unfortunately the 4.2 distribution contains config files that do a
considerable amount of header munging, and more hacking will probably
make matters worse.

Sendmail is still a mixed blessing, however some of us hope to
eventually fix the (few) cursed parts.

Gary Murakami
AT&T Bell Laboratories
ihnp4!gjm



Date: Mon, 27 Feb 84 23:26:56 EST
From: Daniel Long <long@BBN-UNIX>
Subject: Re: Bogus "Arpanet hosts"
In-Reply-To: Your message of 27 Feb 84 20:05:41 PST (Monday)
To: Hamilton.ES@PARC-MAXC.ARPA
Cc: Header-People@mit-mc, long@BBN-UNIX

Bruce,

    You have every right to expect usable return addresses from CSNET.
If you can find any examples of un-replyable CSNET messages, we would
be very interested in seeing the headers so we can correct the
problem.

CSNET problems/inquiries may be directed to CIC@CSNET-SH.

Thanks,
Dan Long
Technical Liaison
CSNET Coordination and Information Center

Date: Mon 27 Feb 84 21:22:48-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Bogus "Arpanet hosts"
To: Hamilton.ES@PARC-MAXC.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Bruce Hamilton <Hamilton.ES@PARC-MAXC.ARPA>" of Mon 27 Feb 84 20:05:41-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Bruce -

     The TOPS-20 mailer, by deliberate design, does not perform any
relay services beyond that of a bridge.  CMU and Columbia both run
this software (although your example involved CMU-CS-PT, a Unix
system).  Unlike the UUCP world, I consider store-and-forward relaying
and relative addressing to be temporary measures pending the adoption
of a universal standard for electronic mail addressing.  It's too bad
that so many people confuse "where" the person is with the "way to get
there."

     I also have substantial reservations about the entire philsophy
of header-munging.  All too often I have seen my message headers
transmogrified into invalid headers by a well-meaning, but incorrect,
header modifier.  Several delivery problems, especially in the early
days of SMTP, proved to be undebuggable because a header modifier
succeeded in destroying the information needed to figure out what
happened.  Worse is the habit of MMDF and certain other header modifiers
to make a message header "cute" by applying certain rules of case
modification; I'm really tired of seeing crap such as "Mit-Xx", "Su-Ai",
or - the worst insult of all - "Mrc".

     I feel that a host using the services of a bridge should be willing
to generate a message header that is valid at the other side of the
bridge.  It isn't difficult to do, especially if both sides of the bridge
are willing to recognize Internet addresses.

-- Mark --
-------

Date:  Tue, 28 Feb 84 10:38 EST
From:  Steven Schwartz <SSchwartz@MIT-MULTICS.ARPA>
Subject:  Diseased mail headers
To:  <@MIT-MC.ARPA:eagle!hou3c!ka@MIT-VAX>, postmaster@MIT-MC.ARPA, 
     <@MIT-MC.ARPA:postmaster@MIT-VAX>, gjm%ihnp4.UUCP@UCB-VAX.ARPA
cc:  header-people@MIT-MC.ARPA
In-Reply-To:  Message of 28 Feb 84 00:56 EST from "Network_Server.Daemon (eagle!hou3c!ka@MIT-VAX@MIT-MC)"
Message-ID:  <840228153852.194555@MIT-MULTICS.ARPA>

I have lately been receiving mail with headers like the following:

    Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:eagle!hou3c!ka@MIT-VAX>
    Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Feb-1984 00:56:12-est
    Date: 27 Feb 1984 23:18:51-EST
    From: eagle!hou3c!ka at mit-vax
    To: Header-People@MIT-MC.ARPA
    Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP
    Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm
    From: gjm@ihnp4.UUCP (Gary J. Murakami)
    Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami)
    Subject: Re: "From " vs. "From:" in Sendmail
    Message-ID: <555@ihnp4.UUCP>
    Date: Mon, 27-Feb-84 20:24:48 EST
    Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST
    References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP>
    In-Reply-To: <277@kobold.UUCP>
    Organization: AT&T Bell Labs, Naperville, IL

Somewhere along the line, someone's mail server is adding a second From:
field.  I'm certain it isn't the fault of the message sender(s?), but I
have little idea of why this message is traveling between Berkeley (an
ARPA site) and MIT-MC (also ARPA) via MIT-VAX.  Anyone have any clues?

                              Steve Schwartz
                              SSchwartz at MIT-Multics

Date:     Tue, 28 Feb 84 7:46:23 EST
From:     G B Reilly <reilly@udel-relay.arpa>
To:       Mark Crispin <MRC@su-score.arpa>
cc:       Header-People@mit-mc.arpa
Subject:  Re:  Bogus "Arpanet hosts"

MMDF does generate a header that is readable on both sides of
a bridge.

As for CSNet, for example, all messages that travel from a CSNet host
to the ARPA have their addresses modified so that they end with
"@CSNET-RELAY.ARPA".  Hence, according to the RFC 822 standard, those
messages can be replied to.


Brendan Reilly

Date: 28 Feb 1984 18:22:55-EST
From: eagle!hou3c!ka at mit-vax
To: SSchwartz@MIT-MULTICS.ARPA, postmaster@MIT-MC.ARPA, postmaster@mit-vax, gjm@ihnp4.UUCP@UCB-VAX.ARPA
Cc: header-people@MIT-MC.ARPA
In-Reply-To: <840228153852.194555@MIT-MULTICS.ARPA>
Subject: Re: Diseased mail headers

The message originated on the USENET and was forwarded to the mailing
list, which explains the route.  The extra "From:" line is a gift of
the code on mit-vax to convert from UUCP mail to RFC 822 mail.  The
first "From:" lines should really be a "Sender:" line.  Eventually
Berkeley will take over the gateway since they have direct access to
the ARPANET.
				Kenneth Almquist
				ka@hou3c.UUCP
				ealge!hou3c!ka@mit-vax
				ihnp4!hou3c!ka@Berkeley
				harpo!hou3c!ka@seismo


P.S.  If people on this list prefer not to see the stuff from USENET,
I can stop gatewaying it.  I can also (to a limited extent) weed out
specific topics if that is desired.



Date: 28 Feb 1984 18:23:11-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: hou3c!burl!ulysses!harpo!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <5472@umcp-cs.UUCP>
Date: Sun, 26-Feb-84 19:53:12 EST
Received: by hou3c.UUCP; Tue, 28-Feb-84 16:53:17 EST
References: <5638.31.445827921@ucbarpa> <450@sun.uucp>
In-Reply-To: <450@sun.uucp>
Organization: Univ. of Maryland, Computer Science Dept.

Well, on our system the uucp "envelope" info is usually wrong
because uux uses getpwuid(getuid())->pw_name, but it is invoked
on behalf of the fake user "mmdf" when MMDF dequeues UUCP channel
mail.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay



Date: 28 Feb 1984 18:23:18-EST
From: eagle!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Path: hou3c!burl!ulysses!allegra!alice!research!dmr
From: dmr@research.UUCP
Subject: addressing follies
Message-ID: <1023@research.UUCP>
Date: Tue, 28-Feb-84 02:41:37 EST
Received: by hou3c.UUCP; Tue, 28-Feb-84 05:00:29 EST

Here, for your enjoyment, is the first line of the last 12 uucp letters
received by research from ucbvax.  I'm especially fond of the
first one.  Too bad it doesn't have a % to make it perfect.

	From @Ucl-Cs.ARPA:@Caga.AC.UK:@Ucl-Cs.ARPA:lcp@Camsteve.AC.UK
	From @SU-SCORE.ARPA:@SU-AI:MACKAY@WASHINGTON
	From @SU-SCORE.ARPA:@SU-AI:greep@SU-DSN
	From @SU-SCORE.ARPA:@SU-AI:phil@RICE
	From @SU-SCORE.ARPA:@SU-AI:sdcarl!rusty@Berkeley
	From @SU-SCORE.ARPA:DRF@SU-AI
	From @SU-SCORE.ARPA:gwyn@brl-vld
	From @SU-SCORE.ARPA:phil@RICE
	From Ellis@YALE.ARPA
	From fateman@ucbdali.Berkeley.ARPA
	From kahn@UCLA-CS.ARPA
	From lbl-csam!FURUTA@WASHINGTON.ARPA



Date: Tue 28 Feb 84 16:33:44-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: addressing follies
To: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "eagle!hou3c!ka at mit-vax" of Tue 28 Feb 84 15:23:18-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Some of those addresses are perfectly valid, in particular:
	@SU-SCORE.ARPA:DRF@SU-AI
	@SU-SCORE.ARPA:gwyn@brl-vld
	@SU-SCORE.ARPA:phil@RICE
	Ellis@YALE.ARPA
	kahn@UCLA-CS.ARPA


     The following addresses are bogus because ":" is used in the
source path multiple times.  Score's software has always done the
right thing in the past; unless there was a bug suddently
introduced I believe that somebody in the mail chain after Score
(probably some Unix someplace) bogotified it.
	@SU-SCORE.ARPA:@SU-AI:MACKAY@WASHINGTON
	@SU-SCORE.ARPA:@SU-AI:greep@SU-DSN
	@SU-SCORE.ARPA:@SU-AI:phil@RICE
	@SU-SCORE.ARPA:@SU-AI:sdcarl!rusty@Berkeley
		      ^-- these addresses would be valid if this
			  colon was a comma instead.

     The following address is bogus because "Caga.AC.UK" and
"Camsteve.AC.UK" are not valid in the Internet domain yet.  Note
that the excessive colons appear here as well, bolstering my
contention that somebody is incorrectly converting commas to
colons at the Internet/UUCP bridge.
	@Ucl-Cs.ARPA:@Caga.AC.UK:@Ucl-Cs.ARPA:lcp@Camsteve.AC.UK

     The following address is bogus because "ucbdali.Berkeley.ARPA"
is not valid in the Internet domain yet.
	fateman@ucbdali.Berkeley.ARPA

     The following address is bogus in the Internet world due to
the presence of UUCP syntax.  WASHINGTON.ARPA is a TOPS-20 site
and does not use UUCP syntax.  Somebody obviously thought it
does, probably in the UUCP world.
	lbl-csam!FURUTA@WASHINGTON.ARPA
-------

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
	id AA22845; Tue, 28 Feb 84 10:52:27 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14/4.14.2) id AA00386; Tue, 28 Feb 84 10:52:37 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.13.2) id AA01592; Tue, 28 Feb 84 10:25:51 pst
Date: Tue, 28 Feb 84 10:25:51 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8402281825.AA01592@ucbopal.CC.Berkeley.ARPA>
To: SSchwartz@MIT-MULTICS.ARPA
Subject: Re:  Diseased mail headers
Cc: ihnp4!gjm@Berkeley, header-people@MIT-MC.ARPA, cbosgd!mark@Berkeley,
        postmaster@MIT-MC.ARPA, postmaster@MIT-VAX.ARPA, postmaster@Berkeley

In reply to:

	Date:  Tue, 28 Feb 84 10:38 EST
	From: Steven Schwartz <SSchwartz@MIT-MULTICS.ARPA>
	Subject:  Diseased mail headers
	To: <@MIT-MC.ARPA:eagle!hou3c!ka@MIT-VAX>, postmaster@MIT-MC.ARPA,
	        <@MIT-MC.ARPA:postmaster@MIT-VAX>, gjm@ihnp4.UUCP
	Cc: header-people@MIT-MC.ARPA
	In-Reply-To:  Message of 28 Feb 84 00:56 EST from
		"Network_Server.Daemon (eagle!hou3c!ka@MIT-VAX@MIT-MC)"
	Message-Id:  <840228153852.194555@MIT-MULTICS.ARPA>

	I have lately been receiving mail with headers like the following:

	    Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:eagle!hou3c!ka@MIT-VAX>
	    Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Feb-1984 00:56:12-est
	    Date: 27 Feb 1984 23:18:51-EST
	    From: eagle!hou3c!ka at mit-vax
	    To: Header-People@MIT-MC.ARPA
	    Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP
	    Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm
	    From: gjm@ihnp4.UUCP (Gary J. Murakami)
	    Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami)
	    Subject: Re: "From " vs. "From:" in Sendmail
	    Message-ID: <555@ihnp4.UUCP>
	    Date: Mon, 27-Feb-84 20:24:48 EST
	    Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST
	    References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP>
	    In-Reply-To: <277@kobold.UUCP>
	    Organization: AT&T Bell Labs, Naperville, IL

	Somewhere along the line, someone's mail server is adding a
	second From:  field.  I'm certain it isn't the fault of the
	message sender(s?), but I have little idea of why this message
	is traveling between Berkeley (an ARPA site) and MIT-MC (also
	ARPA) via MIT-VAX.  Anyone have any clues?

	                              Steve Schwartz
	                              SSchwartz at MIT-Multics

------

It looks like a USENET news article was introduced directly into
the mail system at MIT-VAX without a mail header or without a null
line (end of header indicator) between the mail header and the news
article header. Or somewhere along the mail relay path, the null line
between the mail header and news article header was lost.

The following headings in the message above appear to be 
USENET news article header fields (some of which have be modified
in the mail system):


	    Date: 27 Feb 1984 23:18:51-EST
	    Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP
	    Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm
	    From: gjm@ihnp4.UUCP (Gary J. Murakami)
	    Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami)
	    Subject: Re: "From " vs. "From:" in Sendmail
	    Message-ID: <555@ihnp4.UUCP>
	    Date: Mon, 27-Feb-84 20:24:48 EST
	    Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST
	    References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP>
	    In-Reply-To: <277@kobold.UUCP>
	    Organization: AT&T Bell Labs, Naperville, IL

The "Reply-To:" with the "@Berkeley" was probably added by MIT-VAX.
The message did not go through Berkeley. (sendmail on UCBVAX generates
full domain names, eg. @Berkeley.ARPA, and Received fields)

Bill Wells, Computing Services, U.C. Berkeley
wcwells@Berkeley.ARPA or ucbvax!wcwells


Date:	  Tue, 28 Feb 84 23:30:00 EST
From:	  Doug Kingston <dpk@brl-vgr.arpa>
To:	  Header-People@MIT-MC
Reply-To: DPK@BRL-VGR, Reilly@UDEL-RELAY, Steve@UCL-CS
Subject:  User selectable mailboxes

	We have decided that we would like to add a facility to
the MMDF local channel, to allow users to have mail delivered
to a file other than there regular mailbox simply by having
the mail addressed with a slightly different "mailid".  We already
have the facility for have mail delivered to arbitrary files and
processes, but due to the security implications, this kind of delivery
is under the control of the system management.  This new facility
should be one that can be invoked by the user without bothering the
management.  It must also be sufficiently restricted that outside
users cannot create random files or destroy same.

	Our strawman proposal for implementing this facility calls
for they following syntax to be recognized:

	"user"	     deliver to user's regular mailbox (/disk/user/mailbox)
	"user=h-p"   deliver to alternate mailbox hp (/disk/user/mailbox=h-p)

We chose "=" as the magic character to trigger this, since it did not
appear to have any magic properties anywhere else we could think of.
Can anyone think of any problems this would cause, and if so, what
suggestions do you have for altering the syntax to be more useable?
We are not wedded to = or even the precise syntax used here.  We would
be interested in hearing what other systems may have implemented such
a facility and what syntax they have used.

					Fighting the 150 message a day habit,
							-Doug-

Date: Wed, 29 Feb 84 07:06 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: User selectable mailboxes
To: DPK@BRL-VGR.ARPA, Reilly@UDEL-RELAY.ARPA, Steve@UCL-CS.ARPA
Cc: Header-People@MIT-MC.ARPA
In-reply-to: The message of 28 Feb 84 23:30-EST from Doug Kingston <dpk at BRL-VGR>

I don't understand.  This seems to be purely an internal
issue between your system management and the users you
want to restrict to creating mailboxes with only certain
names.  Any system I've had much truck with has always
let people create mailboxes under any name whatsoever.
Why do we need a convention for the sake of sites that
want to be restrictive?

Anyone sending to this user's special mailbox has to
know the name of the special-purpose mailbox anyway,
and agree to use that name.  Presumably he has to be
told anyway.  People do this all the time with mass-mailing
lists, with names like SMITH-JUNK, etc.

Date: Wed, 29 Feb 84 07:06 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: User selectable mailboxes
To: DPK@BRL-VGR.ARPA, Reilly@UDEL-RELAY.ARPA, Steve@UCL-CS.ARPA
Cc: Header-People@MIT-MC.ARPA
In-reply-to: The message of 28 Feb 84 23:30-EST from Doug Kingston <dpk at BRL-VGR>

I don't understand.  This seems to be purely an internal
issue between your system management and the users you
want to restrict to creating mailboxes with only certain
names.  Any system I've had much truck with has always
let people create mailboxes under any name whatsoever.
Why do we need a convention for the sake of sites that
want to be restrictive?

Anyone sending to this user's special mailbox has to
know the name of the special-purpose mailbox anyway,
and agree to use that name.  Presumably he has to be
told anyway.  People do this all the time with mass-mailing
lists, with names like SMITH-JUNK, etc.

Date: Wednesday, 29 Feb 1984 09:01-PST
To: DPK@BRL-VGR, Reilly@UDEL-RELAY, Steve@UCL-CS
Cc: Header-People@MIT-MC
Subject: Re:  User selectable mailboxes
In-reply-to: Your message of Tue, 28 Feb 84 23:30:00 EST.
From: greep@SU-DSN

I modified the delivery part of Rand MH to do something similar, although
I used "." instead of "=", e.g. "greep.foomail" means user greep, mailbox
foomail.  What then happens is that if the recipient has specified his own
program to handle his incoming mail (this was already part of MH), one of
the arguments that is passed to that program is the mailbox, in this case
"foomail".  The program can do whatever it wants with the message.  If the
address consists of a user name with no mailbox, then the argument defaults
to "inbox".  If the user does not have his own program to handle incoming
mail, then the part after the period is ignored and the mail all goes in
one place.

This is how we handle bboards.  For example, "dsn-WorkS" is aliased to
"news.works".  There is a fake user called "news" which has a shell file
to handle incoming mail.  The shell program makes sure that the mailbox
specified exists and then puts the message in it.  If the mailbox isn't
valid, the program returns a non-zero return code which tells the mailer
to notify the sender of the error by sending back a message, which will
include any error messages that were output by the program.

Date:  1 Mar 1984 12:55:00 PST
From: POSTEL@USC-ISIF
Subject: dead hosts ?
To:   header-people@MIT-MC


I recently sent out an RFC announcement to a long mailing list, and as
expected received numerous messages from various mailers daemons about
things that did not work.  The largest group of these messages were
from the mailer on my home system complaining that a few destination
hosts were down every time it tried to deliver the mail for three
days.  The people who have mailboxes on these hosts might consider moving
to more reliable hosts.  This time the hosts in question were: MIT-ML,
SRI-UNIX, AMES-TSS, and LL.

--jon.
-------

Date:  1 March 1984 13:37 pst
From:  Bakin.SSID at HI-MULTICS
Subject:  RESENT field :)
To:  HEADER-PEOPLE at MIT-MC
Acknowledge-To:  Bakin.SSID at HI-MULTICS

I recently received a message with two fields I had never seen before:

RESENT-(FROM TO)

I took offense at the person listed as resent from, I don't know him,
why should he resent me!  I was pleased that the mailer told me that guy
resents me, I'll never send him mail again, but how did the mailer
figure it out?

YES, it was me he resents, because I was listed as the RESENT-TO!  But
this jerk also resents an entire mailing list, because they were in
there too.

Does some RFC exist specifying fields such as this?  Is there a

FLAMING-DEATH-TO field?  or maybe a

VOTE-FOR field?

I was aware of such fields as SENDER:, FROM:, and I had thought
something like Redistributed-By, and maybe Redistributed-To:, but I
really think we should leave such personal fields as RESENTMENT out
headers entirely!

Jerry.

P.S. Maybe this should be RE-SENT-(FROM TO)?

Received: by YALE-BULLDOG via CHAOS; Thu, 1 Mar 84 17:38:59 EST
Date:    Thu, 1 Mar 84 17:34:59 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: RESENT field :)
To:      Bakin.SSID@HI-MULTICS.ARPA
Cc:      HEADER-PEOPLE@MIT-MC.ARPA
In-Reply-To: Bakin.SSID at HI-MULTICS, 1 March 1984 13:37 pst

    RESENT-(FROM TO)
    ...
    Does some RFC exist specifying fields such as this?

Read RFC 822.

    P.S. Maybe this should be RE-SENT-(FROM TO)?

My Random House College Dictionary (1975), admittedly not the best
dictionary, has the following definition for "resend":

    resend, ... resent, resending.  1. to send again.  2. to send back.

So "Resent-From"  is hyphenated correctly.
-------

Date: 1 Mar 1984 22:06:04-EST
From: allegra!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: hou3c!burl!ulysses!harpo!decvax!genrad!grkermit!masscomp!kobold!tjt
From: tjt@kobold.UUCP
Reply-To: ucbcad!masscomp!kobold!tjt@Berkeley.ARPA (hopefully)
Subject: Re: "From " vs. "From:" in Sendmail
Message-ID: <279@kobold.UUCP>
Date: Wed, 29-Feb-84 09:13:57 EST
Received: by hou3c.UUCP; Thu, 1-Mar-84 02:49:46 EST
References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> <555@ihnp4.UUCP>
In-Reply-To: <555@ihnp4.UUCP>
Organization: Masscomp, Westford, MA

Although I missed Rob Pike's "cat -v considered harmful" talk at the
Toronto USENIX conference, I understood he mentioned that the current
trend in arcane command switches would no double lead to an extension
language for cat. It occurred to me the other day after wrestling with
configuration files that sendmail must be the aforementioned extension
language (where is TECO now that we need you?).

-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax}!masscomp!tjt   (617) 692-6200 x275



Date: 1 Mar 1984 22:06:12-EST
From: allegra!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 5/3/83; site ukc.UUCP
Path: hou3c!burl!ulysses!harpo!seismo!hao!hplabs!zehntel!tektronix!uw-beaver!cornell!vax135!ukc!mjb
From: mjb@ukc.UUCP (M.J.Bayliss)
Subject: Re: Strange From headers
Message-ID: <4097@ukc.UUCP>
Date: Thu, 16-Feb-84 06:45:03 EST
Received: by hou3c.UUCP; Thu, 1-Mar-84 18:58:40 EST
References: <215@heurikon.UUCP>
In-Reply-To: <215@heurikon.UUCP>
Organization: Computing Lab. Kent University, England

This is a sendmail problem and it's not just restricted to the sites named
in the original article (ukc also generates the same problem).

What happens (as far as i can work out) is:

	sendmail generates an UGLYUUCP from line

	to find the sitename to put in the "remote from...." it
	takes the first component of the $g macro

	but... $g is not always correct!

Sites that cause this problem are not adding their own sitename onto
the sender's address at the right place. I've spent two days examining
trace output from sendmail and as far as i can tell $g is continually
reset as the sender address is modified (rulesets 3, 1, 4 and the uucp
mailer sender ruleset). This should be an easy bug to fix but...

When I wrote my sendmail.cf I found I had to use the uucp ruleset to
put "ukc!" on the front of the sender's name, if I didn't sendmail complained
because there was no "!" in the sender. Following the same logic I should
just need to put "ukc!" at the start of every sender's name that goes through
the uucp ruleset. However, this doesn't work and $g does not include the
"ukc!", but does contain the full uucp route upto and including the
sender's site.

I suspect it's because we're all trying to be too clever, and getting
carried away converting everything in sight into "user@site.net" triples.

Are there any sendmail experts out there? Is Eric Allman reading this?
I for one would appreciate help just to stop sites adjacent to me complaining.

	mike bayliss	University of Kent.
		...!{vax135,mcvax}!ukc!mjb

P.S. no flames telling me I should use standard configuration files,
I'm trying to cope with a local network of 8 systems (2 different mail
protocols) and two wide area networks (2 different mail protocols and 2
different naming conventions).



Date: 1 Mar 1984 22:06:21-EST
From: allegra!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: hou3c!burl!ulysses!mhuxl!ihnp4!dual!fair
From: fair@dual.UUCP (Erik E. Fair)
Subject: Re: addressing follies
Message-ID: <320@dual.UUCP>
Date: Wed, 7-Mar-84 02:40:18 EST
Received: by hou3c.UUCP; Thu, 1-Mar-84 18:52:45 EST
References: <1023@research.UUCP>
In-Reply-To: <1023@research.UUCP>
Organization: Dual Systems, Berkeley, CA

If anyone is curious for a translation of those mysterious address, you
may inquire at one of the addresses below:

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

	dual!fair@BERKELEY.ARPA
	{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
	Dual Systems Corporation, Berkeley, California



Date: Fri, 2 Mar 84 00:43 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: RESENT field :-<:)
To: Bakin.SSID@HI-MULTICS.ARPA
Cc: HEADER-PEOPLE@MIT-MC.ARPA
In-reply-to: The message of 1 Mar 84 16:37-EST from Bakin.SSID at HI-MULTICS

    Date:  1 March 1984 13:37 pst
    From:  Bakin.SSID at HI-MULTICS

    Does some RFC exist specifying fields such as this?  Is there a

    FLAMING-DEATH-TO field?  or maybe a

    VOTE-FOR field?

Yeah, RFC822, I believe.  You're no longer allowed to REDISTRIBUTE mail,
and this has caused a notable increase in user RESENTment.  It also
subjects us to a lot of chatter between mailers about who got what from
whom and other interbeing private topics that really shouldn't be told
in public.  I've taken to censoring my headers!

If you don't wish to cause RESENTment, you can always be straight FORWARD!
Unfortunately, the response does not always go as you'd like.

Date:  2 Mar 84 1144 EST
From: Rudy.Nedved@CMU-CS-A
To: POSTEL@USC-ISIF
Subject: Re: dead hosts ?
CC: header-people@MIT-MC
In-Reply-To: "POSTEL@USC-ISIF's message of 1 Mar 84 15:55-EST"
Message-Id: <02Mar84.114453.EN0C@CMU-CS-A>

SRI-Unix seems to be answering for SRI-SPRM for some reason. I have sent
there system (by hand) mail about the problem per our users complaints
(since we have users getting mail from them...) and we have a policy
now of depending on NIC to have the correct information about hosts.

-Rudy

Date: 2 Mar 1984 10:08-EST
Sender: MOOERS@BBNA
Subject: Re:  RESENT field :)
From: MOOERS@BBNA
To: Bakin.SSID@HI-MULTICS
Cc: HEADER-PEOPLE@MIT-MC
Cc: Mooers@BBNA
Message-ID: <[BBNA] 2-Mar-84 10:08:58.MOOERS>
In-Reply-To: The message of  1 March 1984 13:37 pst from  Bakin.SSID at HI-MULTICS

I agree completely that "RESENT" is an unfortunate choice.  I was told
that Dave Crocker thought it was cute.  At the time that RFC822 was 
written, HERMES and MSG used "REDISTRIBUTED" and MM used "REMAILED".
I don't know that anyone was using "RESENT".  HERMES spells the fields
"ReSent".  What else can you do?

---Charlotte

Date: 2 Mar 1984 10:52-PST
Sender: BILLW@SRI-KL
Subject: Re: dead hosts ?
From: BILLW@SRI-KL
To: Rudy.Nedved@CMU-CS-A
Cc: POSTEL@USC-ISIF, header-people@MIT-MC
Message-ID: <[SRI-KL] 2-Mar-84 10:52:56.BILLW>
In-Reply-To: <02Mar84.114453.EN0C@CMU-CS-A>

SRI-UNIX's Imp port is broken, and it is temporaryilly
using the port assigned to sprm.  We hope the change is
not long-lived enough to announce to any but the most
prolific of those sending mail to SRI-UNIX.  Since
they are the primary gateway from usenet, its nic to
have them up somewahere...

BillW, Postmaster, SRI

Date: 2 Mar 1984 18:58:04-EST
From: allegra!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site vax135.UUCP
Path: hou3c!hocda!houxm!vax135!martin
From: martin@vax135.UUCP (Martin Levy)
Subject: .ARPA hard coded into sendmail/src/daemon.c
Message-ID: <638@vax135.UUCP>
Date: Thu, 1-Mar-84 20:14:07 EST
Received: by hou3c.UUCP; Thu, 1-Mar-84 22:00:34 EST
Organization: AT&T Bell Labs, Holmdel, NJ

when using sendmail around a local ethernet and or thru any other media
where sendmail (in daemon mode) get's it's mail via sockets, it will set
up the Received header line like this:-

Received: from vax135.UUCP (vax135.ARPA) by marvin.UUCP (4.12/4.7)
	id AA03076; Thu, 1 Mar 84 19:58:24 est

now, we are not on the ARPANET, and hence the .ARPA is not correct. this
is very hard coded in, and only happens when the HELO argument (SMTP RFC???)
does not match gethostbyaddr() of the socket.
now, i pass vax135.UUCP over as the HELO arg, and the output of gethostaddr()
is "vax135", ok so whats up?, i think i should just send over "HELO vax135",
but the default sendmail scripts use vax135.UUCP.
a simple fix is to put .ether instead of .ARPA in the name, but that's even 
worse!!.
whats the correct fix while still leaving things 'configurable' by sendmail.cf?.

martin levy.



Date:  4 Mar 84 2143 EST
From: Rudy.Nedved@CMU-CS-A
To: Header-People@MIT-MC
Subject: smtp, errors and delivery
Message-Id: <04Mar84.214333.EN0C@CMU-CS-A>

A large number of sites seem to handle "mail from:" command errors by
issuing the command "mail from:<>" as the next command. Considering
that alot of mail is forwarded and that any mail with a null return
is "droppable" if an error occurs, I don't think this is a wise way
of handling "mail from" errors for the user will not get an error
message. The following is an example of this code:

220 CMU-CS-A.ARPA TOPS-10 SMTP server ready 1C(50)-2
HELO bazola
250 CMU-CS-A.ARPA
MAIL FROM:<frodo.baggins@bonzo_land>
500 malformed local host name 'bonzo_land', for line 'MAIL FROM:<frodo.baggins@bonzo_land>'.
MAIL FROM:<>
250 Mail okay.
RCPT TO:<Joe.Smoe@cmu-cs-a>
250 Rcpt okay.
DATA
354 Ready for mail.
250 Mail completed.
QUIT
221 CMU-CS-A.ARPA TOPS-10 SMTP service terminating

I can understand that the code was probably installed duringthe tcp
transition days when alot of smtp servers were still "buggy" but I
can not see a reason for it now. Is there some other reason or should
I send mail to sites that have this "old code" installed?

Thanks,
-Rudy

Date: Mon 5 Mar 84 01:09:03-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: smtp, errors and delivery
To: Rudy.Nedved@CMU-CS-A.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 4 Mar 84 21:43:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Rudy -

     The TOPS-20 SMTP sender (part of MMailr) is one of those SMTP
senders who will send a MAIL FROM: with a null argument if the SMTP
server rejects the command.  This is to maximize what chance the
message has of getting through.  I think that this is completely
within reasonable fault-tolerance procedures.

     I will resist any pressure to change it, until and unless CMU
is willing to undertake the responsibility of reliably delivering
any and all mail originating from any and all TOPS-20 systems on
the Internet.

-- Mark --
-------

Date:     Mon, 5 Mar 84 10:13:30 GMT
From:     Hsmith@ucl-cs.arpa
To:       msggroup@brl.arpa, header-people@mit-mc.arpa
Subject:  CBMS 84


			 International Federation
			for Information Processing
				 IFIP WG 6.5

		    International Working Conference on

		      COMPUTER-BASED MESSAGE SERVICES

				Nottingham, UK
			        1-4th May 1984



			    Final Announcement





     Conference Sessions include:

	  Message Architecture & Multimedia Systems
	  Naming/Addressing and Directory Services
	  User Interface Architecture
	  Services and Cost/Benefit Issues
	  Regulatory and Security Considerations
	  Conference and Message System Interconnection
	  Message Server Implementations
	  Teletex Systems

	  Panel I   - International CBMS Standards Activities:Overview
	  Panel II  - International CBMS Standards Activities:
		      The Commercial View
	  Panel III - Intermediate Term Interconnection Strategies
	  Working Group Sessions




     The objective of this conference is to promote the interchange of
     information  and  discussion  about  national  and  international
     computer-based message services.  Because many service and inter-
     connection requirements remain to be established for these emerg-
     ing systems, the conference includes a  number  of  working  ses-
     sions.   Issues  to  be discussed in the working sessions include
     both technical and economic/political  aspects  of  message  ser-
     vices.

     The conference brings together 27 speakers from  eight  countries
     to  present  papers  on computer-based messaging systems and ser-
     vices.  There are no parallel paper sessions in  order  to  allow
     delegates  to  attend  all  presentations.   In  addition  to the
     papers, three panels serve to  review  progress  and  issues  in;
     standards  activity,  commercial  developments,  and intermediate
     term interconnection requirements.  The final day and a  half  is
     devoted  to working sessions which will develop the issues raised
     by the panels and address a number of  application  topics.   The
     application  topics  will  include  multimedia systems, directory
     service  standards,  conferencing   system   requirements,   user
     environment services, and facilities for impaired communities.

     Venue

     The conference will be held in the Albany Hotel situated  in  the
     centre of  Nottingham, UK. The City is approximately two hours by
     train from London. Air Travellers arriving at Heathrow or Gatwick
     may  also  reach  the  city via a shuttle flight to East Midlands
     Airport. The City is some  twenty  minutes  taxi  ride  from  the
     airport.  Further  information  will  be  sent  with registration
     details.


     Registration

     The Conference registration fee is #90 (90 pounds UK sterling).
     This includes a  copy  of the proceedings, a conference dinner
     on May 2nd, and refreshments during the sessions.

     Address for Further Details:

	     CBMS '84
	     Human Computer Interaction Group
	     Nottingham University
	     Nottingham NG7 2RD
	     England

	     Arpa: hsmith@ucl-cs.isid
	     Telephone: (+44) 602 506101 Ext: 3587
	     Telex:  37346 UNINOT G


     Programme Committee

     G. Antoni, Italy             J. Palme, Sweden
     A. Danthine, Belgium         S. Ramani, India
     P. Kirstein, UK              P. Schicker, Switzerland
     J. Garcia-Luna, USA          K. Smaaland, Norway
     R. Miller, USA               L. Tarouco, Brazil
     N. Naffah, France            J. White, USA
     G. Neufeld, Canada           K. Wimmer, German Federal Republic


     Organising Committee


	     H.T. Smith, Nottingham University, UK
	     W. Dzida, GMD Bonn, German Federal Republic
	     R. Uhlig, Bell Northern Research, Canada



Date:  5 Mar 84 1116 EST
From: Rudy.Nedved@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: smtp, errors and delivery
CC: Header-People@MIT-MC
In-Reply-To: "Mark Crispin's message of 5 Mar 84 04:09-EST"
Message-Id: <05Mar84.111651.EN0C@CMU-CS-A>

Mark,

I didn't even know that TOPS-20 was in the crowd of people doing
this way of handling rejected "mail from" commands. It looks
like it is a defacto standard then since Unix, ITS and TOPS-20
do it.

I don't understand why people use this mechanism if they want
their users to have their mail delivered or get an error
message back. I consider the risk too high to take the
chance with using a null-return or no-return path....sigh.

Maybe it is the case that these same systems parse the headers
if they don't have a return-path and try to use the address??
If so the picture doesn't seem so bleak afterall.

Well back to work....I not going to bug anyone except for
people around CMU.

-Rudy

Date:  5 Mar 84 1250 EST (Monday)
From: don.provan@CMU-CS-A
To: Rudy.Nedved@CMU-CS-A
Subject: Re: smtp, errors and delivery
CC: Mark Crispin <MRC@SU-SCORE>, Header-People@MIT-MC
In-Reply-To: <05Mar84.111651.EN0C@CMU-CS-A>
Message-Id: <05Mar84.125014.DP0N@CMU-CS-A>

Rudy,
	Look at your example: your mailer is all set to reject the
mail altogether because it doesn't like "bonzo_land".  How can you
be upset about the remote mailer sending you a blank field?  Its
first priority is to get the mail delivered.  If you're going to
reject the only from address it has, what else can it do?  You aren't
going to return an error message there anyway.
	I don't really understand why mail receivers are parsing this
field so carefully, anyway.  I've had several sites i couldn't get mail
to because they tried to parse '"Provan Don%c"@LLL-MFE' and couldn't,
so they rejected the mail.  Its bad enbough that they can't parse
it, but to reject some mail because a field that shouldn't ever
get used can't be parsed is silly.  I wasn't smart enough to think
of sending an empty address if it wouldn't take my real address,
but now that it's been suggested, I think I'll add it.
	Frankly, I think the only legal error to a mail command
should be "too busy to send mail now."  I don't think it makes
sense to reject it because of a syntax error.

Date:           Mon, 5 Mar 84 11:16:36 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Re: "MAIL FROM:<>" in SMTP

Instead of using an empty "MAIL FROM:" address if the original return
path is rejected for some reason by the receiving site, I would suggest
trying a "Postmaster" address, as in the following scenario:

    220 FOO.ARPA SMTP Server ready
    HELO BLAH.ARPA
    250 FOO.ARPA
    MAIL FROM:<"Fred Flintstone"@BLAH.ARPA>
    501 Yecch! I don't like <"Fred Flintstone"@BLAH.ARPA>
    MAIL FROM:<Postmaster@BLAH.ARPA>
    250 OK
    . . .

This way, at least, the delivery-error message (if any) will go some-
where and can be dealt with by a (probably already overworked) wizard.

If, for some inscrutable reason, the receiving site rejects a "Postmas-
ter" return address, THEN go ahead and use an empty address.

Whenever a receiving site rejects a valid "MAIL FROM:" address and the
mailer has to resort to using "Postmaster", of course, the gurus at the
sending site should be notified in some way (e.g., by a note in a log
file).  This is doubly true in cases where a receiving site rejects a
"Postmaster" address -- something that should never, ever happen!

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

Date: Mon 5 Mar 84 13:23:51-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: smtp, errors and delivery
To: Rudy.Nedved@CMU-CS-A.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Mon 5 Mar 84 11:16:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Rudy -

     The problem is that it is a "de facto standard" to reject
MAIL FROM: commands for the slightest bogosity (even if the
bogon turns out to be at the SMTP server's end!).  A number of
SMTP servers reject a-d-l's, for example.  Still others reject
mail from "unknown hosts" when the problem is that the SMTP
server's host table is out of date.  Yet another problem is
that many (most?) SMTP servers reject bracketed host names.
There are a number of "nameless" TOPS-20s which talk TCP/IP
and use their bracketed address forms as a name (e.g. [1.2.3.4]).
This is valid according to the standard and TOPS-20 fully
implements it, but try convincing a large number of SMTP
servers of that!!

     I won't even go into the details of how to reply or return
messages in these cases (other than "implement the standard").

-- Mark --
-------

Date: Mon 5 Mar 84 13:30:58-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: smtp, errors and delivery
To: don.provan@CMU-CS-A.ARPA
cc: Rudy.Nedved@CMU-CS-A.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 5 Mar 84 12:50:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Don -

     I take the middle ground.  I think it is completely alright
to reject a MAIL FROM command because of a syntax error PROVIDED
that the syntax parser COMPLETELY implements the standard.  That
includes:
 . all forms of quoting
 . source path route lists
 . bracketed or #'d host addresses in lieu of host names

     Very few SMTP servers do.  I believe TOPS-20's SMTP server
does (if it doesn't, it's a bug because all the code is there).

     I don't think an SMTP server should try to validate a host
name in a MAIL FROM command other than checking it for syntactical
validity.  RCPT TO: is a different matter entirely.

-- Mark --
-------

Date: Mon, 5 Mar 84 17:07:15 cst
From: solomon@wisc-crys (Marvin Solomon)
Message-Id: <8403052307.AA04439@wisc-crys.ARPA>
Received: by wisc-crys.ARPA (4.22/3.7)
	id AA04439; Mon, 5 Mar 84 17:07:15 cst
To: Header-People@mit-mc.ARPA
Subject: Re: smtp, errors and delivery

I can't resist putting in my two bits.

An important principle in mail systems is the notion of
responsibility.  If we want reliable mail systems, then we should
design them so that throughout a message's lifetime, there is always
some module responsible for it.  When a server SMTP accepts a message,
it is taking responsibility for that message.  If for some reason it
can't deliver the message to the recipient, it has the responsibility
to return it to the sender.  If it has reason to believe that it is
being asked to accept a piece of mail that will be unreturnable, it has
every right (indeed duty) to reject it.  Otherwise, it may end up with
no alternative but to drop the message on the floor--the very worst thing
to do in any mail systems.

The old BBN SMTP server (used with many Berkeley 4.1 UNIX systems) got
a lot of flack (righly) for being too promiscuous in what it would accept;
it would take just about anything, and figure out later what to do about
it:

	MAIL FROM: !random@@garbage?
	250 Fine and dandy
	RCPT TO: >you got to be kidding>
	250 You betcha
	DATA
	blah blah blah
	.
	250 Yes sir boss!

I would much rather see mail bounce back to the sender if something
goes wrong, than to have it flush down a black hole.  If the server doesn't
like the MAIL FROM address, the sender should take the rejection gracefully,
and inform the sender that something is wrong.  The sender (if he is a
naive user) will yell at his mail system maintainer, who will see what's
wrong and fix it.  The idea of substituting "Postmaster" has a lot
to recommend it, but if that's rejected (perhaps because it's the host name,
not the local part, that's at issue), the sender shouldn't cram the mail
down the receiver's throat.  Null return addresses should only be used for
the error messages themselves.

If many (most?) SMTP servers are broken, they should be fixed, not coded
around by breaking the senders as well.

Date:  5 Mar 84 2058 EST (Monday)
From: don.provan@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: smtp, errors and delivery
CC: Header-People@mit-mc
In-Reply-To: "Mark Crispin's message of 5 Mar 84 16:30-EST"
Message-Id: <05Mar84.205835.DP0N@CMU-CS-A>

Mark,
	Why should you ever reject it because of a bogus Mail From field?
All you do by that is make sure the receiver doesn't get the mail.  Of all
the parties involved, the receiver is the one that can't possibly be at
fault, so why limit the sevice you provide him?  I agree that bells and
wistles should go off all over the place, but not at the expense of delivery.

Date:     Mon, 5 Mar 84 23:07:22 EST
From:     Doug Kingston <dpk@brl-vgr>
To:       don.provan@cmu-cs-a
cc:       Rudy.Nedved@cmu-cs-a, Mark Crispin <MRC@su-score>, Header-People@mit-mc
Subject:  Re:  smtp, errors and delivery

	There are two different philosophies being used here.  One says
"Deliver the message at all costs", while the other says "Make a reliable
deliver, or return it".  The first is the method used by people that
will give you a null return addresss (MAIL FROM:<>) while the second is
the more conservative stratagy and gives you a better guarantee that you
will know that the message was delivered (or not).  MMDF (the system I
maintain) is a more conservative mailer.  We rigorously adhere to the
transfer of responsibility model and we always give a return address
(even it is the postmaster address).  We do not attempt to supply alternate
MAIL FROM addresses, and as it turns out we now almost never get rejections
based on the MAIL FROM address.  This was not true when the net first
changed protocols though.

	Mark and others are not wrong in what they are doing, it just
shows a difference in priorities.

					Cheers,
						-Doug-

Date: 5 Mar 1984 18:49:54-EST
From: allegra!hou3c!ka at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site cornell.UUCP
Path: hou3c!hocda!houxm!ihnp4!harpo!ulysses!burl!clyde!floyd!vax135!cornell!bill
From: bill@cornell.UUCP (Bill Nesheim)
Subject: Re: .ARPA hard coded into sendmail/src/daemon.c
Message-ID: <6741@cornell.UUCP>
Date: Mon, 5-Mar-84 10:05:09 EST
Received: by hou3c.UUCP; Mon, 5-Mar-84 17:05:36 EST
References: <638@vax135.UUCP>
In-Reply-To: <638@vax135.UUCP>
Organization: Cornell Univ. CS Dept.

Wouldn't it be better to use the localnet name, instead of .ARPA or .ether?
We have several localnets here, and it sure would be nice to see
the localnet name put in where the .ARPA is hard coded now.

Opinions?

		-- Bill Nesheim
		Cornell U. Dept of Computer Science
		{vax135,uw-beaver}!cornell!bill
		bill@cornell
		bill@CRNLCS.BITNET



Date:  6 Mar 84 0146 EST
From: Rudy.Nedved@CMU-CS-A
To: don.provan@CMU-CS-A
Subject: Re: smtp, errors and delivery
CC: Header-People@MIT-MC
In-Reply-To: <05Mar84.125014.DP0N@CMU-CS-A>
Message-Id: <06Mar84.014615.EN0C@CMU-CS-A>

don,

The problem is that large number of sites including CMU's Unix machines relay
mail to another site and do not include their name in the return path. In the
example I gave the sender was something like "bazola" and it was NOT in the
mail from: line. The return path of
	"@bazola:<user>@bonzo_land"
will work in the CMU-CS-A server (independent of whether it is in the host
table) and so will
	"@[78.7.8.9]:<user>@bonzo_land"
but since my mail system knows that hosts that are in the local domain have
names that contain the character set A-Z and period it rejects the mail. The
reason behind this was I was getting some real bizarre garbage host names that
sometimes look like data or internal queueing data from the remote host. I
suspect that a large chunk of mail systems can not handle funny characters that
"happen" to be the queue file delimiter....like our Unix machines using colons
can not simply insert the return path into the queue file...some conversion has
to be done.

The other problem I have seen is that if I add the connected site name to the
return path if it is not there then when the mail is rejected, the site I did
this service for rejects the error notifcation.

I think what I will do now is change the mail server so that it adds the
connecting site host name (or address) and if an error occurs it tries to send
it back to the correct address and if that fails it replaces the address with
Postmaster@<original connecting site>.

As Doug Kingston has pointed out...we have two design philosphys in the mail
world....I didn't realize this before and I am glad I sent mail asking before
starting to shoot at sites that are different.

My apology for the length of this message.

-Rudy

Date: Mon 5 Mar 84 23:19:46-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: smtp, errors and delivery
To: don.provan@CMU-CS-A.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 5 Mar 84 20:58:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

That's easy.  Most syntactically invalid MAIL FROM commands are from
people who are debugging SMTP senders.  I said that the TOPS-20 SMTP
server completely implements the standard, so no correct SMTP sender
should encounter an error.

The TOPS-20 SMTP server will accept any return-path for the MAIL FROM
argument as long as it is syntactically valid.  It won't barf mail just
because the host isn't in some host table!
-------

Date:  5-Mar-84 23:34 PST
From: Rich Zellich  <RICH.GVT@OFFICE-3>
Subject: Re: smtp, errors and delivery
To: Header-People@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-489L3>

Re the mention of two different philosophies:  Remember, please, that there is 
an authentication issue involved, too.  Perhaps the "deliver at all costs" 
philosophy should quietly begin disappearing (at least in the MilNet 
environment), since there is a very large, and growing, community of users using
mail for business purposes as well as the older uses for technical (and social) 
purposes.

-Rich


Date:     Tue, 6 Mar 84 9:20:47 EST
From:     Stephen Wolff <steve@brl-bmd>
To:       Rich Zellich <RICH.GVT@office-3>
cc:       Header-People@mit-mc
Subject:  Re:  smtp, errors and delivery

>	Perhaps the "deliver at all costs" philosophy should quietly begin
>	disappearing (at least in the MilNet environment) .........

Why the (apparent) double standard?  MILNET people don't NEED reliable mail
service?  Or at least not if `business' (commercially) related?  Can you
explain, please?  I'm puzzled.
				-steve


Date:     Tue, 6 Mar 84 11:42:08 EST
From:     Dave Farber <farber@udel-ee.arpa>
To:       Stephen Wolff <steve@brl-bmd.arpa>
cc:       Rich Zellich <RICH.GVT@office-3.arpa>, Header-People@mit-mc.arpa
Subject:  Re:  smtp, errors and delivery

As some one who has run an experimental mail relay for the
Military for many years (!!), let me assure all that they
NEED reliable mail and deliver at any cost. You every see
a red faced 4 star?

Dave

ps Steve, I know you know. It should be to: Rich, copy you.

Date:  Tue, 6 Mar 84 12:02 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Mailing lists that "take responsability"
To:  header-people@MIT-MC.ARPA
Message-ID:  <840306170219.672347@CISL-SERVICE-MULTICS.ARPA>

I want to make a plea for some of the big mailing list servers to start
putting themselves in as the return path, instead of the person who
submitted the transaction to the list.

I am tired of the volume (and I mean VOLUME) of failed mail notification
that I get every time I send to this (and several other) lists.

What is needed is for the home system of HEADER-PEOPLE or whatever to
make header-people-request the target of the return path, instead of me.

Further, if the SMTP server involved implements EXPN, then it should NOT
expand header people.

Date: 06-Mar-84 16:45:11-UT
From: gross@dcn7
Subject: RE: smtp, errors and delivery
To:   rich.gvt@office-3
cc:   header-people@mit-mc


I'm also in favor of phasing out the 'deliver at all costs' philosophy
since it can cause as many problems as it solves.  Are there any
counterbalancing arguments out there?  Why leave Milnet out?

Phill 

-------

Date: 6 Mar 1984 12:03-EST
From: Dan Hoey <hoey@NRL-AIC>
Subject: Re: smtp, errors, and delivery
To: header-people at MIT-MC

I know I'll regret this, but I think some of these ideas need
straightening out, so I'll try.

The return-path is, I am told, supposed to be the address of the sender
of the message, routed in reverse order of the message's delivery.
Many uses have been inferred for it, but in this pragmatic world I can
tell you what it's used for (and if I've left your favorite use out,
I'd like to hear it):

1.  An address to send delivery errors back to.  This saves the
	rfc-writers from having to document an ``Errors-to'' header
	field.
2.  A fallback reply address.  If the ``From'' or ``Reply-to'' field is
	garbage--some of them get typoed by hand, you know--the return
	path is sometimes usable.
3.  A quick index to the ``Received'' lines, useful when those lines
	are out of order or missing.  This can be useful in diagnosing
	mail problems.
4.  A testament by the systems involved as to the actual origin of the
	message, useful when the mail is somehow unlawful and the
	malefactors are being rounded up.

It should be noted that (1) is somewhat in conflict with (2) through
(4), but since (1) is an important and routine function that hasn't
otherwise been provided for we live with it.  Incidentally, I imagine
(4) is what Rich Zellich is talking about becoming more important with
Milnet, but I'm not sure.

The ``deliver-at-all-costs'' philosophy might better be stated as
``deliver even if you can't get back from here.''  When such a
philosophy is taken, all the benefits of 1-4 are lost.  The loss of (1)
and (2) means that the message could get to a point where even with
human intervention, there's no way of telling who the message is for or
from, an uncomfortable situation for us dead-letter-office personnel.
Loss of (3) could lead to not being able to figure out why we get into
all these uncomfortable situations.  And loss of (4) could prevent us
from calling a halt to the chain letters, cranks, ransom notes, and
other Trojan thoughts that we can't deliver, return, or diagnose
anyway.

Unfortunately, the ``responsibility'' philosophy seems to imply that
you can't send mail unless it can be returned.  With so many protocols
around, one site's mailbox is another site's host name.  Rudy's example
of "_" in a host name is an example, but I'm aware of various uses of
certain other @=." )\!:([%] special characters that might be
insufficiently quoted--or quotable--to permit returning of the mail.
It seems unfortunate that person A out in funny-character-land should
be prohibited from sending his phone number to person B in
easy-address-ville because host C in the middle is feeling responsible.

I can suggest some more strategies for people who want to sail
gracefully between the explosive source and the yawning sink.  I'm
pretty sure they're orthogonal, and some of them may even be easy.

1. Try to patch the return-path.  For instance, put quotes around it?
Maybe put parens around it and add "Postmaster"?  I don't know if
quotes and comments fit the return path syntax, but it's a try.

2. Stuff an error message containing the offending return-path onto the
message before sending the message with an empty return-path.

3. Send a notification back along the return-path to warn that delivery
errors may happen and the sender may not hear about them.

4. Log it locally so InterNetPol can track it back to its source if
necessary.

An ideal site might implement them on both sides (server and user).

I would be interested in seeing other solutions to the problems of
unusable return-paths.  Somehow I can't get into this philosophy jazz,
though.

Dan Hoey

Date: Tue 6 Mar 84 10:58:04-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: authentication
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     The only authentication issue with Internet mail is that there is
NO authentication.  Let's not introduce this particular red herring.
Anybody who thinks that Internet mail is authenticated is fooling
himself.
-------

Date:  6-Mar-84 13:13 PST
From: Rich Zellich  <RICH.GVT@OFFICE-3>
Subject: Re: smtp, errors and delivery and authentication
To: Header-People@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-490UQ>

Mark Crispin seems to be the only one who understood that the key word in my 
message was "authentication".  Yes, I know that technically mail is not really 
authenticated (except that it \is/ to a great extent by addition of the Received
lines and the Return-path building).  The point is, that in an official-business
environment, \reliability means not only the ability to deliver the mail, but 
also to get it there with a reasonable indication of who really sent it/.  
Getting mail from a host your mail-receiving server can't identify may not be 
the best idea in the world (and with name servers coming online along with 
domains, a hosts private name table shouldn't be the cause of wrongly-rejected 
mail).

Sometime in the future, of course, we must add \real/ authentication (and real 
security, real precedence, ...).  Right now, the official policy when sending 
official direction via netmail is to follow it up with a TWX.  In practice, 
unless it's fairly important, only the net message is used; this is because most
of the users don't understand how easily a message can be forged on many 
systems, and because they haven't yet been bitten by a forged message.

-Rich


Date: Tue 6 Mar 84 13:57:15-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: SMTP and authentication
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)

     As a taxpaying citizen of the United States of America (and
reasonably patriotic, despite certain leftist political views), I
strongly object to the idea of having Internet mail used for ANY
confidential, official, or any other traffic which in some way
involves USA national security.

     Internet mail is, and should remain, a high-connectivity,
high-throughput mail network with reasonable reliability and
validation.  This is quite suited for the research purposes it is
mostly put to.  Excessive validation (which tends to affect the
HELO command and not the return-path in the MAIL FROM command)
will only serve to seriously impact the high connectivity of
Internet mail.

     I am glad to hear the military follows up all official (and
unclassified, I hope!) directives sent over Internet with a TWX.
My faith in the US military as a viable agency in defending our
nation against foreign aggression would be shattered if it relied
on Internet mail.

     What makes this whole discussion silly is that NONE of the
hosts on Internet (except perhaps the Multics sites) are secure
enough to have authenticated mail in any case.  Certainly not any
of the Tenex, TOPS-20, or Unix systems.  It is only when you can
restrict entry into the network (e.g. the secure subnet of Milnet)
that there is any authentication at all.  Even then all it means
is that the mail was not forged outside of the network.

     Can't we end this once and for all?  Authentication does not
exist, and cannot exist with the current hosts on the network.

-- Mark --
-------

Date:     Tue, 6 Mar 84 17:53:43 EST
From:     Doug Kingston <dpk@brl-vgr>
To:       Benson I. Margulies <Margulies@cisl-service-multics.arpa>
cc:       header-people@mit-mc.arpa
Subject:  Re:  Mailing lists that "take responsability"

I've said this before, but some seemed to have missed it...

	In the MMDF II software, I have implemented something called
the "list channel" which is in fact a "remailing" mechanism which
will substitute an alternate return address for original (sender's)
address.  All the lists handled through BRL hosts are sent through
the list channel.  As a result, senders to Unix-Wizards, Info-Micro,
Info-Cpm, etc. get much less return mail when they submit a message.
The list channel inserts Unix-Wizards-Request, and generally *-request
as the return address in the MAIL FROM command if that is a valid
address on the BRL host.  As a result, the failed mail messages go
to someone who can actually do something about it, the list manager.

	Unfortunately, it is not possible to totally eliminate this
return trash since some mailers will blindly except the mail and
reject it later after throwing away the MAIL FROM address.  They still
take the return address from the letter.  There is nothing we can do
to stop this unless we start munging the message, which we are unwilling
to do in this case.

					Stop promiscuous hosts!
						-Doug-

PS. Then there the hosts that return mail unmodified under separate
    cover...   Arrrgggg....


Date: 6 Mar 1984 1907-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: MRC at SU-SCORE, Header-People at MIT-MC
ENET-address: "Castor::Covert"
Phone: "(603) 884-8271 or DTN 264-8271"
UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert"
Subject: Re: SMTP and authentication
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11997283717.19.132.6887 at DEC-MARLBORO>
Regarding: Message from Mark Crispin <MRC@SU-SCORE.ARPA>
              of 6-Mar-84 1656-EST

Authentication does not exist without encryption (because without
encryption you can hack the authentication).

I'm amazed that people who are concerned about authentication think
that following up a message with a TWX or Telex involves any more
authentication!

A TWX or Telex can be hacked just as easily as netmail!  All it takes
is changing the answerback.

When people worry about authentication in netmail, my usual reply is
"Anyone can throw a letter into the Postal Service with any return
address they want, as well as a forged signature."

No unencrypted mail system has authentication.

/john
   --------

Date:  6 Mar 84 1757 EST (Tuesday)
From: don.provan@CMU-CS-A
To: header-people@mit-mc
Subject: re: smtp, errors, and delivery
Message-Id: <06Mar84.175702.DP0N@CMU-CS-A>

what we need is two new types of error messages.  one to indicate
that the mail may be delivered but errors cannot be returned and
another to indicate that the mail will be delivered but there was
still something bogus about the return path.  this general discussion
is fine, but the times i've had mail rejected because of what the
server thought was a syntax error in the return path, the mail
would have been delivered immediately by the server, so there was
no danger of the return path being used, anyway.

Date:  Tue, 6 Mar 84 20:04 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  return-path
To:  header-people@MIT-MC.ARPA
Message-ID:  <840307010402.021078@CISL-SERVICE-MULTICS.ARPA>

As Mr.  Crispin pointed at length last week, the RFC specifies that
RETURN-PATH is explicitly supposed to serve as a target of complaints,
and NOT as a reply address or anything else.

Date:  Tue, 6 Mar 84 20:07 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  Authentication
To:  header-people@MIT-MC.ARPA
Message-ID:  <840307010738.841199@CISL-SERVICE-MULTICS.ARPA>

I disagree with Mr.  Covert.

Given the assumption that the net gives me trustworthy informatio on the
source host of mail (which the ARPAnet can), and knowledge of the
security characteristics of the hosts on the net, authentication is
available.

Consider two Multics systems on ARPA.  The sending system software that
installs the source name in the envelope is trusted code.

The recieving server can validate that the IMP leader/IP header specify
the address of a directly connected trusted mail host, and copy the
envelope source user name into the appropriate Sender field.  Voila!  We
maintain the envelope data in trusted code so that even local mail has
authenticated sources.

Over an unreliable communications medium, where you cannot perform HOST
level authentication, mr.  covert is correct.  only encryption will do.

Date:  6 Mar 84 1849 EST
From: Rudy.Nedved@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP and authentication
CC: Header-People@MIT-MC
In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST"
Message-Id: <06Mar84.184902.EN0C@CMU-CS-A>

Mark,

Can't you use semi-secret "public" key encryption to validate the
sender? The semi-secret parts comes from the fact that you can't
set up in any enviroment by the points you mentioned (insecure
networks and hosts) a authentication server without the potential
for forgery of it....but you can have users type in magic numbers
at both ends and have the mail authenticated....the magic numbers
are sent by "secure" courier...a guy with a handcuffed briefcase.

This is one the issues CMU CS/RI systems staff is suppose to
solve ASAP....probably after we get the user names and host
names "addressing" issues solved.

-Rudy

Date:  6 Mar 84 1852 EST
From: Rudy.Nedved@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP and authentication
CC: Header-People@MIT-MC
In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST"
Message-Id: <06Mar84.185221.EN0C@CMU-CS-A>

Oh. The mail message would be in clear text with a complete business
like letter enclosed (duplicating the from:, to:, cc: and subject:
fields) and would have at the end a "encrypted checksum" of sorts.

-Rudy

Date:  6-Mar-84 17:59 PST
From: Rich Zellich  <RICH.GVT@OFFICE-3>
Subject: Re: SMTP and authentication
To: John R. Covert <RSX-DEV at DEC-MARLBORO>
Cc: Header-People@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-491AK>
In-reply-to: <"MS10(2124)+GLXLIB1(1136)" 11997283717.19.132.6887 at 
DEC-MARLBORO>

Well, the TWXs come through the secure commo centers using the DoD AUTODIN 
network.  Supposedly, the manual channels covering getting the typed original to
the comm center for transmission take care of authenticating the 
Sender/From/Authorized-by/etc.

Last I heard, the plan is to use the new MilNet/ARPANET protocols with the 
security and precedence stuff added to replace the aged AUTODIN.  How the 
AUTODIN-replacement network will be interconnected with the ARPANET, 
current-version MilNet, or any other part of the internet, I have no idea.

-Rich


Date: Tue, 6 Mar 84 23:57:32 EST
From: Steve Dyer <sdyer@BBN-UNIX>
Subject: please remove me
To: header-people@mit-mc

Please remove me from your mailing list.

Thanks,
Steve Dyer
sdyer@bbn-unix
sdyer@bbncca

Date: Wed, 7 Mar 84 01:11 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: Not about SMTP and authentication
To: Rudy.Nedved@CMU-CS-A.ARPA
Cc: Header-People@MIT-MC.ARPA

I'm tired of this topic.  Let's talk about your In-Reply-To: header.

    Received: from MIT-MC by SCRC-YUKON with CHAOS; Tue 6-Mar-84 20:53:07-EST
    Date:  6 Mar 84 1852 EST
    From: Rudy.Nedved@CMU-CS-A
    To: Mark Crispin <MRC@SU-SCORE>
    Subject: Re: SMTP and authentication
    CC: Header-People@MIT-MC
    In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST"
    Message-Id: <06Mar84.185221.EN0C@CMU-CS-A>
    
It's different; something I hadn't seen before.  It would have been
useful, except for two things:

1)  You use the pretty "Mark Crispin's" personal name instead of
(or without including) the actual mailbox name.

2)  You turn what would have been a perfectly nice phrase parsable phrase
into a single word by quoting it.

I just wanted to call your attention to the fact that despite RFC822's
lack of any useful advice on the issue, there ARE those of us out here
with mail-readers capable of making good use of the In-Reply-To field.
Since your mail-sender obviously goes to enough work to generate
everything needed, why not include the mailbox-name with the personal
name?

In my opinion, any In-Reply-To: header which doesn't include Date: and
From: mailbox information, or Message-ID: information, is useless
fluffery, and cannot be relied on to identify any particular message.
This includes constructs like "Your message of", since too often people
add and delete recipients.

Also, in the interest of standardization, and so we don't need to
recognize still another format (although it's not hard), I would
recommend the following format.

In-Reply-To: The message of 6 Mar 84 16:57-EST from Mark Crispin <MRC@SU-SCORE>

This format, or something close, is pretty widly used by those who
generate the In-Reply-To: header at all when there is no message ID, and
our mail-reader is capable of quickly finding the referenced message
from this information.

Indeed, by tracing forward and backward using this information, I
can delete an entire conversation at a single keystroke, which
is what I wanted to do with the topic under discussion.

I hope any future header-RFC writers include some useful information,
and maybe even restrictions, on In-Reply-To next time around.  Oh, well.

But since this is a different topic, I have carefully deleted my
In-Reply-To: header:  In-reply-to: <06Mar84.185221.EN0C@CMU-CS-A>

Date: Tue 6 Mar 84 22:27:19-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Authentication
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 6 Mar 84 17:25:55-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Does Multics prevent users from connecting to the SMTP server port on
other systems?  If not, your entire previous argument is worthless.
-------

Date:  7 Mar 84 0532 EST
From: Rudy.Nedved@CMU-CS-A
To: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC>
Subject: Re: Not about SMTP and authentication
CC: Header-People@MIT-MC
In-Reply-To: "\"Robert W. Kerns\"'s message of 7 Mar 84 01:11-EST"
Message-Id: <07Mar84.053239.EN0C@CMU-CS-A>

My world does not cover "mail compostion" issues and the people
that normally work on RdMail either have left or are extremely
busy and can not expend the time to get this kinda of thing fixed.

I wish I could help but all I influence is delivering the message
rain, sleet, power failure, disk crash (well...) and sunny weather
(in Pittsburgh??? ha!).

-Rudy

Date:  7-Mar-84 10:30 PST
From: Bill Barns  <WWB.TYM@OFFICE-2>
Subject: Re: SMTP and authentication
To: RICH.GVT@OFFICE-2
Cc: Header-People@MIT-MC
Message-ID: <[OFFICE-2]TYM-WWB-492TB>
In-reply-to: <[OFFICE-3]GVT-RICH-491AK>

Yes, to expand a bit on your discussion: the authentication and security of 
AUTODIN I are derived from three things: physical security of the terminals and 
switches, encryption of data, and administrative procedures.  If you could 
connect your terminal or PC into AUTODIN and type away, authentication would be 
out the window.

One of the effects of the AUTODIN admin procedures is that it is generally 
impossible to get something transmitted without it going through the hands of 
someone other than the originator.  There are exceptions to this, as well as the
possibility of admin breakdowns.  Message centers are supposed to maintain files
of signatures of authorized releasers and all the message forms are supposed to 
be signed.  As to the exceptions, there are a bunch of rules not worth 
repeating, but basically they are logged in a special way.

The idea of using Internet for AUTODIN GENSER type traffic relies heavily on 
encryption.  I haven't heard what the drafter/releaser procedures will be; I 
suspect no "official" decision has been made.  Once you get the data "canned" 
with the right NSA techniques, there is no problem sending it down any pipe you 
want - Milnet, Arpanet, direct broadcast satellite, suit yourself.  The 
interesting questions have to do with how you get your can of data sealed.  I 
don't see it working with the style of mail-sending we use now; probably 
military installations will eventually be set up to let people "draft" items by 
a procedure similar to Internet "sending", but before being "released" they will
have to go through some procedure similar to what is done to declassify a 
magtape, which basically means somebody else in a secure place will have to poke
at it.

There is a bunch of work in progress on retinal scanners and other gee whiz 
stuff, but I don't think you should plan on finding one on your desk any time 
soon.  Back in '77 I was hearing that by 1984 the Pentagon would be full of 
Secure Office Terminals.  It isn't (but yes, there has been some progress).  
Someday, probably, but not before all the Spectra-70's keel over.  I think there
will have to be one or more interim solutions.  -b


Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
	id AA00232; Thu, 8 Mar 84 11:56:40 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14.noSUID/4.14.2) id AA16452; Thu, 8 Mar 84 11:42:02 pst
Received: by ucbopal.CC.Berkeley.ARPA
	(4.14/4.14) id AA02084; Thu, 8 Mar 84 11:48:17 pst
Date: Thu, 8 Mar 84 11:48:17 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8403081948.AA02084@ucbopal.CC.Berkeley.ARPA>
To: Header-People@MIT-MC
Subject: Re:  smtp, errors and delivery

Military message systems operate on three basic principles: reliability,
speed, and security. Of the three, "reliability is paramount".
I think you will find that an electronic mail system that permits
messages to "drop into a black hole" will not be acceptable for
Defense Data Network (ie. MILNET) use.

Mail transport agents should be responsible for ensuring the FROM in
SMTP and the "From" in the mail header are correct both when received
and when transmitted.  This may require that gateway mail transport
agents modify the address when the message is transmitted by a gateway
into a different mail domain or mail system.  For non-Internet mail
addresses, this means transforming the address into an address that is
acceptable to the Internet world.  It may mean adding  the source
"route" (eg. @host.domain:) of the gateway mail transport agent to the
front of the From address, or changing the address into the form:

   "off-net-address"@mail-gateway-id.registered-top-domain-name

where the address to the right of the "@" sign is a valid Internet
mail domain name.

Receiving mail transport agents should check the FROM field, if the
syntax is correct, but the domain name is not, then they should add
the domain name of the sending mail transport agent to the front of
the source "route" in the address to ensure a reply path. --- Hmmmm.
That would imply the addresses of the form:

   <@mail-gate.Internet-top-domain:local-address@hostid.non-ARPA-domain-name>

for example:

   <@mail-relay.ARPA:userid@hostid.local-netid>

should be legal within the Internet mail world. That is, if the
first domain-name in the source "route" is known and valid within the
current mail domain, and the syntax of the address is correct,
then the address should be accepted by the receiving mail transport
agent.

Bill Wells, Computing Services, UC Berkeley
wcwells@Berkeley.ARPA or ...!ucbvax!wcwells


Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25)
	id AA23963; Sun, 11 Mar 84 14:33:54 pst
Received: by ucbarpa.ARPA (4.22/4.25)
	id AA09682; Sun, 11 Mar 84 14:28:59 pst
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 11 Mar 1984 1428-PST (Sunday)
Message-Id: <9681.31.447892136@ucbarpa>
To: allegra!hou3c!ka@mit-vax, vax135!martin@Berkeley (Martin Levy)
Cc: Header-People@MIT-MC.ARPA
Subject: Re: .ARPA hard coded into sendmail/src/daemon.c
In-Reply-To: Your message of 2 Mar 1984 18:58:04-EST,
    Thu, 1-Mar-84 20:14:07 EST.
             <638@vax135.UUCP>
Fcc: mail

I have modified sendmail on the Berkeley version to have a new
configuration option (`N') that specifies the local net name.
This defaults to "ARPA" for back compatibility.

eric

Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25)
	id AA24288; Sun, 11 Mar 84 15:05:07 pst
Received: by ucbarpa.ARPA (4.22/4.25)
	id AA10286; Sun, 11 Mar 84 15:00:12 pst
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 11 Mar 1984 1500-PST (Sunday)
Message-Id: <10285.31.447894010@ucbarpa>
To: vax135!ukc!mjb@Berkeley (M.J.Bayliss)
Cc: Header-People@MIT-MC.ARPA
Subject: Re: Strange From headers
In-Reply-To: Your message of 1 Mar 1984 22:06:12-EST,
    Thu, 16-Feb-84 06:45:03 EST.
             <4097@ukc.UUCP>

I am indeed reading your message....

You have identified the problem correctly -- the UGLYUUCP code is
ONLY for cases where you are sticking with the oh-so-ugly technique
of stacking UNIX-style from lines, e.g.,

	From uucp .... remote from vax135
	>From uucp .... remote from ukc
	>From mjb ....

If you decide to use the ".UUCP" format, you must stop using the
stacked "remote from ..." syntax.  This can be turned off selectively
by having two UUCP mailer definitions, e.g., "olduucp" and "newuucp."

eric

Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Sun 11-Mar-84 20:32:14-EST
Date: Sun, 11 Mar 84 20:30 EST
From: Moon@MIT-MC.ARPA
Subject: Goodbye
To: Header-People@MIT-MC.ARPA

I can no longer keep up with this amount of mail.  I have deleted 213
unread Header-People messages from my mailbox and removed myself from
the list.  Goodbye.

Date: 16 Mar 1984 09:19:33-EST
From: allegra!hou3c!hocda!houxm!ihnp4!zehntel!dual!unisoft!ed at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site unisoft.UUCP
From: ed@unisoft.UUCP (Ed Gould)
Subject: Re: .ARPA hard coded into sendmail/src/daemon.c
Message-ID: <227@unisoft.UUCP>
Date: Wed, 14-Mar-84 02:11:08 EST
Received: by hou3c.UUCP; Wed, 14-Mar-84 23:03:14 EST
References: <6741@cornell.UUCP>
In-Reply-To: <6741@cornell.UUCP>
Organization: UniSoft Corp., Berkeley

Nothing is hard-coded into sendmail.  It all comes from the .cf file.
I know they're hard to deal with, but all the flexibility you
want is there.

-- 
Ed Gould
ucbvax!mtxinu!ed



Date: 16 Mar 1984 09:19:44-EST
From: allegra!hou3c!hocda!houxm!ihnp4!harpo!seismo!rick at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site seismo.UUCP
From: rick@seismo.ARPA (Rick Adams)
Subject: Re: .ARPA hard coded into sendmail/src/daemon.c
Message-ID: <703@seismo.UUCP>
Date: Thu, 15-Mar-84 12:43:18 EST
Received: by hou3c.UUCP; Thu, 15-Mar-84 15:53:43 EST
References: <6741@cornell.UUCP> <227@unisoft.UUCP>
In-Reply-To: <227@unisoft.UUCP>
Organization: Center for Seismic Studies, Arlington, VA


	Nothing is hard-coded into sendmail.  It all comes from the .cf file.
	I know they're hard to deal with, but all the flexibility you
	want is there.

Funny, this certainly looks hardcoded to me:
		/* determine host name */
		hp = gethostbyaddr(&otherend.sin_addr, sizeof otherend.sin_addr, AF_INET);
		if (hp != NULL)
--->			(void) sprintf(buf, "%s.ARPA", hp->h_name);
		else
			/* this should produce a dotted quad */
			(void) sprintf(buf, "%lx", otherend.sin_addr.s_addr);
		RealHostName = newstr(buf);

How do you propose I get it to say .UUCP instead of .ARPA?


---rick



Date: 16 Mar 1984 13:23:49-EST
From: allegra!hou3c!hocda!houxm!ihnp4!harpo!seismo!rick at mit-vax
To: Header-People@MIT-MC.ARPA
Posting-Version: version B 2.10.1 6/24/83; site seismo.UUCP
From: rick@seismo.ARPA (Rick Adams)
Subject: Re: .ARPA hard coded into sendmail/src/daemon.c
Message-ID: <704@seismo.UUCP>
Date: Thu, 15-Mar-84 13:26:23 EST
Received: by hou3c.UUCP; Thu, 15-Mar-84 20:18:25 EST
References: <6741@cornell.UUCP> <227@unisoft.UUCP>
In-Reply-To: <227@unisoft.UUCP>
Organization: Center for Seismic Studies, Arlington, VA

Re:
	Nothing is hard-coded into sendmail.  It all comes from the .cf file.
	I know they're hard to deal with, but all the flexibility you
	want is there.

Funny, this certainly looks hardcoded to me:
		/* determine host name */
		hp = gethostbyaddr(&otherend.sin_addr, sizeof otherend.sin_addr, AF_INET);
		if (hp != NULL)
--->			(void) sprintf(buf, "%s.ARPA", hp->h_name);
		else
			/* this should produce a dotted quad */
			(void) sprintf(buf, "%lx", otherend.sin_addr.s_addr);
		RealHostName = newstr(buf);

How do you propose I get it to say .UUCP instead of .ARPA?

---rick



Date: 16 Mar 1984 13:13:35 PST
From: POSTEL@USC-ISIF.ARPA
Subject: .ARPA is coming
To:   header-people@MIT-MC.ARPA


Please note the announcement in DDN MGT Bulletin 22 of the change in the
data kept in the HOST.TXT file and made available via the NIC's Host-Name
Server.

On March 21 (at 8am EST) all the official host names will be changed to
have ".ARPA" appended.  For example, "USC-ISIF" will become "USC-ISIF.ARPA".

This might cause some programs a few minor problems.  If you would like to
check things prior to the change over you can use the file DHOSTS.TXT from
the NIC (pathname=<NETINFO>DHOSTS.TXT on SRI-NIC).

--jon.
-------

