Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 09:53:19 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05463;
          13 Jul 89 9:49 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA04362@BLOOM-BEACON.MIT.EDU>; Thu, 13 Jul 89 08:19: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: 13 Jul 89 08:47:10 GMT
From: bionet!%%%lear%%%%NET.BIO.NET@csd4.milw.wisc.edu
Subject: Re: Assumptions & Rules for Transiting UUCP/SMTP Messages.
Message-Id: <Jul.13.01.47.09.1989.6414@NET.BIO.NET>
References: <1368@fernwood.MPK.CA.US>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


[In reply to Geoff Goodfellow's message, <1368@fernwood.MPK.CA.US>]

This is not really a criticism on your suggestions for gateways, but
more a point on interprotocol routing, in general.

It is up to a gateway to decide how it will handle a protocol
conversion.  That site must perform some manipulation on the header
(as specified by what protocol exists at the far end).  So long as the
message is delivered, the gateway's responsibility is discharged.  It
would also be nice, if at all possible, if the gateway presents a
replyable message.  For example, BITNET was in past well known for its
limitations on usernames and hostnames.  DECNET is even worse.
-- 
Eliot Lear
[lear@net.bio.net]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 12:46:46 EDT
Received: from rice.edu by mintaka.lcs.mit.edu id aa07806; 13 Jul 89 12:42 EDT
Received: from icsa.rice.edu by rice.edu (AA02509); Thu, 13 Jul 89 11:42:04 CDT
Message-Id: <8907131642.AA02509@rice.edu>
Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 4530; Thu, 13 Jul 89 11:41:46 CDT
Received: by RICE (Mailer R2.04) id 0419; Thu, 13 Jul 89 11:41:30 CDT
Date:         Thu, 13 Jul 89 11:30:33 CDT
From: "Mark R. Williamson" <MARK@rice.edu>
Subject:      Resent- as a general prefix?
To: Header People <header-people@mc.lcs.mit.edu>

Can the description in RFC822 of the general philosophy of the prefix
"Resent-" be taken to imply that any valid header field may have "Resent-"
prefixed (e.g., Resent-Subject), or is the set of valid Resent-... fields
defined by those which appear explicitly in the syntax rules?  Opinions?
Definitive statements?

Mark R. Williamson, Rice University, Houston, TX; MARK@ICSA.RICE.EDU

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 16:47:18 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15107;
          13 Jul 89 16:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA15856@BLOOM-BEACON.MIT.EDU>; Thu, 13 Jul 89 15:47: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: 13 Jul 89 19:41:29 GMT
From: Karl Kleinpaste <giza.cis.ohio-state.edu!karl@ohio-state.arpa>
Organization: Ohio State Computer Science
Subject: Re: Assumptions & Rules for Transiting UUCP/SMTP Messages.
Message-Id: <KARL.89Jul13154129@giza.cis.ohio-state.edu>
References: <1368@fernwood.MPK.CA.US>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I note editorially at the outset of this response that I am not a
General Rabid Rerouter, but merely a Domain Absolutist Rabid Rerouter,
that is, I short-circuit to rightmost domain, but otherwise leave
!-paths alone.  The difference is significant.

There are several of these rules with which I quibble, and it is not
at all clear to me that the set of assumptions is complete.

geoff@Fernwood.mpk.ca.us writes:
>  Assumptions:
>	[non-uniqueness of UUCP names; DNS names are unique; UUCP
>	 envelopes are hacked via prepending of pass-through hosts.]

How about "UUCP hosts cannot be counted on to respect RFC-compliant
`operator precedence' in mixed-mode addresses"?  E.g., some UUCP hosts
will take
	a!b@c.d
as
	a!(b@c.d) [broken]
and others will take it as
	(a!b)@c.d [correct].

>  Header Treatment Rules:
>  1.  Headers are treated the same regardless of transport.

No.  Example:
	Origin address given me by someone.else.edu:
		SomeUucpHost!username@out.there.gov
	If I hand it to someone via SMTP, especially DEC-20's w/MAISER:
		I leave it alone.
	If I hand it to a UUCP neighbor:
		out.there.gov!SomeUucpHost!username
Reasoning: UUCP hosts should not be given mixed-mode addresses, due to
my extra assumption above.  I must do the work for them, to ensure
sanity.

This also happens to work around an old bug in smail 2.5 which I have
never taken the time to trace down.

>  2.  Headers should not be touched as messages transit systems UNLESS 
>	 the message is transiting from the UUCP(!) to the SMTP(@) environment.

No.  See above, on SMTP->UUCP.

>  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;

OK.

>  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;

Absolutely not.  RFC 822, section 6.2.2, page 29:

    When a message crosses a domain boundary, all addresses must
    be specified in the full format, ending with the top-level
    name-domain in the right-most field.  It is the responsibility
    of mail forwarding services to ensure that addresses conform
    with this requirement.

There are several implications of this.

First, if a header arrives with the address
	username@OneWordHostName
(lacking, notably, any dotted domain qualifiers), I _cannot_ guarantee
the intended interpretation of the OneWordHostName.  The mailer which
handed me that address has failed the 2nd quoted sentence from 6.2.2.
I cannot say if OneWordHostName was supposed to have been known within
the context of the mailer which handed me the mail, or some other
entity farther behind itself (if the one which handed it to me was
merely the Nth-stage intermediate transfer point).

Second, as a result of the first, given that I have no means by which
to interpret OneWordHostName reliably, I aggressively rewrite it _in_
_my_own_context_, cis.ohio-state.edu.  Since I hide hostnames, I
therefore rewrite this as
	username@cis.ohio-state.edu.

I will _not_ %ify the header.  I flatly refuse.  I %ify the _envelope_
in order to reach, e.g., .bitnet.  Under duress.  Nowhere else.

>  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. 

I don't think so.  In my configuration, anything lacking _both_ ! and
@ is considered not to be punctuated at all; that is, it looks like a
local username, and I add @cis.ohio-state.edu in accordance with 6.2.2.

>  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).

You ignore the Property of Non-Reversability of UUCP Paths, at your
peril.  I don't perform DARR[*] for nothing; it's a solution (which
has worked without exception up to this point, mind you) to this
particular Property.

--Karl

[*] DARR: Domain Absolutist Rabid Rerouting.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:44:40 EDT
Received: from VAX.FTP.COM by mintaka.lcs.mit.edu id aa00403;
          14 Jul 89 14:45 EDT
Received: from stev.feather.ftp.com by vax.ftp.com via PCMAIL with DMSP
	id AA22759; Fri, 14 Jul 89 14:22:53 EDT
Date: Fri, 14 Jul 89 14:22:53 EDT
Message-Id: <8907141822.AA22759@vax.ftp.com>
To: bionet!%%%lear%%%%net.bio.net@csd4.milw.wisc.edu
Subject: re: assumptions & rules for transiting uucp/smtp messages.
Cc: header-people@mc.lcs.mit.edu
Sender: stev@vax.ftp.com
From: stev@vax.ftp.com
Repository: ftp.com
Originating-Client: feather.ftp.com

*So long as the
*message is delivered, the gateway's responsibility is discharged.  It
*would also be nice, if at all possible, if the gateway presents a
*replyable message. 

*Eliot Lear
*[lear@net.bio.net]

wrong, eliot. if you cant do it right (for some value of right)
you shouldnt be doing it. as am example, i present your address
as it arrived on my machine. sorta scary. hopefully, the right 
thing will happen with it.

there are too many "weenie" users out there who can barely remember 
to delete their old mail when they leave their mail programs, dont make 
it too much harder for them.

as a side note on the original note, i dont think you should assume all @
addresses are DNS resolvable. things are growing *very* quickly, and we
will be seeing more addresses from people before the DNS stuff gets
updated. i think all you can assume is that the server for the [sub]domain
one level above should be resolvable, and that he could be given the mail.
(this is an argument for the "wildcard" MX record.)

stev knowles
ftp software
stev@ftp.com



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:11:07 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00509;
          15 Jul 89 8:43 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA29992@BLOOM-BEACON.MIT.EDU>; Sat, 15 Jul 89 05:52:47 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: 15 Jul 89 06:04:02 GMT
From: Keith Moore <utkcs2!cygnusx1.cs.utk.edu!moore@gatech.edu>
Organization: CS Dept -- University of TN, Knoxville
Subject: Suggested goals for mail gatewaying in general
Message-Id: <998@utkcs2.cs.utk.edu>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

[I've been working on a follow-up to the suggestions by Goodfellow, Vixie,
 and subsequently by Kleinpaste, but there are lots of cases to consider, 
 and it's really difficult to think of everything.  So I thought I'd take
 a step back and define some general goals.  Here's what I have come up 
 with so far.  Comments?]

Goals for successful gatewaying of electronic mail messages (in general):
(Roughly in decreasing order of importance)

1.  The first responsibility of a mail gateway is to either:
    a) to convert an incoming message and arrange for delivery to its 
       recipients via the destination network, or
    b) to report failure of delivery to the originator if such conversion
       is not possible, for example, if the message body (for non-text
       messages), or an envelope recipient address could not be converted.

2.  The gateway should make reasonable attempts to ensure that all components
    (e.g. envelope addresses, headers, and message body) of the gatewayed
    message are within accepted standards for the destination network, and
    if possible, also within the usual conventions for the destination 
    network.

3.  Ideally, the gateway should arrange that notification of delivery
    failure on the recipient's network will be returned to the originator.
    If this is not possible, such notification should be returned to the
    gateway postmaster.

4.  Ideally, a recipient of the message should be able to reply to the
    message using his UA's "reply" or similar command.  The gateway should
    arrange that such replies will be sent to the "correct" reply address(es)
    according to the conventions of the originator's mail system.

5.  Gateways should preserve information which may be useful to a human
    in tracing the path that a message traversed in reaching its 
    destination, and in determining an appropriate reply address should
    the gateway be unable to provide one.

6.  Gateways should make a reasonable attempt to ensure that all header
    and envelope addresses are "correct" according to the standards and
    conventions of the destination network, for those headers that are
    likely to be interpreted by mail-handling programs.  "Correct" means
    that the addresses are likely to be interpreted correctly by mailers,
    not simply that the addreses are syntatically correct.

7.  Gateways should never knowingly pass invalid envelope or header addresses
    on to the destination network.  If, for instance, an address cannot be 
    translated appropriately according to the standards of the destination
    network, it should be hidden from mail-handling programs, and the 
    original address preserved in an appropriate place (e.g. an extension
    message header) for interpretation by humans.
--
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 15 Jul 89 17:43:04 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07147;
          15 Jul 89 17:12 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA12104@BLOOM-BEACON.MIT.EDU>; Sat, 15 Jul 89 16:59: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: 15 Jul 89 20:19:09 GMT
From: vax5!sdry@cu-arpa.cs.cornell.edu
Subject: Enhanced "vacation" program sought
Message-Id: <19038@vax5.CIT.CORNELL.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Does anybody have an enhanced version of the "vacation" program that uses
RFC822 headers like "Reply-To" to decide where a reply is to be sent?
This would be particularly useful for people (like myself) who are on a mailing
list and would like to prevent the reply from going to the whole list.
The version of "vacation" I have is designed with uucp in mind, and only
looks at the "From " line.
Another (perhaps even more useful) enhancement would be the possibility of
specifying in advance a list of users who should not get a reply. I realise I
could play with the .vacation.pag and .vacation.dir files, but that requires
a special program.
	I could rewrite "vacation" myself, but if somebody else has already
done it I see no point in duplicating his/her effort.
	Thanks,
						Sergio Gelato
						gelato@astrosun.tn.cornell.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 20:09:08 EDT
Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa23254;
          21 Jul 89 20:02 EDT
Received: by ahwahnee.Stanford.EDU; Fri, 21 Jul 89 16:56:37 PDT
Date: Fri, 21 Jul 89 16:56:37 PDT
From: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Subject: Re:  Enhanced "vacation" program sought
To: header-people@mc.lcs.mit.edu, vax5!sdry@cu-arpa.cs.cornell.edu
Message-ID:  <8907212002.aa23254@mintaka.lcs.mit.edu>

I believe that the MMDF-based vaction-type program does the sorts of
things you are interested in.

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Jul 89 17:16:57 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03295;
          31 Jul 89 17:11 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA03598@BLOOM-BEACON.MIT.EDU>; Mon, 31 Jul 89 16:54: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: 31 Jul 89 05:18:27 GMT
From: Bruce Robert Larson <contact!umb!blarson@husc6.harvard.edu>
Organization: UMASS-Boston, Boston, MA
Subject: For Sale: Compaq 386/20 w/5MB 60MB
Message-Id: <875@umb.umb.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


FOR SALE

Compaq Deskpro 386/20 (nine months old)
  *  5 MB Compaq RAM
  *  60 MB Compaq (CDC) HD RLL w/1:1 interleave
  *  5-1/4 1.2MB floppy drive
  *  3-1/2" 1.44 MB Compaq drive
  *  2 serial ports
  *  2 parallel ports
  *  Compaq Deskpro Technical Reference Guide vols. 1 & 2 (complete)
  *  monitor and video card NOT included

  Have been running 386/ix on it. It's a real screamer.

Asking $6800 or best offer.

Call (617) 288-4377, and ask for Bruce.
Or send email to blarson@umb.edu.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Aug 89 17:47:43 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16590;
          4 Aug 89 17:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA02726@BLOOM-BEACON.MIT.EDU>; Fri, 4 Aug 89 17:15:44 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 Aug 89 17:27:08 GMT
From: Marc Cohen <m2c!umvlsi!umvlsi.ecs.umass.edu!cohen@husc6.harvard.edu>
Organization: University of Massachusetts, Engineering Computer Services
Subject: RE: CONVEX C-210 SUPERCOMPUTER
Message-Id: <COHEN.89Aug4132707@gumby.ecs.umass.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Sorry....

The reply address for those interested in the Convex C-210 should have read:

blanchard@ecs.umass.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Aug 89 17:47:50 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16594;
          4 Aug 89 17:43 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA02692@BLOOM-BEACON.MIT.EDU>; Fri, 4 Aug 89 17:14:08 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 Aug 89 15:43:41 GMT
From: Marc Cohen <m2c!umvlsi!umvlsi.ecs.umass.edu!cohen@husc6.harvard.edu>
Organization: University of Massachusetts, Engineering Computer Services
Subject: CONVEX C-210 SUPERCOMPUTER FOR SALE
Message-Id: <COHEN.89Aug4114341@gumby.ecs.umass.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I'm posting this for our Director.  Please respond to address below.

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

			FOR SALE

		CONVEX C-210 SUPERCOMPUTER

		Complete System

	Hardware:
		o  32 Mb memory
		o  (2) 434 Mb disk drives
		o  6250/1600 bpi tape drive
		o  (2) 16 line async. comm. controllers
		o  Ethernet controller

	Software:
		o  CONVEX UNIX
		o  Ethernet software
		o  Vectorizing Fortran compiler
		o  CONVEX consultant
		o  COVUE Shell w/ network software

	Installation date:  6/3/88

	For further information contact:

		Daniel Blanchard
		University of Massachusetts
		College of Engineering
		Amherst, MA 01003
		413-545-1580
		BLANCHARD@UMAECS.UMASS.EDU

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Aug 89 09:23:14 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12445;
          13 Aug 89 9:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA09032@BLOOM-BEACON.MIT.EDU>; Sun, 13 Aug 89 09:08: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: 8 Aug 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 15 Aug 89 17:21:47 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10988;
          15 Aug 89 17:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 
	id <AA17458@BLOOM-BEACON.MIT.EDU>; Tue, 15 Aug 89 16:57: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: 15 Aug 89 20:16:25 GMT
From: "Tom.Moore@ciss.Dayton.NCR.COM" <ncrlnk!ciss!tmoore@uunet.uu.net>
Organization: NCR Corp. Network Application Services
Subject: Confirm Delivery
Message-Id: <909@ciss.Dayton.NCR.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

For what ever the reason and privacy isues aside, I need the ability to have 
the MTAs within the NCR mail system acknowledge that a message has been 
delivered to a user mailbox.  Has there been any standardization within the 
net as to the proper header to use?  Apparently there was some discussion a 
while back about "Return-Receipt-To:".  This sounds like what I have in mind. 

-- 
* Tom Moore                NCR Corporation  PCD-6              (513) 445-1373 *
* Consulting Analyst       1700 S. Patterson Blvd.         VOICEplus 622-1373 *
* Network Applications     Dayton, OH 45479          Tom.Moore@Dayton.NCR.COM *

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Aug 89 19:47:34 EDT
Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa12630;
          15 Aug 89 19:44 EDT
Received: by ahwahnee.Stanford.EDU; Tue, 15 Aug 89 16:37:24 PDT
Date: Tue, 15 Aug 89 16:37:24 PDT
From: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Subject: Re:  Confirm Delivery
To: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net
Message-ID:  <8908151944.aa12630@mintaka.lcs.mit.edu>

Is there any interest in specifying a set of header-additions, to RFC822,
which augment 822's functionality and make it equivalent to X.400?

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 15:04:42 EDT
Received: from shamash.cdc.com by mintaka.lcs.mit.edu id aa20577;
          16 Aug 89 10:33 EDT
Received: by shamash.cdc.com (5.59/CDC1.2)
	id AA10880; Wed, 16 Aug 89 09:15:56 -0600
Return-Path: <kehres>
Received: by jpntok.cdjapan.co.jp (5.51++/1.14.7-TIS)
	id AA21781; Wed, 16 Aug 89 23:15:07 JST
Message-Id: <8908171415.AA21781@jpntok.cdjapan.co.jp>
Date: Wed, 16 Aug 89 23:15:04 -1500
From: Tim Kehres <kehres@tis.llnl.gov>
Subject: Re: Confirm Delivery
To: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Cc: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net
X-Orig-Date: Tue, 15 Aug 89 16:37:24 PDT
X-Orig-From: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
X-Orig-Message-Id: <8908151944.aa12630@mintaka.lcs.mit.edu>

In your message you write:
> Is there any interest in specifying a set of header-additions, to RFC822,
> which augment 822's functionality and make it equivalent to X.400?

I'm not sure what you could do to augment 822's functionality to make it
'equivalent' to X.400.  The X.400 recommendations encompass not only the
address format of messages (roughly equivalent to P2 in X.400) but the
entire Message Transfer System (MTS) as well as Message Store (MS) functions
and certain types of gateways (oops, that's Access Units for OSI people
that consider 'gateway' a dirty word), and certain types of conversions.
The basic representation of messages is considerably different between
the two worlds: most 822 based systems look at messages as being text
based only, and only consisting of a single body part, where X.400 does
not have these restrictions.  While it may be possible to augment 822
to handle some of these cases, is it practical to think that the existing
transport services that 822 users use will change to accomodate some of
these enhancements?

Please don't think that I am trying to argue against enhancements to 822.
In fact, I do believe that there are certain areas, like defining standard
header fields for delivery notification and return receipt requests that
would be valuable additions to the protocol.  It is just that your short
query seems very open-ended and I am curious as to what you had in mind.

Best Regards,

Tim Kehres

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 15:06:48 EDT
Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa21452;
          16 Aug 89 11:46 EDT
Received: by ahwahnee.Stanford.EDU; Wed, 16 Aug 89 08:39:21 PDT
Date: Wed, 16 Aug 89 08:39:21 PDT
From: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Subject: Re: Confirm Delivery
To: dcrocker@ahwahnee.stanford.edu, kehres@tis.llnl.gov
Cc: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net
Message-ID:  <8908161146.aa21452@mintaka.lcs.mit.edu>

It is interesting to send an (intentionally) simplistic suggestion and then
watch the reactions.  (Actually, I was a little too rushed, or I would have
indicated the real gist of my interest:

There are functions in X.400 that CAN be translated into an enhanced
RFC822 specification.  It seems to me that it would be worth having
a fairly brief(?), focussed effort to define those upgrades.  I believe
that one type of confirmed delivery is a candidate.

Certainly, we cannot and should not attempt to replicated P1 or P3, which
are the protocols Tim is references.  (Well, really only P1, for MTA-to-MTA
transfers.)  But 822 is primarily a UA-to-UA specification, so that
keeping the focus on P2 seems reasonable.  (Yes, I realize that the
referenced conform-delivery will probably be of the MTA-to-UA-mailbox
style and therefore goes beyond P2.)

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 10:50:22 EDT
Received: from janeb.cs.wisc.edu by mintaka.lcs.mit.edu id aa06541;
          17 Aug 89 10:45 EDT
Message-Id: <8908171445.AA04085@janeb.cs.wisc.edu>
Received: from localhost by janeb.cs.wisc.edu; Thu, 17 Aug 89 09:45:30 -0500
To: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Cc: kehres@tis.llnl.gov, header-people@mc.lcs.mit.edu, 
    ncrlnk!ciss!tmoore@uunet.uu.net
Subject: Re: Confirm Delivery 
In-Reply-To: Your message of Wed, 16 Aug 89 08:39:21 -0700.
             <8908161146.aa21452@mintaka.lcs.mit.edu> 
Date: Thu, 17 Aug 89 09:45:29 CDT
From: hagens@cs.wisc.edu



> There are functions in X.400 that CAN be translated into an enhanced
> RFC822 specification.  It seems to me that it would be worth having
> a fairly brief(?), focussed effort to define those upgrades.  I believe
> that one type of confirmed delivery is a candidate.

> Certainly, we cannot and should not attempt to replicated P1 or P3, which
> are the protocols Tim is references. 
>...

> Dave
Dave, may I caution you to consider the amount of time it would take to
	1) define the upgrades
	2) implement them in a User Interface
	3) distribute those changes
If it takes more than 1 year, you might as well wait for real X.400 (with the help
of RFC 1006) running over existing Internet links (via TCP/IP).

Rob Hagens 

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 21:49:05 EDT
Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa14901;
          17 Aug 89 21:42 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA24587@EDDIE.MIT.EDU>; Thu, 17 Aug 89 21:28:48 EDT
Received: from splat.UUCP by ssyx.ucsc.edu (4.0/1.1)
	id AA03578; Thu, 17 Aug 89 18:28:37 PDT
Received: by Splat.Aptos.CA.US (smail2.5)
	id 00776; 17 Aug 89 18:08:57 PDT (Thu)
From: Brad Allen <splat!ulmo@ssyx.ucsc.edu>
Date: Thu, 17 Aug 89 18:08:55 PDT
In-Reply-To: Dave Crocker <ssyx!dcrocker%ahwahnee.stanford.edu>
       "Re:  Confirm Delivery" (Aug 15, 19:42)
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Dave Crocker <dcrocker@ahwahnee.stanford.edu>, 
    Header-People@mc.lcs.mit.edu
Subject: Re:  Confirm Delivery
Message-Id: <19890817.1808,00776@Splat.Aptos.CA.US>

> Is there any interest in specifying a set of header-additions, to RFC822,
> which augment 822's functionality and make it equivalent to X.400?

I have always found it crazy that mail (of all things) doesn't require
ACKnowledgement from the other side.  I've always wanted to have a list
for every user account I own which tells what mail is pending for
acknowledgement, and to what extent it is pending acknowledgement.

This comes more from the unreliable UUCP perspective, I think, than
the Internet perspective.  However, I've had my share of theoretically
perfectly straightforward Internet mailings get lost.

Clearly to me, knowing that the mail made it to the user's actual mailbox is
the least which should be required for such acknowledgement.  However,
there are lots of things which could be acknowledged:

 - Actual receipt by the human user.  (Often considered private information.)
   I can see two subtypes of this already, implicit and explicit;
   implicit acks are automatic, saying that the user pressed the key
   to have the message displayed; explicit means the user specifically
   gave a command saying "Here, I read this".
   There are possibly more subtypes which would be useful:
   "Yes I got it I'll read it later"
   "I have read it all."
   "I discarded it."
   "Whatever I did, I dealt with it; I'm done with it."
   This would be voluntary, but I would always suggest supporting it
   since I would find it useful to tell people which pieces of mail
   out of my 10 megabyte (yes) mailbox I've seen, read, noticed, etc.
 - Everything between the birth and death of the message -- you can
   interpolate from here.  Things like "It got to machine X",
   "It got to the mailbox itself" (what I mentioned above), and
   "It did NOT get to machine X".

This brings up the issue of complexity and usefulness.
If designed well, acknowledgements could be made elegant and potentially
complex in representation but simple in understanding.

I have no idea what ISO X.400 says.
Whatever X.400 does, I do suggest that it's always a good idea
to keep Internet standards current, and at least comparable with ISO,
while the Internet standards are still being used.

What is more difficult to me is how to support these for automated use;
if my local mailer is to retry sending a message, then how does it know if
the remote host is conforming to this standard?  It would be pretty easy
to flood-enforce the community to upgrade to new mailers by simply
letting the local mailers re-send until stopped, but this is not very elegant.
And, don't get afraid of mailers which would send zillions of messages around:
some people just haven't heard of restraint.  The local mailer would use some
rapidly increasing interval between resend, and would inform the local user
of the progressing failure after an uncommon amount of time had transpired.
I still really like my idea of the local mailer keeping a list of messages
which haven't somehow been ACK'ed yet -- every day I log in, I can routinely
muck with that list and the associated messages until they get there OK.
A better solution is consulting the DNS to find out what protocols the
remote host is using -- perhaps this is a good chance to change mail from
TCP to some UDP, IP, or similar object-based protocol (where the ACK itself
isn't being ACKed many times at lower levels, and where an IP packet doesn't
have to be sent out for HELO, MAIL FROM:, and RCPT TO: type commands).

Brad Allen
5 year BBS user

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 11:04:40 EDT
Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa19594;
          18 Aug 89 1:44 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA29232@EDDIE.MIT.EDU>; Fri, 18 Aug 89 01:43:48 EDT
Received:  by XN.LL.MIT.EDU; Fri, 18 Aug 89 01:21:24 EDT
Posted-Date: Thu, 17 Aug 89 8:13:30 EDT
Received: by SCUBED.COM (1.2/5.20b)
	id AA25399; Thu, 17 Aug 89 08:52:59 pdt
Message-Id: <8908171552.AA25399@SCUBED.COM>
Subject: Re: Confirm Delivery
To: Dave Crocker <dcrocker@ahwahnee.stanford.edu.uucp>
Date: Thu, 17 Aug 89 8:13:30 EDT
From: Tom Moore <ll-xn!scubed!coss!tmoore@eddie.mit.edu>
Cc: header-people@mc.lcs.mit.edu, kehres@tis.llnl.gov
In-Reply-To: <8908161546.AA07448@uunet.uu.net>; from "Dave Crocker" at Aug 16, 89 8:39 am
X-Mailer: ELM [version 2.2 PL10]

I'm still a novice at all of this but it seems that RFC 987 and RFC 1026
attempt to address the RFC822 <-> X.400 gateway issue.  That was the 
first place that I looked for the comfirm delivery header.  Unfortunately
it was one of those that was not supported, probably due to the lack of
capability within most RFC822 routers.

I for one would be very interested in the RFC822 <-> X.400 discussion.
My company is currently using RFC822 but we are committed to an X.25
network and X.400 mail in the near future.  As this transition takes place
we will need the gateway service.  I would rather that we do not go 
swimming against the tide as we do it but rather go with the standards of 
the community.

-- 
* Tom Moore                NCR Corporation  PCD-6              (513) 445-1373 *
* Consulting Analyst       1700 S. Patterson Blvd.         VOICEplus 622-1373 *
* Network Applications     Dayton, OH 45479          Tom.Moore@Dayton.NCR.COM *

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 11:04:49 EDT
Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa19600;
          18 Aug 89 1:44 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA29238@EDDIE.MIT.EDU>; Fri, 18 Aug 89 01:44:07 EDT
Received:  by XN.LL.MIT.EDU; Fri, 18 Aug 89 01:21:57 EDT
Posted-Date: Thu, 17 Aug 89 8:16:43 EDT
Received: by SCUBED.COM (1.2/5.20b)
	id AA25406; Thu, 17 Aug 89 08:53:24 pdt
Message-Id: <8908171553.AA25406@SCUBED.COM>
Subject: Re: Confirm Delivery
To: dcrocker@ahwahnee.stanford.edu
Date: Thu, 17 Aug 89 8:16:43 EDT
From: Tom Moore <ll-xn!scubed!coss!tmoore@eddie.mit.edu>
Cc: kehres@tis.llnl.gov, header-people@mc.lcs.mit.edu
X-Mailer: ELM [version 2.2 PL10]

I'm still a novice at all of this but it seems that RFC 987 and RFC 1026
attempt to address the RFC822 <-> X.400 gateway issue.  That was the 
first place that I looked for the comfirm delivery header.  Unfortunately
it was one of those that was not supported, probably due to the lack of
capability within most RFC822 routers.

I for one would be very interested in the RFC822 <-> X.400 discussion.
My company is currently using RFC822 but we are committed to an X.25
network and X.400 mail in the near future.  As this transition takes place
we will need the gateway service.  I would rather that we do not go 
swimming against the tide as we do it but rather go with the standards of 
the community.

-- 
* Tom Moore                NCR Corporation  PCD-6              (513) 445-1373 *
* Consulting Analyst       1700 S. Patterson Blvd.         VOICEplus 622-1373 *
* Network Applications     Dayton, OH 45479          Tom.Moore@Dayton.NCR.COM *

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 12:54:44 EDT
Received: from janeb.cs.wisc.edu by mintaka.lcs.mit.edu id aa27056;
          18 Aug 89 12:40 EDT
Message-Id: <8908181640.AA05334@janeb.cs.wisc.edu>
Received: from localhost by janeb.cs.wisc.edu; Fri, 18 Aug 89 11:40:31 -0500
To: Brad Allen <splat!ulmo@ssyx.ucsc.edu>
Cc: Dave Crocker <dcrocker@ahwahnee.stanford.edu>, 
    Header-People@mc.lcs.mit.edu
Subject: Re: Confirm Delivery 
In-Reply-To: Your message of Thu, 17 Aug 89 18:08:55 -0700.
             <19890817.1808,00776@Splat.Aptos.CA.US> 
Date: Fri, 18 Aug 89 11:40:28 CDT
From: hagens@cs.wisc.edu



> Clearly to me, knowing that the mail made it to the user's actual mailbox is
> the least which should be required for such acknowledgement.

In my (very personal) opinion, that's the most that you should be given. Until
e-mail has "legal status", I don't don't think it is any of your business whether
I read my mail, delete it, or print it out to read later. This issue is clearly
a "religious war"!


> I have no idea what ISO X.400 says.
I am not well versed in X.400(88), but in 84, there were 2 kinds of confirmation
information: Delivery Confirmation -- which tells you that it made it to the
user's mailbox (MS or UA), and the Receipt Notificaion -- which tells you that
the user agent has delivered the mail to the actual user (i.e., printed it
on the screen). Both are optional. I believe in the former, but not in the
latter.

Rob Hagens

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 16:44:08 EDT
Received: from tis.llnl.gov by mintaka.lcs.mit.edu id aa00857;
          18 Aug 89 16:42 EDT
Return-Path: <kehres>
Received: by tis.llnl.gov (4.0/1.14.5-TIS)
	id AA01267; Fri, 18 Aug 89 13:20:11 PDT
Message-Id: <8908182020.AA01267@tis.llnl.gov>
Date: Fri, 18 Aug 89 13:20:09 -0800
From: Tim Kehres <kehres@tis.llnl.gov>
Subject: Re: Confirm Delivery
To: Tom Moore <ll-xn!scubed!coss!tmoore@eddie.mit.edu>
Cc: dcrocker@ahwahnee.stanford.edu, header-people@mc.lcs.mit.edu
Reply-To: ifip-gtwy-request@tis.llnl.gov
X-Orig-Date: Thu, 17 Aug 89 8:16:43 EDT
X-Orig-From: Tom Moore <ll-xn!scubed!coss!tmoore@eddie.mit.edu>
X-Orig-Message-Id: <8908171553.AA25406@SCUBED.COM>

In your message you write:
: 
> I for one would be very interested in the RFC822 <-> X.400 discussion.

There is currently another distribution list dedicated to these types
of discussions.   If you are interested in subscribing, please send a
note to me at:

	ifip-gtwy-request@tis.llnl.gov

As you have probably already noticed, the list can be accessed by sending
messages to:

	ifip-gtwy@tis.llnl.gov

In addition, the list archive is also located on tis.llnl.gov and can be
retrieved via anonymous ftp.

Regards,

Tim Kehres
ifip-gtwy-request@tis.llnl.gov

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 18:37:06 EDT
Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa02460;
          18 Aug 89 18:33 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA20248@EDDIE.MIT.EDU>; Fri, 18 Aug 89 18:33:02 EDT
Received: from splat.UUCP by ssyx.ucsc.edu (4.0/1.1)
	id AA21928; Fri, 18 Aug 89 15:32:48 PDT
Received: by Splat.Aptos.CA.US (smail2.5)
	id 00243; 18 Aug 89 15:21:50 PDT (Fri)
From: scritzifchisted ulmo qzutvchsxik <splat!ulmo@ssyx.ucsc.edu>
Date: Fri, 18 Aug 89 15:21:47 PDT
In-Reply-To: ssyx!hagens%cs.wisc.edu
       "Re: Confirm Delivery" (Aug 18, 11:35)
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Header-People@mc.lcs.mit.edu
Subject: Re: Confirm Delivery
Message-Id: <19890818.1521,00243@Splat.Aptos.CA.US>

Hagens wrote:
} > Clearly to me, knowing that the mail made it to the user's actual mailbox is
} > the least which should be required for such acknowledgement.
} 
} In my (very personal) opinion, that's the most that you should be given. Until
} e-mail has "legal status", I don't don't think it is any of your business
} whether I read my mail, delete it, or print it out to read later.
} This issue is clearly a "religious war"!

I think compromises need to made.  My compromise is that this is optional.
The compromise comes in that people like you have to admit to the world
that you're not someone who admits which mails you acknowledge and which
mails you don't; many people (like me) will have a predjiduce against
people who don't want to admit the simplest of things such as this.

However, it's something that can be implemented easily, has its obvious
uses, and therefore is hard to stop from being done.  Eventually,
we'll probably have to deal with this issue at our doorstep, so
why not today?

Now, whether or not it made it to the user's input mail processor is
not private information:  unless that user uses corrupt methods which we
in our society do not really accept (such as declaring certain gateways defunct
and making sure they are so, so that mail to them gets sent to the black
hole), then there's really no reason not to let us know that.  The reason
I want this to be mandatory for those mailers which support it is
for the purpose of automated reliable delivery.  There >are< errors all
over the place, and not checking your work once you're done is just asking
for more trouble than is necessary or acceptable.

Brad Allen
ulmo@splat.aptos.ca.us

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 23:34:48 EDT
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa07707;
          18 Aug 89 23:32 EDT
Received: by uunet.uu.net (5.61/1.14) 
	id AA03271; Fri, 18 Aug 89 23:31:59 -0400
Date: Fri, 18 Aug 89 23:31:59 -0400
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8908190331.AA03271@uunet.uu.net>
To: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu
Subject: Re: Confirm Delivery

Return receipts double the cost of sending mail.

They are almost never justified. The people who chose to
use them dont use them judiciously, they use them for EVERYTHING.

(Observations from experience with a mail system that permitted
return receipts)

Unless the return receipt visibly costs the sender something, count on them
either not using it or always using it.

The post office has the right model (charge extra for it). Unfortunately
there is no reasonable way to do this as most senders arent
paying for it someone else (NSF/DARPA/Their company is)


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Aug 89 11:06:10 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa15896;
          19 Aug 89 11:01 EDT
Received: by INFOODS id <000009B7046@INFOODS.MIT.EDU> ;
       Sat, 19 Aug 89 10:52:29 EDT
Date: Sat, 19 Aug 89 10:20:02 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  Re: Confirm Delivery
To: Rick Adams <rick@uunet.uu.net>
X-VMS-Mail-To: EXOS%"Rick Adams <rick@uunet.uu.net>"
Message-ID: <890819102002.000009B7046@INFOODS.MIT.EDU>
cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu

>Return receipts double the cost of sending mail.
> ...
>Unless the return receipt visibly costs the sender something, count on them
>either not using it or always using it.
>
>The post office has the right model (charge extra for it). Unfortunately
>there is no reasonable way to do this as most senders arent
>paying for it someone else (NSF/DARPA/Their company is)
  Rick has an interesting point here, and my experience is consistent
with his.  Several of the comments that have been made about the
desirability of return-receipts assume an error-prone environment,
presumably an error-prone environment in which, if the message does not
get through, no one bothers to send a rejection. 
  If this is primarily an Internet discussion, at least at the first 
level, it is worth noting that:
 -> SMTP is a virtual connection protocol, not a "you send to 
intermediary A, whom you hope will send it to intermediary B, whom..." 
type of protocol (such as those used on BITNET and UUCP).  The protocol 
already *requires* that error messages be produced, i.e., if the message 
is not delivered to the target mailbox, you are guaranteed to find out, 
at least within the fallibility parameters of the network.
 -> Consequently, confirmation from an MTA that it has delivered to a 
user mailbox or UA is redundant--you get confirmation of non-delivery 
anyway--unless you assume badly behaved hosts or more network 
fallibility than experience justifies.  And, if things were that badly 
behaved or fallible, you couldn't reliably get your confirmations back 
in any event.
 -> Since there are (deliberately, I assume) no Internet protocols that 
standardize the behavior of UAs or of exactly how mail is handled within 
a given host (X.400 goes a bit further in this direction), some of the 
distinctions among types of acknowledgements don't work.  If you say 
"tell me when the message is delivered by the MTA to the user's UA", an 
Internet host has the right to respond "what do you mean UA?  that is an 
interesting conceptual model, but we haven't layered things that way."
 -> Since the protocol uses virtual circuits, in the absence of MXs 
and/or source routes, the only place you need to ask "whose queue is 
this sitting in now" is your own sending host.  There is no need for 
equivalents of the BITNET facility to query the queues on an
intermediate machine or, presumably, its UUCP equivalent, since there
are no intermediate hosts.
 -> This means that, if one is using confirmations to monitor network 
transit (several of the suggestions have implied this), only the 
following cases are important for SMTP:
   o Your own machine opened a connection to a remote machine and 
successfully pushed the message down the connection.  That is purely a 
local issue, and requires no protocol changes.
   o The message is going through a mail exchange or relaying host, and 
you want to know when it has passed things on.  Dandy idea, but how are 
you supposed to tell which hosts are mail exchangers?  The idea of a 
universal name space is that you shouldn't have to know or need a way to 
find out.
   o The message is going through a mail exchanger / gateway into an 
unreliable network and you want to know if and when it gets to the 
ultimate target machine.  Seems like a good idea, but, from an Internet 
standpoint, probably best worked out--perhaps using some of the ideas 
suggested in the last few days--by having enough acknowledgement action 
between the mail exchanger MTA and the target machine MTA so that the 
mail exchanger can do its job (i.e., not violate the protocols) by 
returning accurate non-delivery messages when deliveries are not made.

This brings me back to Rick's point about costs.  There are really two 
separate issues, neither attractive.  As things now work, if anyone pays 
for an acknowledgement, it is likely to be the environment of the
receiver, not the environment of the confirmation-requestor.  That is 
not particularly desirable, to say the least, and makes a reason for not 
supporting confirmations: "I don't feel like paying for your amusement".
Rick's "who pays" point remains interesting if one could pass the cost 
of receipts on to the requestor.  It would be interesting to check with, 
e.g., MCIMail, where delivery receipt requests are optional and charged 
to senders, to find out who uses them, who doesn't, and in what patterns 
if they have that information.
  Also keep in mind that voluntary confirmation of receipt and 
understanding by the end user, in situations where you are unsure about
the network or user requires no protocol change.  We request, and get, 
such receipts all the time.  The procedure is to include, in the body 
of the message, something to the effect of "hey, Joe, if theis reaches 
you, please send me a confirming message, since I don't trust the 
system.  If I don't hear from you, I'll use the phone."  "Joe", wanting 
to avoid phone calls, usually manages to respond if the message is 
received.

So, let's step back a bit and answer the question "what are delivery 
conformations for, and which confirmations?" before worrying about how 
to do them technically.
  john klensin     Klensin@INFOODS.MIT.EDU


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Aug 89 11:52:51 EDT
Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa16375;
          19 Aug 89 11:50 EDT
Received: by ahwahnee.Stanford.EDU; Sat, 19 Aug 89 08:42:56 PDT
Date: Sat, 19 Aug 89 08:42:56 PDT
From: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
Subject: Re: Confirm Delivery
To: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu
Message-ID:  <8908191150.aa16375@mintaka.lcs.mit.edu>

The discussion about which kind of acks to generate is one that always
ensues, when one asks about whether to generate mail acks.  It is exactly
the kind of discussion that can cause 822-enhancement efforts to take more
than a year.

It is exactly the kind of discussion that I was trying to help avoid, buy
suggesting blindly adopting any of the X.400 functionality that can
easily be translated into 822 syntax and semantics.

The discussions certainly are important and often can be interesting.
They also are quite time-consuming.

Given that many of these discussion already have taken place among a
significant body of email-knowledgeable people, I suggest that the
intellectual exercises be moved out of the path of generating 822
upgrade specification.

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 12:01:19 EDT
Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa27648;
          20 Aug 89 11:55 EDT
Received: from UIAMVS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4197; Sun, 20 Aug 89 11:55:18 EDT
Received: (from R25@UIAMVS for MAILER@UIAMAIL via NJE)
         (KHENRY$M-5656;       6 LINES); Sun, 20 Aug 89 10:53:07 CDT
Date:    Sun, 20 Aug 89 10:53 CDT
From:     Ken Henry <KHENRYPA%UIAMVS.BITNET@cunyvm.cuny.edu>
To:        HEADER-PEOPLE@MC.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject:  Please add to HEADER-PEOPLE
Message-ID:  <8908201155.aa27648@mintaka.lcs.mit.edu>

SUBSCRIBE HEADER-PEOPLE Ken Henry


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 23:55:15 EDT
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa29951;
          20 Aug 89 17:32 EDT
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA06603; Sun, 20 Aug 89 14:31:52 PDT
Date: Sun, 20 Aug 89 14:31:52 PDT
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <8908202131.AA06603@garnet.berkeley.edu>
To: Header-People@MC.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu
Subject: Re: Confirm Delivery

In reply to:

  ... for the purpose of automated reliable delivery

There are various levels of acknowledgement possible. I do not trust
automated acknowledgements and never will.  The only valid reader to
drafter acknowledgement is a message sent by the addressee of original
message back to the drafter.  An automatically generated acknowledgement
could be generated by the wrong reader in a shared mailbox.

Bill Wells

Disclaimer. This opinion is my own and not that of my employer.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 23:55:23 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa29961;
          20 Aug 89 17:33 EDT
Received: by INFOODS id <000009BA072@INFOODS.MIT.EDU> ;
       Sun, 20 Aug 89 17:23:37 EDT
Date: Sun, 20 Aug 89 17:19:09 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  Re: Confirm Delivery
To: Dave Crocker <dcrocker@ahwahnee.stanford.edu>
X-VMS-Mail-To: EXOS%"Dave Crocker <dcrocker@ahwahnee.stanford.edu>"
Message-ID: <890820171909.000009BA072@INFOODS.MIT.EDU>
cc: @mintaka.lcs.mit.edu:header-people@MC.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu

Dave,
  My understanding of the X.400 ack structure (and I have studied the
red book version much more closely than the 88 version) is that "you
name it, they've got it".  They also have a strong model of user-code ->
UA -> MTA -> MTA -> UA -> user-code, and their definitions of what gets
sent to whom, when, are built on that model. 
   The quasi-philosophical discussion is needed because the mapping 
between "what X.400 supports" and SMTP/RFC822 is not obvious, especially
given that the Internet protocols leave behavior of local systems almost 
completely unspecified and unmodeled.
  john


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 09:33:38 EDT
Received: from gjetost.cs.wisc.edu by mintaka.lcs.mit.edu id aa07845;
          21 Aug 89 9:32 EDT
From: Marvin Solomon <solomon@cs.wisc.edu>
Message-Id: <8908211332.AA02826@gjetost.cs.wisc.edu>
Received: by gjetost.cs.wisc.edu; Mon, 21 Aug 89 08:32:35 -0500
Subject: Re: Confirm Delivery
To: Dave Crocker <@mc.lcs.mit.edu:dcrocker@ahwahnee.stanford.edu>
Date: Mon, 21 Aug 89 8:32:33 CDT
Cc: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu
In-Reply-To:  <8908191150.aa16375@mintaka.lcs.mit.edu>; from "Dave Crocker" at Aug 19, 89 11:27 am
X-Mailer: ELM [version 2.2 PL10]

Dave's right, this is one of those perennial discussions that come up
every few years and generate lots of heat but very little light.
Let me briefly summarize the X.400 situation and try to avoid value
judgetments.

X.400 distinguishes between "delivery notifications", "non-delivery
notifications", and "receipt notifications".  A delivery notification
is high-level ack.  It means that the message got to the destination
MTA (in Internet terms, you can think of that as roughly "destination host").
A non-delivery notification is an error report.  A reciept notification
means that it was actually delivered to the user.  The specs are rather
vague (deliberately, I suspect) on exactly what that means.  They
explain exactly how to request receipt notification and what one should
look like when sent, but don't explain the precise significance of
when they are sent.  To do so would involve standardizing aspecs of the
user interface--something the OSI specs studious avoid doing.  So far as I
know, receipt notification is seldom implemented in "real" systems, but I
haven't taken a scientific survey.

The sender of a message can request any combination of notifications--or none
at all--and the specification is on a per-recipient basis.  It is also
possible to indicate whether the contents of the original message should be
included in a non-delivery notification.  Notifications are flagged as
different "types" of messages.  When the original message is returned
as part of a notification, it is delimited so that it is possible
to unambiguously extract it from the notification.  Message id's are
used to correlate notifications with the messages to which they
pertain.

In effect 822/821 mandates "non-deliverly notification: always" and
"other notifications: never".  There has been some debate about "return
of contents".  As I recall, the specs are pretty vague about this.
Most implementations include the contents, but may truncate it if it is
"very long".  At least one implementation used to send the notification
with an indication that "the message follows under separate cover".  That
was extremely unpopular, since it was almost impossible to correlate the
notification with the returned contents.

My experience with naive users is that if they have ever used a mail
system with some sort of notifications, they love this feature and
cannot understand why Internet mail doesn't support it.
When I try to find out whether it is delivery notification or receipt
notification they really want, they have a lot of trouble understanding
the distinction, but I get the general impression that it is delivery
notification they really like, because they don't really trust the
mail delivery system.  I could speculate further on this issue, but
I'd like to stick to mechanism and avoid policy for now.
I will simply say that both kinds of notification have their uses.

I've listed the essential features of X.400 wrt notifications in the
third paragraph above.  822/821 currently supports little of this
mechanism.  Some parts could be added by extensions or even simple
conventions.  For example,

o  there is already an rfc suggesting encapsulalion techniques for embedding
   one message in another
o  a special header field or special string in the subject could be used
   to indicate that a message is a notification
o  message id's exist, but there may be some additional standardization
   required concerning how they are used for notifications

The one change that would require major additions to the spec is the
ability to specify options on a per-recipient basis.  Items in the
X.400 equivalent of To: and From: fields are called "originator/recipient
names" (O/R names).  An O/R name is a record that contains not only
a designation of a mailbox, but also addtional information, including
an indication of the kind of notifications desired.  (It is also used
to record in a message which recipients have already had copies delivered
to them.)

Back in the early days of CSNET, we encountered another place
where per-recipient info was needed:  as a check on cached mappings
from CSNET id to address.  At the 822 level, there seemed to be
only two possible approaches, neither very attractive.  We could
list all the id's in a separate header field and try to match them
up with addresses elsewhere in the header, or we could stuff the id
in the "phrase" or comment part of an address.  At the 821 (SMTP) level,
it was even harder.  I approached the "mail police" for a solution.
I proposed that an address become a sort of "property list".  My proposal
was very cooly received.  I believe we finally settled on including
the id in an 822 comment, despite strong warnings from Dave Crocker
(he felt the spec gave no reassurance that comments wouldn't be
altered or deleted).

I can't resist ending with a little sermon.  Some Internet folks 
write off all OSI developments as junk.  It is true that some OSI 
standards are garbage, many contain some garbage, and the presentations of
nearly all are unreadable garbage.  The political and religious wars in OSI
land make the Internet community look like a love-in.  Nonetheless, there are
some very good ideas there, and those who are serious about advancing the
state of the art should take the trouble to learn about them.
In the case of mail, I think that X.400 is fundamentally better than
822.  You could try to stuff bits of X.400 functionality into 822, but
in the short term I don't think it would work (most "822" implementors
haven't even read rfc822!) and in the long term I don't think there's
much point to it.  A '69 Chevy Ipala with tail fins isn't a very
modern vehicle, but it will get you accross country better than a horse.
...And adding wheels to the horse won't change that.

	Marvin Solomon
	Computer Sciences Department
	University of Wisconsin, Madison WI
	solomon@cs.wisc.edu, uwvax!solomon

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 11:55:56 EDT
Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa26854; 18 Sep 89 11:49 EDT
Received: by p.lanl.gov (5.54/1.14)
	id AA03698; Mon, 18 Sep 89 09:04:39 MDT
Received: by sneezy.lanl.gov (4.0/5.17)
	id AA02376; Mon, 18 Sep 89 09:04:34 MDT
Date: Mon, 18 Sep 89 09:04:34 MDT
From: "C. Philip Wood" <cpw%sneezy@lanl.gov>
Message-Id: <8909181504.AA02376@sneezy.lanl.gov>
To: header-people@mc.lcs.mit.edu
Subject: What is the correct way to set up mailing lists?

When I mail to various lists, I often get a bunch of replys from
MAILER-DAEMON, Darth-Vador or someone like him.

I get the impression that there is a correct way to set up lists so that
the maintainter of the list will get errors rather than the list itself.

Since, I have a few local lists myself, I would like to do it right the
second time.

1. Where is the inter-relationship of the following aliases defined:

	<group>-request
	owner-<group>
	<group>
	
2. Why are there both <group>-request and owner-<group>?

3. Are there more aliases needed to handle a mail group correctly? 
	
4. Is the following a good idea for sublists:

	<group>: "|/usr/lib/sendmail -oi -f<group>-request <group>-sublist"
	<group>-sublist: u1, u2, ... uN
	


Phil Wood
Los Alamos National Laboratory


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 13:39:08 EDT
Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa28412; 18 Sep 89 13:26 EDT
Received: by p.lanl.gov (5.54/1.14)
	id AA07591; Mon, 18 Sep 89 11:26:15 MDT
Received: by sneezy.lanl.gov (4.0/5.17)
	id AA00310; Mon, 18 Sep 89 11:26:09 MDT
Date: Mon, 18 Sep 89 11:26:09 MDT
From: "C. Philip Wood" <cpw%sneezy@lanl.gov>
Message-Id: <8909181726.AA00310@sneezy.lanl.gov>
To: header-people@mc.lcs.mit.edu
Subject: Re: correct way to set up mailing lists.

What is the correct way to handle the following, which I got in
in response to the original posting about how to set up mailings lists?

Phil

----- Begin Included Message -----

From @mc.lcs.mit.edu:Mailer-Daemon@unix.sri.com Mon Sep 18 11:03:14 1989
Received: from p.lanl.gov by sneezy.lanl.gov (4.0/5.17)
	id AA00303; Mon, 18 Sep 89 11:03:11 MDT
Received: by p.lanl.gov (5.54/1.14)
	id AA07068; Mon, 18 Sep 89 11:03:05 MDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27697;
          18 Sep 89 12:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 12:36:11 EDT
Received: from UNIX.SRI.COM by mintaka.lcs.mit.edu id aa27582;
          18 Sep 89 12:29 EDT
Received: by unix.sri.com (4.0/SMI-4.0)
	id AB21391; Mon, 18 Sep 89 09:27:40 PDT
Date: Mon, 18 Sep 89 09:27:40 PDT
From: Mail Delivery Subsystem <Mailer-Daemon@unix.sri.com>
Subject: Returned mail: Service unavailable
Message-Id: <8909181627.AB21391@unix.sri.com>
To: @mc.lcs.mit.edu@LANL.GOV, cpw@sneezy.LANL.GOV
Mmdf-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Status: R

   ----- Transcript of session follows -----
mail: /var/spool/mail/knutsen has more than one link or is a symbolic link
Mail saved in dead.letter
554 <knutsen@unix.sri.com>... Service unavailable

   ----- Unsent message follows -----
Return-Path: <@mc.lcs.mit.edu,@p.lanl.gov:cpw%sneezy@lanl.gov>
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by unix.sri.com (4.0/SMI-4.0)
	id AA21384; Mon, 18 Sep 89 09:27:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27120;
          18 Sep 89 12:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 11:55:56 EDT
Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa26854; 18 Sep 89 11:49 EDT
Received: by p.lanl.gov (5.54/1.14)
	id AA03698; Mon, 18 Sep 89 09:04:39 MDT
Received: by sneezy.lanl.gov (4.0/5.17)
	id AA02376; Mon, 18 Sep 89 09:04:34 MDT
Date: Mon, 18 Sep 89 09:04:34 MDT
From: "C. Philip Wood" <cpw%sneezy@lanl.gov>
Message-Id: <8909181504.AA02376@sneezy.lanl.gov>
To: header-people@mc.lcs.mit.edu
Subject: What is the correct way to set up mailing lists?

When I mail to various lists, I often get a bunch of replys from
MAILER-DAEMON, Darth-Vador or someone like him.

I get the impression that there is a correct way to set up lists so that
the maintainter of the list will get errors rather than the list itself.

Since, I have a few local lists myself, I would like to do it right the
second time.

1. Where is the inter-relationship of the following aliases defined:

	<group>-request
	owner-<group>
	<group>
	
2. Why are there both <group>-request and owner-<group>?

3. Are there more aliases needed to handle a mail group correctly? 
	
4. Is the following a good idea for sublists:

	<group>: "|/usr/lib/sendmail -oi -f<group>-request <group>-sublist"
	<group>-sublist: u1, u2, ... uN
	


Phil Wood
Los Alamos National Laboratory


----- End Included Message -----





Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 07:42:12 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa17923;
          21 Sep 89 7:38 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8690; Thu, 21 Sep 89 07:37:12 EDT
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 2321; Thu, 21 Sep 89 07:37:11 EDT
Received: from ODEN by brage.qz.se; Thu, 21 Sep 89 12:18 +0200
Date: 21 Sep 89 10:31 +0200
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: Re: correct way to set up mailing lists.
To: header-people <HEADER-PEOPLE@mc.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <449434@QZCOM>
In-Reply-To: <8909181726.AA00310@sneezy.lanl.gov>
 <8909181504.AA02376@sneezy.lanl.gov>
bcc:         "C. Philip Wood" <cpw@sneezy>

Perhaps there should be an RFC to describe how a good mailing
list expander in the SMTP-based domain should work?

Here are some comments on what should be in it:

(1) SMTP-sender should be set to the name of the maintainer of
the list. Not the list itself, not the original author.

(2) From: and Message-ID should not be altered.

(3) If the message lacks a Message-ID, such an Id should be added,
computed by hashing the author name, date and text. (The advantage
with hashing is that if another mail expander expands the same
message, it should get the same hashed value for the ID.)

(4) The name of the list should be added in a standardized format
to the Received: part of the header, so that this can be used
for loop control if the same message comes around once more to
the same list. (The advantage with this kind of loop control,
is that it can be translated, via a gateway, to the corresponding
loop control in X.400).

Also, the RFC should say something about the proper activity
of a User Agent or Postmaster Agent when receiving a message
from a list. Such as that non-delivery messages should be sent
to the SMTP-sender, not the From-field-name, etc.

I am willing to supply a proposal for the Message-ID hashing
algorithm, but cannot do the whole work.
<


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 11:08:00 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa20265;
          21 Sep 89 11:06 EDT
Received: by INFOODS id <00001472062@INFOODS.MIT.EDU> ;
       Thu, 21 Sep 89 10:58:13 EDT
Date: Thu, 21 Sep 89 10:50:16 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  Re: correct way to set up mailing lists.
To: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
X-VMS-Mail-To: EXOS%"Jacob Palme QZ <JPALME%com.qz.se@mitvma>"
Message-ID: <890921105016.00001472062@INFOODS.MIT.EDU>
cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu

>(1) SMTP-sender should be set to the name of the maintainer of
>the list. Not the list itself, not the original author.
   Already in the forthcoming Host Requirements RFC.

>(2) From: and Message-ID should not be altered.
   Ditto, albeit with some qualifications about gateways.

>(3) If the message lacks a Message-ID, such an Id should be added,
>computed by hashing the author name, date and text. (The advantage
>with hashing is that if another mail expander expands the same
>message, it should get the same hashed value for the ID.)
  Only if we can all agree on a hashing algorithm for this purpose that 
is completely machine-independent.  Most of the ones in active use 
aren't.

>Also, the RFC should say something about the proper activity
>of a User Agent or Postmaster Agent when receiving a message
>from a list. Such as that non-delivery messages should be sent
>to the SMTP-sender, not the From-field-name, etc.
  It has ALWAYS been the rule that SMTP error messages are sent to the 
SMTP (RFC821) sender, not any of the addresses in the header.  While 
there have been some ill-behaved SMTP MTAs and UAs, most of the problems 
have been the result of gateways that don't bother to capture the RFC821 
From field and then use it properly.  The forthcoming Host Requirements 
RFC further clarifies and stresses this point.

>I am willing to supply a proposal for the Message-ID hashing
>algorithm, but cannot do the whole work.
  Seems like a large fraction of the work is done already.  What is 
needed is correct and consistent application of existing protocols.

 John Klensin, Klensin@INFOODS.MIT.EDU


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 22:55:18 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa29474;
          21 Sep 89 22:49 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1567; Thu, 21 Sep 89 22:48:12 EDT
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 3397; Thu, 21 Sep 89 22:48:11 EDT
Received: from ODEN by brage.qz.se; Fri, 22 Sep 89 04:33 +0200
Date: 22 Sep 89 02:51 +0200
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: RE:  Re: correct way to set up mailing lists.
To: header-people <HEADER-PEOPLE@MC.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <449731@QZCOM>
In-Reply-To: <890921105016.00001472062@INFOODS.MIT.EDU>

> From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
>
> >Also, the RFC should say something about the proper activity
> >of a User Agent or Postmaster Agent when receiving a message
> >from a list. Such as that non-delivery messages should be sent
> >to the SMTP-sender, not the From-field-name, etc.
>   It has ALWAYS been the rule that SMTP error messages are sent to the
> SMTP (RFC821) sender, not any of the addresses in the header.  While
> there have been some ill-behaved SMTP MTAs and UAs, most of the problems
> have been the result of gateways that don't bother to capture the RFC821
> From field and then use it properly.  The forthcoming Host Requirements
> RFC further clarifies and stresses this point.
>
> >I am willing to supply a proposal for the Message-ID hashing
> >algorithm, but cannot do the whole work.
>   Seems like a large fraction of the work is done already.  What is
> needed is correct and consistent application of existing protocols.

Yes, certainly. Much of the text in an RFC on mailing lists will
be already known and by many implementors accepted principles. But
by combining this knowledge in an RFC, we will increase the likelihood
that implementations will handle distribution lists in a proper way.

For example, I did receive non-deliveries on the message you are replying
to, non-deliveries which should have been sent to the header-people
maintainer.

Some of my proposals, such as putting the history of which lists
a message hast passed in the "Received:" fields is not so common,
but would be very valuable in co-working with X.400, since X.400
has such a trace and puts large emphasis on its use.

Here are some additional points which might be inclunded in an
RFC on distribution lists:

(a) The custom of adding "-request" at the end of a list name
in order to address its maintainer.

(b) An automatic protocol for adding and deleting a user from
a list by sending mail to "-request" or perhaps "-autoserver"
to distinguish between messages to be handled by a human and
those to be handled by an automatic server. LISTSERV in BITNET
already has such a protocol, the AMIGO MHS+ group defined
an alternative, other protocol ideas may exist.

(c) An automatic protocol for requesting sending/resending
of messages from a list archive, if such exists, from a
server which could be the list name with "-archive" added
at the end?

This protocol could be useful (i) if you lost a message from
a list (ii) if you are new and want to read previous messages.

(d) A RFC822-heading field, added by the list, giving a sequence
number of all messages distributed by the list. This sequence
number can be used by recipient UA-s to automatically recognize
that they have lost messages, and automatically request renewed
sending using the protocol (c) above.



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 01:45:59 EDT
Received: from WSMR-SIMTEL20.ARMY.MIL by mintaka.lcs.mit.edu id aa02474;
          22 Sep 89 1:41 EDT
Date: Thu, 21 Sep 1989  23:40 MDT
Message-ID: <WANCHO.12528185964.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
To:   Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Cc:   header-people <HEADER-PEOPLE@MC.lcs.mit.edu>, 
      WANCHO@wsmr-simtel20.army.mil
Subject: correct way to set up mailing lists.
In-reply-to: Msg of 22 Sep 89 02:51 +0200 from Jacob Palme QZ <JPALME%com.qz.se at mitvma.mit.edu>

Jacob,

I believe that the apparently logical convention of listname-REQUEST,
which has now been around some 13 years, was a mistake.  It has been
far too easy to simply forget to add the -REQUEST, mostly in haste if
not in ignorance, and accidentally send an administrative message to
an unmoderated list.

I propose to break this traditional convention and move to a prefixed
form of anything-listname, such as REQUEST-listname.  Get the first
part right and the second part will naturally follow, mainly because
you have to *think* before you act.  Not so with the current form
because you are mostly concentrating on getting the listname@hostname
right.

Also, please consider where rejection notices should be sent in the
case of lists which redistribute to secondary or sublists.  The main
list maintainer usually does not have ability nor the desire to repair
sublist problems.  When passing through a mailer which explodes a
sublist, it should be required that the mailer replace the RFC-821
From line with one pointing to the sublist maintainer, or, in a
non-SMTP environment, make the appropriate header modifications which
have similar meaning.

--Frank

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 07:09:37 EDT
Received: from shamash.cdc.com by mintaka.lcs.mit.edu id aa07265;
          22 Sep 89 7:06 EDT
Received: by shamash.cdc.com (5.59/CDC1.2)
	id AA23522; Fri, 22 Sep 89 05:59:03 -0600
Return-Path: <kehres>
Received: by jpntok.cdjapan.co.jp (5.51++/1.14.7-TIS)
	id AA28426; Fri, 22 Sep 89 19:07:53 JST
Message-Id: <8909231007.AA28426@jpntok.cdjapan.co.jp>
Date: Fri, 22 Sep 89 19:07:50 -1500
From: Tim Kehres <kehres@tis.llnl.gov>
Subject: Re: correct way to set up mailing lists.
To: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
Cc: JPALME%com.qz.se@mitvma.mit.edu, HEADER-PEOPLE@mc.lcs.mit.edu, 
    WANCHO@wsmr-simtel20.army.mil
X-Orig-Date: Thu, 21 Sep 1989 23:40 MDT
X-Orig-From: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
X-Orig-Message-Id: <WANCHO.12528185964.BABYL@WSMR-SIMTEL20.ARMY.MIL>

In your message you write:
: 
+ I propose to break this traditional convention and move to a prefixed
+ form of anything-listname, such as REQUEST-listname.  Get the first
+ part right and the second part will naturally follow, mainly because
+ you have to *think* before you act.  Not so with the current form
+ because you are mostly concentrating on getting the listname@hostname
+ right.

I would vote not to do this, primarily because in the process you will
break a lot of the software currently running on the internet.  The 
idea is sound, but since there is already a mechanism in place to handle
this situation, I don't consider the trade-off to be a good one.

+ Also, please consider where rejection notices should be sent in the
+ case of lists which redistribute to secondary or sublists.  The main
+ list maintainer usually does not have ability nor the desire to repair
+ sublist problems.  When passing through a mailer which explodes a
+ sublist, it should be required that the mailer replace the RFC-821
+ From line with one pointing to the sublist maintainer, or, in a
+ non-SMTP environment, make the appropriate header modifications which
+ have similar meaning.

I have a filter program running on tis.llnl.gov now for close to two
years that does the required header munging for sendmail.  For distribution
lists, it automatically adds the -request address for the Sender: and
Return-Path: fields.  It has saved a *lot* of aggrivation in running
the mhsnews and ifip-gtwy lists.  In addition, I am currently updating
the program to filter out the Return-Receipt: fields.  Depending on how
the filter is invoked, the Return-Receipt field will either be removed
or changed to point to the list maintainer.  I realize that the Return-Receipt
field is not "official" RFC822, but there are enough sendmail sites out
there that will respond with a delivery notification message, that without
the added capability it is impossible to keep the addresses in the list
private.

If there is any interest in this program, please let me know.  If the
interest is great enough, I'll go ahead and make it generally available.

Regards,

Tim Kehres

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 10:34:29 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa09663;
          22 Sep 89 10:31 EDT
Received: by INFOODS id <00001975061@INFOODS.MIT.EDU> ;
       Fri, 22 Sep 89 10:23:45 EDT
Date: Fri, 22 Sep 89 09:44:07 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:  RE:  Re: correct way to set up mailing lists.
To: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
X-VMS-Mail-To: EXOS%"Jacob Palme QZ <JPALME%com.qz.se@mitvma>"
Message-ID: <890922094407.00001975061@INFOODS.MIT.EDU>
cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu

I want to stress that I was not opposing such an RFC.  Indeed, I think
it would be extremely useful.   Instead, I was trying to suggest that 
  (1) it would not need to contain very much that was controversial, 
since several of the original comments (especially error handling) are 
already parts of the standards.
  (2) because there are clear statements in these areas in the existing
protocols, the effort would be less large than might initially be 
supposed.

However, part of the historical problem with defining an inter-network 
mail distribution protocol is that these messages pass through several 
networks, each with its own variations on headers, procedures, and 
protocols.  Each has also tended to behave as if it is the center of the 
universe, with other networks being "similar to" its rules.  Since, for 
example, USENET newsfeeds are different in concept from Internet
distribution lists and neither is quite isomorphic with what LISTSERV
does, one needs ways to translate concepts in an appropriate way, not 
just make statements about protocols in the protocol-language of a 
single network.

Again, just as an example, it is sad that non-delivery messages from 
header-people are still delivered to message originators, not to the 
list maintainer.  But it is not surprising, given the number of odd 
gateways and translations through which the messages pass.  We can agree 
that errors go to the address in the RFC821 "From" field (referred to as
the SMTP-sender field in earlier messages), and agree that the Internet
protocols require that.  The Host Requirements RFC insists that the
RFC821 From field be recorded in a final Received header so that UAs
processing the RFC822 headers can generate error messages to the right
place (this is just a clarification of a long-standing rule).
   But, of necessity, where the Internet (in the narrow sense) stops, so
does RFC821 and HRRFC.  Even RFC822 stops at that boundary: BITNET and
UUCP use mail header arrangements that are similar to RFC822, but that
are not strictly RFC822. 

So, messages routinely pass from the Internet, through a gateways onto
other well-known networks, into other modes for handling distribution
lists, and thence through other gateway into private nets with their own
arrangements and it is very difficult to enforce the rules as 
information gets lost and other information is made up.  If, some 
intermediary drops the RFC821 From field because it discards the 
envelope, then it is going to be difficult for something further 
downstream to generate a correct error message to the correct place.  

No amount of protocol specifying is going to cure this problem. If the
gateway passed the correct information along, it is rarely useful to
heap abuse on the gateway maintainer, since they typically have only 
very limited control over systems on the far end of the gatewayed
network.  And the far-end system is often behaving reasonably according 
to its understanding of the rules of the network on which it operates.

So, I suggest that the interesting and hard part of a distribution list 
RFC effort is specifying, and getting agreement on, the reversible 
transformations and mappings as the message, and its envelope and 
headers, move through a series of redistributions, on a series of 
heterogeneous networks, each with similar, but not identical, header and 
envelope rules.

We don't even have a good (in the sense of completeness and specificity) 
set of "what gateways are supposed to do with *mail* between X and Y" 
documents yet.  In particular, we don't have a published one between the 
Internet and BITNET/EARN/NETNORTH/etc., partially because we continue to 
pretend that mail on these systems is identical.

  John Klensin
  Klensin@INFOODS.MIT.EDU


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 11:12:51 EDT
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10360;
          22 Sep 89 11:07 EDT
Received: by INFOODS id <00001994031@INFOODS.MIT.EDU> ;
       Fri, 22 Sep 89 11:00:13 EDT
Date: Fri, 22 Sep 89 10:57:02 EDT
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: RE:   correct way to set up mailing lists.
To: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
X-VMS-Mail-To: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
Message-ID: <890922105702.00001994031@INFOODS.MIT.EDU>
cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu

>I believe that the apparently logical convention of listname-REQUEST,
>which has now been around some 13 years, was a mistake.  It has been
>far too easy to simply forget to add the -REQUEST, mostly in haste if
>not in ignorance, and accidentally send an administrative message to
>an unmoderated list.
>
>I propose to break this traditional convention and move to a prefixed
>form of anything-listname, such as REQUEST-listname.  Get the first
>part right and the second part will naturally follow, mainly because
>you have to *think* before you act.  Not so with the current form
>because you are mostly concentrating on getting the listname@hostname
>right.

Frank,
  I think you are right, but it is too late.  It is already getting very 
difficult, with BITNET hosts assuming domain-style names, to remember 
which lists should be sent administrative messages to xxx-request and 
which ones require such messages to be sent in specific form to the list 
or to some LISTSERV.  At least there, if one can figure out which 
network the host is really on (something I shouldn't have to do), it is 
possible to make educated guesses.  But, to know which Internet lists 
use xxx-listname and which ones use listname-xxx is likely to be 
impossible.
  And, based on the things that creep out onto unmoderated lists, if 
someone tries listname-request and it fails, the next attempt is going 
to be a message to the list asking where one sends messages to 
desubscribe.  It happens anyway, much too often, and a change in 
conventions would tend to reinforce it.
  I think I'm opposed to it, but, if you wanted a semi-foolproof 
convention that could be implemented today, you would specify something 
like the following:
  1) For this list, all messages must start with a single line 
consisting of, say, an asterisk followed by a keyword.  If that line 
does not appear as the first text line in the message, the message will 
be returned to the sender, with a polite, but tedious, error message.
  2) The first line keyword would be either:
   *distribute
       in which case the message was intended to go out to the list or
   *request
       in which case the message was intended for administrative 
processing or some sort.
    You could define additional keywords as needed.

Now, again with the understanding that I'm not sure I like this 
particular idea, it accomplishes several things:
  a) The list management activity is handled by list management fields 
within the list-message, not by unofficial conventions or by trying to 
overload headers.
  b) If Jacob can talk you into it, the initial list exploder for lists 
operating with this convention could generate a special message id as a 
second *-line.  Since this would not depend on header or envelope 
management, it could be preserved across all sorts of network-induced 
transformations.  More broadly, this could be the beginning of saying 
"mailing lists and similar things are not mail, they just use mail 
facilities as a transport medium".
  c) It has the right sort of error hierarchy behavior, i.e.,
   - someone who understands and follows the rules gets smooth behavior.
   - someone who tries sending to the wrong address (e.g., 
listname-request) gets automatic 'no addressee' messages or, if one 
feels inclined, a message that explains the correct procedure.
   - someone who sends administrative requests to the list without 
understanding the conventions can get a long, and automatically 
generated, reply explaining what should be done.

>When passing through a mailer which explodes a
>sublist, it should be required that the mailer replace the RFC-821
>From line with one pointing to the sublist maintainer, or, in a
>non-SMTP environment, make the appropriate header modifications which
>have similar meaning.
   Yep.  The sublist is where such a message is originating, after all, 
regardless of where it copied it from.  However, the occasional 
counterargument, which has to do with the sublist tracking down trash 
that might have originated from the original list, reinforces the value 
of building carefully structured Received fields any time the RFC821 
From field is altered.

   --john

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Sep 89 09:23:45 EDT
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa28817;
          25 Sep 89 9:19 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7863; Mon, 25 Sep 89 09:18:26 EDT
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 0888; Mon, 25 Sep 89 09:18:24 EDT
Received: from ODEN by brage.qz.se; Mon, 25 Sep 89 14:13 +0200
Date: 23 Sep 89 10:13 +0200
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: Re: correct way to set up mailing lists.
To: header-people <HEADER-PEOPLE@MC.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <449949@QZCOM>
In-Reply-To: <8909231007.AA28426@jpntok.cdjapan.co.jp>

In order to ensure that non-delivery-notifications are sent to
the list maintainer, and not to the author, non-delivery-notifications
should be sent to the SMTP-sender. The "From:" field should stay
as the original author.

If a message is expandet by successive sublists, each sublist
should change SMTP-sender to the latest sublist maintainer.

There is one problem with this. In an old, today mostly discarded,
protocol used in BITNET, there was no SMTP information, only
RFC822 information. But this old protocol is not used very much
in BITNET now, BSMTP is used instead.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Sep 89 13:51:22 EDT
Received: from tis.llnl.gov by mintaka.lcs.mit.edu id aa22644;
          29 Sep 89 6:26 EDT
Return-Path: <kehres>
Received: by tis.llnl.gov (4.0/1.14.5-TIS)
	id AA08251; Fri, 29 Sep 89 02:39:56 PDT
Message-Id: <8909290939.AA08251@tis.llnl.gov>
Date: Fri, 29 Sep 89 02:39:54 -0800
From: Tim Kehres <kehres@tis.llnl.gov>
Subject: Mailing List Software
To: Header People Distribution List <header-people@mc.lcs.mit.edu>

A week or so back I volunteered some software to assist with the
modification of header fields when processing mailing lists with
sendmail.  Since that time I have received several requests for
this code.  I still have about one week of cleanup (writing a
man page and cleaning up the M4 macros that go with it) prior to
being able to distribute the code.  Unfortunately, I will not be
available to do this cleanup until after I return to the States
in late October (I leave Tokyo tomorrow for approx 3 1/2 weeks).
I am currently anticipating that the code will be available near
the first of November, at which time I will send a message 
indicating how the code can be obtained.

Regards,

Tim Kehres

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Oct 89 21:51:15 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19686;
          11 Oct 89 21:14 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA12095; Wed, 11 Oct 89 21:12:01 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 89 00:30:59 GMT
From: Jon Boede <mailrus!cs.utexas.edu!ut-emx!walt.cc.utexas.edu!jon@purdue.edu>
Organization: The People's Republic of Austin, Texas
Subject: Date -> time(2)
Message-Id: <19481@ut-emx.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Rather than re-invent the wheel, I'm looking for a piece of code that converts
the Date field of messages into a nice time(2) style long integer that my C
program can use.  The messages envelopes on the other side of a gateway I'm in
charge of use a long instead of the ASCII date -- currently we're using the
date the letter arrived at the gateway as the "Date:" which, given the speed
of most Internet letters, is pretty good... but, not always.

The variety among Date: lines is even more frightening than From: lines. :-)

If anyone has a piece of code written, please mail me.  If anyone WANTS this
code, mail me as well... I'll have to write it if I don't get somebody else's,
and I'll be happy to re-distribute.

Please mail to jon@bodedo.ucm.org as I hardly ever get a chance to read news
these days (sigh).

Thanks!
-- -  -   -    -     -      -       -        -         -          -
Jon Boede					jon@bodedo.ucm.org
7117 Wood Hollow #726		...!{uunet,texbell}!cs.utexas.edu!bodedo!jon
Austin, TX  78731-2548				+1 512 346-3142
	"People who are incapable of making decisions are
	 the ones that hit those barrels at freeway exits"

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Oct 89 15:48:28 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04377;
          12 Oct 89 15:45 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00563; Thu, 12 Oct 89 14:29:01 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 89 15:42:52 GMT
From: Henry Spencer <jarvis.csri.toronto.edu!utgpu!utzoo!henry@rutgers.edu>
Organization: U of Toronto Zoology
Subject: Re: Date -> time(2)
Message-Id: <1989Oct12.154252.23144@utzoo.uucp>
References: <19481@ut-emx.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <19481@ut-emx.UUCP> jon@walt.cc.utexas.edu (Jon Boede) writes:
>Rather than re-invent the wheel, I'm looking for a piece of code that converts
>the Date field of messages into a nice time(2) style long integer that my C
>program can use...

Check out the getdate() function, shipped with most versions of news
software.  It's the de-facto standard for such things.  It is not perfect,
but pretty good.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Oct 89 16:09:24 EDT
Received: from mcs.nlm.nih.gov by mintaka.lcs.mit.edu id aa21503;
          13 Oct 89 16:03 EDT
Received: from ncbi.nlm.nih.gov by mcs.nlm.nih.gov (5.59/1.14)
	id AA10006; Fri, 13 Oct 89 16:04:24 EDT
Received: by tech.nlm.nih.gov (4.0/SMI-4.0)
	id AA07572; Fri, 13 Oct 89 16:05:11 EDT
Date: Fri, 13 Oct 1989 16:05:10 EDT
From: Peter Karp <pkarp@ncbi.nlm.nih.gov>
To: header-people@mc.lcs.mit.edu
Subject: mail servers
Message-Id: <CMM.0.88.624312310.pkarp@tech.nlm.nih.gov>

I'm looking for information on mail server programs -- the kind
of program that can process queries from people via mail.  For
example, I might mail a message to such a program asking it to
send me a piece of software.  If you know of such a server that
I can get hold of, that runs under Unix, please let me know.

Peter

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Oct 89 23:29:44 EDT
Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa26809;
          13 Oct 89 23:20 EDT
Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP
	id AA10416; Fri, 13 Oct 89 23:19:59 EDT
Message-Id: <8910140319.AA10416@MIT.EDU>
Date:     Fri, 13 Oct 89 22:21:50 CDT
From: Rich Zellich <zellich@stl-07sima.army.mil>
To: Peter Karp <pkarp@ncbi.nlm.nih.gov>
Cc: header-people@MC.lcs.mit.edu
Subject:  Re:  mail servers

If nothing else, under Unix you can easily put together a combination of
shell scripts and optionally a small program to unpack file-names from
message bodies, put the requested file in the body of an outgoing message,
and send it back to the requestor.  I did just that here, before we got
all our machines hooked together on an Ethernet, and it worked just fine;
it would even understand requests for Internet-resident files, FTP them
onto the gateway machine, and then mail them internally to the requestor
(I had a setup requiring a dedicated "ftpmail" account on each of our
machines, but with MMDF it's not really necessary since I can specify
a filter to pick out mail with certain Subject entries and route them
to a server from any account).

I can send you what I did if you want, but it's really pretty trivial.

Cheers,
Rich

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 14:24:55 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03337;
          21 Oct 89 14:19 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA13430; Sat, 21 Oct 89 12:37:06 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 Oct 89 18:33:45 GMT
From: Ed Wright <zehntel!edw@bloom-beacon.mit.edu>
Organization: 10*E12 Dyne & Zehn and The Art of ATE
Subject: ForSale Shaved Ice Sno Cone Machine and Supplies
Message-Id: <1864@zehntel.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


        Please reply to this posting by Phone directly to:
                      Mohammed H. Kahn
           Home 408 227 1936      Work 415 966 2560
      mail replies (via this acct) will NOT reach the seller

                            For Sale
                 Swan SI-100 Shaved Ice Machine.
  All accessories included such as spare blades, foot pedal, plastic
  syrup bottles, amber/black pour spouts.
  Paid over $1300.00 for the machine and used for only three months.
  Asking $895.00 and will include over $1000.00 (at retail) worth
  of syrups to go with machine.
  This is a high profit margin item.
  Approx Size  36" high, 12" wide, 12" deep, Weight 70LBS
  
  To answer ALL your questions:
  What color is it,  Why is it being sold, When can I make a sample
  sno cone, How will I get it, Can you ship it, will he dicker on
  the price why is the sky blue?
  
  Beats me ! I have never seen it! Call Mohammed At The number(s) above
  Mohammed is an aquaintance, seems like a nice enough guy, and I am 
  posting this as a favor. My only research was to validate that 
  he does not sell stuff for a living. ie I assured myself that 
  this is personal property, and not a business venture.
  Tha tha tha thats all folks
  
 UUCP Path      ucbvax  or  sun  or varian  !zehntel!edw       KA9AHQ
Life Is Hard ....  Can't get to heaven on roller skates,
Can't take a taxicab to Timbuktu.
                                       ... Timbuk3

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 19:24:26 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05465;
          21 Oct 89 19:16 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA20410; Sat, 21 Oct 89 19:15: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: 21 Oct 89 08:05:28 GMT
From: "John R. Galloway Jr." <snorkelwacker!apple!jrg@eddie.mit.edu>
Organization: Galloway Research
Subject: Unix/X/DOS/MS-Windows computer system for sale
Message-Id: <35810@apple.Apple.COM>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


               UNIX/DOS  Computer System
		     For Sale
		John Galloway (408) 259-2490 

   An AT with coprocesor running Unix V.3 with the X Window system and
Microsoft Windows on a 19" monchrome screen at 58% off current (good
i.e. Frys) retail (let alone what I paid a couple of years ago :-)
current
 retail
 guess	  55%	Discount
  $800 	 $360 	Wells America 8Mhz AT clone with 1Mbyte on board, 1.2 MB 5.25"
                       floppy & flpy/HD ctlr
  $575 	 $259 	Segate ST4096, 80 Meg (formated) internal winchester
   $35 	  $16 	second serial port
  $120 	  $54 	Logiterch 3 button mouse
  $250 	 $113 	Idea Associates monochrome/CGA/serial/parallel/clock
  $150 	  $68 	Hyundai amber monitor, 2 keyboards (pc and AT styles)
  $800 	 $360 	Everex internal 60MB cartridge tape (incl backup software)
  $570	 $257	18 DC300A and 12 DC600A cartridges for above drive
   $50	  $23	DOS 3.1
  $150	  $75	Speed store disk format and diagnostic utility
 -----	-----
 $3724	$1575	AT clone with hard disk and tape HW & SW total

	  65%	discount
 $5500	$1925 	Opus 220-8 coprocessor, NSC 32332 15Mhz CPU, MMU, & FPU, and
			8 Mbytes (w parity)
  $450 	 $158 	Unix Sys V.3 (+BSD utils) for Opus, uses AT for I/O processor
			with concurrent DOS usage
  $150	  $53	AT&T Unix Prog ref, User ref, Prog guide, Sys Admin Ref & Sys
			Admin guide manuals.
  $450	 $150	X 10.4 for Opus/Moniterm Viking-1 combination (I think X 11 is
			available from Opus)
 -----	-----
 $6550	$2293	Unix Sys V.3 on 2 MIP, 8MBV coprocesor with X, HW & SW total

	  40%	Discount
 $1600	 $960 	HP Laserjet II (512 KBytes, no font cartridges) & parallel cable
   $99 	  $59 	Glyphix soft downloadable fonts for HP-LJII, (font generator)"
  $100 	  $60 	Laser Control (various printer emulations for HP-LJII)
 -----	-----
 $1799	$1079	Laser Printer HW & SW total

	  55%	Discount
 $2100	 $945	Moniterm Viking 1 (19" 1280x960x1, monitor & AT card with
			Hitachi GPU)
  $150 	  $68 	MicroSoft Windows 2.1 (windows/286)) plus Moniterm Viking-1
			driver
  $295 	 $133 	MicroSoft Excel (for windows)
 -----	-----
 $2545	$1145	Micro Soft Windows on 19" monitor HW & SW total

 =====	=====
$14394	$6092	GRAND TOTAL (68% discount overall!!)



   The system has worked flawlessly for between 1 and 3 years (depending on
component).  It is working now and you are welcome to stop by for a demo.  
Preferences will be given to a purchase of the entire system, follwed by
complete groups with individual items as a last resort. Sale of the AT or Opus
board is contingent on sale of the other (i.e. neither does me any good alone)
Included are all cables, manuals and original packaging.  Purchase of the
entire system includes shipping/transportation & installation at your site
(within 100 mile radius of San Jose).  All offfers cheerfully discussed.
-- 
apple!jrg	John R. Galloway, Jr.       contract programmer, San Jose, Ca

These are my views, NOT Apple's, I am a GUEST here, not an employee!!

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Oct 89 23:20:54 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00530;
          22 Oct 89 17:16 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA03056; Sun, 22 Oct 89 09:12: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: 21 Oct 89 22:48:27 GMT
From: Ed Wright <zehntel!zps!edw@bloom-beacon.mit.edu>
Organization: 10*E12 Dyne & Zehn and The Art of ATE
Subject: Re: ForSale Shaved Ice Sno Cone Machine and Supplies
Message-Id: <1873@zehntel.UUCP>
References: <1864@zehntel.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I have been getting some interesting questions from the land of
bitnet

like what the *&%^ is this doing in header . people 
or mail . comp  or whatever

Whoever is the keeper of the gateway might want to look into this 
as thats not where stuff got posted.

This groups below are a duplicate of the original header
(just in case things are getting hosed along the way)

##############################################################
## Newsgroups: na.forsale,misc.forsale,ba.market,ca.wanted  ##
##############################################################

Its always nice when strange things happen  :-) /2

Ed
 UUCP Path      ucbvax  or  sun  or varian  !zehntel!edw       KA9AHQ
Life Is Hard ....  Can't get to heaven on roller skates,
Can't take a taxicab to Timbuktu.
                                       ... Timbuk3

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:19 EDT
Received: from ATHENA.MIT.EDU by mintaka.lcs.mit.edu id aa05665;
          23 Oct 89 11:19 EDT
Received: from PORTNOY.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA16229; Mon, 23 Oct 89 11:16:52 EDT
Received: by PORTNOY.MIT.EDU (5.61/4.7) id AA23950; Mon, 23 Oct 89 11:16:26 -0400
Date: Mon, 23 Oct 89 11:16:26 -0400
From: Bill Sommerfeld <wesommer@athena.mit.edu>
Message-Id: <8910231516.AA23950@PORTNOY.MIT.EDU>
To: rick@uunet.uu.net
Cc: Erik Fair <fair@apple.com>, usenet@bloom-beacon.mit.edu, 
    header-people@MC.lcs.mit.edu
In-Reply-To: Rick Adams's message of Sun, 22 Oct 89 22:57:22 -0400,
	<8910230257.AA04668@uunet.uu.net>
Subject: header-people, used computers, Sno-Cones, and misdirected messages.

Two messages have been gatewayed to header-people from apparantly
random newsgroups (including misc.forsale) in the past couple of days.

The reason why was fairly obvious if you look at one of articles in
question while its still in the news system. <35810@apple.Apple.COM>
was posted with the following newsgroups and distributions:

Newsgroups: na.forsale,misc.forsale,ne.forsale,dc.forsale,pa.forsale
Distribution: na

Note the "na.forsale" newsgroup in the Newsgroups: line.

Now, in our sys file, we find the following entry for the news->mail
gateway software for header-people/comp.mail.headers; this is the
first entry with system name "INTERNET" (the pseudo-system for mail
gatewaying).

INTERNET:comp,!comp.all,comp.mail.headers,!comp.mail.headers.all,world,inet,ddn!ddn.all,na,usa\
        :S:/usr/lib/news/gateway header-people header-people header-people-requs

Note that there isn't an "!na.all", because we were under the delusion
that "na" names a Distribution, not a Newsgroup Hierarchy, and we
don't have any "na.*" newsgroups on Beacon.

Fortunately, rnews doesn't push the article through more than one sys
file entry for a given name, or else we would have sent ads for
sno-cone machines to all the mailing lists we gateway..

Erik: I made the following change to `macros.m4' in our mail-news
gateway setup to fix this:

*** macros.m4   Thu Apr  7 03:06:09 1988
--- macros.m4.new    Mon Oct 23 10:43:56 1989
***************
*** 94,100 ****
  define(TOP,{substr($1,0,index($1,.))})
  define(DIST,{$1,!$1.all})
  define(GRP,{DIST(TOP($1)),DIST($1)})
! define(STDDIST,{DEFDIST,inet,DIST(ddn),na,usa})
  define(GROUPLIST,{GRP($1),STDDIST})
  define(SYSFILE,{PSEUDO:GROUPLIST($1):S:MAILER $2 $3 $4 $5})

--- 94,100 ----
  define(TOP,{substr($1,0,index($1,.))})
  define(DIST,{$1,!$1.all})
  define(GRP,{DIST(TOP($1)),DIST($1)})
! define(STDDIST,{DEFDIST,DIST(inet),DIST(ddn),DIST(na),DIST(usa)})
  define(GROUPLIST,{GRP($1),STDDIST})
  define(SYSFILE,{PSEUDO:GROUPLIST($1):S:MAILER $2 $3 $4 $5})

				- Bill


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:34 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05705;
          23 Oct 89 11:21 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA21907; Mon, 23 Oct 89 10:58: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: 23 Oct 89 14:57:23 GMT
From: Bill Sommerfeld <snorkelwacker!snorkelwacker!wesommer@bloom-beacon.mit.edu>
Organization: /mit/wesommer/.organization
Subject: This is a test.
Message-Id: <WESOMMER.89Oct23105723@portnoy.athena.mit.edu>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

If my hunch is correct, this will wind up on header-people

If you're reading this on header-people, sorry for the noise; this
will be corrected shortly.  In any case, DO NOT REPLY TO THIS MESSAGE.

Thanks for your patience.

				- Bill
--
Henry Spencer is so much of a  |    Bill Sommerfeld at MIT/Project Athena
minimalist that I often forget |    sommerfeld@mit.edu
he's there - anonymous         |

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:41 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05707;
          23 Oct 89 11:21 EDT
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA22044; Mon, 23 Oct 89 11:05: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: 23 Oct 89 15:03:26 GMT
From: Bill Sommerfeld <snorkelwacker!snorkelwacker!wesommer@bloom-beacon.mit.edu>
Organization: /mit/wesommer/.organization
Subject: This is a second test.
Message-Id: <WESOMMER.89Oct23110326@portnoy.athena.mit.edu>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

This should *NOT* wind up in header-people.

Sorry for filling up people's junk groups..

					- Bill


--
Henry Spencer is so much of a  |    Bill Sommerfeld at MIT/Project Athena
minimalist that I often forget |    sommerfeld@mit.edu
he's there - anonymous         |

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Oct 89 18:26:06 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25593;
          29 Oct 89 18:22 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA29671; Sun, 29 Oct 89 18:17:25 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 Oct 89 23:05:58 GMT
From: Michael DeCorte <gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!news@ohio-state.arpa>
Organization: Clarkson University, Potsdam NY
Subject: Precedence: field
Message-Id: <MRD.89Oct29180553@image.clarkson.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


Under Unix there is a program called vacation.  It is used to reply
to incoming mail if you are on vacation. In the documentation it says
that it won't reply to mail containing the header lines:

Precedence: junk
or
Precedence: bulk

(The idea is that mail from newsgroups would contain this field) 
The 'Precedence' field is not mentained in RFC822 but it seems useful
and I want to use it (I maintain a BIG archive-server you see).  Now
I have found that many mailers get a bit upset if they see this little
field.

So, the question is: How do I get this field to work or is this a
little bit of nonsence made up by the author of vacation who didn't
bother to read RFC-822 and he should have used 'X-Precedence:'?
--

Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet
2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu
---------------------------------------------------------------------------
Clarkson Archive Server // commands = help, index, send, path
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
---------------------------------------------------------------------------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Oct 89 20:59:07 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28894;
          29 Oct 89 20:52 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01195; Sun, 29 Oct 89 20:37:32 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 89 01:29:05 GMT
From: Jeff Beadles <zephyr.ens.tek.com!orca!quark!jeff@uunet.uu.net>
Organization: Tektronix, Inc., Wilsonville, OR
Subject: Re: Precedence: field
Message-Id: <5156@orca.WV.TEK.COM>
References: <MRD.89Oct29180553@image.clarkson.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <MRD.89Oct29180553@image.clarkson.edu> mrd@sun.soe.clarkson.edu (Michael DeCorte) writes:
|
|Under Unix there is a program called vacation.  It is used to reply
|to incoming mail if you are on vacation. In the documentation it says
|that it won't reply to mail containing the header lines:
|
|Precedence: junk
|or
|Precedence: bulk
|
|(The idea is that mail from newsgroups would contain this field) 
|The 'Precedence' field is not mentained in RFC822 but it seems useful
|and I want to use it (I maintain a BIG archive-server you see).  Now
|I have found that many mailers get a bit upset if they see this little
|field.
|
|So, the question is: How do I get this field to work or is this a
|little bit of nonsence made up by the author of vacation who didn't
|bother to read RFC-822 and he should have used 'X-Precedence:'?

Well, it's not vacation's fault.  Sendmail uses the precedence field.  As I
recall, there are a few "default" values that can be used.  For example, if I
say "Precidence: bulk" in my message, and it's sent to a site that can not deal
with it, (unknown/no such user) it should silently trashcan the message, and
not bounce it back to me.

I've been running with this on the rc-cars mailing list for some time now, with
NO bounced messages that I know of.  (Unless the site trashcans it, then that's
ok :-)

	-Jeff
-- 
Jeff Beadles	Utek Engineering, Tektronix Inc.	jeff@quark.WV.TEK.COM
Maintainer of rc-cars mailing list. Requests to rc-cars-request@quark.wv.tek.com

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Oct 89 09:59:53 EST
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa25959;
          30 Oct 89 9:52 EST
Return-Path: <rlk@Think.COM>
Received: from Underprize.Think.COM by Think.COM; Mon, 30 Oct 89 09:53:45 -0500
Received: by underprize.think.com; Mon, 30 Oct 89 09:48:53 EST
Date: Mon, 30 Oct 89 09:48:53 EST
Message-Id: <8910301448.AA22109@underprize.think.com>
From: "Robert L. Krawitz" <rlk@think.com>
Sender: rlk@think.com
To: header-people@mc.lcs.mit.edu
In-Reply-To: <MRD.89Oct29180553@image.clarkson.edu>
Subject: Precedence: field

   Date: 29 Oct 89 23:05:58 GMT
   From: Michael DeCorte <gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!news@ohio-state.arpa>

   Under Unix there is a program called vacation.  It is used to reply
   to incoming mail if you are on vacation. In the documentation it says
   that it won't reply to mail containing the header lines:

   Precedence: junk
   or
   Precedence: bulk

So that's why I never have problems with vacation mail bouncing back to
me (owner-info-nets).  Sometimes I wish mailers would respect that in
general and not send certain types of bounce mail back at all, like
postal third-class mail, where forwarding addresses are not reported.
I've never even read the man page on vacation, since I refuse to use it
even when I am on vacation.

   (The idea is that mail from newsgroups would contain this field) 
   The 'Precedence' field is not mentained in RFC822 but it seems useful
   and I want to use it (I maintain a BIG archive-server you see).  Now
   I have found that many mailers get a bit upset if they see this little
   field.

What mailers?  I`ve never had anything complain.  The only mailer that's
ever barfed at me is the Symbolics user agent, which refuses to allow
ANY nonstandard headers, even those prefixed by X-, unless you do
something nasty to the mailer to start with.  Of course, there are
always those mailers that send "comments" back to me every time a
non-compliant address passes through them.  Those are incredibly
annoying, but fortunately few and far between.

   So, the question is: How do I get this field to work or is this a
   little bit of nonsence made up by the author of vacation who didn't
   bother to read RFC-822 and he should have used 'X-Precedence:'?

RFC822 page 25 states that users are free to define and add additional
header fields, but that unless they begin with 'X-' they may be
pre-empted by future standards.  I assume that that means that you're
free to use precedence: as you see fit, but that its meaning is not
presently standardized although it may be in the future.  X-precedence
doesn't avoid the problem of non-standardization; the only difference
with that name is that it can never be standardized.  Of course, another
mailer is free to do as it pleases with the additional header, and that
includes bouncing it back to you, although that sounds like a rather
pedantic over-reaction.

Given that sendmail and vacation respect precedence: fields, and use
them fairly wisely (sendmail reduces the priority of junk mail and
increases the priority of special delivery mail), I recommend that you
continue to use precedences in your mailing list mail.

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 lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Nov 89 12:52:12 EST
From: Rob Austein <sra@lcs.mit.edu>
Sender: sra@MINTAKA.lcs.mit.edu
To: Michael DeCorte <mrd@sun.soe.clarkson.edu>
In-reply-to: mrd@sun.soe.clarkson.edu's message of 29 Oct 89 23:05:58 GMT
Subject: Precedence: field
CC: Header-People@mc.lcs.mit.edu
Date: Wed, 1 Nov 89 12:24:58 EST
Message-ID:  <8911011225.aa02675@mintaka.lcs.mit.edu>

The "Precedence:" field is not defined by the standard (more
precisely, it's what RFC822 calls a "user-defined-field"), and falls
under the so-called "local rights" clause:

  Vacation is within its rights to do whatever it wants to do based on
  the "Precedence:" field, including replying to certain messages
  based on its value.

  Sendmail is within its rights to do whatever it wants to do based on
  the "Precedence:" field, including discarding certain messages based
  its value.

  Other mailers are within their rights to do whatever they want to do
  based on the "Precedence:" field, including bouncing certain
  messages based on its existance.

Anybody sending messages with "Precedence:" headers is violating the
"be conservative in what you send, liberal in what you accept" dictum.
In practice there are so many people using random user-defined-fields
("Favorite-Beer:", "Zippy-Says:" ...) that bouncing messages because
they contain one seems pretty silly, but it's not a crime.
User-defined-fields should be used only between consenting adults.

If the authors of the vacation and sendmail programs had used
"X-Precedence:" instead of "Precedence:" it would not have changed
this situation in any material way; all that the "X-" prefix does is
guarantee that nobody will will ever be allowed to standardize
"X-Precedence:" while, in theory, somebody could come along and
standardize "Precedence:", possibly with different semantics than
those used by sendmail and vacation.

--Rob Austein

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Nov 89 04:30:14 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa10723;
          2 Nov 89 4:26 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8513; Thu, 02 Nov 89 04:25:31 EST
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 5078; Thu, 02 Nov 89 04:25:31 EST
Received: from ODEN by brage.qz.se; Thu, 2 Nov 89 10:23 +0100
Date: 02 Nov 89 09:07 +0100
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: Precedence: field
To: header-people <HEADER-PEOPLE@mc.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <460994@QZCOM>
In-Reply-To: <8910301448.AA22109@underprize.think.com>

The X.400 recommendation has facilities like
"supression of non-delivery notifications"
to get similar results.



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Nov 89 04:30:19 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa10724;
          2 Nov 89 4:26 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8514; Thu, 02 Nov 89 04:25:34 EST
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id
 5080; Thu, 02 Nov 89 04:25:33 EST
Received: from ODEN by brage.qz.se; Thu, 2 Nov 89 10:22 +0100
Date: 02 Nov 89 09:04 +0100
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: -
To: header-people <HEADER-PEOPLE@mc.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <460992@QZCOM>
In-Reply-To: <8910292359.AA13296@qzuno.qz.se>

If you want to include undocumented fields, like the
Precedence field, in headers, my advice is to put it last
of the lines in the RFC822 header lines.

Some mail programs quit processing the RFC822 header at the
first un-understandable line in it.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Dec 89 13:21:02 EST
Received: from IU.AI.SRI.COM by mintaka.lcs.mit.edu id aa28606;
          4 Dec 89 13:16 EST
Date: Mon 4 Dec 89 10:15:14-PST
From: Peter Karp <PKARP@iu.ai.sri.com>
Subject: [barmar@THINK.COM: Inferior Lisp mode conflicts with]
To: header-people@mc.lcs.mit.edu
Message-ID: <628798514.750000.PKARP@IU.AI.SRI.COM>
Mail-System-Version: <VAX-MM(248)+TOPSLIB(136)+PONY(256)@IU.AI.SRI.COM>

The following message illustrates an interesting problem in Internet
mailing lists.  Someone at Buffalo has subscribed an account there
to a number of different mailing lists, and then set mail forwarding
on that account to the INFO-VAX mailing list, thereby forwarding
many different mailing lists to INFO-VAX (it appears thus far that
the person has not subscribed to INFO-VAX!).  

(This happened about a week ago, and the system administrator at
Buffalo disabled the account, but now it's happening again; I've
sent a note to the administrator).

My question is: what automatic methods could be used to detect such
actions (which could even happen unintentionally)?  For example,
mailing list expanders might insert header lines such as 
"Redistribute: No" in outgoing messages, and then refuse to
redistribute incoming messages containing this header.  Other
ideas?

Peter
                ---------------

Return-Path: <@Gizmo.SRI.COM:RELAY-INFO-VAX@CRVAX.SRI.COM>
Received: from Gizmo.SRI.COM by IU.AI.SRI.COM via SMTP with TCP; Mon,
	  4 Dec 89 04:01:14-PST
Received: From ubvmsc.cc.buffalo.edu ([128.205.2.8]) by CRVAX.SRI.COM
	  with TCP; Mon,  4 DEC 89 03:23:07 PDT
Received: from PUCC.PRINCETON.EDU by UBVMS.BITNET; Mon,
	  4 Dec 89 06:20 EST
Received: by PUCC (Mailer R2.06X) id 1586; Mon, 04 Dec 89 06:17:31 EST
Date: Mon, 4 Dec 89 02:46:44 EST
From: barmar@THINK.COM
Subject: Inferior Lisp mode conflicts with Shell mode
Sender: Gnu-Emacs bugs & info <GNUEMACS@FINHUTC.BITNET>
To: Tao Uwang <V094QQSF@ubvmsc.cc.buffalo.edu>
X-VMS-To: Tao Uwang <V094QQSF@UBVMS.BITNET>
Reply-to: barmar@THINK.COM
Resent-date: Mon, 4 Dec 89 06:20 EST
Resent-to: INFO-VAX@SRI.COM
Comments: To: bug-gnu-emacs@prep.ai.mit.edu
Comments: cc: bug-gmacs@think.com

In GNU Emacs 18.52.25...
 
Setting some key bindings in inferior-lisp-mode-map causes those same keys
to be bound in shell-mode-map.  It happens whenever you rebind a multi-key
sequence whose default value is copied from Shell mode (e.g. c-c c-z).
 
The cause is that inferior-lisp-mode-map is initialized to be (copy-alist
shell-mode-map).  This only copies two levels of the tree structure of the
sparse keymap.  The second-level alists, which are used for dispatching
after a prefix key, are shared by both keymaps.  When rebinding a key that
is already bound in the keymap the shared cons is RPLACDed, affecting both
keymaps.
 
Instead of using copy-alist, it should be using copy-keymap, so that all
levels of the keymap are copied.
 
						barmar
 

-------
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Dec 89 13:04:21 EST
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa07047;
          8 Dec 89 12:59 EST
Return-Path: <rlk@Think.COM>
Received: from Underprize.Think.COM by Think.COM; Fri, 8 Dec 89 13:00:20 -0500
Received: by underprize.think.com; Fri, 8 Dec 89 12:55:34 EST
Date: Fri, 8 Dec 89 12:55:34 EST
Message-Id: <8912081755.AA28834@underprize.think.com>
From: "Robert L. Krawitz" <rlk@think.com>
Sender: rlk@think.com
To: header-people@MC.lcs.mit.edu, info-nets@think.com
Subject: [MAILER-DAEMON@Think.COM: Returned mail: User unknown]

I'm amazed.  There are still people living in the dark ages out there...

ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111

Date: Fri, 8 Dec 89 12:53:43 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@Think.COM>
Subject: Returned mail: User unknown
To: <rlk@Think.COM>

   ----- Transcript of session follows -----
>>> RCPT To:<postmaster@clark-emh.af.mil>
<<< 550 User "postmaster" Unknown.
550 <postmaster@clark-emh.af.mil>... User unknown

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Dec 89 16:31:39 EST
Received: from BBN.COM by mintaka.lcs.mit.edu id aa13639; 13 Dec 89 16:14 EST
From: Jack Haverty <haverty@bbn.com>
Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with]
To: PKARP@iu.ai.sri.com
Cc: haverty@bbn.com, header-people@mc.lcs.mit.edu
In-Reply-To: <628798514.750000.PKARP@IU.AI.SRI.COM>
Date: Wed, 13 Dec 89 15:53:44 EDT
Mail-System-Version: <MacEMail_1.2.1@BBN.COM>
Message-ID:  <8912131614.aa13639@mintaka.lcs.mit.edu>

I think I remember that one of the original reasons for insisting on a
Message-id field in a message was to permit the implementation of mail
handling software which could be resilient in situations such as 'loops'
in mail distribution.  For example, a host receiving a message could
compare it's ID against a list of the IDs of messages it has received
recently, and cull duplicates; this would prevent loops and also reduce
the number of multiple copies a user receives, e.g., when you reply to a
message which includes a list of which you are a member.  Of course, how
successful such a scheme is depends on the host's choice of "recently",
but that is a local argument to have.

This wouldn't permit configuration problems where a mailing list is
forwarded to another mailing list, but I don't think a new field would
either.  The problem is that the user is setting the configuration to do
something which is presumably not having the desired result.  My vote
for a new mechanism would be a mail-list management tool that simply
says things like "All mail on the XXX list will be forwarded
automatically to 7683 users on 4 continents. Is that what you intended?"

I'd be curious to hear if any software out there actually uses the
message-id field in any way.  There were lots of notions flying around
in the 70s, e.g., "threading" a sequence of replies by tracking
message-ids and "in-reply-to".  Anybody do anything with message ids?

Jack

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Dec 89 19:25:19 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa16312; 13 Dec 89 19:19 EST
Received: by ifi.uio.no (5.61++/1.15) 
	id AA21968; Thu, 14 Dec 89 01:17:03 +0100
Date: Thu, 14 Dec 89 01:17:03 +0100
Message-Id: <8912140017.AA21968@ifi.uio.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: Jack Haverty <haverty@bbn.com>
Cc: PKARP@iu.ai.sri.com, haverty@bbn.com, header-people@mc.lcs.mit.edu
In-Reply-To: <8912131614.aa13639@mintaka.lcs.mit.edu> "Jack Haverty <haverty@bbn.com>"
Subject: [barmar@THINK.COM: Inferior Lisp mode conflicts with]

I seem to just have gotten my subscription working again due to
problems at what was perceived as a safe relay point.

Anyway, Jack asks about software that uses the Message-ID field.  Mine
does.  I use the Reference field in USENET, too.  I can review the
message that something is a reply to, IFF the message has a properly
used In-Reply-To field, and I also let my mailer strip out quotes
(excerpts) from the replied-to message and store them in a special
space-conserving way (#Q@<line>) to refer to that line in the
replied-to message.  Messages quoted in this way are also flagged, so
as not to delete them.  Copies of my own messages are also flagged as
answered when I get replies.  This also works for USENET news, but
based on the Reference field instead.  (With NNTP this works great
except for expired messages.  That problems remains to be solved.)

I have not found many systems who consistently use Message-IDs, and
some users insist on reformatting quoted text, anyway.  There is also
a lot of software which disobeys the syntax rules for the In-Reply-To
field, and even some PC-based network news software which uses
unquoted `[' and `]' in the message-id.  (The authors thought they
were true to RFC 1036, but had "forgotten" about the explicit
references to RFC 822 as the superior RFC when in conflict.)

I don't know the context of this discussion, but if you are about to
discourage the use of Message-IDs in general, I think that there is no
reason to do so, even if you do not want to insert your own.

Oh, one more thing.  I use Message-IDs to request mail, from the
sender, that lost for some reason.  Most people are totally unable to
find a message by this unique id.  I also use Message-IDs in the
specified accounts I send to my network's (uu.no) users when I bill
them their share of the costs.  Some of these use them to check
against their own logs, for forgeries or other mishaps.

While on the topic, let me throw in a little discussion on the format
of Message-IDs.  Sendmail's verbose <yymmddhhmmss.AAppppp@domain> is
too long.  I am trying a shorter one <yy-jjj-mmmm@domain>, where jjj
is the day of the year (Julian date) and mmmm is the number of the
message that day.  Beta-test users note that it is easier to recognize
and use when it's short and readable.  Some software insists on total
garbage in the local-part field, which I dislike intensely.  Prominent
hosts like A.ISI.EDU (or some prominent users, maybe) also use formats
like <[A.ISI.EDU].verbose-date.USER> with no `@'-sign in it at all.
I once got across a piece of software which rewrote Message-IDs the
way it rewrote addresses, tacking on "@domainname" and making the
other `@' a `%'...

--Erik

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 08:22:52 EST
Received: from ACF6.NYU.EDU by mintaka.lcs.mit.edu id aa20168;
          14 Dec 89 0:07 EST
Date:    Thu, 14 Dec 1989 0:06:03 EST
From:    Stephen Tihor <TIHOR@acf6.nyu.edu>
Message-Id: <891214000603.34a03825@ACF6.NYU.EDU>
Subject: A sad comentary
To:      header-people@mc.lcs.mit.edu
X-Vmsmail-To: IN%"header-people@mc.lcs.mit.edu"

From:	BITNET%"ned@YMIR.BITNET"      "Ned Freed, Postmaster" 13-DEC-1989 23:31:12.31
To:	CSERH000@KENTVMS.BITNET, INFO-PMDF@YMIR.BITNET
CC:	
Subj:	RE: Question about implementing a BITNET -> Internet gateway

Received: From YMIR(POSTMAST) by NYUACF7 with Jnet id 8241
          for TIHOR@NYUACF; Wed, 13 Dec 89 23:31 EST
Received: from HMCVAX.BITNET by YMIR.BITNET; Wed, 13 Dec 89 16:56 PST
Resent-date: Wed, 13 Dec 89 17:00 PST
Date: Wed, 13 Dec 89 16:55 PST
From: "Ned Freed, Postmaster" <ned@YMIR.BITNET>
Subject: RE: Question about implementing a BITNET -> Internet gateway
Resent-to: INFO-PMDF-LIST2@YMIR.BITNET
To: CSERH000@KENTVMS.BITNET, INFO-PMDF@YMIR.BITNET
Errors-to: postmast@YMIR.BITNET
Resent-message-id: <0CAB5FE026BF600D2C@YMIR.BITNET>
Message-id: <0CADBF2E6D5F20011F@HMCVAX.BITNET>
X-Envelope-to: TIHOR@NYUACF.BITNET
X-VMS-To: IN%"CSERH000@KENTVMS.BITNET"
X-VMS-Cc: IPMDF
     
Leo Holmberg writes:
     
> I am sending this to you, rather than to the list, because I'm not sure that
> is a PMDF issue; it might just represent my lack ok knowledge of Internet
> mail. Feel free to post it, if you think it relates to PMDF...
     
> During the last 2 months, we have had a user here, who was flooding BITNET
> with mailings for a China News digest. He was sending to about 2000
> subscribers, and due to the topology here, in the state of Ohio, all his
> messages were clogging up the machine, that serves as the focus for most
> of the BITNET trafic in the state. About half his messages were destined for
> Internet addresses, and these were being sent to Cornell, as our Internet-
> BITNET gateway. I therfore decided to try and implement a BITNET -> Internet
> gateway here on KENTVMS.BITNET, using PMDF.
     
> Well, to make a long story  short, it was fairly easy to do. I had one problem
   ,
> getting PMDF to act as the local mail delivery agent. I sent out a message to
> the list, and got a reply from some guy at APPSTATE, who informed me my error
> was probably in my definition of channel L (it was). I had the IBM mailer here
   ,
> (on KENTVM) point to me as Interbit, and it's been working OK, for a couple of
> weeks or so.
     
> Now yesterday morning, I found the following in my mail....
     
> > Note the attached header.  I'm not an expert, but it appears that this
> > mail was routed to the Internet without any indication of the gateway,
> > leaving the From: address as 'user@node.bitnet'.
     
> > Isn't this a violation of some Internet policy?  I know it confuses our
> > mailer, which has never heard of domains such as '___.uucp' or '___.bitnet'!
     
> > Ric Nauen
     
> > > From: PETER HORWITZ <HORWITZ@KENTVM.BITNET>
     
> Is he complaining because the return is HOROWITZ@KENTVM.BITNET? Have I set
> something up wrong. Currently, the machine KENTVM.BITNET does not have an
> Internet addresss, so what else could it be? Am I violating Internet policy?
> We haven't registered the domain yet with BITNIC, but we had planned on doing
> at some point in the future? Can you advise? Thanks in advance...Leo
     
This is a very interesting and complex issue. I have received a couple of
messages about it in the past few days, so I thought it was time to post
something to info-pmdf.
     
Let's deal with the "violation of some Internet policy" part first. I've looked
through the various standards, and it seems to me (as well as several other
people I've corresponded with about this) that the relevant information is in
RFC1123 (Internet host requirements, and in particular, the requirements for
gatewaying mail messages):
     
>          (D)  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.
     
The "requirements for Internet mail" are not spelled out anywhere else I can
find, so this little paragraph seems to be the definitive source of information
on the subject. HORWITZ@KENTVM.BITNET is certainly syntactically correct. So
the remaining requirement is that the address is "effective and useful". And
that's a matter of opinion. I think .BITNET is a useful address form. You may
not, but so what? Any reasonable mailer can be told to route anything that ends
in .BITNET to the closest Internet-BITNET gateway. So the address is
"effective" (again in my opinion).
     
So I don't think a case can be made for this being a violation of Internet
policy. It is, however, typical to see people claiming that something is a
violation without ever having checked to see if it is true or not. (Ric Nauen
is nice about it, at least. Most messages I've seen of this type have been much
uglier.)
     
But this leaves open the issue of "is it a good idea to emit .BITNET addresses
on the Internet?" My feeling (and this is only my opinion) is that it is a good
idea to avoid it when there's an acceptable substitute available. In this
particular case, I'd recommend registering your domain, selecting a
domain-style name for your systems, and using those addresses whenever possible
(I would continue to use .BITNET style addresses on BITNET until your domain
definitions percolate around BITNET).
     
I draw the line at source routes, however. Source routes are (still) strongly
discouraged (and this *does* have the status of an Internet policy). If the
choice is between emitting a .BITNET address and using a source route, I'll
take the .BITNET address every time. My interpretation of the Internet host
requirements seem to support this view. But on the practical side, I always
come back to the fact that practically any mailer can be told how to handle
.BITNET addresses with a simple configuration change, while many mailers are
fundamentally broken when it comes to source routes and cannot be fixed without
substantial recoding that nobody is willing to do. No matter how I slice it,
source routes lose when compared to defacto standard domain names.
     
                                Ned

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 10:58:37 EST
Received: from PO2.ANDREW.CMU.EDU by mintaka.lcs.mit.edu id aa28465;
          14 Dec 89 10:53 EST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA01500> for header-people@mc.lcs.mit.edu; Thu, 14 Dec 89 10:49:16 EST
Received: via switchmail; Thu, 14 Dec 89 10:49:03 -0500 (EST)
Received: from apollo.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.IZVw19m00VsL00KlEq>;
          Thu, 14 Dec 89 10:46:19 -0500 (EST)
Received: from apollo.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr13/cfe/.Outgoing/QF.QZVw0xe00VsL8OgKRy>;
          Thu, 14 Dec 89 10:46:06 -0500 (EST)
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.andrew.cmu.edu.rt.r3
          via MS.5.6.apollo.andrew.cmu.edu.rt_r3;
          Thu, 14 Dec 89 10:46:05 -0500 (EST)
Message-Id: <kZVw0xS00VsL8OgKJC@andrew.cmu.edu>
Date: Thu, 14 Dec 89 10:46:05 -0500 (EST)
From: "Craig F. Everhart" <cfe+@andrew.cmu.edu>
To: header-people@mc.lcs.mit.edu, Erik Naggum <erik@naggum.uu.no>
Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with]
Cc: PKARP@iu.ai.sri.com, haverty@bbn.com, header-people@mc.lcs.mit.edu, 
    @bellcore.com:nsb@thumper, Jonathan Rosenberg <jr+@andrew.cmu.edu>, 
    "Craig F. Everhart" <cfe+@andrew.cmu.edu>
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
In-Reply-To: <8912140017.AA21968@ifi.uio.no>
References: <8912140017.AA21968@ifi.uio.no>

You betcha we use Message-IDs (and their cousins, In-reply-to and References).

I. Eliminate duplicate deliveries.
We use 'em to eliminate mail forwarding loops by keeping a
mostly-correct database on the local disks of our post-office machines,
containing (key, value) pairs like:
	( key=(message-id, recipient-addr);
	  value=(timestamp, return-path, ``for'' information) )
That is, whenever a PO machine delivers mail, it records the message-id
of the message and the recipient-addr to which it was delivered.  (This
neatly handles the problems of receiving the same message multiple
times, but for different recipients each time--usually routed by diverse
mail forwardings.)  We eliminate old entries (over four days old) by
reading the whole database and deleting every entry whose ``timestamp''
makes it uninteresting.  The return-path and ``for'' information (e.g.
that in a Received: header--in our case, what mail forwardings are
currently being expanded) are useful inclusions in the status-report
message that we generate for the local administrator.

Every message we send off-site, or to any forwarding mechanism, has a
Message-ID (or a ReSent-Message-ID, if appropriate), even if the
delivery system has to invent one and add it.  This is strictly
necessary if the mechanism is to eliminate problems from mail forwarding
loops, which are awfully common here since there are lots of different
mechanisms by which users set their own forwarding addresses; they all
have different latencies before changes take effect.

II.  Duplicate elimination in folders
The duplicate-elimination mechanism in the delivery system mentioned in
I., above, works on each individual post office machine; four different
machines serve the andrew.cmu.edu domain.  (Putting the database on each
local disk makes it cheap enough.  It tolerates errors; mail is
delivered even if it couldn't be noted in the database.  The point to
that database was to eliminate outright disasters of thousands of copies
of the same piece of forwarded mail, not to eliminate the occasional
duplicate.)  In addition, lots of (local) mail is delivered straight
from a workstation to a user's mailbox in the distributed file system. 
So, further duplicates are possible by all sorts of mechanisms.

Our principal mail filing program does duplicate elimination within
individual folders of messages, using the Message-ID field.  Each folder
has an index file, containing a fixed-width summary of each message in
the folder.  One field in each message summary is a 32-bit signature
hash of the Message-ID field, which is used to find duplicates in a
given database.  (Yes, hash collisions are tolerated, because the full
Message-ID field values are checked on hash equality.)  It works great.

III.  In-reply-to and References fields.
The same mail-filing program also maintains other indexed values, one
for any principal In-reply-to/References field and one for a
heuristically-based ``message thread'' identifier.  Whenever messages
are added to a folder, the mail-filing program tries to find the
``related'' messages by comparing hashes and texts of its Message-ID and
In-reply-to fields with the comparable fields in all the existing
messages in the folder.  ``Related'' messages are, by definition, stored
with the same message-thread identifier.

IV.  Complaints.
Lots of software doesn't generate sensible Message-ID fields.  I don't
care how long such fields are, but apparently many Netnews
implementations do.  It's always a bear when you see Message-ID fields
used as an advertisement for a mailer, where the same string is used for
many messages, e.g.:
	Message-Id: <Sent by MUSIC/SP Mailer at UTREYP0>
Also, many Netnews implementations do case-folding on the local-part of
Message-IDs, so when we try to compress lots of (to our minds,
necessary) unique-ifying information into a short message-ID value using
a case-sensitive base-64 digit basis, some sites discard information by
case-folding 26 digits of our base-64 identifiers into 26 different ones.

Well, enough flaming for now.

		Craig

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 11:44:38 EST
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa29256;
          14 Dec 89 11:37 EST
Received: by uunet.uu.net (5.61/1.14) 
	id AA12168; Thu, 14 Dec 89 11:36:26 -0500
Date: Thu, 14 Dec 89 11:36:26 -0500
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8912141636.AA12168@uunet.uu.net>
To: TIHOR@acf6.nyu.edu, header-people@mc.lcs.mit.edu
Subject: Re: A sad comentary

Despite your particular ideas about valid addresses, foo.bitnet
is NOT  a valid internet address. It never has been and I am
quite sure that it never will be.

The fact that some hosts can handle it does not change the fact that
the internet gateway is OBLIGATED to change it into a valid
internet domain (the usual cheap way to do this is to
change user@site.bitnet into user%site.bitnet@internetgateway).

The gateway is clearly, undeniably at fault and needs to be fixed.


:p

Your suggestion that the many thousands of internet hosts change their
mailer to accept your invalid host.bitnet address is ludicrous.

If you want to sent internet mail, you have to play by the internet rules.
BITNET is not a valid top level domain.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 15:42:53 EST
Received: from NYU.EDU by mintaka.lcs.mit.edu id aa03974; 14 Dec 89 15:30 EST
Received: from ACF7.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34)
	id AA25675; Thu, 14 Dec 89 15:08:56 -0500
Date: 14 Dec 89 13:48 EST
From: TIHOR@acf7.nyu.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
To: rick@uunet.uu.net
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject: RE: A sad comentary
Cc: header-people@MC.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Message-Id: <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA>
In-Reply-To: Message of 14-DEC-1989 11:37:49 from rick@uunet.uu.net

Rick, I happen to agree with you.  But Ned raises a reasonable question:

Why we all know the intention is for the right had side of everything
in a SMTP address to be a domain name system resolvable name
THAT REQUEUIRMENT DOES NOT SEEM TO BE WRITTEN DOWN ANYWHERE.

I remember its discussion way back when but it does not see to have
made it into even the host requirements document except eliptically.

Thats no way to write standards.

Please provide exact citation and quotation for why X.Y.Z must be a
DNS name if the following addresses by the RFCs:


	<user@X.Y.Z>

	<@A.B.C:user@X.Y.Z>

	<@A.B.C,@X.Y.Z:user@D.E.F>


If you can you have refuted Ned's proactical arguements (and some other things
people have been asserting I can rebut properly.)

That will leave the "accept generously emit strictly" rule as justification
for .BITNET.

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 16:06:39 EST
Received: from NYU.EDU by mintaka.lcs.mit.edu id aa05965; 14 Dec 89 16:04 EST
Received: from uunet.UU.NET by cmcl2.NYU.EDU (5.61/1.34)
	id AA27409; Thu, 14 Dec 89 16:03:26 -0500
Received: by uunet.uu.net (5.61/1.14) 
	id AA29665; Thu, 14 Dec 89 16:02:13 -0500
Date: Thu, 14 Dec 89 16:02:13 -0500
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <8912142102.AA29665@uunet.uu.net>
To: TIHOR@acf7.nyu.edu
Subject: RE: A sad comentary
Cc: header-people@mc.lcs.mit.edu

RFC822 clearly states that the domain-ref (the part to the right
of the @) must be an "official name". RFC974 discusses how to route it.

I have better things to do than waste my time searching the exact paragraphs.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 17:40:06 EST
Received: from NYU.EDU by mintaka.lcs.mit.edu id aa12667; 14 Dec 89 17:36 EST
Received: from CMCL1.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34)
	id AA29499; Thu, 14 Dec 89 17:35:11 -0500
Date: 14 Dec 89 17:11 EDT
From: TIHOR@cmcl1.nyu.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
To: rick@uunet.uu.net
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject: RE: A sad comentary
Cc: header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Message-Id: <3485E704B.00022376.1989@CMCL1.CMCL1.NYU.EDU.ARPA>
In-Reply-To: Message of 14-DEC-1989 16:55:09 from rick@uunet.uu.net

Thank you so much for your kind assistance.
I appologize most humbly for lacking also myself the intelligence and copius
time to locate the necessary citations to put such non-conforming mail
things as X@Y.BITNET and <@A.B.C:TNEILAND@FALCON> on notice of their
non-conformaty.

I will send them your message.  I am sure it will convince these people
of the errors of their ways.

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 17:40:15 EST
Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa12705;
          14 Dec 89 17:36 EST
Posted-Date: Thu, 14 Dec 89 14:34:15 PST
Message-Id: <8912142233.AA21198@venera.isi.edu>
Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA21198>; Thu, 14 Dec 89 14:33:38 -0800
To: TIHOR@acf7.nyu.edu
Cc: rick@uunet.uu.net, header-people@mc.lcs.mit.edu
Reply-To: pvm@venera.isi.edu
Subject: Re: A sad comentary 
In-Reply-To: Your message of 14 Dec 89 13:48:00 -0500.
             <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA> 
Date: Thu, 14 Dec 89 14:34:15 PST
From: Paul Mockapetris <pvm@venera.isi.edu>

The Host Requirements group intentionally avoided specifying mail
gateway behaviour, the argument being that it was HOST requirements.

You can check the SMTP section of RFC1123 in the RCPT command to find
an envelope level DNS requirement.

<Flame on>

But all this is somewhat peripheral.  These .BITNET addresses (and the
like) are litter in the Internet mail system, and it didn't seem like
there would be real interest in strict enforcement of littering laws,
especially because it is usually just easier to clean up other's
trash.

paul



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 10:25:22 EST
Received: from WS6.NNSC.NSF.NET by mintaka.lcs.mit.edu id aa06260;
          15 Dec 89 10:09 EST
To: TIHOR@acf7.nyu.edu
cc: rick@uunet.uu.net
cc: header-people@mc.lcs.mit.edu
Subject: Where it says what's on the right of @
Date: Fri, 15 Dec 89 10:08:07 -0500
From: Craig Partridge <craig@nnsc.nsf.net>
Message-ID:  <8912151009.aa06260@mintaka.lcs.mit.edu>


A few places where Internet standards state the thing on the right of the @
sign needs to be a valid Internet domain.  Section 5.2.18 of 1123 is
particularly clear on this...

RFC 1123
 
      5.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., they must be
         fully-qualified principal names or domain literals, not
         nicknames or domain abbreviations.  A canonicalized name either
         identifies a host directly or is an MX name; it cannot be a
	 CNAME.

------
 
      5.2.18  Common Address Formatting 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
         MUST NOT generate illegal address syntax.
 
         o    A common error is to leave out the semicolon after a group
              identifier.
 
         o    Some systems fail to fully-qualify domain names in
              messages they generate.  The right-hand side of an "@"
              sign in a header address field MUST be a fully-qualified
              domain name.
 
RFC 822

    6.2.3.  DOMAIN TERMS

        A domain-ref must be THE official name of a registry, network,
        or  host.

<actually, this quote is slightly out of context -- a domain-ref is
part of a domain name in 822, because 822 describes an older
version of the domain naming scheme>

Craig
  

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 13:48:59 EST
Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa11445;
          15 Dec 89 13:44 EST
Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA05972>; Fri, 15 Dec 89 10:42:53 -0800
Date: Fri, 15 Dec 89 10:43:52 PST
From: postel@venera.isi.edu
Posted-Date: Fri, 15 Dec 89 10:43:52 PST
Message-Id: <8912151843.AA00326@bel.isi.edu>
Received: by bel.isi.edu (4.0/4.0.3-4)
	id <AA00326>; Fri, 15 Dec 89 10:43:52 PST
To: header-people@mc.lcs.mit.edu, ietf-hosts@nnsc.nsf.net, 
    info-pmdf%ymir.bitnet@cunyvm.cuny.edu
Subject: Forwarding Mail into the Internet
Cc: Braden@venera.isi.edu, NAHAJ@cc.utah.edu, Postel@venera.isi.edu, 
    Tihor@acf7.nyu.edu, ned%ymir.bitnet@cunyvm.cuny.edu, rick@uunet.uu.net

Folks:

RFF-1123 page 67 says:

         (D)  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.

The last phrase means that you can't send a message into the Internet with
a mailbox address in its header that is not registered in the Domain Name
System (DNS).  For a mailbox address to be effective and useful for sending
replies to an Internet host, the Internet host must be able to translate 
the domain part of the mailbox to an IP address via the DNS (either MX or
A records).  So if the host asserted in the domain part is not registered
in the DNS database, then it is illegal to forward a message with that
mailbox address into the Internet.

Since ".BITNET" and ".UUCP" are not currently registered domains in the DNS,
mailbox address ending in these strings can't legally be sent into the Internet.

--jon.
 


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Dec 89 14:25:23 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22098;
          16 Dec 89 14:22 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6783; Sat, 16 Dec 89 14:21:39 EST
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1781;
 Sat, 16 Dec 89 14:21:38 EST
Received: from ODEN by brage.qz.se; Sat, 16 Dec 89 20:18 +0100
Date: 16 Dec 89 18:26 +0100
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with]
To: header-people <HEADER-PEOPLE@MC.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <475948@QZCOM>
In-Reply-To: <8912131614.aa13639@mintaka.lcs.mit.edu>

Our COM conferencing software uses message-id-s to eliminate
duplicates, stop loops etc. Note however, that there is a
security problem with this function. If a user happens to
know the ID of a message, but does not know the content,
then that user can send a false message, with different
content but the same ID, and the merging facility will then
merge them, which will allow people who have not access
rights to the original message to read it.

In order to avoid this security problem, we check that the
content is the same also, not only the ID, before merging.
This, however, also causes problems, since two copies of
the same message can sometimes be different, mostly in
double "headers". So some differences should be acceptable,
still accepting them as the same message.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Dec 89 14:25:29 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22101;
          16 Dec 89 14:22 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6784; Sat, 16 Dec 89 14:21:43 EST
Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1783;
 Sat, 16 Dec 89 14:21:43 EST
Received: from ODEN by brage.qz.se; Sat, 16 Dec 89 20:19 +0100
Date: 16 Dec 89 18:30 +0100
From: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Subject: Message-ID
To: header-people <HEADER-PEOPLE@MC.lcs.mit.edu>
Reply-to: Jacob Palme QZ <JPALME%com.qz.se@mitvma.mit.edu>
Message-ID:  <475949@QZCOM>
In-Reply-To: <8912140017.AA21968@ifi.uio.no>

I have spent a lot of effort in the last years in getting
the CCITT to accept the Message-ID as mandatory in the X.400
standard.

The reason for this is the advantage of Message-ID-s

(1) For merging duplicates of the same message

(2) For preserving conversations (set of messages related
by in-reply-to-links) from system to system, so that users
can be given facilities to browse conversations, store
them in special folders etc.

(3) For avoding loops. This is the least important use,
since CCITT has chosen to use other methods for loop
elimination in X.400.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Dec 89 00:14:35 EST
Received: from ALLSPICE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa23033;
          20 Dec 89 0:12 EST
Received: by PTT.LCS.MIT.EDU 
	id AA10876; Wed, 20 Dec 89 00:11:26 EST
Date: Wed, 20 Dec 89 00:11:26 EST
From: Noel Chiappa <jnc@ALLSPICE.LCS.MIT.EDU>
Message-Id: <8912200511.AA10876@PTT.LCS.MIT.EDU>
To: postel@venera.isi.edu
Subject: Re:  Forwarding Mail into the Internet
Cc: header-people@mc.lcs.mit.edu.jnc, ietf-hosts@nnsc.nsf.net

	Jon, I find your argument straightforward and compelling; if the
Host RFC does not say this clearly then the next Rev (dunno when we can
get that out, given the desire of manufacturers not to have Musical Specs)
ought to be cleaned up.

	Noel

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Dec 89 19:46:31 EST
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa02038;
          20 Dec 89 19:42 EST
Received: by decwrl.dec.com; id AA09745; Wed, 20 Dec 89 16:41:35 -0800
Received: by volition.pa.dec.com (5.57/4.7.34)
	id AA20380; Wed, 20 Dec 89 16:39:00 PST
Message-Id: <8912210039.AA20380@volition.pa.dec.com>
To: header-people@MC.lcs.mit.edu
Subject: 
Date: Wed, 20 Dec 89 16:38:58 PST
From: Dave Crocker <dcrocker@decwrl.dec.com>


------- Forwarded Message

Date: 14 Dec 89 13:48 EST
From: TIHOR@acf7.nyu.edu
Mmdf-Warning:  Parse error in original version of preceding line at lcs.mit.edu
To: rick@uunet.uu.net
Mmdf-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject: RE: A sad comentary
Cc: header-people@mc.lcs.mit.edu
Mmdf-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Message-Id: <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA>
In-Reply-To: Message of 14-DEC-1989 11:37:49 from rick@uunet.uu.net

...
Why we all know the intention is for the right had side of everything
in a SMTP address to be a domain name system resolvable name
THAT REQUEUIRMENT DOES NOT SEEM TO BE WRITTEN DOWN ANYWHERE.

I remember its discussion way back when but it does not see to have
made it into even the host requirements document except eliptically.

Thats no way to write standards.

Please provide exact citation and quotation for why X.Y.Z must be a
DNS name if the following addresses by the RFCs:


	<user@X.Y.Z>

	<@A.B.C:user@X.Y.Z>

	<@A.B.C,@X.Y.Z:user@D.E.F>

...
- -------


------- End of Forwarded Message

The Host Requirements document, for the upper layers, should leave no doubt
that the right-hand side must be "globally" resolvable to an Internet
host.

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Jan 90 02:36:59 EST
Received: from ACF7.NYU.EDU by mintaka.lcs.mit.edu id aa13524; 3 Jan 90 2:37 EST
Date:    Wed, 3 Jan 1990 2:36:13 EST
From:    Stephen Tihor <TIHOR@acf7.nyu.edu>
Message-Id: <900103023613.35409504@ACF7.NYU.EDU>
Subject: w/r/t Ned's reply
To:      header-people@mc.lcs.mit.edu
X-Vmsmail-To: IN%"header-people@mc.lcs.mit.edu"

I'll start by (once again) disagreeing with Ned's "answer" that .BITNET is the
"right" ting to emit.

I assert that (a) in the real world mailers shoudl be able to handle .BITNET
if it is handed to them.  (b) gateways should mangle the BITNET user@host into
the local part of their internet address.

Since I am on serious drugs after oral surgery I can get away with being brief.
I very much admire Ned's work on PMDF.  His reply that someone someone will
play with x%y in x%y@z so you should not use it is, perhaps, an arguement for
x.y@z.  It is not an arguement for .BITNET. 

I have pushed this issue because I think we can get it fixed and that the Ixyz
(for whatever xyz is apprporate) is responsible enough to recognize the problem
and agree with CREN as to the fix and tell the rest of us.

I don't care if we break the internet to bitnet links personally since we are
on both sides of the fence already and similarly we have no problems with
.BITNET nor with using eithe the offical INTERBIT gateway or our own private
gateway.  But NYU was an early ARPANET site.  We have allways had local mailer
expertise. 

I do want to see a real working and offical solution in place. SOON.  I want to
see Ned's "it just won't happen" disproved for the good of the little guys like
the one that started this discussion on INFO-PMDF.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Jan 90 07:10:57 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21997;
          3 Jan 90 7:10 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA10787; Wed, 3 Jan 90 06:47: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: 2 Jan 90 18:05:53 GMT
From: 1770 MCI <n8emr!vlink01!steve@ohio-state.arpa>
Organization: |UUCP Mail : osu-cis!vlink01!steve     |Vlink                |
Subject: MCIMAIL CMSLINK
Message-Id: <131@vlink01.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


There is a company called CMSLINK, in Southfield, MI, which makes a 
package which retrieves and sends MCI Mail.  It is available for Xenix.

I am looking for someone which could write me a bridge from the elm mailer
to re-format the enevelope from elm to work with this package available
from CMSLink.  

If anyone is interested in helping me out or can point me in the right
direction, I would welcome their email.  

Thanks so much, in advance.

uucp!osu-cis!vlink01!steve
-- 
|UUCP Mail : osu-cis!vlink01!steve     |Vlink                |
|MCI Mail  : uucp!mcimail.com!368-5882 |Steven E. Frazier    |      
|ATT Mail  : attmail!vlink01!steve     |1828 Darrow Drive    |
|Voice Mail: 614-755-3772              |Powell, Ohio  43065  |

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Jan 90 12:14:29 EST
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa01424;
          3 Jan 90 12:12 EST
Received: by decwrl.dec.com; id AA25431; Wed, 3 Jan 90 09:11:04 -0800
Received: by dcrocker.pa.dec.com (5.57/4.7.34)
	id AA06164; Wed, 3 Jan 90 09:09:49 PST
Message-Id: <9001031709.AA06164@dcrocker.pa.dec.com>
To: Stephen Tihor <TIHOR@acf7.nyu.edu>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: w/r/t Ned's reply 
In-Reply-To: Your message of Wed, 03 Jan 90 02:36:13 -0500.
             <900103023613.35409504@ACF7.NYU.EDU> 
Date: Wed, 03 Jan 90 09:09:47 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Drugs?  For oral surgery?  Gee, I thought that oral surgery would just
fix what you say...

Let me express some confusion about the .bitnet confusion.  No doubt,
much of what follows will show ignorance, ratherthan anything more
constructive:

The domain name system model should have no problem with the general
reference to bitnet.  Within that model, you can use either the existing
.NET top-level domain, registering .BIT.NET underneath it, or you can
try to convince a number of powers-that-be to register .BIT or .BITNET
at the top-level.

Assuming that you want to Bitnet gateways to encode routing information,
so that return mail will go to the same gateway that sent the original
message, then you need to code a domain name for each gateway.

Hence, a global Bitnet address, such as user@host1, becomes an Internet
address of user.host1@gatex.bit.net.  If you want to be extremely
clever, you could code it as user@host1.gatex.bit.net.  This requires choices
at the gateway and in the domain name system data base.  Neither should be
that tough to develop or operate.

So,

What subtleties have I missed?

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Jan 90 15:11:25 EST
Received: from NYU.EDU by mintaka.lcs.mit.edu id aa07425; 3 Jan 90 15:07 EST
Received: from ACF1.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34)
	id AA27891; Wed, 3 Jan 90 15:06:33 -0500
Date: 3 Jan 90 13:03 EST
From: TIHOR@acf7.nyu.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
To: dcrocker@nsl.dec.com
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject: RE: w/r/t Ned's reply
Cc: header-people@mc.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Message-Id: <347B774.35409A05.1990@ACF7.ACF7.NYU.EDU.ARPA>
In-Reply-To: Message of  3-JAN-1990 12:12:28 from dcrocker@nsl.dec.com

Someone say registereing BIT.NET would be a bad idea from a domain point of view
since its a physical connectivity rather than a logical location.
Anyway what I want is just to have the gateway which has to have an
internet address use user.host1@gateway.internetdomain.whatevertoplevels
or anything else it understands.  Ned says this is bad because there is a
brain damaged mailer out there (or several) that will parse user.host1
[Did I say that right or do I need more Oral surgery? :-) wince |-{ ]

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Jan 90 19:09:53 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa16461;
          3 Jan 90 19:07 EST
Date: Wed 3 Jan 90 19:02:41-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: w/r/t Ned's reply 
To: dcrocker@nsl.dec.com
Cc: TIHOR@acf7.nyu.edu, header-people@mc.lcs.mit.edu
Message-ID: <631411361.140000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <9001031709.AA06164@dcrocker.pa.dec.com>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

Dave and others,
  I've been away several times in the course of this discussion and decided 
to follow it, rather than putting my two cents in.  Now you get four cents. 
My apologies for going back over a little old ground, but it may be needed 
in context.  Much of this is also review of ancient history, but I think it 
may be worth repeating.

  A few little problems--but it is these sorts of "few" and "little" that
cause most of the problems of the universe.  The whole DNS notion, in 
addition to distributing the authority for names and name spaces, focused 
on "administrative" domains, not network-topological ones.  Since a large, 
and rising, number of BITNET sites are at institutions that have Internet 
sites and domains, establishing foo.bit.net is going to cause logical 
problems.  For example, you don't want to know whether MITVMC.MIT.EDU is a 
BITNET site or an Internet one (the former, but with an appropriate MX 
address).  Similarly, INFOODS.MIT.EDU (Internet) and MITVMA.MIT.EDU (both, 
and a gateway).  The BITNET folks have, incidentally, gone to a lot of 
trouble to make their part of this work--BITNET mail from most BITNET hosts 
addressed to Klensin@INFOODS.MIT.EDU will be routed to an appropriate 
BITNET host, over BITNET, and that host will know what to do with it (much 
like MX handling, but less dynamic).

The powers-that-be, as I understand it, would probably be happy to register 
.BIT.NET (or maybe even .BITNET) as a domain for the administrative folks 
who operate/maintain the thing, much as .CS.NET has long been registered as 
a domain.  But that would do no good for the user on an Internet machine 
who wants to address mail to a user on a BITNET machine which was not one 
of the operator/maintainer organization's installations, any more than a 
CSNET user node uses .CS.NET, rather than its own domain name and 
structure.

But the hard problems don't lie there anyway.  One can clearly write a UA 
that would take something the user types as user@foo.BITNET and transform 
it into user%foo.BITNET@gateway.  One could, in principle, transform it 
into "<@gateway:user@foo.BITNET>" but, as has been pointed out, this has 
always been illegal, since foo.BITNET isn't part of the DNS system--whether 
one could put it in and legalize it in future really has no bearing at the 
moment--and the HRRFC went out of its way to discourage the RFC822
source-route format anyway.  If the RFC does not make it completely clear
that names that appear to the right of @ must be DNS-registered names, I
can assure you that it wasn't because we didn't try: Bob and I had several 
exchanges in the hope of text that was clear without being irritating and 
patronizing.  I thought we had succeeded until this discussion chain 
started.

Given that interpretation, there are three forms in which a BITNET address 
can appear on the Internet:
  (1) The BITNET node can acquire and register a DNS name, possibly with 
MXs pointing to nearby gateways with preferences descending with increasing 
"distance".  That is what it is supposed to be all about.  Then we see,
e.g., user@foo.bar.edu
  (2) The bitnet address can be shown as local-part of a valid Internet 
address, e.g.,  user%foo.bar.edu@Internet-Bitnet-Gateway.mumble.edu or 
user%foo.BITNET@Internet-Bitnet-Gateway.mumble.edu or, in principle, as 
"/BITNET/user%foo"@Internet-Bitnet-Gateway.mumble.edu.  The point behind 
this last being that only the gateway cares how to parse the local part.
If the gateways were run by "the BITNET administration", they could be 
gateway.BIT.NET, as you point out.  But there really hasn't been a "BITNET 
administration", and the gateways are not run by them.  The advertised ones 
all all in university hands, and the unadvertised ones--well, who knows, 
but there are lots of them.
  (3) One can show the gateway, against the explicit recommendations of 
HRRFC, by using, e.g., <@gateway.mumble.edu:user@foo.bar.edu>.  But, here, 
foo.bar.edu must be an Internet DNS name of Internet-wide name definition, 
not something that only 'gateway.mumble.edu' can resolve unambiguously.  In 
the examples in (2) above, 'foo.BITNET' and 'foo.bar.edu' need only be 
names in the extended name space of the host/gateway Internet-Bitnet-
Gateway.mumble.edu.  They need not be Internet-unique, nor does '.edu' in 
that context necessarily mean what it would to the DNS.

All that is fine.  The problem arises with what a well-behaved gateway will 
do with BITNET mail coming into the Internet.  From the BITNET side of the 
gateway, it may get mail from, e.g., UNIVCMS1 or UNIVCMS1.BITNET or 
CMS1.UNIV.EDU (these are common transformations, but not rules, and it 
cannot be guaranteed that the second and third are, from the Internet side, 
the same machine).  Now, assuming that the gateway does not have sufficient 
knowledge to turn one of the first two into the third, the only thing that 
it can do is to map them into user%UNIVCMS1.BITNET@gateway-DNS-name
(although it can leave the ".BITNET" off if it likes, or spell it 
differently).  Can't emit it to the Internet as @UNIVCMS1.BITNET because 
that isn't a DNS address, and that is the way we wrote the rules, 
regardless of what Ned's software can do.
  And, since we (HRRFC) prohibit anyone but the gateway itself from 
rewriting a local-part, a reply to the message is going back the way it 
came in.  No problem--unless a message is forwarded several times, such as 
by a distribution list--that is probably the right gateway anyway.  And, if 
it isn't, it will work anyway, just be a tad suboptimal.  But so much for 
routing information.

  But, say the gateway gets lucky and sees @CMS1.UNIV.EDU.  The HRRFC text 
says, or was intended to say, that gateways should be pretty scrupulous 
about names being DNS names.  Let's even assume that it passes the name 
through a resolver and verifies that everyone is being well-behaved.  Now, 
what does it put out?  It has three choices:
   user%cms1.univ.edu@gateway-DNS-name   (anyway)
   user@cms1.univ.edu
   <@gateway-DNS-name:user@cms1.univ.edu>
Now, if the first is used, there is no hope for the receiving UA, in 
generating a reply, to send things out through another, more convenient,
gateway, since we prohibit looking at the local-part.  The second is, I 
think, our Internet preference, but it assumes/requires that the receiving 
host support the DNS and MX resolution (that is ok, since we require that 
capability now).  However, if "user" (the local-part) implies some machine 
reached via an MX, it also implies either that the final machine support 
the DNS for replies, or that the MX-target-gateway transform the address in 
some appropriate way.  The current BITNET->Internet gateways found those to 
be bad assumptions in practice--when it worked, it was fine, but, when it 
didn't, there was no way to reply--so that form is not used, at least at 
present.
  Finally, the third.  Well, HRRFC pretty agressively discourages its use 
at all.  My BITNET colleagues say "but it provides a hint as to how to get 
back and hence more robustness", which is a worthy goal.  And, while HRRFC 
quite deliberately avoided taking that position, it is logically possible 
to write an RFC821/822-consistent pair of rules that say, if you are a UA 
and receive something with an address in <@gateway-domain:user@user-domain>
form, and the user says "reply": 
 (i) You may reply to that address, i.e., source-route to 'gateway-domain' 
or, since you are guaranteed that 'user-domain' is a DNS name and parsing 
the address sufficiently to find it does not require that you parse a 
local-part,
 (ii) You may forget the source route, resolve 'user-domain' directly, and 
go happily on your way.
  Presumably, if you couldn't handle MXs, or were lazy, you would pick the 
first option; if you were clever or trying to be optimal, you would pick 
the second.
  And, now, we have routing information, handled correctly.  The BITNET 
host, and associated arrangements, specify which gateway its mail to the 
Internet goes through.  An Internet host, originating mail to a BITNET 
host, looks it up in the DNS, gets an MX, and does the right thing, using a 
gateway preference chosen by the target host.  An Internet host, *replying*
to a message from a BITNET host, either replies through the originating 
gateway or pretends that it is originating mail and uses the DNS resolver, 
depending on the incoming address syntax and on how smart it wants to be.  

>Assuming that you want to Bitnet gateways to encode routing information,
>so that return mail will go to the same gateway that sent the original
>message, ...
  Actually, you often don't want mail to go back to the same gateway
through which it came, which is one of the reasons this is a problem.  
Let's assume that a BITNET user at Stanford sends a contribution to 
header-people@mc.lcs.mit.edu.  Using standard BITNET software and tables,
that is a well-defined address in that form.  The message traverses the 
country on BITNET, gets to the MIT BITNET-Internet gateway, and shows up 
on the list and back to you as "From: user%stanfbar.BITNET@MITVMA.MIT.EDU"
or as "From: <@MITVMA.MIT.EDU:user@bar.stanford.edu>"  (you actually see
one of the other choices today, but it is illegal, and...).  Now, you want 
to send a note direct to the originator.  While it would work, albeit 
slowly, you really don't want to go back to MIT in order to get to a host 
that is a few miles from you.  You want to look up "bar.stanford.edu" in 
the DNS, and dispatch your message, presumably to a gateway within a 
hundred or so miles (and a very small number of BITNET hops) from the 
Stanford machine.
  And adding bar.stanford.bit.net addresses to the DNS really does not do 
much for that problem, regardless of how you spell it.  And it does mean 
that Stanford suddenly has to maintain two DNS name spaces, one for its 
BITNET hosts and one for its Internet hosts.  And that, in turn, implies 
that its gateway(s), if any, could end up with two names--bar.stanford.edu 
and bar.stanford.bit.net--which is part of what the DNS was intended to 
avoid.

Now, there is another part of Ned's comment, and the appropriate response.  
Read what he is doing a different way, and I think it is completely 
reasonable.  The distinction is between what capabilities it should be 
reasonable to have in an originating UA (or a surrogate for one) and what 
should be floating around the Internet or presented to an SMTP Server.
  If, on my local host, it amuses me to be able to type 
"myfriend@host.BITNET", or even "myfriend@host.bn", as if they were 
Internet DNS addresses, and I can negotiate or create a UA that will 
transform that into myfriend%host.bitnet@nearby-gateway-domain before 
passing them to an MTA, then there is nothing, in any protocol that 
prevents or argues against that.  It is a very handy typing/abbreviation 
convention, and a member of a class of things that a nice UA might have in 
it, nothing else.  Somewhat similar arguments can be made for "cleaning up"
addresses in incoming traffic, but have to be made carefully because
nothing guarantees that, in the syntax xxx%yyy.bitnet@remote-domain, "xxx"
is a user name and "yyy" is the name of a host on BITNET.  Only
"remote-domain" is presumed to know in any authoritative way. 

My apologies for kicking a dead horse, but this seems to keep coming up, in 
one form or another.
     john
     Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 00:52:35 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa01994; 4 Jan 90 0:41 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA07465; Thu, 4 Jan 90 01:38:00 -0400
Message-Id: <9001040538.AA07465@alw.nih.gov>
To: KLENSIN@infoods.mit.edu
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  00:39:55 EST
Subject:  Re:  w/r/t Ned's reply

I have just one question.  If user@node.BIT.NET is a bad idea, why are
user@host.UU.NET and the use of fidonet.org as a gateway to all of
Fidonet good ideas?  Both are being done now.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 01:41:25 EST
Received: from WSMR-SIMTEL20.ARMY.MIL by mintaka.lcs.mit.edu id aa03821;
          4 Jan 90 1:34 EST
Date: Wed, 3 Jan 1990  23:31 MST
Message-ID: <WANCHO.12555458149.BABYL@WSMR-SIMTEL20.ARMY.MIL>
From: "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
To:   Roger Fajman <RAF@cu.nih.gov>
Cc:   header-people@MC.lcs.mit.edu, KLENSIN@infoods.mit.edu, 
      WANCHO@wsmr-simtel20.army.mil
Subject: w/r/t Ned's reply
In-reply-to: Msg of 3 Jan 1990  22:39-MST from Roger Fajman <RAF at cu.nih.gov>

    If user@node.BIT.NET is a bad idea, why are user@host.UU.NET and
    the use of fidonet.org as a gateway to all of Fidonet good ideas?

Actually, the use of "...fidonet.org" is an excellent idea because
*all* of the entries exist as MX records pointing to the fidonet
gateway nearest to the target host.  Its clever use of MX records
should be the model for ...BIT.NET.

--Frank

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 10:05:23 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00671;
          4 Jan 90 10:04 EST
Date: Thu 4 Jan 90 07:53:42-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: w/r/t Ned's reply
To: WANCHO@wsmr-simtel20.army.mil
Cc: RAF@cu.nih.gov, header-people@MC.lcs.mit.edu
Message-ID: <631457622.950000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <WANCHO.12555458149.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>>    If user@node.BIT.NET is a bad idea, why are user@host.UU.NET and
>>    the use of fidonet.org as a gateway to all of Fidonet good ideas?
>
>Actually, the use of "...fidonet.org" is an excellent idea because
>*all* of the entries exist as MX records pointing to the fidonet
>gateway nearest to the target host.  Its clever use of MX records
>should be the model for ...BIT.NET.

  I'm not sure that "...fidonet.org" is the best idea I've ever heard of,
and would be interested in an authoritative answer from the namekeepers on
this one. Fidonet is, however, an "org", and its members are participants 
in that organization, which makes it at least a reasonable idea.  And, as 
Frank points out, subdomains point to the "right" gateways with carefully- 
chosen MX records, and many of the "wrong" gateways would be really wrong: 
There is no attempt to implement a guess-as-guess-can "Interbit" strategy 
on the Internet side, one which relies, on the BITNET side, on "nearest" 
gateway to the sender, not nearest to the receiver.
  "...fidonet.org" would become a relatively poor idea at the point that 
either of two things happened (my apologies for picking on Roger):
 (i) A fidonet site was set up at, e.g., NIH, and was given the name 
xxx.yyy.fidonet.org, rather than doggie.nih.gov.  Keep in mind that, since 
NIH already has a domain, "doggie.nih.gov" could perfectly well be a 
fidonet node, running fidonet protocols, as long as the DNS record could 
contain an MX pointing to an appropriate exchanger/gateway.
  or, even worse,
 (ii) that hypothetical machine had to be known, on the Internet, by both 
of those names, with different address routings to access them and the fact 
that it was the same machine known only by oral tradition and obscure 
lists.

This is the pragmatic problem with .BITNET, independent of all of the 
philosophical ones.  The vast majority of BITNET sites are located at 
places that have DNS domain assignments, or that will soon.  A machine 
having two name-identities is a poor idea, especially if those two
identities imply two separate routings from a given point.  As more and 
more of the institutions that support BITNET capability also acquire 
Internet/CREN capability, there will be more and more gateways which should 
be known to software and the DNS, but not the active concern of users.

For example, Roger, I now see your address as CU.NIH.GOV.  While I have 
vague recollections of TCP/IP nodes at NIH, it is a great pleasure to not 
have to know whether this machine is something that is "really" a BITNET 
site, and if it is, whether the MX gateway is at NIH or elsewhere, or 
whether it is actually an Internet site.  And, if my MTA here breaks, as it 
managed to do a few weeks ago for a short time, and I decide to answer your 
message from another machine, with different network connections (e.g., a 
BITNET host) it is a great pleasure that it can figure out what to do, 
(nearly-)optimally with CU.NIH.GOV given its topology and connections and, 
in particular, that I don't need to figure out if CU.NIH.GOV is "really" 
NIHCU.BITNET in order to avoid the "cross network B in order to deliver 
mail between two sites on network A" problem.

There are also a few pragmatic reasons why one does not want to try to 
maintain DNS resolution for fidonet nodes one at a time, or one per 
institution/household.  Most of the BITNET institutions already have 
adequate administrative setups, and there are enough alternate, but quite 
plausible, gateways to make a rich system of per-institution MXs, etc., 
quite useful.

As soon as the notions of ".BIT.NET" implying one gateway and there being 
any advantage in either maintaining a separate DNS registration authority 
for BITNET nodes or of trying to avoid such an authority at the node/host
level (as in fidonet) disappear, there are just no practical advantages to 
.BIT.NET as part of the DNS.  And there are several disadvantages.

As an aside, the evolving procedures for US and International registration
of organizational identifiers for OSI are following along much the same 
lines that I've attributed to the DNS registration rules: organizations, 
and hence subdomains, are administrative entities with the ability to do 
some administering or to pay someone to do that for them, they are not 
network topologies or lengths of wire.
   --john
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 10:10:42 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa00763;
          4 Jan 90 10:07 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7340; Thu, 04 Jan 90 03:49:37 EST
Received: from HASEOC.BITNET (NOREILLY) by MITVMA.MIT.EDU (Mailer R2.05) with
 BSMTP id 5133; Thu, 04 Jan 90 03:49:36 EST
Date:     Thu, 4 Jan 90 09:40 N
From:     NOREILLY%HASEOC.BITNET@mitvma.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject:  RE: w/r/t Ned's Reply
To:       HEADER-PEOPLE@MC.lcs.mit.edu
X-Original-To:  HDR-PPL
Message-ID:  <9001041007.aa00763@mintaka.lcs.mit.edu>

On Wed, 3 Jan 90 23:31:00 MST, "Frank J. Wancho" said:
>
> Actually, the use of "...fidonet.org" is an excellent idea because
> *all* of the entries exist as MX records pointing to the fidonet
> gateway nearest to the target host.  Its clever use of MX records
> should be the model for ...BIT.NET.
>
> --Frank

  Is everyone shouting the same thing, then?  How soon can we have
  all of BITNET existing as MX records pointing to the INTERBIT
  gateway nearest to the target host, or even nearest to the source
  host.

Niall

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 10:16:33 EST
Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa00865;
          4 Jan 90 10:11 EST
Received: from NET.Prime.COM by EN-C06.Prime.COM; 04 Jan 90 10:15:38 EST
Received: from Relay.Prime.COM by NET.Prime.COM; 04 Jan 90 10:09:32 EST
Received: (from user ARIEL) by Relay.Prime.COM; 04 Jan 90 10:11:40 EST
To: header-people@MC.lcs.mit.edu
Cc: cic@sh.cs.net
From: Robert Ullmann <Ariel@relay.prime.com>
Subject: re: .BITNET domain
Date: 04 Jan 90 10:11:40 EST
Message-ID:  <9001041011.aa00865@mintaka.lcs.mit.edu>

Hi,

The following is a slightly updated version of a message sent to the
CSnet/BITnet list(s) debating the (then) pending merger:

Re: how does a domain site handle user@somesite.BITNET ?

Please recall the almost painless (for DNS sites) conversion
from .ARPA to the preferred domain names, with the .ARPA zone
gradually coming to consist only of CNAME RRs ...

Proposal:

    the .BITNET domain should be registered, with CSnet/BITnet
    (whatever they call themselves now :-) providing the name service

    *.BITNET would then be MX'd to the default Interbit gates, with
    appropriate reference weights

    the gates would use addresses on outgoing (to Internet) mail with
    .BITNET where the sending host did not have a "real" domain name known
    to the gateway.

At this point, we have essentially the current routings. Then:

    BITNET sites with local gates could request the addition of
    MX records for their .BITNET systems. (with whatever definition
    of "local" the site and gateway prefer)

    as BITNET systems acquire real domain names, CNAME records can
    be added to redirect route inquiries to the domain MX records.

    the CNAMEs can then be used by the gates themselves to canonicalize
    names on outgoing mail.

    gates can stop generating routes (e.g.) ABC%SITE.BITNET@MITVMA.MIT.EDU
    instead generating ABC@SITE.BITNET

    the domain names can be phased in with little or no disruption

The .BITNET zone would be restricted, as a matter of policy, to
contain only CNAME and MX RR's; it would exist only as a transition domain.

This could be done with .BIT.NET instead; but it would involve many
changes to gates first, and also is a user-visible change; whereas
a .BITNET zone could be implemented with no changes, and has the advantage
of being "obviously" a transition domain ala .ARPA.

[ irrelevent observations:
I believe that there are any number of sites that would be willing
to act as Interbit gates, if only the traffic was limited to a
controllable set of BITNET destinations. At present, these are invisible
to the normal internet routing.

This sort of thing could also be done with .uucp. I have a program
which munches the /pathalias/ maps into a zone consisting entirely
of MX's and CNAMEs.

I have a collection of incendiary mail received from the first time
this was sent out; you are welcome to add to it ... :-)
]

Robert Ullmann
Prime Computer
Ariel@Relay.Prime.COM
+1 508 879 2960 x1736

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 10:39:45 EST
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa01360;
          4 Jan 90 10:28 EST
Received: by decwrl.dec.com; id AA29600; Thu, 4 Jan 90 07:26:12 -0800
Received: by dcrocker.pa.dec.com (5.57/4.7.34)
	id AA07524; Thu, 4 Jan 90 07:24:52 PST
Message-Id: <9001041524.AA07524@dcrocker.pa.dec.com>
To: Roger Fajman <RAF@cu.nih.gov>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: w/r/t Ned's reply 
In-Reply-To: Your message of Thu, 04 Jan 90 00:39:55 -0500.
             <9001040538.AA07465@alw.nih.gov> 
Date: Thu, 04 Jan 90 07:24:50 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Roger,  you raise a good political question, given that .uu.net is
currently used/accepted.

Technical point of distinction, however, is that bitnet has multiple
gateways to the Internet.  As I recall, uu.net refers to a single
gateway.

Therefore, bitnet would have to use gatex.bit.net, to get the same
degree of precision.  

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 14:13:22 EST
Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa09111;
          4 Jan 90 14:10 EST
To: header-people@MC.lcs.mit.edu
Subject: re: .BITNET domain
Date: Thu, 04 Jan 90 14:07:52 -0500
From: Craig Partridge <craig@nnsc.nsf.net>
Message-ID:  <9001041410.aa09111@mintaka.lcs.mit.edu>


Like John, I'd planned to stay out of the particular discussion about .BITNET,
I know too much of the history, but....

Some history:

In January of 1986 a group of people responsible for running the key
e-mail networks (or in the case of UUCP, a senior UUCPer, since no one
runs UUCP) met at SRI to discuss how the Internet's conversion to domain
names would affect the other networks.  After considerable discussion
about the merits of .BITNET and .CSNET vs descriptive domain names
ending in .EDU, .COM, etc., the following concensus emerged:

    (1) That topology based names like .BITNET and .CSNET were bad.
    In practice, users find the names confusing ("Gee, was Joe's
    account on BIG-U.BITNET or BIG-U.CSNET or BIG-U.ARPA???").
    Lest you think this is philosophical sophistry, there was,
    for a couple of years, a very large and prestigious university
    that had two hosts, named <University-name>.BITNET and
    <University-name>.CSNET which were not connected to each
    other.  Every week, the e-mail admins of the two machines
    held a tape swap to exchange mis-delivered mail.  I kid you not.

    (2) That there was a need for a domain for machines which were
    affiliated with network administrators as opposed to the corporations
    which ran them.  (I.e. BITNET has an identity independent of EDUCOM,
    and CSNET has an identity independent of BBN -- so for example,
    csnet-relay.bbn.com was clearly not the right name for the
    CSNET relay -- relay.cs.net made it's purpose more clear).

    (3) That all the networks (BITNET included) could reasonably implement
    domain names internally on their network, in a matter of a few
    years, thus allowing a unified e-mail world in which users only
    needed to type user@domain-name, no matter what network they were
    on (yes those of us at the meeting were being a bit starry eyed).

The policies the NIC tries to enforce on use of .NET and .BITNET are
a result of this meeting.

Observe that this meeting did not preclude naming BITNET gateways in
BIT.NET.  Many networks do just this -- relay.cs.net is a good example,
but so to are the names in NSF.NET which were given to the Phase I
NSFNET Fuzzballs.  Clearly the gateways play an important role in BITNET
and, in some sense, have a relationship with the folks that administer
BITNET.

What is precluded is doing something like BIG-U.BIT.NET where
BIG-U.BIT.NET is not an Interbit gateway but instead is simply the
BITNET host at BIG-U.  BIG-U should have its own domain name.

Note this meeting further precluded there ever being a .BITNET.

Craig

PS: I should further point out that, with the exception of BITNET,
all the major networks have gotten a long way to achieving universal
use of domains.  The last holdout in the Internet is the military.
CSNET is totally converted.  A large fraction of UUCP-land is
converted.  And user@domain is sure a whole lot less painful than
all those '%', '!' things.

PPS: As I recall, the BITNET plan was to revise the mail software to
map domain names into the fixed-length BITNET ids.  So there'd be
a step where the name vm.cuny.edu would map into an envelope address
CUNYVM that only the BITNET mailer would see; never the user.
Unknown addresses would be mapped to Interbit gateways which would
forward or reject them as appropriate (hacks like checking the right
side of unknown domain names against lists of known top-level domains
were to be used to limit the amount of bad mail being sent to gateways).

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 17:03:54 EST
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa15717;
          4 Jan 90 17:00 EST
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA03874; Thu, 4 Jan 90 13:58:55 PST
Date: Thu, 4 Jan 90 13:58:55 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9001042158.AA03874@garnet.berkeley.edu>
To: HEADER-PEOPLE@MC.lcs.mit.edu, MAIL-L@bitnic.bitnet
Subject: Simplification of internet mail addresses
Cc: hostmaster@nic.ddn.mil

I think it is time to go back to using simple internet mail addresses.

1. Recommendation:

Stop adding host-table-defined-domain hosts to addresses as in:
	mailbox%DNS-defined-domain@host-table-defined-domain
and use:
	mailbox@domain

For example, use:
	mailbox@dali.berkeley.edu
instead of:
	mailbox%dali.berkeley.edu@ucbvax.berkeley.edu
or:     <@ucbvax.berkeley.edu:mailbox@dali.berkeley.edu>

Justification: Elimate source routing resulting from using a
gateway type address to permit direct SMTP delivery.
All MILNET should have converted to the Internet Distributed
Nameserver System by October 1989 per RFC 1031. 
Does anyone know if this time table has been changed?


  RFC 1031                MILNET DOMAIN TRANSITION           November 1987

  MIGRATION TIMETABLE

   Table 1 shows the events and dates involved in the MILNET transition
   from host table to domain system.  The operational testing of the
   root server software has been completed.  Voluntary conversion can
   begin immediately, with mandatory conversion required by October
   1989.  After this date, hosts not converted need to obtain the host
   table equivalent by private arrangement (see "Migration Path" above).

                                                      Start     End
        Milestone                                      Date     Date
        ===========================================   ======   ======
        Root server operational testing               Dec 86   Jul 87
        Policy announced in DDN Management Bulletin   Oct 87
        Host conversion                               Oct 87   Oct 89
        Host table discontinued                       Oct 89

                       MILNET Name Domain Timetable

                                  Table 1


2. Recommendation:

Advise Internet mail users in the BITNET zone that they can stop using:
	mailbox%domain@mail-gateway-domain
on BITNET in most cases, and use the simple:
	mailbox@domain

Justification:  INTERBIT mail gateways now use DNS to resolve addresses
and can handle MX defined domains.  All internet top-domains are being
added to the DOMAIN NAMES mail gateway routing file. (MX only domains
were previously omitted because the gateways could not handle them.)

3. Recommendation:

Encourage Internet mail users in the UUCP zone to use mail software
that will support:
	mailbox@domain
or at least:
	domain!mailbox  (in UUCP mail, not the internet)

Justification:

Simplification of addresses.


Bill Wells, E-mail Postmaster & Network Consultant

------------------------------------------------------------------------
| William C. Wells      Telephone: 1 415 642-9801  (CA-ATSS: 582-9801) |
|         Data Communication & Network Services, 269 Evans Hall,       |
|           University of California, Berkeley, CA 94720, USA          |
------------------------------------------------------------------------
| Internet Mail System  postmaster@jade.berkeley.edu                   |
|  & BITNET VM Mailer:  netinfo@garnet.berkeley.edu                    |
| UUCP:     {harvard,rutgers,ucbvax,uunet}!garnet.berkeley.edu!netinfo |
| FAX (group III):      1 415 643-5385 (8am - 4:15pm, PST or PDT)      |
------------------------------------------------------------------------


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 18:37:03 EST
Received: from NIC.DDN.MIL by mintaka.lcs.mit.edu id aa17071; 4 Jan 90 17:32 EST
Date: Thu, 4 Jan 90 14:29:55 PST
From: Ken Harrenstien <KLH@nic.ddn.mil>
Subject: re: .BITNET domain
To: header-people@mc.lcs.mit.edu
cc: KLH@nic.ddn.mil
In-Reply-To: <9001041410.aa09111@mintaka.lcs.mit.edu>
Message-ID: <12555632625.27.KLH@NIC.DDN.MIL>

Like everyone else, I had hoped to stay out of this discussion too, but
it looks like a few words from here may help to prevent additional
go-arounds.

As far as I know, I was the person who originally invented .COM, .EDU,
.ORG, and the rest (guilty!).  We in our little NIC/ISI group had many
other ideas, but this was the one we reached consensus on.  I'm pretty
sure this was not the same meeting Craig mentions (which I recall as
the "bang-percent-atsign" group), but the conclusions we arrived at
did not change much with further meetings.

In particular, Craig's points are all correct.  In much the same way
that the consequences of relativity fall out of the simple assumption
that the speed of light is always constant, most of the domain name
system policies fall out of the simple goal of giving a host a name
that remains constant and unique regardless of your reference frame
(network).  Starry-eyed maybe, but laudable.  Note that the parallel
extends to the fact that from a single fixed frame, DNS looks the same
as a simple hostname scheme, just as relativistic equations collapse
into Newtonian mechanics.

Human policies are not quite as reliable as the laws of physics, however.
A classic example is MITRE.ORG, which should really be MITRE.COM; it just
slipped past because the NIC staff who did the actual registration paperwork
were still new to the concepts and reluctant to challenge apparently
knowledgeable applicants.  Then it was (or seemed) too late.

UU.NET was an aberration as well, which is why it is not a good model for
BITNET.

At the NIC we have received and rejected many, many requests to
register <clever-prefix>.NET.  After due explanation, most applicants
readily understand what we're trying to do.  All NET domains are supposed
to be used only for associating names with addresses used for network
control -- gateways, operation and information centers, and the like --
where the network is a recognizably distinct organization such as CSNET is.

I'm encouraged by the fact that more and more people are seeing the
light and taking over the evangelical duties formerly performed by
Paul Mockapetris and others.  As a contractual minion of DCA, it is not
always practical to speak up from here.

--Ken

P.S. An aside about FIDONET.  After a number of long discussions
caused by our refusal to register FIDO.NET, we eventually compromised
with IFNA.ORG since the IFNA (International FidoNet Association) was
the only thing close to an administrative entity.  Tim Pozar later
decided to replace it with FIDONET.ORG instead, which in my personal
opinion only continues to perpetuate Newtonian thinking.  Oh well.
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 18:50:22 EST
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa20463;
          4 Jan 90 18:47 EST
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA05785; Thu, 4 Jan 90 14:50:09 PST
Date: Thu, 4 Jan 90 14:50:09 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9001042250.AA05785@garnet.berkeley.edu>
To: header-people@MC.lcs.mit.edu
Subject: Re: w/r/t Ned's reply
Cc: postmaster@uunet.uu.net

The issue is simple, those BITNET sites that do not register 
internet domain names for their sites and impliment mail software
that can handle internet domain addressess are not part of the
Internet Mail System.  I see the nodeid.BIT.NET and nodeid.BITNET
domain proposals as a move by those BITNET sites that are too lazy
to implement the proper software to participate in the Internet
Mail System.  These proposals are fueled in part by "true blue" nodes
on the BITNET who will only run IBM software on their IBM systems.

In reply to:

	Date: Thu, 04 Jan 90 07:24:50 PST
	From: Dave Crocker <dcrocker@nsl.dec.com>

	Roger,  you raise a good political question, given that .uu.net
	is currently used/accepted.

According to the Internet nameserver at uunet.uu.net the following
domains are defined in the UU.NET domain:

 bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net
 janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net
 seismo.uu.net tb.uu.net uunet.uu.net

So it should be apparent at UU.NET domain is only being used for UUNET
network gateway services related hosts and not all the nodes in the
UUCP world.

	Technical point of distinction, however, is that bitnet has
	multiple gateways to the Internet.  As I recall, uu.net refers
	to a single gateway.

UUNET is not a network, but a gateway service providing forwarding
services for messages sent to contracting sites.  I believe that
all sites paying for UUNET gateway services now have or will soon
internet domain names. I suspect that in the future, uunet.uu.net
may phase out support for addresses of the form

	host!user@uunet.uu.net

since they are not a general Internet/UUCP gateway.

	Therefore, bitnet would have to use gatex.bit.net, to get the
	same degree of precision.

	Dave

This is a bad idea. Users should not be doing source routing. 
Addressing from any part of the Internet mail system (SMTP, UUCP, or
BITNET zones) should use the simple internet address format:

	mailbox@domain

From the internet SMTP zone, MX records should be defined for
BITNET zone mail domains to at least two and perhaps all INTERBIT
gateways with different precedences reflecting the topology of the
BITNET. With this setup the user is not concerned with source routing
and mail is automatically routed to the next nearest INTERBIT
gateway when is the primary gateway is down.


Bill Wells
postmaster@jade.berkeley.edu
netinfo@garnet.berkeley.edu

PS. The above opinions are my own and not necessarily those of my
employer, the University of California.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 20:16:22 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa23780; 4 Jan 90 20:13 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA13390; Thu, 4 Jan 90 21:00:59 -0400
Message-Id: <9001050100.AA13390@alw.nih.gov>
To: KLENSIN@infoods.mit.edu
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  20:03:57 EST
Subject:  Re:  w/r/t Ned's reply

>   I'm not sure that "...fidonet.org" is the best idea I've ever heard of,
> and would be interested in an authoritative answer from the namekeepers on
> this one. Fidonet is, however, an "org", and its members are participants
> in that organization, which makes it at least a reasonable idea.  And, as
> Frank points out, subdomains point to the "right" gateways with carefully-
> chosen MX records, and many of the "wrong" gateways would be really wrong:
> There is no attempt to implement a guess-as-guess-can "Interbit" strategy
> on the Internet side, one which relies, on the BITNET side, on "nearest"
> gateway to the sender, not nearest to the receiver.

Why is FidoNet more of an "org" than BITNET?  BITNET, of course,
currently has different administrations for BITNET (US), EARN, and
NETNORTH.  But the International FidoNet Association does not by any
means own all the FidoNet nodes.  I think that some if the FidoNet
zones (e.g., RBBS-NET) are separately administered, but I'm not
positive about that.  (I'm just starting to learn more about FidoNet.)
CREN is the corporation that administers the US portion of BITNET.
Somehow I don't think you would be happier with user@host.CREN.ORG,
user@host.EARN.ORG, etc., but I still don't see the essential
difference from FidoNet.

You may say that most of the FidoNet systems are operated by
individuals, and I agree with that.  But such systems, could, in
principle, be registered under the US and other country domains.  Not
that I'd care to take on that job.

And what about the use of user@host.UU.NET?  Why is that OK?

>   "...fidonet.org" would become a relatively poor idea at the point that
> either of two things happened (my apologies for picking on Roger):
>  (i) A fidonet site was set up at, e.g., NIH, and was given the name
> xxx.yyy.fidonet.org, rather than doggie.nih.gov.  Keep in mind that, since
> NIH already has a domain, "doggie.nih.gov" could perfectly well be a
> fidonet node, running fidonet protocols, as long as the DNS record could
> contain an MX pointing to an appropriate exchanger/gateway.
>   or, even worse,
>  (ii) that hypothetical machine had to be known, on the Internet, by both
> of those names, with different address routings to access them and the fact
> that it was the same machine known only by oral tradition and obscure
> lists.

I see no mention in the FidoNet gateway description of the possiblity
of a FidoNet node having its own name (i.e., doggie.nih.gov) in the
DNS.  But if it did, I don't see how that would prevent it also being
addressed as Fnnn.Nnnn.Zn.FIDONET.ORG. In order to implement DNS
domains for FidoNet nodes, the gateways would have to keep a large list
giving the translation.  This is similar to the problem for BITNET if
the translation idea suggested by some is used.

For a more real life example, I am SYSOP of a BBS for the Capital PC User
Group.  I plan to put that BBS on FidoNet.  I could apply for a domain
name (CPCUG.ORG) and probably find someone to do name service for it,
but as near as I can tell, there's no way for the FidoNet gateway to
be told about it.  Please correct me if I am wrong.

> This is the pragmatic problem with .BITNET, independent of all of the
> philosophical ones.  The vast majority of BITNET sites are located at
> places that have DNS domain assignments, or that will soon.  A machine
> having two name-identities is a poor idea, especially if those two
> identities imply two separate routings from a given point.  As more and
> more of the institutions that support BITNET capability also acquire
> Internet/CREN capability, there will be more and more gateways which should
> be known to software and the DNS, but not the active concern of users.

Where are the statistics that support your statement?  I see 161 domains
defined in the current BITNET DOMAIN NAMES file.  Even if all are assumed
to be US domains (they're not - many are country domains), that's still
maybe only a third of the BITNET membership (not counting EARN and NETNORTH).

And the mere fact that a domain is registered doesn't make the software
to support domains magically appear on all BITNET machines that might
possibly be a part of that domain.  We had to write ours.

> For example, Roger, I now see your address as CU.NIH.GOV.  While I have
> vague recollections of TCP/IP nodes at NIH, it is a great pleasure to not
> have to know whether this machine is something that is "really" a BITNET
> site, and if it is, whether the MX gateway is at NIH or elsewhere, or
> whether it is actually an Internet site.  And, if my MTA here breaks, as it
> managed to do a few weeks ago for a short time, and I decide to answer your
> message from another machine, with different network connections (e.g., a
> BITNET host) it is a great pleasure that it can figure out what to do,
> (nearly-)optimally with CU.NIH.GOV given its topology and connections and,
> in particular, that I don't need to figure out if CU.NIH.GOV is "really"
> NIHCU.BITNET in order to avoid the "cross network B in order to deliver
> mail between two sites on network A" problem.

I agree with that, and have worked towards getting better support for
domains in the BITNET protocols.  But the fact is that domains are only
partially supported in the BITNET protocols -- only for mail, not for
file transfer or interactive messages.  So when we put CU.NIH.GOV on
the Internet (yes, it is an Internet host now), we had to make a
decision about how to be known on BITNET.  Mail can be sent to
CU.NIH.GOV on BITNET and we will accept it, but when we send mail to
BITNET we do it as NIHCU.  The reason is that it is easier to explain
that we are CU.NIH.GOV on the Internet and NIHCU on BITNET, than to
explain that for mail it's CU.NIH.GOV, but for BITNET file transfer and
interactive messages it's NIHCU.

> There are also a few pragmatic reasons why one does not want to try to
> maintain DNS resolution for fidonet nodes one at a time, or one per
> institution/household.  Most of the BITNET institutions already have
> adequate administrative setups, and there are enough alternate, but quite
> plausible, gateways to make a rich system of per-institution MXs, etc.,
> quite useful.

True, but the protocols are not in place to do a complete job to
implement domains on BITNET.  I've made proposals myself to change
that, but so far it's come to no more than talk.

> As soon as the notions of ".BIT.NET" implying one gateway and there being
> any advantage in either maintaining a separate DNS registration authority
> for BITNET nodes or of trying to avoid such an authority at the node/host
> level (as in fidonet) disappear, there are just no practical advantages to
> .BIT.NET as part of the DNS.  And there are several disadvantages.

There's nothing that says that BIT.NET would have to imply only one
gateway any more than FIDONET.ORG does.  There may be no practical
advantages on the Internet side, but given the current state of things,
there are on the BITNET side.

> As an aside, the evolving procedures for US and International registration
> of organizational identifiers for OSI are following along much the same
> lines that I've attributed to the DNS registration rules: organizations,
> and hence subdomains, are administrative entities with the ability to do
> some administering or to pay someone to do that for them, they are not
> network topologies or lengths of wire.
>    --john
> -------

It's easier to do when you get to define the protocols in advance.
Of course, it is taking a while to get done.  :-)

I agree that network-independent naming is a great idea.  But BITNET isn't
ready for it and may never be.  So the real question is whether it's worth
doing anything beyond what we already have while we are waiting.

Roger Fajman


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 20:16:42 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa23828; 4 Jan 90 20:15 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA13419; Thu, 4 Jan 90 21:12:09 -0400
Message-Id: <9001050112.AA13419@alw.nih.gov>
To: dcrocker@nsl.dec.com
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  20:15:22 EST
Subject:  Re:  w/r/t Ned's reply

> Roger,  you raise a good political question, given that .uu.net is
> currently used/accepted.
>
> Technical point of distinction, however, is that bitnet has multiple
> gateways to the Internet.  As I recall, uu.net refers to a single
> gateway.
>
> Therefore, bitnet would have to use gatex.bit.net, to get the same
> degree of precision.
>
> Dave

No, multiple gateways could be done with appropriate MX records, just
as is done with FIDONET.ORG.  A.BIT.NET and B.BIT.NET could be MXed to
different gateways.

And how is the following justified?  It's from a recent message to Info-Nets.

  +=============== HOW TO ADDRESS MESSAGES TO INDIAN SITES ================+
  |                                                                        |
  |  If you are at an Internet site         |  site!user@shakti.uu.net  OR |
  |  that can handle domains                |  user%site@shakti.uu.net     |
  |------------------------------------------------------------------------|
  |  If you are at a site that can't        |  uunet!shakti!site!user      |
  |  handle domains                         |                              |
  +========================================================================+

Apparently, shakti.uu.net is in India.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 20:32:30 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa24327; 4 Jan 90 20:28 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA13427; Thu, 4 Jan 90 21:24:41 -0400
Message-Id: <9001050124.AA13427@alw.nih.gov>
To: craig@nnsc.nsf.net
Cc: header-people@MC.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  20:27:37 EST
Subject:  re:  .BITNET domain

>     (3) That all the networks (BITNET included) could reasonably implement
>     domain names internally on their network, in a matter of a few
>     years, thus allowing a unified e-mail world in which users only
>     needed to type user@domain-name, no matter what network they were
>     on (yes those of us at the meeting were being a bit starry eyed).

Unfortunately, this has not come to pass on BITNET.  It does (mostly)
work for mail, but not for other BITNET services (file transfer and
interactive messages).  So it's not possible for a BITNET node to
use its domain name exclusively.  How would you like it if you had to
use one name to send email to a machine and another to FTP to it?
That's the situation with domain names on BITNET.

> The policies the NIC tries to enforce on use of .NET and .BITNET are
> a result of this meeting.
>
> Observe that this meeting did not preclude naming BITNET gateways in
> BIT.NET.  Many networks do just this -- relay.cs.net is a good example,
> but so to are the names in NSF.NET which were given to the Phase I
> NSFNET Fuzzballs.  Clearly the gateways play an important role in BITNET
> and, in some sense, have a relationship with the folks that administer
> BITNET.
>
> What is precluded is doing something like BIG-U.BIT.NET where
> BIG-U.BIT.NET is not an Interbit gateway but instead is simply the
> BITNET host at BIG-U.  BIG-U should have its own domain name.
>
> Note this meeting further precluded there ever being a .BITNET.
>
> Craig

My original question is why are these policies not enforced
consistently with respect to FIDONET.ORG and UU.NET?  Why is an Indian
host named shakti.uu.net acceptable while a similarly named BITNET host
is not?

> PS: I should further point out that, with the exception of BITNET,
> all the major networks have gotten a long way to achieving universal
> use of domains.  The last holdout in the Internet is the military.
> CSNET is totally converted.  A large fraction of UUCP-land is
> converted.  And user@domain is sure a whole lot less painful than
> all those '%', '!' things.
>
> PPS: As I recall, the BITNET plan was to revise the mail software to
> map domain names into the fixed-length BITNET ids.  So there'd be
> a step where the name vm.cuny.edu would map into an envelope address
> CUNYVM that only the BITNET mailer would see; never the user.
> Unknown addresses would be mapped to Interbit gateways which would
> forward or reject them as appropriate (hacks like checking the right
> side of unknown domain names against lists of known top-level domains
> were to be used to limit the amount of bad mail being sent to gateways).

This is pretty much the way it works.  But only for email.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 20:54:14 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa25225; 4 Jan 90 20:52 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA13487; Thu, 4 Jan 90 21:48:47 -0400
Message-Id: <9001050148.AA13487@alw.nih.gov>
To: KLH@nic.ddn.mil
Cc: header-people@MC.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  20:51:36 EST
Subject:  re:  .BITNET domain

> UU.NET was an aberration as well, which is why it is not a good model for
> BITNET.

What's the story there?

> At the NIC we have received and rejected many, many requests to
> register <clever-prefix>.NET.  After due explanation, most applicants
> readily understand what we're trying to do.  All NET domains are supposed
> to be used only for associating names with addresses used for network
> control -- gateways, operation and information centers, and the like --
> where the network is a recognizably distinct organization such as CSNET is.
>
> I'm encouraged by the fact that more and more people are seeing the
> light and taking over the evangelical duties formerly performed by
> Paul Mockapetris and others.  As a contractual minion of DCA, it is not
> always practical to speak up from here.
>
> --Ken

I understand the policy and have for a long time.  What I don't
understand is why exceptions are made in some cases and not others.

> P.S. An aside about FIDONET.  After a number of long discussions
> caused by our refusal to register FIDO.NET, we eventually compromised
> with IFNA.ORG since the IFNA (International FidoNet Association) was
> the only thing close to an administrative entity.  Tim Pozar later
> decided to replace it with FIDONET.ORG instead, which in my personal
> opinion only continues to perpetuate Newtonian thinking.  Oh well.

Why did you compromise?  As I understand the policy, none of those
names should have been registered for the use in question.  I don't
think that many people care much whether the name ends in NET, ORG, or
whatever.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Jan 90 21:10:56 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa25960; 4 Jan 90 21:09 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA13502; Thu, 4 Jan 90 22:04:49 -0400
Message-Id: <9001050204.AA13502@alw.nih.gov>
To: netinfo@garnet.berkeley.edu
Cc: header-people@MC.lcs.mit.edu, postmaster@uunet.uu.net
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 04 Jan 90  21:07:50 EST
Subject:  Re:  w/r/t Ned's reply

> The issue is simple, those BITNET sites that do not register
> internet domain names for their sites and impliment mail software
> that can handle internet domain addressess are not part of the
> Internet Mail System.  I see the nodeid.BIT.NET and nodeid.BITNET
> domain proposals as a move by those BITNET sites that are too lazy
> to implement the proper software to participate in the Internet
> Mail System.  These proposals are fueled in part by "true blue" nodes
> on the BITNET who will only run IBM software on their IBM systems.

That's not my motivation -- we've already written such software for
ourselves.  I'm just trying to make people more familiar with the
significant problems remaining with the implementation of domains on
BITNET.  In my opinion, there's too much Internet-centric thinking on
the issue.  BITNET is not the Internet.

> According to the Internet nameserver at uunet.uu.net the following
> domains are defined in the UU.NET domain:
>
>  bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net
>  janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net
>  seismo.uu.net tb.uu.net uunet.uu.net
>
> So it should be apparent at UU.NET domain is only being used for UUNET
> network gateway services related hosts and not all the nodes in the
> UUCP world.

So where does shakti.uu.net come into it?  I've also seen mail
come from intercon.uu.net (but not recently).


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Jan 90 13:31:39 EST
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa01263;
          5 Jan 90 13:25 EST
Received: by uunet.uu.net (5.61/1.14) 
	id AA13394; Fri, 5 Jan 90 10:42:13 -0500
From: UUNET Postmaster <root@uunet.uu.net>
Message-Id: <9001051542.AA13394@uunet.uu.net>
Subject: Re:  w/r/t Ned's reply
To: Roger Fajman <RAF@cu.nih.gov>
Date: Fri, 5 Jan 90 10:42:08 EDT
Cc: netinfo@garnet.berkeley.edu, header-people@MC.lcs.mit.edu
In-Reply-To: <9001050204.AA13502@alw.nih.gov>; from "Roger Fajman" at Jan 04, 90 9:07 pm
X-Mailer: ELM [version 2.2 PL14]

> From RAF@CU.NIH.GOV Fri Jan  5 05:35:34 1990
> From: "Roger Fajman" <RAF@CU.NIH.GOV>
> Date:     Thu, 04 Jan 90  21:07:50 EST
> 

[discussion about BIT.NET vs BITNET sites deleted]

> 
> > According to the Internet nameserver at uunet.uu.net the following
> > domains are defined in the UU.NET domain:
> >
> >  bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net
> >  janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net
> >  seismo.uu.net tb.uu.net uunet.uu.net
> >
> > So it should be apparent at UU.NET domain is only being used for UUNET
> > network gateway services related hosts and not all the nodes in the
> > UUCP world.
> 
> So where does shakti.uu.net come into it?  I've also seen mail
> come from intercon.uu.net (but not recently).

There are tremendous number of uunet subscribers using such domain addresses
much to my dismay.  At some point some site started this little problem and
way to many sites have picked up on it.

Everytime I see it used (and that's a *lot*) I send a nice little form letter
requesting that they either register a real domain name or stop using ours.
Mostly they seem to disregard it.

If we ever feel like removing the relevant lines from sendmail.cf we'll bring
down the whole thing in a hurry.  I really don't want to have to deal with all
those people asking why their mail doesn't work though.

	-- uunet postmaster (James Revell)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Jan 90 15:19:10 EST
Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa05930;
          5 Jan 90 15:15 EST
Received: by uunet.uu.net (5.61/1.14) 
	id AA25399; Fri, 5 Jan 90 13:53:09 -0500
Date: Fri, 5 Jan 90 13:53:09 -0500
From: Rick Adams <rick@uunet.uu.net>
Message-Id: <9001051853.AA25399@uunet.uu.net>
To: RAF@cu.nih.gov, dcrocker@nsl.dec.com
Subject: Re:  w/r/t Ned's reply
Cc: header-people@MC.lcs.mit.edu


And how is the following justified?  It's from a recent message to Info-Nets.

  +=============== HOW TO ADDRESS MESSAGES TO INDIAN SITES ================+
  |                                                                        |
  |  If you are at an Internet site         |  site!user@shakti.uu.net  OR |
  |  that can handle domains                |  user%site@shakti.uu.net     |
  |------------------------------------------------------------------------|
  |  If you are at a site that can't        |  uunet!shakti!site!user      |
  |  handle domains                         |                              |
  +========================================================================+

Apparently, shakti.uu.net is in India.

-----

Funny how the people who claim that network independant naming is a good
idea are complaing about the geographic location of uunet's
gateway to India (which is,cleverly enough, in India). Shatki is
within UUNET's organizational domain, so the name SHOULD be unrelated
to geography.

Purist will be happy to note that the .IN top level domain for India
has been registered and the sites we are dealing with that are
Physically in India are being converted to that domain (including shakti).

The use of shakti.uu.net is a transitional convenience.

Remember that, uunet != all uucp sites != all usenet sites
(although I'm working on it...)

---rick


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Jan 90 23:11:09 EST
Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa00579;
          5 Jan 90 22:50 EST
To: raf@cu.nih.gov
cc: header-people@mc.lcs.mit.edu
Subject: re: .BITNET domain
Date: Fri, 05 Jan 90 08:14:49 -0500
From: Craig Partridge <craig@nnsc.nsf.net>
Message-ID:  <9001052250.aa00579@mintaka.lcs.mit.edu>


> My original question is why are these policies not enforced
> consistently with respect to FIDONET.ORG and UU.NET?  Why is an Indian
> host named shakti.uu.net acceptable while a similarly named BITNET host
> is not?

If shakti isn't a host involved in running uu.net it isn't acceptable use.
(I don't personally know the status of shakti).  As for enforcement,
that's a tricky question.  It isn't clear there is an enforcement mechanism,
short of turning off uu.net at the root domain servers -- that's a rather
extreme act.  All the more reason for the NIC to be careful about who it
gives .NET domains to.

>> PPS: As I recall, the BITNET plan was to revise the mail software to
>> map domain names into the fixed-length BITNET ids.  So there'd be
>> a step where the name vm.cuny.edu would map into an envelope address
>> CUNYVM that only the BITNET mailer would see; never the user.
>> Unknown addresses would be mapped to Interbit gateways which would
>> forward or reject them as appropriate (hacks like checking the right
>> side of unknown domain names against lists of known top-level domains
>> were to be used to limit the amount of bad mail being sent to gateways).

> This is pretty much the way it works.  But only for email.

Why only for e-mail?  It would seem to me that if a conversion scheme
exists, you ought (in principle) to be able to fit it into the user
interface of other protocols.  My internet address is 128.89.1.178 -- but
I can type nnsc.nsf.net to telnet.

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU;  6 Jan 90 00:53:04 EST
Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU;  6 Jan 90 00:53:09 EST
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa03955;
          6 Jan 90 0:50 EST
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA25210; Fri, 5 Jan 90 21:50:39 PST
Date: Fri, 5 Jan 90 21:50:39 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9001060550.AA25210@garnet.berkeley.edu>
To: header-people@ai.ai.mit.edu, postmaster@uunet.uu.net, RAF@cu.nih.gov
Subject: Re:  w/r/t Ned's reply

In reply to:

	From: "Roger Fajman" <RAF@CU.NIH.GOV>
	Date:     Thu, 04 Jan 90  21:07:50 EST
	Subject:  Re:  w/r/t Ned's reply


	...  In my opinion, there's too much Internet-centric thinking on
	the issue.  BITNET is not the Internet.

Yes, BITNET is not the Internet. But, the VM Mailer
system and clones are part of the Internet Mail System.
Thus, we need to adopt Internet policies and procedures for the
BITNET VM Mailer System.

I prefer to encourage BITNET/EARN/NETNORTH/ASIANET net sites to
become part of the Internet mail system by registering an internet
domain name and implementing the appropriate internet software.
Defining a network domain name is inappropriate for the following
reasons:

	a. We will soon have hundreds of BITNET sites on the
Internet as internet nodes.

	b. It is inappropriate to be sending mail from the
internet via the BITNET to a directly connected internet site.
This is already accords because network dependant addresses are
given to users.  We need network independant addresses to allow
routing to be determined by site, not networks.

	c. Network domain names do not allow for direct routing
to a site gateway on the internet.

	d. Listing each node of a network in the Internet nameserver
is more work than listing wild-card entries by site. (BITNET only lists
country domains by country, it should also allow entries by sites in
the DOMAIN NAMES file, but then that is also more work).

----

	So where does shakti.uu.net come into it?  I've also seen mail
	come from intercon.uu.net (but not recently).

It is not authorized, but it works because the uu.net nameserver has
a wild-card entry for *.uu.net.  If I was the postmaster at uunet.uu.net
I would remove that wild card entry.

----

Bill Wells
postmaster@jade.berkeley.edu
netinfo@garnet.berkeley.edu

PS. The opinions expressed above are my own.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Jan 90 05:47:38 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa03064;
          6 Jan 90 0:15 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1914; Sat, 06 Jan 90 00:15:04 EST
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id
 8069; Sat, 06 Jan 90 00:15:03 EST
Date:    Fri, 05 Jan 90 21:14 PST
To:      Craig Partridge <craig@nnsc.nsf.net>
Cc:      header-people@mc.lcs.mit.edu
From:    Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Subject: Re: .BITNET domain
Message-ID:  <9001060015.aa03064@mintaka.lcs.mit.edu>

On Fri, 05 Jan 90 08:14:49 -0500,
   Craig Partridge <craig@NNSC.NSF.NET> said:
> >> (discussion of mapping domain names to bitnet node names deleted)
> > This is pretty much the way it works.  But only for email.
>
> Why only for e-mail?  It would seem to me that if a conversion scheme
> exists, you ought (in principle) to be able to fit it into the user
> interface of other protocols.  My internet address is 128.89.1.178 -- but
> I can type nnsc.nsf.net to telnet.

Yes, in principle.  Bitnet E-mail uses programs written by Bitnet
people, not vendors, so it can be made to do what we need, and in
finite time rather than in geologic time.  Other services (file
transfer and interactive messaging) use facilities supplied by
vendors, generally without source code.  For TSO, it should be
possible to write a front end to the TRANSMIT command to allow domain
names to be used.  I suspect that everyone is waiting for someone else
to do it.  I could write it, but it's low on my priority list, since I
think that Bitnet has leapt too fast into domain names.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Jan 90 14:09:42 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa24217; 6 Jan 90 13:59 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA18823; Sat, 6 Jan 90 14:57:34 -0400
Message-Id: <9001061857.AA18823@alw.nih.gov>
To: craig@nnsc.nsf.net
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Sat, 06 Jan 90  13:58:58 EST
Subject:  re:  .BITNET domain

> >> PPS: As I recall, the BITNET plan was to revise the mail software to
> >> map domain names into the fixed-length BITNET ids.  So there'd be
> >> a step where the name vm.cuny.edu would map into an envelope address
> >> CUNYVM that only the BITNET mailer would see; never the user.
> >> Unknown addresses would be mapped to Interbit gateways which would
> >> forward or reject them as appropriate (hacks like checking the right
> >> side of unknown domain names against lists of known top-level domains
> >> were to be used to limit the amount of bad mail being sent to gateways).
>
> > This is pretty much the way it works.  But only for email.
>
> Why only for e-mail?  It would seem to me that if a conversion scheme
> exists, you ought (in principle) to be able to fit it into the user
> interface of other protocols.  My internet address is 128.89.1.178 -- but
> I can type nnsc.nsf.net to telnet.

Yes, in principle, it can be done for the other protocols and it should
be.  But the current reality is that it hasn't.  I made a proposal
myself to enhance BSMTP to support BITNET-style file transfer with
domain names.  But that proposal has not been adopted and no others
have been put forward.  One problem is that there still is no mechanism
for adopting standards for BITNET.  Another problem is that no one is
stepping forward to write the software.  We can't do it, as our
environment is not typical of BITNET, in which IBM VM and VAX VMS
systems predominate.

Given the current state of things, there is a strong motivation for a
system with both BITNET and Internet connections to support domain
names on BITNET as well as the Internet.  But for systems with only a
BITNET connection, domain names are currently something of a negative,
because of the lack of support for file transfer and interactive
messages.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Jan 90 16:45:55 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa29011; 6 Jan 90 16:26 EST
Received: from svarte.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA04547; Sat, 6 Jan 90 22:25:33 +0100
Date: Sat, 6 Jan 90 22:25:33 +0100
From: Erik Naggum <erik.naggum@uunic.uu.no>
Sender: enag@ifi.uio.no
To: header-people@mc.lcs.mit.edu
Subject: .BITNET and the Internet
Summary: The problem should be solved at the gateways.
Message-Id: <90-006-1521@uunic.uu.no>

There have been gripes about a certain Internet-centricity in this
discussion.  This is certainly right -- the Internet has a full body
of standards, and if you want to play, you have to follow the rules.
However, none of the people who write these standards try to enforce
their view on networks who borrow good ideas, or just look similar to
Internet ways in certain application.  An occasionally squeeking
spectator in the RFC 1122/3 work, I saw that it was hard enough to get
the Old Network Boys to consider other networks at all.  It took me
some time to realize that it wasn't really their business to care
about these other networks who were nevertheless likely to follow
their lead, anyway.  IMHO, this is the problem that e.g. Roger Fajman
has.

As far as the Internet is concerned, you can mangle your mail headers
all you want as long as you are not travelling on the Internet.  If
some user wants to see "FOOBAR.BITNET" in his mail, and send to it,
the underlying software should rewrite this to the equivalent domain
name when the mail enters the Internet.  Equivalently, you can talk
ISO LATIN 1 with your computer, but you've got to talk ASCII with
SMTP.

A case in point.  In Norway, we have a BITNET node called NOBIVM,
which has the domain name BI.NO.  The MX for BI.NO is
runix.runit.sintef.no, which NOBIVM also talks to to send mail
(BITNET-wise, it is NORUNIX, I believe).  As I see it, this mail
gateway should translate "NOBIVM" to "BI.NO" on outgoing mail and
"BI.NO" to "NOBIVM" on incoming mail (as seen from the BITNET side).
The mail gateway has to do a lot of header massaging, anyway.

Users on the BITNET site should be informed that they have two
different addresses, a BITNET address and an Internet address, where
the latter is preferable to hand out to other people.  (Not dissimilar
to having a telephone number and a telex number, is it?)

I think we have to take cognizance of the fact that we deal with
different networks, all of which are not able to go domain-based very
soon.  My base experience is with UUCP (which is no more than a
point-to-point transfer protocol and should never have been used for
mail addressing, in my opinion).  Even though the UUCP world is moving
to domains, when you issue UUCP commands, you still have to use the
"link-level" uucp node name.  Knowing that "uunic.uu.no" is "naggum"
in this way is not intuitive, but we won't be able to rewrite our uucp
software to ask sundry domain name servers about what is what.  Isn't
this exactly similar to the BITNET problem?

There are a lot fewer BITNET <-> Internet gateways than there are
BITNET sites, so why not publish the domain name of a BITNET site in
their map data bases or whatever, and then the gateways know what to
do?  As far as I know, BITNET is a lot more well-defined than the
aggregate of UUCP sites (in the absence of a "UUCP Network").

Then, when the gateways are upgraded, we (who? :-) enforce the
requirements implicit in RFC 821/2 and explicit in RFC 1123 about
Fully Qualified Domain Names, so that .BITNET becomes non-functioning
in addition to its long standing as illegal.

We should do the same with .UUCP.

Note that we preserve the old BITNET (and UUCP) ways as long as we
operate within their respective networks (or "networks"), and that the
User Agent can do what it wants, including, as one participant noted,
supporting .BITNET to the user.  There already exists software in the
UUCP world to support .UUCP to the user, and gateways solve this
problem.  Is BITNET so fundamentally different?

I think we could perhaps learn something from the telephone people who
split area codes.  Graceful transitions, if you ask me.  It seems a
lot rougher on the users with e-mail "splits".

All of this is of course my opinion, not official Internet policies.

[Erik]

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU;  6 Jan 90 21:57:53 EST
Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU;  6 Jan 90 21:58:04 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa08649; 6 Jan 90 21:53 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA19211; Sat, 6 Jan 90 22:51:39 -0400
Message-Id: <9001070251.AA19211@alw.nih.gov>
To: header-people@ai.ai.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Sat, 06 Jan 90  21:52:56 EST
Subject:  Re:  w/r/t Ned's reply

> Yes, BITNET is not the Internet. But, the VM Mailer
> system and clones are part of the Internet Mail System.
> Thus, we need to adopt Internet policies and procedures for the
> BITNET VM Mailer System.

Well, what the Columbia Mailer and it's relatives send to the Internet
ought to conform to Internet standards.  And it pretty much does, at
least as well as most other things do.  What is done on BITNET is not
subject to Internet standards unless BITNET chooses to adopt those
standards as it's own in whole or in part.

>        b. It is inappropriate to be sending mail from the
> internet via the BITNET to a directly connected internet site.
> This is already accords because network dependant addresses are
> given to users.  We need network independant addresses to allow
> routing to be determined by site, not networks.

Exclusive use of network-independent addresses is not possible given
the current state of protocol definition and software implementation.
People are not going to give up transfering files and sending
interactive messages on BITNET.  Those things cannot be done with
domain names today.

If you really want network independent addressing, support the efforts
of myself and others to standardize the necessary protocols for BITNET.

>        d. Listing each node of a network in the Internet nameserver
> is more work than listing wild-card entries by site. (BITNET only lists
> country domains by country, it should also allow entries by sites in
> the DOMAIN NAMES file, but then that is also more work).

Yes, it definitely is more work.  Someone would have to write a piece
of software to extract the necessary information for the name servers
from BITEARN NODES.  This is a considerably smaller job than converting
BITNET entirely to domains and could be viewed as part of a transition
effort.  It would have the beneficial effect of avoiding the mention of
specific gateways in addresses.



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Jan 90 23:31:04 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa08934; 6 Jan 90 22:01 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA19215; Sat, 6 Jan 90 22:59:43 -0400
Message-Id: <9001070259.AA19215@alw.nih.gov>
To: erik.naggum@uunic.uu.no
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Sat, 06 Jan 90  22:01:01 EST
Subject:  Re:  .BITNET and the Internet

> There have been gripes about a certain Internet-centricity in this
> discussion.  This is certainly right -- the Internet has a full body
> of standards, and if you want to play, you have to follow the rules.
> However, none of the people who write these standards try to enforce
> their view on networks who borrow good ideas, or just look similar to
> Internet ways in certain application.  An occasionally squeeking
> spectator in the RFC 1122/3 work, I saw that it was hard enough to get
> the Old Network Boys to consider other networks at all.  It took me
> some time to realize that it wasn't really their business to care
> about these other networks who were nevertheless likely to follow
> their lead, anyway.  IMHO, this is the problem that e.g. Roger Fajman
> has.

No, my meaning was simply that Internet standards do not automatically
apply outside the Internet.  Some people seem to think they do.

When you are considering a gateway between two networks, then the needs
of both networks have to be considered.  This is not the subject of
RFCs 1122 and 1123.  Or RFCs 821 and 822, for that matter.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Jan 90 20:13:07 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa25225; 7 Jan 90 7:57 EST
Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA09062; Sun, 7 Jan 90 13:57:16 +0100
Received: by slembe.uio.no (5.61++/SMI-3.2)
          id AA20185; Sun, 7 Jan 90 13:57:14 +0100
Date: Sun, 7 Jan 90 13:57:14 +0100
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: Roger Fajman <RAF@cu.nih.gov>
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <9001070259.AA19215@alw.nih.gov> ""Roger Fajman" <RAF@CU.NIH.GOV>"
Subject:  .BITNET and the Internet
Message-Id: <90-007-0432@uunic.uu.no>

   No, my meaning was simply that Internet standards do not automatically
   apply outside the Internet.  Some people seem to think they do.

Some people outside the Internet want to follow Internet standards as
long as they fit their networks.  The Internet application layer is
useful and good not only for the Internet.  RFC 822, for instance.
Other than this admittedly minor nit, I think we are in agreement.

   When you are considering a gateway between two networks, then the needs
   of both networks have to be considered.  This is not the subject of
   RFCs 1122 and 1123.  Or RFCs 821 and 822, for that matter.

Exactly my point.  However, you didn't come across (to me, anyway)
saying this in your previous messages.

So, it is decided, then.  .BITNET as a top-level Internet domain is
bad idea, and gateways do the necessary work.  [Tongue in cheek.]

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Jan 90 20:15:16 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00949;
          7 Jan 90 12:43 EST
Date: Sun 7 Jan 90 12:40:08-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re:  Re:  .BITNET and the Internet
To: RAF@cu.nih.gov
Cc: header-people@mc.lcs.mit.edu
Message-ID: <631734008.460000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <9001070259.AA19215@alw.nih.gov>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>No, my meaning was simply that Internet standards do not automatically
>apply outside the Internet.  Some people seem to think they do.
  Curiously, this problem does not originate from the Internet side of the 
boundary, but from the "other" side.  Let me use BITNET, specifically the 
VM/CMS systems that have dominated its design, as an example, since I know
something about it, but I suspect that the UUCP and other histories are
similar. 
  When the time came to do a MAIL command for VM/CMS BITNET, that command 
was done by people who were already familiar with Internet mail and liked
(at least because they were used to it) the general style in which Internet 
mail (and one or two implementations in particular) worked.  So they 
imitated it: because it was familiar, because it was demonstrated to work, 
and because, as has been mentioned, it was well-documented and well-
understood.  I imagine that the origins of the Crosswell MAILER were much 
the same--an attempt to simulate, as nearly as possible, the Internet 
facility on BITNET.  And that--the combination of Internet experience, 
Internet documentation, and probably a certain amount of Internet-envy--
is what has produced Internet-centric notions on BITNET.
   The problem, as I've said many times before in other forums, is that 
these decisions, while understandable, may not be correct ones.  BSMTP, for 
example, is more or less a strict translation of SMTP (RFC821) into batch 
transmission terms.  However, as such, it fails to capture two kinds of 
things.  The first of these is the very nature of SMTP as an *interactive* 
protocol, working over virtual circuits.  That distinction means that there 
are a series of strategies available to SMTP for dealing with errors and 
non-delivery problems that are not available to BSMTP.  And, because BSMTP 
is essentially a translation and sequencing, there are no sensible 
alternatives.  The second is that a number of things that are unique to 
BITNET (or BITNET-like networks)--things that are meaningless on the 
Internet--probably ought to be reflected in the BSMTP envelope so that 
MAILERs and gateways can take advantage of them, but, largely because of 
the "translation" problem, haven't been.  The example that is relevant to 
the recent discussion is that it would be possible for the BSMTP envelope 
to contain:
  My-hosts-NJE/rscs-address-is:
  My-hosts-DNS-name-is:
  The-DNS-name-represents-an-A-record.
  The-appropriate-gateway-from-the-Internet-is:
  Errors-to:
and a series of similar things.  I'm not suggesting that any particular one 
of these would be a good idea, only that this sort of thing would provide 
MAILERs and gateways with a lot of information that they don't have and 
that they could take good advantage of.  I am also suggesting that, because 
of Internet-centricity ON THE BITNET DESIGN SIDE, these types of BSMTP 
extensions, and their MAILER implications, have not been seriously 
addressed at the right times and by the right people.  These things are not 
needed on the Internet because the addressing model is different, the MTA 
model uses virtual circuits rather than host-to-host store-and-forward,
etc.
   It is also interesting to note that this discussion--once again--is 
occurring on an Internet list--header-people--and that, in my limited 
experience, it tends to vanish without a trace when it shows up on the 
BITNET INTERBIT and FUTURE-L and similar lists.
   In addition, and compounding the problem, is the fact that Internet RFCs 
go through a stage of being just that--more or less widely-circulated 
documents available for comment.  BSMTP, to use that example again, is not 
written down, and is treated as a private agreement among MAILER 
maintainers.  That approach has some advantages, but reflection by, and 
comment from, a large variety of perspectives is not one of them.

>When you are considering a gateway between two networks, then the needs
>of both networks have to be considered.  This is not the subject of
>RFCs 1122 and 1123.  Or RFCs 821 and 822, for that matter.
  Fortunately, the only thing that one network can rationally say about 
others is to specify the form that messages (or whatever) take once they 
cross into one's own network.  That is what these RFCs and others do about,
e.g., BITNET traffic, which is to say--or try to say--what those messages 
must look like when they traverse the Internet.  From an Internet 
perspective, it would also be possible to say "look, folks, if you were 
part of our network, and used our network-layer protocols, then you could 
really simulate our applications-level protocols".  In other words, if 
BITNET dropped this RSCS/NJE stuff and ran TCP/IP, a lot of problems--
with respect to the Internet--would vanish.  That statement is true, but
useless and *really* Internet-centric and, fortunately, I haven't heard it 
much lately.
   Let me stress that I favor Roger's approach that BITNET should develop 
some protocols that, while adapted from Internet ones if appropriate, 
really reflect BITNET requirements, including requirements for proper 
handling of error conditions (especially those resulting from the actions 
of sophisticated and distributed list-expanders) and reasonable behavior at
gateway-boundaries to networks for which there are multiple plausible 
gateways.

Finally, it has been suggested that part of the BITNET problem is that DNS 
addressing works only for mail, and that it would be more widely accepted 
if it worked for file transfer and interactive messaging also.  I suggest 
that the first-level problem is easier than it appears but that there is a 
second-level problem that makes things much more difficult.
  If CMS is representative, equipping SENDFILE and TALK with a table lookup 
that would accept DNS names and translate them into NJE addresses (i.e., 
the eight-character things) would be pretty easy (under a day's work).  I 
know, I just looked at the code in SENDFILE.  There are some efficiency and 
performance issues associated with opening and searching large files (this 
lookup has to occur in file whose size is 'one BITNET/EARN/etc node, one 
, but
it is not clear how big a problem that really is.  So: could it be done?  
Sure, it is just a matter of someone getting motivated.  If someone could 
solve the "other" problem, I'd do it myself to prove it.
  Part of the "real" problem is that, while OSI model clearly involves
layered protocols, and TCP/IP is reasonably well layered, some features of 
NJE/RSCS more or less encourage users to deal directly with what we would 
normally think of as the network and transport layers, and discussions with 
them have to be in terms of host addresses, just as the TCP/IP versions at 
those levels use IP addresses, not host names.  Providing applications-
level code to do the right thing and hide this is not particularly hard, 
but convincing users to change their ways might be.  For that reason, the 
comment above describes SENDFILE and TALK, and does not mention PUNCH and 
SMSG.  If a user has execs, or commands, or habits, that addresses these 
lower levels (I realize that the analogies are not exact, but let's not 
quibble) then he or she is going to need to know that the low-level stuff 
must use BITNET names, while the upper-level stuff may (or must) use DNS 
names.  And the re-education job is a tough one.  It is much easier to 
change software than it is to change user knowledge, behavior, and 
entry', not one the size of DOMAIN NAMES) environments.
  But, while it is an issue that should not be underestimated, that is just
a symptom.  The greater difficulty is that there is a case to be made that
there are some things that it is not appropriate to make transparent. For
example, while mail is, within a close approximation, mail, the BITNET
file-sending model is not analogous to Internet FTP and, although it is
done frequently, hiding file transfers in mail messages has always been
viewed as being in bad taste on the Internet.   I think I might rather 
explain to a BITNET user that SENDFILE is a low-ish level facility and 
that, to use it, one needs to address a host by its BITNET name although 
mail works better using a DNS name than to try to explain to that same user 
why the set of names that works with SENDFILE is a proper, and lexically 
unpredictable, subset of the names that work with MAIL.  I'm not saying 
that it cannot be done, only that one would want to think carefully about 
the model, the supporting tools, the documentation, and the error messages.
  Fortunately or not, mail is the unusual case in which differences in
protocols can be smoothed over (even if we have not done it as well as we
might have wanted to).  In the other cases, the Internet and OSI models are
dominated by logics that depend on virtual circuits: "I've got this for 
you, are you willing to accept it?" protocol styles, rather than "here it 
comes, like it or not" styles.  BITNET does not have the former, nor has it 
evolved appropriate protocol surrogates.  For example, it would be 
possible, within the BITNET model (albeit at the price of tampering with 
fairly low-level vendor-supplied code), for me to have accounting records 
that specified whom I was, or was not, willing to receive a file from.  
Using those as an FTP-surrogate might still require taking up the bandwidth 
needed to transfer the file before it was rejected (unlike FTP, which does 
not permit the transfer to start), but it would be a step in the right 
direction.  It would even be possible to structure things so that those 
accounting records could be checked, via interactive messaging, one RSCS 
process to another before data was actually sent, or to invent "BFTP", with
target file names and directories, passwords, etc.  But none of those
things has been done, and the blame for that certainly does not lie with 
the Internet community.
   John Klensin
   Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Jan 90 20:17:59 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa05393; 7 Jan 90 15:30 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA19835; Sun, 7 Jan 90 16:28:10 -0400
Message-Id: <9001072028.AA19835@alw.nih.gov>
To: erik@naggum.uu.no
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Sun, 07 Jan 90  15:30:30 EST
Subject:  Re:  .BITNET and the Internet

> So, it is decided, then.  .BITNET as a top-level Internet domain is
> bad idea, and gateways do the necessary work.  [Tongue in cheek.]
>
> [Erik]

Tongue not in cheek, I see several possibilities:

(1)  Leave things as they are, with Internet users using explicit
     gateway names in addresses, unless the BITNET node happens to have
     its own domain name.  Gateway names are difficult to change and
     mail sometimes takes very non-optimal paths.

(2)  Use a Fidonet-style solution of something like
     user@node.gateway-domain (.BITNET, .BIT.NET, .BITNET.ORG,
     .CREN.ORG, or whatever).  The BITNET node name is embedded in the
     address, so the gateway does not have to keep a translation table.
     With MX records, different BITNET nodes could be serviced by
     different gateways.  Gateways could be changed without impacting
     users.  BITNET nodes with their own domain names would continue to
     use them.  Gateway software to support this would have to be
     developed.

(3)  Force all BITNET nodes to have a domain name.  Gateways would
     maintain a translation table between BITNET node names and domain
     names.  This avoids the need for all BITNET nodes to have software
     capable of handling domain names.  BITNET users would have to know
     two names for their node.  The necessary gateway software would
     need to be developed.

(4)  Force all BITNET nodes to have a domain name and to install
     software capable of using it for mail.  Other BITNET services
     (file transfer and interactive messages) would continue to use
     BITNET node names.  BITNET users would have to know two names for
     their node.  Software for some BITNET environments would need to
     be developed.

(5)  Enhance BITNET protocols so that they support domain names for all
     services.  Develop the necessary software to support the
     protocols.  Eventually force all BITNET nodes to have a domain
     name and install the software to support it.  BITNET users would
     use only domain names.  The BITNET routing table could be reduced
     to one gateway node per site.

Option (5) is what was recommended by the BITNET Domains Task Force.
This recommendation was never adopted by the BITNET Board.

These options are not all mutually exclusive.  Personally, I favor (5)
with (2) as a transition aid.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Jan 90 22:30:15 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa05324; 7 Jan 90 15:28 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA19831; Sun, 7 Jan 90 16:26:26 -0400
Message-Id: <9001072026.AA19831@alw.nih.gov>
To: erik@naggum.uu.no
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Sun, 07 Jan 90  15:28:31 EST
Subject:  Re:  .BITNET and the Internet

>    No, my meaning was simply that Internet standards do not automatically
>    apply outside the Internet.  Some people seem to think they do.
>
> Some people outside the Internet want to follow Internet standards as
> long as they fit their networks.  The Internet application layer is
> useful and good not only for the Internet.  RFC 822, for instance.
> Other than this admittedly minor nit, I think we are in agreement.

Yes, of course, RFC 822 and a few others have been used outside the
Internet when appropriate.  And I agree that the Internet is under no
obligation to accomodate such use, although it may wish to do so
anyway.  Sometimes it has done so.

It's up to each network to decide which Internet standards, if any, it
would like to use and which parts of those standards.  For example,
although BITNET uses RFCs 821 and 822, not everything in them applies
to BITNET.  Unfortunately the differences are not formally specified.

I, too, don't see any serious disagreement here.

As an aside, perhaps someone could explain why RFC 821 (SMTP) calls
for only a 7 bit data path, instead of the 8 bit path supplied by TCP.

Here are some interesting quotes from RFC 821:

1.  INTRODUCTION

   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
   mail reliably and efficiently.

   SMTP is independent of the particular transmission subsystem and
   requires only a reliable ordered data stream channel.  Appendices A,
   B, C, and D describe the use of SMTP with various transport services.
   A Glossary provides the definitions of terms as used in this
   document.

   An important feature of SMTP is its capability to relay mail across
   transport service environments.  A transport service provides an
   interprocess communication environment (IPCE).  An IPCE may cover one
   network, several networks, or a subset of a network.  It is important
   to realize that transport systems (or IPCEs) are not one-to-one with
   networks.  A process can communicate directly with another process
   through any mutually known IPCE.  Mail is an application or use of
   interprocess communication.  Mail can be communicated between
   processes in different IPCEs by relaying through a process connected
   to two (or more) IPCEs.  More specifically, mail can be relayed
   between hosts on different transport systems by a host on both
   transport systems.

APPENDIX D

   X.25 Transport service

      It may be possible to use the X.25 service [7] as provided by the
      Public Data Networks directly, however, it is suggested that a
      reliable end-to-end protocol such as TCP be used on top of X.25
      connections.

>    When you are considering a gateway between two networks, then the needs
>    of both networks have to be considered.  This is not the subject of
>    RFCs 1122 and 1123.  Or RFCs 821 and 822, for that matter.
>
> Exactly my point.  However, you didn't come across (to me, anyway)
> saying this in your previous messages.

I had gotten the feeling that some people thought only the needs of
the Internet are worth considering.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Jan 90 22:35:07 EST
Received: from maui.engin.umich.edu by mintaka.lcs.mit.edu id aa04440;
          8 Jan 90 8:50 EST
Received: by caen.engin.umich.edu (5.59.1/caen.0.9)
	id 47e98d51d.0017b5e; Mon, 8 Jan 90 08:48:51 EST
Message-Id: <47e98d51d.0017b5e@caen.engin.umich.edu>
To: Craig Partridge <craig@nnsc.nsf.net>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: .BITNET domain 
In-Reply-To: Your message of Thu, 04 Jan 90 14:07:52 -0500.
             <9001041410.aa09111@mintaka.lcs.mit.edu> 
Date: Mon, 08 Jan 90 08:48:49 -0500
From: paul killey <paul@caen.engin.umich.edu>

	 	
You write ... 
	 
	    "...there was, for a couple of years, a very large and
prestigious university
	    that had two hosts, named <University-name>.BITNET and
	    <University-name>.CSNET which were not connected to each
	    other.  Every week, the e-mail admins of the two machines
	    held a tape swap to exchange mis-delivered mail.  I kid you not."

umich.csnet was a vax running unix in electrical and computer
engineering and umich.bitnet was a vax running vms in the physics
department.  I made tapes for the physics people and read the ones
they brought over.

I don't know if that's the case you knew about, but it is a true story.

This was a while ago, when we had just gotten on csnet via dialup, etc.
After several years of "advances" in e-mail I have to admit that the
setup we had then (we called it MAGnet, of course) now has a certain primitive
appeal. -:)

--paul


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 01:08:03 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa02123;
          8 Jan 90 20:16 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5073; Mon, 08 Jan 90 20:16:22 EST
Received: from ACADVM1.UOTTAWA.CA by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP
 id 2867; Mon, 08 Jan 90 20:16:21 EST
Received: by UOTTAWA (Mailer R2.04) id 7740; Mon, 08 Jan 90 20:15:59 EST
Date:         Mon, 8 Jan 1990 20:15:43 EST
From:         Neil Duffee <NJD2D%UOTTAWA.BITNET@mitvma.mit.edu>
Subject:      Re: .BITNET suffix, etc.
To:           HEADER-PEOPLE@MC.lcs.mit.edu
Message-ID:  <9001082016.aa02123@mintaka.lcs.mit.edu>

---->  this originally was sent to MAIL-L but found that I was
---->  also getting the same discussion here on header-people.
---->  So.... thought that the other half might like a chance
---->  to shoot me down too. ;->

Well, I've learned a massive amount in following this discussion and
appreciated the bits of history lessons that were included for people
such as myself.  I know this will continue on since the resolution
will be a major one no matter the course of action chosen.  However,
my two cents worth.

In all this reading, I've come to the conclusion that most of us are
attempting to compare oranges and apples in the internet vs Bitnet
discussion.  One of the beauties of the internet is the use of
wildcards to reduce routing tables (not the best word here, but given
my personal Bitnet background, understandable) with items such as:
*.INSTITUTE.EDU - that will point to a single sub-net 'gateway'.
(really, please excuse my vocabulary here, I've picked up a lot about
the internet but NOTHING beats hands-on and daily use.)

A real problem with internet/Bitnet/UUCP/etc. gatewaying is that
SEVERAL gateways are desirable.  Fidonet.Org has been used as an
example but I'll bet my bottom dollar that the MX-records resemble:

*.z1.fidonet.org
*.z2.fidonet.orf
*.z3.fidonet.org
   *.fidonet.org - just in case

   - since fidonet already seems to be physically divided by naming
conventions into these differing zones.  This, obviously, cannot be
used in reference to Bitnet/etc due to its flat naming space.
Also, registering '*.host1.bitnet.org' is non-viable since Bitnet
itself is suffering under a burgeoning routing table of 2.5K+.
To suggest that the internet add this to their list - not reasonable.

However, I'm not without a suggestion but it will require more expertise
knowledge of the internet gurus for help.  This is because I've not
been able to determine exactly what a name server is and how it works.
(I wouldn't mind private mail on this from any and all with a summary
forwarded to any and all that give me a private mail request to be
included.  ANYthing to keep the minor details out of the mainstream
discussion. :)  My belief and understanding is that the name server
will supply an MX (or A) record on demand. (in the most simplest of terms)

Proposal: that an entry such as:
*.BITNET.ORG    ns=cunyvm.cuny.edu      pref=10  (or however the order of
                ns=cornellc.edu         pref=20  (  preference is given
                ns=other.interbit.org   pref=30
     - with the preference changing for each internet host to point the
the nearest 'official' INTERBIT gateway.  Thus each Mail Transfer Agent (MTA)
can query the name server with UOTTAWA.BITNET.ORG and be provided with
the proper MX to the gateway closest to the Bitnet host and, purportedly,
the best routing.

This would allow the gateways to blithely add '.BITNET.ORG' to mail from
Bitnet and remove it from internet mail.  The internet address need not
changed since the top-level domains are resolvable for Bitnet mailers.
Any replies for list mail to the original submitter will also be
sent through a more appropriate gateway rather than the gateway that
the LISTSERVer used (usually half way 'round the world, too).
This would easily be adapted to other networks since only 4-5 entries are
required to cover the top-levels of *.com, *.org, *.edu, *.mil, *.net.

This obviously won't work if my understanding of name servers stinks.
However, is it at least on the right track?  Discussion?  (hah, as if I
really need to ask, eh?)

--------------->  signature = 9 lines follows <-------------------
Neil Duffee
System Operator, U. of Ottawa, Ottawa, Ontario, Canada
BITNET:  NJD2D@UOTTAWA
.CA DOMAIN:  njd2d@acadvm1.uottawa.ca             (requires MX records)
    or:  njd2d%acadvm1.uottawa.ca@ugw.utcs.utoronto.ca (explicit route)
INTERNET:    see .CA DOMAIN above
UUCP:  gatech!utai!uottawa.bitnet!njd2d
COMPU$ERVE:  >INET:njd2d@acadvm1.uottawa.ca
'If I was allowed an opinion, you'd be the first to hear about it.'
 Neil Duffee         MAIL-L@MARIST        1/05/90*.BITNET suffix, etc.

--------------->  signature = 9 lines follows <-------------------
Neil Duffee
System Operator, U. of Ottawa, Ottawa, Ontario, Canada
BITNET:  NJD2D@UOTTAWA
.CA DOMAIN:  njd2d@acadvm1.uottawa.ca             (requires MX records)
    or:  njd2d%acadvm1.uottawa.ca@ugw.utcs.utoronto.ca (explicit route)
INTERNET:    see .CA DOMAIN above
UUCP:  gatech!utai!uottawa.bitnet!njd2d
COMPU$ERVE:  >INET:njd2d@acadvm1.uottawa.ca
'If I was allowed an opinion, you'd be the first to hear about it.'
Acknowledge-To: <NJD2D@UOTTAWA>

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 03:33:30 EST
Received: from [128.32.136.6] by mintaka.lcs.mit.edu id aa11456;
          8 Jan 90 23:48 EST
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA03606; Mon, 8 Jan 90 20:48:16 PST
Date: Mon, 8 Jan 90 20:48:16 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9001090448.AA03606@garnet.berkeley.edu>
To: header-people@mc.lcs.mit.edu, RAF@cu.nih.gov
Subject: Re:  .BITNET and the Internet

I believe the node management plan is to have the internet domain name
(and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES"
file as proposed in "NODES File Format and Contents (of the 1989
version)" by Berthold Pasch.  (File NODETAGS DESCRIPT from the NETSERV
fileserver).  The ":internet" tag is defined in section 2.3.8 on pages
21-22.

These NODES files are not maintained by the gateway(s) but by the site
that owns the node.

Bill Wells
NETINFO at UCBGARNE
netinfo@garnet.berkeley.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 03:39:09 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa14680; 9 Jan 90 0:59 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA24993; Tue, 9 Jan 90 01:57:37 -0400
Message-Id: <9001090557.AA24993@alw.nih.gov>
To: netinfo@garnet.berkeley.edu
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Tue, 09 Jan 90  00:59:12 EST
Subject:  Re:  .BITNET and the Internet

> I believe the node management plan is to have the internet domain name
> (and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES"
> file as proposed in "NODES File Format and Contents (of the 1989
> version)" by Berthold Pasch.  (File NODETAGS DESCRIPT from the NETSERV
> fileserver).  The ":internet" tag is defined in section 2.3.8 on pages
> 21-22.
>
> These NODES files are not maintained by the gateway(s) but by the site
> that owns the node.
>
> Bill Wells
> NETINFO at UCBGARNE
> netinfo@garnet.berkeley.edu

Yes, that's correct.  However, it's not clear when that plan will be
implemented.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 03:39:43 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa15025; 9 Jan 90 1:10 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA25001; Tue, 9 Jan 90 02:08:22 -0400
Message-Id: <9001090608.AA25001@alw.nih.gov>
To: netinfo@garnet.berkeley.edu
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Tue, 09 Jan 90  01:09:56 EST
Subject:  Re:  .BITNET and the Internet

> I believe the node management plan is to have the internet domain name
> (and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES"
> file as proposed in "NODES File Format and Contents (of the 1989
> version)" by Berthold Pasch.  (File NODETAGS DESCRIPT from the NETSERV
> fileserver).  The ":internet" tag is defined in section 2.3.8 on pages
> 21-22.
>
> These NODES files are not maintained by the gateway(s) but by the site
> that owns the node.
>
> Bill Wells
> NETINFO at UCBGARNE
> netinfo@garnet.berkeley.edu

I replied too soon.  Yes, what you say is correct.  However, that
mechanism would have to be extended to support a gateway capable of
translating between domain addresses and BITNET addresses.  The problem
is that there is no indication of whether such a translation is desired
or not.  Many sites currently supporting domains for mail on BITNET
would not want the translation to be performed.

It's also true that it's not clear when the new BITEARN NODES format
will be implemented.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 03:42:00 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa15675; 9 Jan 90 1:30 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA25018; Tue, 9 Jan 90 02:28:03 -0400
Message-Id: <9001090628.AA25018@alw.nih.gov>
To: KLENSIN@infoods.mit.edu
Cc: header-people@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Tue, 09 Jan 90  01:29:37 EST
Subject:  Re:  Re:  .BITNET and the Internet

>   But, while it is an issue that should not be underestimated, that is just
> a symptom.  The greater difficulty is that there is a case to be made that
> there are some things that it is not appropriate to make transparent. For
> example, while mail is, within a close approximation, mail, the BITNET
> file-sending model is not analogous to Internet FTP and, although it is
> done frequently, hiding file transfers in mail messages has always been
> viewed as being in bad taste on the Internet.   I think I might rather
> explain to a BITNET user that SENDFILE is a low-ish level facility and
> that, to use it, one needs to address a host by its BITNET name although
> mail works better using a DNS name than to try to explain to that same user
> why the set of names that works with SENDFILE is a proper, and lexically
> unpredictable, subset of the names that work with MAIL.  I'm not saying
> that it cannot be done, only that one would want to think carefully about
> the model, the supporting tools, the documentation, and the error messages.

I have also worried about this problem.  However, it's not a new one.
FTP and Telnet work with some hosts and not others (i.e., those with a
domain name and MX record, but no IP address).

One of the benefits of adopting domain names on BITNET is reducing the
size of the routing tables by having only one gateway node per site.
This cannot be done if users continue to use NJE node names.

The Internet could decide that it would like to facilitate file
transfer gateways with other networks by defining an Internet file
transfer protocol that works in a manner analogous to mail.  This could
be a new protocol, an addition to SMTP, or an extension to RFC 822 to
allow attached files.  The concept of attaching files to a mail message
is popular in LAN email systems for PCs.  Unfortunately, such an
enhancement to the Internet protocol suite seems unlikely at the
present time.  Yes, of course, there's UUENCODE and it's relatives, but
they are not user friendly.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Jan 90 14:32:57 EST
Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa13033;
          9 Jan 90 14:29 EST
To: raf@cu.nih.gov
cc: header-people@mc.lcs.mit.edu
Subject: re: .BITNET domain
Date: Fri, 05 Jan 90 08:14:49 -0500
From: Craig Partridge <craig@nnsc.nsf.net>
Message-ID:  <9001091429.aa13033@mintaka.lcs.mit.edu>


> My original question is why are these policies not enforced
> consistently with respect to FIDONET.ORG and UU.NET?  Why is an Indian
> host named shakti.uu.net acceptable while a similarly named BITNET host
> is not?

If shakti isn't a host involved in running uu.net it isn't acceptable use.
(I don't personally know the status of shakti).  As for enforcement,
that's a tricky question.  It isn't clear there is an enforcement mechanism,
short of turning off uu.net at the root domain servers -- that's a rather
extreme act.  All the more reason for the NIC to be careful about who it
gives .NET domains to.

>> PPS: As I recall, the BITNET plan was to revise the mail software to
>> map domain names into the fixed-length BITNET ids.  So there'd be
>> a step where the name vm.cuny.edu would map into an envelope address
>> CUNYVM that only the BITNET mailer would see; never the user.
>> Unknown addresses would be mapped to Interbit gateways which would
>> forward or reject them as appropriate (hacks like checking the right
>> side of unknown domain names against lists of known top-level domains
>> were to be used to limit the amount of bad mail being sent to gateways).

> This is pretty much the way it works.  But only for email.

Why only for e-mail?  It would seem to me that if a conversion scheme
exists, you ought (in principle) to be able to fit it into the user
interface of other protocols.  My internet address is 128.89.1.178 -- but
I can type nnsc.nsf.net to telnet.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Jan 90 19:41:48 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa21005;
          10 Jan 90 19:38 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA04160; Wed, 10 Jan 90 20:35:24 -0400
Message-Id: <9001110035.AA04160@alw.nih.gov>
To: HEADER-PEOPLE@MC.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Wed, 10 Jan 90  19:36:42 EST
Subject:  Naming with an Internet to BITNET Gateway

Sorry to start this discussion again, but I can't resist copying the
messages below from the TCP/IP list.

It seems to be that the bottom line here is that CREN could, if it
wished, register a domain name and offer an Internet to BITNET gateway
service using names something like user@node.BITNET.CREN.ORG. While it
is not in accordance with the intent of the DNS, it has been found to
be expedient by other networks, such as SPAN and Fidonet.  There's no
reason why CREN should or would be treated differently.

Presumably the implementors of such a gateway, if it is ever done,
would wish to develop a program to construct the necessary MX records
from the BITNET nodes data base so that the gateway nearest each BITNET
node would be used.

Roger Fajman


Date: 9 Jan 90 17:45:42 GMT
From: haven!uvaarpa!randall@purdue.edu  (Randall Atkinson)
Subject: Re: %-Hack .vs. Route Address

In article <836@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) wr
ites:

>But it seems to me that you're only allowed to use route-addresses when all
>the hosts are registered with the NIC.  Since they won't want to register
>every PC in the world, or even every mainframe on lots of networks which are
>not on the Internet, it seems you've got to break some rules to make things
>work.  Personally, I think source-routes are nasty since they aren't pure
>left-to-right or right-to-left.  But then I've never had to use them....

Actually, any node on the GE internal DECnet can be reached as
node.DNET.GE.COM and there are no A records or in fact IP addresses
for virtually all of the machines on that network.  The RFC states
that you are only allowed to use route-addresses with fully-qualified
domain names in registered domains.  GE's solution is fairly general
and requires only a single MX record pointing *.DNET.GE.COM to a
relay-host directly on the Internet.

There are special cases that won't be covered, but this solution DOES
handle the case of PCs on an internal network or any other  such situation.
The main case it won't (legally) handle is gatewaying to a network whose
machines aren't under your theoretical administrative control.
NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and
I heartily approve of NASA's solution even though many nodes on that
DECnet aren't owned or operated by NASA.

The %-hack is widely overused and I'd like to see it used only when
really necessary because it causes a lot of mail delivery problems.

  Ran


Subject: Re: %-Hack .vs. Route Address
Date: Tue, 09 Jan 90 18:41:35 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>

(quote from previous message deleted)

This was/is a hack to enable reasonable functionality for mail
relay to SPAN systems.  It's not the right thing to do, but was
expedient.  The reason it's not right is that SPAN is not run by
a single organizational unit (to use OSIspeak).  The right way
of skinning the cat would be to use individual MX records for
machines at sites to map them into the local domain name space
of the facility.

For example, a DECNET node named SAT located at Ames, should not
be addressed at user@sat.span.nasa.gov, but user @sat.arc.nasa.gov.  This
way, if the machine happens to speak IP (as it does), it could be
considered a CNAME for it's full hostname, or an MX record could
be used that points mail at an Ames local MAIL-11 relay system.  If
you use an MX record for *.span.nasa.gov, then all of it has to
go through a single mail relay.  You can get into the case of a JPL host
sending internet mail to a JPL DECNET host via a relay at ARC or GSFC.
If the JPL DECNET host had an MX record in the jpl.nasa.gov subdomain,
a more optimal path could be taken.  I think JPL actually does this,
but the point is the obvious.

The problem with this is that it means having all the individual
system administrators interacting with all the site domain managers
and whoever runs a relay at the site to fix things so they work
right, which is harder than fixing it once using the span.nasa.gov
pseudodomain.

The same reason holds why a .BIT.NET or .CS.NET (or maybe .ONE.NET
these days I guess) is a bad idea.  Those systems really should reside
in a site's name local namespace.  If people obeyed these rules, Internet
mail delivery would be much more transparent, and the fact that a
particular network (SPAN,BITNET,CSNET, etc...) was being used as
transport would be hidden from the users.  And that makes life easier
on them.  Why should 3 different forms of different address
specifications be used to talk to 3 machines connected in different
ways at one site?


                                       Thanks,
                                          Milo

PS All the usual disclaimers about the government not being responsible
for anything I say apply of course...


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 04:46:16 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10672;
          11 Jan 90 4:44 EST
Date: Thu 11 Jan 90 04:41:06-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re:  Naming with an Internet to BITNET Gateway
To: RAF@cu.nih.gov
Cc: HEADER-PEOPLE@mc.lcs.mit.edu
Message-ID: <632050866.700000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <9001110035.AA04160@alw.nih.gov>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>It seems to be that the bottom line here is that CREN could, if it
>wished, register a domain name and offer an Internet to BITNET gateway
>service using names something like user@node.BITNET.CREN.ORG. While it
>is not in accordance with the intent of the DNS, it has been found to
>be expedient by other networks, such as SPAN and Fidonet.  There's no
>reason why CREN should or would be treated differently.
  Roger,
The discussion cited does not, fortunately or unfortunately, prove 
anything, nor does it really address anything not already discussed 
here.  Let me try to summarize what I think all of this "means":

 (1) The DNS, as an operational mechanism, is technologically capable of
supporting any of the .BIT.NET, .BITNET, etc., suggestions that have been 
made, with only one exception.  The exception requires that MXs work the 
way INTERBIT does, i.e., that, when I make an inquiry about a given node, I 
get back an MX list, preference-ordered by how Internet-close I am to the 
gateway, rather than how BITNET-close the gateway is to the target host.

 (2) The historical Internet/DNS consensus has been that it is best if the 
Internet reflect administrative entities and domains, not geography or
(worse) network topology.  That consensus has generated a bias against
host.BITNET (or spelling variations on that theme) in situations where 
"host" does not belong to the "BITNET administration" but, rather, to an 
academic or governmental entity.
  The bias is especially strong in the BITNET case, as distinct
(historically) from, e.g., the SPAN case, because there are many gateways
and, more important, most hosts exist in institutional settings that
already have Internet connections and DNS domains, and because most of 
those BITNET hosts belong to the institution.

 (3) There is also a historical Internet/DNS consensus that use of CNAMEs
to point from one domain to another, while desirable to have as an 
available facility for special cases and as a transitional mechanism,
it is not a wonderful idea to use a great deal, partially because it
creates confusion.  There are many advantages associated with living in a
"one host, one name" world, rather than having to guess whether a pair of
names actually represent one address or whether they really represent two. 
This same principle is presumably the reason why CNAMEs exist at all--if
you must have multiple names for the same host, one "real" name with some 
aliases pointing to it is preferable to, e.g., several (primary) names with 
the same A-records and IP addresses.

 (4) The combination of an "administrative domains" rule and the lack of an 
enforcement mechanism once a domain (at some level) is delegated and 
registered almost guarantees that there will be ambiguous situations and 
that little or nothing will be done about anything but the most flagrant of 
abuses.  To a certain extent, if you own a domain, and want to abuse 
whatever informal principles there are in assigning host names within it, 
the most anyone is likely to do is to point out that it is a bad idea. 
And, of course, the abuses of the past are likely to be cited as precedents 
for the future.  Equally naturally, people's sensitivity to marginal cases 
and abuses increases insofar as a given domain name gets closer to the root 
or causes multiple names for the same machine in contexts where people have 
to notice.
  The SPAN and HEPNET issue illustrates one of those ambiguities that is 
not pointed out in the material you forwarded.  Among universities, there 
are many BITNET machines.  Almost without exception, those machines belong 
to the universities, in every administrative sense of "belong" including 
ownership or lease-holding.  On the other hand, there are many SPAN and
HEPNET machines that, while resident on university campuses, "belong" to 
NASA or DOE financially and, in many respects, administratively.  Now, are 
they part of the university's "administrative domain", or that of NASA or 
DOE?  Possible to argue it either way and, if you conclude the latter, and 
then NASA comes along and says "*our* SPAN-type machines are 
administratively different from our 'internal' computers, and we want to 
handle them through a different administrative zone", then there is no 
reason to object to host.SPAN.NASA.GOV.  Note that the strawman argument 
here does not mention where the MXs point, only the character of an 
administrative domain.
    foo.ENET.DEC.COM is, incidentally, an unambiguous and correct example 
of DNS application.  Again, that statement does not have anything to do 
with MX structures, or where the "wildcards" are located, but that the "DEC 
Engineering Network" is an administrative entity, with the same 
organizational entity having responsibility for all of the machines in a 
very real sense.  And if DEC decides at some stage in the future to further 
subdivide that domain by inventing foo.VMS.DEC.COM and foo.ULTRIX.DEC.COM 
or something, then, while they will cause some confusion (changing the name 
of a host is never very attractive), and may want to use some CNAMEs for at 
least a while, it is clearly within the scope of their organization to do 
so.

Summary of the summary:
 I. There is absolutely no technical reason why .BITNET or .BIT.NET could 
not be made to function.  The basic DNS addressing system really does not 
care how domains are structured.
 II. These names are not good ideas, primarily because they would either 
severely distort the "administrative domain" notion or force multiple names 
per host on the Internet.  And "severely", here, is not a moral concept but 
one that has to do with the frequency of impact and the frequency of people 
having to notice.  Statistically, mumble.BITNET (sic) is much more likely 
to *be* an Internet node, or to be standing next to one with which it may 
have a private connection (people running tapes across the room included 
under "connection"), than mumble.fidonet.org is.
   john
   Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 13:35:35 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27145;
          11 Jan 90 12:52 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA05513; Thu, 11 Jan 90 12:34:03 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 90 17:26:41 GMT
From: mcsun!ukc!tcdcs!csvax1.cs.tcd.ie!swift.cs.tcd.ie!ccvax.ucd.ie!h235_062@uunet.uu.net
Organization: University College Dublin
Subject: test
Message-Id: <377.25aa1ed1@ccvax.ucd.ie>
Sender: header-people-request@MC.lcs.mit.edu
To: header-people@MC.lcs.mit.edu

Testing....1,2,3......1,2,3,4..........................

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 15:30:48 EST
Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa03666;
          11 Jan 90 15:24 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
	id AA06286; Thu, 11 Jan 90 16:21:47 -0400
Message-Id: <9001112021.AA06286@alw.nih.gov>
To: KLENSIN@infoods.mit.edu
Cc: HEADER-PEOPLE@mc.lcs.mit.edu
From: Roger Fajman <RAF@cu.nih.gov>
Date:     Thu, 11 Jan 90  15:23:55 EST
Subject:  Re:  Naming with an Internet to BITNET Gateway

First of all, let me say that in an ideal world, BITNET would have full
domain support and we wouldn't be having this discussion.  But there's
still a long way to go on that.  I would like to eliminate the gateway
names from the addresses in the meantime.

The DNS is quite capable, given the right MX records, of giving the
gateway that's nearest in BITNET terms to the destination BITNET node.
Since the Internet is the higher performance network, that makes the
most sense to me.  A program would have to be written to produce those
MX records from the BITNET node data base.

I think your reaching when you argue that SPAN is different from BITNET
because SPAN hosts are under one administration.  Milo Medin said in
his mail that it is not so.  In looking through a list of SPAN sites, I
see a lot that are by no stretch of the imagination part of NASA.  Even
supposing that these nodes are funded by NASA, it doesn't make then
part of NASA.  If it does, then NIH (where I am) is a lot bigger than I
thought.  :-)

And even if what you say about a comparison of SPAN to BITNET is true,
I find it interesting that the managers of SPAN found the complexity of
having each host in its "proper" domain too much to deal with.

Let me suggest that the real difference between SPAN and BITNET is that
SPAN uses DECnet.  Thus it does not use RFC 822 and nobody expects
that it should try to convert to domains within itself.


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 16:40:15 EST
Received: from ucbeh.san.uc.edu by mintaka.lcs.mit.edu id aa04135;
          11 Jan 90 15:37 EST
Date: Thu, 11 Jan 90 14:13 EST
From: Amin Shafie - Univ of Cincinnati Comp Ctr <SHAFIE@ucbeh.san.uc.edu>
Subject: SIGUCCS CALL for PARTICIPATION
To: 386USERS@twg.com, 9370-L%HEARN.BITNET@mitvma.mit.edu, 
    AAI@st-louis-emh2.army.mil, ADA-SW@wsmr-simtel20.army.mil, 
    ADVISE-L%CANADA01.BITNET@cunyvm.cuny.edu, ADVSYS@eddie.mit.edu, 
    AG-EXP-L%NDSUVM1.BITNET@cunyvm.cuny.edu, AI-ED@sumex-aim.stanford.edu, 
    AIDSNEWS%RUTVM1.BITNET@cunyvm.cuny.edu, AIList@ai.ai.mit.edu, 
    AIX-L%BUACCA.BITNET@mitvma.mit.edu, ALLIN1-L@ccvm.sunysb.edu, 
    AMETHYST-USERS@wsmr-simtel20.army.mil, AMIGA-RELAY@udel.edu, 
    ANDREW-DEMOS@andrew.cmu.edu, ANTHRO-L%UBVM.BITNET@cunyvm.cuny.edu, 
    apollo@umix.cc.umich.edu, ARMS-D@xx.lcs.mit.edu, 
    ARPANET-BBOARDS@mc.lcs.mit.edu, ASM370%UCF1VM.BITNET@cunyvm.cuny.edu, 
    AVIATION@mc.lcs.mit.edu, AVIATION-THEORY@mc.lcs.mit.edu, bicycles@bbn.com, 
    BIG-LAN@suvm.acs.syr.edu, BIG-LAN@suvm.bitnet, 
    BIOTECH%UMDC.BITNET@cunyvm.cuny.edu, BIOTECH@umdc.umd.edu, 
    BITNEWS%BITNIC.BITNET@cunyvm.cuny.edu, 
    BMDP-L%MCGILL1.BITNET@cornellc.ccs.cornell.edu, 
    bug-1100@sumex-aim.stanford.edu, CA@think.com, CADinterest^.es@xerox.com, 
    CAN-INET@mc.lcs.mit.edu, cisco@spot.colorado.edu
Message-id: <F5F94E786DBF00D81C@UCBEH.SAN.UC.EDU>
X-Envelope-to: V2LNI-PEOPLE@MC.LCS.MIT.EDU, SCHEME@MC.LCS.MIT.EDU,
 NIHONGO@MC.LCS.MIT.EDU, INFO-JAPAN@MC.LCS.MIT.EDU,
 Heath-People@MC.LCS.MIT.EDU, HEADER-PEOPLE@MC.LCS.MIT.EDU,
 Dead-Flames@MC.LCS.MIT.EDU, CAN-INET@MC.LCS.MIT.EDU,
 AVIATION-THEORY@MC.LCS.MIT.EDU, AVIATION@MC.LCS.MIT.EDU,
 ARPANET-BBOARDS@MC.LCS.MIT.EDU
X-VMS-To: @LISTS.DIS
X-VMS-Cc: SHAFIE

<--------------------------------------------------------------------
< 
<                 SIGUCCS User Services Conference XVIII
<                        Call For Participation
<
<                  New Centerings in Computing Services
< 
<                  September 30 through October 3, 1990
<
<                           Westin Hotel
<                         Cincinnati, Ohio
< 
<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<Attention Directors, Managers, Analysts, Consultants, Programmers,
<<Technical Writers, Trainers, and Librarians!
<< 
<<The higher education computing scene in the 1990s will present exciting
<<challenges.  To accommodate users' needs, computing service organizations
<<are now visibly transforming in function and structure.  The widespread
<<adoption of personal computing by all disciplines, the increasing demand
<<for desktop access to shared resources, the growth in demand for
<<supercomputing capabilities, and the proliferation of powerful desktop
<<workstations exert irresistible forces on central computing services.
<<In response, the central site grows exponentially in staff and machinery
<<at one academic institution; at another, the computing center is disbanded
<<to provide distributed computing!  At some sites increasing specialization
<<is urged; at others, generalization is required.  Regardless of the
<<transforming strategy adopted by an individual institution, one fact
<<seems clear:  the user is the center toward which all computing services
<<are directed.
<< 
<<SIGUCCS '90 invites you to participate in the examination and discussion
<<of the myriad challenges facing user services professionals as we enter a
<<new decade and of the new centerings computing service organizations are
<<discovering to meet them.  Please join us!
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<You can Participate
<< 
<<	Presentations
<< 
<<	Papers
<< 
<<	Panel Discussions
<< 
<<	Quick Workshops
<< 
<<	Educational Materials Competition
<< 
<<	Newsletter Competition
<< 
<<	Technical Writing Competition
<< 
<<	Documentation Display
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<< 
<<Important Dates
<< 
<<	March 1, 1990		Presentation proposals due
<<	April 1, 1990		Notification of proposal acceptance
<<	May 1, 1990		Final Papers due
<<	June 1, 1990		Newsletter entries due
<<	June 1, 1990		Technical writing entries due
<<	June 15, 1990		Notification of paper/panel acceptance
<<	September 1, 1990	Deadline for materials for
<<				documentation display
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Presentation Topic Areas
<< 
<< 
<<Information Exchange Technology
<< 
<<Information exchange may well be the most important computing
<<activity of the 1990s. The infrastructure for information delivery, the
<<National Research and Academic Network (NREN), is presently being developed.
<<How do we meet the challenges of a world where the
<<facilitation of information delivery may be a principal user services
<<responsibility?  Topics of particular interest include:
<< 
<<	new approaches to information exchange
<< 
<<	campus activity in implementing information exchange
<<	facilities that comply with emerging international standards
<< 
<<	research and development of computer-mediated information
<<	exchange methods
<< 
<< 
<<Distributed Services
<< 
<<As the role of user services shifts to providing distributed support,
<<we must create new ways of providing traditional services as well as
<<designing new services.  Topics of particular interest include:
<< 
<<	providing support staff in departments and colleges
<< 
<<	funding issues
<< 
<<	if and how to charge back for services
<< 
<<	human networking of distributed support staff
<< 
<<	nonlabor-intensive support strategies
<< 
<<	cooperative efforts with other departments
<< 
<< 
<< 
<<Management Strategies
<< 
<<How do user services managers cooperate with other administrative and
<<academic units that use or provide computing resources?  How do they
<<meet the many and diverse demands?  Topics of particular interest include:
<< 
<<	reorganization
<< 
<<	interaction with faculty advisory groups
<< 
<<	delegating and distributing responsibility
<< 
<<	coordinating university computing resources
<< 
<<	staff professional development
<< 
<< 
<<Marketing your Services
<< 
<<Changing roles may require changing your services and, often, your image on
<<campus as you provide new services to new users.  Topics of particular in-
<<terest include:
<< 
<<	promotional strategies
<< 
<<	conducting market research
<< 
<<	designing services for unique or special audiences
<< 
<< 
<< 
<<Strategies for Small Schools
<< 
<<How can a small liberal arts college have distributed user services and
<<centralized user services?  How do distributed and centralized services work
<<together to provide computing services beyond word processing?  The
<<sciences have become computer literate; now, how do we reach out  from the
<<center to the humanities and fine arts?  Are we getting out of the
<<office and into the trenches?  Are we making too many "house calls"?
<<Should we make them at all?
<< 
<< 
<<Security and Ethics
<< 
<<As electronic mail and conferencing become more popular, computing
<<systems are widely accessible to more users.  How secure should academic
<<computing resources be?  What are the ethical guidelines provided for users
<<of electronic mail and conferencing systems?  Topics of particular interest
<<include:
<< 
<<	promoting responsible and ethical use of computing resources
<< 
<<	security strategies
<< 
<<	adopting an ethics policy
<< 
<< 
<<Serving New Audiences
<< 
<<People from the humanities, the arts, and other traditionally nontechnical
<<disciplines are discovering that computers can help in areas other than
<<word processing.  In an increasingly proactive stance in the central
<<computing facility, what do we do to attract and support these new audi-
<<ences?  Topics of interest include:
<< 
<<	providing information about off-the-shelf specialized
<<	programs for music, fine arts, and the humanities
<< 
<<	facilitating technical support of nontraditional areas
<< 
<<	serving the computing beginner who wants to do
<<	sophisticated tasks
<< 
<< 
<<Consulting, Training, and Documentation
<< 
<<Supporting those who use the computing resources that we provide re-
<<mains an important responsibility of user services organizations.  Topics
<<of particular interest include:
<< 
<<	new approaches to training
<< 
<<	providing distributed consulting
<< 
<<	documentation distribution services
<< 
<< 
<<and/or other topics that would be of interest to your national
<<and international colleagues
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Submitting Proposals
<< 
<< 
<<Submit proposals via electronic mail to:
<< 
<<	SIGPAPER@OHSTVMA.BITNET or
<< 
<<	SIGPAPER@OHSTVMA.IRCC.OHIO-STATE.EDU
<< 
<<If you do not have access to electronic mail, send a printed copy to:
<< 
<<		Susan Jenkins Saari
<<		Instruction and Research
<<		Computer Center
<<		The Ohio State University
<<		1971 Neil Avenue
<<		Columbus, OH 43210
<< 
<<		phone:      (614) 292-4843
<<		fax:      (614) 292-7081
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Accepted Proposals
<< 
<< 
<<Proposals must be received by March 1, 1990.  Any submisson received
<<after this date will not be considered by the Program Committee.  You will
<<be notified of the Program CommitteeUs decision by April 1, 1990.  If your
<<proposal is accepted, you will be asked to submit a full paper by May 1,
<<1990.  Any papers received after this date will not be considered.  You will
<<be notified of the Program CommitteeUs decision by June 15, 1990.
<< 
<<If your presentation is accepted, SIGUCCS is depending on you.  If you are
<<ker to make your presentation (not a substitute presentation).
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<How to Participate
<< 
<< 
<<Proposals
<< 
<<For each proposal, include your name, title, affiliation, mailing ad-
<<type of  proposal (presentation or panel discussion) and its topic area.
<<In addition, you must enclose the proper materials from the following
<<requirements list:
<< 
<<Description
<< 
<<Papers		Papers will be presented in 20-minute ntervals, with
<<		three papers scheduled per 90-minute session. Speakers'
<<		papers will be published in the conference proceedings.
<< 
<<Panels		Panels will be in-depth treatments of a single topic by
<<		two to four speakers from at least two different schools,
<<		coordinated by a moderator.  Allow ample time for audience
<<		discussion.  Abstracts for panels should be submitted
<<		as a unit by the person who wishes to act as a moderator.
<<		Panelists' papers will be published in the conference
<<		proceedings.
<< 
<<Quick Workshops	Quick workshops provide 90-minute overviews of new technolo-
<<		gies, innovative applications, and creative strategies
<<		for addressing the needs of computer users on campus.
<< 
<< 
<<Requirements
<< 
<<Papers		A 250- to 300-word abstract of the paper.  Acceptance of
<<		a proposal does not automatically ensure acceptance
<<		of a paper for presentation; you must submit a full
<<		paper to be considered for the conference program.
<< 
<<Panels		A 250- to 300-word description of the panel, including
<<		each panelist's name, title, affiliation, and presentation
<<		topic.  Acceptance of a panel description does not
<<		automatically ensure acceptance of the panel for
<<		presentation; each panelist must submit a full paper
<<		to be considered for the conference program.
<< 
<<Quick Workshops	A one- to two-page outline of the presentation and a
<<		10-minute videotape excerpt from the proposed presentation.
<<		Acceptance of a proposal does not automatically ensure
<<		acceptance of a workshop for presentation; you must
<<		submit a full paper to be considered for the conference
<<		program.  Only three or four presentations will be a
<<		ccepted in this category because it is highly competiive.
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<Other Ways to Participate
<< 
<<Education and Training Materials Competition
<< 
<<Interest in and the importance of user education and training have grown
<<with each SIGUCCS conference.  The 1990 SIGUCCS Conference offers,
<<for the first time, competition for user education and training materials for
<<colleges and universities.*  We invite you to submit no more than two
<<entries in any or all of the following categories: curriculum catalog, class-
<<room printed materials, or self-contained printed tutorials.  Although the
<<first year of this competition includes only printed materials, we would like
<<to know if there is an interest in expanding our future competitions to
<<include video, audio, and computer-based tutorials.  Deadline for entry is
<<June 1, 1990.  For more details and an entry form, or to address the issue
<<of future competition categories, contact:
<< 
<<		Diane Jung-Gribble
<<		Indiana University
<<		750 North State Road 46 Bypass
<<		Bloomington, IN  47405
<< 
<<		(812) 855-0962
<< 
<< 
<<		JUNG@IUBACS.BITNET
<<		JUNG@JADE.BACS.INDIANA.EDU
<< 
<<*NOTE:  this competition is not open to commercial materials
<< 
<<Newsletter Competition
<< 
<<Winning an award in the SIGUCCS Newsletter Competition is a mark of
<<distinction for your institution, and for your editors, writers,artists,and
<<designers.  You will be asked to submit two consecutive issues published
<<between June 1989 and May 1990.  Deadline for entry is June 1, 1990.
<<For more details and an entry form, contact:
<< 
<<		Jess Anderson
<<		Madison Academic Computing Center
<<		University of Wisconsin-Madison
<<		1210 West Dayton Street
<<		Madison, WI   53706
<< 
<<		(608) 263-6988
<< 
<<		ANDERSON@MACC.WISC.EDU
<<		ANDERSON@WISCMACC.BITNET
<< 
<< 
<<Technical Writing Competition
<< 
<<If you have written or published a particularly good article in a computing
<<newsletter, enter it in the Technical Writing Competition.  Each computing
<<center may enter one article.  Deadline for entry is June 1,1990.  To obtain
<<entry forms and more details, contact:
<< 
<<		Donald J. Montabana
<<		University of Pennsylvania
<<		Computing Resources Center
<<		1202 Blockley Hall
<<		Philadelphia, PA  19104-6021
<< 
<<		(215) 898-9085
<< 
<<		MONTABANA@A1.RELAY.UPENN.EDU
<< 
<< 
<< 
<<Documentation Display
<< 
<<The documentation room will feature an online system for submitted
<<documentation.  Conference attendees who have BITNET or INTERNET
<<access will be able to email documentation to their university or college.
<<Documentation may be submitted electronically to DOCUMENT@MIAMIU,
<<by hardcopy, or diskette (IBM or Mac formatted) and must be received
<<before September 1, 1990.  Direct inquries to:
<< 
<<		Al Kaled
<<		Academic Computing Services
<<		Miami University
<<		Oxford, OH  45056
<< 
<<		(513) 529-6226
<< 
<<		AK75STAF@MIAMIU
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<More Information
<< 
<< 
<<General Information
<
<<Amin Shafie, Conference Chair
<<University of Cincinnati
<< 
<< 
<<		e-mail:		SHAFIE@UCBEH.BITNET
<< 
<<		phone:		(513) 556-9001
<< 
<<		fax:		(513) 556-0035
<< 
<< 
<<Call for Participation
<<Susan Jenkins Saari, Program Chair
<<The Ohio State University
<< 
<<		e-mail:		SIGPAPER@OHSTVMA.BITNET
<< 
<<		phone:		(614) 292-4843
<< 
<<		fax:		(614) 292-7081
<< 
<< 
<<Registration
<<Ken Maccarone, Registration Chair
<<University of Cincinnati
<< 
<<		e-mail:		MACCARON@UCBEH.BITNET
<< 
<< 
<<		phone:		(513) 556-9098
<<		fax:		(513) 556-0035
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<ACM SIGUCCS
<< 
<<The Association of Computing Machinery's (ACM) Special Interest Group
<<for University and College Computing (SIGUCCS) is one of ACM's
<<organizational units devoted to the technical activities of its members.
<<SIGUCCS provides a link for guidance and the interchange of ideas among
<<computing professionals in the full range of small to large institutions.
<<Its newsletter, annual conferences, and workshops promote the discussion
<<of mutual problems. networks, user services, and computer center management.
<<This SIGUCCS conference emphasizes practical ways to improve services for
<<those who use university and college computing centers.


Amin Shafie
Assistant Director
Academic Computing Services                UCBEH::SHAFIE
University of Cincinnati                   SHAFIE@UCBEH.SAN.UC.EDU
ML 088                                     SHAFIE@UCBEH.BITNET
Cincinnati, Ohio  45221
(513) 556-9022

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Jan 90 17:11:42 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10727;
          13 Jan 90 17:06 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01894; Sat, 13 Jan 90 16:32:11 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 Jan 90 18:26:09 GMT
From: Leif Ljung /DP <mcsun!sunic!kps!llj@uunet.uu.net>
Organization: Kuwait Petroleum Sweden, Stockholm
Subject: chopping off identical domains
Message-Id: <644@kps.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

It seems that my sendmail chops the top domain name,
(.se in my case) if a mail is sent to that domain in
which my host also resides.
The problem does not exist when I'm in a subdomain to .se
sending to a host in the top domain.
Is my mailer (or .cf) to be considered as broken?

-Leif
----------
uunet!mcsun!sunic!kps!llj||llj@kps.se

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Jan 90 11:19:18 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa14333;
          14 Jan 90 11:14 EST
Date: Sun 14 Jan 90 11:10:49-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: chopping off identical domains
To: mcsun!sunic!kps!llj@uunet.uu.net
Cc: header-people@MC.lcs.mit.edu
Message-ID: <632333449.800000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <644@kps.UUCP>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>It seems that my sendmail chops the top domain name,
>(.se in my case) if a mail is sent to that domain in
>which my host also resides.
   There is a lot of flexibility within a given subdomain, and, in 
particular, it is assumed that your users should never have to type the 
domain qualification
when sending from one host to another in the same subdomain.  However, all
messages that reach any machine *must* be fully-qualified.  It turns out,
in practice, that it is virtually impossible to make partially-qualified
names work between machines in a subdomain and not have them, sooner or
later, turn up somewhere else.   
  The RFCs require that messages transferred between hosts use fully-
qualified names.

>Is my mailer (or .cf) to be considered as broken?
  I would consider it broken.  The only circumstances under which it would 
not be broken would require exceptionally careful gateways.
  Note that, even if the gateways operate to prevent any of the protocol 
rules from being broken, leaving off part of the domain name is a poor 
idea because of the user confusion it ultimately causes.  Sooner or later, 
someone who does not understand the issues will give out a chopped-off 
address at an international meeting to someone else who does not understand 
the issues, and there will be massive confusion a few weeks later when 
people try to guess at what the first and second level domains might have 
been.
   --john    Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 09:07:43 EST
Received: from NSFNET-RELAY.AC.UK by mintaka.lcs.mit.edu id aa15401;
          15 Jan 90 9:05 EST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa09990; 15 Jan 90 13:05 GMT
Received: from prg.ox.ac.uk (jael) by prg.oxford.ac.uk
	 id AA16518; Mon, 15 Jan 90 13:13:05 GMT
Received: by prg.ox.ac.uk (4.0/prg3.0)
	 id AA05342; Mon, 15 Jan 90 13:14:45 GMT
Date: Mon, 15 Jan 90 13:14:45 GMT
Message-Id: <9001151314.AA05342@prg.ox.ac.uk>
From: Geraint Jones <Geraint.Jones%prg.oxford.ac.uk@nsfnet-relay.ac.uk>
To: HEADER-PEOPLE%mc.lcs.mit.edu@nsfnet-relay.ac.uk
Subject: Re: chopping off identical domains

>->  Message-Id: <632333449.800000.KLENSIN@INFOODS.MIT.EDU>
>->  ... leaving off part of the domain name is a poor 
>->  idea because of the user confusion it ultimately causes.  Sooner or later, 
>->  someone who does not understand the issues will give out a chopped-off 
>->  address at an international meeting to someone else who does not understand 
>->  the issues, and there will be massive confusion a few weeks later when 
>->  people try to guess at what the first and second level domains might have 
>->  been.
>->     --john    Klensin@INFOODS.MIT.EDU
>->  -------

Some of us over here are in the habit of referring to addresses in the USA
as, say, HEADER-PEOPLE@mc.lcs.mit.edu.usa (well, strictly speaking, as
HEADER-PEOPLE@usa.edu.mit.lcs.mc, but that's because we still drive on the
left; don't let's get led astray by that red herring).  What is the status
of the .USA ? Is it a UK fiction?  Is it not a damn good idea even if it is?
What is the proper atitude to adopt to an American who thinks the most
significant domain of his address is EDU or COM, when there seems no reason
not to have EDU or COM next-to-most-significant-level domains elsewhere?
									   gj

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 13:01:12 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa18814; 15 Jan 90 12:59 EST
Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA01894; Mon, 15 Jan 90 18:58:31 +0100
Received: by slembe.uio.no (5.61++/SMI-3.2)
          id AA09341; Mon, 15 Jan 90 18:58:29 +0100
Date: Mon, 15 Jan 90 18:58:29 +0100
Message-Id: <9001151758.AA09341@slembe.uio.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: Geraint.Jones@prg.oxford.ac.uk
Cc: HEADER-PEOPLE@mc.lcs.mit.edu
In-Reply-To: <9001151314.AA05342@prg.ox.ac.uk> "Geraint.Jones%prg.oxford.ac.uk@nsfnet-relay.ac.uk"
Subject: UK fiction (.USA)

Flame ON!

UK never ceases to surprise me.  So you "invent" your own top-level
domain just to screw the name-servers, the Internet idea of domains,
and interoperability.  How nice.

It may be in the British way of life to be pragmatic and unerringly
avoid thinking about consequences and design philosophy, but please
keep this to your own island, OK?

Flame half off

There already exists a .US top-level domain, with geographical
subdomains.  .USA does NOT exist.  If we were to follow ISO 3166, it
would be correct to have .GB instead of .UK.  As far as I know, the
rest of the national top-level domains follow this standard.  While on
the topic of standards and suggestions, may I suggest that you people
over there try to follow those that already exist before you "suggest"
all kinds of "improvements"?

Flame off

> What is the status of the .USA?  Is it a UK fiction?

Yes, indeed it is.

> Is it not a damn good idea even if it is?

It is not a damn good idea.

The Internet is an American invention.  EDU, COM, etc are there for
historical reasons.  The same is true for UK as a top-level domain.

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 14:24:56 EST
Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa20164;
          15 Jan 90 14:19 EST
Posted-Date: Mon, 15 Jan 90 11:18:05 PST
Message-Id: <9001151917.AA25409@venera.isi.edu>
Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA25409>; Mon, 15 Jan 90 11:17:16 -0800
To: Craig Partridge <craig@nnsc.nsf.net>
Cc: raf@cu.nih.gov, header-people@mc.lcs.mit.edu
Reply-To: pvm@venera.isi.edu
Subject: Re: .BITNET domain 
In-Reply-To: Your message of Fri, 05 Jan 90 08:14:49 -0500.
             <9001091429.aa13033@mintaka.lcs.mit.edu> 
Date: Mon, 15 Jan 90 11:18:05 PST
From: Paul Mockapetris <pvm@venera.isi.edu>

> 
> > My original question is why are these policies not enforced
> > consistently with respect to FIDONET.ORG and UU.NET?  Why is an Indian
> > host named shakti.uu.net acceptable while a similarly named BITNET host
> > is not?
> 
> If shakti isn't a host involved in running uu.net it isn't acceptable use.
> (I don't personally know the status of shakti).  As for enforcement,
> that's a tricky question.  It isn't clear there is an enforcement mechanism,
> short of turning off uu.net at the root domain servers -- that's a rather
> extreme act.  All the more reason for the NIC to be careful about who it
> gives .NET domains to.

The .NET domain is an obvious breeding ground for Trojan horses.

Why UU.NET and not .BITNET?

As my mother would say "fool me once - shame on you; fool me twice -
shame on me."  Or as someone else said, I forget who, "We won't be
fooled again."

paul

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 16:44:59 EST
Received: from NSFNET-RELAY.AC.UK by mintaka.lcs.mit.edu id aa22687;
          15 Jan 90 16:38 EST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa24760; 15 Jan 90 20:19 GMT
Received: from prg.ox.ac.uk (jael) by prg.oxford.ac.uk
	 id AA23213; Mon, 15 Jan 90 20:26:54 GMT
Received: by prg.ox.ac.uk (4.0/prg3.0)
	 id AA05844; Mon, 15 Jan 90 20:28:34 GMT
Date: Mon, 15 Jan 90 20:28:34 GMT
Message-Id: <9001152028.AA05844@prg.ox.ac.uk>
From: Geraint Jones <Geraint.Jones%prg.oxford.ac.uk@nsfnet-relay.ac.uk>
To: Erik Naggum <erik%naggum.uu.no@nsfnet-relay.ac.uk>
Cc: HEADER-PEOPLE%mc.lcs.mit.edu@nsfnet-relay.ac.uk
Subject: fiction

> Message-Id: <9001151758.AA09341@slembe.uio.no>
>
> > What is the status of the .USA?  Is it a UK fiction?
> 
> Yes, indeed it is.

Thank you for the information; I assure you I really was asking because I
wanted to know.

> The Internet is an American invention.

I am told that politeness and a sense of humour are English inventions.  There
are times I wonder what it would be like to be English.  I bet you do too.   gj

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 18:17:02 EST
Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id aa28615;
          30 Jan 90 18:09 EST
Received: from CCRMA-F4 by SAIL.Stanford.EDU with PUP; 30-Jan-90 15:09 PST
Date: 30 Jan 90  1509 PST
From: Tovar <TVR%CCRMA-F4@sail.stanford.edu>
Subject: Junk EMail    
To:   Header-People%MC.LCS.MIT.EDU@sail.stanford.edu
Message-ID:  <9001301809.aa28615@mintaka.lcs.mit.edu>

If there isn't an Internet regulation explicitly prohibiting this kind of
abuse, there ought to be something in the header to permit these things to
be automatically flushed.  While it might be argued that the conference
in question might have some vague relevence to Header-People, it is clearly
of little interest to readers of AIDS-News, Dead-Flames or Aviation-Theory!
Some states prohibit junk faxing, and we should do likewise; but if we can't,
at least we should be able to throw the stuff away before it gets in the
door.  You know what will happen if we don't...

					-- Tovar

Partial enclosure of ~500 line message:
_______________________________________________________________________________

 11-Jan-90  1959	@mc.lcs.mit.edu:SHAFIE@ucbeh.san.uc.edu 	SIGUCCS CALL for PARTICIPATION    
Received: from SAIL.STANFORD.EDU by CCRMA with PUP; 11-Jan-90 19:59 PST
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jan 90  20:02:01 PST
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07416;
          11 Jan 90 17:00 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 16:40:15 EST
Received: from ucbeh.san.uc.edu by mintaka.lcs.mit.edu id aa04135;
          11 Jan 90 15:37 EST
Date: Thu, 11 Jan 90 14:13 EST
From: Amin Shafie - Univ of Cincinnati Comp Ctr <SHAFIE@ucbeh.san.uc.edu>
Subject: SIGUCCS CALL for PARTICIPATION
To: 386USERS@twg.com, 9370-L%HEARN.BITNET@mitvma.mit.edu, 
    AAI@st-louis-emh2.army.mil, ADA-SW@wsmr-simtel20.army.mil, 
    ADVISE-L%CANADA01.BITNET@cunyvm.cuny.edu, ADVSYS@eddie.mit.edu, 
    AG-EXP-L%NDSUVM1.BITNET@cunyvm.cuny.edu, AI-ED@sumex-aim.stanford.edu, 
    AIDSNEWS%RUTVM1.BITNET@cunyvm.cuny.edu, AIList@ai.ai.mit.edu, 
    AIX-L%BUACCA.BITNET@mitvma.mit.edu, ALLIN1-L@ccvm.sunysb.edu, 
    AMETHYST-USERS@wsmr-simtel20.army.mil, AMIGA-RELAY@udel.edu, 
    ANDREW-DEMOS@andrew.cmu.edu, ANTHRO-L%UBVM.BITNET@cunyvm.cuny.edu, 
    apollo@umix.cc.umich.edu, ARMS-D@xx.lcs.mit.edu, 
    ARPANET-BBOARDS@mc.lcs.mit.edu, ASM370%UCF1VM.BITNET@cunyvm.cuny.edu, 
    AVIATION@mc.lcs.mit.edu, AVIATION-THEORY@mc.lcs.mit.edu, bicycles@bbn.com, 
    BIG-LAN@suvm.acs.syr.edu, BIG-LAN@suvm.bitnet, 
    BIOTECH%UMDC.BITNET@cunyvm.cuny.edu, BIOTECH@umdc.umd.edu, 
    BITNEWS%BITNIC.BITNET@cunyvm.cuny.edu, 
    BMDP-L%MCGILL1.BITNET@cornellc.ccs.cornell.edu, 
    bug-1100@sumex-aim.stanford.edu, CA@think.com, CADinterest^.es@xerox.com, 
    CAN-INET@mc.lcs.mit.edu, cisco@spot.colorado.edu
Message-id: <F5F94E786DBF00D81C@UCBEH.SAN.UC.EDU>
X-Envelope-to: V2LNI-PEOPLE@MC.LCS.MIT.EDU, SCHEME@MC.LCS.MIT.EDU,
 NIHONGO@MC.LCS.MIT.EDU, INFO-JAPAN@MC.LCS.MIT.EDU,
 Heath-People@MC.LCS.MIT.EDU, HEADER-PEOPLE@MC.LCS.MIT.EDU,
 Dead-Flames@MC.LCS.MIT.EDU, CAN-INET@MC.LCS.MIT.EDU,
 AVIATION-THEORY@MC.LCS.MIT.EDU, AVIATION@MC.LCS.MIT.EDU,
 ARPANET-BBOARDS@MC.LCS.MIT.EDU
X-VMS-To: @LISTS.DIS
X-VMS-Cc: SHAFIE

<--------------------------------------------------------------------
< 
<                 SIGUCCS User Services Conference XVIII
<                        Call For Participation
<
<                  New Centerings in Computing Services
< 
<                  September 30 through October 3, 1990
<
<                           Westin Hotel
<                         Cincinnati, Ohio
< 
...


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU;  5 Feb 90 15:46:33 EST
Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU;  5 Feb 90 15:46:13 EST
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa19792;
          5 Feb 90 15:38 EST
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA04865; Mon, 5 Feb 90 12:39:20 PST
Date: Mon, 5 Feb 90 12:39:20 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9002052039.AA04865@garnet.berkeley.edu>
To: header-people@ai.ai.mit.edu
Subject: Keep it simple gateways!

Lets keep it simple folks.  The gateway address suffixes are getting
to be to much. Networks are not even following their own rules.
Here is how the address

	<vanbastelaer@ts.info.fundp.rtt.be>

was changed to:

vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu

as it was relayed:

vanbastelaer%ts.info.fundp.rtt.be

     %fun-cs.uucp               UUCP node incorrectly added  a ".UUCP"
				host name. (fun-cs.uucp is in the
				UUCP zone of the internet mail system
				with the name fun-cs.info.fundp.ac.be
				and should have left the internet
				address as is).

         %blekul60.bitnet	   UUCP/BITNET gateway incorrectly
				   added a ".bitnet" node name (should
				   have left it as is since .UUCP is a
				   valid top domain in the BITNET VM
				   Mailer system.)

             @jade.berkeley.edu	      UCBJADE correctly added internet
				      hostname to .BITNET address for
				      relay into the campus internet.


Bill Wells
postmaster@jade.berkeley.edu
netinfo@garnet.berkeley.edu
NETINFO@UCBGARNE.BITNET

In reference to:

From vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu Fri Feb  2 22:41:56 1990
Received: by garnet.berkeley.edu (5.57/1.32)
	id AA21080; Fri, 2 Feb 90 22:41:55 PST
Received: from jade.Berkeley.EDU by violet.berkeley.edu (5.61/1.31)
	id AA00866; Fri, 2 Feb 90 22:41:49 PST
Received: from BLEKUL60.BITNET
	by jade.berkeley.edu (5.61.1/1.16.23)
	id AA27520; Fri, 2 Feb 90 22:41:58 PST
From: vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu
Received: by kulcs.uucp; Fri, 2 Feb 90 18:12:01 +0100
Date: 2  Feb 90 17:49
To: <postmaster@jade.berkeley.edu>
Cc: <dlw@jade.berkeley.edu>
Message-Id: <213:vanbastelaer@ts.info.fundp.rtt.be>
Subject: BRIE
Return-Receipt-To: vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu

(text deleted)


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Feb 90 17:33:19 EST
Received: from [129.122.1.1] by mintaka.lcs.mit.edu id aa25156;
          5 Feb 90 17:25 EST
Received: (from user DRB) by Relay.Prime.COM; 05 Feb 90 17:29:09 EST
To: header-people@mc.lcs.mit.edu
Cc: Rob Ullmann <Ariel@relay.prime.com>
From: David Robinson (Special Systems) <DRB@relay.prime.com>
Subject: Proposed RFC on Encoding header field
Encoding: 13 text, 342 text
Date: 05 Feb 90 17:29:09 EST
Message-ID:  <9002051726.aa25156@mintaka.lcs.mit.edu>

The following is a draft RFC for an Encoding header field to support the
mailing of multi-part, multi-structured Internet messages.

A mail user interface (MUA) using Encoding for message structures has been
in use at Prime for the past 2 years.  A newer MUA and mailer, which uses
Encoding for multiple parts as well as structures, has been in use for the
past 6 months.

Comments welcome.

David Robinson
Rob Ullmann
Prime Computer, Inc.


Network Working Group                            D. Robinson, R. Ullmann
Request for Comments: DRAFT                         Prime Computer, Inc.
                                                           February 1990






              Encoding Header Field for Internet Messages

1. Status of the Memo

This RFC proposes an Encoding header field to permit the mailing of
multi-part, multi-structured messages.

The use of Encoding obsoletes RFC 943 (Message encapsulation), updates
RFC 1049 (Content-Type), and updates RFC 1040 (Privacy enhancement).

Distribution of this memo is unlimited.

2. Introduction

RFC 822 [2] defines an electronic mail message to consist of two parts,
the message header and the message body, separated by an apparently
blank line.

The Encoding header field permits the message body itself to be further
broken up into parts, each part also separated from the next by an
apparently blank line.

Thus, conceptually, a message has a header part, followed by one or more
body parts, all separated by blank lines.

Each body part has an encoding type.  The default (no Encoding field in
the header) is a message body of one part of type "text".

3. The Encoding Field

The Encoding field consists of one or more subfields, separated by
commas.  Each subfield corresponds to a part of the message, in the
order of that part's appearance.  A subfield consists of a line count, a
keyword defining the encoding, and optional information relevant only to
the specific encoding. The line count is optional in the last subfield.











Robinson, Ullmann                                               [Page 1]

RFC DRAFT     Encoding Header Field for Internet Messages  February 1990


3.1. Format of the Encoding Field

The format of the Encoding field is:

  [<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]

  where:

     <count>   := a decimal integer
     <keyword> := a single alphanumeric token starting with an alpha
     <options> := keyword-dependent options


3.2. <count>

The line count is a decimal number specifying the number of text lines
in the part. Parts are separated by a blank line, which is not included
in the count of either the proceeding or following part. Since a count
always begins with a digit and a keywords always begins with an letter,
it is always possible to determine if the count is present. (The count
is first because it is the only information of interest when skipping
over the part.)

The count is not required on the last or only part.

3.3. <keyword>

The keyword defines the encoding type.  The keyword is a common single
word name for the encoding type. The keywords are not case-sensitive.

Standard keywords are registered with the Internet NIC (presently
J. K. Reynolds), the list is intended to be the same as the list used
for the Content-Type: header descibed in [6]. This RFC proposes
additions to the list. Implementations can then treat "Content-Type" as
an alias of "Encoding", which will always have only one body part.

3.4. <options>

The optional information is used to specify additional keyword-specific
information needed for interpreting the contents of the encoded part.
It may be any sequence of tokens not containing a comma.

3.5. Encoding Version Numbers

In general, version numbers for encodings, when not actually available
within the contents of the encoded information, will be handled as
options.





Robinson, Ullmann                                               [Page 2]

RFC DRAFT     Encoding Header Field for Internet Messages  February 1990


3.6. Comments

Comments enclosed in parentheses may, of course, be inserted anywhere in
the Encoding field.  Mail reading systems may or may not pass the
comments to their clients.  Comments may not be used by mail reading
systems for content interpretation; that is the function of options.

4. Encodings

This section describes some of the defined encodings used.

As with the other keyword-defined parts of the header format standard,
extensions in the form of new keywords are expected and welcomed.
Several basic principles should be followed in adding encodings:

   - The keyword should be the most common single word name for the
     encoding, including acronyms if appropriate. The intent is that
     different implementors will be likely to choose the same name for
     the same encoding.

   - Keywords not be too general: "binary" would have been a bad choice
     for the "hex" encoding.

   - The encoding should be as free from unnecessary idiosyncracies as
     possible, except when conforming to an existing standard, in which
     case there is nothing that can be done.

   - The encoding should, if possible, use only the 7 bit ASCII printing
     characters if it is a complete transformation of a source document
     (such as "hex" or "uuencode". If it is essentially a text format,
     the full range may be used. If there is an external standard, the
     character set may already be defined.

Keywords beginning with "X-" are permanently reserved to implementation-
specific use. No standard registered encoding keyword will ever begin
with "X-".

4.1. Text

This indicates that the message is in no particular encoded format, but
is to be presented to the user as is.

The full range of the ASCII character set is used. The message is
expected to consist of lines of reasonable length (less than 1000
characters).

On some transport services, only the 7 bit subset of ASCII can be used.
Where full 8 bit transparency is available, the text is assumed to be
ISO 8859-1 [3] (ASCII-8)



Robinson, Ullmann                                               [Page 3]

RFC DRAFT     Encoding Header Field for Internet Messages  February 1990


4.2. Message

This encoding indicates that the body part is itself in the format of an
Internet message, with its own header part and body part(s).  A
"message" body part's message header may be a full internet message
header or it may consist only of an Encoding field.

Using the message encoding on returned mail makes it practical for a
mail reading system to implement a reliable resending function, if the
mailer generates it when returning contents. It is also useful in a
"copy append" MUA operation.

Message encoding is also used when mapping to X.400 to handle
recursively included X.400 P2 messages.

4.3. Hex

The encoding indicates that the body part contains binary data, encoded
as 2 hexadecimal digits per byte, highest significant nibble first.

Lines consist of an even number of hexadecimal digits.  Blank lines are
not permitted.  The decode process should accept lines with between 2
and 998 characters, inclusive.

4.4. EVFU

EVFU (Electronic Vertical Format Unit) specifies that each line begins
with a one-character "channel selector". The original purpose was to
select a channel on a paper tape loop controlling the printer.

This encoding is sometimes called "FORTRAN" format. It is the default
output format of FORTRAN programs on a number of computer systems.

The legal characters are `0' to `9', `+', `-', and space.  These
correspond to the 12 rows (and absence of a punch) on a printer control
tape (used when the control unit was electromechanical).

The channels that have generally agreed definitions are:

        1     advances to the first print line on the next page
        0     skip a line, i.e. double-space
        +     over-print the preceeding line
        -     skip 2 lines, i.e. triple-space
     (space)  print on the next line, single-space


4.5. EDI

The EDI (Electronic Document Interchange) keyword indicates that the
message or part is a business document, formatted according to ANSI X12


Robinson, Ullmann                                               [Page 4]

RFC DRAFT     Encoding Header Field for Internet Messages  February 1990


or related standards.

The first word after the EDI keyword indicates the particular
interchange standard.

A message containing a note and 2 X12 purchase orders might have an
encoding of:

    Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12

4.6. X.400

The Encoding header field provides a mechanism for mapping multi-part
messages between CCITT X.400 [1] and RFC 822.

The X.400 keyword specifies a section that is converted from an X.400
body part type not known to the gateway, or not corresponding to a
useful internet encoding.

If the message transits another gate, or if the receiving user has the
appropriate software, it can be decoded and used.

The X.400 keyword is followed by a second token indicating the method
used.  The simplest form is "X.400 HEX", with the complete X.409
encoding of the body part in hexadecimal. More compact is "X.400 3/4",
using the 3-byte to 4-character encoding as specified in RFC 1040,
section 4.2.3.4.

4.7. uuencode

The uuencode keyword specifies a section consisting of the output of the
uuencode program supplied as part of uucp.

4.8. encrypted

The encrypted keyword indicates that the section is encrypted with the
methods in RFC1040 [4] and revisions. This replaces the possible use of
RFC934 [5] encapsulation.

References

[1]   International Telegraph and Telephone Consultative Committee.
      Data Communication Networks: Message Handling Systems.
      In CCITT Recommendations X.400 to X.430.  VIIIth Plenary Assembly,
         Malaga-Torremolinos, 1984.
      Fascicle VIII.7 ("Red Book").

[2]   David H. Crocker.
      Standard for the Format of ARPA Internet Text Messages.
      RFC 822, University of Delaware, August, 1982.


Robinson, Ullmann                                               [Page 5]

RFC DRAFT     Encoding Header Field for Internet Messages  February 1990


[3]   International Organization for Standardization.
      Information processing - 8-bit single-byte coded graphic character
         sets - Part 1: Latin alphabet No. 1.
      ISO 8859-1, ISO, 1987.

[4]   J. Linn.
      Privacy enhancement for Internet electronic mail: Part I: Message
         encipherment and authentication procedures..
      RFC 1040, IAB Privacy Task Force, January, 1988.

[5]   M. T. Rose, E. A. Stefferud.
      Proposed standard for message encapsulation.
      RFC 943, University of Delaware and NMA, January, 1985.

[6]   M. A. Sirbu.
      Content-type header field for Internet messages.
      RFC 1049, CMU, March, 1988.

Authors' Addresses

   David Robinson 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

   Phone: +1 508 879 2960 x1774
   Email: DRB@Relay.Prime.COM

   Robert Ullmann 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

   Phone: +1 508 879 2960 x1736
   Email: Ariel@Relay.Prime.COM

















Robinson, Ullmann                                               [Page 6]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Feb 90 20:39:51 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa03564; 5 Feb 90 20:31 EST
Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA20735; Tue, 6 Feb 90 01:47:18 +0100
Received: by slembe.uio.no (5.61++/SMI-3.2)
          id AA03964; Tue, 6 Feb 90 01:47:16 +0100
Date: Tue, 6 Feb 90 01:47:16 +0100
In-Reply-To: <9002051726.aa25156@mintaka.lcs.mit.edu> "DRB@relay.prime.com"
Message-Id: <90-037-0007@naggum.uu.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: DRB@relay.prime.com
Cc: header-people@mc.lcs.mit.edu, Ariel@relay.prime.com
Subject: Proposed RFC on Encoding header field

Robert and David,

I appreciate the effort you have made, and like the result.  I think
this will gain more acceptance in the user community than the
Content-Type field has (at least as far as I've seen -- I've never
received any mail with this header).  It may render me biased, since I
exchange mail with Robert now and then, but I _have_ seen mail with
the "Encoding" header in it. :-)

Your list of added keywords is just what the doctor ordered.

However, it seems to me that Encoding and Content-Type solve somewhat
similar problems, but very differently.  You indicate that one could
regard Encoding as an alias for Content-Type in the presence of one
body-part.  I never liked the number of semicolons in Content-Type,
which I think makes the header harder to read for humans, and I see
Encoding as more versatile than Content-Type in general applications,
whereas Content-Type is better for whole documents being transmitted.

My comment reflects on the appropriateness of stressing the similarity
between Encoding and Content-Type.  As far as I can see, they serve
different purposes which are somewhat similar, but not enough to make
the solutions similar.  To the extent that design decisions have been
made to accomodate the similarity and "aliasability" between these, I
think these should be reassessed.

From a cursory, midnight reading of the draft RFC, I want to implement
it in my mailer software, particularly the part about "message", which
my MTA will need.  I didn't get as far as implementing Content-Type,
although I started to read about SGML because of it...

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Feb 90 00:49:01 EST
Received: from [129.189.192.2] by mintaka.lcs.mit.edu id aa14128;
          6 Feb 90 0:42 EST
Received: by orc.olivetti.com (4.0/SMI-3.2)
	id AA01865; Mon, 5 Feb 90 21:42:39 PST
Resent-Message-Id: <9002060542.AA01865@orc.olivetti.com>
Return-Path: <roode@orc.olivetti.com> 
Received: from orc.olivetti.com (Pisa) by Ricerca (4.0/SMI-3.2) id AA06987;
        Mon, 5 Feb 90 21:38:07 PST 
Received: by orc.olivetti.com (4.0/SMI-3.2) id AA01823; Mon, 5 Feb 90
        21:37:32 PST 
Date: Mon, 5 Feb 1990 21:37:30 PST 
From: David Roode <roode@orc.olivetti.com>
To: header-people@mc.lcs.mit.edu
Cc: DRB@relay.prime.com, header-people@mc.lcs.mit.edu, Ariel@relay.prime.com, 
    enag@ifi.uio.no, roode@orc.olivetti.com
Subject: Re: Proposed RFC on Encoding header field 
In-Reply-To: Your message of Tue, 6 Feb 90 01:47:16 +0100 
Message-Id: <CMM.0.87.634282650.roode@Pisa> 
Resent-To: header-people%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu, 
           drb%relay.prime.com@relay.cs.net, 
           ariel%relay.prime.com@relay.cs.net
Resent-Date: Mon, 5 Feb 1990 21:42:37 PST
Resent-From: David Roode <roode@orc.olivetti.com>
Message-Id: <CMM.0.87.634282957.roode@Pisa>

My feeling is that what is needed is the analog of the content-type/
encoding header, but that it is too important to be encoded as a header.
I think this piece of information belongs in the SMTP (mail transfer)
envelope.  This would broaden SMTP to be a "Typed Simple Message Transfer
Protocol" with exactly 1 type of content negotiated between sender
and receiver for each message.

This broadening of SMTP would permit, using the same definition as
is currently done for SMTP, the transfer of typed data such as
Group III Facsimile data or digitally encoded voice or postscript.
Where alternative representations are possible at the source, the destination
could negotiate a translation, or relay back to the sender "message
type not supported at receiving site."  One thing I think critical to this
broadening of SMTP into TSMTP would be the requirement of support
for 8-bit bytes rather than limitations to 7 bit ASCII.
The header information expected would be dependent on the message type,
i.e. a new RFC 822 might be required for each new message type.

The services this transport protocol might efficiently support are many.
To name a few:
	1.  Users could have Voice and FAX mailboxes on each
	host in addition to text.

	2.  A voice mailbox might be forwarded by the host into a voice
	mail system accessible from the telephone network.
	Long-haul transmission would be by the Internet.

	3.  FAX mailboxes might be redirected to various printing
	FAX machines, as the recipient travels.

	4.  Efficient relaying of FAX traffic from the Internet to
	persons not on the Internet would be possible.

	5.  Simple and more economical transmission of FAX data would
	be possible through the use of the Internet.

	6.  New user agents might be created which would not only
	let the user read his text mail, but also permit him to
	browse through stored voice and FAX.  At the same time,
	a voice-only user agent could be allowed, both for
	receipt and transmission.

	7.  To support incoming data from the switched telephone
	GROUP III FAX network, a standard header, perhaps
	in bar code format, could be defined for the header page
	of a hardcopy FAX transmitted into a relay for conversion
	to TSMTP FAX traffic.  


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Feb 90 01:37:14 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa16085; 6 Feb 90 1:29 EST
Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA22737; Tue, 6 Feb 90 07:29:13 +0100
Received: by slembe.uio.no (5.61++/SMI-3.2)
          id AA06511; Tue, 6 Feb 90 07:29:11 +0100
Date: Tue, 6 Feb 90 07:29:11 +0100
Message-Id: <9002060629.AA06511@slembe.uio.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: David Roode <roode@orc.olivetti.com>
Cc: header-people@mc.lcs.mit.edu, DRB@relay.prime.com, Ariel@relay.prime.com
In-Reply-To: <CMM.0.87.634282650.roode@Pisa>
Subject: Proposed RFC on Encoding header field 

David,

Have you considered what it takes to get something like that
implemented?  (8 out of 10 random vendors implement SMTP wrong as it
is, and more than half of the programmers behind them can't spell
"state machine".)

Have you considered what it would take to get system admins to want to
support it?

We have a good protocol as it is, SMTP, and we have a tremendously
versatile standard for the messages carried on top of it.  (I mean,
how would you introduce an "Encoding" field in X.400 if it wasn't
already there?  Ever looked at the difference between X.400-1984 and
X.400-1988?)

This present draft RFC solves a problem very neatly.  No binary trash,
no real need to rush to implement it in the UA's as the users can do
without it (using the field as guidelines, only) for a while.

In short, if you want to reinvent X.400 (which basically is a
reinvention of the Internet mail services with a lot of wishes thrown
in to make it hard to implement), it has to be less than a wish-list.

God, it's 7.30.  Where did the night go? :-)

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Feb 90 21:42:34 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00410;
          6 Feb 90 21:35 EST
Date: Tue 6 Feb 90 21:31:33-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Proposed RFC on Encoding header field 
To: erik@naggum.uu.no
Cc: header-people@MC.lcs.mit.edu
Message-ID: <634357893.80000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <9002060629.AA06511@slembe.uio.no>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

I tend to agree with David, but for another reason.  Strangely enough, it 
starts from Eric's premise, but I reach a different conclusion.  We have 
gone to considerable lengths, in the original protocols and in HRRFC 
(RFC1123) to say, more or less, "if you accept the envelope, you are 
accepting responsibility for getting the message delivered".  I would add 
to this "in intelligible form".  The protocols also specify how the errors 
are to be reported if reporting must be delayed, specifically use of <> in 
the MAIL FROM field, to avoid error-reporting loops.  In most systems, 
envelope management at that level must be done by the MTA, not an MUA.
  Now, if the type of information implied by "Encoding" is in the headers, 
the MTA cannot guarantee intelligible delivery, since it can't verify that 
the delivery host has the required capabilities, without looking at the 
message headers, which MTAs are not supposed to need to do.  And, with a 
good MTA/MUA separation, the UA, upon discovering that it can't handle the 
Encoding properly, cannot generate a protocol-conforming non-delivery 
message (here really a non-comprehensibility message).
  It may well be that one would optimally want both Encoding headers and 
encoding information in the envelope, but the envelope information must be 
sufficient that the MTA can determine whether or not the receiver can 
process the information.
  Erik argues that, since many sites can't get SMTP right, tampering with 
it is worse.  I suggest that, since many sites cannot get SMTP right, and 
many others won't implement this feature [quickly], the envelope is exactly 
the right place to do it.  Consider three cases:
 Case 1. Server-SMTP gets an "encoding" verb and the host knows how to 
process it.  Encoding is handled properly, much as in the original 
proposal.
 Case 2. Server-SMTP gets an "encoding" verb and understands about them,
but the host does not know how to handle whatever encoding is specified in 
the predicate.  Server-SMTP sends back a proper fatal error message, 
typically within the protocol by rejecting the "encoding" verb.
 Case 3. Server-SMTP gets an "encoding" verb but--either because it is a 
bad implementation or because it has not implemented it yet--does not 
recognize it at all.  Server-SMTP rejects the verb, replying with either a 
syntax error or some type of "facility not available" error.  
  I think that is the desired behavior.

Suggested metarule:  Any proposed change to mail that involves a feature 
that would change the interpretation of the message in a fundamental way if 
it were used (i.e., where ignoring the use of the feature if it were not 
recognized would be hazardous to intelligibility or worse) should require a 
change to the envelope that will cause older systems, that don't have 
knowledge of the feature, to reject the message.
  This suggested metarule could take a form much more simple than putting 
an encoding verb in the envelope.  One could, in principle, define an 
extended SMTP (ESMTP? EMTP?) that would have several new "required" header 
fields ("required" in this context, means only that mail systems would need 
to be prepared to cope with them, not that they would necessarily appear in 
every message).  That extended version could then be a near superset of 
the existing RFC821/822 but with at least one envelope modification that 
would distinguish "ordinary" from "extended".  As an extreme example, a 
system originating an "extended" message might send
   STUF FROM: <...>
in the envelope, rather than
   MAIL FROM: <...>
Guaranteed to stop an old, poor, implementation in its tracks.

Note that this is arguably necessary for something as "trivial" as 
transmission of ISO8859-1, since SMTP implementations have the RIGHT TO 
EXPECT that only seven-bit characters will be transmitted.  This is a 
little different from saying "some transport media won't support eight bit 
characters".
     --john klensin
    Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 08:48:10 EST
Received: from cise.cise.nsf.gov by mintaka.lcs.mit.edu id aa23496;
          7 Feb 90 8:40 EST
Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id <AA17218@cise.cise.nsf.gov>; Wed, 7 Feb 90 08:40:57 -0500
From: Stephen Wolff <steve@cise.nsf.gov>
Received: by ncri.cise.nsf.gov id <AA05831@ncri.cise.nsf.gov>; Wed, 7 Feb 90 08:40:47 -0500
Date: Wed, 7 Feb 90 08:40:47 -0500
Message-Id: <9002071340.AA05831@ncri.cise.nsf.gov>
To: header-people@mc.lcs.mit.edu, roode@orc.olivetti.com
Subject: Re: Proposed RFC on Encoding header field
Cc: Ariel@relay.prime.com, DRB@relay.prime.com

Why spend so much energy on a vanishing species?  Do it for X.400.  -s


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 12:33:35 EST
Received: from apollo.transarc.com by mintaka.lcs.mit.edu id aa02569;
          7 Feb 90 12:21 EST
Received: by apollo.transarc.com (5.57/Ultrix3.0-C)
	id AA08935; Wed, 7 Feb 90 11:08:02 EST
Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3
          via MS.5.6.apollo.transarc.com.pmax_3;
          Wed,  7 Feb 90 11:07:59 -0500 (EST)
Message-Id: <UZo4TTL0BwwO8SS2N4@transarc.com>
Date: Wed,  7 Feb 90 11:07:59 -0500 (EST)
From: Craig_Everhart@transarc.com
Reply-To: Craig_Everhart@transarc.com
To: header-people@mc.lcs.mit.edu
Subject: Re: Proposed RFC on Encoding header field
Cc: DRB@relay.prime.com, Ariel@relay.prime.com, Craig_Everhart@transarc.com, 
    nsb@thumper.bellcore.com
In-Reply-To: <9002060629.AA06511@slembe.uio.no>
References: <9002060629.AA06511@slembe.uio.no>

Here are my comments, shorter to longer.

Point 1: line count.  Does the counting begin with the first non-blank
line of the encoded part?  do blank lines within the encoded part count?
 Are transport mechanisms rigorous enough in not introducing extra blank
lines after the end of a header?

Point 2: some of the new encoding types, such as ``hex'', ``uuencode'',
and ``encrypted''.  These are ill-specified, I think.  It's clear that a
part described by one of these encodings should undergo the named
transformation before becoming useful; that is, one needs to uudecode a
body part that's described by a ``uuencode'' encoding.  But what's the
result?  Is it text?  Is it a tar file?  Is it a compressed tar file? 
Is it a raster image in some format?  Is it an encrypted mail message
with headers and all?  If you're going to admit simple
data-transformation ``encoding'' types, the language for specifying them
has to be richer than this.

Probably EVFU encoding implies that the resultant object is a
line-printer image, much as PostScript encoding/content-type implies
that the resultant object is a printed or displayed page.  I don't know
enough about the actual content-types in EDI or X.400 (why 1984? why not
1988?) to comment on whether this is a sufficient mapping.

Point 3: descriptors in the envelope or header or body.  In our
Content-Type: use in Andrew messages, we treat the header value as a tag
on the body type.  We worked out a solution to the exchange problem, but
never implemented or published it.  I'll outline it here, just to muddy
the waters (:-)).

Invent a new class of delivery agent, in some ways similar to the one in
the X.400 architecture.  This class of delivery agent is, in general,
responsible for doing content-type manipulation as well as doing actual
delivery.  That is, each message to be delivered may have a
Content-type: header indicating that it isn't a vanilla-text message. 
If the delivery agent is being asked to deliver the message to a
recipient that is unable to understand the given content-type, perhaps
the message should be translated into a form that the recipient is able
to understand (with the presumption that all recipients understand
vanilla text).

We introduce the If-Type-Unsupported: field, which takes one of three
values that indicate what to do if the delivery agent can't know that
the recipient is able to understand the content-type of the given
message.  The values are:

- alter	transform the message to an understandable form
- send	send the message with content-type unaltered
- reject	do not transform the message; reject it back to its sender.

With this, message senders can indicate what content-type
transformations should occur when the delivery system can't be sure that
the content-type will be understood.  We've implemented this much, and
we're pretty happy with it.

Now, how does the delivery agent ever tell whether a fancy content-type
will be understood?  (This is what we never really implemented; our own
delivery system can never tell whether an off-site message recipient
will be able to understand a fancy content-type, so it always has to use
the If-type-unsupported information for formatted mail going off-site.)

The answer to the question depends on the delivery protocol.  For SMTP,
imagine an extension command something like
	XCT <content-type>
that would allow SMTP-users to query SMTP-servers as to whether they
understood <content-type>.  Clearly, responses such as ``500 Command
unrecognized'' would have to be interpreted as indicating that the
recipient understood only vanilla text, but imagine a more structured
response, such as
	250 OK
to indicate that the given format was OK, or
	277 <list-of-alternate-formats>
to indicate that the recipient understood only the listed formats (which
would, at least implicitly, always include vanilla text format).  The
SMTP-user would then consult the list of transformations that it had at
its disposal.  (For any content-type that it was trying to deliver,
presumably it always has some method for transforming it to vanilla
text, but it may also have some method for transforming it to some other
format.  For instance, one can convert most ATK/BE2 formatting to troff
without much pain.)  The SMTP content-type negotiation can stop here;
the sender has enough information to decide on an acceptable
content-type transformation, and the mail, as it will be transmitted,
will simply be tagged with the given type.

I don't have an intimate understanding of other transport mechanisms,
but I can certainly imagine comparable things happening elsewhere.  For
example, UUCP could be told what content-types are acceptable for each
of its outgoing links (in the L.sys file or elsewhere).

The only remaining issue here is that before a delivery receiver
indicates that it is willing to receive a given format of message, it
has to be willing to engage in the same negotiation should it ever be
called on to transmit that message elsewhere.  That is, all the
delivery-agent senders have to perform this negotiation and translation,
and must have some transform-to-vanilla-text operation available, before
any delivery-agent receivers can announce that they will accept a given
special format.  Otherwise, a mail node could accept a formatted piece
of mail, then discover that it was in fact to be forwarded off-site, and
not discover that, in forwarding the message off-site, the content-type
needs to be reduced to vanilla-text.

---------

OK, so what does this have to do with the Encoding header discussion? 
Two points:

- Encoding versions need to go in the header, not in the body, so that
they can be used properly for negotiation between cooperating delivery
agents.  That is, it does me little good if you tell me that you
understand PostScript, so I send you my postscript message body, yet
when you get it you find that you can't understand the PostScript
version 41 that it's encoded in.

- The header information is important to delivery agents.  The encoding
information can't simply go in the envelope, though, since even after
delivery, message readers will have to know how to interpret the message
body.  It's convenient to have the stored-mail representation be the
same as the message-in-transit one (in the header rather than in the
envelope), since then you don't run into problems when a stored-mail
message is re-injected into the system (by a re-send operation, for
instance).

		Craig Everhart

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 13:00:07 EST
Received: from bells.cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa04326;
          7 Feb 90 12:54 EST
Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound 
          id aa02376; Wed, 7 Feb 90 17:53:57 +0000
To: David Robinson (Special Systems) (Special Systems) <DRB@relay.prime.com>
cc: header-people@mc.lcs.mit.edu, Rob Ullmann <Ariel@relay.prime.com>
Subject: Re: Proposed RFC on Encoding header field
Phone: +44-1-380-7294
In-reply-to: Your message of 05 Feb 90 17:29:09 -0500. 
             <9002051726.aa25156@mintaka.lcs.mit.edu>
Date: Wed, 07 Feb 90 17:51:47 +0000
Message-ID: <2215.634413107@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@cs.ucl.ac.uk>

Negative response coing up - sorry about this.

I feel strongly that this is an RFC we do not need.   RFC 822 was obsolete
when it was written - however it was needed to keep the services going.

Internet work on Multimedia messaging followed a different track, and lead
to much  excellent work.   

Now we have X.400, which in conjunction with RFC 1006 is a clear choice for
the Internet.     

If you try to extend 822 you will get problems:
   - agreeing a spec (there are several other approaches to this
   	already)
   - coding implementations
   - interworking
   - more X.400 gatewaying problems

Summary - don't hack 822, deploy X.400


Steve

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 14:58:16 EST
Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa10522;
          7 Feb 90 14:50 EST
Received: from Relay.Prime.COM by EN-C06.Prime.COM; 07 Feb 90 14:56:23 EST
Received: (from user DRB) by Relay.Prime.COM; 07 Feb 90 14:53:39 EST
To: header-people@mc.lcs.mit.edu
Cc: Rob Ullmann <Ariel@relay.prime.com>
From: David Robinson (Special Systems) <DRB@relay.prime.com>
Subject: Re: Proposed RFC on Encoding header field
Date: 07 Feb 90 14:53:40 EST
Message-ID:  <9002071450.aa10522@mintaka.lcs.mit.edu>

The proposed Encoding header field permits the mailing of multi-part,
multi-structured Internet messages.  There have been several header-people
postings suggesting that this functionality would be better provided within
the tranport protocol (SMTP) rather than in the message header.

RFCs 821 and 822 define a separation of tasks between the mail transport
service and higher level services.  Generally speaking, the mail transport
service is responsible for transporting the mail messages.  Higher level
agents are responsible for processing the actual mail messages.

The encoding functionality is used to describe the internal structure and
interpretation of the message body.  Under the current separation of
responsibilities, the appropriate place for this information is in the
header, not in the transport service.

Under the current separation of responsibilities, any processing of mail
messages into a more "intelligible form" is the responsibility of the
destination mail processing agent.

This current separation of responsibilities is simple and works well.

Use of the Encoding header field will not require changes to any mailers.
Mail reading programs can be modified to use Encoding ... or not.  The
user can always file the message and extract the information separately.

On the other hand, if the mail transport service is to make decisions about
what will be an "intelligible form" to the destination message processor,
then the entire transport network will require modification.

The problem is that "intelligible form" is not necessarily a problem that
*can* be solved.  And, it can't be solved theoretically, then specifying
that the transport service will solve it with some future protocol is just
voidware.  Which is prohibited!

What I mean to say is that PostScript version incompatibility is only a
drop in the ocean.  Taken to its logical end, one should be able to specify
that all messages whose "text" encoding type has the option "Deutch" to be
converted to English.  Thank you, no!  I'd rather have it in German and
find someone I trust to translate it for me.  Better still, I'd rather
agree with the sender that we'll both exchange mail in French which we both
understand (un peu!).

Which is the real solution.  We have to create common well-defined
encodings for those mail objects whose exchange is considered most useful.
If we really want to exchange PostScript, then we need to specify what
constitutes acceptible, generally exchangable PostScript.  (As Jon Postel
did for PostScript RFCs in RFC 1111.)

And, when a message arrives that the processing agent cannot be converted
to an "intelligible form", the decision to reject it should be made by the
processing agent, not the mail transport service.  After all, if the
processing agent is my mail reading program, I'll probably file the message
and see if I can find some other way to crack it.  Or discard it.  Either
way, I'd like the opportunity afforded by having the message in my mailbox
as it was sent by the sender, without transport service reformatting.

Cheers,
David

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 16:24:24 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa15286;
          7 Feb 90 16:16 EST
Date: Wed 7 Feb 90 16:12:37-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Proposed RFC on Encoding header field
To: DRB@relay.prime.com
Cc: header-people@mc.lcs.mit.edu
Message-ID: <634425157.700000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To:  <9002071450.aa10522@mintaka.lcs.mit.edu>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

David,
  I will continue to disagree, and, since I'm not likely to convince you or 
vice versa, let me define two points of difference for others to discuss:

(1) If the encoded information is *ever* going to contain eight-bit 
characters, that is a matter for the transport service by the part of the 
rules where our reasoning intersects.  The transport service has to be able 
to verify that the high bit will go through unmolested in order to function 
as a reliable transport.  The only way for the transport service to verify 
that within the general spirit and context of SMTP requires an envelope
modification, with the envelope itself remaining in seven-bit ASCII.

Now, if I thought this was worth pursuing, I would say "ok, assume that you 
are mostly right, then let's figure out what envelope information--or 
restrictions--are needed to ensure correct transport, and then go to work 
on putting the 'rest' in the header".  But that brings me to the second 
point:

(2) While I would not agree with the characterization of RFC822 as being 
"obsolete when written", SMTP is the wrong place to do this work at this 
point.  X.400 (1988) has the right framework, is expected to carry some of 
the types of information you are interested in, and is designed around a 
type-of-field/length-of-field/field organization.  You need the latter, you 
are specifying the latter, and it fits rather poorly on top of SMTP 
messages.  Not to say it can't be done, but why bother?
   john klensin
   Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 17:12:40 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa17612; 7 Feb 90 17:06 EST
Received: from nautsund.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA20922; Wed, 7 Feb 90 23:05:13 +0100
Date: Wed, 7 Feb 90 23:05:13 +0100
In-Reply-To: <2215.634413107@UK.AC.UCL.CS> "Steve Kille <S.Kille@cs.ucl.ac.uk>"
Message-Id: <90-038-0163@naggum.uu.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: Steve Kille <S.Kille@cs.ucl.ac.uk>
Cc: David Robinson (Special Systems) <DRB@relay.prime.com>, 
    Rob Ullmann <Ariel@relay.prime.com>, header-people@mc.lcs.mit.edu
Subject: Proposed RFC on Encoding header field

Steve,

While you may believe that X.400 is a good idea, you have a few
million users to convince, and they aren't yet.  I do not know X.400
in the detail I know you do, but I know that I would much rather go
for a simpler solution and expand on it, than trust some committee
somewhere to decide what I need.  Each user is different, and his
computer system will never be that envisioned "Open System" dream,
anyway.

Another thing which I dislike with X.400 is it's propensity for binary
transmission form, instead of the humanly-readable format of RFC
821/822.  You can't just extend ASN.1, either, as you can with RFC
822-headers.

There are many new ideas within the X.400 framework, and some of them
good, but the bigotry that goes with them is disgusting.  You X.400
people could at least credit the Internet for the basic ideas that you
exploit so merrily.  Look how easily the Internet has adopted many of
your acronyms, for instance.  (And don't tell me that they're better
ideas -- my point is that we're listening in order to solve problems,
and don't particularly care whose idea it was (except for crediting
them).)

Let's take an example.  I have been able to do a full RFC 821/822
implementation in less than 3 months from scratch.  I can "deploy" my
mailer at clients and interested parties for well under $100,
sometimes I just give it away.  If I spent 3 years on X.400, they'd
put out an incompatible new "standard" four years after the one I used
for spec, and I couldn't just give the thing away, and there would not
be enough people who could or would buy it to support my three years
of development, anyway.

My summary is quite opposite of yours: Don't wait for X.400, do it in
the Internet.

[Erik]

"The Internet has it *NOW*."  (paraphrased from a well-known vendor)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  7 Feb 90 23:28:46 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa04254; 7 Feb 90 23:20 EST
Received: from nautsund.uio.no by ifi.uio.no (5.61++/1.15) with SMTP 
	id AA23488; Thu, 8 Feb 90 05:20:10 +0100
Date: Thu, 8 Feb 90 05:20:10 +0100
Message-Id: <9002080420.AA01558@nautsund>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: KLENSIN@infoods.mit.edu
Cc: DRB@relay.prime.com, header-people@MC.lcs.mit.edu
In-Reply-To: <634425157.700000.KLENSIN@INFOODS.MIT.EDU>
Subject: Proposed RFC on Encoding header field

The debate over 8-bit vs 7-bit transport services prompts a question:
Why was RFC 821 restricted to 7-bit data paths in the first place?

For a while, my mailer regarded anything after the blank line that
separates header and body as "data", and did not attempt to treat it
as lines, and subsequently ate 8-bit data without hesitation.  I had
to stop doing that and break things into lines (max length 1000 chars)
and strip the 8th/most significant/parity bit for compliance reasons.

Now I wonder -- is there any need to retain this 7-bit restriction?
Or the line length restriction in the body?  It's supposed to be
left untouched by the MTA's, anyway.

I know that there are 7-bit restrictions outside the Internet.

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Feb 90 06:36:41 EST
Received: from bells.cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa18509;
          8 Feb 90 6:31 EST
Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound 
          id aa12892; Thu, 8 Feb 90 11:30:13 +0000
To: Erik Naggum <erik@naggum.uu.no>
cc: David Robinson (Special Systems) <DRB@relay.prime.com>, 
    Rob Ullmann <Ariel@relay.prime.com>, header-people@mc.lcs.mit.edu
Subject: Re: Proposed RFC on Encoding header field
Phone: +44-1-380-7294
In-reply-to: Your message of Wed, 07 Feb 90 23:05:13 +0100. 
             <90-038-0163@naggum.uu.no>
Date: Thu, 08 Feb 90 11:27:59 +0000
Message-ID: <1043.634476479@UK.AC.UCL.CS>
From: Steve Kille <S.Kille@cs.ucl.ac.uk>

Erik,

I'm going to try not to get cauhgt up in this!

 >From:  Erik Naggum <erik@no.uu.naggum>
 >To:    Steve Kille <S.Kille@uk.ac.ucl.cs>
 >Subject: Proposed RFC on Encoding header field
 >Date:  Wed, 7 Feb 90 23:05:13 +0100

 >
 >Steve,

 >While you may believe that X.400 is a good idea, you have a few
 >million users to convince, and they aren't yet. 
 
I don't think most users care about either 822 or X.400.  User requirements
are for a good UA and connectivity.   The protocol stuff should be buried.

 >in the detail I know you do, but I know that I would much rather go
 >for a simpler solution and expand on it,
 
Agreed, but I'd rather have one complex solution, as opposed to lots of
simple solutions, each addressing different needs.  Uniform service is a
major user requirement.  We want as few standards as possible.

 >Another thing which I dislike with X.400 is it's propensity for binary
 >transmission form, instead of the humanly-readable format of RFC
 >821/822.  You can't just extend ASN.1, either, as you can with RFC
 >822-headers.

I like text encoding, particularly for prototyping.  However, there are many
arguments both ways.  I believe that the general concesus is now moving
towards binary encoded protocols (e.g., quite a few recent Interet protocols
in ASN.1).  

I would suggest X.400 (88 not 84) is more extensible than 822.

 >There are many new ideas within the X.400 framework, and some of them
 >good, but the bigotry that goes with them is disgusting.  

Most technical groups have their bigots.  You might even find one or two on
the Internet. 
 
 >You X.400
 >people could at least credit the Internet for the basic ideas that you
 >exploit so merrily.  
 
I think that credit is given in many places.  However, I find it sad that
the Internet applications have not evolved in the way the underlying
technology has.


 >Let's take an example.  I have been able to do a full RFC 821/822
 >implementation in less than 3 months from scratch.  I can "deploy" my
 >mailer at clients and interested parties for well under $100,
 >sometimes I just give it away.  If I spent 3 years on X.400, they'd
 >put out an incompatible new "standard" four years after the one I used
 >for spec, and I couldn't just give the thing away, and there would not
 >be enough people who could or would buy it to support my three years
 >of development, anyway.

 >My summary is quite opposite of yours: Don't wait for X.400, do it in
 >the Internet.

I think that some aspects of X.400 are a bit trickier - in part becuase the
services offered are a good deal richer.  However, I think that implementing
a system is a remarkably small part of the effort involved in deploying a
SERVICE to hundreds of thousands of users.  Because the effort is large, the
strategic choice is critical.  Saving you a few months coding effort does
not enter into the picture.

 >[Erik]



Steve

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Feb 90 12:04:09 EST
Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa29243;
          8 Feb 90 11:56 EST
Received: from Relay.Prime.COM by EN-C06.Prime.COM; 08 Feb 90 12:02:15 EST
Received: (from user ARIEL) by Relay.Prime.COM; 08 Feb 90 11:59:33 EST
To: Header People <header-people@mc.lcs.mit.edu>
From: Robert Ullmann <Ariel@relay.prime.com>
Subject: on evolution in internet mail
Date: 08 Feb 90 11:59:33 EST
Message-ID:  <9002081156.aa29243@mintaka.lcs.mit.edu>

[a side note: while discussion of the relative merits of internet
 and X.400 is interesting, this group (header-people/comp.mail.headers)
 is about RFC-822-et-al headers: the usefulness of RFC 822 and the
 continued use and development of internet mail is (usually :-) taken
 as axiomatic in this forum.  -- Rob]

Steve,

[just to provide context :-]

> I think that credit is given in many places.  However, I find it sad that
> the Internet applications have not evolved in the way the underlying
> technology has.

The rate of evolution is directly proportional to the environmental
pressure present. Animals evolve faster when a changing environment
produces problems. When they have evolved to solve the problem, the
evolution stops.

Actually it slows, to an imperceptable rate. Further changes occur
only as "tweaks", or in non-linear response to periodic climate variation.

I believe that internet mail appeared to stop evolving precisely
because the problem of internetwork electronic mail was solved.

However, a few new environmental pressures have emerged. One of
them is the enthusiastic promotion of X.400 :-)

The response is as expected: new trial variations are introduced,
and may or may not be successful. The Encoding: proposal is one
of these.

Since you lament the perceived lack of evolution, I am startled
to see you immediately criticize it when it starts occuring at
a faster rate!

Best Regards,
Rob

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  8 Feb 90 19:46:35 EST
Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa19805;
          8 Feb 90 19:41 EST
Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA19057>; Thu, 8 Feb 90 16:39:17 -0800
Date: Thu, 8 Feb 90 16:41:30 PST
From: postel@venera.isi.edu
Posted-Date: Thu, 8 Feb 90 16:41:30 PST
Message-Id: <9002090041.AA01900@bel.isi.edu>
Received: by bel.isi.edu (4.1/4.0.3-4)
	id <AA01900>; Thu, 8 Feb 90 16:41:30 PST
To: erik@naggum.uu.no
Subject: Re: Proposed RFC on Encoding header field
Cc: DRB@relay.prime.com, KLENSIN@infoods.mit.edu, 
    header-people@mc.lcs.mit.edu


> Why was RFC 821 restricted to 7-bit data paths in the first place?

The were at the time many machines that stored ascii as 7-bit data internally.
If mail is routed through such machines the 8th bit is lost.
There still are a few in operation on the Internet.

--jon.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Feb 90 03:29:06 EST
Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa08138;
          9 Feb 90 3:25 EST
Received: from HBAPN1.Prime.COM by EN-C06.Prime.COM; 09 Feb 90 03:30:52 EST
Received: (from user MDELANY) by HBAPN1.Prime.COM; 09 Feb 90 19:24:57 +1100
From:    Mark Delany <MDelany@hbapn1.prime.com>
To:      David Robinson <DRB@relay.prime.com>, 
         Rob Ullmann <Ariel@relay.prime.com>
Cc:      Header-People@MC.lcs.mit.edu
MMDF-Warning:  Parse error in original version of preceding line at lcs.mit.edu
Subject: Proposed RFC on Encoding header field
Date: 09 Feb 90 19:24:58 +1100
Message-ID:  <9002090325.aa08138@mintaka.lcs.mit.edu>


Hi Dave & Rob:

A few comments on your proposed RFC.

[The group should note my "From:" line and be wary of possible bias.]


Trivial editorial comments.
---------------------------

The section on encoding types should probably provide a more precise
definition of uuencode as even this humble encoder now suffers from a
number of mutants/variants.

Perhaps it would also be of benefit to define a minimum subset that all
implementations should be encouraged to support?


Is it needed?
-------------

Leaving the larger question of whether this sort of effort is better
directed at x.400, to those more capable; the smaller question of
applicability to 821/822 remains.

Apart from the inherent functionality, the aspect I'd like to concentrate
on is that the proposal provides a frame-work for standardizing a set of
long-standing de facto practices.

When you think about it, encoded mails are probably the pre-eminent form
of file transfer between dis-similar or unknown target OS's. Good examples
are the obviously popular uuencode, atob and shar forms of encoding.
(I've taken some license in this statement, but I'm sure you get the
drift.)

In spite of such popular usage (and I pass no judgement on this, but to
say that it's surely going to continue), aren't the current methods one
enormous pain?

Try extracting the useful data from a shar file on a non-UNIX system, or
uudecode a file for that matter!  The worst case of course is a
compressed, uuencoded, tar file that some of the popular archivers send.
Interoperable it's not.  (BTW, top marks to HP's shar, it ships the source
of uudecode with the encoded file!  An admirable approach to the current
mess, but probably impractical for something like Postscript :-).

Now there's no reason why these need to be inherently painful, and it's
certainly no reflection on the original creators - given the circumstances
they did a good job - it's just that in the absence of a standard, people
tended to grab the nearest tool to hand, which invariably turns out to be
OS specific.

So if you take the view that 821/822 will be alive for years to come, and
you accept that encoded file transfers are a common user, then it's
probably not a bad idea to specify a vehicle that helps move such
prevalent usage away from it's OS specific origins to something more
generally applicable.


Returning to the earlier suggestion of a minimum subset.  To attract this
type of usage to the fold, I imagine that the subset would have to include
satisfactory replacements for uuecode and tar styled encodings.  The
former is well covered, but the latter may best be satisfied by some form
of the Usenix/IEEE POSIX tar.


An anecdote addendum for the discussion group:
----------------------------------------------

I've been in a position to use the implementation mentioned by the
authors, and I can atest to it's usefulness. While it's nice to be able to
exactly pick out the relevant portions, the important point is that it
eliminates the error-prone cut/paste/decode/process methods currently in
wide-spread use.

Whether this is an appropriate place to provide the functionality is an
open question; however, from my point of view there is little doubt as to
it's usefulness.


Mark.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Feb 90 18:37:44 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07876;
          9 Feb 90 18:30 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01695; Fri, 9 Feb 90 16:30: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: 9 Feb 90 20:23:41 GMT
From: Rouben Rostamian <cs.utexas.edu!samsung!aplcen!haven!umbc3!math9.math.umbc.edu!rouben@yale-zoo.arpa>
Organization: University of Maryland, Baltimore County
Subject: How to set a "Reply-To: " filed in the mail header?
Message-Id: <2773@umbc3.UMBC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


I use ucb mail in ULTRIX.  I wonder if there is an option to add a header line
of the sort:

"Reply-To: a_preferred_return_address"

in some of the mail that I send out from various machines, just like it's
done in usenet postings.  My man page on mail is silent about this.

Any hints will be appreciated.

--Rouben Rostamian

P.S.: I do know about .forward files, but nevertheless I would prefer
      specifying a Reply-To header field.

--
      
Rouben Rostamian                               Telephone: (301) 455-2458
Department of Mathematics and Statistics       e-mail:
University of Maryland Baltimore County        rostamian@umbc.bitnet
Baltimore, MD 21228                            rostamian@umbc3.umbc.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 00:53:26 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24355;
          20 Feb 90 0:50 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11337; Mon, 19 Feb 90 23:32:22 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: 20 Feb 90 03:21:12 GMT
From: Robert Stephens <sgi!roberts%nimrod.wpd.sgi.com@bloom-beacon.mit.edu>
Organization: Silicon Graphics, Inc., Mountain View, CA
Subject: Re: How to set a "Reply-To: " filed in the mail header?
Message-Id: <51174@sgi.sgi.com>
References: <2773@umbc3.UMBC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
> 
> I use ucb mail in ULTRIX.  I wonder if there is an option to add a header line
> of the sort:
> 
> "Reply-To: a_preferred_return_address"

Not that I know of.  I just had to add such an option to our version of ucb
Mail in IRIX.  I don't think you can do it at all with standard ucb Mail.

	Robert Stephens

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 02:47:57 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27876;
          20 Feb 90 2:45 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA19401; Tue, 20 Feb 90 02:15: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: 20 Feb 90 07:00:31 GMT
From: Dan Heller <turnpike!argv@sun.com>
Subject: Re: How to set a "Reply-To: " filed in the mail header?
Message-Id: <132047@sun.Eng.Sun.COM>
References: <2773@umbc3.UMBC.EDU>, <51174@sgi.sgi.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <51174@sgi.sgi.com> roberts@nimrod.wpd.sgi.com (Robert Stephens) writes:
> In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
> > I use ucb mail in ULTRIX.  I wonder if there is an option to add a header line
> > of the sort:
> > "Reply-To: a_preferred_return_address"
> Not that I know of.  I just had to add such an option to our version of ucb
> Mail in IRIX.  I don't think you can do it at all with standard ucb Mail.

In Mush, just type:
    my_hdr Reply-To: roberts
and there you go.  Note: Mush is backwards compatible with ucbMail,
so there's no learning curve involved in getting up to speed with
Mush.  However, Mush is as powerful as the other mail packages, if
not more so, so it might be worth your while to ftp it than to
continue hacking your ucbMail.  And while I'm pushing Mush :-),
it's portable to virtually all versions of UNIX (no problems yet)
and there is a DOS version as well.

ftp info: ucbvax:pub/mailers/mush-7.0.tar.Z
those who want the DOS version mail to lmoc@lena.uucp (via uunet).
Mush is currently at version 7.0.4.  7.1 will be out shortly --
this has significant improvements to the sunview mode.
dan
-----------------------------------------------------------
		    O'Reilly && Associates
		argv@sun.com / argv@ora.com
	   632 Petaluma Ave, Sebastopol, CA 95472 
     800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 12:29:24 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18167;
          20 Feb 90 12:25 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA15386; Tue, 20 Feb 90 11:56: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: 20 Feb 90 16:51:37 GMT
From: "Barton E. Schaefer" <mintaka!ogicse!schaefer@bloom-beacon.mit.edu>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Subject: Re: How to set a "Reply-To: " filed in the mail header?
Message-Id: <7459@ogicse.ogc.edu>
References: <2773@umbc3.UMBC.EDU>, <51174@sgi.sgi.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <51174@sgi.sgi.com> roberts@nimrod.wpd.sgi.com (Robert Stephens) writes:
} In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
} > 
} > I use ucb mail in ULTRIX.  I wonder if there is an option to add
} > 
} > "Reply-To: a_preferred_return_address"
} 
} Not that I know of.  I just had to add such an option to our version of ucb
} Mail in IRIX.  I don't think you can do it at all with standard ucb Mail.

You can't do it "right", but you can do it:

----------------------------------------
#! /bin/sh
# "mail" front-end for Reply-To: headers
echo -n "Subject: "
read subject
# Note imbedded return in the "" text
mail -s "$subject
Reply-To: a_preferred_return_address" $*
----------------------------------------

I won't go to the work of figuring out how to test for "set ask" before
prompting for the subject, nor how to parse a -s option to the script,
but it can be done.

You still ought to get Mush. ;-)

Just the other mush hacker,
-- 
Bart Schaefer          "February.  The hangnail on the big toe of the year."
                                                                    -- Duffy

schaefer@cse.ogi.edu (used to be cse.ogc.edu)

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 16:42:04 EST
Received: from inet.att.com by mintaka.lcs.mit.edu id aa29086;
          20 Feb 90 16:28 EST
Received: by inet; Tue Feb 20 14:27:10 1990
From: smb@ulysses.att.com
To: header-people@MC.lcs.mit.edu
Subject: Re: How to set a "Reply-To: " filed in the mail header? 
Date: Tue, 20 Feb 90 14:27:00 EST
Original-From: smb@toucan
Message-ID:  <9002201628.aa29086@mintaka.lcs.mit.edu>

In '81 or thereabouts, when I first wrote pathalias, I hacked ucbmail
to let you specify arbitrary headers.  You could create a variable
to specify your header set; each element in the comma-separated list
specified another variable to include in the header.  But that code
died with 4.1bsd, as far as I know.

		--Steve Bellovin

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 20:42:05 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29928;
          21 Feb 90 20:38 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28937; Wed, 21 Feb 90 19:14: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: 21 Feb 90 12:54:34 GMT
From: Jan Stevens <mcsun!hp4nl!phigate!philtis!jan@uunet.uu.net>
Organization: Philips CFT
Subject: Re: How to set a "Reply-To: " filed in the mail header?
Message-Id: <970@philtis.cft.philips.nl>
References: <2773@umbc3.UMBC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


Most mailers use a fixed, predefined header. To change the header you
must use a mailer which is capable of adding lines to the header. Elm is
such a type of mailer. What the layout of the header concerns :
  It ends with an empty line.
  It must have a To and From line.

Jan Stevens, Unix Support Engineer
Philips CFT, the Netherlands
e-mail: jan@philtis.cft.philips.nl

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 17:15:53 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09653;
          24 Feb 90 17:05 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07095; Sat, 24 Feb 90 15:53: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: 24 Feb 90 20:50:27 GMT
From: Matt Madison <mintaka!ogicse!uwm.edu!rpi!MADISON%vms.ecs.rpi.edu@bloom-beacon.mit.edu>
Organization: Rensselaer Polytechnic Institute, Troy, NY
Subject: Mild flame about (some) UNIX mailers
Message-Id: <00932CA6.30EE8E00@vms.ecs.rpi.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Having just finished writing some new E-mail software for our VMS system,
I have spent several hours studying both RFC 821 and RFC 822 to ensure that
this software complies with these standards.  After all, these standards
are used by all the systems on the Internet, right?

As soon as this software went into production use, we started experiencing
problems exchanging mail with (you guessed it) some UNIX systems on our
network (and elsewhere).  There have been three problems so far, and trivial
though they may be, they have been rather aggravating.

Problem 1.  In implementing a gateway between VMS MAIL coming in over
DECnet and SMTP, my software generates return addresses of the form
<"node::user"@domain>.  The quotation marks are necessary because colons
are considered "special" by RFC 822.  This immediately started to cause
problems because (I'm told) sendmail by default strips quotation marks
from the user portion of an address.  So when UNIX users tried to reply
to messages sent from my system, the replies would be rejected by my
SMTP server becuase <node::user@domain> is not valid RFC 822.

Problem 2.  RFC 821 states that all lines sent should be terminated with a
carriage return/line feed sequence.  It turns out that some UNIX-based
SMTP implementations do not adhere to this and by default terminate lines
simply with line feeds.  Now, I can understand this behaviour in older UNIX
implementations.  But we're talking recent versions of ULTRIX and SGI's
UNIX (whatever it's called)!

Problem 3.  Some UNIX mail systems appear to generate return addresses of
the form

       real name <user@domain>

Where "real name" is simply pulled from the passwd file (or wherever this
information is obtained on UNIX systems), without verifying that it can be
left unquoted and still comply with RFC 822.  This means that anyone who has
included their middle initial with their name, with a dot, will have a
return address that violates the standard (dots are not allowed in the
leading phrase before the address).  Parsing 822-compliant addresses is
complicated enough without having to deal with crap like this.

What really burns me up about this, is that it's considered _my_ fault that
this stuff doesn't work!  Argh.
--
Matthew Madison, Systems Programmer  | "First they built the world's standard.
Engineering Computing Services       |  Then they added standards no one else
Rensselaer Polytechnic Institute     |  had."  - an ad for SCO Xenix
Troy, New York 12180-3590 USA        |
   madison@vms.ecs.rpi.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 01:00:39 EST
Received: from RUDY.FAC.CS.CMU.EDU by mintaka.lcs.mit.edu id aa16309;
          25 Feb 90 0:55 EST
Received: from rudy.fac.cs.cmu.edu by RUDY.FAC.CS.CMU.EDU id aa01909;
          25 Feb 90 0:54:54 EST
To: Matt Madison <madison@vms.ecs.rpi.edu>
cc: header-people@mc.lcs.mit.edu
Subject: Re: Mild flame about (some) UNIX mailers 
In-reply-to: <00932CA6.30EE8E00@vms.ecs.rpi.edu> 
Date: Sun, 25 Feb 90 00:54:19 EST
From: Rudy.Nedved@rudy.fac.cs.cmu.edu
Message-ID:  <9002250055.aa16309@mintaka.lcs.mit.edu>


Matt,

You are not alone in you frustrations but after you have hacked mail
systems you understand that mail systems are an example of extreme
software politics, policy and peopleness and you live with it.

This is why you hear comments like "Be liberal in what you accept and
conservative in what you generate" when referring to mail protocol
implementations. You understand why.

Rudy Nedved
(old mail wizard for TOPS-10/20, Unix, VMS, ??)
Operations Manager
School of Computer Science
Carnegie Mellon University

P.S. In the spirit of progress, why are you using source-routed addresses
     embedded in a mail address. Why don't you register you DECnet node
     names in a domain name server and have incoming mail from DECnet nodes
     translated from DECnet names to internet domain name?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 03:34:11 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22275;
          25 Feb 90 3:28 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11216; Sun, 25 Feb 90 02:42: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: 25 Feb 90 04:31:23 GMT
From: crash!simpact!jeh@nosc.mil
Organization: Simpact Associates, San Diego CA
Subject: Re: Mild flame about (some) UNIX mailers
Message-Id: <985.25e6ef1b@simpact.com>
References: <00932CA6.30EE8E00@vms.ecs.rpi.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <00932CA6.30EE8E00@vms.ecs.rpi.edu>, madison@vms.ecs.rpi.edu 
(Matt Madison) writes:
> Problem 1.  In implementing a gateway between VMS MAIL coming in over
> DECnet and SMTP, my software generates return addresses of the form
> <"node::user"@domain>.  The quotation marks are necessary because colons
> are considered "special" by RFC 822.  This immediately started to cause
> problems because (I'm told) sendmail by default strips quotation marks
> from the user portion of an address.  So when UNIX users tried to reply
> to messages sent from my system, the replies would be rejected by my
> SMTP server becuase <node::user@domain> is not valid RFC 822.

I suggest that you do what we (the DECUS uucp folks) do for our
"user base":  We have an address rewrite mechanism that, for From addresses
on outbound mail, can be set up to rewrite

	node::user

to

	user@node.rest_of_domain

eg, stuff coming from SKYVAX::user here ('here' is simpact.com) ends up
coming from user@skyvax.simpact.com.  This is in concert with most domain
naming schemes anyway, where the second-level domain ('simpact' in our 
case) specifies which company within .com, and the third-level specifies
which machine within .simpact.com .

Our rewrite rules can get fancier; for example, if there may be overlaps
between DECnet nodename space and some other internal network's namespace 
to which you must also delivery mail, you can choose to rewrite to something 
like

	user@node.decnet.simpact.com

or even 

	user%node@decnet.simpact.com

(but a lot of other mailers don't do what you want with %'s)

And, of course, for To: addresses on inbound mail, we can look for things
that match whichever of the above patterns the user wants, and rewrite
to node::user for inbound delivery.  

This works for us (simpact), even in a horribly mixed decnet/tcp-ip/uucp 
environment, and we don't even use PMDF (yet).  

> ...[descriptions of other hassles deleted]

> What really burns me up about this, is that it's considered _my_ fault that
> this stuff doesn't work!  Argh.

Being chief recipient for e-mail and phone calls regarding DECUS uucp, 
I know EXACTLY what you mean.  (And thanks to all of you who have communicated
thanks to us for the package; you are keeping us going!)  The above commentary 
is in no way meant to suggest that mailers Out There ought NOT to take 

	"anything_at_all"@domain

and pass the stuff in quotes intact.  But suggesting that they do so is
probably tilting at windmills.  

(p.s.:  DECUS uucp is uucp for VMS with full mail and netnews support.  It 
is essentially free.  Send mail to me for info.)

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 20:39:01 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28048;
          25 Feb 90 20:28 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA17906; Sun, 25 Feb 90 18:34: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: 25 Feb 90 23:27:14 GMT
From: Eliot <snorkelwacker!usc!cs.utexas.edu!uwm.edu!bionet!turbo.bio.net!lear@bloom-beacon.mit.edu>
Organization: GenBank Computing Resource for Mol. Biology
Subject: Re: Mild flame about (some) UNIX mailers
Message-Id: <Feb.25.15.27.14.1990.5767@turbo.bio.net>
References: <00932CA6.30EE8E00@vms.ecs.rpi.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


[From RFC1123]

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:


                "Be liberal in what you accept, and
                 conservative in what you send"

UNIX doesn't let you forget that.
-- 
Eliot Lear
[lear@TURBO.BIO.NET]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 07:36:16 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22635;
          26 Feb 90 7:28 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA22843; Mon, 26 Feb 90 06:46:03 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 Feb 90 11:39:44 GMT
From: Ned Freed <zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!csvned@think.com>
Organization: Harvey Mudd College, Claremont, CA 91711
Subject: Re: Mild flame about (some) UNIX mailers
Message-Id: <4674@jarthur.Claremont.EDU>
References: <00932CA6.30EE8E00@vms.ecs.rpi.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Welcome to the real world of mailers! As the primary author of PMDF, a very
popular mail system for VMS machines, I've run into all the problems you
cite on numerous occasions. You've only just started -- there are lots
more waiting for you.

Now some advice. You'll never get mailers to accept "node::user"@domainhost
format. It is a hopeless task. So I'd recommend using something of the form
user%node@domainhost if possible. This even generalizes to multiple nodes
if you need them. Note that this does not solve the entire problem of
how to handle all the wierd stuff VMS MAIL likes to use, but it will get
you started at least.

The problem of mailers inserting some bogosity into the personal name
field in an address is well-known too. My advice on this one is to simply
ignore it. You should not be looking at header lines for delivery purposes
anyway. The envelope should suffice, and personal name fields are flagrantly
illegal in an envelope (PMDF accepts them but strips them for reasons that
I won't get into in this forum). You can either insert a sanitized header
line in place of the incorrect line or just pass it on unchanged and let
the next mailer downstream worry about it. If it rejects it your hands are
clean -- that's a battle between the offending mailer and the picky mailer!

A final note. All the standards say that a blank address is completely
legal in various places, e.g. an SMTP MAIL FROM: line. Watch out for those.
Several UNIX mailers (you know who you are) go into infinite loops when they
get one of these. And if you think you've had trouble with users whose mail
got lost in the past, you've got a new treat when you deal with a sysmgr
whose load average was at 50 before he wiped out all those looping mail
processes. Not a pretty sight.

Good luck on your project. I saw an announcement of your system on the
JNET-L list, I believe. Sounds good.

				Ned Freed
				ned@ymir.claremont.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 10:02:42 EST
Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa28569;
          26 Feb 90 9:56 EST
Received: by decpa.pa.dec.com; id AA06273; Mon, 26 Feb 90 06:56:40 -0800
Received: by dcrocker.pa.dec.com; id AA12692; Mon, 26 Feb 90 06:54:37 PST
Message-Id: <9002261454.AA12692@dcrocker.pa.dec.com>
To: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!csvned@think.com
Cc: header-people@mc.lcs.mit.edu
Subject: Re: Mild flame about (some) UNIX mailers 
In-Reply-To: Your message of 26 Feb 90 11:39:44 +0000.
             <4674@jarthur.Claremont.EDU> 
Date: Mon, 26 Feb 90 06:54:36 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Just to add to the fun, an alternate to the format that Ned suggests is:

user@node.domain

but this requires you to set up the domain servers which handle domain to
MX all references to *.domain to the appropriate gateway.  Actually,
this is not onerous overhead and results in Internet email addresses
that look quite natural.  The '%' usage (kindly called the percent hack)
was developed originally to overcome the lack of any mechanism such
as MX records, around the spring of 79.  Most of the world has advanced,
so it would be nice to take advantage of it.

On the other hand, the percent hack is simple and always works.

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 11:22:03 EST
Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa02712;
          26 Feb 90 11:13 EST
Received: by decpa.pa.dec.com; id AA10514; Mon, 26 Feb 90 08:13:46 -0800
Received: by dcrocker.pa.dec.com; id AA12820; Mon, 26 Feb 90 08:11:35 PST
Message-Id: <9002261611.AA12820@dcrocker.pa.dec.com>
To: header-people@mc.lcs.mit.edu
Subject: Re: Mile flame about (some) Unix mailers
Date: Mon, 26 Feb 90 08:11:32 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Well, this certainly is interesting...


------- Forwarded Message

Return-Path: Postmaster@rutgers.edu
Received: by jove.pa.dec.com; id AA20020; Mon, 26 Feb 90 07:34:38 -0800
Received: by decpa.pa.dec.com; id AA08268; Mon, 26 Feb 90 07:34:33 -0800
Received: from uwvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP 
	id AB17668; Mon, 26 Feb 90 10:34:05 EST
Date: Mon, 26 Feb 90 10:34:05 EST
From: Postmaster@rutgers.edu (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <9002261534.AB17668@rutgers.edu>
To: dcrocker

   ----- Transcript of session follows -----
554 ames!indri!uakari!brutus!jarthur!csvned... Mail loop detected
554 sendall: too many hops (17 max)

   ----- Unsent message follows -----
Received: from uwvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP 
	id AA17668; Mon, 26 Feb 90 10:34:05 EST
Received: from uakari.primate.wisc.edu by spool.cs.wisc.edu; Mon, 26 Feb 90 09:31:26 -0600
Received: from indri.primate.wisc.edu by uakari.primate.wisc.edu;
          id AA17370; 5.61/41.6; Mon, 26 Feb 90 09:31:11 -0600
Received: from ames.arc.nasa.gov by indri.primate.wisc.edu;
          id AA06486; 5.61/37.11; Mon, 26 Feb 90 09:31:05 -0600
Received: from iuvax.cs.indiana.edu by ames.arc.nasa.gov (5.61/1.2); Mon, 26 Feb 90 07:30:51 -0800
Received: from uiucdcs!brutus!nsl.dec.com by iuvax.cs.indiana.edu with UUCP
	(5.61+/1.4jsm) id AA02194; Mon, 26 Feb 90 10:30:48 -0500
Received: from brutus.cs.uiuc.edu by a.cs.uiuc.edu with SMTP
	(5.61+/IDA-1.2.8) id AA19452; Mon, 26 Feb 90 09:00:50 -0600
Received: from Choices.cs.uiuc.edu (babym.cs.uiuc.edu) by brutus.cs.uiuc.edu (4.0/1.2nn-UIUC-Systems-Research-Group)
	id AA07063; Mon, 26 Feb 90 08:59:27 CST
Received: from zaphod.mps.ohio-state.edu by Choices.cs.uiuc.edu (4.0/1.2nn-UIUC-Systems-Research-Group)
	id AA16516; Mon, 26 Feb 90 09:02:38 CST
Received: from decpa.pa.dec.com by zaphod.mps.ohio-state.edu (4.1/1.890401)
	id AA13621; Mon, 26 Feb 90 10:00:30 EST
Received: by decpa.pa.dec.com; id AA06410; Mon, 26 Feb 90 06:59:26 -0800
Received: by nsl.pa.dec.com; id AA04542; Mon, 26 Feb 90 06:56:48 -0800
Received: by decpa.pa.dec.com; id AA06318; Mon, 26 Feb 90 06:57:21 -0800
Received: from Fafnir.Think.COM by Think.COM; Mon, 26 Feb 90 09:57:12 -0500
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 26 Feb 90 09:55:56 EST
Return-Path: <dcrocker@nsl.dec.com>
Received: from decpa.pa.dec.com by Think.COM; Mon, 26 Feb 90 09:56:56 -0500
Received: by decpa.pa.dec.com; id AA06273; Mon, 26 Feb 90 06:56:40 -0800
Received: by dcrocker.pa.dec.com; id AA12692; Mon, 26 Feb 90 06:54:37 PST
Message-Id: <9002261454.AA12692@dcrocker.pa.dec.com>
To: brutus!csvned@uakari.primate.wisc.edu
Cc: header-people@mc.lcs.mit.edu
Subject: Re: Mild flame about (some) UNIX mailers 
In-Reply-To: Your message of 26 Feb 90 11:39:44 +0000.
             <4674@jarthur.Claremont.EDU> 
Date: Mon, 26 Feb 90 06:54:36 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Just to add to the fun, an alternate to the format that Ned suggests is:
...

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 16:50:36 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa18994;
          26 Feb 90 16:45 EST
Date: Mon 26 Feb 90 16:40:52-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Mild flame about (some) UNIX mailers 
To: dcrocker@nsl.dec.com
Cc: header-people@mc.lcs.mit.edu
Message-ID: <636068452.670000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <9002261454.AA12692@dcrocker.pa.dec.com>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>On the other hand, the percent hack is simple and always works.
    Actually, the percent hack "always" works iff the mail servers at the 
gateway understand how to make the translation to an address on your 
network.  Some do, some don't, although all can be designed to do so.  The 
user@node.domain approach avoids this problem, as well as use of the hack-
domain.
    --john
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 17:38:29 EST
Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa21642;
          26 Feb 90 17:35 EST
Received: by decpa.pa.dec.com; id AA05831; Mon, 26 Feb 90 14:35:59 -0800
Received: by dcrocker.pa.dec.com; id AA13458; Mon, 26 Feb 90 14:33:53 PST
Message-Id: <9002262233.AA13458@dcrocker.pa.dec.com>
To: John C Klensin <KLENSIN@infoods.mit.edu>
Cc: header-people@mc.lcs.mit.edu
Subject: Re: Mild flame about (some) UNIX mailers 
In-Reply-To: Your message of Mon, 26 Feb 90 16:40:52 -0500.
             <636068452.670000.KLENSIN@INFOODS.MIT.EDU> 
Date: Mon, 26 Feb 90 14:33:51 PST
From: Dave Crocker <dcrocker@nsl.dec.com>

Experimental psychologists sometimes are accused of doing an experiment
that shows a difference which is significant, but without meaning.  That is,
the statistics point to a discernible difference, but there is no
real impact.

To carry the example into current reality:  anything which involves a relay
requires its consent.  user@node.domain requires that the machine which is
MX's for *.domain be a consenting cpu, the same as the machine referenced
by domain, in user%node@domain.  Certainly the syntax and some of the
underlying mechanisms (e.g., support for MX records) is different.

The point behind my implying greater safety in the %-hack is that it has
less dependence upon outside mechanism.  In particular, use of the domain
name system and MX records works less often than we all would wish.

Dave

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  2 Mar 90 08:36:11 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02625;
          2 Mar 90 8:30 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA10206; Fri, 2 Mar 90 07:43: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: 2 Mar 90 11:18:25 GMT
From: Jerry Peek <snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan!jdpeek@bloom-beacon.mit.edu>
Organization: Syracuse University, Syracuse, NY
Subject: Re: How to set a "Reply-To: " filed in the mail header?
Message-Id: <2323@rodan.acs.syr.edu>
References: <2773@umbc3.UMBC.EDU>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
> I use ucb mail in ULTRIX.  I wonder if there is an option to add a header line
> of the sort:
> 
> "Reply-To: a_preferred_return_address"

I'm two weeks behind on my news :-(, so sorry if I missed someone else's
posting (expired by now) with this answer.  MH lets you customize
the header completely.  You make a blank draft template file called
"components".  It could look like this:

	To:
	Reply-to: a_preferred_return_address
	cc:
	Subject:
	-------

Then, when you send a message, you'll be prompted for the empty components.
The Reply-to: component in this file will be used, as is, automatically.

--Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY
  jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET        +1 315 443-3995
-- 

--Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY
  jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET        +1 315 443-3995

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  2 Mar 90 14:35:18 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19377;
          2 Mar 90 14:29 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00414; Fri, 2 Mar 90 14:11:22 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 90 18:06:27 GMT
From: Jef Poskanzer <snorkelwacker!apple!well!jef@bloom-beacon.mit.edu>
Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal
Subject: Re: Mild flame about (some) UNIX mailers
Message-Id: <16483@well.sf.ca.us>
References: <Feb.25.15.27.14.1990.5767@turbo.bio.net>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

}                "Be liberal in what you accept, and
}                 conservative in what you send"

In my experience, the typical postmaster who quotes this aphorism wants
others to abide by the first part, so that he doesn't have to abide by
the second.  Not Eliot, of course.  But every other time this bullshit
has appeared, that has been what was actually going on.
---
Jef

  Jef Poskanzer  jef@well.sf.ca.us  {ucbvax, apple, hplabs}!well!jef
                      Now how much would you pay?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  2 Mar 90 18:32:28 EST
Received: from akbar.cac.washington.edu by mintaka.lcs.mit.edu id aa00216;
          2 Mar 90 18:14 EST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
	(5.61/UW-NDC Revision: 2.11 ) id AA27641; Fri, 2 Mar 90 15:14:35 -0800
Date: Fri, 2 Mar 1990 15:06:46 PST
From: Mark Crispin <MRC@cac.washington.edu>
Sender: mrc@tomobiki-cho.cac.washington.edu
Subject: Re: Mild flame about (some) UNIX mailers
To: Jef Poskanzer <jef@well.sf.ca.us>
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <16483@well.sf.ca.us>
Message-Id: <MailManager.636419206.2781.mrc@Tomobiki-Cho.CAC.Washington.EDU>

In <16483@well.sf.ca.us>, Jef Poskanzer writes:
>}                "Be liberal in what you accept, and
>}                 conservative in what you send"
>
>In my experience, the typical postmaster who quotes this aphorism wants
>others to abide by the first part, so that he doesn't have to abide by
>the second.

It's worse than that.  They also expect others to abide by the second part, so
that they don't have to abide by the first.  :-(

-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  2 Mar 90 21:58:49 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12256;
          2 Mar 90 21:55 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA16013; Fri, 2 Mar 90 21:45: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 Mar 90 20:04:18 GMT
From: Peter da Silva <bu.edu!snorkelwacker!tut.cis.ohio-state.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!texbell!ficc!peter@bloom-beacon.mit.edu>
Organization: Xenix Support, FICC
Subject: Re: Mild flame about (some) UNIX mailers
Message-Id: <JM:1UZxds13@ficc.uu.net>
References: <Feb.25.15.27.14.1990.5767@turbo.bio.net>, <16483@well.sf.ca.us>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

> }                "Be liberal in what you accept, and
> }                 conservative in what you send"

> In my experience, the typical postmaster who quotes this aphorism wants
> others to abide by the first part, so that he doesn't have to abide by
> the second.  Not Eliot, of course.  But every other time this bullshit
> has appeared, that has been what was actually going on.

One does not always have the option of abiding by the second, unless you
use the newfangled meaning of the word "conservative" (i.e., reactionary).

Those of us at sites with proprietary mail software that can't economically
be replaced are kind of stuck. Even if we generate standard UUCP version
2 headers (which conform to RFC822 via a grandfather clause, according
to people I've spoken to) we're out of luck for sites running smail 3.0.
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  3 Mar 90 15:31:20 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa18910;
          3 Mar 90 15:28 EST
Date: Sat 3 Mar 90 15:22:37-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Mild flame about (some) UNIX mailers
To: header-people@mc.lcs.mit.edu
Message-ID: <636495757.200000.KLENSIN@INFOODS.MIT.EDU>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

> Even if we generate standard UUCP version
>2 headers (which conform to RFC822 via a grandfather clause, according
>to people I've spoken to) ...
   Peter,
     I don't know whom you have spoken to, but there are no grandfather 
clauses in RFC822, and RFC1123 (Host Requirements) clarifies and stresses 
several things that should have already been clear from any careful and 
reasonable reading of RFC822.
     Your note implies to me that there is more merit in blaming, and 
pressuring, vendors of email (etc.) software packages than it is in 
blaming and pressuring those who run the package, and, having been forced 
to run some things I was very unhappy with, I concur.  On the other hand, 
it is typically the case that vendors are more easily "persuaded" by their 
current and potential users than by "the community" and -- especially from 
your standpoint -- the most attractive way for the rest of us to create
that situation often involves yelling at the people who put the incorrect
headers (or whatever) out.   The only alternative the Internet community 
has is to strenuously encourage gateways to stop passing mail traffic that 
does not conform to the standards, and that would cut you off entirely 
until your vendor came into line.
   john klensin
   Klensin@INFOODS.MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  4 Mar 90 00:59:58 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08824;
          4 Mar 90 0:57 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA29984; Sun, 4 Mar 90 00:34: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: 2 Mar 90 05:28:12 GMT
From: ccavax!tinkelman@uunet.uu.net
Organization: Cambridge Computer Associates, Inc.
Subject: Replacing colons with periods in To-addresses
Message-Id: <18538.25edbe1d@ccavax.camb.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I have a question about a sendmail.cf rule.  But first the background.

Recently I received mail from a friend at Digital who was using a new
mail system.  It arrived with an illegal return address, albeit one that
I, as a human, could understand.  It was 

	<uunet!decwrl!koala.enet!mrgate::add::koala::x4::graff>

meaning make uucp hops to uunet and decwrl, then DECnet mail-ll to koala,
then through mrgate into the message router, then to node koala (aren't we
already here?), to Message Router mailbox x4, to user graff.  (Simple, huh?)

Despite the fact I was 99% certain that those colons would cause problems
somewhere, I decided to try replying, just to see what would happen.  What
happened was a rejection from decwrl:

>    ----- Transcript of session follows -----
> 550 <koala::mrgate..add..koala..x4..graff%decwrl.dec.com>... User unknown

Surprise!  uunet accepted the address with those colons, passed it on to
decwrl, but changed the colons into periods.  It really was uunet that had
made the changes.  In reply to my inquiry, the postmaster at uunet said that
their sendmail.cf has scattered throughout it lines like

	# map colons to dots everywhere.....
	R$*:$*                  $1.$2                    map colons to dots

I'm not a sendmail.cf expert (and I certainly don't have uunet's entire
sendmail.cf in front of me to look at).  I'd assume that uunet knows what 
they're doing.  Could someone please explain it?  When would the above rule
make sense?
--
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
bob@ccavax.camb.com  or ...!uunet!ccavax!bob      
-- 
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
bob@ccavax.camb.com  or ...!uunet!ccavax!bob      

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Mar 90 20:07:57 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21371;
          5 Mar 90 19:59 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04893; Mon, 5 Mar 90 19:29:17 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 Mar 90 23:42:23 GMT
From: John Gilmore <hoptoad!gnu@ucbvax.berkeley.edu>
Organization: Cygnus Support, Palo Alto
Subject: Re: "X.400" articles with >To:, Message-Version:, etc
Message-Id: <10613@hoptoad.uucp>
References: <EMV.90Mar3024737@duby.math.lsa.umich.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

emv@math.lsa.umich.edu (Edward Vielmetti) wrote:
> My B News 2.11.14 croaks on articles with articles that look like
> this.  Note the
> 	>To:
> and	>From:
> headers. 
> 
> I'm converting to C News soon, not sure if this is a bug in B News,
> a bug in something else, or just a problem with bit.*.

(The article is below...you won't believe it.)

This is a bug in the email software that gatewayed this message into
the Internet from some X.400 based mail system.  In particular, I have
seen this cruft on EVERY message that goes through the "attmail"
service, even if it is just relaying from a uucp site to another uucp site.
When the email happens to gateway into a newsgroup, netnews barfs on it.

I complained to attmail but they said "Every one of those headers has
a purpose, you are just full of shit."

Tell it to the Marines.  Note the three different Message-ID's, the four
useless version numbers and End-Of headers (haven't they noticed that
RFC822 specifies that the order of header lines is not preserved?), and
the mangled ">To:" and ">From:" lines instead of To: and From: lines.

	John

> article <DBASE-L%90022818341054@TECMTYVM.BITNET>
> 220 0 <DBASE-L%90022818341054@tecmtyvm.bitnet> Article retrieved, head and body follow.
> Path: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!psuvm!MD3B2P!HMACK
> Approved: NETNEWS@PSUVM.BITNET Gateway
> Message-Version: 2
> >To: att!tecmtyvm.bitnet!dbase-l
> >From: hmack (Herbert C. Mack x6098)
> UA-Content-ID: <PMX-PC-2.0-003901-md3b2p-hmack-3879>
> End-of-Header:
> Email-Version: 2
> UA-Message-ID: <ATT-2.01-hmack-164>
> Phone: 631-6098
> End-of-Protocol:
> Content-Type: text
> Content-Length: 237
> Message-ID:   <DBASE-L%90022818341054@TECMTYVM.BITNET>
> Newsgroups: bit.listserv.dbase-l
> Date:         Wed, 28 Feb 90 18:33:53 EDT
> Reply-To:     Discussion on the use of the dBase language and related dialects
>               <DBASE-L@TECMTYVM>
> Sender:       Discussion on the use of the dBase language and related dialects
>               <DBASE-L@TECMTYVM>
> From:         hmack@MD3B2P.ATT.COM
> Subject:      dBase Listing
> 
>        To Whom It May Concern,
> 
>          I am interested in receiving information regarding dbase, fox, and
> clipper. My return mail address is as follows:
> 
>          EMAIL DBASE -L md3b2p!hmack@att.att.com
> 
> 
>         Thanks,
> 
>         Herb
> .

-- 
John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
 Boycott the census!  The government that invaded Central America does not
hesitate to break into "their own" census database to violate your privacy.
         Maximum penalty for refusing to answer:  $100, no jail.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  6 Mar 90 10:00:43 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05158;
          6 Mar 90 9:56 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA23570; Tue, 6 Mar 90 09:52:31 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 Mar 90 14:49:01 GMT
From: TRANSARC.COM!Craig_Everhart@ucbvax.berkeley.edu
Subject: Re: "X.400" articles with >To:, Message-Version:, etc
Message-Id: <gZwwrR70BwwOQMSnQv@transarc.com>
References: <10613@hoptoad.uucp>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

I don't think there's anything out-and-out illegal about what you quoted
in the gatewayed-from-X.400 header.  You may not *like* the
	>To:
and
	>From:
headers, but RFC822 says they're OK.  (Whether B-news likes them is
another matter, but that's a ``small matter of programming.'')  The two
additional IDs will doubtless be useful to you three years hence when
you're debugging your own installation of X.400.

		Craig

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Mar 90 07:05:36 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25074;
          9 Mar 90 6:59 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA16611; Fri, 9 Mar 90 04:53:09 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 Feb 90 20:50:27 GMT
From: Matt Madison <eru!luth!sunic!uupsi!rpi!MADISON%vms.ecs.rpi.edu@bloom-beacon.mit.edu>
Organization: Rensselaer Polytechnic Institute, Troy, NY
Subject: Mild flame about (some) UNIX mailers
Message-Id: <00932CA6.30EE8E00@vms.ecs.rpi.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Having just finished writing some new E-mail software for our VMS system,
I have spent several hours studying both RFC 821 and RFC 822 to ensure that
this software complies with these standards.  After all, these standards
are used by all the systems on the Internet, right?

As soon as this software went into production use, we started experiencing
problems exchanging mail with (you guessed it) some UNIX systems on our
network (and elsewhere).  There have been three problems so far, and trivial
though they may be, they have been rather aggravating.

Problem 1.  In implementing a gateway between VMS MAIL coming in over
DECnet and SMTP, my software generates return addresses of the form
<"node::user"@domain>.  The quotation marks are necessary because colons
are considered "special" by RFC 822.  This immediately started to cause
problems because (I'm told) sendmail by default strips quotation marks
from the user portion of an address.  So when UNIX users tried to reply
to messages sent from my system, the replies would be rejected by my
SMTP server becuase <node::user@domain> is not valid RFC 822.

Problem 2.  RFC 821 states that all lines sent should be terminated with a
carriage return/line feed sequence.  It turns out that some UNIX-based
SMTP implementations do not adhere to this and by default terminate lines
simply with line feeds.  Now, I can understand this behaviour in older UNIX
implementations.  But we're talking recent versions of ULTRIX and SGI's
UNIX (whatever it's called)!

Problem 3.  Some UNIX mail systems appear to generate return addresses of
the form

       real name <user@domain>

Where "real name" is simply pulled from the passwd file (or wherever this
information is obtained on UNIX systems), without verifying that it can be
left unquoted and still comply with RFC 822.  This means that anyone who has
included their middle initial with their name, with a dot, will have a
return address that violates the standard (dots are not allowed in the
leading phrase before the address).  Parsing 822-compliant addresses is
complicated enough without having to deal with crap like this.

What really burns me up about this, is that it's considered _my_ fault that
this stuff doesn't work!  Argh.
--
Matthew Madison, Systems Programmer  | "First they built the world's standard.
Engineering Computing Services       |  Then they added standards no one else
Rensselaer Polytechnic Institute     |  had."  - an ad for SCO Xenix
Troy, New York 12180-3590 USA        |
   madison@vms.ecs.rpi.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Mar 90 08:23:35 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27024;
          9 Mar 90 8:00 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA21197; Fri, 9 Mar 90 07:41: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: 12 Feb 90 20:18:49 GMT
From: Kyle Jones <rti!talos!kjones@mcnc.org>
Subject: message encapsulation in returned mail: a plea
Message-Id: <1990Feb12.201849.28525@talos.uu.net>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

If any of you are writing a new mail delivery agent, and this agent
returns a copy of a message upon unsuccessful delivery, please take a
look at RFC 934, "Proposed Standard for Message Encapsulation", before
inventing another way to encapsulate messages.

I'm maintaing a mail reader that tries to recognize and extract returned
mail.  At present an if-clause is required for every different delivery
agent, because they all have a different way of heralding the beginning
of an undelivered message.

I'd love to see existing delivery agents adopt the standard as well,
but at the very least I hope no new mailers will ignore it.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  9 Mar 90 09:58:38 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa01764;
          9 Mar 90 9:53 EST
Date: Fri 9 Mar 90 09:48:21-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: message encapsulation in returned mail: a plea
To: rti!talos!kjones@mcnc.org
Cc: header-people@MC.lcs.mit.edu
Message-ID: <636994101.340000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To: <1990Feb12.201849.28525@talos.uu.net>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

>If any of you are writing a new mail delivery agent, and this agent
>returns a copy of a message upon unsuccessful delivery, please take a
>look at RFC 934, "Proposed Standard for Message Encapsulation", before
>inventing another way to encapsulate messages.

Kyle,
  I don't know what transformations you are seeing on the far side of the 
gateway to UUCP (which I infer from the headers that you are using), but 
note that, if your <real> objective is to separate messages sent to report 
errors from original messages, and either (i) you were running SMTP or
(ii) your gateway were to preserve all relevant information, then--
you can determine, unambiguously, which is which using the following 
envelope rule:

- Messages <MUST> use MAIL FROM transactions that identify the sending SMTP
and user. 
- Error/non-delivery messges <MUST> not have that information; their MAIL 
FROM transactions <MUST> be exactly MAIL FROM: <>

This should be much more reliable than heuristics about emcapsulation 
styles, partially because the latter are often also used in (non-error) 
forwarded or relayed mail.

If your gateway, or other gateways, don't deliver adequate information 
about what they received in the envelopes, it would seem to me that the 
place to start a campaign is at the gateway and its transformations, not at 
the far-larger number of delivery agents.
   --john klensin
   Klensin@MIT.EDU 
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Mar 90 22:58:56 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12933;
          11 Mar 90 22:55 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00475; Sun, 11 Mar 90 22:21: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: 11 Mar 90 19:18:40 GMT
From: Michael Richardson <jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!utzoo!dciem!nrcaer!fts1!michael@rutgers.edu>
Organization: Fountain Technical Services, Ottawa, ON
Subject: Re: Replacing colons with periods in To-addresses
Message-Id: <155@fts1.UUCP>
References: <18538.25edbe1d@ccavax.camb.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <18538.25edbe1d@ccavax.camb.com> tinkelman@ccavax.camb.com writes:
>I have a question about a sendmail.cf rule.  But first the background.
>
>Recently I received mail from a friend at Digital who was using a new
>mail system.  It arrived with an illegal return address, albeit one that
>I, as a human, could understand.  It was 
>
>	<uunet!decwrl!koala.enet!mrgate::add::koala::x4::graff>

  I'd really like to know why uunet insists on playing with the the
internal (not envelope) From: and To: at all! (Usually deleting the
(name) portion of the From: so that I may have an address but no name
to associate it with...)

	My machine has all the maps, I understand @ addresses. And so do all the
machines from myself to uunet.
	This wouldn't be such a problem if every little bit of mail didn't go through 
uunet because of their screwed up `DEMAND' markings in their map entries. Do they
really dial all these people?
	My solution is to to `pathalias -d uunet'
	On some entries it adds a hop, on many it actually removes a redundant hop through
uunet. 

-- 
  :!mcr!:
  Michael C. Richardson
HOME: mcr@julie.UUCP SCHOOL: mcr@doe.carleton.ca WORK: michael@fts1.UUCP
I never liked staying in one place too long, but this is getting silly...

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Mar 90 03:02:36 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29387;
          13 Mar 90 2:56 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04739; Tue, 13 Mar 90 02:08: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: 13 Mar 90 02:21:02 GMT
From: Amanda Walker <intercon!news@uunet.uu.net>
Organization: InterCon Systems Corporation, Sterling, VA
Subject: Re: Replacing colons with periods in To-addresses
Message-Id: <1990Mar13.022102.14408@intercon.com>
References: <18538.25edbe1d@ccavax.camb.com>, <155@fts1.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes:
>   I'd really like to know why uunet insists on playing with the the
> internal (not envelope) From: and To: at all! (Usually deleting the
> (name) portion of the From: so that I may have an address but no name
> to associate it with...)

As I understand it, uunet's sendmail.cf rewrites domain-style addresses into
bang paths whenever it thinks it's talking to a site that only understands
UUCP mail, whether that site in fact does or not.  A while back I asked
much the same question and they said, "Oh, we'll change you from UUCP to
INTERNET" or some such.  Since then, no more header munging.  Perhaps some
site along the way is mistakenly listed as UUCP-style...

--
Amanda Walker
InterCon Systems Corporation

"Many of the truths we cling to depend greatly upon our own point of view."
	--Obi-Wan Kenobi in "Return of the Jedi"

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Mar 90 04:01:48 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02508;
          13 Mar 90 3:55 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09046; Tue, 13 Mar 90 03:55: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: 13 Mar 90 08:34:22 GMT
From: Dan Heller <turnpike!argv@sun.com>
Subject: Re: Replacing colons with periods in To-addresses
Message-Id: <132861@sun.Eng.Sun.COM>
References: <18538.25edbe1d@ccavax.camb.com>, <155@fts1.UUCP>, <1990Mar13.022102.14408@intercon.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <1990Mar13.022102.14408@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
> In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes:
> >   I'd really like to know why uunet insists on playing with the the
> > internal (not envelope) From: and To: at all! (Usually deleting the
> > (name) portion of the From: so that I may have an address but no name
> > to associate it with...)
> 
> As I understand it, uunet's sendmail.cf rewrites domain-style addresses into
> bang paths whenever it thinks it's talking to a site that only understands
> UUCP mail, whether that site in fact does or not.  A while back I asked
> much the same question and they said, "Oh, we'll change you from UUCP to
> INTERNET" or some such.  Since then, no more header munging.  Perhaps some
> site along the way is mistakenly listed as UUCP-style...

there seems to be a lot of problems with uunet in this respect.
For example, mail going thru uunet gets all bang paths stripped
off.  I tested this by having someone at a site that talks to
both sun and uunet via uucp send me mail to dheller@monet.berkeley.edu.
She added a return-receipt-to header as well.  Lines got changed, but
the two that "really mattered" for delivery purposes were From: and
the return-reciept.  They were changed to something like:

    From: uunet!user
    Return-Receipt-To: user@uunet.UU.NET

I considered these important differently than the munging it
did to the To: and return-* lines since the destination machine
cannot return receipt reliably.  The mail going thru sun got the
entire path retained properly. [%]  When I got my friend to
configure the mail headers to use @-style domain paths, it worked
by virtue of the fact that uunet didn't touch the headers.
Granted this is "correct", but I don't think this has anything
to do with why it does things "wrong" with the non-domain style
paths.

Who maintains the mail at uunet and if s/he reds this group(s)
can there be a comment of rationale for this behavior?

[%] Sun is poorly configured as well -- for example, it doesn't
understand "uunet.uu.net", but it *does* undersatnd "uunet.UU.NET".
I didn't know you could configure sendmail to be case sensitive...
and why would you?
dan
-----------------------------------------------------------
		    O'Reilly && Associates
		argv@sun.com / argv@ora.com
	   632 Petaluma Ave, Sebastopol, CA 95472 
     800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104
    Opinions expressed reflect those of the author only.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Mar 90 19:42:05 EST
Received: by mintaka.lcs.mit.edu id aa11666; 15 Mar 90 19:23 EST
Received: from BERLIN-EMH1.ARMY.MIL by mintaka.lcs.mit.edu id aa10822;
          15 Mar 90 19:04 EST
Date:     Thu, 15 Mar 90 20:53:23 CET
From:     "Kendrick J. Gibson" <aeba-im-o-e2@berlin-emh1.army.mil>
To:       header-people%mc@MINTAKA.lcs.mit.edu
Subject:  Address problem
Message-ID:  <9003151904.aa10822@mintaka.lcs.mit.edu>

Could you Header People please help us with an address that is giving us
 
a problem?  
 
We received mail from his!bang!address@ncar.ucar.edu
 
Our system is running MMDF II and we download a host table that the 
 
MMDF software must use to check addresses before our host will forward
 
the mail (if you weren't already familiar with MMDF).
 
The problem is that ncar.ucar.edu is not a host, or at least, it's not
 
listed in the table we download from sri-nic.arpa.  Therefore, we get 
 
a bad host error when we attempt to send mail to it.  
 
Could you please inform us as to how we might answer mail from 
 
ncar.ucar.edu  ?
 
Thanx,
 
Ken Gibson
Asst System Administrator
 


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Mar 90 22:24:13 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa19574;
          15 Mar 90 22:22 EST
Date: Thu 15 Mar 90 22:15:38-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re:  Address problem
To: aeba-im-o-e2@berlin-emh1.army.mil
Cc: header-people@mc.lcs.mit.edu
Message-ID: <637557338.740000.KLENSIN@INFOODS.MIT.EDU>
In-Reply-To:  <9003151904.aa10822@mintaka.lcs.mit.edu>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

On Thu, 15 Mar 90 20:53:23 CET, Ken Gibson wrote, in part:

>We received mail from his!bang!address@ncar.ucar.edu
>Our system is running MMDF II and we download a host table that the 
>MMDF software must use to check addresses before our host will forward
>the mail (if you weren't already familiar with MMDF).
 
>The problem is that ncar.ucar.edu is not a host, or at least, it's not
>listed in the table we download from sri-nic.arpa.  Therefore, we get 
>a bad host error when we attempt to send mail to it.  

  Ken, the rules, as I understand them, now require that even Milnet sites
be running Domain Name System (DNS) resolvers, or be moving to that *very*
quickly. Until you do, you are going to have these problems with increasing
frequency, especially with .EDU sites in the USA and with sites in other
countries not belonging to the US Government.  As a general rule, new sites
in those categories are not going to appear in the sri-nic.arpa (now
properly nic.ddn.mil) host table.  Ever. 
  This means that you are going to have problems with sites that have IP 
addresses but that don't appear in the NIC tables, and worse problems with 
sites that don't have IP addresses but that have DNS "Mail eXchanger" 
records, so can be reached from the Internet.  For the latter, "host table" 
records are meaningless.

>Could you please inform us as to how we might answer mail from 
>ncar.ucar.edu  ?
  Until you devise a better solution--i.e., implementing DNS support--the 
easiest solution is probably to modify your local copy of the host table to
include its address, which is 128.117.64.4.  Alternately, if this is a one-
time thing, and your software accepts dotted-decimal addresses for mail, 
try addressing to his!bang!address@[128.117.64.4].
  FYI, there is a server maintained by CSNET that will give you information 
from the DNS until you have a more automatic way to obtain it.  To use it, 
send mail to 'nslookup@sh.cs.net' (subject line ignored) whose body 
contains one or more host names, one per line.  Explanatory information, 
and the records obtained from the DNS, are returned.  Be patient; sometimes 
it takes a while.  Also, questions of this type (this is not a header 
problem) are usually best addressed to the 'info-nets' list.  To subscribe,
send mail to info-nets-request@THINK.COM .

  john klensin
  Klensin@MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Mar 90 08:20:43 EST
Received: from WS6.NNSC.NSF.NET by mintaka.lcs.mit.edu id aa12814;
          16 Mar 90 8:19 EST
From: "Kendrick J. Gibson" <aeba-im-o-e2@berlin-emh1.army.mil>
cc: header-people@mc.lcs.mit.edu
Subject: re: Address problem
Date: Fri, 16 Mar 90 08:19:00 -0500
Sender: craig@nnsc.nsf.net
Message-ID:  <9003160819.aa12814@mintaka.lcs.mit.edu>


Kendrick:

    You will probably get many notes telling you that the NIC host
table is no longer accurate.  It lists only about 8,000 hosts out of
the 150,000 on the Internet.  You need to get the version of MMDF II
which uses the Domain Name System.  A distribution was on the BSD tape,
and updates to that distribution can be FTPed from sh.cs.net:mmdf/update*

Craig

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 23 Mar 90 05:07:22 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12340;
          23 Mar 90 5:02 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11456; Fri, 23 Mar 90 04:03: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: 22 Mar 90 14:59:05 GMT
From: Christian Huitema <mcsun!inria!mirsa!jerry.inria.fr!huitema@uunet.uu.net>
Organization: INRIA Sophia Antipolis
Subject: Re: "X.400" articles with >To:, Message-Version:, etc
Message-Id: <656@mirsa.inria.fr>
References: <10613@hoptoad.uucp>, <gZwwrR70BwwOQMSnQv@transarc.com>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <gZwwrR70BwwOQMSnQv@transarc.com>,
Craig_Everhart@TRANSARC.COM writes:
|>I don't think there's anything out-and-out illegal about what you quoted
|>in the gatewayed-from-X.400 header.  You may not *like* the
|>	>To:
|>and
|>	>From:
|>headers, but RFC822 says they're OK.  (Whether B-news likes them is
|>another matter, but that's a ``small matter of programming.'')  The two
|>additional IDs will doubtless be useful to you three years hence when
|>you're debugging your own installation of X.400.
|>
|>		Craig
           
Humm... I have been through all that process, and our X.400 mail
is gatewaying more than 1000 messages per day. And we have never felt the need
for such variations... 

I believe that the ">To" and ">From" field are probably a transcription
of the X.400 enveloppe. This is redundant, as the enveloppe fields get
translated in the SMTP "From:" and "To:" headers anyhow; but if one
insists on using them, then the
conventions of RFC-1148 should be followed, i.e. using "X400-Originator:"
and "X400-Recipients:".

Christian Huitema

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Mar 90 21:04:42 EST
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14661;
          24 Mar 90 21:02 EST
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA22166; Sat, 24 Mar 90 20:21: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: 24 Mar 90 15:31:11 GMT
From: Yintien Wang <zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!grasp.cis.upenn.edu!yintien@think.com>
Organization: University of Pennsylvania
Subject: telnet to a machine
Message-Id: <22136@netnews.upenn.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu


All you netters out there :

				I've been trying to get on a machine
in N.J. I do have that machine e-mail address ( of my friend) but I
can't telnet it. My friend work for a major firm which required that
machine to go through a *.com ( gateway ? ) before the mail reached
me. Here is the question for all you wizer out there
       1. Is there a way I can look up the machine node's name under 
          telnet ? I would like to see what in the world my machine is 
          connected to.
       2. Is there a way my friend could do in his machine to find out
          his internet address number in order for me to telnet to his
          machine.

       Thanks you guys in advance for your time and help.....



					yintien@grasp.cis.upenn.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Mar 90 11:02:25 EST
Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10476;
          25 Mar 90 10:58 EST
Date: Sun 25 Mar 90 11:00:26-EST
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: 'How to reach machine X' question
To: header-people@mc.lcs.mit.edu
Message-ID: <638380826.830000.KLENSIN@INFOODS.MIT.EDU>
Mail-System-Version: <VAX-MM(250)+TOPSLIB(138)@INFOODS.MIT.EDU>

For the information of readers of this list who don't know, the optimum 
place to ask questions about how to reach one host from another is on the 
info-nets list (subscription requests to info-nets-request@think.com or, 
for BITNET subscribers, to INFONETS via your local LISTSERV).  
header-people is really the wrong place and amounts to a call for help to 
people who aren't interested (even when the subcribers lists overlap).
   --john klensin
   Klensin@MIT.EDU
-------

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 18:30:58 EST
Received: from sh.cs.net by mintaka.lcs.mit.edu id aa27812; 28 Mar 90 18:27 EST
To: HEADER-PEOPLE@mc.lcs.mit.edu
Subject: RELAY.CS.NET's hiding of host names
Date: Wed, 28 Mar 90 18:20:23 -0500
From: Daniel Long <long@sh.cs.net>
Message-ID:  <9003281827.aa27812@mintaka.lcs.mit.edu>

For a long time, RELAY.CS.NET has been rewriting outgoing addresses as:

	local-part%domain@relay.cs.net

to accomodate folks who don't understand how to do MX lookups.  The question is
whether this practise is still necessary these days.  How many folks out there
don't yet understand how to do MX lookups?  For example, is all of MILNET still
using only host tables?  Would it be reasonable to have an "exception" list to
enable the %-hack for certain destinations but default to no %-hack?  If so,
any suggestions on how to build such a list?

Thanks,
Dan Long
CSNET CIC

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 20:21:14 EST
Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa03504;
          28 Mar 90 20:18 EST
Received: by garnet.berkeley.edu (5.57/1.33)
	id AA23208; Wed, 28 Mar 90 17:18:09 PST
Date: Wed, 28 Mar 90 17:18:09 PST
From: Postmaster & BITINFO <netinfo@garnet.berkeley.edu>
Message-Id: <9003290118.AA23208@garnet.berkeley.edu>
To: HEADER-PEOPLE@mc.lcs.mit.edu, long@sh.cs.net
Subject: Re: RELAY.CS.NET's hiding of host names

I have the same problem with having to do:

	local-part%domain@host.berkeley.edu

We are doing this not only for MX only domains but also
for domains not in the host table.

I think we going to have to force the issue by using only

	local-part@domain

where domain is a valid internet domain name (A record) in the DNS.
We may want to wait on doing this for MX only domains for another
year or so to allow software with MX support to stabilize.

We have given the MILNET sites 2 years to convert to DNS:

    MIGRATION TIMETABLE (from RFC 1031)

       Table 1 shows the events and dates involved in the MILNET transition
       from host table to domain system.  The operational testing of the
       root server software has been completed.  Voluntary conversion can
       begin immediately, with mandatory conversion required by October
       1989.  After this date, hosts not converted need to obtain the host
       table equivalent by private arrangement (see "Migration Path" above).

                                                          Start     End
            Milestone                                      Date     Date
            ===========================================   ======   ======
            Root server operational testing               Dec 86   Jul 87
            Policy announced in DDN Management Bulletin   Oct 87
            Host conversion                               Oct 87   Oct 89
            Host table discontinued                       Oct 89

                           MILNET Name Domain Timetable

                                      Table 1

(It should be noted that NIC.DDN.MIL is still providing the host table,
though it has been trimmed down some.)

Bill Wells
postmaster@jade.berkeley.edu
netinfo@garnet.berkeley.edu
NETINFO@UCBGARNE.BITNET

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 22:25:17 EST
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa08896; 28 Mar 90 22:13 EST
Received: from slembe.uio.no by ifi.uio.no (5.61+IDA/KTH/LTH/1.15) with SMTP 
	id AAifi06870; Thu, 29 Mar 90 05:12:16 +0200
Received: by slembe.uio.no (5.61+IDA/KTH/LTH/SMI-3.2)
          id AAslembe26457; Thu, 29 Mar 90 05:12:12 +0200
Date: Thu, 29 Mar 90 05:12:12 +0200
Message-Id: <9003290312.AAslembe26457@slembe.uio.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: long@sh.cs.net
Cc: HEADER-PEOPLE@mc.lcs.mit.edu
In-Reply-To: <9003281827.aa27812@mintaka.lcs.mit.edu> "long@sh.cs.net"
Subject: Re: RELAY.CS.NET's hiding of host names

I dislike the local-part munging in which the like of relay.cs.net
engages vehemently.  At some point, I got so disgusted with "known
mungers" that I put them in a list, and "undid" their work, but then
the list got so long it impared mail delivery.  Mail delivered to my
mailbox is now devoid of most of those %'s, iff I (think I) can reach
the hosts so hidden.  This is ugly and by standards decreed wrong.  I
agree with those standards, but still feel the need to undo other
people's work.

I would like relay.cs.net to be more selective in which addresses is
munges, if you are going to continue this practice.  ONLY those
domains for which an MX lookup results in a pointer to "relay.cs.net",
should be rewritten.  The problem I see is that too many valid domains
end up embedded in a local-part.

Also, I would favor removal of this practice entirely.  Better to make
the non-MX mailers find a willing gateway to help them and force-route
mail they can't deliver there in an interim.

Even in the case of hosts for which RELAY.CS.NET is MX and such
gateway, the headers should not be munged.  It's a transport problem,
not an addressing problem.  Locally configurably mailers should be
configured to take care of this problem while it exists.

Disclaimer: I've made a bunch of money configuring sendmail.cf files
and my view may be slightly slanted in favor of other consultants in
the field. :-)

[Erik]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 08:32:53 EST
Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa01614; 29 Mar 90 8:27 EST
Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP
	id AA06175; Thu, 29 Mar 90 08:26:05 EST
Message-Id: <9003291326.AA06175@MIT.EDU>
Date:     Thu, 29 Mar 90 7:27:47 CST
From: Rich Zellich <zellich@stl-07sima.army.mil>
To: Daniel Long <long@sh.cs.net>
Cc: HEADER-PEOPLE@MC.lcs.mit.edu
Subject:  Re:  RELAY.CS.NET's hiding of host names

I think I can guarantee that there are a *lot* of .army.mil sites still
running MMDF, using host tables.  Many of these machines are not directly
connected to the net, but are hung off of a subnet behind one kind or
another of a gateway - some of the gateways will pass only mail...you can't
get out onto the net through them to do *anything*.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 18:02:04 EST
Received: from sh.cs.net by mintaka.lcs.mit.edu id aa24656; 29 Mar 90 17:49 EST
To: HEADER-PEOPLE@mc.lcs.mit.edu
Subject: Re: RELAY.CS.NET's hiding of host names 
Date: Thu, 29 Mar 90 17:39:31 -0500
From: Daniel Long <long@sh.cs.net>
Message-ID:  <9003291749.aa24656@mintaka.lcs.mit.edu>

Thanks for all the responses.  From the sounds of it, MILNET is the main MX
holdout.  In particular, MILNET sites not running TOPS-20 and not at BRL are
the culprits.  MILNET machines that cannot do MX's can sometimes (but not
always) forward undeliverable mail to a "smart" gateway.

There's some sentiment to just stop doing the %-hack altogether and let the
poor have-not's suffer so much that they get off their....um...so that they put
up MX-capable software.

There's additional sentiment to drop the %-hack but to soften the blow by
adding a header field like:
    "X-Suggested-Reply-Path-For-Folks-Who-Have-Broken-Mailers: 
    	    send to user%domain@relay.cs.net"

I'm not interested in disrupting email connectivity to CSNET PhoneNet members
but I *would* like to help encourage MX usage and the resulting simplification
of address syntax.

So, my options seem to be:
	1) Keep things as they are today (and for n years to come).
	2) Convert to user@domain and forget the poor have-nots.
	3) Convert to user@domain and add the header warning.
	4) Convert to user@domain except when mailing to a specific
		group of hosts (e.g. *.MIL less *.BRL.MIL less TOPS20's)
	5) Others?

Send your votes to me and I'll summarize!

Thanks,
Dan

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 23:46:07 EST
Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id ab08902;
          29 Mar 90 23:41 EST
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1000; Thu, 29 Mar 90 23:40:24 EDT
Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id
 3185; Thu, 29 Mar 90 23:40:23 EST
Date:    Thu, 29 Mar 90 20:41 PST
To:      Daniel Long <long%sh.cs.net@usc.edu>
CC:      HEADER-PEOPLE@MC.lcs.mit.edu
From:    Leonard D Woren <LDW%MVSA.USC.EDU@mitvma.mit.edu>
Subject: Re: RELAY.CS.NET's hiding of host names
Message-ID:  <9003292341.ab08902@mintaka.lcs.mit.edu>

On Thu, 29 Mar 90 17:39:31 -0500,
   Daniel Long <long%sh.cs.net@USC.EDU> said:
> There's some sentiment to just stop doing the %-hack altogether and let the
> poor have-not's suffer so much that they get off their....um...so that they pu
> up MX-capable software.

Normally, I agree with things like that, but I'm now caught on the
other side of the fence.  We desperately need to have a DNS mailer
here, but what can I do when the vendor of our software just can't
supply the required functionality?

(The problem is that some sites run vendor-(un)supported software like
Acces/MVS.  ACC was so incapable of supporting this product that they
just sold it to Interlink.  Acces/MVS Release 3 supposedly has DNS
support, but ACC has not met the promised dates for shipping Release
3.  Let's see if Interlink does better.)

/Leonard

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Mar 90 11:02:29 EST
Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa06563;
          30 Mar 90 11:00 EST
Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP
	id AA10915; Fri, 30 Mar 90 10:59:08 EST
Message-Id: <9003301559.AA10915@MIT.EDU>
Date:     Fri, 30 Mar 90 9:59:29 CST
From: Rich Zellich <zellich@stl-07sima.army.mil>
To: long%sh.cs.net@usc.edu
Cc: header-people@MC.lcs.mit.edu
Subject:  Milnet hosts and support of MX records, etc.

The .army.mil sites I mentioned in my earlier reply are running "supported"
MMDF software, but that support is out of Ft. Huachuca these days, and we
are entirely at their mercy as far as when we get upgrades and what they
put in them.  We are *required* to run the standard MMDF software by our
HQs (HQ Army Materiel Command, in my case), and the folks at Huachuca
don't seem to be very responsive to anyone else (the management people,
that is; I have no knowledge of the actual programer(s) - if any - assigned
to the MMDF system).

-Rich

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU;  5 Apr 90 06:26:18 EDT
Received: from KAUAI.MCL.UNISYS.COM by mintaka.lcs.mit.edu id aa21495;
          5 Apr 90 6:24 EDT
Received: from LANAI.MCL.UNISYS.COM by kauai.MCL.Unisys.COM (4.1/Domain/jpb/mls/2.9) 
	id AA14912; Thu, 5 Apr 90 06:25:23 EDT
Received: by LANAI.MCL.UNISYS.COM [4.1/Domain/jbp/2.4] 
	id AA20336; Thu, 5 Apr 90 06:23:29 EDT
Date: Thu, 5 Apr 90 06:23:29 EDT
From: Dennis Perry <perry@mcl.unisys.com>
Message-Id: <9004051023.AA20336@LANAI.MCL.UNISYS.COM>
To: header-people@mc.lcs.mit.edu
Subject: help with header understanding
Cc: perry@mcl.unisys.com


The following headers appear to have loops in them.  Why?  Also,
the From: line has a machine which is not in the header list.  Can
someone explain to me in simple terms what takes place with these messages.

Thanks,
dennis

-------------
From wheaton!perryl@yclept.chi.il.us Wed Apr  4 21:14:08 1990
Received: from kauai.MCL.Unisys.COM by LANAI.MCL.UNISYS.COM [4.1/Domain/jbp/2.4] 
	id AA19762; Wed, 4 Apr 90 21:14:05 EDT
Received: from rutgers.edu by kauai.MCL.Unisys.COM (4.1/Domain/jpb/mls/2.9) 
	id AA13960; Wed, 4 Apr 90 21:15:45 EDT
Received: from gargoyle.uchicago.edu by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP 
	id AA00778; Wed, 4 Apr 90 19:50:51 EDT
Received: from gargoyle.uchicago.edu by oddjob.uchicago.edu Wed, 4 Apr 90 17:21:22 CDT
Received: by gargoyle.uchicago.edu (5.59/1.14)
	id AA01302; Wed, 4 Apr 90 17:21:16 199
Received: by homebru.chi.il.us (smail2.5)
	id AA03204; 4 Apr 90 16:58:24 EDT (Wed)
Received: by obdient.chi.il.us (smail2.5)
	id AA28008; 4 Apr 90 14:54:36 CST (Wed)
Received: by wheaton.UUCP (1.2/UUCP-Wheaton/Hack 12/21/87))
	id AA14855; Wed, 4 Apr 90 14:17:03 cdt
Date: Wed, 4 Apr 90 14:17:03 cdt
From: wheaton!perryl@yclept.chi.il.us (Lynellen Perry)
Message-Id: <9004041917.AA14855@wheaton.UUCP>
To: perry@mcl.unisys.com
Subject: returning your test
Status: R
_____________________________________________________

>From obdient!mcdchg!homebru!gargoyle!clout!gargoyle!oddjob!homebru!gargoyle!clout!Stars.Reston.Unisys.COM!perry Wed Apr  4 07:09:06 1990
Received: by wheaton.UUCP (1.2/UUCP-Wheaton/Hack 12/21/87))
	id AA06648; Wed, 4 Apr 90 07:09:00 cdt
Received: by obdient.chi.il.us (smail2.5)
	id AA17692; 4 Apr 90 07:09:02 EST (Wed)
Received: by chg.mcd.mot.com (smail2.5)
	id AA25714; 4 Apr 90 06:53:14 CDT (Wed)
Received: by homebru.chi.il.us (smail2.5)
	id AA01413; 4 Apr 90 04:10:16 CDT (Wed)
Received: by homebru.chi.il.us (smail2.5)
	id AA01293; 4 Apr 90 03:25:21 CDT (Wed)
Received: by gargoyle.uchicago.edu (5.59/1.14)
	id AA13631; Wed, 4 Apr 90 00:45:30 199
Received: by clout.chi.il.us (smail2.5 - gargoyle) id AA13524; 4 Apr 90 00:40:30 CDT (Wed)
Received: by gargoyle.uchicago.edu from oddjob.uchicago.edu (5.59/1.14)
	id AA13324; Wed, 4 Apr 90 00:30:10 199
Received: by oddjob.uchicago.edu Wed, 4 Apr 90 00:30:06 CDT
Received: by homebru.chi.il.us (smail2.5)
	id AA00784; 3 Apr 90 23:17:28 CDT (Tue)
Received: by gargoyle.uchicago.edu (5.59/1.14)
	id AA09486; Tue, 3 Apr 90 21:20:58 199
Received: by clout.chi.il.us (smail2.5 - gargoyle) id AA09392; 3 Apr 90 21:15:40 CDT (Tue)
Received: from gargoyle.uchicago.edu by oddjob.uchicago.edu Tue, 3 Apr 90 20:35:08 CDT
Received: by gargoyle.uchicago.edu from aviary.stars.reston.unisys.com (5.59/1.14)
	id AA08765; Tue, 3 Apr 90 20:35:00 199
Received: by aviary.Stars.Reston.Unisys.COM (4.0/Domain/jpb/2.9) 
	id AA15755; Tue, 3 Apr 90 21:33:36 EDT
Date: Tue, 3 Apr 90 21:33:36 EDT
From: gargoyle!oddjob!Stars.Reston.Unisys.COM!perry (Dennis Perry - Unisys)
Message-Id: <9004040133.AA15755@aviary.Stars.Reston.Unisys.COM>
To: wheaton!perryl
Subject: test
Cc: perry@mcl.unisys.com
Status: RO

this is  a test



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 01:13:48 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21926;
          17 Apr 90 1:14 EDT
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA07591; Sat, 14 Apr 90 04:38:31 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 Apr 90 14:17:19 GMT
From: Robert Story <clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!utzoo!censor!avcocan!bounder@uunet.uu.net>
Organization: AFS Ltd., London, Ontario, CANADA
Subject: Mailer Standards
Message-Id: <506@avcocan.UUCP>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

Where can I find out about mail standards?  I would specifically like to
know about RFC 822 and MHS.  Is RFC 822 the standard that the Unix mail 
system uses?  Perhaps, this should be a new book from Nutshell!

Thanks.
-- 
[ Robert Story  ..uunet!{jtsv16!geac!censor, mnetor!lsuc}!avcocan!bounder  ]
[ SnailMail :   AFS 201 Queens Avenue London Ontario Canada N6G 4M5        ]
[ Voice     :   +1 519 672-4220 xtn 642 or Direct Line +1 519 660-2642     ]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 02:23:30 EDT
Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24508;
          17 Apr 90 2:21 EDT
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA18374; Sat, 14 Apr 90 12:37: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: 14 Apr 90 08:28:54 GMT
From: "Oberman, Kevin" <rogue.llnl.gov!oberman@lll-winken.llnl.gov>
Organization: Lawrence Livermore National Laboratory-Engineering
Subject: Re: Mailer Standards
Message-Id: <55987@lll-winken.LLNL.GOV>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <506@avcocan.UUCP>, bounder@avcocan.UUCP (Robert Story) writes...
>Where can I find out about mail standards?  I would specifically like to
>know about RFC 822 and MHS.  Is RFC 822 the standard that the Unix mail 
>system uses?  Perhaps, this should be a new book from Nutshell!

RFC 822 and RFC 1123 are the closest thing to standards that exist, but I've
never seen a Unix(tm) mailer that follows it completely. Most notaable is the
addition of fields to the header that violate the "standards".

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 11:36:14 EDT
Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa12504; 17 Apr 90 11:25 EDT
Received: from svarte.uio.no by ifi.uio.no (5.61+IDA/KTH/LTH/1.15) with SMTP 
	id AAifi07473; Tue, 17 Apr 90 16:28:32 +0200
Date: Tue, 17 Apr 90 16:28:32 +0200
Message-Id: <9004171428.AAsvarte28797@svarte.uio.no>
From: Erik Naggum <erik@naggum.uu.no>
Sender: enag@ifi.uio.no
To: rogue.llnl.gov!oberman@lll-winken.llnl.gov
Cc: header-people@mc.lcs.mit.edu
In-Reply-To: <55987@lll-winken.LLNL.GOV> "rogue.llnl.gov!oberman@lll-winken.llnl.gov"
Subject: Mailer Standards

   In article <506@avcocan.UUCP>, bounder@avcocan.UUCP (Robert Story)
   >writes...  Where can I find out about mail standards?  I would
   >specifically like to know about RFC 822 and MHS.  Is RFC 822 the
   >standard that the Unix mail system uses?  Perhaps, this should be
   >a new book from Nutshell!

It would have to be an awfully large nutshell, in my opinion.  "Unix
mail" doesn't exist per se, there are only lots of variations over a
more or less common theme, which, by the way, has nothing whatsoever
to do with RFC 822.  (It only looks like it does, which confuses
people.)

   RFC 822 and RFC 1123 are the closest thing to standards that exist,
   but I've never seen a Unix(tm) mailer that follows it completely.
   Most notaable is the addition of fields to the header that violate
   the "standards".

RFC 822 (with updates in RFC 1123) is the _Internet_ message format
specification.  What you see in the Unix mailboxes is a user agent
format, which RFC822 expressly does not talk about.  Those "extra"
fields that certain user agents add for their own book-keeping are
legal as long as they don't enter the Internet.  Also, RFC 822 (++) is
pretty lax on unspecified headers, so the locally added headers are
not in violation of the standard, as such.  (Certain headers are
hashed into mush to retrofit the old Unix mailbox format, and those
are, of course, in violation of the standard.)  Also, the UUCP relic
"From_" line which "separates" message in the standard (?) Unix
mailbox format, is a clear violation.

RFC822 (with the updates in RFC 1123) are, however, routinely ignored
by that nefarious Unix system mail delivery agent, sendmail.  I would
positively hate having the gross errors and circumventions of sendmail
become an inofficial standard, anywhere.  What we need is a tool to
validate sendmail.cf files, so that headers on the Internet side are
according to the standards.  I've tried to do that, and ended up
writing my own delivery and user agents...

"Unix" mail systems have a long way to go to measure up to the
standards they purportedly follow.  It's the part of Unix systems I
have real problems with.

Finally, MHS (if you think about MOTIS) is covered by a huge
International Standard, ISO 10020, and by CCITT Recommandation series
X.400 (1988).  I suggest you take a long vacation if you plan to touch
those documents.  You also need to buy them for an incredible load of
money, and you can get nice "introductions" to these standards in your
favorite academic bookstore for another incredibly mass of money.

[Erik], the mail standards guy

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 15:31:09 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa23542; 17 Apr 90 15:28 EDT
Received: from Concord.ms by ArpaGateway.ms ; 17 APR 90 12:22:07 PDT
Sender: Samuel_S_Jones.dlosLV300@xerox.com
Date: 17 Apr 90 12:22:04 PDT (Tuesday)
Subject: REMOVE FROM DL. (EOM)
From: Samuel_S_Jones.dlosLV300@xerox.com
To: header-people@mc.lcs.mit.edu
cc: sjone.dlosLV300@xerox.com
Message-ID: <900417-122207-4272@Xerox>



THANK YOU.


SAM




S  8*736-3127,,214-420-3127,,vmx:736-3127
  Central Time
  Samuel S Jones:DLOSLV300:XEROX
   41032.25220222116.0
FAX--8*736-3344,,214-420-3344
A  XEROX CORPORATION
       1301 RIDGEVEIW DR
        LEWISVILLE,TEXAS  75067
        MAIL STOP::R380-301

