Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 02:17:05 EST
Received: from (JCURRAN)UMASS.BITNET by WISCVM.ARPA on 12/10/85 at
  13:21:20 CST
Date:    Tue, 10 Dec 85  09:59:36 EST
From:  JCURRAN%UMASS.BITNET@WISCVM.ARPA
To:  HEADER-PEOPLE@MIT-MC.ARPA
Subject: A suggestion for preventing machine mail loops

    It occurs to me that the rfc822 document has very good
provisions for handling machine generated mail and preventing
'loops' per se.  In a server or demon, one can simply provide
the following set of fields in a out-going message:

From:  Server-name@node
Sender: Person@node
Reply-to: <>

    In this way, the actual origin is specified, but will never
be used as an address; all errors should be sent to the person
responsible for the server, and any attempts at replies to the
server should be disallowed since the reply-to field is null.

-- John Curran
-- Umass/Amherst

Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 03:07:24 EST
Date: Wed 11 Dec 85 00:05:58-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Re: A suggestion for preventing machine mail loops
To: JCURRAN%UMASS.BITNET@WISCVM.WISC.EDU
Cc: HEADER-PEOPLE@MIT-MC.ARPA
Message-ID: <VAX-MM(164)+TOPSLIB(114)+PONY(0) 11-Dec-85 00:05:58.SRI-IU.ARPA>
In-Reply-To: Message from " JCURRAN%UMASS.BITNET@WISCVM.ARPA" of
	     Tue, 10 Dec 85  09:59:36 EST

I think I must be missing something in this discussion of automatically
generated replies.

You don't want to use a line like:
	Reply-To: <>
to stop mailers from returning undeliverable messages.  This is not
the address that mailers (or programs) are supposed to use for this
purpose, and in fact this address SHOULD have some value (particularly
for program-generated messages) so that people receiving the messages
know how to contact a person responsible for the program's behavior.

In fact mailers are supposed to return undeliverable messages to the
address specified in the SMTP "MAIL FROM" command.  This address is
normally written to a "Return-Path:" field in the header upon actual
delivery in a person's mailbox.  Programs which generate messages should
have the brains to tell their outgoing mailer to use a null address
in the "MAIL FROM" command - particularly when these programs are
mailers which are in fact returning a message to its sender.

I thought this is all laid out fairly clearly in 821 and 822.

Peter
-------

Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 11:25:57 EST
Received: from (JCURRAN)UMASS.BITNET by WISCVM.WISC.EDU on 12/11/85 at
  10:23:15 CST
Date:     Wed, 11 Dec 85  11:08:06 EST
From:  JCURRAN%UMass.BITNET@WISCVM.WISC.EDU  (Local UMass address is
  Avenger@Mailer.CY175)
Subject:  automatic generation of replies
To:  Header-people@mit-mc.arpa

    I don't think that rfc822 CLEARLY pointed out that
automatically generated replies should have a "return-path" of
null.  In fact, rfc822 discusses computer generated messages and
states that since computer programs cannot be held accountable,
the SENDER field of the message should contain an path of the
human responsible.  This means that a good header specification
resulting from a demon could be:

From:   Demon@Node...
Sender:  Demon-fixers@node..

    By rfc822, Demon-fixers will recieve "notices of any
problems in transport or delivery of the original messages"
while Demon@node will recieve any replies.  This works very well
except when the server/demon doesn't want any replies sent to
it.  It can either discard them as the arrive, or since a
REPLY-TO field is the address that "the reply should go to..
and not the FROM field" the demon could simply indicate on its
messages that it does not wish replies (of any kind, automatic
or 'real') by including a REPLY-TO field of Null.

Comments?

-- John Curran
-- Umass/Amherst

Received: from USC-ISIB.ARPA by MIT-MC.ARPA 11 Dec 85 13:36:28 EST
Date: 11 Dec 1985 10:00:09 PST
From: POSTEL@USC-ISIB.ARPA
Subject: re: automatic generation of replies - return path
To:   header-people@MIT-MC.ARPA


John Curran:

The "return-path" is discussed in RFC-821.

--jon.
-------

Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 16:00:56 EST
Received: from (MAILER)DBNGMD21.BITNET by WISCVM.WISC.EDU on 12/11/85
  at 14:55:33 CST
Date:    Wed, 11 Dec 85 18:34 CET
To: Header People <header-people@mit-mc.ARPA>
From:      Peter Sylvester +49 228 303245
  <GRZ027%DBNGMD21.BITNET@WISCVM.WISC.EDU>
Subject: (Copy) Re: A suggestion for preventing machine mail loops


Where is the return-path: header field in the following message?
 ---------------------------- Text of forwarded message -----------------------
Received: (from SMTPUSER@WISCVM for GRZ027@DBNGMD21 via NJE)
         (RSCS6516-6516;      35 LINES); Wed, 11 Dec 85 18:12:35 CET
Received: from MIT-MC.ARPA by wiscvm.wisc.edu on 12/11/85 at 02:32:58 CST
Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 03:07:24 EST
Date: Wed 11 Dec 85 00:05:58-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Re: A suggestion for preventing machine mail loops
To: JCURRAN%UMASS.BITNET@WISCVM.WISC.EDU
Cc: HEADER-PEOPLE@MIT-MC.ARPA
Message-ID: <VAX-MM(164)+TOPSLIB(114)+PONY(0) 11-Dec-85 00:05:58.SRI-IU.ARPA>
In-Reply-To: Message from " JCURRAN%UMASS.BITNET@WISCVM.ARPA" of
         Tue, 10 Dec 85  09:59:36 EST

....
In fact mailers are supposed to return undeliverable messages to the
address specified in the SMTP "MAIL FROM" command.  This address is
normally written to a "Return-Path:" field in the header upon actual
delivery in a person's mailbox.
....


Received: from sri-spam.arpa by MIT-MC.ARPA 11 Dec 85 16:28:34 EST
Received: by sri-spam.arpa (5.4/4.16)
	id AA10452; Wed, 11 Dec 85 13:25:55 PST
Date: Wed, 11 Dec 85 13:25:55 PST
From: gds@sri-spam.ARPA (Greg Skinner)
Message-Id: <8512112125.AA10452@sri-spam.arpa>
To: header-people@mc
Subject: Re: Need for new field in RFC and MHS standards

> From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV  Wed Dec 11 01:37:39 1985
> Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16)
> 	id AA01923; Wed, 11 Dec 85 01:37:39 PST
> Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST
> Return-Path: <mcvax!ace!teus>
 ...
> Message-Id: <8512101018.AA16148@sunrel1>

It might be the case that we also want to modify our mailers so that
upon receipt and full delivery of a message with a given Message-ID, all
subsequent messages received with that same Message-Id are dropped on
the floor (no need to advise anybody automagically of duplicates, since
we don't want to see exponential growth of looping mail :-).  I don't
know if this is an MHS requirement or not but it is essential in a
conferencing system (where the same messsage might come from different
nodes in a network) and would relieve us of seeing duplicates.  The only
problem is that not all mailers generate Message-IDs at the source of
the message, plus a redistributor may replace (or add) its own
Message-ID.  We should limit the number of Message-IDs to one per
message.

--gregbo


Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 18:22:04 EST
Date: Wed 11 Dec 85 15:16:36-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: "Where is the Return-Path line?"
To: header-people@MIT-MC.ARPA
Message-ID: <VAX-MM(164)+TOPSLIB(114)+PONY(0) 11-Dec-85 15:16:36.SRI-IU.ARPA>

Peter Sylvester:

It appears that your mail system didn't write one.

The important concept here is that associated with every SMTP message
is an out of band (i.e., not in the header) address which is where
the message is suposed to be returned to if it cannot be delivered.
As a message hops from host to host, each one is supposed to suffix
its name to this return path.  The Tops-20 mail system is nice enough
to write this address into a Return-Path: field in your message
header when it delivers it to your mailbox.  I don't believe this is
part of any official specificiation, but it does come in handy.

This out of band address is transmitted in the SMTP "MAIL FROM"
command.  For example, when I send this message to header-people, it 
starts at SUMEX, goes to MIT-MC, and then gets relayed to each of you.
Here is what the mailers tell each other along the way:

SUMEX to MIT-MC:		MAIL FROM:<PKARP@SUMEX-AIM.ARPA>
MIT-MC to yourarpa host:	MAIL FROM:<@MIT-MC.ARPA:PKARP@SUMEX-AIM.ARPA>

Well, hopefully this gives you the idea.  As Jon says, this stuff
is discussed in RFC821.

Note by the way that I'm not arguing that all this is an ideal state of
affairs, I'm merely saying how to use the current system correctly.  One
might argue that having both out of band address information and address
information in the header is a very bad idea since the two can become
inconsistent.  But clearly it makes mail system code a lot simpler since
SMTP only has to deal with the out of band band info - it doesn't have to
parse message headers.  This allows SMTP to deal with messages as
featureless blocks of text and leave all header issues to mail
reading/composition programs.

Or at least it could if it weren't for gateways between different
mail protocols.  Anyone care to start a discussion of how to rewrite
message headers when messages are relayed across protocol boundaries?
A lot of sites are doing this but I have yet to see any official
specification of how to do it or even a formal statement of the rules
that are used.  For example, this is how lovely addresses like:
	tuna!user%spam@turkey!beaver@phred
get created.

Peter (Karp)
-------

Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 12 Dec 85 09:45:00 EST
Received: from (JCURRAN)UMASS.BITNET by WISCVM.WISC.EDU on 12/12/85 at
  08:42:22 CST
Date:     Thu, 12 Dec 85  08:33:53 EST
From:  jcurran%UMass.BITNET@WISCVM.WISC.EDU  (John Curran  (413)
  545-2690)
Subject:  Internet formats
To:  Header-people@mit-mc.arpa

    Please notice that many internetwork gateways do not allow
the sender control over any of the SMTP commands sent other then
indirectly..  As such, it becomes crucial that all essential
information about a message envelope can be expressed not only
in SMTP commands, but in fields in the message.

    In the past, when mentioning machine generated mail and the
potential for "looping" of replies, references to the MAIL FROM
field in the SMTP envelope be null.  This solution might work
for SMTP to SMTP mail but it is questionable of whether it will
succeed in an net-gateway-net situation.  Examine the problem of
'dueling reply demons' whereby two mail system users, each on
their own network, have left on vacation and have installed a
reply-demon that automatically inform the sender that his mail
have been recived and will be read when the account owner
returns.

    In a SMTP network, the first automatic reply gets a MAIL
FROM field of null, the second reply can never be send for lack
of destination.  In an internet message there is no SMTP fields
and depending upon the transformations done via the gateway, it
is possible that the replies will go on and on..

    Now there is a choice of either making the "return-addr" or
"From" field null if the geteway program has reason to believe
(like a null MAIL FROM field on a SMTP header) that the message
was machine generated.  Also, mail systems (and demons) must be
prepared to handle such an occurance.

  John Curran
  Umass/Amherst

Received: from A.CS.CMU.EDU by MIT-MC.ARPA 12 Dec 85 12:29:43 EST
Date: Thu, 12 Dec 85 12:15 EST
From: Craig.Everhart@A.CS.CMU.EDU
To: Header-People@MIT-MC.ARPA
Subject: Re: Internet formats
CC: jcurran%UMass.BITNET@WISCVM.WISC.EDU (John Curran (413) 545-2690)
In-Reply-To: "jcurran%UMass.BITNET@WISCVM.WISC.EDU's message of 12 Dec 85
             08:33-EST"
Message-Id: <12Dec85.121525.RD00@A.CS.CMU.EDU>

So it's the responsibility of the inter-net gateway to transmit the proper
semantics of the null SMTP MAIL FROM:<> address through the other network.
In fact, it's the responsibility of the other network to provide such
semantics, and it's the responsibility of the inter-net gateway to translate
that net's semantics to the null SMTP MAIL FROM: form.  If this means putting
some information in a header field as mail moves from SMTP-land to some other
place, and reading that header field in messages from that other place to
figure out what to use for the MAIL FROM: contents, so be it.

		Craig Everhart

Received: from hplabsd by MIT-MC.ARPA 12 Dec 85 15:55:35 EST
Received: by hplabsd ; Thu, 12 Dec 85 12:14:41 pst
To: veeger!hpcnof!hplabs!Header-People@MIT-MC.ARPA
Date: Thu, 12 Dec 85 11:04:45 MST
From: hpcnou!dat@hplabsd (Dave Taylor)
Subject: X-* headers
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.3]


As a response to a recent request for headers that are in X-* form, (or
should be) an excerpt from my List of Mail Headers...

(requests for the full document should be mailed to me at either of the
 signature addresses)

					-- Dave Taylor
					
					hpcnof!dat@HPLABS
				    or  ihnp4!hpfcla!d_taylor

----------

			Extensions and User Defined Fields
			----------------------------------

       There are many more headers that	can be	found  in  electronic  mail
       (some  of which are listed below) and often the personal	headers	are
       prefixed	by "X-", since it is guaranteed	that any extensions to	the
       mail headers will not begin with	these two letters.

       It is important to note that this section is by no means	complete  -
       there  are  a  great number of strange headers floating about.  I've
       tried to	document the most common and most interesting ones here.



       37.  Latitude:

	    This header	indicates  the	relative  Latitude  and	 Longtitude
       (geographic  location)  of the sender.  Theoretically, if you have a
       "Great Circle" program, you could feed it these entries and your	own
       location	 and  figure  out  how far away	from you they are.  It's of
       dubious use, though.

       Example:

       Latitude: 40.4166       Longitude:      86.9166


       38.  Organization:

	    This is a quite  common  header  (with  it's  European  variant
       "Organisation:")	 and  indicates	 the  organization  that the sender
       works for or is attending (in the case of a University).

       Examples:

       Organisation: the Antelope project, Kruislaan 312, Amsterdam

       Organization: Hewlett Packard, Colorado Networks	Operation



       39.  Origin:

	    This is mostly used	to verify  that	 the  sending  username	 is
       actually	the person who sent it.	 it contains the tty device sending
       the message, the	hostname of the	machine	and the	date sent.

       Example:

	 Origin: tty613	on hpccc; Mon, 23 Sep 85 09:48:38 PDT



       40.  Phase-Of-The-Moon:

	    This is a strangely	popular	header that is presumed	to indicate
       what phase the moon is in at the	senders' site...more dubious infor-
       mation!

       Example:

	 Phase-Of-The-Moon: Waning Crescent (18% of Full)



       41.  Phone:

	    The	telephone number by which the sender can be  reached  (usu-
       ally their work phone number).

       Example:

	 Phone:	+31 20 5924122,	+31 20 947183



       42.  Postal-Address:

	    The	"overland" (non-electronic) mail address for the sender	 of
       the message.

       Example:

       Postal-Address: Dave Taylor,
		       HP Colorado Networks,
		       3404 East Harmony Road
		       Fort Collins, Colorado
		       80525



       43.  Status:

	    This header	is generated and used at the receiving end  by	the
       (Berkeley)  mailx  mailer  and  it's  derivatives, and indicates	the
       "status"	of the individual message.  Known values for the field are:

	       N      -	new
	       R      -	read
	       RO     -	read, old (saved to file and re-read)


       Example:

	 Status: RO



       44.  Sunrise:

	    What time sunrise and sunset are at	the senders location.

       Example:

	 Sunrise: 6:23	       Sunset:	19:08	(CST)



       45.  Telephone:

	    This is the	same as	'Phone:' above.

       Example:

	 Telephone: (415) 857-5875



       46.  X-Location:

	    This is the	geographic location of the sender.

       Example:

	 X-Location: Fort Collins, Colorado, USA



       47.  X-Mailer:

	    This indicates what	mailer the sender used to compose and actu-
       ally  transmit  the  message.   It's  usually  used to indicate non-
       standard	mailers...

       Example:

	 X-Mailer: fastmail [version 1.0]



       48.  X-Sent-By-Nmail_Version:

	    This is the	same as	the  "X-Mailer:"  header,  only	 much  more
       specific.  It should, in	fact, be absorbed into the previous header.

       Example:

	 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46





Received: from hplabsd by MIT-MC.ARPA 17 Dec 85 15:51:27 EST
Received: by hplabsd ; Tue, 17 Dec 85 12:27:12 pst
To: veeger!hpcnof!hplabs!cak@Purdue.EDU
Date: Tue, 17 Dec 85 11:03:43 MST
From: hpcnou!dat@hplabsd (Dave Taylor)
Subject: More on bizarre headers
Cc: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA, msg-group@hplabsd
In-Reply-To: Message from "Christopher A. Kent" of Dec 12, 85 at 9:35 pm
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.3]


Chris Kent at Purdue informs me that I missed his contribution to the mail 
header mania...

----------------
  From root Tue Dec 17 10:48:25 1985
  To: hpcnou!dat@hplabs.arpa (Dave Taylor)
  Subject: Re: X-* headers
  National-Indulgence-Of-The-Day: Lager
  From: "Christopher A. Kent" <hplabs!cak@Purdue.EDU>

  Dave,
  
  Somehow you've missed my contribution to mail header explosion (see
  above.)

  Chris
----------

My response is: Gee you have a wonderful header there.  So do
some other friends of mine:

 Phase-of-the-Day: management by objectives
 Fruit-of-the-Day: apple
 Buzzword-of-the-Day: user-friendly
 Mood-of-the-Moment: happy 
 Neuron-Firing-Level: high
 Libido-Level: very high
 Weather: sunny with a 30% chance of rain this evening
 Temperature: 80 degrees, +/- 5 degrees

and so on.

My real reaction - the arbitrary headers are fine...no biggie...but
I'm not about to start adding every random header to the list just
to give people vicarious thrills.  Y'know what I mean?  (Besides,
it would increase the size of the list without bounds once I started)

If you can get a number of people at a number of different sites to
start using your header then it will make it into the document I
transmitted since that's the way I decide...

While I'm at it, I'd like to poll the readers of this message about their
reactions to my posting this list every so often, including all updates, 
to the newsgroup "net.mail".  Any comments?  It seems like this would be 
a pretty useful addition to the net...

Sorry to seem so untractable, Chris, but I'd really like to avoid a
replay of the header-wars that first hit when people realized they can 
put just about any random junk in the headers of their outbound messages.

My worst nightmare is to start getting messages like:

-----------
 From root <date>
 Subject: how about THESE headers!
 Alternative-Subject: more headers for inclusion in your list
 Mail-Generated-By: typing it in, of course.
 From: John Public <john@random_vax>
 Really-From: God
 Almost-From: Ronald Reagan
 Political-Stance-of-the-Day: ban the bomb!
 Start-Body:
 Line-1: Dave,
 Line-2:
 Line-3: Just thought you'd appreciate this message with it's wonderful
 Line-4: headers and would consider it for inclusion in your list of 
 Line-5: mail headers...
 End-Body:
 Signed:			John Q. Public
 Authorized-by: jqp at 4:50 pm

   hi
----------

or something equivalent.

					-- Dave Taylor
					Hewlett Packard 





Received: from hplabsd by MC.LCS.MIT.EDU 18 Dec 85 15:10:29 EST
Received: by hplabsd ; Wed, 18 Dec 85 12:07:10 pst
To: veeger!hpcnoe!hpfcla!hp-sdd!ken@hplabsd
Date: Wed, 18 Dec 85 10:03:37 MST
From: hpcnou!dat@hplabsd (Dave Taylor)
Subject: Quiz - Parse this From line
Cc: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Ken Stone" of Dec 17, 85 at 2:36 pm
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.3]

Ken Stone of HP-SDD sent me his copy of my recent note and the return
address is the strangest I've seen yet on this network...

 >From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985

The question is - how does one parse this?  There are a LOT of
ambiguities here ... including two '@' addresses and such.  It
seems to me that a decent return address would be parsable in
a unique fashion, rather than this "if the destination machine is
an ARPA gateway then it'll send to (?) hplabsd, if not, then if
it's a BITNET gateway it'll send to MIT-MC.ARPA (through an ARPA
gateway?) else it'll just send it to noscvax and let THEM deal
with it...

Anyone have any pearls of wisdom about all this?

----- for further amusement, the modified From line too...(now wrong) ----

 From: noscvax!hpcnou!dat@hplabsd.ARPA (Dave Taylor)

-----

Are we having fun yet?
					-- Dave





Received: from ucbarpa by MC.LCS.MIT.EDU 18 Dec 85 16:28:33 EST
Received: by ucbarpa (5.31/1.7)
	id AA24747; Wed, 18 Dec 85 12:38:44 PST
Date: Wed, 18 Dec 85 12:38:44 PST
From: jordan@ucbarpa.BERKELEY.EDU (Jordan Hayes)
Message-Id: <8512182038.AA24747@ucbarpa>
To: header-people@mit-mc.arpa
Subject: Re:  Quiz - Parse this From line

	From: hpcnou!dat@hplabsd (Dave Taylor)

 >> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

Simple.

If there's a leading '@', use source-routing. If not, look for
the right-most '@' ... so, send the return message to "hplabsd" ...

Ah, they say -- "but that's not the truth ..."

Humbug.

You can't parse it correctly unless you make some assumptions about
where that address showed up at. If it showed up at a dumb UUCP host
connected to noscvax, you may not have a problem returning it to
there and having noscvax send to mit-mc which would send to hplabsd
which would send to hpfcla!hpcnoe!veeger!hpcnou!dat ... *ugh* !!

However, if the site it came from recieved the message *via* uucp,
but is also an arpanet host (can you say "seismo" "ucbvax" "topaz"
"sdcsvax" "harvard" + a cast of thousands ...), you have a problem,
since it will try to do the "correct" thing I mentioned above about
sending it to hplabsd (BTW: how about your own return address, Dave?)

Such a silly question to ask ... the answer is clear: you can't parse
addresses with multiple (conflicting) syntaxes ... I thought we cleared
this question up a few years ago ... *sigh*

Now: how about the solution? As simple as the answer to Dave's
Question ... uucp needs to use 822 addresses if they expect to get
decent service when getting gatewayed into/out of the Arpanet.

They can do whatever they want between themselves, but when in Rome ...

/jordan

Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Dec 85 15:14:08 EST
Received: from hplabs.arpa by CSNET-RELAY.ARPA id a012273; 19 Dec 85 15:01 EST
Received: by hplabsd ; Thu, 19 Dec 85 12:00:38 pst
Date: Thu, 19 Dec 85 10:02:56 pst
From: Scott McGregor <hpccc!mcgregor@hplabs.arpa>
To: hplabs!hpcnou!dat%hplabs.arpa@csnet-relay.arpa, 
    veeger!hpcnoe!hpfcla!hp-sdd!ken%hplabs.arpa@csnet-relay.arpa
Subject: Re:  Quiz - Parse this From line
Cc: mcgregor@hplabs.arpa, 
    veeger!hpcnoe!hpfcla!hplabs!Header-People%mit-mc.arpa@csnet-relay.arpa


Hey, I can answer this one (sort of).

**Warning** **Warning** **Warning** **Warning** **Warning** **Warning**
**                                                                   **
** Lengthy reply follows, Cognoscenti may wish to trash message now! **
**                                                                   **
**Warning** **Warning** **Warning** **Warning** **Warning** **Warning**

First let me explain how it can be correctly parsed, and then go over
the assumptions.

There are three basic forms here:

RFC 822 simple address:   user@host
RFC 822 explicit routing: @relay:user@host
UUCP routing:             host1!host2!...!user

Lets build up the address from its parts:

       hpfcla!hpcnoe!veeger!hpcnou!dat

is a legal UUCP routing address. Since RFC 822 doesn't describe
any substructure for the "user" field, this can be treated as the
"user" portion of a RFC 822 address (user@hplabsd).

       hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

At this point, we can go from an RFC 822 simple address to
an explicit routing address where MIT-MC.ARPA is the relay.

       @MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

Now, UUCP routing doesn't break up user parts either. So we
can treat the above as the user part ofnoscvax!user.

       noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

This address will work as a TO address IF the following are true:

 - The machine originating the message only talks UUCP syntax.
 - noscvax can receive UUCP traffic from the machine sending the mail.
 - noscvax can send RFC822 mail to MIT-MC.ARPA
 - MIT-MC.ARPA either ONLY understands RFC-822, or
   MIT-MC.ARPA always gives RFC822 precedence over UUCP, or
   MIT-MC.ARPA talks to hplabsd using RFC822, but not to hpfcla using UUCP
 - hplabsd must be able to receive RFC822 mail form MIT-MC.ARPA
 - hplabsd must be able to send UUCP mail to hpfcla.
 - hpfcla must be able to send UUCP mail to hpcnoe.
 - hpcnoe must be able to send UUCP mail to veeger.
 - veeger must be able to send UUCP mail to hpcnou.
 - hpcnou must have a local user named dat.
 - no machine tries to short-cut or parse the "user" portion of the
   address when they have it.

The interesting problem of course is what if one or more of the
sites does support both RFC822 and UUCP syntax, without the
explicit precedence rules.

In particular, confusion can arise if:

- MIT-MC.ARPA can talk RFC 822 to hplabsd, *and* UUCP to hpfcla.

If the mail were accidentally UUCP mailed to hpfcla, then
hpcnoe would be told to deliver to dat@hplabsd. If hpcnoe
doesn't talk RFC 822 or doesn't talk to hplabsd then
the mail would fail.  If it does talk RFC 822 to hplabsd then
the mail could be successfully delivered to "dat" there if
that was a legal mail name there.  Obviously the dat@hplabsd
could be a different than the hpcnoe!dat.

It shouldn't matter to noscvax that there are two at-signs in the
address when it sees it, since they are in valid RFC 822 routing format,
so there should be no conflict in whether to send to hplabsd with
the rest being the user field vs. sending to MIT-MC.ARPA. By the rules
of 822 it MUST be sent to MIT-MC.ARPA. Of course, if the mailer is
not completely RFC 822 standard (and many are not) there could be
a problem and the mail could be acccidentally sent to hplabsd instead.
That of course would be disasterous, since the "user" field handed
to hplabsd would be neither valid RFC 822 nor UUCP routing form.

By the way, there is no indication of any BITNET syntax here at all.

The remaining question is left for the user, namely, why is

 >From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985

in an UUCP ">From" line rather than in a RFC 822 "From:" line?:

 From: noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

            Scott McGregor
           {...!hplabs, ...!hpcea, ...!hpisla}!hpccc!mcgregor
            HP Corporate Computing Center






Received: from sri-spam.arpa by MC.LCS.MIT.EDU 19 Dec 85 15:28:59 EST
Received: by sri-spam.arpa (5.4/4.16)
	id AA07164; Thu, 19 Dec 85 12:26:18 PST
Date: Thu, 19 Dec 85 12:26:18 PST
From: gds@sri-spam.ARPA (Greg Skinner)
Message-Id: <8512192026.AA07164@sri-spam.arpa>
To: header-people@mc
Subject: Re:  Quiz - Parse this From line

 >> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd


Since Dave Taylor said that the message came from someone at hp-sdd,
whic is not on the ARPA Internet as far as I know, and is not
constructing 822 addresses, the From line can be read as such:

hp-sdd <-- noscvax
noscvax <-- mit-mc
mit-mc <-- hplabsd
hplabsd <-- hpcnou (though 4 hops)

The reply works in this case because MIT-MC saw fit to do source
routing, which is probably not a bad idea for mail coming from UUCP.

If the message came from someone on a smart UUCP site that did 822
header munging, or was on both ARPA and UUCP, the rightmost @ would be
favored, that's where the mess begins.

It is possible for UUCP sites to address outside of UUCP using bang
format.  For example, the above address could be folded into:

noscvax!hplabsd.arpa!....!hpcnou!dat

Note I left MIT-MC out of the picture.  MIT-MC just redistributed the
message -- it did not originate it, and has no right to be included in
reply text.  I suspect possible munging of From or From: lines.
However, if you insist on seeing MIT-MC in there,

noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat

Gateways/mail bridges *ought* to do the transformation between ! and 822
formats, that's what they're there for.  One of the purposes of a
gateway is to do protocol transformations on messages which is clearly
what is needed here.  No one in UUCP need know about @ or any other such
nonsense -- as long as they know the qualified names of the sites they
are sending to, they should be free to construct paths through the
gateways with legal UUCP syntax, with the gateways doing the appropriate
transformations.

--gregbo


Received: from ucbarpa by MC.LCS.MIT.EDU 19 Dec 85 17:05:03 EST
Received: by ucbarpa (5.31/1.7)
	id AA11462; Thu, 19 Dec 85 14:01:31 PST
Date: Thu, 19 Dec 85 14:01:31 PST
From: jordan@ucbarpa.BERKELEY.EDU (Jordan Hayes)
Message-Id: <8512192201.AA11462@ucbarpa>
To: header-people@mit-mc.arpa
Subject: Re:  Quiz - Parse this From line

	From: gds@sri-spam.ARPA (Greg Skinner)

	noscvax!hplabsd.arpa!....!hpcnou!dat

	Note I left MIT-MC out of the picture.  MIT-MC just
	redistributed the message -- it did not originate it, and has
	no right to be included in reply text.  I suspect possible
	munging of From or From: lines.  However, if you insist on
	seeing MIT-MC in there,

	noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat

Gregbo,

You clearly have shown your parsing skills, but I think what is missing
from this little point you made is the assumption that just because
noscvax is on the Internet that it will know about the hp site (by the
way, the original said "hplabsd" and you have "hplabsd.arpa" which does
not exist ... "hplabsd" is a nick-name for "hplabs.arpa" -- no "d" in
the .arpa-ized form. This is because the people running sendmail on
that machine have the local name go out on mail, instead of the
official name ... *sigh*)

Anyways, what i wanted to say was that the reference to mit-mc was in
fact necessary, and should indeed be included, unless you are
absolutely sure you can get to the hp site by yourself. When an
exploder is doing its work, it definately should put itself in the address.

What if I on a machine "foo" that is on a local ether with mit-mc send
to the list that redistributes to someone on a machine one UUCP hop
away from noscvax ... should the return be noscvax!foo!jordan ...? or
should it be noscvax!mit-mc.arpa!foo!jordan ...?

Although it certainly may be true that noscvax could theoretically have
an entry for foo in its /etc/hosts file (nosc, as you recall, is on
MILNET and does not need to have resolvers running yet ...) and *could*
make the smtp connection to foo itself, it should go back to mit-mc.

Manual editing of headers from list exploders is a mail wizards hobby.
Not for the children at home ...

/jordan

Received: from hplabs.ARPA by MC.LCS.MIT.EDU 31 Dec 85 17:08:09 EST
Received: by hplabs.ARPA ; Tue, 31 Dec 85 14:04:17 pst
To: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA
Date: Tue, 31 Dec 85 13:38:00 MST
From: hpcnou!dat@hplabs.ARPA (Dave Taylor)
Subject: Info on Organization wanted...
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.3b]


Hello everyone!

	I've just been reading an article in Software News about
electronic mail, and they mention a group called the "Electronic
Mail Association".   What I'd like to find it is:  has anyone
heard of the group?  Are they worth joining?  If so, how does one
contact them (ie mailing address)

More generally, does anyone know of a journal/magazine/?? that 
deals with the general electronic mail topics and issues??

Thanks!!
					-- Dave Taylor
					hpcnof!dat@HPLABS

ps: Happy New Year y'all!





Received: from OFFICE-1.ARPA by MC.LCS.MIT.EDU 31 Dec 85 18:03:09 EST
Date: 31 Dec 85 14:57 PST
From: William Daul / McDonnell-Douglas / APD-ASD  <WBD.TYM@OFFICE-1.ARPA>
Subject: Re: Electronic Mail Association
To: Header-People@MIT-MC
Message-ID: <TYM-WBD-8C8SI@OFFICE-1>

I am getting my notes off of tape regarding the EMA meeting of Nov. 14-15. When
I have them I will forward them to you.   --Bi//


Received: from hplabs.ARPA by MC.LCS.MIT.EDU  1 Jan 86 16:22:35 EST
Received: by hplabs.ARPA ; Wed, 1 Jan 86 13:18:34 pst
To: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA
Date: Wed, 1 Jan 86 13:21:55 MST
From: hpcnou!dat@hplabs.ARPA (Dave Taylor)
Subject: Another thing...
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.3b]


Speaking of electronic mail (aren't we always?) I've always been
annoyed by the plethora of blank lines appended to messages I
receive through electronic mail.  I usually have 5-10 lines blank
at the end of the message!!

What I suspect happens is that certain mailers (perhaps sendmail/rmail)
add a trailing '\n' to the last line of the file when it copies it in
from the phone line...over the course of a half-dozen hops it adds up to
a considerable percentage of the total lines of a message!!

Am I right?  Has anyone else noticed this pesky problem??

			Mailed without ANY trailing blank lines,

				from  Dave Taylor





Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU  8 Jan 86 11:35:01 EST
Received: from (R21)DDATHD21.BITNET by WISCVM.WISC.EDU on 01/08/86 at
  10:35:49 CST
Received: from THDNET (V0.11) by DDATHD21.BITNET
Date:      8 Jan 86 17:02:06 +0100
From:  XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU  (YD14@BR1.THDNET)
Subject:  Mailer problem
To:  header-people@mit-mc

We at DDATHD21.BITNET received a mail with the following header:

> Received: from columbia.edu by wiscvm.wisc.edu on 01/07/86 at 13:19:50 CST
> Received: by columbia.edu (5.31/5.10) id AA06692; Tue, 7 Jan 86 14:18:14 EST
> From: phri!pluto!warren@columbia.edu
> Received: by phri.UUCP (4.12/4.7)
>     id AA23384; Tue, 7 Jan 86 13:57:29 est
> Date: Tue, 7 Jan 86 13:57:29 est
> Message-Id: <8601071857.AA23384@phri.UUCP>
> To: XBR1YD22%DDATHD21.BITNET@wiscvm.wisc.edu
> Subject: (  deleted due to data security   )
> In-Reply-To: your article <902@caip.RUTGERS.EDU>

The header is OK.
But the mail was not addressed to "XBR1YD22" as specified in the RFC-header.
The mail was delievered to "SEISMO!X". The ARPA <-> BITNET gateway at
WISCVM truncates f.e. the user field "SEISMO!XBR1YD22" of
"SEISMO!XBR1YD22@DDATHD21.BITNET" to "SEISMO!X" because only 8 characters
are allowed in BITNET. Some mailer must have forgotten to remove the
"SEISMO!" in the transport information.

Whose mailer doesn't process such mails correctly?

Reinhard Goeth
Technical University of Darmstadt
Fed. Rep. of Germany

ARPA address:    XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU
BITNET address:  XBR1YD14 @ DDATHD21 (no NETDATA please)

Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 17:49:55 EST
Date: Wed, 22 Jan 1986  17:48 EST
From: "Karen R. Sollins" <sollins@XX.LCS.MIT.EDU>
Message-ID: <[XX.LCS.MIT.EDU].SOLLINS.22-Jan-86 16:54:01>
To:   arpanet-bboards@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA,
      msggroup@BRL-AOS.ARPA, header-people@MC.LCS.MIT.EDU,
      namedroppers@SRI-NIC.ARPA, info-nets@OZ.AI.MIT.EDU
Subject: IMPORTANT NOTICE ABOUT MC.LCS.MIT.EDU

Many rumors have been spreading about MC.LCS.MIT.EDU.  The following are the
facts:
* The maintenance contract on the machine will be discontinued at the end
  of March.

* MIT will continue to support the mail and mailing list activities that
  have run historically on MC.  After the end of March this service will
  reside on other hardware that will be named MC.LCS.MIT.EDU.

* The KL-10 will not evaporate immediately, although its name and possibly
  internet address will change.

			Karen R. Sollins
			Director of Computing Resources
			MIT/Laboratory for Computer Scinece

Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 15 Feb 86 23:45:06 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686350397650951@MIT-MULTICS.ARPA>; 15 Feb 1986 19:26:37 est
Date:        15 Feb 86 18:07 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Subject: Loop control mechanisms in mailing lists
Message-ID:  <153372@QZCOM>

Do mailing lists in Arpanet, Csnet, UUCP etc. usually contain
loop control, and if so which kind of loop control.

The most common methods for loop control are:

(1) Do not send a message to a member of the mailing list, if
that member is already in the TO, CC or BCC fields of the incoming
message, or possibly also some other field like SENDER, FROM?

(2) Save at least the Message-ID-s of the message passing the
list, and do not allow a message with the same ID to pass the
list twice.

(3) Organize the lists and sublists so that no loop occurs in
the structure.

(4) Expand all lists and sublists at one time at the original
sending of the message.

QZCOM at present uses method (1) and (2). I know that UUCP/USENET
uses method (2).

A problem with method (1) is that the name of the same recipient
can be given in many alias forms, and this will make it difficult
to understand that the name in the list and the name in the message
is the same.

A problem with method (2) is that all messages do not have any
Message-ID-s. Because of this, QZCOM always adds Message-ID-s
to messages sent to us and forwarded again from us to the nets.
At present we construct these Message-ID-s as <...@QZCOM>, but
a neater way would be to construct them from a checksum of the
from, date and contents, and then present them as <...@CHECKSUM>
as I have proposed in a message about a year ago.

I would be very interested to know which methods of loop controls
other mailing lists apply, and their experience with them.



Received: from Xerox.COM by MC.LCS.MIT.EDU 16 Feb 86 04:02:34 EST
Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 86 01:00:00 PST
Sender: "Donald W. Gillies.osbunorth"@Xerox.COM
Date: 15 Feb 86 23:54:18 PST (Saturday)
Subject: Re: Subject: Loop control mechanisms in mailing lists
From: gillies.osbunorth@Xerox.COM
To: Jacob_Palme_QZ%QZCOM.Mailnet@MIT-MULTICS.ARPA,
 header-people@MC.LCS.MIT.EDU
In-Reply-to: SenderNameTooLong%MC.LCS.MIT:EDU's message of 15 Feb 86
 20:57:54 PST (Saturday)
Message-ID: <860216-010000-3354@Xerox>


another method of loop control used by some of our mail gateways:

(5) Each host physically appends a [post]mark to the message that
identifies it as "A message already acted on here".  Refuse to process
[kill] the message if it shows up later at the same host with one of
your [post]marks still in tact.

This is a good way for a gateway to prevent looping.  However, it won't
work if you're sending mail through a dumb gateway that strips off this
information to accomplish format conversion.

				Don Gillies

Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 17 Feb 86 01:57:35 EST
Date: Sun 16 Feb 86 23:01:18-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Re:     Subject: Loop control mechanisms in mailing lists
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    header-people@MC.LCS.MIT.EDU
Message-ID: <VAX-MM(164)+TOPSLIB(114)+PONY(0) 16-Feb-86 23:01:18.SRI-IU.ARPA>
In-Reply-To: Message from
	     "       Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" of
	     15 Feb 86 18:07 +0100

I believe that Unix Sendmail counts "Received:" lines in message headers,
assuming that it has detected a mail loop if this number gets past some
threshold.  Simple but effective...

Peter
-------

Received: from USC-ISIB.ARPA by MC.LCS.MIT.EDU 17 Feb 86 13:49:46 EST
Date: 17 Feb 1986 10:47:15 PST
From: POSTEL@USC-ISIB.ARPA
Subject: loop detection by hop count
To:   header-people@MC.LCS.MIT.EDU


I think that loop detection by hop count is a bad idea.  The problem
is that it will work for awhile, until we have forgotten all about it,
then some messages that ought to go through won't.  The world will get
bigger, and what was once a reasonable choice for "max hops" will be
smaller than the diameter of the mail world.

--jon.

-------

Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 17 Feb 86 20:35:10 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686526283721442@MIT-MULTICS.ARPA>; 17 Feb 1986 20:18:03 est
Date:        17 Feb 86 21:25 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people@MC.LCS.MIT.EDU, gillies.osbunorth@XEROX.COM
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: Subject: Loop control mechanisms in mailing lists
Message-ID:  <153766@QZCOM>
In-Reply-To: <860216-010000-3354@Xerox>

Your solution of appending a postmark on the message is a variant
of my method (2). This method should have been formulated in
more general terms, to append some kind of trace information
on the message. I prefer to put the postmark in the TO field
for the following reasons:

(a) What you want to stop is not the same message looping back
to the same host. This, in fact, can be perfectly legal in some
cases. What you want to stop is the message looping back to the
same mailing list.

(b) The TO: field is one of the safest field from being munged
by header-munging systems.

Best of course would be to have an additional, special field
in the headers intended for this kind of trace information -
provided that all systems accept and are willing to handle this
trace field in the proper manner.



Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 17 Feb 86 20:35:10 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686526283721442@MIT-MULTICS.ARPA>; 17 Feb 1986 20:18:03 est
Date:        17 Feb 86 21:25 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people@MC.LCS.MIT.EDU, gillies.osbunorth@XEROX.COM
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: Subject: Loop control mechanisms in mailing lists
Message-ID:  <153766@QZCOM>
In-Reply-To: <860216-010000-3354@Xerox>

Your solution of appending a postmark on the message is a variant
of my method (2). This method should have been formulated in
more general terms, to append some kind of trace information
on the message. I prefer to put the postmark in the TO field
for the following reasons:

(a) What you want to stop is not the same message looping back
to the same host. This, in fact, can be perfectly legal in some
cases. What you want to stop is the message looping back to the
same mailing list.

(b) The TO: field is one of the safest field from being munged
by header-munging systems.

Best of course would be to have an additional, special field
in the headers intended for this kind of trace information -
provided that all systems accept and are willing to handle this
trace field in the proper manner.



Received: from dione.rice.edu by MC.LCS.MIT.EDU 17 Feb 86 22:17:23 EST
Received: by dione.rice.edu (AA21250); Mon, 17 Feb 86 21:10:19 CST
Date:     Mon, 17 Feb 86 20:48:25 CST
From: Paul Milazzo <milazzo@rice.edu>
Subject:  Re: loop detection by hop count
To: POSTEL@USC-ISIB.ARPA
Cc: header-people@MC.LCS.MIT.EDU
Message-Id: <1986.02.17.20.48.26.610.20870@dione.rice.edu>
In-Reply-To: <8602171916.AA13887@tethys>

Jon Postel writes:

        "The problem is that [loop detection by hop count] will work
        for awhile, until we have forgotten all about it, then some
        messages that ought to go through won't."

Well, I've seen some amazingly long UUCP paths recently, and that they
will get longer still seems difficult to contest.  However, the same
objection can be made to dropping packets with TTL <= 0, and the
interim solution of increasing the hop count threshold can be pushed
rather a long way.

More importantly, however, the original topic was loop detection in
*mailing lists*, and there the hop count mechanism is completely
inappropriate.  With a hop count of 30 and a queue interval of 10
minutes, a loop in a piece of personal mail will be broken within five
hours.  The same is true of a mailing list, save for a small side
effect:  as many as 30 copies of the message might be mailed to
thousands of list recipients.

In short, since even one duplicate of a mailing list message represents
an enormous waste of resources, distribution list software should
employ algorithms which can detect a loop on the first iteration.

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX
Domain:	milazzo@rice.EDU
BITNET:	milazzo@ricenet, milazzo@ricecsvm
UUCP:	{cbosgd,convex,hp-pcd,sun,ut-sally,waltz}!rice!milazzo

Received: from ucbarpa.berkeley.edu by MC.LCS.MIT.EDU 18 Feb 86 02:27:07 EST
Received: by ucbarpa.berkeley.edu (5.45/1.8)
	id AA02302; Mon, 17 Feb 86 23:24:42 PST
Date: Mon, 17 Feb 86 23:24:42 PST
From: jordan@ucbarpa.berkeley.edu (Jordan Hayes)
Message-Id: <8602180724.AA02302@ucbarpa.berkeley.edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: loop detection

I'm all for exploders that remove their real From: address and make it
a Really-From: header, so replying goes to the list and not the
sender ... then, the exploder has to look for itself in the From:
field and forward to the owner ... is this so hard or am I kidding
myself?

/jordan

Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU 18 Feb 86 09:29:52 EST
Received: from localhost by Dewey.UDEL.EDU id a029373; 18 Feb 86 9:18 EST
Reply-To: header-people@mc.lcs.mit.EDU
To: Jordan Hayes <jordan@ucbarpa.berkeley.EDU>
cc: header-people@mc.lcs.mit.EDU
Subject: Re: loop detection
In-Reply-To: Your message of Mon, 17 Feb 86 23:24:42 PST.
		<8602180724.AA02302@ucbarpa.berkeley.edu>
Date: Tue, 18 Feb 86 09:18:48 -0500
Message-ID: <29371.509120328@dewey>
From: James M Galvin <galvin@dewey.udel.EDU>

> I'm all for exploders that remove their real From: address and make it
> a Really-From: header, so replying goes to the list and not the
> sender

I don't agree.  I'm all for mail systems that require a From: field and
reject mail without it.

Actually, what you are suggesting is available internally from MMDF.
BRL wrote a list processor which changes the From: field as it is
known to the MTA's to "list-request".  This means the actual message
itself is not altered, but as the message is passed from host to host,
each host is told that the From: address is "list-request".  Now, if
we could teach the remaining mail systems to keep this information
around instead of looking in the message for it the world would be
a better place.

The next step is to teach mail user agents about a "Reply-To:" field.
If they would let you insert one then individuals could specify
to keep the discussion on the mailing list, not in his/her personal
mailbox.  Note mine.

Time to be quiet.  I am beginning to sound religious.

Jim

Received: from ucbarpa.berkeley.edu by MC.LCS.MIT.EDU 18 Feb 86 13:19:48 EST
Received: by ucbarpa.berkeley.edu (5.45/1.8)
	id AA09320; Tue, 18 Feb 86 10:17:25 PST
Date: Tue, 18 Feb 86 10:17:25 PST
From: jordan@ucbarpa.berkeley.edu (Jordan Hayes)
Message-Id: <8602181817.AA09320@ucbarpa.berkeley.edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: loop detection

	From galvin@dewey.udel.EDU Tue Feb 18 06:31:43 1986

	The next step is to teach mail user agents about a "Reply-To:"
	field.  If they would let you insert one then individuals could
	specify to keep the discussion on the mailing list, not in
	his/her personal mailbox.  Note mine.

Also note that you not only sent the list a copy, but me a personal one
as well, even though I'm on the list. Not a big deal on the internet,
but a very big deal in csnet/phonenet or UUCP world (even mailnet).

Hmmm ... you're correct about needing smarter user agents, but I think
that the concept of "mailing list" means that if you have something
to add, you should add to it, and not reply directly. So, making the
exploder claim responsibility and adding a "Reply-To:" field makes
dumb UAs send replys to the list, which is what it should do.

The problem you run into is error detection. If there is an error
somewhere down the line, mailer-daemons "return to sender" which now is
the entire list. This is bad. So, the exploder need only check for
itself in the From: field, and forward to the list maintainer.

I sorta like the idea that rn has about having an {r,R} reply to the
sender, and a {f,F} reply to the list. Not both.

/jordan

Received: from Cs by MC.LCS.MIT.EDU 18 Feb 86 15:39:42 EST
Received: from geca.cardiff.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a000780; 18 Feb 86 15:23 GMT
To:      Peter Karp <@cs.ucl.ac.uk,@cs.ucl.ac.uk:PKARP@sri-iu.arpa>
From:    Ralph Martin (on ICF GEC 4090 at Cardiff) <XACF03%geca.cardiff.ac.uk@cs.ucl.ac.uk>
Date:    Tue, 18 Feb 86 14:10 GMT
In-reply-to: <VAX-MM(164)+TOPSLIB(114)+PONY(0) 16-Feb-86 23:01:18.SRI-IU.ARPA>
Message-Id: <18 FEB 1986 14:10:46 XACF03@CFGA>
Subject: Re:     Subject: Loop control mechanisms in mailing lists
Cc:      header-people <@cs.ucl.ac.uk,@cs.ucl.ac.uk:header-people@mc.lcs.mit.edu>

Counting received lines is simple, and STUPID. How many hops do you
think your message took to reach me here in Wales ? Well, perhaps it
didn't take quite that many, but I certainly wouldn't like to rely on that !


Received: from GW.UMICH.EDU by MC.LCS.MIT.EDU 18 Feb 86 15:53:24 EST
Date: 18-Feb-86 20:47:40-UT
From: hwb@gw.umich.edu
Subject: Sun header processing (sendmail).
To:   header-people@mit-mc.arpa
cc:   hwb@GW.UMICH.EDU

Hi:
 
I have some problems in getting a Sun(3) sendmail configuration to
work with domain names. It does not necessarely need to resolve
the names via domain requests, just from hosts.txt would be fine for 
now. Does any one have a working sendmail.(main.)cf file which
would work and which I could copy?
 
	-- Hans-Werner Braun
-------

Received: from sri-spam.arpa by MC.LCS.MIT.EDU 19 Feb 86 03:08:10 EST
Received: by sri-spam.arpa (5.4/4.16)
	id AA08869; Wed, 19 Feb 86 00:07:48 PST
Date: Wed, 19 Feb 86 00:07:48 PST
From: gds@sri-spam.ARPA (Greg Skinner)
Message-Id: <8602190807.AA08869@sri-spam.arpa>
To: header-people@mit-mc.ARPA
Subject: loop control

Hello everyone.  Remember this event?

> From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV  Wed Dec 11 01:37:39 1985
> Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16)
> 	id AA01923; Wed, 11 Dec 85 01:37:39 PST
> Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST
> Return-Path: <mcvax!ace!teus>
 ...
> Message-Id: <8512101018.AA16148@sunrel1>

This was the solution I previously proposed.

> It might be the case that we also want to modify our mailers so that
> upon receipt and full delivery of a message with a given Message-ID, all
> subsequent messages received with that same Message-Id are dropped on
> the floor (no need to advise anybody automagically of duplicates, since
> we don't want to see exponential growth of looping mail :-).  I don't
> know if this is an MHS requirement or not but it is essential in a
> conferencing system (where the same messsage might come from different
> nodes in a network) and would relieve us of seeing duplicates.  The only
> problem is that not all mailers generate Message-IDs at the source of
> the message, plus a redistributor may replace (or add) its own
> Message-ID.  We should limit the number of Message-IDs to one per
> message.

Given the growing number of "conferences" (actually Usenet groups)
which are fed into the ARPA Internet as mailing lists, I think we should
honor the Message-ID's generated at their source and refuse to
process anything arriving with a Message-ID that has previously been
processed.  Although Usenet lists arrive in the ARPA Internet through
single points of entry (commonly known as "gateways"), the increasing
load to these machines may cause them to use multiple entry points.
This increases the possibility of a loop if the gateways have common
forwarding entries.  Also, in our current mail environment, mail looping
is caused for other, more obscure reasons.

I've never looked into the part of sendmail which handles Message-IDs,
but I imagine it wouldn't be too difficult to modify sendmail to refuse
to process a message with an ID which has already been processed.

There is a fundamental difference between Mailnet, Usenet and the ARPA
mailing lists, in that the ARPA lists are not currently conferenced.  I
was wondering if anyone here is on the multimedia conferencing project,
will there be standards set for converting our mailing lists into
conferences, so we can read the mail as a conference?  Also, the NNTP
work can help solve looping problems caused by generation of duplicate
postings. 

--gregbo


Received: from CSNET-SH.ARPA by MC.LCS.MIT.EDU 19 Feb 86 23:47:44 EST
To: Greg Skinner <gds@sri-spam.ARPA>
cc: header-people@mc.lcs.mit.edu, cic@CSNET-SH.ARPA
Subject: Re: loop control 
In-reply-to: Message from Greg Skinner <gds@sri-spam.ARPA>
	posted Wed, 19 Feb 86 00:07:48 PST.
Date: Wed, 19 Feb 86 23:42:37 -0500
From: Dennis Rockwell <dennis@CSNET-SH.ARPA>

	From: Greg Skinner <gds@sri-spam.ARPA>
	Date: Wed, 19 Feb 86 00:07:48 PST
	Subject: loop control

	[ ... ] I think we should
	honor the Message-ID's generated at their source and refuse to
	process anything arriving with a Message-ID that has previously been
	processed.

For end-delivery duplicate deletion, that would work OK, except in the
presence of resenders (not forwarders) that add annotations.  However, for
loop detection and breaking, the stroke is too broad; some simple cases
break down.  Consider our case (RELAY.CS.NET, admittedly not your typical
host): we see a submission go by for header-people from one of our PhoneNet
sites with message-id 1234.foo@pudunk.edu.  You scheme would have us drop
the posting of that message to everybody behind relay.cs.net!  That doesn't
seem quite right, somehow.  With more local hosts being hidden behind mail
relays (when the MX namesolver implementations percolate out), this sort of
situation will be much more common than it is now.  It's already bad for
relay.cs.net, because we'll accept any mail message that we think we can
deliver, so some sites on the Internet use us as a staging host to get to
hard-to-reach sites.

The list exploder can't change the message-id, or direct recipients wouldn't
be able to filter out duplicates.

I'm all for loop control, but more information needs to be processed to
determine whether there's been a loop.  We use a very generous hop count,
and we would like something that would catch loops sooner.  Possibly a
repeated pattern or sequence of received postmarks would do it?
Unfortunately, that requires that at least two mailers in the loop insert
postmarks (if only one mailer does, it reduces to hop count, which is
probably a good last-ditch scheme) which *most* mailers do.  Of course, any
mailer trying to do loop detection should add its own postmark before
checking for a loop!  I don't think that simply checking for our own
postmark would work, either; consider a mail message being resent (as
opposed to forwarded) to multiple people or mailing lists by multiple
senders; all messages would have the original message-id.

What heuristics do *you* use when looking at a message to detect a loop? Can
you write code that executes in reasonable time (specifically, that you
would be willing to add to the incoming message processing) to implement
it?  This isn't the AI Digest, but...

Dennis Rockwell
CSNET Technical Staff

Received: from USC-ECL.ARPA by MC.LCS.MIT.EDU 20 Feb 86 05:25:30 EST
Received: from ECLD by ECLA with DECnet; Thu 20 Feb 86 02:24:23-PST
Date: Thu 20 Feb 86 02:24:17-PST
From: Bob Larson <BLARSON%ECLD@USC-ECL.ARPA>
Subject: Re: loop control 
To: dennis@CSNET-SH.ARPA
cc: gds@SRI-SPAM.ARPA, header-people@MC.LCS.MIT.EDU, cic@CSNET-SH.ARPA
In-Reply-To: Message from "Dennis Rockwell <dennis@CSNET-SH.ARPA>" of Wed 19 Feb 86 21:17:55-PST
Message-ID: <12184828912.50.BLARSON@USC-ECLD.Internet>


It seems to me that the best idea is to have each mailing list keep
a list of message id's that have been sent to the list, and avoid
resending a message with a duplicate id.  (Preferably complaining
to the list maintainer.)  This of course does not work if something
deletes/changes the message id, so should be backed up with another
form of loop control.

(P.S: I just added mailing lists to our local prime mailer--
currently without any form of loop control.  I should probably be
planning for the future, especially since we do have a (flaky)
link to the outside world...)

Bob Larson
Blarson@Usc-Ecl.Arpa
sdcrdcf!oberon!blarson
-------

Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 20 Feb 86 11:16:10 EST
Received: by ucbvax.berkeley.edu (5.45/1.9)
	id AA18480; Thu, 20 Feb 86 07:54:49 PST
Received: from DBNGMD21.BITNET
	by ucbjade.Berkeley.Edu (4.19/4.41.3)
	id AA21631; Thu, 20 Feb 86 07:54:39 pst
Message-Id: <8602201554.AA21631@ucbjade.Berkeley.Edu>
Date:    Thu, 20 Feb 86 16:51 CET
From: Peter  Sylvester +49 228 303245             <GRZ027%DBNGMD21.BITNET@ucbvax.berkeley.edu>
Subject: Re: loop control
To: dennis@csnet-sh.arpa
Cc: gds@sri-spam.arpa, header-people@mc.lcs.mit.edu, cic@csnet-sh.arpa
To: Bob Larson <BLARSON%ECLD@usc-ecl.arpa>

Bob:

How long do You want to keep ids of old messages in Your system?
One year? Ten years? How much disk space do You have?
Although the idea is correct it is not praticable in a large
network environment I guess.

Our local mailer has mailing lists. When messages arrive from
the outside, it knows that he must not use outside addresses.
This avoids loops in that special case.

The situation we are talking about is that we have cascades of
lists with one list pointing to the other or a loop in a list.

We should try to avoid such situations:

First, we should distinguish between general redistribution lists
i.e. with lists that have a "global" target.
Those lists should not be placed into other global lists.
The second type are more local lists that cover a local node
or a subdomain. Those lists can be contained in global lists
and can contain global list when the following procedure is used:
The list processor must have a "responsibility list", i.e a list
or an algorithm to determine what members of the target are to be
selected. A special case is a "local" redistribution list.
where message are delivered to all local members when the message
comes from outside. When the message comes from a local user
the message can be delivered to all users or to remote users only
when it is known that one of the remote users is a global lists
containing this list. Even if that is not done, the local users
will get about two copies (perhaps some more if more lists are
involved.)

In addition it would be helpful to have a centralized data base
or server that contains the names of ALL global lists.
Sometimes I get messages from anywhere that tells: Now we
a have new list here at the "white house" where You can discuss
technical things about SDI or whatever.
The general problem is that normal users will have those information
earlier than a postmaster. Then it happens that a user quits his job
etc. and the postmaster has the poor job to find out the source
of the distribution, i.e all subscriptions.

"local" redistribution lists must not be contained in that
data base. only global lists, I guess there are current about
200 global list?

Peter Sylvester GMD Bonn

Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 21 Feb 86 10:46:36 EST
Received: from (MAILER)CUNYVM.BITNET by WISCVM.WISC.EDU on 02/21/86 at
  09:44:46 CST
Received: by CUNYVM (Mailer X1.23) id 2386; Fri, 21 Feb 86 10:41:31 EST
Date:         Fri, 21 Feb 1986 10:36 EST
From:           Henry Nussbacher  <HJNCU%CUNYVM.BITNET@WISCVM.WISC.EDU>
Subject:      Stopping loops
To:  <header-people@mc.lcs.mit.edu>

This may not be the best method but it works for me today and for Annette
Deschon who manages the gateways that respond to mail for Telemai/Mcimail/
Dialcom.  We scan the From: line for one of the following character strings:

MAILER SMTPUSER DAEMON DATABASE POSTMAN POSTMAST MMDF SUBSYSTEM

If the From field contains one of these character strings the mail is
placed in a holding area and is not processed until there is some
human intervention.  I would prefer to see a special RFC header that
indicates that the mail being received was created by a program and not
by a human but I guess that will never happen.  In the meantime, this
works for Database@Bitnic.Bitnet and has stopped countless loops between
networks and within Bitnet.

Hank

Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 21 Feb 86 17:33:35 EST
Date: Fri 21 Feb 86 14:17:58-PST
From: Peter Karp <KARP@SUMEX-AIM.ARPA>
Subject: Minor correction
To: header-people@MC.LCS.MIT.EDU
Reply-To: Peter D. Karp <PKarp@SRI-IU>
Message-ID: <12185220976.41.KARP@SUMEX-AIM.ARPA>

I made a slight error in my previous message in refering to ancestors
and descendants of packets interchangeably.  A loop occurs when a packet
that is a (proper or not) descendant of a packet you have seen before
arrives and is destined for the same recipients.  A packet which is a 
proper ancestor of a packet you've seen before may or may not have
looped (one of the packets in my example falls under this category).

Peter
-------

Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86  19:12:02 EST
Date: Fri 21 Feb 86 19:11:46-EST
From: Robert Lenoil <LENOIL@DEEP-THOUGHT.MIT.EDU>
Subject: Re: FYI 
To: info-nets@OZ.AI.MIT.EDU
cc: header-people@MC.LCS.MIT.EDU
Message-ID: <12185241694.19.LENOIL@DEEP-THOUGHT.MIT.EDU>

I had heard that there was a field for bouncing messages, but that it is
no longer used because other networks do bad things with that address.
Personally, I'd like to see a "Errors-To:" field become a standard on the
internet.  Another possibility would be a field that simply says don't
bounce at all; sort of the mail equivalent of a datagram, i.e. an unreliable
mail message.  Such a field would look like "Don't-Return:", or perhaps an
"Errors-To:" field with a blank address.

BTW, the appropriate place for this discussion is probably header-people@mc.
I've remailed the previous articles in this discussion there, and suggest
that interested persons start reading header-people - they talk about just
this kind of stuff.

Robert Lenoil
-------

Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 22 Feb 86 14:19:55 EST
Date: Fri 21 Feb 86 11:47:35-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Mail looping
To: header-people@MC.LCS.MIT.EDU
Cc: pkarp@SRI-IU.ARPA
Message-ID: <VAX-MM(174)+TOPSLIB(114)+PONY(0) 21-Feb-86 11:47:35.SRI-IU.ARPA>

I believe I have at least a good theoretical understanding of how
to prevent mail loops.  In the previous messages on this topic it
hasn't been clear to me how one could theoretically prevent mail
loops, or if this is even possible.  I believe I do know how to do
it in theory; if you all buy this argument then we can talk about
the implementation later.

I apologize if this is obvious to everyone; it wasn't obvious to me and on
re-consideration of the messages I've seen it still doesn't appear obvious.

Consider the following example.  A message originates on Host-A, and is
set to a mailing list called "LIST@Host-B".  One element of LIST on Host-B
is the address SUB-LIST-1@Host-C.  An element of SUB-LIST-1 on Host-C is
SUB-LIST-2@Host-B, from which it gets distributed to various individuals.
Let us postulate that the original message was also set to "USER@Host-B",
and that  "USER@Host-B" is also a member of SUB-LIST-1. Thus,
"USER@Host-B" should receive two copies of the message: one direct from
Host-A, and one with return path: @Host-C,@Host-B:Originator@Host-A.

Notice that the "same message" gets routed through Host-B several times,
and that it would be incorrect for Host-B to think it has detected a loop
simply based on the Message-ID created by the message originator (this has
been pointed out before).  Also note that the "same message" gets sent to
the same recipient several times (USER@Host-B), and it would also be
incorrect for Host-B to suppress the duplicate simply because it sees two
messages with the same Message-ID going to the same recipient.  Both of
these conditions look like loops but are not.


So, what's the solution?  Consider an abstraction.  Imagine that a mail
message is simply a packet getting switched between the nodes of a
network. Mail packets are special in that any one packet can be duplicated
into several other packets at other nodes as mailing lists are expanded.
These child packets then go their own way in the network.  There are two
strcutures of interest here.  One is the path a given packet follows through
the network. The other is the mailing-list-based packet-synthesis tree
which shows how one initial message packet gets duplicated into a whole
swarm of child packets which eventually get either dropped on the floor or
land in someone's mailbox.

A loop condition occurs when a packet P with the following properties has
arrived at a network node:
	a) either that same packet or one of its ancestors in the packet-
	synthesis tree, P',  has been to that node before.

	b) Packet P and packet P' were both addressed to the same
	recipient.

How can a host detect a loop condition?  Simple: when it relays a packet
it puts a mark on that packet which it will recognize if that packet or
any of its descendants ever arrives at that host again.  It also must record
what recipients the packet was destined for, and check all incoming
packets to determine if it has seen them or an ancestor of theirs before,
addressed to the same recipient(s).


So again, if this looks right we can start worrying about implementation.


Peter
-------

Received: from UCI.EDU by MC.LCS.MIT.EDU 23 Feb 86 07:00:27 EST
Received: from localhost by UCI.EDU id a004810; 22 Feb 86 15:39 PST
To: header-people@mc.lcs.mit.edu
Subject: Re: Mail looping
In-reply-to: Peter Karp <PKARP@sri-iu.arpa> message of Fri 21 Feb 86.
             <VAX-MM(174)+TOPSLIB(114)+PONY(0) 21-Feb-86 11:47:35.SRI-IU.ARPA>
Date: Sat, 22 Feb 86 15:39:26 -0800
Message-ID: <4807.509499566@uci.edu>
From: Einar Stefferud <stef@UCI.EDU>

Long ago in a discussion group not too far away, we discussed one
aspect of this "distribution" problem that I think is relevant in this
current looping discussion.  The original topic was failure return
addresses, and hinged on the question of what is legit for a
distributor to do to a message it is distributing to a list.

Can it ethically and morally change the From: Sender: Reply-to: or
Return-Path: fields to divert mail the might result from downstream
events like failure, or reply, or whatever.

Also, is it a violation of the sanctity of the seal for a LIST
DISTRIBUTOR to look inside the header in the first place.

As I recall the discussion, it was concluded that a LIST DISTRIBUTOR is
in fact operating as a "USER AGENT" and not as a "MAIL TRANSFER AGENT"
so it is fine for the list distributor to do anything its administrator
wants it to do to the content of any distributed item.  If there is any
kind of contract between the administrator and the subscribers, it is
that agreement that governs the administrator's actions.

With this in mind, it seems simple enough to me for any LIST
DISTRIBUTOR to put a special header field (like DIST-ID: <unique-id>)
which is can look for in any incoming item.  If it sees such a thing it
should shunt it aside for manual inspection, and this will prevent
loops through that LIST DISTRIBUTOR, as long as no intervening transfer
agants or user agents or LIST DISTRIBUTORS, et al, remove or change the
magic <unique-id> in any DIST-ID: fields.

This does not take care of other kinds of loops, but it would simply
take care of LIST DISTRIBUTOR LOOPS.

For those of you who are wondering what was decided about the earlier
failure return question, we simply decided to have the list distributor
insert a new "RETURN-PATH: list-request@host" field in place of the
original RETURN-PATH field, without deciding what to do with the old one.

 ---- Stef

Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 26 Feb 86 01:21:51 EST
Received: by ucbvax.berkeley.edu (5.45/1.9)
	id AA12821; Tue, 25 Feb 86 22:21:04 PST
Received: by ucbjade.Berkeley.Edu (4.19/4.41.3)
	id AA24895; Tue, 25 Feb 86 21:41:33 pst
Date: Tue, 25 Feb 86 21:41:33 pst
From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO)
Message-Id: <8602260541.AA24895@ucbjade.Berkeley.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: Mail looping

Handling of mailing list error messages (Reply-to, Errors-to, etc) was
discussed at length in this mailing list group about a year or two ago.

The final conclusion was that "mailing list exploders" should generate
a new message (ie. with a new Message-ID). (The "Errors-to" header was
also disapproved if I remember rightly.)

In reply to:

	Date: Fri 21 Feb 86 11:47:35-PST
	From: Peter Karp <PKARP@sri-iu.arpa>
	Subject: Mail looping
	To: header-people@mc.lcs.mit.edu
	Cc: pkarp@sri-iu.arpa
	Message-Id: <VAX-MM(174)+TOPSLIB(114)+PONY(0)
		21-Feb-86 11:47:35.SRI-IU.ARPA>

	... Thus,
	"USER@Host-B" should receive two copies of the message: one direct from
	Host-A, and one with return path: @Host-C,@Host-B:Originator@Host-A.

The first message would have the original Message-ID and the new message
would have a new Message-ID generated by the exploder.

	Notice that the "same message" gets routed through Host-B
	several times, and that it would be incorrect for Host-B to
	think it has detected a loop simply based on the Message-ID
	created by the message originator (this has been pointed out
	before).  Also note that the "same message" gets sent to the
	same recipient several times (USER@Host-B), and it would also
	be incorrect for Host-B to suppress the duplicate simply
	because it sees two messages with the same Message-ID going to
	the same recipient.  Both of these conditions look like loops
	but are not.

To avoid this problem, I suggest that each SUB-LIST exploder also replace
the Message-ID with a new Message-ID. (ie. Mailing list exploders at any
level should generate a new message.)

The mail exploder should also change the envelope and/or mail heading so
that error messages are returned to that exploder's administrator.
(ie. to the lowest level exploder).

There is a basic assumption about mailing lists that may be wrong.  Can
we assume that list mail goes from the root to all branches without going
through the same node twice?

Bill Wells
netinfo%ucbjade@Berkeley.EDU

Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 26 Feb 86 04:22:01 EST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 26 Feb 86 01:06:19-PST
Date: Wed 26 Feb 86 00:12:44-PST
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject: Re: Mail looping
To: netinfo%ucbjade@UCBVAX.BERKELEY.EDU
cc: header-people@MC.LCS.MIT.EDU
In-Reply-To: <8602260541.AA24895@ucbjade.Berkeley.Edu>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12186377826.8.MRC@PANDA>

Bill Wells -

     You cannot assume that list mail goes from the root to all branches
without going through the same node twice.  This is especially true with
mailers which do not differentiate between "mail exploders", "mail aliases",
and "mail forwardings".  Add to this swamp the large numbers of individuals
who regularly use multiple hosts (I have two primary, two secondary, and
dozens of tertiary Internet hosts in addition to my DEC-20 at home) and
who have "classed mailboxes" and forwardings all over the place and it isn't
hard to see how you can lose big.

     I'd argue that if you really care about loop abatement you will use
what SMTP provides to help you out from this -- the EXPN command.  That is,
the sender fully resolves the destination list.  It isn't hard to detect
loops when you do this.
-------

Received: from su-pescadero.arpa by MC.LCS.MIT.EDU 26 Feb 86 12:26:17 EST
Received: by su-pescadero.arpa with Sendmail; Wed, 26 Feb 86 09:25:43 pst
Date: Wed, 26 Feb 86 09:25:43 pst
From: Joseph I. Pallas <pallas@Pescadero>
Subject: Re: Mail looping
To: MRC%PANDA@sumex-aim.ARPA, netinfo%ucbjade@UCBVAX.BERKELEY.EDU
Cc: header-people@MC.LCS.MIT.EDU

Mark, you of all people should know just how futile it would be to attempt
to resolve the entire destination list of a message using EXPN.  Aside from
the fact that some of the destinations may go outside of SMTP, there's no
guarantee that EXPN will return meaningful information.  Several implementations
don't support it, and most that do don't deal correctly with naming-domain
boundary crossings (including yours).

joe

Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 26 Feb 86 14:13:43 EST
Date:           Wed, 26 Feb 86 10:57:10 PST
From:           Rich Wales <wales@LOCUS.UCLA.EDU>
To:             HEADER-PEOPLE@MC.LCS.MIT.EDU
Subject:        Non-domain host names in mail
Message-ID:     <509828230-13014-wales@DIANA.LOCUS.UCLA.EDU>

[NOTE:  I had planned to send this message out several weeks ago, but a
mail problem at MC.LCS.MIT.EDU -- which apparently put the Header-People
mailing list out of commission for a while -- got in the way.  Apologies
for any of the following information which is out of date. -- RBW]

Here's yet another chapter in the ongoing saga of "bad" and "semi-bad"
host names in mail.  This message has to do with "non-domain-style" host
names (i.e., nicknames which appear in the NIC host name table, but
which do not contain periods).  A subsequent message will discuss host
names which do not appear in the NIC table at all.

The following non-domain-style host names were observed in connection
with mail received by LOCUS.UCLA.EDU between 6 December 1985 and 15 Jan-
uary 1986.

Most of these names could be converted into valid (i.e., defined)
domain-style names by adding ".ARPA" to them.  Those names which do not
occur with the ".ARPA" suffix in the NIC host name table are indicated
by asterisks.

Since non-domain-style host names are NEVER going to be listed in the
domain data base, I would strongly encourage the hosts listed below to
stop using them NOW and use the correct domain-style names instead.

************************************************************************
*    I would also again urge the NIC to set a deadline for phasing     *
*    all non-domain-style names out of the host name table.  (Note     *
*    that I am NOT advocating that ALL nicknames be removed -- only    *
*    that nicknames without periods be removed.)  No matter what       *
*    anyone may say about transition to the domain data base -- and    *
*    no matter what anyone may say about only using a host's           *
*    "official" name -- the fact remains that as long as these names   *
*    appear in the table, people are going to continue to use them.    *
************************************************************************

Also, I would suggest again to those hosts which are using the domain
data base that -- when they see a non-domain-style nickname in a mail
address -- they should try adding ".ARPA" to the name and look up the
result in the data base before giving up.  This should be thought of as
a temporary "hack", to get around the unfortunate fact that it is likely
to be some time before non-domain-style nicknames have been utterly and
completely eradicated from our midst.

Before anyone asks:  I am NOT going to try to send individual letters to
system adminstrators about this issue this time.  The last time I did
this, I got very few responses.  Most people seemed to simply ignore me
(witness the size of the lists below!).  One person (who shall remain
nameless unless he chooses to make himself known) even said he planned
to keep on using his non-domain-style nickname, because he liked to make
waves!  Predictably, said host is still on my list, and the wizard in-
volved is no doubt very proud of this fact.  Sigh.

My apologies for any typos which might have made it into this list.
Also, my apologies if any hosts listed below have since fixed things.

Again, host names indicated below with (*) do not have ".ARPA" counter-
parts; an attempt (as described above) to make sense of these names by
tacking ".ARPA" onto them would fail.

(1) Non-domain-style host names used in return addresses of mail:

    Name used       Domain-style name
    =================================
    AERO (*)        AEROSPACE.ARPA
    AIDS-UNIX       AIDS-UNIX.ARPA
    BBNCCM          BBNCCM.ARPA, CCM.BBN.COM
    BBNCCP          BBNCCP.ARPA
    CIT-750         CIT-750.ARPA, CIT-750.CALTECH.EDU
    FORD-WDL1       FORD-WDL1.ARPA
    GLACIER (*)     SU-GLACIER.ARPA, GLACIER.STANFORD.EDU
    GSWD-VMS        GSWD-VMS.ARPA
    HPLABSD (*)     HPLABS.ARPA
    LASSPVAX        LASSPVAX.ARPA, LASSPVAX.TN.CORNELL.EDU
    MEDEA (*)       MEDEA.BERKELEY.EDU
    NRL-AIC         NRL-AIC.ARPA
    PARCVAX         PARCVAX.ARPA, PARCVAX.XEROX.COM
    SRI-SPAM        SRI-SPAM.ARPA
    SRI-UNIX        SRI-UNIX.ARPA
    SU-PSYCH        SU-PSYCH.ARPA, PSYCH.STANFORD.EDU
    TOR (*)         NTA-VAX.ARPA
    UMN-UCC-VA      UMN-UCC-VA.ARPA
    YALE-VENUS      YALE-VENUS.ARPA

(2) Non-domain-style host names used in SMTP HELO commands:

    Name used     Address         Domain-style name
    ===============================================
    ALMSA-1       26.1.0.61       ALMSA-1.ARPA
    ATHENA (*)    18.58.0.1       MIT-ATHENA.ARPA, ATHENA.MIT.EDU
    BBNCCM        8.7.0.14        BBNCCM.ARPA, CCM.BBN.COM
    BBNCCP        8.2.0.4         BBNCCP.ARPA
    FORD-WDL1     128.5.32.1      FORD-WDL1.ARPA
    GLACIER (*)   36.40.0.205     SU-GLACIER.ARPA, GLACIER.STANFORD.EDU
    HPLABSD       192.5.58.10     HPLABS.ARPA
    MEDEA (*)     128.32.0.15     UCBMEDEA.ARPA, MEDEA.BERKELEY.EDU
    MEDIA-LAB     18.85.0.2       MEDIA-LAB.ARPA, MEDIA-LAB.MIT.EDU
    MIT-EDDIE     18.62.0.6       MIT-EDDIE.ARPA, EDDIE.MIT.EDU
    NRL-AIC       26.1.0.8        NRL-AIC.ARPA
    NRL-CSS       192.5.17.112    NRL-CSS.ARPA
    PREP (*)      128.52.22.14    MIT-PREP.ARPA, PREP.AI.MIT.EDU
    SU-PSYCH      36.36.0.202     SU-PSYCH.ARPA, PSYCH.STANFORD.EDU
    UCBARPA (*)   10.0.0.78       UCB-ARPA.ARPA, UCBARPA.BERKELEY.EDU
    YALE (*)      10.2.0.9        YALE-GW.ARPA

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@LOCUS.UCLA.EDU  -or-  wales@UCLA-LOCUS.ARPA
	UUCP:   ...!(ucbvax,ihnp4)!ucla-cs!wales

Date: Wed, 26 Feb 86 15:05:40 EST
From: David Vinayak Wallace <GUMBY@MC.LCS.MIT.EDU>
Subject:  Mail looping
To: netinfo%ucbjade@UCBVAX.BERKELEY.EDU
cc: HEADER-PEOPLE@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 25 Feb 86 21:41:33 pst from netinfo%ucbjade at BERKELEY.EDU (Postmaster + BITINFO)
Message-ID: <[MC.LCS.MIT.EDU].831513.860226.GUMBY>

    Date: Tue, 25 Feb 86 21:41:33 pst
    From: netinfo%ucbjade at BERKELEY.EDU (Postmaster + BITINFO)

    The final conclusion was that "mailing list exploders" should generate
    a new message (ie. with a new Message-ID). (The "Errors-to" header was
    also disapproved if I remember rightly.)

    ...I suggest that each SUB-LIST exploder also replace
    the Message-ID with a new Message-ID. (ie. Mailing list exploders at any
    level should generate a new message.)

What if I accidentally get two compies of a message?  If they've come
through different forwarders there'll be no way for my mail reader do
detect this condition and delete excess copies.

Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 27 Feb 86 00:35:42 EST
Received: by ucbvax.berkeley.edu (5.45/1.9)
	id AA03981; Wed, 26 Feb 86 21:33:48 PST
Received: by ucbjade.Berkeley.Edu (4.19/4.41.3)
	id AA14125; Wed, 26 Feb 86 21:33:24 pst
Date: Wed, 26 Feb 86 21:33:24 pst
From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO)
Message-Id: <8602270533.AA14125@ucbjade.Berkeley.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: Mail looping

In reply to:

	Date: Wed 26 Feb 86 00:12:44-PST
	From: Mark Crispin <MRC%PANDA@sumex-aim.arpa>
	Subject: Re: Mail looping
	Message-Id: <12186377826.8.MRC@PANDA>

	     I'd argue that if you really care about loop abatement you will
	use what SMTP provides to help you out from this -- the EXPN command.
	That is, the sender fully resolves the destination list.  It isn't
	hard to detect loops when you do this.
	-------

Unfortunately, mail lists are not limited to the SMTP/RFC822 mail world. So
this is only a partial solution.  I suspect there is not one fail-safe method
and that a varies of methods will be needed to used to reduce looping.

One alternative that is less subject to looping is the USENET news distribution
system.  It is available for Unix systems and shortly will be available for
IBM CMS systems. I would prefer to see large mailing lists converted to
news groups. It is much nicer to see one message going between news/conference
systems than to see several duplications of the same message resulting
from mail list explosion being transmitted.  I suggest that the USENET
article/batch formats be adopted as a standard method of transporting
collective address messages between news and conferencing systems.

Bill Wells
netinfo%ucbjade@Berkeley.EDU

Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 FEB 86  05:16:11 EST
Date: Thu, 27 Feb 86 05:18:43 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: Request to be added to Header-People
To: BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU
cc: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].16642.860227.CENT>

    Date: 26 FEB 86 09:49-CST
    From:  BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU
    To:  HEADER-PEOPLE-REQUEST@MIT-MC.ARPA
    Subject: Request to be added to Header-People
    This is a request to be added to the Header-People distribution list.
    I do not know if it is reasonable for you to do this but I am
    interested in seeing the activity in this group.  My mail address is
    not on Internet but on BITNET; please try to let me know if this cannot
    be handled.  Thanks for considering my request.  My mail address is:
	    BURNUM@VANDVMS1.BITNET
    or possibly
	    BURNUM%VANDVMS1.BITNET@WISCVM.ARPA
    if the BITNET node names are not immediately known to your mail router.
					    Denson Burnum
					    Vanderbilt University

what's a -REQUEST list for but to deal with exactly this sort of situation?
welcome to Header-People. recent mail to this list lives in the file
KSC;HEADER MINS on MC, with older archives in KSC;HEADER MINS09 through
MINS14. these files are accessible via FTP over the Arpanet; beyond there
is up to you.

Received: from USC-ECL.ARPA by MC.LCS.MIT.EDU 27 Feb 86 16:49:23 EST
Received: from ECLD by ECLA with DECnet; Thu 27 Feb 86 13:45:01-PST
Date: Thu 27 Feb 86 13:44:34-PST
From: Bob Larson <BLARSON%ECLD@USC-ECL.ARPA>
Subject: Mail looping, changing message ID
To: header-people@MC.LCS.MIT.EDU
Message-ID: <12186787760.51.BLARSON@USC-ECLD.Internet>

Changing the message ID is counter-productive in detecting mail looping.
(Adding one if there isn't one isn't.)  Take the trivial case where list
A and list B have each other as members.  List A changes the message ID,
sends the message to B who changes the message ID and sends it back to A.
A hasn't seen the message with B's new ID, so the process continues...
This is also a very bad idea for mailing lists gated to usenet newsgroups.
Usenet normally has loops purposefully put in its newsgroup distribution,
(to reduce the time it takes to get any specific message, and to add reliability
by redundancy) which are taken care of by unique message IDs.  There has
been a proposal (in testing, I think) for multiple arpanet to usenet
gateways for arpa mailing lists, increasing this redundancy.  This would
be broken by changing message IDs.

There are numerous good reasons for not expanding a mailing list on one
host.  One is the world isn't SMTP, so it won't discover the hard to find
loops anyway.  Another is some hosts probably will answer with local only
addresses.  (Do you know how to get mail to ECLD, KYLARA, and HARVEY?
ECLA (usc-ecl.arpa) does.)  Probably the biggest objection is the load
it places on the originating host and the network.  There are already
problems with duplicated messages due to hosts crashing in the middle
of sending a message to a long list.  

Bob Larson <BLarson@Usc-Ecl.Arpa>
-------

Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU  9 Mar 86 19:34:07 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2688251359663107@MIT-MULTICS.ARPA>; 09 Mar 1986 19:29:19 est
Date:        19 Feb 86 00:42 +0100
From:        Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@MC.LCS.MIT.EDU
Subject:     Re: loop detection
Message-ID:  <154125@QZCOM>
In-Reply-To: <29371.509120328@dewey>

Loop detection == Group Distributor Agent (GDA) answering the
question "Have I seen this message before?".

"this message" can be identified by its MessageID.

"seen before" = "MessageID IN GDA.distribution_log"

Therefore,

1) Require unique MessageID's on all messages passing a GDA.
   If one is missing, generate one!

2) Teach GDA's to generate a sufficiently large round-robin log
   of MessageID's that have passed.

3) Do not (re-)distribute a message if its MessageID is in this
   log.

4) (. Call the network police to extrincate any system that removes
   an existing MsgID .)

This will (I think) be a solution for X.400 too, provided that
either (a) the GDA resides in both P1 and  P2 space, or (b) the
P1.UaContentID is made mandatory and == P2.Heading.IPMessageID.

This means that all the Via's (Recieved-by, P1.TraceInformation)
can be discarded in this matter.

I have a feeling that one could mathematically prove that (for
messages involved) "the set of GDA-log's is equivalent to the
set of all P1.TraceInformation", just differently distributed.

Comments?

Tommy




Received: from SIMTEL20.ARPA by MC.LCS.MIT.EDU 30 Apr 86 09:59:54 EDT
Date: Wed 30 Apr 86 07:58:46-MDT
From: William G. Martin <WMartin@SIMTEL20.ARPA>
Subject: When you know you'll have problems
To: header-people@MC.LCS.MIT.EDU
cc: WMartin@SIMTEL20.ARPA, wmartin@ALMSA-1.ARPA
Message-ID: <12202955893.16.WMARTIN@SIMTEL20.ARPA>

Hi!
Haven't seen any "header-people" traffic for some months now, so I don't
know if the list is still active, or this address (wmartin@simtel20) got 
dropped off, or what... Anyway, I thought I'd try the "MIT-MC" list
address, since it was still listed in the Interest-groups file at SRI-NIC
as being valid, even though I expected MIT-MC list addresses to stop being
usable. Hope this gets through.

Anyway, the point of this is to ask the following question: I'm an
administrative-type systems administrator on the ALMSA-1 host. (Not
a mail maintainer -- that's handled by another division -- in case that
is important.) Every now and then, we know in advance that our system
will be off the net for some extended period of time, like three days
for air conditioning work [which just happened this past weekend].
I know that there are some mailer systems that will only queue mail for
three days (the one here at Simtel20, for example) and will then bounce
it back to the sender as undeliverable. In this particular instance,
not only were we down for the expected three days, but some other
problems delayed our coming back on the net in a fully-operational mode
for some time after that. So I am sure that some mail to us, from various
sites across the network(s), was either lost, or sent back as 
"undeliverable".

Is there anything I can do, prior to our having such scheduled downtime,
or, from another host [like I am sending this message], during such
downtime or times of system troubles, to automatically inform the net
that any mail addressed to "ALMSA-1" addressees should be treated
differently than usual -- maybe to extend the automatic cut-off timer
for some extra number of days, or to expect system difficulties and
only attempt sending on a more infrequent interval, so that other systems
don't waste their resources trying to send to us every 15 minutes for the
whole time we are down or unavailable?

In the past, I've sent messages to the "ARPA-BBOARDS" address to inform
people of this, but that is slow, and also a manual process; I don't want 
to pester people to do something manually about this -- I would like to
send out some sort of "control" message that would interact with the
mail system automatically and inform it about this, maybe turning on some
switch or flag associated with my host's name. Then, when things are
fixed, I could send another "control message" turning off such flags.

Does this exist, or has such a mechanism been proposed?

Will Martin
-------

Date: Thu,  1 May 86 03:50:27 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: list moving
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].33378.860501.CENT>

The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now
as AI.AI.MIT.EDU.  Recent mail to the list lives in the file 
KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09
through MINS14, also on AI.  These files are trivially accessible over the
Arpanet via FTP; we regret that this is not of much help to those list
members not on the Arpanet.

Please remember to address your add/remove/change requests to
HEADER-PEOPLE-REQUEST@AI, not to the main list.

This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS
mailer daemon, is fixed.  It no longer has to keep the host tables in its
address space, which leaves all that room to be taken up by other data,
like longer messages.  A lot of mail, especially to lists like this which
live on ITSs, has been sidetracked over the past few months while the local
hackers were fixing COMSAT.  We expect to start sending out this backlog
during the next week; the process will take several days, in order to avoid
overloading COMSAT or overworking us.  An ArpaNet-BBOARDS msg explaining
this retransmission will be broadcast sometime in the next few days.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 MAY 86  13:22:42 EDT
Received: from SH.CS.NET by MC.LCS.MIT.EDU  1 May 86 13:20:38 EDT
To: "William G. Martin" <WMartin@SIMTEL20.ARPA>
cc: header-people@MC.LCS.MIT.EDU, wmartin@ALMSA-1.ARPA, cic@SH.CS.NET
Subject: Re: When you know you'll have problems 
In-reply-to: Message from "William G. Martin" <WMartin@SIMTEL20.ARPA>
	posted Wed 30 Apr 86 07:58:46-MDT.
Date: Thu, 01 May 86 13:10:52 -0500
From: Dennis Rockwell <dennis@SH.CS.NET>

	From: "William G. Martin" <WMartin@SIMTEL20.ARPA>
	Subject: When you know you'll have problems

	Is there anything I can do [ ... ] to automatically inform the
	net that any mail addressed to "ALMSA-1" addressees should be
	treated differently than usual [ ... ]

If the domain server system were more stable, you could request that your
domain server replace your address and MX records with an MX pointing to
some host that you know will hold the mail for a period comfortably longer
than your downtime.  Of course, this will only help those hosts whose
mailers look at MX records (not just A records), which will not include the
MILnet community or the Sendmail users for quite some time.

Dennis Rockwell
CSNET Technical Staff

Date: Thu,  1 May 86 21:59:36 EDT
From: John Whorfin <WHORFN@AI.AI.MIT.EDU>
Sender: SRA@AI.AI.MIT.EDU
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].4.860501*XPER*.SRA>

this is a test message. please ignore it.

Date: Thu,  1 May 86 22:32:20 EDT
From: John Whorfin <WHORFN@AI.AI.MIT.EDU>
Sender: SRA@AI.AI.MIT.EDU
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].6.860501*XPER*.SRA>

this is a test message. please ignore it.

Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86  03:56:42 EDT
Date: Fri,  2 May 86 03:56:38 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: open mouth, insert foot
To: HEADER-PEOPLE@AI.AI.MIT.EDU
cc: BUG-MAIL@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].33875.860502.CENT>

Moving this list to AI shook loose a number of bugs, probably within the
timing of the ITS address resolver rather than inside COMSAT.  This sad
situation is being worked on.  Until it is corrected, HEADER-PEOPLE is
moved back to MC, which being a KL runs faster than AI (a KS).

Date: Fri, 16 May 86 21:14:09 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: testing
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].42071.860516.CENT>

This is a test of COMSAT, the mailer that is shot from gunz.

Received: from WISCVM.WISC.EDU by AI.AI.MIT.EDU 19 May 86 14:11:04 EDT
Received: from (XBR1YD14)DDATHD21.BITNET by WISCVM.WISC.EDU on 05/19/86
  at 13:09:50 CDT
Received: from BR1.THD.DA.D.EUROPE by DDATHD21.BITNET
          via GNET with RJE ; 19 May 86 20:00:12
Date:     Mon, 19 May 86 19:58:24 +0200
From:  XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU  (Reinhard Goeth - TH
  Darmstadt HRZ)
Subject:  Timezone
To:  HEADER-PEOPLE@AI.AI.MIT.EDU ,
    XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU
X-VMS-To:
  X%"HEADER-PEOPLE%AI.AI.MIT.EDU@WISCVM.WISC.EDU",X%"XBR1YD14%DDATHD21.B
 ITNET@WISCVM.WISC.EDU"

What's the timezone code for Central European Time?
Some nodes use +0100 others use -0100.
I think +0100 (or A military time) is correct.
So for example EST would be equivalent to -0500 or R.
Is that correct?

Regards Reinhard Goeth (Techn. Univ. of Darmstadt; Fed. Rep. of Germany)

Received: from SPHINX.LOCUS.UCLA.EDU by AI.AI.MIT.EDU 19 May 86 16:47:38 EDT
Date:           Mon, 19 May 86 13:09:02 PDT
From:           Rich Wales <wales@LOCUS.UCLA.EDU>
To:             Reinhard Goeth <XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU>
CC:             HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:        Re: Timezone
Local-Timezone: PDT (Pacific Daylight Time -- GMT-7h, -0700, or T)
In-reply-to:    Message of Mon, 19 May 86 19:58:24 +0200
                    from "XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU
                        (Reinhard Goeth - TH Darmstadt HRZ)"
Message-ID:     <860519.200902z.13298.wales@DIANA.LOCUS.UCLA.EDU>

Reinhard --

Replying to your message:

	What's the timezone code for Central European Time?
	Some nodes use +0100 others use -0100.
	I think +0100 (or A military time) is correct.
	So for example EST would be equivalent to -0500 or R.
	Is that correct?

That is correct.  Central European Time is indeed "+0100" or "A" (in
summer, "+0200" or "B").  Eastern Standard Time (in North America) is
"-0500" or "R".

The sites that use "-0100" -- indeed, *any* European or Middle Eastern
sites which use a negative time zone -- are either configured wrong or
are taking a holiday in the Atlantic Ocean :-}.

With regard to the single-letter time zone designators, by the way,
ARPA RFC822 has things backwards.  I have been told by several people
(who ought to know) that "A" means GMT+1h (i.e., Central European
Time), not GMT-1h as shown on page 26 of RFC822.

I'm not sure why so many European sites seem to be using the wrong
time zone.  It might be because some people were confused by the pre-
viously mentioned mixup in RFC822 and incorrectly concluded that
"-0100" meant GMT+1h.  More likely -- at least in the case of sites
running Berkeley "sendmail" -- it might be because UNIX's internal
time zone information is set up in terms of an offset *west* of GMT
(which may make sense if you consider that all time zones in the USA,
where UNIX was first developed, are west of GMT).

In any case, though, any site in Europe or the Middle East which is
using a negative time zone for its local time stamps is *wrong* and
should fix its software.  Lest anyone accuse me of bias :-}, let me
also state that any North American site using a *positive* time zone
for its local time stamps is wrong and should fix its software.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	wales@LOCUS.UCLA.EDU     ...!(ucbvax,ihnp4)!ucla-cs!wales
"Sir, there is a multilegged creature crawling on your shoulder."

Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT
Received: by FNS1; Fri, 23 May 86 16:51:12
Date: Fri, 23 May 86 16:10:16
From: Bob Larson <R.LARSON@FNS1>
Subject: Mail headers
To: header-people%ai.ai.mit.edu@USC-ECL.ARPA
Cc: r.larson@FNS1

The message is from a mail system under developement.  (It is running
on a prime under primos.)  As far as I know, the only rfc822
violation in the headers is the lack of time zone. Does anyone see
any other violations?

This is also a test of how Usc-Ecl.Arpa mungs the From: line, if it
does.

(Message-id is a planned addition, but low priority.)

Bob Larson  R.Larson%Fns1@Usc-Ecl.Arpa  or Blarson@Usc-Ecl.Arpa


Received: from WISCVM.WISC.EDU by AI.AI.MIT.EDU 27 May 86 01:16:02 EDT
Received: from (XBR1YD14)DDATHD21.BITNET by WISCVM.WISC.EDU on 05/27/86
  at 00:14:11 CDT
Received: from BR1.THD.DA.D.EUROPE by DDATHD21.BITNET
          via GNET with RJE ; 27 May 86 03:32:35
Date:     Tue, 27 May 86 03:32:22 +0200
From:  XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU  (Reinhard Goeth - TH
  Darmstadt HRZ)
Subject:  Mail-Header
To:  Blarson@Usc-Ecl.ARPA ,
    Header-People@AI.AI.MIT.EDU
X-VMS-To:
  X%"Blarson@Usc-Ecl.ARPA",X%"Header-People%AI.AI.MIT.EDU@WISCVM.WISC.ED
 U",YD14

>Received: from AI.AI.MIT.EDU by wiscvm.wisc.edu on 05/23/86 at 23:02:48 CDT
>Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT
>Received: by FNS1; Fri, 23 May 86 16:51:12
>Date: Fri, 23 May 86 16:10:16
>From: Bob Larson <R.LARSON@FNS1>
>Subject: Mail headers
>To: header-people%ai.ai.mit.edu@USC-ECL.ARPA
>Cc: r.larson@FNS1
>
> ...
>
>Bob Larson  R.Larson%Fns1@Usc-Ecl.Arpa  or Blarson@Usc-Ecl.Arpa

Dear Bob,

I think your From-Field is wrong. It should show your address.

You should use

        From: Bob Larson <R.Larson%Fns1@Usc-Ecl.Arpa>
   or   From: Bob Larson <Blarson@Usc-Ecl.Arpa>

Regards Reinhard Goeth (Techn. Univ. of Darmstadt - Comp. Center)

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86  14:02:55 EDT
Received: from hplabs.ARPA by MC.LCS.MIT.EDU 27 May 86 14:02:34 EDT
Received: from hpldat by hplabs.ARPA ; Tue, 27 May 86 11:00:17 pdt
Received: by hpldat ; Tue, 27 May 86 11:04:08 pdt
From: Dave Taylor <taylor%hpldat@hplabs.ARPA>
Message-Id: <8605271804.AA05956@hpldat>
To: Header-People@mit-mc
Date: Tue, 27 May 86 11:04:04 PDT
Subject: Mail headers (from Bob Larson)
Organization: Hewlett-Packard Laboratories, Knowledge Technologies Lab.
X-Mailer: ELM [version 1.0]


Bob Larson asked if his headers are okay...

 Well, here's what I received;

 From @AI.AI.MIT.EDU:R.LARSON%FNS1.#USCnet@USC-ECL.ARPA Fri May 23 19:00:41 1986
 Received: from hplabs.ARPA by hpldat ; Fri, 23 May 86 19:00:35 pdt
 Message-Id: <8605240200.AA04767@hpldat>
 Received: from AI.AI.MIT.EDU by hplabs.ARPA ; Fri, 23 May 86 18:55:58 pdt
 Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT
 Received: by FNS1; Fri, 23 May 86 16:51:12
 Date: Fri, 23 May 86 16:10:16
 From: Bob Larson <R.LARSON@FNS1>
 Subject: Mail headers
 To: header-people%ai.ai.mit.edu@USC-ECL.ARPA
 Cc: r.larson@FNS1

	[message body]

My comments on the above;

  First off, that's a pretty damn bizarre return address!  In fact, this
could possibly be a honourable mention in the strange addresses contest!
The question of parsing becomes pretty incredible with this;

    @AI.AI.MIT.EDU:R.LARSON%FNS1.#USCnet@USC-ECL.ARPA 

If my local mailer knows "true" 822 addressing, it'll try to grab the
AI.AI.MIT.EDU part and send to that...if it knows Internet addressing,
it'll grab the "USC-ECL.ARPA" part...if it knows (?USC?) addressing, it'll
send it through the gateway, and if it just knows "uucp" addressing, it'll 
toss it's proverbial cookies!!

  Secondly, what is this "#" in the address??  I don't recall that being
part of the legal alphabet for addresses.  

[Does anyone know how to parse that part?  Is it the gateway that Bob
 refers to that's adding this??]

  Third, note that the Message-Id has been added by my local machine.  This
means that it didn't have one when it got here - either it was stripped off
on the way (a frightening implication) or it never got one...

  Fourth, it's a bit odd looking that the "R.LARSON@FNS1" in the From:
line is all uppercase, but the "r.larson@FNS1" in the Cc: is in lowercase.
I understand why this happens and all, but in an aesthetic sense it's not
particularly thrilling...

  Finally, and this is something that Bob alluded to, the date really needs
to have a timezone attached!

		Other than that :-) it looks good!

						-- Dave Taylor

						HP Labs - taylor@hplabs

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86  02:02:48 EDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 28 May 86 02:02:27 EDT
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 27 May 86 22:59:48-PDT
Date: Tue 27 May 86 22:02:07-PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject: Re: Mail headers (from Bob Larson)
To: taylor%hpldat@HPLABS.ARPA
cc: Header-People@MC.LCS.MIT.EDU
In-Reply-To: <8605271804.AA05956@hpldat>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12210198232.7.MRC@PANDA>

Dave Taylor -

     The return path is perfectly legit.  The "%FNS1.#USCnet" is part of
the mailbox and you have no business even thinking about parsing it.  His
From: line was bogus though, since nobody outside of USC knows what FNS1
is.

     The ".#" stuff is an artifact of the TOPS-20 mailer, and refers to
a physical network link that the message uses, in this case the USC DECnet.
It should have been .#DECnet, but the USC people didn't understand that
the name really does refer to a physical hardware transport and had nothing
to do with any proper names.  So, they "improved" it by calling it .#USCnet,
leading to no end of confusion in the outside world from people who think
that some proper named entity called "USCnet" is involved.

     It isn't.  The .# stuff simply tells the TOPS-20 mailer which local
interface it should use to send the mail out on.  It NEVER (at least in
the distributed versions of the TOPS-20 mailer) appears to the right of
the "@" in mail sent on the net.  Its purpose is to allow a user to
distinguish between, say, an Internet host named FOO and a completely
other machine also called FOO on the local DECnet.  It is relevant ONLY
to the host named to the right of the "@"; in other words:
	user%FOO.#DECnet@HOST-1.ARPA
and	user%FOO.#DECnet@HOST-2.ARPA
do NOT refer to the same host named FOO or for that matter to the same
DECnet!

     I'm sorry for inflicting this lengthy explanation on everybody else,
but it is necessary to explain why this clumsy syntax exists.  To my
knowledge, the TOPS-20 mailer is the only mailer that even tries to be
able to mail to two different machines named "FOO" on two different
networks that happen to be connected to the local machine.  Unix just
picks the network it prefers and you can't mail at all to the FOO host
on the network it doesn't prefer.  This syntax provided an unambiguous,
if ugly, means of referring to the two different FOO's and solved a real
problem that has actually come up at multiple times.
-- Mark --
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86  15:32:53 EDT
Received: from USC-ECLB.ARPA by MC.LCS.MIT.EDU 28 May 86 15:32:43 EDT
Date: 28 May 1986  12:30 PDT (Wed)
Message-ID: <TLI.12210356396.BABYL@ECLB>
Sender: TLI@USC-ECLB.ARPA
From: Tony Li <Tli@USC-ECLB.ARPA>
To:   Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Cc:   Header-People@MC.LCS.MIT.EDU, taylor%hpldat@HPLABS.ARPA
Reply-to: Tli@Usc-Eclb
Subject: Mail headers (from Bob Larson)
Home: 1115 E. Cordova St. Apt. 110, Pasadena CA., 91106 (818) 793-3342
In-reply-to: Msg of 27 May 1986  22:02-PDT from Mark Crispin <MRC%PANDA at SUMEX-AIM.ARPA>

    From: Mark Crispin <MRC%PANDA at SUMEX-AIM.ARPA>

         The ".#" stuff is an artifact of the TOPS-20 mailer, and refers to
    a physical network link that the message uses, in this case the USC DECnet.
    It should have been .#DECnet, but the USC people didn't understand that
    the name really does refer to a physical hardware transport and had nothing
    to do with any proper names.  So, they "improved" it by calling it
    .#USCnet, 
    leading to no end of confusion in the outside world from people who think
    that some proper named entity called "USCnet" is involved.

Yes, Mark, we do understand what your code does.  However, USCnet is
NOT just our local DECNET.  It is a logical network which uses a
variety of transport mechanisms. In fact, FNS1 is a Prime machine
which is not on DECNET.  

Cheers,
Tony ;-)

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  13:24:35 EDT
Received: from OFFICE-1.ARPA by MC.LCS.MIT.EDU  4 Jun 86 13:13:44 EDT
Date:  4 Jun 86 13:07 EDT
From: Bill Barns  <WWB.TYM@OFFICE-1.ARPA>
Subject: Status of long lines vs. MMDF?
To: header-people@MIT-MC.ARPA
Message-ID: <TYM-WWB-9B2P3@OFFICE-1>

Some time back (2-3 years) it came out that the MMDF SMTP server couldn't cope 
with lines longer than 255 characters in the "DATA" (822 message).  Messages 
with such lines always elicited a 400 series reply code with some generic "try 
again later" text.  When I learned this, I asked around and was told that the 
necessary change to MMDF code (to handle 1000 character lines as specified in 
RFC 821) was non-trivial but would be done in MMDF II.  In recent months, I've 
somehow gotten the idea that MMDF II now exists.  But I still see my SMTP 
mailer encounter this behavior with some sites.  What is the current truth of 
the situation?  Is there now an MMDF version that handles 1000 character lines?
 If there is, maybe those sites just need to be told how to get it.  If there 
isn't, will there be one "soon"?  If not, is there any prospect of getting the 
4xx reply code changed to something like 554 with some appropriate explanatory 
text, so my mailer will know not to "try again" repeatedly and unsuccessfully 
for N days before giving up?

Bill Barns  (WWB.TYM@OFFICE-1.ARPA)


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  14:21:45 EDT
Received: from isi-vaxa.ARPA by MC.LCS.MIT.EDU  4 Jun 86 13:47:41 EDT
Received: by isi-vaxa.ARPA (4.12/4.7)
	id AA04562; Wed, 4 Jun 86 10:46:14 pdt
From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro)
Message-Id: <8606041746.AA04562@isi-vaxa.ARPA>
Date:  4 Jun 1986 1046-PDT (Wednesday)
To: Bill Barns  <WWB.TYM@OFFICE-1.ARPA>
Cc: header-people@MIT-MC.ARPA
Subject: Re: Status of long lines vs. MMDF?
In-Reply-To: Your message of 4 Jun 86 13:07 EDT.
             <TYM-WWB-9B2P3@OFFICE-1>

I have been working with a "pre-release" of MMDF-II.  The symbolic name in
question is LINESIZE, and in my pre-release, it is still 256.  I hear that
MMDF-II is to be released with 4.2BSD.  I cannot speak for that version.

Jeff

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  15:19:49 EDT
Received: from SRI-NIC.ARPA by MC.LCS.MIT.EDU  4 Jun 86 15:02:41 EDT
Date: Wed 4 Jun 86 12:01:17-PDT
From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
Subject: Re: Status of long lines vs. MMDF?
To: jeff@ISI-VAXA.ARPA
cc: OLE@SRI-NIC.ARPA, header-people@MC.LCS.MIT.EDU
In-Reply-To: <8606041746.AA04562@isi-vaxa.ARPA>
SRI-International: (415) 859-4536  Home: (415) 325-9427 
Message-ID: <12212186003.36.OLE@SRI-NIC.ARPA>


I think you mean "...is to be released with 4.3BSD." It is my understanding
that MMDF-II does indeed come with 4.3BSD.

Ole
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  15:24:24 EDT
Received: from UMD2.UMD.EDU by MC.LCS.MIT.EDU  4 Jun 86 15:05:39 EDT
Date: Wed, 04 Jun 86 14:36:09 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
To: ARPA Internet Mail Interest List <header-people@mit-mc.arpa>,
    BitNet Mail Interest List <@UMD2.UMD.EDU:MAIL-L@BITNIC.BITNET>
Subject: Technical Question on User Agent "reply" command
Message-ID: <M1986$016684.016118BEN.ZBEN@UMD2.UMD.EDU>

When you tell a mail user agent to REPLY to a message, precisely which of the
(possibly many) addresses in the header gets used?  This question does become
nontrivial when you consider REPLY-TO: fields, RESENT- fields, etc.  Because
certain user agents do forwarding with RESENT- fields, this pathological
situation arises:


  From: director@admin          From:        director@admin
  To:   teamleader@research     To:          teamleader@research
 . . . . . . . . . . . . . .    Resent-From: teamleader@research
                   .            Resent-To:   mem1@pc1, member2@pc2, etc
                   .             . . . . . . . . . . . . . . . . . . .
                   .                             .
------------------ V    -----------------------  V         ---------------
| director@admin |----->| teamleader@research |------+---> | member2@pc2 |
------------------ (1)  ----------------------- (2)  |     ---------------
        ^                           ^                |
        :                           : (4)            +---> etc
        :                           :                |
        :              (5)    ------------           |
        :.....................| mem1@pc1 |<----------+
                              ------------
                                   (3)

(1) DIRECTOR@ADMIN sends message to TEAMLEADER@RESEARCH.

(2) TEAMLEADER tells user agent at RESEARCH to forward message to his staff.

(3) MEM1@PC1 does REPLY command.  Does user agent at PC1 follow RESENT-FROM:
    field and reply to TEAMLEADER (4), or does it follow original FROM: field
    and reply to DIRECTOR (5)?



I am considering using the truncated sequence RESENT-REPLY-TO:, REPLY-TO:,
FROM:, thus leaving out RESENT-FROM: fields.  This may seem like the wrong
thing to do, but hear me out.

What I want to do is give the FORWARDER a chance to select which of the two
plausable behaviors REPLY might eventually do.  If replies are to go back to
the original sender (5), then forwarder does nothing:


  From: director@admin          From:        director@admin
  To:   teamleader@research     To:          teamleader@research
 . . . . . . . . . . . . . .    Resent-From: teamleader@research
                   .            Resent-To:   mem1@pc1, member2@pc2, etc
                   .             . . . . . . . . . . . . . . . . . . .
                   .                             .
------------------ V    -----------------------  V         ---------------
| director@admin |----->| teamleader@research |------+---> | member2@pc2 |
------------------ (1)  ----------------------- (2)  |     ---------------
        ^                                            |
        :                                            +---> etc
        :                                            |
        :              (5)    ------------           |
        :.....................| mem1@pc1 |<----------+
                              ------------
                                   (3)

(3) MEM1@PC1 gives mail REPLY command.  Since RESENT-REPLY-TO: field is not
    present, mail follows FROM: field and replies to original sender (5).


But, if forwarder wants to be "in the loop" for replies, then he supplies
a RESENT-REPLY-TO: field pointing to himself:


  From: director@admin          From:            director@admin
  To:   teamleader@research     To:              teamleader@research
 . . . . . . . . . . . . . .    Resent-From:     teamleader@research
                           ====>Resent-Reply-To: teamleader@research
                   .            Resent-To:       mem1@pc1, member2@pc2, etc
                   .             . . . . . . . . . . . . . . . . . . .
                   .                             .
------------------ V    -----------------------  V         ---------------
| director@admin |----->| teamleader@research |------+---> | member2@pc2 |
------------------ (1)  ----------------------- (2)  |     ---------------
                                    ^                |
                                    : (4)            +---> etc
                                    :                |
                              ------------           |
                              | mem1@pc1 |<----------+
                              ------------
                                   (3)

(3) MEM1@PC1 gives mail REPLY command.  Mail follows RESENT-REPLY-TO:
    field and replies to FORWARDER (4).

I realize this breaks the strict correspondance between RESENT- and normal
fields, but it does give us a capability we would like to have.  If anybody
has objections or even observations please let me know what you think.

Ben Cranston

       UMD5.UUCP
ZBEN @ UMD2.UMD.EDU
       UMD2.BITNET

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86  16:43:56 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU  4 Jun 86 16:43:39 EDT
To: wwb.tym@office-1.arpa
cc: header-people@mit-mc.arpa
Subject: MMDF and Long Lines
Date: Wed, 04 Jun 86 16:37:20 -0400
From: Craig Partridge <craig@loki.bbn.com>


Bill,

    This bug was fixed some time ago.  We have tested and can confirm
that it is not present in MMDF2b, which will be released shortly.

    We believe, but have not checked, that it is also fixed in MMDF2a
(which came out last year).

Craig Partridge
CSNET Technical Staff & MMDF2b Co-Coordinator

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86  10:06:27 EDT
Received: from ALMSA-1 by MC.LCS.MIT.EDU  5 Jun 86 10:06:00 EDT
Received: from almsab by ALMSA-1.ARPA id a011128; 5 Jun 86 8:07 CDT
Date:     Thu, 5 Jun 86 7:45:52 CDT
From:     Rich Zellich <zellich@ALMSA-1.ARPA>
To:       ZBEN@UMD2.ARPA
cc:       Header-People@MIT-MC.ARPA, MAIL-L%bitnic.bitnet@UMD2.ARPA
Subject:  Re:  Technical Question on User Agent "reply" command

As I recall, the official way is to use Reply-To if present, From if it is
present and Reply-To is not, and finally Sender if neither Reply-To nor From
are present.  I don't remember the extended field-names like Resent-* entering
into the equation at all but, personally, I like the idea of including
Resent-Reply-To at the head of the chain (if anyone has a mail agent that will
let you include such a field).

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86  12:04:00 EDT
Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU  5 Jun 86 12:03:47 EDT
Received: from localhost by Dewey.UDEL.EDU id a003062; 5 Jun 86 12:00 EDT
Reply-To: James M Galvin <galvin@dewey.udel.EDU>
To: Rich Zellich <zellich@almsa-1.ARPA>
cc: ZBEN@umd2.umd.EDU, Header-People@mc.lcs.mit.EDU, 
    MAIL-L%bitnic.bitnet@umd2.umd.EDU
Subject: Re: Technical Question on User Agent "reply" command 
In-reply-to: Your message of Thu, 05 Jun 86 07:45:52 CDT.
Date: Thu, 05 Jun 86 11:59:20 -0400
Message-ID: <3047.518371160@dewey>
From: James M Galvin <galvin@dewey.udel.EDU>

> From: Rich Zellich <zellich@almsa-1.ARPA>
> Date: Thu, 5 Jun 86 7:45:52 CDT
> As I recall, the official way is to use Reply-To if present, From if it is
> present and Reply-To is not, and finally Sender if neither Reply-To nor From
> are present.

Actually, I don't know of any "official" way but I do know of three
different interpretations.  Berkeley Mail as distributed with 4.[23]BSD
does one of the following:

	1. reply to FIRST address listed in Reply-To: field ONLY
	2. reply to From: address and To: and Cc: fields
	3. reply to Sender: address and To: and Cc: fields

Now MMDF msg does one of the following:

	1. reply to Reply-To: address(es) and To: and Cc: fields
	2. reply to From: address and To: and Cc: fields

And finally, Berkeley Mail as distributed with MMDF does one of:

	1. reply to Reply-To: address(es) and To: and Cc: fields
	2. reply to From: address and To: and Cc: fields
	3. reply to Sender: address and To: and Cc: fields

I would probably following MMDF's msg.  I am not convinced we need the
utility of "Resent-Reply-To" though.  Why not just redistribute the
message and then include the additional recipient in any replies you
generate.  If the additional recipient replies to the message you
redistributed then s/he will receive replies to that message and so
will you.  If the redistributor wants to be the only one receiving
replies from the additional recipient then the message should be
forwarded not redistributed.

Jim

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86  14:40:18 EDT
Received: from hplabs.ARPA by MC.LCS.MIT.EDU  5 Jun 86 14:40:01 EDT
Received: from hpldat by hplabs.ARPA ; Thu, 5 Jun 86 11:38:12 pdt
Received: by hpldat ; Thu, 5 Jun 86 11:40:58 pdt
From: Dave Taylor <taylor%hpldat@hplabs.ARPA>
Message-Id: <8606051840.AA16858@hpldat>
To: Header-People@mit-mc
Date: Thu, 5 Jun 86 11:40:53 PDT
Subject: More on mail address priorities...
Organization: Hewlett-Packard Laboratories, Knowledge Technologies Lab.
X-Mailer: ELM [version 1.0]


From what I understand, and what my mailer knows, the scheme for generating
a return address is;

	1. If the message has a "Reply-To:", use it.

	2. If the message has a "From:", use it.

	3. If the message has a "Sender:", use it, but not for textual,
	   user-originated, replies.  Rather, this should be used just
	   for delivery/routing problems and other error notification.
	   The example in RFC-822 indicates that `Sender:' could most
	   commonly be considered the address of a secretarial-type 
	   person...

	4. If the message has none of the above, it is considered to
	   not have a valid return address and the mailer agent can
	   optionally refuse to generate a reply address;

		'822 requires that any minimal legal mail message
	   contain; a date stamp ("Date:"), an indication of whom
	   the mail is from ("From:") and some indication of whom
	   the mail was sent to ("To:" or "Bcc:" <- "bcc" can be an
	   empty list).

		Given this, we can assume that a conformant mailer
	   can indeed refuse to reply to mail without a From: or
	   Reply-To: header.  As we know, though, a great deal of
	   mail (especially on "uucp" sites, like my own) would then
	   be dropped post haste!!  *sigh*

As far as the priority of the "Resent-Reply-To:" I think that this would
be a dangerous header to generate - the correct behaviour of a mailer 
when mail is resent is to leave the Reply-To: header alone.  (The problem
with this, though, is that say Rich Zellich sends me a message, with a
Reply-To: to him.  I then resend it to a friend.  That resending fails, 
though, and the mailer generates a failed-message error.  Should that error
go to Rich or myself?)  (we could use the "Errors-To:", but that's a field
that I don't know of ANY mailers/transport systems using...)

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

To wax philosophical for a bit, it seems to me that this whole issue is
indicative of a problem with the 822 specification.  What is needed is
a clear, unambiguous set of headers for a message that contain the
following information in some manner or other;

	o The name and address of the person(s) sending the message.
	o The name and address of the person(s) to reply to.
	o The name and address of the person who originated the message.
	o The (name and) address of the person to send errors to.

These are not necessarily all required.  Furthermore, there is a problem
of address versus route (e.g. my email address is taylor@hpldat.HP.COM, but
my route might very well be "ihnp4!hplabs!hpldat!taylor").

It seems like the current problem with the network is that there is too little
distinction between these two forms of address.  Consider the "should the
intermediate hosts alter the From:/Reply-To: lines" debate - some hosts
say that they shouldn't, because it's an address, and others say they should
since it's a route.  

My proposed solution, based on the information sketchily described in '822, is
to have the originating mail system attach a new header "Reply-Path:" to the
header of the message.  All intermediate machines would then be REQUIRED to
attach their hostname/routingname to this path but would NOT be allowed to 
alter the contents of the Reply-To: or From: headers.  The receiving user
agent would then be able to use "Reply-Path:" to reply to the message IF it
needed to use a 'route' address, or simply use the Reply-To:/From: if it 
knew about `formal' addresses.

A few examples;

	[the first is a pure UUCP address]

	From uucp <local agent reception time and date>
	From: Dave Taylor <taylor@hpldat.HP.COM>
	Date: <date of submission of the original message>
	Reply-Path: hpfcla!hplabs!hpldat!taylor
	To: j_richards@hpfclq.HP.COM
	Subject: automatic, correct, reply addresses

	   [message body]

	[the next has a Reply-To field.  Note that the Reply-Path: header
	 is for the Reply-To, NOT the From: field!]

	From mmdf <local agent reception time and date>
	From: Dave Taylor <taylor@hpldat.HP.COM>
	Reply-To: Computers And Society Digest <cas-request@hpldat.HP.COM>
	Date: <date of submission of the original message>
	Reply-Path: emoryu2!gatech!hplabs!hpldat!cas-request
	To: gatech!emoryu2!emoryu1!janet
	Subject: More on Science and Technology...

	   [message body]

Any thoughts?

						-- Dave Taylor
						taylor@hplabs (soon .HP.COM)

ps: While I'm sending mail to the group, is there any consensus on a
    preferred order for headers in a message?  The order of the To:/Subject:/
    From:/Date:/etc fields seems pretty darn random...

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86  17:02:16 EDT
Received: from isi-vaxa.ARPA by MC.LCS.MIT.EDU  5 Jun 86 17:01:43 EDT
Received: by isi-vaxa.ARPA (4.12/4.7)
	id AA05188; Thu, 5 Jun 86 14:00:26 pdt
From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro)
Message-Id: <8606052100.AA05188@isi-vaxa.ARPA>
Date:  5 Jun 1986 1400-PDT (Thursday)
To: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
Cc: OLE@SRI-NIC.ARPA, header-people@MC.LCS.MIT.EDU, jeff@ISI-VAXA.ARPA
Subject: Re: Status of long lines vs. MMDF?
In-Reply-To: Your message of Wed 4 Jun 86 12:01:17-PDT.
             <12212186003.36.OLE@SRI-NIC.ARPA>

Yes, I meant MMDF-II is to be released with 4.3BSD.  A little typo there.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUN 86  22:14:36 EDT
Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU  7 Jun 86 21:40:32 EDT
Received: from localhost by Dewey.UDEL.EDU id a001221; 6 Jun 86 20:51 EDT
Reply-To: James M Galvin <galvin@dewey.udel.EDU>
To: Dave Taylor <taylor%hpldat@hplabs.ARPA>
cc: Header-People@mc.lcs.mit.EDU
Subject: Re: More on mail address priorities... 
In-reply-to: Your message of Thu, 05 Jun 86 11:40:53 PDT.
             <8606051840.AA16858@hpldat> 
Date: Fri, 06 Jun 86 20:50:50 -0400
Message-ID: <1213.518489450@dewey>
From: James M Galvin <galvin@dewey.udel.EDU>

> From: Dave Taylor <taylor%hpldat@hplabs.ARPA>
> Date: Thu, 5 Jun 86 11:40:53 PDT
>
> (The problem
> with this, though, is that say Rich Zellich sends me a message, with a
> Reply-To: to him.  I then resend it to a friend.  That resending fails, 
> though, and the mailer generates a failed-message error.  Should that error
> go to Rich or myself?)

Obviously the correct thing to do is to give you the error message.
Now, if MMDF is your transport agent, you do get the error message.  The
recipients and sender of a message are maintained separately from the
message, although the construction of this file may require looking at the
message.  This is exactly how the "list channel" of MMDF operates.
Distribution list are processed via the "list channel" which sets the
return address in this file to be "LIST-request".  This file is used during
the SMTP dialog.  Now, if we could only get other mailers to remember this
information rather than assuming it is contained in the message.

> ps: While I'm sending mail to the group, is there any consensus on a
>     preferred order for headers in a message?  The order of the
>     To:/Subject:/From:/Date:/etc fields seems pretty darn random...

This is a user agent problem, not a transport agent problem.  In MH, a user
can completely specify the order and format of all displayed messages.

Jim

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 JUN 86  20:23:27 EDT
Received: from titan.arc.nasa.gov by MC.LCS.MIT.EDU  8 Jun 86 20:09:22 EDT
Received: by titan.arc.nasa.gov (5.45/1.7)
	id AA07643; Sun, 8 Jun 86 17:06:20 PDT
Date: Sun, 8 Jun 86 17:06:20 PDT
From: Jordan Hayes <jordan@titan.arc.nasa.gov>
Message-Id: <8606090006.AA07643@titan.arc.nasa.gov>
To: header-people@mc.lcs.mit.edu
Subject: A funny thing happened on the way to my mailbox ...
Cc: kpetersen@simtel20.arpa, s.pae@deep-thought.mit.edu

Did anyone else get this or am I just hosed?

	Date: Tuesday, 3 June 1986  16:20-MDT
	Message-Id: <KPETERSEN.12213166335.BABYL@SIMTEL20.ARPA>
	Sender: "Philip A. Earnhardt" <S.PAE@^?deep-thought.mit.edu^?>
	From: "Philip A. Earnhardt" <S.PAE@^?deep-thought.mit.edu^?>
	To: TELECOM@mc.lcs.mit.edu
	Subject:   MNP Protocol
	Resent-From: KPETERSEN@simtel20.arpa
	Resent-To: Info-Modem7@simtel20.arpa

I changed the wierd character to how it comes out on my editor (^? I would
imagine is something like ascii 127 ...

Where did this strangeness come from? Will it go away?

/jordan

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86  05:21:57 EDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU  9 Jun 86 05:21:31 EDT
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 9 Jun 86 02:19:30-PDT
Date: Mon 9 Jun 86 00:51:24-PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject: timezones and RFC 822
To: Header-People@MC.LCS.MIT.EDU
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12213374776.7.MRC@PANDA>

     Rich Wales is correct that RFC 822 has military timezones
backwards.  Continental Europe time (GMT+1 hour, known in Germany
as MEZ) is military timezone "A".  Timezones "M" and "Y" refer to
the same zone, except that "M" is west of the international date
line and "Y" is east.

     The PANDA version of TOPS-20 implements these timezones (it
is better than DEC TOPS-20's behavior of showing no timezone at
all outside of the USA or GMT), and I decided to go with the military
standard instead of what RFC 822 claimed.

     Is it at all possible that we can revise RFC 822 to correct
this and other obvious errors?  To emphasize that it is not a new
standard (ala RFC 733 => RFC 822), let's call the new document
RFC 822(1) or something.  It would not hurt to make the description
of things like domains and domain literals be more in keeping with
RFC 821 and the other domain documents, but let's keep this sweet
and simple.

     At the very least, let's have an RFC with all the known bugs
in RFC 822 and make that available as an appendix to any further
hardcopy printing of RFC 822.
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86  11:36:11 EDT
Received: from harvard.HARVARD.EDU by MC.LCS.MIT.EDU  9 Jun 86 11:32:22 EDT
Received: from endor.HARVARD.EDU (endor) by harvard.HARVARD.EDU; Mon, 9 Jun 86 11:25:44 EDT
Date: Mon, 9 Jun 86 11:25:41 EDT
Received: by endor.HARVARD.EDU; Sun, 8 Jun 86 18:06:03 EDT
From: macrakis@harvard.HARVARD.EDU (Stavros Macrakis)
To: header-people@mit-mc.arpa
Cc: GUMBY@AI.AI.MIT.EDU
Subject: Failed messages to mailing lists

As far as I know, there is no way to specify that you're not
interested in failed mail messages from a particular message.  When
I am sending, e.g., bug notes, I want to be sure my message reaches
the redistribution host, but once it gets there, I'd like to have the
list administrator be responsible for failed mail.

This is good both for the individual senders to the list and for the
list administrator.  As a sender in such cases, I really don't care if
there is a delay in the message getting through to one of the 100
readers of the list.  On the other hand, as a list administrator, I'd
like to be able to prune my list according to failed mail problems.

If I can't get this, I'd at least like to have the ability of saying
`tell me only if it never gets through'.  There have been messages
where I've gotten 2-3 `temporary' NAK's (host down for a day, will try
again, etc. etc.) before getting the final NAK (host down for a week,
I won't continue trying, take it back).

	-s


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86  08:23:27 EDT
Received: from rand-unix.ARPA by MC.LCS.MIT.EDU 10 Jun 86 08:16:33 EDT
Received: from localhost by rand-unix.ARPA; Tue, 10 Jun 86 03:52:52 pdt
Message-Id: <8606101052.AA11352@rand-unix.ARPA>
To: Jordan Hayes <jordan@ames-titan.arpa>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: A funny thing happened on the way to my mailbox ...
In-Reply-To: Your message of Sun, 8 Jun 86 17:06:20 PDT.
             <8606090006.AA07643@titan.arc.nasa.gov>
Date: Tue, 10 Jun 86 03:52:13 PDT
From: greep@rand-unix.ARPA

Looks like maybe it was some internal form that was never supposed
to make it to the outside world.  4.2bsd Unix sendmail plays games
like that (although in this case it is evidently not a Unix site),
and screwing up sendmail's config file can have that effect.  I've
also seen funny internal forms come out of Xerox once in a while.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86  09:22:15 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 10 Jun 86 09:22:39 EDT
Date:  Tue, 10 Jun 86 08:53 EDT
From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject:  timezones and RFC822
To:  header-people@MC.LCS.MIT.EDU
Message-ID:  <860610125356.810321@MIT-MULTICS.ARPA>

If such a revision were to be made, it would be helpful to authorize the
NAMES (or at least some names) for some of the timezones that don't
cross the continental US.  At one level, we should have named zones that
span Alaska and Hawaii.  At another, with ARPANET (not MILNET) sites in
Western Europe and BITNET/EARN sites all over the place using RFC822, it
would be at a minimum to have support for what those folks call their
zones.

This is especially important in internetwork dealings with the
BITNET/EARN sites who seem to feel a deep need to use a locally-named
zone (e.g., MEZ), rather than an (especially backwards) [US] military
zone code.  Those local zones are fine as long as they stay within their
own network, but, when messages cross over into the Internet, as least
some mail agents get upset with them because the dates are not
RFC822-legal.

The other question, of course, is how one arranges a transition from a
"backwards" standard to a "forwards" one, given that mail-producing
codes to generate the older type of zone codes will probably linger
somewhere in the works for years.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86  14:18:38 EDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 10 Jun 86 14:17:21 EDT
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 10 Jun 86 11:15:08-PDT
Date: Tue 10 Jun 86 10:19:19-PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject: Re: A funny thing happened on the way to my mailbox ...
To: greep@RAND-UNIX.ARPA, jordan@AMES-TITAN.ARPA
cc: header-people@MC.LCS.MIT.EDU
In-Reply-To: <8606101052.AA11352@rand-unix.ARPA>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12213740307.7.MRC@PANDA>

Actually, that particular internal form (with DEL's around the host
name) comes out of the TOPS-20 mailer.  Normally, the mailer is
forbidden from doing any header modification, but if the mail composer
puts DEL's around the host name it says "I think this is the right
host name, but I can't be sure, and the message may get relayed to a
third party, so look this name up and fix it up, doing whatever %-type
conversion you think is necessary."

I'm not sure why it "bogued out", but my suspicion is that the host
name in the header was bad, but the name in the envelope was not.  The
mailer will always deliver a message if the envelope is okay irregardless
of what trash may appear in the header.  If it is completely unable to
fix up a "<DEL>hostname<DEL>" entry, it assumes that it wasn't really
such an entry at all but instead was a legitimate text DEL and leaves
it alone.

Supporting this suspicion is the Message-ID, which indicates that the
"Babyl" mail composer (instead of MM) composed this message.  Babyl is
written in TECO (a text editing programming language) and I believe it
does not do any validation of host names.  MM won't let you do this,
but conceivably it is possible for a Babyl user to have a different
host name in the envelope from the header, and blow it on the latter.

I apologize for the confusion it may have caused you.  There isn't too
much the mailer could have done; it's classic GIGO.  If you would like
to talk with the people who might be able to do something about Babyl's
generating this garbage, try BUG-BABYL@MC.LCS.MIT.EDU.

-- Mark --
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86  15:02:20 EDT
Received: from decwrl.DEC.COM by MC.LCS.MIT.EDU 10 Jun 86 15:02:05 EDT
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.05/4.7.34)
	id AA00401; Tue, 10 Jun 86 12:01:06 pdt
Message-Id: <8606101901.AA00401@decwrl.DEC.COM>
Date: 10-Jun-1986 1417
From: covert%covert.DEC@decwrl.DEC.COM  (John R. Covert)
To: header-people@mc.lcs.mit.edu
Subject: Zone names

>If such a revision were to be made, it would be helpful to authorize the
>NAMES (or at least some names) for some of the timezones that don't
>cross the continental US.

Oh no!  This is an incredible rathole!

Do this and you have to worry about conflicts between BST=British Summer Time
and BST=Bering Standard Time.  These two happen to be exactly twelve hours
apart.

Of course, Alaska changed all their timezones recently:  BST doesn't even
exist any more and Anchorage is one timezone east of where almost every
reference shows it (it's now only one hour west of California).  To top
this off, people in Alaska call their timezone AST=Alaska Standard Time
even though that conflicts with AST=Atlantic Standard Time!

And then there's EST=Eastern Standard Time in both the U.S. and Australia.

How many languages shall we use for the abbreviation of Central European
Time?  German, French, Italian, Spanish, Dutch, Danish, ...  And the French
and the French speaking Swiss can't agree on the abbreviation for Central
European Summer Time: HECE and HEEC!

Forget the abbreviations; they just aren't useful except possibly as a
comment field!

/john

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86  17:13:39 EDT
Received: from NRTC-GREMLIN.NORTHROP.COM by MC.LCS.MIT.EDU 10 Jun 86 16:55:02 EDT
Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a006168;
          10 Jun 86 13:52 PDT
To: "John R. Covert" <covert%covert.DEC@decwrl.dec.COM>
reply-to: header-people@mc.lcs.mit.EDU
cc: header-people@mc.lcs.mit.EDU
Subject: Re: Zone names 
In-reply-to: Your message of 10 Jun 86 14:17:00 +0000.
             <8606101901.AA00401@decwrl.DEC.COM> 
Date: Tue, 10 Jun 86 13:52:08 -0700
Message-ID: <6166.518820728@nrtc-gremlin.northrop.com>
From: Marshall Rose <mrose@nrtc-gremlin>

    The zone name business is a classic user agent vs. user interface
    problem.  Let me relate an lengthy experience.  I have the
    misfortune of being one of the MH maintainers.  MH is this message
    handling system for UNIX.

    In RFC822, you get three choices for a timezone, e.g., "-0050", "E",
    or "EST".  When a date is displayed to a user, they prefer the third
    form of timezone because it's more meaningful.  Sadly, many user
    agents understand and generate other, non-standard, abbreviations
    for timezones.  

    You all know about how BST (Bering Standard Time) is different from
    BST (British Summer Time) depending on whether you're in Alaska or
    the U.K.  Although local tables of user-friendly timezones are
    desirable, values generated from them are typically un-meaningful
    (or even anti-meaningful) when found outside of the local environs.
    An extreme example is EVT (Eastern Virtual Time) which was being
    generated by an IBM host because you couldn't change the timezone
    string in the mailsystem without re-configuring the operating
    system.

    So, to discourage this type of behavior, and set an example for
    mailsystems everywhere, MH was modified to generate to use only
    numeric (unambiguous, globally meaningful) timezones when posting
    mail.  Considering the volume of hate mail I got when this new
    version of MH was released, most people had extraordinarily minimal
    user interfaces!  That is, their user interface didn't try to
    convert the numeric timezone to a locally meaningful abbreviation.
    The reason for these minimal interface implementations, supposedly,
    goes back to the RFC822 basis in ASCII text.  "Since everything's
    just text", reason some implementors, "why not just output it
    directly to the user's terminal without interpretation?"  Hopefully,
    implementations of X.400 won't suffer from this problem, since dates
    in MHS are IA5 strings but not very easy to read (e.g.,
    "860610135005-0500").  

    To summarize this long-winded reply:  NO GLOBAL TABLES, REPEAT, NO
    GLOBAL TABLES.  Local tables are fine so long as you guarantee they
    NEVER escape from the domain where they are meaningful (e.g., the
    host originating the mail).  

/mtr

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 JUN 86  19:23:35 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 11 Jun 86 19:04:57 EDT
Date:  Wed, 11 Jun 86 19:03 EDT
From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject:  Re: time zones
To:  header-people@MC.LCS.MIT.EDU
Message-ID:  <860611230319.475119@MIT-MULTICS.ARPA>

I capitulate, and apologize for bringing it up.  Seems to me that a very
good argument is being made for striking the eight zone names permitted
by RFC822, since they are ultimately not entitled to special preference
and their presence encourages the transmission of local innovations over
the network.

It also suggests an additional set of rules/guidelines for gateways of
the character of "you may permit that nonsense on your network, but we
expect them to be cleaned up into numeric values before the message
cross over into the Internet".

So --- revised and quite opposite version of the suggestion:  if RFC822
is to be opened up and corrections made, how would people feel about
"correcting" the existing eight zone names out of there?

It is also clear that the easiest way to "solve" the compatibility
problems with the ascending or descending letters is to "correct" that
convention by banning both the ascending and descending forms, insisting
on numerics.  That provides better X.400 compatability, as pointed out
indirectly in an earlier message, and, if user agents can manage
locally-referenced zone names, they can certainly manage to convert
numbers to letters in a locally-acceptable scheme.  The lives of such
agents would certainly be easier if there were only one, unambiguous,
form -- effort could be devoted to making a clean local interface rather
than to parsing and near-heuristics.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 JUN 86  23:43:55 EDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 11 Jun 86 23:38:25 EDT
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 11 Jun 86 20:36:10-PDT
Date: Wed 11 Jun 86 19:28:57-PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject: Re: time zones
To: Klensin@MIT-MULTICS.ARPA
cc: header-people@MC.LCS.MIT.EDU
In-Reply-To: <860611230319.475119@MIT-MULTICS.ARPA>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12214102509.6.MRC@PANDA>

John Klensin -

     I think it is pretty much hopeless to expect the RFC 822 world to
abandon US timezones.  A much more sensible approach is to think about
X.400 instead.

-- Mark --
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  02:35:47 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86  02:33:29 EDT
Received: from ALMSA-1 by MC.LCS.MIT.EDU  9 Jan 86 11:10:10 EST
Received: from almsab by ALMSA-1.ARPA id aa05813; 9 Jan 86 10:02 CST
Date:     Thu, 9 Jan 86 10:02:20 CST
From:     Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
To:       arms-d@MIT-MC.ARPA, human-nets@RUTGERS.ARPA, sf-lovers@RUTGERS.ARPA, 
          arpanet-bboards@MIT-MC.ARPA, header-people@MIT-MC.ARPA, 
          info-terms@MIT-MC.ARPA, space@MIT-MC.ARPA
cc:       zellich@ALMSA-1.ARPA
Subject:  Host MIT-MC may vanish abruptly

Some of you might have heard rumors or indications that the longtime
ARPANET mail-relay and list-archive storage computer, MIT-MC, is due to
be retired. These rumors are true; I append below a message from one of
the system managers confirming this. 

Therefore, if you have been relying on having MIT-MC around as a source
for archived mailing-list files, or as a mail-forwarder, be warned that
it is likely to disappear abruptly in the near future. It would be good
if all the list archives could be moved to other hosts which would also
support the traditional ARPA "anonymous FTP", and also that mailing-list
addresses should be changed to no longer rely on forwarding or list
expansion by MIT-MC. I hope that this information is disseminated as
widely as possible, so as to reach all list-maintainers and the whole
community of users and list readers and contributors.

Those of us who have been involved with the ARPANET for some years all
owe a debt of gratitude to MIT-MC and the support staff that ran it over
the past decade or so; that host was the seminal point for the entire
mailing list and Digest phenomenon. It's sad to see it go, but we all
know that hardware progress makes such changes inevitable. 

Regards, Will Martin

----- Forwarded message # 1:

Date: Wed,  8 Jan 86 19:17:46 EST
From: "Christopher C. Stacy" <CSTACY@mit-mc.ARPA>
Subject:  Future of MIT-MC?
To: wmartin@ALMSA-1.ARPA
cc: POSTMASTER@mit-mc.ARPA
Message-ID: <[MC.LCS.MIT.EDU].777682.860108.CSTACY>

Will,

I am afraid that the rumors about MIT-MC's future are true.

The maintenance contract for MIT-MC expires in a few months (at the end
of February, I think).  After that, the next time the machine breaks
badly, it will be retired from service.

There are few KS-10 (DEC2020) machines in the building now, and one of
them is actually running ITS and calling itself MIT-AI.  This tiny
machine not on the Internet yet, although it probably will be before too
long.  However, MIT-AI will not have anywhere near the capacity of MC,
and won't be able to service the world in general.  There really isn't
any machine available at MIT to take over the services MC has provided;
the structure of the community and its associated resources has changed.

People should be moving off of MIT-MC rapidly; the machine really will
be decommissioned with little warning in the near future.  Also, people
should move their data, as files may not be retrievable once it's gone.

Cheers,
Chris
----- End of forwarded messages

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  02:59:42 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86  02:33:36 EDT
Received: from hplabs.ARPA by MC.LCS.MIT.EDU  9 Jan 86 17:11:01 EST
Received: by hplabs.ARPA ; Thu, 9 Jan 86 14:10:24 pst
To: veeger!hpcnof!hplabs!Header-People@MIT-MC.ARPA,
        veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA
Date: Thu, 9 Jan 86 14:21:44 MST
From: hpcnou!dat@hplabs.ARPA (Dave Taylor)
Subject: Questions on ARPA/Domain naming...
Organization: Hewlett Packard, Colorado Networks Operation
X-Location: Fort Collins, Colorado, USA
X-Mailer: msg [version 2.4]


	Recently I've hooked my mailer up to ues the pathalias database
distributed on the usenet system and have been trying to improve the 
search to hit ratio through various techniques.

   My current algorithm is:

	1. Extract the host name from the address
	2. Remove all the domain information
	3. Translate the entire name to lower case letters
	4. Search in table
	5. If the search fails, return the original host name
	   otherwise return the expanded address

The question is, since the database is a mixture of USENET and ARPANET
(and presumably CSNET, BITNET, ??NET too) is it safe to consider each
host machine as a unique identifier?

On ARPA machines, the addresses are case insensitive, so it's rather
obvious that the third step in the algorithm above is okay.  What about
on USENET?

Finally, are there any cases where there are two machines with the 
same name and differ only on domain?  (like 'vax.att.com' versus 
'vax.harvard.edu')

Any input on these problems, or (perhaps) other equally successful
techniques for searching the database would be appreciated.

				-- Dave Taylor
				Hewlett Packard
				hpcnof!dat@HPLABS.ARPA

ps: Speaking of which, is it possible to get the ARPA hostname table?
    (anyone at SRI-NIC reading this?)

pps: Also, has anyone considered modifying pathalias to allow not only
     the '<name> <tab> <address>' information but also an organizational
     entry for each machine?    The user could then do queries like 
     "Where is this mail from?" "what is this machine?" and so on...




Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  02:59:46 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86  02:33:39 EDT
Received: from BRL-SEM.ARPA by MC.LCS.MIT.EDU  9 Jan 86 19:39:53 EST
Date:     Thu, 9 Jan 86 19:35:54 EST
From:     Ron Natalie <ron@BRL.ARPA>
To:       Dave Taylor <hpcnou!dat@hplabs.arpa>
cc:       header-people@mit-mc.arpa
Subject:  Re:  Questions on ARPA/Domain naming...

There are many cases of the sort
	vax.att.com and vax.harvard.edu.

Check the tables for the host "sam" for instance.

	sam.cs.ucl.ac.uk
	sam.cs.cmu.edu
	sam.brl.mil

to name a few.

-Ron

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  13:51:05 EDT
Received: from titan.arc.nasa.gov by MC.LCS.MIT.EDU 12 Jun 86 13:51:04 EDT
Received: by titan.arc.nasa.gov (5.45/1.7)
	id AA12374; Thu, 12 Jun 86 10:47:29 PDT
Date: Thu, 12 Jun 86 10:47:29 PDT
From: Jordan Hayes <jordan@titan.arc.nasa.gov>
Message-Id: <8606121747.AA12374@titan.arc.nasa.gov>
To: header-people@mc.lcs.mit.edu
Subject: Re:  Questions on ARPA/Domain naming...
Cc: hpcnou!dat@hplabs.hp.com

	From: hpcnou!dat@HPLABS.HP.COM Thu, 9 Jan 86 14:21:44 MST

	since the database is a mixture of USENET and ARPANET (and
	presumably CSNET, BITNET, ??NET too) is it safe to consider
	each host machine as a unique identifier?

First of all, "usenet" is a method of distributing news around. I guess
you are refering to the UUCP network.

Second, it's not safe to assume that. There are few hostname collisions
left in the table, and you shouldn't be putting csnet and bitnet sites
in your data -- they each have a well defined relay point. You don't
really need to know what those networks look like -- just bundle up a
user%host@relay and shove it to hplabs.hp.com and they'll know what to
do with it.

That should take care of the Internet, BITNET, CSNET, MAILNET even
Australia's ACSNet stuff (ship it out to seismo -- they can handle
it).

I believe the maps now have some domained uucp addresses, so you
shouldn't strip any of the domain information.

	On ARPA machines, the addresses are case insensitive, so it's
	rather obvious that the third step in the algorithm above is
	okay.  What about on USENET?

No, in the UUCP land, hostnames are case sensitive.  You must preserve
case.

	Finally, are there any cases where there are two machines with
	the same name and differ only on domain?  (like 'vax.att.com'
	versus 'vax.harvard.edu')

Like Ron Natalie said, *tons* ...

But for UUCP there aren't going to be too many until the domaining
starts to take hold -- up until now, most places that wanted to get
into the map files had to work something out about namespace collisions
(opus -> hropus is the classic example) -- since your Internet mail
shouldn't touch the pathalias stuff, you shouldn't have to worry about
it for now.

	Any input on these problems, or (perhaps) other equally
	successful techniques for searching the database would be
	appreciated.

Well, I think it's pretty evil to take a long path and try to optimize
it. It's almost always a bad idea. Mostly because if you have an
address like a!b!c!d!e!user you have no idea which "e" that person is
on. Maybe it's not a documented machine, but has the same name as one
that is in your data, so you change the address to f!g!h!other_e!user,
and it bounces.

I think it's only feasible (notice I didn't say "reasonable") to do
that with an address like user@host.uucp

God, I don't want this to turn into net.mail.flame.automatic-routing

	Speaking of which, is it possible to get the ARPA hostname
	table?

You could uucp it from hplabs.hp.com ... it lives in /etc/hosts

	Also, has anyone considered modifying pathalias to allow not
	only the '<name> <tab> <address>' information but also an
	organizational entry for each machine?    The user could then
	do queries like "Where is this mail from?" "what is this
	machine?" and so on...

Pathalias only cares about the routing information, but John Quarterman
wrote some scripts to extract the other information from the maps and
there's an RFC (915) which describes a network service for the info. I
wrote a server that does this plus can answer queries about the
organization, etc.

/jordan

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  21:12:09 EDT
Received: from ucbvax.Berkeley.EDU by MC.LCS.MIT.EDU 12 Jun 86 21:11:21 EDT
Received: by ucbvax.Berkeley.EDU (5.51/1.14)
	id AA21221; Thu, 12 Jun 86 18:10:31 PDT
Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/5.4)
	id AA23659; Thu, 12 Jun 86 18:09:55 PDT
Date: Thu, 12 Jun 86 18:09:55 PDT
From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO)
Message-Id: <8606130109.AA23659@ucbjade.Berkeley.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Re:  Zone names

The solution is to use one date/time (eg: "UT", "GMT", or "Z") in all
date/time fields of messages sent between Mail Transfer Agents (MTA).
The military, several governments, civil aviation, and other world-wide
communication systems have been doing this for years.

I do not recommend having User Agent programs converting UT into local
time because humans reference messages by the orginator's name
and the date/time of the message.


Bill Wells
UC Berkeley Academic Computing Services
netinfo%ucbjade@Berkeley.EDU

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86  21:34:41 EDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 12 Jun 86 21:34:59 EDT
Received: from iowa-state by csnet-relay.csnet id ab15313; 12 Jun 86 21:28 EDT
Received: by isucs1.UUCP (4.12.01/2.02)
	id AA23693; Thu, 12 Jun 86 10:43:59 cdt
Date: Thu, 12 Jun 86 10:43:59 cdt
From: Dave Shaver <shaver%iowa-state.csnet@CSNET-RELAY.ARPA>
To: header-people@MC.LCS.MIT.EDU
Subject: Questions on ARPA/Domain naming...


I'm quoting Dave Taylor with the >'s.

> [I]s it safe to consider each host machine as a unique identifier [across
> all the networks]?

	I'm certainly not an expert, but I think you are asking for
trouble.  It's bad enough trying to get unique hostnames within the
UUCP `domain.'

> On ARPA machines, the addresses are case insensitive [...]
> What about on USENET?

	Although most people say, "Don't use ANY caps when naming your
UUCP host," some people still mix-in uppercase letters.  Glacier and
Shasta come to mind off the top of my head.  I don't know what kind of
work-arounds are out there at these hosts, but I'm pretty sure that
'Glacier' is not the same as 'glacier' in the UUCP world.

> [...] are there any cases where there are two machines with the 
> same name and differ only on domain?  (like 'vax.att.com' versus 
> 'vax.harvard.edu')

	Yes.  I believe that's a big reason for having domains.  It
allows names to be the same, but different since they are in different
domains.  When naming a host, you only need to worry about being unique
within your own region.

> [H]as anyone considered modifying pathalias to [...] allow an
> organizational entry for each machine?   The user could then do
> queries [on the real-life location of the machine and whatnot]

	No need to hack on pathalias.  The program uuhosts does all
that and more.  It accesses the UUCP maps posted to mod.map on USENET.
I can supply more information or the program source to those asking.

				Cheers,

/\  Dave Shaver  -=*=-  Located at Iowa State University -- Ames, IA
\/  {okstate,umn-cs,csu-cs}!isucs1!shaver  or  shaver@iowa-state.CSNET



Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 JUN 86  11:18:23 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 13 Jun 86 11:18:34 EDT
Date:  Fri, 13 Jun 86 10:45 EDT
From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject:  Re: Zone names
To:  header-people@MC.LCS.MIT.EDU
Message-ID:  <860613144509.852045@MIT-MULTICS.ARPA>

Bill,
  The solution -- one date/time system -- is, in essence, what X.400
does.  Even if it permits an offset, it at least forces a single system.
The problem, in this regard, with RFC822 is that it permits any of three
separate systems which, to make things worse, might be described as
 - one parochial
 - one confusing and (according to Mark) very hard to cope with on some
systems.
 - and one wrong.
 ..not that it permits offsets in some form.

What I don't understand is your last comment.  Would you suggest that
the user agents report the time in UT?  I used to keep an extra clock on
my desk that always showed that, but I bet most of our academic
colleagues would dislike the idea.  Both "referring to the message I
sent to you at <time>" and "the message you sent <n> hours ago" are
important types of references, the latter sometimes in the context of
"how old is this information, anyway".  They clearly can be resolved in
UT, but only if the users (not just user agents) think in UT.  Otherwise
they better be resolvable relative to someone's local time or local
frame of reference.
  The communities you mention are somewhat specialized and, to
paraphrase Mark, you are just not going to get the person or academic on
the street to give up their local zones.

I suppose that, in some ideal world, I would like to see the time always
going in UT (no offset), and to have the message carry an offset that
indicates how far the sender was from UT.  Then, one could build a user
mail-reading agent that would report, using the style of RFC822:
  DATE: DD MMM YYYY 2300.0 UT (sender-time: +1, receiver time: 1800.6 edt)
 or some such thing.

What I don't know is whether this would be consistent with your
recommendation, or whether it would be worth the trouble.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 JUN 86  12:54:43 EDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 13 Jun 86 12:54:53 EDT
Received: by hplabs.HP.COM ; Fri, 13 Jun 86 09:53:08 pdt
Date: Fri, 13 Jun 86 09:53:13 pdt
From: Scott McGregor <hpccc!mcgregor@hplabs.HP.COM>
To: header-people@mc.lcs.mit.edu
Subject: Re: Zone names.

Since people DO have stupid user agents with RFC822, why not try
to promolgate a standard that PERMITS human readable time zones
(even ambiguous ones) as acceptable COMMENTS, but REQUIRES also
an unambiguous value that smart user agents can make use of. 
 
New capabilities don't have to be supplant old ones; they can peacefully
coexist until the obvious desirability of the new over the old causes
the old to fall out of favor.  

Since X.400 can create a new world where all user agents are smart,
there is no need to have the human readable ones there,  and it
is good to push for a simple unambiguous timezone representation for
message transmittal there, with no need for the human readable
representations.  But, many people have working RFC-822 mail systems
with primitive user agents and no great desire to build new user
agents right away.  A policy which meets their needs with limited
changes necessary to their mailers is most likely to be quickly accepted
and implemented.

Be liberal in what you accept, strict in what you send.

    Scott McGregor
    HP Corporate Computing Center

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 JUN 86  14:27:54 EDT
Received: from NRTC-GREMLIN.NORTHROP.COM by MC.LCS.MIT.EDU 13 Jun 86 14:28:08 EDT
Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a027380;
          13 Jun 86 11:26 PDT
To: Scott McGregor <hpccc!mcgregor@hplabs.hp.COM>
cc: header-people@mc.lcs.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: Zone names. 
In-reply-to: Your message of Fri, 13 Jun 86 09:53:13 -0700.
Date: Fri, 13 Jun 86 11:26:08 -0700
Message-ID: <27378.519071168@nrtc-gremlin.northrop.com>
From: Marshall Rose <mrose@nrtc-gremlin>

    The problem with 

	"Be liberal in what you accept, strict in what you send."

    is that good citizens follow it, and bad citizens don't.  People
    still send out stuff with "EVT".  I still don't know what I should
    do with "BST".  Better to have something unambiguous as a transfer
    standard between user AGENTs (which is what 822 SHOULD be), and then
    local implementations display the date in any LOCAL format they want
    (which is what your user INTERFACE is supposed to do.  I have a
    great 822 system which works and I don't have this problem.  So do a
    lot of other people at other places.  On the other hand, some people
    still read their mail with cat and vi (that's @TYPE and @EDIT to
    you TOPS-20 folks out there).  These people (the cat'ers not the
    20'ers (-: ) can't be helped.

    Moral of the story:  do whatever you please in your local
    environment.  When you leave it, use something unambiguous.  

/mtr


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 JUN 86  14:46:29 EDT
Received: from ucbvax.Berkeley.EDU by MC.LCS.MIT.EDU 13 Jun 86 14:46:45 EDT
Received: by ucbvax.Berkeley.EDU (5.51/1.14)
	id AA04502; Fri, 13 Jun 86 11:45:54 PDT
Received: by ulysses.UUCP; Fri, 13 Jun 86 14:09:46 edt
Received: by circe.UUCP; Fri, 13 Jun 86 14:09:37 edt
Date: Fri, 13 Jun 86 14:09:37 edt
From: ulysses!smb@ucbvax.Berkeley.EDU (Steven Bellovin)
Message-Id: <8606131809.AA19368@circe.UUCP>
To: ucbvax!mc.lcs.mit.edu!header-people
Subject: pathalias vs. domains

Those interested in the subject may when to consult the Honeyman & Bellovin
paper on pathalias from the June '86 USENIX.  Among other things, it discusses
how pathalias handles domains, what it does about duplicate names (yes, they
do exists), etc.

		--Steve Bellovin

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 JUN 86  01:47:38 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUN 86  01:47:09 EDT
Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 29 Jan 86 20:52:58 EST
Date:           Wed, 29 Jan 86 17:31:34 PST
From:           Rich Wales <wales@LOCUS.UCLA.EDU>
To:             Header-People@MC.LCS.MIT.EDU
Subject:        Non-domain nicknames in mail
Message-ID:     <507432694-13157-wales@DIANA.LOCUS.UCLA.EDU>

Here's yet another chapter in the ongoing saga of "bad" and "semi-bad"
host names in mail.  This message has to do with "non-domain-style" host
names (i.e., nicknames which appear in the NIC host name table, but
which do not contain periods).

The following non-domain-style host names have been observed in connec-
tion with mail received by LOCUS.UCLA.EDU between 6 December 1985 and 15
January 1986.

Most of these names could be converted into valid (i.e., defined)
domain-style names by adding ".ARPA" to them.  Those names which do not
occur with the ".ARPA" suffix in the NIC host name table are indicated
by asterisks.

Since non-domain-style host names are NEVER going to be listed in the
domain data base, I would strongly encourage the hosts listed below to
stop using them and use the correct domain-style names instead.

I would also urge the NIC to set a deadline for phasing all non-domain-
style names out of the host name table.  (Note that I am NOT advocating
that ALL nicknames be removed -- only that nicknames without periods be
removed.)  No matter what anyone may say about transition to the domain
data base -- and no matter what anyone may say about only using a host's
"official" name -- the fact remains that as long as these names appear
in the table, people are going to continue to use them.

Also, I would suggest again to those hosts which are using the domain
data base that -- when they see a non-domain-style nickname in a mail
address -- they should try adding ".ARPA" to the name and look up the
result in the data base before giving up.  This should be thought of as
a temporary "hack", to get around the fact that it is likely to be some
time before non-domain-style nicknames have been utterly eradicated.

Before anyone asks:  I am NOT going to try to send individual letters to
system adminstrators about this issue this time.  The last time I did
this, I got very few responses.  Most people seemed to simply ignore me
(witness the size of the lists below!).  Hopefully posting this one note
to Header-People will get the word out to most of the intended audience
with a minimum of wear and tear on my fingers.

My apologies for any typos which might have made it into this list.
Also, my apologies if any hosts listed below have since fixed things.

(1) Non-domain-style host names used in return addresses of mail:

    Name used       Domain-style name
    =================================
    AERO (*)        AEROSPACE.ARPA
    AIDS-UNIX       AIDS-UNIX.ARPA
    BBNCCM          BBNCCM.ARPA, CCM.BBN.COM
    BBNCCP          BBNCCP.ARPA
    CIT-750         CIT-750.ARPA, CIT-750.CALTECH.EDU
    FORD-WDL1       FORD-WDL1.ARPA
    GLACIER (*)     SU-GLACIER.ARPA, GLACIER.STANFORD.EDU
    GSWD-VMS        GSWD-VMS.ARPA
    HPLABSD (*)     HPLABS.ARPA
    LASSPVAX        LASSPVAX.ARPA, LASSPVAX.TN.CORNELL.EDU
    MEDEA (*)       MEDEA.BERKELEY.EDU
    NRL-AIC         NRL-AIC.ARPA
    PARCVAX         PARCVAX.ARPA, PARCVAX.XEROX.COM
    SRI-SPAM        SRI-SPAM.ARPA
    SRI-UNIX        SRI-UNIX.ARPA
    SU-PSYCH        SU-PSYCH.ARPA, PSYCH.STANFORD.EDU
    TOR (*)         NTA-VAX.ARPA
    UMN-UCC-VA      UMN-UCC-VA.ARPA
    YALE-VENUS      YALE-VENUS.ARPA

(2) Non-domain-style host names used in SMTP HELO commands:

    Name used     Address         Domain-style name
    ===============================================
    ALMSA-1       26.1.0.61       ALMSA-1.ARPA
    ATHENA (*)    18.58.0.1       MIT-ATHENA.ARPA, ATHENA.MIT.EDU
    BBNCCM        8.7.0.14        BBNCCM.ARPA, CCM.BBN.COM
    BBNCCP        8.2.0.4         BBNCCP.ARPA
    FORD-WDL1     128.5.32.1      FORD-WDL1.ARPA
    GLACIER (*)   36.40.0.205     SU-GLACIER.ARPA, GLACIER.STANFORD.EDU
    HPLABSD       192.5.58.10     HPLABS.ARPA
    MEDEA (*)     128.32.0.15     UCBMEDEA.ARPA, MEDEA.BERKELEY.EDU
    MEDIA-LAB     18.85.0.2       MEDIA-LAB.ARPA, MEDIA-LAB.MIT.EDU
    MIT-EDDIE     18.62.0.6       MIT-EDDIE.ARPA, EDDIE.MIT.EDU
    NRL-AIC       26.1.0.8        NRL-AIC.ARPA
    NRL-CSS       192.5.17.112    NRL-CSS.ARPA
    PREP (*)      128.52.22.14    MIT-PREP.ARPA, PREP.AI.MIT.EDU
    SU-PSYCH      36.36.0.202     SU-PSYCH.ARPA, PSYCH.STANFORD.EDU
    UCBARPA (*)   10.0.0.78       UCB-ARPA.ARPA, UCBARPA.BERKELEY.EDU
    YALE (*)      10.2.0.9        YALE-GW.ARPA

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@LOCUS.UCLA.EDU  -or-  wales@UCLA-LOCUS.ARPA
	UUCP:   ...!(ucbvax,ihnp4)!ucla-cs!wales

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 JUN 86  16:14:18 EDT
Received: from NRTC-GREMLIN.NORTHROP.COM by MC.LCS.MIT.EDU 15 Jun 86 16:08:44 EDT
Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a004936;
          15 Jun 86 13:06 PDT
To: Header-People@mc.lcs.mit.EDU, MAIL-L%bitnic.bitnet@umd2.umd.EDU
Subject: Re: Technical Question on User Agent "reply" command 
In-reply-to: Thu, 05 Jun 86 11:59:20 EDT. <3047.518371160@dewey> 
Date: Sun, 15 Jun 86 13:06:54 -0700
Message-ID: <4932.519250014@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

I realize that this is a delayed, but I have reviewed the whole
discussion and do not find any mention of one important issue.  

This is the idea that a ReSender should choose the right tool to do what
is intended.  This is why, for example, the MH BCC:  handling actually
puts the BCC copy (blind recipient's copy) in a separate envelope in the
form of a forwarded message, to give the sender some control over the
way replies will be generated.  The recipient of the BCC COPY is not
inadvertently able to reply to all the non-BCC recipients.  Believe me,
this is a really big plus for MH.

On the other hand, MH had a "dist" command for ReSending, and it
provides to the new ReSent-to and ReSent-cc recipients an unaltered
copy of the original Reply-to, To, Cc, and Return-path headers so they
can infact reply to the original.  (I don't know of any UA that would
also automatically include ReSent-to, ReSent-cc, or ReSent-by
addressees in a reply, so this must be done manually in all cases I
know of.)

But, to summarize:  

ReSenders should use Forward to provide an enclosed copy when they want
replies to come back to the From, To, Cc on the ReSent (Forwarded)
addressees.

When the desired effect is to enable recipients to reply to the
original, the ReSender should use MH Dist, or MM REMAIL, or HERMES
RESENT, or MMDF MSG "y", or .... depending on your UA.

My plea is to avoid extending a local problem based on user
misunderstanding of the proper use of tools, into a network problem
where-in we all have to extend and our UA softweare with additional
complex and overly structured behavior.

Best - Stef

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JUN 86  11:44:43 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86  11:41:39 EDT
Received: from sri-spam.arpa by MC.LCS.MIT.EDU 18 Feb 86 05:38:49 EST
Received: by sri-spam.arpa (5.4/4.16)
	id AA29731; Tue, 18 Feb 86 02:37:31 PST
Date: Tue, 18 Feb 86 02:37:31 PST
From: gds@sri-spam.ARPA (Greg Skinner)
Message-Id: <8602181037.AA29731@sri-spam.arpa>
To: header-people@mit-mc.ARPA
Subject: loop control

Hello everyone.  Remember this historic event?

> From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV  Wed Dec 11 01:37:39 1985
> Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16)
> 	id AA01923; Wed, 11 Dec 85 01:37:39 PST
> Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST
> Return-Path: <mcvax!ace!teus>
 ...
> Message-Id: <8512101018.AA16148@sunrel1>

It's my opinion that loop control should be handled the same way in our
mailing lists as in conferencing systems, in this way (previously
posted). 

> It might be the case that we also want to modify our mailers so that
> upon receipt and full delivery of a message with a given Message-ID, all
> subsequent messages received with that same Message-Id are dropped on
> the floor (no need to advise anybody automagically of duplicates, since
> we don't want to see exponential growth of looping mail :-).  I don't
> know if this is an MHS requirement or not but it is essential in a
> conferencing system (where the same messsage might come from different
> nodes in a network) and would relieve us of seeing duplicates.  The only
> problem is that not all mailers generate Message-IDs at the source of
> the message, plus a redistributor may replace (or add) its own
> Message-ID.  We should limit the number of Message-IDs to one per
> message.

I don't see what is so unreasonable about checking the Message-ID to see
if something was already delivered.  Given the proliferation of
conferencing systems which are currently being fed into the ARPA
Internet mailing list environment, and the possible multiple points of
entry for them (not currently, since most Usenet groups are "gatewayed"
from single points of entry, but I wouldn't be surprised if a some
future point in time the "gateways" decide they cannot handle such a
high crossover load, and begin to share the load of distribution into
the ARPA Internet) possible situations for duplicate delivery of mail
are created.  In our current environment, duplicate mail is already
created!

I haven't looked into it, but it seems like it wouldn't be too hard a
change to make in sendmail.  This won't handle all the cases of possible
duplicates (see above examples) but it should handle the detection of
duplicates from conferencing systems.

Which reminds me ...

There are a couple of communities within the ARPA Internet working on
conferencing systems, and I was wondering how their work is progressing
(specifically, the multimedia conferencing system and NNTP).  If any of
you are on these lists, please drop me a note.  It might be good if some
kind of standard could be decided on for handling the conversion of a
specific conferencing system to our (future) conferencing system(s).

--gregbo

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JUN 86  12:08:49 EDT
Received: from titan.arc.nasa.gov by MC.LCS.MIT.EDU 17 Jun 86 12:04:23 EDT
Received: Tue, 17 Jun 86 09:01:06 PDT by titan.arc.nasa.gov (5.45/1.1)
Date: Tue, 17 Jun 86 09:01:06 PDT
From: Jordan Hayes <jordan@titan.arc.nasa.gov>
Message-Id: <8606171601.AA17494@titan.arc.nasa.gov>
To: header-people@MC.LCS.MIT.EDU
Subject: Re:  loop control

	From: gds@sri-spam.arpa (Greg Skinner)

	I don't see what is so unreasonable about checking the
	Message-ID to see if something was already delivered.

	I haven't looked into it, but it seems like it wouldn't be too
	hard a change to make in sendmail.  This won't handle all the
	cases of possible duplicates (see above examples) but it should
	handle the detection of duplicates from conferencing systems.

It's not, but the change should not be made to sendmail. Sendmail is
best viewed as a big cross-switch. An external mailer (in the strict
sendmail definition) should be written to deal with conferencing (much
in the way that uucp has its own mailer, and the built-in IPC mailer
takes care of SMTP stuff) and that hack should be put into that. I
think that bboards in MH is closer to what you want (not sure if it
checks message ids -- mtr are you out there?) and I think Erik Fair is
working on the USENET gatewaying software. I *know* he's doing this.

/jordan

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JUN 86  14:07:52 EDT
Received: from NRTC-GREMLIN.NORTHROP.COM by MC.LCS.MIT.EDU 17 Jun 86 13:57:08 EDT
Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a010062;
          17 Jun 86 10:48 PDT
To: Jordan Hayes <jordan@ames-titan.ARPA>
cc: header-people@mc.lcs.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: loop control 
In-reply-to: Your message of Tue, 17 Jun 86 09:01:06 -0700.
             <8606171601.AA17494@titan.arc.nasa.gov> 
Date: Tue, 17 Jun 86 10:47:52 -0700
Message-ID: <10054.519414472@nrtc-gremlin.northrop.com>
From: Marshall Rose <mrose@nrtc-gremlin>

Well, the BBoards channel in MH doesn't check the message-id:s, it assumes
that your distribution tree is acyclic.  Stef had a student working on
his enhancement about 5 years ago(!!) but nothing came of the work(sad).

/mtr

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 JUN 86  14:31:25 EDT
Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 17 Jun 86 14:32:06 EDT
Date: Tue 17 Jun 86 11:30:54-PDT
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Loop control
To: header-people@MC.LCS.MIT.EDU
Message-ID: <VAX-MM(194)+TOPSLIB(120)+PONY(0) 17-Jun-86 11:30:54.SRI-IU.ARPA>

Any mailer that discards a message because it contains a Message-ID
that has already been seen could be discarding a perfectly valid
message!  Things are more complicated than this; this simple algorithm
is dead wrong.

Back when this was a hot topic of debate (~6 months ago?) I wrote a
fairly long message which I believe gave a correct treatment of this
subject (at least, no one disagreed with it).  I suggest you find this
message in the archives, though I don't know where they are.

Are we forever doomed to go around in circles on this list?

Peter
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 JUN 86  21:18:51 EDT
Received: from SIMTEL20.ARPA by MC.LCS.MIT.EDU 21 Jun 86 21:15:51 EDT
Date: Fri, 20 Jun 1986  22:24 MDT
Message-ID: <WANCHO.12216482787.BABYL@SIMTEL20.ARPA>
From: WANCHO@SIMTEL20.ARPA
To:   HEADER-PEOPLE@MC.LCS.MIT.EDU
cc:   WANCHO@SIMTEL20.ARPA
Subject: Truncated From: lines

I recently became the keeper of the VIDEOTECH mailing list, which
feeds into net.video and vice-versa.  Last week a user at BRL replied
to a net.video message and his message arrived here safely and intact.
However, in the process of redistributing his message, some mailer
truncated his From: line, leaving what appears to be "unbalanced"
parens and a left angle bracket.  The only reason I know this is from
the many mail rejection notices I received complaining about the
imbalance.

My question for today is why do these mail servers care what the From:
line looks like?  I thought their only business was the envelope and
not its contents.  (Oh, nevermind.  I forgot about uucp mail...)  Then
the question is why would a mailer truncate the From: line in the
first place?  Do certain mailers have a line length limit?  If so, why
truncate and cause problems for others down the line, and simply
refuse the message instead?

Does anybody wish me to send specifics and details to this list or do
you have enough to address this problem?

--Frank

Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JUN 86  09:04:58 EDT
Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86  19:08:42 EST
Received: from OZ.AI.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Feb 86 13:45-EST
Received: from ATHENA.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Feb 86 12:13-EST
Received: by ATHENA (5.15/4.7)
	id AA00700; Thu, 20 Feb 86 12:11:30 EST
Received: by PRIAM (5.15/4.7)
	id AA03884; Thu, 20 Feb 86 12:13:56 EST
Date: Thu, 20 Feb 86 12:13:56 EST
Message-Id: <8602201713.AA03884@PRIAM>
From: Robert L. Krawitz <rlk@ATHENA.MIT.EDU>
Sender: rlk@ATHENA.MIT.EDU
To: info-nets@oz
In-Reply-To: NSF-CS@USC-ISI.ARPA's message of 20 Feb 1986 10:26-EST
Subject: Re: FYI
ReSent-Date: Fri 21 Feb 86 19:08:28-EST
ReSent-From: Robert Lenoil <LENOIL@DEEP-THOUGHT.MIT.EDU>
ReSent-To: header-people@MC.LCS.MIT.EDU
ReSent-Message-ID: <12185241093.19.LENOIL@DEEP-THOUGHT.MIT.EDU>

nsf-cs and rem have proposed the idea that mail bouncage should be
returned to the moderator of a mailing-list as opposed to the
originator of the message.  I think the idea is interesting enough to
warrant discussion here, or perhaps on namedroppers.  There seem to be
problems with this suggestion, but I do like the concept, as I have
had this problem with mailing lists that I am on.  The problems, as I
see them.

1)  Oz's mailer would have to be hacked.

2)  Many mailers across the country would have to be hacked, as
bounces are often originated at remote sites.

3)  What algorithm should be used to determine whether an address is a
mailing list or an ``atomic'' address?  We could perhaps agree that
any address info-* or bug-* is a list, but there are plenty of lists
(telecom, sf-lovers,...) which don't fit the pattern.  I don't see how
a mailer could tell that telecom, say, is a list or a person.  In
fact, there are addresses on info-nets that I can't be certain are
individuals as opposed to lists.  This makes tracking down problems
difficult.  A global mailing-list database is also out of the question
for obvious reasons.

4) The address of the moderator is usually of the form <list>-request.
This itself expands to something else, and can thus break.  This is
more likely to happen then a personal address breaking (i. e. rlk),
but less likely than a large distribution list (such as info-nets).
On the other hand, my own mail reception system has broken a number of
times lately, which could lead to serious looping.  And, of course,
the request address may not exist.

Some solutions that I can see:

1) and 2)  just require standardization of some sort (try telling
uucp!)

3) could perhaps be solved by the mailing list expander inserting a
header something like "Errors-To:" with the name of a responsible
party.  This would help standardize things as well.

4)  probably just requires maintainers to keep their mail flowing.

The overall problem I see is standardization; the idea of having a
concept of a person responsible for a mailing list at a lower level
than postmaster is a good one.

Comments?

Robert Krawitz
info-nets-request@mit-mc

Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JUN 86  09:05:01 EDT
Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86  19:08:57 EST
Received: from OZ.AI.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Feb 86 17:38-EST
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Feb 86 16:24-EST
Received: from CSNET-SH.ARPA by MC.LCS.MIT.EDU 20 Feb 86 16:25:09 EST
To: "Robert L. Krawitz" <rlk@athena.mit.edu>
cc: info-nets@mc.lcs.mit.edu
Subject: Re: FYI 
In-reply-to: Message from "Robert L. Krawitz" <rlk@athena.mit.edu>
	posted Thu, 20 Feb 86 12:13:56 EST.
Date: Thu, 20 Feb 86 16:16:15 -0500
From: Dennis Rockwell <dennis@CSNET-SH.ARPA>
ReSent-Date: Fri 21 Feb 86 19:08:44-EST
ReSent-From: Robert Lenoil <LENOIL@DEEP-THOUGHT.MIT.EDU>
ReSent-To: header-people@MC.LCS.MIT.EDU
ReSent-Message-ID: <12185241142.19.LENOIL@DEEP-THOUGHT.MIT.EDU>

	From: "Robert L. Krawitz" <rlk@athena.mit.edu>
	Date: Thu, 20 Feb 86 12:13:56 EST
	Subject: Re: FYI

	3)  What algorithm should be used to determine whether an address is a
	mailing list or an ``atomic'' address?  We could perhaps agree that
	any address info-* or bug-* is a list, but there are plenty of lists
	(telecom, sf-lovers,...) which don't fit the pattern.  I don't see how
	a mailer could tell that telecom, say, is a list or a person.  In
	fact, there are addresses on info-nets that I can't be certain are
	individuals as opposed to lists.  This makes tracking down problems
	difficult.  A global mailing-list database is also out of the question
	for obvious reasons.

	4) The address of the moderator is usually of the form <list>-request.
	This itself expands to something else, and can thus break.  This is
	more likely to happen then a personal address breaking (i. e. rlk),
	but less likely than a large distribution list (such as info-nets).
	On the other hand, my own mail reception system has broken a number of
	times lately, which could lead to serious looping.  And, of course,
	the request address may not exist.

Both of these problems have been addressed and the standard method of
implementation is for the mail exploder itself to rewrite the return address
*in the envelope*, not in the message text.  This way, all you need is a
mail handling program at the exploder that takes in submissions and
resubmits them to the list members (envelope only, remember) with a pre-set
return address configured in some reasonable way (typically, if the name
<list>-request a valid recipient at the exploder's host, use that).  Mailers
that fail typically don't parse the message itself, they just send errors to
the envelope return address.  The envelope return address is what UUCP
passes around in the command file, for instance.

This scheme has been in use on the Internet for several years, and holds up
well except in the presence of mailers that confuse the envelope with the
message text.  Many mailers (or maybe just many hosts running the same
broken mailer) rewrite the From: field with the envelope return address,
losing the name of the submitter.

Anybody care to pick holes?  Claims that confusing the envelope with the
text is not a bug, but a feature, will be met with derision.

Dennis Rockwell
CSNET Technical Staff

Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JUN 86  09:05:05 EDT
Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86  19:09:12 EST
Received: from OZ.AI.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Feb 86 15:26-EST
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 21 Feb 86 13:55-EST
Received: from ucbarpa.berkeley.edu by MC.LCS.MIT.EDU 21 Feb 86 13:56:09 EST
Received: by ucbarpa.berkeley.edu (5.45/1.9)
	id AA13200; Fri, 21 Feb 86 10:54:55 PST
Date: Fri, 21 Feb 86 10:54:55 PST
From: fair@ucbarpa.berkeley.edu (Erik E. Fair)
Message-Id: <8602211854.AA13200@ucbarpa.berkeley.edu>
To: dennis@csnet-sh.arpa, rlk@athena.mit.edu
Subject: Re: FYI
Cc: info-nets@mc.lcs.mit.edu
ReSent-Date: Fri 21 Feb 86 19:08:59-EST
ReSent-From: Robert Lenoil <LENOIL@DEEP-THOUGHT.MIT.EDU>
ReSent-To: header-people@MC.LCS.MIT.EDU
ReSent-Message-ID: <12185241187.19.LENOIL@DEEP-THOUGHT.MIT.EDU>

All mail leaving ucbvax from the USENET to various internet mailing
lists go out in the following way:

SMTP command:
	MAIL FROM:<list-request@listhost.foo>

mail header:
	From: flup!blatz!bar!user@ucbvax.berkeley.edu
	Sender: usenet@ucbvax.berkeley.edu

the MAIL FROM is a flagrant lie, but it causes bounces from the mailing
list to go to the list-request address, rather than to me, or the user
out on the USENET (neither of whom can do anything about it anyway).
Except, of course, for mailing lists on TOPS-20 systems using old
broken versions of MMailer, which insist on sending errors to the
`Sender:' which is WRONG. (read RFC821).

A new working version of MMailer is available from MRC@SIMTEL20.ARPA,
and I strongly suggest that you beat, badger, pester, annoy,
exasperate, and otherwise convince your local postmaster to install
this version as soon as possible (postmaster@usc-isif.arpa, are you
listening?).

Sendmail machines, of course, already do the right thing. They also
have a facility known as a list owner, which causes any errors in SMTP
delivery to any address on the list to get sent to the list owner,
rather than to the sender of the message. No header hacking required.

Why am I so irritated about this? I'm usenet@ucbvax.berkeley.edu.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JUN 86  09:06:47 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUN 86  09:06:33 EDT
Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 21 Feb 86 21:24:23 EST
Date: Fri 21 Feb 86 11:47:35-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Mail looping
To: header-people@MC.LCS.MIT.EDU
Cc: pkarp@SRI-IU.ARPA
Message-ID: <VAX-MM(174)+TOPSLIB(114)+PONY(0) 21-Feb-86 11:47:35.SRI-IU.ARPA>

I believe I have at least a good theoretical understanding of how
to prevent mail loops.  In the previous messages on this topic it
hasn't been clear to me how one could theoretically prevent mail
loops, or if this is even possible.  I believe I do know how to do
it in theory; if you all buy this argument then we can talk about
the implementation later.

I apologize if this is obvious to everyone; it wasn't obvious to me and on
re-consideration of the messages I've seen it still doesn't appear obvious.

Consider the following example.  A message originates on Host-A, and is
set to a mailing list called "LIST@Host-B".  One element of LIST on Host-B
is the address SUB-LIST-1@Host-C.  An element of SUB-LIST-1 on Host-C is
SUB-LIST-2@Host-B, from which it gets distributed to various individuals.
Let us postulate that the original message was also set to "USER@Host-B",
and that  "USER@Host-B" is also a member of SUB-LIST-1. Thus,
"USER@Host-B" should receive two copies of the message: one direct from
Host-A, and one with return path: @Host-C,@Host-B:Originator@Host-A.

Notice that the "same message" gets routed through Host-B several times,
and that it would be incorrect for Host-B to think it has detected a loop
simply based on the Message-ID created by the message originator (this has
been pointed out before).  Also note that the "same message" gets sent to
the same recipient several times (USER@Host-B), and it would also be
incorrect for Host-B to suppress the duplicate simply because it sees two
messages with the same Message-ID going to the same recipient.  Both of
these conditions look like loops but are not.


So, what's the solution?  Consider an abstraction.  Imagine that a mail
message is simply a packet getting switched between the nodes of a
network. Mail packets are special in that any one packet can be duplicated
into several other packets at other nodes as mailing lists are expanded.
These child packets then go their own way in the network.  There are two
strcutures of interest here.  One is the path a given packet follows through
the network. The other is the mailing-list-based packet-synthesis tree
which shows how one initial message packet gets duplicated into a whole
swarm of child packets which eventually get either dropped on the floor or
land in someone's mailbox.

A loop condition occurs when a packet P with the following properties has
arrived at a network node:
	a) either that same packet or one of its ancestors in the packet-
	synthesis tree, P',  has been to that node before.

	b) Packet P and packet P' were both addressed to the same
	recipient.

How can a host detect a loop condition?  Simple: when it relays a packet
it puts a mark on that packet which it will recognize if that packet or
any of its descendants ever arrives at that host again.  It also must record
what recipients the packet was destined for, and check all incoming
packets to determine if it has seen them or an ancestor of theirs before,
addressed to the same recipient(s).


So again, if this looks right we can start worrying about implementation.


Peter
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JUN 86  23:43:45 EDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 22 Jun 86 23:45:03 EDT
Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Sun 22 Jun 86 20:40:02-PDT
Date: Sun 22 Jun 86 19:30:12-PDT
From: David Roode <ROODE%BIONET@SUMEX-AIM.ARPA>
Subject: Re: FYI
To: rlk@atherna.mit.edu, header-people@MC.LCS.MIT.EDU
In-Reply-To: <8602201713.AA03884@PRIAM>
Message-ID: <12216986318.17.ROODE@IC2060>

Certain sites already handle return of mailing list error messages
to the logical equivalent of the list moderator.  They do this
by definition of a mail identity X-RELAY for mailing list X.
X-REQUEST still exists.  On a local site any mail to an entity
X for which a corresponding X-REQUEST exists has its return
path set to X-REQUEST so that downline errors do not
propogate back up the list to the originator.  This is a simple
and expedient way of handling all the problems associated
with error messages for list recipients.

The separation of X-REQUEST and X-RELAY is valuable because
the type of messages directed to each varies.  The volume of traffic
on even a small list directed to X-REQUEST can easily drown
a few human-originated messages to X-RELAY if both are mixed.
-------
 

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 JUN 86  09:22:02 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86  09:18:25 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU 25 Feb 86 15:48:54 EST
To: header-people@mc.lcs.mit.edu
Subject: Mail Gateways
Date: Tue, 25 Feb 86 15:42:42 -0500
From: Craig Partridge <craig@loki.bbn.com>


    I recently found myself wrestling with a mail related problem
which I thought people on this list might (1) find interesting and
(2) possibly shed new light on.  The problem is complex, and doesn't
explain well without examples, so bear with me....

    As some of you may know it looks as if, in addition to the Internet
and CSNET, some substantial subset of the UUCP network and BITNET will
convert to using domain names.  To make things more complicated, it
also looks as if each of the physical networks (Internet, CSNET, UUCP
and BITNET) will probably use slightly different systems for resolving
domain names (UUCP will probably use tables on each machine, CSNET
will at least partially relay on tables maintained on CSNET-RELAY along
with the Internet domain database, etc.).  As a result, we are no
longer going to be able to route mail based on names (.UUCP and .CSNET)
or even format ('!' vs '%' or '@').

    Having set up my stage, here's the basic problem.  There are several
hosts which offer gateway service between the different mail networks.
For example CSNET-RELAY (aka RELAY.CS.NET) between CSNET and the Internet,
and SEISMO.CSS.GOV between UUCP and the Internet.  How are these gateways
to decide how to route mail to a host, if that host is on more than
one administrative network?

    For example, imagine A.ATT.COM (a phoney host name).  ATT.COM is/will
be on both CSNET and UUCP, and thus A.ATT.COM can be reached through
either network.  Now I am on LOKI.BBN.COM, an Internet host, and
mail to JOE@A.ATT.COM.  My mailer, since I am only on the Internet,
queries the domain database and finds the following information (which
is purely hypothetical -- I do not know which way ATT may choose
to route their mail):

    ; mail thru RELAY preferred over SEISMO
    *.ATT.COM.	IN	MX	10	RELAY.CS.NET.   ; CSNET relay
    *.ATT.COM.	IN	MX	20	SEISMO.CSS.GOV. ; UUCP gateway

it tries to deliver to RELAY and fails and passes the message instead
of SEISMO.  Now what is SEISMO supposed to do?  It is on the Internet,
so it could wait for RELAY (the preferred Internet relay) to come up
and then pass the message on to RELAY, or since it is on UUCP along
with ATT, SEISMO can choose to send the message via UUCP.  Which
is SEISMO expected to do?  I'm sort of inclined to say it sends to
ATT via UUCP, despite the fact this may surprise people on the Internet.
In other words, once mail reaches a gateway host it is considered to
have crossed into the new network (if that makes sense).

    But there are odd problems with this system.  What happens to mail
for ATT originating on SEISMO.  SEISMO is an Internet host, and the
domain system indicates that given their druthers, ATT would like Internet
mail routed via CSNET.  Should SEISMO send to RELAY.CS.NET? 

    More generally, the system suggest that mail within an administrative
domain will tend to stay there.  Mail originating within CSNET and destined
for a host which is both on CSNET and UUCP, will stay within CSNET.
The CSNET relay, having been conditioned to believe that mail sent
to it is destined for CSNET will not consult the Internet domain database
for information about hosts it knows how to reach.

    Does this feel like the right way to do things at the gateways?
Has anyone got better suggestions?  Let me point out one small restriction
here for those who have better ideas -- some mail systems split apart
the functions of receiving and sending mail -- so it is highly likely
that at the time the CSNET relay (or some other mail gateway) is 
deciding where to send a message, it probably no longer knows from
what network the message came in from (particularly if the names in
the headers no longer convey this information).  So any scheme which
says "if it comes in from this net, try to send it out the other net"
probably doesn't work.

Craig Partridge
CSNET Technical Staff

craig@csnet-sh or craig@sh.cs.net (CSNET)
craig@loki.bbn.com (ARPA)

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JUN 86  12:17:13 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU 24 Jun 86 12:18:23 EDT
To: header-people@mc.lcs.mit.edu
Subject: re: Mail Gateways
Date: Tue, 24 Jun 86 12:23:56 -0400
From: Craig Partridge <craig@loki.bbn.com>


People should note that the message on this subject is four months old and the
problems raised have been considered, and to some degree answered, in a paper
presented at this month's USENIX convention called "Mail Routing using
Domain Names".

Craig Partridge
CSNET Technical Staff

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 JUN 86  15:57:23 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU 25 Jun 86 15:56:06 EDT
To: header-people@mc.lcs.mit.edu
cc: cic@sh.cs.net
Subject: CSNET-RELAY and BITNET
Date: Wed, 25 Jun 86 15:56:40 -0400
From: Craig Partridge <craig@loki.bbn.com>


    Just for general information:

    We are currently unable to get mail from the CSNET-RELAY to WISCVM.
The basic problem is that WISCVM is severely overloaded.  The resulting
symptoms, which are not worth getting into here, make it impossible for
us to relay mail to them with any regularity.   The folks at WISCVM
have been working to try to fix this problem but, so far, the problem
remains unrepaired.

    Since we currently process about a 100 BITNET destined messages a
day, this is a serious concern for us.  We are trying to find alternative
gateways willing to take our traffic.  But if and until we do so, people
should be aware that messages destined to BITNET that pass through the
CSNET relay may be considerably delayed or even fail to get through.

    We apologize for the inconvenience this may cause people.

Craig Partridge
CSNET Technical Staff

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 JUN 86  23:27:35 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUN 86  23:16:41 EDT
Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 26 Feb 86 15:53:10 EST
Date: Wed 26 Feb 86 11:34:45-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Mail looping
To: header-people@MC.LCS.MIT.EDU
Message-ID: <VAX-MM(176)+TOPSLIB(114)+PONY(0) 26-Feb-86 11:34:45.SRI-IU.ARPA>

Bill Wells -

I believe it is very wrong for a mail system to REPLACE a Message-ID
within a header.  Imagine a message that loops from host A to B to C to
A.  If A were trying to detect loops, it would be unable to do so because
the Message-ID which it puton the message and recorded would have
been removed by host B.  Likewise, the ID host B put on would have been
removed by C!

It seems to me that the only alternative is for mail systems to APPEND
Message-IDs every time they forward a message.  This has obvious
implications for the size of the message (i.e., it increases every
time it is forwarded).

One trick would be to give this ID a special name, (e.g., Loop-Message-ID),
and to remove all such lines from the message header just before it is
actually delivered to a disk mailbox.  Of course this doesn't decrease
the cost of storing and transmitting a network until its end delivery.


Mark Crispin -

Doesn't SMTP EXPN only help if the loop is between two hosts?  Also,
loops can occur over different mail protocols than SMTP (e.g., UUCP).


Peter
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86  01:39:16 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86  01:40:29 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU 26 Feb 86 16:13:18 EST
To: HEADER-PEOPLE@mc.lcs.mit.edu
Subject: Mail Gateways
Date: Wed, 26 Feb 86 16:12:00 -0500
From: Craig Partridge <craig@loki.bbn.com>


    The first time thru this apparently didn't make it (it was submitted
on the afternoon Tuesday the 26th and has yet to make it through, despite
more recent messages making it o.k.).

------- Forwarded Message

To: header-people@mc.lcs.mit.edu
Subject: Mail Gateways
Date: Tue, 25 Feb 86 15:42:42 -0500
From: Craig Partridge <craig@loki.bbn.com>


    I recently found myself wrestling with a mail related problem
which I thought people on this list might (1) find interesting and
(2) possibly shed new light on.  The problem is complex, and doesn't
explain well without examples, so bear with me....

    As some of you may know it looks as if, in addition to the Internet
and CSNET, some substantial subset of the UUCP network and BITNET will
convert to using domain names.  To make things more complicated, it
also looks as if each of the physical networks (Internet, CSNET, UUCP
and BITNET) will probably use slightly different systems for resolving
domain names (UUCP will probably use tables on each machine, CSNET
will at least partially relay on tables maintained on CSNET-RELAY along
with the Internet domain database, etc.).  As a result, we are no
longer going to be able to route mail based on names (.UUCP and .CSNET)
or even format ('!' vs '%' or '@').

    Having set up my stage, here's the basic problem.  There are several
hosts which offer gateway service between the different mail networks.
For example CSNET-RELAY (aka RELAY.CS.NET) between CSNET and the Internet,
and SEISMO.CSS.GOV between UUCP and the Internet.  How are these gateways
to decide how to route mail to a host, if that host is on more than
one administrative network?

    For example, imagine A.ATT.COM (a phoney host name).  ATT.COM is/will
be on both CSNET and UUCP, and thus A.ATT.COM can be reached through
either network.  Now I am on LOKI.BBN.COM, an Internet host, and
mail to JOE@A.ATT.COM.  My mailer, since I am only on the Internet,
queries the domain database and finds the following information (which
is purely hypothetical -- I do not know which way ATT may choose
to route their mail):

    ; mail thru RELAY preferred over SEISMO
    *.ATT.COM.	IN	MX	10	RELAY.CS.NET.   ; CSNET relay
    *.ATT.COM.	IN	MX	20	SEISMO.CSS.GOV. ; UUCP gateway

it tries to deliver to RELAY and fails and passes the message instead
of SEISMO.  Now what is SEISMO supposed to do?  It is on the Internet,
so it could wait for RELAY (the preferred Internet relay) to come up
and then pass the message on to RELAY, or since it is on UUCP along
with ATT, SEISMO can choose to send the message via UUCP.  Which
is SEISMO expected to do?  I'm sort of inclined to say it sends to
ATT via UUCP, despite the fact this may surprise people on the Internet.
In other words, once mail reaches a gateway host it is considered to
have crossed into the new network (if that makes sense).

    But there are odd problems with this system.  What happens to mail
for ATT originating on SEISMO.  SEISMO is an Internet host, and the
domain system indicates that given their druthers, ATT would like Internet
mail routed via CSNET.  Should SEISMO send to RELAY.CS.NET? 

    More generally, the system suggest that mail within an administrative
domain will tend to stay there.  Mail originating within CSNET and destined
for a host which is both on CSNET and UUCP, will stay within CSNET.
The CSNET relay, having been conditioned to believe that mail sent
to it is destined for CSNET will not consult the Internet domain database
for information about hosts it knows how to reach.

    Does this feel like the right way to do things at the gateways?
Has anyone got better suggestions?  Let me point out one small restriction
here for those who have better ideas -- some mail systems split apart
the functions of receiving and sending mail -- so it is highly likely
that at the time the CSNET relay (or some other mail gateway) is 
deciding where to send a message, it probably no longer knows from
what network the message came in from (particularly if the names in
the headers no longer convey this information).  So any scheme which
says "if it comes in from this net, try to send it out the other net"
probably doesn't work.

Craig Partridge
CSNET Technical Staff

craig@csnet-sh or craig@sh.cs.net (CSNET)
craig@loki.bbn.com (ARPA)

------- End of Forwarded Message


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86  01:39:21 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86  01:40:32 EDT
Received: from gjetost.wisc.edu by MC.LCS.MIT.EDU 26 Feb 86 18:10:35 EST
Date: Wed, 26 Feb 86 17:10:05 cst
From: solomon@gjetost.wisc.edu (Marvin Solomon)
Message-Id: <8602262310.AA01092@gjetost.wisc.edu>
Received: by gjetost.wisc.edu; Wed, 26 Feb 86 17:10:05 cst
Reply-To: solomon@crys.wisc.edu
To: header-people@mc.lcs.mit.edu
Subject: Re:  Mail looping

		...I suggest that each SUB-LIST exploder also replace
		the Message-ID with a new Message-ID. 

	What if I accidentally get two compies of a message?  If they've come
	through different forwarders there'll be no way for my mail reader do
	detect this condition and delete excess copies.

The problem is worse than you indicate.  I'm less worried about you
being annoyed by seeing the same message twice than I am about the
network being fooded due to a cycle in mailing lists (which, by the
way, could result in you getting hundreds of copies of the message).
Suppose the list LISTA@HOSTA contains LISTB@HOSTB (along with hundred
of other addresses) and LISTB@HOSTB contains LISTA@HOSTA. Suppose I send a
message to LISTA@HOSTA.  Under the proposed scheme, HOSTA would put on
its own message id, say mid1, and send copies to all members of the
list, including LISTB@HOSTB.  HOSTB would replace mid1 with its own
message-id (say mid2) and forward a copy to LISTA@HOSTA.  The HOSTA
exploder wouldn't recognize the message as one it sent, so it would
strip mid2 and replace it with mid3 and send it back to HOSTB.  The
message would bop back and forth forever, each time generating hundreds
of copies.

How about this alternative:  Each exploder maintains a list of message-id's
of all messages it's exploded in recent history (a couple of days should be
plenty), and refuses to resend a message with an id on the list.
If EITHER of the exploders in the above scenario followed this algorithm,
the loop is broken, unless the other exploder either (1) held on to a
message for a very long time before relaying it (long enough for the
"smart" exploder to forget the message) or (2) messed with the
message-id.  In case (1), at least the looping would be very slow.
In case (2), I fail to see how any solution would work (short of some
sort of hashing on the message body).

As I see it, the moral of the story is

	Nobody should EVER mess with a Message-id when relaying mail.
	(Adding a Message-id if none is there is a different matter).

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86  01:39:27 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86  01:40:36 EDT
Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 27 Feb 86 03:12:04 EST
Received: by ucbvax.berkeley.edu (5.45/1.9)
	id AA02632; Thu, 27 Feb 86 00:11:25 PST
Received: by ucbjade.Berkeley.Edu (4.19/4.41.3)
	id AA16022; Wed, 26 Feb 86 23:44:43 pst
Date: Wed, 26 Feb 86 23:44:43 pst
From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO)
Message-Id: <8602270744.AA16022@ucbjade.Berkeley.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: Mail looping

In reply to:

	Date: Wed, 26 Feb 86 15:05:40 EST
	From: David Vinayak Wallace <GUMBY@mc.lcs.mit.edu>
	Subject:  Mail looping

	What if I accidentally get two compies of a message?  If they've come
	through different forwarders there'll be no way for my mail reader do
	detect this condition and delete excess copies.

True.  USENET news solves this problem by having an Article-ID assigned by
the originating host. But then that solution applies to conferencing/news
systems and not mail.

I wish we could use some tested solutions, for example,
military messages with collective address designators (ie. mailing list address)
require all addresses to be defined in the transmission instructions (ie.
envelope) or use a collective routing indicator (ie. envelope address).
The first solution is not feasible for huge mailing lists.
Is the second solution possible for Internet mail?  I don't think so
since we have to deal with mail systems that do not have SMTP mail envelopes.

This is a hard nut to crack.  So I think the solution of using news/conferencing
systems with structured distribution is the best solution. The nice thing
about news/conferencing systems that distribute between hosts (not users)
is that the news/conferencing, not mail, handles duplicates.
The news/conferencing program can assume that an article (or message)
received with a duplicate ID is really a duplicate.

Anyone for USENET news instead of mailing lists yet?

Bill Wells
netinfo%ucbjade@Berkeley.EDU

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86  01:41:50 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86  01:41:18 EDT
Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 27 Feb 86 15:10:56 EST
Date:           Thu, 27 Feb 86 10:42:19 PST
From:           Rich Wales <wales@LOCUS.UCLA.EDU>
To:             HEADER-PEOPLE@MC.LCS.MIT.EDU
Subject:        Undefined host names in mail
Message-ID:     <509913739-13257-wales@DIANA.LOCUS.UCLA.EDU>

[NOTE:  I had planned to send this message out several weeks ago, but a
mail problem at MC.LCS.MIT.EDU -- which apparently put the Header-People
mailing list out of commission for a while -- got in the way.  Apologies
for any of the following information which is out of date. -- RBW]

This message has to do with undefined host names (i.e., host names which
do not appear in the NIC host name table).  A previous message dealt
with host names that are defined in the NIC table, but which are not
domain-style (i.e., don't contain periods).

The following undefined host names were observed in connection with mail
received by LOCUS.UCLA.EDU between 6 December 1985 and 15 January 1986.

Some of these names appear in the domain data base; they are indicated
by asterisks.  Non-domain-style undefined names (i.e., those without any
periods) naturally do not fall into this category.  Nor should undefined
names ending in ".ARPA" -- since presumably these are all listed in the
NIC table.

Since an unknown number of hosts (for any of a number of reasons -- some
more or less justified, some not) do not use the domain data base and
are still using the NIC table, it is probably still advisable to list in
the table any host name which might appear in the return address of a
message.  Some special circumstances may make this impossible (e.g.,
hosts in a non-connected local network which send out mail via a gateway
machine) -- but the fact nevertheless remains that some proportion of
the net will still reject an address as invalid unless its host name
appears in the NIC host name table.  In any event, this comment should
be taken to heart as much by those hosts which are still using the NIC
table as by those hosts whose names are listed only in the data base.

In some instances where mail forwarding is involved, it is possible that
the host which made the SMTP connection to us is not the same host as
that being referred to via an undefined host name.  I assume the mail
wizards on the hosts in question will be able to sort out such cases.

My apologies if there are any typos in the following lists -- or if any
of the hosts named below have since fixed things.

Again, an asterisk (*) in the following tables indicates a host name
which occurs in the domain data base, but not in the NIC table.

(1) Undefined host names used in return addresses of mail:

    Name used               Net address     Domain-style name
    =========================================================
    CSLI-WHITEHEAD          36.9.0.8        (none found in NIC table)
    JACK.WISC.EDU (*)       192.12.12.50    (none found in NIC table)
    KID.ARPA                26.7.0.16       DECWRL.DEC.COM
    LOON.AI.MIT.EDU (*)     128.52.22.14    PREP.AI.MIT.EDU
    MOOSE.AI.MIT.EDU (*)    128.52.22.14    PREP.AI.MIT.EDU
    OBERON.ARPA             10.0.0.121      USC-OBERON.USC.EDU
    PLAYFAIR                36.10.0.171     (none found in NIC table)
    RAND-RELAY              10.4.0.5        RELAY.CS.NET
    TAKASHI.ARPA            10.0.0.25       SEISMO.CSS.GOV

(2) Undefined host names used in SMTP HELO commands:

    Name used                 Net address     Domain-style name
    ===========================================================
    AERO.ARPA                 26.2.0.65       AEROSPACE.ARPA
    AIDS-GRAPE.ARPA           10.2.0.56       AIDS-UNIX.ARPA
    ARTHUR.PURDUE.EDU (*)     128.10.0.1      PURDUE.EDU
    CS                        128.16.9.3      CS.UCL.AC.UK
    CSLI-WHITEHEAD            36.9.0.8        (none found in NIC table)
    DIONE.ARPA                128.42.1.1      DIONE.RICE.EDU
    HYDRA.ARPA                192.5.35.2      RIACS-HYDRA.ARPA
    JACK.WISC.EDU (*)         192.12.12.50    (none found in NIC table)
    KIM                       128.32.0.11     KIM.BERKELEY.EDU
    MIT-OZ                    10.3.0.44       MC.LCS.MIT.EDU
    OBERON.ARPA               10.0.0.121      USC-OBERON.USC.EDU
    OZ.AI.MIT.EDU (*)         10.3.0.44       MC.LCS.MIT.EDU
    PLAYFAIR.ARPA             36.10.0.171     (none found in NIC table)
    SRI-C3-5.ARPA             192.5.38.95     (none found in NIC table)
    TP4                       192.5.14.154    (none found in NIC table)
    TP5                       192.5.14.155    (none found in NIC table)
    TPP                       192.5.14.159    (none found in NIC table)
    UR-CAYUGA.ROCHESTER.ARPA  10.0.0.15       ROCHESTER.ARPA
    YALE-CHEOPS.YALE.ARPA     128.36.0.4      YALE-CHEOPS.ARPA
    YALE-COMIX.YALE.ARPA      128.36.0.17     YALE-COMIX.ARPA

NOTES:

(1) ARTHUR.PURDUE.EDU changed its network address from 128.10.0.1 to
    128.10.2.1 after the data used to compile this report was gathered.

(2) OZ.AI.MIT.EDU has an MF (mail forward) RR in the domain data base,
    but not an A (Internet address) RR.  I understand that this machine
    is not on the Internet.  However, the MF RR will still not be good
    enough for some hosts to be able to send mail to OZ.AI.MIT.EDU at,
    the present time, because:

    (a) Many hosts which do use the domain data base will only look for
	A (address) RRs.  These hosts will not see the MF RR and will
	thus conclude that OZ.AI.MIT.EDU is an undefined name.

    (b) Hosts which still use the NIC table, of course, will not be
	helped by a MF RR in the data base.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@LOCUS.UCLA.EDU  -or-  wales@UCLA-LOCUS.ARPA
	UUCP:   ...!(ucbvax,ihnp4)!ucla-cs!wales

Received: from ucbarpa.Berkeley.EDU by AI.AI.MIT.EDU 26 Jun 86 14:11:21 EDT
Received: by ucbarpa.Berkeley.EDU (5.52/1.14)
	id AA15256; Thu, 26 Jun 86 01:13:20 PDT
Date: Thu, 26 Jun 86 01:13:20 PDT
From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
Message-Id: <8606260813.AA15256@ucbarpa.Berkeley.EDU>
To: header-people@ai.ai.mit.edu
Subject: loops and how the USENET gateway prevents them
Cc: jordan@ucbarpa.Berkeley.EDU, rick@seismo.css.gov, ron@BRL.ARPA

I thought since the USENET gateway has to deal with the potential of
mail loops, I would comment on Just How It Is Done Here. On the USENET,
all messages must have a network-wide unique message-id because the
USENET uses flood broadcast for distribution, and if you have multiple
neighbors, it is pretty likely that you will get sent more than one
copy of the same thing. Therefore you keep a history list, and relegate
duplicates to the bit bucket.

For bi-directionally gatewayed mailing lists (e.g. videotech@simtel20.arpa
and net.video) messages are flowing in both directions. From the ARPA
side, I guarantee that anything that they send to me, I will never send
back to them. For the USENET side, anything I get from ARPA gets its
message-id checked against a message-id history list, and tossed if
I've already got it.

For the videotech example, it is set up something like this:

On simtel20.arpa the definition of the mailing list might look like this:

	videotech: user@foo, luser@bar, videotech-gateway@ucbvax

The problems are twofold with this setup:

1. When videotech@simtel20.arpa sends the gateway a message,
	the gateway must *never* send it back to videotech@simtel20.arpa
	(loop#1)

	I do the USENET to ARPA gatewaying with entries in the `sys'
	file which controls distribution of newsgroups to your
	neighbors (which set of newsgroups, and how to send to them).
	I have a pseudo-site called `internet' which has many entries
	for single groups, and the transmit field is a mailer call
	with the right destination address for the particular group.
	Example:

internet:na,!na.all,usa,!usa.all,net,!net.all,\
	net.video,!net.video.all\
	::/usr/spool/news/lib/gateway videotech videotech-request simtel20.arpa

	This basically says, if a message is in the group net.video
	(but not, for example, net.video.vhs), then fire off the
	gateway program (an awk script) to send the message to site
	`internet.' What gateway does is discard irrelevant headers
	and hack things up so that the people on the USENET will never
	see mailing list errors by pointing the return path at
	videotech-request@simtel20.arpa. The gateway script
	specifically preserves message-id, subject, and some other
	things like that.

	The mail alias on ucbvax for the gateway looks like this:

owner-videotech-gateway: usenet
videotech-gateway: "|/usr/spool/news/lib/nrecnews -n net.video -x internet"
	
	When I call the USENET software to send an ARPA message onward, I
	give it the `internet' name as a site that it should NOT send
	the message, even if the group matches.

2. When the gateway sends videotech@simtel20.arpa a message,
	the gateway will get a copy back as part of the distribution,
	which the USENET has already seen. (loop#2)

	Assuming that videotech@simtel20.arpa doesn't muck with the
	message-id (and he'd better not, otherwise we die), the gateway
	can reject the return copy because it has a record of having
	seen a message with that message-id.

	Ideally, I can make special arrangement with the mailing list
	administrator so that the gateway never get copies of anything
	it sends to the mailing list. In UNIX mail alias format, the
	mailing list definition on simtel20.arpa would look something
	like this:

videotech: videotech-gateway@ucbvax, arpa-videotech
arpa-videotech: user@foo, luser@bar

	What happens here is that normal ARPA people mail to
	videotech@simtel20.arpa, and I get a copy at the gateway.
	However, when the gateway sends a message, it sends the message
	to arpa-videotech@simtel20.arpa so that the gateway *won't* get
	a copy back.

	Fortunately, even if I make no such arrangement, the gateway
	still prevents loops by checking message-ids of incoming
	messages from the ARPA side.

Interestingly, this message-id checking has saved the USENET from three
or four ARPA mailer burps (wherein a mailer gets bit rot and sends 100
copies of the same thing). The gateway forwards the first copy, and the
rest get tossed (leaving somewhat confused USENET readers: ``Duplicates?
What duplicates?'').  The possibility exists, however, of a mailer burp
on a message without a message-id, in which case the USENET will lose
big.  Fortunately, most mailers generate message-ids (although some of
them are out of spec), and this has yet to happen.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUN 86  15:29:39 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 29 Jun 86 15:18:57 EDT
Received: from CORNELLA(MAL) by MITVMA (Mailer X1.23) id 9291;
          Sun, 29 Jun 86 15:08:42 EDT
Received: by CORNELLA (Mailer X1.23b) id 2158; Sun, 29 Jun 86 15:06:53 EDT
Date: 29 June 86 15:06 EDT
From: RMXJ@CORNELLA
Subject: What is going on?
To: HEADER-PEOPLE@MC.LCS.MIT.EDU

I just saw part of the conversation on Mail Looping and then realized
that not only had I read it before but that in fact it was from February
26th!!!  Can anyone explain this?

--- Gligor Tashkovich
    RMXJ @ CORNELLA.BITNET
    RMXJ%CORNELLA.BITNET@WISCVM.WISC.EDU

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 JUL 86  15:53:20 EDT
Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU  1 Jul 86 15:51:17 EDT
To: header-people@mc.lcs.mit.edu
cc: cic@sh.cs.net
Subject: BITNET Gateway Problems Resolved
Date: Tue, 01 Jul 86 15:46:25 -0400
From: Craig Partridge <craig@loki.bbn.com>


    To follow up my previous note -- the mail problems at WISCVM appear
to have to been fixed (thanks to Larry Landweber and crowd) and mail is
now flowing again.

Craig Partridge
CSNET Technical Staff

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU  8 Jul 86 06:12:44 EDT
Received: from WEIZMANN(VMMAIL) by MITVMA (Mailer X1.23) id 1035;
          Tue, 08 Jul 86 02:51:49 EDT
Received: by WEIZMANN (Mailer X1.23) id 3196; Tue, 08 Jul 86 09:50:50 +03
Date:         Tue, 8 Jul 1986 09:44:34 +0300
From:         Henry Nussbacher <VSHANK@WEIZMANN>
Subject:      Re: UK net (cross posted from net.unix)
To:           Ben Cranston <zben@umd5.umd.edu>,
              <header-people@ai.ai.mit.edu>
In-Reply-To:  Your message of Mon, 7 Jul 86 19:00:51 EDT

Wrong!

The document you are looking at is quite old.  I have a copy from
March 11, 1986 that reads as follows:


> 12 MAIL - EARN TO JANET
>
> The  EARN node must offer some means of constructing mail  according  to
> the RFC822 standard and sending it to userid MAILER at EARN node UKACRL.
> The  Columbia  Mailer  with  an appropriate internet exit  is  one  such
> suitable system. The destination system must offer 'Grey Book' mail.
>
> The 'To:' field must contain:
>
> To: receiver%nrsname@AC.UK
>
> 'receiver' is normally the identification of a recipient which may be  a
> distribution  list,  a  username,  or  a  real  name  depending  on  the
> destination.  'nrsname'  is  a  registered name of a  'Grey  Book'  mail
> system.
>
> Access to a number of destinations is barred for regulatory reasons.


We have been sending mail into UKACRL with an RFC822 envelope (no BSMTP
envelope supported yet) with addresses in the following form:

user%nrsname@AC.UK
user@reversed_nrsname


In actuality, 'AC.UK' is an alias for UKACRL.  'nrsname' is the janet
address in 'UK.AC.....' format.  The 'reversed_nsrname' format also works:
user@node.node.AC.UK
as long as the mail gets to MAILER@UKACRL.

Hank

Received: from umd5.UMD.EDU by AI.AI.MIT.EDU  8 Jul 86 13:27:34 EDT
Return-Path: <zben>
Received: by umd5.UMD.EDU (5.5/umd.03)
        id AA25243; Mon, 7 Jul 86 19:00:51 EDT
Date: Mon, 7 Jul 86 19:00:51 EDT
From: Ben Cranston <zben@umd5.UMD.EDU>
Message-Id: <8607072300.AA25243@umd5.UMD.EDU>
To: header-people@ai.ai.mit.edu, msggroup@brl.arpa
Subject: UK net (cross posted from net.unix)

Subject: Re: Problems with Janet and Bitnet
References: <1942@brl-smoke.ARPA>
Reply-To: zben@umd5.UUCP (Ben Cranston)
Organization: University of Maryland, College Park

In article <1942@brl-smoke.ARPA> SLG6M%USU.BITNET@WISCVM.arpa writes:

> Help!  I have been trying without success for the past two weeks
> to send a mail message to Nigel Holder at Marconi Research.  I
> am connected to Bitnet, which allegedly has the capability to
> send mail to JANET via a gateway at a Bitnet node called UKACRL
> in London.  It gets to London via Bitnet OK, but then I keep getting
> "YF21@UK.CO.GEC-MRC.U Is an invalid assress. No delivery made."
> mailed back to me?  Any ideas a) what's going wrong here, and b)
> how do I send a message to Nigel?

a: There's some kind of bovine feces about passwords using that gateway,
   see below for more information.

b: I would suggest you use the other address:

   yf21%u.gec-mrc.co.uk@ucl-cs

   that Nigel advertises in his .signature.  Note that the British net uses
   backwards domaining, and that ucl-cs reverses it for you while ukacrl
   does not.   

c: Bovine Feces:  From "EDUCOM NETWORKING" Volume 2 Number 1 1986 page 6:

EARNET/JANET GATEWAY DEVELOPMENT

A gateway between the European Academic Research Network (EARN) and the 
Joint Academic Network for academic and research institutes in the United
Kingdom (JANET) is under development at the Rutherford Appleton Laboratory
in England.

Currently EARN, BITNET's European counterpart, numbers 269 nodes.  With the
addition of JANET, networking capabilities expand by approximately 200
computers.  When fully operational, the gateway will allow transfer of files
and mail between BITNET/EARN/NetNorth and JANET sites.  NetNorth, the 81-node
Canadian academic and research network, has direct links to BITNET and EARN.

The file transfer facilities of the gateway are available now.  To transfer
a file to a JANET node, the first two lines of the file must be:

//* *FILE SITE=site name,USER=user id,PSWD=password,DEV=file
//* *FILE FILE=file name,KEEP=NO

The password is normally the one associated with the userid.  However,
password information may not be required, particularly on IBM VM/CMS
systems.  The file should be send to id JANET at EARN node UKACRL.

The mail gateway to JANET is under development and should be available
by late March.  When this work is complete, BITNET/EARN/NetNorth nodes
with Columbia mailers can send mail to JANET nodes with the following
address:

   userid@site.AC.UK

For example, mail to Fred on JANET node RL.GB would be send with the address:

   Fred@GB.RL.AC.UK

Note that node names must be reversed for transmission into JANET.  That is,
the node at which Fred receives his mail would be presented on a JANET node 
list as UK.AC.RL.GB.  BITNET/EARN/NetNorth nodes without the Columbia mailer
must send files to communicate with JANET nodes.

JANET uses the "Coloured Books" protocols developed in the U.K., and
BITNET/EARN/NetNorth use IBM's NJE/NJI protocols.  Due to lack of
standardization in both environments, not all facilities will be available
to all nodes.  For mail transfer, the BITNET/EARN/NetNorth node must provide
the Columbia mailer or compatable system, and the JANET node must offer
"Grey Book" mail.  Binary file transfer will only be supported between IBM
nodes on either network.  Interactive messaging will not be supported 
through the gateway.

Not all JANET sites will be known to the gateway at Rutherford.  A list of
available nodes will be posted on NICSERVE when the gateway is operational.
-CKW

[OK zben here again] Whew.  The bovine feces concern the password stuff.
There is probably a password built into the binary for the Columbia mailer,
which is an object-only distribution.  The Columbia mailer is written in
IBM assembler code, so you can see how much fun it is trying to support a
non-IBM-370 machine on BitNet, and why non-IBM-370 machines are sometimes
made to feel second-class citizens.  Oh well.

If you've read this far, you might wonder how to get from BITNET to the
ARPA gateway.  I don't know for sure, because I don't know if WISCVM does
the 'rightmost percent sign' stuff for multiple gateways.  One might 
write an address like:

      yf21%u.gec-mrc.co.uk%ucl-cs.arpa@wiscvm
          ^               ^
and one would want wiscvm to interpret the RIGHTMOST percent sign of the
two.  I think this is the right thing to do, and all MY mail software does
this.  If you support a mailer that does percent sign, consider implementing
this subtle point.

Also note that there was a five-part SENDMAIL patch system posted to 
mod.sources some time ago.  I printed it off but quite frankly do not know
enough to pick out which gateway it finally ended up using out of the mass
of stuff posted.  The ID coordinates were: 1636, 1638, 1639, 1642, and 1643
at "panda.UUCP".  They were submitted by:

    Jim Crammond <seismo!mcvax!cs.hw.ac.uk!jim>

Some people call me a packrat.

-
                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU <= Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 10 Jul 86 15:41:39 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2698860600402925@MIT-MULTICS.ARPA>; 10 Jul 1986 15:30:00 edt
Date:        10 Jul 86 17:27 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     A protocol for distribution lists and their managements
Message-ID:  <186565@QZCOM>

INTERNET has a defined standard for messaging (RFC821, RFC822 etc.)
but has no defined standard for distribution lists and their management.
Within the AMIGO project, we are working on the definition of such
a standard.

(AMIGO is a joint project between seven European countries.)

The purpose of this message is to outline the main parts of what should
be in such a standard, in order to get comments and ideas.

We are planning to define the standard in such a way, that it will
be usable both for distribution lists in mail networks based on
the X.400 and on the various variants of the internet mail protocols,
and also for connected distribution lists over gateways between
X.400-based and internet mail-based nets, since we expect that
this will occur often in the future.

(We are also working on distribution list facilities specifically
for use in X.400, but that work is not the topic of this message.)

In the text below, I will try to present our thinking in internet
terms rather than X.400 terms in order to make it easier to understand
for the participants of header-people.

One important goal of our standard is that any kind of nesting
of distribution lists should be possible without any risk of loops.

We think that such a standard should cover the following topics:

Distribution list expansion
---------------------------

During expansion, we are considering the following procedure of
modifying the header of a message when sent from one distribution
list to another. The procedure is illustrated by an example of
a message passing four distribution list expansions from the
original sender to the final recipient:

Input from original sender to DL-1 (the first distribution list):

     SMTP-sender: Original sender
     SMTP-rcpt:   DL-1

     From:        Original sender
     To:          DL-1

Output from DL-1:

     SMTP-sender: DL-1-request (=auditor of DL-1)
     SMTP-rcpt:   DL-2

     Resent-from: DL-1
     From:        Original sender
     To:          DL-1

Output from DL-2:

     SMTP-sender: DL-2-request (=auditor of DL-2)
     SMTP-rcpt:   DL-3

     Resent-from: DL-2
     From:        Original sender
     To:          DL-1

Output from DL-3:

     SMTP-sender: DL-3-request (=auditor of DL-3)
     SMTP-rcpt:   DL-4

     Resent-from: DL-3
     Resent-to:   DL-2
     From:        Original sender

Output from DL-4:

     SMTP-sender: DL-4-request (=auditor of DL-4)
     SMTP-rcpt:   Final recipient

     Resent-from: DL-4
     Resent-to:   DL-2, DL-3
     From:        Original sender
     To:          DL-1

In x.400-terms, "SMTP" above is replaced by "P3", "Resent-" by
"Forwarded IPMessageHeader" and the rest of the fields by the
inner "IPMessageHeader".

This procedure could formally described as follows:

- Add the name in the Resent-from field to the Resent-to field
  if that name is not already in any of the recipient fields.

- Put the name of the expanding list in the Resent-from field.

- Put the name of the auditor of the list as SMTP-sender.

The advantage with the procedure shown by the example above
is that all the distribution lists, through which the message
passes will be included in the header, enabling efficient loop
control.

Loop control
------------

With the procedure described above, three kinds of loop control
will be possible, and *all* three should be implemented:

(1) When receiving a message, do not accept it if the name of
    the DL is in the Resent-from or Resent-to fields.

(2) When expanding a list, do not forward the message to those
    members of the list which are in the "To", "From", "Resent-to",
    and "Resent-from" fields.

(3) Store the Message-ID-s of passing messages in a store of
    at least two weeks validity. Do not expand a message if
    its ID is in that list.

    Note: If the message lacks a Message-ID, the list should
    add such an ID, computed by a check-sum method. (In X.400,
    if the IPMessageID lacks an OR-name part, such a part should
    be added using the P2.originator, or, if that is lacking,
    the P1.originator).

Question: Why not put the name of the recipient in the "Resent-to"
fields of outgoing messages from a list.

Answer: (a) For a large list, this would create a very large header
            with all the list members.
        (b) Loop control of type (1) would then not be possible.

Stored propoerties of a distribution list
-----------------------------------------

A distribution list should store the following information about
itself:

- Name of the list
- Textual description of the list
- Whether anyone is allowed to send messages to be expanded by the
  list. Values TRUE or FALSE.
- List of those who are allowed to send messages to the list (if
  the previous value was FALSE).
- List of those who are to recieve messages from the list.
- Name of the auditor of the list, who is to receive conformations
  sent to the list, and who will be SMTP-sender (=P3.originator)
  of outgoing messages from the list.
- Optional name to which messages are to be forwarded if sent by
  someone who is not allowed to send via the list. (Typically this
  can be the moderator of a moderated list. It need not be
  identical with the auditor.)
- Charging algorithm valid for the list. Note that charging the
  sender is probably only reasonable for lists with a restricted
  list of allowed senders. Note that charging the sender in case of
  nested lists is not easy.
- Whether this is a moderated list.
- Whether this is a digested list. (Digesting could, for non-
  moderated lists, be done automatically by the DL software.)

Operations on the list
----------------------

The following list-management operations should be standardized.
It should be possible to transmit them as ASCII-text in the body
of messages. (Other forms, like direct-connection forms, of these
operations may also be possible.)

*Add member*: Adds one or more new members to a list.

*Delete member*: Deletes a member from a list.

*Get description*: Gets description and attributes of the list.
All the attributes described above should be retrievable. It
should be possible to input attributes to this operation to
control what data about the list which is requested. Note that
getting a list of all or some of the members of the list is
a special case of this operation.

*List lists*: Will return a list of all or some of the distribution
lists managed on a certain host.

*List personal mailboxes*: Will return a list of all or some of
the personal mailboxes managed on a certain host.

*Create list*: A newly created list will get default values on
all attributes. The creator will then if needed change these
with the operation "modify attributes".

*Modify attributes*: A general operation for modifying any
of the attributes of the list.

*Delete list*.

Access control
--------------

We are suggesting that in the simplified standard we are defining,
the rules for access control will not be standardized. However,
access control will certainly exist, and might cause some of
the operations described above, for some senders, not to be
performed or be performed only partially. For example, most people
will only be allowed to add and delete themselves from a list,
and a "list lists" operations may not return the names of local
closed lists.

Coding
------

The operations should be coded as ASCII text in the body of messages
sent to a special mailbox called "AMIGO-server" or something like
that, which should exist on each host.

Coding can be done either as human-writeable text (so that anyone
can code such an operation) or as machine-formatted text (requiring
anyone who wants to send such an oepration to have availabe a
program "directory user agent" to produce them).

A further question is whether several operations can be coded in
one message, and if so, if they can refer to each other, e.g.
one operation asking for a list of list names, and a second
operation asking for the description of each of them.




Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 10 Jul 86 21:35:28 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a003570;
          10 Jul 86 18:34 PDT
To: msggroup@brl.ARPA
cc: header-people@ai.ai.mit.EDU, Ben Cranston <zben@umd5.umd.EDU>
Subject: Re: UK net (cross posted from net.unix) 
In-reply-to: Mon, 07 Jul 86 19:00:51 EDT. <8607072300.AA25243@umd5.UMD.EDU> 
Date: Thu, 10 Jul 86 18:33:59 -0700
Message-ID: <3568.521429639@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

Hello All -- I believe the time has come for MsgGroup to cease automatic
distribution and quietly go out of business.  The traffic has become
less and less relevant and now tends to be mostly cross postings from
folks who are just trying to achieve maximum coverage for some reason.

So, without further ado, I am going to replace the main distribution
list with a simple redirector to myself so I can monitor your reactions.

I will continue to capture all the traffic, and add it to the complete
archives I have collected over the years, but the time has come to close
out what has been a very interesting 11 years of mail system pioneering.

My very best to you all - Stef (MsgGroup Moderator since June, 1975)

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 JUL 86  11:23:37 EDT
Received: from INFOODS.MIT.EDU by MC.LCS.MIT.EDU 11 Jul 86 09:10:37 EDT
Received: by INFOODS id <000001EC061@INFOODS.MIT.EDU> ;
       Fri, 11 Jul 86 09:01:14 EDT
Date: Fri, 11 Jul 86 08:57:08 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Mail header test
To: header-people@mc.lcs.mit.edu
X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu",KLENSIN     

Well folks, we are trying to test out and evaluate a new 
SMTP system.  Things look pretty much OK to me, but would
appreciate any constructive comments or pointers about 
errors.

If for some reason you can't get back here, and don't want to
clutter the list, please use my Multics address (below).
   thanks.

John Klensin   KLENSIN@INFOODS.MIT.EDU
               jck@MIT-Multics.ARPA

Received: from SRI-IU.ARPA by AI.AI.MIT.EDU 11 Jul 86 14:02:49 EDT
Date: Fri 11 Jul 86 11:00:45-PDT
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Re:     A protocol for distribution lists and their
	 managements
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc: header-people@AI.AI.MIT.EDU
Message-ID: <VAX-MM(194)+TOPSLIB(120)+PONY(0) 11-Jul-86 11:00:45.SRI-IU.ARPA>
In-Reply-To: Message from
	     "       Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" of
	     10 Jul 86 17:27 +0200

One of your loop control mechanisms - trashing messages if you've seen
their IDs within the past two weeks - is too simplistic as I explained several
times on this list.  Your other loop control mechanisms seem reasonable
though.

Do you plan to distinguish between mailing lists and mail forwarding?

I also believe your treatment of the return path (smtp-sender) is too
simplistic.  Sometimes the sender wants to see failed messages come
back to him/her, and sometimes s/he doesn't.  For example, I don't care if
everyone on header-people sees this message within the next day, but if I
am announcing an important meeting to a group of business associates 
which will take place tomorrow, I'd sure like to know if the mail can't
get to some of them.  No fixed scheme will handle this problem.

Also, I'd like to see a different field than "Resent-From" and
"Resent-To" used to distinguish the exapansion of a mailing list from
when someone manually remails a message that they have received to
someone else.
-------

Received: from UMD2.UMD.EDU by AI.AI.MIT.EDU 11 Jul 86 15:05:26 EDT
Date: Fri, 11 Jul 86 14:46:54 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
To: ARPA Internet Mail Interest List <header-people@ai.ai.mit.EDU>
Subject: "Restricted" "Standards"
Message-ID: <M1986$020798.016118BEN.ZBEN@UMD2.UMD.EDU>

>> X.400 will never appear electronically, not because someone
>> won't type it in, but because the documents are copyright...

> ...I believe the attitude of copyrighting and then restricting distribution
> is contradictory to standardization that is intended to [be] universal.
> If you want everyone to use it, give it to them.
> Is there anyone who agrees with me that standards that are expected to
> be universally adopted should have unrestricted distribution?

Regardless of the philosophical and/or moral implications raised, I am sure
that a large part of the popularity of SMTP (and in fact of the entire ARPA
suite) can be credited (blamed? :-) on the fact that not only are the various
RFC documents freely distributable but that the NIC maintains copies of them
for anonymous FTP at any time!  If copyrighting and charging for ISO documents
is an attempt at cost-recovery, I believe it WOEFULLY shortsighted.  Here are
a few reasons why:

Joel M. Snyder <jms@arizmis> (in fact the original poster) writes:

> When you get a copy from CCITT in the proper color binding for that study
> period, you are assured that you have the exact same recommendations as
> everybody else.

A. Let's consider my mother's microwave oven and VCR (yes, this will eventually
become relevant!).  Both have clocks.  Dumb human beings sometimes tend to
push buttons that they really didn't mean to.  Part of good human engineering
is to design things so the dumb human beings have to push a LOT of wrong
buttons before they can really mess things up.

The VCR is a Sony Beta.  It uses a philosophy: make it hard to change the time.
So when one day we lost power for 15 minutes, it took me an hour to figure out
how to reset the time (manual?  where is the manual to YOUR VCR right now?) on
the stupid thing - gotta push three buttons with each hand and the other one
with your nose for crying out loud.  This corresponds to limited distribution
color coded scheme.

The microwave is a Sears bottom-of-the-line.  It takes the diametrically
opposite philosophy:

   "Make it so easy to FIX that messing it up ain't no great disaster!"

You push "Time Set" then what time it is.  No muss no fuss.  So, if you find
that two copies of RFC822 don't agree, sign on and FTP a new one from the NIC!
You have no worry about being OUT of date because the marginal cost to get
back UP to date is so small.

B.  When I argue with someone about putting up a mail implementation on a
machine that hitherto had none, he's going to give me a little static.  It's
VERY impressive to show him how easy it is to fetch and print a copy of the
documentation he will need to implement the protocol suite.  It removes one
argument: "I don't know/can't find the documentation".  Can't read comes later.

I dunno - working here at Enourmous State, a branch of the state government
of the Kingdom of Merryland, one gets a somewhat jaundiced viewpoint.  Every
time I deal with a (lowest bidder) red pen that right out of the box will not
write, or (lowest bidder) computer paper that will tear anywhere BUT the
perforations, I think of the brass hat who looks good by saving 10 dollars on
a million dollar purchase.  I really wouldn't mind except that his glory comes
at my expense.  What we say here is:

   The University will do ANYTHING to save money, no matter WHAT it costs.
                                      ^^^^^^^^^^                    ^^^^^
                                      perceived                    actual

I think that to jeopardize the acceptance of a standard by restricting its
availability, all in the name of mindless bean-counter cost recovery, is
being penny-wise and pound-foolish.  Pounds?  Oh, that was before the metric
standard money...

> I don't mean to sound condescending,
> but CCITT recommendations are really not aimed at people like you;
> they are written by countries for countries.
> The member bodies of the CCITT don't care for public domain implementations.

I won't sound condescending either, but the Apple computer didn't come from
any DEC research lab or any member of CCITT or any country per se.  It came
from three guys working out of a garage.  The Europeans might not understand
this, perhaps because there some vestige of nobless oblige would cause any
worthy Woz types to become adopted by an established engineering firm.

If CCITT recommendations are really written by countries for countries then
let the fool countries write the code (sounds fair).  And if the member bodies
of CCITT want to keep me barefoot and pregnant then there is no law that says
I have to go along with it...

(Neither barefoot nor pregnant, and aiming to keep it that way...)

                    umd5.UUCP       {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU <= Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 11 Jul 86 17:16:08 EDT
Received: from WEIZMANN(VMMAIL) by MITVMA (Mailer X1.23) id 5521;
          Fri, 11 Jul 86 15:54:06 EDT
Received: by WEIZMANN (Mailer X1.23) id 8487; Fri, 11 Jul 86 10:25:29 +03
Date:         Fri, 11 Jul 1986 10:05:03 +0300
From:         Henry Nussbacher <VSHANK@WEIZMANN>
Subject:      AMIGO
To:           <header-people@ai.ai.mit.edu>

Jacob,

1) Hopefully whatever the List sends out will have a very clear standard
   that will inform my UA not to acknowledge receipt of the list mail.
   Distribution list mail should never generate acknowledgements.  Otherwise,
   the network becomes bogged down with 500 distribution list pieces of
   mail floating out and 500 pieces of acknowledgement mail floating back
   to either the original sender or the list itself (heaven forbid!)

2) The list should be settable by the moderator to be either reply-to user
   or reply-to list.  This way the UA can be used for replying and to reply
   to the correct place.

3) List Lists:  Yes, that is nice to be able to find out what lists exist
   on a certain host but I can easily forsee network users building programs
   to poll every node in the network to see what lists are available.  You
   need either a human or a process for sites to centrally register the lists
   they want known to the rest of the network.

4) Here is where I flame:  After using INTERNET for 6 years, I can say that
   I am totally disgusted with it's handling of distribution list mail.
   The problem is that RFC822 mail serves as a pseudo-conferencing system
   and thereby blurs the meaning of 'electronic mail'.  I want mail to mean
   mail and computer conferencing to mean computer conferencing.  And my
   UA should be able to seperate the two and let me handle e-mail immediately
   and computer conferencing objects in my leisure.

   Instead, I end up with 100+ pieces of electronic mail every day from
   various Arpanet lists, Bitnet lists, Csnet lists, etc.  Mixed in that is
   true electronic mail.  If all AMIGO does is change the headers around
   and adds some added bells and whistles then you haven't really done anything
   to improve on RFC822.

   If you're gonna do it - do it right!

Hank

Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 12 Jul 86 02:21:08 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a010778;
          11 Jul 86 23:19 PDT
To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.ARPA, header-people@ai.ai.mit.EDU
Subject: Re: A protocol for distribution lists and their managements 
In-reply-to: 11 Jul 86 11:00:45 PDT.
 <VAX-MM(194)+TOPSLIB(120)+PONY(0) 11-Jul-86 11:00:45.SRI-IU.ARPA> 
Date: Fri, 11 Jul 86 23:19:13 -0700
Message-ID: <10776.521533153@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

I am bothered by several things in your proposed standard.  One is the
excessive structure it implies, and the implication that all hosts in
the entire ARPA Internet and the X.400 Internet will all have to
implement list managers that behave as you specify.  If that is a
requirement, then it is not going to be implemented at many sites.  

As I see it, and have repeatedly pointed out once or twice each year for
the last 5 years now, list distribution is something that must occur at
the User Agent Level, with the list distributror operating with the
"Authority of a User Agent".  

I essence, when a message arrives at a distributor, it is regarded by
the MTA as having been delivered.  If it cannot be delivered to the
distributor, then a failure should go to the originator.  If it is
delivered, and is received by the distributor, then failures should not
go to the originator.  So we see that "delivery" suggests that it is now
in the hands of a UA level entity.

Furthermore (and Jacob's proposal includes this idea) the distributor
opens up the 822 headers, or the P2 header, and modifies it in some way.
According to all the rules, this is never to be done by any MTA, so this
must be done by an entity operating with the authority of a UA.  When
the message is ready to be RePosted, then it reappears to the MTA as a
new item, with indications to return failures to the "new originator"
which is our "distributor".  

So, as I see it, if this is really a UA doing something to RePost
modified versions of received mail, it can do anything it wishes in the
way of adding legal new fields or changing the content of old ones to
accomplish its objectives.  In RFC822, it is possible to simply add
fields with new unique names, such as Distributor-ID:  and
Distribution-Item-ID:  to unambiguously identify the distribution agent
and the item that is being distributed.  I would then use this
information to contol looping.  If you see your own ID come back, or
your ecognize your own item ID in a new arrival, you can take whatever
actions seem correct, such as delete forthwith, or refer it to a human
for evaluation, or something.  (Distributor's Choice) 

In short, I would suggest finding a way to totally separate distribution
indicators and controls from MTA operations, to keep from getting them
entangled with each other.  The distributor standard should accept both
RFC822/821 and X.400-P1/P2 to be immutable as given, and work the
problem entirely at the UA level, assuming UA authority as I have
described it above.  I don't think all that structure is needed in this
simplified model.  

Also, I don't think that list management tools should be standardized in
the same document that standardizes on the mechanisms of distribution
9given some list) and the mechanisms for loop control.  These are two
very differenet kinds of standards, and they should be kept totally
separate so one can be replaced without affecting the other.  The
modularity concept is central to the whole idea of these kinds of
standards.  

Cheers - Stef

Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 12 Jul 86 02:51:50 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a010940;
          11 Jul 86 23:50 PDT
To: header-people@ai.ai.mit.EDU
Subject: Its not the fault of Internet Mail -- Re: AMIGO 
In-reply-to: Henry Nussbacher <VSHANK@weizmann> Fri, 11 Jul 86 10:05:03 O.
Date: Fri, 11 Jul 86 23:50:03 -0700
Message-ID: <10935.521535003@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

Dear Henry -- Your flame about how all your mail and conference items
come to your single mailbox is misdirected.  

You should not condem the whole Internet Mail system for your failure to
arrange for your conference mail to be delivered to some sort of
conference address at your site.

It is not our fault that you (or your local administrator) chooses to
let all your conference and real mail get mixed up together because you
give everyone the same single address.  

Here at NRTC-GREMLIN and at many other sites that run MH BBoards, or
other sites that run other BBorad systems, the conference mail is sorted
on arrival into the BBoard folders, and it never appears in my inbox.  

I have no idea how anyone survives without BBoards if they read any of
the lists.  

If you want more information on how to get and run a BBoards system at
your site, just ask, and I will find some way to get the information to
you.

Cheers - Stef

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 13 Jul 86 19:39:42 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699134239663483@MIT-MULTICS.ARPA>; 13 Jul 1986 19:30:39 edt
Date:        12 Jul 86 09:17 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          "Peter Karp" <PKARP@SRI-IU.ARPA>
Cc:          HEADER-PEOPLE@AI.AI.MIT.EDU,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re:     A protocol for distribution lists and their managements
Message-ID:  <187236@QZCOM>
In-Reply-To: <VAX-MM(194)+TOPSLIB(120)+PONY(0) 11-Jul-86 11:00:
             45.SRI-IU.ARPA>

(a) Can you explain more fully what is wrong with using Message-ID-s
for loop control?

I can see one problem. And that is which message-ID to use for
multi-body messages, and also finding the innermost message-ID
when X.400 messages have been converted into RFC-style messages
according to RFC987, where the inner message has become part
of the text body of the RFC822 message. But those problems, I
believe, are solvable.

Another problem is that some people or message systems may be
misusing Message-ID-s, for example by changing a message (e.g.
by adding text) without changing the ID. But that happens so
rarely that I do not see it as a problem.

(b) If we want conformance with X.400, we cannot put anything
into the IPMessageHeaders than is allowed by X.400. It would
be possible to add extra header fields by putting them into the
text of the message, but I intentionally tried to avoid adding
extra header fields when a field occuring in both X.400 headers
and RFC822 headers could be used reasonably well.

(c) I agree with you that "RESENT-" may not be good to use, primarily
because RFC987 does not recommend it in X.400 gateways. Instead,
RFC987 recommends putting inner bodies as text, so I guess that
is what one should do instead. This may cause some trouble for
a DL handler to distinguish between text which are headers of
forwardes messages, and text which is really text, but that problem
is probably solvable.



Date: Sun, 13 Jul 86 20:14:20 EDT
From: Rob Austein <SRA@AI.AI.MIT.EDU>
Subject:  braino
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].69382.860713.SRA>

cancel that. it's an xx bboard already, i'll read it there.

sorry.

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 14 Jul 86 14:13:16 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699200885916348@MIT-MULTICS.ARPA>; 14 Jul 1986 14:01:25 edt
Date:        14 Jul 86 17:07 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          HEADER-PEOPLE@AI.AI.MIT.EDU, "Einar Stefferud"
              <stef@NRTC-GREMLIN>
Cc:          AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: A protocol for distribution lists and their managements
Message-ID:  <187753@QZCOM>
In-Reply-To: <10776.521533153@nrtc-gremlin.northrop.com>

The only part of our proposal which it would be very valuable
if all list expansion tools implemented is the loop controls,
both the creation of loop control info and the use of it for
loop controls. Apart from that, our proposal is intentionally
written such that it could incorporate existing activities. Even
those existing lists which are not willing to implement loop
control could be handled, by just ensuring that they will not
be part of any loops.

I agree with you that it would be much neater to add RFC822 header
fields for loop control. However, I do not believe this is possible.
The reason for this is that the proposal should work also under
X.400, and since CCITT seems to be firmly determined to put distribution
lists in the P1 layer, there is very small changes of getting
them to accept new P2 facilities for handling mailing lists.



Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 14 Jul 86 15:49:27 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a022589;
          14 Jul 86 12:47 PDT
To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.ARPA, 
    AMIGO_Group%QZCOM.MAILNET@mit-multics.ARPA, 
    Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.ARPA
cc: HEADER-PEOPLE@ai.ai.mit.EDU
Subject: Re: A protocol for distribution lists and their managements 
In-reply-to: Your message of 14 Jul 86 17:07:00 +0200.
             <187753@QZCOM> 
Date: Mon, 14 Jul 86 12:47:48 -0700
Message-ID: <22586.521754468@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

I am glad to hear that you intend for the main force of the Distribution
List Standard to apply to the Looping Controls.  I suggest that you make
this more obvious, with the "Required Optional Facilties" set forth as
being suggestions only.  

As for your problem with 822 vs X.400, I suggest that you do what you
must to comply with X.400, and let that reflect into new RFC822 headers
to be dealt with in the ARPA-X.400 Gateway, which I believe will not
prsent any difficulties on the 822 side, or the X.400 side.

RFC822 is extensible (Good Idea) so lets use the built in extensibility
to solve the problem without requiring any changes to anyting on the
ARPA Internet side.  

If CCITT and ISO want to muck about and make it difficult to do things
at the P2 level, they are only hurting their own products and services.
I am constantly amazed at how the European CCITT/ISO folks seem to feel
a strong need to regulate what I put in my headers.

Stef

Received: from UMD2.UMD.EDU by AI.AI.MIT.EDU 15 Jul 86 15:37:15 EDT
Date: Tue, 15 Jul 86 15:26:22 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
To: ARPA Internet Mail Interest List <header-people@ai.ai.mit.EDU>
CC: Mark Horton <cbpavo.cbosgd.ATT.UUCP!mark@seismo.CSS.GOV>
Subject: Domain branching (50 to 100)
Message-ID: <M1986$021165.016118BEN.ZBEN@UMD2.UMD.EDU>

From: mark@cbpavo.cbosgd.att.com (Mark Horton)
> Based on my experience on UUCP, you can fan out a lot wider than 50-100.
> I've seen fanouts of 1000 with no serious problems, although beyond
> that may be getting iffy.  Since the top couple levels give no idea
> of what net to forward to anyway, I'm not sure that difference in fanout
> buys you anything technically.  On the other hand, keeping the names
> short so people won't mind typing them is important.  Which would you
> rather send to: mark@cbosgd.ATT.COM, or mark@d.osg.cb.btl.att.com?
> The latter describes the organizational heirarchy better, but...

I don't want to get into a 7+-2 discussion.  That some cognitive limit exists
is more important than the actual number.  The 50-100 number probably came
from some obscure RFC or net.mail posting or something.  But remember the
whole domain thing came about because maintaining the "one true list" got to
be such an administrative bear.

I'm not sure I understand your comment about the top couple of levels giving
no information - I thought you had to go all the way to the final nameserver
before you had ANY routing information...

I would much rather type cbosgd.ATT.COM than d.osg.cb.btl.att.com but I see
the wave of the future being personal databases to associate these things
with short personal IDs anyway (c.f. IBM NAMES).  I have all your data saved
under the name HORTON - let me pull it in here:
----
To: Mark Horton <cbpavo.cbosgd.ATT.UUCP!mark@seismo.CSS.GOV>
----
Some of the other ones have phone numbers, snailmail addresses, etc.  Given
this kind of facility the question of how much the user has to type becomes
much less important.  The cost of these schemes is the gore of changing all
those entries out there when you change the name of your machine or move to
a new one.

> ...that's before every "Two-Guys-From-Italy-Pizza" starts to connect in.

One of the best pizza places in this Kingdom is called "Three Brothers".
It really is these three brothers from Italy you see...   :-)

------
                    umd5.UUCP       {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU <= Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 15 Jul 86 19:54:56 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2699308315623906@MIT-MULTICS.ARPA>; 15 Jul 1986 19:51:55 edt
Date:        15 Jul 86 23:25 +0200
From:        Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     Re: A protocol for distribution lists and their managements
Message-ID:  <188185@QZCOM>
In-Reply-To: <22586.521754468@nrtc-gremlin.northrop.com>

I completely agree that distribution should be handled in UAL,
not in MTL. I do however heard another story of who is advocating
DL in MTL, possibly also with respect to restrictions on P2.
But I still think that we can influence the CCITT/ISO work.

Tommy



Received: from Cs.Ucl.AC.UK by AI.AI.MIT.EDU 16 Jul 86 05:06:14 EDT
Received: by vax2.Cs.Ucl.AC.UK   with Delay channel  id a001225;
          16 Jul 86 9:49 BST
To: Tommy_Ericson%qzcom@Cs.Ucl.AC.UK
cc: amigo_group%qzcom@Cs.Ucl.AC.UK, header-people@AI.AI.MIT.EDU
Subject: CCITT lists in the MTL
Phone: +44-1-387-7050 ext 226
Date: Wed, 16 Jul 86 07:15:30 +0000
Message-ID: <574.521878530@UK.AC.UCL.CS>
From: Steve Kille <steve@Cs.Ucl.AC.UK>

Tommy,

Are we sure that CCITT is making the big mistake that everyone
seems to claim that it is  making.   As you well know, I
strongly agree that doing lists at the P2 level is the only
reasonable approach.

Now CCITT are definitely proposing doing distribution lists in
the MTL.  The key thing here is that by doing it in the MTL,
the PTTs can charge for list expansion as a value added service.
However, the Reston output (I have not yet seen the
Melbourne stuff) notes "although its expansion point resides in
the MTS, a DL bears some resemblance to a UA....".   It strikes
me that what is going to happen is that CCITT will define a P2
level (correct) functionality, and then say it belongs within
the MTL.   This is exactly the same architectural fudge as they
made for content conversion.   It all boils down to the fact
that money and politics have a much stronger influence on CCITT
than having a clean model.


Steve

Received: from UMD2.UMD.EDU by AI.AI.MIT.EDU 18 Jul 86 16:09:55 EDT
Date: Fri, 18 Jul 86 14:08:32 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
To: BitNet Mail Interest List <@UMD2.UMD.EDU:MAIL-L@BITNIC.BITNET>,
    ARPA Internet Mail Interest List <header-people@ai.ai.mit.EDU>
CC: Roger Fajman <@UMD2.UMD.EDU:RAF@NIHCU.BITNET>
Subject: Multiple gateways and nameservice
Message-ID: <M1986$021620.016118BEN.ZBEN@UMD2.UMD.EDU>

> X-From:     "Roger Fajman" <RAF@NIHCU>
> Date:     Wed, 16 Jul 86  19:54:06 EDT

> There are also useful differences in routing outside of a single
> site.  For example, my node (NIHCU) is connected to the UMDD at the
> University of Maryland, only 10-15 miles away from here.  They also
> have an ARPANET connection and the BITNET and ARPANET machines are
> themselves connected.  So, if I want to send something to one of the
> ARPANET machines at the University of Maryland, it doesn't make a
> whole lot of sense for me to send it a thousand miles via multiple
> network hops to WISCVM, just so it can turn around and come all the
> way back through ARPANET.  I don't have an ARPANET connection, so I
> can't just put it onto ARPANET.  Yet, sending all my ARPANET traffic
> through the University of Maryland ARPANET connection isn't
> necessarily right either, as they may well not want to or be able to
> handle all of it.

Roger and I have talked about setting up something to do this.  My main
qualm at this point is that my connection to the Internet (ARPAnet) is
currently through the Department of Computer Science's mimsy, which is
a very busy machine, and I fear the possible political consequences of
suddenly foisting off a much greater packet traffic on them.  We have our
Internet connection basically at their sufferance.

When last we talked I suggested to Roger that we get together and discuss
this matter in the future, when we had our own Internet connection.  At
the time this was slated for June 5, but it is now July 18 and it has not
happened yet.  Sorry Roger, you know how schedules slip.  Not my fault.

My other concern is network bandwidth.  Many of our connections are actually
as slow as 9600 baud, and significant traffic could cause bottlenecks that
might impact our operation.  The umd2-umdd link was upgraded from 9600 to
64kb, but the umd2-mimsy link is still 40kb, and the umdb-gwuvm link is still
9600.  I don't know about Roger's link, he is probably on umdb but I don't
know the bandwidth offhand.

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

But his point is a good one.  If there is only one defined gateway it is
going to be a bottleneck.  There needs to be some way of spreading out the
load.  Here at UMD we have an exit for xxx.UMD.EDU pointing at UMD2 so mail
for mimsy.umd.edu, cvl.umd.edu, etc goes through the on-campus gateway.
But if somebody says mimsy.arpa or cvl.arpa then it's WISCVM time again.

The same problem can occur under nameserving.  Let's say Roger registers
blue.NIH.GOV and I request nameservice.  If I read the Internet RFC stuff
correctly all it can do is return WISCVM, or whatever the defined gateway
to the RSCS transport service might be.  It might return me multiple MX
resource records, but they will be prioritized, and the standard says I must
try them in priority order.  I have no choice about maybe using an on-campus
gateway in preference to WISCVM.

I am not sure from the standard if the nameserver is allowed to look at *my*
Internet address and maybe tell me something different than it would tell
*you*...  Anybody feel confident enough to comment on this?


Received: from Cs.Ucl.AC.UK by AI.AI.MIT.EDU 22 Jul 86 11:03:26 EDT
Received: by vax2.Cs.Ucl.AC.UK   with Delay channel  id a001520;
          22 Jul 86 9:51 BST
To: header-people@AI.AI.MIT.EDU
Cc: phil@Cs.Ucl.AC.UK, mcdowell@Cs.Ucl.AC.UK
Subject: Second attempt
Date: Tue, 22 Jul 86 08:50:01 +0000
Message-ID: <905.522402601@UK.AC.UCL.CS>
From: Steve Kille <steve@Cs.Ucl.AC.UK>

This was rejected by our domain server/mail system.  Can't get
thru to the correct NS at present, so its not clear where the
error is.

Steve
------- Forwarded Message

To: jacob_palme_qz@qzcom
cc: amigo_group@qzcom, header-people@ai.ai.mit.edu
Subject: Distribution lists
Phone: +44-1-387-7050 ext 226
Date: Mon, 21 Jul 86 15:52:48 +0000
Message-ID: <6445.522341568@UK.AC.UCL.CS>
From: Steve Kille <steve@UK.AC.UCL.CS>

Jacob,

One comment on you paper, and one general point:

1) your proposed approach of encoding protocol in ASCII in the
body of an IP Message seems like a bad move.   WHy not define a
new protocol over  P1 with X.409 encodings?  This would be much
more robust (particularly for error conditions), and would be
simpler to specify.  It is also architecturally more sound.

2) A mechanism to prevent loops, which requires neither
nasty additions to tracing info, nor the retention of history at
the list expansion point is simply to enforce strict hierarchy
by adminstrative procedures.  An easy way to do this would be
to assign a 'level' to any list, and to require that if any
member of a list is itself a list, then the level of that list
must be higher than the first list.   The 'level' would simply
be a property of the list in the DIrectory Service.   I cannot
see any type of useful use of lists which this mechanism would
prevent.

any thoughts?

Steve

------- End of Forwarded Message

Received: from Cs.Ucl.AC.UK by AI.AI.MIT.EDU 29 Jul 86 04:13:45 EDT
Received: by vax2.Cs.Ucl.AC.UK   with Delay channel  id a001137;
          29 Jul 86 9:07 BST
To: Jacob_Palme_QZ%qzcom@Cs.Ucl.AC.UK, AMIGO_Group%qzcom@Cs.Ucl.AC.UK, 
    header-people@AI.AI.MIT.EDU
Subject: Re: Distribution lists
Phone: +44-1-387-7050 ext 226
In-reply-to: Your message of 26 Jul 86 13:30 +0200.
             <190291@QZCOM>
Date: Tue, 29 Jul 86 09:01:43 +0000
Message-ID: <1099.523008103@UK.AC.UCL.CS>
From: Steve Kille <steve@Cs.Ucl.AC.UK>



         From:    Jacob_Palme_QZ@qzcom
         Subject: Distribution lists
         Date:    26 Jul 86 13:30 +0200


         HIER is the method commonly used in INTERNET. The restriction
         requiring a hierarchical structure will make message transmission
         slower and less efficient in some cases.

         In some cases it is
         natural to allow every list to be a member of every other list
         in a set of linked lists.

I dispute this last sentence.   I agree that there is a loss of
generality.   However, I would suggest that the convoluted
structures prohibited are undesirable, and that prohibiting them
is an advantage.  I can see a few cases where there would be a
need to create an 'invisible' list purely for the purposes of
structuring, but not where this would get out of hand.

I suggest a lemma (I don't have time to figure out a proof),
that ANY list structure can be represented by HIER.

As a challenge, I request REAL examples of list structures for
which HIER is inappropriate.   I suggest is is EXACTLY what is
wanted in the majority of cases, and is quite reasonable in
all others.   If this suggestion is correct, it makes HIER an
interesting choice of loop control.

Steve

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU  3 Aug 86 14:29:40 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2700929363312433@MIT-MULTICS.ARPA>; 03 Aug 1986 14:09:23 edt
Date:        03 Aug 86 16:40 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             HEADER-PEOPLE@AI.AI.MIT.EDU,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Hiearchical structure for loop control in distribution lists
Message-ID:  <192163@QZCOM>
In-Reply-To: <1099.523008103@UK.AC.UCL.CS>

Assume the following hierarchical structure of a distribution list:

          +-----TOP------+
          !              !
        SUBA-----+      SUBB
          !      !       !
     SUBSUBAA SUBSUBAB SUBSUBBA

Assume that the time to transfer a message between any two nodes in
the structure is N hours.

If a user in the SUBSUBAA system writes a message to the list, s/he
must send this message to "TOP" which would take 2N hours. The time
before the message reaches SUBSUBAA would be 2N hours back again,
or a total of 4N hours. If the user could submit his message directly
to SUBSUBAA, and have SUBSUBAA transfer it to SUBA, which would then
transmit it to TOP, it would reach members of SUBSUBAA in 0 hours
instead of 4N hours. The times to reach the different nodes would be:

Node            With hierarchical       With links both
                structure               up and down the tree

SUBSUBAA        4N                      0
SUBA            3N                      N
SUBSUBAB        4N                      2N
TOP             2N                      2N
SUBB            3N                      3N
SUBSUBBA        4N                      4N

Average         3.33N                   2N

The cost would also be lower with links both up and down the tree,
since the message need not be sent up to the TOP and then back down
to SUBSUBAA again. If TOP and SUBA were on different sides of the
Atlantic this would be a substantial saving.

Even faster, but less efficient, transmission would occur if all
the lists were members of each other. The cheapest transmission
will occur with a loop-less structure but with links both up and
down the tree.

In certain cases, it may also be politically difficult to designate
one list as the "TOP node", but this is not the major argument
against enforcing hierarchical structure.

It may also be easier for the users if they can submit new entries to
any list in the structure, and have it transferred to all the others,
instead of having to send it to TOP if all are to be reached.

A hierarchical structure has a rather dubious advantage that you
can send a message to only a subtree, e.g. a message to SUBA will
only reach members of SUBA, SUBSUBAA and SUBSUBAB and not e.g.
members of SUBB or SUBSUBBA.

Finally, an argument against a hierarhical structure is that there
maybe problems in enforcing it. Dynamic loop control will automatically
avoid loops, with any structure of the list connections.



Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU  4 Aug 86 16:47:35 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2701025032355755@MIT-MULTICS.ARPA>; 04 Aug 1986 16:43:52 edt
Date:        26 Jul 86 13:30 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, "MESSAGE AGENT"
              <steve@UCL-CS.ARPA>,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@EDU.MIT.AI.AI,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          "MESSAGE AGENT" <steve@UCL-CS.ARPA>,
             HEADER-PEOPLE@AI.AI.MIT.EDU
Cc:          AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@EDU.MIT.AI.AI,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Distribution lists
Message-ID:  <190291@QZCOM>
In-Reply-To: <6445.522341568@UK.AC.UCL.CS>

(a) We wanted something which (i) would work both under RFC822/821
and under X.400, including gateways betwen these protocols (ii)
not requring any change in X.400, so that it could be implemented
and used before changes in X.400 have been adopted and implemented
everywhere. That is why we chose to encode things in the text
bodies.

(b) Loop control:

There are five major methods of loop control:

(HIN) HISTORY-TRACE, CHECK ON RECIEPT: Include with a message a
history trace of lists which the message has passed, do not accept
into a list a message which has already passed that list.

(HOUT) HISTORY-TRACE, CHECK ON SENDING: Include with a message a
history trace of lists which the message has passed, do not send
it out again via list expansion to a list in the history trace.

(ID) MESSAGE-ID CHECK: Include with a message some kind of
message-ID, do not accept into a list a message with an ID which
already has passed the list.

(HIER) HIERARCHICAL ORDER: Enforce an hierarchical order on the
sublists.

(SPOINT) SINGLE EXPANSION POINT: Do all list expansion at a
single point.

Comments on these five methods:

HOUT is more efficient than HIN in network load, and also less
susceptible to problems when mapped onto RFC822.

ID is the method commonly used in USENET. This is the only method
which stops a person from receiving the same message twice, but
it cannot be used as the only loop control mechanisms because
of unreliability of Message-ID-s in certain cases.

HIER is the method commonly used in INTERNET. The restriction
requiring a hierarchical structure will make message transmission
slower and less efficient in some cases. In some cases it is
natural to allow every list to be a member of every other list
in a set of linked lists.

SPOINT is inefficient for large lists, and requires access to
a global directory system, which we do not have today.

We have chosen to suggest the use of HOUT in combination with
ID.

One can note that CCITT is presently considering SPOINT, but
they may change their mind before their new recommendation is
ready.



Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 AUG 86  01:24:17 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 AUG 86  01:25:48 EDT
Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 25 Mar 86 22:10:48 EST
Received: from (R21)DDATHD21.BITNET by WISCVM.WISC.EDU on 03/25/86 at
  21:07:43 CST
Received: from THDNET (V0.11) by DDATHD21.BITNET
Date:     26 Mar 86 03:55:24 +0100
From:  XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU  (YD14@BR1.THDNET)
Subject:  Timezone
To:  HEADER-PEOPLE@MIT-MC

What's the timezone code for Central European Time?
Some nodes use +0100 other use -0100.
I think +0100 (or A military time) is correct.
So f.e. EST would equivalent to -0500 or R.
Is that correct?

Regards Reinhard Goeth (Techn. Univ. of Darmstadt; Fed. Rep. of Germany)

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 AUG 86  15:26:24 EDT
Received: from B.ISI.EDU by MC.LCS.MIT.EDU 10 Aug 86 15:25:00 EDT
Date: 10 Aug 1986 12:22:10 PDT
From: POSTEL@B.ISI.EDU
Subject: re: timezone
To:   header-people@MC.LCS.MIT.EDU


Reinhard Goeth:

Numeric timezones indicators should be as specified by ISO 4031.

You are correct that the U.S. Eastern Standard Zone is -0500, and
Central European Time should be +0100.

--jon.
-------

Received: from WISCVM.ARPA by AI.AI.MIT.EDU 13 Aug 86 18:49:58 EDT
Received: from (FOXEA)VTVAX3.BITNET by WISCVM.ARPA on 08/13/86 at
  12:06:49 CDT
Date:  Wed, 13-AUG-1986 13:04 EDT
From:      <FOXEA%VTVAX3.BITNET@WISCVM.ARPA>
To:  <header-people@ai.ai.mit.edu>
Subject:  Suggestions for Single System Image (SSI) project

At Virginia Tech we have embarked upon a project to facilitate first
mail and later other applications like printing and database access
being accessible in a convenient way to all users of mainframes, minis,
and micros (of which we have over 6000).  With about 25,000 people in
the university community this is indeed an important and challenging
activity.

We would like to use the X.400 standard, but build some of our
connections over asynch lines, some over a Sytek local area network,
some over ISN, and some over ethernet (using TCP/IP).  We ultimately
want to have interfaces for IBM mainframes (running PROFS or regular CMS),
IBM/PCs, UNIX System V (on 3B15, UNIX/PCs, VAX, etc.), UNIX 4.2/3bsd
(on SUN, VAX, ...), VAX/VMS, etc.

Please send comments directly to me rather than to the group.  We are
especially interested in finding out about all current and planned
X.400 implementations.

Many thanks for your time and interest,
    Ed Fox (Dr. Edward A. Fox, Dept. of Comp. Science, Virginia Tech)
    ARPAPNET: fox%vt@csnet-relay.arpa
    BITNET:   fox@vtcs1.bitnet
    UUCP:     seismo!vtisr1!fox

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 AUG 86  06:38:57 EDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 AUG 86  06:32:41 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 25 Apr 86 05:28:11 EST
Received: from HLERUL5(OUWEHAND) by MITVMA (Mailer X1.23) id 2517;
          Fri, 25 Apr 86 05:11:30 EST
Date: 24 APR 86 23:49-N
From: OUWEHAND@HLERUL5
To: HEADER-PEOPLE@MC.LCS.MIT.EDU
Subject: BITNET mail follows


Please put me on the list.

    OUWEHAND@HLERUL5     (EARN)





Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 AUG 86  15:02:18 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 18 Aug 86 15:00:52 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2702227243514690@MIT-MULTICS.ARPA>; 18 Aug 1986 14:40:43 edt
Date:        10 Aug 86 17:57 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Timezone
Message-ID:  <193931@QZCOM>
In-Reply-To: <193304@QZCOM>

As you can see from the header of this message, we at QZCOM use
"+0200" when Western Europe has daylight saving time, and "+0100"
when Western Europe does not have daylight saving time. I hope
this is correct, that you should give different values when daylight
saving time is in effect and when it is not!



Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 AUG 86  07:36:21 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 23 Aug 86 07:35:18 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2702632744728087@MIT-MULTICS.ARPA>; 23 Aug 1986 07:19:04 edt
Date:        20 Aug 86 18:48 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Timezone
Message-ID:  <196650@QZCOM>
In-Reply-To: <860819-085256-1588@Xerox>

The header Don_Winter received:

> FROM: "Don_Winter.XSIS"@Xerox.COM
>
> Re: "As you can see from the header of this message, we at QZCOM use
> "+0200" when Western Europe has daylight saving time"
>
> Actually, I can see nothing of the sort. Here is the header, as it
> reached me:
>
> "From: Jacob_Palme_QZ@QZCOM.Mailnet
> Reply-to: Jacob_Palme_QZ@QZCOM.Mailnet,
> Header_People_mailing_lists@QZCOM.Mailnet
> To: Header_People_mailing_lists@QZCOM.Mailnet, header-people
> <header-people@MC.LCS.MIT.EDU>
> Subject: Timezone
> In-Reply-To: <193304@QZCOM>
> Return-Path:
> <@AI.AI.MIT.EDU:Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU>
> Redistributed: XeroxHeaderPeople^.x
> Received: from AI.AI.MIT.EDU by Xerox.COM ; 18 AUG 86 12:53:44 PDT
> Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 AUG 86
> 15:02:18 EDT
> Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 18 Aug 86 15:00:52 EDT
> Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id
> <2702227243514690@MIT-MULTICS.ARPA>; 18 Aug 1986 14:40:43 edt
> Message-ID: <193931@QZCOM>"

The header we sent to MIT-MULTICS:

SMTP-SENDER: Jacob_Palme_QZ@QZCOM.MAILNET
SMTP-RECIPIENT: header-people@MIT-MC.ARPA

Date:        10 Aug 86 17:57 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Timezone
Message-ID:  <193931@QZCOM>
In-Reply-To: <193304@QZCOM>




Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 AUG 86  16:20:30 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 24 Aug 86 16:19:25 EDT
Date:  Sun, 24 Aug 86 16:09 EDT
From:  "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject:  timezones
To:  header-people@MC.LCS.MIT.EDU
cc:  Jacob_Palme_QZ@QZCOM.MAILNET
Message-ID:  <860824200932.724930@MIT-MULTICS.ARPA>

Jacob,
  The mailer agent at Multics canonicalizes dates and times into an
internal format when they pass through its clutches, then reinterprets
them into displayable local times (now EDT) as they go back out.  So,
something that came through here on its way to a MAILNET site like QZ
with a +/-nnnn time (or an RFC822-conforming named zone) will leave here
as EDT.
  Dates and times that cannot be canonicalized (i.e,.  that do not
conform to RFC822) result in a header being rebuilt from the envelope,
with obvious unfortunate consequences.

  I didn't do the software, nor make the rules, nor completely agree
that they are the right rules to have, but that is the way it works and
thought the explanation might be helpful.
   John

Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU  2 Sep 86 18:49:11 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a004967;
          2 Sep 86 13:19 PDT
To: ARPA-MHS@brl.ARPA, ARPANET-BBOARDS@mc.lcs.mit.EDU, Taylor@hplabs.hp.COM, 
    Header-People@ai.ai.mit.EDU, HUMAN-NETS@rutgers.EDU, 
    INFO-NETS%MIT-OZ@mc.lcs.mit.EDU, MMM-PEOPLE@b.isi.EDU, 
    NAMEDROPPERS@sri-nic.ARPA, TELECOM@xx.lcs.mit.EDU, 
    MHS_IMPLEMENTATION@rsch.wisc.EDU
Subject: REPEAT C Call for Papers WG 6.5
Reply-to: stef@nrtc-gremlin
Date: Tue, 02 Sep 86 13:19:15 -0700
Message-ID: <4965.526076355@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

------- Forwarded Message

Subject: Call for Papers WG 6.5
From: Peter Schicker <schicker%ean.cs.nott.ac.uk@cs.ucl.ac.UK>
To: Hugh Smith <hugh%computer-science.nottingham.ac.uk@cs.ucl.ac.UK>, 
    Einar Stefferud <stef@brl.ARPA>
Cc: Rolf Speth <Rolf_Speth_QZ%com.york.ac.uk@cs.ucl.ac.UK>
Date: 13 Jun 86 7:55 -0100 BST

Hugh and Stef

Could you post the following call for papers on the US and European nets,
please.

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

			 CALL  FOR  PAPERS

	  IFIP WG 6.5 International Working Conference on

		      MESSAGE HANDLING SYSTEMS
	      (State of the Art and Future Directions)

			 27 to 29 April 1987
			       Munich
			Fed. Rep. of Germany

- ----------------------------------------------------------------------
Program

The purpose of the conference is to provide an international forum for the
exchange of information on the technical, economic, social, and political
impacts of computer message and office systems. The conference format will
be two days of conference paper presentations followed by one day of work-
shops.

Papers are desired in the following topic areas:

MHS Interconnection and Interworking
  Interconnection of X.400 Systems (Private and public)
  Gateways to X.400 Systems
  X.400 Shell to non-X.400 Systems
  Interworking between X.400 and the Postal System
  Interworking with other Architectures (e.g., DIA/DCA, All-In-1, etc.)
  Multi-Vendor Private Message Systems

Documents and Messages
  Document and Message Architectures
  Multimedia Documents and Messages
  Graphics (GKS) vs. Facsimile
  Communication of Business Forms and Trade Documents

Directory Services
  Naming and Addressing
  Public Directory Systems
  Interworking between Public and Private Directory Systems

New Access Protocols
  Mailbox Services
  Extensions to X.400 Series Recommendations

Message Management
  Personal Message Management
  Message and Document Filing and Retrieval

Group Communication
  Distribution Lists
  Organization of Message Flow
  Real-Time Conferencing
  Models for Group Communication

Workstations and User Interface
  Workstation and Cluster Design
  Backup and Archiving
  User Interface Issues
  Message Editing

Security Aspects
  Authentication
  Confidentiality

Impacts of MHS
  Social and Behavioral Impacts
  Impacts on Organizations
  Impacts on Nations
  Inpacts on Relieving Impairment

Policy Issues
  Public Policy Issues in MHS
  Transborder Data Flow
  Legal Status of MHS
  Privacy and Confidentiality

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

Instructions to Authors:

Prospective Authors are invited to submit for review unpublished original
contributions (not exceeding 5000 words) which describe recent developments
on any design or service aspect of computer message systems.

Accepted papers will appear in the Conference Proceedings published by
North-Holland Publishing Company.

Deadlines:

Today               Send a postcard with your name, telephone, and EMail
                    address to:
                       Message Systems '87
                       Mrs. Stenzel
                       Siemens AG
                       D-AP.11
                       Otto Hahn Ring 6
                       D-8000 Munich 83
                       Fed. Rep. of Germany
                    This will ensure that you will receive further information
                    about the conference. Please indicate also the provisio-
                    nal title if you intend to submit a paper.
Sept. 30, 1986      Draft versions of papers required
Nov. 30, 1986       Notification of acceptance
Jan. 31, 1987       Camera-ready papers required

Papers should be submitted to:

Peter Schicker
Zellweger Telecommunications AG
CH-8634 Hombrechtikon
Switzerland

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

------- End of Forwarded Message

Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 13 Sep 86 03:50:12 EDT
Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a001324;
          13 Sep 86 0:44 PDT
To: ZELLICH@sri-nic.ARPA, header-people@ai.ai.mit.EDU
Cc: human-nets@red.rutgers.EDU, "Frank J. Wancho" <WANCHO@simtel20.ARPA>
Subject: MsgGroup Archives now at SIMTEL20
Reply-to: msggroup-request@brl.ARPA
Date: Sat, 13 Sep 86 00:43:59 -0700
Message-ID: <1321.526981439@nrtc-gremlin.northrop.com>
From: Einar Stefferud <stef@nrtc-gremlin>

To all who may be interested in the history of the world according to
MsgGroup, the list ceased its operation during the summer of 1986 after
11 continuous years of operation.  The decision to cease operations was
difficult, but necessary, because MsgGroup's reason for being had
evaporated sometime during the previous year or two.  MsgGroup was
brain-dead before it was turned off, and its demise was quite welcome.  

But, the complete transcript has been kept intact, and the archives are
in the safe keeping of Frank Wancho@simtel20.arpa who will attempt to
keep them online and available to anyone who cares to poke and search
for the nuggets that are hidden there-in.  More than one student has
gotten quite an education by perusing the archives.  

I wish here to thank all who helped us to grapple with the central
issues of mail when the concepts were being forged.  The FLAMES were
magnificent, the arguments both profound and sublime (when not
ridiculous), and the results, when processed through the political mills
of international standards organizations, have given us X.400.  I
shudder to think what they would have produced without the flames of
MsgGroup to light the way.  


The vital access facts are given below:  

FORMAT: Twenex Mail Files, with 100 messages per file.

Host: SIMTEL20.ARPA	Directory PS:<ARCHIVES.MSGGROUP>

Filename			Type	 Bytes	 CRC

MSGGROUP.0001-0100.3		ASCII	198684  50A9H
MSGGROUP.0101-0200.4		ASCII	347359  900DH
MSGGROUP.0201-0300.4		ASCII	270092  9B89H
MSGGROUP.0301-0400.2		ASCII	157965  538EH
MSGGROUP.0401-0500.1		ASCII	214015  4163H
MSGGROUP.0501-0600.2		ASCII	220514  EB2BH
MSGGROUP.0601-0700.2		ASCII	216929  8742H
MSGGROUP.0701-0800.1		ASCII	184410  5743H
MSGGROUP.0801-0900.1		ASCII	206165  954CH
MSGGROUP.0901-1000.2		ASCII	196196  A48EH
MSGGROUP.1001-1100.1		ASCII	157610  9C39H
MSGGROUP.1101-1200.1		ASCII	145564  F043H
MSGGROUP.1201-1300.1		ASCII	174805  1E5CH
MSGGROUP.1239-TTY.1		ASCII	 44162  DB6CH
MSGGROUP.1301-1400.1		ASCII	154057  1909H
MSGGROUP.1401-1500.1		ASCII	151548  24FEH
MSGGROUP.1501-1600.1		ASCII	273691  C4C0H
MSGGROUP.1520.1			ASCII	 57835  981AH
MSGGROUP.1592.1			ASCII	 24211  0DA1H
MSGGROUP.1601-1700.1		ASCII	153240  3BA6H
MSGGROUP.1619.1			ASCII	  5905  12DCH
MSGGROUP.1701-1800.1		ASCII	161110  042AH
MSGGROUP.1801-1900.1		ASCII	195880  4D56H
MSGGROUP.1901-2000.1		ASCII	212798  83D5H
MSGGROUP.2001-2100.1		ASCII	227262  5E47H
MSGGROUP.2101-2200.1		ASCII	182884  C018H
MSGGROUP.2201-2300.1		ASCII	219566  F02EH
MSGGROUP.2301-2400.1		ASCII	193318  81C2H
MSGGROUP.2401-2500.1		ASCII	257445  62A7H
MSGGROUP.2501-2600.1		ASCII	149617  30E6H
MSGGROUP.REQUIREMENTS.2		ASCII	  3469  27E1H
MSGGROUP.SCHWARTZ-CSD-MSG.1	ASCII	 56400  9D31H

Survey files contain two-line per message surveys of the corresponding
twenex message files.  

SURVEY.0001-0100.1		ASCII	 11965  4797H
SURVEY.0101-0200.1		ASCII	 12887  7A5BH
SURVEY.0201-0300.1		ASCII	 12558  2651H
SURVEY.0301-0400.1		ASCII	 13536  23FDH
SURVEY.0401-0500.1		ASCII	 13507  FC24H
SURVEY.0501-0600.1		ASCII	 13174  BE2DH
SURVEY.0601-0700.1		ASCII	 12864  3806H
SURVEY.0701-0800.1		ASCII	 12892  71B3H
SURVEY.0801-0900.1		ASCII	 12310  FED3H
SURVEY.0901-1000.1		ASCII	 13320  411AH
SURVEY.1001-1100.1		ASCII	 12001  65FFH
SURVEY.1101-1200.1		ASCII	 12534  183EH
SURVEY.1201-1300.1		ASCII	 12116  ED10H
SURVEY.1301-1400.1		ASCII	 11522  C76EH
SURVEY.1401-1500.1		ASCII	 12292  29B1H
SURVEY.1501-1600.1		ASCII	 12553  8CC7H
SURVEY.1601-1700.1		ASCII	 12537  7758H
SURVEY.1701-1800.1		ASCII	 12599  4B7DH
SURVEY.1801-1900.1		ASCII	 13052  2974H
SURVEY.1901-2000.1		ASCII	 12053  8EB7H
SURVEY.2001-2100.1		ASCII	 12779  D9C1H


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 SEP 86  12:17:25 EDT
Received: from BRL-SEM.ARPA by MC.LCS.MIT.EDU 22 Sep 86 12:09:41 EDT
Date:     Mon, 22 Sep 86 11:01:37 EDT
From:     Ron Natalie <ron@BRL.ARPA>
To:       header-people@mc.lcs.mit.EDU
Subject:  [Henry Dardy:  RE: Ultrix 1.2 and unacceptable tcp packets]
Message-ID:  <8609221101.aa03927@SEM.BRL.ARPA>

This must win some kind of award for stupid date lines...


----- Forwarded message # 1:

Received: from BRL-VGR.ARPA by SEM.BRL.ARPA id aa03022; 22 Sep 86 9:34 EDT
Received: from SRI-NIC.ARPA by VGR.BRL.ARPA id aa01602; 22 Sep 86 9:27 EDT
Received: from NRL-ACOUSTICS.ARPA by SRI-NIC.ARPA with TCP; Sat 20 Sep 86 15:16:34-PDT
Date: 0  0 00:00:00 EDT
From: Henry Dardy <dardy@nrl-acoustics.arpa>
Subject: RE: Ultrix 1.2 and unacceptable tcp packets
To: tcp-ip <tcp-ip@sri-nic.arpa>
cc: dardy@nrl-acoustics.arpa
Reply-To: Henry Dardy <dardy@nrl-acoustics.arpa>
Message-ID:  <8609220927.aa01602@VGR.BRL.ARPA>

You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***.  Sorry,
but your (flame on) hadn't cooled yet!

Hank

------

----- End of forwarded messages

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 23 Sep 86 17:22:07 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2705338196046899@MIT-MULTICS.ARPA>; 23 Sep 1986 14:49:56 edt
Date:        23 Sep 86 14:16 +0200
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     CONFIRM: DELIVERY
Message-ID:  <204048@QZCOM>

I am considering implementing in COM a facility that if an incoming
message has "CONFIRM: DELIVERY" in the RFC822 header, then
when the message has been delivered to the recipient mailbox,
a message is sent back to the SMTP-sender saying that this
has been done.

One could also envisage "CONFIRM: RECEIVED".

This is not fully compatible with X.400, since in X.400 one
can request confirmation separately for each recipient. But that
is not so easy to fit into the RFC822 syntax, so I suggest just
one command for all the recipients.

Any comments? Has anyone already implemented something similar?
In that case, I should use their syntax and not reinvent something
different.



Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 23 Sep 86 18:44:53 EDT
Date: Tue, 23 Sep 1986  18:50 EDT
Message-ID: <SRA.12241325772.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU
Cc:   HEADER-PEOPLE@AI.AI.MIT.EDU
Subject: CONFIRM: DELIVERY
In-reply-to: Msg of 23 Sep 86 14:16 +0200 from Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA

You might want to use something like

CONFIRM: <address-to-confirm-to>

rather than using the SMTP-sender.  Or you could do

Confirm-Delivery: <address-to-confirm-to>

and

Confirm-Receipt: <address-to-confirm-to>

Using the SMTP sender for anything but the limited purpose defined in
the spec is probably a bad idea.

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 24 Sep 86 09:18:38 EDT
Date:  Wed, 24 Sep 86 09:02 EDT
From:  John C Klensin <Klensin@MIT-MULTICS.ARPA>
Subject:  CONFIRM-DELIVERY
To:  Jacob_Palme_QZ@QZCOM.MAILNET
cc:  header-people@AI.AI.MIT.EDU
Message-ID:  <860924130255.410923@MIT-MULTICS.ARPA>

From a technical standpoint, I agree with Bob Austein's comment.  We
have enough problems already with overloading of the From and Sender
fields to deliberately set ourselves up for another one.

And two field names is probably better then one, since there are
logically three separate confirmations that one might reasonably want to
ask for:
 1) Confirmation that one's local MTA had actually gotten the message
off-system.  (Confirm-Sent:?)
 2) Confirmation that the MTA closest to the user had delivered the
message to the user's mailbox (I assume that this is what you are
talking about when you suggest "Confirm:Delivery").
 3) Confirmation that the user has actually received the message.

Note that an MTA may have a little bit of difficulty figuring out
whether it is the right agent (or when is the right time) to send the
acknowledgement in "2".  Given clusters, LANs, and mail servers for
usually-disconnected machines, the notion of "delivery" can get a little
abstract.  The protocol used in BITNET/EARN/NETNORTH, for example,
acknowledges delivery (to the next machine down the line) at each hop in
the forwarding and storing enterprise.

Now the hard problem....
  At the risk of restarting a long and sometimes acrimonious discussion
here, the confirm-receipt notion raises some quite complex privacy
questions.  It is not, a priori, reasonable that I (as a sender) should
be able to force you to tell me when you are reading your mail.  It is
not, a priori, reasonable that I should be able to make you sign for a
message that you wish to reject, rather that explicitly accepting.  And
many of the reasons for wanting a receipt-acknowledgement -- most of the
reasons not accounted for by a confirmation that the network has done
its job from Confirm-Delivery -- raise signature issues:  you really
want to know whether I've received it personally, whether a human agent
has collected it for me and [probably] passed it on, or whether the work
was done by an MTA that the system cannot identify (or thinks is a UA)
and it has not gotten to me at all.  For example, consider a computer
that periodically logs into another one, collects mail from designated
mailboxes, carries it somewhere else, and remails it:  much the way that
MAILNET works, but without the consent and participation of the MTA on
the network-connected machine at the receiving end.

  Greater separation of envelopes and messages (vis X.400) will help
somewhat with this, as there are somewhat fewer objections if one can
accurately identify the sender and originator, and the fact that a
receipt was requested, before deciding whether to accept delivery of the
mail (and assuming that "receipt" is not confirmed on looking at the
envelope, but only when looking at the message body).  "Decide whether
to accept delivery" is suggested here because the addressee can do at
least two things with incoming mail -- read it or delete it and, if
receipt confirmation is supported, there should be a third option,
namely, have the UA send the message back unread and optionally
annotated with the reason for rejection, without ever "opening the
envelope".
  Note also that handling a "confirm receipt" facility correctly can
place a heavy burden on some classes of UAs.  Depending on the mechanism
used for maintaining mailboxes, it may be very hard to avoid
acknowledging receipt of a message every time it is looked at, at least
without rewriting the message to eliminate or annotate the field.  And
such rewriting can violate security constraints about message-signature
binding in many types of implementations.

 There is also the argument that it is undesirable to include fields
that demand action on the part of the recipient that the latter's UA may
just ignore without comment.  And receipt confirmation is certainly an
example of this:  receipt confirmation has to be done by a UA; an MTA,
by definition, does not have access to the right information.  If I, as
a user, decide that your sending me messages with receipt
acknowledgement requested is antisocial, I can, in principle, modify my
UA to ignore the field.  That is behavior that you might reasonably
consider antisocial, but, from my standpoint, that would just make us
even.  The only way to avoid this problem appears, in fact, to be to
transfer the responsibility back to the MTA.  Compare this to the Post.
When a letter is sent to me without a request for a receipt
confirmation, and the postal delivery person finds me not at home, the
letter is simply left.  Delivery can be confirmed, but receipt cannot.
However (at least in the USA), if that letter arrives with a request for
confirmation of receipt, what is left for me if I'm not there to
"receive" and acknowledge it is a slip of paper -- acting as a surrogate
for the envelope -- that tells me to come and pick the letter up and
sign for it, an act equivalent to notifying me to explicitly request the
message from the MTA under circumstances that the MTA's responding to
the request can be accurately construed as my having actually received
the message, rather than just having it delivered it to my doorstep.
That still does not confirm that I have read it or paid any attention,
of course.

So:
  - Certainly in the third case (receipt confirmation) go slow, at least
until you can demonstrate clear enough need to overwhelm the objections
outlined above.
 - Before you add header fields of these types, please work out and
discuss, very carefully, the semantics that you expect them to imply.
Simply adding a field to the header by [partially] copying an X.400
field, or as a request that something be put into an X.400 field, is
looking for trouble in our somewhat different environment.  If the only
reason for such a field is X.400 compatability, then an alternative
solution to consider might be a series of fields named
 X400-xxx
 implying that they appear for X.400 compatability and interchange, but
that they are expected to be ignored in RFC821/822 mail systems.  If you
will, they are instructions to X.400 <->RFC822 header-munging gateways,
not instructions to MTAs on the RFC822 side.

Received: from ALMSA-1 by AI.AI.MIT.EDU 25 Sep 86 11:02:59 EDT
Received: from almsab by ALMSA-1.ARPA id aa22775; 25 Sep 86 9:36 CDT
Date:     Thu, 25 Sep 86 9:34:44 CDT
From:     Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
To:       header-people@MIT-AI.ARPA
Subject:  Can a user "prod" a remote host?

Is there any way that an ordinary user can "prod" or signal a remote host
across the ARPA/MILNET to cause that remote host to check for and start
the sending process for mail that may be queued up for delivery to the
user's host?

An example: my host has had problems for some days, such as the network 
connection being down, or the machine being down -- something that has
prevented it from receiving mail from the network. It comes back up,
and some incoming mail is delivered. I, as a user on that machine, look
at the mail and can tell that there is still some missing (such as some
mailing-list digests, where issues are numbered and I can see that I have
not received certain numbers). Is there something I can do using the
"telnet" or "ftp" capability to reach across the network to the host
that sends out these messages and tell it that it should now search its
out-bound queues for any mail to my host and start the regular mail delivery
process?

This could be especially valuable if I knew, for example, that my host 
will be up for a short time and will then go down again, and that the remote
machine normally delivers mail to us at night when I know that my computer
will be down again. So if I could trigger an unscheduled, right-now mail
delivery, the traffic would get through -- if I do nothing, and let the
scheduled processes run things, there would be another unsucessful
delivery attempt and perhaps the mailer would time out and reject the mail
back to the sender.

I recall that there were some methods for a person to simulate an
automatic net-mail-type host-to-host connection; that led me to wonder
if such a method could be used to trigger a remote machine to start up
such a process.

Regards, Will Martin

Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 26 Sep 86 05:56:14 EDT
Date: Fri, 26 Sep 1986  06:01 EDT
Message-ID: <SRA.12241972091.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
Cc:   header-people@AI.AI.MIT.EDU
Subject: Can a user "prod" a remote host?
In-reply-to: Msg of 25 Sep 1986  10:34-EDT from Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>

In theory SMTP provides a facility that could be used the way you
describe, the TURN command.  To use it you'd call up the host you
wanted to prod, negotiate a TURN (at which point you turn into an SMTP
"server" instead of an SMTP "user"), then get instant gratification as
the foreign machine dumped all its mail out to you.

In practice I am not aware of any SMTP server that implements TURN
except to negotiate a close correctly after a foreign site has
inflicted a TURN on you.  Too much hair, particularly for mailsystems
where the smtp-server (mail listener) and smtp-user (mailer daemon)
are two different program.

There's also a potential for misuse by pinheads if something like TURN
were implemented.  For the case you mention it is pretty clearly
justified, but what do you do about the bozo who calls you up as a
regular habit because he thinks your retransmission queue scan time is
too slow?  Stop answering the phone, I guess....

--Rob Austein <SRA@XX.LCS.MIT.EDU>

Received: from ucbarpa.Berkeley.EDU by AI.AI.MIT.EDU 26 Sep 86 11:19:53 EDT
Received: by ucbarpa.Berkeley.EDU (5.53/1.16)
	id AA02096; Fri, 26 Sep 86 08:19:17 PDT
Date: Fri, 26 Sep 86 08:19:17 PDT
From: jordan@ucbarpa.Berkeley.EDU (Jordan M. Hayes)
Message-Id: <8609261519.AA02096@ucbarpa.Berkeley.EDU>
To: header-people@ai.ai.mit.edu
Subject: Re:  Can a user "prod" a remote host?
Cc: sra@xx.lcs.mit.edu

	From: Rob Austein <SRA@XX.LCS.MIT.EDU>

	In theory SMTP provides a facility that could be used the way
	you describe, the TURN command.  To use it you'd call up the
	host you wanted to prod, negotiate a TURN (at which point you
	turn into an SMTP "server" instead of an SMTP "user"), then get
	instant gratification as the foreign machine dumped all its
	mail out to you.

Yes, but I think the main reason this has never been implemented is for
security reasons ... I could find a machine that does a lot of queueing
on a regular basis (ucbvax for one queues a lot, since the load is
usually above the "safe" threshold for sendmail to run to completion)
and telnet to port 25 on your machine and issue a TURN and I steal all
the mail headed for that machine ... not _too_ cool ...

/jordan

Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 26 Sep 86 15:41:48 EDT
Date: Fri, 26 Sep 1986  15:46 EDT
Message-ID: <SRA.12242078671.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   jordan@UCBARPA.BERKELEY.EDU (Jordan M. Hayes)
Cc:   header-people@AI.AI.MIT.EDU
Subject: Can a user "prod" a remote host?
In-reply-to: Msg of 26 Sep 1986  11:19-EDT from jordan@ucbarpa.Berkeley.EDU (Jordan M. Hayes)

    Date: Friday, 26 September 1986  11:19-EDT
    From: jordan@ucbarpa.Berkeley.EDU (Jordan M. Hayes)

    Yes, but I think the main reason this has never been implemented is for
    security reasons ... I could find a machine that does a lot of queueing
    on a regular basis (ucbvax for one queues a lot, since the load is
    usually above the "safe" threshold for sendmail to run to completion)
    and telnet to port 25 on your machine and issue a TURN and I steal all
    the mail headed for that machine ... not _too_ cool ...

Um, yeah.  So you'd want to look up the name from the HELO and check
that the foreign address you were talking to corresponded.  Except
that here in the future somebody could get their domain server to lie
for them.  Mumble.  So you'd have to do a reverse (IN-ADDR) lookup too
to verify the address (assuming that you aren't dealing with somebody
smart enough to forge IP addresses or corrupt your resolver, but if
they can do that you might as well give up, you lose anyway).

That does limit the usefulness some, since traditionally SMTP
listeners will accept almost anything in the HELO.  On the other hand,
it doesn't bite you until you use TURN, and it'd give people a motive
to set up the IN-ADDR data correctly (a pet peeve).

--Rob

Received: from ucbarpa.Berkeley.EDU by AI.AI.MIT.EDU 26 Sep 86 15:48:44 EDT
Received: by ucbarpa.Berkeley.EDU (5.53/1.16)
	id AA07009; Fri, 26 Sep 86 12:48:03 PDT
Date: Fri, 26 Sep 86 12:48:03 PDT
From: jordan@ucbarpa.Berkeley.EDU (Jordan M. Hayes)
Message-Id: <8609261948.AA07009@ucbarpa.Berkeley.EDU>
To: sra@xx.lcs.mit.edu
Subject: Re:  Can a user "prod" a remote host?
Cc: header-people@ai.ai.mit.edu

A lot of places and mailers _do_ check the inbound address for
correctness, but there's nothing stopping me from being on the machine
I claim I am, but asking for mail that the other end hasn't gotten
around to delivering yet -- if the load is high enough on ucbvax, and
mail comes in that needs to go to xx.lcs.mit.edu, it will get queued
...  in the interim, i go to xx.lcs.mit.edu and telnet to port 25 on
ucbvax and give a turn ... sendmail on ucbvax says "oh, ok -- here's
your bloody mail" and I get it all ... I repeat -- not _too_ cool.

/jordan

Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 26 Sep 86 16:04:20 EDT
Date: Fri, 26 Sep 1986  16:03 EDT
Message-ID: <SRA.12242081725.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   jordan@UCBARPA.BERKELEY.EDU (Jordan M. Hayes)
Cc:   header-people@AI.AI.MIT.EDU
Subject: Can a user "prod" a remote host?
In-reply-to: Msg of 26 Sep 1986  15:48-EDT from jordan@ucbarpa.Berkeley.EDU (Jordan M. Hayes)

You're right.  And this just a few days after I was caught
pontificating in public on why one should never trust the guy at the
other end of the network.  Foo.  Sorry for the noise, folks.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 SEP 86  22:50:50 EDT
Received: from Xerox.COM by MC.LCS.MIT.EDU 26 Sep 86 22:48:46 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 SEP 86 19:40:00 PDT
Date: 26 Sep 86 19:39:44 PDT (Friday)
Subject: Re: Timezone -- and header hammering.
In-reply-to: <196650@QZCOM>
To: Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU,
 "Don_Winter.XSIS"@Xerox.COM, Klensin@MIT-MULTICS.ARPA
cc: header-people@MC.LCS.MIT.EDU, Hostrop.PA@Xerox.COM,
 RMRichardson.PA@Xerox.COM
From: Rich <RMRichardson.PA@Xerox.COM>
Reply-to: RMRichardson.PA@Xerox.COM
Message-ID: <860926-194000-5801@Xerox>

Oops, I forgot to send this out when it was timely so here it is late
...


The problem for Don Winter appears to be that he "lives" on the far side
of 
a Xerox gateway that is shooting the "Date:" line in the header.  The
examples 
following are: Jacob Palme's header, Jacob's earlier header as Don
received it, 
and a pair of headers from a message I received from the two Xerox mail 
handling systems.

From example 1 <<Date: 20 Aug 86 18:48 +0200>> we see +0200 just as
Jacob says. 
Now from example 4 we find <<Date: 22 Aug 86 21:49:00 PDT (Friday)>> but
note 
that this header appears to be rather minimal, and in fact, the
"message" 
contains another header between two lines of GVs.  This contained header
is 
the remnant of the header in example 3.  

ARPA net mail gets to Xerox through a single gateway (at PARC in
California) 
and is sent to the addressee via the GrapeVine (old) mail system.  (In
the 
examples the addressees are DLs and so the messages are redistributed to
the individuals therein.)  Many people no longer have GV addresses, but
are 
on the NS (newer) mail system so their messages must go through the 
GV <=> NS gateway.  Example 3 is the copy delivered by the GV system;
example 
4 went through the gateway and NS mail.  The gateway has built a new
header, 
and shoved the old header in the message (surrounded by lines of
GVGV...).  
However, the gateway has created a new date/time line 
<<Date: 22 Aug 86 21:49:00 PDT (Friday)>> AND deleted the old one 
<<Date: Fri, 22 Aug 86 09:57:04 pdt>> from the embedded copy.

In Don Winter's case, the original date and timezone was lost at Xerox
and 
not MIT.


Rich

----------


Example 1:
----------
GVInfo: @AI.AI.MIT.EDU:Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU,
from 3#37, at 23-Aug-86  5:27:13 PDT (return to
Owners-XeroxHeaderPeople^.x)
Return-Path:
<@AI.AI.MIT.EDU:Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU>
Redistributed: XeroxHeaderPeople^.x
Received: from AI.AI.MIT.EDU by Xerox.COM ; 23 AUG 86 04:44:20 PDT
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 AUG 86
07:36:21 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 23 Aug 86 07:35:18 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id
<2702632744728087@MIT-MULTICS.ARPA>; 23 Aug 1986 07:19:04 edt
Date: 20 Aug 86 18:48 +0200
From: Jacob_Palme_QZ@QZCOM.Mailnet
Reply-to: Jacob_Palme_QZ@QZCOM.Mailnet
To: header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Timezone
Message-ID:  <196650@QZCOM>
In-Reply-To: <860819-085256-1588@Xerox>


Example 2:
----------
> "From: Jacob_Palme_QZ@QZCOM.Mailnet
> Reply-to: Jacob_Palme_QZ@QZCOM.Mailnet,
> Header_People_mailing_lists@QZCOM.Mailnet
> To: Header_People_mailing_lists@QZCOM.Mailnet, header-people
> <header-people@MC.LCS.MIT.EDU>
> Subject: Timezone
> In-Reply-To: <193304@QZCOM>
> Return-Path:
> <@AI.AI.MIT.EDU:Jacob_Palme_QZ%QZCOM.MAILNET@MULTICS.MIT.EDU>
> Redistributed: XeroxHeaderPeople^.x
> Received: from AI.AI.MIT.EDU by Xerox.COM ; 18 AUG 86 12:53:44 PDT
> Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 AUG 86
> 15:02:18 EDT
> Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 18 Aug 86 15:00:52
EDT
> Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id
> <2702227243514690@MIT-MULTICS.ARPA>; 18 Aug 1986 14:40:43 edt
> Message-ID: <193931@QZCOM>"


Example 3:
----------
GVInfo: arpa-mhs-request@BRL.ARPA, from 3#37, at 22-Aug-86 21:49:00 PDT
(return to Owners-arpa-mhs^.x) 
Return-Path: <arpa-mhs-request@BRL.ARPA>
Redistributed: arpa-mhs^.x
Received: from BRL-ADM.ARPA by Xerox.COM ; 22 AUG 86 14:05:42 PDT
Received: from brl-aos.arpa by ADM.BRL.ARPA id aa04397; 22 Aug 86 16:09
EDT
Received: from csnet-relay.arpa by AOS.BRL.ARPA id a006436; 22 Aug 86
16:00 EDT
Received: from ubc by csnet-relay.csnet id af04903; 22 Aug 86 13:22 EDT
Date: Fri, 22 Aug 86 09:57:04 pdt
Received: by ubc.csnet id AA15618; Fri, 22 Aug 86 09:57:04 pdt
From: Erik Skovgaard <erik%sydney.cdn@ubc.CSNET>
To: Einar Stefferud <stef@nrtc-gremlin.arpa>
Cc: arpa-mhs@BRL.ARPA
In-Reply-To: <3978.524969962@nrtc-gremlin.northrop.com>
Message-Id: <984:erik@sydney.cdn>
Subject: Re: Query on Domain Defined Attributes in ORNames 


Example 4:
----------
Sender: arpa-mhs-request%BRL:ARPA:Xerox
Date: 22 Aug 86 21:49:00 PDT (Friday)
Subject: Re: Query on Domain Defined Attributes in ORNames
From: erik%sydney.cdn%ubc:CSNet
To: stef%nrtc-gremlin
cc: arpa-mhs%BRL
In-Reply-to: <3978.524969962@nrtc-gremlin.northrop.com>

GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: Erik Skovgaard <erik%sydney.cdn@ubc.CSNET>
To: Einar Stefferud <stef@nrtc-gremlin.arpa>
Cc: arpa-mhs@BRL.ARPA
In-Reply-To: <3978.524969962@nrtc-gremlin.northrop.com>
Subject: Re: Query on Domain Defined Attributes in ORNames
Return-Path: <arpa-mhs-request@BRL.ARPA>
Redistributed: arpa-mhs^.x
Received: from BRL-ADM.ARPA by Xerox.COM ; 22 AUG 86 14:05:42 PDT
Received: from brl-aos.arpa by ADM.BRL.ARPA id aa04397; 22 Aug 86 16:09
EDT
Received: from csnet-relay.arpa by AOS.BRL.ARPA id a006436; 22 Aug 86
16:00 EDT
Received: from ubc by csnet-relay.csnet id af04903; 22 Aug 86 13:22 EDT
Received: by ubc.csnet id AA15618; Fri, 22 Aug 86 09:57:04 pdt
Message-Id: <984:erik@sydney.cdn>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV




Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 SEP 86  13:33:17 EDT
Received: from spam.istc.sri.com by MC.LCS.MIT.EDU 30 Sep 86 13:31:26 EDT
Received: by spam.istc.sri.com (5.51/4.16)
	id AA22542 for header-people@mc.lcs.mit.edu; Tue, 30 Sep 86 10:29:00 PDT
Date: Tue, 30 Sep 86 10:29:00 PDT
From: The lost Bostonian <gds@spam.istc.sri.com>
Message-Id: <8609301729.AA22542@spam.istc.sri.com>
To: header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa
Subject: Re: SMTP, 2600, and the security of mail

> From: Mark Crispin <MRC@SIMTEL20.ARPA>

> The Internet protocols are insecure by nature.  A reasonably suspicious
> host should always record the host name or IP address of the how which
> actually connected to the SMTP server (the real host, not what was
> claimed in a HELO).

If it is true that all IP implementations enable a server program to
determine the IP address of its peer, then the HELO command, and its
response could be eliminated, which would save us a few bytes.
Certainly the response to the HELO is not necessary, since the server
has already identified itself in the opening greeting.

However, I quote from RFC 821, the explanation for HELO:

	This command and an OK reply to it confirm that both the
	sender-SMTP and receiver-SMTP are in the initial state, 
	that is, there is no transaction in progress and all state
	tables and buffes are cleared.

I do not see that there would be a big problem of detecting the initial
state without a HELO.  Other protocols (FTP, NNTP) don't use it.

--gregbo


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 SEP 86  17:57:29 EDT
Received: from ucbvax.Berkeley.EDU by MC.LCS.MIT.EDU 30 Sep 86 17:56:02 EDT
Received: by ucbvax.Berkeley.EDU (5.53/1.17)
	id AA19007; Tue, 30 Sep 86 14:55:34 PDT
Received: by ulysses.UUCP; Tue, 30 Sep 86 16:57:05 edt
Received: by nestor.UUCP; Tue, 30 Sep 86 16:56:58 edt
Date: Tue, 30 Sep 86 16:56:58 edt
From: ulysses!smb@ucbvax.Berkeley.EDU (Steven Bellovin)
Message-Id: <8609302056.AA03119@nestor.UUCP>
To: tcp-ip@sri-nic.arpa,
        ucbvax!mc.lcs.mit.edu!header-people@ucbvax.Berkeley.EDU
Subject: Re:  SMTP, 2600, and the security of mail

It's important to remember that SMTP is used on non-TCP virtual circuits.
For example, some hosts within Bell Labs use it over Datakit(r) VCS connections.
You can't do this nearly as easily with FTP because the semantics of some of
the commands (i.e., PORT and PASSIVE) are intimately tied to TCP and IP.  In
general, though, I regard SMTP as a newer and better protocol than FTP, and
as a better model for other protocols.  The concept of looking for the initial
state is a good one; I've often seen half-open circuits get spliced to due
to software bugs (though not on TCP, of course).

