Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  6 Oct 88 02:23:51 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 5 Oct 88 02:23:56-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA26308@BLOOM-BEACON.MIT.EDU>; Wed, 5 Oct 88 02:18:04 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 5 Oct 88 04:16:00 GMT
From: amdcad!rpw3@bloom-beacon.mit.edu  (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Subject: Re: Documentation on Internet/UUCP/??? possible types of mail addresses?
Message-Id: <23128@amdcad.AMD.COM>
References: <194@chip.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <194@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes:
+---------------
| Unfortunately, from what I can determine RFC822 does not address the mixed
| UUCP/DECNET/Internet/?? formats that can exist that we all commonly use now.  
+---------------

See RFC976, "UUCP Mail Interchange Format Standard". It includes recommendations
about what to do when you see mixed-mode addresses.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 OCT 88  03:51:30 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA11106@EDDIE.MIT.EDU>; Sat, 8 Oct 88 03:50:10 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22342@BLOOM-BEACON.MIT.EDU>; Sat, 8 Oct 88 03:26:34 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Oct 88 07:00:45 GMT
From: mcvax!hp4nl!philapd!ssp15!jos@uunet.uu.net  (Jos Vos)
Organization: Philips Telecommunication and Data Systems, The Netherlands
Subject: Contents of RFC822 field "Encrypted"
Message-Id: <578@ssp15.idca.tds.philips.nl>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Does anyone know the (registered) official contents of the Encrypted
field in a RFC822 mail header?

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Oct 88 12:54:44 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ad00695; 12 Oct 88 12:17 EDT
Received: from sdr.slb.com by RELAY.CS.NET id af12597; 12 Oct 88 11:18 EDT
Date: Wed, 12 Oct 88 10:23 EDT
From: "PSI%PRSRTR::PRSRTR::MRGATE::\"MRGATE::PSI%SINET.000000360400::RILEY\"%sdr.slb.com"@RELAY.CS.NET
Subject: RFC #822 Received: id field
To: header-people@MC.LCS.MIT.EDU
X-VMS-To: MRGATE::M_SDR::IN%"header-people@mc.lcs.mit.edu"


It has been suggested that I send the following to
HEADER-PEOPLE@MC.LCS.EDU so ...

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

Would anyone out there like to explain the following problem/conflict
with RFC #822 (the "Standard for ARPA Internet Text Messages" used in
many mail systems) :-

	Problem: The received message "id" in a "Received:" field is
	not in the specified format for all mail I have seen (and a
	friend confirms this also).

	The definition for the "Received:" field is the following ...

		received = "Received" ":"
				 ["from" domain]
				 ["by"   domain]
				 ["via"  atom]
				*("with" atom)
				 ["id"   msg-id]
				 ["for"  addr-spec]
				";" date-time

	The definition for "msg-id" is the following ...

		msg-id = "<" addr-spec ">"

	Now observe an example "Received:" field ...

		Received: from relay.cs.net by RELAY.CS.NET
			  id eu17161; 20 Sep 88 1:37 EDT

	For a start, the id is not surrounded by angle brackets ("<" and
	">"). Secondly, "addr-spec" is defined to be ...

		addr-spec = local-part "@" domain

	... there is definitely not an "@" sign either???????

	One might think that the definition of "msg-id" is incorrect;
	however, for the "Message-ID:" field whose definition is ...

		"Message-ID" ":" msg-id

	... I have seen the following ...

		Message-Id: <8809201329.AA26050@ncsuvx.ncsu.edu>

	... which is in the correct format!

What should the definition for the "id" section of an "Received:" field
be? Are there a lot of gateways out there that have got it wrong?

(My source for the RFC #822 definition is "Standard For The Format Of
ARPA Internet Text Messages", dated August 13, 1982, revised by David
H. Crocker).

Thanks
Mark Riley
GECO (Geophysical Company Of Norway A/S)
Internet: riley@gest01.sdr.slb.com
SINet: m_gest01::riley
Tel: +47 4 506437

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 14 Oct 88 03:02:19 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 13 Oct 88 14:27:23-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA07726@BLOOM-BEACON.MIT.EDU>; Thu, 13 Oct 88 03:24:56 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Oct 88 21:28:17 GMT
From: att!alberta!ubc-cs!attvcr!tri-x!tjs@bloom-beacon.mit.edu  (Tim Snider)
Organization: TRI-X Technologies Inc., Vancouver, B.C., Canada
Subject: pathalias
Message-Id: <510@tri-x.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

#Take that you line-eater you!

Could someone in the local area please mail me a copy of pathalias.
I'd prefer if you could contact me first but I've gotten no previous
replies so I could probably manage to wade through a few copies if
you send it.

The latest version I have is from  1985, I understand that the latest is
past 1986. 

Please help me tidy up my mail system.



Please Reply to:

UUCP:	tri-x!tjs (Tim Snider)		 Voice:	(604)273-1077
(please avoid routing thru van-bc)
Snail Mail:	#200-10711 Cambie Rd.,Richmond, B.C., Canada, V6X 3G5
		c/o TRI-X Technologies Inc.

Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 14 Oct 88 03:53:15 EDT
Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Fri 14 Oct 88 00:23:12-CDT
Date: Fri, 14 Oct 88 00:23 CDT
From: David Vinayak Wallace <Gumby@MCC.COM>
Subject: How come bitnet hosts always seem to reply to the return-path?
To: header-people@mc.lcs.mit.edu
Supersedes: <881014002247.5.GUMBY@BRAHMA.ACA.MCC.COM>
Message-ID: <881014002310.6.GUMBY@BRAHMA.ACA.MCC.COM>

Whenever I receive a reply from someone on bitnet, it always appears to
have been sent to the return-path of the message, rather than the From
address.  What gives?  Are you bitnet folks on this list ever going to
fix this?

Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 OCT 88  06:28:50 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA10226@EDDIE.MIT.EDU>; Wed, 12 Oct 88 15:05:27 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22877@BLOOM-BEACON.MIT.EDU>; Wed, 12 Oct 88 14:53:04 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Oct 88 16:47:08 GMT
From: joyce!aai7!brunner@ames.arpa  (Eric Brunner)
Organization: SRI International, Menlo Park CA
Subject: Re: Documentation on Internet/UUCP/??? possible types of mail addresses?
Message-Id: <14172@joyce.istc.sri.com>
References: <194@chip.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <194@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes:
>Greetings...
>SOOOO...I guess what I am asking is for a pointer to a definitive document
>that addresses all sorts of address formats.

You may want to read the article that appeared in the October 1986 issue
of the CACM entitled "Notable Networks" by John Quarterman, the format of
addresses for most of the known world (then, and now) are described.
You may also want to look at the rules files in the sendmail sources for
translation rules.

Thomas Eric Brunner
Manager, SRI IST Division Computer Facility, EJ309, x3130

Received: from MTUS5 (TCP 4345005001) by MC.LCS.MIT.EDU 16 Oct 88 22:43:17 EDT
Received: from MTUS5 by MTUS5 ; Fri, 14 Oct 88 09:16:44 EST
Date: Fri, 14 Oct 88 09:16:41 EST
From: "Jeffery K. Bacon III" <BACON@MTUS5>
To:   header-people@mc.lcs.mit.edu

A newer (It should be the newest copy, right?) copy of pathalias, along
with smail 3.some are available by anonymous ftp from simtel20.arpa,
if you can do ftp.

Received: from MTUS5 (TCP 4345005001) by MC.LCS.MIT.EDU 16 Oct 88 22:43:26 EDT
Received: from MTUS5 by MTUS5 ; Fri, 14 Oct 88 09:19:58 EST
Date: Fri, 14 Oct 88 09:19:57 EST
From: "Jeffery K. Bacon III" <BACON@MTUS5>
To:   header-people@mc.lcs.mit.edu
Subject: bitnet people

Well...bitnet is not full of what one might call intelligent router
systems. Often, as is the case here, we get to supply a full path
ourselves. Needless to say, the less-informed often choose the easiest
choice, the return-path, not knowing whether it will work or not.

Forgive us our sins, master, and may TCP/IP be with us all soon. :-)

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Oct 88 20:22:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8102; Fri, 14 Oct 88 21:29:26 EDT
Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 8101; Fri, 14 Oct 88 21:29:16 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
 BSMTP id 3767; Fri, 14 Oct 88 21:33:07 EDT
Date: Fri, 1988 Oct 14   21:19 EDT
From: (John F. Chandler)   PEPMNT@CFAAMP.BITNET
To:   HEADER-PEOPLE@MC.LCS.MIT.EDU, (David Vinayak Wallace)   Gumby@MCC.COM
Subject: Re: How come bitnet hosts always seem to reply to the return-path?
In-reply-to:  Gumby@MCC.COM message of Fri, 14 Oct 88 00:23:00 CDT
Message-id: <PEPMNT.881014.211904.B0@CFAAMP.BITNET>

> Whenever I receive a reply from someone on bitnet, it always appears to
> have been sent to the return-path of the message, rather than the From
> address.  What gives?  Are you bitnet folks on this list ever going to
> fix this?

First, BITNET is far from a homogeneous domain, and mail user agents
have widely varying behavior.  Second, the "Return-path" field is almost
always suppressed from the header, along with the "Message-id" and the
others not truly essential to delivery.  This helps keep the
transmission load down.  Third, mail distributed on BITNET for
HEADER-PEOPLE usually comes with a "Reply-to" field of the list because
the (re)distribution was apparently set up that way when WISCVM started
drowning in mail.  If you want replies to come directly back to you, you
can specify your own "Reply-to".

Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 17 Oct 88 21:58:39 EDT
Received: from garnet.berkeley.edu
	by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l)
	id AA10100; Mon, 17 Oct 88 18:19:50 PDT
Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.13)
	id AA23339; Mon, 17 Oct 88 18:19:46 pdt
Date: Mon, 17 Oct 88 18:19:46 pdt
From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO)
Message-Id: <8810180119.AA23339@garnet.berkeley.edu>
To: BACON%MTUS5.bitnet@jade.Berkeley.EDU
Subject: pathalias routing information
Cc: header-people@mc.lcs.mit.edu

In reply to:

	From <@mc.lcs.mit.edu:BACON@MTUS5> Sun Oct 16 20:28:31 1988
	Date: Fri, 14 Oct 88 09:16:41 EST
	From: "Jeffery K. Bacon III" <BACON%MTUS5.bitnet@jade.berkeley.edu>
	To: header-people@mc.lcs.mit.edu
	
	A newer (It should be the newest copy, right?) copy of
	pathalias, along with smail 3.some are available by anonymous
	ftp from simtel20.arpa, if you can do ftp.

One problem with pathalias for Internet mail sites is that it uses
the UUCP map data.  The UUCP map data assumes that you are in the
UUCP zone using UUCP addressing.

If you do not have UUCP links, for example, you are only an internet
host, then you have to identify the internet names for UUCP/internet
hosts and override the UUCP map data. Ideally this should be done for
all UUCP/internet hosts. However there are network usage restrictions.
Multiple gateways may also require some fine tuning (adjustments) to
the pathalias routing data.

If you are only originating traffic going to UUCP it is possible to
identify one local UUCP gateway to be used, and to generate pathalias
data in an internet gateway format. For example:

	uucppath-address@gateway-domainname
or 
	uucpdomain!uucpdomain!user@gateway-domainname

where gateway-domainname is an internet domain name. Hopefully, your
internet/UUCP mail gateway is a local one so you do not run into
network usage restrictions.  You should obtain permission to use the
internet/UUCP gateway before you send all your UUCP traffic there.
(Please note: ucbvax is not the internet/UUCP gateway for the whole
world. There are others now.)

Conversion to an Internet gateway address format is done by reading
in the following uucp map data last and generating the pathalias
data for "localhost":

-----
# The following line defines the local internet/UUCP gateway
gateway-domainname = uucp-node-name
#
# The following line flips addresses into internat format
# if the pathalias data is generated for "localhost".
localhost	@uucp-gateway-domainname(DEDICATED)
-----

Bill Wells, Postmaster

------------------------------------------------------------------------
| William Wells      Telephone: COML: +1 415-642-9801, ATSS: 582-9801  |
| Data Communication & Network Services  postmaster@jade.berkeley.edu  |
| University of California at Berkeley   netinfo@garnet.berkeley.edu   |
------------------------------------------------------------------------

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Oct 88 20:22:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8102; Fri, 14 Oct 88 21:29:26 EDT
Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 8101; Fri, 14 Oct 88 21:29:16 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
 BSMTP id 3767; Fri, 14 Oct 88 21:33:07 EDT
Date: Fri, 1988 Oct 14   21:19 EDT
From: (John F. Chandler)   PEPMNT@CFAAMP.BITNET
To:   HEADER-PEOPLE@MC.LCS.MIT.EDU, (David Vinayak Wallace)   Gumby@MCC.COM
Subject: Re: How come bitnet hosts always seem to reply to the return-path?
In-reply-to:  Gumby@MCC.COM message of Fri, 14 Oct 88 00:23:00 CDT
Message-id: <PEPMNT.881014.211904.B0@CFAAMP.BITNET>

> Whenever I receive a reply from someone on bitnet, it always appears to
> have been sent to the return-path of the message, rather than the From
> address.  What gives?  Are you bitnet folks on this list ever going to
> fix this?

First, BITNET is far from a homogeneous domain, and mail user agents
have widely varying behavior.  Second, the "Return-path" field is almost
always suppressed from the header, along with the "Message-id" and the
others not truly essential to delivery.  This helps keep the
transmission load down.  Third, mail distributed on BITNET for
HEADER-PEOPLE usually comes with a "Reply-to" field of the list because
the (re)distribution was apparently set up that way when WISCVM started
drowning in mail.  If you want replies to come directly back to you, you
can specify your own "Reply-to".

Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 OCT 88  01:48:25 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA24999@EDDIE.MIT.EDU>; Wed, 19 Oct 88 21:32:02 EDT
Received: from Think.COM by news.think.com; Wed, 19 Oct 88 21:18:36 EDT
Return-Path: <amdahl!tron@ames.UUCP>
Received: from ames.arc.nasa.gov by Think.COM; Wed, 19 Oct 88 21:16:26 EDT
Received: Wed, 19 Oct 88 18:19:16 PDT by ames.arc.nasa.gov (5.59/1.2)
Received: by amdahl.uts.amdahl.com (/\=-/\ Smail3.1.6.1 #6.3)
	id <m0e8mHF-00000dC@amdahl.uts.amdahl.com>; Mon, 17 Oct 88 19:40 PDT
Message-Id: <m0e8mHF-00000dC@amdahl.uts.amdahl.com>
Date: Mon, 17 Oct 88 19:40 PDT
From: tron@uts.amdahl.com (Ronald S. Karr)
To: header-people@mc.lcs.mit.edu
Subject: Re: Smail3 and pathalias on simtel20.arpa

>A newer (It should be the newest copy, right?) copy of pathalias, along
>with smail 3.some are available by anonymous ftp from simtel20.arpa,
>if you can do ftp.

Being one of the two authors of Smail3, I would like to warn people
that Smail3.1 is in alpha release.  We did ask in the distribution's
README file to restrict distribution, though it is a bit late now.
Well, if people want the Smail3 alpha patch updates, please send mail
to info-smail-request@uts.amdahl.com.  In particular, support for the
BSD BIND server just went out in the most recent patch (patch #10).

Could somebody please send mail detailing the patch level of the
sources on Simtel20?

Also, if you are interested in Smail3, please request to be on our
mailing list.

	tron	|-<=>-|		ARPAnet:  amdahl!tron@Sun.COM
      tron@uts.amdahl.com	UUCPnet:  {decwrl,sun,uunet}!amdahl!tron

PS.  The version of pathalias that is included in the Smail3
     distribution is not an "official" release by Peter Honeyman.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Oct 88 23:18:56 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06765@BLOOM-BEACON.MIT.EDU>; Fri, 21 Oct 88 23:11:52 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Oct 88 15:35:38 GMT
From: cwjcc!hal!nic.MR.NET!tank!ncar!noao!asuvax!nud!sunburn!dover!waters@ohio-state.arpa  (Mike Waters)
Organization: Motorola CAD Mesa, AZ {dover}
Subject: Re: pathalias
Message-Id: <474@dover.uucp>
References: <510@tri-x.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <510@tri-x.UUCP> tjs@tri-x.UUCP (Tim Snider) writes:
>
>Could someone in the local area please mail me a copy of pathalias.

We are trying to get Unix/Unix mail working here, and seem to have
everything BUT mail routing working. I too could use a copy or
a pointer to an archive which has a copy. I have looked around in
SIMTEL20 without success, but that may well be my lack of experience.

Thanks in advance for any assistance.


-- 
Mike Waters                 (for your EDIFication)
Motorola SMART CAD Group - EDIF support
Mesa, AZ   ...!sun!sunburn!dover!waters
          OR   moto@cad.Berkley.EDU

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Oct 88 23:40:06 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03922@BLOOM-BEACON.MIT.EDU>; Mon, 24 Oct 88 23:36:07 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Oct 88 16:23:43 GMT
From: munnari!basser!john@uunet.uu.net  (John Mackin)
Organization: Dept. of Comp. Science, Uni of Sydney, Australia
Subject: Is anyone using the RFC822 address grammar from comp.sources.misc?
Message-Id: <1557@basser.oz>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I'd like to get in contact with anyone who has done anything with the
yacc parser for RFC822 addresses that was posted to comp.sources.misc
by David Herron, <david@ms.uky.edu>, back in October of 1987 (article
<4959@ncoast.UUCP>).  I've been working on it for a while and have
fixed several bugs and improved its conformance to RFC822 in some
ways; I'd like to find out what others have done with it, and share
the fixes.  If I don't get any responses to this, I'll post a patch
to comp.sources.bugs in a couple of months, after the new version of
the mailer I've put it into has been in production for a while.

(Please don't mail me asking me to send you a copy of the original
article; unless, that is, you're in Australia.  See Brandon's
periodical postings for a list of comp.sources.misc archive
sites.)

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET)
{uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 04:40:40 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10462@BLOOM-BEACON.MIT.EDU>; Tue, 25 Oct 88 04:28:20 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Oct 88 20:22:26 GMT
From: bpa!cbmvax!vu-vlsi!devon!shockeye!hermit@rutgers.edu  (Mark Buda)
Organization: Competitive Computer Systems, Lancaster PA
Subject: Re: pathalias
Message-Id: <228@shockeye.UUCP>
References: <510@tri-x.UUCP>, <474@dover.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <474@dover.uucp> waters@dover.UUCP (Mike Waters) writes:
>In article <510@tri-x.UUCP> tjs@tri-x.UUCP (Tim Snider) writes:
>>
>>Could someone in the local area please mail me a copy of pathalias.
>
>We are trying to get Unix/Unix mail working here, and seem to have
>everything BUT mail routing working. I too could use a copy or
>a pointer to an archive which has a copy. I have looked around in
>SIMTEL20 without success, but that may well be my lack of experience.

tut.cis.ohio-state.edu has pathalias available via anonymous FTP.
osu-cis has pathalias available via anonymous UUCP.

They may be the same machine.

Pathalias is in pathalias/pathalias9.[12].Z
You can look at the file GNU.how-to-get for more complete information.

>Thanks in advance for any assistance.
You're welcome. You also will probably already know this by the time this
gets to you... life in the backwaters of USENET sucks.
-- 
Mark Buda / Smart UUCP: hermit@shockeye.uucp / Phone(work):(717)299-5189
Dumb UUCP: ...rutgers!bpa!vu-vlsi!devon!shockeye!hermit
Entropy will get you in the end.
"A little suction does wonders." - Gary Collins

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 09:10:09 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA14437@BLOOM-BEACON.MIT.EDU>; Tue, 25 Oct 88 08:58:25 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Oct 88 12:19:49 GMT
From: phri!roy@nyu.edu  (Roy Smith)
Organization: Public Health Research Institute, NYC, NY
Subject: To parse the unparseable dream
Message-Id: <3566@phri.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


	What would you do if you saw the following on a To: line?

Roy Smith <philabs.philips.com.weiser.pa@xerox.com  (Roy Smith)>

	I'm not sure what it's supposed to mean, but it certainly doesn't
mean me.  Actually, the odd part is that somehow it does mean me because it
got to me (although as part of a several-bounce error message).  Where
would you start if you wanted to try to parse this, or would you just say
it's illegal and throw up your hands?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 14:55:16 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22110@BLOOM-BEACON.MIT.EDU>; Tue, 25 Oct 88 14:48:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Oct 88 18:31:17 GMT
From: cwjcc!pirate!chet@ohio-state.arpa  (Chet Ramey)
Organization: CWRU Andrew R. Jennings Computing Center
Subject: Re: To parse the unparseable dream
Message-Id: <210@cwjcc.CWRU.Edu>
References: <3566@phri.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3566@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>	What would you do if you saw the following on a To: line?
>Roy Smith <philabs.philips.com.weiser.pa@xerox.com  (Roy Smith)>

I would (and so would my sendmail.cf) send the whole mess to Xerox and let
them deal with it.  This is a strict interpretation of RFC-822.

>Where would you start if you wanted to try to parse this, or would you just
>say it's illegal and throw up your hands?

If I wanted to parse it, I'd take whatever's between the brackets, throw 
out the comments, and work on what's left.  (And what is a sendmail.cf, if
not the embodiment of it's creator's ideas about mail routing and 
addressing? :-)

So, if you feed it through ruleset 3, it'll come back as

philabs.philips.com.weiser.pa<@xerox.com>

so that seems OK so far (of course, it may not be what was intended). 
Then try to resolve xerox.com, since we don't touch the local part, and
send it off to them (hell, for all I know, Grapevine might actually
make that local part into something useful when it gets there). 

Chet Ramey
Network Operations Group, CWRU
chet@cwjcc.CWRU.EDU


Chet Ramey            			chet@cwjcc.CWRU.EDU
Network Management Group		chet@alpha.CES.CWRU.EDU
Andrew R. Jennings Computing Center	chet@pirate.CWRU.EDU
Case Western Reserve University

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 19:25:24 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA28493@BLOOM-BEACON.MIT.EDU>; Tue, 25 Oct 88 19:24:53 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Oct 88 22:19:02 GMT
From: encore!necis!adamm@bu-cs.bu.edu  (Adam Moskowitz)
Organization: NEC Information Systems, Boxborough, MA
Subject: Incorrect address on outgoing mail
Message-Id: <784@necis.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

We're having some problems with our outgoing mail and I'm hoping someone out
there in net.land has already solved them so I don't have to.

When I send mail, it's often addressed to several people, some of whom are on
a different systemt that the one I'm sending from. It gets to them fine, but
when they try to reply all is hosed because the addresses they receive are
wrong. To be more specfic: I say "mailx user1@host1, user2@host2, user3"
(it's implied that user3 and I are on the same system)(I also seem to get the
same results using elm). But when user1 gets the mail, the address for user3
still says "user3" and I claim it *should* say "user3@host3". Otherwise, how
is user1's mailer supposed to know where to send the reply?

We're using smail 2.5, supposedly updated on 15-Sep-87, on a System V box. I
believe the "stock" /bin/mail is now masquerading as /bin/lmail.

So, please email any possible solutions to the address shown below. If I'm
off my rocker or missing something, email that too. Thanx.
-- 
Adam S. Moskowitz	            ...!(backbone)!{necntc,encore}!necis!adamm
                                    adamm@necis.nec.com

     "Gonna die with a smile if it kills me!"  --  Jon Gailmore

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 20:25:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA29436@BLOOM-BEACON.MIT.EDU>; Tue, 25 Oct 88 20:20:48 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Oct 88 17:54:50 GMT
From: werner@astro.as.utexas.edu  (Werner Uhrig)
Organization: U. Texas, Astronomy, Austin, TX
Subject: I would like to see a header Sender-Addressed-To: <orig. To-address>
Message-Id: <3296@utastro.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

incoming mail arrives on my machine with a To-address which no longer
contains the information of how the sender had originally addressed me,
as the intermediate sites often modify the To-address as the mail gets
passed on from site to site.

I wished all mail would arrive with a header:

X-Sent-To: <original To-address used>
X-CCed-To: <original CC-address>
..etc..

as this is often the only way I can understand and comment on addressing
problem the sender might be having.  Often the CC-addresses arrive here
mangled, as some sites along the way modify them, but others don't,
leaving me to try to hand-knit addresses before I can send a REPLY (to) ALL

has this been discussed before?  has anyone implemented such?
(I might as well start configuring our sendmail.cf do that to encourage
others to follow ...)


-- 
--------------------> PREFERED-RETURN-ADDRESS-FOLLOWS <---------------------
(ARPA)	    werner@rascal.ics.utexas.edu   (Internet: 128.83.144.1)
(INTERNET)     werner%rascal.ics.utexas.edu@cs.utexas.edu
(UUCP)	..!utastro!werner   or  ..!uunet!rascal.ics.utexas.edu!werner

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Oct 88 06:01:33 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4783; Wed, 26 Oct 88 02:10:51 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 4782; Wed, 26 Oct 88 02:10:17 EDT
Date:    Tue, 25 Oct 88 23:09 PDT
To:      werner@ASTRO.AS.UTEXAS.EDU(Werner Uhrig)
CC:      header-people@MC.LCS.MIT.EDU
From:    Leonard D Woren                      <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>
Subject: Re: I would like to see a header Sender-Addressed-To:

Well, I think it's finally time to post something that I've had
sitting around for many years.  I don't know where this originated,
but consider my posting this to be my comment on additional header
lines that don't provide increased function to the end user.  Also,
maybe it'll provide some amusement for readers of this list...


Leonard D. Woren
LDW@USCMVSA.BITNET  LDW@MVSA.USC.EDU = LDW%MVSA.USC.EDU@Oberon.USC.EDU
University of Southern California


     Date:     7 Apr 1977 1712-EST
     From:     Bob Chansler at CMU-10A
     Reply-To: Lord High Executier@CMU-10A
     Subject:  Re: Close, but no cigar
     To:       BRIAN.REID at CMU-10A
     CC:       chansler@CMU-10A
     Sender:   BOB.CHANSLER at CMU-10A
     Message-ID: (CMU-10A)  7 Apr 1977 17:12:49 Bob Chansler
     In-Reply-To: Your message of April 6, 1977
     My-Seq-#: 39492094
     Yr-Seq-#: 4992488
     Class:    A
     Subclass: MCMXLVII
     Author:   fred
     Typist:   fred
     Terminal: TTY88
     FE-L#:    44
     Reason:   Did Godzilla need a reason?
     Valid:    Not before 12 Apr 1977 1321Z
     Suspend:  After 19 Apr 1977 0000Z
     Spelling-errors-this-message:  0
     Spelling-errors-to-date:  23
     Weather:  Light rain, fog.
     Forcast:  Clearing by morning
     Psych-evaluation-of-sender:  slightly unstable
     Security-level:  Public
     Security-sublevel:  0
     Authority-to-send:  general
     Authority-to-rcv:  general
     #-people-in-terminal-room:  12
     XGP:      UP-cutter not working
     Ht/Wt-sender:  76/205
     Machines: M&Ms available but almond machine is empty
     M&Ms-Last-Nickel:  17
     Remailed-To: John.Zsarnay at CMU-10A
     Remailed-From: Peter.Schwarz at CMU-10A
     Remailed-Date: Saturday, 22 September 1979 0155-EDT
     Origin:  C410PS20 at CMU-10A; 22 Sep 1979 0155-EDT
     Remailed-To: Mike.Accetta at CMUA
     Remailed-From: John.Zsarnay at CMU-10A (A650JZ04)
     Remailed-Date: 22 September 1979 1615-EDT
     Origin:  A650JZ04 at CMU-10A; 22 Sep 1979 1616-EDT
     Remailed-To: Fil.Alleva at CMU-10A
     Remailed-From: Mike Accetta <Mike.Accetta at CMU-10A> (A650MA33)
     Remailed-Date: Saturday, 22 September 1979 2004-EDT
     Via:     CMU-10A; 22 Sep 1979 2006-EDT
     Remailed-To: Ken.Wertz at CMU-10B
     Remailed-From: Fil.Alleva at CMU-10B (A650FA33)
     Remailed-Date: Monday, 24 September 1979 1023-EDT
     Via:     CMU-10B; 24 Sep 1979 1025-EDT
     Remailed-To: Don.Provan at CMU-10A
     Remailed-From: Krafty Ken Wertz <Ken.Wertz at CMU-10A>
     Remailed-Date: Monday, 24 September 1979 1029-EDT
     Origin:  C425KW0F at CMU-10A; 24 Sep 1979 1036-EDT
     Remailed-To: Carolyn.Councill at CMU-10A
     Remailed-From: don.provan at CMU-10A
     Remailed-Date: Monday, 24 September 1979 1054-EDT
     Origin:  C425DP0N at CMU-10A; 24 Sep 1979 1055-EDT
     Remailed-To: Eddie.Caplan @ CMUA
     Remailed-From: Carolyn.Councill at CMU-10A (C425CC33)
     Remailed-Date: Monday, 24 September 1979 1631-EDT
     Origin:  C425CC33 at CMU-10A; 24 Sep 1979 1632-EDT
     Remailed-To: lawrence.butcher at CMU-10A
     Remailed-From: eddie caplan <EC0F at CMU-10A>
     Remailed-Date: 24 September 1979 1634-EDT
     Origin:  C425EC0F at CMU-10A; 24 Sep 1979 1635-EDT
     Remailed-To: Mike Kazar at CMU-10A, Craig Everhart at CMU-10A
     Remailed-From: Lawrence Butcher at CMU-10A (X335LB50)
     Remailed-Date: Tuesday, 25 September 1979 1811-EDT
     Origin:  X335LB50 at CMU-10A; 25 Sep 1979 1812-EDT
     Remailed-To: sipb @ mc
     Remailed-From: Mike Kazar <Mike.Kazar at CMU-10A> (C410MK50)
     Remailed-Date: Wednesday, 26 September 1979 0009-EDT

     I do not understand your concern about the size of message headers.
     -------

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Oct 88 06:25:33 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05483@BLOOM-BEACON.MIT.EDU>; Wed, 26 Oct 88 03:40:24 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 04:18:06 GMT
From: ukma!david@rutgers.edu  (David Herron -- One of the vertebrae)
Organization: U of Kentucky, Mathematical Sciences
Subject: Re: To parse the unparseable dream
Message-Id: <10437@s.ms.uky.edu>
References: <3566@phri.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3566@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	What would you do if you saw the following on a To: line?
>
>Roy Smith <philabs.philips.com.weiser.pa@xerox.com  (Roy Smith)>

Actually this isn't too bad ... The embedded comment is a little
strange but is legal.

Of course, we all know that "philabs.philips.com.weiser.pa" is
really a couple of things concatenated together.  The tail part
of that is (as I recall) Mark Weiser's name & "domain" within Xerox.
The rest is domain name for part of philips.com ... BUT, syntactically
this address is perfectly correct.  It is only wrong in its SEMANTICS.

What our system here would do?  Well, I'm assuming for the moment
that MMDF's address parser is correct enough to handle that right.
I believe that it is ... So anyway, we'd pass it over to xerox.com
and it's their problem to figure out who to give it to...


-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.

Received: from cs.utexas.edu (TCP 20024705411) by MC.LCS.MIT.EDU 26 Oct 88 14:47:50 EDT
Posted-Date: Wed, 26 Oct 1988 13:43:39 CDT
Received: from rascal.ics.utexas.edu by cs.utexas.edu (5.59/1.15)
	id AA29749; Wed, 26 Oct 88 13:47:47 CDT
Received: by rascal.ics.utexas.edu (3.2/4.22)
	id AA17312; Wed, 26 Oct 88 13:43:42 CDT
Date: Wed, 26 Oct 1988 13:43:39 CDT
From: Werner Uhrig <werner@rascal.ics.UTEXAS.EDU>
Reply-To: werner@rascal.ics.utexas.edu (Werner Uhrig)
To: Justin Bur <iros1.UUCP%mcgill-vision!cs.utexas.edu!Larry.McRCIM.McGill.EDU!justin@astro.as.UTEXAS.EDU>
Subject: Re: I would like to see a header Sender-Addressed-To: <orig.
        To-address> 
In-Reply-To: Your message of Wed, 26 Oct 88 13:19:44 EDT 
Cc: justin@iro.umontreal.ca, header-people@cs.utexas.edu
Message-Id: <CMM.0.88.593894619.werner@rascal.ics.utexas.edu>

> There is no decent reason for anyone to go rewriting valid RFC822
> To: lines (except at gateways).  It's probably explicitly forbidden
> in the RFC, too.

	the *REAL* world, to my great lament, does not live by RFC822
	alone;  give me credit and assume that my suggestion was made
	because it would provide me useful information;  not out of
	idle curiosity ...

> Most sendmail.cf's that I have seen ....

	it's the ones we haven't seen ..... besides, we do agree that
	not the whole world uses sendmail, right?  Who knows what
	they use in Europe, on Bitnet, on WeirdNet ....   (-:

PS: just take a look at the reply address my mailer generated when it faw your
	message From:-header; do I need to say more?

From: Justin Bur <iros1.UUCP%mcgill-vision!cs.utexas.edu!Larry.McRCIM.McGill.EDU!justin@astro.as.UTEXAS.EDU>

	so the reply address came out as:

To: Justin Bur <iros1.UUCP%mcgill-vision!cs.utexas.edu!Larry.McRCIM.McGill.EDU!justin@astro.as.UTEXAS.EDU>

--------------------------> please send REPLIES to <------------------------
INTERNET:    werner@rascal.ics.utexas.edu     (Internet # 128.83.144.1)
     or:	  werner%rascal.ics.utexas.edu@cs.utexas.edu
UUCP:     ...<well-connected-site>!cs.utexas.edu!rascal.ics.utexas.edu!werner
ALTERNATIVE:   werner@astro.as.utexas.edu   OR    werner@utastro.UUCP

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Oct 88 15:55:40 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12697@BLOOM-BEACON.MIT.EDU>; Wed, 26 Oct 88 15:53:40 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 16:11:13 GMT
From: *!postman+@pt.cs.cmu.edu  (Craig F. Everhart)
Organization: Carnegie Mellon
Subject: Re: To parse the unparseable dream
Message-Id: <EXNTYVy00VsLE154t7@andrew.cmu.edu>
References: <3566@phri.UUCP>,
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I could also take
        Roy Smith <philabs.philips.com.weiser.pa@xerox.com  (Roy Smith)>
and, by hand, figure that maybe philabs.philips.com added itself as a source
route (something like <@philabs.philips.com:weiser.pa@xerox.com>), then
somebody's brain-dead (or ancient) sendmail.cf turned the colon into a dot,
giving something like what you saw.  If I believed that, I'd forward a report of
the thing to the postmasters at philabs.philips.com and whatever other routing
sites had been added in the Received: lines.

                Craig Everhart
                Andrew message system

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Oct 88 16:23:40 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2203; Thu, 27 Oct 88 10:34:32 EDT
Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 2200; Thu, 27 Oct 88 10:33:59 EDT
Received: by IRLEARN (Mailer X1.24) id 4430; Thu, 27 Oct 88 14:32:16 GMT
Date:         Thu, 27 Oct 88 14:30:22 GMT
From:         "Kieran Carrick,UCD,Ireland" <CARRICK%IRLEARN.BITNET@MITVMA.MIT.EDU>
Subject:      Re: I would like to see a header Sender-Addressed-To:
To:           HEADER-PEOPLE@MC.LCS.MIT.EDU
In-Reply-To:  Message of Wed, 26 Oct 88 21:22:55 GMT from <NOREILLY@IRLEARN>

My colleagues here working on OSI and X.400 have commented that it is
nice to see that the US Networking community are are beginning to
create headers that look like x.400 addresses :-)
Kieran Carrick
EARN Country Coordinator - Ireland

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Oct 88 16:55:53 EDT
Received: from iros1.iro.umontreal.ca by RELAY.CS.NET id aa12438;
          27 Oct 88 0:21 EDT
Received: by iros1.iro.umontreal.CA (3.2-SMI)
	id AA09467; Wed, 26 Oct 88 15:45:57 EDT
Message-Id: <8810261945.AA09467@iros1.iro.umontreal.CA>
From: Justin Bur <justin%iro.umontreal.ca@RELAY.CS.NET>
Date: Wed Oct 26 15:33:33 1988
In-Reply-To: Werner Uhrig's message of Wed, 26 Oct 1988 13:43
To: Werner Uhrig <werner@RASCAL.ICS.UTEXAS.EDU>
Subject: Re: I would like to see a header Sender-Addressed-To: <orig. To-address>
Cc: header-people@MC.LCS.MIT.EDU, mouse@LARRY.MCRCIM.MCGILL.EDU

I didn't intend to suggest that you were asking for your
new header line for frivolous reasons, but rather to point
out that the information you want is supposed to be present
already.  What I didn't make clear is that I consider the
effort better spent to use the existing header lines properly
rather than add new ones.  In either case, obtaining compliance
from everyone is practically impossible.  Cleaning up the exist-
ing line, as I see it, is more generally useful than defining a
new one.

Of course one could argue that the new line is guaranteed to be
used properly, whereas the old one is known to be widely misused.
That is, until the first time someone misreads the definition of
the new line and writes software that destroys it, too.

(As for that horrid From: line:  yet another hazard of UUCP mail.
The postmaster of the site mainly responsible for the mess will
probably recognize it and insist again that it's not his fault.)

-- 
Justin Bur
Universite de Montreal - IRO		  <justin@iro.umontreal.ca>
Montreal (Qc) Canada H3C 3J7			<justin@iros1.uucp>

Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 OCT 88  20:05:38 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA06386@EDDIE.MIT.EDU>; Thu, 27 Oct 88 13:03:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA20974@BLOOM-BEACON.MIT.EDU>; Thu, 27 Oct 88 03:31:07 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 22:40:18 GMT
From: brian@ucsd.edu  (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Subject: Re: I would like to see a header Sender-Addressed-To: <orig. To-address>
Message-Id: <1220@ucsd.EDU>
References: <3296@utastro.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I've added the following to our sendmail.cf so that we'll add some
useable addressing info as the mail passes through us; what we do is add
the delivery address we see to the Received line.  That won't do all
that Werner suggested, but it is a help.

HReceived: $?sfrom $s $.by $j ($v/$V)$?r via $r$.;
	$b id $i for $u
---
	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 27 Oct 88 21:31:02 EDT
Received: from localhost.cso.uiuc.edu by uxc.cso.uiuc.edu with SMTP
	(5.60+/IDA-1.2.5) id AA25455; Thu, 27 Oct 88 15:33:44 CDT
To: Bob Larson <R.LARSON%AIS1@ECLA.USC.EDU>
Cc: header-people@MC.LCS.MIT.EDU, postmaster@CI.SEI.CMU.EDU,
        postmaster@SEI.CMU.EDU, postmaster@ANDREW.CMU.EDU, postmaster@SUN.COM,
        postmaster@JUNE.CS.WASHINGTON.EDU, postmaster@OBERON.USC.EDU,
        postmaster@AMES.ARC.NASA.GOV, postmaster@LLL-CRG.LLNL.GOV,
        postmaster@UUNET.UU.NET, postmaster@UMBC3.UMD.EDU, postmaster@TMC.EDU,
        postmaster@jade.berkeley.edu, postmaster@RELAY.CS.NET
Subject: Re: Bogus rejections from unix systems 
In-Reply-To: Your message of Wed, 26 Oct 88 14:14:36 -0700.
             <24102688.16921465@AIS1> 
Date: Thu, 27 Oct 88 15:33:37 CDT
Message-Id: <25451.593987617@uxc.cso.uiuc.edu>
From: Paul Pomes (UofI-CSO 217-333-6262) <paul@uxc.cso.uiuc.edu>

The problem appears more to be in the user mail agent, which breaks addresses
at white space and ",", than in sendmail.

Invoking sendmail directly via

/usr/lib/sendmail -q '<@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>'

caused uxc to contact nss.cs.ucl.ac.uk with the following conversation:

220 nss,cs,ucl.ac.uk Server SMTP etc
>>> HELO uxc.cso.uiuc.edu
250 nss.cs.ucl.ac.uk
>>> MAIL From:<paul@uxc.cso.uiuc.edu>
250 OK
>>> RCPT To:<info-prime-request%ais1@ecla.ucs.edu>
550 (BHST) Unknown host/domain name in "info-prime-request <@ecla.ucs.edu:info-prime-request@ais1>"
<@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>... User unknown
>>> QUIT

Unfortunately nss.cs.ucl.ac.uk has become unreachable precluding the test of
replacing the "..uk,@ecla..." replaced by "..uk:@ecla..."

Received: from ECLA.USC.EDU (TCP 3205200101) by MC.LCS.MIT.EDU 28 Oct 88 01:56:52 EDT
Received: by AIS1; Wed, 26 Oct 88 14:14:36 PDT
Date: Wed, 26 Oct 88 14:14:36 PDT
From: Bob Larson <R.LARSON%AIS1@ECLA.USC.EDU>
Subject: Bogus rejections from unix systems
To: header-people@MC.LCS.MIT.EDU
Cc: postmaster@CI.SEI.CMU.EDU, postmaster@SEI.CMU.EDU,
    postmaster@ANDREW.CMU.EDU, postmaster@UXC.CSO.UIUC.EDU,
    postmaster@SUN.COM, postmaster@JUNE.CS.WASHINGTON.EDU,
    postmaster@OBERON.USC.EDU, postmaster@AMES.ARC.NASA.GOV,
    postmaster@LLL-CRG.LLNL.GOV, postmaster@UUNET.UU.NET,
    postmaster@UMBC3.UMD.EDU, postmaster@TMC.EDU,
    postmaster@JADE.BERKELEY.EDU, postmaster@RELAY.CS.NET, r.larson%AIS1@ECLA.USC.EDU
Message-id: <24102688.16921465@AIS1>


There seems to be a nasty bug in many unix mailers that causes them to
reject messages with a (almost) valid rfc822 header.  The line in
question is:
    To: info-prime <@NSS.Cs.Ucl.AC.UK,@ecla.usc.edu:info-prime@ais1>
Other than the fact that ais1 is not a valid domain, it is a usable
and working address.  (Mailers that don't try to validate all domains
in rfc822 routes should accept this.)

Some (most? sendmail sites?) unix mailers apperently mangle this to:
    To: info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1>
and reject it because of the unbalanced '>'!

Csnet at handles this slightly differently, and does deliver the mail
with a "parse error in original version" warning.

The Cc: recipents of this message are sites that sent rejection
messages (many duplicates) and may not even be the sites guilty,
since upstream sites do the rejection of errors recognised durring
the SMTP session.  If anyone wants copies of the messages from their
site, or all 28 of them, let me know.

Here are the relivent sections of a typical rejection message:

[Recieved lines deleted]
From: MAILER-DAEMON@pwcs.stpaul.gov (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8810260448.AA17826@pwcs.StPaul.GOV>
To: INFO-PRIME-REQUEST%AIS1@ecla.usc.edu

   ----- Transcript of session follows -----
554 ECLA.USC.EDU!INFO-PRIME-REQUEST%AIS1... Unbalanced '>'
554 johne... Unbalanced '>'
554 johne... Unbalanced '>'

   ----- Unsent message follows -----
[Recieved lines deleted]
Via:          uk.ac.umist.cns; Tue, 25 Oct 88 15:05:36 GMT (UMPA/20.200d)
From: Ian Pallfreeman <ip@sun.central-services.umist.ac.uk>
Message-Id: <4413.8810251440@sun>
Subject: TeX driver for Printronix?
To: info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1>
Date: Tue, 25 Oct 88 14:40:26 BST
X-Mailer: Elm [version 1.7]

[text deleted]

Bob Larson <Postmaster%ais1@ecla.usc.edu>


Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Oct 88 07:02:23 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 12:04:04 PDT
Date: Wed, 26 Oct 88 12:03:53 PDT
From: JLarson.pa@Xerox.COM
Subject: Re: To parse the unparseable dream
To: roy%phri.UUCP@arisia.xerox.com, phri!roy@nyu.edu
Cc: chet@cwjcc.CWRU.EDU, david@ms.uky.edu, header-people@mc.lcs.mit.edu,
 JLarson.pa@Xerox.COM
Message-ID: <881026-120404-1351@Xerox>

>	What would you do if you saw the following on a To: line?
>Roy Smith <philabs.philips.com.weiser.pa@xerox.com  (Roy Smith)>

You should try to get someone to fix the broken mailer rather than worry
about parsing smashed header fields.  The most effective thing to do would
be send the headers on the offending message to postmaster@xerox.com and
your local site postmaster so they can determine which mailer(s) is (are)
causing the problem and get it fixed.  

John 


Received: from june.csl.sri.com (TCP 30003020453) by MC.LCS.MIT.EDU 28 Oct 88 13:51:39 EDT
Received: by june.csl.sri.com
	(5.59e++/IDA-1.2.3-10) id AA16333; Fri, 28 Oct 88 10:50:05 PDT
Date: Fri, 28 Oct 1988 10:50:01 PDT
From: David L. Edwards <dle@csl.sri.com>
To: Bob Larson <R.LARSON%AIS1@ECLA.USC.EDU>
Cc: header-people@MC.LCS.MIT.EDU
Subject: re: Bogus rejections from unix systems 
Message-Id: <CMM.0.88.594064201.dle@>

IDA sendmail handles this correctly, in my opinion, by formatting the
header line such that all mailers will find it acceptable while handling
it correctly.  The message failed because of an authorization failure
from nss.

See below which is the result of using the following to address:
	info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1>

-dle

From dle@june.csl.sri.com Fri Oct 28 10:27:02 1988
Received: by june.csl.sri.com
	(5.59e++/IDA-1.2.3-10) id AA16299; Fri, 28 Oct 88 10:27:02 PDT
Date: Fri, 28 Oct 1988 10:27:00 PDT
From: David L. Edwards <dle@csl.sri.com>
To: info-prime <info-prime%ais1@ecla.usc.edu>
Subject: TEST MESSAGE
Message-Id: <CMM.0.88.594062820.dle@>

Lets see if we have the bug...

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 29 Oct 88 05:11:51 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22992@BLOOM-BEACON.MIT.EDU>; Sat, 29 Oct 88 05:09:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Oct 88 05:11:54 GMT
From: utkcs2!cygnusx1!moore@gatech.edu  (Keith Moore)
Organization: CS Dept -- University of TN, Knoxville
Subject: Re: I would like to see a header Sender-Addressed-To: ... (long)
Message-Id: <611@utkcs2.cs.utk.edu>
References: <3296@utastro.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3296@utastro.UUCP> werner@utastro.UUCP (Werner Uhrig) writes:
>incoming mail arrives on my machine with a To-address which no longer
>contains the information of how the sender had originally addressed me,
>as the intermediate sites often modify the To-address as the mail gets
>passed on from site to site.
>
>I wished all mail would arrive with a header:
>
>X-Sent-To: <original To-address used>
>X-CCed-To: <original CC-address>
>..etc..
>
>as this is often the only way I can understand and comment on addressing
>problem the sender might be having.  Often the CC-addresses arrive here
>mangled, as some sites along the way modify them, but others don't,
>leaving me to try to hand-knit addresses before I can send a REPLY (to) ALL
>
>has this been discussed before?  has anyone implemented such?
>(I might as well start configuring our sendmail.cf do that to encourage
>others to follow ...)

Actually, this is easy to do.  Just have either the mail user agent or
the originating system's mailer add the header.  The other mailers should
pass it on undisturbed as long as they don't recognize it.  For instance,
X-Original-To: is probably reasonably safe.  Subsequent mailers should not
add such a header line anyway, since they cannot be sure that the header
was not rewritten before it arrived at that machine.

But why are the addresses being changed anyway?
There are two good reasons that I can think of for addresses to be rewritten:
(would someone like to suggest some others?)
 
1.  The network being used requires source routing (e.g. UUCP), and the
    address must be rewritten at each machine it passes to make it valid  
    for that machine.
2.  The piece of mail in question is being gatewayed from one network to
    another network with a different addressing convention, and the
    addresses must be rewritten to be valid on the second network.

In the latter case, it is useful if the mail gateway includes information
about the address translation, perhaps in the Received: lines.
What I would like to see is a set of network-specific headers added
to a message when it crosses such a gateway, so that if the same message
crosses another gateway to the original network, the original headers
can be restored.  For instance, if someone sends a message to me from
a DECnet node UTKVX, the headers are originally something like
this:

From:	JOE
To: 	UTKCS2::"moore@cygnusx1.cs.utk.edu"

When it reaches the DECnet-to-Internet gateway at UTKCS2, it gets converted
to:

From: JOE%UTKVX.DECNET@utkcs2.cs.utk.edu
To: moore@cygnusx1.cs.utk.edu

Now, if this piece of mail is somehow forwarded to another DECnet system
(say UTKCS1) from cygnusx1, the From: line ends up looking something like 
this:

From:	UTKUX1::"JOE%UTKVX.DECNET%utkcs2.cs.utk.edu@cygnusx1.cs.utk.edu"

when it could be as simple as

From:	UTKVX::JOE


So, I'm thinking about having our gateways add header lines like
X-UT-DECnet-To:, X-BITNET-To:, X-UT-PROFS-To:, and X-Internet-To:
for messages that cross gateway boundaries, and having them recognize
these lines if they are already in the header.

I'd be interested to hear comments and criticisms about how well this
scheme would work, and ideas for better ways to do this sort of thing.


Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore@utkcs1
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 30 Oct 88 02:27:02 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA04058@BLOOM-BEACON.MIT.EDU>; Sun, 30 Oct 88 02:24:26 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 30 Oct 88 01:37:34 GMT
From: mcdchg!chinet!jkingdon@gatech.edu  (James Kingdon)
Organization: Chinet - Public Access Unix
Subject: Re: I would like to see a header Sender-Addressed-To: <orig. To-address>
Message-Id: <6858@chinet.chi.il.us>
References: <3296@utastro.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3296@utastro.UUCP> werner@utastro.UUCP (Werner Uhrig) writes:
>has this been discussed before?  has anyone implemented such?
>(I might as well start configuring our sendmail.cf do that to encourage
>others to follow ...)

I know of at least 2 mailers that do so.  PMDF for VAX/VMS (which is a
mailer which supports TCP/IP, BITNET, DecNET, etc.) calls it X-VMS-To.
The mailer that comes with JNET (which allows a VAX to speak the IBM
RSCS protocols used over BITNET) calls it Original-To.  Whether they
do the same to CC I don't know.  I suppose this kind of "chaos control"
is a good idea but I'd rather focus my energy on trying to get everyone
to accept the standard address format user@foo.bar.baz one way or another.

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 30 Oct 88 14:42:00 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6931; Sun, 30 Oct 88 14:42:30 EST
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 6928; Sun, 30 Oct 88 14:41:57 EST
Date:    Sun, 30 Oct 88 11:35 PST
To:      Bob Larson <R.LARSON%AIS1@ECLA.USC.EDU>,
         header-people@MC.LCS.MIT.EDU,
         Paul Pomes (UofI-CSO 217-333-6262) <paul@UXC.CSO.UIUC.EDU>
From:    Leonard D Woren                             <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>
Subject: Re: Bogus rejections from unix systems

> Invoking sendmail directly via
>
> /usr/lib/sendmail -q '<@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1
>
> caused uxc to contact nss.cs.ucl.ac.uk with the following conversation:
...
> >>> RCPT To:<info-prime-request%ais1@ecla.ucs.edu>
> 550 (BHST) Unknown host/domain name in "info-prime-request <@ecla.ucs.edu:info
> rime-request@ais1>"
> <@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>... User unknown

The 550 message is correct, since the hostname was miskeyed.
It's ECLA.USC.EDU, *not* ECLA.UCS.EDU .

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  5 Nov 88 04:53:12 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10055@BLOOM-BEACON.MIT.EDU>; Sat, 5 Nov 88 04:52:28 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Nov 88 23:41:35 GMT
From: munnari!vuwcomp!rata.vuw.ac.nz!newbery@uunet.uu.net  (Michael Newbery)
Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand
Subject: Widespread violation of RCF822 in "received" ?
Message-Id: <14347@comp.vuw.ac.nz>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

This article is being posted on behalf of a friend who noticed the anomally
while writing an RFC822 parser (in FORTRAN!) I checked and he seems to
be right. The curious may wonder why a New Zealand site is forwarding
stuff from Norway but that is another story...
-----------------------------------------------------------------------

Would anyone out there like to explain the following problem/conflict
with RFC #822 (the "Standard for ARPA Internet Text Messages" used in
many mail systems) :-

        Problem: The received message "id" in a "Received:" field is
        not in the specified format for all mail I have seen (and a
        friend confirms this also).

        The definition for the "Received:" field is the following ...

                received = "Received" ":"
                                 ["from" domain]
                                 ["by"   domain]
                                 ["via"  atom]
                                *("with" atom)
                                 ["id"   msg-id]
                                 ["for"  addr-spec]
                                ";" date-time

        The definition for "msg-id" is the following ...

                msg-id = "<" addr-spec ">"

        Now observe an example "Received:" field ...

                Received: from relay.cs.net by RELAY.CS.NET
                          id eu17161; 20 Sep 88 1:37 EDT

        For a start, the id is not surrounded by angle brackets ("<" and
        ">"). Secondly, "addr-spec" is defined to be ...

                addr-spec = local-part "@" domain

        ... there is definitely not an "@" sign either???????

        One might think that the definition of "msg-id" is incorrect;
        however, for the "Message-ID:" field whose definition is ...

                "Message-ID" ":" msg-id

        ... I have seen the following ...

                Message-Id: <8809201329.AA26050@ncsuvx.ncsu.edu>

        ... which is in the correct format!

What should the definition for the "id" section of a "Received:" field
be? Are there a lot of gateways out there that have got it wrong?

(My source for the RFC #822 definition is "Standard For The Format Of
ARPA Internet Text Messages", dated August 13, 1982, revised by David
H. Crocker).

Thanks
Mark Riley
GECO (Geophysical Company Of Norway A/S)
Internet: riley@gest01.sdr.slb.com
SINet: m_gest01::riley
Tel: +47 4 506437

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU  7 Nov 88 08:58:33 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5865; Mon, 07 Nov 88 08:58:57 EST
Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 5864; Mon, 07 Nov 88 08:58:23 EST
Received: by BUCLLN11 (Mailer R2.01) id 3995; Mon, 07 Nov 88 08:59:03 +0100
Date:         Mon, 07 Nov 88 08:53:19 +0100
From:         "Alain FONTAINE (Postmaster - NAD)" <FNTA80%BUCLLN11.BITNET@MITVMA.MIT.EDU>
Subject:      Re: Widespread violation of RCF822 in "received" ?
To:           Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
In-Reply-To:  Message of Thu, 3 Nov 88 23:41:35 GMT from
 <munnari!vuwcomp!rata.vuw.ac.nz!newbery@UUNET.UU.NET>

The Received:  header line is added  by each Mail Transfer  Agent in the
chain.  In the  Internet, MTA's  normally use  SMTP, defined  in RFC821.
Since SMTP, being a MTA  protocol, specifies the generation of Received:
header lines, it also contains a definition of that line. Unfortunately,
this definition  is not  the same  as the  one you  found in  RFC822 (in
RFC821, id  is defined as 'any  string'...). So, depending on  which RFC
you follow....                                       /AF

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU  7 Nov 88 15:30:52 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0689; Mon, 07 Nov 88 15:30:59 EST
Received: from MAINE.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 0685; Mon, 07 Nov 88 15:30:09 EST
Received: by MAINE (Mailer X1.25) id 0733; Mon, 07 Nov 88 14:22:35 EST
Subject: Re: Widespread violation of RCF822 in "received" ?
To:      HEADER-PEOPLE@MC.LCS.MIT.EDU
From:    Barry D Gates <Gates%MAINE.BITNET@MITVMA.MIT.EDU>
Date:    Mon, 7 Nov 88 14:18:35 EST

>From:         Michael Newbery
>              <munnari!vuwcomp!rata.vuw.ac.nz!newbery@UUNET.UU.NET>
>Subject:      Widespread violation of RCF822 in "received" ?
>
>What should the definition for the "id" section of a "Received:" field
>be? Are there a lot of gateways out there that have got it wrong?

I asked the same question about a month or two back on this list.  The
best I've been able to come up with that is usable is:

    ["id" (msg-id / local-part)]

which I've yet to see anything that will fail it.  If you think about it,
the "domain" in the message-id is normally redundant as it is usually the
same as the "by" clause on the Received tag if one was given (in the messages
I've seen anyway).

This particular syntax is also very easy to differentiate as well.  Just
grab the first token after the atom "id"; if it is the special "<" then
you have a msg-id to parse, otherwise use the local-part format.

Hope that helps,
Barry...

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Dec 88 06:03:40 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA26484@BLOOM-BEACON.MIT.EDU>; Thu, 1 Dec 88 05:54:16 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Dec 88 09:24:13 GMT
From: deimos!ksuvax1!tar@rutgers.edu  (Tim Ramsey)
Organization: Kansas State University, Dept of Computing & Information Sciences
Subject: Mail header wishlist (was Re: Another example why not to re-route)
Message-Id: <1320@ksuvax1.cis.ksu.edu>
References: <1005@asylum.sf.ca.us>, <VIXIE.88Nov29011054@bacchus.pa.dec.com>, <2696@sultra.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[ I've added comp.mail.headers and directed followups there since this thread
  seems to be moving in that direction.  -- Tim]

The Options: header is a good idea.  How about a Bounced-By: header, to make
it clear to mailing list repeaters that this mail shouldn't be broadcast to
the list?  It could include the reason the mail was bounced.

-- 
Timothy Ramsey, USENET Keeper-Upper
BITNET: tar@KSUVAX1
Internet: tar@ksuvax1.cis.ksu.edu
UUCP: ...!rutgers!ksuvax1!tar -or- ...!{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!tar

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Dec 88 10:18:56 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA02505@BLOOM-BEACON.MIT.EDU>; Thu, 1 Dec 88 10:10:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Dec 88 15:04:19 GMT
From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa  (Karl Kleinpaste)
Organization: OSU
Subject: Re: Mail header wishlist
Message-Id: <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>
References: <VIXIE.88Nov29011054@bacchus.pa.dec.com>, <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes:
   The Options: header is a good idea.  How about a Bounced-By: header, to make
   it clear to mailing list repeaters that this mail shouldn't be broadcast to
   the list?  It could include the reason the mail was bounced.

That would be unnecessary if mailing lists would all make sure that,
when distributing out to the list's recipients, an Errors-To:
listname-request@listname-host-machine header were included.  Then
bounces would go to the admin only, and nowhere else.  Also, it helps
to have the From_ line indicate listname-request@listname-host-machine
to keep vacation(1) happily silent.

--Karl

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  1 Dec 88 13:41:27 EST
Received: from sol.engin.umich.edu by XX.LCS.MIT.EDU with TCP/SMTP; Thu 1 Dec 88 13:39:22-EST
From: bhoward@sol.engin.umich.edu
To: karl%triceratops.cis.ohio-state.edu.uucp@ohio-state.arpa,
    header-people@mc.lcs.mit.edu
Date: 1 Dec 1988 13:38 EST
Subject: Re: Mail header wishlist

	From ohio-state.arpa!karl%triceratops.cis.ohio-state.edu.uucp Thu Dec  1 10:45:50 1988
	From: karl%triceratops.cis.ohio-state.edu.uucp@ohio-state.arpa  (Karl Kleinpaste)
	Sender: header-people-request@mc.lcs.mit.edu
	To: header-people@mc.lcs.mit.edu
	Date: 1 Dec 88 15:04:19 GMT
	Organization: OSU
	Subject: Re: Mail header wishlist
	Message-Id: <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>
	References: <VIXIE.88Nov29011054@bacchus.pa.dec.com>, <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>
	
	tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes:
	   The Options: header is a good idea.  How about a Bounced-By: header, to make
	   it clear to mailing list repeaters that this mail shouldn't be broadcast to
	   the list?  It could include the reason the mail was bounced.
	
	That would be unnecessary if mailing lists would all make sure that,
	when distributing out to the list's recipients, an Errors-To:
	listname-request@listname-host-machine header were included.  Then
	bounces would go to the admin only, and nowhere else.  Also, it helps
	to have the From_ line indicate listname-request@listname-host-machine
	to keep vacation(1) happily silent.
	
	--Karl
	
	
From_ aren't valid rfc822.  vacation should use appropriate rfc header
(from:, reply-to:, whatever)

			bruce howard

Received: from tis.llnl.gov (TCP 30003010402) by MC.LCS.MIT.EDU  2 Dec 88 15:46:08 EST
Return-Path: <kehres>
Received: by tis.llnl.gov (4.0/1.14-TIS)
	id AA16199; Fri, 2 Dec 88 12:36:36 PST
Message-Id: <8812022036.AA16199@tis.llnl.gov>
Date: Fri, 2 Dec 88 12:36:32 -0800
From: kehres@tis.llnl.gov (Tim Kehres)
Subject: Re: Mail header wishlist
To: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa
Cc: header-people@mc.lcs.mit.edu
X-Orig-Date: 1 Dec 88 15:04:19 GMT
X-Orig-From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl
             Kleinpaste)
X-Orig-Message-Id: <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>

In your message you write:
> tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes:
>    The Options: header is a good idea.  How about a Bounced-By: header, to make
>    it clear to mailing list repeaters that this mail shouldn't be broadcast to
>    the list?  It could include the reason the mail was bounced.
> 
> That would be unnecessary if mailing lists would all make sure that,
> when distributing out to the list's recipients, an Errors-To:
> listname-request@listname-host-machine header were included.  Then
> bounces would go to the admin only, and nowhere else.  Also, it helps
> to have the From_ line indicate listname-request@listname-host-machine
> to keep vacation(1) happily silent.
> 
> --Karl

The main problem with including an "Errors-To:" field is that it is not
conformant to RFC-822.  More appropriate header fields to use (that are
currently defined by RFC-822) include the "Sender:" as well as 
"Return-Path:" fields.  From RFC-822:

"4.3.1   RETURN-PATH

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

Since most mailing lists can be thought of as re-submitting a message
as opposed to relaying a message, the use of this field by the mailing
list should be valid.

"4.4.2   SENDER / RESENT-SENDER

   This field contains the authenticated identity of the AGENT
   (person, system or process) that sends the message.  It is
   intended for use when the sender is not the author of the mes-
   sage, or to indicate who among a group of authors actually
   sent the message.  If the contents of the "Sender" field would
   be completely redundant with the "From" field, then the
   "Sender" field need not be present and its use is discouraged
   (though still legal).  In particular, the "Sender" field MUST
   be present if it is NOT the same as the "From" Field....."

"4.4.4   AUTOMATIC USE OF FROM / SENDER / REPLY-TO

   For systems which automatically generate address lists for
   replies to messages, the following recommendations are made:

      o  The "Sender" field mailbox should be sent notices of
	 any problems in transport or delivery of the original
	 messages.  If there is no "Sender" field, then the
	 "From" field mailbox should be used.

      o  The "Sender" field mailbox should NEVER be used
	 automatically, in a recipient's reply message....."

Tim Kehres
kehres@tis.llnl.gov

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  3 Dec 88 04:48:35 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA21402@BLOOM-BEACON.MIT.EDU>; Sat, 3 Dec 88 04:43:49 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Dec 88 14:27:20 GMT
From: rti!talos!kjones@mcnc.org  (Kyle Jones)
Organization: Philip Morris Research Center, Richmond, VA
Subject: Re: Mail header wishlist
Message-Id: <359@talos.UUCP>
References: <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> Karl Kleinpaste writes:
[concerning Bounced-By: header]
>That would be unnecessary if mailing lists would all make sure that,
>when distributing out to the list's recipients, an Errors-To:
>listname-request@listname-host-machine header were included.

This works only if everyone runs a mailer that supports this header.
There is no mention of Errors-To: in RFC822.  Sendmail claims to
support this header, but smail (2.5) certainly does not.  I say
'claims' because I recently had a mailing list that I run flooded with
returned mail from a host running sendmail.  An Errors-To: line was
present in the message in question.

For my money, the right way to avoid bounced mail hitting an entire
mailing list is to make the From: header say <list-name>-request
instead of <list-name>.  This means that recipients must edit the To:
line if they want to reply to the list, but that's a small price to pay.

kyle jones   <kjones@talos.UUCP>   ...!uunet!talos!kjones

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  3 Dec 88 12:18:33 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA27950@BLOOM-BEACON.MIT.EDU>; Sat, 3 Dec 88 12:12:43 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Dec 88 16:51:40 GMT
From: ukma!david@rutgers.edu  (David Herron -- One of the vertebrae)
Organization: U of Kentucky, Mathematical Sciences
Subject: Re: Mail header wishlist
Message-Id: <10645@s.ms.uky.edu>
References: <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>, <359@talos.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes:
>In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> Karl Kleinpaste writes:
>[concerning Bounced-By: header]
>>That would be unnecessary if mailing lists would all make sure that,
>>when distributing out to the list's recipients, an Errors-To:
>>listname-request@listname-host-machine header were included.
>  An Errors-To: line was
>present in the message in question.
>
>For my money, the right way to avoid bounced mail hitting an entire
>mailing list is to make the From: header say <list-name>-request
>instead of <list-name>.  This means that recipients must edit the To:
>line if they want to reply to the list, but that's a small price to pay.


No no no no ...

The *right* way to do this is to change the out-of-band return
address to be <list-name>-request@list-host.domain.  I think this
is even documented in an RFC somewhere, but is certainly the
preferred practice on the Internet.  And the main offenders are
mailing lists run at sites running SendMail.

On the internet the out-of-band information is carried as part of
the SMTP conversations in the MAIL FROM:<> and RCPT TO:<> lines.
In BITNET there isn't any good place to carry the information
unless you're using BSMTP, and this is one of the reasons why
BITNET should be converting to BSMTP.  In UUCP, this information
is carried in two places, the TO information is carried along as
arguments to rmail and the FROM information is carried along
in the "From<space>" line.  Most rmail's allow only one argument,
which ends up requiring physically seperate messages be sent out
for each person on the mailing list.

This is one of the things which MMDF does right.  Part of the
package is the List Channel.  It accepts messages meant for
a mailing list and

	expands the TO portion of the out-of-band information
		to be all the people on the list.
	if <list-name>-request exists as an alias in the system,
		changes the out-of-band FROM information to
		reflect this.
	resubmits the message to the system.  (no header munging)

A similar program would be easy to do to run under sendmail.
Part of how this happens in MMDF is that you have a sequence
of aliases like:

	<list>:		<list>-outgoing@list-processor
	<list>-outgoing: :include:/file
	<list>-request:	joe-blow

In other words, you have to set up a pseudo-host so that you can
direct mail to it.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.

Received: from IU.AI.SRI.COM (TCP 1201200002) by MC.LCS.MIT.EDU  3 Dec 88 14:13:25 EST
Date: Sat 3 Dec 88 11:13:06-PST
From: Peter Karp <PKARP@IU.AI.SRI.COM>
Subject: Re: Mail header wishlist
To: rti!talos!kjones@mcnc.org
Cc: header-people@mc.lcs.mit.edu
Message-ID: <597179586.0.PKARP@IU.AI.SRI.COM>
In-Reply-To: <359@talos.UUCP>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(133)+PONY(225)@IU.AI.SRI.COM>

Get real folks.  RFC822 provides ways of solving this problem.
If every mailer followed the specs, error messages would go to
the right places.  I see no point in proposing new specs that
people will be just as lax in following.

Peter
-------

Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU  3 Dec 88 22:18:50 EST
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.60+/IDA-1.2.5) id AA10879; Sat, 3 Dec 88 21:19:17 CST
Message-Id: <8812040319.AA10879@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 4115; Sat, 03 Dec 88 21:04:51 CST
Date:         Sat, 03 Dec 88 20:46:56 CST
From: Philip Howard <phil@vmd.cso.uiuc.edu>
Subject:      mailing list headers
To: Tim Kehres <kehres@tis.llnl.gov>,
        Header-People <header-people@mc.lcs.mit.edu>

> The main problem with including an "Errors-To:" field is that it is not
> conformant to RFC-822.  More appropriate header fields to use (that are
> currently defined by RFC-822) include the "Sender:" as well as
> "Return-Path:" fields.  From RFC-822:
(RFC822 extract omitted)
> Tim Kehres
> kehres@tis.llnl.gov

Because of mailing system security, one of the FROM CLASS fields must
represent the true origin of the mail.  Usually it is FROM: itself, but
SENDER: usually provides a sufficient alterantive.  However, in the case
of mailing lists on some systems, there may be a need to identify:
1.  Who wrote the message being distributed
2.  Who actually sent the message to the mailing list
3.  The mailing list itself, usually for contributing
4.  The daemon that runs the mailing list
5.  The mailing list administration

Typically, there are fewer than 5 distinct addresses in a mailing, but the
bindings between those identities that are the same address could be different
in different cases.  For example one system may usually have 3 and 4 be the
same address while another has 4 and 5 the same address.  Even if no actual
case has 5 distinct addresses, we might need to consider the combinations as
though there were 5 distinct addresses.  Still, there even can be a need for
all 5.

Now can someone label each of the 5 addresses with the name of the RFC822
header field that should be used for it?  If you are wanting to use the
RESENT CLASS headers, consider:
6.  Who resent the mail to mailing list
7.  Who resent the mailing list mail to someone

--phil--

Received: from wucs1.wustl.edu (TCP 20077075414) by MC.LCS.MIT.EDU  4 Dec 88 07:38:43 EST
Received: from wubios.wustl.edu by wucs1.wustl.edu
	(5.59/1.33); id AA26493; Sun, 4 Dec 88 06:39:16 CST
Return-Path: <phil@wubios.WUstl.EDU>
Received: by wubios.WUstl.EDU (4.0/Sun UNIX 4.0); Sun, 4 Dec 88 06:42:27 CST
From: phil@wubios.WUstl.EDU (J. Philip Miller)
Message-Id: <8812041242.AA13415@wubios.WUstl.EDU>
To: header-people@mc.lcs.mit.edu (Header-People Distribution List)
Date: Sun, 4 Dec 88 6:42:26 CST
Subject: mailing list headers
X-Mailer: Elm [version 1.5]

> Date:         Sat, 3 Dec 88 20:46:56 CST
> From: Philip Howard <phil@VMD.CSO.UIUC.EDU>
> Subject:      mailing list headers
> 
> Because of mailing system security, one of the FROM CLASS fields must
> represent the true origin of the mail.  Usually it is FROM: itself, but
> SENDER: usually provides a sufficient alterantive.  However, in the case
> of mailing lists on some systems, there may be a need to identify:
> 1.  Who wrote the message being distributed
> 2.  Who actually sent the message to the mailing list
> 3.  The mailing list itself, usually for contributing
> 4.  The daemon that runs the mailing list
> 5.  The mailing list administration
> 
> Typically, there are fewer than 5 distinct addresses in a mailing, but the
> bindings between those identities that are the same address could be different
> in different cases.  For example one system may usually have 3 and 4 be the
> same address while another has 4 and 5 the same address.  Even if no actual
> case has 5 distinct addresses, we might need to consider the combinations as
> though there were 5 distinct addresses.  Still, there even can be a need for
> all 5.

Phil, you have writen one of the most cogent statements on this problem
that I have seen in many months.  Most contributors have simply resorted
to mailer-bashing because someone else's mailing list grouped  your 5
cases in a different way than on their own system.  How these functions are
grouped is typically a function of other software, administrivia and
technical issues.  Just because something works well in a Unix/sendmail
environment does not mean it works right in an IBM RSCS-type
environment.

As to whether there needs to be new headers or not (I think there is
such a need), 822 clearly allows for the registration of new header
types.  If such registration is done (As far as I know it has never been
actually done), then the use of such headers IS 822 CONFORMING!


-phil
> 
> Now can someone label each of the 5 addresses with the name of the RFC822
> header field that should be used for it?  If you are wanting to use the
> RESENT CLASS headers, consider:
> 6.  Who resent the mail to mailing list
> 7.  Who resent the mailing list mail to someone
> 
> --phil--
> 
> 


Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 DEC 88  05:30:17 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07047@EDDIE.MIT.EDU>; Mon, 5 Dec 88 05:30:49 EST
Received: from Think.COM by news.think.com; Mon, 5 Dec 88 05:19:55 EST
Return-Path: <amdahl!busboy.uts.amdahl.com!tde.uts.amdahl.com!tron@ames.UUCP>
Received: from ames.arc.nasa.gov by Think.COM; Mon, 5 Dec 88 04:43:37 EST
Received: Mon, 5 Dec 88 02:11:42 PST by ames.arc.nasa.gov (5.59/1.2)
Received: by amdahl.uts.amdahl.com (/\=-/\ Smail3.1.10.3 #10.1)
	id <m0eQGBr-00000VC@amdahl.uts.amdahl.com>; Mon, 5 Dec 88 08:03 GMT
Received: by busboy.uts.amdahl.com (/\=-/\ Smail3.1.11.5 #11.3)
	id <m0eQGAp-0001HpC@busboy.uts.amdahl.com>; Mon, 5 Dec 88 00:02 PST
Received: by tde.uts.amdahl.com (/\=-/\ Smail3.1.11.5 #11.5)
	id <m0eQGAc-000057C@tde.uts.amdahl.com>; Mon, 5 Dec 88 00:02 PST
Message-Id: <m0eQGAc-000057C@tde.uts.amdahl.com>
Date: Mon, 5 Dec 88 00:02 PST
From: tron@uts.amdahl.com (Ronald S. Karr)
To: bhoward@sol.engin.umich.edu
Subject: Re: Mail header wishlist
Cc: header-people@mc.lcs.mit.edu

 >From_ aren't valid rfc822.  vacation should use appropriate rfc header
 >(from:, reply-to:, whatever)

The From_ sender address is the closest UUCP equivalent to the sender
path described in RFC821 (SMTP).  The SMTP sender path is the preferred
address for error messages, so the philosophy of using the From_ line
is not so inappropriate as you say it is.

	tron	|-<=>-|

Received: from po2.andrew.cmu.edu (TCP 20000574551) by MC.LCS.MIT.EDU  6 Dec 88 11:01:01 EST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA02624> for header-people@mc.lcs.mit.edu; Tue, 6 Dec 88 11:01:00 EST
Received: via switchmail; Tue,  6 Dec 88 11:00:49 -0500 (EST)
Received: from apollo.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q006/QF.kXb0E6y00VsLI0J08i>;
          Tue,  6 Dec 88 11:00:16 -0500 (EST)
Received: from apollo.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr13/cfe/.Outgoing/QF.8Xb0E2y00VsLE1JXV0>;
          Tue,  6 Dec 88 11:00:02 -0500 (EST)
Received: from Version.6.25.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.andrew.cmu.edu.rt.r3
          via MS.5.6.apollo.andrew.cmu.edu.rt_r3;
          Tue,  6 Dec 88 11:00:02 -0500 (EST)
Message-Id: <EXb0E2y00VsL81JXNa@andrew.cmu.edu>
Date: Tue,  6 Dec 88 11:00:02 -0500 (EST)
From: "Craig F. Everhart" <cfe+@andrew.cmu.edu>
X-Andrew-Message-Size: 2805+0
To: header-people@mc.lcs.mit.edu
Subject: Re: mailing list headers
In-Reply-To: <8812040319.AA10879@uxc.cso.uiuc.edu>
References: <8812040319.AA10879@uxc.cso.uiuc.edu>

At the risk of participating in a header-name-calling war, I'd like to offer an
interpretation of Philip Howard's fine analysis of header bindings that I
believe is what the RFCs say:
> 1.  Who wrote the message being distributed
Value of the From: field
> 2.  Who actually sent the message to the mailing list
Value of the Sender: field
> 3.  The mailing list itself, usually for contributing
Value of the To: field.  Some distribution mechanisms might wish to interject
this in a Reply-to: field, but that gets in the way of the author/sender's use
of said field.
> 4.  The daemon that runs the mailing list
Value of the Return-path: field, copied from the envelope; this reaches the list
administration.  It's not clear that recipients know how to communicate with the
daemon itself, should it happen to have a mailing address.
> 5.  The mailing list administration
Value of the Return-path: field, copied from the envelope
> 6.  Who resent the mail to mailing list
Value of the ReSent-From: field, when the corresponding ReSent-To: field is the
list submission address
> 7.  Who resent the mailing list mail to someone
Value of the ReSent-From: field, when the corresponding ReSent-To: field is the
address of ``someone''.

Lots of folks don't live in the RFC821/RFC822 world and thus don't have routine
access to all this information; unfortunately, RFC821 and RFC822 differ on where
the errors-to information should go (821: the MAIL FROM:/Return-Path:
information, 822: the Sender), even though Sender: can be useful to the composer
of the original message composer as well.

There are doubtless lots of presumptions I'm making.  There's always a tension
between whether the receiver of a message to be redistributed is a first-class
mail recipient or not.  If it is first-class, then the redistribution is a
re-sending operation applied to a piece of received mail; if it's not
first-class, redistribution is a matter of rewriting the envelope without
opening the letter.  My preference is for the latter; the ReSent-xxx headers are
always messy for recipients to handle automatically.  In any event,
non-first-class-recipient redistribution only needs to mess with the envelope;
errors go to the Return-path: information, as given in RFC821; and the
redistributor isn't burdened with rewriting RFC822 headers at all.

My own opinion is that the fact that sendmail implements Errors-to: and
<listname>-owner doesn't make them a standard that others need to follow.

Clearly, other views are possible.  According to my understanding, it's a
miracle that LISTSERV works at all; in RSCS-land there's no distinct envelope
information (or none that you can count on), and LISTSERV is a first-class mail
recipient, so it both has to have an address and has to muck with the
preexisting message headers.

Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU  6 Dec 88 17:45:00 EST
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.60+/IDA-1.2.5) id AA04054; Tue, 6 Dec 88 16:43:27 CST
Message-Id: <8812062243.AA04054@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 0730; Tue, 06 Dec 88 15:49:44 CST
Date:         Tue, 06 Dec 88 15:25:36 CST
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      Re: mailing list headers
To: "Craig F. Everhart" <cfe+@andrew.cmu.edu>,
        header people <header-people@mc.lcs.mit.edu>
In-Reply-To:  Your message of Tue,  6 Dec 88 11:00:02 -0500 (EST)

> > 3.  The mailing list itself, usually for contributing
> Value of the To: field.  Some distribution mechanisms might wish to interject
> this in a Reply-to: field, but that gets in the way of the author/sender's use
> of said field.

I forgot to include something here.  There is ALSO another address, that
being the address of who is receiving the mail from the mailing list system.
Because of the way LISTSERV redistributes mail, it has to use this header.

See later part about first-class mail receipt.  This is not needed if....

BTW:
I have also seen mailer-daemons that will not accept the mail unless it is
address To: someone on their machine (or in Cc:).  I think those are kind of
sick, but I'm not going to offend people there with this because they cannot
receive this header-people mail anyway.


> > 4.  The daemon that runs the mailing list
> Value of the Return-path: field, copied from the envelope; this reaches the li
> administration.  It's not clear that recipients know how to communicate with t
> daemon itself, should it happen to have a mailing address.
> > 5.  The mailing list administration
> Value of the Return-path: field, copied from the envelope

Would you mean (and is it legal) for there to be 2 different Return-path:
headers when 4 and 5 are different?  If it is legal 822, sounds good to me.
BITNET's LISTSERV has an address, and mail to it is interpreted as a set of
commands that include automatic subscribing and access to a file server with
indexes related to mailing lists.  A nifty system.


> Lots of folks don't live in the RFC821/RFC822 world and thus don't have routin

The MAILER used on lots of BITNET VM/CMS systems is partly RFC733 and partly
RFC822 compatible.  There is a new MAILER out, but I haven't been able to get
a copy of it yet.

> mail recipient or not.  If it is first-class, then the redistribution is a
> re-sending operation applied to a piece of received mail; if it's not
> first-class, redistribution is a matter of rewriting the envelope without
> opening the letter.  My preference is for the latter; the ReSent-xxx headers a
> always messy for recipients to handle automatically.  In any event,
> non-first-class-recipient redistribution only needs to mess with the envelope;

This would make things a lot easier and it is possible to do even on VM/CMS
using MAILER.  Just send BSMTP to your server and make the server a known
MAILER.  This would be my preference, too.

> Clearly, other views are possible.  According to my understanding, it's a
> miracle that LISTSERV works at all; in RSCS-land there's no distinct envelope
> information (or none that you can count on), and LISTSERV is a first-class mai
> recipient, so it both has to have an address and has to muck with the
> preexisting message headers.

Since early efforts to write a LISTSERV were done by students without access
to their systems beyond ordinary user access, things just got started this
way and never changed.  It could change, but now it would be rather disruptive.
Wait a while, and it will be a bigger disruption later.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  6 Dec 88 17:53:15 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06331@BLOOM-BEACON.MIT.EDU>; Tue, 6 Dec 88 17:39:33 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Dec 88 22:00:32 GMT
From: mailrus!ulowell!page@ohio-state.arpa  (Bob Page)
Organization: University of Lowell, Computer Science Dept.
Subject: Re: Mail header wishlist
Message-Id: <10512@swan.ulowell.edu>
References: <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>, <359@talos.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Karl Kleinpaste writes:
> [include] Errors-To:

Errors-To: is a sendmail-ism.  A stock sendmail will bounce errors to
the Errors-To: address IN ADDITION to the From: address.

You should use Sender: as per rfc822. 

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page
Have five nice days.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  6 Dec 88 23:38:15 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12452@BLOOM-BEACON.MIT.EDU>; Tue, 6 Dec 88 23:29:40 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Dec 88 04:16:24 GMT
From: unmvax!turing.unm.edu!mike@bloom-beacon.mit.edu  (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Subject: Re: Mail header wishlist
Message-Id: <2179@unmvax.unm.edu>
References: <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec1100418@triceratops.cis.ohio-state.edu>, <359@talos.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes:


   In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> Karl Kleinpaste writes:
   [concerning Bounced-By: header]
   >That would be unnecessary if mailing lists would all make sure that,
   >when distributing out to the list's recipients, an Errors-To:
   >listname-request@listname-host-machine header were included.

   This works only if everyone runs a mailer that supports this header.
   There is no mention of Errors-To: in RFC822.  Sendmail claims to
   support this header, but smail (2.5) certainly does not.  I say
   'claims' because I recently had a mailing list that I run flooded with
   returned mail from a host running sendmail.  An Errors-To: line was
   present in the message in question.

Hmmm...It appears I (who said the same thing as Karl) that you are
correct.  On the other hand, the Sender: field is unquestionable the
proper location for errors to be sent.  

   For my money, the right way to avoid bounced mail hitting an entire
   mailing list is to make the From: header say <list-name>-request
   instead of <list-name>.  This means that recipients must edit the To:
   line if they want to reply to the list, but that's a small price to pay.

Hmmmm...yeah.  But then I suspect you will have to manually forward
lots of postings from users who didn't manually edit the To: line.  

The best way is for mail addressed like so:

To: mailinglist@foo.bar.bax
From: Joe.User@my.machine

to be transformed by foo.bar.bax when it resends the mail into

Resent-From: mailinglist-request@foo.bar.bax
Resent-Sender: mailinglist-request@foo.bar.bax
To: mailinglist@foo.bar.bax
From: Joe.User@my.machine

The mail should be delivered using the Resent-* headers in preference
to the originals...according to the RFC.  How much you wanna bet that
smail and sendmail both don't actually do this right...:-)

The best defacto solution is probably to have the mail set to
individual list subscribers be addressed

To: mailinlist@foo.bar.bax
Sender: mailinglist-request@foo.bar.bax
From: Joe.User@my.machine
Reply-To: mailinglist@foo.bar.bax

If you want the from line changed, then go ahead--but you are asking
to be filled with pain if you don't fix the Reply-To: line...


--
Michael I. Bushnell         \  	  This above all; to thine own self be true
HASA - "A" division   GIG!   \    And it must follow, as the night the day,
mike@turing.unm.edu   	     /\	  Thou canst not be false to any man.
Numquam  Gloria Deo   	    /  \  Farewell:  my blessing season this in thee!

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU  7 Dec 88 00:05:23 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9113; Wed, 07 Dec 88 00:05:23 EST
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 9112; Wed, 07 Dec 88 00:05:20 EST
Date:    Tue, 06 Dec 88 21:00 PST
To:      header-people@MC.LCS.MIT.EDU
From:    Leonard D Woren                      <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>
Subject: Re: mailing list headers

My personal view is that ReSent-xxx is a bad idea which should never
have been included in the standard.  It's too hard to determine
exactly what's going on when there are ReSent- headers.  And what
happens if you resend a resent message???  This may or may not be a
reasonable analogy, but if you receive a letter via snailmail, and
you want to forward it to someone else, you don't stick more writing
on the first envelope.  You put the whole thing in a new envelope and
resend it.  This is how *I* think that resent e-mail should be done.

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU  7 Dec 88 05:33:25 EST
Received: by INFOODS id <00000EF7061@INFOODS.MIT.EDU> ;
       Wed,  7 Dec 88 05:28:00 EST
Date: Wed,  7 Dec 88 04:28:16 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: mailing list headers and envelopes
To: Leonard D Woren <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>
X-VMS-Mail-To: EXOS%"Leonard D Woren <LDW%MVSA.USC.EDU@MITVMA>"
Message-ID: <881207042816.00000EF7061@INFOODS.MIT.EDU>
cc: header-people@MC.LCS.MIT.EDU

I've been trying to ignore this discussion, since I think it is kicking 
a dead horse, but Leonard's comment has finally prompted me to start 
typing.  First, and perhaps most important, there are three
meta-problems with RFC821/822 that set part of the context of this
discussion:
  (a) A lot of systems, including the most popular mailers used on U**X
systems and the dominant mailer for VM/CMS systems on BITNET conform at
the "mostly" level.  As has been pointed out earlier in this discussion,
if one adds headers, or makes more specific rules about how existing
ones are used, someone out there will decline to pay any attention.  So,
at best you can make the situation a bit better--at great cost--but you
can't solve it.
  One of the reasons for non-conformance is that the 821/822 logic was
designed around the assumptions of strong envelopes and interactive
(i.e., able to negotiate with each other) MTAs.  In the design
environment of SMTP (821), if the MTA on machine A tries to send a
message to an unknown user on machine B, it gets an error message from
the MTA on machine B in response to machine A's RCPT-TO message.  At
that point, the MTA on machine A can trash the message as it deems
appropriate, having never transmitted the message body.  To state this a
little more clearly for the non-Internet readers of this list: RFC822
does not need rules about what machine B does to the (822) headers of an
undeliverable message or which of them it uses to generate an error
reply, because machine B *never* sees the message OR THE 822 HEADERS if
its MTA reports to machine A's MTA that the message is undeliverable. 
  Now, things like BSMTP provide some approximation to the "envelope" 
part of this business, but they can't approximate the interactive way in 
which SMTP uses that envelope in a "I want this delivered to Fred", "we 
don't have a Fred" dialogue.  And, as has been pointed out, BITNET is
exceedingly tolerant of messages that don't arrive with BSMTP envelopes, 
just as various other arrangements are tolerant of non-conforming 
header fields.
  Making rules is easy, the problem is getting people to follow them, 
especially people who think they know better and have "better ideas".

  (b) RFC822 was never designed to accomodate mailing list traffic in the 
form in which that traffic has evolved.  Things look and feel peculiar 
because they are peculiar.  While I'm very sympathetic to the analysis 
that has appeared here over the last few days, and to some of the 
specific suggestions, there is some stretching involved.  For example, 
if RFC822 "Sender" is different from "From", the "Sender" is supposed to 
be the authenticated [human] agent of the message originator, who
appears in "From". If I'm on my way out of the office, and I hand an
e-mail message on paper to a secretary and say "please transmit this",
then he or she becomes "Sender" and I become "From".  Does the secretary
want the bounce messages? No, probably not, but under other scenarios,
the answer might be different.   This sort of thing is, ultimately, a 
strong argument for an assortment of "Error-mumble" fields in RFC822 or 
its descendants, but see (a) above and (c) below.  In the interim, it is 
sensible to devise strategies to get around the problems as much as 
possible without bothering to argue protocol-purity.
   More important, adding fields won't help very much if one of the 
hosts involved implements RFC821 as discussed under (a).  If you don't 
see the message headers, but work only with the envelope, you can't do 
much with the message headers.  To require that an RFC821 mail server 
accept any incoming message and analyse it so that it can return it to 
the "right" place would require a fairly major change in that protocol.  
I think it would also raise some security issues, but I don't want to 
think about that at the moment.

  (c) Like it or not, X.400, especially in the 1988 version, is looming 
on the horizon.  It is going to be hard to get vendors, or even the 
protocol-specifying part of the research community, to make major 
investments in things like RFC822 headers when the shape of the future 
is as clear as X.400 is today.  And, for better or worse, X.400 is 
populated with a rather complete set of "this kind of errors go to A, 
that kind go to B, acknowledgements go to C, and replies go to D" sorts 
of fields.  
   Nothing said above should be taken as either an endorsement of, or 
enthusiasm about, X.400.  I merely assert that it is a reality which 
sets some context for proposing header changes.

Now, after that long introduction, Leonard Woren writes:
>My personal view is that ReSent-xxx is a bad idea which should never
>have been included in the standard.  It's too hard to determine
>exactly what's going on when there are ReSent- headers.  And what
>happens if you resend a resent message???  This may or may not be a
>reasonable analogy, but if you receive a letter via snailmail, and
>you want to forward it to someone else, you don't stick more writing
>on the first envelope.  You put the whole thing in a new envelope and
>resend it.  This is how *I* think that resent e-mail should be done.

But, in 821/822 land, this is *exactly* what happens.  RFC822 headers 
are not part of the envelope, they are a structured piece of the 
message.  When I get a message from you, and I want to resend it to a 
third party, and my UA is smart enough to arrange a "forward" or 
"resend" operation correctly, all of the action goes on in the envelope 
that is constructed for the message to be resent.  If I'm doing that 
with snailmail, I've probably discarded the envelope in which I received 
the message (this is consistent with Leonard's model) and so, to send 
the message to a third party, I make up a new envelope and send it out.  
So far, exact analogy, and I haven't mentioned a "Resent" header.  BUT, 
I also do one other thing before sealing the envelope and dropping it in 
the postbox, which is to affix a sticky piece of paper to the message 
text that says "hey Joe, I think you should look at this too, --john".  
I'd suggest that this becomes part of the "header" (the letterhead and 
original addressee information) and, in RFC822's language, is Resent-to,
Resent-from, and [X-]Resent-comment.
  Now, if "joe" sends it on again, he might take any of three courses of 
action:
 (a) remove my piece of sticky paper and replace it with his own, 
analogous to removing the original Resent fields and replacing them.
 (b) add his piece of sticky paper to the letter, analogous to adding 
additional Resent fields.
 (c) cut the interesting parts out of the letter and tape it to his own 
notes and then send that, analogous to building a new message, headers, 
envelope, and all, with him as "From" and no Resent fields at all.

  Yes, in the second case, one has to do a little deducing if you want 
to figure out the path the message travelled (especially if you don't 
have a full set of Received fields with full information), but you have 
that problem with the postal analogy also.

  Finally, note that there are at least a few conforming implementations 
of SMTP in which the actual body of the message text belongs to the 
local MTA, which thinks it is responsible for header authentication.  
You can read mail, you can extract mail from the system and repackage 
it, but the only way you ever get a Resent or Forwarded field involves 
asking the MTA to forward it for you: those fields imply a guarantee by 
the MTA that what you received you sent on, unaltered.  If you copy the 
message text out and then try to send it, it is a new message as far as
the system is concerned and you don't get Resent or Forwarded fields.

John Klensin, Center for International Studies, MIT


Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  7 Dec 88 13:08:25 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA25588@BLOOM-BEACON.MIT.EDU>; Wed, 7 Dec 88 12:53:57 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 5 Dec 88 10:28:48 GMT
From: mcvax!inria!crcge1!lri!rd@uunet.uu.net  (Roland Dirlewanger)
Organization: LRI - Orsay. France.
Subject: Validity check failed - What is it ?
Message-Id: <316@lri.lri.fr>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Some gateways refuse to forward some messages issued by our site. This
problem affects mostly BSMTP error messages. In the following example, some
user at MIT.EDU sent a message to some user at our site (FRLRI61.BITNET).
The local user name was wrong, so our mailer generated an error message back
to the sender, an this message was rejected by CUNYVM.

Could someone tell me why ? How does a gateway check the validity
of some message ?

Thanks a lot in advance.
--
Roland Dirlewanger				E-mail: rd@lri.fr
Universite Paris Sud					rd@lri.UUCP
Laboratoire de Recherche en Informatique		rd@FRLRI61.BITNET
Batiment 490					Phone: +33 (1) 69 41 64 01
91405 Orsay Cedex

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

Here is the example:

# Your mail was not delivered to some or all of its
# intended recipients for the following reason(s):
# 
# Validity check failed.
# 
# --------------------RETURNED MAIL FILE--------------------
# Received: from FRLRI61(MAILER) by CUNYVM (Mailer R2.01) id 3865;
#           Fri, 02 Dec 88 11:11:13 EDT
# From: MAILER-DAEMON@FRLRI61.BITNET
# Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100
# Date: Fri, 2 Dec 88 16:58:16 +0100
# Subject: Returned mail: User unknown
# Message-Id: <8812021558.AB17631@sun1.lri.fr>
# To: mailer@cunyvm
# 
#    ----- Transcript of session follows -----
# Connected to sun8:
# >># RCPT To:<stephane@sun8>
# <<< 550 <stephane@sun8>... User unknown
# 550 stephane... User unknown
# 
#    ----- Unsent message follows -----
# Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100
# Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 3726; Fri,
#  02 Dec 88 10:58:29 EDT
# Received: from ATHENA by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02
#  Dec 88 10:54:50 EDT
# Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28643; Fri, 2 Dec 88 10:54:29 EST
# From: <mbl@ATHENA.MIT.EDU>
# Received: by HAWAII.MIT.EDU (5.45/4.7) id AA06057; Fri, 2 Dec 88 10:54:15 EST
# Message-Id: <8812021554.AA06057@HAWAII.MIT.EDU>
# To: stephane%frlri61.bitnet@cunyvm.cuny.edu
# Date: Fri, 02 Dec 88 10:54:11 EST
# 

Newsgroups: comp.mail.headers,comp.mail.sendmail
Subject: Validity check failed - help needed
Expires: 
References: 
Sender: 
Reply-To: rd@lri.UUCP ()
Followup-To: 
Distribution: world
Organization: LRI - Orsay. France.
Keywords: 

Some gateways refuse to forward some messages issued by our site. This
problem affects mostly BSMTP error messages. In the following example, some
user at MIT.EDU sent a message to some user at our site (FRLRI61.BITNET).
The local user name was wrong, so our mailer generated an error message back
to the sender, an this message was rejected by CUNYVM.

Could someone tell me why ? How does a gateway check the validity
of some message ?

Thanks a lot in advance.
--
Roland Dirlewanger				E-mail: rd@lri.fr
Universite Paris Sud					rd@lri.UUCP
Laboratoire de Recherche en Informatique		rd@FRLRI61.BITNET
Batiment 490					Phone: +33 (1) 69 41 64 01
91405 Orsay Cedex

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

Here is the example:

# Your mail was not delivered to some or all of its
# intended recipients for the following reason(s):
# 
# Validity check failed.
# 
# --------------------RETURNED MAIL FILE--------------------
# Received: from FRLRI61(MAILER) by CUNYVM (Mailer R2.01) id 3865;
#           Fri, 02 Dec 88 11:11:13 EDT
# From: MAILER-DAEMON@FRLRI61.BITNET
# Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100
# Date: Fri, 2 Dec 88 16:58:16 +0100
# Subject: Returned mail: User unknown
# Message-Id: <8812021558.AB17631@sun1.lri.fr>
# To: mailer@cunyvm
# 
#    ----- Transcript of session follows -----
# Connected to sun8:
# >># RCPT To:<stephane@sun8>
# <<< 550 <stephane@sun8>... User unknown
# 550 stephane... User unknown
# 
#    ----- Unsent message follows -----
# Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100
# Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 3726; Fri,
#  02 Dec 88 10:58:29 EDT
# Received: from ATHENA by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02
#  Dec 88 10:54:50 EDT
# Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28643; Fri, 2 Dec 88 10:54:29 EST
# From: <mbl@ATHENA.MIT.EDU>
# Received: by HAWAII.MIT.EDU (5.45/4.7) id AA06057; Fri, 2 Dec 88 10:54:15 EST
# Message-Id: <8812021554.AA06057@HAWAII.MIT.EDU>
# To: stephane%frlri61.bitnet@cunyvm.cuny.edu
# Date: Fri, 02 Dec 88 10:54:11 EST
# 

Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU  7 Dec 88 15:30:21 EST
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.60+/IDA-1.2.5) id AA11512; Wed, 7 Dec 88 14:30:26 CST
Message-Id: <8812072030.AA11512@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 0441; Wed, 07 Dec 88 13:35:33 CST
Date:         Wed, 07 Dec 88 13:22:54 CST
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      mail analogies
To: Header People <header-people@MC.LCS.MIT.EDU>

The analogy of electronic mail to paper mail is a useful one.  That model
can provide a powerful base upon which to build an excellent mail system.

THE FACT IS, IT JUST ISN'T USED.

Every time my paper mail passes through a different postal delivery facility,
it is NOT opened, NOR does some postal clerk write ON MY LETTER what postal
facility processed this.  I'm talking about "Received:".  On occaision, the
post office misdelivers the mail and it is usually detected at the post
office of the wrong location.  They often stamp the mail and send it on its
way to the proper destination.  When I have mail forwarded, an address label
is added.

ALL THIS HAPPENS ON THE ENVELOPE.

I GET THE ENVELOPE AND CAN READ IT ALL.

In electronic mail as per RFC821/822, this is not the model actually used.
RFC821 (the envelope) does not provide for very many things to be written on
the envelope.  In practice, the electronic mailman also opens my mail for me
(although he claims he doesn't read the text) and destroys the envelope.

I don't know anything about X.400.  Does it use this model?  Until the
standards for X.400 are public domain and available over the net, I doubt
I will ever know.

Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU  7 Dec 88 23:41:01 EST
Received: from uunet.UU.NET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Wed, 07 Dec 88 23:41:09 EDT
Received: from watmath.UUCP by uunet.UU.NET (5.59/1.14) with UUCP 
    id AA24714; Wed, 7 Dec 88 23:40:56 EST
Received: from looking.uucp by watmath; Tue, 6 Dec 88 17:02:49 EST
Received: by looking.UUCP (smail2.5)
    id AA11830; 6 Dec 88 16:54:40 EST (Tue)
To: HEADER-PEOPLE%MC.LCS.MIT.EDU@CUNYVM.CUNY.EDU
Date: Tue, 6 Dec 88 16:54:39 EST
Subject: Re: I would like to see a header Sender-Addressed-To:
In-Reply-To: Message from "Leonard D Woren" of Oct 25, 88 at 11:09 pm
X-Mailer: Elm [version 1.5]
Message-Id: <8812061654.AA11830@looking.UUCP>
From: watmath!looking!funny@uunet.UU.NET (Funny Guy)

Why not.

Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU  8 Dec 88 02:28:27 EST
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.60+/IDA-1.2.5) id AA00809; Thu, 8 Dec 88 01:27:21 CST
Message-Id: <8812080727.AA00809@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 8704; Thu, 08 Dec 88 01:17:43 CST
Date:         Thu, 08 Dec 88 01:07:50 CST
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      Re: Validity check failed - What is it ?
To: Roland Dirlewanger <rd%lri%crcge1%inria%mcvax@uunet.uu.net>
Cc: Header People <header-people@MC.LCS.MIT.EDU>
In-Reply-To:  Your message of 5 Dec 88 10:28:48 GMT

The mailer used on most BITNET VM/CMS hosts checks to be sure that the
mail FILE originates from the same place that the RFC822 headers CLAIM
that it originates.  Based on the assumptions that the FILE origin is
secure (not so, but more so that RFC822 headers) these are supposed to
match.  The FILE origin can match FROM: or SENDER: or some others.

Alternatively, if the FILE originates from a known mailer (know to send
mail in BSMTP format FILES) then such a mailer's file is acceptable no
matter what the headers say.  It is assumed the other mailer validated it.

As postmaster for UIUCVMD.BITNET (=VMD.CSO.UIUC.EDU) I occaisionally see
mail being rejected by our mailer just because some new bitnet node started
sending mail from a mailer before the table that tells it what other mailers
there are is updated to include the new one.  In fact, just today I got
one of these.  I manually checked the table to see if it was known and it
was NOT.  Since someone from that node asked me about it, I responded to
them telling them that their mailer was not known and no database entry
existed for it.

Whenever you get the validity check, see which BITNET node rejected the
mail.  The look at the Received: headers and see which BITNET node passed
that mail on just before.  The latter was unknown to the former.

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU  8 Dec 88 09:14:32 EST
Received: by INFOODS id <00000F43061@INFOODS.MIT.EDU> ;
       Thu,  8 Dec 88 09:08:46 EST
Date: Thu,  8 Dec 88 08:38:22 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re;  Sender-addressed-to
To: watmath!looking!funny@UUNET.UU.NET
X-VMS-Mail-To: EXOS%"watmath!looking!funny@uunet.UU.NET"
Message-ID: <881208083822.00000F43061@INFOODS.MIT.EDU>
cc: Header-People@MC.LCS.MIT.EDU

> From:	watmath!looking!funny@uunet.UU.NET
> Why not.

Because every single one of these do-it-yourself, not-incorporated-into-
RFC822, poorly-documented-as-to-exactly-how-it-is-to-be-used, and 
supported-by-somewhere-between-25%-and-75%-of-hosts-and-mailers header 
fields...
 a) Adds confusion.
 b) Interferes with the proper operation of UAs that really try to 
validate headers and handle them in a consistent way.
 c) Considerably increases the network bandwidth needed to carry a 
trivial message and the amount of spare disk space someone needs to be 
prepared to receive e-mail.

On this last point, consider the number of characters of headers, etc.,
needed now to transport the message body "why not.".  And this message 
spared us both the common collection of clever "headers" (latitude, 
longitude, mothers-name, complaints-if-you-dont-like-my-headers,...), and 
the umpty-line "footers" that draw maps of states, etc.

   I don't think RFC822 is adequate for the ways in which mail is being 
used today, don't think that the relationship between 821 and 822 is 
quite right, don't think that the issues of using 822 for non-Internet 
MTAs (i.e., without 821) have ever been worked out well, and have a few
other problems as well.  But "let's add another header to try to paper 
over the problem" is not a solution.  A project to rebuild and redefine 
821 and 822, fix the definitions of fields so that their intent and uses 
was completely clear, and produce new RFCs, might be a good idea.  But, 
practically, that has already been undertaken, and it is called X.400 
and MOTIS (in CCITT and ISO, respectively).

  John Klensin, MIT
  Klensin@INFOODS.MIT.EDU


Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU  8 Dec 88 10:14:19 EST
Received: by INFOODS id <00000F43063@INFOODS.MIT.EDU> ;
       Thu,  8 Dec 88 09:40:58 EST
Date: Thu,  8 Dec 88 09:15:47 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re: mail analogies
To: header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"header-people@MC.LCS.MIT.EDU"
Message-ID: <881208091547.00000F43063@INFOODS.MIT.EDU>

Philip Howard suggests that no one has implemented e-mail the way paper
mail works.  I partially disagree.

Let's keep in mind that any of these analogies, like most of the other 
analogies in the world, will break down if pushed long enough or hard 
enough, so I will give up, rather than quibble.

Making the analogy "work" depends in part on a careful drawing of the
boundaries between user mail software, UA, and MTA.  There was a good
explanation of this distinction on this list many months ago that I
won't try to reproduce.  The rest depends on realizing that RFC821/822 
were designed, to some degree, around models of office/professional 
mail, not personal letters.  Now, with those comments as background...

  I don't know how things work in Illinois, but when the MIT person who 
delivers mail to my office delivers it, he drops it in a pile in front 
of my secretary.  He has not opened any envelopes, and he and his 
predecessors have annotated them only if there is a problem.  Typically, 
any problem severe enough to require envelope annotation results in
returning the mail to the sender, not delivering it, annotated, to me. 
So far my system is just like the one Phil described, considering the 
Post Office and that delivery person as the MTA process.  That is what 
they do, and MTAs deal with envelopes.
  Now, my secretary OPENS THE ENVELOPES, whips out a rubber stamp, and 
affixes "received" and a date to the TOP OF THE LETTER.  If the letter 
or package arrives in a non-standard way, or is otherwise peculiar, she 
may add additional annotation.  She may even ignore the specific person 
addressed on the envelope, attach a routing slip with multiple names on 
it, and circulate the mail internally.  The envelope may be discarded in 
this process, or its information content (postmark date, return address, 
and any annotations) may be attached to the message text (typically 
using a high-tech device called a paper clip).  She is acting as my 
agent in doing this, and header-filtering, non-transport header 
rewriting, and rerouting based on headers (rather than on envelopes) is 
a User Agent function.
  Now, I get the message, and I do onto it whatever I do onto messages.  
If an answer is to go out on paper, I may scribble out (possibly on the 
computer) the message text and the name of the person the letter is to 
go to.  That text then goes back to my user agent who:
 a) constructs complete headers (i.e., puts the thing on letterhead and 
attaches the internal and external addresses).
 b) constructs an envelope, puts addresses on it and the letter in it. 
and
 c) hands the envelope off to the mail transfer system.

Finally, if something enters the transport system with our address, but 
that is not for anyone in our office, it can be intercepted and rejected 
either by the transport system (MIT's mailroom personnel) or when it 
gets to us.  In either case, the envelope (!) is annotated and returned 
to the person listed as a "return address" on the envelope.  If one of 
these comes back to us that we've sent someone else, the envelope is 
opened, the "received" stamp goes on the letter body, and the letter 
body is annotated (typically by a clipped-on part of the envelope that 
contains the rejection notice) to indicate that someone should deal with 
the bad address.  That task is routed, by the UA, not by the MTA or the 
rejecting node, to the right person to straighten out bad mailing list 
entries (who is often not the message author and, in offices larger than 
ours, may not be the sender, either).


Received: from NNSC.NSF.NET (TCP 20026200662) by MC.LCS.MIT.EDU  8 Dec 88 14:07:30 EST
To: header-people@mc.lcs.mit.edu
Subject: RFC 821/822 standards
Date: Thu, 08 Dec 88 14:06:41 -0500
From: Craig Partridge <craig@NNSC.NSF.NET>


Hi folks:

    Given the recent life (or flames) on this list I thought folks might
like an advance look at the upcoming Host Requirements text on using
SMTP with RFC 822.  (For those who don't know, the Host Requirements document
is a sort of profile of what a TCP/IP Host should look like -- a careful
walk through the RFCs and varying interpretations).

    Flames/coments to me, I'll pass them on to the working group.

Craig
craig@bbn.com or craig@nnsc.nsf.net




   5.1  ELECTRONIC MAIL -- SMTP and RFC-822

      5.1.1  INTRODUCTION

         In the TCP/IP protocol suite, electronic mail is exchanged
         using the Simple Mail Transfer Protocol (SMTP) in the format
         specified by RFC-822 [5.1:2].  SMTP is defined in RFC-821
         [5.1:1].

         Over the years, while SMTP has remained unchanged, the Internet
         community has made several changes in the way SMTP is used.  In
         particular, changes in address formats and the way mail is
         routed have both been affected by the conversion to domain
         names.

         RFC-822 specifies the Internet standard format for electronic
         mail messages.  Since this format is logically independent of
         the protocol used to transfer the message, RFC-822 is also used
         in some non-Internet mail environments (e.g., BITNET and CSNET)
         that use different mail transfer protocols than SMTP.

         RFC-822 supercedes an older standard, RFC-733, that may still
         be in use in a few places, although it is obsolete.  The two
         formats are sometimes referred to simply by number (822 and
         733).






Internet Engineering Task Force                                [Page 98]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


      5.1.2  PROTOCOL WALK-THROUGH

         This section covers both RFC-821 and RFC-822.

         The SMTP specification in RFC-821 is clear and contains
         numerous examples, so implementors should not find it difficult
         to understand.  This section simply updates or annotates
         portions of RFC-821 to conform with current usage.  RFC-822 is
         a long and dense document, defining a rich syntax.
         Unfortunately, incomplete or defective implementations of RFC-
         822 are common, although nearly all of the many formats are
         actually used, so that a conforming implementation must
         recognize and interpret them properly.

         The reader should be aware that there are errors in the BNF
         grammar within the text of RFC-822.  Use the BNF summary on the
         last two pages, which is correct.

         5.1.2.1  The SMTP Model: RFC-821 Section 2

            Mail is sent by a series of request/response transactions
            between a client, the "sender-SMTP," and a server, the
            "receiver-SMTP."  These transactions pass (1) the message
            proper, which is composed of header and body, and (2) SMTP
            source and destination addresses, referred to as the
            "envelope."

            In the Internet model for electronic mail, the local file
            system is used for communication between the SMTP programs
            that perform inter-host message transfers and the user agent
            (UA) programs with which users read and compose mail.  Thus,
            the receiver-SMTP is assumed to deliver a message to the
            target user specified in the envelope by writing the message
            into a file; for example, it might simply append the message
            to the user's "mail file."  The user will subsequently read
            the mail from this file by running a UA program.  Similarly,
            to originate mail the user creates a file using the UA
            program, which passes that file to the sender-SMTP for
            transmission.

            The envelope is constructed at the originating site,
            typically when the message is first queued for transmission
            by the sender-SMTP program.  The envelope addresses may be
            derived from information in the message header, or supplied
            by the user interface (e.g., to implement a bcc: request),
            or derived from local configuration information (e.g.,
            expansion of a mailing list.)  The SMTP envelope cannot in
            general be re-derived from the header at a later hop in the



Internet Engineering Task Force                                [Page 99]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            message transmission path, so the envelope is transmitted
            separately from the message itself using the MAIL and RCPT
            commands of SMTP.

            The text of RFC-821 suggests that mail is to be delivered to
            an individual user at a host.  With the advent of the domain
            system and of mail routing using mail-exchange (MX) resource
            records, implementors should now think of delivering to a
            user at a domain, which may or may not be a particular host.
            This DOES NOT change the fact that SMTP is a host-to-host
            mail exchange protocol, and it has no important effect on
            the correctness of the SMTP model.

         5.1.2.2  Canonicalization: RFC-821 Section 3.1

            The domain names that a Sender-SMTP sends in MAIL and RCPT
            commands must have been  "canonicalized," i.e., converted to
            the fully-qualified principal names.  These must either name
            hosts directly or be resolvable into host names using MX
            records.

         5.1.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3

            A receiver-SMTP must implement VRFY and should implement
            EXPN.  However, it should be possible to disable EXPN in a
            particular installation, perhaps even selectively by list.

            DISCUSSION:
                 SMTP users and administrators make regular use of these
                 commands for diagnosing mail delivery problems.

                 EXPN is controversial: it is useful for diagnosing mail
                 loops, but some feel that it represents a significant
                 privacy and perhaps even a security exposure.

         5.1.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4

            The commands to send to a user's terminal (SEND, SOML, and
            SAML) have never been implemented in most mail systems, and
            these commands are not generally considered useful in the
            current Internet environment.

         5.1.2.5  HELO Command: RFC-821 Section 3.5

            The <domain> parameter to a HELO command must be a valid
            host domain name for the host containing the client SMTP; MX
            resolution must not be required.




Internet Engineering Task Force                               [Page 100]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            A host may verify that this parameter really corresponds to
            the IP address of the sender. However, the receiver must not
            refuse to accept a message, even if the sender's HELO
            command fails verification.  A recommended procedure is to
            insert a note about the unknown authenticity of the sender
            into the message header (e.g., in the "Received:"  line).

            DISCUSSION:                                                   |
                 Note that verifying the HELO parameter requires a        |
                 domain name lookup and may therefore take considerable   |
                 time.  An alternative tool for tracking bogus mail       |
                 sources is suggested below (see "DATA Command".)         |

         5.1.2.6  Mail Relaying: RFC-821 Section 3.6

            SMTP supports the relaying of mail and requires that a
            return path be constructed in the envelope as the message
            and envelope are passed along from relay to relay.
            Specifically, a mail relay host must add a source route to
            the SMTP return path within the envelope of each message as
            it is forwarded.  For example, if a message sent from
            user@domain passes through relays X.relay and Y.relay before
            reaching the final destination, the return path in the
            envelope will be:

               @Y.relay,@X.relay:user@domain.

            The relay must add an appropriate "Received:" line to the
            header of a message that it forwards, but it should not
            alter any other header field.

            We distinguish a mail "relay," which forwards a message
            within the SMTP mail environment, from a mail "gateway,"
            which passes a message between the SMTP environment and a
            different environment -- e.g., CSNET or BITNET.)  The
            alternate destinations described by a set of MX records
            might list a set of SMTP mail relays within the Internet
            that have agreed to accept mail destined for a particular
            domain name, or they might point to a mail gateway between
            two heterogeneous mail environments.

            The rules for mail gateways are discussed in Section
            5.1.3.7.

         5.1.2.7  RCPT Command: RFC-821 Section 4.1.1

            A host that supports a receiver-SMTP must support the
            reserved mailbox "Postmaster".



Internet Engineering Task Force                               [Page 101]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            The receiver-SMTP must process RCPT commands as they arrive,
            rather than after the DATA command has transferred the
            message.  RCPT failures will then be reflected in RCPT
            responses, not deferred until after message transfer.  RCPT
            responses must not be delayed beyond a reasonable timeout
            (see Section 5.1.3.2.)  For example, if a soft domain system
            error prevents immediate verification of an RCPT address,
            validity must be assumed.

            However, the expansion of a mailing list in a RCPT command
            should be deferred until after the message has been accepted
            from the sender-SMTP.

            DISCUSSION:
                 Expanding a large mailing list may take a very long
                 time.  If expansion were not deferred, it would hold up
                 SMTP transactions and perhaps cause spurious timeouts
                 (see Section 5.1.3.2).

         5.1.2.8  DATA Command: RFC-821 Section 4.1.1                     |

            It is recommended that the receiver-SMTP supply a             |
            "Received:" line that contains both (1) the name of the       |
            source host as presented in the HELO command and (2) a        |
            domain literal containing the IP address of the source,       |
            determined from the TCP connection.                           |

            DISCUSSION:                                                   |
                 This may provide enough information for tracking         |
                 illicit mail sources, without the overhead of verifying  |
                 the HELO information.                                    |

         5.1.2.9  SMTP Replies:  RFC-821 Section 4.2                      |

            A new reply code is defined for the VRFY command:             |

                 252 Cannot VRFY user (e.g., info is not local), but      |
                 will take message for this user and attempt delivery.    |

            A receiver-SMTP must send only the reply codes listed in      |
            section 4.2.2 of RFC-821 or in this document.                 |

            A sender-SMTP must be able to recognize any legal reply
            code, i.e., code that conforms to Appendix E.

            A sender-SMTP must determine its actions only by the reply
            code, not by the text; any text, including no text at all,
            must be acceptable (except for 251 and 551 replies).



Internet Engineering Task Force                               [Page 102]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            However, it is recommended that a receiver-SMTP use the text
            shown in examples in RFC-821, whenever appropriate.

            DISCUSSION:
                 Interoperability problems have arisen with SMTP systems
                 using reply codes that are not listed explicitly in
                 RFC-821 Section 4.3 but are legal according to the
                 theory of reply codes explained in Appendix E of that
                 document.

                 The space (blank) following the reply code is
                 considered part of the text.

         5.1.2.10  Transparency: RFC-821 Section 4.5.2

            Implementors must be sure that their mail systems always add
            and delete periods to ensure message transparency.

         5.1.2.11  WKS Use in MX Processing: RFC-974, p. 5

            RFC-974 [5.1:3] recommended that the domain system be
            queried for WKS records, to verify that each proposed mail
            target does support SMTP.  Later experience has shown that
            WKS is not widely supported, so the WKS step in MX
            processing is no longer recommended.

         The following are notes on RFC-822, organized by section of
         that document.

         5.1.2.12  RFC-822 Time Zones: RFC-822 Section 5

            The military time zones are incorrect: they count the wrong
            way from UT (the signs are reversed).

            There is a strong trend towards the use of numeric timezone
            indicators, and implementations should use numeric timezones
            instead of timezone names.  However, all implementations
            must accept either notation.

         5.1.2.13  RFC-822 Syntax Errors: RFC-822 Section 6.1

            Errors in formatting or parsing 822 addresses are
            unfortunately common.  This section mentions only the most
            common errors.  A user agent must accept all valid RFC-822
            address formats, and should never generate an illegal
            address syntax.

            Many systems erroneously use a route-addr, an address



Internet Engineering Task Force                               [Page 103]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            specification within angle brackets such as
            <craig@nnsc.nsf.net>, without a leading phrase.  Of the
            following examples:

                From: "Craig Partridge" <craig@nnsc.nsf.net>

                From: <craig@nnsc.nsf.net>

            the first "From:" field is legal, but the second is not.

            Another common error is to leave out the semicolon after a
            group identifier.

            Many systems fail to fully-qualify domain names in messages
            they send out.  Headers with illegal "From:" fields like:

                From: user@cs

            instead of:

                From: user@cs.myuniversity.edu

            are unfortunately common.

            Finally, many systems mis-parse multiple source routes such
            as:

                @relay1,@relay2,@relay3:user@domain.

            Therefore, it is recommended that this form not be used. The
            following alternative notation is accepted by many mail
            systems:

                user%domain%relay3%relay2@relay1

         5.1.2.14  Domain Literals: RFC-822 Section 6.2.3

            An Internet mailer must be able to accept and parse a domain
            literal whose contents ("dtext") are a dotted-decimal host
            address.  This satisfies the requirement of Section 5.0.1
            for the case of mail.

      5.1.3  SPECIFIC ISSUES

         5.1.3.1  SMTP Queueing Strategies

            The common structure of a host SMTP implementation includes
            user mailboxes, one or more areas for queueing messages in



Internet Engineering Task Force                               [Page 104]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            transit, and one or more daemon processes for sending and
            receiving mail.  The exact structure will vary depending on
            the needs of the users on the host and the number and size
            of mailing lists supported by the host.  We describe several
            optimizations that have proved helpful, particularly for
            mailers supporting high traffic levels.

            Any queueing strategy must include:

            o    Timeouts on all activities.  See Section 5.1.3.2.

            o    Never sending error messages in response to error
                 messages.


            5.1.3.1.1 Sending Strategy

               The general model of the sender-SMTP is one or more
               processes that periodically attempt to transmit outgoing
               mail.  In a typical system, the program that composes a
               message has some method for requesting immediate
               attention for a new piece of outgoing mail, while mail
               that cannot be transmitted immediately must be queued and
               periodically retried by the sender.  A mail queue entry
               will include not only the message itself but also the
               envelope information.

               Retries continue until the message is transmitted or the
               sender gives up; the give-up time should be at least 4-5
               days.  The parameters to the retry algorithm must be
               configurable.

               When the same message is to be delivered to several users
               on the same host, only one copy of the message should be
               transmitted. That is, the sender-SMTP the sender should
               use the command sequence: RCPT, RCPT,... RCPT, DATA
               instead of the sequence: RCPT, DATA, RCPT, DATA,... RCPT,
               DATA.  Implementation of this efficiency feature is
               strongly recommended.

               The sender must not immediately retry a particular
               destination after one attempt has failed.  In general,
               the retry interval should be at least 30 minutes;
               however, more sophisticated and variable strategies may
               be beneficial when the sending SMTP can determine the
               reason for nondelivery.

               DISCUSSION:



Internet Engineering Task Force                               [Page 105]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


                    Experience suggests that failures are typically
                    transient (the target system has crashed), favoring
                    a policy of two connection attempts in the first
                    hour the message is in the queue, and then backing
                    off to once every two or three hours.

                    The sender-SMTP can shorten the queueing delay by
                    cooperation with the receiver-SMTP.  In particular,
                    if mail is received from a particular address, it is
                    good evidence that any mail queued to send to that
                    host can now be sent.

                    The strategy may be further modified as a result of
                    multiple addresses per host (see Section 5.1.3.4),
                    to optimize delivery time vs. resource usage.

               A sender should keep a list of hosts it cannot reach and
               corresponding timeouts, rather than just retrying queued
               mail items.

               DISCUSSION:
                    A sender-SMTP may have a large queue of messages for
                    each unavailable destination host, and if it retried
                    all these messages in every retry cycle, there would
                    be excessive Internet overhead and the daemon would
                    be blocked for a long period.  Note that an SMTP can
                    generally determine that a delivery attempt has
                    failed only after a timeout of a minute or more; a
                    one minute timeout per connection will result in a
                    very large delay if it is repeated for dozens or
                    even hundreds of queued messages.

               Similarly, the sender-SMTP may support multiple
               concurrent outgoing mail transactions to achieve timely
               delivery.  However, some limit should be imposed to
               protect the host from devoting all its resources to mail.

               The use of the different addresses of a multihomed host
               is discussed below.

            5.1.3.1.2  Receiving strategy

               The receiver-SMTP should attempt to keep a pending listen
               on the SMTP port at all times.  This will require the
               support of multiple incoming TCP connections for SMTP.
               Some limit may be necessary.

               When the receiver-SMTP receives mail from a particular



Internet Engineering Task Force                               [Page 106]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


               host address, it may notify the sender-SMTP to retry any
               mail pending for that host address.

         5.1.3.2  Timeouts in SMTP

            Timeouts are an essential feature of an SMTP implementation.
            If the timeouts are too long (or worse, there are no
            timeouts), Internet communication failures or software bugs
            in receiver-SMTP programs can tie up senders indefinitely.
            If the timeouts are too short, resources will be wasted with
            attempts that time out part way through message delivery.

            There are two approaches to timeouts in the sender-SMTP:
            (a) limit the time for each SMTP command separately, or (b)
            limit the time for the entire SMTP dialogue for a single
            mail message.  Option (a), per-command timeouts, should be
            used.

            DISCUSSION:
                 If option (b) is used, the timeout has to be very
                 large, e.g., an hour, or else it must be a linear
                 function of the size of the message being transmitted.
                 A large fixed timeout leads to two problems: a failure
                 can still tie up the sender for a very long time, and
                 very large messages may still spuriously time out
                 (which is a wasteful failure!).  If proportional timing
                 is chosen, it is difficult to determine the
                 proportionality constant.

                 Using the recommended option (a), a timer is set for
                 each SMTP command and for each buffer of the data
                 transfer.  The latter means that the overall timeout is
                 inherently proportional to the size of the message.

            Certain steps in the SMTP dialog may encounter significant
            delays at the receiver caused by looking up host names,
            expanding mailing lists, local file system operations, etc.
            We now present some specific recommendations for per-command
            timeouts, based on extensive experience with busy mail-relay
            hosts

            o    Initial 220 Message

                 A Sender-SMTP process must distinguish between a failed
                 TCP connection and a delay in receiving the initial 220
                 greeting message. Many receiver-SMTPs will accept a TCP
                 connection but delay delivery of the 220 message until
                 their system load will permit more mail to be



Internet Engineering Task Force                               [Page 107]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


                 processed.  Senders should wait at least 5 minutes for
                 the 220 message after the TCP connection is opened.

            o    MAIL Command

                 Senders should wait at least 5 minutes for the reply to
                 a MAIL command.

            o    RCPT Command

                 Senders should wait at least 5 minutes for the reply to
                 a RCPT command.  (A longer timeout would be required if
                 processing of mailing lists were not deferred until
                 after the message was accepted).

            o    DATA Initiation

                 Senders should wait at least 2 minutes for the "354
                 Start Input" reply to a DATA command.

            o    Data Block

                 Senders should wait at least 3 minutes for the
                 acknowledgment of each chunk of transmitted data.

            o    DATA Termination

                 When the receiver gets the final period terminating the
                 message data, it typically performs processing to
                 deliver the message to a user mailbox. A spurious
                 timeout at this point would be very wasteful, since the
                 message has been successfully sent.

                 Senders should wait at least 10 minutes for the "250
                 OK" reply.


            A receiver-SMTP should have a timeout of at least 5 minutes
            while it is awaiting the next command from the sender.

         5.1.3.3  Reliable Mail Receipt

            When the receiver-SMTP accepts a piece of mail (by sending a
            "250 OK" message), it is accepting responsibility for
            delivering or relaying the message.  It should take this
            responsibility seriously and not lose the message for
            frivolous reasons, e.g., because the host later crashes or
            because of a predictable resource shortage.  To the extent



Internet Engineering Task Force                               [Page 108]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            possible, the receiver-SMTP should detect conditions that
            will preclude delivery to individual recipients and generate
            appropriate error replies to the respective RCPT commands.

            However, some delivery failures may be unavoidable.  For
            example, it may be impossible for the receiver-SMTP to
            validate all the delivery addresses before accepting the
            message; this may happen, for example, because of a soft
            domain system error or because the target is a mailing list
            (see earlier discussion of RCPT.)  If there is a later
            delivery failure, the receiver-SMTP must formulate and send
            error message to the MAIL FROM: address in the envelope (not
            an address in the message header.)  However, if the MAIL
            FROM: address is null, the receiver-SMTP must not send an
            error message.

            A receiver-SMTP must implement some procedure to avoid
            receiving duplicate messages as the result of timeouts.

            DISCUSSION:
                 One problem with all timeout schemes is that they
                 aggravate an SMTP protocol problem that may permit
                 duplicate copies of a message to be delivered.  The
                 problem comes when the SMTP receiver waits a long time
                 before responding to the final "." that ends a message.
                 Details of the problem and a recommended solution are
                 described in RFC-1047 [5:1.4].

         5.1.3.4  Reliable Mail Transmission

            To transmit a message, a sender-SMTP will determine the IP
            address of the target host from the destination address in
            the envelope.  Specifically, it will map the string to the
            right of the "@" sign into an IP address.  This mapping or
            the transfer itself may fail with a soft error (see Section
            6.1.2.3), so a sender-SMTP must be able to requeue outgoing
            mail when soft errors are encountered and move on to other
            requests.

            When it succeeds, the mapping can result in a list of
            alternative delivery addresses rather than a single address,
            because of (a) multihoming or (b) multiple MX records (see
            Section 6.1 below) or both.  To provide reliable
            transmission of mail, the sender-SMTP must be able to rank
            such a list of IP addresses and to try (and retry) each of
            the addresses in this list until a delivery attempt
            succeeds.  However, there should also be a configurable
            limit on the number of alternate addresses that can be



Internet Engineering Task Force                               [Page 109]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            tried.

            The following information should be used to rank the host
            addresses:

            (1)  Multiple MX Records -- these contain a preference
                 indication that should be used in sorting the IP
                 addresses.  If there are multiple destinations with the
                 same preference and there is no clear reason to favor
                 one (e.g., by address preference), then the SMTP sender
                 should pick one at random to spread the load across
                 multiple mail exchanges for a specific organization;
                 note that this is a refinement of the procedure in
                 [6.1:3].

            (2)  Multihomed host -- For a multihomed target host, the
                 domain name resolver will return a list of alternative
                 IP addresses.  It is the responsibility of the domain
                 name resolver interface (see Section 6.1.3.3 below) to
                 have ordered this list by decreasing preference.  SMTP
                 must try them in the order presented.


            DISCUSSION:
                 Although the capability to try multiple alternative
                 addresses is required, there may be circumstances where
                 specific installations want to limit or disable the use
                 of alternative addresses.  The subject of whether a
                 sender should attempt retries using the different
                 addresses of a multihomed host has been controversial.
                 The main argument for using the multiple addresses is
                 that it maximizes the probability of timely delivery,
                 and indeed sometimes the probability of any delivery;
                 the counterargument is that it may result in
                 unnecessary resource use.

                 Note that the resource usage is strongly determined
                 also by the sending strategy discussed in Section
                 5.1.3.1.

         5.1.3.5  Domain Name Support

            SMTP implementations must use the mechanism defined in
            Section 6.1 for mapping between domain names and IP
            addresses.  This means that every SMTP must include support
            for the domain name system.

            In particular, a sender-SMTP must support the MX record



Internet Engineering Task Force                               [Page 110]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


            scheme [5.1:3].  See also Section 7.4 of [6.1:2] for
            information on domain name support for SMTP.

         5.1.3.6  Mailing Lists and Aliases

            An SMTP-capable host should support both the alias and the
            list form of address expansion for multiple delivery.

            DISCUSSION:
                 An important mail facility is a mechanism for
                 transforming or "expanding" a pseudo-mailbox address
                 into a list of addresses to obtain multiple delivery of
                 a single message.  When a message is sent to such a
                 pseudo-mailbox (sometimes called an "exploder"), copies
                 are forwarded or redistributed to each mailbox in the
                 expanded list.  We rclassify such a pseudo-mailbox as
                 an "alias" or a "list", depending upon the expansion
                 rules:


                 (a)  Alias

                      To expand an alias, the recipient mailer simply
                      replaces the pseudo-mailbox address in the
                      envelope with each of the expanded addresses in
                      turn; the envelope and the message body are left
                      unchanged.  The message is then delivered or
                      forwarded to each expanded address.


                 (b)  List

                      To expand a list, the recipient mailer again
                      replaces the pseudo-mailbox address in the
                      envelope with each of the expanded addresses in
                      turn.  However, when the message is delivered or
                      forwarded to each expanded address, the return
                      address in the envelope is also changed to be the
                      address of a person who administers the list.  The
                      message body is left unchanged and in particular,
                      the "From" field of the message is unaffected.

                      The return address in the envelope is changed so
                      that all error messages generated by the final
                      deliveries will be returned to the list
                      administrator, not to the message originator, who
                      generally has no control over the contents of the
                      list and will typically find error messages



Internet Engineering Task Force                               [Page 111]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


                      annoying.

                      The list may be said to operate by
                      "redistribution" rather than "forwarding." A
                      useful conceptual model (not necessarily an
                      implementation approach) is this: a mailing list
                      is a UA function, not an SMTP function. Thus, the
                      message is originally delivered into the mailbox
                      of a UA daemon belonging to the mailing list
                      administrator; this UA daemon remails the message
                      to each entry in the list.


         5.1.3.7  Mail Gatewaying

            Gatewaying mail between different mail environments, i.e.,
            different mail formats and protocols, is complex and does
            not easily yield to standardization.  However, some general
            guidelines may be given for a gateway between the Internet
            and another mail environment:


            o    It is sometimes necessary to rewrite header fields when
                 messages are gatewayed across mail environment
                 boundaries.

                 DISCUSSION:
                      The other mail systems gatewayed to the Internet
                      generally use a subset of RFC-822 headers.
                      However, they do not have an equivalent to the
                      SMTP envelope.  Therefore, when a message leaves
                      the Internet environment, it is generally
                      necessary to fold the SMTP envelope information
                      into the message header.

                      A possible solution would be to create new header
                      fields to carry the envelope information (e.g.,
                      "X-SMTP-MAIL:" and "X-SMTP-RCPT:".) However, this
                      would require changes in mail programs in the
                      foreign environment.


            o    From the Internet side, the gateway must accept all
                 valid address formats in SMTP commands and in RFC-822
                 message fields and all valid RFC-822 messages.

                 DISCUSSION:
                      It is often tempting to restrict the range of



Internet Engineering Task Force                               [Page 112]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


                      addresses accepted at the mail gateway to simplify
                      the translation into addresses for the remote
                      environment.  This practice is based on the
                      assumption that mail users have control over the
                      addresses their mailers send to the mail gateway.
                      In practice, however, users have little control
                      over the addresses that are finally sent; their
                      mailers are free to change addresses into any
                      legal RFC-822 format.


            o    The gateway must ensure that all header fields of a
                 message that it forwards into the Internet meet the
                 requirements for Internet mail.  In particular, all
                 addresses in "From:", "To:", "Cc:, etc., fields must be
                 transformed (if necessary) to satisfy RFC-822 syntax,
                 and they must be effective and useful for sending
                 replies.


            o    The translation algorithm used to convert mail from the
                 Internet protocols to another environment's protocol
                 must ensure that error messages are delivered to the
                 sender listed in the SMTP envelope, not to the sender
                 listed in the "From:" field of the RFC-822 message.

                 DISCUSSION:
                      Internet mail lists usually place the address of
                      the mail list maintainer in the envelope but leave
                      the original message header intact (with the
                      "From:" field containing the original sender).
                      This yields the behavior the average recipient
                      expects: a reply to the header gets sent to the
                      original sender, not to a mail list maintainer;
                      however, errors get sent to the maintainer (who
                      can do something about problem) and not the sender
                      (who probably does not control the list).


         5.1.3.8  Maximum Message Size

            Note that SMTP does not define a maximum size of a message.
            Some systems have a practical limitation as low as 10,000
            bytes, while other systems can comfortably accept a document
            of 300,000 bytes or more in a single message.  Users are
            expected to show good judgment when they send large
            messages.




Internet Engineering Task Force                               [Page 113]




***DRAFT RFC***        APPLICATIONS LAYER -- MAIL      November 11, 1988


      5.1.4 REFERENCES


         [5.1:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821,
              August 1982.


         [5.1:2]  "Standard For The Format of ARPA Internet Text
              Messages," D. Crocker, RFC-822, August 1982.

              This document obsoleted an earlier specification, RFC-733.


         [5.1:3]  "Mail Routing and the Domain System," C. Partridge,
              RFC-974, January 1986.


         [5.1:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
              February 1988.
































Internet Engineering Task Force                               [Page 114]


Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  8 Dec 88 18:53:53 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA24764@BLOOM-BEACON.MIT.EDU>; Thu, 8 Dec 88 18:47:40 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Dec 88 02:02:49 GMT
From: hpda!hpcuhb!hpcilzb!hpcea!marvit@bloom-beacon.mit.edu  (Peter Marvit)
Organization: HP Corporate Engineering - Palo Alto, CA
Subject: Re: Mail header wishlist (was Re: Another example why not to re-route)
Message-Id: <1760002@hpcea.CE.HP.COM>
References: <1320@ksuvax1.cis.ksu.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

To prevent massive repostings to a distribution list, I use the addres form
(described in RFC-822):

	To: NiceName-of-List: real-address@host, address-alias;

I also include a

	From: List-request@myhost

as well as the usual X-Errors-to and anything else I can think of.

The above addressing convention works well for small mailing lists as well
(inside an organization).

	-Peter marvit
 	HP Labs

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 10:39:20 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06992@BLOOM-BEACON.MIT.EDU>; Sat, 10 Dec 88 10:23:59 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Dec 88 01:55:36 GMT
From: mcmi!hdr!unocss!fritz@uunet.uu.net  (Tim Russell)
Organization: U. of Nebraska at Omaha
Subject: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <555@unocss.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Hi all,

    I recently acquired the MM mailer that Columbia has ported to Unix
(it's in beta-test), and discovered a bug, for lack of a better word,
in the Berkeley mail program.

    First off, let me set things up: this is on a Sequent Balance 8000,
running Dynix 2.1.1 (BSD 4.2 and System V.2 together).  I've also tried
this on a Vax 8200 running Ultrix 2.3.

     Here's the deal:  MM sends out messages with "From" headers of the
form:

          From: Real Name <address.domain>

which, I have come to find out, is used as an example throughout RFC822.
The specific they use is "From: George Jones <Jones@Group.Org>".

     When I send a message out from MM to myself, and read and reply to
it, however, Berkeley mail generates an extra, totally wrong, recipient.
Here is a log of the Berkeley mail session (thanks to screen):

--------------------
Mail version 2.18 5/19/83.  Type ? for help.
"/usr/spool/mail/fritz": 1 message 1 new
>N  1 fritz@unocss.unl.edu Thu Dec  8 19:16  10/241 "Test message."
&
Message  1:
From fritz Thu Dec  8 19:16:19 1988
Date: Thu, 8 Dec 1988 19:15:50 CST
From: Tim Russell <fritz@unocss.unl.edu>
To: fritz
Subject: Test message.
Message-Id: <CMM.0.88.597633350.fritz@unocss.unl.edu>
Status: R

This is a test message to demonstrate.


& reply
To: unl:fritz@edu fritz@unocss.unl.edu
Subject: Re:  Test message.

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

Notice the "To" line in the reply above?  This is, as you can see,
nowhere in the original message.  According to RFC822, when an address
of the form "<address>" is included in the header line, everything else
should be ignored and this should be used as the address.

    The Ultrix mailer (fergvax.unl.edu) generated this as the "To"
line under the same circumstances:

        To: fritz@fergvax.unl.edu fritz@fergvax.unl.edu

    Interestingly enough, when I tell MM to put my name in quotes, as in:

          From: "Tim Russell" <fritz@unocss.unl.edu>

neither of the mailers I tried had any problem at all.  Wierdness abounds.
Also, the problem can be fixed by including a "Reply-To" header, not
of the same format, of course.

    People at Columbia tell me they have never had any problem of this kind.

    So, can anyone tell me what could be causing this?  Is this a common
problem?  Does Berkeley know about it?  Has it been fixed?

    Sorry for being so verbose, but I wanted to make the problem clear.
Thanks for any help anyone can give me!

-- 
---------------------------------+--------------------------------------------
 Tim Russell, Computer Operator  | Internet: fritz@fergvax.unl.edu
 Campus Computing                | Bitnet:   russell@unoma1
 University of Nebraska at Omaha | UUCP:     uunet!btni!unocss!fritz

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 15:24:25 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10763@BLOOM-BEACON.MIT.EDU>; Sat, 10 Dec 88 15:16:00 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Dec 88 19:13:58 GMT
From: cs.utexas.edu!execu!dewey@ohio-state.arpa  (Dewey Henize)
Organization: Home for Recalcitrant Hackers
Subject: Help requested setting up smart mailer
Message-Id: <401@execu.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Hello.

With the holiday season coming, I'm going to waste a few hours of my employers
time and attempt to get a 'smart' mail system going.  I am, however, VERY
confused about all this so I'm asking help from those of you that have fought
this battle before, so I don't reinvent the wheel.

Environment:  We have a group of varied machines, including Sun's, Ultrix
based Vaxen, HP's and others.  We are currently running pretty much plain
vanilla senmail, with one Sun handling our UUCP traffic and making mail
look like it all comes from there.  I have aliases set up such that mail
coming into the system gets rerouted to users at the appropriate machines.
We use YP on all the systems because of a very low number of system admin
types (me, mostly) and a large and very often changing number of hosts.

We have an Internet number assiged for us, as execu.com.  So far, management
hasn't approved the finances for a gateway, so we haven't done much else 
along that line till we convince them it's needed.  It'll happen, but the
time frame is <ahem> flexible.  So for now, we have to assume complete
dependence on dialout connections.

Goal:  I'd much like to get our mail setup running a lot smarter.  I have
a copy of smail and pathalias, and for that matter run a set of maps through
pathalias every night.  We manually try to determine paths from this output
but its not exactly a user friendly way to go about things.

I've tried to RTFM but it confuses me.  I end up with more questions at the
end than I do answers.  I keep coming back to the sendmail.cf file and after
a bit it looks like I'm going in circles.

So, is there anyone with a set of papers that you might be able to send that
would help me?  One of the biggest goals is that the nasty paths generated
by replies to usenet articles would be cleaned up and optimized a bit, but
it would also be wonderful if most of my user base could have a simpler, more
obvious method of sending mail than trying to look up the address with our
shell file and then hopefully typing it in correctly.

I'm not looking to aggressively reroute mail passing through.  Seems that
causes more problems than its worth overall.  I WOULD like to reroute the
mail that arrives here and dies because of a bad path, and I would like to
generate addresses (or restructure addresses) from mail and replies that
come from here.

I would guess that anything informative enough to help me would be fairly
long, so please e-mail to me.  I'll keep it all and would be more than willing
to pass it on should others so wish.

Thanks in advance for any and all help.

Dewey Henize
Execucom Systems Corp

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| There is nothing in the above message that can't be explained by sunspots.  |
|                   execu!dewey             Dewey Henize                      |
|         Can you say standard disclaimer?  I knew you could.  Somehow...     |

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 17:39:20 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12813@BLOOM-BEACON.MIT.EDU>; Sat, 10 Dec 88 17:24:30 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Dec 88 07:17:09 GMT
From: killer!jolnet!stephen@eddie.mit.edu  (Stephen Diercouff)
Organization: Jolnet, public access Unix, Orland Park (Joliet) IL
Subject: Re: From line
Message-Id: <53@jolnet.ORPK.IL.US>
References: <52@jolnet.ORPK.IL.US>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu



sorry-my .signature got left off the last posting.
-- 
Stephen Diercouff
uucp: ames!killer!jolnet!mtbaker!stephen
      uw-beaver!tikal!camco!eskimo!mtbaker!stephen
"A nod's as good as a wink to a blind bat." -Monty Python 

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 17:39:29 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12820@BLOOM-BEACON.MIT.EDU>; Sat, 10 Dec 88 17:24:56 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Dec 88 07:13:34 GMT
From: killer!jolnet!stephen@eddie.mit.edu  (Stephen Diercouff)
Organization: Jolnet, public access Unix, Orland Park (Joliet) IL
Subject: From line
Message-Id: <52@jolnet.ORPK.IL.US>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

My mailer inserts the line From ...., which causes no problems, except
with one UUCP link, which uses smail. When my mail arrives there, smail
does not recognise the From line, and inserts its own line--
From: uucp@mtbaker.
My question is, does my mailer have a problem? Should I recompile it,
adding the colon after the From , or is the problem with smail. I know
that recompiling would work, but i'd rather not fix something that's
not broken so it will work with something that is broken.
If you respond to this via e-mail, please use one of the paths below.
Thanks!

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 19:39:36 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA14612@BLOOM-BEACON.MIT.EDU>; Sat, 10 Dec 88 19:24:36 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Dec 88 22:20:16 GMT
From: sco!keithr@uunet.uu.net  (Keith Reynolds)
Organization: The Santa Cruz Operation, Inc.
Subject: "Errors-To:" header (was Re: Mail header wishlist)
Message-Id: <1518@scovert.sco.COM>
References: <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec110041
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Interestingly, karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
	had this to say about "Mail header wishlist":
}
} That would be unnecessary if mailing lists would all make sure that,
} when distributing out to the list's recipients, an Errors-To:
} listname-request@listname-host-machine header were included.  Then
} bounces would go to the admin only, and nowhere else.
} 

"Errors-To:"?  I've just gotten back to this group after a
long time of not having time to read it, and this was the
second posting that hadn't expired, so I imagine this was
proposed as an additional header to add to the next mail
RFC, whenever that comes out.  My question: is this
necessary?  My copy of RFC822 says (section 4.4.4):

	The "Sender" field mailbox should be sent notices of any
	problems in transport or delivery of the original messages.
	If there is no "Sender" field, then the "From" field mailbox
	should be used.

	The "Sender field mailbox should NEVER be used automatically,
	in a recipient's reply message.

So, if the mailing list would put the "request" address in
the "Sender" field, compliant mailers should send bounces to
that, without any standards or software changes (assuming
sendmail/mmdf and other major transports actually obey
this).  The second quoted paragraph indicates that replies
wouldn't (or shouldn't) use this field, so doing this wouldn't
affect the ability to reply to messages sent out by the list
processor.

-- 
Keith Reynolds, Systems Administrator, The Santa Cruz Operation, Inc.

{uunet,ucbvax!ucscc,decvax!microsoft,spl1,sun}!sco!keithr
keithr@sco.COM, @ucscc.UCSC.EDU:keithr@sco.COM, keithr%sco.COM@ucscc.UCSC.EDU

"Though a program be but three lines long,
	someday it will have to be maintained." -- The Tao of Programming

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Dec 88 11:39:53 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15886@BLOOM-BEACON.MIT.EDU>; Mon, 12 Dec 88 11:38:27 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Dec 88 16:17:40 GMT
From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa  (Karl Kleinpaste)
Organization: OSU
Subject: Re: "Errors-To:" header (was Re: Mail header wishlist)
Message-Id: <KARL.88Dec12111740@triceratops.cis.ohio-state.edu>
References: <1320@ksuvax1.cis.ksu.edu>, <KARL.88Dec110041, <1518@scovert.sco.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


   "Errors-To:"?  ...
   So, if the mailing list would put the "request" address in
   the "Sender" field...

Yes, it was pointed out to me (several times!) that Errors-To: is a
sendmail-ism; that'll teach me to put something to use which I see
`documented' somewhere other than in an RFC.

My local generalized mailing list management scheme has been altered
to accommodate the use of *both* Errors-To: (to make sendmails happy)
and Sender:.

--Karl

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Dec 88 13:54:55 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA18013@BLOOM-BEACON.MIT.EDU>; Mon, 12 Dec 88 13:50:23 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Dec 88 17:34:18 GMT
From: emory!arnold@gatech.edu  (Arnold D. Robbins {EUCC})
Organization: Emory University
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <3502@emory.uucp>
References: <555@unocss.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes:
>From fritz Thu Dec  8 19:16:19 1988
>Date: Thu, 8 Dec 1988 19:15:50 CST
>From: Tim Russell <fritz@unocss.unl.edu>
>To: fritz
>Subject: Test message.
>Message-Id: <CMM.0.88.597633350.fritz@unocss.unl.edu>
>Status: R
>
>This is a test message to demonstrate.
>
>& reply
>To: unl:fritz@edu fritz@unocss.unl.edu
>Subject: Re:  Test message.

The problem is that the To: address does not have an "@dom.ain" part.
For reasons I was not able to pin down, both the To: and the From:
address need to be either fully domain'ed or non-domain'ed ("fritz")
but having mixtures produces this problem.

/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically
have already done it, and called the result mailx.  It is interesting to
note that Sun's /usr/ucb/Mail is actually mailx.

The way I fixed things was to have my sendmail always put a domain,
even on mail from users on the same machine to each other.  Mail was
just too hard to fix. Sigh.
-- 
Arnold Robbins -- Emory University Computing Center
DOMAIN:	arnold@unix.cc.emory.edu
UUCP:	{ decvax, gatech, skeeve }!emory!arnold		BITNET:	arnold@emoryu1
PHONE:	+1 404 727-7636		FAX:	+1 404 727-2599

Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 12 Dec 88 15:50:40 EST
Received: from CCRMA-F4 by SAIL.Stanford.EDU with PUP; 12-Dec-88 12:51 PST
Date: 12 Dec 88  1250 PST
From: Tovar <TVR%CCRMA-F4@SAIL.Stanford.EDU>
Subject: Plausible use for "Errors-To:"??  
To:   Header-People@MC.LCS.MIT.EDU    

Those of you who have been on this list a very long time might remember my
arguing against excess verbosity in headers.  I'd say they are now completely
out of hand, and something that should only be shown to the user upon request.
Having said that, i'd like to give an argument (albeit not one that i could
get very excited about) why "Errors-To:" might have legitimate uses.  This is
not to say that the current use of "Errors-to:" is necessary or appropriate.

The combination of From:, To:, Sender:, and Resent-by: and Resent-To:, is
probably sufficient for most purposes, at least in an environment largely
inhabited by computer knowledgable people.  But some folks are better than
others at coping with this, and there have been more than one occasion where
i would like to get mailer errors for specific users, so that i could help
them out, at least to the degree of suggesting an appropriate address or
explaining why they're losing, without having to wait until they've given
up in frustration.  Consider the following scenerio:

Suppose an adminstrator, named Lee for purposes of discussion, has a secretary
named Jan, and suppose Lynn maintains the mail system for a proverbial
organization, say, Widgets, Inc.  Now, Jan is great at dealing with
microcomputer software, but networks are another matter...  So, when Lee asks
Jan to send Smith@Cybermumble a message,  Lynn would like to also "look over
their shoulders" when some sort of mailer error comes back.  So Lynn might
arrange to have the Jan's default header look something like this:

  From: widgets!marketing!lee@SBGTWY.Com
  To: Smith@Cybermumble.Com
  Sender: widgets!marketing!jan@SBGTWY.Com
  Errors-to: widgets!marketing!jan@SBGTWY.Com,widgets!marketing!lynn@SBGTWY.Com

In this case, both people would get the mailer errors, and it is clear who
the messge what from, and who actually sent the message.  Obvious, it would
not have made sense, from a human's standpoint, to have two addresses in
the "Sender:" field, even if other mailers knew what to do about this.
 
If there's some way of getting the same behavior with current setup and still
convey reasonable information, i'd like to hear about it.  Before flaming
at me about this, please remember that i'm very reluctant to have any more
cruft added to the header.  I just thought the argument was at least
interesting.  Note that a mail maintainer might be able to hack things to
always receive the errors (but perhaps not the message text) destined for
certain users, i doubt these can be reliably distinguished from ordinary
traffic.
				-- Tovar


Received: from almsal (TCP 30010712006) by MC.LCS.MIT.EDU 12 Dec 88 16:04:56 EST
Date:     Mon, 12 Dec 88 14:20:25 CST
From:     Bob Savacool <cool@ALMSA-1.ARPA>
To:       header-people@MC.LCS.MIT.EDU
Subject:  Remove me from list

To whom it may concern,

   Please remove me from the header-people mailing list.

   I realy need to shut this off.

Bob Savacool
cool@almsa-1

Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 12 Dec 88 20:49:11 EST
Date: Mon 12 Dec 88 19:47:23-CST
From: David Wallace <AI.GUMBY@MCC.COM>
Subject: Domains on local mail?
To: emory!arnold@gatech.edu
cc: header-people@mc.lcs.mit.edu
In-Reply-To: <3502@emory.uucp>
Message-ID: <12453956700.58.AI.GUMBY@MCC.COM>

    Date: 12 Dec 88 17:34:18 GMT
    From: emory!arnold@gatech.edu  (Arnold D. Robbins {EUCC})

    The way I fixed things was to have my sendmail always put a domain,
    even on mail from users on the same machine to each other.  Mail was
    just too hard to fix. Sigh.

I don't see what's wrong with that.  Let the user's UA worry about
removing domains from local addresses (in fact mine reformats most of
the headers it chooses to present to me).  It's not worth your MTA's
worrying about it.

Also, consider the case where the user FTPs his/her mail file to
another machine and then wants to reply to a message...
-------

Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 12 Dec 88 22:40:21 EST
Received: from garnet.berkeley.edu
	by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l)
	id AA08371; Mon, 12 Dec 88 19:39:25 PST
Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.13)
	id AA13888; Mon, 12 Dec 88 19:39:20 pst
Date: Mon, 12 Dec 88 19:39:20 pst
From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO)
Message-Id: <8812130339.AA13888@garnet.berkeley.edu>
To: fritz@fergvax.unl.edu
Subject: Re:  BSD 4.2 Mail not RFC822-compliant?
Cc: header-people@mc.lcs.mit.edu

Tim,

You are apparently running a very old version of BSD Unix "Mail"
(Mail version 2.18 5/19/83).  Current BSD 4.3 "Mail" is "UCB Mail
Version 5.3 (2/18/88)"

I believe the mail "reply" problem was fixed some years ago.
Check with the vendors (DEC and Sequent Balance) for fixes.
Or upgrade to a BSD 4.3 Unix derived operating system.

Bill Wells
postmaster@jade.berkeley.edu


Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Dec 88 20:36:22 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 13 Dec 88 20:35:43-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA16284@BLOOM-BEACON.MIT.EDU>; Tue, 13 Dec 88 18:14:20 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Dec 88 21:04:29 GMT
From: amdahl!fai!ronc@ames.arpa  (Ronald O. Christian)
Organization: Fujitsu America, Inc.
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <1262@fai.UUCP>
References: <555@unocss.UUCP>, <3502@emory.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>The problem is that the To: address does not have an "@dom.ain" part.
>For reasons I was not able to pin down, both the To: and the From:
>address need to be either fully domain'ed or non-domain'ed ("fritz")
>but having mixtures produces this problem.

I just performed the same experiment (Sequent Symmetry running
Dynix 3.0.something.... 12, I think) and did not see the problem.

>The way I fixed things was to have my sendmail always put a domain,
>even on mail from users on the same machine to each other.

Yeah, I just looked again, and sendmail at our site does exactly
the same thing.  My network administrator is not here right now,
so I can't say what he might have done (if anything) to fix the
problem.  I suspect a minor change to sendmail.cf.

>/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically
>have already done it, and called the result mailx.

The AT&T salesperson pushed mailx really hard as a clean rewrite of berkeley
Mail, but our copy (SysV on a Vax 11/780) dumped core randomly and frequently.
Perhaps they've come out with something since that works?

>It is interesting to
>note that Sun's /usr/ucb/Mail is actually mailx.

With how much work done by Sun??  At least the network stuff must
have been added by Sun -- AT&T has only recently acknowledged the
existance of SMTP mail.


				Ron
-- 

      Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.)
      {amdahl, pyramid, sun, unisoft, uunet}!fai!ronc -or- ronc@fai.com

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Dec 88 21:08:04 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15588@BLOOM-BEACON.MIT.EDU>; Tue, 13 Dec 88 17:36:28 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Dec 88 21:44:42 GMT
From: pasteur!helios.ee.lbl.gov!ace.ee.lbl.gov!leres@ames.arpa  (Craig Leres)
Organization: Lawrence Berkeley Laboratory, Berkeley
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <1463@helios.ee.lbl.gov>
References: <555@unocss.UUCP>, <3502@emory.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

(Followups to ... uh ... gee, so many groups to choose from ... uh ...
comp.mail.headers, yeah, that's the ticket.)

Arnold D. Robbins writes:
> For reasons I was not able to pin down, both the To: and the From:
> address need to be either fully domain'ed or non-domain'ed ("fritz")
> but having mixtures produces this problem.

If the recipient is non-local, then all addresses in the message
(including the sender) must be domainized. Otherwise, the recipient
might have a difficult time replying to the message.

		Craig

Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 DEC 88  23:54:55 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA12352@EDDIE.MIT.EDU>; Tue, 13 Dec 88 23:55:05 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA00497@BLOOM-BEACON.MIT.EDU>; Tue, 13 Dec 88 22:59:37 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Dec 88 21:59:05 GMT
From: oliveb!3comvax!bridge2!auspex!guy@ames.arpa  (Guy Harris)
Organization: Auspex Systems, Santa Clara
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <698@auspex.UUCP>
References: <555@unocss.UUCP>, <3502@emory.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>The problem is that the To: address does not have an "@dom.ain" part.
>For reasons I was not able to pin down, both the To: and the From:
>address need to be either fully domain'ed or non-domain'ed ("fritz")
>but having mixtures produces this problem.

I think part of the problem may be that the 4.2BSD version of Mail got
confused by the "." when it constructed the address for the reply; it
may think that "." is a Berknet addressing character or something.  This
may be fixed in the 4.3BSD version.

>/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically
>have already done it, and called the result mailx.  It is interesting to
>note that Sun's /usr/ucb/Mail is actually mailx.

It is also interesting to note that a lot of the overhauling of the
address-handling portion of Mail wasn't done by AT&T; a
much-closer-to-RFC822-compliant version that I did is in the 4.3BSD
version of Mail and the S5R3 version of "mailx" (as well as the SunOS
4.0 "Mail").  There are still some holes in it, though.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Dec 88 05:04:30 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06352@BLOOM-BEACON.MIT.EDU>; Wed, 14 Dec 88 04:57:02 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Dec 88 00:43:35 GMT
From: auspex!guy@uunet.uu.net  (Guy Harris)
Organization: Auspex Systems, Santa Clara
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <700@auspex.UUCP>
References: <555@unocss.UUCP>, <3502@emory.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>The problem is that the To: address does not have an "@dom.ain" part.
>For reasons I was not able to pin down, both the To: and the From:
>address need to be either fully domain'ed or non-domain'ed ("fritz")
>but having mixtures produces this problem.

I think part of the problem may be that the 4.2BSD version of Mail got
confused by the "." when it constructed the address for the reply; it
may think that "." is a Berknet addressing character or something.  This
may be fixed in the 4.3BSD version.

>/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically
>have already done it, and called the result mailx.  It is interesting to
>note that Sun's /usr/ucb/Mail is actually mailx.

I don't know that "mailx" is a complete overhaul; they added a bunch of
stuff, and may have cleaned up some things, but one thing they didn't
touch was the address parsing.  The 4.2BSD "Mail" and S5R2 "mailx" had a
parser that claimed to be an RFC733 parser; the 4.3BSD "Mail" and S5R3
"mailx" picked up an updated parser I did that claims to be an RFC822
parser, although there are still some holes in it.

The generation of "unl:fritz@edu" is, I suspect, due to the problem I
cited above.  However, the SunOS 4.0 "Mail", which is derived from the
S5R2 "mailx" but has a bunch of 4.3BSD "Mail" and other fixes, including
my updated parser, still generates two "fritz@unocss.unl.edu" in the
"To:" line when you do "replyall".

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Dec 88 16:04:54 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA17554@BLOOM-BEACON.MIT.EDU>; Wed, 14 Dec 88 15:52:50 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Dec 88 17:57:18 GMT
From: oliveb!3comvax!bridge2!auspex!guy@ames.arpa  (Guy Harris)
Organization: Auspex Systems, Santa Clara
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <705@auspex.UUCP>
References: <555@unocss.UUCP>, <3502@emory.uucp>, <1262@fai.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>The AT&T salesperson pushed mailx really hard as a clean rewrite of berkeley
>Mail, but our copy (SysV on a Vax 11/780) dumped core randomly and frequently.
>Perhaps they've come out with something since that works?

Calling "mailx" a "rewrite" of "Mail" is incorrect.  The S5R2 "mailx" is
basically an *enhanced* version of a "Mail" of somewhere between 4.1BSD
and 4.2BSD vintage; the stuff they added is obviously new, but the
4.xBSD-derived stuff is pretty much unchanged.  The S5R3 one may have
changed more, but I still wouldn't call it a "rewrite".

>>It is interesting to
>>note that Sun's /usr/ucb/Mail is actually mailx.
>
>With how much work done by Sun??  At least the network stuff must
>have been added by Sun -- AT&T has only recently acknowledged the
>existance of SMTP mail.

Basically, stuff from the 4.2BSD (and, later, 4.3BSD) "Mail" was merged
back into the S5R2 "mailx" to make the SunOS "Mail".  Among the stuff
merged back was the use of "sendmail" to actually deliver mail, hence
the support for SMTP or anything else you get "sendmail" to support.  A
bunch of other miscellaneous stuff was added as well.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 04:49:34 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA28260@BLOOM-BEACON.MIT.EDU>; Thu, 15 Dec 88 04:25:54 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Dec 88 03:15:41 GMT
From: pyramid!csg@lll-lcc.llnl.gov  (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <51056@pyramid.pyramid.com>
References: <555@unocss.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes:
>... and discovered a bug, for lack of a better word, in the Berkeley mail
>program.
>
>... this is on a Sequent Balance 8000, running Dynix 2.1.1....

To make a long story short, this is little a bug in the 4.2BSD version of
Mail. Get your machine upgraded to Dynix 3.n, which uses the 4.3BSD version
of Mail.

<csg>

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 06:19:40 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA00461@BLOOM-BEACON.MIT.EDU>; Thu, 15 Dec 88 06:04:33 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Dec 88 11:27:38 GMT
From: agate!saturn!ssyx.ucsc.edu!ulmo@labrea.stanford.edu  (Brad Allen)
Subject: Is dot valid in address for indicating absolute domain name?
Message-Id: <5765@saturn.ucsc.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Is "foo.baz.org." with the trailing dot mentioned in an RFC?  Is it
supposed to be standard?  Is it a standard?  Who likes it?  Should it
be used?  It denotes absolute (nonrelative) addressing to the local
systems I use when using a few of the net facilities.

(I have no affiliation, so ignore any implied organization)

Received: from gaak.LCS.MIT.EDU (TCP 2206400041) by MC.LCS.MIT.EDU 15 Dec 88 08:22:39 EST
Received: by gaak.LCS.MIT.EDU 
	id AA22958; Thu, 15 Dec 88 08:22:22 EST
Date: Thu, 15 Dec 88 08:22:22 EST
From: map@gaak.LCS.MIT.EDU (Michael A. Patton)
Message-Id: <8812151322.AA22958@gaak.LCS.MIT.EDU>
To: agate!saturn!ssyx.ucsc.edu!ulmo@labrea.stanford.edu
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: (Brad Allen's message of 14 Dec 88 11:27:38 GMT <5765@saturn.ucsc.edu>
Subject: Is dot valid in address for indicating absolute domain name?

Trailing dots and other artifacts like that to the right of the @ are
covered by the Domain Name System RFC sequence (1031-1035).  RFC1033
mentions the two forms at the top of page 4 as a convention for the
actual Domain data files, RFC1034 discusses this topic on page 8 as a
user-interface issue, and RFC1035 revisits the discussion from RFC1033
in greater detail on page 34.

In general your observation is correct, names ending in dot are
complete and absolute while names without a trailing dot are relative
(subject to extension).  This is purely a question of external (i.e.
in text) representation, the internal representations are always
absolute.  If a routine reading in a domain is presented with a
relative name, it should extend it in whatever way is appropriate.

In the case of a zone file for the DNS the extension is a previously
given domain, for the more general user-interface (and this is the
part that applies to mail headers, this group is about mail headers,
remember :-) the name "should be completed by local software using
knowledge of the local domain."  They are "taken relative ... to a
list of domains used as a search list. ... The most common
interpretation uses the root `.' as either the single originor as one
of the members...so a multi-label relative name is often one where the
trailing dot has been omitted to save typing."  [all quotes (except
the atrocious takeoff on Alice's Restaurant) from RFC1034 page 8]

As far as I know, there are only a few (or less, maybe even no :-)
implementations that actually implement the "search list" operation in
the right way.  The most common is to try the local domain and root as
the only extensions, and frequently only one of these based on whether
there are already dots.

I hope this information has been helpful to you.  It is not complete
in the minutae and not guaranteed to stay correct even long enough for
the mail to reach you.  The DNS is a moving target and this is one of
the areas in the spec that people are flexing on to see what can be
done as the spec stands and what is useful to be done that can't
within the current spec.  The simple general statement you made is
(and is expected to stay) what the user sees of the operation.

	    __
  /|  /|  /|  \		Mike Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

MAP@LCS.MIT.Edu, PostMaster@LCS.MIT.Edu, BUG-LCS-Domain@LCS.MIT.Edu, etc.

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 11:34:35 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05432@BLOOM-BEACON.MIT.EDU>; Thu, 15 Dec 88 11:28:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Dec 88 15:57:45 GMT
From: cs.utexas.edu!fletcher@ohio-state.arpa  (Fletcher Mattox)
Organization: U. Texas CS Dept., Austin, Texas
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <4352@cs.utexas.edu>
References: <555@unocss.UUCP>, <51056@pyramid.pyramid.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <51056@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes:

>To make a long story short, this is little a bug in the 4.2BSD version of
>Mail. Get your machine upgraded to Dynix 3.n, which uses the 4.3BSD version
>of Mail.

To make a short story (slightly) more accurate, n > 0.4.
DYNIX 3.0.4 still uses the the 4.2 Mail. 

Fletcher

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 13:35:49 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA07525@BLOOM-BEACON.MIT.EDU>; Thu, 15 Dec 88 13:25:58 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Dec 88 16:51:11 GMT
From: cfe+@andrew.cmu.edu  (Craig F. Everhart)
Organization: Carnegie Mellon
Subject: Re: Is dot valid in address for indicating absolute domain name?
Message-Id: <kXdypzy00VsLE0WkZr@andrew.cmu.edu>
References: <5765@saturn.ucsc.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I believe that it's mentioned in the domain-system specs, which for interchange
purposes don't care if a name is suffixed with a dot or not.  Some programs that
act as user agents for the domain system use it to know whether to try appending
local suffixes or not; I don't believe that that usage is anywhere in an RFC.
One place that it's NOT is in RFC821 or RFC822; the mail address
``foo@bar.baz.'' is invalid RFC822.  You can't append a dot to an RFC822 domain
without invalidating it as an RFC822 domain.

                Craig Everhart

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 15 Dec 88 14:58:34 EST
Date: Thu, 15 Dec 1988  14:54 EST
Message-ID: <SRA.12454678878.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   agate!saturn!ssyx.ucsc.edu!ulmo@LABREA.STANFORD.EDU (Brad Allen)
Cc:   header-people@MC.LCS.MIT.EDU
Subject: Is dot valid in address for indicating absolute domain name?

The trailing dot stuff was added to the DNS between the first and
second specifications (ie, between RFCs 882-883 and 1034-1035).  The
first I recall hearing of it was in a mail message from Paul
Mockapetris on Namedroppers in response to people who claimed that the
DNS had no provision for this kind of thing.

DNS internal representations don't have any dots at all.

RFC 821/822 compliant mailsystems MUST NOT put trailing dots in
outgoing messages (disallowed by the BNF).  It's ok for your mail
composer/reader to use the syntax but the name must be cannonicalized
before it escapes your machine.

The TOPS-20 resolver code supports the trailing dot stuff along with
per-site search paths (per-user would have been a real bear on
TOPS-20, although Noel Chiappa came up with a cute idea for the basic
mechanism).  The TOPS-20 mailer cannonicalizes all hostnames anyway.

I am not aware of any other implemntations that support the trailing
dot syntax in their user interface (all implementations support it in
master files, for self-preservation); I'd be interested in hearing
about ones that do.

--Rob

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 23:05:04 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA16369@BLOOM-BEACON.MIT.EDU>; Thu, 15 Dec 88 23:02:28 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Dec 88 10:24:41 GMT
From: mcvax!hp4nl!htsa!hanst@uunet.uu.net  (Hans Trompert)
Organization: AHA-TMF (Technical Institute), Amsterdam, Netherlands
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <668@htsa.uucp>
References: <555@unocss.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <555@unocss.UUCP>, fritz@unocss.UUCP (Tim Russell) writes:
> Hi all,
> 
>     I recently acquired the MM mailer that Columbia has ported to Unix
> (it's in beta-test), and discovered a bug, for lack of a better word,
> in the Berkeley mail program.
> 
>     First off, let me set things up: this is on a Sequent Balance 8000,
> running Dynix 2.1.1 (BSD 4.2 and System V.2 together).  I've also tried
> this on a Vax 8200 running Ultrix 2.3.

Greetings,
We too have a Sequent Balance 8000, and we are running Dynix V3.0.4.
We have never used the original mail, because we were told there are many
problems using RFC822 mail headers. So we use RSMTP instead (originally
written by Jack Jansen CWI Amsterdam Netherlands, uunet!mcvax!piring!jack or
jack@cwi.nl). RSMTP (Realy Simple Mail Transfer Program) 
pretends to understand internet addresses, but what it
does is just converting these addresses to uucp-like addresses: jack@cwi.nl
becomes cwi.nl!jack. Installing RSMTP is rather straight forward, a manual
is included, but you can also ofcourse examine the sources. For those who
are interested we are willing to post those sources.


Hans Trompert HTS "A" Amsterdam Netherlands
--> hanst@htsa.uucp
--> uunet!mcvax!htsa!hanst

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Dec 88 16:23:38 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19976@BLOOM-BEACON.MIT.EDU>; Tue, 27 Dec 88 16:14:35 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Dec 88 20:30:35 GMT
From: rochester!uhura.cc.rochester.edu!msir@rutgers.edu  (Mark Sirota)
Organization: Univ. of Rochester, Computing Center
Subject: Simple form of RFC 822?
Message-Id: <569@ur-cc.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I'm writing a sendmail.cf for the University of Rochester, and I'm sitting
here reading through RFC 822 to see if I missed any legal address-forms.
Now, those of you who have tried to read RFC 822 before will hopefully
agree that this is a difficult document to read.

What I'm looking for is a relatively simple list of legal
address-specifications in human-readable form (unlike RFC 822).  Anyone
have such a beast?
-- 
Mark Sirota - University of Rochester, Rochester, NY
 Internet: msir@cc.rochester.edu
 Bitnet:   msir_ss@uordbv.bitnet
 UUCP:     ...!rochester!ur-cc!msir

Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 16:58:38 EST
Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 13:24:35 PST
Received: from obelix by Obelix.TWG.COM id aa05526; 28 Dec 88 15:25 PST
Reply-To: James M Galvin <galvin@TWG.COM>
To: Mark Sirota <msir@cc.rochester.edu>
cc: header-people@mc.lcs.mit.edu
Subject: Re: Simple form of RFC 822? 
In-reply-to: Your message of 27 Dec 88 20:30:35 GMT.
             <569@ur-cc.UUCP> 
Date: Wed, 28 Dec 88 13:25:47 -0800
Message-ID: <5524.599347547@twg.com>
From: James M Galvin <galvin@TWG.COM>

> What I'm looking for is a relatively simple list of legal
> address-specifications in human-readable form (unlike RFC 822).  Anyone
> have such a beast?

The answer may be simpler than you think.  If you are writing it for your
own machine, the only things you have to worry about are the addresses you
understand.

So, if you are an Internet host, the only addresses you have to understand
are those with an "@" in them.  If they don't have that, they are malformed.
Now you have to decide if your are going to reject it, assume it is local and
try to deliver, or push it off to a gateway.  Similar statements can be made
about other networks.

Assuming it is local may be too generous, so you may wish to check for other
"delimiter characters" (eg "!:") and then reformat and repeat.  That, of
course, is your original question.

My position is, is it really necessary to be overly generous?  Given that
fully qualified host names are a necessity, must the mail system have all
of the complexity needed to "clean up" after its users?  I think it is
time we forced some knowledge back onto the users.  Require them to enter
syntactically correct addresses.

You may think I am cynical, but I seriously pose the question, "why be
generous?"

Comments and thoughts are solicited.

Jim

Received: from uhura.cc.rochester.edu (TCP 20045760021) by MC.LCS.MIT.EDU 28 Dec 88 17:49:11 EST
Received: by uhura.cc.rochester.edu id AA20958 (3.2wj3); Wed, 28 Dec 88 17:44:34 EST
Message-Id: <8812282244.20958@uhura.cc.rochester.edu>
Date: Wed, 28 Dec 88 17:44:34 EST
From: msir@uhura.cc.rochester.edu (Mark Sirota)
Reply-To: msir@cc.rochester.edu
X-Mailer: Mail User's Shell (6.4 12/27/88)
To: James M Galvin <galvin@TWG.COM>
Subject: Re: Simple form of RFC 822?
Cc: header-people@mc.lcs.mit.edu

>> What I'm looking for is a relatively simple list of legal
>> address-specifications in human-readable form (unlike RFC 822).  Anyone
>> have such a beast?
> 
> The answer may be simpler than you think.  If you are writing it for your
> own machine, the only things you have to worry about are the addresses you
> understand.

Except that there's this thing called a standard, currently defined by
RFC-822.  All mailers on the internet should handle any address specified
by this standard.

> My position is, is it really necessary to be overly generous?  Given that
> fully qualified host names are a necessity, must the mail system have all
> of the complexity needed to "clean up" after its users?  I think it is
> time we forced some knowledge back onto the users.  Require them to enter
> syntactically correct addresses.

Oh, I agree absolutely.  The mailer shouldn't have to figure out what the
user meant; it should just bounce bad addresses.  However, what I was
looking for was the definition of a bad address (or, more particularly,
the definition of a good address).

Mark

-- 
Mark Sirota - University of Rochester, Rochester, NY
 Internet: msir@cc.rochester.edu
 Bitnet:   msir_ss@uordbv.bitnet
 UUCP:     ...!rochester!ur-cc!msir

Received: from gaak.LCS.MIT.EDU (TCP 2206400041) by MC.LCS.MIT.EDU 28 Dec 88 17:56:03 EST
Received: by gaak.LCS.MIT.EDU 
	id AA29279; Wed, 28 Dec 88 17:54:24 EST
Date: Wed, 28 Dec 88 17:54:24 EST
Message-Id: <8812282254.AA29279@gaak.LCS.MIT.EDU>
To: galvin@twg.com
From: MAP@lcs.mit.edu
Sender: map@gaak.LCS.MIT.EDU
Cc: msir@cc.rochester.edu, header-people@mc.lcs.mit.edu
In-Reply-To: James M Galvin's message of Wed, 28 Dec 88 13:25:47 -0800 <5524.599347547@twg.com>
Subject: Re: Why process non-RFC822 style addresses

   Date: Wed, 28 Dec 88 13:25:47 -0800
   From: James M Galvin <galvin@twg.com>

	[...]

   My position is, is it really necessary to be overly generous?  Given that
   fully qualified host names are a necessity, must the mail system have all
   of the complexity needed to "clean up" after its users?  I think it is
   time we forced some knowledge back onto the users.  Require them to enter
   syntactically correct addresses.

   You may think I am cynical, but I seriously pose the question, "why be
   generous?"

Because my users have no control over what will be handed them on
incoming mail and thus used in a "Reply" command in the mailer.  If I
could somehow ensure that incoming messages had valid Internet
addresses in all the appropriate fields (To:, From:, Reply-To:, etc.)
then it wouldn't be a problem.  The users are frequently not
sophisticated enough to fix these up when they occur, if the mailer
can make a guess that's right 75% of the time that reduces (by greater
than 75% :-) the number of times I get calls about not being able to
reach someone.  If all the gateways would translate to valid RFC822,
there wouldn't be a problem.  But many of them don't (for various
reasons, that's a whole 'nother can of worms I don't really want to
open) and I am forced to deal with them, if I can do it automatically
then I save myself work.

   Comments and thoughts are solicited.

   Jim

	    __
  /|  /|  /|  \		Mike Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

PostMaster@LCS.MIT.Edu, Bug-LCS-Domain@LCS.MIT.Edu, MAP@LCS.MIT.Edu

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:00:27 EST
Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:45:03 PST
Received: from obelix by Obelix.TWG.COM id aa06679; 28 Dec 88 17:46 PST
Reply-To: James M Galvin <galvin@TWG.COM>
To: MAP@lcs.mit.edu
cc: msir@cc.rochester.edu, header-people@mc.lcs.mit.edu
Subject: Re: Why process non-RFC822 style addresses 
In-reply-to: Your message of Wed, 28 Dec 88 17:54:24 EST.
             <8812282254.AA29279@gaak.LCS.MIT.EDU> 
Date: Wed, 28 Dec 88 15:46:27 -0800
Message-ID: <6675.599355987@twg.com>
From: James M Galvin <galvin@TWG.COM>

> Because my users have no control over what will be handed them on
> incoming mail and thus used in a "Reply" command in the mailer.  If I
> could somehow ensure that incoming messages had valid Internet
> addresses in all the appropriate fields (To:, From:, Reply-To:, etc.)
> then it wouldn't be a problem.

I agree that "gateways" may need more knowledge than the average host in a
given local environment.  But why not reject incoming mail that does not
have valid Internet addresses?

Oops, touched a nerve no doubt.  There are two sets of addresses: those in
the "envelope" as transported and managed by SMTP, and those in the message,
more specifically in the headers of the message.  Dare gateways touch the
addresses in the headers as the message passes by to ensure replyability?
Maybe the delivery process should just include the envelope addresses in
the message when it is delivery, ie modify the message itself.  Wait, I
heard of that before; it is called "return-path".  So why don't more user
agents make use of it? ...

The basic problem is electronic mail is a service.  I do the best I can to
provide a "good" service to my clients, someone else does the best he can
to provide a "good" service and yet another person does the best she can
to provide a "good" service.  The trouble is that leaves us right where we
started.

It is time to start educating the users to educate their system administrators
to change the fundamental principles upon which the mail service is based.
Rather than each administrator being in his/her own world and compensating
for the rest of the world, we have to start doing it right.

Anyone disagree?

Jim

Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:08:23 EST
Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:31:03 PST
Received: from obelix by Obelix.TWG.COM id aa06570; 28 Dec 88 17:32 PST
Reply-To: James M Galvin <galvin@TWG.COM>
To: msir@cc.rochester.edu
cc: header-people@mc.lcs.mit.edu
Subject: Re: Simple form of RFC 822? 
In-reply-to: Your message of Wed, 28 Dec 88 17:44:34 EST.
             <8812282244.20958@uhura.cc.rochester.edu> 
Date: Wed, 28 Dec 88 15:32:31 -0800
Message-ID: <6567.599355151@twg.com>
From: James M Galvin <galvin@TWG.COM>

> Except that there's this thing called a standard, currently defined by
> RFC-822.  All mailers on the internet should handle any address specified
> by this standard.

> However, what I was
> looking for was the definition of a bad address (> or, more particularly,
> the definition of a good address).

You answered your own question, didn't you?  But then, you originally asked
for someone to explain in English what is a valid address, or at least to
provide a set of examples of valid addresses.  Well, 822 has an appendix of
example addresses.  To expand on that and offer some English rules, how about
these for a start:

1.  internet address must have an "@" in it, if not it is a local address.
2.  "@" usage is either LOCAL@HOST1 or @HOST1,@HOST2,@HOST3:LOCAL.  Determine
    which and deliver to HOST1.
3.  Beware of quoted "@"'s.

Jim

Received: from uhura.cc.rochester.edu (TCP 20045760021) by MC.LCS.MIT.EDU 28 Dec 88 21:18:29 EST
Received: by uhura.cc.rochester.edu id AA22873 (3.2wj3); Wed, 28 Dec 88 21:15:43 EST
Message-Id: <8812290215.22873@uhura.cc.rochester.edu>
Date: Wed, 28 Dec 88 21:15:43 EST
From: msir@uhura.cc.rochester.edu (Mark Sirota)
Reply-To: msir@cc.rochester.edu
X-Mailer: Mail User's Shell (6.4 12/27/88)
To: James M Galvin <galvin@TWG.COM>, MAP@lcs.mit.edu
Subject: Re: Why process non-RFC822 style addresses
Cc: header-people@mc.lcs.mit.edu

In message <6675.599355987@twg.com> James M Galvin <galvin@TWG.COM> writes:
> It is time to start educating the users to educate their system
> administrators to change the fundamental principles upon which the mail
> service is based.  Rather than each administrator being in his/her own
> world and compensating for the rest of the world, we have to start doing it
> right.

This is all well and good, but it seems to contradict what you said
earlier.  There exists a decent standard, which, assuming it's used
properly, should work well.  So, rather than each of doing it however we
feel, we should adhere to the standard.

I believe you were the one who said:
> If you are writing it for your own machine, the only things you have to
> worry about are the addresses you understand.

Perhaps I'm misunderstanding what you meant by that, but it sounds like
you meant "wing it and make your users happy".

Mark

-- 
Mark Sirota - University of Rochester, Rochester, NY
 Internet: msir@cc.rochester.edu
 Bitnet:   msir_ss@uordbv.bitnet
 UUCP:     ...!rochester!ur-cc!msir

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 29 Dec 88 08:54:39 EST
Received: by INFOODS id <00002752061@INFOODS.MIT.EDU> ;
       Thu, 29 Dec 88 08:48:45 EST
Date: Thu, 29 Dec 88 08:35:50 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: RE:  Re: Simple form of RFC 822? 
To: James M Galvin <galvin@TWG.COM>
X-VMS-Mail-To: EXOS%"James M Galvin <galvin@TWG.COM>"
Message-ID: <881229083550.00002752061@INFOODS.MIT.EDU>
cc: header-people@MC.LCS.MIT.EDU

James M Galvin writes:
> ...
>  To expand on that and offer some English rules, how about
>these for a start:

>1.  internet address must have an "@" in it, if not it is a local address.
>2.  "@" usage is either LOCAL@HOST1 or @HOST1,@HOST2,@HOST3:LOCAL.  Determine
>    which and deliver to HOST1.
>3.  Beware of quoted "@"'s.

I hope this is not what TWG is doing, because the second example in (2) 
is twice illegal:
  (a) <@host1,@host2:local@host3>   may not appear without the 
bracketing <...>
  (b) The syntax <@hostn,@hostm:local> is illegal: there must be a 
domain name for the local address, i.e., <@host1,@host2:local@host3>

In addition, it is in poor taste and probably a violation of the 
protocols to generate a "reply" address by using the Reverse-path.  The 
only reasonable rule for a gateway to follow (with the understanding 
that some don't) is to have only legal internet addresses appear on the 
Internet.  That means, in part, that any *address* appearing in an 
RFC-822 header on the Internet side of a gateway must be in Internet 
form and that all of the strings that are in the form @hostN above must 
be valid (registered/resolvable) domain names.


Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 29 Dec 88 11:28:19 EST
Received: from TWG.COM by twg.com with SMTP ; Thu, 29 Dec 88 08:03:41 PST
Received: from obelix by Obelix.TWG.COM id aa12368; 29 Dec 88 10:05 PST
Reply-To: James M Galvin <galvin@TWG.COM>
To: John C Klensin <KLENSIN@infoods.mit.edu>
cc: header-people@mc.lcs.mit.edu
Subject: Re: Simple form of RFC 822? 
In-reply-to: Your message of Thu, 29 Dec 88 08:35:50 EST.
             <881229083550.00002752061@INFOODS.MIT.EDU> 
Date: Thu, 29 Dec 88 08:05:05 -0800
Message-ID: <12366.599414705@twg.com>
From: James M Galvin <galvin@TWG.COM>

> I hope this is not what TWG is doing, because the second example in (2) 
> is twice illegal:

No, we are definitely not doing this.  They were offered as a suggested
starting point, not complete solutions.  The 2 comments you made are
certainly correct.

> In addition, it is in poor taste and probably a violation of the 
> protocols to generate a "reply" address by using the Reverse-path.

Not true.  The standard only requires that automatically generated address
lists use the from/sender/reply-to, at a minimum.  The return-path is intended
to indicate a route back to the originator.  There are no other restrictions
on what a user agent provides.

> The 
> only reasonable rule for a gateway to follow (with the understanding 
> that some don't) is to have only legal internet addresses appear on the 
> Internet.

I agree, and my position is why should I at my site have to make up for
improper gateways.  I am suggesting that users should be required to begin
to understand the complexities and thus pressure can be brought to bear
to fix things.

Note that I am not saying anything new.  This discussion has gone on here
and elsewhere many times before.  I am beginning to feel much more strongly
about it as a result of the recent Internet worm.  I think that we should
stop trying to be so "smart" everywhere, leaving the "smarts" in as few
places as possible.  Thus, stripped down sendmail configuration files should
be available, and used much more often than what is currently distributed.

Jim

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  7 Jan 89 17:28:08 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15137@BLOOM-BEACON.MIT.EDU>; Sat, 7 Jan 89 17:09:51 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Jan 89 20:33:50 GMT
From: cs.utexas.edu!execu!dewey@husc6.harvard.edu  (Dewey Henize)
Organization: Home for Recalcitrant Hackers
Subject: Still trying to get smart routing working.
Message-Id: <412@execu.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I posted about 3 weeks ago that I was trying to convert our systems to using
smail and do some semi-intelligent routing...

Well, so far it hasn't gone too well.  I still have quite a list of folks that
are also interested if I can figure out the problems, but the amount of solid
info has been, uh, sparse.

Smail seems to compile pretty well, but I'm running into real problems with the
sendmail.cf file.  We're a bsd (Sun 4.0.broken) site for a main server, and
a lot of dec and sun and other machines around besides that.  It appears that
perhaps the sendmail.cf file is not reading the /etc/hosts file at all.

Pathalias seems to be going ok, we run it every night and use the add'l tools
to reformat for use by smail, etc.

Some basic questions...
Our alias file is, as Sun recommends, of the form
fred:	fred@execu
joe:	joe@prickleypear
...etc...

Is this the right form for smail/sendmail?  Should there be more/less info
in there?

The sendmail.cf from Sun seems to be messed up, at least according to the docs
I read in one of the Sun manuals.  Supposedly (no, I'm not a guru, not even
close) the construct for a rhs of $:$>8 should direct more processing to 
ruleset 8 - but there isn't a S8 in the file...  duh?

Again, if anyone has any ideas that could help, please send them to me.  And
please don't worry about repeating what you think someone else would have surely
said - they didn't, and if they do I'll STILL appreciate the info and confirmation.

Final note - is anyone aware of a program called [perhaps] 'ease' for use in
generating config files?  I tried to look it up, but I don't see it anywhere
in the indexes I've downloaded.

Thanks 

Dewey Henize
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| There is nothing in the above message that can't be explained by sunspots.  |
|                   execu!dewey             Dewey Henize                      |
|         Can you say standard disclaimer?  I knew you could.  Somehow...     |

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  7 Jan 89 22:42:58 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19866@BLOOM-BEACON.MIT.EDU>; Sat, 7 Jan 89 22:28:10 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Jan 89 17:35:54 GMT
From: mcvax!enea!kth!draken!chalmers!cs.chalmers.se!lindberg@uunet.uu.net  (Gunnar Lindberg)
Organization: Dept. of CS, Chalmers, Sweden
Subject: Re: BSD 4.2 Mail not RFC822-compliant?
Message-Id: <2820@fnatte.cs.chalmers.se>
References: <555@unocss.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes:
    > ...
    >From: Tim Russell <fritz@unocss.unl.edu>
    >To: fritz
    >
    >& reply
    >To: unl:fritz@edu fritz@unocss.unl.edu

I hope I haven't missed the point completely, but this used to happen
here too. It seems like the routine "map()" in "src/ucb/Mail/names.c"
does a lot of funny things with reply addresses, so we simply replaced
it with a "return;" (well, its content, of course). What "map()" was
really supposed to do I still don't know...

	Gunnar Lindberg

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  8 Jan 89 06:27:58 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA25745@BLOOM-BEACON.MIT.EDU>; Sun, 8 Jan 89 06:07:39 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jan 89 10:50:50 GMT
From: nic.MR.NET!xanth!wisner@csd4.milw.wisc.edu  (Bill Wisner)
Organization: Old Dominion University, Norfolk Va.
Subject: Re: Still trying to get smart routing working.
Message-Id: <7094@xanth.cs.odu.edu>
References: <412@execu.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes:
>Our alias file is, as Sun recommends, of the form
>fred:	fred@execu
>joe:	joe@prickleypear
>...etc...

Sounds bogus to me. If fred and joe are real accounts that want to receive
mail on another machine, give them .forward files. If they're not real
accounts and you're setting up forwarding addresses, disregard this
paragraph.

>Is this the right form for smail/sendmail?

The form is fine. Smail knows how to grok Sendmail's alias file format.

>The sendmail.cf from Sun seems to be messed up, at least according to the docs
>I read in one of the Sun manuals.  Supposedly (no, I'm not a guru, not even
>close) the construct for a rhs of $:$>8 should direct more processing to 
>ruleset 8 - but there isn't a S8 in the file...  duh?

If there is no ruleset 8, Sendmail will ignore that rule.

>Final note - is anyone aware of a program called [perhaps] 'ease' for use in
>generating config files?  I tried to look it up, but I don't see it anywhere
>in the indexes I've downloaded.

Ease is a language reminiscent of C that you can use to specify a sendmail.cf
file. The Ease program converts a file written in the Ease language into a
sendmail.cf that can be digested by Sendmail.

And now I wax religious:

I dislike Ease. That puts me into a minority. Learning an entire new language
just to keep one's mailer configured is ridiculous. Sendmail rules are simply
pattern match-and-replaces. The syntax involved is actually easy to learn.
The interactions between rulesets are also straightforward. The difficulty
lies in knowing, in excruciating step-by-step detail, every trifling little
action that must be taken to get Sendmail to deliver a message. Writing
one's configuration in a different format won't change that.

Ease is a waste of time.

If you remain unconvinced and want to try Ease yourself, it's available
from a comp.sources.unix archive. But it's still a waste of time.

Bill, the man from Xanth

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  8 Jan 89 19:58:07 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06722@BLOOM-BEACON.MIT.EDU>; Sun, 8 Jan 89 19:43:13 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jan 89 23:36:20 GMT
From: vixie@decwrl.dec.com  (Paul A Vixie)
Organization: DEC Western Research Lab
Subject: Re: Still trying to get smart routing working.
Message-Id: <VIXIE.89Jan8153620@bacchus.pa.dec.com>
References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[Wisner]
# And now I wax religious:
#
# I dislike Ease. [...]

I agree with most of your conclusions about Ease.  However, I recommend that
anyone interested in understanding sendmail's raw configuration language get
Ease, read all of its documentation, and play with it for a week.  This is
how I finally learned enough about sendmail.cf to write one from scratch.

I might have stayed with Ease if it had made multi-line strings possible; my
"Received:" headers spanned a physical newline and the grammar that came with
Ease at that time would have taken massive hacking to make that possible.
Also, Ease cannot generate the extensions used by IDA.  No fault on the part
of its implementors, since IDA didn't exist when Ease was first conceived.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  8 Jan 89 19:58:18 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06728@BLOOM-BEACON.MIT.EDU>; Sun, 8 Jan 89 19:43:41 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jan 89 23:31:27 GMT
From: vixie@decwrl.dec.com  (Paul A Vixie)
Organization: DEC Western Research Lab
Subject: Re: Still trying to get smart routing working.
Message-Id: <VIXIE.89Jan8153127@bacchus.pa.dec.com>
References: <412@execu.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[Henize]
# Smail seems to compile pretty well, but I'm running into real problems with
# the sendmail.cf file.  We're a bsd (Sun 4.0.broken) site for a main server,
# and a lot of dec and sun and other machines around besides that.  It
# appears that perhaps the sendmail.cf file is not reading the /etc/hosts
# file at all.
# [...]
# The sendmail.cf from Sun seems to be messed up, at least according to the
# docs I read in one of the Sun manuals.  [...]

I recommend that you try to use the sendmail.cf file that comes with the smail
package rather than back-fitting Sun's config file to use smail for UUCP.  The
Sun config file was a nightmare last time I looked at it (in fairness, the one
in Ultrix is not easy to figure out either), but the one that comes with smail
is sufficient for most purposes, is relatively simple as sendmail config files
go, and makes a great base for later additions.

There are a few gotchas in the config file that smail builds for you, and the
questions it asks you in its build script aren't very clear, but once you get
something that barely works it is only an hour's work to get it to the 99%
point, which is as far as sendmail is ever going to get you anyway.

Moral: throw out the sendmail.cf that came from your CPU vendor and use the
       one that comes with smail.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  9 Jan 89 02:41:11 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12287@BLOOM-BEACON.MIT.EDU>; Mon, 9 Jan 89 02:26:18 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Jan 89 07:00:20 GMT
From: utkcs2!cygnusx1!moore@gatech.edu  (Keith Moore)
Organization: CS Dept -- University of TN, Knoxville
Subject: sendmail incompatibility (was Re: Still trying to get ...).
Message-Id: <697@utkcs2.cs.utk.edu>
References: <412@execu.UUCP>, <VIXIE.89Jan8153127@bacchus.pa.dec.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[Henize]
>[...]
>The sendmail.cf from Sun seems to be messed up, at least according to the
>docs I read in one of the Sun manuals.  [...]

[Vixie]
>I recommend that you try to use the sendmail.cf file that comes with the smail
>package rather than back-fitting Sun's config file to use smail for UUCP.  The
[...]
>Moral: throw out the sendmail.cf that came from your CPU vendor and use the
>       one that comes with smail.

Even this is not always enough.  It seems that some vendors have changed
sendmail enough that config files for vanilla (i.e. Berkeley) sendmail don't
work with the vendor-supplied version.   Our standard .cf file works fine
with 5.59, but breaks when I give it to either the Ultrix 3.0 sendmail or
the SunOS 4.0 sendmail.  I'm sure the required changes are minor, but I
really have no way of knowing what is different about the vendors' versions.
Rather than try and figure out a black box, we just run 5.59 on everything.

Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and
use the one from ucbarpa.berkeley.edu.

[Busily reverse-engineering the mail11 gateway so we can run Ultrix 3.0...]
--
Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore@utkvx
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Jan 89 04:44:01 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA08562@BLOOM-BEACON.MIT.EDU>; Tue, 10 Jan 89 04:36:08 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Jan 89 08:22:33 GMT
From: pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu  (Dan Heller)
Organization: University of California, Berkeley
Subject: ucbarpa's sendmail config (was sendmail incompatibility )
Message-Id: <8688@pasteur.Berkeley.EDU>
References: <412@execu.UUCP>, <VIXIE.89Jan8153127@bacchus.pa.dec.com>, <697@utkcs2.cs.utk.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <697@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes:
>Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and
>use the one from ucbarpa.berkeley.edu.

I'm curious about something.  This config file is used all over berkeley,
as it is at many other sites.  Sometimes, when mail is sent out or when
mail is routed thru said machine, the name-server might fail and your
hostname is not expanded correctly into the fully qualified domain.

The result is the recipient gets mail that says something like:
    From: dheller@cory
As opposed to
    From: dheller@cory.Berkeley.EDU

Many times, I mail to people and they can't reply because "cory" doesn't
make sense (cuz it's not qualified).

The same problem happens when I mail to people at Santa Cruz Operation.
"sco" talks to ucscc.ucsc.edu, so I address the mail:
    To: sco!user@ucscc.ucsc.edu
but when ucsc gets the message, sometimes (when the name server fails to
get info about "ucscc") it rejects the mail with the error:
    ucscc.ucsc.edu: I refuse to talk to myself.

So,  the bottom line is, is it possible to configure a sendmail.cf file
so that if a hostname lookup or a name server lookup fails, it can be
replaced by a known/preset value so that mail can continue to work as
it should.
Dan Heller	<island!argv@sun.com>

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 Jan 89 16:43:44 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22763@BLOOM-BEACON.MIT.EDU>; Mon, 16 Jan 89 16:39:56 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Jan 89 07:52:38 GMT
From: oliveb!3comvax!bridge2!fjd@ames.arpa  (Farokh J. Deboo)
Organization: 3Com Corp., Mt. View, CA
Subject: Call for Papers: IEEE/EMS 1990 Conference in San Francisco
Message-Id: <258@bridge2.3Com.Com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


My apologies for this large cross-posting.

This is to invite prospecitve authors for  papers  relevant  to  the  1990
IEEE/EMS Conference (see announcement below)--- especially for any parties
interested in chairing a session or submitting papers related to electonic
mail in this context.

Thank you,

Farokh Deboo

  +----------------------------------------------------------------------+
  |                        FIRST CALL FOR PAPERS                         |
  |         1990 International Engineering Management Conference         |
  |                      in the San Francisco area                       |
  +----------------------------------------------------------------------+
  |  The IEEE/EMS Conference sponsored by the IEEE Engineering  Manage-  |
  |  ment  Society  will  be held in the San Francisco area between Oc-  |
  |  tober 22 and 24, 1990, with the theme:                              |
  |        Management through the year 2000 and the Pacific Rim.         |
  |                                                                      |
  |  This is an annual international conference dedicated to  improving  |
  |  engineering management.  Contributions are solicited that address,  |
  |  but are not limited to the following main topics:                   |
  |                                                                      |
  |  o  Artificial Intelligence and Robotics                             |
  |  o  Company Management Styles from the entrepreneur to the establis- |
  |     hed                                                              |
  |  o  Transition from Engineer to Manager                              |
  |  o  Management of Corporate R & D Centers                            |
  |  o  Micro Devices                                                    |
  |  o  Doing Business in the Pacific Rim,  Europe, South  America  and  |
  |     Canada                                                           |
  |  o  Manufacturing Management & Factory Operations                    |
  |  o  Just-in-Time and Dock-to-Stock Techniques                        |
  |  o  Education for Manufacturing Managers                             |
  |  o  Manufacturing Technology                                         |
  |                                                                      |
  |  Prospective authors are  requested  to  submit  one  to  two  page  |
  |  abstracts  of  their  presentation  by  April 30, 1990 to IEEE/EMS  |
  |  1990, c/o Judith Baar Inc., 620 Abbie Court, Pleasanton,  Califor-  |
  |  nia  94566.   For  further  information call Judith Baar (415/484-  |
  |  4795) or Michael Crocker (415/354-5240).                            |
  |                                                                      |
  |  The program committee is also looking for  additional  volunteers.  |
  |  If you are interested, please contact the Conference Chairman, Dr.  |
  |  Burton V. Dean at (408) 924-3551 or send mail to "sun!bridge2!fjd"  |
  +----------------------------------------------------------------------+

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 18 Jan 89 21:00:18 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19086@BLOOM-BEACON.MIT.EDU>; Wed, 18 Jan 89 20:54:39 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Jan 89 23:36:09 GMT
From: avsd!childers@bloom-beacon.mit.edu  (Richard Childers)
Organization: die Edelstahlratte
Subject: Re: Still trying to get smart routing working.
Message-Id: <412@avsd.UUCP>
References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <7094@xanth.cs.odu.edu> wisner@xanth.cs.odu.edu (Bill Wisner) writes:

>In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes:

>>Our alias file is, as Sun recommends, of the form
>>fred:	fred@execu
>>joe:	joe@prickleypear
>>...etc...

>Sounds bogus to me. If fred and joe are real accounts that want to receive
>mail on another machine, give them .forward files. If they're not real
>accounts and you're setting up forwarding addresses, disregard this
>paragraph.

As far as I can tell, .forward files don't really fit into a LAN environment.
In my case, I have about four or five YP domains, a corresponding number of
networks, and need to maintain complete interconnectability, for everybody's
convenience. But I can't mount everybody's home directory everywhere, that's
unnecessary and crude - that's what /usr/lib/aliases is for.

When I find .forward files in the LAN - usually as a result of receiving 
mail that looped round and round, before ending up in my mailbox as a problem
report from MAILER-DAEMON - I cat /dev/null into them and chown them to root
and chmod the sucker to 444 and that's that.

Always use /usr/lib/aliases, and concentrate all your network problems into
one place. .forward is an obsolete mechanism from a decade ago.

>Bill, the man from Xanth

What happened to Kent ? You guys merge ?	(-:

-- richard


-- 
 *                     Bismillah hir-Rahman nir-Rahim                         *
 *                                                                            *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 05:02:09 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA25494@BLOOM-BEACON.MIT.EDU>; Thu, 19 Jan 89 05:00:29 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Jan 89 06:52:09 GMT
From: helios.ee.lbl.gov!ace.ee.lbl.gov!leres@nosc.mil  (Craig Leres)
Organization: Lawrence Berkeley Laboratory, Berkeley
Subject: Re: Still trying to get smart routing working.
Message-Id: <1715@helios.ee.lbl.gov>
References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Richard Childers writes:
> When I find .forward files in the LAN - usually as a result of receiving 
> mail that looped round and round, before ending up in my mailbox as a problem
> report from MAILER-DAEMON - I cat /dev/null into them and chown them to root
> and chmod the sucker to 444 and that's that.

This sounds gratuitously fascist to me. Luckly, it's not hard to remove
such a file:

    helios 7 % ls -l .forward
    -r--r--r--  1 root            0 Jan 18 22:40 .forward
    helios 8 % rm .forward
    rm: override protection 444 for .forward? y
    helios 9 % ls -l .forward
    .forward not found

The advanced reader might want to use "rm -f .forward"

		Craig

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 14:02:27 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03805@BLOOM-BEACON.MIT.EDU>; Thu, 19 Jan 89 13:53:06 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Jan 89 16:32:06 GMT
From: phri!roy@nyu.edu  (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Subject: Re: Still trying to get smart routing working.
Message-Id: <3656@phri.UUCP>
References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[Regarding the selection of newsgroups, I consider it fundamentally wrong
to crosspost to foo.misc as well as foo.x, foo.y, and foo.z.  I've directed
followups to comp.mail.sendmail since that's the most appropriate group.]

In article <412@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:
> Always use /usr/lib/aliases, and concentrate all your network problems into
> one place. .forward is an obsolete mechanism from a decade ago.

	I'd almost agree with that, except that it would be nice if people
could set up things like vacation on their own (do you, as postmaster,
really want to change /usr/lib/aliases every time somebody goes on vacation
or comes back?)  Of course, the alternative is to have sendmail (or
whatever MTA you use) deal with vacation processing itself.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 19:02:57 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA08658@BLOOM-BEACON.MIT.EDU>; Thu, 19 Jan 89 18:56:07 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Jan 89 18:57:06 GMT
From: auspex!guy@uunet.uu.net  (Guy Harris)
Organization: Auspex Systems, Santa Clara
Subject: Re: Still trying to get smart routing working.
Message-Id: <868@auspex.UUCP>
References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>Always use /usr/lib/aliases, and concentrate all your network problems into
>one place. .forward is an obsolete mechanism from a decade ago.

"From a decade ago"? In other words, "sendmail" existed in early 1979?
News to me.  "delivermail" may have existed then, but as I remember it
had "/usr/lib/aliases" but *not* ".forward" files, so "/usr/lib/aliases"
*antedates* ".forward" files.

".forward" is not obsolete; it serves purposes other than to forward
mail from a user's "alternate" accounts to their "primary" account.  For
one thing, it lets you run all your mail through a filter, or a "mail
watcher" such as "vacation"....

(As for mounting everybody's home directory everywhere, while it isn't
necessary, it can sure be *convenient* at times - if I have to work on
several different machines, it's nice to be able to have my environment
travel with me.)

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Jan 89 22:17:52 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22955@BLOOM-BEACON.MIT.EDU>; Sat, 21 Jan 89 22:07:13 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Jan 89 11:39:21 GMT
From: mcvax!cernvax!ethz!solaris!wyle@uunet.uu.net  (Mitchell Wyle)
Organization: SOT Sun Cluster, Swiss Federal Institute of Tech.
Subject: simple encryption in mail
Message-Id: <508@solaris.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I am in need of a simple encryption scheme for mail messages which can
be used by many different mail readers.  I'd prefer if it could work
with mh, mailx, /usr/ucb/Mail, mm, and mush.  A simple "pager" such as
more with encryption built-in might do the trick.

A mail administrator (Hi Hannes!) here reads my mail as it goes out,
and I assume he reads mail when it arrives as well.  Please flame him
at: lubich%komsys.inf.ethz.ch@relay.cs.net or lubich@ethz.uucp.

There are some standards coming in this regard, but I'd prefer something
I can use now.  Thanks,  -Mitch (wyle@ethz.uucp)
-- 
-Mitchell F. Wyle                         wyle@ethz.uucp
Institut fuer Informationsysteme          wyle@inf.ethz.ch
ETH Zentrum / 8092 Zurich, Switzerland    +41 1 256 5237

Received: from Jester.CC.MsState.Edu (TCP 20204460100) by MC.LCS.MIT.EDU 23 Jan 89 11:56:46 EST
Received:  by Jester.CC.MsState.Edu (4.0/2.5);  id AA05549; Mon, 23 Jan 89 10:56:18 CST
Date: Mon, 23 Jan 89 10:56:18 CST
From: Frank W. Peters <peters@CC.MsState.Edu>
Message-Id: <8901231656.AA05549@Jester.CC.MsState.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Subscription

Greetings,

     Please add the mail sublist <header-people@MsState.Edu> to your mailing
list.  Please direct any problems to me at <peters@CC.MsState.Edu>.

     Please note that you may already have an existing distribution to me 
directly.  If so, please remove me when you add the new list.

                      Thank You
                      Frank Peters

=============================================================================
Systems Programmer                 |   Mississippi State University
Phone:    (601) 325-2942           |   Computing Center and Services
Internet:  peters@CC.MsState.Edu   |   Post Office Drawer CC
BITNET:    PETERS@MSSTATE.BITNET   |   Mississippi State, MS.  39759
=============================================================================


Received: from Jester.CC.MsState.Edu (TCP 20204460100) by MC.LCS.MIT.EDU 23 Jan 89 12:05:05 EST
Received:  by Jester.CC.MsState.Edu (4.0/2.5);  id AA05571; Mon, 23 Jan 89 11:04:40 CST
Date: Mon, 23 Jan 89 11:04:40 CST
From: Frank W. Peters <peters@CC.MsState.Edu>
Message-Id: <8901231704.AA05571@Jester.CC.MsState.Edu>
To: header-people@mc.lcs.mit.edu
Subject: Apology

Please forgive the subscription request which I inadvertantly sent to the 
entire mailing list.  I really do know better.


               Frank Peters

=============================================================================
Systems Programmer                 |   Mississippi State University
Phone:    (601) 325-2942           |   Computing Center and Services
Internet:  peters@CC.MsState.Edu   |   Post Office Drawer CC
BITNET:    PETERS@MSSTATE.BITNET   |   Mississippi State, MS.  39759
=============================================================================

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Jan 89 19:33:37 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03110@BLOOM-BEACON.MIT.EDU>; Mon, 23 Jan 89 19:31:12 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Jan 89 14:05:08 GMT
From: cunyvm!maine.bitnet!michael@psuvm.bitnet
Organization: University of Maine System
Subject: Re: simple encryption in mail
Message-Id: <1119MICHAEL@MAINE>
References: <508@solaris.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I can't quite tell where you are located, but if it is inside the USA then your
mail administrator should know that by reading your mail as it comes and goes
he is (unless he can reasonably cite system security, which I doubt) breaking
the law. There is a law in this country (PL99-508, "The Electronic
Communications Privacy Act of 1986") that specifically prohibits intercepting
and reading of electronic mail and other forms of electronic communication.
You could probably sue him and win on the grounds of privacy invasion.

Secondly, a good simple encryption scheme is ROT-13, but it does not require
a key, so your administrator could also decrypt your stuff, assuming he reads
this and wants to continue his illegal activity. Just rotate each alphabetic
letter through the alphabet 13 positions. Thus, 'A' becomes 'N' and 'Z' becomes
'M', etc. To reverse it, simply do the same rotation again and things go back
to their previous state.

Hope this helps you.

Michael Johnson                           "We are the Priests of the Temples
University of Maine System                 of Syrinx. Our great computers fill
Computing and Data Processing Services     the hallowed halls." - Neil Peart

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Jan 89 17:19:32 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA27243@BLOOM-BEACON.MIT.EDU>; Tue, 24 Jan 89 17:02:53 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Jan 89 20:14:02 GMT
From: mailrus!cwjcc!hal!nic.MR.NET!shamash!raspail!steve@ohio-state.arpa  (Steve Schonberger)
Organization: Control Data Corporation, Arden Hills, MN
Subject: Re: simple encryption in mail
Message-Id: <1178@raspail.UUCP>
References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes:
> I can't quite tell where you are located, but if it is inside the USA then
> your mail administrator should know that by reading your mail as it comes
> and goes he is (unless he can reasonably cite system security, which I doubt)
> breaking the law. There is a law in this country (PL99-508, "The Electronic
> Communications Privacy Act of 1986") that specifically prohibits intercepting
> and reading of electronic mail and other forms of electronic communication.

This is not correct.  Any place that provides mail may choose whether to be
follow this law or not.  The law is that a mail provider must do everything
possible to ensure the privacy of communications if they say their mail is
private.  By saying their mail is private, they bring themselves under the
same body of law that keeps the Post Office and telephone companies from
inspecting communications that they pass.

The advantage of this to a mail provider is that having the provider legally
bound to be secure is a good selling point, because people like secure mail. 
The disadvantage is that they are liable for criminal (not just civil)
penalties if they breach that privacy, and possibly civil penalties if someone
outside their organization invades their privacy through flaws in their
security.

If someone is unable to provide communication security comparable to a
telephone conversation (the case with _all_ mail going through the net),
doesn't want to bother making it that secure (the case within most sites),
or just doesn't want to put themselves at legal risk, they can state that
their system is not guaranteed secure, at which point they can do whatever
they feel like to their mail.

A lot of local bulletin board systems I use have statements saying that it is
not their policy to read or alter mail, but that they refuse to guarantee that
it is secure.  By saying this they free themselves of any legal responsibility
connected with that law.

I do not know what that law says about the default case.  In other words, I
am not sure if a mail provider is assumed to guarantee privacy if they don't
specifically disclaim it, or if they are assumed to disclaim it unless they
specifically guarantee it.  I'd be curious to know, if anyone can provide a
direct quote of the law on that matter.

To bring this all back to the topic of this newsgroup, I think that the only
way you can expect mail to be private, legal guarantees or not, is to encrypt
it.  A standard mail header to indicate encryption would be a good thing,
though the message looking like garbage data accomplishes the same thing.

	Steve Schonberger
	steve@raspail.uucp	raspail!steve@shamash.cdc.com
	...!uunet!rosevax!shamash!rapail!steve

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 26 Jan 89 16:18:25 EST
Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by XX.LCS.MIT.EDU with TCP/SMTP; Thu 26 Jan 89 09:19:14-EST
To: header-people@mc.lcs.mit.edu
Subject: SIGCOMM Call for papers
Date: Thu, 26 Jan 89 08:48:19 -0500
From: Craig Partridge <craig@NNSC.NSF.NET>



                      CALL FOR PAPERS
                 ACM SIGCOMM '89 SYMPOSIUM
         Communications Architectures and Protocols
                       Austin, Texas
                   September 20-22, 1989
                 (Tutorials September 19th)

The  symposium  provides  an  international  forum  for  the
presentation  and discussion of communication network appli-
cations and technologies, as well  as  recent  advances  and
proposals  on  communication architectures, protocols, algo-
rithms, and performance models.  Authors are invited to sub-
mit  full  papers  concerned  with both theory and practice.
The areas of interest for the symposium include, but are not
limited  to  the  following: analysis and design of computer
network architectures and algorithms, innovative results  in
local  area networks, computer-supported collaborative work,
network interconnection and mixed-media networks, high-speed
networks,  resource  sharing in distributed systems, distri-
buted operating systems and databases,  protocol  specifica-
tion, verification, and analysis.

Papers should be  about  20  double-spaced  pages  long  and
should  have  an  abstract  of 100-150 words.  All submitted
papers will be reviewed and will be judged with  respect  to
their  quality  and  relevance.   Authors of accepted papers
will be expected to sign an ACM copyright release form.  The
Proceedings  will  be  distributed at the symposium and pub-
lished as a special issue of SIGCOMM Computer  Communication
Review.   A few of the submitted papers will be selected for
publication in the ACM Transactions on Computer Systems.

Submit 5 copies of each paper to the program  chairman:  Dr.
Mohamed  Gouda,  Computer Sciences Department, University of
Texas at Austin, Austin  TX  78712,  USA;  Telephone:  (512)
471-9532; EMAIL: gouda@cs.utexas.edu

For more information about the symposium, contact  Dr.  L.H.
Landweber,  General  Chair, Computer Sciences Dept., Univer-
sity of Wisconsin, 1210 W. Dayton St.,  Madison,  WI  53706;
Tel: (608) 262-1204; EMAIL: landweber@cs.wisc.edu.

                    STUDENT PAPER AWARD

Papers submitted by  students  will  enter  a  student-paper
award contest.  Among the accepted papers, a maximum of four
outstanding papers  will  be  awarded  (1)  full  conference
registration and (2) a travel grant of $500 US dollars.

                      IMPORTANT DATES

Deadline for paper submission: March 20, 1989
Notification of acceptance:  May 19, 1989
Camera-ready manuscript due: June 19, 1989

                    SYMPOSIUM COMMITTEE

General Chair:  L.H. Landweber, University of Wisconsin, USA
Program Chair:  M. Gouda, University of Texas, USA
Local Arrangements: M. Gouda, University of Texas, USA

------- End of Forwarded Message


Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Jan 89 12:54:32 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 26 Jan 89 23:36:03-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19058@BLOOM-BEACON.MIT.EDU>; Thu, 26 Jan 89 23:29:10 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Jan 89 03:44:57 GMT
From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu  (Steve Dempsey)
Organization: Colorado State University, Fort Collins, CO  80523
Subject: Re: simple encryption in mail (no more legal discussion)
Message-Id: <1073@ccncsu.ColoState.EDU>
References: <1178@raspail.UUCP>, <508@solaris.UUCP>, <1119MICHAEL@MAINE>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


In article <1178@raspail.UUCP>, steve@raspail.UUCP (Steve Schonberger) writes:
> In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes:
>> [in article <508@solaris.UUCP>  wyle@solaris.UUCP (Mitchell Wyle) writes:]
>> [looking for a simple encrypton method because his mail is watched]
>
>  [lengthy discussion about legal aspects of the SA's rights & wrongs
>           regarding interception and perusal of private mail DELETED]

Ok, this poor fellow asks for a simple way to protect his private e-mail,
and what does he get?  A meta-discussion on legalities.  Well, here is
my suggestion for implementing the simple encryption in a UNIX environment:

The sender:

 % crypt < msg.txt > cypher               (use previously agreed-upon key)
 % uuencode cypher < cypher > cypher.uu
 % mail whoever@wherever -s crypted_message < cypher.uu

The recipient:

 % mail                      (receive mail, save in appropriate file)
 % uudecode cypher.uu
 % crypt < cypher > msg.txt    (must have same key as sender)
 % more msg.txt
 
Simple enough?  Of course, you'll have to communicate the crypt key by
some other means in advance.


        Steve Dempsey,  Center for Computer Assisted Engineering
  Colorado State University, Fort Collins, CO  80523    +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 28 Jan 89 06:34:38 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15704@BLOOM-BEACON.MIT.EDU>; Sat, 28 Jan 89 03:51:58 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Jan 89 03:38:39 GMT
From: ndcheg!ndmath!krueger@iuvax.cs.indiana.edu  (Andreas Krueger)
Organization: Math. Dept., Univ. of Notre Dame
Subject: Re: simple encryption in mail (no more legal discussion)
Message-Id: <1298@ndmath.UUCP>
References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <1073@ccncsu.ColoState.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1073@ccncsu.ColoState.EDU>, steved@longs.LANCE.ColoState.Edu (Steve Dempsey) writes:
 > 
 >In article <1178@raspail.UUCP>, steve@raspail.UUCP (Steve Schonberger) writes:
 > >In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes:
 > >> [in article <508@solaris.UUCP>  wyle@solaris.UUCP (Mitchell Wyle) writes:]
 > >> [looking for a simple encrypton method because his mail is watched]
 > >
 > >  [lengthy discussion about legal aspects of the SA's rights & wrongs
 > >           regarding interception and perusal of private mail DELETED]
 > 
 > Ok, this poor fellow asks for a simple way to protect his private e-mail,
 > and what does he get?  A meta-discussion on legalities.  Well, here is
 > my suggestion for implementing the simple encryption in a UNIX environment:
 > 
 > [A few lines of commands using "crypt" which would do the job]

Unfortunately, legal aspects aren't quite over if this poor
fellow is not in the US, for (quote from man crypt):

 > RESTRICTIONS
 >      This program is not available on  software  shipped  outside
 >      the U.S.


krueger@ndmath.math.nd.edu
(* Disclaimer: Restrictions quoted herein are not my own *)

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Jan 89 13:42:21 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sun 29 Jan 89 04:05:44-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA07087@BLOOM-BEACON.MIT.EDU>; Sun, 29 Jan 89 03:58:08 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Jan 89 07:37:51 GMT
From: sargas.usc.edu!tli@oberon.usc.edu  (Tony Li)
Organization: University of Southern California, Los Angeles, CA
Subject: Re: simple encryption in mail (no more legal discussion)
Message-Id: <15005@oberon.USC.EDU>
References: <1119MICHAEL@MAINE>, <1073@ccncsu.ColoState.EDU>, <1298@ndmath.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


Crypt isn't the best thing to use.  There's a package called Crypt
Breakers Workbench that has been posted which is quite useful when
trying to break a crypt'ed file.

Tony Li - USC University Computing Services - Dain Bramaged.
Uucp: oberon!tli						
Bitnet: tli@kylara, tli@ramoth
Internet: tli@sargas.usc.edu

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Jan 89 20:20:46 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05044@BLOOM-BEACON.MIT.EDU>; Tue, 31 Jan 89 20:11:57 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Jan 89 07:39:47 GMT
From: avsd!childers@bloom-beacon.mit.edu  (Richard Childers)
Organization: die Edelstahlratte
Subject: administration fascism
Message-Id: <445@avsd.UUCP>
References: <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>, <1715@helios.ee.lbl.gov>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

leres@helios.ee.lbl.gov (Craig Leres) writes:

>Richard Childers writes:

>> When I find .forward files in the LAN ... I cat /dev/null into them and
chown them to root and chmod the sucker to 444 and that's that.

>This sounds gratuitously fascist to me. Luckly, it's not hard to remove
>such a file ...

But it is impossible to edit it until it is removed, and provokes the required
dialogue between user and administrator ... which is all I ask.

>The advanced reader might want to use "rm -f .forward"

One presumes that the advanced reader doesn't mangle his .forward ...

Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
by the world. But if you can't trust your users to edit /usr/lib/aliases, then
you probably can't trust them to edit .forward, either.

>		Craig

-- richard


-- 
 *                    -= If it works, it must be a Fluke =-                   *
 *                                                                            *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Jan 89 23:20:55 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA07598@BLOOM-BEACON.MIT.EDU>; Tue, 31 Jan 89 23:15:33 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 89 03:56:56 GMT
From: unmvax!unmvax.cs.unm.edu!mike@bloom-beacon.mit.edu  (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Subject: Re: administration fascism
Message-Id: <2253@unmvax.unm.edu>
References: <412@avsd.UUCP>, <1715@helios.ee.lbl.gov>, <445@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:

>One presumes that the advanced reader doesn't mangle his .forward ...
>
>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>you probably can't trust them to edit .forward, either.


Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
/usr/lib/aliases.  If someone f*cks up, then we have the simple solution
of asking "who changed the XXX alias to YYY?" and then we can explain to
them the necessity of being more careful in the future.

But if we decided that people were not trustable, then there is a hell of
a difference between mangling your OWN .forward (which only screws up your
own mail) and mangling /usr/lib/aliases (which can steal other peoples' mail,
break vital mailing lists, etc.).  

In short, it may be quite rational to protect users from eachother (by
protecting /usr/lib/aliases), but it IS facism to "protect" people from
themselves.
  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Feb 89 09:15:02 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12478@BLOOM-BEACON.MIT.EDU>; Wed, 1 Feb 89 04:30:26 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 89 05:01:14 GMT
From: bionet!agate!helios.ee.lbl.gov!ace.ee.lbl.gov!leres@csd4.milw.wisc.edu  (Craig Leres)
Organization: Lawrence Berkeley Laboratory, Berkeley
Subject: Re: administration fascism
Message-Id: <1818@helios.ee.lbl.gov>
References: <445@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Several weeks ago, Richard Childers wrote:
> When I find .forward files in the LAN ... I cat /dev/null into them and
> chown them to root and chmod the sucker to 444 and that's that.

Shortly after, I wrote:
> This sounds gratuitously fascist to me. Luckly, it's not hard to remove
> such a file ...

More recently Richard Childers writes:
> But it is impossible to edit it until it is removed, and provokes the required
> dialogue between user and administrator ... which is all I ask.

When one of my users botches his/her .forward file (this is a rare
event, perhaps my users are smarter than yours) I find that mail(1)
provides an interface that is completely sufficient to "provoke"
dialogue with the user. Not once have I had to play power games with
superuser privileges to achieve this goal.

		Craig

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Feb 89 17:36:01 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA25896@BLOOM-BEACON.MIT.EDU>; Wed, 1 Feb 89 17:18:28 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 89 13:12:58 GMT
From: texbell!uhnix1!sugar!karl@bellcore.bellcore.com  (Karl Lehenbauer)
Organization: Sugar Land Unix - Houston, TX
Subject: Re: administration fascism
Message-Id: <3376@sugar.uu.net>
References: <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>, <2253@unmvax.unm.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
> Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
> /usr/lib/aliases.  If someone f*cks up, then we have the simple solution
> of asking "who changed the XXX alias to YYY?" and then we can explain to
> them the necessity of being more careful in the future.

Thus the cost of providing the flexibility of letting people edit 
/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes
a little, sometimes a lot.  I don't know if I would call this policy 
"enlightened."  I would say it balances things a little more toward 
ease-of-use at the cost of reducing reliability.  Why do they need to
edit /usr/lib/aliaes anyway?  How often does this happen?
-- 
-- uunet!sugar!karl  | "We've been following your progress with considerable 
-- karl@sugar.uu.net |  interest, not to say contempt."  -- Zaphod Beeblebrox IV
-- Usenet BBS (713) 438-5018

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Feb 89 19:21:01 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA27856@BLOOM-BEACON.MIT.EDU>; Wed, 1 Feb 89 19:03:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 89 23:22:39 GMT
From: unmvax!unmvax.cs.unm.edu!mike@bloom-beacon.mit.edu  (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Subject: Re: administration fascism
Message-Id: <2254@unmvax.unm.edu>
References: <412@avsd.UUCP>, <2253@unmvax.unm.edu>, <3376@sugar.uu.net>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3376@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes:
>In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
>> Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
>> /usr/lib/aliases.  If someone f*cks up, then we have the simple solution
>> of asking "who changed the XXX alias to YYY?" and then we can explain to
>> them the necessity of being more careful in the future.
>
>Thus the cost of providing the flexibility of letting people edit 
>/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes
>a little, sometimes a lot.  I don't know if I would call this policy 
>"enlightened."  I would say it balances things a little more toward 
>ease-of-use at the cost of reducing reliability.  Why do they need to
>edit /usr/lib/aliaes anyway?  How often does this happen?

They (the faculty) maintain several mail aliases for various groups.
They even *create* such aliases relatively frequently.  No one's
*ever* screwed up anyone else's mail.  This makes creating mailing
lists easy for arbitrary users.
  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  1 Feb 89 19:21:18 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA27613@BLOOM-BEACON.MIT.EDU>; Wed, 1 Feb 89 18:52:59 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 89 18:52:00 GMT
From: auspex!guy@uunet.uu.net  (Guy Harris)
Organization: Auspex Systems, Santa Clara
Subject: Re: administration fascism
Message-Id: <926@auspex.UUCP>
References: <412@avsd.UUCP>, <1715@helios.ee.lbl.gov>, <445@avsd.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

>But it is impossible to edit it until it is removed, and provokes the required
>dialogue between user and administrator ... which is all I ask.

Maybe yes, maybe no; they may just get ticked off, as I presume Mr. 
Leres would (and as I probably would, too), and just remove it without
talking to the administrator. 

>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>you probably can't trust them to edit .forward, either.

Incorrect.  You can screw more people by monkeying with
"/usr/lib/aliases" than you can by editing ".forward"; by editing the
former you can foul up the delivery of mail to people other than
yourself without their consent.

Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU  3 Feb 89 08:20:30 EST
Received: from gallua.bitnet by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7711; Fri, 03 Feb 89 08:20:19 EST
Date: Fri, 3 Feb 89 08:19 EST
From: "E. Remington" <CADS_REMINGT%GALLUA.BITNET@CUNYVM.CUNY.EDU>
Subject: INFORMATION
To: HEADER-PEOPLE@MC.LCS.MIT.EDU
X-VMS-To: IN%"HEADER-PEOPLE@MC.LCS.MIT.EDU"



Hi, my name is Elizabeth Remington.  I am writing to you from Gallaudet
University in D.C.  I am new to the bitnet and arpanet systems and I am trying
to find get more information on gateways and how they work.  I am trying to
reach a person in London on what I believe is called a PSDN (public service
data network ?), specifically Primenet.

If you know anyone I could contact who may have any ideas or a direction I
could look in please let me know.  Thanks for your help.

Elizabeth

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  4 Feb 89 11:37:00 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06017@BLOOM-BEACON.MIT.EDU>; Sat, 4 Feb 89 11:22:57 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Feb 89 21:05:15 GMT
From: mcvax!hp4nl!uva!dik@uunet.uu.net  (Casper H.S. Dik)
Organization: Faculteit Wiskunde & Informatica, Universiteit van Amsterdam
Subject: Re: administration fascism
Message-Id: <608@uva.UUCP>
References: <1715@helios.ee.lbl.gov>, <445@avsd.UUCP>, <2253@unmvax.unm.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <2253@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:
>In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes:
>
>>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable
>>by the world. But if you can't trust your users to edit /usr/lib/aliases, then
>>you probably can't trust them to edit .forward, either.
>
>
>Hmmm...I disagree.  We are an "enlightened" site which lets people edit 
>/usr/lib/aliases.  If someone f*cks up, then we have the simple solution
>of asking "who changed the XXX alias to YYY?" and then we can explain to
>them the necessity of being more careful in the future.

Hmmm... you must trust your users very much.
People can not only steal other peoples mail, but can add an alias like
myalias: |/myhome/myprogram

The program /myhome/myprogram will be executed with the uid sendmail uses
for untrusted mailers. If it is daemon (it is on my systems) the user
could then 'do some things I will not disclose here' and become root
in a matter of minutes.

At that point he can do more damage to your system than you can repair
in the time saved by letting your users edit /usr/lib/aliases.

>In short, it may be quite rational to protect users from eachother (by
>protecting /usr/lib/aliases), but it IS facism to "protect" people from
>themselves.

Agreed

>  Michael I. Bushnell       \     This above all; to thine own self be true
>         GIG!                \    And it must follow, as the night the day,
>mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
>  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!


____________________________________________________________________________
Casper H.S. Dik
University of Amsterdam     |		      dik@uva.uucp
The Netherlands             |                 ...!uunet!mcvax!uva!dik

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  4 Feb 89 17:22:09 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10854@BLOOM-BEACON.MIT.EDU>; Sat, 4 Feb 89 17:07:04 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Feb 89 21:53:51 GMT
From: unmvax!turing.cs.unm.edu!mike@bloom-beacon.mit.edu  (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Subject: Re: administration fascism
Message-Id: <2264@unmvax.unm.edu>
References: <445@avsd.UUCP>, <2253@unmvax.unm.edu>, <608@uva.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <608@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes:

>Hmmm... you must trust your users very much.
>People can not only steal other peoples mail, but can add an alias like
>myalias: |/myhome/myprogram

Our goal for security is to prevent users from doing accidental
damage.  We can restore the system from tape in a matter of
hours--with little loss of data.  The offending person is easily
determined, and we can easily use administrative means to can them.  

>The program /myhome/myprogram will be executed with the uid sendmail uses
>for untrusted mailers. If it is daemon (it is on my systems) the user
>could then 'do some things I will not disclose here' and become root
>in a matter of minutes.

In the interests of letting people know what we mean, you could, for
example, modify the atq and have jobs executed as root.  The atq is,
on most systems, owned by daemon, so daemon can modify it and have
jobs run under any uid.

>At that point he can do more damage to your system than you can repair
>in the time saved by letting your users edit /usr/lib/aliases.

As I said, not too much damage.  We don't worry.  Administrative
control is far better than online security.

  Michael I. Bushnell       \     This above all; to thine own self be true
         GIG!                \    And it must follow, as the night the day,
mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  4 Feb 89 23:07:09 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15723@BLOOM-BEACON.MIT.EDU>; Sat, 4 Feb 89 22:56:53 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Feb 89 18:25:50 GMT
From: mcvax!kth!enea!maxim!prc@uunet.uu.net  (Robert Claeson)
Organization: ERBE DATA AB
Subject: Re: simple encryption in mail (no more legal discussion)
Message-Id: <485@maxim.ERBE.SE>
References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <1298@ndmath.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1298@ndmath.UUCP>, krueger@ndmath.UUCP (Andreas Krueger) writes:

> Unfortunately, legal aspects aren't quite over if this poor
> fellow is not in the US, for (quote from man crypt):
> 
>  > RESTRICTIONS
>  >      This program is not available on  software  shipped  outside
>  >      the U.S.

So let's  use DES instead. Even though not included in the export versions
of UNIX, it's  universally available and the algorithms are  well-known.
One can even use it to send mail to Russia :-).
-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
"No problems." -- Alf
Tel: +46 758-202 50  EUnet:    rclaeson@ERBE.SE  uucp:   uunet!erbe.se!rclaeson
Fax: +46 758-197 20  Internet: rclaeson@ERBE.SE  BITNET: rclaeson@ERBE.SE

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU  6 Feb 89 12:13:53 EST
Received: by INFOODS id <0000224F061@INFOODS.MIT.EDU> ;
       Sun,  5 Feb 89 12:44:33 EST
Date: Sun,  5 Feb 89 12:00:32 EST
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re: 'administration fascism', alias files, etc.
To: header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu"
Message-ID: <890205120032.0000224F061@INFOODS.MIT.EDU>

People,
  I am not familiar with the intimate details of sendmail operation, but 
it may be that (a) this conversation chain has gone on about long enough 
in this list, especially since it is no longer a discussion relevant to 
the list (if it ever was) and (b) that an observation from "outside"
might be useful. 

Summary of where I think the dialogue stands:
  - Letting users edit these files in arbitrary ways is quite dangerous.
A moderately smart and slightly malicious user, or one who is trying to
prove system insecurity, can manage the alias file in ways that provide
enough privilege and access to pretty well damage a system and destroy
and/or browse other user's files. 
  - At the same time, considerable system convenience can be realized, 
and inconvenience to both users and system administrators avoided, if 
users are permitted to edit their own records.
  - For at least some installations, backup arrangements are considered 
adequate to rapidly restore the system and user files from any damage 
caused by accidental or malicious damage, and post hoc administrative 
sanctions are considered an adequate remedy for any malicious or 
repeated problems.  For those installations, convenience may outweigh 
security/privacy.

Now, two suggestions:
 (1) Move this discussion elsewhere.  Many of us who are interested in 
headers and related issues are not terribly interested in this 
discussion.  More important, there are probably lots of people in the 
U**X/sendmail communities who are, or should be, very interested in this 
discussion but are not seeing it because they are not interested in 
header issues (or think that they aren't).  On the other hand, please 
let's avoid a discussion chain on appropriateness: if the participants 
in this chain disagree, please just ignore this remark.
 (2) Multics provides an extremely straightforward way to deal with 
problems like this one that both provides the convenience and avoids the 
potential risks.  It has parallels on several other systems (some of 
them otherwise fairly retarded, and should be easily simulated on UNIX). 
You don't give "users" access to modify the file.  You do give that 
access to a special user, or to a daemon.  "Users" make changes in their 
entries by sending a message to the special user that says "please edit 
my entry to read....".  The special user or daemon searches the file, 
finds the entry for the submitting user, and alters it as requested.  
Assuming that the special user or daemon can adequately authenticate the 
sender on your particular system (if you can't do that, you have other 
problems),  this effectively gives anyone the ability to change his or 
her own entry.  It effectively prevents anyone but a system 
administrator from changing anyone else's entry and, if you feel a need 
to do so, permits you to use the special user or daemon to filter what 
types of change request are permitted.
  Now, if this is a big issue, why doesn't someone do something about 
it?
    John Klensin     Klensin@INFOODS.MIT.EDU


Received: from oodis01.arpa (TCP 3202400024) by MC.LCS.MIT.EDU  6 Feb 89 19:10:49 EST
Return-Path: <kerr>
Received: by oodis01.arpa
	id AA25747; Mon, 6 Feb 89 10:50:48 MST
Message-Id: <8902061750.AA25747@oodis01.arpa>
Date: Mon Feb 6 10:50:46 1989
From: kerr@oodis01.arpa (Grant Kerr)
Subject: Return-receipt-to header field
To: header-people@mc.lcs.mit.edu
Return-Receipt-To: kerr@oodis01.arpa
Status:  N 

It seems that some mail systems send messages to the message originator 
when a user and/or system receives a mail message.  On our system it uses 
the "Return-receipt-to:" header to do this function.  What systems support this?
Does any RFC refer to this header field? (I couldn't find one)

grant
(kerr@oodis01.arpa)

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  7 Feb 89 21:04:46 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 08:54:55-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05853@BLOOM-BEACON.MIT.EDU>; Tue, 7 Feb 89 08:41:42 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Feb 89 13:41:22 GMT
From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa  (Karl Kleinpaste)
Organization: OSU
Subject: Re: administration fascism
Message-Id: <KARL.89Feb7084122@triceratops.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

comp.mail.headers, right?  Yeah, I thought so.  There *is* a
comp.mail.misc, folks.

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  7 Feb 89 21:04:46 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 08:54:55-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05853@BLOOM-BEACON.MIT.EDU>; Tue, 7 Feb 89 08:41:42 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Feb 89 13:41:22 GMT
From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa  (Karl Kleinpaste)
Organization: OSU
Subject: Re: administration fascism
Message-Id: <KARL.89Feb7084122@triceratops.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

comp.mail.headers, right?  Yeah, I thought so.  There *is* a
comp.mail.misc, folks.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  7 Feb 89 23:57:58 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA21164@BLOOM-BEACON.MIT.EDU>; Tue, 7 Feb 89 23:51:13 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Feb 89 04:07:24 GMT
From: helios.ee.lbl.gov!ace.ee.lbl.gov!leres@nosc.mil  (Craig Leres)
Organization: Lawrence Berkeley Laboratory, Berkeley
Subject: Re: administration fascism
Message-Id: <1875@helios.ee.lbl.gov>
References: <KARL.89Feb7084122@triceratops.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Karl Kleinpaste writes:
> comp.mail.headers, right?  Yeah, I thought so.  There *is* a
> comp.mail.misc, folks.

Why so uptight, Karl? Too much caffeine?

		Craig

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  8 Feb 89 04:49:51 EST
Received: from po3.andrew.cmu.edu by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 12:17:48-EST
Received: by po3.andrew.cmu.edu (5.54/3.15) id <AA03479> for header-people@mc.lcs.mit.edu; Tue, 7 Feb 89 11:53:27 EST
Received: via switchmail; Tue,  7 Feb 89 11:53:18 -0500 (EST)
Received: from larimer.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.wXvltWy00Uk409pWtd>;
          Tue,  7 Feb 89 11:50:48 -0500 (EST)
Received: from Messages.7.2.N.CUILIB.3.45.SNAP.NOT.LINKED.larimer.andrew.cmu.edu.rt.r3
          via MS.5.6.larimer.andrew.cmu.edu.rt_r3;
          Tue,  7 Feb 89 11:50:38 -0500 (EST)
Message-Id: <0XvltSy00Uk4I9pW8S@andrew.cmu.edu>
Date: Tue,  7 Feb 89 11:50:38 -0500 (EST)
From: Nathaniel Borenstein <nsb+@andrew.cmu.edu>
X-Andrew-Message-Size: 8833+0
To: kerr@oodis01.arpa (Grant Kerr)
Subject: Re: Return-receipt-to header field
Cc: header-people@mc.LCS.MIT.EDU, "Craig F. Everhart" <cfe+@andrew.cmu.edu>
In-Reply-To: <8902061750.AA25747@oodis01.arpa>
References: <8902061750.AA25747@oodis01.arpa>

Well, the Andrew Message System implements one such feature.  We got some way
towards writing up an RFC, and then sort of tailed off, but for what it is
worth, here is what we wrote up about it circa 2 years ago -- the format is
Scribe input, but it should be pretty readable anyway.

Nathaniel S. Borenstein
Manager, Andrew Applications Development
Information Technology Center
Carnegie Mellon University

@b(RFC XXX)

@center[An end-to-end delivery notification feature for ARPA Internet Messages

Nathaniel S. Borenstein
Craig F. Everhart
Information Technology Center
Carnegie-Mellon University
Pittsburgh, Pennsylvania, 15213

nsb+@@andrew.cmu.edu

Abstract

@quotation[A standardized Ack-To field allows mail reading systems to implement
a "confirmation" feature whereby the users can request confirmation that a piece
of mail has actually been received by the recipient.   The type of confirmation
defined for the User-Reciept-To feature is "end-to-end" in the sense that it
confirms actual receipt by the final reader (the human being) rather than the
completion of some stage of the delivery process (e.g. the entry of the message
into the recipient's mailbox).  The feature has been designed to conform to the
Internet mail standard RFC 822 and to be plausibly converted to and from the
X.400 Delivery Notification service at future SMTP-X.400 gateways.  This
proposal calls for the creation of three new standard Intenet mail headers,
"Ack-To", "Ack-type", and "Ack"]]

@Section(Introduction )

This RFC proposes a new addition to the set of standard headers which may appear
in Internet mail as defined by RFC 822.  The purpose of the new "Ack-To" header
is to facilitate confirmation that  a message has indeed been delivered to its
intended recipient.

Although the feature appears simple, it has been carefully designed to meet a
few key criteria:

@begin(itemize)
Conformity to RFC 822

Interoperability with X.400

Non-interference with the functioning of mail systems that do not implement the
feature.

Independence from other types of confirmation schemes with different semantics,
which have been implemented independently.
@end(itemize)

The last criterion is necessary because there has been and continues to be a
significant amount of disagreement regarding the most desirable form of delivery
notification.  Some efforts have been made in the past, such as the 4.2/3 BSD
sendmail program's use of the "Return-Reciept-To" header, which requests
automatic notification of the completion of key steps in the delivery process.
Rather than assert that the "end-to-end" return receipt proposed in this
document is the "correct" form of delivery notification, we simply offer it as
an alternative, to be implemented by those systems that regard it as desirable.

@Section(Alternative Models for Delivery Notification)

Ideally, a delivery notification mechanism would provide a one-to-one mapping
onto successful deliveries:  if the user receives a delivery notification, he
could be certain that the message had been delivered, and if the notification
never arrived, he could be certain the message had never been delivered.

Unfortunately, this ideal mechanism is rendered virtually impossible by the
fundamental uncertainty of internetwork mail delivery, which is of course itself
one of the major motivating factors in providing such a service.  Since it is
always conceivable that mail will be lost, it is always conceivable that mail
confirming successful delivery will be lost.   While one can imagine mechanisms
that would guarantee this mapping, their implementation would be essentially as
hard as implementing completely reliable mail delivery in the first place.   In
the absence of any medium-term prospects of such reliability, a useful delivery
notification scheme should be designed to be much easier to implement.

Given that the ideal guarantee can not be made, an alternative is to guarantee
that the receipt of a delivery notification implies that the recipient received
the mail, but to make no guarantees about the absence of receipt.  That is the
position taken in this proposal.

Another point where notions of delivery confirmation may differ is in the point
at which the confirmation is generated.  The two major choices here are
confirmation of delivery and confirmation of human receipt.  In the former case,
the receipt guarantees simply that the message was put somewhere (e.g. a
mailbox) where the user could be expected to find it.  In the latter case, the
position specified in this proposal, the receipt guarantees that the message was
actually seen by the human recipient.  (Of course, no guarantee can be made that
the right human being read the message, especially given the unatuthenticated
nature of internetwork mail, but the recipient's identity should be checked to
the extent that the authentication facilities on the recipient's system permit.)
 The receipt by human being was selected for this proposal because it seems the
stronger of the two guarantees, and is well within the implementation
capabilities of most mail systems.

In order to better accommodate the mix of possible acknowledgement types, a
third, optional header is defined, the "Ack-type" header.  If present, this
field indicates the type of acknowledgement being provided, as indicated below.

@Section(Specification of the Ack-To header)

The User-Reciept-To header has a syntax identical to the Reply-To header, as
defined in RFC 822.  It specifies a destination address to which the delivery
confirmation should be mailed.   It may be identical to the From or Reply-To
header, but need not be.

When a User-Reciept-To header is used, a Message-ID header is required.

@Section(Specification of the Ack-Type header)

The Ack-Type header is optional.  If provided, it should have one of a small set
of designated values, indicated the type of confirmation being provided.  In
particular, "Ack-type: explicit" indicates that the mail was actually read by
the human user and that the user explicitly agreed to send the acknowledgement.
 Other values for the Ack-type field should be published as needed.

@section(Specification of the Delivery Notification Message)

When the user agent in a mail system shows a user a new message requesting
confirmation with the Ack-To header, it may generate a corresponding delivery
notification message.   (The term "may" implies not only that many mail systems
may not implement this feature, but also that some may choose to give the user
the option of sending or not sending such a confirmation.)  In this case, it
will send a message to the destination address specified in the Ack-To header.
That message should contain a "Ack" header, the contents of which should be
simply the Message-ID header of the message being confirmed.

In addtion, it is recommended that, for the benefit of users of mail systems
that do not automatically correlate return-reciepts, two additional steps be
taken in the composition of the confirmation message.  First, the Subject header
should be composed of the word "Confirming: " followed by the subject of the
original message.  Second, the body of the message should contain a suitable
explanatory phrase, one that will be meaningful if read by a human being.  A
sample can be found in the following section.

Finally, it is recommended that, when the delivery notification message is sent,
the user agent makes some note of the fact in order to prevent the sending of a
duplicate notification message in the future.

@section(Example)

The following shows a matched pair of messages, the first requesting delivery
notification, and the second (presumably automatically generated) providing it.

@begin(programexample)
From: Nathaniel Borenstein <nsb+@@andrew.cmu.edu>
Subject: How are you?
Date: Sun, 25 Oct 87 09:46:54 -0500 (EST)
To: "Craig F. Everhart" <cfe+@@andrew.cmu.edu>
Ack-To: Nathaniel Borenstein <nsb+receipts@@andrew.cmu.edu>
Message-ID: <MVTvxNyOOWAKRYA07p@@andrew.cmu.edu>

Hi, Craig.  This is just a test of the user-receipt feature.

- Nathaniel



From: "Craig F. Everhart" <cfe+@@andrew.cmu.edu>
Subject: Confirming: How are you?
Date: Sun, 25 Oct 87 10:46:54 -0500 (EST)
To: Nathaniel Borenstein <nsb+receipts@@andrew.cmu.edu>
Ack: <MVTvxNyOOWAKRYA07p@@andrew.cmu.edu>
Message-ID: <NACvx0078@@andrew.cmu.edu>

This message confirms the receipt by "Craig F. Everhart"
of a message from "Nathaniel Borenstein <nsb+@@andrew.cmu.edu>"
on the subject "How are you?"
dated "Sun, 25 Oct 87 09:46:54 -0500 (EST)".

This is an "explicit" receipt, which means that the user
saw the message and agreed to send this confirmation.
@end(programexample)

@section(References)

1.  Crocker, David H. RFC 822: Standard for the Format of ARPA Internet Text
Messages.  Network Information Center, August 13, 1982.




Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  8 Feb 89 21:56:34 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 8 Feb 89 14:43:49-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA04024@BLOOM-BEACON.MIT.EDU>; Wed, 8 Feb 89 14:25:16 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Feb 89 03:22:43 GMT
From: avsd!childers@bloom-beacon.mit.edu  (Richard Childers)
Organization: die Edelstahlratte
Subject: Re: administration fascism
Message-Id: <463@avsd.UUCP>
References: <445@avsd.UUCP>, <2253@unmvax.unm.edu>, <608@uva.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

dik@uva.UUCP (Casper H.S. Dik) writes:

>mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes:

>>In short, it may be quite rational to protect users from eachother (by
>>protecting /usr/lib/aliases), but it IS facism to "protect" people from
>>themselves.

>Agreed

I beg to disagree, gentlebeings. I am not intent on 'protecting users from
each other' when I forbid ~{user}/.forward files ... I am protecting myself.

It's not a matter of facism. It's a matter of functionality. I have a mandate,
as it were, to maintain the mail subsystem. I also have an unofficial mandate
to order my tasks in such a way as to avoid wasting my time. Reading mail to
'root' from 'MAILER-DAEMON', time after time, is a waste of my time. I know
what the problem is, I know there is no way I'll ever be able to educate the
entire user community, there's always someone browsing the manual - and that,
in itself, is a blessing of sorts, since they aren't asking me - so I created
a solution, the simplest, cheapest solution I could think of. It works.

The meter for determining if the mailer subsystem works, is whether you get
any mail from users or MAILER-DAEMON complaining. That's the only meter that
really counts. I'm not interfering in anyone's productivity, I'm keeping them
from impinging on mine.

You may call it administrative fascism ... but I think of it as facilitating
things, overall ... maintaining functionality, at the cost of an occasional
damaged ego, perhaps, but maintaining functionality. One person objects, but
they are inevitably a minority. Is this fascism ?

>>  Michael I. Bushnell       \     This above all; to thine own self be true
>>         GIG!                \    And it must follow, as the night the day,
>>mike@turing.cs..unm.edu      /\   Thou canst not be false to any man.
>>  Hmmmm..............       /  \  Farewell:  my blessing season this in thee!

-- richard

-- 
 *       "Do not look at my outward shape, but take what is in my hand."      *
 *                            -- Jalaludin Rumi, 1107-1173                    *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  9 Feb 89 23:39:42 EST
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 9 Feb 89 21:41:09-EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05992@BLOOM-BEACON.MIT.EDU>; Thu, 9 Feb 89 21:26:47 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Feb 89 22:13:38 GMT
From: mcvax!kth!enea!front.se!zap@uunet.uu.net  (Svante Lindahl)
Organization: Front Capital Systems, Stockholm, Sweden
Subject: Re: simple encryption in mail (no more legal discussion)
Message-Id: <293@front.se>
References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <485@maxim.ERBE.SE>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <485@maxim.ERBE.SE>, prc@maxim.ERBE.SE (Robert Claeson) writes:
# In article <1298@ndmath.UUCP>, krueger@ndmath.UUCP (Andreas Krueger) writes:
[ crypt is no good 'cause: ]
# >  > RESTRICTIONS
# >  >      This program is not available on  software  shipped  outside
# >  >      the U.S.

# So let's  use DES instead. Even though not included in the export versions
# of UNIX, it's  universally available and the algorithms are  well-known.

Yes, definitely available:
In volume 10 of comp.sources.unix (summer '87):
des		DES encryption routines and a login front-end
In volume 7 of comp.sources.unix (fall '86):
des		Purported DES program in C

Also available in volume 10:
cbw		(5 parts) Crypt Breaker's Workbench

-- 
Svante

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Feb 89 15:45:34 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA24236@BLOOM-BEACON.MIT.EDU>; Wed, 15 Feb 89 15:38:49 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Feb 89 22:32:17 GMT
From: clsib21!lpi!jdc@bbn.com  (Dustin Clampitt )
Organization: Language Processors Inc., Framingham MA
Subject: Fortune 16/32 parts forsale
Message-Id: <276@lpi.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I have just dis-assembled a couple Fortune 16/32 Systems.  If you
have a need for any replacement parts just let me know.  If there
is no immediate interest it's all going into the junk parts box.

I have: 

	- Motherboards 
	- Keyboards 
	- Monitors 
	- Monitor video boards (ONLY for Fortunes)
	- Disk controllers cards (ONLY for Fortunes)
	- Serial I/O cards
	- Memory cards
	- Power supplies

Make me an offer.  I can ship UPS COD.


					Dustin Clampitt
					jdc@lpi.uucp


-- 
Dustin Clampitt  "Is it Saturday yet?" 	
| Language Processors, Inc. (LPI)	   
| 959 Concord Street, Framingham, Mass. 01701-4613
| UUCP: ....!harvard!necntc!lpi!jdc

Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU  1 Mar 89 11:06:17 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1419; Wed, 01 Mar 89 11:05:05 EST
Received: from VM1.TAU.AC.IL by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 1264; Wed, 01 Mar 89 10:59:45 EST
Received: by TAUNIVM (Mailer R2.02) id 5115; Wed, 01 Mar 89 17:22:10 IST
Date:         Wed, 01 Mar 89 17:15:50 IST
From:         Hank Nussbacher <HANK%TAUNIVM.BITNET@MITVMA.MIT.EDU>
Subject:      Problems with .IL domain
To:           header-people@mc.lcs.mit.edu
Reply-To:     Hank Nussbacher <HANK%TAUNIVM.BITNET@MITVMA.MIT.EDU>

.IL is a registered upper level domain with SRI.  Unfortunately,
there is now a .IL.US which stands for Illinois in the USA.  It appears
that various mailers like to drop off the .US suffix leaving an address
with just .IL.  Here is an example of what can happen:

>220 VM1.TAU.AC.IL Columbia MAILER R2.02 BSMTP service ready.
>050 HELO CUNYVM.BITNET
>250 VM1.TAU.AC.IL Hello CUNYVM.BITNET
>050 TICK 3619
>250 3619 ... that's the ticket.
>050 MAIL FROM:<win@gatech.edu>
>250 <win@gatech.edu>... sender OK.
>050 RCPT TO:<heiby@mcdchg.chi.il>
>250 <heiby@mcdchg.chi.il>... recipient OK.
>050 DATA
>354 Start mail input.  End with <crlf>.<crlf>
>554-Mail not delivered to some or all recipients:
>554 Mail service is not available for
>050 QUIT
>221 VM1.TAU.AC.IL Columbia MAILER BSMTP service done.
>
>Original message follows:
>
>Received: from CUNYVM.BITNET by VM1.TAU.AC.IL (Mailer R2.02) with BSMTP id
> 4842; Wed, 01 Mar 89 17:03:26 IST
>Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.02A) with BSMTP id 3619; Wed,
> 01 Mar 89 10:03:10 EST
>Received: from gatech.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Wed,
> 01 Mar 89 10:03:07 EST
>Received: by gatech.edu (5.58/GATECH-8.6)
>    id AA26887 for heiby@mcdchg.chi.il; Wed, 1 Mar 89 10:01:29 EST
>Date: Wed, 1 Mar 89 10:01:29 EST
>From: win@gatech.edu (Win Strickland Jr)
>Message-Id: <8903011501.AA26887@gatech.edu>
>To: heiby@mcdchg.chi.il
>Subject: Re:  phone bill blues

I have seen cases where the RFC822 header did have the .IL.US but the
SMTP envelope only had .IL.  In the case above, neither has the extra
.US that should be there.

I think someone should take care of this.  I would imagine that of the
50 states, there must be quite a few with a matching European or Far
East country that has their upper level domain registered.

I am not on this list, so please reply directly to me if you have a
solution.

Hank

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  2 Mar 89 13:50:58 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA29260@BLOOM-BEACON.MIT.EDU>; Thu, 2 Mar 89 13:40:14 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 89 18:25:57 GMT
From: mailrus!wasatch!cs.utah.edu!mike@ohio-state.arpa  (Mike Hibler)
Organization: University of Utah, Computer Science Dept.
Subject: VAXen for sale (Salt Lake City, UT)
Message-Id: <1223@wasatch.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

This is posted for a friend.  Send mail to him, not me:
---

For sale:

VAX 8650..................
 
	floating point accelerator
	Unibus expansion box
	80Mb ram
	Star Coupler
	HSC50
	4 RA82's
	3 RA81's
	TA78 tape drive
	DEC maintained since purchase
	VMS,DECNET,C,PASCAL,FORTRAN,LISP,BLISS
	CMS,MMS,PCA,LSE,SCAN,ETHERNIM,SPM
 
	$380,000
 
VAX 750.....................
 
	floating point accelerator
	RA81 disk
	TU80 tape
	6Mb ram
	ethernet controler
	DEC maintained since purchase
 
	$10,000
 
6 VAXSTATION II's...........
 
	VR260 19" monocrhome monitors
	dual floppy disks
	6Mb  to 10Mb ram
	30Mb to 150Mb disk
	DEC maintained since purchase
 
	$7,000 to $8,000	
 
Howard Hughes Medical Institute
Al Tingey
801-581-4157
al%howard@cc.utah.edu

Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU  9 Mar 89 19:33:31 EST
Received: from TWG.COM by twg.com with SMTP ; Thu,  9 Mar 89 16:32:00 PST
Received: from obelix by Obelix.TWG.COM id aa22109; 9 Mar 89 18:36 PST
Reply-To: James M Galvin <galvin@TWG.COM>
To: header-people@mc.lcs.mit.edu
Subject: 3 month old waiting mail message
Date: Thu, 09 Mar 89 16:36:17 -0800
Message-ID: <22104.605493377@twg.com>
From: James M Galvin <galvin@TWG.COM>

This is outstanding!  I just got this waiting mail message for a message I
sent to header-people almost 3 months ago.  In fact, I just got several of
them.

Jim

------- Forwarded Message

Sender:   mmdf@bbn.com
From:     BBN Mail System (MMDF) <mmdf@bbn.com>
To:       @bfly-vax.bbn.com,@ice.bbn.com,@f.bbn.com,@mc.lcs.mit.edu,@TWG.COM:ga
	  lvin@TWG.COM
Date:     Mon, 6 Mar 89 3:01:37 EST
Subject:  Waiting mail  (msg.kn02771)

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

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

	~RSCHAAF@ice.bbn.com (host: ice.bbn.com) (queue: smtp)

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

    Your message begins as follows:

Received: from bfly-vax.bbn.com by BBN.COM id kn02771; 2 Mar 89 20:44 EST
Received: from ice.bbn.com by BFLY-VAX.BBN.COM id nb04282; 2 Mar 89 17:49 EST
Received: from f.bbn.com by NONAME.bbn.com id ab00522; 28 Dec 88 20:36 EST
Received: from MC.LCS.MIT.EDU by F.BBN.COM; Wed 28 Dec 88 20:45:53-EST
Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:08:23 ES
T
Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:31:03 PST
Received: from obelix by Obelix.TWG.COM id aa06570; 28 Dec 88 17:32 PST
Reply-To: James M Galvin <galvin@twg.com>
To: msir@cc.rochester.edu
cc: header-people@mc.lcs.mit.edu
Subject: Re: Simple form of RFC 822? 
In-reply-to: Your message of Wed, 28 Dec 88 17:44:34 EST.
             <8812282244.20958@uhura.cc.rochester.edu> 
Date: Wed, 28 Dec 88 15:32:31 -0800
Message-ID: <6567.599355151@twg.com>
From: James M Galvin <galvin@twg.com>

> Except that there's this thing called a standard, currently defined by
> RFC-822.  All mailers on the internet should handle any address specified
...


------- End of Forwarded Message


Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 21 Mar 89 13:35:09 EST
Received: by ATHENA.CS.YALE.EDU; Tue, 21 Mar 89 13:35:26 EST
Date: Tue, 21 Mar 89 13:35:26 EST
From: Pradeep Varma <varma-pradeep@YALE.ARPA>
Full-Name: Pradeep Varma
Message-Id: <8903211835.AA10658@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-acee/ACEE) 
          via WIMP-MAIL (Version 1.3/1.5) ; Tue Mar 21 13:18:41
To: header-people@mc.lcs.mit.edu
Subject: "too many hops"


hi,
    I am maintaining some mailing lists, and often when I broadcast a message sent to me, 
I get bouncebacks because of "too many hops". An example of such a bounceback is enclosed.
I would greatly appreciate it if someone could suggest a scheme that would take care of
this problem while redirecting the mail to the lists automatically.


                           Thanks for any answers,
                                                      Pradeep



P.S I know a manual hack. Take the incoming mail message to an editor and strip the
"Received: ... " lines from it before sending it off again. But I don't particularly
like it. I think it will mess up people replying to the original message.









1989/03/18.09:58:12,8316;01
Received: by YALE-RING-MAIL-GW via SSMTP ($Revision: 1.19 $) ; Fri Mar 17 19:43:19 1989
Received: from uunet.UU.NET by ELI.CS.YALE.EDU; Fri, 17 Mar 89 19:35:10 EST
Full-Name: 
Received: from mcvax.UUCP by uunet.UU.NET (5.61/1.14) with UUCP 
	id AA07527; Fri, 17 Mar 89 19:36:54 -0500
Received: by mcvax.cwi.nl via EUnet; Fri, 17 Mar 89 15:40:37 +0100 (MET)
Received: from irisa.irisa.fr by inria.inria.fr (5.61+/89.0.5) via Fnet-EUnet id AA11104; Fri, 17 Mar 89 08:41:10 +0100 (MET)
Message-Id: <8903170741.AA11104@inria.inria.fr>
Received: by irisa.irisa.fr; Fri, 17 Mar 89 08:42:22 +0100 (3.2/M3.1)
Date: Fri, 17 Mar 89 08:42:22 +0100
From: mcvax!irisa.fr!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
To: <varma-pradeep@YALE.ARPA>

   ----- Transcript of session follows -----
554 <lemetayer@irisa.irisa.fr>... Mail loop detected
554 sendall: too many hops (15 max)

   ----- Unsent message follows -----
Received: by irisa.irisa.fr; Fri, 17 Mar 89 08:42:22 +0100 (3.2/M3.1)
Received: by inria.inria.fr (5.61+/89.0.5) via Fnet-EUnet id AA11078; Fri, 17 Mar 89 08:40:33 +0100 (MET)
Received: from kth.se by enea.se (5.57++/1.103) via EUnet
	id AA28932; Fri, 17 Mar 89 06:59:37 +0100 (MET)
Received: from chalmers.se by kth.se (5.57+IDA+KTH/4.0)
	id AA28226; Fri, 17 Mar 89 06:55:49 +0100
Received: from fnatte.cs.chalmers.se by chalmers.se id AA28711; Fri, 17 Mar 89 06:57:49 +0100
Received: from chalmers.se by fnatte.cs.chalmers.se id AA10843; Fri, 17 Mar 89 06:57:04 +0100
Received: from kth.se by chalmers.se id AA28703; Fri, 17 Mar 89 06:56:35 +0100
Received: from enea.se by kth.se (5.57+IDA+KTH/4.0)
	id AA28159; Fri, 17 Mar 89 06:52:23 +0100
Received: by enea.se (5.57++/1.103) via EUnet
	id AA28836; Fri, 17 Mar 89 06:54:53 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Fri, 17 Mar 89 06:44:50 +0100 (MET)
Received: from CS-GW.CS.YALE.EDU by uunet.UU.NET (5.61/1.14) with SMTP 
	id AA08339; Thu, 16 Mar 89 15:17:00 -0500
Received: by ELI.CS.YALE.EDU; Thu, 16 Mar 89 12:12:54 EST
Resent-Date: Tue, 14 Mar 89 17:30:41 CST
Resent-Message-Id: <8903161712.AA11470@ELI.CS.YALE.EDU>
Received: by yale-ring (node-acee/ACEE) 
          via WIMP-MAIL (Version 1.3/1.5) ; Thu Mar 16 12:00:25
Received: by YALE-RING-MAIL-GW via SSMTP ($Revision: 1.19 $) ; Tue Mar 14 18:38:52 1989
Received: from a.cs.uiuc.edu by ELI.CS.YALE.EDU; Tue, 14 Mar 89 18:29:50 EST
Received: from reddy (reddy.cs.uiuc.edu) by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
	id AA03940; Tue, 14 Mar 89 17:31:16 CST
Received: by reddy (4.0/9.7)
	id AA08852; Tue, 14 Mar 89 17:30:41 CST
Date: Tue, 14 Mar 89 17:30:41 CST
From: reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8903142330.AA08852@reddy>
To: kamin@tatoo.inria.Fr
Cc: fp@YALE.ARPA
In-Reply-To: Sam Kamin's message of Wed, 8 Mar 89 11:15:01 +0100 <8903081014.AA06940@inria.inria.fr>
Subject: Haskell comments - please post to fp mailing list
Reply-To: reddy@a.cs.uiuc.edu
Resent-From: varma@YALE.ARPA
Resent-To: fp-other@YALE.ARPA, fp-others-under-us@YALE.ARPA,
        fp-local@YALE.ARPA, fp-us1@YALE.ARPA, fp-us2@YALE.ARPA,
        fp-us3@YALE.ARPA






Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Mar 89 15:29:03 EST
Date: Tue, 21 Mar 1989  15:31 EST
Message-ID: <SRA.12479851471.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Pradeep Varma <varma-pradeep@YALE.ARPA>
Cc:   header-people@MC.LCS.MIT.EDU
Subject: "too many hops"
In-reply-to: Msg of 21 Mar 1989  13:35-EST from Pradeep Varma <varma-pradeep@YALE.ARPA>

Removing "Received:" headers shouldn't affect anybody's ability to
reply.  Received headers are intended for tracing purposes only.  Any
mail User Agent (UA) that attempts to do clever things with Received
headers is broken.  Humans who have to analyze Received headers to
figure out how to reply to a message are victims of broken mailers.
Since you are reposting these messages, presumably you can verify that
the From: or Reply-To: headers look moderately reasonable before
passing the messages along.

Having mailer daemons that count Received headers is a cute idea but
probably misguided, as your problems show; the correct thing to do
would be to count, or preferably do some kind of intelligent analysis
on, entries in the Return-Path.  (Yes, I know that there are hosts
that don't update the return path, but then there are hosts that don't
add received headers either, gotta draw a line somewhere....)

The real problem appears to be that the mailer in question has an
"unreasonably low" value set for what it thinks is a mailer loop (15
probably seemed like a reasonable idea when it was chosen, years ago).
Unless you can convince the owners of the mailers in question to fix
this behavior, stripping out the Received lines when you repost is
probably as good a kludge as you're going to get.

--Rob

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Mar 89 05:45:43 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA27981@BLOOM-BEACON.MIT.EDU>; Sat, 25 Mar 89 05:20:08 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Mar 89 12:35:26 GMT
From: oliveb!apple!well!pokey@ames.arpa  (Jef Poskanzer)
Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal
Subject: Is comp.mail.headers dead?
Message-Id: <11074@well.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

This newsgroup has not has any traffic in quite a while.  Is it dead?
Should we give it a decent burial?

As I recall, this newsgroup is gatewayed to mailing list.  Perhaps the
mailing list is active but the gateway is broken?
---
Jef

            Jef Poskanzer   jef@helios.ee.lbl.gov   ...well!pokey

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 03:31:05 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12729@BLOOM-BEACON.MIT.EDU>; Mon, 27 Mar 89 03:26:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Mar 89 13:56:06 GMT
From: attcan!dptcdc!berner!contact!rlerdorf@uunet.uu.net  (Rasmus Lerdorf)
Organization: Contact User Supported BBS. Toronto, Ontario.
Subject: Re: Is comp.mail.headers dead?
Message-Id: <446@contact.UUCP>
References: <11074@well.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


	At the risk of sounding completely ignorant here, what is the topic of
discussion in this poor lonely newsgroup?
-- 
  />   Rasmus Lerdorf     | `-_-' | Hurra for Danske piger!                <\
 // rlerdorf@contact.UUCP |  'U`  | Support the morally handicapped         \\
</  Waterloo SD Eng, '93  | bleh! | '93 ?  I'll never get out of this place! \>

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 13:31:21 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA23174@BLOOM-BEACON.MIT.EDU>; Mon, 27 Mar 89 13:25:06 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Mar 89 18:07:41 GMT
From: mailrus!shadooby!wisner@ohio-state.arpa  (Bill Wisner)
Organization: Amnesia International
Subject: Re: Is comp.mail.headers dead?
Message-Id: <236@shadooby.cc.umich.edu>
References: <11074@well.UUCP>, <446@contact.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

No, it's not dead. Just quiet. That happens periodically.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 19:16:24 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA29803@BLOOM-BEACON.MIT.EDU>; Mon, 27 Mar 89 19:05:02 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Mar 89 21:42:56 GMT
From: att!pegasus!ech@bloom-beacon.mit.edu  (Edward C Horvath)
Organization: AT&T ISL Middletown NJ USA
Subject: Re: Is comp.mail.headers dead?
Message-Id: <2723@pegasus.ATT.COM>
References: <236@shadooby.cc.umich.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

From article <236@shadooby.cc.umich.edu>, by wisner@shadooby.cc.umich.edu (Bill Wisner):
> No, it's not dead. Just quiet. That happens periodically.

Hmm, sounds like the parrot..."It's just pinin' for the fjords"

Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 29 Mar 89 05:08:44 EST
Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa01448; 29 Mar 89 10:04 GMT
To: header-people@mc.lcs.mit.edu
Subject: 987 - try again
Date: Wed, 29 Mar 89 11:01:48 +0100
Message-ID: <24996.607168908@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@Cs.Ucl.AC.UK>
Source-Info:  purple.cs.ucl.ac.uk

    Your message could not be delivered to....

To: ifip-gtwy@tis.llnl.gov
cc: mailgroup@Cs.Ucl.AC.UK, header-people@ms.lcs.mit.edu, 
    rare-wg1@vax.runit.unit.uninett, iso@sri-nic.arpa, 
    iso-tg@compsci.bristol.ac.uk
Subject: RFC 987 (88)
Phone: +44-1-380-7294
Date: Wed, 29 Mar 89 09:45:57 +0100
Message-ID: <18186.607164357@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@Cs.Ucl.AC.UK>
Source-Info:  purple.cs.ucl.ac.uk

I'm posting this message wide - apologies to those who get duplicates.
Please do NOT reply to all of the CC lists.   

RFC 987 is a specification to map between RFC 822 based protocols and X.400
(1984).   I have just completed the first draft of the version to map
to X.400 (1988) - a quite substantial update.   For now, I am calling this
RFC 987(88).  

I hope that this specification can gain wide acceptance, following input
from all interested parties.

I propose to use the ifip-gtwy list to discuss this specification.  I will
be circulating the specification by mail in two weeks time (April 11th) -
experience has suggested that there are too many interested parties without
file transfer access.  This should give interested people sufficient time to
get onto the list.  Send to ifip-gtwy-request@tis.llnl.gov.  For UK people
send to arpa-mhs-request@uk.ac.ucl.cs.  I suggest that other Europeans
should get national expansions.

People should also get themselves copies of X.400 (88) - at least the DIS.
I'm sure that "how to get the standard" will be discussed on ifip-gtwy.

I am proposing to hold a meeting on 27-28 June in London to finalise this
specification following electronic discussion.  Put this date in your
diaries!  If there is sufficient request, it may be useful to also hold a
one day meeting sometime in early May.  

Steve

------- End of Forwarded Message


Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 29 Mar 89 15:27:23 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 1766; Wed, 29 Mar 89 15:28:37 EST
Received: from CARLETON.CA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8222;
 Wed, 29 Mar 89 15:28:36 EST
Received: by CARLETON (Mailer); Wed, 29 Mar 89 15:14:13 EST
Date:       Wed, 29 Mar 89 15:12:15 EST
From:       Walter_Roberson%CARLETON.CA@mitvma.mit.edu
To:         header-people@mc.lcs.mit.EDU
Message-Id: <890329.15124491.020412@ADMIN.CP6>
Subject:    mangled 'From:' starting with '!'


  Check out the mangled From: field in the header quoted below. I've
enclosed most of it just for completeness. The message was redistributed by
the apollo mailing list: our system had it marked as being from
apollo-request@umix.cc.umich.edu . Thus, the From: field shown below
was in the body of the message, not in the envelope of the resent message.
Anyone care to take a guess which system was responsible for putting the '!'
as the first component of the From: path?

  Walter Roberson <Walter_Roberson@Carleton.CA>

---- begin quoted message ---

 Received: by CARLETON (Mailer); Wed, 29 Mar 89 14:42:35 EST
 Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 8377; Wed,
  29 Mar 89 14:10:50 EST
 Received: from umix.cc.umich.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP
;
  Wed, 29 Mar 89 14:10:41 EST
 Received: by umix.cc.umich.edu (5.54/umix-2.0)
     id AA00853; Wed, 29 Mar 89 07:21:26 EST
 Received: by umix.cc.umich.edu (5.54/umix-2.0)
     id AA06936; Wed, 29 Mar 89 05:54:37 EST
 Received: by ucbvax.Berkeley.EDU (5.61/1.36)
     id AA00984; Wed, 29 Mar 89 02:43:44 -0800
 Received: from USENET by ucbvax.Berkeley.EDU with netnews
     for apollo-arpa@umix.cc.umich.edu (apollo@umix.cc.umich.edu)
     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
 Date: 28 Mar 89 21:49:26 GMT
 From: !sharp%calgary%alberta%ncc%pyramid%oliveb.uucp@apple.com  (Maurice Sharp)
 Subject: Re: EMACS for Apollo?
 Message-Id: <979@cs-spool.calgary.UUCP>
 References: <42467373.f81c@lexington.UUCP>
 Sender: apollo-request@umix.cc.umich.edu
 To: apollo@umix.cc.umich.edu

<Message Text Deleted>

  E-MAIL : sharp@ksi.cpsc.UCalgary.CA
  EAN    : sharp@calgary.CDN

--- end of quoted message ---

 Walter Roberson <Walter_Roberson@Carleton.CA>

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU  3 Apr 89 10:03:34 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA23752@BLOOM-BEACON.MIT.EDU>; Mon, 3 Apr 89 09:59:05 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Apr 89 15:40:19 GMT
From: mcvax!ukc!tcdcs!tcdmath!ajudge@uunet.uu.net  (Alan Judge)
Organization: Maths Dept., Trinity College, Dublin
Subject: Re: mail headers
Message-Id: <712@maths.tcd.ie>
References: <5463@ozdaltx.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
>Wouldn't it be wonderful to receive e-mail WITHOUT scads of
>notations of 'Received by:' at the beginning of each
>message?  Does anyone really care what system received the
>message, that systems ID number and a time stamp to boot?  I
>can tell what sites the message went through by looking at
>the path line plus I can read the date the message was sent
>and I know when I received it.

Most system administrators will tell you that the Received headers are very
useful when diagnosing problems or holdups in mail. With the number of
"intelligent" mailers out there now, they are also of considerable use in
finding out how messages are being routed.

Most mail messages do not have a "path line" (this is a news only
phenomenon) and most smart mailers do *not* modify the mail headers (such as
from:) to indicate what sites the message has been through. Therefore without
the Received headers there is no way to determine the routing of the message.
Without routing information it is sometimes impossible to reply at all. For
example, a mail message I just received just said mmdf2@relay.cs.net in the
From: line. Without Received lines I would not know it had been through
 tcdcs, ccvax.ucd.ie, irlearn.bitnet, cunyvm.cuny.edu, relay.cs.net

Admittedly, some mailers put in useless information into headers, but I
think that the host name and time should definitely be kept.

Anyway, if you are using a nice mail reader you shouldn't even see headers
like Received, Message-id etc.. unless you explicitly ask.

>Not to mention the bytes saved in transmission by
>eliminating all this garbage.  What can be done????

Transmission times for mail are usually dwarfed by those for news anyway.

>Scotty
>{ames,rutgers,texsun,smu}!killer!ozdaltx!sysop 
--
Alan Judge, SysAdmin, Dept. of Maths, Trinity College, Dublin, Ireland.
Smart: ajudge@maths.tcd.ie	Stupid: ...!uunet!maths.tcd.ie!ajudge

P.S. I have crossposted to comp.mail.headers and directed followups there
since this does not belong in news.sysadmin.

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 11 Apr 89 22:20:24 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 2240; Tue, 11 Apr 89 22:22:24 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 9650; Tue, 11 Apr 89 22:21:52 EDT
Date:    Tue, 11 Apr 89 19:19 PDT
From:    Leonard D Woren                  <LDW%MVSA.USC.EDU@mitvma.mit.edu>
To:      Header People                    <Header-People@MC.LCS.MIT.EDU>
Subject: Hostname in Message-Id

I have a philosophy question regarding the host name which must appear
in the Message-Id: line.  Suppose that I send one message to two
recipients, one at foo.bar.edu, and the other at mung.bitnet .  Since
my host is on both networks, it has two names -- MVSA.USC.EDU and
USCMVSA.BITNET .  The message id as seen by the user at foo.bar.edu
should be "local.part@MVSA.USC.EDU", but the message id as seen by the
Bitnet user should be "local.part@USCMVSA".  This offends my
sensibilities.  I claim that RFC 822 requires that all copies of one
message have identical message ids.  Since most Bitnet mailers can be
handed mail to .....edu addresses and deliver it correctly, via a
gateway if necessary, I see no reason why the Bitnet recipient should
not get the same message id as the Internet recipient.  In other
words, always use my Internet name in the Message-Id.  Comments?

I had a long argument with another mail expert who claims that the
Message-Id should be transformed at network boundaries the same way
that From:/To:/Cc: are transformed.  I claim that this invalidates
the Message-Id, since there are now multiple copies of a single
message with differing message ids.


Leonard D. Woren
Senior MVS Systems Programmer
MVS Postmaster  <LDW@USCMVSA.BITNET>  <LDW@MVSA.USC.EDU>
University of Southern California

Received: from valeria.cs.ucla.edu (TCP 20354640044) by MC.LCS.MIT.EDU 12 Apr 89 00:51:20 EDT
Return-Path: <wales>
Received: by valeria.cs.ucla.edu (Sendmail 5.59/2.16)
	id AA05030; Tue, 11 Apr 89 21:15:38 PDT
Date: Tue, 11 Apr 89 21:15:35 PDT
From: Rich Wales <wales@CS.UCLA.EDU>
Message-Id: <890412.041535z.05012.wales@valeria.cs.ucla.edu>
To: Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Cc: header-people@MC.LCS.MIT.EDU
Subject: Re: Hostname in Message-Id
In-Reply-To: Message of Tue, 11 Apr 89 19:19 PDT
        from "Leonard D Woren
        <LDW%MVSA.USC.EDU@mitvma.mit.edu>"
        <8904112259.aa27835@mintaka.lcs.mit.edu>

Leonard --

Replying to your question about whether the host name in a Message-ID
should be changed depending on which network the messages goes out on:

My understanding is that this should *not* be done.  Two reasons:

(1) As you pointed out, name-changing in Message-ID's would make it
    impossible for different recipients on the two different networks
    to be sure they were both talking about the same message.

(2) The domain naming system was designed with the idea that each host
    would have exactly *one* primary name, irrespective of whatever
    network(s) it might be on.  The whole concept of having domain-style
    names ending in ".BITNET", ".UUCP", ".CSNET", etc.  is considered an
    evil abomination by domain purists.  To be sure, the operational
    realities of some networks have forced some sites to adopt multiple,
    network-specific names -- but this has never been accepted offi-
    cially, and you aren't going to find anything in any of the RFC's
    that acknowledges the legitimacy of this practice.

-- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683
   3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
   wales@CS.UCLA.EDU      ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales
"Fate protects fools, little children, and ships named _Enterprise_."

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 12 Apr 89 08:55:21 EDT
Received: by INFOODS id <000000D5072@INFOODS.MIT.EDU> ;
       Wed, 12 Apr 89 08:49:35 EDT
Date: Wed, 12 Apr 89 07:48:06 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re: Hostname in Message-Id
To: Leonard D Woren <LDW@MVSA.USC.EDU>, header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"Leonard D Woren <LDW@MVSA.USC.EDU>", EXOS%"header-people@MC.LCS.MIT.EDU"
Message-ID: <890412074806.000000D5072@INFOODS.MIT.EDU>

I think this response should be subtitled as "stop worrying about things 
you can't change".  In my capacity of a self-designated DNS purist, your
reasoning is absolutely correct: one host, one name regardless of what 
it happens to be connected to, with one qualification, noted below.  And 
gateways should, pragmatically, not mess with any fields that they don't 
have to mess with.  Message-IDs are not such a field, especially since 
the gateway can't know how the ID itself (independent of host names) is 
created by the sending system.  If it did, it might discover a need to 
transform them to, say, local time.  A half-transformed field is always 
worse than a fully-transformed field.

But there is a qualification to all of this.  Never (well, hardly ever) 
did even the most optimistic believe that either RFC822 or the DNS would 
apply to all of the machines, on all of the networks, in the world.  
They were designed so that, if successful, they could serve that role, 
but without the expectation that they *would* serve that role.  If you 
have a host that is reached from the Internet and that does not obey the 
DNS rules, or even the RFC822 rules, then (i) that is why there are 
conventions about embedding non-Internet host names in the 'local part' 
of an address and (ii) gateways have to be somewhat aggressive about the 
transformations they perform.
  The aggressiveness is expected to be bidirectional, although there is
no way to enforce this and, in some cases, it can't work.  
"Bidirectional" implies that, if a gateway performs a transformation as 
a message goes through a gateway, that the translation is invertable and 
that the inverse operation is performed by whatever gateway, or 
meta-gateway, passes the message back.  That is possible in practice 
with real gateways that do not also house the UAs.  But, when you, 
Leonard, have a machine that is hosted on both BITNET and the Internet 
(note that I'm discussing its connections, not its name), and you send 
something out via BITNET and get it back via the Internet via someone 
else's gateway, I don't know what expectations you can have.
  In any event, the "single name" rules of the DNS apply to something 
that we can think of, conceptually, as an "extended Internet": networks 
that are part of the DNS namespace and that obey other Internet rules, 
including the Internet's view of what gateways should do to headers of 
messages passed in and out.  By that definition, it is not clear that 
BITNET is a member of the "extended Internet".  As you say, from a DNS 
purist standpoint, "foo.BITNET" is an obscenity, and it is a public 
obscenity if "foo.bar.edu" also exists and is the same machine.  But 
only some BITNET machines have names that are registered with the DNS.  
Indeed, only some of them run MAILERs that support DNS names and RFC822. 
  And, from a purist standpoint, any gateway that permits a message to 
enter the Internet that contains header fields or field components not 
specified in RFC822 is, at least, ill-behaved.  Given what the INTERBIT 
machines don't filter, there is another argument that, while BITNET 
co-exists reasonably well with the Internet, it is not part of this 
conceptual extended Internet.

  Now, let me reconstruct some early, and very informal, discussions: 
If you care about what is in a Message-ID, and are on a host different 
from the originator, you are going well beyond what RFC822 and its 
predecessors intended for that field.  If you are a gateway, and 
transform it, you are probably obligated to transform it back before 
sending to the original host.  And, since you probably can't get that 
right, you should probably keep hands off.
   But correct universal use of a Message-ID requires going well beyond
what RFC822 specifies.  Assume that I'm operating in a workstation 
environment, with a local UA, but with the MTA on the next machine down 
the line.  Assume further that my "address" is on the machine with the 
MTA, that I communicate with it using "post office" protocols, not 
ordinary SMTP.  Just to complicate life, assume that the MTA-machine is 
a multiprocessor, with a high degree of parallel capability.  Let's also 
assume that the MTA machine is a host on multiple networks, some of 
which are *not* part of the DNS, even at the MX level, for one reason or 
another, and some of which don't use anything resembling RFC822.  In this 
environment, there are significant advantages to seeing the workstations 
(I may use different ones on different days) as a UA function, not an 
MTA function.  That reasoning is consistent with the SMTP/RFC822 
boundary: you don't see Message-IDs in the envelope, do you?  But, if 
"host" in the Message-ID is going to be the MTA hostname, then it is 
going to be hard to guarantee uniqueness--at least uniqueness that you, 
the receiver, can understand and use.  I can give it to you 
probabilistically.  Or we can encode the latitude and longitude (to the 
nearest 20cm) of the sender (not the workstation, please) and the time
(in GMT, to the nearest half-second) in the Message-ID to make it 
unique.  That raises a few other problems, but...

Finally, people who believe that gateways should transform Message-ID
fields are probably obligated to believe that they should transform 
"Received" fields.  But that is a potential catastrophe, destroying all 
of the information needed when something goes wrong.  Note that, when we 
(as an Internet host) get a message forwarded from your BITNET side via 
an INTERBIT gateway, I see a Received field that says ".. from 
UCBMVSA.BITNET by MITVMA.MIT.EDU ... with BSMTP...".  It is followed (in 
time) by a Received field containing "from MITVMA.MIT.EDU by 
mitvma.mit.edu (IBM VM SMTP...) ... with BSMTP...".  Want to argue for 
something else?  I do, but the "it should transform" argument would like 
it less, and that would use "MITVMA.BITNET" where "MITVMA.MIT.EDU" 
appears above, but "mitvma.mit.edu" where that appears in lower case.  
It is in that intra-machine transfer that "gateway" happens, and, before 
that, these are separate networks with different protocols.

Conclusion: (1) Gateways should probably not change them.  (2) If you 
consider your host to be part of the DNS, and part of the extended 
Internet in all of its transactions and in all of the networks to which 
it is attached, then it should have only one name in all of those 
(that?) namespace.  (3) If you count on any of this, you are looking for 
trouble.

Please consider a related problem, which is more interesting and more of 
a problem:
   You send mail to header-people@mc.lcs.mit.edu.  mc.lcs.mit.edu is an 
Internet site, with no direct connections to BITNET.  Something at your
end decides to route that message via BITNET, presumably because it has 
been told to prefer BITNET and its DOMAIN NAMES tables (the closest 
BITNET gets to DNS MX resolution) says "send it to MITVMA via BITNET".  
MITVMA gets it, opens an SMTP connection to MC, and sends the message 
off.  So far, so good.  But the gateway code on MITVMA says "this got 
here via BITNET, it may have to go back via BITNET" and "fixes" your 
address so that it says "LDW%MVSA.USC.EDU@mitvma.mit.edu".  But if I, or 
MC, 'reply' to that, we violate the principle that says that we don't 
use network B to carry a message between two hosts on network A.  
  Question: what should the gateway do?  Consider that, if the message 
originates from a bitnet-connected host that is not part of the DNS, it
must say 
  user%host.BITNET@mitvma.mit.edu
If it says anything else, it is in violation of the DNS (and 822 rule) 
that says that nothing runs around the Internet with something that 
looks like a host name in an address that isn't a [DNS-registered] host 
name.  Should it look MVSA.USC.EDU up with the DNS and leave the address 
in LDW@MVSA.USC.EDU if it finds an "A" record?  How about if it finds an 
"A" record or an "MX" record?  (Keep in mind that many MILNET hosts, and 
more than a few other Internet hosts, still lack DNS resolvers).  
Whatever the answer to that question, would finding an MX record that 
points back to MITVMA change your answer?  And, finally, if it does that 
lookup and finds a CN record that says your name is "CORRAL" and not 
"OUTLAW" (no apologies to the slandered who are using non-primary names 
in their From fields), should it "fix" it?
  I suggest that, whatever your answer, the gateway can't do the "right" 
thing without actually looking up the putative DNS name and being sure 
that it is one.  And then, sometimes, you are not going to like the 
answer to any firm rule, since MITVMA may know some things about 
connections, transport arrangements, and temporary congestion points at 
the time the message is answered that you can't know, a day or two 
earlier.
  On the other hand, this situation could use a better set of rules.  
Someone should propose some.
   John Klensin, MIT
   Klensin@INFOODS.MIT.EDU


Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 09:31:50 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 3192; Wed, 12 Apr 89 09:33:50 EDT
Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 3211; Wed, 12 Apr 89 09:32:05 EDT
Received: by BUCLLN11 (Mailer R2.03B) id 3422; Wed, 12 Apr 89 09:35:30 +0200
Date:         Wed, 12 Apr 89 09:32:23 +0200
From:         "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@mitvma.mit.edu>
Message-Id:   <890412.093223.+0200.af@sei.ucl.ac.be>
Subject:      Re: Hostname in Message-Id
To:           Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
In-Reply-To:  Message of Tue, 11 Apr 89 19:19:00 PDT from
 <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>

If at  BITNET site still has  no software dealing with  domain addressed
mail, there is only a very small  probability (to say the least) that it
will have any software handling the 'message-id' header item...

So I can't see any reason to put a BITNET NJE hostname in a 'message-id'
header line...                                 /AF

Received: from HUSC3.HARVARD.EDU (TCP 20031600465) by MC.LCS.MIT.EDU 12 Apr 89 10:02:49 EDT
Date: Wed, 12 Apr 89 09:53 EDT
From: Danny Padwa <PADWA@HUSC3.HARVARD.EDU>
Subject: Multi-Networked Hosts (was Hostname in Message-ID)
To: header-people@mc.lcs.mit.EDU, John C Klensin <Klensin@Infoods.Mit.EDU>,
 Leonard D Woren <LDW@Mvsa.Usc.EDU>
X-VMS-To: IN%"header-people@mc.lcs.mit.edu",
 IN%"John C Klensin <Klensin@Infoods.Mit.Edu>",
 IN%"Leonard D Woren <LDW@Mvsa.Usc.Edu>",PADWA

I think John hit the nail on the head when discussing the difficulties
faced by gateways that are "multi-homed" on both BITnet (or other
non-RFC822 systems) and the Internet.

One major problem is that our Interbit gateways perform address munging
that cannot be undone by us here. I can't count how many messages I've
received with return addresses of the form:
		user%host.bitnet@cunyvm.cuny.edu

How do I respond? RFC822 pretty clearly prohibits me from messing with
the local part of this address (user%host.bitnet) and sending it
directly over BITnet. Yet sending via CUNYVM is clearly inefficient.
	
One possible solution to this is to rename the INTERBIT gateways from the
Internet side, more along the lines of the BITnet solution. There, instead
of pointing records towards any specific gateway, all hosts send mail
to the gateway address on node "INTERBIT", which is routed to the closest
node. Perhaps we could allocate a subspace of the DNS and put such
"special" gateways in there. Then, the INTERBIT gateways could all
set return addresses to be INTERBIT.GATES.NET or INTERBIT.BIT.NET or some
other monstrosity. Then (how is this for ugly, awful, despicable hacking?)
any host that is on both nets can munge its mailer configuration files to
strip away INTERBIT from either side, and process the remaining address.
I know this violates our "never-make-exceptions-to-the-rules" rule, but
since any such multi-netted host must have complex mailer configurations
anyway, you can't really complain.

While we're on the topic of incompatibilities between the BITnet and
Internet, I think we need to address BITnet's "wanton" use of invalid
domain-style names. I don't mind any non-Internet site calling itself
foo.bar, as long as proper MX records are located somewhere. Harvard and
Berkeley both provide MX service for BITnet only sites that want domain
names.....sites that insist on using names not in the DNS only manage
to greatly confuse things.

	Any suggestions?

				Danny Padwa
				Harvard University VMS Network Programmer
				Padwa@Husc3.Harvard.Edu
				Padwa@Husc3.Bitnet

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 10:02:51 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 3308; Wed, 12 Apr 89 10:04:41 EDT
Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 3595; Wed, 12 Apr 89 10:02:22 EDT
Received: by IRLEARN (Mailer X1.24) id 3149; Wed, 12 Apr 89 12:32:28 GMT
Date:         Wed, 12 Apr 89 12:25:56 GMT
From:         "Niall O'Reilly     (NOREILLY@IRLEARN.UCD.IE)" <NOREILLY%IRLEARN.BITNET@mitvma.mit.edu>
Subject:      Re: Hostname in Message-Id
To:           HEADER-PEOPLE@MC.LCS.MIT.EDU
cc:           Tom Wade <T_WADE@CCVAX.UCD.IE>
In-Reply-To:  Message of Tue, 11 Apr 89 19:19:00 PDT from
 <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>

I agree with Leonard.  Message-Id fields should not be munged by
gateways.  I don't see what functional benefit there could be
in munging them.  There may be an aesthetic advantage, but I think
that the functional must come first in this case.

Now, it seems to me a matter of no functional significance which
of the (perhaps multiple) domain- or node- aliases is used in
forming the Message-Id.

Niall O'Reilly
EARN/.IE gatemaster
[Hmm ... I wonder what my own gateway does ... 8-)]

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 15:43:54 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4509; Wed, 12 Apr 89 15:45:21 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 8696; Wed, 12 Apr 89 15:45:20 EDT
Date:    Wed, 12 Apr 89 12:39 PDT
To:      Danny Padwa <PADWA@HUSC3.HARVARD.EDU>
Cc:      header-people@MC.LCS.MIT.EDU
From:    Leonard D Woren                      <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID)

> While we're on the topic of incompatibilities between the BITnet and
> Internet, I think we need to address BITnet's "wanton" use of invalid
> domain-style names.

I have repeatedly argued this point in a number of Bitnet forums, and
I always lose.  My argument is that sites that are not reachable on
the Internet (via DNS) MUST NOT be allowed to use DNS-style names.
Bitnet-only sites all too often don't have a reasonable perspective on
these things.

> I don't mind any non-Internet site calling itself
> foo.bar, as long as proper MX records are located somewhere. Harvard and
> Berkeley both provide MX service for BITnet only sites that want domain
> names.....sites that insist on using names not in the DNS only manage
> to greatly confuse things.

YES!  The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should
be banned, and Bitnet sites with DNS-style names without MX service
should be banned.

          Leonard D. Woren
          Senior MVS Systems Programmer
          MVS Postmaster  <LDW@USCMVSA.BITNET>  <LDW@MVSA.USC.EDU>
          University of Southern California

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 17:43:52 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4831; Wed, 12 Apr 89 17:45:48 EDT
Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 0035; Wed, 12 Apr 89 17:45:19 EDT
To:       HEADER-PEOPLE@MC.LCS.MIT.EDU
From:     "Roger Fajman" <RAF%NIHCU.BITNET@mitvma.mit.edu>
Date:     Wed, 12 Apr 89  17:40:37 EDT
Subject:  Re:  Multi-Networked Hosts (was Hostname in Message-ID)

> > While we're on the topic of incompatibilities between the BITnet and
> > Internet, I think we need to address BITnet's "wanton" use of invalid
> > domain-style names.
>
> I have repeatedly argued this point in a number of Bitnet forums, and
> I always lose.  My argument is that sites that are not reachable on
> the Internet (via DNS) MUST NOT be allowed to use DNS-style names.
> Bitnet-only sites all too often don't have a reasonable perspective on
> these things.
>
> > I don't mind any non-Internet site calling itself
> > foo.bar, as long as proper MX records are located somewhere. Harvard and
> > Berkeley both provide MX service for BITnet only sites that want domain
> > names.....sites that insist on using names not in the DNS only manage
> > to greatly confuse things.
>
> YES!  The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should
> be banned, and Bitnet sites with DNS-style names without MX service
> should be banned.

All BITNET domains should be reachable through the Internet.  For those
sites who do not have their own, Harvard and Berkeley provide the
domain name service, with suitable MX records.  The only exceptions are
a few old domains like .UUCP for which name service is not allowed.  No
new domains like that are allowed to be created in BITNET.

:interconnect.MX has nothing to do with sending mail from the Internet
to BITNET.  It exists to aid sites that have both BITNET and Internet
connections in making a decision about which network to use for sending
the mail.

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 18:52:29 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5064; Wed, 12 Apr 89 18:53:47 EDT
Received: from DBNGMD21.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 0898; Wed, 12 Apr 89 18:47:01 EDT
Message-ID: <"89-04-13-00:19:56.52*GRZ027"@DBNGMD21.BITNET>
Date:    Thu, 13 Apr 89 00:19
To:      Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
From:    Peter Sylvester +49 228 8199645      <GRZ027%DBNGMD21.BITNET@mitvma.mit.edu>
Subject: Re: Hostname in Message-Id

I would like to see the JANET internal version of an internet
orinated message-id. It is known the JANET uses a "domain format"
which is syntactically identical to RFC822 but the domains are
just reversed. Therefore message-id are hopefully either
reversed in all gateways between JANET and internet.

All Internet/Bitnet gateways do at least some EBCDIC/ASCII
translation. This might not be considered as "header munging"
but it is known that IBM has some problems to define globally
unique translate tables for some special characters.

I would like to know how I could gateway some internet message-id
into some X.400 ip-message-id *without* "header-munging", in this
case it is at least a different "encoding". For details I refer
to RFC987.

If a BITNET internal mail system that has NO internet "name"
wants to generate a globally unique id, how can it do that?
It could create @node.BITNET as a suffix  and ((un)fortunately)
there would be no conflict with a "correct" internet message-id.

What about all the uucp mail systems that have no internet name?
Ah hm, somehow someone managed to get a @uunet.uu.net suffix.....

These examples/questions are somewhat heretic.

Good morning

Peter Sylvester GMD Bonn

Received: from icsa.rice.edu (TCP 20012417002) by MC.LCS.MIT.EDU 12 Apr 89 19:20:59 EDT
Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2) with BSMTP id 3692; Wed, 12 Apr 89 18:20:58 CDT
Received: by RICE (Mailer R2.01) id 3689; Wed, 12 Apr 89 18:20:53 CDT
Date:         Wed, 12 Apr 89 18:11:23 CDT
From:         "Mark R. Williamson" <MARK%RICE@icsa.rice.edu>
Subject:      Re: Multi-Networked Hosts (was Hostname in Message-ID)
To:           HEADER-PEOPLE@MC.LCS.MIT.EDU
In-Reply-To:  Message of Wed, 12 Apr 89 12:39:00 PDT from
 <LDW%MVSA.USC.EDU@MITVMA.MIT.EDU>

On Wed, 12 Apr 89 12:39:00 PDT Leonard D Woren said:
>> names.....sites that insist on using names not in the DNS only manage
>> to greatly confuse things.
>
>YES!  The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should
>be banned, and Bitnet sites with DNS-style names without MX service
>should be banned.

WHOA!  The :Interconnect.MX doesn't relate to this topic!  It flags
quite a different situation, namely that a domain (Internet registered)
has nodes reachable only by MX records, so that sites operating
gateways which don't understand MX records won't try to ship mail to
those domains through the Internet.  If you want to ban names not in
the DNS, you want to ban entries with :Interconnect.NO, not MX which,
like :Interconnect.YES, flags domains accessible through DNS.

Mark R. Williamson

Received: from MCC.COM (TCP 20017405412) by MC.LCS.MIT.EDU 12 Apr 89 19:22:08 EDT
Received: from OGHMA.ACA.MCC.COM (OGHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 12 Apr 89 18:13:04-CDT
Date: Wed, 12 Apr 89 18:11 CDT
From: David Vinayak Wallace <Gumby@MCC.COM>
Subject: No Domain service => No Domain names?
To: Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
cc: Danny Padwa <PADWA@HUSC3.HARVARD.EDU>, header-people@MC.LCS.MIT.EDU
In-Reply-To: The message of 12 Apr 89 14:39 CDT from Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Message-ID: <19890412231137.7.GUMBY@OGHMA.ACA.MCC.COM>

    Date:    Wed, 12 Apr 89 12:39 PDT
    From:    Leonard D Woren                      <LDW%MVSA.USC.EDU@mitvma.mit.edu>

    I have repeatedly argued this point in a number of Bitnet forums, and
    I always lose.  My argument is that sites that are not reachable on
    the Internet (via DNS) MUST NOT be allowed to use DNS-style names.
    Bitnet-only sites all too often don't have a reasonable perspective on
    these things.

I guess I don't have a resonable perspective either.  I understand your
position but not your argument; in fact I haven't the faintest idea why
forbidding it would be useful.

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 12 Apr 89 20:11:32 EDT
Received: by INFOODS id <00000156143@INFOODS.MIT.EDU> ;
       Wed, 12 Apr 89 20:05:26 EDT
Date: Wed, 12 Apr 89 19:27:45 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: RE:  Re: Hostname in Message-Id
To: Peter Sylvester +49 228 8199645 <GRZ027%DBNGMD21.BITNET@MITVMA.MIT.EDU>
X-VMS-Mail-To: EXOS%"Peter Sylvester +49 228 8199645 <GRZ027%DBNGMD21.BITNET@mitvma>"
Message-ID: <890412192745.00000156143@INFOODS.MIT.EDU>
cc: header-people@MC.LCS.MIT.EDU

Peter,
  I agree with what you are saying (if I understand it), but am not sure 
what it means in practice.  Fortunately, nothing in RFC822 (or anywhere 
else) guarantees universality of names, only uniqueness within a given 
name space, of which the Internet DNS for host names is one.  JANET is a 
different name space, regardless of what obvious mapping rules apply 
between Internet domain names and JANET domain names.  I hope that the 
gateways either translate message-ids, or don't translate them, but that
they do it (or not) consistently. 
  In my purist capacity, I have a lot of reservations about the 
Internet-registered domain ".UK", since, while there may be a host 
"known as" xxx.AC.UK, there are no hosts whose "name is" xxx.AC.UK, only 
a host whose "name is" UK.AC.xxx.  The reversing operation implies that 
the we have GATEWAYs, not simply Mail eXchangers, between the two 
networks.  That is, of course, the case, but it implies Internet
addressing to, e.g., user%UK.AC.xxx@gateway, where the "gateway" is an 
Internet DNS name, not use of an MX to user@xxx.AC.UK.  In my practical 
capacity, I'd be happy to be spared the annoyance.
  That said, a *gateway* getting hold of a message ID might decide to 
insure its uniqueness in the target network.  That is clearly an 
optional service, at least as I read the protocols.  And, whatever the 
transformation is, probably the gateway name is part of it.  And that 
gateway, and all of the other gateways between the two networks, had 
better know how to undo what they have done.
  The real message, again, is that RFC822 message ids were never 
intended to be taken too seriously.  They are, after all, even 
optional--a message need not have one at all.

>All Internet/Bitnet gateways do at least some EBCDIC/ASCII
>translation. This might not be considered as "header munging"
>but it is known that IBM has some problems to define globally
>unique translate tables for some special characters.
   It is header and message munging.  But the theory is that this is 
transparent for two reasons: (i) the same transformations are performed 
going through those gateways from right to left as are performed going 
from left to right.  For that purpose, it is not relevant whether the 
translations are correct (whatever that means), only that they are
invertible.

   As I suggested in my earlier note, much of the problem underlying 
Leonard's complaints is that large fractions of BITNET/NETNORTH/EARN/etc 
behave as if they are part of the Internet name space, without being 
part of the Internet name space.  If they were, then every name on those 
networks that looks like a DNS name could be resolved by asking an
Internet name server and each and every one of those server inquiries 
would yield either an "A" record--an IP address to which mail could be 
sent for that host--or an MX record that would point to a 
carefully-chosen "nearby" gateway, with no nonsense about "INTERBIT" 
from the Internet side.  But they aren't, and people are breaking the 
rules and introducing much confusion.  To make things worse, some of 
those hosts pretend to be part of the Internet name space for some 
purposes and not for others.

> I would like to know how I could gateway some internet message-id 
>into some X.400 ip-message-id *without* "header-munging", in this
>case it is at least a different "encoding". For details I refer
>to RFC987.
  Here, there is absolutely no problem (or a great problem, but a 
different one).  The X.400 system does not use RFC822.  It doesn't even 
claim to use RFC822, but "mostly" use it (which is how I would describe 
both BITNET/etc and most of the UUCP sites).  To get from an X.400 mail 
system to an Internet mail system, you need a gateway and a serious 
header translation activity (not just "munging", which usually is used 
to refer to the modification of headers between one RFC822 network and 
another (nearly) RFC822 network).  I would not expect message-ids to 
translate in any particularly useful way, at least in the absence of a 
strong standard, which RFC987 is not.

>If a BITNET internal mail system that has NO internet "name"
>wants to generate a globally unique id, how can it do that?
>It could create @node.BITNET as a suffix  and ((un)fortunately)
>there would be no conflict with a "correct" internet message-id.
   It does whatever it likes.  Once you move outside the Internet name 
space, and the DNS, the *meaning* of the syntax is compromised.  An 
extreme purist might state this as "if you don't have a registered 
domain name, then you are not conforming to RFC822, regardless of what 
syntax you choose".  Within BITNET, there is no problem with 
@node.BITNET.  Within some other network, there might be no problem with 
@latitude.longitude.  If these messages cross into the Internet, then 
the gateways have to figure out what to do with them, and, more 
important, whether errors of type I are better or worse than errors of 
type III.  In other words, do you prefer to risk deciding that something 
is unique when it isn't, or deciding that something isn't unique when it 
is?
  The one problem the gateway has is that intelligent choices cannot be 
made heuristically.  If people on BITNET care what message-ids look like 
in BITNET and/or what the gateways should do with them, then appropriate 
technical committees should be convened to settle on the appropriate 
syntax and generating rules for BITNET message id fields, and then the 
gateways could take advantage of those rules.

>What about all the uucp mail systems that have no internet name?
>Ah hm, somehow someone managed to get a @uunet.uu.net suffix.....
    There is a misunderstanding here.  The UUNET consortium made a case, 
just as CSNET did, for what is, relative to the original rules, a minor 
(and convenient) kludge.  So there is a domain ".net", with a domain 
server, and it has a few subdomains.  One of those is ".uu.net", another 
is ".cs.net".  The latter has several hosts, some of which are not even 
gateways.  As far as the DNS is concerned, the fact that UUNET.UU.NET is 
the MX host for a lot of DNS-registered uucp sites is nothing more than 
an interesting coincidence.  And its appropriate behavior with regard to 
message ids is just like the BITNET situation: if there were a rule and 
consistency with the UUCP community about the assignment of message-ids, 
then the gateway could do something interesting, intelligent, and 
consistent with them (whether to preserve or to modify).  If there is no 
rule, then it does whatever it does, and people should not over-rely on 
message-ids.
  And, again as with BITNET, the problems arise with hosts that exist on 
both networks.  If I can get mail either from the Internet or from UUCP 
directly, and I care about message IDs, I need to know the rules for 
message IDs on both the UUCP and Internet sides, and then I need to know 
exactly what transformations the gateway is performing.  Since there is 
more than one gateway, I also need to hope that all of them do the same 
thing (whatever it is), or my UA is going to need to track back through 
the Received paths (if they were supplied) to figure out which gateways 
were involved so that I can reverse (or canonicalize) their 
transformations.

No one ever said that this was going to be easy.

John Klensin, MIT


Received: from hanna.cac.washington.edu (TCP 20064074001) by MC.LCS.MIT.EDU 13 Apr 89 00:02:57 EDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu (5.61/6.12)
	id AA10432; Wed, 12 Apr 89 21:00:50 -0700
Return-Path: <MRC@WSMR-SIMTEL20.Army.MIL>
Date: Wed, 12 Apr 1989 20:57:30 PDT
From: Mark Crispin <MRC@WSMR-SIMTEL20.Army.MIL>
Subject: re: Hostname in Message-Id
To: Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Cc: Header People <Header-People@MC.LCS.MIT.EDU>
In-Reply-To: Message of 303616 from Leonard D Woren
Message-Id: <MS-C.608443050.1103527590.MRC@WSMR-SIMTEL20.Army.MIL>

Leonard Woren -

     I agree with you 100%.  The whole point of a Message-ID is defeated if
mail gateways are allowed to transmogrify them.  It is for this reason that I
feel it was somewhat of a mistake to have the local-part@domain syntax for
message IDs, since it was inevitable that someone would get this idea...

-- Mark --

-------

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 01:46:28 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5491; Wed, 12 Apr 89 22:42:44 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 2702; Wed, 12 Apr 89 22:41:40 EDT
Date:    Wed, 12 Apr 89 19:38 PDT
To:      David Vinayak Wallace <Gumby@MCC.COM>
Cc:      header-people@MC.LCS.MIT.EDU
From:    Leonard D Woren                      <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Subject: Re: No Domain service => No Domain names?

Somehow, we've gotten a bit off the track of "Header-People".  I
didn't realize how big the can of worms was that I opened by my
original query about Message-Id.  (Well,
I *thought* that I was asking a
_simple_ question...)

It seems that I may have a partial (or complete  :-( )
misunderstanding of the Bitnet :Interconnect. definition and usage.
In any case, if my mailer is handed a piece of mail with a DNS-style
name for the destination, assuming it has MX support (which it doesn't
yet -- ACC, are you listening???), then my mailer better be able to
send that piece of mail out over the Internet.  I guess the following
problem may be unrelated, but the way things are now, mail to Internet
sites often goes out over Bitnet, for example, postings to
Header-People.  I wonder if there's a bug in my MTA in the address
form that it uses for this case?  Should it be using
LDW@USCMVSA.BITNET to send to MC.LCS.MIT.EDU, because it is going to
use the Bitnet path to MIT?  Even so, why does MIT mangle the address
into LDW%MVSA.USC.EDU@MITVMA.MIT.EDU?  Shouldn't it leave it as
LDW@MVSA.USC.EDU???

          Leonard D. Woren
          Senior MVS Systems Programmer
          MVS Postmaster  <LDW@USCMVSA.BITNET>  <LDW@MVSA.USC.EDU>
          University of Southern California

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 01:47:12 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5597; Thu, 13 Apr 89 00:48:05 EDT
Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 2971; Thu, 13 Apr 89 00:48:04 EDT
To:       HEADER-PEOPLE@MC.LCS.MIT.EDU
From:     "Roger Fajman" <RAF%NIHCU.BITNET@mitvma.mit.edu>
Date:     Thu, 13 Apr 89  00:04:11 EDT
Subject:  Re:  Multi-Networked Hosts (was Hostname in Message-ID)

> >YES!  The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should
> >be banned, and Bitnet sites with DNS-style names without MX service
> >should be banned.
>
> WHOA!  The :Interconnect.MX doesn't relate to this topic!  It flags
> quite a different situation, namely that a domain (Internet registered)
> has nodes reachable only by MX records, so that sites operating
> gateways which don't understand MX records won't try to ship mail to
> those domains through the Internet.  If you want to ban names not in
> the DNS, you want to ban entries with :Interconnect.NO, not MX which,
> like :Interconnect.YES, flags domains accessible through DNS.
>
> Mark R. Williamson

No, that isn't right either.  I quote from DOMAIN GUIDE (available from
LISTSERV@BITNIC):

:interconnect - This field can have one of three values:

YES This domain is directly connected  to the Internet,  and mail that
    can be sent  via BITNET/EARN/NETNORTH  can therefore  also be sent
    via the Internet.   If even a single host within the stated domain
    cannot be reached directly via the Internet,  then the domain must
    be defined as either NO or MX.

NO  This  domain  is wholly or partly inaccessible  from the Internet.
    This domain  could be one of the non-Internet-style  domains  like
    .HEPNET  and  .UUCP,  or it might  be only  registered  with  (not
    connected  to) the Internet.  It could also be a domain now in the
    process  of connecting  or  one  simply  preferring  delivery  via
    BITNET.  Mail to this domain must be sent via BITNET/EARN/NETNORTH
    to the named gateway  (otherwise,  delivery  may be impossible  or
    unnecessarily slow).

MX  This  domain is wholly  accessible  from the Internet,  but one or
    more hosts within the domain are not directly connected.  Sites in
    BITNET/EARN/NETNORTH  providing general gateway services that lack
    the ability  to handle  MX records  must  send  any mail  for this
    domain to the named gateway,  but mailers  equipped  to handle  MX
    records may send mail via the Internet.

:served - This field indicates that BITNIC is supplying nameservice on
  your behalf via the Berkeley  and Harvard nameservers.   If you have
  coded :interconnect.MX or :interconnect.YES, then remove the :served
  tag from your entry.   If you have coded  :interconnect.NO  then you
  can request  BITNIC nameservice.   If you receive  nameservice  from
  sites other than Berkeley  and Harvard,  then remove the :served tag
  from your entry.

  If your domain  already  appears  in DOMAIN  NAMES,  and you wish to
  obtain  nameservice  support  (for example,  if you are losing  your
  Internet  connection  and, thus, your current  nameservice),  please
  contact DOMAINS@BITNIC and request this service for your domain.

NOTE: "directly  connected  to the Internet" refers only to hosts that
listen to TCP port 25 for incoming mail and have IP addresses.

Unquote.

All BITNET domains are in the DNS because all should be providing their
own name service or getting it provided for them by Harvard and
Berkeley.  The only exceptions are those few, such as .UUCP, that don't
conform to the rules of the DNS and so cannot have name service.  No
more like those are being created.

Now there can be hosts in BITNET domains that are not reachable through
the Internet.  This is a clearly undesirable situation.  Ideally,
:interconnect.NO should be used only for BITNET domains that are not
connected to the Internet at all.  If there is a domain that is only
partially reachable through the Internet, then it must be providing its
own name service and the situation should be correctable by adding MX
records pointing to an appropriate INTERBIT gateway for the BITNET-only
hosts.  The domain would then be designated :interconnect.MX.

Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 13 Apr 89 04:03:25 EDT
Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa01698; 13 Apr 89 7:57 GMT
To: John C Klensin <KLENSIN@infoods.mit.edu>
cc: header-people@mc.lcs.mit.edu
Subject: Re: Hostname in Message-Id 
Phone: +44-1-380-7294
In-reply-to: Your message of Wed, 12 Apr 89 19:27:45 -0400.
             <890412192745.00000156143@INFOODS.MIT.EDU> 
Date: Thu, 13 Apr 89 08:57:33 +0100
Message-ID: <20337.608457453@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@Cs.Ucl.AC.UK>
Source-Info:  purple.cs.ucl.ac.uk

Anyon interested in gatewaying between JNT Mail (Janet) and RFC 822
should real mailgroup note 15 "Gatewaying Between RFC 822 and JNT Mail",
by myself (May 1984).  This is the approved approach.  

The document may be obtained from info-server@cs.ucl.ac.uk   

Mesage Ids are not mentioned.  This was an error.  A gateway should 
reverse the domain order in message Ids.  The MMDF based gateways (
nsfnet-relay (aka nss.cs.ucl.ac.uk), ean-realy, and ukc) do not get this
right.   I don't think it is too big a deal.


Steve

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 09:02:30 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 6364; Thu, 13 Apr 89 09:04:21 EDT
Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 5393; Thu, 13 Apr 89 09:03:11 EDT
Received: by BUCLLN11 (Mailer R2.03B) id 2736; Thu, 13 Apr 89 14:02:13 +0200
Date:         Thu, 13 Apr 1989 14:02:04 +0200
From:         "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@mitvma.mit.edu>
Message-Id:   <890413.131040.+0200.af@sei.ucl.ac.be>
Subject:      Re: Hostname in Message-Id
To:           Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
In-Reply-To:  Message of Wed, 12 Apr 89 07:48:06 EDT from
 <KLENSIN@INFOODS.MIT.EDU>

>   But correct universal use of a Message-ID requires going well beyond
>what RFC822 specifies.  Assume that I'm operating in a workstation
>environment, with a local UA, but with the MTA on the next machine down
>the line.  Assume further that my "address" is on the machine with the
                               .
                              etc...
    (in a few words : what should sit in the 'host' field of the
     message-id in a complex environment)

The very  fact that this problem  exists is in my  (humble?) opinion one
more indication that the structure  of the current addresses (user@host)
is completely  outdated. It dates  back when time-sharing  machines were
the  norm. Today,  giving  the  kind of  environments  described in  the
referred message, individuals should have addresses of the form :
        'name.domn.domn-1.  .dom2.dom1'.
To  say  it otherwise  :  the  DNS should  be  used  up (down?)  to  the
individual level.

This  would eliminate  problems  like  the one  stated  in the  referred
message, and also would allow a more regular treatment of all cases. For
example, name servers  could contain MX records for  individuals. Was it
not the original intent of the DNS  that any 'object' in the world could
someday be designated  by a domain? The syntax  'user@host' forbids this
to be true for a large class of objects, like mailboxes and processes...

This may be completely heretic, idiotic  or worse. If so, I would really
enjoy a correction. /AF

Received: from HUSC3.HARVARD.EDU (TCP 20031600465) by MC.LCS.MIT.EDU 13 Apr 89 09:44:46 EDT
Date: Thu, 13 Apr 89 09:41 EDT
From: Danny Padwa <PADWA@HUSC3.HARVARD.EDU>
Subject: Re: Hostname in Message-Id
To: Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
X-VMS-To: IN%"Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>",PADWA


Sorry to throw more fuel on the fire, but one of the major problems encountered
in this MX-records-for-BITnet-only-domains question is that very few BITNET
domains are actually registered on the servers at Harvard and Berkeley (or
at least the one at Harvard). In fact, the following is a complete list
(if it ain't here, Harvard doesn't have info about it!):

alleg.edu        hampshire.edu    pepperdine.edu   trinity.edu
br               ie               pt               uri.edu
bsu.edu          irl              rose-hulman.edu  urich.edu
bucknell.edu     maine.edu        sg
claremont.edu    naic.edu         towson.edu
conncoll.edu     oberlin.edu      trincol.edu

Berkeley may know about some that Harvard doesn't (doubtful). The import of
all of this is that if I (on my multi-networked host) have a message for
any BITnet-only domain that is not in the above list, it probably will
not be handled properly!!! The clear solution is to disallow Internet messages
with return addresses for invalid domains. Gateway filtering? :-) :-)

			- Danny Padwa
			  Harvard VMS Networking

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 10:20:36 EDT
Received: by INFOODS id <0000020B031@INFOODS.MIT.EDU> ;
       Thu, 13 Apr 89 10:19:55 EDT
Date: Thu, 13 Apr 89 10:17:41 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: RE:        Re: Hostname in Message-Id
To: "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@MITVMA.MIT.EDU>
X-VMS-Mail-To: "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@mitvma>
Message-ID: <890413101741.0000020B031@INFOODS.MIT.EDU>
cc: header-people@MC.LCS.MIT.EDU

Alain FONTAINE writes:
>    (in a few words : what should sit in the 'host' field of the
>     message-id in a complex environment)
>
>The very  fact that this problem  exists is in my  (humble?) opinion one
>more indication that the structure  of the current addresses (user@host)
>is completely  outdated.
    I think "completely" is an exaggeration.

> It dates  back when time-sharing  machines were the  norm.
    At least partially true, although that criticism is more 
appropriately addressed to RFC822 than to the DNS.  More on that below.

> Today,  giving  the  kind of  environments  described in  the
>referred message, individuals should have addresses of the form :
>        'name.domn.domn-1.  .dom2.dom1'.
>To  say  it otherwise  :  the  DNS should  be  used  up (down?)  to  the
>individual level.
    I think the user / host distinction is still useful for some 
purposes.  If I were to make the above statement, it would actually make 
a user /host / domain distinction.  That is another discussion.  
However, please keep in mind that the DNS is defined in terms of the 
identification of "resources".  I prefer not to be a resource-object, 
thank you.  And the discussions of mail and mail headers in this list 
tend to obscure the fact that, when the domain resolvers are used to 
identify host-type resources, there is a big difference between "A" and 
"MX" records.  For example, I can usually make Telnet or FTP connections 
to the latter (and I can even ask the DNS whether or not those protocols 
are supported).  FTP connections to people are not, in general, 
practical.
  Now there are alternate ways to think about DNS-like systems that 
would use different syntax, semantics, and notions about "objects".  You 
are unlikely to change the DNS today.  Instead, if this problem is 
interesting, look at X.500.  If it does not meet your needs, or seems to 
violate things that you have known, from experience, for years, please 
start complaining to your national CCITT administration, write articles, 
etc.  We can avoid repeating the X.400 debacle iff whatever weaknesses 
exist in X.500 are identified early on, and fixed before there are 
implementations in production use.

>This  would eliminate  problems  like  the one  stated  in the  referred
>message, and also would allow a more regular treatment of all cases. For
>example, name servers  could contain MX records for  individuals. Was it
>not the original intent of the DNS  that any 'object' in the world could
?someday be designated  by a domain? The syntax  'user@host' forbids this
>to be true for a large class of objects, like mailboxes and processes...
   I don't believe this would fix the problem raised in the original 
mesasge.  I don't have time to debate the point, but much of that 
original issue derived from partial adherence to the DNS, resulting in 
the same "host" having different names in different networks.  Partial 
compliance to any system, and the absence (or non-observance) of 
canonicalization rules, will produce similar difficulties.
   The message-id problem can be "fixed" with no alterations to the DNS, 
in any event.  The problem here is not the DNS, it is:
 (a) local decisions about observance/non-observance and interpretations 
about what to do under various circumstances.  The RFCs provide little 
guidance, and are sometimes ignored regardless.
 (b) While the criticism of "developed for timesharing" is only 
partially valid for the DNS, it is clearly applicable to RFC822.  That 
protocol is a slight revision, to fix major problems and confusions 
(note "slight" and "major") in much older protocols that date almost to 
the beginning of the ARPANET (back to when we discovered that mail 
should not, after all, just be a special case of file transfer).  That 
field is easily extended in reasonable ways.  Most of the extensions can 
be made within the existing syntax, by decisions at an individual host, 
but they are worthwhile for close message identification elsewhere only 
if there is a protocol that specifies -- really -- what should be in 
there and how the subfields should be handled.  The postoffice issue 
is, for example, easily handled by a close reading of 4.6.1 of RFC822: 
"by the host that generates it".  "It":= the message id, not the
message. Can the postoffice machine (which is what is running SMTP) 
generate a unique message-id?  Sure.  Can it identify the user, as it 
knows her or him in the local-part?  Sure, note "not necessarily 
meaningful to humans".  RFC822 is not broken, only underspecified for 
some of the uses to which people are trying to put it.  The DNS is still 
less broken, at least in these cases.

Summary:
 - The DNS is not all things to all people.  Neither of the problems 
identified in this discussion--message-id uniqueness and unneeded 
gateway routings--are serious challenges to it.
 - If you don't like the DNS, start studying X.500, which you might be 
able to affect and, more important, probably has a longer-term impact.
 - Incompatible changes to the DNS are unlikely to happen at this point 
unless catastrophic problems are demonstrated.  To my knowledge, none 
have been.  These mail difficulties are certainly not in that category.
 - RFC822 never guaranteed that Message-IDs could be reliably used for 
some of the purposes to which people now want to put them.  Many of the 
problems arise in conjunction with those uses and could, in principle, 
be solved, by specification of the format of the local-part of the 
Message-ID field.
 - Most of the *real* problems result from a combination of misbehaving 
gateways (which make transformation they can't reverse or which can't 
make choices that require technology unavailable to them) or mis-use of 
the DNS.  The misuses include hosts that use DNS-style names that are 
not registered and hosts that use multiple names.  These problems are 
violations of the protocols, violations of the spirit of the DNS, 
violations of good sense, or just consequences of complicated problems 
that have been inadequately thought out and documented.  Writing more 
and better rules might solve the last of these; it does nothing for the 
others. 

>This may be completely heretic, idiotic  or worse. If so, I would really
>enjoy a correction. /AF
  It is none of those things.  It is, however, severely non-pragmatic:
 - on a practical, rather than theoretical basis, you should be looking 
for the minimal changes that will fix a problem.  "Replace the DNS" is 
not the minimal change in this situation.  Even theory is perhaps better 
applied to the next version of X.500, not the DNS.
 - And, to quote an old New England comment, "if it ain't broke, don't 
fix it".  It is not clear that there is anything broken in the DNS or in 
the RFC822 definition of the Message-ID field.  What is "broken", 
because it has never been adequately defined, is how gateways between 
highly interconnected networks should behave under a series of 
circumstances.  In the USA, this problem arises with the huge number of 
interconnections and gateways between UUCP and the Internet and the 
slightly less huge number between BITNET and the Internet (in case those 
of you on the far side of the water don't know, the INTERBIT sites are a 
tiny fraction of the institutions with gateway capability or 
multi-hosted machines).  In the UK, someone should verify that the 
transformations performed by the Internet gateway in London and by the 
EARN gateway at Rutherford are identical or properly identified, and 
that each gateway is able to reverse the transformations of the other.  
Those of you who have only a single gateway connecting a non-Internet 
network with the Internet, or a non-RSCS network with EARN, or whatever, 
should consider yourselves fortunate, as many problems are thereby 
eliminated.
   John Klensin,  Klensin@INFOODS.MIT.EDU

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 11:48:22 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 6842; Thu, 13 Apr 89 11:50:15 EDT
Received: from CUNYVM.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 7173; Thu, 13 Apr 89 11:50:14 EDT
Received: by CUNYVM (Mailer R2.01) id 2484; Thu, 13 Apr 89 11:47:22 EDT
Date:         Thu, 13 Apr 89 11:32:07 EDT
From:         Ben Yalow <YBMCU%CUNYVM.BITNET@mitvma.mit.edu>
Subject:      RE:  Re: Hostname in Message-Id
To:           HEADER-PEOPLE@MC.LCS.MIT.EDU
In-Reply-To:  Message of Wed, 12 Apr 89 19:27:45 EDT from
 <KLENSIN@INFOODS.MIT.EDU>

>   As I suggested in my earlier note, much of the problem underlying
>Leonard's complaints is that large fractions of BITNET/NETNORTH/EARN/etc
>behave as if they are part of the Internet name space, without being
>part of the Internet name space.  If they were, then every name on those
>networks that looks like a DNS name could be resolved by asking an
>Internet name server and each and every one of those server inquiries
>would yield either an "A" record--an IP address to which mail could be
>sent for that host--or an MX record that would point to a
>carefully-chosen "nearby" gateway, with no nonsense about "INTERBIT"
>from the Internet side.  But they aren't, and people are breaking the
>rules and introducing much confusion.  To make things worse, some of
>those hosts pretend to be part of the Internet name space for some
>purposes and not for others.
>
>
>No one ever said that this was going to be easy.
>
>John Klensin, MIT
>
>

Actually, the whole INTERBIT hack for BITNET->Internet mail is only
known to the BITNET side (in theory).  A BITNET node needs to know that the
gateway is at SMTP@INTERBIT, and to send mail to there - only the INTERBIT
sites need to know that that INTERBIT isn't a real node hung off CUNYVM
the way the maps would indicate.  From the Internet side, you can send mail
to a user at a BITNET node by sending mail to user%bitnode.BITNET@gateway,
where gateway is any machine you know has agreed to act as a gateway (such
as CUNYVM.CUNY.EDU == CUNYVM on BITNET).  All of the INTERBIT machines
do header munging to produce that address on the BITNET addresses we
send out (like From:, etc), and do the reverse transformation on the
way back - an Internet site can usually just reply without worrying
about address transformations.

The problems (aside from no MX on the INTERBIT gateways, which should
change soon) come from domain style names on purely BITNET sites, and
those are getting MX service from Harvard/Berkeley as new ones are
registered.  The other problem comes from figuring out which physical
network to send mail on between domains that are on more than one
network, and this is a problem the domain system is NOT designed to
deal with - domains are purely administrative methods of dealing
with namespace management, and don't handle transport issues.  The
problems of which transport level services to use are probably not
solvable merely by looking at a domain name - you'll get a path that
will work, but may not be optimal.

Solving THAT problem is much tougher, and I don't know that anybody
has really even figured out what should be done, much less how to do it.
-----------------

Ben Yalow
BITNET: YBMCU@CUNYVM         INTERNET: YBMCU@CUNYVM.CUNY.EDU
City University of New York      555 W 57 St  NY, NY 10019
212-903-3623

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 13:26:30 EDT
Received: by INFOODS id <00000319092@INFOODS.MIT.EDU> ;
       Thu, 13 Apr 89 13:22:20 EDT
Date: Thu, 13 Apr 89 13:21:23 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject:  RE:  Re: No Domain service => No Domain names?
To: header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu"
Message-ID: <890413132123.00000319092@INFOODS.MIT.EDU>

Leonard,

  (1) Yes, BITNET sites without DNS registrations should not use DNS 
style names.  If they do, they should expect to not have mail returned, 
something that may be about to start happening to them, by coincidence.  
  But BITNET is, by definition, limited anarchy.  So, if, by custom or 
convention, these are legal names within BITNET, then they are legal 
names within BITNET.  They just are not legal names on the Internet.
  Beyond that, what means "forbid".  RFC822 "forbids" the use of time 
zones like "CEZ".  If I had a nickel...   What you going to do, call the 
protocol police?  Problem is, there are no protocol police and, if there 
were, they would be powerless.  The only realistic form of "forbid" is 
pressure on the gateway maintainers to not pass certain classes of 
"illegal" stuff. 

  (2) MITVMA trashes your address for two reasons.  The first dominates, 
but the second should:
 (2a) They can't transform it into <@MITVMA.MIT.EDU:user@host> because
the "version 1" BITNET mailers can't deal with that form.  Version 2
can, and you will start seeing this stuff.  However, its effective use
depends on the receiving UA having enough sense to say "I know that
'host' is a DNS name, and I can ignore that source routing and look the
thing up myself".  Few do.  So, once MITVMA does that rewrite, when I
reply to you, you will get the message over the Internet, but via
MITVMA, not direct from here. 
 (2b) <@MITVMA.MIT.EDU:user@mumble.BITNET> or
<@MITVMA.MIT.EDU:user@host.unregistered> are DNS-illegal addresses. 
user%mumble.BITNET@MITVMA.MIT.EDU and 
user%host.unregistered@MITVMA.MIT.EDU are legal addresses - always - since 
they say to send to a valid DNS host which knows how to interpret the 
local-part.  In theory, if the gateway is well-behaved, it puts out 
direct addresses (no routing) or the source route form for all addresses
arriving over BITNET that are DNS[-registered] names, and %-kludge
addresses for non-DNS names.  If I were making the decisions, I'd apply
the following rules to a hostname arriving from BITNET:
 1) If the host name contains no periods, use user%host@MITVMA.MIT.EDU.  
Or user%host.BITNET@MIT..., whichever makes the SMTP server happier.
 2) If the host name contains .BITNET, use user%host.BITNET@MITVMA...
 3) If the host name contains periods and is not in the second category, 
actually do the DNS lookup.  If the lookup succeeds, use 
<@MITVMA.MIT.EDU:user@host>.  If it fails, reject the mail and send it 
back, with a not-very-polite note explaining how easy it is to register 
domain names and how to do it.
    It would not require very many invocations of this rule to solve the 
problem.  But I don't make the decisions, and you should not hold your 
breath.  Discussions with BITNET tech reps and on the INTERBIT list 
are probably the right way to pursue this if you are interested.

>I guess the following
>problem may be unrelated, but the way things are now, mail to Internet
>sites often goes out over Bitnet, for example, postings to
>Header-People.
  This is, in and of itself, a bug, but I think we've covered that.
>  I wonder if there's a bug in my MTA in the address
>form that it uses for this case?  Should it be using
>LDW@USCMVSA.BITNET to send to MC.LCS.MIT.EDU, because it is going to
>use the Bitnet path to MIT?
  Rule 1: The DNS is supposed to be path-independent.
  Rule 2: DNS names are legal names on BITNET, eight-character NJE/RSCS
host ids are legal names on BITNET, and NJE/RSCS host ids suffixed by 
.BITNET are legal names on BITNET.  Only DNS-like names that are not 
registered are in a gray area.
  Rule 3: If something is transmitted between BITNET nodes, rule 2 
applies.  If something is transmitted between BITNET nodes and then 
through a gateway onto the Internet, enforcement of Internet naming 
rules (in which only DNS *host* names are legal and local-parts don't 
count) is a gateway responsibility.  You should not worry about tricking 
the gateway into doing something "better"; you can't win at that game.
  Rule 4: Given rule 2, and the arguments for "one box, one name" which 
you understand very well, using the DNS name in your address is the 
right thing to do, in both networks.  What names the MTAs use to 
communicate with each other is another question, but who cares.  Same 
comment on Message-IDs, which is what I tried to say several days ago.

>  Even so, why does MIT mangle the address
>into LDW%MVSA.USC.EDU@MITVMA.MIT.EDU?  Shouldn't it leave it as
>LDW@MVSA.USC.EDU???
  Nope.  See above.  It can "leave" it only if it is willing to take 
responsibility for two things:
 (a) MVSA.USC.EDU is a DNS-name (not merely something that looks like 
one).
 (b) MVSA.USC.EDU, as a DNS-name, resolves to the same host as 
MVSA.USC.EDU on BITNET does.  The real argument for "no domain, no name" 
is to make this question go away so that identity can be relied upon.
  And, if I had my druthers, it would apply a fourth rule, s.t. it would 
"leave it" only if, in addition,
 (c) MVSA.USC.EDU resolves to an "A" record (an IP address), not an MX.  
If it resolves to an MX, I'd rather see either:
  <@MITVMA.MIT.EDU:LDW@MVSA....> or
  <@designated-mail-exchanger:LDW@MVSA...>
rather than "leaving" the thing, at least until MX support is
universally available.   Even then, this is useful and harmless. 

  John Klensin, Principal Research Scientist, MIT
  Klensin@INFOODS.MIT.EDU


Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 13:50:14 EDT
Received: by INFOODS id <0000026B072@INFOODS.MIT.EDU> ;
       Thu, 13 Apr 89 13:46:30 EDT
Date: Thu, 13 Apr 89 13:45:29 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re: Hostname in Message-Id
To: header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu"
Message-ID: <890413134529.0000026B072@INFOODS.MIT.EDU>

My, am I sorry I started this.

Ben Yalow is completely correct.  I mentioned the INTERBIT business from 
the Internet side only because I've seen yet another suggestion this 
week that involves a convoluted scheme to make "INTERBIT" or some 
surrogate for it a legal Internet name.  It is, as Ben says, a hack, and 
should be kept a BITNET-local hack.

>All of the INTERBIT machines
>do header munging to produce that address on the BITNET addresses we
>send out (like From:, etc), and do the reverse transformation on the
>way back - an Internet site can usually just reply without worrying
>about address transformations.
  I think part of this discussion has been about whether the header 
munging that is done is optimal, or as close to optimal as possible.  It 
clearly works.

>The problems ... change soon) come from domain style names on purely
>BITNET sites, and those are getting MX service from Harvard/Berkeley as
>new ones are registered.
  Those that ask and/or register.  Those that don't ask *are* the
problem. 

> The other problem comes from figuring out which physical network to
>send mail on between domains that are on more than one network, and ...
  Looking at the name can't help.  Looking at the resource record might, 
but, as you say, it is a tough problem.  On the other hand, having a 
BITNET->Internet gateway map user@foo.bar.edu, where foo.bar.edu is a
valid DNS name that will return an "A" record, into, e.g., 
user%foo.bar.edu@cunyvm.cuny.edu (because the message was received from
BITNET and is being sent to the Internet) tends to obscure whatever 
intelligence an MTA on the Internet might try to apply.  If that MTA is 
well-behaved, it *must* send the message back to cunyvm, since it is 
forbidden to try to construe a local-part.  And I guess that is the core 
of the problem as I see it.
  John Klensin
  Klensin@INFOODS.MIT.EDU


Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 18:29:22 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 8204; Thu, 13 Apr 89 18:31:17 EDT
Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 5375; Thu, 13 Apr 89 18:31:16 EDT
To:       PADWA@HUSC3.HARVARD.EDU
cc:       HEADER-PEOPLE@MC.LCS.MIT.EDU
From:     "Roger Fajman" <RAF%NIHCU.BITNET@mitvma.mit.edu>
Date:     Thu, 13 Apr 89  18:27:10 EDT
Subject:  Re:  Hostname in Message-Id

> Sorry to throw more fuel on the fire, but one of the major problems
> encountered
> in this MX-records-for-BITnet-only-domains question is that very few BITNET
> domains are actually registered on the servers at Harvard and Berkeley (or
> at least the one at Harvard).  (remainder deleted)

What is supposed to be the case is that all the others are providing
their own name service.  A few months ago I was assured by John
Chandler, who has been involved in registration of BITNET domains, that
that was in fact the case.  He also told me that care would be taken to
insure that new domains would have name service.  I sent him a copy of
your message to see if he can verify that this is continuing to be
done.

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 23:35:34 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 8898; Thu, 13 Apr 89 23:37:28 EDT
Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 8829; Thu, 13 Apr 89 23:37:27 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
 BSMTP id 9067; Thu, 13 Apr 89 23:35:30 EDT
Date: Thu, 1989 Apr 13   19:21:58 EDT
From: (John F. Chandler)   PEPMNT@CFAAMP.BITNET
To:   HEADER-PEOPLE@MC.LCS.MIT.EDU, (Danny Padwa)   PADWA@HUSC3.HARVARD.EDU,
      (Roger Fajman)   RAF@NIHCU.BITNET
cc:   (Scott Bradner)   SOB@HUSC6.HARVARD.EDU,
      (Hank Nussbacher)   HANK@BARILVM.BITNET
Subject: Re: Hostname in Message-Id
In-reply-to:  PADWA@HUSC3.HARVARD.EDU message of Thu, 13 Apr 89 09:41:00 EDT
Message-id: <PEPMNT.890413.192158.C0@CFAAMP.BITNET>

> Sorry to throw more fuel on the fire, but one of the major problems
> encountered in this MX-records-for-BITnet-only-domains question is
> that very few BITNET domains are actually registered on the servers at
> Harvard and Berkeley (or at least the one at Harvard).  In fact, the
> following is a complete list (if it ain't here, Harvard doesn't have
> info about it!):
>
> alleg.edu        hampshire.edu    pepperdine.edu   trinity.edu
> br               ie               pt               uri.edu
> bsu.edu          irl              rose-hulman.edu  urich.edu
> bucknell.edu     maine.edu        sg
> claremont.edu    naic.edu         towson.edu
> conncoll.edu     oberlin.edu      trincol.edu

The key word is BITNET-only.  There are two kinds of BITNET-only
domains, namely, Internet-conforming and non-conforming.  The latter
group includes such things as MFENET and WUSTL, which no sane person
would try to reach from an Internet host without explicitly using some
sort of "%" notation or source routing -- such domains can't ever be
served by Harvard, Berkeley, or any other name server, since they can't
ever be registered with SRI-NIC.  The former group (Internet-compliant),
on the other hand, includes only 18 domains (as of March 30), and the
above list includes fully 17 of those 18 plus ALLEG.EDU and BR (which
may be new in the last two weeks), BSU.EDU (which hasn't gotten around
to registering with BITNIC), and IRL (which is obsolete).  The only
missing BITNET-only domain is CUN.EDU, and I wonder why Harvard doesn't
have it -- the root server points to Harvard and Berkeley for it, and I
expect Berkeley does have it.  In any case, this is the only real
problem, and it can be solved easily by Harvard.  Note that the monthly
distribution of DOMAIN NAMES from BITNIC clearly shows which domains are
served by Harvard and Berkeley (via the :served.YES tag).
                                     John

Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 17 Apr 89 03:40:26 EDT
Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa03009; 17 Apr 89 7:35 GMT
To: header-people@mc.lcs.mit.edu, ifip-gtwy@tis.llnl.gov
Subject: Message Ids + domain flipping
Date: Mon, 17 Apr 89 08:33:37 +0100
Message-ID: <3401.608801617@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@Cs.Ucl.AC.UK>
Source-Info:  purple.cs.ucl.ac.uk

Header people,

A short while back, I wrote:

> To: John C Klensin <KLENSIN@infoods.mit.edu>
> cc: header-people@mc.lcs.mit.edu
> Subject: Re: Hostname in Message-Id 
>
> Mesage Ids are not mentioned.  This was an error.  A gateway should 
> reverse the domain order in message Ids. 

I received a private prod from Jon Postel, and rethought.  I'd like to
entirely retract this orginal statement.  RFC 822 and JNT Mail are clear
about message IDs - the domain component has no (external) semantics
(Unfortunately, this is made by not stating semantics, rather than explictly
noting the lack of semantics).  Leaving them alone is the only safe method
to preserve them.   

UK recipients of this message will note that it has an RFC 822 ordered
domain in the message id - correctly not transformed.


987 People (esp. those in the UK),

The reason I suggested mapping of message ids was following a conversation
with Jim, about message IDs being broken on traversal of a pair of 987
gateways (examing a broken message, rather than theoretical issues).
Because the 987 message id mapping uses the domain -> O/R Address mapping, 
the UK and US mappings become different.  As the current 987 mapping seems
clean, we concluded that a JNT Mail/RFC 822 mapping should flip domains.

On reflection, such a mapping would cause chaos for JNT Mail / RFC 822
interworking.   

Therefore, there is a need to change RFC 987.  I propose that for message ID
mappings that:

1) Where no "natural" mapping can be found, that the O/R Address is mapped
onto a single DD attribute.  This will make DD based message IDs reverse
mappable at every 987 gateway.

2) The JNT Mail annexe note that domains in message id are treated in RFC
822 order.

This will lead to a mechanically generated (and reversible) mapping for
every id.

Comments?

(Please try to avoid replying to both mailing lists!)

Steve

Received: from SH.CS.NET (TCP 30007663403) by MC.LCS.MIT.EDU 17 Apr 89 11:16:41 EDT
Received: by SH.CS.NET id ac12436; 17 Apr 89 11:16 EDT
To: "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@mitvma.mit.edu>
cc: header-people@mc.lcs.mit.edu
Subject: re: Hostname in Message-Id
Date: Mon, 17 Apr 89 11:02:20 -0400
From: Craig Partridge <craig@SH.CS.NET>



> The very  fact that this problem  exists is in my  (humble?) opinion one
> more indication that the structure  of the current addresses (user@host)
> is completely  outdated. It dates  back when time-sharing  machines were
> the  norm. Today,  giving  the  kind of  environments  described in  the
> referred message, individuals should have addresses of the form :
>         'name.domn.domn-1.  .dom2.dom1'.
> To  say  it otherwise  :  the  DNS should  be  used  up (down?)  to  the
> individual level.
> 
> This  would eliminate  problems  like  the one  stated  in the  referred
> message, and also would allow a more regular treatment of all cases. For
> example, name servers  could contain MX records for  individuals. Was it
> not the original intent of the DNS  that any 'object' in the world could
> someday be designated  by a domain? The syntax  'user@host' forbids this
> to be true for a large class of objects, like mailboxes and processes...
> 
> This may be completely heretic, idiotic  or worse. If so, I would really
> enjoy a correction. /AF

It certainly isn't heretical.  Systems like Grapevine/Clearinghouse have
done something like it for years.

The key problem is finding a system for naming individuals that scales
nicely for mailing lists and which also makes it easy for individuals to
move their mailbox.  The original Grapevine papers suggest this was and
is a tricky enterprise and I think may explain why we haven't seen this
scheme pursued more.

As a sort of half-step, I've tried to encourage people to set up their
organizational mail systems so that their users can be mailed to as
user@<second-level-domain>.  Examples of this are:

    craig@bbn.com
    kzm@twg.com
    pvm@isi.edu
    hr@ibm.com

The benefit, if you can manage your user namespace this well, is that
if the user moves within an organization, no one has to see it.

Craig

Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 19:58:05 EDT
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.61+/IDA-1.2.8) id AA03678; Mon, 17 Apr 89 18:57:51 -0500
Message-Id: <8904172357.AA03678@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 1336; Mon, 17 Apr 89 13:50:02 CDT
Date:         Mon, 17 Apr 89 13:40:00 CDT
X-Date:       Mon, 17 Apr 89 13:40:00 CDT (Even tax day is on monday now)
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
X-From:       Philip Howard <PHIL@VMD.CSO.UIUC.EDU>
Subject:      restructuring addresses
X-Subject:    restructuring addresses
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>
X-To:         Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>
Mailing-List: header-people

Another good reason for restructuring address such that my address:
    phil@vmd.cso.uiuc.edu
becomes just:                           or in the root-down order:
    phil.vmd.cso.uiuc.edu                   edu.uiuc.cso.vmd.phil

is that I might want to have mail sent to me on this timesharing system in
such a way that I can have a mail agent program break it down even further.
I subscribe to several mailing lists, but it all arrives in an arbitrary
sequence at one mailbox.  I might like to have multiple LOGICAL mailboxes.

I could have mail sent to:              or in the root-down order:
    hdr-ppl.phil.vmd.cso.uiuc.edu           edu.uiuc.cso.vmd.phil.hdr-ppl

Now of course the old way can do this, too, but with the new way, it would
be a lot easier and a lot more consistent.  Then we would not have to dream
up new headers just to allow user mail agents to discriminate mail depending
on its purpose (e.g. Mailing-list: header-people).

Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 20:03:54 EDT
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
	(5.61+/IDA-1.2.8) id AA03780; Mon, 17 Apr 89 19:02:53 -0500
Message-Id: <8904180002.AA03780@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 2663; Mon, 17 Apr 89 14:33:27 CDT
Date:         Mon, 17 Apr 89 14:31:23 CDT
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      Trying again to header-people
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>

I'm trying once again....  with all 3 rejected messages.
I leave the error headers in because I know this crowd loves 'em.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 7158;
 Thu, 13 Apr 89 21:14:18 CDT
Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP;
 Thu, 13 Apr 89 21:14:17 CDT
Received: by uxc.cso.uiuc.edu
    (5.61+/IDA-1.2.8) id AA04190; Thu, 13 Apr 89 21:13:16 -0500
Date: Thu, 13 Apr 89 21:13:16 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@uxc.cso.uiuc.edu>
Message-Id: <8904140213.AA04190@uxc.cso.uiuc.edu>
To: PHIL@uiucvmd.bitnet
Subject: Returned mail: Host unknown

   ----- Transcript of session follows -----
<<< RCPT TO:<HEADER-PEOPLE@MC.LCS.MIT.EDU>
<<< DATA
550 MC.LCS.MIT.EDU (TCP-U)... 550 Host unknown
554 <HEADER-PEOPLE@MC.LCS.MIT.EDU>... 550 Host unknown (Non recoverable name
 server error)

   ----- Unsent message follows -----
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
    (5.61+/IDA-1.2.8) id AA04181; Thu, 13 Apr 89 21:13:16 -0500
Message-Id: <8904140213.AA04181@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 3101; Thu, 13 Apr 89 19:08:38 CDT
Date:         Thu, 13 Apr 89 19:02:10 CDT
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      header munging
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>

Here is one reason I don't like header munging:

Someone subscribes to a mailing list here by sending mail.  Their FROM
address is munged along the way.  There subscription is automatically
entered and all seems fine... until their userid is terminated.  Then
the host system they are on sends back a rejection message, containing
the address EVEN FURTHER munged up, and no longer easy to compare for
removing the entry from the list.

If a FROM address is already in a domain format, why change it?

I can accept changing a!b!c!d into d%c%b@a or d@c:@b:@a or visa-versa,
but changing user@a.b.c.domain into anything else doesn't make any sense.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 4886;
 Fri, 14 Apr 89 01:47:18 CDT
Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP;
 Fri, 14 Apr 89 01:47:15 CDT
Received: by uxc.cso.uiuc.edu
    (5.61+/IDA-1.2.8) id AA14055; Fri, 14 Apr 89 01:46:28 -0500
Date: Fri, 14 Apr 89 01:46:28 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@uxc.cso.uiuc.edu>
Message-Id: <8904140646.AA14055@uxc.cso.uiuc.edu>
To: PHIL@uiucvmd.bitnet
Subject: Returned mail: Host unknown

   ----- Transcript of session follows -----
<<< RCPT TO:<HEADER-PEOPLE@MC.LCS.MIT.EDU>
<<< DATA
550 MC.LCS.MIT.EDU (TCP-U)... 550 Host unknown
554 <HEADER-PEOPLE@MC.LCS.MIT.EDU>... 550 Host unknown (Non recoverable name
 server error)

   ----- Unsent message follows -----
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
    (5.61+/IDA-1.2.8) id AA14051; Fri, 14 Apr 89 01:46:28 -0500
Message-Id: <8904140646.AA14051@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 3351; Thu, 13 Apr 89 11:30:01 CDT
Date:         Thu, 13 Apr 89 11:14:35 CDT
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      Re:  Multi-Networked Hosts (was Hostname in Message-ID)
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>
In-Reply-To:  Your message of Wed, 12 Apr 89  17:40:37 EDT

Instead of ":interconnect.MX" it might have been clearer to some had
":DeliveryNetwork.Internet" been used instead, to perform basically
the same function.

That field, as Roger Fajman points out, is essential to some computers
that are on BITNET like our own.

What this field means is that the host does have domain name service,
and that it is therefore possible (and usually preferable) to deliver
it via Internet.  The fact that the IBM SMTP program does not as yet
deliver according to MX record lookups from the name server does not
hinder us.  I have setup a mechanism around the problem, and can deliver
mail to all sites that are MX reachable, via Internet.  Some European
and Japanese sites are not delivered this way by a local override because
for some reason, the recipient is charged costs for delivery by Internet
and not via Bitnet.  But I can deliver by MX routing if I want to.

So what are these "'wanton' use of invalid domain-style address"?  If
you are talking about "nodename.BITNET", would you also apply the same
argument against "nodename.UUCP"?  So what would you suggest be done
(including specific examples)?  If you include "upgrade software", be
sure to include the names of the vendors of the software needing upgrade.
This is often easier said than done.

All Bitnet-only sites should be reachable from an Internet-only site
provided that someone does the name service.  But since such things are
not yet setup, we live with what we have now, and it works for the time
being.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 0108;
 Sun, 16 Apr 89 16:57:20 CDT
Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP;
 Sun, 16 Apr 89 16:57:18 CDT
Received: by uxc.cso.uiuc.edu
    (5.61+/IDA-1.2.8) id AB12400; Sun, 16 Apr 89 16:53:02 -0500
Date: Sun, 16 Apr 89 16:53:02 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@uxc.cso.uiuc.edu>
Message-Id: <8904162153.AB12400@uxc.cso.uiuc.edu>
To: PHIL@uiucvmd.bitnet
Subject: Returned mail: Cannot send message for 2 days

   ----- Transcript of session follows -----
421 MC.LCS.MIT.EDU (TCP-U)... Deferred: Connection timed out during user open
 with MC.LCS.MIT.EDU

   ----- Unsent message follows -----
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
    (5.61+/IDA-1.2.8) id AA17861; Fri, 14 Apr 89 15:33:36 -0500
Message-Id: <8904142033.AA17861@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 6851; Fri, 14 Apr 89 15:24:33 CDT
Date:         Fri, 14 Apr 89 15:11:48 CDT
From: Philip Howard <PHIL@vmd.cso.uiuc.edu>
Subject:      bitnet-only
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>

> not be handled properly!!! The clear solution is to disallow Internet messages
> with return addresses for invalid domains. Gateway filtering? :-) :-)

As clear as mud.

If you got the mail from SOMEWHERE, hopefully you know where.  If the FROM
address makes no sense to you then THIS IS THE TIME (and perhaps ONLY TIME)
to munge the return address by putting in the host name of WHERE YOU GOT IT
(not your own).  THEN send it on.

Now tell me that if every host followed this convention, that the mail could
not get back once/if it found its way to the destination.

As mail comes from BITNET (originating at a BITNET-only node) the FROM address
will be transformed from <user@node> to <user@node.bitnet>.  When it reaches
your node (you are not the gateway, but an intermediate) and if you don't know
how to deliver to ".bitnet", then assume that who you got it from (HELO) knows
because they DIDN'T munge it.  Now the FROM address will look like:
    <@where.it.came.from:user@node.bitnet>

Remember there are two roles here that can take place in different sites.
The BITNET gateway takes the non-DNS BITNET-ish address and changes into a
psuedo-DNS (.bitnet) form.  On subsequent delivery to another host (including
the final destination) which might NOT know what to do with ".bitnet", THAT
host will fix the reference.  Since the gateway knows about BITNET, it does not
need to munged any further than adding ".bitnet" if delivery is local.

Phil Howard
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 17 Apr 89 20:46:04 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5894; Mon, 17 Apr 89 20:47:00 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
 3357; Mon, 17 Apr 89 20:46:27 EDT
Received: (from AccesMVS@USCMVSA for USCMVSA via NJE)
 (UCLA/Mail V1.410 M-ACP-1664-40); Mon, 17 Apr 89 17:34:52 PDT
Received: from MC.LCS.MIT.EDU by MVSA.USC.EDU
    with TCP; Mon, 17 Apr 89 17:34:47 PST
Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 19
:58:05 EDT
Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP
       (5.61+/IDA-1.2.8) id AA03678; Mon, 17 Apr 89 18:57:51 -0500
Message-Id: <8904172357.AA03678@uxc.cso.uiuc.edu>
Received: by UIUCVMD (Mailer X1.25) id 1336; Mon, 17 Apr 89 13:50:02 CDT
Date:         Mon, 17 Apr 89 13:40:00 CDT
X-Date:       Mon, 17 Apr 89 13:40:00 CDT (Even tax day is on monday now)
From: Philip Howard <PHIL%VMD.CSO.UIUC.EDU@mitvma.mit.edu>
Subject:      restructuring addresses
X-Subject:    restructuring addresses
To: Header People <HEADER-PEOPLE@MC.LCS.MIT.EDU>
Mailing-List: header-people

Another good reason for restructuring address such that my address:
    phil@vmd.cso.uiuc.edu
becomes just:                           or in the root-down order:
    phil.vmd.cso.uiuc.edu                   edu.uiuc.cso.vmd.phil

is that I might want to have mail sent to me on this timesharing system in
such a way that I can have a mail agent program break it down even further.
I subscribe to several mailing lists, but it all arrives in an arbitrary
sequence at one mailbox.  I might like to have multiple LOGICAL mailboxes.

I could have mail sent to:              or in the root-down order:
    hdr-ppl.phil.vmd.cso.uiuc.edu           edu.uiuc.cso.vmd.phil.hdr-ppl

Now of course the old way can do this, too, but with the new way, it would
be a lot easier and a lot more consistent.  Then we would not have to dream
up new headers just to allow user mail agents to discriminate mail depending
on its purpose (e.g. Mailing-list: header-people).




Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 17 Apr 89 21:53:48 EDT
Return-Path: <rlk@Think.COM>
Received: from regin.think.com by Think.COM; Mon, 17 Apr 89 21:53:51 EDT
Received: by regin.think.com; Mon, 17 Apr 89 21:53:08 EDT
Date: Mon, 17 Apr 89 21:53:08 EDT
Message-Id: <8904180153.AA01122@regin.think.com>
From: Robert L. Krawitz <rlk@Think.COM>
Sender: rlk@Think.COM
To: HEADER-PEOPLE@mc.lcs.mit.edu
In-Reply-To: <8904172357.AA03678@uxc.cso.uiuc.edu>
Subject: restructuring addresses

   Date:         Mon, 17 Apr 89 13:40:00 CDT
   From: Philip Howard <PHIL@vmd.cso.uiuc.edu>

   is that I might want to have mail sent to me on this timesharing system in
   such a way that I can have a mail agent program break it down even further.
   I subscribe to several mailing lists, but it all arrives in an arbitrary
   sequence at one mailbox.  I might like to have multiple LOGICAL mailboxes.

   Now of course the old way can do this, too, but with the new way, it would
   be a lot easier and a lot more consistent.  Then we would not have to dream
   up new headers just to allow user mail agents to discriminate mail depending
   on its purpose (e.g. Mailing-list: header-people).

I have a tool to do something like this, called Personal Mail Daemon
(pmd).  This program was originally written by Jim Aspnes (now at
CMU), and has been hacked now and then.  It scans headers and drops
mail into appropriate (most of the time) mailboxes.

There's nothing that prevents you from doing this with the current
mail scheme (except for fascist administrators).  I could, for
example, create a mailbox named header-people.rlk@think.com and direct
mail from this list to it (or third-class.rlk@think.com for rdist
trash and the like :-) ).  Even with your scheme, mailbox creation
would likely be under some sort of administrative control at many
sites.

This isn't to detract from your proposal.  I just believe that there's
nothing to prevent sites from implementing heirarchical mailboxes
currently, or forbidding them under your scheme.  As the maintainer of
info-nets, however, I sympathize with your desire for a standardized
naming scheme for mailboxes.  arpalists#info-nets@andrew.cmu.edu, for
example, has to be escaped to make sendmail understand it when it's in
an address file; info-nets.arpalists.andrew.cmu.edu or
info-nets.arpalists@andrew.cmu.edu would make more sense, but I
suspect that the former would be easier to understand than the latter.
Implementing this might be a hassle, however; lots of nameservers
would have to know how to MX an address like this.  Of course, this
was said five years ago about the current domain scheme, and most
people have adapted quite well, and anything that would force Certain
Other Networks to conform to a standard would win...

One point that you don't explicitly bring up, but that I suspect you
notice, is that the division between local and global parts is
somewhat arbitrary.  The % and !  syntaxes (which after all are just
structured uses of the local part to do source routing) make this
clear.  The common foo%host@bar.com often seems to be a way to get
mail to something which should be foo@host.bar.com, except that
bar.com doesn't have its act together.

Some organizations (Xerox, for example) seem to be way ahead of the
game, with "registry" systems.  foobar.pa@xerox.com (foobar at Palo
Alto) could obviously be written as foobar.pa.xerox.com under your
scheme.  foobar@pa.xerox.com would make just as much sense, at that.

So given all this, just what is a practical definition of a local part
of an address?  Does it make sense to have an undifferentiated
heirarchical address space, or does the local part of an address still
make sense?

ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111

Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 18 Apr 89 08:34:14 EDT
Received: from ODUVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8561; Tue, 18 Apr 89 08:33:57 EDT
Date: Tue, 18 Apr 89 07:11:17 EST
To: header-people@mc.lcs.mit.edu
From: TAN100C%ODUVM.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT

Date: 18 April 1989, 07:10:59 EST
From: TAN100C  at ODUVM
To:   header-p at mc.lcs.mit.ed

Please sign me off this list.  Thank you.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Apr 89 23:22:06 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12532@BLOOM-BEACON.MIT.EDU>; Wed, 19 Apr 89 23:03:11 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Apr 89 01:20:38 GMT
From: uhccux!roberta@humu.nosc.mil  (Roberta Hodara)
Organization: University of Hawaii
Subject: x.400
Message-Id: <3798@uhccux.uhcc.hawaii.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ?
Please reply to : roberta@uhccux.uhcc.hawaii.edu

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 10:57:40 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA02251@BLOOM-BEACON.MIT.EDU>; Fri, 21 Apr 89 09:56:59 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Apr 89 22:17:57 GMT
From: hpda!hpcuhb!hpindda!ala@bloom-beacon.mit.edu  (Alyson L. Abramowitz)
Organization: HP Information Networks, Cupertino, CA
Subject: Re: x.400
Message-Id: <3760001@hpindda.HP.COM>
References: <3798@uhccux.uhcc.hawaii.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


    / hpindda:comp.mail.headers / roberta@uhccux.uhcc.hawaii.edu (Roberta Hodara) /  6:20 pm  Apr 19, 1989 /
    Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ?
    Please reply to : roberta@uhccux.uhcc.hawaii.edu
    ----------


X.400 is the name of a standard put out by CCITT.  Generally when
people say X.400 they mean the X.400 Series of Recommendations|MOTIS.
These are a series of standards documents from CCITT and ISO which
provide store and forward messaging.  The most common usage of this
standard is as a basis for electronic mail.

X.400 is a superset of the functionality available on the internet
and includes usage of non-text messages,  a Directory,  etc.

I believe the standard VMS product is not compliant to X.400 but
rather uses its own,  proprietary,  protocol.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 11:25:20 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA04536@BLOOM-BEACON.MIT.EDU>; Fri, 21 Apr 89 10:56:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Apr 89 13:36:48 GMT
From: pacific.mps.ohio-state.edu!miami.mps.ohio-state.edu!verber@ohio-state.arpa  (Mark A. Verber)
Organization: Ohio State University, Physics Department
Subject: Re: x.400
Message-Id: <162@pacific.mps.ohio-state.edu>
References: <3798@uhccux.uhcc.hawaii.edu>, <3760001@hpindda.HP.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I agree that the native DEC mail system is not X.400 curtently, but
DECnet Phase V is to be full ISO (whatever that means).  This will
include supporting X.400 and X.500 directory service (or whatever they
are calling it these days).  There are at least two add on commerical
packages for X.400 that run on Vax/VMS machines today.

Cheers,
Mark A. Verber				| There are two major products that
verber@mps.ohio-state.edu		| come out of Berkeley: LSD and BSD
OSU Physics, 174 W 18th, Cols, OH 43210	| UNIX.  We don't believe this to
1-614-292-8002				| be a coincidence.

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 22:29:22 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22331@BLOOM-BEACON.MIT.EDU>; Fri, 21 Apr 89 21:38:45 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Apr 89 18:32:45 GMT
From: uhccux!roberta@humu.nosc.mil  (Roberta Hodara)
Organization: University of Hawaii
Subject: target mail
Message-Id: <3813@uhccux.uhcc.hawaii.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Has anybody out there had any experience with Target mail.  We are thinking
about buying it for our VAX network.  One possible problem is the address field is short so we wouldn't be able to get to our BITNET node via our UNIX but,
TArget says that in the next release the address will be lengthened.ZZ

Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 09:43:22 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06617@BLOOM-BEACON.MIT.EDU>; Sat, 22 Apr 89 09:36:27 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Apr 89 19:24:36 GMT
From: mcvax!unido!sbsvax!emma@uunet.uu.net  (Martin Emmerich)
Organization: Universitaet des Saarlandes, Saarbruecken, W-Germany
Subject: Re: x.400
Message-Id: <726@sbsvax.UUCP>
References: <3798@uhccux.uhcc.hawaii.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3798@uhccux.uhcc.hawaii.edu>, roberta@uhccux.uhcc.hawaii.edu (Roberta Hodara) writes:
> Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ?

This is x.400 ;-) 

x.400 is a Message handling System, which is an own Standard. All other
Mail-Formats can be converted to x.400 . Here in Germany we have a field
test, sponsored by the Deutsche Bundespost. Thus all mail going via x.400
(as this one) is free.

  /\/>        /         ,---                  /    |  Snail: Hangweg 9
 /  / _   __-/- o _    /-- __  __  _  __ o _ /_    |         D-6601 Buebingen
/  /_/_(_/(_/(_(_/ (  /___//(_//(_(/_/(_(_(_/ (    |  Voice: +(49)6805/8299
---------------------------------------------------+-------------------------
X.400: emma@sbsvax.informatik.uni-saarland.dbp.de  |  Z-Net: aniel@eiko.zer

Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 25 Apr 89 06:39:08 EDT
Received: by INFOODS id <00000329064@INFOODS.MIT.EDU> ;
       Tue, 25 Apr 89 06:06:45 EDT
Date: Tue, 25 Apr 89 05:45:19 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re: X.400 and VMS mail
To: header-people@MC.LCS.MIT.EDU
X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu"
Message-ID: <890425054519.00000329064@INFOODS.MIT.EDU>

>I agree that the native DEC mail system is not X.400 curtently,
>...
 1) Current VAX Mail is not X.400-compliant.  The ways are too numerous
to mention, but the DEC VAX Mail product doesn't even support enough in
the way of envelope (trivial) and headers (none) to support RFC822.
 2) The mail in DEC's All-in-One product is claimed to be
X.400-compliant today, and Digital has participated in a number of
interworking demonstrations involving the use of that system
communicating with others via gateways. 
  This is also stated as "Digital has it now".  Whoops: you don't run 
All-in-One?  I'm sure someone would be happy to sell it to you. -:)

>DECnet Phase V is to be full ISO (whatever that means)...
  It doesn't mean much of anything, in and of itself.  "Full ISO" might 
mean "we support at least one protocol at each level", "we have 
redesigned our level boundaries to be complaint with the ISO OSI model",  
as well as "we are really supporting substituting other ISO-model 
modules, at any arbitrary level, with DECNet modules and we are 
integrating that into the standard DECNet product at no extra cost".  
There are also many other possibilities, and I haven't seen anything 
that I would consider to be equivalent to the last statement.
  In particular, a moderately well-integrated package of All-in-One 
providing a few applications-level protocols including MOTIS (to all 
intents and purposes, this is how ISO spells 'X.400'), a re-layering and 
a few revised system calls, and an improved interface that uses VAX-PSI 
as a transport level, rather than more traditional DECNet transport, 
would be "fully ISO-complaint";
  Note also that there are a lot of vendors who say "we support X.400 
interworking" who mean "we have built our system so that, while it does 
not use X.400 internally, and cannot communicate directly with X.400 
systems, we have this nice gateway arrangement that we will sell or 
lease you that will talk with the X.400-complaint GATEWAYS to other 
systems."  There isn't much wrong with that approach, unless you expect 
to run a wire between a half-dozen machines, each of which "supports" 
X.400 that way, and expect that they will talk with each other in the
same sense that a half-dozen, e.g., TCP/IP systems running SMTP will
talk with each other.

> This will include supporting X.400 and X.500 directory service...
  That is what they (CCITT) are calling it/them.  But I haven't seen 
that announcement from Digital with regard to VMS.  All-in-One is 
another story.

Moral: Don't believe everything you read.  Especially product 
announcements.
  John Klensin,  Klensin@INFOODS.MIT.EDU


Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 26 Apr 89 07:46:58 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4333; Wed, 26 Apr 89 07:48:05 EDT
Received: from ODUVM.BITNET (TAN100C) by MITVMA.MIT.EDU (Mailer R2.03B) with
 BSMTP id 8899; Wed, 26 Apr 89 07:48:05 EDT
Date: Wed, 26 Apr 89 07:41:41 EST
To: header-people@mc.lcs.mit.edu
From: TAN100C%ODUVM.BITNET@mitvma.mit.edu
Comment: CROSSNET mail via MAILER@MITVMA

Date: 26 April 1989, 07:41:18 EST
From: TAN100C  at ODUVM
To:   header-people at mc.lcs.mit.edu

Please sign me off from this list.

Thank you.

Received: from LispM.SLCS.SLB.COM (TCP 20016401600) by MC.LCS.MIT.EDU  1 May 89 11:27:23 EDT
Received: from SLCS.SLB.COM by LispM.SLCS.SLB.COM via INTERNET with SMTP id 36710; 28 Apr 89 10:52:41 CDT
Received: from GLOWWORM.LispM.SLCS.SLB.COM by linus.SLCS.SLB.COM (4.0/SLCS Mailhost 1.0)
	id AA13169; Fri, 28 Apr 89 10:54:03 CDT
Date: Fri, 28 Apr 89 10:52 CDT
From: Chris Garrigues <7thSon@SLCS.SLB.COM>
Subject: A mail routing question
To: header-people@MC.LCS.MIT.EDU
Supersedes: <19890427152700.4.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>,
            <19890427152748.5.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>
Comments: Retransmission of failed mail.
Message-Id: <19890428155247.5.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>

Another group in our company is eliminating a UUCP link to CS.UTEXAS.EDU
because they can now route mail through us over SMTP/TCP.  Naturally, we
want to be certain that anything which worked before still will continue
to work.

One test case which came up was mail to:

	cs.utexas.edu!ibmaus!user

What this was doing was sending the mail via UUCP to CS.TEXAS.EDU, and
then again via UUCP from there to IBMAUS.

When I got this address, I rewrote it as:

	user%ibmaus@cs.utexas.edu

I didn't write it as:

	ibmaus!user@cs.utexas.edu

because "a!b@c" is poorly defined.


This message got shipped properly to CS.UTEXAS.EDU who then bounced it
because IBMAUS wasn't a known host.  My fix for this was to turn any
non-domainized hosts in a UUCP path into host.UUCP when the !'s are
rewritten into %'s, so this example now comes out like this:

	user%ibmaus.UUCP@cs.utexas.edu

but I'm not convinced that this is the right thing in the general case.

I can't always assume that such hosts are UUCP hosts, can I?  What if
the address is something like this:

	hosta.domain!hostb!decnetgateway!hostc!user

Where the decnetgateway is looking at undomainzed hosts and routing them
to whatever is the appropriate network.  This would become:

	user%hostc.UUCP%decnetgateway.UUCP%hostb.UUCP@hosta.domain

I wouldn't expect the same smart decnetgateway which will turn
"hostc!user" into "hostc::user" to also turn "user@hostc.UUCP" into
"hostc::user", although it would turn "user@hostc.DECNET" into
"hostc::user".

Is there a right answer?

Chris

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 03:44:26 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa00218;
          21 May 89 14:30 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6390; Sun, 21 May 89 14:19:24 EDT
Received: from EDVZ.Uni-Wien.AC.AT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP
 id 8262; Sun, 21 May 89 14:19:23 EDT
Received: by AWIUNI11 (Mailer R2.01) id 6166; Sun, 21 May 89 17:44:58 MEZ
Date:     Sun, 21 May 89   17:45 MEZ
To:       HEADER-PEOPLE@MC.lcs.mit.edu
From:     MAIER%EDVZ.UNI-SALZBURG.ADA.AT@mitvma.mit.edu
Comments:       +++ Changed X.430-Header: +++                                  x
 =              BASIC
 TO:         <HEADER-PEOPLE@MC.LCS.MIT.EDU>                                    x
 FROM:       "Franz Maier"<MAIER@EDVZ.UNI-SALZBURG.ADA.AT>                     x
 MESSAGE ID: <MAIER@EDVZ.UNI-SALZBURG.ADA.AT>;292                              x
 BODY TYPE:          IA5TEXT
Message-ID:  <8905211430.aa00218@mintaka.lcs.mit.edu>

PLEASE ADD ME TO YOUR MAILING LIST

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Jun 89 08:49:16 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22235;
          7 Jun 89 8:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA01761@BLOOM-BEACON.MIT.EDU>; Wed, 7 Jun 89 08:41:58 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Jun 89 06:06:07 GMT
From: Chris Bradley <tektronix!percival!escargot!chrisb@bloom-beacon.mit.edu>
Organization: Coredump Central
Subject: RFC822 And New BBS compatibility with UUCP
Message-Id: <239@escargot.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Hello everybody,

I am currently writing a BBS that will EVENTUALLY incorporate UUCP mail.
I would like to be as compatible as possible, and would like from you,
the users, two things:

1: A list or "god" list of things I need to include/omit in my message
   headers. (RFC822 Compliant, preferably)
2: Suggestions or ideas that would improve upon the current UUCP mail
   headers.

Any help, references, or suggestions are gladly accepted and appreciated.
Thanks!

-->Chris

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Jun 89 16:46:21 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21430;
          8 Jun 89 16:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA09335@BLOOM-BEACON.MIT.EDU>; Thu, 8 Jun 89 16:26:42 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jun 89 19:15:23 GMT
From: Scott Horne <Horne-Scott@yale-zoo.arpa>
Organization: Yale University Computer Science Dept, New Haven, CT   06520-2158
Subject: Time-zone abbreviations in international mail
Message-Id: <63066@yale-celray.yale.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I've established an e-mail connexion with someone in Beijing.  I recently
posted some news he sent me to `soc.culture.china', to which I often submit
articles.  The contact in Beijing asked me not to reveal his name or address;
I agreed to this.

Now some people in that newsgroup are accusing me of faking the mail just
because I won't identify the author.  I yielded more than I wanted to by
posting the header without the paths and names.

This still didn't convince some people; in fact, one person has called me a
liar and a forger!  (See his article in that group.)  His reason?  According
to him, times on mail from Asia and Australia are given in Greenwich Mean Time,
and my header contains things like `HKT' (``Hong Kong Time'') and `JST'
(``Japan summer time'').

I know I'm right on this, for I *did* receive that mail from Beijing.  But
would someone please tell him (preferably by posting to `soc.culture.china'
or sending me mail, a summary of which I'll post there) that my header is
genuine (or ``could be'', for cynics like him)?

Advance thanks.

					--Scott

Scott Horne                           Hacker-in-Chief, Yale CS Dept Facility
horne@cs.Yale.edu                      ...!{harvard,cmcl2,decvax}!yale!horne
Home: 203 789-0877              Box 7196 Yale Station, New Haven, CT   06520
Work: 203 432-1205             Summer address:  175 Dwight St, New Haven, CT
I wish I *could* represent Yale, but Benno Schmidt won't let me....

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Jun 89 06:04:06 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13552;
          9 Jun 89 5:45 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22995@BLOOM-BEACON.MIT.EDU>; Fri, 9 Jun 89 05:29:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Jun 89 05:14:19 GMT
From: der Mouse <mcgill-vision!mouse@bloom-beacon.mit.edu>
Organization: McGill University, Montreal
Subject: worst header mangling I've seen
Message-Id: <1555@mcgill-vision.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

And I thought I'd seen some bogus addresses!  Here's what showed up in
my mailbox today.  (I've deleted the body, and though I think it's
probably not his fault, have replaced the sender's username with xxxx.)

Purely for your edification and enlightenment :-)

	From mcvax!inesc!MAILER-DAEMON@uunet.uu.net Thu Jun  8 21:44:29 1989
	Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54)
		id <8906090144.AA14492@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 21:44:14 EDT
	Received: from mcvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
		id AA18632; Thu, 8 Jun 89 21:43:58 -0400
	Received: by mcvax.cwi.nl via EUnet; Fri, 9 Jun 89 03:27:54 +0200 (MET)
	Message-Id: <8906090127.AA10090@mcvax.cwi.nl>
	Date: Thu, 8 Jun 89 13:20:19 EDT
	From: mcvax!inesc!MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
	Subject: Returned mail: User unknown
	To: MAILER-DAEMON@larry.mcrcim.mcgill.edu
	Status: RO
	
	   ----- Transcript of session follows -----
	mail11: mailer-daemon, unknown addressee at HOST
	550 host!MAILER-DAEMON... User unknown
	
	   ----- Unsent message follows -----
	Received: by inesc.UUCP (1.2/Ultrix2.2)
		id AA29675; Fri, 9 Jun 89 00:56:28 GMT
	Received: by mcvax.cwi.nl via EUnet; Fri, 9 Jun 89 01:21:03 +0200 (MET)
	Received: from Larry.MCRCIM.MCGILL.EDU by uunet.uu.net (5.61/1.14) with SMTP 
		id AB16251; Thu, 8 Jun 89 16:18:03 -0400
	Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54)
		id <8906081720.AA07486@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 13:20:19 EDT
	Date: Thu, 8 Jun 89 13:20:19 EDT
	From: Mail Delivery Subsystem  <mcvax!Mail.Delivery.Subsystem.mcvax!Larry.McRCIM.McGill.EDU!MAILER-DAEMON>
	Subject: Returned mail: Data format error
	Message-Id: <8906081720.AA07486@Larry.McRCIM.McGill.EDU>
	To: <host!MAILER-DAEMON@uunet.uu.net>
	
	   ----- Transcript of session follows -----
	554 <mcvax!inesc!host!MAILER-DAEMON@uunet.UU.NET>... Unbalanced '>'
	554 <mcvax!inesc!host!MAILER-DAEMON@uunet.UU.NET>... Unbalanced '<'
	xxxx not found
	uumail: can't find xxxx in database
	554 <xxxx!iros1@larry.mcrcim.mcgill.edu>... Unbalanced '>'
	554 <xxxx!iros1@larry.mcrcim.mcgill.edu>... Unbalanced '<'
	554 <xxxx!iros1@larry.mcrcim.mcgill.edu>... Unbalanced '>'
	501 <xxxx!iros1@larry.mcrcim.mcgill.edu>... Data format error
	
	   ----- Unsent message follows -----
	Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54)
		id <8906081720.AA07483@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 13:20:19 EDT
	Received: from mcvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
		id AA25912; Thu, 8 Jun 89 13:19:53 -0400
	Received: by mcvax.cwi.nl via EUnet; Thu, 8 Jun 89 19:08:05 +0200 (MET)
	Received: by host.fctunl.rccn.pt (1.2-UNL-Apr 26)
		id AA19980; Thu, 8 Jun 89 13:05:42 GMT
	Date: Thu, 8 Jun 89 13:05:42 GMT
	From: mcvax!unl!MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
	Subject: Returned mail: Unable to deliver mail
	Message-Id: <8906081305.AA19980@host.fctunl.rccn.pt>
	To: mcvax!larry.mcrcim.mcgill.edu>@xxxx@iros1<
	
	   ----- Transcript of session follows -----
	554 inesc::iros1@mcvax!larry.mcrcim.mcgill.edu!xxxx... Unbalanced '>'
	
	   ----- Unsent message follows -----
	Date: Thu, 8 Jun 89 13:05:42 GMT
	From: larry.mcrcim.mcgill.edu>@xxxx@iros1<@mcvax.uucp
	To: ap%host@inesc.uucp
	Subject:  

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 03:28:54 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa09950;
          10 Jun 89 3:25 EDT
Received: by INFOODS id <00003553172@INFOODS.MIT.EDU> ;
       Sat, 10 Jun 89 03:20:19 EDT
Date: Sat, 10 Jun 89 03:18:54 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject:  Time zones and other messed-up headers
To: @MINTAKA.LCS.MIT.EDU:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
X-VMS-Mail-To: EXOS%"<@xx.lcs.mit.edu:header-people@mc.lcs.mit.edu>"
Message-ID: <890610031854.00003553172@INFOODS.MIT.EDU>

Scott,
  Your correspondent is living in an unreal world, in which everyone
has the same understanding of the protocols and uses them the same
way.  Before coming back to the time zones, he or she might fairly
accuse you of forging your own address: it came through to here 
as Horne-Scott@yale-zoo.arpa, and under the DNS, that address does
not exist any more.  Since it is an illegal address, you obviously
do not exist, if you follow the logic.  Or one could assume old, and
slightly misbehaving (ok, more than 'slightly' misbehaving) software,
rather than rampant conspiracy.  Some mail systems would reject the 
mail and throw it away, since the return address is invalid, others 
(most) will let it through and hope the receiver can straighten it out.
  Now to time zones.  The RFC that defines legal time zones in mail 
defines and permits three-letter time zone codes only for those zones 
that cross North America, more or less.  That means no three-letter 
codes for Europe, no three-letter codes for Asia, etc.  The RFC (822, 
incidentally), then specifies that any time zone (including those for 
which three letter codes are defined) can be specified by either 
one-letter "military" codes or by a signed offset from UT (GMT to a 
first approximation, but your correspondent is wrong on that count 
also).   The "military" ones are not heavily used, and are gradually 
being discouraged.
  However, dates are transmitted in ASCII text, and "adaptations" and 
"extensions", however prohibited, are very common.  I've heard the 
reasons justified in certain central European countries as, 
approximately, "the stupid, provincial, Americans gave their time zone 
names, but not anyone else's, obviously extensions are the right thing 
to do".  So they do, and confusion abounds, since many of those 
three-letter codes in common use are not unique.
  But the situation is the same as your address.  A few mail agents will 
take it upon themselves to police such things, and declare the header 
invalid, or transform the time zone (or the date-time) into a comment 
before passing the mail on in order to avoid violating the protocol 
themselves.  But most don't, and you could circulate mail several times 
around the world with a time zone of YDT, standing presumably for Yale 
Daylight Time.
  So your correspondent could more reasonably say "call the protocol 
police, someone in China is sending mail with invalid time zones" or "he 
can't be from China, the mail was transmitted with a one-byte character
code, rather than Hangi". 
  I don't/can't have any opinion about the validity of your mail, but 
the claim that the time-zone nonsense proves anything is nonsense.  And 
there *are* mechanisms for getting email to and from China, however slow 
and inefficient, so it seems to me that the burden of proof is on your 
accusers.
   John Klensin
   Center for International Studies
   MIT
   Klensin@INFOODS.MIT.EDU


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 07:59:43 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24073;
          10 Jun 89 7:54 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22818@BLOOM-BEACON.MIT.EDU>; Sat, 10 Jun 89 07:22:43 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Jun 89 13:27:00 GMT
From: John Pettitt <mcvax!ukc!pyrltd!slxsys!jpp@uunet.uu.net>
Organization: Specialix International, London, UK.
Subject: Return-view-to:
Message-Id: <3990@slxsys.specialix.co.uk>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Is the `Return-view-to:' header legal ?  If so what should a user
agent do with it ?    

> X-Mailer: SCO Office Portfolio (version 1.0)
> To:  jpp
> Subject:  test 
> Return-receipt-to: jpp
> Return-view-to: jpp                                      
> From: jpp

While I'm on the subject what whould I do with return receipt tickets
from dead `non-domain' mailers (like sco op) ?

John Pettitt
postmaster@specialix.co.uk
-- 
John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR
{backbone}!ukc!slxsys!jpp     jpp@slxinc.uucp     jpp@slxsys.specialix.co.uk
Tel: +44-1-941-2564       Fax: +44-1-941-4098         Telex: 918110 SPECIX G
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 18:47:01 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28411;
          10 Jun 89 18:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03985@BLOOM-BEACON.MIT.EDU>; Sat, 10 Jun 89 17:49:39 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Jun 89 21:43:35 GMT
From: Joe Buck <apple!epimass!jbuck@bloom-beacon.mit.edu>
Organization: Entropic Processing, Inc., Cupertino, CA
Subject: Re: Time-zone abbreviations in international mail
Message-Id: <3292@epimass.EPI.COM>
References: <63066@yale-celray.yale.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <63066@yale-celray.yale.UUCP> Horne-Scott@cs.yale.edu (Scott Horne) writes:
>I've established an e-mail connexion with someone in Beijing.  I recently
>posted some news he sent me to `soc.culture.china', to which I often submit
>articles.  The contact in Beijing asked me not to reveal his name or address;
>I agreed to this.
>
>Now some people in that newsgroup are accusing me of faking the mail just
>because I won't identify the author.  I yielded more than I wanted to by
>posting the header without the paths and names.
>
>This still didn't convince some people; in fact, one person has called me a
>liar and a forger!  (See his article in that group.)  His reason?  According
>to him, times on mail from Asia and Australia are given in Greenwich Mean
> Time,
>and my header contains things like `HKT' (``Hong Kong Time'') and `JST'
>(``Japan summer time'').

The person who made this accusation against you is confused about the
difference between news (netnews) and mail.  The example he gave about
"what headers look like" showed headers from a news article, not from
a mail message.  That is, it had a "Newsgroups:" line, no "Received"
headers, and gave a time in GMT.

On the other hand, the headers you showed don't prove that much,
though, trusting person that I am, I don't see why I shouldn't believe you.
They look like they may have come from a real message.

By the way, I'm curious.  Just what did you do to stir up such hate
against you?  Seems like the people accusing you of things only need
to see your name to start frothing at the mouth.  Are you really the
evil agent of international communism that they say you are?  :-)


-- 
-- Joe Buck	jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 00:49:39 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00598;
          11 Jun 89 0:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10017@BLOOM-BEACON.MIT.EDU>; Sat, 10 Jun 89 23:50:32 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Jun 89 03:01:00 GMT
From: Mark Harris <cwjcc!mailrus!caen.engin.umich.edu!markh@ohio-state.arpa>
Organization: U of M Engineering, Ann Arbor, Mich.
Subject: RFC-822 'phrase' question
Message-Id: <43c2245d.129dc@blue.engin.umich.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


I have noticed that a number of mailers will generate From: lines like:
  From: John Q. Public <JQP@MIT-AI.ARPA>
This is clearly wrong according to a strict interpretation of RFC-822,
since periods are not allowed in a 'phrase', unless they are part of a
'quoted-string', which must be enclosed in quotes.  Not only have I
found that several mailers use such syntax, but some RFCs as well!  (In
fact, the above line was taken from RFC-821, page 53.)  Is such syntax
acceptable, or should my mailer put quotes around all user names containing
periods?

On a related note, I have also seen the following header:
  In-Reply-To:  Your message of Tue, 30 May 89 15:49:35 EDT
Although it may look pretty, this header is also wrong according to RFC-822
since neither commas nor colons are allowed in a 'phrase'.  This header
would look a lot uglier if quotes were used, however.

Are all mailers that generate either of these two types of headers broken,
or am I missing something?  I know that there is a correction to the
RFC-822 'mailbox' definition in the Host Requirements RFC, but have there
been other changes that I missed?  Thanks in advance to anyone that can
enlighten me.

--
Disclaimer:  I speak only for myself.
Mark Harris <markh@caen.engin.umich.edu>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 16:50:54 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05909;
          11 Jun 89 16:45 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA24071@BLOOM-BEACON.MIT.EDU>; Sun, 11 Jun 89 15:32:51 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Jun 89 19:27:33 GMT
From: Dan Heller <pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu>
Organization: University of California, Berkeley
Subject: Re: Return-view-to:
Message-Id: <14552@pasteur.Berkeley.EDU>
References: <3990@slxsys.specialix.co.uk>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes:
> Is the `Return-view-to:' header legal ?  If so what should a user
> agent do with it ?    
a User Agent?  Don't you mean the Transport Agent?  User agents don't deal
with things like retrun-reciept-to, etc... MTAs to.  but nevertheless, this
is something I haven't heard of before, so I won't venture a guess as to what
to do with it.  However, I might shed some light on the origin of the problem.

> > X-Mailer: SCO Office Portfolio (version 1.0)
This comes frokm sco's funky little Office Automation package they developed.
Mail was written without domains in mind or the foresight of a networking
community.  That is, this mailer does not handle mailing outside of sco
very well.  If it successfully delivers mail out of sco, the headers are
outrageous -- it only allows one address on the To: header and it has all
the names, address, domains, hostnames, pathes and sometimes even comment
all scrunched together with a wild assortment of bangs and at's and the like
interspersed between them.  I once got a header:

    To: island!michaelb@island.sun.argv.uucp!jamescb.sco.maui@heller.dan.com

when it was supposed to be addressed to:

    To: sun!island!maui!argv (dan heller), jamescb@sco.com, michaelb

The good side of this is that sco does has a growing community of mush
users within the company.  
Dan Heller	<island!argv@sun.com>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 12:53:32 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22906;
          12 Jun 89 12:49 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6499; Mon, 12 Jun 89 12:48:50 EDT
Received: from ICSA.RICE.EDU by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 6375; Mon, 12 Jun 89 12:48:50 EDT
Received: by RICE (Mailer R2.03B) id 8465; Mon, 12 Jun 89 11:19:20 CDT
Date:         Mon, 12 Jun 89 11:13:42 CDT
From:         "Mark R. Williamson" <MARK%RICE.BITNET@mitvma.mit.edu>
Subject:      Re: Return-view-to:
To:           HEADER-PEOPLE@mc.lcs.mit.edu
In-Reply-To:  Message of Sun, 11 Jun 89 19:27:33 GMT from
 <pasteur!cory.Berkeley.EDU!dheller@UCBVAX.BERKELEY.EDU>
Message-ID:  <8906121249.aa22906@mintaka.lcs.mit.edu>

On Sun, 11 Jun 89 19:27:33 GMT Dan Heller said:
>In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt)
> writes:
>> Is the `Return-view-to:' header legal ?  If so what should a user
>> agent do with it ?
>a User Agent?  Don't you mean the Transport Agent?  User agents don't deal
>with things like retrun-reciept-to, etc... MTAs to.  but nevertheless, this
>is something I haven't heard of before, so I won't venture a guess as to what
>to do with it.  ...

Since the original message cited both Return-reciept-to: and Return-view-to:
lines, my guess is that the latter (new to me as well) requests a message
when the original is seen by the user, while the former is to happen when
the message is "delivered" (available to be read).  Although it is certainly
arguable that delivery receipts are the province of Transport Agents, receipts
indicating "viewing" can only be issued by a User Agent (since the Transport
Agent presumably has no way of detecting that action).

Can anyone suggest a meaning for Return-view-to: that could be handled by a
Transport Agent?

Mark R. Williamson, Rice University, Houston, TX; MARK@ICSA.RICE.EDU
-------------------------
The above opinions are my own and not necessarily those of Rice University.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 15:59:55 EDT
Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa29784;
          12 Jun 89 15:58 EDT
Received: from bel.isi.edu by venera.isi.edu (5.61/5.51)
	id <AA04922>; Mon, 12 Jun 89 12:57:23 -0700
Date: Mon, 12 Jun 89 12:56:58 PDT
From: postel@venera.isi.edu
Posted-Date: Mon, 12 Jun 89 12:56:58 PDT
Message-Id: <8906121956.AA07988@bel.isi.edu>
Received: by bel.isi.edu (5.54/5.51)
	id AA07988; Mon, 12 Jun 89 12:56:58 PDT
To: header-people@mc.lcs.mit.edu
Subject: Time zones and other messed-up headers




Return-Path: <Saltzer.CSR@MIT-MULTICS.ARPA>
Date:  Fri, 22 Feb 85 14:55 EST
From:  Gary Dixon <GDixon@HIS-PHOENIX-MULTICS.ARPA>
Subject:  Re: zone sources
To:  Saltzer@MIT-MULTICS.ARPA
cc:  "Gary M. Palter" <Palter@HIS-PHOENIX-MULTICS.ARPA>, 
     James A Falksen <Falksenj@HIS-PHOENIX-MULTICS.ARPA>
Resent-Date:  22 Feb 85 22:43 EST
Resent-From:  Saltzer@MIT-MULTICS.ARPA
Resent-To:  postel@USC-ISIF.ARPA
Resent-Comment:
          Jon,
        --
          Remember the discussion a couple of months ago about time zone
          designators and the Multics protocol police rejection of
          things not in your specification?  Well, the Multics central
          guru bureau has reversed field, and is about to start
          accepting any time zone designator in a much larger legal
          list, which I attach for your amusement.  If you should ever
          find yourself faced with a need to reissue the relevant RFC
          and a demand for further time zone definitions, these people,
          in classic Multics fashion, seem to have gotten off to a
          somewhat scholarly start (notwithstanding the astrology
          reference.)
        --
          Now if we could just get the ISO people to debate things like
          this instead of proposing presentation management protocols
          before anyone has built one, they might actually provide us a
          useful service.
        --
                                        Regards,
                                                  Jerry
        --
          -------

Hi, Jerry:

   Gary Palter relayed your inquiry on Multics time zones to me, as project
leader of the software team which developers the new Multics date/time
software.  Jim Falksen was the other team member, and he supplied our starting
set of time zone names, which were then augmented based upon customer input.

Our investigations haven't turned up any standards for zone names, other than
the ANSI standard for US names.  It took some digging to find any references
which listed zone names and offsets.

Jim Falksen used the following sources to form his initial list of time zone
names:

    from THE ASTROLOGY ANNUAL REFERENCE BOOK, 1981 by Marcian B.  MacGregor
    and Zipporah Pottenger Dobyns, Ph.D.

    "STANDARD TIME(ZONE TIME):  At an International Conference held in
    Washington D.C.  on October 1, 1884, the Greenwich Meridian was adopted
    as the prime meridian (0 degrees), with equal division of the world in
    24 fifteen-degree time zones (as originally proposed by Sanford Fleming,
    a Canadian civil and railway engineer).  Subsequently the following
    International Time Zones were adopted:

     -0000 WET  Western European Time
     -0100 WAT  West Africa Time
     -0200 AT   Azores Time
     -0300 BST  Brazil Std Time
     -0330 NFT  Newfoundland Time
     -0400 AST  Atlantic Std Time
     -0500 EST  Eastern Std Time
     -0600 CST  Central Std Time
     -0700 MST  Mountain Std Time
     -0800 PST  Pacific Std Time
     -0900 YST  Yukon Std Time
     -1000 CAT  Central Alaska Time
     -1030 HST  Hawaiian Std Time
               *Hawaii adopted -1000 in 1947
     -1100 NT   Nome Time
     -1100 BT   Bering Time
     -1200 IDLW INternational Date Line, West
     +0100 CET  Central European Time
     +0200 EET  Eastern European Time, USSR Zone 1
     +0300 BT   Baghdad Time, USSR Zone 2
     +0330 IT   Iran Time
     +0400      USSR Zone 3
     +0500      USSR Zone 4
     +0530 IST  Indian Standard Time
     +0600      USSR Zone 5
     +0630 NST  North Sumatra Time
     +0700 SST  South Sumatra Time, USSR Zone 6
     +0730 JT   Java Time
     +0800 CCT  China Coast Time, USSR Zone 7
     +0830 MT   Moluccas Time
     +0900 JST  Japan Std Time, USSR Zone 8
     +0930 SAST South Australia Std Time
     +1000 GST  Guam Std Time, USSR Zone 9
     +1130      USSR Zone 10
     +1130 NZT  New Zealand Time
               *adopted +1200 in 1945
     +1200 IDLE International Date Line, East"

A second source was THE AMERICAN EPHEMERIS, 1971 to 1980, By Neil F Michelsen.

    "Time Zones of the World
     +0000 GMT  Greenwich
     -0100 WAT  West Africa
     -0200 AT   Azores
     -0300      Brazil Zone 2
     -0330 NST  Newfoundland
     -0400 AST  Atlantic
     -0500 EST  Eastern
     -0600 CST  Central
     -0700 MST  Mountain
     -0800 PST  Pacific
     -0900 YST  Yukon
     -1000 AHST Alaska-Hawaii
     -1030 HST  Hawaiian
     -1100 NT   Nome
     -1100 BST  Bering
     -1200      Int'l Date Line
     +0100 CET  Central European
     +0100 MET  MIddle European
     +0200 EET  Eastern European
     +0300 BT   Baghdad
     +0400      USSR Zone 3
     +0500      USSR Zone 4
     +0530 IST  Indian
     +0600      USSR Zone 5
     +0630 NST  North Sumatra
     +0700 SST  South Sumatras
     +0730 JT   Java
     +0800 CCT  China Coast
     +0900 JST  Japan
     +0930 SAST South Australia
     +1000 GST  Guam
     +1200 NZT  New Zealand"

From these two lists we derived the following times.  Items below which are
starred were added to the basic list at customer request.

 known time zones:
 |-11:00  nt Nome Time
 |      |-10:00  ahst Alaska-Hawaii Standard Time
 |      |      | -9:00  yst Yukon Standard Time
 |      |      |      | -8:00  pst Pacific Standard Time
 |      |      |      |      | -7:00  mst Mountain Standard Time
 |      |      |      |      | -7:00  pdt Pacific Daylight Time
 |      |      |      |      |      | -6:00  cst Central Standard Time
 |      |      |      |      |      | -6:00  mdt Mountain Daylight Time
 |      |      |      |      |      |      |      |      |      |      |
 |-11:00|-10:00| -9:00| -8:00| -7:00| -6:00| -5:00| -4:00| -3:00| -2:00|
 |      |      |      |      |      |      |      |      |      |      |
                 Eastern Standard Time est   -5:00|      |      |      |
                 Central Daylight Time cdt   -5:00|      |      |      |
                       Atlantic Standard Time ast   -4:00|      |      |
                        Eastern Daylight Time edt   -4:00|      |      |
                      Newfoundland Standard Time nst   -3:30    |      |
                            Greenland  Standard Time gst   -3:00|      |
                              Atlantic Daylight Time adt   -3:00|      |
                                                 Azores Time at   -2:00|

 | -1:00  wat West Africa Time
 |      | +0:00  ut Universal Time
 |      | +0:00  z Universal Time
 |      | +0:00  gmt Greenwich Mean Time
 |      |      | +1:00  bst British Summer Time (*)
 |      |      | +1:00  cet Central European Time
 |      |      | +1:00  met Middle Europe Time
 |      |      | +1:00  mewt Middle Europe Winter Time
 |      |      | +1:00  swt Swedish Winter Time (*)
 |      |      | +1:00  fwt French Winter Time (*)
 |      |      | +1:00  hfh Heure Francais d'Hiver (*)
 |      |      |      | +2:00  mest Middle Europe Summer Time
 |      |      |      | +2:00  eet Eastern European Time
 |      |      |      | +2:00  sst Swedish Summer Time (*)
 |      |      |      | +2:00  fst French Summer Time (*)
 |      |      |      | +2:00  hfe Heure Francais d'Ete (*)
 |      |      |      |      | +3:00  bt Baghdad Time
 |      |      |      |      |      | +4:00  zp4 GMT +4  hours.
 |      |      |      |      |      |      | +5:00  zp5 GMT +5  hours.
 |      |      |      |      |      |      |      |      |      |      |
 | -1:00| +0:00| +1:00| +2:00| +3:00| +4:00| +5:00| +6:00| +7:00| +8:00|
 |      |      |      |      |      |      |      |      |      |      |
                     Indian Standard Time ist   +5:30    |      |      |
                             GMT +6  hours.   zp6   +6:00|      |      |
                  (*) West Australian Standard Time wast   +7:00|      |
                                               Java Time jt   +7:30    |
                         (*) West Australian Daylight Time wadt   +8:00|
                                           China Coast Time cct   +8:00|

 | +9:00  jst Japan Standard Time
 |    +9:30  cast Central Australian Standard Time (*)
 |    +9:30  sast South Australian Standard Time
 |      |+10:00  east East Australian Standard Time (*)
 |      |   +10:30  cadt Central Australian Daylight Time (*)
 |      |   +10:30  sadt South Australian Daylight Time (*)
 |      |      |+11:00  eadt East Australian Daylight Time (*)
 |      |      |      |+12:00  nzt New Zealand Time
 |      |      |      |      |
 | +9:00|+10:00|+11:00|+12:00|

Also, we have recently received a request to add

  +12:00  nzst New Zealand Standard Time (*)
  +13:00  nzdt New Zealand Daylight Time (*)

but haven't added them to our table yet.

Hope this helps.  Gary

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 17:20:41 EDT
Received: from Valeria.CS.UCLA.EDU by mintaka.lcs.mit.edu id aa13634;
          12 Jun 89 17:15 EDT
Return-Path: <wales@CS.UCLA.EDU>
Received: by valeria.cs.ucla.edu (Sendmail 5.61.ucla-32/2.16)
	id AA23422; Mon, 12 Jun 89 14:14:56 -0700
Date: Mon, 12 Jun 89 14:14:54 PDT
From: Rich Wales <wales@cs.ucla.edu>
Message-Id: <890612.211454z.23383.wales@valeria.cs.ucla.edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: Time zones and other messed-up headers
References: Message of Mon, 12 Jun 89 12:56:58 PDT
        from "postel@venera.isi.edu"
        <8906121956.AA07988@bel.isi.edu>

Regarding Gary Dixon's message, posted to HEADER-PEOPLE by Jon Postel:

If nothing else, I think this hopelessly unwieldy list illustrates why
the only truly reasonable thing to do is to *mandate* the use of numeric
offsets relative to UT -- with the option to include a local time zone
abbreviation as a *comment*.

Any software which wished to work with a time stamp (e.g., in order to
sort mail by date/time) could then use the numeric offset and would not
have to worry about trying to decipher an obscure (and possibly ambigu-
ous!) abbreviation.

-- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683
   3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
   wales@CS.UCLA.EDU      ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales
"This is yet another example of how our actions have random results."

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 07:49:37 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02176;
          13 Jun 89 7:45 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05502@BLOOM-BEACON.MIT.EDU>; Tue, 13 Jun 89 07:18:34 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Jun 89 01:06:38 GMT
From: John Diamant <hpfcdc!hpfclp!diamant@hplabs.hp.com>
Organization: HP SESD, Fort Collins, CO
Subject: Re: Return-view-to:
Message-Id: <7260009@hpfclp.SDE.HP.COM>
References: <3990@slxsys.specialix.co.uk>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

> In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes:
> > Is the `Return-view-to:' header legal ?  If so what should a user
> > agent do with it ?    
> a User Agent?  Don't you mean the Transport Agent?  User agents don't deal
> with things like retrun-reciept-to, etc... MTAs to.

That's an interesting point, and it may be that the relevant mail standards
say that (I don't know; I'm not familiar with either of the above mentioned
headers), but it wouldn't be a very useful interface if the MTA implemented
return-receipt-to.  A return receipt is analagous to a registered letter.
A receipt should only be generated when the recipient has actually seen
the letter.  To have the MTA supply the receipt would be misleading at best.
All it would tell you is that the mail arrived on the destination host.

This is unfortunate as UAs aren't supposed to have to deal with things like
that, but really, it's the only way to implement a return receipt correctly.


John Diamant
Software Engineering Systems Division
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 13:44:25 EDT
Received: from MNEMOSYNE.ACA.MCC.COM by mintaka.lcs.mit.edu id aa06404;
          13 Jun 89 13:41 EDT
Received: from SURYA.CYC-WEST.MCC.COM by MNEMOSYNE.ACA.MCC.COM via DIAL with SMTP id 33686; 13 Jun 89 12:01:43 CDT
Received: from XANTHIPPE.cyc-west.mcc.com by SURYA.CYC-WEST.MCC.COM via INTERNET with SMTP id 19352; 13 Jun 89 09:59:30 PDT
Date: Tue, 13 Jun 89 10:00 PDT
From: David Vinayak Wallace <Gumby@mcc.com>
Subject: Return-view-to:
To: John Diamant <diamant@hpfclp.sde.hp.com>
cc: header-people@mc.lcs.mit.edu
In-Reply-To: <7260009@hpfclp.SDE.HP.COM>
Message-ID: <19890613170001.6.GUMBY@XANTHIPPE.cyc-west.mcc.com>

    Date: 13 Jun 89 01:06:38 GMT
    From: John Diamant <hpfcdc!hpfclp!diamant@hplabs.hp.com>

    This is unfortunate as UAs aren't supposed to have to deal with things like
    that, but really, it's the only way to implement a return receipt correctly.

To re-open a perennial topic, having the UA send the receipt doesn't
assure you of much.

What's correct?  If you fail to receive a receipt, does that mean that
the user didn't see the message or that s/he disabled the receipt
mechanism?  (and of course it doesn't solve the hermaneutic problem of
whether or not the user understood, much less actually read the
message).

Once again, an analogy with the hardcopy postal system applies.  The
post ofifice only guarantees delivery of an envelope; it makes no claims
about the contents.  If you really want to know if the user "got the
message" you must resort to a higher-level protocol (e.g. by putting
"Let me know what you think about this" in the body of your message).

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 14:17:47 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06975;
          13 Jun 89 14:16 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA13125@BLOOM-BEACON.MIT.EDU>; Tue, 13 Jun 89 13:45:52 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Jun 89 07:03:30 GMT
From: John Pettitt <mcvax!ukc!pyrltd!slxsys!jpp@uunet.uu.net>
Organization: Specialix International, London, UK.
Subject: Re: Return-view-to:
Message-Id: <4037@slxsys.specialix.co.uk>
References: <14552@pasteur.Berkeley.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

From article <14552@pasteur.Berkeley.EDU>, by dheller@cory.Berkeley.EDU (Dan Heller):
> In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes:
>> Is the `Return-view-to:' header legal ?  If so what should a user
>> agent do with it ?    
> a User Agent?  Don't you mean the Transport Agent?  User agents don't deal
> with things like retrun-reciept-to, etc... MTAs to.  but nevertheless, this
> is something I haven't heard of before, so I won't venture a guess as to what
> to do with it.  However, I might shed some light on the origin of the problem.
> 
>> > X-Mailer: SCO Office Portfolio (version 1.0)
> This comes frokm sco's funky little Office Automation package they developed.

> The good side of this is that sco does has a growing community of mush
> users within the company.  
> Dan Heller	<island!argv@sun.com>

The Return-view-to: is by definition a user agent problem.  The idea is it
sends a receipt when the user reads (views) the mail, not on final transport
stage.  The reason for my original posting is that we have just installed SCO
OP for our non-technical users and they are sending mail using the OP
mailer (which for all it's faults is not bad for non technical users).

One of the `features' of the op mailer is that is can generate `view' receipts
and track which ones you have had back so far.  My problem is that the
technical users all use mush (what else ? :-) and now I have to hack
support for view receipts into mush.

I would like to do a good job of it,  I.E. conform to any standards that
may be applicable and be compatible with the rest of the world.  So the
orgiginal question remains:

	What should a mail user agent do with `Return-view-to:' ?

John Pettitt
postmaster@specialix.co.uk

-- 
John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR
{backbone}!ukc!slxsys!jpp     jpp@slxinc.uucp     jpp@slxsys.specialix.co.uk
Tel: +44-1-941-2564       Fax: +44-1-941-4098         Telex: 918110 SPECIX G
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 15:29:01 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07744;
          13 Jun 89 15:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA14700@BLOOM-BEACON.MIT.EDU>; Tue, 13 Jun 89 15:02:05 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Jun 89 18:59:22 GMT
From: Dan Heller <pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu>
Organization: University of California, Berkeley
Subject: Re: Return-view-to:
Message-Id: <14602@pasteur.Berkeley.EDU>
References: <14552@pasteur.Berkeley.EDU>, <4037@slxsys.specialix.co.uk>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Note, I added comp.mail.mush and comp.unix.xenix to the newsgroups list ...

In article jpp@slxsys.specialix.co.uk (John Pettitt) writes:
> From article by dheller@cory.Berkeley.EDU (Dan Heller):
> > In article jpp@specialix.co.uk (John Pettitt) writes:
> >> Is the `Return-view-to:' header legal ?  If so what should a user
> >> agent do with it ?    
> > a User Agent?  Don't you mean the Transport Agent?  User agents don't deal
> > with things like retrun-reciept-to, etc... MTAs do.  but nevertheless, this
> > is something I haven't heard of before, so I won't venture a guess as to what
> > to do with it.  However, I might shed some light on the origin of the problem.
> >> > X-Mailer: SCO Office Portfolio (version 1.0)
> > This comes from sco's funky little Office Automation package they developed.

> > The good side of this is that sco does has a growing community of mush
> > users within the company.  
> > Dan Heller	<island!argv@sun.com>
> 
> The Return-view-to: is by definition a user agent problem.  The idea is it
> sends a receipt when the user reads (views) the mail, not on final transport
> stage.  The reason for my original posting is that we have just installed SCO
> OP for our non-technical users and they are sending mail using the OP
> mailer (which for all it's faults is not bad for non technical users).

> One of the `features' of the op mailer is that is can generate `view' receipts
> and track which ones you have had back so far.  My problem is that the
> technical users all use mush (what else ? :-) and now I have to hack
> support for view receipts into mush.

> I would like to do a good job of it,  I.E. conform to any standards that
> may be applicable and be compatible with the rest of the world.  So the
> orgiginal question remains:

> 	What should a mail user agent do with `Return-view-to:' ?
> 
> John Pettitt
> postmaster@specialix.co.uk

As you've described it, this is a very potentially buggy thing to do:
the UA should not be involved.  However, let's address the issue anyway...

What should the UA do with Return-View-To: headers?  The same as what
the MTA does with Return-Receipt-To: headers -- mail back to the person
or address listed on the header.  This means one of two things has to
happen --  either the address on the header has to be complete and
guranateed to work as it is sent by the originator of the message, or
the MTAs in the path have to know about and modify this header en route.
The latter, of course, is impossible since there is no specification for
this in the RFC.  It also implies the same problems that Return-Path:
and From: headers have --that the address might be invalid due to bad
or inconsistent MTAs (see previous discussion about rewriting From: lines
in comp.mail.misc).

Therefore, this new option must be restricted to a local (LAN) environment.
It's somewhat easier to implement this way, but many problems still exist.
As for the header and it's content, just have the user's login name only
listed:
    Return-View-To: argv
When the UA decides to reply to the user, it simply replies to the address
listed -- the MTA will resolve the login name (via aliases file or whatever).
Seems simple enough ... but this won't work anyway.  Consider the following
arguments.

If the UA is responsible for this, then consider what happens when the
user reads a message: a reply is now automatically sent, the message
is flagged for having read the message and for having been replied to,
but the user e(x)its out of the mail program not updating anything.
There is no way to save the fact that the message has been read or
replied to.

Ok, let's hypothetically solve that problem by forcing updates for such
situations.  'x' will now update -only- those messages that have been
replied to.  What happens if the folder is read-only?  The forced updated
cannot happen.

Let's say that the user hasn't read the message, but instead has saved
it in another folder or a filename or has printed it on the printer.
Should these actions be considered as having 'read' the message?  It's
a hazy area here, but I would argue "no" because it is not unlike
another hop in the path of the delivery of the message.  The printer
does not imply that the user has read the message, nor does saving it
to a plain file.  If you save it to a folder, you could save the extra
information that the message has been return-view-to'ed, but what if
you read the message *after* having saved it.  The message has been
viewed and the originator replied to, but what happens when the user
reads the message in that other folder the message was previously saved
to?  As far as that folder is concerned, it hasn't been read yet.  Should
it generate another reply?  How would it know not to?

The more I think about this, the more I conjure up cases which break
this system -- it is poor design to try to have the UA do it.  But, in
spite of all that and if you really want to do it in mush, then you want
to add a new flag (VIEWED) in mush.h as it will be a new flag added to
the m_flags field of the "msg" data structure.  Go into display_msg()
and when the message is read (is_read() is called), you can kludge a
reply_to_hdr value set to Return-Receipt-To and call reply_to() on that
message and generate an automatic reply indicating that the message has
been viewed.
Dan Heller	<island!argv@sun.com>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 19:20:34 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa19338; 13 Jun 89 19:17 EDT
Received: from naggum.uu.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA14868; Wed, 14 Jun 89 01:17:56 +0200
Received: by naggum.uu.no (Xpresmail/2.1A)
	  id AA18134; Wed, 14 Jun 89 01:12:18 +0200
Date: Wed, 14 Jun 89 01:12:18 +0200
From: Erik Naggum <erik@naggum.uu.no>
Subject: Re: Return-view-to:
To: header-people@mc.lcs.mit.edu, jpp@slxsys.uucp
Message-Id: <8906132312.AA18134@naggum.uu.no>

I have written a few mailers over my time as a programmer and mail
user.  I have also sent a lot of mail and received several lots of
mail.  Thus established credentials, now for the comments.  :-)

A proper, standard-conforming mail reader (a.k.a. "user agent") shall,
according to the operating standards in the Internet, take NO ACTION
upon seeing headers like "Return-Receipt-To" and "Return-View-To".

As long as mail does not enter the Internet, any action can be taken,
of course, and for in-house, company-wide, etc, mail, this could be a
feature.  For mail crossing the line of demarcation between local
network and the Internet, such headers should not elicit action, and
any messages resulting from them should be dropped on the floor with no
return message to any part in the mail transaction.

I have seen a few mailers who have produced the "R-R-To" header, and
have never seen any feature to turn the damn thing off.  What if I
don't want receipts?  What if I want the person in question to give a
hint of his receiving my letter?  (A higher-level "protocol" was
mentioned.  This is the Right Thing.)

Get rid of both of these headers on Internet mail.

As I said, what is done on company-wide mail, is entirely up to the
company, and I think that the best solution would be to enable the
mail reader to detect the receipt of either kind and set appropriate
flags on the replied-to message and/or the copy of the sent message.
This is, after all, possible within a company, but I would assume 
that the formats of these messages would need standardization to be
useful.  No such standards exist on the Internet.

Maybe they should.  They should be implemented by mail readers at
both ends and relieve the user of reading machine-generated receipts.
(The same is true for error messages, but that's another question.)
Aside from the technical details of implementation, this is also a
political question.  Do we really want to teach our users not to
reply to "receipts"?  (If this is not implemented in the mail reader.)

Conclusion:  For company-wide, in-house mail: Great, do what you want.
For Internet mail, remove them or standardize them completely.

Cheers,
--Erik Naggum
 +----+     +----+  Email: erik@naggum.uu.no || enag@ifi.uio.no
===   |   ===   /   Snail: Naggum Software; 1560 VIKA; 0118 OSLO; NORWAY
===   |  ===   /    Phone: +472-717-822 (office, all hours) -352-977 (fax)
 +----+  +----+     Quote: "These are my opinions, not those of my employees."

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 07:35:56 EDT
Received: from ssyx.UCSC.EDU by mintaka.lcs.mit.edu id aa07861;
          14 Jun 89 7:34 EDT
Received: by ssyx.ucsc.edu (4.0/1.1)
	id AA22925; Wed, 14 Jun 89 04:34:37 PDT
Date: Wed, 14 Jun 89 04:34:37 PDT
To: header-people@mc.lcs.mit.edu
From: Brad Allen <ulmo@ssyx.ucsc.edu>
Subject:  re: Re: Return-view-to:
In-Reply-To:  <7260009@hpfclp.SDE.HP.COM>
	of 13 Jun 89 01:06:38 GMT; #7207
References:  <3990@slxsys.specialix.co.uk> <7260009@hpfclp.SDE.HP.COM>
Message-Id: 	<1989JE14.104217,7209;ULMO@SSYX.UCSC.EDU>

> A receipt should only be generated when the recipient has actually seen
> the letter.  To have the MTA supply the receipt would be misleading at best.
> All it would tell you is that the mail arrived on the destination host.
> 
> This is unfortunate as UAs aren't supposed to have to deal with things like
> that, but really, it's the only way to implement a return receipt correctly.

It should be specified what the ack is, what it is referring to.
I find acks acceptable in any form, as long as they are correct
to an authenticity which I accept.

i.e.  if I ask for receipt or acknowledgement, I might be satisfied knowing
that the mail got to any of the following:
 - the proper section of the world
 - the general area
 - the site
 - the department
 - the host machine
 - the particular user mailbox
 - the user

Depending on the situation.  It is ok to ACK something as long as you are
not lying.  For instance, there is a difference between "user has read
this letter" and "user deleted this letter without reading it", and I
wouldn't want to get the former ack when in fact the latter ack is the truth.
If the user doesn't want to let me know whether he read it personally,
he may opt to have a less fruitful ack come through:
"mail made it to user mailbox and user has dealt with it"
or even "mail made it to user mailbox".  If a host is incapable of acking
something that I ask it to ack, I ought to know that somehow.
It can be implicitly understood that acks closer to the destination
make any requests for acks further from the destination (earlier in the path)
unimportant, but this would also have to be considered by any standard
for definition.

What I'm saying is that I want flexibility, only because that seems
much more realistic and useful to me.

I can imagine some sort of header specifying various types of acks I want,
and a standard dictating what requests were subsets and supersets
of other requests and/or replies, how to do them, what unrequested acks mean,
the machine-parsable format of an ack, etc.


On a different note, I find it appalling that the Internet mail standards
do not use ACK as a reliability measure.  The top level protocol should always
have some reliable mechanism of ACK, and I'm sick of this being the human.

I point out also that any link in the chain which does not use an ack
will break the chain.  I have lost many hundreds of messages because
my own user mailer reception program would malfunction for one reason
or another (full disk, bug in program, renamed object, you name it),
and the mail got bounced to wherever it came from.
I would like ACKs to take care of this as well.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 19:35:46 EDT
Received: from [128.208.120.3] by mintaka.lcs.mit.edu id aa07242;
          14 Jun 89 19:34 EDT
Return-Path: <MRC@cac.washington.edu>
Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost) by Tomobiki-Cho.CAC.Washington.EDU
	(NeXT-0.8/UW-NDC Revision: 1.60.MRC ) id AA06153; Wed, 14 Jun 89 16:32:33 PDT
Date: Wed, 14 Jun 1989 16:15:26 PDT
From: Mark Crispin <MRC@cac.washington.edu>
Sender: mrc@tomobiki-cho.cac.washington.edu
Subject: re: Re: Return-view-to:
To: Brad Allen <ulmo@ssyx.ucsc.edu>
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <1989JE14.104217,7209;ULMO@SSYX.UCSC.EDU>
Message-Id: <MailManager.613869327.9952.mrc@Tomobiki-Cho.CAC.Washington.EDU>

     Although I understand the reason why many people want return receipts in
Internet mail, I'm extremely skeptical that they'll ever be implemented.  This
discussion comes up every couple of years and eventually it dies down, but not
after a lot of chest-pounding and pontificating.

     The existing netmail has a system of acks.  A mail client accepts
responsibility for a message -- to deliver it or to return a negative answer to
the sender.  It cannot surrender responsibility for the message until it has
received a positive answer from a mail server that the server has accepted
responsibility for the message.  As long as each link in the chain maintains
the return path correctly, there is no problem in transmitting the NACK.  Note
that the same mechanisms that can cause a message or a NACK to be destroyed can
also destroy an ACK (or forge an ACK).

     Leaving that aside...

     I can think of a lot of reasons why individuals or organizations would not
implement return receipts.  One excellent reason is the staggering legal
consequences it may engender.  Can you imagine being served with a lawsuit via
netmail?  It's not as crazy as it sounds.  I for one do *not* want a program
deciding for me whether or not to acknowledge a message.

     I believe that any communication which is so urgent that it requires
direct positive confirmation of contact is best done by telephone.

-- Mark --

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 20:17:42 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07827;
          14 Jun 89 20:16 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA18103@BLOOM-BEACON.MIT.EDU>; Wed, 14 Jun 89 19:55:11 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Jun 89 17:56:44 GMT
From: Frank Mayhar <ladcgw!frank@uunet.uu.net>
Organization: Bull HN Los Angeles Development Center
Subject: Re: Return-view-to:
Message-Id: <438@ladcgw.ladc.bull.com>
References: <14552@pasteur.Berkeley.EDU>, <4037@slxsys.specialix.co.uk>, <14602@pasteur.Berkeley.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Here's an idea:  Have the UA inform the MTA that Message-ID such-and-such,
located in file x, needs a Return-view-to processed.  The MTA then looks in
the indicated file for that message-id, and if it's there, it generates
the return and marks the message accordingly.

So the UA simply informs the MTA when a particular message has been read
(and contains a return-view-to header), and the MTA actually does the work.
What are the problems with this?  Any?
-- 
Frank Mayhar  ..!uunet!ladcgw!frank (frank@ladc.bull.com)
              Bull HN Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045  Phone:  (213) 216-6241

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 21:09:05 EDT
Received: from [128.229.36.16] by mintaka.lcs.mit.edu id aa08408;
          14 Jun 89 21:05 EDT
Received: from localhost.ARPA by confusion.ads.com (5.59/1.11)
	id AA01657; Wed, 14 Jun 89 17:05:15 PST
Message-Id: <8906150105.AA01657@confusion.ads.com>
To: header-people@mc.lcs.mit.edu
Subject: Change of address.
In-Reply-To: Your message of 13 Jun 89 18:59:22 +0000.
             <14602@pasteur.Berkeley.EDU> 
Date: Wed, 14 Jun 89 17:05:14 PST
From: barry@ads.com

Please change barry@confidence.princeton.edu to barry@ads.com.

Thanks,

barry

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jun 89 13:28:03 EDT
Received: from [192.31.95.1] by mintaka.lcs.mit.edu id aa05374;
          15 Jun 89 13:26 EDT
Received: by uccuxa.ucop.edu (5.57/Ultrix2.4-C)
	id AA28662; Thu, 15 Jun 89 10:27:54 PDT
Date: Thu, 15 Jun 89 10:27:54 PDT
From: Pat McGarry <opspjm@uccuxa.ucop.edu>
Message-Id: <8906151727.AA28662@uccuxa.ucop.edu>
To: header-people@mc.lcs.mit.edu
Subject: Mailing List

Please take me off of this list.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jun 89 00:29:57 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20625;
          16 Jun 89 0:27 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA22550@BLOOM-BEACON.MIT.EDU>; Thu, 15 Jun 89 23:55:13 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Jun 89 03:33:19 GMT
From: Cliff Joslyn <vu0112@bingvaxu.cc.binghamton.edu>
Organization: SUNY Binghamton, NY
Subject: ed/awk script to strip mail headers
Message-Id: <2199@bingvaxu.cc.binghamton.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


A kind person recently sent my an ed script to strip "boring" news
header lines (e.g.  References, Via, etc.) Could someone be so kind as
to do the same for mail? Or I guess I can write my own, if you make me. 
;-> ;->

Thanks.


-- 
O---------------------------------------------------------------------->
| Cliff Joslyn, Cybernetician at Large
| Systems Science, SUNY Binghamton, vu0112@bingvaxu.cc.binghamton.edu
V All the world is biscuit shaped. . .

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 07:55:09 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16067;
          22 Jun 89 7:48 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA06266@BLOOM-BEACON.MIT.EDU>; Thu, 22 Jun 89 07:31:05 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Jun 89 20:33:09 GMT
From: Walter Underwood <hpda!hpcuhb!hp-ses!wunder@bloom-beacon.mit.edu>
Organization: HP SW Engineering Systems - Palo Alto, CA
Subject: Re: RFC-822 'phrase' question
Message-Id: <1760002@hp-ses.SDE.HP.COM>
References: <43c2245d.129dc@blue.engin.umich.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

> I have noticed that a number of mailers will generate From: lines like:
>   From: John Q. Public <JQP@MIT-AI.ARPA>

A safe version of this is:

   From: (John Q. Public) JQP@MIT-AI.ARPA

In strict 822-land, the angle brackets are only allowed if there is a
route address, but the draft host requirements RFC amends the BNF to
allow that.  The above example could have angle brackets, but they
are not necessary.

wunder

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 11:13:19 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa27826; 22 Jun 89 11:06 EDT
Received: from naggum.uu.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA13641; Thu, 22 Jun 89 17:07:27 +0200
Received: by naggum.uu.no (Xpresmail/2.1A)
	  id AA18400; Thu, 22 Jun 89 16:36:34 +0200
Date: Thu, 22 Jun 1989 16:01:44 MET DST
From: Erik Naggum <erik@naggum.uu.no>
Subject: Re: RFC-822 'phrase' question 
To: Walter Underwood <wunder@hp-ses.uucp>
Cc: RFC822 still requires something here <header-people@mc.lcs.mit.edu>
Message-Id: <8906221436.AA18400@naggum.uu.no>

> > I have noticed that a number of mailers will generate From: lines like:
> >   From: John Q. Public <JQP@MIT-AI.ARPA>

Strictly speaking, this is in violation of the syntax for a "phrase",
just as you are concerned about.

> A safe version of this is:
> 
>    From: (John Q. Public) JQP@MIT-AI.ARPA
> 
> In strict 822-land, the angle brackets are only allowed if there is a
> route address, but the draft host requirements RFC amends the BNF to
> allow that.  The above example could have angle brackets, but they
> are not necessary.

It could _NOT_ have angle brackets with the current, unamended RFC822!
You also misrepresent the issue by muddying the water around the need
and allowance for angle brackets.  The current syntax, to be amended
by Host Requirements (at least the last draft I have), is:

	mailbox = addr-spec
		/ phrase route-addr

also note that
	
	route-addr = "<" [ route ] addr-spec ">"

where route is clearly optional.

The problem addressed in the draft Host Requirements is the requirement
of a phrase in an angle-bracketed addr-spec.  This will be alleviated
thus (pending approval of the HR RFC):

	mailbox = addr-spec
		/ [ phrase ] route-addr

This I view as a Good Thing.

The following characters are (still) illegal in a phrase (i.e. making it
several words and/or phrases with delimiters between them):

	( ) < > @ , ; : \ " . [ ]

(Note that although `(' and ')' are illegal in a word, they are legal
at any point where a space is legal, thus may legally terminate a word,
perhaps making it one of several words in a phrase.)

To conclude, the first gripe on
	
	From: John Q. Public <JQP@MIT.ARPA>

is valid, and the standards (RFC821 OR RFC822)should be amended to
correct it, and

	From: (John Q. Public) <JQP@MIT.ARPA>

is illegal under the current syntax.

I don't know RFC733.  Anybody knows if the first From address is 
a relic from bygone times?

Cheers, and happy parsing to you all,

--Erik Naggum
 +----+     +----+  Email: erik@naggum.uu.no --or-- enag@ifi.uio.no
===   |   ===   /   Snail: Naggum Software; POB 1560 VIKA; OSLO 0118; NORWAY
===   |  ===   /    Phone: +47-2-717-822 (office, etc) -352-977 (fax)
 +----+  +----+	    "These are my opinions, and not those of my employees."

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 17:06:47 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa02307;
          22 Jun 89 16:40 EDT
Received: from hpsdel.sde.hp.com by hp-sde.sde.hp.com ; Thu, 22 Jun 89 10:38:08 pdt
Received: by hpsdel ; Thu, 22 Jun 89 10:37:53 pdt
Date: Thu, 22 Jun 89 10:37:53 pdt
From: Walter Underwood <wunder@sde.hp.com>
Message-Id: <8906221737.AA23741@hpsdel.sde.hp.com>
To: hp-sdd!uunet!naggum.uu.no!erik@sde.hp.com
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: Erik Naggum's message of Thu, 22 Jun 1989 16:01:44 MET DST <8906221436.AA18400@naggum.uu.no>
Subject: RFC-822 'phrase' question 

I almost didn't mention the angle bracket stuff.  I should have said
that they are only required for route addresses.  I prefer:

  From: jqp@host.domain (John Q. Public)

but I haven't checked that rigorously.

The common use of angle brackets is thanks to (you guessed it!)
sendmail, which uses them to help disambiguate UUCP and ARPA
addresses.

It looks like the robustness principle really applies here, and that
mailers should be be very conservative in what they generate and
liberal in what they accept.

wunder

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 16:48:15 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03225;
          23 Jun 89 16:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA18436@BLOOM-BEACON.MIT.EDU>; Fri, 23 Jun 89 16:25:33 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Jun 89 19:57:14 GMT
From: Chris Garrigues <cs.utexas.edu!ut-emx!linus!daffy!7thson@ohio-state.arpa>
Organization: Schlumberger Lab for CS, Austin, TX
Subject: Re: RFC-822 'phrase' question
Message-Id: <399@linus.SLCS.SLB.COM>
References: <43c2245d.129dc@blue.engin.umich.edu>, <1760002@hp-ses.SDE.HP.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1760002@hp-ses.SDE.HP.COM> wunder@hp-ses.SDE.HP.COM (Walter Underwood) writes:
>> I have noticed that a number of mailers will generate From: lines like:
>>   From: John Q. Public <JQP@MIT-AI.ARPA>
>
>A safe version of this is:
>
>   From: (John Q. Public) JQP@MIT-AI.ARPA
>
>In strict 822-land, the angle brackets are only allowed if there is a
>route address, but the draft host requirements RFC amends the BNF to
>allow that.  The above example could have angle brackets, but they
>are not necessary.
>
>wunder

I don't see the problem with the other form.

Some of the rules from RFC822:
     authentic   =   "From"       ":"   mailbox  ; Single author
                 / ( "Sender"     ":"   mailbox  ; Actual submittor
                     "From"       ":" 1#mailbox) ; Multiple authors
                                                 ;  or not sender

 
     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec
 
     route-addr  =  "<" [route] addr-spec ">"

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

and a parse tree of the sample given above:
	From: John Q. Public <JPQ@MIT-AI.ARPA>	=>
	From: phrase <local-part@domain>	=>
	From: phrase <addr-spec>		=>
	From: phrase route-addr			=>
	From: mailbox				=>
	authentic


What's the problem?

Chris Garrigues,
7thSon@SLCS.SLB.COM

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 19:08:43 EDT
Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa04908;
          23 Jun 89 19:04 EDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
	(5.61/UW-NDC Revision: 1.99 ) id AA10103; Fri, 23 Jun 89 16:03:24 -0700
Date: Fri, 23 Jun 1989 15:52:44 PDT
From: Mark Crispin <MRC@cac.washington.edu>
Sender: mrc@tomobiki-cho.cac.washington.edu
Subject: Re: RFC-822 'phrase' question
To: Chris Garrigues <cs.utexas.edu!ut-emx!linus!daffy!7thson@ohio-state.arpa>
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <399@linus.SLCS.SLB.COM>
Message-Id: <MailManager.614645564.1308.mrc@Tomobiki-Cho.CAC.Washington.EDU>

In <399@linus.SLCS.SLB.COM>, Chris Garrigues writes:
>>> I have noticed that a number of mailers will generate From: lines like:
>>>   From: John Q. Public <JQP@MIT-AI.ARPA>
>What's the problem?
Due to a now-archaic theory of how names should work, the period after "Q" is
not valid.  Once upon a time, people thought that periods should be considered
significant at the RFC-822 level.  Study further what constitutes a "phrase"
and you'll see the problem.

A lot of mail software simply treats period as an ordinary alphanumeric
character.  However, this is contrary to what RFC-822 expects you will do.

I wish the Host Requirements RFC would change this.  The correct header line,
	From: "John Q. Public" <JQP@MIT-AI.ARPA>
looks ugly to many people.

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jun 89 15:44:53 EDT
Received: from icsib.Berkeley.EDU by mintaka.lcs.mit.edu id aa29202;
          23 Jun 89 22:15 EDT
Received: by icsib.Berkeley.EDU (4.0/SMI-4.0)
	id AA04472; Fri, 23 Jun 89 19:18:41 PDT
From: Eric Allman <eric@icsib.berkeley.edu>
Message-Id: <8906240218.AA04472@icsib.Berkeley.EDU>
To: Walter Underwood <wunder@sde.hp.com>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: RFC-822 'phrase' question 
In-Reply-To: Walter Underwood's message of Thu, 22 Jun 89 10:37:53 -0700.
             <8906221737.AA23741@hpsdel.sde.hp.com> 
Date: Fri, 23 Jun 89 19:18:38 PDT

These days I try to stay out of "email wars", but I just had to
respond to this one.  N.B.: I'm responding only to the rather common
misunderstanding in this message, not trying to trash the author.

> Date: Thu, 22 Jun 89 10:37:53 pdt
> From: Walter Underwood <wunder@sde.hp.com>
> Subject: RFC-822 'phrase' question 

> The common use of angle brackets is thanks to (you guessed it!)
> sendmail, which uses them to help disambiguate UUCP and ARPA
> addresses.

This makes about as much sense as claiming that DEC is responsible
for ASCII because they used it in the VT100 series.  Angle brackets
were part of published standards long before sendmail was even a
gleam in its father's eye -- in fact, they were a royal pain to
support, and (to my mind) added nothing of value.  They do nothing
to help disambiguate UUCP and ARPA addresses.

There are many legitimate things wrong with sendmail, perhaps the
worst being that it tried to bridge the gap between two entrenched
standards (the ad hoc UUCP standard and the NCP/RFC733 ARPA world)
and several emerging new worlds, notably the TCP/RFC822 world.  The
latter worlds were changing rapidly -- during the development of
RFC821/822, sendmail adapted to at least a half dozen different draft
versions within days of their release, providing important practical
input to those specifications.  Unfortunately, the flexibility that
made that all possible is now an albatross, engendering formidable
configuration files.  (Believe it or not, the first sendmail.cf was
about one page long; ruleset 0 was but a few lines.  Unfortunately,
I then had to add support for "@dom.ain.a,@dom.ain.b:user@dom.ain.c",
which uses three punctuation characters instead of one, and is in
some cases left recursive and in other cases right recursive.  I also
had to support the "user@hostc@hostb@hosta" syntax, specified in 733,
later disallowed by administrative fiat, but still used all too heavily
in the real world.  I had to support nested angle brackets --
disallowed in 822, but permitted in 733; another of those features
from hell that refused to die.  At the time, CMU made heavy use of
spaces in login names, and again sendmail managed to handle both
the new and the old syntaxes.  The word "at" (surrounded by spaces)
was equivalent to "@" in 733-land, but sendmail coped.  Several sites,
including Berkeley, used ":" to separate hostname from username [as
in host:user]; an especially exciting development in view of the fact
that 822 had two reserved uses for the colon in addresses.  Much to
my shock and delight, many sites had defined "^" as an equivalent to
"!" in UUCP addresses [to avoid the conflict with "!" in csh] -- it
seems this had to be supported as well.  I finally gave up on the
"list: userA, userB, ... , userZ;" syntax, which managed to overload
colon and comma, add semicolon, and be ambiguous as well, but I did
accept the varient "list:;" syntax.  Every single one of these -- and
others  that I have the discretion to avoid discussing) bloated the
configuration file a little bit more.)  This flexibility was great at
the time, but now all it does is obfuscate the issues.

If you want to credit sendmail with something, credit it for helping
bring UNIX onto the Internet.  Credit it for allowing communication
between UUCP and the ARPAnet without requiring that UUCPers type in
822-compliant headers.  Credit it for helping to make possible a world
in which you can send mail to someone in Australia without knowing
that your message goes through UUCP, then  Internet, then X.25
something-or-other, then ACSnet, and probably a few others in between.
Credit it for allowing users to continue to use their existing
user interface programs, rather than insisting that they salute the
new flag.

Make your own choice whether to lambast or laud sendmail for refusing
to decide whether "hostA!user@hostB" should be sent to hostA or hostB,
deferring that decision for the local site -- even allowing sysadmins
to make that decision based on the value of the hostA and hostB strings.
It certainly helped perpetuate the confusion such addresses implied;
but it also helped users ease their way from local networks to global
networks.  You can decide the value of header rewriting.  It helped
the development of automatic "reply" commands in mailers, without
requiring that they know the topology of the internet, but it also
handed miles of ropes to sloppy sysadmins, and allowed multiple address
formats (such as host!user versus user@host) to continue far longer
the shootout that would otherwise have probably resulted.  Roll the
dice about inserting "Apparently-To:" -- I didn't do this of my own
volition.  Several people wanted me to just add To: lines, but I
resisted because messages sent to several people from outside a
sendmail-based world could be delivered with an inaccurate distribution
list.  Using "Apparently-To:" at least admitted to the possibility of
error.

I'm sorry to be so verbose here; I didn't know I had it in me.  I put
five years into sendmail, all of it unpaid  time, and I guess I still
feel a bit protective.  For the record, I know that the time is nearing
for sendmail to step aside for something that makes a new set of
assumptions.  But please acknowlege that sendmail was a success for
its time: it helped us move forward, and the next generation of mailers
will be built on sendmail's shoulders, not on its toes.

eric

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 03:35:03 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa07574;
          24 Jun 89 20:28 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA23322; Sat, 24 Jun 89 19:55:45 -0400
Date: Sat, 24 Jun 89 19:55:45 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906242355.AA23322@uunet.uu.net>
To: eric@icsib.berkeley.edu, wunder@sde.hp.com
Subject: Re: RFC-822 'phrase' question
Cc: header-people@mc.lcs.mit.edu

While we're blaming mailers for things, lets not forget to
blame MMDF for the abusive use of source routes where none are required.

The protypical example is a certain large mail realy in the Boston area
who think that they way to deal with MX records is to generated
a source route. This is clearly unnecssary.

I'll bet fully half of my 870 line sendmail config file is dealing with
source routes from places that should know better. Yes they're
legal, but their typical use can only be described as an
unnecessary pain in the ass.

Every time I get mail from some MMDF site complaining about not
properly handling source routes (when there is no reason for
specify a source route in the first place!) I come a little closer
to ripping out all of the source route code from sendmail and
laughing when someone complains that I'm violating the "standard"

There is no place for source routes in the current mail system
(MX records removed the last excuse). They should be abolished.

--rick

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 18:43:13 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa04025; 25 Jun 89 18:38 EDT
Received: by ifi.uio.no (5.61++/1.15) 
	id AA09492; Mon, 26 Jun 89 00:15:22 +0200
Sender: Erik Naggum <enag@ifi.uio.no>
Date: Mon, 26 Jun 1989 0:15:21 MET DST
From: Erik Naggum <erik@naggum.uu.no>
To: Rick Adams <rick@uunet.uu.net>
Cc: eric@icsib.berkeley.edu, wunder@sde.hp.com, header-people@mc.lcs.mit.edu
Subject: Re: RFC-822 'phrase' question 
In-Reply-To: Rick Adam's message of Sat, 24 Jun 89 19:55:45 -0400 
Message-Id: <CMM.0.88.614816121.enag@ifi.uio.no>

> There is no place for source routes in the current mail system
> (MX records removed the last excuse). They should be abolished.
> 
> --rick

In the headers of messages they are unnecessary as well as cumbersome
for users, and they introduce obstacles to adressering that are
reminiscent of UUCP bang-path adressing prior to pathalias.

The question is very different in the SMTP envelope, however.  I, for
one, favor stronger use of source routes in the envelopes, to make
return paths easier to traverse.  There seems to be a clause in the
Host Requirements Draft RFC which requires an SMTP relay to add its own
canonicalized domain name to the From (MAIL) line in the envelope, and
understand it in the To (RCPT) lines.

Users should also be _able_ to specify source routes, when a scenic
route is deemed necessary.

Provisions for support of the source routes should not be ripped out of
mailers.  Au contraire!  It should be much easier to follow the standards.
(While I commend Eric's effort on sendmail, indeed I am grateful to him,
time has come to allow for simpler products in a more homogenous mail world.
That's _more_ homogenous, and I also speak from the user's point of view,
not about functionality.)

--Erik Naggum
The last defender of source routes.

PS: I apologize for the violation of RFC822 in the format of the Date field.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 09:35:57 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa06552;
          26 Jun 89 0:35 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA21874; Sun, 25 Jun 89 23:44:17 -0400
Date: Sun, 25 Jun 89 23:44:17 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906260344.AA21874@uunet.uu.net>
To: erik@naggum.uu.no
Subject: Re: RFC-822 'phrase' question
Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com

It is a fundamentally flawed assumption that source routes may
be reversed to form a valid mail path.

There are too many one way mail gateways in the world. Use of source
routes encourage the concept that all routes are bidirectional and
are the optimal path.

I dont care what the standard says. The reality is that you can
not necessarily reverse a source route and get a valid mail
path. 

The entire point of a domain naming system is to separate the
name from the route. Virtually everyone agrees that this is good.
If it is good, then source routes are bad. The Recevied lines already
provide all of the information that you might get from the
source routes should you actually need that information.

Think of Postal Mail for a minute. Do you really care what
person stuck the mail in your mailbox? Do you really want to
send all of your reply mail back through that person? What if they
are sick for a week?

The same argument applies to electronic mail.

--rick

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 14:33:52 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa28616;
          26 Jun 89 14:27 EDT
Received: from microsoft.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA27702; Mon, 26 Jun 89 14:24:22 -0400
From: microsoft!t-dannyp@uunet.uu.net
Message-Id: <8906261824.AA27702@uunet.uu.net>
To: header-people@mc.lcs.mit.edu
Subject: Source Routes
Cc: padwa@husc3.harvard.edu
Date: Mon Jun 26 10:57:36 1989

Rick,
	I agree that in an environment without brain-dead mailers, source
routes would be an evil thing, and would be almost criminal. However,
we don't live in such a world......think of all of the "dumb" mailers
out there....many people still can't handle MX records!!

	In that kind of environment, source routes are still needed....
especially when all of the malfunctioning gateways that are operating
are considered. It is tempting to say "Well, if your gateway doesn't work,
then fix it!", but the sad reality is that we must keep our users happy.
Until such time as all "domain-style" addresses are optimally accessable
by MX-derived routes (optimally meaning without to many extraneous trips
across the country) I will continue to recommend source-routes to my
users.....I can't see any alternative.

                            Danny Padwa
                            Harvard VMS Network Programmer
                            Padwa@Husc3.Harvard.Edu
                            (at Microsoft for the summer...mail is forwarded)

Note: The above opinions are my own, probably not those of my employers.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 14:46:35 EDT
Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa28841;
          26 Jun 89 14:43 EDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
	(5.61/UW-NDC Revision: 1.99 ) id AA23824; Mon, 26 Jun 89 11:40:28 -0700
Date: Mon, 26 Jun 1989 11:27:25 PDT
From: Mark Crispin <MRC@cac.washington.edu>
Sender: mrc@tomobiki-cho.cac.washington.edu
Subject: Re: RFC-822 'phrase' question
To: Rick Adams <rick@uunet.uu.net>
Cc: eric@icsib.berkeley.edu, wunder@sde.hp.com, header-people@mc.lcs.mit.edu
In-Reply-To: <8906242355.AA23322@uunet.uu.net>
Message-Id: <MailManager.614888845.5474.mrc@Tomobiki-Cho.CAC.Washington.EDU>

A fanatic gleam appears in MRC's eye as he scans the message from Rick Adams
suggesting that source routes be abolished.  "Vindication!" he screams.  After
six and a half years of preaching that source routes were useless, he being of
the %-hack cult, it seems that the religion has taken fruit.  Let the Word be
spread throughout the land!

Then he calms down, and a mood of depression sinks in, as he realizes that now
he will never have the experience, the joy, the fufilment...  Yes, he'll have to
strike "implement source routes" from the TOPS-20 mailsystem "to-do" list.  Such
sorrow!

Tongue firmly in cheek,

-- Mark --

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 18:03:59 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa02409;
          26 Jun 89 17:57 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA15079; Mon, 26 Jun 89 17:56:26 -0400
Date: Mon, 26 Jun 89 17:56:26 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906262156.AA15079@uunet.uu.net>
To: header-people@mc.lcs.mit.edu, microsoft!t-dannyp@uunet.uu.net
Subject: Re: Source Routes
Cc: padwa@husc3.harvard.edu

Why do you think a mailer that does not handle MX records will
be able to correctly handle source routes.

The now semi-official percent-hack takes care of the gateway
situation.

Sorry, try again.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 19:57:03 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa06272; 26 Jun 89 19:54 EDT
Received: by ifi.uio.no (5.61++/1.15) 
	id AA18099; Tue, 27 Jun 89 01:54:19 +0200
Date: Tue, 27 Jun 1989 1:54:16 MET DST
From: Erik Naggum <enag@ifi.uio.no>
To: Rick Adams <rick@uunet.uu.net>
Cc: header-people@mc.lcs.mit.edu, t-dannyp@microsoft.uucp, 
    padwa@husc3.harvard.edu
Subject: Re: Source Routes 
In-Reply-To: Your message of Mon, 26 Jun 89 17:56:26 -0400 
Message-Id: <CMM.0.88.614908456.enag@ifi.uio.no>

> The now semi-official percent-hack takes care of the gateway
> situation.
> 
> Sorry, try again.

If you seclude the use of the %-hack to the envelope, as I suggest one
do with source routes, all is well, but experience shows that hosts that
are likely to use the %-hack, splat it all over the place, and also
reduce to rubbles the once-working mixed-mode addresses.  This is one
argument against the %-hack.

As we are 100% forbidden to parse the local-part, but required to let
all parts of a source route be MX-resolvable (as the current draft goes),
we might have reduced the size of the local-part, and user agents can
exploit the knowledge that all parts of the source route are adressable
directly in replies.  They have no such capability with %-hacked local-
parts.  This is one argument against the %-hack and for source routes.

We should perhaps require gateways who recognize themselves as the domain
strip themselves from the %-hacked address and UNDO the bleeding %-hack
in the way they introduced it.  This would work, while what they do now
is to translate foo!user@bar to foo!user%bar@gateway, and then send to
foo with uucp when it gets back to gateway.  That's the main reason I
hate the %-hack vehemently!  With "semi-official" things, it's no
guarantee it will work, and with increasing local-parts, things will get
increasingly messy, and no mailers are allowed to do anything with it.
This is one argument against semi-officialness.

--Erik
the last defender of source routes

PS: Standardize functionality, not broken implementations.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 00:34:45 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa14091;
          27 Jun 89 0:21 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA19140; Mon, 26 Jun 89 22:33:34 -0400
Date: Mon, 26 Jun 89 22:33:34 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906270233.AA19140@uunet.uu.net>
To: enag@ifi.uio.no
Subject: Re: Source Routes
Cc: header-people@mc.lcs.mit.edu


	As we are 100% forbidden to parse the local-part, but required to let
	all parts of a source route be MX-resolvable (as the current draft goes),
	we might have reduced the size of the local-part, and user agents can
	exploit the knowledge that all parts of the source route are adressable
	directly in replies.  They have no such capability with %-hacked local-
	parts.  This is one argument against the %-hack and for source routes.


If ALL parts of the address are MX resolvable, then WHAT PURPOSE does
a source route have? The Received lines provide the route trace.
The MX records provide the routing. Whats left other than redundancy and
ugliness?

Note that the principal users of source routes do NOT restrict themselves
to MX resolvable addresses which makes a bad situation even worse.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 00:46:58 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06952;
          27 Jun 89 0:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA10121@BLOOM-BEACON.MIT.EDU>; Tue, 27 Jun 89 00:26:34 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Jun 89 10:31:10 GMT
From: Greg Miller <att!watmath!julian!uwovax!miller@bloom-beacon.mit.edu>
Subject: Re: RFC-822 'phrase' question
Message-Id: <2377@uwovax.uwo.ca>
References: <43c2245d.129dc@blue.engin.umich.edu>, <1760002@hp-ses.SDE.HP.COM>, <399@linus.SLCS.SLB.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <399@linus.SLCS.SLB.COM>, 7thson@daffy.slcs.slb.com (Chris Garrigues) writes:
> and a parse tree of the sample given above:
> 	From: John Q. Public <JPQ@MIT-AI.ARPA>	=>
> What's the problem?

The problem is that unquoted periods in the name tag are not allowed
by RFC 822.

So the above should be written as -

        From: "John Q. Public" <JPQ@MIT-AI.ARPA>

//Greg Miller//

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 01:31:11 EDT
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa29861;
          28 Jun 89 1:28 EDT
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA08206; Tue, 27 Jun 89 22:28:36 PDT
Date: Tue, 27 Jun 89 22:28:36 PDT
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <8906280528.AA08206@garnet.berkeley.edu>
To: header-people@mc.lcs.mit.edu
Subject: Re: Source Routes
Cc: rick@uunet.uu.net

In reply to:

	If ALL parts of the address are MX resolvable, then WHAT
	PURPOSE does a source route have?

Postmasters will still have a use for source routing to override a
bad MX record, in order to send a message to get the MX record fixed. 

I had to do that last week when a host did not realize that they
needed to add a host MX record to override a wildcard MX record for
their site. They had SMTP running, but my mailer which looks for
a MX record first (as it should) used the wildcard MX instructions
and thus did not make a direct SMTP connection based on the inet address
(A record).

Bill Wells
postmaster@jade.berkeley.edu
netinfo@garnet.berkeley.edu


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 05:12:04 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20753;
          28 Jun 89 5:09 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19383@BLOOM-BEACON.MIT.EDU>; Wed, 28 Jun 89 04:56:15 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Jun 89 01:12:41 GMT
From: Jim Anderson <ukma!xanth!nic.MR.NET!shamash!com50!aob!jim@ohio-state.arpa>
Organization: Anderson O-Brien, Inc., St. Paul, MN
Subject: Smail patches for Subject line problem
Message-Id: <217@aob.aob.mn.org>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Quite a while ago, there was a patch posted for smail to fix a problem
where, if smail didn't see the headers in the right order (I think this
is it anyway), it would drop the Subject: line into the body of the
message.  Anyway, I thought I had saved it, but now that I need to get
them installed, I can't find the patches.  Does anybody out there still
have the patches or remember what the fix was?  Thanks.
-- 
Jim Anderson			(612) 636-2869
Anderson O'Brien, Inc		New mail:jim@aob.mn.org
2575 N. Fairview Ave.		Old mail:{rutgers,gatech,amdahl}!bungia!aob!jim
St. Paul, MN  55113		"Fireball... Let me see... How did that go?"

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 06:32:33 EDT
Received: from [128.114.133.1] by mintaka.lcs.mit.edu id aa21398;
          28 Jun 89 6:31 EDT
Received: by ssyx.ucsc.edu (4.0/1.1)
	id AA29541; Wed, 28 Jun 89 01:06:20 PDT
Date: Wed, 28 Jun 89 01:06:20 PDT
To: header-people@mc.lcs.mit.edu
From: Brad Allen <ulmo@ssyx.ucsc.edu>
Message-Id: 	<1989JE28.071941,7248;ULMO@SSYX.UCSC.EDU>
Subject: re: source routes and Rick <root@uunet> asking why

Source routes are useful for both rerouting around network problems
as well as expand the destination of an MX'd host to the appropriate
address on the MXing host.

Network problems are many -- bad packet routing; one out of a collection
of links in the network go down, and source route will help route around
it; bad UUCP Map stuff (this is not really relevant to Internet proper
but serves as a good example).

A conceivable example of an MX using source routes:

mist.aptos.ca.us	preference = 10, mail exchanger = SSYX.UCSC.EDU

Mail to user@mist.aptos.ca.us gets sent to SSYX.UCSC.EDU.

When SSYX receives this piece of mail, it looks the address of this
up in the UUCP Map pathalias output, finds this line:
mist.aptos.ca.us splat!mist!%s
and sends the mail off to UUCP host splat.

Well, SSYX could just as easily have used source routing, converting
mist.aptos.ca.us -> @splat.uucp:user@mist.aptos.ca.us
or even (preferably if the mailer could handle it)
mist.aptos.ca.us -> @splat.aptos.ca.us:user@mist.aptos.ca.us
since @something1:something3@something2 is RFC822
whereas something1!something2!something3 is not.
Splat will soon understand these routes, as will Mist.
(Yes yes I know, splat already understands something1!something2!something3
form.)

For the record, postmaster@ssyx flopped on making sure source routing works
via the sendmail there.  It doesn't, since the commas get in the way,
and he has tweaked sendmail many times to get it working
(for many reasons -- MXes, UUCP Mappings, to get away from the brain damaged
version of sendmail and sendmail.cf Sun put out, deal with NFS hosts which
some have SMTP and some don't but they all use the same directory, etc.)
I can understand the argument against keeping source routes.
However, the standard is the standard, and it does provide a standard
way to do a needed task.

I haven't studied RFC822 that much and often wonder how it is expected
that @domain1,@domian2:mailbox@domain3
is supposed to be distinguished from two distinct recipients
(@domain1 and @domain2:mailbox@domain3)?  I can see that
looking INTO the address @domain1 reveals a missing mailbox,
but so what?  Is that the clue the mailers are to go by?
Conceivably something to @host could be SMTP'd to the host just as is,
with a null username, and the host would know what to do with it
(such as mail to @LastName.City.State.US where the owner
didn't want to be redundant), even though the format
is supposed to be user@host.  What's the answer??

Which brings up the question of why we need the "@" sign.
When is user.name.domain.name going to be a valid mailbox?
I can easily conceive of examples ...
ulmo.aptos.ca.us getting sent to me;
postmaster.uunet.uu.net getting sent to Rick ... etc.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 10:35:21 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24072;
          28 Jun 89 10:30 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA24035@BLOOM-BEACON.MIT.EDU>; Wed, 28 Jun 89 10:22:34 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Jun 89 01:54:01 GMT
From: "Govind N. Kamat" <uccba!uceng!kamat@ohio-state.arpa>
Organization: Univ. of Cincinnati, College of Engg.
Subject: "Status" header
Message-Id: <1322@uceng.UC.EDU>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

I keep noticing a header called "Status" in certain mail, with field
values like "R" and "OR".

What is this header supposed to represent?  It doesn't seem to be part
of RFC822.

-- 
Govind N. Kamat 			College of Engineering
kamat@uceng.UC.EDU			University of Cincinnati
					Cincinnati, OH 45221, USA

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 11:45:37 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa25140; 28 Jun 89 11:39 EDT
Received: by ifi.uio.no (5.61++/1.15) 
	id AA03737; Wed, 28 Jun 89 17:38:57 +0200
Date: Wed, 28 Jun 1989 17:38:54 MET DST
From: Erik Naggum <enag@ifi.uio.no>
To: "Govind N. Kamat" <uccba!uceng!kamat@ohio-state.arpa>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: "Status" header 
In-Reply-To: Your message of 28 Jun 89 01:54:01 GMT 
Message-Id: <CMM.0.88.615051534.enag@ifi.uio.no>

> I keep noticing a header called "Status" in certain mail, with field
> values like "R" and "OR".

It's part of the BSD Mail program (a.k.a mailx) flags support.  When
you see new messages, they have N in the first column.  When you have
not read a message before you leave your mailbox, it will show U in
the header summary next time you read mail.  These correspond to
no status, and "O" status, respectively.  When you have read a message,
it will be flagged "R".  If it also old, it's "RO".

> What is this header supposed to represent?  It doesn't seem to be part
> of RFC822.

What you see in your mailbox does not have to be RFC822-compliant at
all.  In most cases it is, vaguely, but there's no standardized way
to do this.  RFC822 specifies the format of INTERNET text format,
not mailbox text formats.  There is even a discussion in there about
this specific difference.


--Erik Naggum
 +----+     +----+  Email: erik@naggum.uu.no --or-- enag@ifi.uio.no
===   |   ===   /   Snail: Naggum Software; POB 1560 VIKA; OSLO 0118; NORWAY
===   |  ===   /    Phone: +47-2-717-822 (office, etc) -352-977 (fax)
 +----+  +----+	    "These are my opinions, and not those of my employees."

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:01:39 EDT
Received: from SH.CS.NET by mintaka.lcs.mit.edu id aa25348; 28 Jun 89 11:53 EDT
To: Rick Adams <rick@uunet.uu.net>
cc: eric@icsib.berkeley.edu, wunder@sde.hp.com
cc: header-people@mc.lcs.mit.edu
Subject: Re: RFC-822 'phrase' question
Date: Wed, 28 Jun 89 11:12:02 -0400
From: Daniel Long <long@sh.cs.net>
Message-ID:  <8906281153.aa25348@mintaka.lcs.mit.edu>


	The protypical example is a certain large mail realy in the Boston area
	who think that the way to deal with MX records is to generate a
	source route. This is clearly unnecssary.

Rick,

    Since we're under fire here, I want to be sure I'm clear on what you're
firing at :-).  Is that when MMDF relays mail it adds itself to the RFC-821
sender field (which, I believe is required per section 5.2.6 of the draft Host
Requirements RFC).  Or is that RELAY.CS.NET has its MMDF configured to append
@relay.cs.net on mail relayed through it (which affects header rewriting).

    If it's the former, then I'd be happy to help change MMDF's behavior if the
powers-that-be want to change the spec (although I don't think it's wise).  If
it's the latter, then I'm also willing to consider turning off that "feature".
We were mostly waiting for the rest of the world to get their act together and
understand MX records.  I'd be easily convinced that that time has come but I
also want to be sure we don't cut off mail to those organizations we serve
through RELAY.CS.NET.  

We currently do the @relay.cs.net rewrite on mail being sent to most
destinations.  We have an exception list for folks who have told us they don't
want it.  One solution might be to make the default be to not do the rewrite
and to have an exception list for any destinations that don't yet support MX.

Suggestions?
Dan

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:06:54 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25488;
          28 Jun 89 12:01 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA26467@BLOOM-BEACON.MIT.EDU>; Wed, 28 Jun 89 11:45:05 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Jun 89 13:52:45 GMT
From: Karl Kleinpaste <giza.cis.ohio-state.edu!karl@ohio-state.arpa>
Organization: Ohio State Computer Science
Subject: Re: "Status" header
Message-Id: <KARL.89Jun28095245@giza.cis.ohio-state.edu>
References: <1322@uceng.UC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

That's being done by Berkeley Mail.  If you have source, see
ucb/Mail/send.c.  Gross.  Pick another MUA.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 13:11:07 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa14928;
          28 Jun 89 13:07 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA25873; Wed, 28 Jun 89 13:06:47 -0400
Date: Wed, 28 Jun 89 13:06:47 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906281706.AA25873@uunet.uu.net>
To: long@sh.cs.net
Subject: Re: RFC-822 'phrase' question
Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com

Say, for example, I'm a csnet site and I send mail to user@site.oz.au

csnet relay properly goes and finds the MX record that says ship it to uunet.

uunet gets a RCTP TO: line that looks like:

	RCPT TO: <@uunet.uu.net:user@site.oz.au>

I object to the gratuitious addition of the @uunet.uu.net.

(I also object to its addition to the MAIL FROM line, but my
argument on that is with the standard, not with your implementation).

My complaints are all about the RCPT TO line and they seem to
be present in lots of MMDF sites. csnet-relay is just one of the
more obvious.

I think about 1/3 of the sendmail.cf changes we make are to
cope with "unusual" use of source routes.

There was also a truly horrible problem with routing for .NZ that
I can't remember the exact nature of. We were getting things like:

	RCPT TO: <@uunet.uu.net:@vuwcomp.ac.nz:user@someothersite.ac.nz>

and that totally fried things for us. (At the time the NZ mail
was sent via uucp and internet source routes do not easily map
into uucp addresses!)

All we really wanted (or needed) was:

	RCPT TO: <user@someothersite.ac.nz>

My basic claim is that if an MX record says that some site can handle
the address, let them. Dont try and help them out by adding routing
information. Let them do the end routing.

---rick

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 13:23:00 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00531;
          28 Jun 89 13:16 EDT
Received: by INFOODS id <00001139062@INFOODS.MIT.EDU> ;
       Wed, 28 Jun 89 13:09:58 EDT
Date: Wed, 28 Jun 89 12:44:07 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: re: Brad Allen's comments on Rick's comments on source routes
To: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
X-VMS-Mail-To: EXOS%"<@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>"
Message-ID: <890628124407.00001139062@INFOODS.MIT.EDU>

Unfortunately, while I agree with Brad's main point, some of his 
examples and comments add strength to Rick's complaints.  Specifically, 
the reason why I prefer source routes to the %-kludge when there is a 
choice is that the syntax and semantics of source routes--since they are
part of the protocol--are, or can be made, unambiguous, while the 
%-kludge, by definition, is strictly a local-part, up to gateway 
interpretation.  On the other hand, if we can't all manage to read 
things closely enough to take advantage of that syntax and semantics, 
source routes are just so much more clutter.

>Network problems are many -- bad packet routing; one out of a collection
>of links in the network go down, and source route will help route around
>it
   Maybe in UUCP-land.  But, in the internet, source routes do nothing 
for bad packet routing or dead links, except possibly make those 
conditions worse by trying to force routes through bad paths.  For those 
readers not on the Internet or used to its structure, e-mail is normally
transmitted over virtual circuit connections between originating and 
target hosts.  There is no reason for intermediate target hosts, and 
store-and-forward activities (and packet routing) take place down in, 
roughly, the network layer, not in explicit "I give it to you, you give 
it to him, and he gives it to..." action between hosts.  Source routing 
forces applications-level store and forward as well as particular paths, 
and is, conceptually, a bad idea in the Internet.

>; bad UUCP Map stuff (this is not really relevant to Internet proper
>but serves as a good example).
  Actually it is a good example of why we shouldn't pretend that UUCP 
nodes are part of the Internet, shouldn't assign MX addresses to them, 
and should force use of various types of creativity in the local-part 
when mailing to them from the Internet.  I don't believe that either, 
but let's not confuse the issues.

>mist.aptos.ca.us	preference = 10, mail exchanger = SSYX.UCSC.EDU
>Mail to user@mist.aptos.ca.us gets sent to SSYX.UCSC.EDU.
   Yep, that is how it is supposed to work.

>When SSYX receives this piece of mail, it looks the address of this
>up in the UUCP Map pathalias output, finds this line:
>mist.aptos.ca.us splat!mist!%s
>and sends the mail off to UUCP host splat.
  I hope something like that happens.  However, as an Internet site, all 
I need or want to know is that SSYX.UCSC.EDU accepts mail for a host 
that I prefer to know (because it is MX-registered and, hence, a legal 
domain name) as "mist.aptos.ca.us".  If it has other identities or 
routes, I really don't want to know, and, if I do want to know, the 
issue does not involve source routes once the crossover into UUCP is 
made.  I think that is, more or less, the source of Rick's argument.

>Well, SSYX could just as easily have used source routing, converting
>mist.aptos.ca.us -> @splat.uucp:user@mist.aptos.ca.us
  Aha.  But here, SSYX is already in the business of being an 
Internet->UUCP gateway, not a forwarded/router.  As an Internet source 
route/address, @splat.uucp:user... is illegal, since "splat.uucp" is not 
a valid domain name.  If you folks want to make something like that work 
intra-UUCP, that would be dandy, but (a) it shouldn't appear on the 
Internet and (b) it is not an argument for or against Internet source 
routing.
>or even (preferably if the mailer could handle it)
>mist.aptos.ca.us -> @splat.aptos.ca.us:user@mist.aptos.ca.us
  This is conceivably a valid Internet address, but then Rick would 
claim that you would not need it, and I might agree.
> since @something1:something3@something2 is RFC822
>whereas something1!something2!something3 is not.
  Aha again.  something!something2!something3@foo is, however, valid 
RFC822.  You can put whatever you like into the local-part, as long as 
it looks like a "phrase".  If something3%something2%something is valid, 
than the bang-path is also.  The problem is that the Internet rules 
(including RFC822) gives @ absolute precedence, and what is on its right 
(a required domain name) is fundamentally different from what is on its 
left.

>I haven't studied RFC822 that much and often wonder how it is expected
>that @domain1,@domian2:mailbox@domain3
>is supposed to be distinguished from two distinct recipients
>(@domain1 and @domain2:mailbox@domain3)?  I can see that
>looking INTO the address @domain1 reveals a missing mailbox, ...
  *Flame on*  (abusive comments deleted).  Source-route syntax REQUIRES 
the mail address be in pointed brackets, i.e., you can say
   foo@bar   or      Joe Smith <foo@bar>
but, for source routes, you must say
   Joe Smith <@somewhere:foo@bar>
The "requirements for internet hosts" document proposes to make the 
above legal without the 'Joe Smith' part, but the brackets need to be 
there.  Now, by examination of your question, and reverse reasoning, you 
know why.  Please try to read and study the protocols before commenting 
on them or how they should be used.   *flame off*


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 14:16:41 EDT
Received: from SH.CS.NET by mintaka.lcs.mit.edu id aa26440; 28 Jun 89 14:09 EDT
To: Rick Adams <rick@uunet.uu.net>
cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com, 
    techies@sh.cs.net
Subject: Re: RFC-822 'phrase' question 
In-reply-to: Your message of Wed, 28 Jun 89 13:06:47 -0400.
             <8906281706.AA25873@uunet.uu.net> 
Date: Wed, 28 Jun 89 13:45:14 -0400
From: Daniel Long <long@sh.cs.net>
Message-ID:  <8906281409.aa26440@mintaka.lcs.mit.edu>

	Say, for example, I'm a csnet site and I send mail to user@site.oz.au

	csnet relay properly goes and finds the MX record that says ship it to
	uunet.

	uunet gets a RCTP TO: line that looks like:

		RCPT TO: <@uunet.uu.net:user@site.oz.au>

	I object to the gratuitious addition of the @uunet.uu.net.

Hmmm.  MMDF doesn't do that as a result of MX records.  For example, I just
sent a message to ladc.bull.com, which I know has an MX to UUNET.  This is the
SMTP dialog:

connecting to [192.48.96.2]... open.
<-(220 uunet.uu.net Sendmail 5.61/1.14 ready at Wed, 28 Jun 89 13:20:51 -0400)
->(HELO RELAY.CS.NET)
<-(250 uunet.uu.net Hello RELAY.CS.NET, pleased to meet you)
->(MAIL FROM:<long@RELAY.CS.NET>)
<-(250 <long@RELAY.CS.NET>... Sender ok)
->(RCPT TO:<foobar@ladc.bull.com>)
<-(250 <foobar@ladc.bull.com>... Recipient ok)
address ok
->(DATA)
<-(354 Enter mail, end with "." on a line by itself)
sending...:.. ->(.)
<-(250 Ok)
sent
->(QUIT)
<-(221 uunet.uu.net closing connection)

	There was also a truly horrible problem with routing for .NZ that
	I can't remember the exact nature of. We were getting things like:

		RCPT TO: <@uunet.uu.net:@vuwcomp.ac.nz:user@someothersite.ac.nz>

	and that totally fried things for us. (At the time the NZ mail
	was sent via uucp and internet source routes do not easily map
	into uucp addresses!)

(I imagine you meant there was a comma in the source route since MMDF doesn't
generate it the other way:

		RCPT TO: <@uunet.uu.net,@vuwcomp.ac.nz:user@someothersite.ac.nz>)

MMDF can generate the kind of RCPT TO you are complaining about, however.
This happens when a manual route is specified in the MMDF domain-mapping
table.  This might happen if, for example, relay.cs.net were the MX recipient
for all of .nz but needed to forward one specific host back to UUNET.  Of
course, this is better handled with an MX but I do recall cases where this
happened.

	All we really wanted (or needed) was:

		RCPT TO: <user@someothersite.ac.nz>

I agree that this would be preferable.  If, for some reason, an MX is not
appropriate, there is a way to achieve this (by creating a separate channel for
a specific destination such as uunet and listing those domains that should be
manually forwarded within that channel as opposed to via the normal SMTP
channel).  Is it hard to strip off your own name with Sendmail? (Just
curious--I'm not a Sendmail hacker.)  If so, I'll ask the relay staff to use
that method in the future.  Currently we don't have any such manual routes in
place to UUNET so if you are seeing this type of address arrive now, then
something else must be wrong and I'd be happy to try to track it down.  Let
me know.

Regards,
Dan

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 16:49:37 EDT
Received: from GAAK.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa14201;
          28 Jun 89 16:46 EDT
Received: by gaak.LCS.MIT.EDU 
	id AA04139; Wed, 28 Jun 89 16:44:53 EDT
Date: Wed, 28 Jun 89 16:44:53 EDT
Message-Id: <8906282044.AA04139@gaak.LCS.MIT.EDU>
To: KLENSIN@infoods.mit.edu
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: John C Klensin's message of Wed, 28 Jun 89 12:44:07 EDT <890628124407.00001139062@INFOODS.MIT.EDU>
Subject: Further use of source routing
From: "Michael A. Patton" <MAP@lcs.mit.edu>
Sender: map@gaak.lcs.mit.edu

   >Network problems are many -- bad packet routing; one out of a collection
   >of links in the network go down, and source route will help route around
   >it
      Maybe in UUCP-land.  But, in the internet, source routes do nothing 
   for bad packet routing or dead links, except possibly make those 
   conditions worse by trying to force routes through bad paths.  For those 
   readers not on the Internet or used to its structure, e-mail is normally
   transmitted over virtual circuit connections between originating and 
   target hosts.  There is no reason for intermediate target hosts, and 
   store-and-forward activities (and packet routing) take place down in, 
   roughly, the network layer, not in explicit "I give it to you, you give 
   it to him, and he gives it to..." action between hosts.  Source routing 
   forces applications-level store and forward as well as particular paths, 
   and is, conceptually, a bad idea in the Internet.

WRONG!  I frequently find as a network manager (and PostMaster) that I
need to make use of source routing of mail to get around network
problems in the Internet.  I discover a bunch of mail backed up in the
queues and upon investigation discover (or more likely deduce) that
some remote site has bad routing back to net 18 (that's us John :-).
Well, what should I do?  Obviously, I send mail to the responsible
person at that site, right?  Oops, that won't work because I can't get
an SMTP session open with no packets coming back.  The answer is, I
find a host we both CAN talk to and source route through it.  The mail
gets through, the other guy knows what I found from my end and away we
go.  If I'm really anxious, I can edit the control files for those
backed up messages and source route them, too.
----------------------------------------------------------------
Now to go back and add my two cents to the original discussion.  The
original question was not source routing or no source routing but a
question of the syntax and semantics to use for source routing.  All
of the methods talked about, the %-hack, foo!bar@mumble, and
@mumble:bar@foo, are ALL source routing.  Some kind of source routing
is definitely required today, and will probably always have a use
(well, maybe if absolutely nothing ever went wrong we wouldn't need
it, but ...  :-).  The real problem today is all the different
techniques and implementations which don't arrange to be
interoperable.  This is a hard problem to solve, you need to get
everyone to agree (and when everyone means every little UNIX box,
that's a hard task).

My comment on the forms to use are that only one of the three forms
mentioned above is truly unambiguous in ALL cases, but it's not
implemented at all in exactly those places where the others break
down.  Bangs are really bad.  The %-hack comes real close, but I have
seen it break.  The RFC822/823 source route is unambiguous, but
unfortunately suffers from OVER-specification (e.g. all names must be
registered).  The problem isn't to decide on "the one true mail
routing scheme", but rather to design schemes for each realm that are
complete, unambiguous and allow for arbitrary external connections
WITHIN the framework.  Then a gateway between two such realms can
uniquely and unambiguously translate addresses.

Further I expect that there is developing some problem in this
discussion because of people not making the distinction between
addressing and routing.  These really should be seperate, but most
existing specs/systems don't.  This happens in the real world, you use
the same address (from anywhere in the world) to reach me whether you
send by USPS, UPS, FedEx, or Joe's Courier Service, but these would
(probably) use dramatically different routing.  In fact it's
conceivable that Joe would actually put the message (with others) in a
package and send it via one of the other carriers to a friend in
Boston who would open this up and deliver it, this is source routing
done as it should be INSIDE the delivery system completely transparent
to the end user.  Note reletive to this discussion, in my original
example I am inside the system, I'm acting as PostMaster.

I think the development that can help us at this time is a "one true
addressing" scheme, and I think this IS starting to develop although a
little too slowly for my taste.  Then let the mail systems and/or
PostMasters have some kind of source routing for dealing with
intractable problems.  I note that this developing discussion is very
similar to the discussions of naming, addressing, and routing that
went on in the early days of IP concerning the lower layers.  I think
there is a lot to be learned from what went before (if you're
interested try RFC814, IEN179, IEN156, and others).

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 16:55:00 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa23119;
          28 Jun 89 16:50 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA18176; Wed, 28 Jun 89 16:46:03 -0400
Date: Wed, 28 Jun 89 16:46:03 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8906282046.AA18176@uunet.uu.net>
To: ARIEL@en-c06.prime.com
Subject: Re: RFC-822 'phrase' question
Cc: header-people@mc.lcs.mit.edu, long@sh.cs.net

I always object to redundancy and unnecessary crap.

Thats why I started this whole discussion about rfc822 source
routing being unnecessary.

When you start to pass 30,000 messages per day, the time wasted
on extraneous header parsing is real.

Would you object if I routed all uunet mail through your system?
I can format the headers so that the addresses are legal and get
delivered to the correct destination address.

If your mailer can't handle it, its broken. If it can handle it,
why do you care? (Oh you dont have unlimited computing resources
to waste? Gee, what a cooincidence)


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 19:54:44 EDT
Received: from arpa.att.com by mintaka.lcs.mit.edu id aa24273;
          28 Jun 89 19:47 EDT
From: smb@ulysses.att.com
Date: Wed, 28 Jun 89 18:29:12 EDT
Message-Id: <8906282229.AA00384@hector.homer.nj.att.com>
Received: by hector.homer.nj.att.com id AA00384; Wed, 28 Jun 89 18:29:13 EDT
To: John C Klensin <KLENSIN@infoods.mit.edu>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: Brad Allen's comments on Rick's comments on source routes 

	    Maybe in UUCP-land.  But, in the internet, source routes do nothing 
	 for bad packet routing or dead links, except possibly make those 
	 conditions worse by trying to force routes through bad paths.  For those
	 readers not on the Internet or used to its structure, e-mail is normally
	 transmitted over virtual circuit connections between originating and 
	 target hosts.  There is no reason for intermediate target hosts, and 
	 store-and-forward activities (and packet routing) take place down in, 
	 roughly, the network layer, not in explicit "I give it to you, you give 
	 it to him, and he gives it to..." action between hosts.  Source routing 
	 forces applications-level store and forward as well as particular paths,
	 and is, conceptually, a bad idea in the Internet.

Unfortunately, while this has been true, it is becoming less and less
so.  The point was made repeatedly at the INARC workshop that universal
interconnectivity on the Internet no longer exists, and cannot be presumed
to exist in the immediate future.  What with the demise of the ARPANET,
there is no central routing core.  Things are usually functioning reasonably
well, but not always.  And when policy routing comes about, matters may
get worse.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 00:59:50 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07794;
          29 Jun 89 0:58 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12883@BLOOM-BEACON.MIT.EDU>; Thu, 29 Jun 89 00:37:32 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Jun 89 04:26:02 GMT
From: Dan Heller <pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu>
Organization: University of California, Berkeley
Subject: Re: "Status" header
Message-Id: <15051@pasteur.Berkeley.EDU>
References: <1322@uceng.UC.EDU>, <KARL.89Jun28095245@giza.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In reponse to someone's question about what the Status: header is for,
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes:

> That's being done by Berkeley Mail.  If you have source, see
> ucb/Mail/send.c.  Gross.  Pick another MUA.

This header is modified by Mail (or sokme UA) to remember that the
message has been Read, Unread-but-old, or other information about
the message.

Karl feels that this is "gross".  I'd love to hear suggestions about
how to retain the "status" of a message without losing "state" and
not storing the information in the actual message.  The status header
is common among most Mail-based UA's (I don't know about MH).

The "state" I was referring to is the state of integrity that the
information about the message remains accurate even tho there may
be different users/processes accessing the same file.  The state
isn't completely conserved, but it is much more efficient than
using a separate state file.  I don't know how MH manages to remember
the status of messages if it doesn't store such information in the
message (file) itself.

I am guessing that Karl is using MH or something other than Mail, Elm
or Mush.  So, Karl, I ask how one would save the fact that a message
has been saved, printed, forwarded, read/unread, replied-to... Mush
uses the status: header to save all this information about each message.
Dan Heller	<island!argv@sun.com>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 08:03:57 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20288;
          29 Jun 89 7:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19140@BLOOM-BEACON.MIT.EDU>; Thu, 29 Jun 89 07:37:54 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Jun 89 05:19:23 GMT
From: Bill Wisner <mica.berkeley.edu!wisner@ucbvax.berkeley.edu>
Organization: Verrifast Plaine Co Ltd
Subject: Re: "Status" header
Message-Id: <WISNER.89Jun28221923@anableps.berkeley.edu>
References: <1322@uceng.UC.EDU>, <KARL.89Jun28095245@giza.cis.ohio-state.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

MH can be instructed to keep track of messages that have not been seen by
putting them into an "unseen" sequence. It never touches the actual messages
to do this.

MH can also be instructed to keep track of when a message is replied,
forwarded, or whatever. It does not use the utterly bogus and highly ugly
Status: header. It inserts two header lines at the very top of the message
(thus making them very easy to edit out) along the lines of:

Replied: Tue, 27 Jun 89 12:59:17 PDT
Replied: Martin Hanley <praxis!mph@uunet.UU.NET>

(Look, Martin! Your name in lights!)

Note that MH does none of these things unless explicitly told to.

w

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 10:45:10 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa11648;
          29 Jun 89 10:42 EDT
Received: by INFOODS id <00001022064@INFOODS.MIT.EDU> ;
       Thu, 29 Jun 89 10:34:40 EDT
Date: Thu, 29 Jun 89 10:24:45 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  Re: "Status" header
To: Dan Heller <pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu>
X-VMS-Mail-To: EXOS%"Dan Heller <pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu>"
Message-ID: <890629102445.00001022064@INFOODS.MIT.EDU>
cc: header-people <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>

Dan,
  I'm not sure you really want the answer, but...

  You organize your mail system so that you store envelope information 
and message information separately.  You might even separate message 
header information from message information with appropriate data 
structuring.  You might consider status-of-reading information to be 
part of the (stored, and highly canonicalized) envelope information.  
And you might canonicalize the required/important header fields, too.  
  Once you get the envelope and selected header fields stored into a 
canonical form (read "a 'binary' data-structure" if you like), then you 
can put status flags, or whatever, anywhere there and, in no case, does 
it become part of the message.
  Now, how this is displayed to the user is a slightly different issue: 
the most convenient approach might be to have it appear as if it were a 
header field (although some BITNET systems show envelope information as
a *footer* field). 
  Logically separating envelope, header, and message provides an 
additional useful capability, which is that, on a system with any sort 
of security or access-restriction provisions, you can arrange different 
levels thereof and, in particular, give a "postmaster" sufficient access 
to alter envelopes and return or reroute mail, without giving him or her 
sufficient access to read message text, even by accident.  That is a 
nice feature, if you think about it.

New idea?  Nope, something that Multics has done for years.  And not 
something that I had anything to do with inventing, although I wish I 
had.
   John Klensin, MIT
   Klensin@INFOODS.MIT.EDU


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:34:55 EDT
Received: from cory.Berkeley.EDU by mintaka.lcs.mit.edu id aa26233;
          29 Jun 89 23:32 EDT
Received: by cory.Berkeley.EDU (5.59/1.28)
	id AA19957; Thu, 29 Jun 89 20:31:17 PDT
Message-Id: <8906300331.AA19957@cory.Berkeley.EDU>
From: Dan Heller <dheller@cory.berkeley.edu>
Date: Thu, 29 Jun 89 20:31:14 PDT
In-Reply-To: John C Klensin's 48-line message on Jun 29, 10:24am
Phones: Home: (415) 479-4838 Work: 491-1000
X-Mailer: Mail User's Shell (6.5.4 6/12/89)
To: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  Re: "Status" header
Cc: header-people <header-people@mc.lcs.mit.edu>, 
    Bart Schaefer <schaefer@cse.ogc.edu>

I'm including Bart on the Cc list so I'm going to include your whole message..

> On Jun 29, 10:24am, John C Klensin said this about:
> "RE:  Re: "Status" header"
> 
> Dan,
>   I'm not sure you really want the answer, but...
> 
>   You organize your mail system so that you store envelope information 
> and message information separately.  You might even separate message 
> header information from message information with appropriate data 
> structuring.  You might consider status-of-reading information to be 
> part of the (stored, and highly canonicalized) envelope information.  
> And you might canonicalize the required/important header fields, too.  
>   Once you get the envelope and selected header fields stored into a 
> canonical form (read "a 'binary' data-structure" if you like), then you 
> can put status flags, or whatever, anywhere there and, in no case, does 
> it become part of the message.
>   Now, how this is displayed to the user is a slightly different issue: 
> the most convenient approach might be to have it appear as if it were a 
> header field (although some BITNET systems show envelope information as
> a *footer* field). 
>   Logically separating envelope, header, and message provides an 
> additional useful capability, which is that, on a system with any sort 
> of security or access-restriction provisions, you can arrange different 
> levels thereof and, in particular, give a "postmaster" sufficient access 
> to alter envelopes and return or reroute mail, without giving him or her 
> sufficient access to read message text, even by accident.  That is a 
> nice feature, if you think about it.
> 
> New idea?  Nope, something that Multics has done for years.  And not 
> something that I had anything to do with inventing, although I wish I 
> had.
>    John Klensin, MIT
>    Klensin@INFOODS.MIT.EDU

Basically, I disagree with this method for several reasons --
In no particular order...

Portability.  "Binary" format is really a bad idea because different
computers store binary data differently.  In a heterogeneous environment
where several architectures share the same "data" filesystems (such as
/usr/spool/mail or home directories, for example) then any data stored
in a binary format will be sure to fail if the same program compiled for
a different architecture were to read/write it.  I first encountered
this problem at Island (where I work) where we used to store desk top
publishing data files in pseudo-binary format.

Once you split the message headers from the text of the message, you
have completely eliminated any chance for the message to be either
read or "maintained" by any other program.  One thing people like to
do is have the option to use different programs for their data.  I like
the fact that I can use "vi" on files and my co-workers can use "emacs"
to edit the same files.  Since the office place today uses email as its
primary source of communication between workers (the larger the company,
the more apparent this is), having common places where mail messages are
stored and read by many users is a luxury people have come to appreciate.
Having a mail UA do with messages as you described means that users now
only have one program they can use to read their mail.  If I want to move
my mail around, I have to be sure to bring the whole thing with me wherever
I go -- moving folders becomes a royal pain.

The reason that this method works for mail *delivery* schemes (such as
uucp, sendmail, etc..) is because thiere *is* one program and one program
only on the system to handle this level of message storage.  It need not
be interactive with the user and it doesn't worry about interferring with
anyone else.  In this case, your "postmaster" can still handle everything
correctly.


					--dan

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 10:58:14 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa02536;
          30 Jun 89 10:52 EDT
Received: by INFOODS id <00001271062@INFOODS.MIT.EDU> ;
       Fri, 30 Jun 89 10:47:06 EDT
Date: Fri, 30 Jun 89 09:34:57 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Dan Heller's long reply to my longer message about Status fields
To: Header People List <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>
X-VMS-Mail-To: EXOS%"Header People List <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>"
Message-ID: <890630093457.00001271062@INFOODS.MIT.EDU>

Dan,
  I agree with your initial assumptions about what is desirable, but
disagree profoundly with the reasoning, final conclusion, and some of
the associated inferences.  Because it may be of general interest
(although I doubt it), let me identify where I think we disagree and 
why.  Then, since this discussion is not really about headers, and 
because I don't have time, let's drop it or take it offline.

1) The Multics environment, for better or worse, was motivated in part 
by some real security/privacy concerns, and keeping users (even 
"postmaster" users and "super" users) out of each other's mail is 
considered desirable (to say the least).  One can disagree or agree with 
that philosophy, but agreeing makes putting up with some slight 
inconvenience desirable.  This is not, to any degree the only argument 
here, just something that colors the others a bit.

>Portability.  "Binary" format is really a bad idea because different
>computers store binary data differently.  In a heterogeneous environment
>where several architectures share the same "data" filesystems (such as
>/usr/spool/mail or home directories, for example) then any data stored
>in a binary format will be sure to fail if the same program compiled for
>a different architecture were to read/write it.  I first encountered
>this problem at Island (where I work) where we used to store desk top
>publishing data files in pseudo-binary format.
   Either I was not sufficiently clear about the requirement/strategy 
(which is probably) or your argument is a red herring (which is also 
possible).  The reason why I put "binary" in quotes was to avoid the 
problems you identify here.  What I might, equivalently, have said was 
"carefully structured format".  If that format needs to be 
machine-independent, there is no problem with that.  It probably does 
not, for the reasons discussed below.  And there is no problem with 
*code* portability, again for the reasons discussed below.

>Once you split the message headers from the text of the message, you
>have completely eliminated any chance for the message to be either
>read or "maintained" by any other program.  One thing people like to
>do is have the option to use different programs for their data.  I like
>the fact that I can use "vi" on files and my co-workers can use "emacs"
>to edit the same files.
  On the other hand, data-[structure-]hiding and a certain amount of 
functional isolation are fundamental principles in software engineering 
today, and for good reasons.  There is a wrong way to do this, and that 
wrong way is what you, apparently, assume.  For example, in VMS, the 
internal formats of mail are "proprietary", and may change from one 
operating system release to the next.  People who wish to manipulate
mail with private tools have to decode the format, and then be prepared 
to decode again with each system change.  There are many terms to 
describe that strategy, let me try "plain dumb" for public circulation.
  But let's assume that you equip the mail system, as Multics has, not 
only with an internal mechanism for storing mail-objects, but with 
a full set of proper subroutines and functions for accessing and
manipulating those objects.   And let's further assume that you 
guarantee those interfaces across not only operating system releases, 
but across different mail processing mechanisms.  If your abstractions 
are right, you can switch from RFC733 to RFC821, or from SMTP to X.400 
without any change to user-level mail processing programs: the user code 
continues to "see" the same abstractions.

>Having a mail UA do with messages as you described means that users now
>only have one program they can use to read their mail. 
  Just not true.  Mail-reading programs only have to use the proper 
system primitives for accessing messages and queues.  And 
message-accessing gets you back one or more structured objects.  We had 
several mail-reading programs on Multics, only one or two of which were 
system supplied, and they couldn't do anything the others couldn't do, 
since they were constrained to use the same mechanisms.  Note that, on 
Multics, the fact that mail objects are inner-ring objects makes the 
object-hiding mechanisms and functions non-bypassable.  By anything.

> If I want to move my mail around, I have to be sure to bring the whole
>thing with me wherever I go -- moving folders becomes a royal pain. 
   Nope.  If this is a socially desirable activity, then the right 
primitives can be defined.  Since I don't know what would be meant by 
"move my mail around" or "move folders" in a protected mail environment 
abstracted from U**X, I can't comment on its social desirability.  But 
having a user-level program to which you can say "take everything of the 
following description and forward it over there" is very easy.  Multics 
has the facility built into one of the system-provided user-level mail 
reading commands.

>The reason that this method works for mail *delivery* schemes (such as
>uucp, sendmail, etc..) is because thiere *is* one program and one program
>only on the system to handle this level of message storage.  It need not
>be interactive with the user and it doesn't worry about interferring with
>anyone else.
  Yeah.  And in the Multics model, the "user" can't mess with the 
programs or their mechanisms, and the postmaster can be somewhat 
constrained if that is desirable.  For emergencies, adequate access to 
fuss with the queues and objects themselves can be available, but that 
is not needed for "ordinary" postmaster functions, e.g., mail re-routing 
and address correction, and, possibly, should not be available.

>  In this case, your "postmaster" can still handle everything
>correctly.
   Ah, but, if a postmaster is accused of tampering with the content of 
someone else's mail, she or he has no systems defense.  In the Multics 
model, the postmaster *cannot* access the mail text.

The object-hiding of the Multics model also permits some other functions
in the validation and authentication area that are important or useful 
in some contexts.  For example, if I get a message from Doe and 
forward it to Jones, Jones would really like to know that what I've 
claimed Doe said is what Doe said.  In the postal mail system, I do this 
best by putting Doe's original message, complete with unopened envelope, 
in another envelope, possibly with my cover note and sending it on.  The
second-best involves forwarding Doe's orginal letter, in his
handwriting, with my cover note in the same envelope.  Ever wonder, when 
something says "original message follows", or ">", if that is *really* 
the original text?  Well, with the Multics UA (which is not the 
user-level mail reading/writing program but down with the data-hiding
primitives) when I instruct the system to "forward" a message, I don't 
have access to modify its text, and the system guarantees authenticity.  
If I want to annotate a message, as I am doing with yours, I make a 
system call that transfers a canonicalized copy of it to me in an ASCII 
form that resembles what you think of as RFC822, I edit it to my heart's 
content with the editor of my choice, and I then tell the system where 
to send it as a *new* or *altered* message.  But then it is isn't 
authenticated forwarding any more.
  The system can also provide you the ability to delete a message you 
have sent to me, but without letting you look at messages others have 
sent.  Or can enforce a "delete only if not inspected" rule.  In both 
cases, these functions are accessed by calls to the object primitives 
from applications code.  And, because it can keep records of what calls 
were made, the system can *know*, not rely on applications to tell the 
truth.

Summary: The following are GOOD THINGS
 - being able to formulate and manipulate mail using tools of the user's 
choice, with a variety of such tools coexisting.
 - providing a high degree of data structure isolation and hiding for 
data in the formats received over the various networks so that the user 
abstraction of what mail looks like is independent of the formats and 
protocol requirements of multiple networks.  Such hiding can also 
provide different mail abstractions to different users and programs: as 
things evolve, newer programs can use newer interfaces that deliver more 
or different information; older programs can continue to use older 
interfaces which, while less informative, keep those programs working.
 - system management of mail-objects, accessed through data-hiding 
functions, permits system responsibility for authentication and the 
maintenance of flags in an fashion independent of end-user application 
software.  This means, among other things, that if you can convince the 
system that status flags should be part of the mail-object, then all 
user-level software can manipulate those flags without knowledge of each 
other.  On the other hand, if you cannot, or, more generally, want to 
maintain a different mail-management abstraction, *your* software can 
maintain its own tables that map your abstraction into system mail 
identifiers.

This approach has two known major drawbacks:
 (1) Someone has to make a serious investment in the design of the
abstractions that user codes will see and the functions used to access 
them.  Design of the [hidden] mail objects themselves is less important, 
since they can be changed without user-level code noticing.  See any 
OOP paper for a more elaborate form of this principle.  But the 
investment is serious, taking implementation of a mail system out of the 
scale of an afternoon exercise.
  I've seen some "afternoon exercises", and prefer the serious design 
efforts (e.g., sendmail, etc.), but I suppose this is a matter of taste.
  (2) Because the management of real (e.g., RFC822) headers, as distinct 
from their abstractions, is part of the mail-object, a high degree of 
header integrity and validation can be guaranteed.  User-supplied codes
cannot include "Longitude" or "Grandfathers-birth-date" headers in 
messages because there is no way to pass that information through the 
abstractions into the mail objects.  Seems to me that this is an asset, 
but I'm a known fuddy-duddy who hates seeing messages cluttered with 
non-standard, cutsy, header fields.
    john


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 17:32:29 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07093;
          30 Jun 89 17:29 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03186@BLOOM-BEACON.MIT.EDU>; Fri, 30 Jun 89 17:19:04 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 30 Jun 89 18:07:08 GMT
From: "gregg.g.wonderly" <att!cbnewsc!gregg@bloom-beacon.mit.edu>
Organization: AT&T Bell Laboratories
Subject: MH verses the "all in one file" MUAs
Message-Id: <1508@cbnewsc.ATT.COM>
References: <WISNER.89Jun28221923@anableps.berkeley.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

From article <WISNER.89Jun28221923@anableps.berkeley.edu>, by wisner@mica.Berkeley.EDU (Bill Wisner):
> MH can be instructed to keep track of messages that have not been seen by
> putting them into an "unseen" sequence. It never touches the actual messages
> to do this.
>
> ...
> 
> Note that MH does none of these things unless explicitly told to.

And most of us use the appropriate MHL formats and filters to have them
stripped later.  Note that MHs repl(1) command (for replying to a message)
will allow you to reply multiple times.  The Replied headers are stripped
from the resulting message by the time you see it in the editor to add
your reply.

Just a note...  It has been said many times before...  Those who ignore
the past are doomed to repeat it in the future.  In other words, those
people who continue to implement MUAs that use a single file for
storing all messages seem to continue to replicate all the things that
we hate about those programs.

MH is so elegant and flexible.  It pains me to see all the work people
are doing just to duplicate what has already been done.

-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)
-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 20:30:29 EDT
Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa05830;
          30 Jun 89 20:28 EDT
Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu
	(5.61/UW-NDC Revision: 1.108 ) id AA15121; Fri, 30 Jun 89 17:27:55 -0700
Date: Fri, 30 Jun 1989 16:50:19 PDT
From: Mark Crispin <MRC@cac.washington.edu>
Sender: mrc@tomobiki-cho.cac.washington.edu
Subject: Re: "Status" header
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <15051@pasteur.Berkeley.EDU>
Message-Id: <MailManager.615253819.899.mrc@Tomobiki-Cho.CAC.Washington.EDU>

     The grossness is in the entire format of /usr/spool/mail.  Not all Unix-
based mail readers use /usr/spool/mail format.  MM and the IMAP server use
"mtxt" format, basically a clone of the TOPS-20 MAIL.TXT format.  mtxt format
has an exact byte count of the message (no need to insert ">" in front of lines
that accidentally being with the word "from"), a message write date, and a field
of flags (36 in all - surprise!).

     There are other schemes as well.  It just requires breaking away from a
format of mail that should have been considered obsolete 10 years ago.  mtxt
format is certainly not the most wonderful ever invented, but it is much better
than /usr/spool/mail format.

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 05:35:14 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02921;
          1 Jul 89 5:30 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15874@BLOOM-BEACON.MIT.EDU>; Sat, 1 Jul 89 05:26:52 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Jul 89 03:38:39 GMT
From: Dan Heller <eureka!argv@sun.com>
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <113463@sun.Eng.Sun.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I meant to proofread this, but apparently, I missed something...

>   If you think that
> MH's "features" are a result of the fact that it's folder storage method
> is attributed to the fact that it stored messages on a file-per-message
> format, you are mistaken.

I meant to say :

If you think that MH's great features is attributable to its method
for folder storage, you are mistaken.  My intent was to point out the
fact that a good UA should do the "right thing" regardless of how that
UA stores its messages.  Two "correct" UAs --each which stores files
using the Mail and the MH method-- should do the same thing when it
comes to replies, etc...

dan <island!argv@cad.berkeley.edu>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 05:35:23 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02932;
          1 Jul 89 5:30 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15855@BLOOM-BEACON.MIT.EDU>; Sat, 1 Jul 89 05:25:40 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Jul 89 03:31:33 GMT
From: Dan Heller <eureka!argv@sun.com>
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <113461@sun.Eng.Sun.COM>
References: <WISNER.89Jun28221923@anableps.berkeley.edu>, <1508@cbnewsc.ATT.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:
> From article by wisner@mica.Berkeley.EDU (Bill Wisner):
> > MH can be instructed to keep track of messages that have not been seen by
> > putting them into an "unseen" sequence. It never touches the actual messages
> > to do this.
> > Note that MH does none of these things unless explicitly told to.
> 
> And most of us use the appropriate MHL formats and filters to have them
> stripped later.  Note that MHs repl(1) command (for replying to a message)
> will allow you to reply multiple times.  The Replied headers are stripped
> from the resulting message by the time you see it in the editor to add
> your reply.

No one said MH was stupid.  There -are- other stupid UA's out there that
don't do the right thing (what you described is the right thing).  But,
that has nothing to do at all with how a mail folder is stored.  It is
incorrect to make the following statement:

> people who continue to implement MUAs that use a single file for
> storing all messages seem to continue to replicate all the things that
> we hate about those programs.

The reason this is incorrect is because your assumption is that it is
the single-file-folder "feature" that makes the program "bad."
A well written/designed UA should [try to] make it as transparent as
possible about the method for how mail is stored.  You are making a
grave mistake by attributing the storage method utilized by a UA to the
bugs or implementation (design) features of that UA.  If you think that
MH's "features" are a result of the fact that it's folder storage method
is attributed to the fact that it stored messages on a file-per-message
format, you are mistaken.

Believe it or not, I don't advocate using the folder-in-a-file method
any more than MH's method; there are good reasons for doing it both ways.
I hesitate to start yet another religious war about whether or not the
Mail-method or the MH-method is better, but I almost feel compelled to
do so anyway because of the misconceptions about UA's as described in
the previous text above.  If the time has come yet again to resurrect
the war on MH vs. Mail folder formats, let's have it.  I'm prepared.

I'm always looking for good suggestions for improving mush (oh, if I
only had the time), and in fact Bart and I have a long list of things
to do for the future if the future ever arrives.  We're all working
together on this; I don't feel as if I'm competing with MH.

> gregg.g.wonderly@att.com   (AT&T bell laboratories)
dan <island!argv@cad.berkeley.edu>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 21:52:14 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa09775;
          1 Jul 89 21:51 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8635; Sat, 01 Jul 89 21:50:48 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 9753; Sat, 01 Jul 89 21:50:47 EDT
Date:    Sat, 01 Jul 89 18:48 PDT
To:      header-people <header-people@mc.lcs.mit.edu>
From:    Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Subject: Re: "Status" header
Message-ID:  <8907012151.aa09775@mintaka.lcs.mit.edu>

There isn't really anything wrong with a UA adding its own header
lines to save info.  What *is* wrong is that UA not removing those
added lines when forwarding mail.  Of course, one obvious problem is
what happens when it's forwarded with a different UA that doesn't know
about those headers?  Then the USER should edit the message and delete
the garbage.  Not doing so is tacky.  Why is this the user's
responsibility in this case?  Well, he's the one using 2 different,
incompatible UAs.

Lessee now... Header-People discusses headers.  Ok, anyone want to
propose adding a new field to the standard, to allow UAs to store info
there?  The definition should include a rule that a UA make that line
disappear when the message is forwarded, etc.  Can there be a generic
header line defined?
   X-UA-uaxxx:  info for ua xxx
   X-UA-uayyy:  info for ua yyy
Of course, realistically, we all know by now that it's essentially
impossible to get new headers defined and even harder to get them
widely implemented.  Another sigh.

/Leonard

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 23:34:02 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10447;
          1 Jul 89 23:29 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05041@BLOOM-BEACON.MIT.EDU>; Sat, 1 Jul 89 23:18:16 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Jul 89 03:13:25 GMT
From: Christopher Davis <bucsb!ckd@bu-cs.bu.edu>
Organization: Boston University School of Management
Subject: Re: What *should* an MUA do? (was MH verses the "all in one file" MUAs)
Message-Id: <2730@bucsb.UUCP>
References: <113463@sun.Eng.Sun.COM>, <2729@bucsb.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


OOOOOOOOOOOoooooooooooops!

I mucked up the followup-to line in that last.  Followups should go to
comp.mail.misc (or to me if you think it's not something worthy/appropriate
for comp.mail.misc).

--ckd
-- 
  /\  | /  |\  @bu-pub.bu.edu <preferred>  | Christopher K. Davis, BU SMG '90
 /    |/   | \ %bu-pub.bu.edu@bu-it.bu.edu |      uses standardDisclaimer;
 \    |\   | /  <for stupid sendmails>     |       BITNET: smghy6c@buacca 
  \/  | \  |/  @bucsb.UUCP <last resort>  or ...!bu-cs!bucsb!ckd if you gotta.
 --"Ignore the man behind the curtain and the address in the header." --ckd--

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 23:34:10 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10449;
          1 Jul 89 23:29 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA04979@BLOOM-BEACON.MIT.EDU>; Sat, 1 Jul 89 23:13:28 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Jul 89 03:10:58 GMT
From: Christopher Davis <bucsb!ckd@bu-cs.bu.edu>
Organization: Boston University School of Management
Subject: What *should* an MUA do? (was MH verses the "all in one file" MUAs)
Message-Id: <2729@bucsb.UUCP>
References: <113463@sun.Eng.Sun.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <113463@sun.Eng.Sun.COM> argv%eureka@Sun.COM (Dan Heller) writes:
- [...]  My intent was to point out the
- fact that a good UA should do the "right thing" regardless of how that
- UA stores its messages.  Two "correct" UAs --each which stores files
- using the Mail and the MH method-- should do the same thing when it
- comes to replies, etc...

I'm going to go *way* off on a tangent here...

I'm working on (well, writing specs for, at the moment) an MUA for our
Incredibly Big Machine.  I'm interested in finding out what people feel
the "right thing" is for replies (as here) or other aspects of an MUA.

Limitations of the thing:  it will be written in REXX and use XEDIT.
It's *not* a CMS site, so I don't know at present what limitations that
interface will have (if they're really bad the whole project will just
go down the tubes).  The programming team is completely unofficial and
is a management undergrad in Boston and an engineering student in NJ.
[If any of you think we can even get this thing DONE based on all that,
let us know what you think... :-]

Pie in the sky "this is what I'd really like if you could ever do it"
comments will be always accepted, occasionally implemented, definitely
appreciated.  Ye Olde Hacker Spirit and all that.

Followups to comp.mail.misc which I think is the best place to go...

Oh, and no flames, please?  I want suggestions, not "my MUA is better than
yours, my way is better than yours, etc."  "My MUA does this and I like it"
is more the sort of thing I'm looking for.

--ckd
-- 
  /\  | /  |\  @bu-pub.bu.edu <preferred>  | Christopher K. Davis, BU SMG '90
 /    |/   | \ %bu-pub.bu.edu@bu-it.bu.edu |      uses standardDisclaimer;
 \    |\   | /  <for stupid sendmails>     |       BITNET: smghy6c@buacca 
  \/  | \  |/  @bucsb.UUCP <last resort>  or ...!bu-cs!bucsb!ckd if you gotta.
 --"Ignore the man behind the curtain and the address in the header." --ckd--

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Jul 89 21:03:32 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19535;
          2 Jul 89 20:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA26201@BLOOM-BEACON.MIT.EDU>; Sun, 2 Jul 89 20:46:02 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Jul 89 22:41:19 GMT
From: "gregg.g.wonderly" <att!cbnewsc!gregg@bloom-beacon.mit.edu>
Organization: AT&T Bell Laboratories
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <1518@cbnewsc.ATT.COM>
References: <113461@sun.Eng.Sun.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller):
> In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:
>> 
>> And most of us use the appropriate MHL formats and filters to have them
>> stripped later.  Note that MHs repl(1) command (for replying to a message)
>> will allow you to reply multiple times.  The Replied headers are stripped
>> from the resulting message by the time you see it in the editor to add
>> your reply.
> 
> No one said MH was stupid.  There -are- other stupid UA's out there that
> don't do the right thing (what you described is the right thing).  But,
> that has nothing to do at all with how a mail folder is stored.  It is
> incorrect to make the following statement:
> 
>> people who continue to implement MUAs that use a single file for
>> storing all messages seem to continue to replicate all the things that

note that I said SEEM...^^^^

>> we hate about those programs.
> 
> The reason this is incorrect is because your assumption is that it is
> the single-file-folder "feature" that makes the program "bad."
> A well written/designed UA should [try to] make it as transparent as
> possible about the method for how mail is stored.  You are making a
> grave mistake by attributing the storage method utilized by a UA to the
> bugs or implementation (design) features of that UA.  If you think that
> MH's "features" are a result of the fact that it's folder storage method
> is attributed to the fact that it stored messages on a file-per-message
> format, you are mistaken.

I did not say anything about the merits of either method.  What I said
was that I have yet to see a "all messages in the same file" UA that
does anything but what the others from the past do.  People are
spending a lot of time reproducing PD replacements for MUAs that don't
do anything really that different and useful.

> Believe it or not, I don't advocate using the folder-in-a-file method
> any more than MH's method; there are good reasons for doing it both ways.
> I hesitate to start yet another religious war about whether or not the
> Mail-method or the MH-method is better, but I almost feel compelled to
> do so anyway because of the misconceptions about UA's as described in
> the previous text above.  If the time has come yet again to resurrect
> the war on MH vs. Mail folder formats, let's have it.  I'm prepared.

> I'm always looking for good suggestions for improving mush (oh, if I
> only had the time), and in fact Bart and I have a long list of things
> to do for the future if the future ever arrives.  We're all working
> together on this; I don't feel as if I'm competing with MH.

Okay, here's some questions to think about.  What does
mush/elm/mail/whatever not do that MH already does?  How much effort will
it take to add those features (if they are desireable)?  By the time
you have done that, what will have been added to MH that the other MUAs
then won't have?

I don't mean to start any wars on MUAs.  I am just trying to see if the
individuals doing the work are thinking about were they are going.  It
is a real waste of talent to continually play catchup, always adding the
feature that you don't have yet.

I had a personal reply from my original article that stated this

>And MH is huge, and chews up disk space and inodes, and hard to learn, and
>slow to use.

There are several parts to this statement that should be thought about.
MH is VERY large in source and executables.  Mostly because it has a lot of
duplicated code to provide the shell parameter parsing for each command,
plus the copy of the libraries that rides with each executable (50 some odd
executables exist).  That, I cannot dispute.  However, I take up the argument
that this is not a problem, but rather a feature.  If you have ever written
an MH tool (I have written 4 to date), then you know how powerful and easy
to use the library routines are.

The INODE issue is a UN*X deficency, not am MH issue.

Hard to learn is a perception, not a fact.  Most people that I have introduced
a tool to tell me it is easy when they have some experience with something
similiar.  MH is not like any other MUA that I am familiar with (I have
exclusivly used MH for 5 years, so that leaves me mostly biased, although I
have had the necessity to use others from time to time).  However, much of
MH's perceived difficulty is do to lack of coherent documentation.  There
are not any manual pages which provide a nice tutorial on where to start
with MH, so the user is stuck with the command manual pages.  Putting this
aside, if you can type the strings

inc
scan unseen (or scan unread)
show
rmm
refile

you can use MH without any real difficulty.

Now for the 'slow to use' part.  The fact of the matter is that most people
using MH at universities are not going to have high speed CPUs.  MH's
executables average about 200-300K here, and I imagine they are similar
in size elsewhere.  This being the case, MH can be slow on a machine with
limited resources.  But so is every other largish program I have seen.
Very few features of a program come free.  There are design issues that
can govern the relative order of complexity of an operation based on the
underlying algorithym.  I don't think that MH is perfect, there are a
lont of linear algorithyms in it.  The point is that certain things cost
compute time.  Some features of programs can be added in such a way that
they always impact the application, even when the feature is not being
used.  The converse is also true (MH has such features like the 'previous'
profile component).

Give MH a try.  If you hate it, throw it away (or even burn the tape in
effigy).  But at least try it.  MUAs are really a religous issue, so I will
not press any harder.  I just needed to make some arguments against some
of the bad things that people are saying about MH.

-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)
-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 03:18:56 EDT
Received: from cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa22346; 3 Jul 89 3:16 EDT
To: Daniel Long <long@sh.cs.net>
cc: Rick Adams <rick@uunet.uu.net>, eric@icsib.berkeley.edu, 
    header-people@mc.lcs.mit.edu, wunder@sde.hp.com, techies@sh.cs.net
Subject: Re: RFC-822 'phrase' question 
Phone: +44-1-380-7294
In-reply-to: Your message of Wed, 28 Jun 89 13:45:14 -0400.
             <8906281409.aa26440@mintaka.lcs.mit.edu> 
Date: Mon, 03 Jul 89 08:10:58 +0100
Message-ID: <653.615453058@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@cs.ucl.ac.uk>
Source-Info:  lion.cs.ucl.ac.uk


Rick et al,


 >		RCPT TO: <@uunet.uu.net:user@site.oz.au>

 >	I object to the gratuitious addition of the @uunet.uu.net.

Nonsense.  This is doing exactly what SMTP recommends.  (P 14. RFC 821,
"...the first host in the forward-path should be the host receiving the SMTP
commands").   

I would also argue that this is good protocol design - verification of who
you are talking to explictly.  


Steve

------- End of Forwarded Message


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 04:32:28 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23071;
          3 Jul 89 4:29 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA02960@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 04:07:07 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 04:27:48 GMT
From: Dan Heller <eureka!argv@sun.com>
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <113567@sun.Eng.Sun.COM>
References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I am moving this discussion to comp.mail.misc because it doesn't have
anything to do with headers anymore.

The reason this all started was that someone took notice of the Status:
header present in Mail-based MUA's.  Mail, Elm (I guess), Mush, mailx, ...
all do this: use the Status: header to save information about whether the
message is new, unread..  Mush also uses the status header to store info
about whether the message has been saved, replied to, and so on.

Greg points out that MH saves this info as well, but not in a header
which is visible to the user -- MH apparently filters this information
out when the message is displayed.  The first part of this message contains
the preliminary discussion between us.  The latter part of the message
actually discusses the drawbacks of MH and a few comments about Mush.

People who are interested in continuing a discussion about good MUA
development as well as hardline MH users are encouraged to read this
message and participate in the discussion.  Sorry if the preliminary
dialog is hard to follow -- I edited it to make it clear about the
direction the discussion is going.

In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:
> From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller):
> > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:
> >> And most of us use the appropriate MHL formats and filters to have them
> >> stripped later.  Note that MHs repl(1) command (for replying to a message)
> >> will allow you to reply multiple times.  The Replied headers are stripped
> >> from the resulting message by the time you see it in the editor to add
> >> your reply.
> > 
> >   There -are- other stupid UA's out there that
> > don't do the right thing [referencing how mail is replied to].  But,
> > that has nothing to do at all with how a mail folder is stored.  It is
> > incorrect to make the following statement:
> > 
> >> people who continue to implement MUAs that use a single file for
> >> storing all messages seem to continue to replicate all the things that
> 
> note that I said SEEM...^^^^
Yes, you said "seem", but the implication is clear :-).  Nevertheless, I'm
willing to let it go.

> > The reason [your statement] is incorrect is because your assumption is that it is
> > the single-file-folder "feature" that makes the program "bad."
> > A well written/designed UA should [try to] make it as transparent as
> > possible about the method for how mail is stored.  You are making a
> > grave mistake by attributing the storage method utilized by a UA to the
> > bugs or implementation (design) features of that UA.  If you think that
> > MH's "features" are a result of the fact that it's folder storage method
> > is attributed to the fact that it stored messages on a file-per-message
> > format, you are mistaken.
> 
> I did not say anything about the merits of either method.  What I said
> was that I have yet to see a "all messages in the same file" UA that
> does anything but what the others from the past do.  People are
> spending a lot of time reproducing PD replacements for MUAs that don't
> do anything really that different and useful.

You later admit that you haven't used anything else but MH for the past 5
years, so this statement doesn't carry much weight.  Nevertheless, your
observation is somewhat accurate: Most UAs developed today are limited
in either functionality (feature-list) or tend to be ill-designed and
are desitined to make the same mistakes as those that preceded them.  With
these problems in mind, I designed Mush for the purpose of avoiding these
problems while taking advantage of other issues (described later).

> Okay, here's some questions to think about.  What does
> mush/elm/mail/whatever not do that MH already does?  How much effort will
> it take to add those features (if they are desireable)?  By the time
> you have done that, what will have been added to MH that the other MUAs
> then won't have?

I don't want to discuss the entire feature list of Mush; the man page is
50 pages long.  But, Mush does provide similar features like "pick" and
other functions that MH provides.  It does provide "piping" of commands,
sorting of messages, etc..  The point is that these features can be provided
regardless of the storage method of folders.  The fact that many of the
features of MH happen to be replicated (there are some very good ones),
is a side effect of good design.  However, MH has some poor design schemes
that warrant the writing of a new MUA.  So, I'm not reinventing the wheel
with writing Mush, but instead I hope to provide a "new and improved" model.

> I don't mean to start any wars on MUAs.  I am just trying to see if the
> individuals doing the work are thinking about were they are going.  It
> is a real waste of talent to continually play catchup, always adding the
> feature that you don't have yet.

Believe me, we are aware of what we're doing and are continuing in a well
defined direction.  There are definite problems with using a Mail-method
folder format, but there are an equal number of problems with using the
MH-method.  One of the major advantages to using the Mail-based folder
storage method is that it is backwards compatible with [most] other Mail
applications (I address this issue again later).

> I had a personal reply from my original article that stated this
> >And MH is huge, and chews up disk space and inodes, and hard to learn, and
> >slow to use.

There are many things wrong with MH in this respect.  Not only is it huge,
but it *really is* hard to learn.  I remember when I first went to SRI, I
was set up with MH by default.  I spent hours reading all sorts of doc
and experimenting with commands and so on... I was really put off by the
fact that all my mail was moved and split up.  I struggled with it for a
while, but was further put off by the fact that it was so slow.

But what really took the cake for me was the fact that if your mail is
configured for MH, there's no other UA you can use-- you are stuck with MH.
What if I told you I had an editor I'd like you to try but told you that
if you used this editor, you can't use any other editor on files you edit
using that editor.  This is how I see MH's folder format.  What saves MH
is the fact that there is no "standard" (even proposed standards or RFCs)
which discuss folder formats or anything similar.

Upon further investigation, I learned that MH wasn't portable to any other
unix besides BSD systems.  This may have changed lately -- I don't keep up
with MH that much (my loss, I guess).  Is it true that MH still only talks
to sendmail as its sole MTA?

>   That, I cannot dispute.  However, I take up the argument
> that this is not a problem, but rather a feature.  If you have ever written
> an MH tool (I have written 4 to date), then you know how powerful and easy
> to use the library routines are.

Bad excuse.  A good application (regardless of functionality; here we
happen to be talking about MUAs) should have a "core" layer which makes
the program function _independently_ of its user interface.  MH solved the
problem by making each MH function a separate shell command.  Oy vey...
You have to start a new process (fork!?), set up pipes, parse command line
options, read init files (dot-files) and everything *for each MH command*.

MH isn't a "library" as you described, but rather a set of commands.  You
build a "tool" in front of MH by doing a bunch of popen() calls, or system()
calls, or whatever...  Don't you think that's rather inefficient/expensive?

Mush hasn't quite been set up to be totally independent of its user inter-
face, but it is so close that it took me effectively two weeks to build
the curses interface on it.  It also has a suntools interface and a tty
(csh-like) shell interface.  Building a new front end of Mush is in fact
very easy -- it'll even be easier once the implementation of its final
design has been completed.  The point is, Mush is a library of function
calls, not a set of unix commands.

>   Putting this
> aside, if you can type the strings
> 
> inc
> scan unseen (or scan unread)
> show
> rmm
> refile
> 
> you can use MH without any real difficulty.

In mush, if you can type "help", you've got it just about licked..
Of course, if you know how to hit "?" that works, too.  As simple
as you seem to think it is to type "inc", etc..., I never knew to
do that when I first learned MH.  Despite the doc!

> Now for the 'slow to use' part.  The fact of the matter is that most people
> using MH at universities are not going to have high speed CPUs.  MH's
> executables average about 200-300K here, and I imagine they are similar
> in size elsewhere.  This being the case, MH can be slow on a machine with
> limited resources.  But so is every other largish program I have seen.

Mush averages about 100K and provides many features that MH has "as it
turns out."  That is, I didn't design mush to be MH compatible, it just
so happened that some commands and features are very similar.  With suntools,
the binary is bigger -- about 1 MEG or so depending on the version of sunview
or sunwindows you compile with.  Without the curses interface, it's smaller.

Mush runs on a 80286 running xenix or a ATT PC and more -- can MH?  Mush
outperforms MH dramatically on large files.  For example, finding all
messages from a particular author, that has a particular subject, that
was sent (or delivered) between two dates from a folder with 500 messages
takes about 6-10 seconds.  Or, deleting all messages that have been saved
takes about 1 second.

> Give MH a try.  If you hate it, throw it away (or even burn the tape in
I'd love to look at it again... But where does one get it?  Don't tell me
I have to buy it :-).  Actually, there's nothing wrong with selling MH
(or software, for that matter -- sorry, rms :-), it just means that I
won't buy it due to my limited personal financial resources.

>   But at least try it.  MUAs are really a religous issue, so I will
> not press any harder.  I just needed to make some arguments against some
> of the bad things that people are saying about MH.

As I said, there are good things about MH (altho I didn't get into them
here, just note that I recognize them), but I feel that all the good things
about MH can be dupicated more efficiently in a different way.  Future
plans for Mush include supporting MH style folders, news, several inter-
face enhancments (more csh-like features) and performance modifications.
As you said, MUAs are as religious as using different editors -- you're
never going to convince an emacs user to use vi, and chances are unlikely
that you're going to convert an MH user to use Mush (altho there are some
cases where this has happened :-).

> gregg.g.wonderly@att.com   (AT&T bell laboratories)

dan <island!argv@sun.com>
-----
My postings reflect my opinion only -- When on the net, I speak for no company.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 09:50:56 EDT
Received: from rice.edu by mintaka.lcs.mit.edu id aa25307; 3 Jul 89 9:48 EDT
Received: from icsa.rice.edu by rice.edu (AA19891); Mon, 3 Jul 89 08:48:09 CDT
Message-Id: <8907031348.AA19891@rice.edu>
Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 9510; Mon, 03 Jul 89 08:47:58 CDT
Received: by RICE (Mailer R2.04) id 9509; Mon, 03 Jul 89 08:47:52 CDT
Date:         Mon, 03 Jul 89 08:45:03 CDT
From: "Mark R. Williamson" <MARK%RICE@rice.edu>
Subject:      Re: MH verses the "all in one file" MUAs
To: HEADER-PEOPLE@mc.lcs.mit.edu
In-Reply-To:  Message of Sun, 2 Jul 89 22:41:19 GMT from
 <att!cbnewsc!gregg@BLOOM-BEACON.MIT.EDU>

On Sun, 2 Jul 89 22:41:19 GMT gregg.g.wonderly said:
>The INODE issue is a UN*X deficency, not am MH issue.

Fair enough.  What system besides UN*X can MH run on?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 11:21:46 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa26037;
          3 Jul 89 11:15 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA09128; Mon, 3 Jul 89 11:05:21 -0400
Date: Mon, 3 Jul 89 11:05:21 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8907031505.AA09128@uunet.uu.net>
To: S.Kille@cs.ucl.ac.uk, long@sh.cs.net
Subject: Re: RFC-822 'phrase' question
Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, techies@sh.cs.net, 
    wunder@sde.hp.com

Lets ignore what the RFC says. I claim the RFC is wrong and should be updated.

It is gratuitous because it servers no useful purpose. You can tell
where it came from via the Received lines (required in the hosts-requirements
rf)

Besides, it is NOT VERIFICATION. The calling machine is telling you who
it is and you're believing it. Thats not verification in my book. The
Received lines that have an ip address mapped into a hostname are
verification, but the SMTP source routes are just useless filler.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 14:04:07 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27486;
          3 Jul 89 14:00 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12980@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 13:32:38 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 17:20:51 GMT
From: vax5!ut6y@cu-arpa.cs.cornell.edu
Organization: Not in my apartment, there isn't.
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <18916@vax5.CIT.CORNELL.EDU>
References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

My $.02 cents...

The main thing I find ELM (for example) has over MH, both of which I have,
in my time, installed and used extensively, is speed.  Elm2.2 is considerably
faster on our little Vax 750 (Vax1.cit.cornell.edu) than MH6.6.  Both, I 
find, provide a great number of features that I like, and in general, balance out in every other way.

The other advantage to ELM is that you don't have to go through EMACS to
get a really good screen interface.

The final advantage is simply that it is compatible with normal Berkley Mail.
This may not seem important until you realize that there are times when one
has to, for whatever reason, resort to old Mail/Mailx.  MHMail requires
a format conversion in order to integrate whatever you did under Mail.  Elm
does not.

Unc
,

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 15:03:50 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28037;
          3 Jul 89 14:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA14658@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 14:53:37 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 18:50:10 GMT
From: Bill Wisner <mica.berkeley.edu!wisner@ucbvax.berkeley.edu>
Organization: Verrifast Plaine Co Ltd
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <WISNER.89Jul3115010@anableps.berkeley.edu>
References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.CIT.CORNELL.EDU writes:

>This may not seem important until you realize that there are times when one
>has to, for whatever reason, resort to old Mail/Mailx.

HAH!

Bill Wisner		wisner@mica.berkeley.edu	     ucbvax!mica!wisner
I'm not the NRA either.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 18:36:54 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29920;
          3 Jul 89 18:35 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19249@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 18:27:14 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 22:13:58 GMT
From: Curt Stevens <stevens@boulder.colorado.edu>
Organization: University of Colorado, Boulder
Subject: Re: "Status" header
Message-Id: <9838@boulder.Colorado.EDU>
References: <1322@uceng.UC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1322@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes:
>I keep noticing a header called "Status" in certain mail, with field
>values like "R" and "OR".
>
>What is this header supposed to represent?  It doesn't seem to be part
>of RFC822.

I assume that RFC822 describes the vanilla email header??? Could someone
please tell me where I can get this via anonymous ftp? Thanks a bunch...

===============================================================================
|Curt Stevens        (303)492-1218 |   /   |arpa: stevens@boulder.colorado.edu|
|University of Colorado at Boulder |  o o  |uucp:{ncar|nbires}!boulder!stevens|
|Computer Science Department       |   |   |----------------------------------|
|Campus Box 430                    |  \_/  |Its a dog eat dog world & Im wear-|
|Boulder, Colorado 80309           |       |ing milkbone underwear.Norm@Cheers|
===============================================================================

========
| Curt |
========

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 19:08:14 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00419;
          3 Jul 89 19:04 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA19941@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 18:52:11 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 22:47:32 GMT
From: Bill Wisner <mica.berkeley.edu!wisner@ucbvax.berkeley.edu>
Organization: Verrifast Plaine Co Ltd
Subject: Re: "Status" header
Message-Id: <WISNER.89Jul3154732@anableps.berkeley.edu>
References: <1322@uceng.UC.EDU>, <9838@boulder.Colorado.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

RFC822 describes the standard format for messages on the Internet. The
UNIX mail format is not quite RFC822, although it does make an effort
to conform.

Bill Wisner		wisner@mica.berkeley.edu	     ucbvax!mica!wisner
I'm not the NRA either.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 19:39:16 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00877;
          3 Jul 89 19:37 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA20852@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 19:27:56 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 16:19:19 GMT
From: "p.a.davis" <att!mtuxo!mtgzz!davis@bloom-beacon.mit.edu>
Organization: AT&T, Middletown NJ
Subject: DEC Mail-11 & headers
Message-Id: <5217@mtgzz.att.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Are there any opinions, informed or otherwise, concerning DEC's
Mail-11 protocol and its refusal to handle non-VMSmail headers ?
I find it infuriating to have mail with a reply-to routed through
a VAX running a Mail-11 gateway system, only to hear from the
recipient that the reply-to has been "excised" from the header,
and now, as far as RFC???-compliant mailers are concerned, is
actually part of the message ? Does anyone know if DEC plan to
do anything about this appallingly parochial approach before X.400 ?

Paul Davis

Internet: davis@mtgzz.att.com 		Bitnet: bartonb@duvm
Voice1: 201-957-5569 (day) 		Voice2: 215-981-0614 (night)

"All opinions are my own, which may or may not increase their value."

"To shatter tradition makes us feel free,
    But tradition is a static defence
	against a chaotic community ... "    Annette Peacock, 1981

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  3 Jul 89 20:41:18 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01540;
          3 Jul 89 20:36 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA21627@BLOOM-BEACON.MIT.EDU>; Mon, 3 Jul 89 20:04:11 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jul 89 22:35:26 GMT
From: "Brandon S. Allbery" <cwjcc!hal!ncoast!allbery@ohio-state.arpa>
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Subject: Re: "Status" header
Message-Id: <13784@ncoast.ORG>
References: <1322@uceng.UC.EDU>, <KARL.89Jun28095245@giza.cis.ohio-state.edu>, <15051@pasteur.Berkeley.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

As quoted from <15051@pasteur.Berkeley.EDU> by dheller@cory.Berkeley.EDU (Dan Heller):
+---------------
| In reponse to someone's question about what the Status: header is for,
| karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes:
| 
| > That's being done by Berkeley Mail.  If you have source, see
| > ucb/Mail/send.c.  Gross.  Pick another MUA.
| 
| This header is modified by Mail (or sokme UA) to remember that the
| message has been Read, Unread-but-old, or other information about
| the message.
| 
| Karl feels that this is "gross".  I'd love to hear suggestions about
| how to retain the "status" of a message without losing "state" and
| not storing the information in the actual message.  The status header
| is common among most Mail-based UA's (I don't know about MH).
+---------------

MH *does* use such headers.  However, the format is quite different:

	Replied: Sat, 01 Jul 89 10:43:08 -0400

However, you can give MH commands a flag (-noannotate) to turn this off.
Presumably, Karl does this (assuming that he uses MH); I, personally, prefer
to know about it.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Jul 89 10:36:45 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa07941;
          4 Jul 89 10:31 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0741; Tue, 04 Jul 89 10:30:17 EDT
Received: from IRLEARN.UCD.IE by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 8693; Tue, 04 Jul 89 10:30:17 EDT
Received: by IRLEARN (Mailer R2.03B) id 1023; Tue, 04 Jul 89 15:13:38 GMT
Date:         Tue, 04 Jul 89 14:59:24 GMT
From:         "Niall O'Reilly     (NOREILLY@IRLEARN.UCD.IE)" <NOREILLY%IRLEARN.BITNET@mitvma.mit.edu>
Subject:      Re: DEC Mail-11 & headers
To:           HEADER-PEOPLE@MC.lcs.mit.edu
In-Reply-To:  Message of Mon, 3 Jul 89 16:19:19 GMT from
 <att!mtuxo!mtgzz!davis@BLOOM-BEACON.MIT.EDU>
Message-ID:  <8907041031.aa07941@mintaka.lcs.mit.edu>

My partly-informed and strongly-held opinion is that if mail passing
through a VMS VAX must be mangled at all, then that VAX ought to be
running PMDF (or better, but I don't know any better: I'm just partly-
informed).

Mail-11 doesn't support more than three or four of the
header elements of RFC822, and supports very restricted addressing.
A variety of ad-hoc extensions offer some relief, but too often
result in messagesfor which the REPLY command does not work.

I'm not quite sure what you mean by 'Mail-11 gateway'.
My notion of a gateway is something which comprehends more than Mail-11 ...

Niall

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Jul 89 10:36:51 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07946;
          4 Jul 89 10:33 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA05501@BLOOM-BEACON.MIT.EDU>; Tue, 4 Jul 89 10:06:02 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Jul 89 13:39:01 GMT
From: Larry Campbell <redsox!campbell@think.com>
Organization: The Boston Software Works, Inc.
Subject: Re: DEC Mail-11 & headers
Message-Id: <797@redsox.bsw.com>
References: <5217@mtgzz.att.com>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

DEC will never "fix" the Mail-11 protocol.  It is not too far from the
truth to say that Mail-11 is braindamaged on purpose -- DEC's attitude
is that if you want "real" mail, you buy Mailbus products.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@bsw.com                        120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02146

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Jul 89 19:12:06 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11315;
          4 Jul 89 19:04 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA14758@BLOOM-BEACON.MIT.EDU>; Tue, 4 Jul 89 18:37:56 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Jul 89 22:10:39 GMT
From: Keith Moore <utkcs2!CYGNUSX1.CS.UTK.EDU!moore@gatech.edu>
Organization: CS Dept -- University of TN, Knoxville
Subject: Re: DEC Mail-11 & headers
Message-Id: <979@utkcs2.cs.utk.edu>
References: <5217@mtgzz.att.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <5217@mtgzz.att.com> davis@mtgzz.UUCP (p.a.davis) writes:
>Are there any opinions, informed or otherwise, concerning DEC's
>Mail-11 protocol and its refusal to handle non-VMSmail headers ?

Mail-11 and VMS MAIL are toys.

It's a royal pain to have to translate from MAIL-11 to "real" mail
protocols, but this is because VMS MAIL was never designed to talk
to anything but other VMS MAIL (or very similar) programs.

>I find it infuriating to have mail with a reply-to routed through
>a VAX running a Mail-11 gateway system, only to hear from the
>recipient that the reply-to has been "excised" from the header,
>and now, as far as RFC???-compliant mailers are concerned, is
>actually part of the message ? 

Some SMTP-to-MAIL-11 gateway programs scan the RFC822 headers to 
determine the "best" reply-to address, and insert that address in
the MAIL-11 "From" line, so replies go to the correct addresss.
(PMDF does this, and so does my mail-11 gateway for UNIX systems.)

>Does anyone know if DEC plan to
>do anything about this appallingly parochial approach before X.400 ?

I'm sure your DEC customer relations person will tell you that they
have done something about the problem, and it's called "Mailbus".
--
Keith Moore			Internet: moore@utkcs2.cs.utk.edu
University of Tenn. CS Dept.	BITNET: moore@utkvx
107 Ayres Hall, UT Campus	UT Decnet: utkcs2::moore
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Jul 89 17:12:04 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12467;
          9 Jul 89 17:10 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA24277@BLOOM-BEACON.MIT.EDU>; Sun, 9 Jul 89 16:07:30 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Jul 89 14:20:31 GMT
From: "Nicholas J. Simicich" <bywater!scifi!njs@uunet.uu.net>
Organization: Nick Simicich, Peekskill, NY
Subject: Re: MH verses the "all in one file" MUAs
Message-Id: <682@scifi.UUCP>
References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM>, <18916@vax5.CIT.CORNELL.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.cit.cornell.edu (The Dread Pirate Mikey (Mike Shappe)) writes:
>The final advantage is simply that it is compatible with normal Berkley Mail.
>This may not seem important until you realize that there are times when one
>has to, for whatever reason, resort to old Mail/Mailx.

I think that I can say that this isn't true in my case.  And I know
many other people who do all of their mailing on Unix (AIX) who use
mh-mode in GNUemacs, rmail mode in GNUemacs, or XMH, and who never use
the Berkley mail command.

Me?  I like RMAIL mode....




-- 
Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 22:45:53 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27056;
          12 Jul 89 22:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA26881@BLOOM-BEACON.MIT.EDU>; Wed, 12 Jul 89 22:23:23 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Jul 89 00:51:26 GMT
From: Geoff Goodfellow <fernwood!geoff@decwrl.dec.com>
Organization: Anterior Technology, Menlo Park, CA  USA
Subject: Assumptions & Rules for Transiting UUCP/SMTP Messages.
Message-Id: <1368@fernwood.MPK.CA.US>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[The following blurb is the result of an ~11pm-1am fueling at The Oasis (a local
burger/pizza/beer garden) between Geoff Goodfellow & Paul Vixie.  Comments?]

	   ASSUMPTIONS & RULES FOR TRANSITING UUCP/SMTP MESSAGES

Assumptions:

1.  UUCP(!) style addresses are not guaranteed to always be unique and/or
      registered in the uucp maps.
2.  SMTP(@) rfqdm style address are unique and registered in the DNS.
3.  The envelope of a UUCP message is always touched as a message transits
      a system, by prepending the transited systems name to the front.


Header Treatment Rules:

1.   Headers are treated the same regardless of transport.
2.   Headers should not be touched as messages transit systems UNLESS 
       the message is transiting from the UUCP(!) to the SMTP(@) environment.
3.   While transiting a message from the UUCP(!) to the SMTP(@) environment,
3a.    IF the header contains an (@) style address with a rfqdm address on the
         right of it THEN do not touch it;
3b.    IF the header contains an (@) style address with a non-rfqdm address on
         the right of it THEN do some type of %ification to the non-rfqdm
         address and append the rfqdm (@) address of the transited system;
3c.    IF the header does not contain an (@) style address THEN replace 
         the header "From:" address with envelope "From " address and 
         append the rfqdm (@) address of the transited system. 


Notes:

DNS = Internet Domain Name System.

rfqdm = Registered Fully Qualified Domain address in the DNS.

An (@) style address is an address with an @-sign in it.

You cannot assume an (@) style address is a rfqdm name without checking its
   validity with the DNS when transiting messages from UUCP -> SMTP, as there
   are hosts which will assign themselves a DNS style name without registering
   it in a DNS server connected to the Internet.  (Use of the PSEUDODOMAIN 
   function in IDA Sendmail permits bypassing DNS lookups on bogus top-level
   domains such as .uucp, .bitnet, .janet, et al and then proceed
   directly to rule 3b).

Some systems prepend their name to headers as a message transits them
   (in violation of rule 2).  This inconsistiency is fixed by copying
   the envelope "From ", which is always augmented as a message transits
   a system (assumption 3) into the "From:" header field (rule 3c).

There is no attempt to fix or clean-up bad/invalid headers or short-circuit
   routing.  garbage in ==> garbage out (with the exception for rule 3c's
   handeling of "From:" when transiting a message from !-land into @-land).

	
Some Rule Examples (fernwood.mpk.ca.us is the UUCP -> SMTP gateway host)

2.  z!foo		-->	 	z!foo
    x!y!z!foo		-->	 	x!y!z!foo
    x!y!z.com!foo	-->	 	x!y!z.com!foo


3a. foo@z.com		-->	 	foo@z.com

3b. foo@z.uucp		-->	  	foo%z.uucp@fernwood.mpk.ca.us
    bar@z.bitnet	-->	 	bar%z.bitnet@fernwood.mpk.ca.us
    foo@z		-->	 	foo%z@fernwood.mpk.ca.us
    foo@bogus.com	-->	 	foo%bogus.com@fernwood.mpk.ca.us

3c. Envelope:	x!y!z!foo
    Header:     x!z!foo		-->	x!y!z!foo@fernwood.mpk.ca.us
    Envelope:	x.com!y!z!foo
    Header:     x.com!y!z!foo	-->	x.com!y!z!foo@fernwood.mpk.ca.us

