Date: Fri 9 Nov 84 04:28:46-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: mail address parsing
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Wed 24 Oct 84 02:24:44-EDT

The reason why you can't use () for specifying precedence in routing,
is, I believe, that () are used for comments in an RFC822 header.  At
least, in the local Chaosnet mailers it is.

However, user-specified precedence seems to me to be a good idea,
instead of having all these path servers all over the place.  Path
servers which do relays only to hosts they know about are fine, but
path servers which carry the full UUCP database can get out of whack,
causing strange things to happen.  From my UUCP experience at work
(houxm), a number of machines have different ideas of who they talk
to, and how they talk to who they talk to.

As an aside, what's the socket number for the UUCP path server?  (Mail
only, please, and you can send it to ihnp4!houxm!gregbo if you want.)

--gregbo
-------

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647192586063412@MIT-MULTICS.ARPA>; 19 Nov 1984 14:16:26 est
Date:        19 Nov 84 18:00 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people <header-people@MIT-MC.ARPA>
Subject:     Long names
Message-ID:  <79307@QZCOM>

A message which was sent out from us, contained in the TO field
the following text:
TO: <Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA>

This message was obviously truncated by some relayer on the way,
so that some characters at the end were deleted including the
final >, and we got an error message back saying that some system
got an RFC822 header with unbalanced <>-s.

Should we stop using such long names? We could alternatively
use names of the format:

TO: Message Group at BRL mailing list <C153%QZCOM.MAILNET@MIT-MULTICS>

Advantage: Would not get those truncation problems
Disadvantage: The text within <> says nothing on what it is

Note: "Message Group at BRL mailing list" is our local conference
which receives entries sent to us from the MSGGROUP @ BRL-AOS.ARPA.



Delivery-Date:  19 Nov 84 10:47 EST
Delivery-By:  Network_Server.Daemon@MIT-MULTICS.ARPA (ihnp4!gatech!mmdf@Berkeley@UCB-V)
Date:  Mon, 19 Nov 84 08:04 EST
From:  ihnp4!gatech!mmdf@UCB-VAX.ARPA
Subject:  Illegal Address (gitpry!robert)
To:  Schauble.PDO1@MIT-MULTICS.ARPA
cc:  postmaster@UCB-VAX.ARPA
Message-ID:  <8411191549.AA24629@UCB-VAX.ARPA>
Resent-Date:  20 Nov 84 00:49 EST
Resent-From:  Paul Schauble <Schauble@MIT-MULTICS.ARPA>
Resent-To:  Header-People@MIT-MC.ARPA
Resent-Comment:
          I just got this message back from an attempt to mail to a
          usenet address through Berkeley. Has this stopped working? If
          not, could someone please explain what's happening here?
        --
                    Thanks,
                    Paul
Resent-Message-ID:  <841120054958.570873@MIT-MULTICS.ARPA>

          Your letter has been intercepted trying to access
a restricted access host (e.g. an ARPANET host).  A copy
of your letter has been sent to the system administrators.
The text of your letter follows.

  --------------- Returned Mail Follows --------------
>From ucbvax!Schauble.PDO1@MIT-MULTICS.ARPA  Sun Nov 18 05:38:49 1984 remote from ihnp4
Received: by ihnp4.ATT.UUCP; id AA23151; 18 Nov 84 05:38:49 CST (Sun)
Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
          id AA07391; Fri, 16 Nov 84 17:10:47 pst
Date:  Fri, 16 Nov 84 20:02 EST
From: Paul Schauble <ihnp4!ucbvax!Schauble@MIT-MULTICS.ARPA>
Subject:  Your conversion of ogre to printf
To: ihnp4!gatech!gitpry!robert@BERKELEY
Message-Id:  <841117010220.841626@MIT-MULTICS.ARPA>

Would you please post the result to net.sources when finished?

          Thanks,
          Paul
  --------------- End of Returned Mail ---------------

Date: 20 Nov 1984 18:38:59 PST
From: POSTEL@USC-ISIF.ARPA
Subject: re: long names
To:   header-people@MIT-MC.ARPA


Jacob Palme:

It probably does not matter so much how many characters are inside the
angle brackets (<>), but rather the total length of the line. I would
suggest you both use a shorter name inside the angle brackets and a
shorter line.  In any case the truncation is a bug in some program, it
would be nice if that program could be identified and then fixed.

--jon.
-------

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647709795468488@MIT-MULTICS.ARPA>; 25 Nov 1984 13:56:35 est
Date:        25 Nov 84 16:21 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          MHS_implementation%QZCOM.MAILNET@MIT-MULTICS.ARPA
Bcc:         Announcement_conferences%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             MHS_subsetting_group_%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>,
             msggroup@BRL-AOS.ARPA, mailgroup@UCL-CS..ARPA,
 Mailnet_implementation_and_JNT-MAIL%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             External_mail_experience%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     MHS (X.400) implementation
Message-ID:  <80073@QZCOM>

A new QZCOM conference with the name "MHS (X.400) implementation"
has been started. The conference will to mail networks have the
name "MHS_(X.400)_implemenetation", in most cases postfixed by
"%QZCOM@MIT-MULTICS.ARPA".

The conference/mailing list is open for anyone who is seriously
interested in implementing the CCITT X.400 (MHS) message handling
protocols or gateways to these protocols.

In the conference/mailing list we can for example discuss how
to understand and interpret the MHS recommendation, how to map
existing mail system and mail network features onto the MHS
structure etc.

To join the conference do as follows:
QZCOM users: Use the "member" command.
Users at other sites: Write a letter to me personally, "Jacob_Palme_QZ
%QZCOM.MAILNET@MIT-MULTICS.ARPA", do NOT write to the conference
itself.



Received: from Cabernet.MS by ArpaGateway.ms ; 24 NOV 84 15:41:14 PST
Date: 24 Nov 84 15:41:04 PST
From: Murray.pa@XEROX.ARPA
Subject: Re: Long names
In-reply-to: <79307@QZCOM>
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc: Murray.pa@XEROX.ARPA, header-people <header-people@MIT-MC.ARPA>

Why did you put <>s around that name? I thought that format was intended
for source routing, and I don't see any interesting routing in your
example.

I think the spec requires a noise word is between the "To:" and the "<".

Received: from Cabernet.MS by ArpaGateway.ms ; 24 NOV 84 15:43:02 PST
Date: 24 Nov 84 15:42:56 PST
From: Murray.pa@XEROX.ARPA
Subject: Re: Long names
In-reply-to: <79307@QZCOM>
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc: Murray.pa@XEROX.ARPA, header-people <header-people@MIT-MC.ARPA>

Grapevine (our internal mail system) has a limit of 64 characters. If I
counted right, your example is exactly 64 characters long. This limit is
in the envelope, not the header.

I have a mild preference for doing whatever is easy/reasonable to avoid
long names. Your C153 suggestion looks fine.

Our Arpa-Grapevine mail gateway will correctly deliver messages with
long names. If the return-path is too long, it substitues something
legal as it passes the message to Grapevine. The only problem is that
our users won't be able to reply to the message.

Received: from Aurora.ms by ArpaGateway.ms ; 25 NOV 84 22:57:07 PST
From: DonWinter.pasa@XEROX.ARPA
Date: 26 Nov 84 1:56:43 EST
Subject: Re: Long names
In-reply-to: Murray.pa's message of 24 Nov 84 15:42:56 PST
To: Murray.pa@XEROX.ARPA
cc: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people
 <header-people@MIT-MC.ARPA>

Interestingly enough, since Lily (the Grapevine's Terminal Service) uses
the Return-Path in the Table of Contents (I don't know why), I received
Jacob's original message with the Sender listed as "Name-too-Long"!!!

			Don

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2647976203558355@MIT-MULTICS.ARPA>; 28 Nov 1984 15:56:43 est
Date:        28 Nov 84 12:31 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Long names
Message-ID:  <80597@QZCOM>
In-Reply-To: <80334@QZCOM>

The ideal way if your local net or system cannot handle long
names, would of course be to create a data base of the long names
versus the abbreviated names you use locally, so that names can
be translated to the long format again externally. I have done
it that way in the COM-RFC-mail interface.



Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA14458; Sun, 9 Dec 84 12:17:15 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.30)
	id AA02180; Sun, 9 Dec 84 12:18:36 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.30)
	id AA01056; Sun, 9 Dec 84 12:18:11 pst
Date: Sun, 9 Dec 84 12:18:11 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8412092018.AA01056@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: New "Top-name" Domain Names

Does anyone know yet what the initial set of new top-name domains will be?
What happens 15 Dec 84? When do the host/domain name tables need to be
changed?

Bill

Date: 13 Dec 1984 15:34-PST
Sender: WESTINE@USC-ISIF.ARPA
Subject: New "Top-name" Domain Names
From: Postel@isif
To: Header-people@MIT-MC.ARPA
Message-ID: <[USC-ISIF.ARPA]13-Dec-84 15:34:52.WESTINE>


Bill Wells et al:

Please read RFCs, 920 and 921 very carefully.

The new top-level domain names are discussed there.  The procedure
for registering new names is also described.

--jon.


Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2649676128111791@MIT-MULTICS.ARPA>; 18 Dec 1984 08:08:48 est
Date:        05 Dec 84 01:13 +0100
From:        -KPJ_Jaakkola_QZ_private%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    -KPJ_Jaakkola_QZ_private%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@MIT-MC.ARPA, Postel@USC-ISIF
Subject:     re: long names
Message-ID:  <82112@QZCOM>
In-Reply-To: <79583@QZCOM>

Could the problem maybe be that some UNIX mail handling programs
truncate lines to 40 characters?



Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA01965; Mon, 17 Dec 84 18:57:32 pst
Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.31)
	id AA16155; Mon, 17 Dec 84 18:57:23 pst
Received: by ucbpopuli.CC.Berkeley.ARPA (4.19/4.31)
	id AA20909; Mon, 17 Dec 84 18:56:49 pst
Message-Id: <8412180256.AA20909@ucbpopuli.CC.Berkeley.ARPA>
Date: 17 December 84 21:56 EST
From: RMXJARTJ%CORNELLA.BITNET@Berkeley
To: HEADER-PEOPLE@MIT-MC
Subject: Request to add user

Hello,

Could you please add my userid to "THE LIST?"

Thank you,

Gligor Tashkovich

(But everyone calls me "G")

RMXJARTJ @ CORNELLA.BITNET


Date: 19-Dec-84 12:42 PST
From: Kirk Kelley  <KIRK.TYM@OFFICE-2.ARPA>
Subject: Body line length
To: HEADER-PEOPLE@MIT-MC
Message-ID: <TYM-KIRK-610SV@OFFICE-2.ARPA>

Our message converter to RFC 822 folds everything in the body at 80 columns as a
default (our paragraphs normally have no CRLFs in them).  We use 80 columns 
instead of something shorter because our customers send tables formatted for 80 
characters.  We would prefer not placing ANY line breaks in the paragraphs of 
the body.

   [We would also prefer not getting ANY line breaks in paragrahs FROM the 
   Internet, but thats another story.]

This would mean we would send some "lines" in the body thousands of characters 
long.  Are people going to suffer more from this as the default or from forcing 
line breaks at 80 or 72 or 60 or ????

Assuming SMTP knows how to deal with long lines, will mailers and mail readers 
break, or is this just a display aesthetics problem?

We aim to please.  -- kirk


Date: 20 Dec 84 0558 EST
From: Rudy.Nedved@CMU-CS-A.ARPA
To: Kirk Kelley <KIRK.TYM@OFFICE-2.ARPA>
Subject: Re: Body line length
CC: HEADER-PEOPLE@MIT-MC.ARPA
In-Reply-To: <TYM-KIRK-610SV@OFFICE-2.ARPA>
Message-Id: <20Dec84.055825.EN0C@CMU-CS-A.ARPA>

Kirk,

I have had system give me huge lines, specifing a bad recipient address
and then not accept what they sent me.

I have system that get weird error failures....and if I look it
turns out one of our users is sending a message with long lines...he
or she generated because the terminal they have did auto-crlf...so
they typed until they were done with the message.

It sounds like you are hitting what Xerox hit along time ago. I would
suggest that you either avoid sending out long lines or have a table
of sites that "work" and wrap for all the other ones....I doubt you
will get mail to work for more then 55% of the hosts....It is just
to easy to have a static character buffer of a 1000 characters. I
know our CMU Unix code does that (the subtle thing is it does not
fail...it just adds new lines).

Good luck,
-Rudy

Received: from Salvador.ms by ArpaGateway.ms ; 20 DEC 84 04:35:03 PST
Date: 20 Dec 84 04:34:55 PST
From: Murray.pa@XEROX.ARPA
Subject: Names with spaces
To: Header-People@MIT-MC.ARPA
Cc: Murray.pa@XEROX.ARPA

We are in the final stages of bringing up a mail gateway between
Grapevine, our research mail system, with names like "Murray.PA" and our
product mail system with names like "Hallam G. Murray:OSBU North". Note
the nasty things like periods and spaces in the new names.

Does anybody out there have a system that will get in serious trouble if
we send you a message with a return-path containing spaces? By "serious"
I mean crash your system or break your mail server rather than
generating obscure error messages when somebody tries to reply to a
message with an unparsable header. Do I need to drop everything and hack
our mail gateway to prevent names with spaces from escaping into the
internet?

A few people have been testing things for the past month. So far, nobody
has complained to me that their new name was causing unreasonable
problems, like preventing them from exchanging mail with somebody else.

I am expecting to encounter some rough edges. I won't get upset if a few
users can't exchange mail with a few obscure sites, but I will have to
do something if too many sites can't live with our new names.

Assuming that our names contain spaces, will you be able to send mail to
us?

Assuming that we get the quotes right and such, will you be able to
receive mail from us? Will the corner of your mail processing software
that automatically generates headers to help you answer a message still
work?

Should I send a test case?

Anybody want a summary of the answers I get back?

Do you know of any other pitfalls in this area that I might have
overlooked?



Date: 20 Dec 84 1323 EST
From: Rudy.Nedved@CMU-CS-A.ARPA
To: Murray.pa@XEROX.ARPA
Subject: Re: Names with spaces
CC: Header-People@MIT-MC.ARPA
In-Reply-To: "Murray.pa@XEROX.ARPA's message of 20 Dec 84 07:34-EST"
Message-Id: <20Dec84.132343.EN0C@CMU-CS-A.ARPA>

You should not have any problems with any CMU sites that are in the
NIC host table with double quoted names that have spaces...However
don't expect the single character slash quoting mechanism to work.

I would be interested in what sites/mailers you have problems with.
Many CMU users still send out names with spaces...It has been a
while since I have heard complaints.

Good luck...I hope you get 90% or better.

-Rudy

Date: Thu 20 Dec 84 11:29:58-MST
From: William G. Martin <WMartin@SIMTEL20.ARPA>
Subject: Re: Body line length
To: KIRK.TYM@OFFICE-2.ARPA
cc: HEADER-PEOPLE@MIT-MC.ARPA, WMartin@SIMTEL20.ARPA
In-Reply-To: Message from "Kirk Kelley  <KIRK.TYM@OFFICE-2.ARPA>" of Wed 19 Dec 84 12:42:00-MST

Ugh! I have long wished for some sort of automatic filter on both mail
traffic and USENET postings that would automatically break any long lines
at 80 cols. Such long-lined messages and items look OK on terminals that
wrap the long line, and only give a clue to their bad nature by the fact
that some words are broken or other formatting is damaged. But when they get
sent to a printer, all of a sudden we discover that the middle of a 
many-paged output has to be edited out and reprinted through a folding
filter because a batch of long lines printed merrily out to an infinite
right margin.

Yes, I know that I could put in automatic checks for such things, like
piping all printer output through "fold" (under UNIX). I don't want to.
The normal convention is 80 columns wide. Everything is set up to expect
that. Most sources abide by that and generate suitably-formatted product.
Why should everybody have to build in extra checks and processing to catch
the few systems that generate long-lined output? When such special
terminals and systems become commonplace, when there are clear advantages
to having unformatted text blocks transmitted for formatted display at
the receiving end, then it will be worth it for simpler systems to 
expect such and build in the traps and checks and fixes needed to view
and process such text in an otherwise-80-column environment. That time has
not yet arrived.

Please make sure your output formatter breaks long-lined text into 80-column
material before releasing it to the Internet. 

Will Martin
Host Administrator, ALMSA-1
US Army Mat'l Command
-------

Date: 20 Dec 1984  12:24 MST (Thu)
Message-ID: <WANCHO.12072991707.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   "William G. Martin" <WMartin@SIMTEL20>
Cc:   HEADER-PEOPLE@MIT-MC, KIRK.TYM@OFFICE-2
Subject: Body line length
In-reply-to: Msg of 20 Dec 1984  11:29-MST from William G. Martin <WMartin>

Will,

As I, and perhaps others have pointed out already to Kirk, there are
many brain-damaged terminals we have no choice in using that do an
auto-wrap when anything appears in column 80.  With a fill to 80,
those lines with something in 80 will be followed by a single blank
line.  This appearance was surely not the format intended by the
author.  The alternative that such terminals offer is to shut that
"feature" off and have all the overflow characters overwrite each
other on column 80!  Thus, I have pleaded for pre-wrapping at 79,
which is exactly the width our people prefer for 12 pitch hardcopy.
(For 10 pitch, well, that's another story.)

(I also won't bring up the discussion rehashed many times on MSGGROUP
about the "readability" of messages read on the standard CRT when
filled to 70.)

BTW, BABYL will refill the body of a message to the default 70
(optionally to any width) with a single keystroke...and is "undoable"
in case the message contained specially formatted material that got
garbled in the fill process.

--Frank

Date: 20 December 1984 15:17-EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:    Body line length
To: WMartin @ SIMTEL20
cc: HEADER-PEOPLE @ MIT-MC, KIRK.TYM @ OFFICE-2


If the limit were 72 columns wide then I could read my mail on
punched cards.  I could even read those obnoxiously long-lined
messages which people compose on punched paper tape!  
On the other hand, printer widths are usually 120 or 132, so
maybe the limit should be 120.  Some VT100s are that wide too.
An APPLE has 40 columns, so maybe that should be the common
denomentator.  While we are on the subject, perhaps we should
limit the vertical length of messages too, since many people
have 300 baud modems.

Anyway, if wide terminals are not commonplace, then why are you
receiving so many messages which don't fit on your screen?

There are certainly many (commercially available) wide screen
terminals at my site, and we regularly send messages which look
much nicer when they are not scrunched down into 80 columns.

A more basic point is that the specification for textual messages
does not attempt to implicitly define what sorts of textually
oriented devices may be used for composing or reading the mail.

Your complaint is that your user interface is inadequate for
communication with many other people who are operating under the
same messaging protocol.  Perhaps you should consider fixing
this by changing or upgrading your mail reading software, rather
than by imposing an arbitrary restriction on the rest of the
world.

The BABYL mail reader (an EMACS library), which has been around
for years, has a single keystroke command which will instantly
reformat the message on the screen to make the lines fit more
nicely on the screen.  It even has heuristics for not destroying
the indentation of any included messages or program code.  About
half the time I read long messages on an 80 column screen, and
BABYL's text reformation command works just fine.

Chris

Date: Thu 20 Dec 84 13:32:22-MST
From: William G. Martin <WMartin@SIMTEL20.ARPA>
Subject: Re: Body line length
To: WANCHO@SIMTEL20.ARPA
cc: HEADER-PEOPLE@MIT-MC.ARPA, KIRK.TYM@OFFICE-2.ARPA, WMartin@SIMTEL20.ARPA
In-Reply-To: Message from ""Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>" of Thu 20 Dec 84 12:24:00-MST

Frank makes a good point; I used "80" in a rather generic sense in my
comments -- consider everywhere I said "80" to really mean "79". My
usual terminal (an ADM42) produces the "following-blank-line" glitch
Frank described, so I am familiar with these ill effects. However, where
I really suffer from long lines is on printed output, as I stated before.
If I have to, I can live with extra blank lines on my screen; there's no
recovery from having data printed on the platen.

Will
-------

Date: Thu 20 Dec 84 14:17:30-MST
From: William G. Martin <WMartin@SIMTEL20.ARPA>
Subject: Re: Body line length
To: CSTACY@MIT-MC.ARPA
cc: HEADER-PEOPLE@MIT-MC.ARPA, KIRK.TYM@OFFICE-2.ARPA, WMartin@SIMTEL20.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY @ MIT-MC>" of Thu 20 Dec 84 13:17:00-MST

Chris,

The point is that we (at least at this end of the Internet) DON'T get
"many" messages with over-80-column lines in them. (Or 79, as per the
preceeding discussion!) If we got "many", it would be worth the effort
to "change or upgrade" the mail software, though, if you would re-read
my posting, you would discover that I was NOT discussing the mail-reading
display; I had based my objection on the effect of dumping un-processed
messages/postings to 80-column-wide printers.

Because we don't get "many", we are talking about avoiding an
occasional minor irritation. Because so few are now being sent, I
believe that this 80/79-column convention is being adhered to already
by the majority of sites and/or people. So the discussion is an attempt
to avoid an INCREASE in this anomaly; I'm not asking everyone to change
their methods or behavior; they are now doing what is right! Only a
few long-lined postings or messages show up now, so few that I never
mentioned it or expressed my desire to have those few eradicated until
the original posting of this exchange threw open the prospect of a
lot more of them suddenly appearing.

We are in an environment now where some people have fancy bit-mapped 
displays in which they can send mail with Old English titles and 
various font sizes in the text, and include graphs, digitized images,
and, for all I know, tastes and smells. Others are making do with
TI 745 printing terminals. It is fine for those with the facilities to
do so to interchange documents and mail with any and all of their
special capabilities. When we speak of generically communicating with 
arbitrary addressee "x" in the Internet environment, however, we HAVE
to go back to the lowest common denominator. That means straight text,
minimal fanciness with formatting (avoid even character-^H-underscore!),
and limit lines to 79 (a tip of the hat to Frank!) characters long.

Once you have determined that you are communicating with specific
individual "y", who has this and that capabilities in his equipment,
THEN go ahead and ship him messages with twelve fonts, unbroken text blocks,
and animation embedded in it. Until then, or when you are addressing the
unknown capabilities of the world (as you are when sending to a mailing
list or posting to a USENET newsgroup), keep it simplistic. 

As I tried to make obvious before, when the pendulum has swung so that
the majority (or at least a lot of the highly-communicative) of the Internet
folk have the facilities to interpret what sort of fancy machine this
particular message came from, and then display it in the particular
format it was intended to be viewed in, and also produce paper copies
of it with better technologies than serial ASCII daisywheel printers
or the equivalent, THEN lets throw away the the 79-column convention
(remember that we are talking here only about a voluntary self-limitation!),
because then we would be limiting ourselves severely for the sake of
the poor or the cheap (individuals or organizations :-). I don't think
that is yet the case. I don't see this sort of capability anywhere on
the MILNET to any great extent (I actually don't know of any at all, but
I'm sure there is SOME somewhere...); if you want to speed this up, 
mail your congresscritter a request to divert the funds from a couple
of F-15's or the like to instead go to DoD workplace automation. (Though
they'll probably just spend it on another batch of low-bidder terminals,
which is the cause of all this fuss in the first place... :-)

In the real world,

Will Martin
Host Administrator, ALMSA-1
-------

Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2649882381394887@MIT-MULTICS.ARPA>; 20 Dec 1984 17:26:21 est
Date: Thu, 20 Dec 84 11:45:54 EST
From: Steve_Rothwell%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
To: KELLEY@OFFICE-2.ARPA,
    HEADER-PEOPLE@MIT-MC.ARPA
Message-ID: <593610@UMich-MTS.Mailnet>
Subject: Body line length

Re:  Message-ID: <TYM-KIRK-610SV@OFFICE-2.ARPA>
     From: Kirk Kelley  <KIRK.TYM@OFFICE-2.ARPA>

Kirk,
Why do you reformat the body of the message at all?
We present whatever you send to the recipient. If you
send 1000 character lines that's what they see.  Why not
send it the way you want it seen and assume others have
done the same?

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA11974; Thu, 20 Dec 84 18:43:09 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.31)
	id AA17066; Thu, 20 Dec 84 18:50:44 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.31)
	id AA14990; Thu, 20 Dec 84 18:50:31 pst
Date: Thu, 20 Dec 84 18:50:31 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8412210250.AA14990@ucbopal.CC.Berkeley.ARPA>
To: Murray.pa@XEROX.ARPA
Subject: Re: Names with spaces
Cc: Header-People@mit-mc.ARPA

I am not confident that quotes will make it through all Unix mail
systems.  If a csh shell is called to process a mail command at the
command interpreter level the quotes may be lost unless action has been
taken to prevent this lost.

I suggest translating spaces to underlines going to Internet,
and underlines to spaces going in reverse.  This means you would
not be allowed to have underline(s) in local grapevine address.
This fix also allows local addresses with spaces to be sent
via other (non-Internet) mail networks (eg. UUCP) which used
space(s) as a delimiter between addresses.

Bill Wells
ucbvax!wcwells
wcwells@Berkeley.ARPA

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA12510; Thu, 20 Dec 84 19:22:46 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.31)
	id AA17704; Thu, 20 Dec 84 19:30:25 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.31)
	id AA15450; Thu, 20 Dec 84 19:30:15 pst
Date: Thu, 20 Dec 84 19:30:15 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8412210330.AA15450@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: Re: Body line length

AUTODIN (JANAP 128) limits: 72 max characters per line for narrative
messages (for all those model 28 Teletypes still in military service)
and 80 (ie. punched card) for data messages.  I think there may also
still be a 100 line limit.

PS. Message header fields can be greater that 80 characters. Watch out
for long from addresses in "Received:" header fields.

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2650562939819468@MIT-MULTICS.ARPA>; 28 Dec 1984 14:28:59 est
Date:        25 Dec 84 14:23 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA
Subject:     Names with spaces
Message-ID:  <84081@QZCOM>
In-Reply-To: <83786@QZCOM>

COM also has spaces in the names of people. If this is nasty
or not is something you can discuss. I think it is natural that
my name is "Jacob Palme" and would regard names like "JPALME"
or "P3" as unnatural and nasty.

With the COM RFCMail interface, we began sending out our names
as they were, with spaces in them, but then according to RFC821/822
with quotes on the names. This got us into many problems, since
many systems could not handle such names.

So now, we translate all spaces to underlines when sending out
names. My name is thus sent as Jacob_Palme%QZCOM@MIT-MULTICS,
and not as "Jacob Palme"%QZCOM@MIT-MULTICS.

When getting a name from the network, we translate underlines
into spaces before entering the names into the COM data base.
This has worked fairly well, except for one person who complained
she could not write to us because there was no way to generate
underlines on the keyboard of her IBM PC. Is this really true
of IBM PC-s?



Date: 31 Dec 1984 21:33:43 EST (Monday)
From: Marshall Abrams <abrams@mitre>
Subject: Soliciting members for a computer services committee
To: header-people@mit-mc, info-printers@mit-mc, info-rsts@mit-mc,
    info-terms@mit-mc, info-unix@brl, info-vax@sri-csl
Cc: self:@mitre, abrams@mitre

I am soliciting members for the IEEE Computer Society's Computer
Services Advisory Committee (CSAC). The function of the committee is
to advise the President and Governing Board on hardware, software, and
services to support office operations, provide member services, and
provide electronic mail services to members and officers. There are
two items presently on the agenda which might interest you and would
profit from your experience:

(1) The PDP 11/44 in the East Coast office and the Microdata in the
West Coast office are both approaching saturation. A suggestion being
considered is to purchase additional 11s. This would permit
utilization of existing software (which has proven satisfactory) and
DECNet interconnection when necessary. Replacing these existing
computers with VAXs has been suggested, but is currently not favored.
People experienced with DEC products would be quite valuable.

(2) The Computer Society provides an electronic mail service called
CompMail+ to its officers and employees to conduct Society business
and to members as an extra-cost benefit of membership. Quite favorable
rates were obtained as a result of a competative procurement. This
CompMail+ service as provided by Dialcom is in the process of being
re-evaluated. The contract may be re-competed. There is a very strong
interest in establishing a gateway between CompMail+, CSNet, and
ARPANET. Several alternatives are under investigation.

I hope to conduct as much committee business as possible via
electronic mail, so physical location should not be too much of a
problem. I think each of the two items discussed above will be handled
by separate sub-committees. A person could belong to either or both.
It is desirable, but not absolutely necessary, that volunteers be
members of the Computer Society.

Let me hear from you if you are interested.

Marshall Abrams
  abrams@mitre.arpa
  64:M.ABRAMS (on Dialcom)
  phone: 703/883-6938


Date:  2 Jan 1985 16:12:40 PST
From: POSTEL@USC-ISIF.ARPA
Subject: Domain Style Names
To:   Header-People@MIT-MC.ARPA


Hi.

We are getting ready to start using Domain Style Names.  Please see RFCs
920 and 921 for the procedures and schedule.  Anyone planing on using a
new name should prepare an application as indicated in RFC 920 and send
it to HOSTMASTER@SRI-NIC.ARPA on or after 15-Jan-85 (according to the
schedule in RFC 921).  New names may not be used until they are registered
(you get a note back from Hostmaster saying it is ok), and the new name
is listed in the data base of some domain name servers.

--jon.
-------

Date:  3 Jan 1985 16:44:47 PST
From: POSTEL@USC-ISIF.ARPA
Subject: What Domain For Me ?
To:   header-people@MIT-MC.ARPA


What domain name should i choose?

Suppose i am Fred Smith of Northern Oklahoma Technical University (known
far and wide as "N.O. Tech").

Suppose that N.O. Tech is connected to the Internet world via CSNET.  
That is,  suppose i have a little VAX running Berkeley 4.2 Unix as a 
"phone net" site of CSNET.

That means that a user on a typical Internet host currently can send 
mail to me using the address:

   Fred%NO-TECH@CSNET-RELAY.ARPA

Domain style names are coming.  What should i do about it?

In fact, i can get away with doing nothing.  The current address will 
probably work ok for some time to come.  And the CSNET management will 
almost certainly do someting about getting "CSNET" registered as a 
top-level or second-level domain (e.g., ".CSNET" or ".CSNET.EDU").

Let us assume that the CSNET management does get ".CSNET" registered as 
a top-level domain name.  In that case, users at typical internet hosts 
would be able to send me messages using the address:

   Fred@NO-TECH.CSNET

That looks like a great improvement!  It is a lot shorter.  It leaves 
out the business about a relay, and does not have any gratuitous mention
of ARPA.  It does somewhat imply that N.O. Tech is a member of 
(subservient to ?) CSNET.

Let us take a minute to review (generally) what happens when an Internet
host sends a message to the address "Fred@NO-TECH.CSNET".  First, the 
sending host looks up an internet address for "NO-TECH.CSNET".  It does 
this by asking a domain server about a mail address for "NO-TECH.CSNET".
The domain server replies (approximately) "mail for '*.CSNET' should be 
sent to 'RELAY.CSNET' at '10.4.0.5'".  Then the mail sending host opens 
an SMTP/TCP/IP connection to "RELAY.CSNET" and sends the mail to 
recipient "Fred@NO-TECH.CSNET".  Notice that there is nothing wired in 
about names ending in ".CSNET" using the relay host.  The lookup went 
through a perfectly general mapping in the server data base.

If i decided that N.O. Tech was the important thing , and that the fact 
that electronic mail got to me via CSNET was a mere technicality, i 
might want to down play the CSNET affiliation (or hide it completely).  
I could do this by applying to the management of the Education domain to
become "NO-TECH.EDU".  If this were approved my mail address would be:

   Fred@NO-TECH.EDU

The typical internet host would treat this in the same way as the 
previous case.  First, the sending host looks up an internet address for
"NO-TECH.EDU".  It does this by asking a domain server about a mail 
address for "NO-TECH.EDU".  The domain server replies (approximately) 
"mail for 'NO-TECH.EDU' should be sent to 'RELAY.CSNET' at '10.4.0.5'". 
Then the mail sending host opens an SMTP/TCP/IP connection to 
"RELAY.CSNET" and sends the mail to recipient "Fred@NO-TECH.EDU".

If, as is typical of important universities, N.O. Tech is affiliated 
with several electronic mail systems (e.g., MAILNET, BITNET, CSNET, 
UUCP, even ARPA-Internet), it would be somewhat difficult to choose one 
of them to be my primary address.  It will probably work for people to 
send me messages as "Fred@NO-TECH.BITNET" and "Fred@NO-TECH.MAILNET", 
etc (provided those are registered top-level domains).  But, what should
i put in as my "From:" address on mail i send out?  What should i put on
my business cards?  The solution is "Fred@NO-TECH.EDU".   This points 
out the advantage of using the domain style names as an administrative 
structure, independent of network topologies or protocol environments.

--jon.
-------

Received: from vax2.ucl-cs.ac.uk by 44a.Ucl-Cs.AC.UK   with SMTP  id a012554;
          4 Jan 85 17:35 GMT
To: POSTEL@usc-isif.arpa
cc: header-people@mit-mc.arpa
Subject: Re: What Domain For Me ?
Phone: +44-1-387-7050 ext 773
In-reply-to: Your message of 3 Jan 1985 16:44:47 PST.
Date: 04 Jan 85 16:56:09 GMT (Fri)
Message-ID: <1360.473705769@UCL-CS.AC.UK>
From: Steve Kille <steve@ucl-cs.arpa>

Jon,

The administrative model you put forward is surely what the user wants to
see.  Thinking in terms of academic institutions, rather than arpanet,
csnet, foonet etc. is good from the user's viewpoint.

An interesting, and common, case is how does joe@no-tech.edu
(connected say to csnet + mailnet) communicate with
fred@so-tech.edu (connected say to usenet + bitnet).
A simple approach is for all mail to pass thru a host with
direct access to a domain name server, with local
table/nameserver entries giving better paths to frequently
used domains.  My suspicion is that there are not enough
hosts with direct access to domain nameservers to make this
workable.

Use of a more physical domain structuring (unfortunately) makes
things just a little easier for a host which only has dialup
links to a few other places.  A pointer to an entry point
(e.g. which of two dialout links should be used)
to csnet (for example) can be determined (implicitly)
from the domain structure no-tech.csnet.   Routing within
csnet is then a private problem for the csnet  administration.
Ideally, administrators of csnet, usenet, mailnet, bitnet, janet,
arpanet, etc. would be evolving a solution appropriate to the
needs and realities of ALL the networks.  What is
missing with the Darpa scheme is a mechanism for deriving
sensible tables (nasty reality) to control a partially connected
network such as Usenet.  If the domain EDU (and other top
levels) were to be managed by an organisation which could deal
with all the nets, then it might be possible to build a
mechanism which has no 'phsical' domains (such as csnet) and still avoid
the problem noted in the previous paragraph.

Steve



Date: Fri 4 Jan 85 10:56:01-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: What Domain For Me ?
To: steve@UCL-CS.ARPA, POSTEL@USC-ISIF.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Steve Kille <steve@ucl-cs.arpa>" of Fri 4 Jan 85 16:56:09-PST
Location:  EJ286    Phone: (415) 859-2774

Regarding the taxonomical scheme for assigning top level domains, it
would be nice if it were planned to work according to Steve Kille's
example, but I think it is planned to have names more along the lines
of "joe@no-tech.csnet.edu", i.e. the user has to be concerned BOTH
with the physically-relevant domain structuring and the taxonomical
one.  I think this is clumsy, since it would be possible for the
currently proposed second-level domains to maintain an attribute
specifying taxonomical grouping, and then to dispense with the use of
the top-levels as domains at all.  The advantages of administrative
separation to be had by partitioning the world into groupings is not
significant when the number of groupings is so small (four).
The naming is unnecessarily lengthened for the user.  Supposedly,
users won't have to concern themselves with these names.  This
remains to be seen.
-------

Date: Sat 5 Jan 85 02:21:08-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: Names with spaces
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Thu 20 Dec 84 21:55:13-EST

    Message-Id: <8412210250.AA14990@ucbopal.CC.Berkeley.ARPA>

    I am not confident that quotes will make it through all Unix mail
    systems.  If a csh shell is called to process a mail command at the
    command interpreter level the quotes may be lost unless action has been
    taken to prevent this lost.

The Unix mailers around me *only* execute scripts with /bin/sh.  This
is pretty standard and should be adhered to everywhere.  The uux
commands are also executed with /bin/sh.

Greg Skinner
Gds@MIT-XX.ARPA
{allegra,cbosgd,ihnp4}!houxm!gregbo (UUCP)
-------

Date: Sat 5 Jan 85 03:01:58-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: What Domain For Me ?
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Steve Kille <steve@ucl-cs.arpa>" of Fri 4 Jan 85 16:56:09-EST

    From: Steve Kille <steve@ucl-cs.arpa>

    What is missing with the Darpa scheme is a mechanism for deriving
    sensible tables (nasty reality) to control a partially connected
    network such as Usenet.  If the domain EDU (and other top levels)
    were to be managed by an organisation which could deal with all
    the nets, then it might be possible to build a mechanism which has
    no 'phsical' domains (such as csnet) and still avoid the problem
    noted in the previous paragraph.

The problem with deriving sensible tables for USENET (UUCP acutally)
will be solved by the relay hosts between ARPA and UUCP.  As I
understand it, this is how things will work:

A user sends mail to gregbo@houxm.UUCP from somewhere.ARPA.

An SMTP connection is made to relay.UUCP (this may be harvard.ARPA or
ucbvax.ARPA -- I don't know).  

The message is delivered to relay.UUCP and marked for further delivery
to houxm.UUCP.

(Here's where things get interesting.)

There is a piece of Unix software which doubtless you have heard of
called pathalias, which takes information in the form of the most
up-to-date UUCP host tables and provides least-cost paths from the
site to all other UUCP sites.

At any rate, relay.UUCP will invoke pathalias (or a reasonable
front-end for it) requesting a least-cost path from relay to houxm.
The message can then be delivered to gregbo@houxm.  Most likely the
cheapest path will be ihnp4!houxm!gregbo (at least it ought to be).

UUCP will most likely be subdomained, so it may be possible to send
mail from ARPA to gregbo@houxm.ATT.  The SMTP connection should
probably still be to relay.UUCP since ATT will be a proper subset of
UUCP.  It is unlikely at first that relay.UUCP will open a UUCP
connection to relay.ATT (because it may actually be cheaper for
relay.UUCP to deliver a message to some-other-machine.UUCP which can
deliver a message cheaply to gregbo@houxm.ATT) but as I understand it
there is a UUCP project which will handle such subdomaining.

The main point of this, I guess, is that just like the rest of the
top-level domains, the UUCP domain, if it ever comes into existence
will utilize mail software at the gateways for relaying mail.  UUCP
will, for all intents and purposes, appear as a fully-connected
network.

As an example, send mail someday to houxm!gregbo@harvard.ARPA (which
is rather close to what the acutal address should look like --
gregbo@houxm.UUCP) and it will be delivered to me at houxm.  Note that
there is no harvard->houxm UUCP connection (there is, however, an
houxm->harvard connection) so the pathalias software will provide a
cheap route from harvard to houxm, and it will be invisible to the
sender of mail.

I hope this clears things up.

Greg Skinner
Gds@MIT-XX.ARPA
{allegra,cbosgd,ihnp4}!houxm!gregbo or should I say
houxm!gregbo@harvard.ARPA?
-------

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2651167399472676@MIT-MULTICS.ARPA>; 04 Jan 1985 14:23:19 est
Date:        04 Jan 85 13:44 +0100
From:        Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             "Kirk Kelley" <KIRK.TYM@OFFICE-2.ARPA>, "William G. Martin"
              <WMARTIN@SIMTEL20.ARPA>
Cc:          HEADER-PEOPLE@MIT-MC.ARPA
Subject:     Re: Body line length
Message-ID:  <84819@QZCOM>
In-Reply-To: <83790@QZCOM>

I don't agree with your wish to see all messages cut down to
80 col's. I might want to use the message network to send a
document that is to be output on a lineprinter (or a 132-wide
screen), I do not want the transporting network to intervene.

The funtion of re-formatting a document should be a user-level
application level feature, I might use different output medias
from time to time.




Date:     Tue, 8 Jan 85 11:28:42 EST
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       Greg Skinner <Gds@MIT-XX.ARPA>
cc:       header-people@MIT-MC.ARPA
Subject:  Re:  What Domain For Me ?

Actually a better scenario is that if you want to send mail to the
houxm.UUCP, you connect to the UUCP domain name server host.  It returns
you the address of the most appropriate relay machine.  After it gets
plopped onto the relay mahine, the rest of your message about what the
relay host decides to do with the message holds.

-ron


Date: Wed 9 Jan 85 08:43:41-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: bug in Berkeley
To: Postmaster@UCB-VAX.ARPA, Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     UCB-VAX is now sending messages with "Berkeley.ARPA" in its
message headers.  I would appreciate it if this was fixed; this is
INVALID since Berkeley is a nickname and Berkeley.ARPA is undefined.
-------

Received: from 44d.ucl-cs.ac.uk by 44a.Ucl-Cs.AC.UK   with SMTP  id a025719;
          22 Jan 85 12:47 GMT
Received: from hcig.nott.ac.uk by 44d.Ucl-Cs.AC.UK   via Janet with NIFTP
           id a004773; 22 Jan 85 12:45 GMT
Received: from CS.Nott.AC.UK by Hcig.Nott.AC.UK   via Phonenet  id a004304;
          22 Jan 85 12:41 GMT
Received: from Tuck.Maths.Nott.AC.UK by Robin.Cs.Nott.AC.UK   via PHONENET
           id a016599; 22 Jan 85 12:39 WET
Date: 22 Jan 85 12:38:22 UT (Tue)
To: header-people@mit-mc.arpa
Subject: The MODEM communications package
From: Tim Lee <tdl%cs.nott.ac.uk@ucl-cs.arpa>
Sender: Tdl%maths.nott.ac.uk@ucl-cs.arpa

   I am trying to trace a public domain communications package for CP/M
machines and MS-DOS.  The different versions of the suite are called
MODEM and MODEM7, and appear to have been written by Irvin Hoff and
Christopher Rhodes.  Does anyone know of a supplier/distributer of this
for the Osborne Executive, Epsons and IBM clones.
   Sorry if this is not the best list to mail.

Tim Lee



Date: Tue, 22 Jan 85 19:38:35 est
From: ukma!david@ANL-MCS.ARPA (David Herron, NPR Lover)
Subject: Re: The MODEM communications package.
Return-Path: <ukma!david@ANL-MCS.ARPA>
Message-Id: <8501230038.AA15502@ukma.UUCP>
Received: by ukma.UUCP (4.12/4.7) id AA15502; Tue, 22 Jan 85 19:38:35 est
To: header-people@MIT-MC.ARPA

Since the headers gave no clue on how to get back to this person....

	
	   I am trying to trace a public domain communications package for CP/M
	machines and MS-DOS.  The different versions of the suite are called
	MODEM and MODEM7, and appear to have been written by Irvin Hoff and
	Christopher Rhodes.  Does anyone know of a supplier/distributer of this
	for the Osborne Executive, Epsons and IBM clones.
	   Sorry if this is not the best list to mail.
	
	Tim Lee

They were actually written by Randy <something> and Ward Christiansen.
They run on CP/M machines.  You can call up an RBBS somewhere and
they might have a copy.  Or you can get ahold of the CP/M users group
and they have it on one of their disks.  (Or there is a similar
group for IBM users).  Failing all that, SIMTEL-20.ARPA keeps
archives of micro stuff.  They may be able to help you.
(Keith Peterson <W8SDZ@SIMTEL-20.ARPA> is the keeper of the archives there).

		David Herron

		david%ukma.uucp@anl-mcs.arpa
		cbosgd!qusavx!ukma

Date: 5 Feb 85 13:49:52 EST
From: dca-pgs @ DDN1.ARPA
Subject: Question on Probability of Keyboard Error
To: works @ rutgers.arpa, sun-spots @ rice.arpa, apollo @ yale.arpa, header-people @ mit-mc.arpa
CC: dca-pgs @ DDN1.ARPA


Is there a widely accepted human-factors number on
probability of typing error with either/both of
the density variables being (1)time, (2)characters to be
typed?

Are there any good references on the subject?

Thank you,
Pat Sullivan
DCEC
Reston, VA


Return-Path: <hadron!jsdy@seismo.ARPA>
Received: from hadron.UUCP by seismo.ARPA with UUCP; Wed, 6 Feb 85 13:32:18 EST
Received: by hadron.UUCP (4.12/4.7)
	id AA28095; Wed, 6 Feb 85 12:25:52 est
Date: Wed, 6 Feb 85 12:25:52 est
From: hadron!jsdy@seismo.ARPA (Joseph S. D. Yao)
Message-Id: <8502061725.AA28095@hadron.UUCP>
To: seismo!HEADER-PEOPLE@MIT-MC.ARPA, seismo!MMM-PEOPLE@USC-ISIF.ARPA,
        seismo!MsgGroup@BRL.ARPA
Subject: Sendmail-like entity on System V?

I'm not (yet) on this newsgroup, so any responders will have to mail
to me directly at the address below.  We very much like the way that
sendmail on 4BSD works (at least, usually).  One of our folk, however,
has to use some System V machines.  I was wondering if there was a
version of sendmail for S-V?  (He wants it last week, of course.)

Appreciate any info.  If this hasn't already been on the net, I'll
summarise and put it back out.

Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

Date:     Wed, 6 Feb 85 16:36:00 EST
From:     Doug Kingston <dpk@BRL-TGR.ARPA>
To:       "Joseph S. D. Yao" <jsdy%hadron.uucp@seismo.ARPA>
cc:       header-people@mit-mc.ARPA, mmm-people@usc-isif.ARPA, msggroup@brl.ARPA
Subject:  Re:  Sendmail-like entity on System V?

	MMDFII has been ported to System V on the Vax.  I suspect
it will also work with little work on other 32bit System V implementatins.
MMDFII will be released in the near future through BRL and UCL-CS under
minimal licensing.  Stay tuned for an announcement (1 - 2 weeks from
now).  MMDFII in a entire mail system including an MSG/SEND style
user interface, (Cap)Mail user interface, a uucp channel, a TCP/SMTP
channel, an EAN channel, a NIFTP channel, a list-processor, a Phonenet
channel, and a powerful local delivery facility.

					-Doug-

Received: from Mission.ms by ArpaGateway.ms ; 08 FEB 85 10:09:56 PST
Date: 8 Feb 85 10:09:53 PST (Friday)
Subject: Re: problem with WISCVM gateway
In-reply-to: F33PAP%DHHDESY3.BITNET's message of 850208.082825 GMT
To: F33PAP%DHHDESY3.BITNET@WISCVM.ARPA
cc: HEADER-PEOPLE@MIT-MC.ARPA, INFO-NETS%MIT-OZ@MIT-MC.ARPA,
 Hamilton.ES@XEROX.ARPA
From: Bruce Hamilton <Hamilton.ES@XEROX.ARPA>

[Sorry if this has been thrashed out already on HEADER-PEOPLE; I'm not
on that list.]

For what it's worth, the "Date" field in your msg:

Subject: European Internal Networks
Date:    850208.082825 GMT

in your header probably does not meet any of the various ARPAnet
RFC822-acceptable formats, because my mail program can't handle it.  Is
there somebody at WISCVM who can upgrade their gateway software from
BITNET to munge the date properly?

--Bruce

Received: from (ARNOLD)WISCPSLB.BITNET by WISCVM.ARPA on 02/08/85 at
  14:21:52 CST
Date: 8 FEB 85 14:05-CDT
From:  ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA
To:  header-people@mit-mc
Cc:  ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA
Subject: Please add me to the list

Please add me to the list.

Steve Arnold, Joiner Associates Inc.
ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA

Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/08/85 at
  16:05:22 CST
Date: Fri, 8 Feb 85 13:56:27 PST
From:   David Alpern  <ALPERN%SJRLVM4.BITNET@WISCVM.ARPA>
To:  Header-People@MIT-MC.ARPA
cc:  stef@udel.arpa ,
    mrose@udel.arpa
Subject: RFC 934 - Message Encapsulation

I'm bothered by the choice made in the message separator (EB) as
described in this document.  Most digests currently do hold quite well
to a standard of using either 70 or 30 hyphens alone on a line,
with a blank line on either side.  This is specific enough to avoid
confusing user text with separators.  Defining a hyphen in the first
column of a line, with no other restrictions, as a separator seems
like asking for ambiguity.  Most front end programs will not be changed
to "stuff" mail being sent for the first time, nor will most mail
reader software "unstuff".

As a proposal, may I suggest a line which starts with 5 hyphens in
sequence followed by a space and an asterisk, ends with the reverse,
and has a total length of 68.  This is much harder for a user to hit
randomly, would be easy for the user to avoid, and yet still allows
for some text field within the separator.

I think it would be worthwhile to define the standard in such a way
that mail reading programs could tell, almost without ambiguity, if
a message contained embedded messages.  Then, depending on the user
interface and the user's desires, the system could either break such
messages automatically or on user command.  Using the single hyphen
separator it will be too likely for a single message to get broken
at a list bullet or just above a "signature" (notice my own, which
I've used this way for ages - if "unstuffed", this hyphen will disappear
-and if I forget the space, the file gets split).

- Dave

     David Alpern
     IBM San Jose Research Laboratory, K65/282
     5600 Cottle Road, San Jose, CA 95193
     Phone: (408) 284-6521
     Bitnet: ALPERN@SJRLVM4
     CSnet:  ALPERN@IBM-SJ

Received: From udel-dewey.ARPA by udel-louie.ARPA id a017133 ;8 Feb 85 23:15 EST
To: David Alpern <ALPERN%SJRLVM4.BITNET@WISCVM.ARPA>
cc: Header-People@MIT-MC.ARPA
Reply-To: header-people@MIT-MC.ARPA
Subject: Re: RFC 934 - Message Encapsulation
In-reply-to: Your message of Fri, 8 Feb 85 13:56:27 PST.
Date: 08 Feb 85 23:16:57 EST (Fri)
Message-ID: <4057.476770617@udel-dewey>
From: Marshall Rose <mrose%udel-eecis2.delaware@udel-louie.ARPA>

Unfortunately, requiring more dashes just makes the problem
harder and introduces additional ambiguity.  Let me explain.
A primary motivation for writing that RFC was that I was
getting tired of constantly modifying the bursting agent in MH.

First, I tried looking for 5 dashes at the beginning of a line.
Sure enough, some digests let that through.  Then I upped it to 30.
Sure enough, some digests let that through.  Then I got clever and
introduced special heuristics based on the number of blank lines
both preceeding and following the line that started with the dashes.
Still not good enough.  I then decided to look at least TWO LINES ahead
and see if I could find what looked like a header.  Still no good,
one day someone just happened to have a couple of blank lines, a line
of dashes, a couple of blank lines, all followed by a line that looked like
a header.  Brute force and extremely clever coding just can't compete.

So, I decided that we need to bit (well, byte) stuff.  This is the ONLY
way to unambiguously separate messages in a digest (or a forwarding of
messages, in general).  So, if you're going to change all that software in
net to be considerate and generate digests etc., that other software can
burst, then you might as well make the change as simple as possible.
Hence, the choice of a single dash for the EB.
The RFC contains very simple algorithms to byte-stuff on encapsulation
and to burst on decapsulation.  The latter algorithm, in fact, needs
only one character look-ahead.

The point of all this is that I want to get painless bursting with the
absolute LEAST amount of effort on the part of the mail hackers in the
net.  I really don't think it's too difficult to look at the beginning of
each line and output a "- " if it starts with a "-".

/mtr

Date:     Fri, 8 Feb 85 20:31:50 EST
From:     Ron Natalie <ron@BRL-TGR.ARPA>
To:       Bruce Hamilton <Hamilton.ES@XEROX.ARPA>
cc:       F33PAP%DHHDESY3.BITNET@WISCVM.ARPA, HEADER-PEOPLE@MIT-MC.ARPA, 
          INFO-NETS%MIT-OZ@MIT-MC.ARPA, Hamilton.ES@XEROX.ARPA
Subject:  Re:  problem with WISCVM gateway

Various ARPAnet format?

There is only 1.


Date:  Sat, 9 Feb 85 17:05 EST
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: RFC 934 - Message Encapsulation
To:  mrose%udel-eecis2.delaware@UDEL-LOUIE.ARPA
cc:  header-people@MIT-MC.ARPA
Message-ID:  <850209220524.599492@MIT-MULTICS.ARPA>

I have to agree with David Alpern.  A common two-character sequence
should not be pre-empted this way.  A longer sequence is less likely to
be used in messages.

Actually, the problem is not in the sequence chosen.  The problem is
that it is not possible for the Bursting Agent to tell whether the
sending software includes an Forwarding Agent.  If not, then the sender
won't have translated lines beginning with a hyphen, but your reader
will decide that the message contains encapsulated messages and burst
it.  The right solution is to require Encapsulation Agents to add a
header field, such as

Encapsulation-Boundary:  <string>

If this header field is not present, then the message does not contain
an RFC934-conformant encapsulation, and the Bursting Agent should just
pass it through unchanged.  If it does, then a line beginning with
<string> is an encapsulation boundary.  As in the original RFC, if the
<string> is followed immediately by a space then it is an escape prefix
and the Bursting Agent should merely remove it from the text.

I don't really think it is important that the EB be variable, as in my
example.  The only reason I included that capability was because I was
inventing a header field and I couldn't think of anything else to put
there.  Another possibility is:

Encapsulation-Mode:  RFC-934

which allows for future enhancement of this protocol.
                                        barmar

Date: 9 Feb 1985  16:31 MST (Sat)
Message-ID: <WANCHO.12086406097.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   mrose%udel-eecis2.delaware@UDEL-LOUIE
Cc:   header-people@MIT-MC
Subject: RFC 934 - Message Encapsulation

Marshall,

Notwithstanding the relative merits of certain portions of this RFC, I
was rather surprised that you cited the lack of a standard format,
particularly the Encapsulation Boundary, as the primary motivation to
write this RFC in the first place.  There has been a de-facto standard
in use since the first digest appeared several years ago, and a
complementary UnDigestify command by Gail Zacharias (GZ@MC) for those
of us who use BABYL.  A couple of years ago, Mike Muuss (mike @BRL)
developed an UnDigestify for Unix/MMDF msg.  (There is even an option
to permit automatic detection and UnDigestification along with an
UnDo, just in case it guessed wrong.)  Whenever a new digest appears,
the moderator soon finds out whether or not the digest message was
formatted correctly.  Thus, although the original digests came first,
it has been those of us who have an UnDigestify command who tend to
"enforce" conformance to this "standard" format.

I suspect that had you asked, you would have been able to develop a
similar UnDigestify command for your mail handler instead of producing
yet another proposed standard that seems to ignore the existing one.

All of the above is not meant to say that the entire RFC is not
without merit.  There is something to be said in favor of the proposed
method of handling Bcc:s, Forwarded, and ReMailed messages, and the
implied extension of the UnDigestify command to handle the latter two
cases.  However, please don't overlook the fact that an extension to
an existing command has a better chance of being acceptable to the
community than a rewrite would...

--Frank

Received: from Cabernet.MS by ArpaGateway.ms ; 09 FEB 85 15:42:35 PST
Date: 9 Feb 85 15:42:23 PST
From: Murray.pa@XEROX.ARPA
Subject: Re: problem with WISCVM gateway
In-reply-to: "ron@BRL-TGR.ARPA's message of Fri, 8 Feb 85 20:31:50 EST"
To: Ron Natalie <ron@BRL-TGR.ARPA>
Cc: Bruce Hamilton <Hamilton.ES@XEROX.ARPA>,
 F33PAP%DHHDESY3.BITNET@WISCVM.ARPA, HEADER-PEOPLE@MIT-MC.ARPA

There may be only one date format in the specs, but reality is a lot
different.

When our header munger encounters a header that it can't parse, it can
send me a message including a copy of the pesky header. Occasionally
it's a bug in the parser. Normally it's a mail generating program that
doesn't play by the rules. Crazy dates are quite common, and this is
after our parser has been patched to know about the common illegal
formats.

I'll collect some samples if you want any data. (I'll even unpatch the
parser if you want a lot of data.)

And if you think there is a standard for dates.... I'm still amazed at
the number of messages that come through with "at" where there should be
an "@".



Date:     Sun, 10 Feb 85 1:33:28 EST
From:     Doug Kingston <dpk@BRL-TGR.ARPA>
To:       "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
cc:       mrose%udel-eecis2.delaware@UDEL-LOUIE.ARPA, header-people@MIT-MC.ARPA
Subject:  Re:  RFC 934 - Message Encapsulation

I agree with many of the comments made so far on RFC924.  First, their
is a defacto standard for which there exists working software.  Second,
a single dash is a poor choice of separater since it is highly likely
that a) it will be used in message text by the user in such a way as to
be mistaken for a separator, and b) unbursting will not be universially
installed.  People who don't unburst will use "-" poorly and the
bursters will burst badly.

I like the stuff on handling bursted contents.

					-Doug-

Received: From udel-dewey.ARPA by udel-louie.ARPA id a006628
          ;10 Feb 85 22:14 EST
Reply-To: header-people@MIT-MC.ARPA
To: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>, Doug Kingston <dpk@BRL-TGR.ARPA>
cc: header-people@MIT-MC.ARPA
Subject: Re: RFC 934 - Message Encapsulation
In-reply-to: Your message of Sun, 10 Feb 85 1:33:28 EST.
Date: 10 Feb 85 22:16:03 EST (Sun)
Message-ID: <4057.476939763@udel-dewey>
From: Marshall Rose <mrose%udel-eecis2.delaware@udel-louie.ARPA>

Frank,

    I am aware of the software you mentioned (in particular Mike's
    code), and it is true that everyone who posts digests seems to be
    using the same rules for encapsulating messages into digests. In
    this case perhaps the use of the term "pseudo-standard" by the RFC
    is unfortunate.  Stef and I did not (at least intentionally) ignore
    what others had done and decide to introduce "Yet Another Standard"
    that ignores what's working now.  We went to great lengths to try
    and remain compatible with existing Internet software to minimize
    compliance problems.

    However, there is a larger issue which I am apparently missing in
    the your and Doug's and Barry's comments:

	 It really is unimportant as to the precise string that is used
	 for an EB.  The important thing is that when that string
	 appears in a message being encapsulated into a digest (or
	 forwarding in general), that the encapsulation agent use some
	 escape mechanism to prevent the bursting agent from declaring
	 an end-of-message prematurely.

    Now, if the BABYL software (and any other software used to do
    encapsulation) does that correctly, then the primary motivation for
    the RFC is a non-problem.  Hurrah.  However, I have noticed in the
    past that every now and then a message containing a blank line, a
    line of dashes, another blank line, and a line with something that
    remotely looks like a header slips through digests like HUMAN-NETS
    and TELECOM.  (This isn't an attack against either group, I just
    happen to recall a couple of instances in each list about six to
    eight months ago where this happened). So, there might exist
    "working software", but if EBs aren't byte-stuffed then you can't
    unambiguously de-capsulated messages and "it doesn't work right".

    To repeat (though re-phrase) what the RFCs says and what my last
    message said:

	 All I really want is encapsulation agents to byte-stuff their
	 EBs.  If you want to use 30 or 50 dashes on a line as an EB
	 fine.  That isn't prohibited by the RFC.

    If everyone does the byte-stuffing, then the choice of an EB
    becomes moot.

    As I clear my throat to change the subject, I'm interested if there
    are comments on the unification of forwardings, distributions, and
    blind-carbon-copies.  The latest (and hopefully last) release of
    MH, MH.5 uses encapsulation in the generation of Forwardings and
    BCC:s.  Although it sounds esoteric, being able to recursively
    forward forwarded messages is rather neat.

/mtr

Received: from (F33PAP)DHHDESY3.BITNET by WISCVM.ARPA on 02/11/85 at
  02:53:31 CST
Date:    11 FEB 85  09:36:21 MEZ
From:  F33PAP%DHHDESY3.BITNET@WISCVM.ARPA
To:  INFO-NETS%MIT-OZ@MIT-MC.ARPA
Cc:  HEADER-PEOPLE@MIT-MC.ARPA
Subject: DATE STAMPING

O.K.
P.S.: Sorry my header generator cannot make small letters in the text.


Date: 11 Feb 1985 11:04:37 EST (Mon)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: RFC 934 - Message Encapsulation
To: Marshall Rose <mrose%udel-eecis2.delaware@udel-louie.ARPA>
Cc: Header-People@MIT-MC.ARPA
In-Reply-To: Marshall Rose's message <4057.476770617@udel-dewey>
Message-Id: <476985877/hoey@nrl-aic>

Marshall,

I am surprised that you say

    ... we need to bit (well, byte) stuff.  This is the ONLY
    way to unambiguously separate messages in a digest (or a forwarding of
    messages, in general).

I have previously indicated to you that there is a way to entirely
avoid modification of the text of messages.

Header People,

The method I proposed was for the Forwarding Agent to choose an
encapsulation boundary that does not occur in the messages to be
encapsulated.  Barry Margolin's proposal of indicating the chosen EB in
the header is an appropriate way of communicating the choice to the
Bursting Agent.  However, the use of this boundary followed by a space
for stuffing is not necessary.

An algorithm for choosing the EB:

    1.  Form a list of trial EB's.  I suggest the trial EB's be
	- twenty hyphens,
	- twenty hyphens followed by the current date and time, and
	- twenty hyphens followed by twenty randomly-chosen
		alphanumeric characters.

    2.  Scan the messages to be encapsulated for occurrences of the trial
        EB's.

    3.  If all of the trial EB's were found, fail.  (If messages are
	being encapsulated at a rate of a megabyte per second, this step
	should be taken fewer than once every quintillion centuries,
	barring hardware failure.)

    4.  Return the first of the trial EB's not found in any message.

Dan

Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/11/85 at
  11:35:38 CST
Date: Mon, 11 Feb 85 09:11:13 PST
From:   David Alpern  <ALPERN%SJRLVM4.BITNET@WISCVM.ARPA>
To:  header-people@MIT-MC.ARPA
cc: Marshall Rose <mrose%udel-eecis2.delaware@udel-louie.ARPA>
Subject: Re: RFC 934 - Message Encapsulation
In-Reply-To: Message of 08 Feb 85 23:16:57 EST (Fri) from Marshall Rose
     <mrose%udel-eecis2.delaware@udel-louie.ARPA>
References: <4057.476770617@udel-dewey>, and My message of Fri, 8 Feb
     85 13:56:27 PST.

Marshall,

I understand your point, in that no digests that I know of prevent
a message sender from including a line of 30 hyphens that is not
meant as a separator.  On the other hand, I don't forsee us ever
getting all mail sending and reading programs on the net to "stuff".
To do this properly, it would have to be not only digestifiers/
undigestifiers, but all sending/receiving programs since nothing other
than the presence of a separator indicates a forwarded message.

I disagree that one could use the 30 hyphen field simply as one special
case of the single hyphen definition.  The problem here is that not
all software will be changed at once - you will be lucky if most ever
is.  How will the first "unstuffer" tell if it has a separator or a
text hyphen - i.e. if the sender "stuffed"?

Maybe the right thing is to ask all digest creators and mail forwarders
to add a hyphen to any line containing exactly 30 hyphens alone in an
entering message.  This will help avoid the ambiguity, and will be useful
even if accomplished in a very gradual manner.  I doubt many will care
if a line they send as 30 hyphens gets seen as 31, although there always
will be somebody.

This does lead to a question however -- how do we want to handle a
forwarded message being sent to a digest, or otherwise reforwarded?
I, for one, would first want to see the complete message (both forwarded
and surrounding) as a single entity within a burst digest, and yet would
like the ability to burst it again when I desired.  Any bright ideas?
Maybe using Barry Margolin's header-line specification of separator,
combined with some "lenghten the separator for each embedded message
level" algorithm will permit this.

Regarding the other aspects of the RFC, i.e. treating forwarded messages
in the same manner as digests -- I LIKE!  I agree that currently
forwarded messages are not too useful until one does separate the
original text from the surrounding message.  There are, however, cases
where one would like to reply to both the original sender and the
forwarder at once, which is not easy with your scheme as is.  As an
informal suggestion, I'll comment that both my undigestifier and the
similar code I use for forwarded messages (less useful because of less
of a pseudo-standard) add a LIST: field to the header of the embedded
messages to specify either the discussion group or the forwarding sender,
and my reply code notices this.

- Dave

     David Alpern
     IBM San Jose Research Laboratory, K65/282
     5600 Cottle Road, San Jose, CA 95193
     Phone: (408) 284-6521
     Bitnet: ALPERN@SJRLVM4
     CSnet:  ALPERN@IBM-SJ

Date: 11 Feb 1985  12:09 MST (Mon)
Message-ID: <WANCHO.12086882676.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   Header-People@MIT-MC
Subject: Message Encapsulation

The digests originating from Rutgers use a program to generate them.
The program produces a line of 70 hyphens as the Topic Separator, and
a line of 30 dashes as the Message Separator.  Each Separator includes
a blank line before and after the line of hyphens.  As it processes
each message to be encapsulated, it removes any trailing lines of
hyphens.

BABYL's UnDigestify command takes the first occurrance of a line of 65
to 85 hyphens as the Topic Separator and automatically flushes any
immediately preceding blank lines.  The remainder of the message is
assumed to be a collection of one or more encapsulated messages
separated by a line of 27 to 33 hyphens.  Blank lines following the
separator are also removed in the process.  Other trailing blank lines
that occurred before the Message Separator in the resulting messages
are discarded as an inherent part of the normal BABYL message
processing.

--Frank

Date: 11 February 1985 15:59-EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject:  Message Encapsulation
To: HEADER-PEOPLE @ MIT-MC
In-reply-to: Msg of 11 Feb 1985  12:09 MST (Mon) from Frank J. Wancho <WANCHO at SIMTEL20.ARPA>

A minor correction to Frank's description: Babyl's UnDigestify command
assumes that the encapsulated messages are separated by a blank line
followed by a line of 27-33 dashes.  The reason for the blank line is to
allow one of the most common in-text use of dash sequences, which is to
underline portions of the text.
---------

Note that this underlining usage is one example of a situation where the user
would indeed object to the mail system changing the exact number of dashes
or inserting spaces or other characters in front of the dashes.

I have to agree that the most important thing is to have the fact of
encapsulation noted somewhere in the message, like in the header.  If the
sender can communicate the encapsulation method to the recipient, the
actual method used is less of an issue.  It should be up to the sender to
decide whether to make the EB unique by varying the EB or munging the
messages.

Date: Mon 11 Feb 85 18:25:20-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: lowercase host names
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I would like to consign to eternal damnation all these mailers
which think it is cute to use lowercase in host names.  Perhaps their
implementors should also suffer such damnation, but I'll settle for
mandatory schooling in human factors.

     Many terminals do not satisfactorily show the difference between
"1" (the numeral) and "l" (the letter).  On the terminal I'm using,
the difference is a single pixel.  It is not at all obvious that
"nyu-cmcl2" is "NYU-CMCL2" instead of "NYU-CMC12".  Those long UUCP
addresses get even worse.

     Getting a terminal with a better font is NOT the answer.
-------

Date: Mon 11 Feb 85 18:39:32-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: lowercase host names
To: MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Mon 11 Feb 85 18:31:52-PST
Location:  EJ286    Phone: (415) 859-2774

I would like to agree with Mark.  It has long been the custom
that  acronyms are capitalized.  Why should  Massachussetts Institute
of Technology, Macsyma Consortium (MIT-MC), Stanford University,
Artificial Intelligence (SU-AI),  Bolt, Beranek and Newman Communications
Corporation-F  (BBNCCF), and the like NOTE be subject to conventions
that have been established since the middle ages.  (Did they have
Acronyms in the Middle Ages?  Did they name things with contractions
composed of the first letter of each word in a title?)
has anyone looked at host names and considered how high a percentage
are ACRONYM-based?
-------

Received: from SCRC-HUDSON by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 176804; Tue 12-Feb-85 11:14:49-EST
Date: Tue, 12 Feb 85 11:10 EST
From: hornig@SCRC-QUABBIN.ARPA
Sender: joseph@SCRC-QUABBIN.ARPA
Subject: Re: lowercase host names
To: David Roode <ROODE@SRI-NIC.ARPA>, MRC@SU-SCORE.ARPA,
    Header-People@MIT-MC.ARPA
In-Reply-To: The message of 11 Feb 85 21:39-EST from David Roode <ROODE@SRI-NIC.ARPA>
Message-ID: <850212111029.5.JOSEPH@HUDSON.SCRC.Symbolics.COM>

    Date: Mon 11 Feb 85 18:39:32-PST
    From: David Roode <ROODE@SRI-NIC.ARPA>

    I would like to agree with Mark.  It has long been the custom
    that  acronyms are capitalized.  Why should  Massachussetts Institute
    of Technology, Macsyma Consortium (MIT-MC), Stanford University,
    Artificial Intelligence (SU-AI),  Bolt, Beranek and Newman Communications
    Corporation-F  (BBNCCF), and the like NOTE be subject to conventions
    that have been established since the middle ages.  (Did they have
    Acronyms in the Middle Ages?  Did they name things with contractions
    composed of the first letter of each word in a title?)
    has anyone looked at host names and considered how high a percentage
    are ACRONYM-based?
    -------

I will accept this line of reasoning only if people are also willing to
allow hosts with names which are not acronyms to not be capitalized as
if they were.  I used to be the liaison for MIT-devMultics (capitalized
just so).  It was generally referred to by other hosts as MIT-DEVMULTICS
or Mit-Devmultics, both incorrect.

My mailbox now lives on SCRC-Stony-Brook.ARPA (soon to be
Stony-Brook.SCRC.Symbolics.COM).  I haven't even bothered to make our
own mailer deal with that.

Received: from (ALPERN)SJRLVM4.BITNET by WISCVM.ARPA on 02/12/85 at
  12:09:25 CST
Date: Tue, 12 Feb 85 09:58:09 PST
From:   David Alpern  <ALPERN%SJRLVM4.BITNET@WISCVM.ARPA>
To:  Header-People@MIT-MC.ARPA
Subject: Forwarded mail from Kenneth Sloan <sloan@uw-tanga.arpa>

=== Begin message text ===

Date: 11 Feb 1985 17:03-PST
From: Kenneth Sloan <sloan@uw-tanga.arpa>
Subject: Re: RFC 934 - Message Encapsulation
To: David Alpern  <ALPERN%SJRLVM4.BITNET@wiscvm.arpa>
In-Reply-To: David Alpern's message of Mon, 11 Feb 85 130843 PST

David-

Well, I probably don't have my note anymore - sadly, I find that I
don't have time to participate in these RFC debates.  If you still have
a copy, you may do with it what you want, including posting it.

As for "how to break from" in-band signalling, I support the idea of
using a unique (to a particular message) character sequence, which is
specified in a header field.  I reject (on principle) any scheme which
requires modifying the text of a message.

I would prefer a scheme in which the message breaks were listed in the
header (say, by line number).  Something like:

    Break-On: 1, 53, 105, 259, 711, 911

However, that seems to be politically incorrect...

Keep on fighting the good fight.

-Ken Sloan

=== End message text ===


Date:  Tue, 12 Feb 85 14:40 EST
From:  "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject:  capitalization
To:  header-people@MIT-MC.ARPA
Message-ID:  <850212194020.750425@CISL-SERVICE-MULTICS.ARPA>

Why in seven hells do these cute-as-a-shithouse-rat mailers insist on
touching the text of the destination host name at all?  Why not make the
rules be "match case insensitive, but preserve what the sender sent?"

Date: 12 Feb 1985 13:26-PST
Sender: GEOFF@SRI-CSL
Subject: Re:  capitalization
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To: Margulies@CISL-SERVICE-MULTICS
Cc: header-people@MIT-MC
Message-ID: <[SRI-CSL]12-Feb-85 13:26:06.GEOFF>
In-Reply-To:  <850212194020.750425@CISL-SERVICE-MULTICS.ARPA>

I'm with you Benson.

As I recall, it all started years ago when Dave Crocker thought it was
a "good idea" to cutesy-up host names and put code in the MMDF mailer.
Since then, the affliction seems to have grown and spread.  Can we
kill the epidemic before it becomes inter galactically offensive?

g

Date: 12 Feb 1985 20:23:38 PST
From: POSTEL@USC-ISIF.ARPA
Subject: re: lower case host names
To:   header-people@MIT-MC.ARPA


The case of characters in hosts names is not significant.  That is, names
are to be recognized independent of case.  If some host likes to use its
name in a mixed case style (e.g., MIT-devMultics), that is fine, but it
can't complain that some other caseification makes it's name somehow wrong
(e.g., MIT-DEVMULTICS or Mit-Devmultics are still legal names for that host).

[As an aside, for years the Multics hosts insisted that the name of my
host was "USC-ISIf" (note the lower case f).  No one at ISI ever suggested or
liked that name.  And for a long time we couldn't get the Multics people to
change it.  As far as i can tell it was the Multics people who started silly
caseification of host names.] 

One thing that does happen to host names is that they are required to be the
official names, not nick names or locally used aliases.  Sometimes a program
fixes this by using the host tables to convert the given name into a number
(internet address) then convert the number into the official name.  Thus you
end up with the caseification that was in the host table on the host where
the fix was performed.

--jon.
-------

Date: Wed 13 Feb 85 01:20:12-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: capitalization
To: header-people@MIT-MC.ARPA

I agree with what was said about retaining case insensitivity while
also retaining the original header information.  A friend of mine was
unkindly flamed at by the mailer at ihnp4 which had rejected a legal
address sent to me at houxm via ihnp4, excepting the fact that all the
host names had been capitalized.  The mail software running at ihnp4
was case sensitive, causing the messages to fail, however the sending
agent (the VMS mailer on mit-jcf) had no business capitalizing the
address my friend supplied, which was in lowercase.

--gregbo
gds@mit-xx.arpa
gregbo%houxm.uucp@harvard.arpa
{allegra,cbogsd,ihnp4}!houxm!gregbo
-------

Date: Wed 13 Feb 85 00:45:45-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: nicknames not allowed in headers
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Let's not forget the offically sanctioned exception to this,
BERKELEY.ARPA which is now listed in the NIC host table as a
nickname for UCB-VAX.ARPA.  Rather than fix their software so that
it didn't say "user@Berkeley.ARPA", they hacked the host table.

     In a way, I'm glad they did.  At least it stopped the flood of
hysterical and abusive mail I got claimed that the TOPS-20 mailsystem
was broken because it didn't recognize "Berkeley.ARPA" as a host.
-------

Received: from Cabernet.MS by ArpaGateway.ms ; 13 FEB 85 02:04:25 PST
Date: 13 Feb 85 01:57:46 PST
From: Murray.pa@XEROX.ARPA
Subject: Re: lowercase host names
In-reply-to: <850212111029.5.JOSEPH@HUDSON.SCRC.Symbolics.COM>
To: hornig@SCRC-QUABBIN.ARPA
Cc: David Roode <ROODE@SRI-NIC.ARPA>, MRC@SU-SCORE.ARPA,
 Header-People@MIT-MC.ARPA

There is a slight complication here. Somebody along the way is supposed
to change nicnames into official names before a message goes out over
the net. That means if a user types in a nicname, the message goes out
with the capitalization that's in the official host name table...

Will the new domain based scheme support lower case letters?

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA01534; Wed, 13 Feb 85 10:13:26 pst
Received: from CORNELLA.BITNET
	by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1)
	id AA02047; Wed, 13 Feb 85 10:13:58 pst
Message-Id: <8502131813.AA02047@ucbjade.CC.Berkeley.ARPA>
Date: 13 February 85 13:08 EST
From: RMXJITRY%CORNELLA.BITNET@Berkeley
Subject: DOMAINS and lower case addressing
To: HEADER-PEOPLE@MIT-MC.ARPA

I sincerely hope that the new DOMAIN scheme will not
support lower case letters.  THe only immediate problem with that
is that would (probably) interfere greatly with sending mail on usenet.

-- Gligor

RMXJITRY%CORNELLA@WISCVM.ARPA

Date: 13 Feb 1985 11:00:47 PST
From: POSTEL@USC-ISIF.ARPA
Subject: re: lower case host names
To:   header-people@MIT-MC.ARPA


The Domain server implemented for TOPS20 at ISI stores the names in its
database with whatever case the names have in the master file.  The server
recognizes names on a case independent basis.  And, it reports names with
the case they have in the database.  So who ever it is that prepares the
master files gets to set the case used for the names.

--jon.
-------

Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2654659062681411@MIT-MULTICS.ARPA>; 14 Feb 1985 00:17:42 est
Received: from Wayne-MTS by UMich-MTS.Mailnet via MTS-Net; Wed, 13 Feb 85 22:45:17 EST
From: Michael_D'Alessandro@Wayne-MTS
Message-ID: <32767@Wayne-MTS>
Date: Wed, 13 Feb 85 17:19:50 EST
From: Michael_D'Alessandro%Wayne-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
To: header-people@MIT-MC.ARPA

Please remove me from your mailing list.  My address is:

Michael_D'Alessandro%Wayne-MTS%Umich-MTS.Mailnet@MIT-Multics.ARPA

Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2654670288730861@MIT-MULTICS.ARPA>; 14 Feb 1985 03:24:48 est
Date:       Wed, 13 Feb 85 23:39:49 EST
From:       "GO CCITT GO - X.400" <995@NJIT-EIES.MAILNET>
To:         Header-People@MIT-MC
In-Reply-To:The last stream of messages
Subject:    message formats
Message-ID: <M20.11002@NJIT-EIES.MAILNET>

Won't it be nice when MHS gets up and running
then we won't have to worry how each system handles message separation.
a message is a message part (and data type)

Date: Thu, 14 Feb 85 11:43:49 est
From: Mark Shoemaker <mas@Purdue.ARPA>
Message-Id: <8502141643.AA17187@purdue.ARPA>
Received: by purdue.ARPA; Thu, 14 Feb 85 11:43:49 est
To: header-people@MIT-MC.ARPA
Subject: Firewalls in sendmail


Has anyone hacked sendmail to prevent non-local or unauthorized users
from using a host as a mail relay? Our specific problem is that we have
one system designated for research use that has an IMP connection and
several other systems connected to it used solely for instruction, and
we would very much like to keep student users from sending/receiving
ARPAnet mail.

I'm aware of the checkcompat() routine, but it looks like it will be
very difficult to make it handle the non-trivial cases (like a
resarcher who forwards his/her mail off-host).

I'm hoping we can avoid re-inventing the wheel.  Any suggestions/advice
would be most welcome.

Thanks,
Mark Shoemaker		<mas@purdue>

Received: by UCB-VAX.ARPA (4.24/4.41)
	id AA01276; Thu, 14 Feb 85 09:28:13 pst
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7)
	id AA29926; Thu, 14 Feb 85 10:18:09 est
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA14535; Thu, 14 Feb 85 10:12:52 est
Date: Thu, 14 Feb 85 10:12:52 est
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8502141512.AA14535@cbpavo.cbosgd.ATT.UUCP>
To: RMXJITRY%CORNELLA.BITNET@Berkeley, header-people@mit-mc.ARPA
Subject: Re: DOMAINS and lower case addressing
Cc: vortex!lauren@Berkeley

	I sincerely hope that the new DOMAIN scheme will not
	support lower case letters.  THe only immediate problem with that
	is that would (probably) interfere greatly with sending mail on usenet.

I have no idea what brought this on, but I can assure you that not only
do Usenet and UUCP have no trouble with lower case, but in fact by
convention nearly EVERYTHING is in lower case.

The domain rules state that to the right of the @ sign, case is to be
ignored.  We intend to follow this on UUCP.  The current UUCP transport
layer software is case sensitive, that is, Shasta and shasta might be
considered different on some machines (but sendmail ususally hides this.)
The mail layer being developed will ignore case.

Of course, Usenet is not a mail network, just a news network.  It has
very little interaction with the mail or domain systems, and the interaction
it has will not care about upper or lower case.

	Mark Horton

Received: by lll-tis.ARPA (4.30/4.7)
	id AA21899; Fri, 15 Feb 85 14:44:49 pst
Message-Id: <8502152244.AA21899@lll-tis.ARPA>
Date: Fri Feb 15 14:44:43 1985
From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch)
Subject: Re: Firewalls in sendmail
To: mas@Purdue.ARPA
Cc: header-people@MIT-MC.ARPA
X-Orig-Date: Thu, 14 Feb 85 11:43:49 est
X-Orig-From: Mark Shoemaker <mas@Purdue.ARPA>
X-Orig-Message-Id: <8502141643.AA17187@purdue.ARPA>
Status:  N 

> Has anyone hacked sendmail to prevent non-local or unauthorized users
> from using a host as a mail relay? Our specific problem is that we have
> one system designated for research use that has an IMP connection and
> several other systems connected to it used solely for instruction, and
> we would very much like to keep student users from sending/receiving
> ARPAnet mail.

Why not relax and enjoy it? The entire scheme of internetwork
mail forwarding is based on the ideas of comity, cooperation, and
freedom of information flow. Now, if student mail traffic was
overloading your poor research machine, you might want to modify
your host and routing tables, to have the flow go somewhere else.

If you were talking about preventing the escape of sensitive
information, it might be worth doing, but just to cut off
students' internet mail access? (Remind me where NOT to apply to
get MY next degree! :-) ) Access to the various lists, both
technical and nontechnical, is a worthwhile use of resources.
Why not buy 'em a cheap gateway instead?

				Michael C. Berch
				mcb@lll-tis.ARPA
				{akgua,ihnp4,sun}!idi!lll-tis!mcb

Date: 16 February 1985 12:13-EST
From: "Lyman R. Hazelton, Jr." <LRH @ MIT-MC>
To: HEADER-PEOPLE @ MIT-MC

Please take me off the Header-People mailing list.   I have other fish
to fry now.   Thanks to all of you for the lively debate and interesting
viewpoints over the years.   I learned a lot.
						Lyman

Message-Id: <8502170613.AA05778@merlin.ARPA>
Received: by merlin.ARPA; Sun, 17 Feb 85 01:13:16 est
To: mcb%lll-tis.ARPA@lll-tis.ARPA (Michael C. Berch)
Cc: mas@Purdue.ARPA, header-people@MIT-MC.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of Fri Feb 15 14:44:43 1985.
	     <8502152244.AA21899@lll-tis.ARPA>
Date: 17 Feb 85 01:13:13 EST (Sun)
From: Christopher A Kent <cak@Purdue.ARPA>


	From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch)
	Subject: Re: Firewalls in sendmail

	Why not relax and enjoy it? The entire scheme of internetwork
	mail forwarding is based on the ideas of comity, cooperation, and
	freedom of information flow.

It's late, and maybe I shouldn't be responding in my tired state, because
I'm going to flame, but why did you send such a useless reply to the list?
We have a real problem, need some help, and you try to tell us that we
should just ignore it. Why must you question our motives?

Maybe it's escaped you, but the DARPA Internet is a *research* network.
Our sponsoring agent has specified that ONLY research users should be
allowed access. Therefore we have to put together some firewalls. It's
not a question of cycles or bandwidth. It's policy.

chris

Received: FROM UCL-CS.ARPA BY USC-ISID.ARPA WITH TCP ; 18 Feb 85 05:14:55 EST
To: Mark Shoemaker <mas@purdue.arpa>
cc: header-people@mit-mc.arpa
Subject: Re: Firewalls in sendmail
Phone: +44-1-387-7050 ext 773
In-reply-to: Your message of Thu, 14 Feb 85 11:43:49 est.
             <8502141643.AA17187@purdue.ARPA>
Date: 18 Feb 85 10:08:13 GMT (Mon)
Message-ID: <1360.477569293@UCL-CS.AC.UK>
From: Steve Kille <steve@ucl-cs.arpa>

Although not answering your question directly, you might be interested in
MMDF  II (which you sould be able to get from BRL in the near future),
which has a number of features to provide access control.  We (UCL) are
beginning to use these controls to restrict message flow between the
Internet and the UK.  Currently, if you attempt to loop a
message back to yourself thru UCL, you will receive a warning
message telling you to become authorised (for the UK -> US hop)!
This is done on the basis sender, recipient, and connect hosts,
to determine which networks may be accessed.

Steve


Received: by lll-tis.ARPA (4.30/4.7)
	id AA03271; Mon, 18 Feb 85 21:24:40 pst
Message-Id: <8502190524.AA03271@lll-tis.ARPA>
Date: Mon Feb 18 21:24:36 1985
From: mcb%lll-tis.ARPA@lll-tis (Michael C. Berch)
Subject: Firewalls (and flames) in sendmail
To: header-people@MIT-MC.ARPA
Cc: cak@Purdue, mas@Purdue
Status:  N 

Well, my posting about denying Internet access to students seemed
to hit a raw nerve at many sites. Mail is running about 70% in
favor of my comments (the tenor of which were to leave well enough
alone) and the remainder were opposed, on the various grounds of
security, network/gateway capacity, policy, or DoD-related rules.

  From cak@Purdue:
  > It's late, and maybe I shouldn't be responding in my tired state, because
  > I'm going to flame, but why did you send such a useless reply to the list?
  > We have a real problem, need some help, and you try to tell us that we
  > should just ignore it. Why must you question our motives?
  
The reply WAS meant to be useful, and I stand by it. My comment
was that you may not have a problem. Many times I have posted a
question of the form, "How can I do X?", and gotten the reply
that for whatever technical/administrative/commonsense reason, I
really DON'T want to do X. And I am thankful for it.

  > Maybe it's escaped you, but the DARPA Internet is a *research* network.
  > Our sponsoring agent has specified that ONLY research users should be
  > allowed access. Therefore we have to put together some firewalls. It's
  > not a question of cycles or bandwidth. It's policy.

I can understand that if you have an ARPANET sponsor breathing down 
your necks, yelling, "GET THOSE %#$@&#@ STUDENTS OFF THE NET!!"
and threatening to yank your funding and DARPA authorization, that's
one thing. If that's the case, you truly have my sympathy, and I
agree that you certainly don't need my smug assertions about comity.

But if not, I'd wonder why you would want to make it an issue. It
doesn't take too much close reading of the headers of many of
these lists to determine that many institutions have granted more
or less general access to the Internet -- for mail purposes --
to their local networks. It is also evident that ARPANET and
MILNET gateways and hosts are carrying a fair amount of off-net
traffic, much of it destined for UUCP, CSNET, and BITNET nodes.

Anyway, the volume of mail (and the intensity of the opinions
expressed therein) leads me to believe that student/casual access 
to internetwork mail service is a problem that isn't going to go
away. I believe, as many do, that freedom of information flow
should be paramount, and that the value of an internet increases
with the number of persons accessible. On the other hand, there
are real concerns about resource consumption, security, and
network sponsor policy involved.

So, what are people doing about this? Are there alternatives that
preserve access to the internetwork community while balancing
policy concerns? Is this a problem or a non-problem?

My apologies for the long posting.
Perhaps this discussion should move elsewhere, like info-nets?

----
Michael C. Berch
mcb@lll-tis.ARPA
{akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
                                         ...!idi!lll-tis!mcb

Date: Sat, 16 Feb 85 01:19:06 est
From: Mark Shoemaker <mas@Purdue.ARPA>
Message-Id: <8502160619.AA00638@purdue.ARPA>
Received: by purdue.ARPA; Sat, 16 Feb 85 01:19:06 est
To: mcb@lll-tis.ARPA (Michael C. Berch)
Cc: header-people@MIT-MC.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of Fri Feb 15 14:44:43 1985.
             <8502152244.AA21899@lll-tis.ARPA>

----------

> Why not relax and enjoy it?

I wish we could -- but allowing approximately 4500 undergraduate
students access to the ARPAnet (even if only through mail) seems,
uh, unwise.

I'm curious: are there any schools out there that give unrestricted
ARPA mail access to all their students (and will admit it)?

Mark		<mas@purdue>

Received: from (BSD)PSUVM.BITNET by WISCVM.ARPA on 02/19/85 at 10:32:01
  CST
Date: Tue, 19 Feb 1985  11:06:55 EST
From:  BSD%PSUVM.BITNET@WISCVM.ARPA
Subject: Re: Firewalls and flames in sendmail
To:  header-people@MIT-MC.ARPA

One thing to think about before denying students access to the
various networks is the fact that much of the net depends on
students.  How many of you who are in favor of stopping student
access to the networks (Not just the ARPA Internet, but all nets.
This is an idea that is gaining popularity at Universities.) have
ever sent mail from Usenet to BITNET via psuvax1?  How many
of you knew that the mail software there is maintained not by
systems administrators or computer professionals, but by a HIGH SCHOOL
STUDENT?  He helped in the writing of the initial gateway, and has
done much development on it since the real developer has been on leave.

I'm sure that there are a lot of other instances where 'THOSE #*&$%#&$
STUDENTS' have made useful contributions to the network. And after all,
how does one become a computer professional if not by first being
a student?


--Scott Dickson
User Consultant
uucp: {ihnp4, allegra, akgua}!psuvax1!BSD%PSUVM.BITNET
Bitnet: BSD@PSUVM.BITNET
Arpa: BSD%PSUVM.BITNET@WISCVM.ARPA


Date: 19 Feb 85 1205 EST
From: Rudy.Nedved@CMU-CS-A.ARPA
To: Mark Shoemaker <mas@Purdue.ARPA>
Subject: Re: Firewalls in sendmail
CC: header-people@MIT-MC.ARPA
In-Reply-To: <8502160619.AA00638@purdue.ARPA>
Message-Id: <19Feb85.120510.EN0C@CMU-CS-A.ARPA>

Mark,

If you are all for free mail and everything...I have some internal
sites you could pay for leased lines to and set up mail connections
and get mail working to. You can deal with the fun that some students
and people have at attacking ARPANET sites, sending large binary
files thru the mail and other nice unconstructive ways of gumming up
the works.

We have had people read the Unix documentation of things that are
quite obvious "security holes" in Unix and procedure to do them...
including the (while (1) mkdir foo; cd foo; end) hack. The eventual
change was to disable most of the commands...I disagree with that
approach...I am old fashioned...I would had his hands cut off.

The other reality is that the ARPANET is paid for by tax money, if
people want general access to the ARPANET that other people don't
have....I will be glad to help 60 minutes or whatever set of news
organization help scream about misuse of goverment resources.

There is alot of good in computer science proffessionals talking
over networks...but the ARPANET is not a replacement for GTE TELEMAIL,
MCI mail and the such....Joe Blow should use those service...not
a goverment research network.

-Rudy

Received: by bbnccv.ARPA (4.12/4.7)
	id AA00736; Tue, 19 Feb 85 12:51:59 est
Message-Id: <8502191751.AA00736@bbnccv.ARPA>
To: Rudy.Nedved@cmu-cs-a.ARPA
Cc: Mark Shoemaker <mas@purdue.ARPA>, header-people@mit-mc.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of 19 Feb 85 1205 EST.
	     <19Feb85.120510.EN0C@CMU-CS-A.ARPA>
Date: 19 Feb 85 12:51:50 EST (Tue)
From: jsol@bbnccv


	Date: 19 Feb 85 1205 EST
	From: Rudy.Nedved@CMU-CS-A.ARPA
	To: Mark Shoemaker <mas@Purdue.ARPA>
	Subject: Re: Firewalls in sendmail
	Cc: header-people@MIT-MC.ARPA

	There is alot of good in computer science proffessionals talking
	over networks...but the ARPANET is not a replacement for GTE TELEMAIL,
	MCI mail and the such....Joe Blow should use those service...not
	a goverment research network.

I agree, but of course you realize that if Joe Blow want's to send
mail to someone on the Internet he is basically out of luck. This is
unfortunate since electronic mail is fast becoming the latest form of
communication (it is cheaper to send an electronic mail message than
to call someone on the phone and say basically the same thing).

When I was working for Rutgers, I found that the administration there
was also not into letting students send mail to the arpanet. For the
most part I agree with the idea that "Joe Student" shouldn't be able
to send mail to the arpanet, but I was never a "joe typical student"
either. I was fascinated by electronic mail systems, and enjoyed the
conversations I had with other people via the net and the electronic
mailing lists were absolutely awesome! Look at me now, I work for a
software house maintaining the electronic mail system (amongst other
things), and I maintain the TELECOM mailing list (digest). I would
say that I was contributing to the welfare of the ARPANET since I was
in college, and I would say that if I hadn't had access to the
ARPANET, I would probably not be where I am today.

As I am trying to say, I don't think all students should be
encouraged to send mail on the arpanet, but if someone gets
interested, I think their interest should be encouraged, to the point
of hiring the person to maintain the mail system or something else.
It would be sad to hear that some site was not permitting someone who
wants to get involved to do so, that's the sort of person we need
here, someone who will contribute to the well-being of the net.
This sort of consideration should be set up in the software. At
Rutgers, there is a priviledge bit on the systems which allows users
to send mail over the ARPANET, and in addition, there are selected
addresses (such as mine) which send mail over the arpanet to me even
though users at Rutgers specify local addresses (the wonders of mail
forwarding).

One more thing, I recall that an authorized mail message is defined
by the DCA as being authenticated either at the sender end or the
receiver end. In short, that means that I should be able to send mail
to anyone on the net because I am authenticated, and anyone on the
net should be able to send mail to me, regardless of authentication.
Too bad the protocol doesn't make this easy to implement. Joe Student
should be able to send mail to me, since I'm authorized to receive
mail.

I would like to see more work devoted to that form of authentication
before tackling the less important problem of keeping students off
the net.

Cheers,
--JSol



Message-Id: <8502191952.AA11779@merlin.ARPA>
Received: by merlin.ARPA; Tue, 19 Feb 85 14:52:07 est
To: jsol@bbnccv.ARPA
Cc: Rudy.Nedved@cmu-cs-a.ARPA, Mark Shoemaker <mas@Purdue.ARPA>,
        header-people@mit-mc.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of 19 Feb 85 12:51:50 EST (Tue).
	     <8502191751.AA00736@bbnccv>
Date: 19 Feb 85 14:52:04 EST (Tue)
From: Christopher A Kent <cak@Purdue.ARPA>

We *do* have such authentication, and it is used for telnet, ftp, etc.
What we're trying to come up with is a solution to allow us to use it
for mail.

Let's quit discussing the hows and whys -- just take it as given that
there is a certain class of user here that, for whatever reason, may
not send or receive mail on the Arpanet. Back to the original question:
how can we enforce this in sendmail?

chris

P.S. I agree that there are students and students. I'm a student; I also
maintain the network systems in the CS department, and do research. The
students we're talking about are beginning programming undergrads that
are supposed to be using our terribly overloaded instructional machines
JUST for their programming homework, not flooding the mailer or the
arpanet with digest mail. If they want to get involved in hacking
network systems, there are venues for doing so. Enough already!
----------

Date: 19 Feb 85 1543 EST
From: Rudy.Nedved@CMU-CS-A.ARPA
To: jsol@BBNCCV.ARPA
Subject: Re: Firewalls in sendmail
CC: Mark Shoemaker <mas@purdue.ARPA>, header-people@mit-mc.ARPA
In-Reply-To: <8502191751.AA00736@bbnccv.ARPA>
Message-Id: <19Feb85.154337.2@CMU-CS-A.ARPA>

If I sounded anti-student...I am not. In general, I am anti-abuse. I
don't like people screwing things up and if there is no recourse to
reprimand that abuse....I handle it via software.

I work for the CS department and the Robotics Institute. If you abuse
the priv of having ARPANET access....we nail your account. Simple and
effective.

The majority of the students use other facilities and the
adminstration until last year was extremely lax in dealing with
system crashers. The "discipline" council did not understand
computers and the representative for the general computing facility
seems to be afraid of restricting anyone's freedom even though the
individual has caused harm to other individuals.  Therefore....system
crashing, deleting files, stealing accounts, sending huge mail and
other destructive actions were rampant. The result was the software
people quickly learned to build bigger and better walls that didn't
allow crashes, that discouraged password stealing, limited mail
sending sizes and mail receiving sizes....The students got smarter
and so did the system support people...it was an all out war.

The wind has changed and things are taking a more professional
attitude.  Many students have accounts at CS or other departments and
do very good work. They have their privs but heaven help them if they
blow it.

Basically I put in restrictions according to whether it causes me or
other people grief. If a mail system I maintain slows down and I get
complaints that meetings are being missed or whatever because mail is
taking 30 minutes instead of 5....I look at it...If I find 40 people
getting junk mail or two people having a mail war...I come down on
them like a ton a bricks. I don't care if it is some employee from
some company that sprouted from CMU or some guest professors or some
graduate student....(all of which have done there fair share of
abuse)

Rudy Nedved
Undergraduate Applied Math Major (full time for two years, part-time now)
CMU CS/RI Research Systems Programmer
Facilities Staff

Received: from iapetus by rice.ARPA (AA04888); Tue, 19 Feb 85 18:47:43 CST
Received: by iapetus (AA05177); Tue, 19 Feb 85 18:50:32 CST
Date:       Tue, 19 Feb 85 18:35:40 CST
From: Scott Alexander <salex@rice.ARPA>
Subject:    Re: Firewalls in sendmail
To: header-people@mit-mc.ARPA
Message-Id: <477707741.salex@Iapetus.ARPA>
In-Reply-To: a message from jsol@bbnccv dated 19 Feb 85 12:51:50 EST (Tue)

Firstly, my situation is somewhat unique in that although we have
transparent access (well,  fairly transparent) to the arpanet, we pay per
packet charges to GTE.  Thus, if joe random decides to send mail to his
friend on the arpanet, and his friend's site is down, we pay to check every
ten minutes to see if that site has come back up.

Second, on the subject of undergraduates and other random students using the
network.  I am an undergraduate and am in charge of rice's network.  I agree
that letting *some* students have access to the arpanet is good.  However, I
see an increasing number of students (with the increasing enrollment) who do
not see the community of computer scientists which has bred a sense of fair
play in the past.  I feel that I have some resonsibility to the rest of the
arpanet community to prevent students from attempting to cause problems to
other machines.  Locally, this is easy to deal with and I take the attitude
which Rudy suggests.  However, if someone from a rice machine uses the
arpanet to conduct mail wars, it is difficult for me to discover this in
time to substantially prevent it without preventing all mail from students
to the outside world.  If a student has the promise, an effort is made to
hire him into a position which gives him access to the arpanet.

Locally, educational sites can be lenient if they desire, but we have a
greater responsibility to the arpanet (even if one is willing to ignore the
clauses of the arpanet agreement about research use only).

Scott Alexander
postmaster
Rice University

Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 02/20/85 at
  02:18:18 CST
Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
Received: by WEIZMANN   id 2074; Wed, 20 Feb 85 10:10:48 IST
Date:         Wed, 20 Feb 85 10:10 IST
From:           Henry Nussbacher  <VSHANK%weizmann.BITNET@WISCVM.ARPA>
Subject:      Firewalls
To:  <header-people@mit-mc.ARPA>

Restricting student access to Arpanet: very interesting.  I don't
know what the solution is.  How to restrict access?  By userid?
By password?  Since Arpanet is for research do you also restrict
access to administrators and secretaries who run each shop but
are not involved with strict research?

My belief is that any tool will be abused.  A hammer can be used for
hammering nails or for taking someones head off.  The trick is to
convince the abusers that they will be punished.  I have had a problem
off and on with students (specifically - high school students) sending
chain letters through BITNET (if you think Digest mail is bad, you
ought to see what happens with chain letters in a network!).  The
simple solution is that if a user will send out a chain letter, they
will have their account suspended, and all their files erased.  We have
also threatened to shut off the link to the outside world if some sort
of abuse of the network is found (obscene mail, junk mail, chain letters)
and to publish in the system the name of the user who is responsible
for the disruption in service.  We have never had to do this but have
come close at times.  The threat of it is enough to control even 12
year old kids!

We have managed to keep digest mail levels down by only allowing one
subscriber on our node and placing the various interesting digests
on a local Bulletin Board.  This way we only get one copy of SF-Lovers
and not 30 or 40.  In addition, the BITNET mailer will send only one
copy of a piece of mail to a node even if there are many recipients
for that node.  The mailer at the destination will then fan it out
to the recipients.  In this fashion, we have also cut down the number
of mail files that travel through the network.

These are solutions to congested network problems.  Student abuse will
only aggravate the problem.  I am not sure if there are any easy
solutions.

In reference to the person who threw in PSUVAX1 as a good example of
a high school student writing the gateway: bad example!  PSUVAX1
has one of the worst reputations on BITNET for flaky software.  That
is what you get when you place a clever high schooler to do the work
of a qualified systems programmer.  All gateways in BITNET accept mail
from "trusted" second party mail handlers.  Except PSUVAX1.  It
rejects mail from "trusted" mailers and has been like this for the
past 6 weeks.  I would prefer to get a qualified systems programmer
at PSUVAX1 to fix it so BITNET can finally use the "official" UUCP
gateway.  So much for the merits of high school written code!

Hank
Weizmann Institute of Science
Rehovot, Israel

Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA12284; Wed, 20 Feb 85 23:38:20 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1)
	id AA14547; Wed, 20 Feb 85 23:14:41 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.33)
	id AA26651; Wed, 20 Feb 85 23:14:19 pst
Date: Wed, 20 Feb 85 23:14:19 pst
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8502210714.AA26651@ucbopal.CC.Berkeley.ARPA>
To: HEADER-PEOPLE@MIT-MC.ARPA, RMXJITRY%CORNELLA.BITNET@Berkeley
Subject: Re: DOMAINS and lower case addressing

Some Unix systems with uucp links are case sensitive.

Unix sendmail converts all addresses to one case when comparing
domain-name and userid information. It should leave the case the way in
was sent in the header when it forwards a message.

We recently had a problem on a Unix system here because a userid
(login name) had been created that contained upper and lower case
letters. The result was that the user could not receive mail because
sendmail was looking for a lower-case only login name.  Thus mail
to "UsEr" would be forwarded to "user" (if "user" existed) or generate
an unknown user error. So case is also an issue with the local part
of the address on some systems.

Bill Wells
wcwells@Berkeley.ARPA


Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655274531772228@MIT-MULTICS.ARPA>; 21 Feb 1985 03:15:31 est
Date:       Wed, 20 Feb 85 14:22:17 EST
From:       "Thomas A. Moulton" <995@NJIT-EIES.MAILNET>
To:         Header-People@MIT-MC.ARPA
In-Reply-To:<19Feb85.120510.EN0C@CMU-CS-A.ARPA>
Subject:    Firewalls in mail senders
Message-ID: <M20.13182@NJIT-EIES.MAILNET>

If you think about it, these "Mail Wars" and system crashing and other
damaging system hacking is not a professional way for students to act.
Once you take that perspective the student accounts are No problem,
if a student steps to far out of line he gets yelled at, hand slapped and
warned that they could lose their entire college career, I have heard that
if a student gets thrown out of school by the Committee for Professional Conduct
they might as well decide to either pump gas for the rest of their lives or
just start over from scratch.

Once you make an example of one or two students your problems are solved.
On the school's main computer (the dumb one, no mail system) there was even
a student who was making lots of money on the cpu time allocated to him for
classes, needless to say he's history...

It's kinda fun to watch a student hang himself by ignoring such warnings,
you know the kind, they wimper when you take away your account and then
once they get it back they act like a hot shot in the terminal room as they
go to crash the system one final time...

Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2655278688719196@MIT-MULTICS.ARPA>; 21 Feb 1985 04:24:48 est
Date:        21 Feb 85 00:36 +0100
From:        Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: RFC 934 - Message Encapsulation
Message-ID:  <91867@QZCOM>
In-Reply-To: <90500@QZCOM>

David,

I think that trying to enforce rules on Digestors like "Insert
a line of 30 hyphens as message separator" would never work,
for example, my keyboard cannot count.

The right way of handling this would be to elaborate the Multi-Media
and Script concepts, work that is currently going on (e.g. in IFIP).

The X.400 way may also work. It may look cumbersome but it should
be remembered that the user interface is completely left out
from the recommendation, leaving it up to all and everyone to
tackle the User-Presentation problem as he wishes.

- Tommy



Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2655298608378532@MIT-MULTICS.ARPA>; 21 Feb 1985 09:56:48 est
Date: Wed, 20 Feb 85 09:02:02 EST
From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
To: header-people@MIT-MC.ARPA,
    Bernard_Galler@UMich-MTS.Mailnet
Message-ID: <655931@UMich-MTS.Mailnet>
Subject: Firewalls etc.

Hi:

Are there any "official" policies around about how local institutions handle
their access to Internet and/or CSNET facilities? Do people have to sign a
written down form? Do any of these forms exist on file so that you could send
me a copy by electronic mail?

I'd suggest that if you have such a policy that you send it just in a message
to me, since the Firewall discussion is already beginning to get out of hand.

I'd appreciate any responses!

         -- Hans-Werner

         HWB%UMICH-MTS.MAILNET@MIT-MULTICS.ARPA

Date: Sun 24 Feb 85 12:07:04-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Re: Firewalls in sendmail
To: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Mark Shoemaker <mas@Purdue.ARPA>" of Tue 19 Feb 85 08:26:22-EST

    From: Mark Shoemaker <mas@Purdue.ARPA>

    > Why not relax and enjoy it?

    I wish we could -- but allowing approximately 4500 undergraduate
    students access to the ARPAnet (even if only through mail) seems,
    uh, unwise.

    I'm curious: are there any schools out there that give unrestricted
    ARPA mail access to all their students (and will admit it)?

    Mark		<mas@purdue>

I think your problem lies not in restricting mail access through
purdue to ARPA hosts, but in restricting mail access between machines.

At MIT's undergraduate comp center (mit-eecs) students often need to
communicate with their TA's via mail, who often keep accounts on other
research machines on the chaosnet.  Therefore, mail access to the
chaosnet is allowed.  It so happens that mail access to the ARPAnet is
done via the chaosnet, so students have mail access to the ARPAnet as
well.

It seems that mail is considered generally harmless to the ARPAnet by
those in a position to control access to it, so it was not disallowed.
It certainly could have been disallowed, since general use of the
chaosnet is not permitted for undergraduates (it requires a special
bit which enables one to write to the cha: device which is the chaos
network device on a DEC-20).  Undergraduates are not allowed to make
file transfers, telnet to other hosts, etc. unless they have that bit.
Since mail works the same way, it could have been restricted the same
way.

The policy of the undergraduate comp center was (at least up until a
couple of years ago) to deny chaosnet access to any undegraduates
using the 20 unless they actually worked there as staff, consultant,
or some other software support.  With the growing number of
undergraduate research opportunities at MIT, the number of chaosnet
access bits increased (the only other way to get chaosnet access was
to justify the need for it by having a non-guest account on another
chaosnet machine).  Nowadays many undergrads get chaosnet bits -- I'm
not saying this is right or wrong, just the way things are.

Speaking personally, having chaosnet access (implying ARPA access)
benefitted me greatly as an undergrad because I was able to get useful
technical information (unix-wizards, header-people, etc.) which I
wouldn't have got otherwise until my undergrad years had just about
ended.  I wouldn't have known half of what I knew coming out of school
without those bits.  Many other MIT undergrads feel the same way --
I'll forward the question to some of them so you can hear from them.

--gregbo
gds@mit-xx.arpa
gregbo%houxm.uucp@harvard.arpa
{allegra,cbosgd,ihnp4}!houxm!gregbo
-------

Message-Id: <8502241827.AA19782@merlin.ARPA>
Received: by merlin.ARPA; Sun, 24 Feb 85 13:27:45 est
To: Greg Skinner <Gds@MIT-XX.ARPA>
Cc: header-people@MIT-MC.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of Sun 24 Feb 85 12:07:04-EST.
	     <8502241707.AA26342>
Date: 24 Feb 85 13:27:40 EST (Sun)
From: Christopher A Kent <cak@Purdue.ARPA>

PLEASE! No more bleeding heart messages about why we shouldn't bother.
If you have an answer to our question (that is, how do we erect
firewalls in sendmail for those users that are not to have arpa
access), please respond. Otherwise, don't waste our mailbox bandwidth.
The decision to restrict or not to restrict is solely our own. We
aren't fascists -- we merely know our user community. You don't. So let
us make the decisions.

As it is, all the users in question have access to Usenet, so they can
get all the neat mailing lists that people have flamed about, at much
less mailer bandwidth (one copy per site).

Still looking for a technical answer,
chris
----------

Date: Sun 24 Feb 85 13:20:43-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: Firewalls in sendmail
To: cak@PURDUE.ARPA, Gds@MIT-XX.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Christopher A Kent <cak@Purdue.ARPA>" of Sun 24 Feb 85 13:27:40-PST
Location:  EJ286    Phone: (415) 859-2774

Many TOPS-20 sites establish BBOARD's which bring Unix-wizards,
header-people, etc. to the user community in the same low-bandwidth
way referred to in the last message as inherent in Usenet.

Also, I think CAK missed the fact that GDS's message explained a
different approach to accomplishing Purdue's goal.  Namely users on
backend machines can be blocked from network access (to local as well
as ARPANET sites) either in general or according to type of network
service (mail, FTP, Telnet, etc.)   Even if this does not solve
Purdue's problem, it seems like it might be useful information
for other sites, and it does not say Purdue should not control
access.
-------

Date: Sun 24 Feb 85 13:20:43-PST
From: David Roode <ROODE@SRI-NIC.ARPA>
Subject: Re: Firewalls in sendmail
To: cak@PURDUE.ARPA, Gds@MIT-XX.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Christopher A Kent <cak@Purdue.ARPA>" of Sun 24 Feb 85 13:27:40-PST
Location:  EJ286    Phone: (415) 859-2774

Many TOPS-20 sites establish BBOARD's which bring Unix-wizards,
header-people, etc. to the user community in the same low-bandwidth
way referred to in the last message as inherent in Usenet.

Also, I think CAK missed the fact that GDS's message explained a
different approach to accomplishing Purdue's goal.  Namely users on
backend machines can be blocked from network access (to local as well
as ARPANET sites) either in general or according to type of network
service (mail, FTP, Telnet, etc.)   Even if this does not solve
Purdue's problem, it seems like it might be useful information
for other sites, and it does not say Purdue should not control
access.
-------

Message-Id: <8502242138.AA24713@merlin.ARPA>
Received: by merlin.ARPA; Sun, 24 Feb 85 16:38:08 est
To: David Roode <ROODE@SRI-NIC.ARPA>
Cc: header-people@MIT-MC.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of Sun 24 Feb 85 13:20:43-PST.
	     <8502242121.AA01008>
Date: 24 Feb 85 16:38:03 EST (Sun)
From: Christopher A Kent <cak@Purdue.ARPA>

To make things painfully clear: we have access control in place for all
services except mail. We can't just turn off mail access, because we are
a very "distributed" environment -- network mail is a basic fact of
life for getting work done on campus. We need to be able to restrict
mail from a certain class of users to a certain class of hosts, in
sendmail. Does anyone have a method of doing this?

chris
----------

Received: by bbnccv.ARPA (4.12/4.7)
	id AA07476; Sun, 24 Feb 85 20:17:23 est
Message-Id: <8502250117.AA07476@bbnccv.ARPA>
To: David Roode <ROODE@sri-nic.ARPA>
Cc: cak@purdue.ARPA, Gds@mit-xx.ARPA, header-people@mit-mc.ARPA
Subject: Re: Firewalls in sendmail
In-Reply-To: Your message of Sun 24 Feb 85 13:20:43-PST.
	     <8502242134.AA06551@bbnccv.ARPA>
Date: 24 Feb 85 20:17:19 EST (Sun)
From: jsol@bbnccv

The problem with using network access bits to control mail access is
that you have to modify the deamon mailer to check each user for the
bits involved. Without modifying sendmail source you will not be able
to accomplish this. The configuration file simply doesn't take this
into account.

Before you go off writing patches to sendmail, think about the
structure of sendmail and try to make something we can all use (i.e.
make it a new feature to the sendmail.cf file).

Cheers,
--JSol

Received: from SCRC-CROW by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 184636; Mon 25-Feb-85 15:04:38-EST
Date: Mon, 25 Feb 85 15:01 EST
From: Robert W. Kerns <RWK@SCRC-RIVERSIDE.ARPA>
Subject: Firewalls in sendmail
To: GDS@MIT-XX.ARPA
cc: header-people@MIT-MC.ARPA
Message-ID: <850225150112.0.RWK@CROW.SCRC.Symbolics.COM>

    Date: Sun 24 Feb 85 12:07:04-EST
    From: Greg Skinner <Gds@MIT-XX.ARPA>
A minor problem with this first statement...

    It [CHAOS mail access] certainly could have been disallowed, since
    general use of the
    chaosnet is not permitted for undergraduates (it requires a special
    bit which enables one to write to the cha: device which is the chaos
    network device on a DEC-20).  Undergraduates are not allowed to make
    file transfers, telnet to other hosts, etc. unless they have that bit.
    Since mail works the same way, it could have been restricted the same
    way.

Untrue!  Mail does not work the same way!  The (implementation) reason
students can send mail via the CHAOSnet is because it isn't THEY who
send the mail, it's the mailer daemon, which is a part of the system.
It would be rather difficult to restrict some people and not others,
involving all sorts of issues of validation, etc.  TOPS-20 is by no
means unique in this regard, at MIT or elsewhere, nor is TOPS-20 the
only system that undergraduates use.

Putting in firewalls into every operating system on every machine
that undergraduates have occasion to use is not likely to be worth
the work, especially on systems that don't give you the sources to
their mailer!  And personal computers really make a mockery of these
efforts, unless you care to forbid the connection of personal coputers
to the network.  This would certainly NOT be feasible at MIT!

Also, it is not clear just what constitutes "undergrad use of the
arpanet".  If an undergrad sends mail to his TA, and his TA forwards his
mail to MIT-Multics (quite reasonable), is it the undergrad or the TA
that's using the network.  What if the undergrad sends mail to
HEADER-PEOPLE@XX, assuming XX has such a forwarding entry to MC?

    The policy of the undergraduate comp center was (at least up until a
    couple of years ago) to deny chaosnet access to any undegraduates
    using the 20 unless they actually worked there as staff, consultant,
    or some other software support.  With the growing number of
    undergraduate research opportunities at MIT, the number of chaosnet
    access bits increased (the only other way to get chaosnet access was
    to justify the need for it by having a non-guest account on another
    chaosnet machine).  Nowadays many undergrads get chaosnet bits -- I'm
    not saying this is right or wrong, just the way things are.

Indeed, forbidding access on the basis of restricting individuals
to mail between certain groups of users, certain machines, certain
networks, or using any other arbitrary predetermined boundaries, is
doomed to perpetual inappropriateness.  Either you have to restrict
communications that would be better left unrestricted, or you have
to permit ones you did not intend.

    Speaking personally, having chaosnet access (implying ARPA access)
    benefitted me greatly as an undergrad because I was able to get useful
    technical information (unix-wizards, header-people, etc.) which I
    wouldn't have got otherwise until my undergrad years had just about
    ended.  I wouldn't have known half of what I knew coming out of school
    without those bits.  Many other MIT undergrads feel the same way --
    I'll forward the question to some of them so you can hear from them.

This is right on, although I don't think you made the point
strongly enough.  I think mail access is an ESSENTIAL part of
the undergraduate curriculum.  I don't want to hire a new grad
who has just been exposed to the little world on MIT-EE, and
who has no idea how to behave in the larger world.

    --gregbo
    gds@mit-xx.arpa
    gregbo%houxm.uucp@harvard.arpa
    {allegra,cbosgd,ihnp4}!houxm!gregbo
    -------

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA;  7 MAR 85 17:44:51 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656535304832326@MIT-MULTICS.ARPA>; 07 Mar 1985 17:28:24 est
Date:        07 Mar 85 17:06 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA
Cc:          GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Checksum as a replacement for missing Message-ID.
Message-ID:  <94759@QZCOM>

Checksum as a replacement for missing Message-ID.
------------------------------------------------

The Message-ID is a very useful field for many purposes:

(a) To preserve In-reply-to references between transferred messages.

(b) To stop loops by not accepting the same message to the same
recipient more than once.

(c) To be able to identify that several copies of the same message
are the same, which will save disk space and provide better user
functionality in some systems.

The problem is that many messages do not have any Message-ID-s.

I am planning to modify the COM network mail interface to generate
Message-ID-s for messages which lack such ID-s. These generated ID-s
will be used internally in COM and will be affixed to a message if it
is sent out to the networks again, e.g. by a conference/mailing list
residing on a COM system.

The Message-ID should uniquely identify one message, so that all copies
of the same message will get the same Message-ID. Thus, if two systems
independently generate a Message-ID for a message, they should produce
the same message. To achieve this goal, I suggest to generate the
Message-ID as a checksum of the message.

If two systems independently generate a Message-ID for a message, they
should preferably produce the same ID. Thus, the ID should *not* refer
to the host name of the message system generating the ID, if this is not
the system where the message originated. Thus, I propose to generate
Message-ID-s of the format <CHECKSUM-VALUE@CHECKSUM> where the host
name in RFC822 is replaced by the word "CHECKSUM". This will tell
recieving systems that this is a CHECKSUM-ed ID, so that they can
identify it with other CHECKSUM-ed ID-s.

The alternative would be to produce ID-s in the format <CHECKSUM-
VALUE@ORIGINAL-HOST>. However, it does not seem nice to generate ID-s
purporting to come from a host which did not in reality generate this
ID.

Selection of CHECKSUM algorithm:
-------------------------------

The algorithm should uniquely identify a message with very low
probability of different messages getting the same ID. On the other
hand, the checksum should not change for common modifications to a
message, like additions of new recipients in the RFC822 header,
different line foldings or conversions of TAB-s to SPACE-s.

The following algorithm is proposed:

The CHECKSUM contains 15 characters, in three groups of five
characters. The first group is computed from the name in the FROM
field, the second group from the value in the DATE field, the third
group is computed from the textual contents of the message.

Each group should have a checksum algorithm suitable for that group.

For the FROM field, I suggest the following:

(a) Use only the value of the "addr-spec" part of the FROM field
(delete the "phrase" part and the <>-s, if any).

(b) Upcase the characters A-Z before checksum computation.

(c) Only include characters A-Z and digits 0-9 in checksum computation.

(d) Compute the checksum by summation of the characters, with the
weight 1 to the first character, 2 for the second, 4 for the third
etc. up to 2^16 for the sixteenth character, then 1 for the seventeenth
etc.

(e) Take the remainder of the checksum modulo 2^24. Translate this
remainder to five characters in a 32-based number system with the
digits 0...9, A..V.

Rationale: This checksum should be easy to compute on any computer
with 32-bit word integer arithmetic.

For the DATE field, I suggest as checksum the number
(((YEAR+SECOND+MONTH)*31+DAY)*24+HOUR)*60+MINUTE
This number is again translated to a five character string as
described in (e) above.

For the contents of the message, all non-printable characters, including
tab and space, should be disregarded when computing the checksum. The
checksum is computed using the algorithm in stage (d) and (e) described
above (but not stages a-b-c). Rationale: Disregarding all non-printable
characters, including tab and space, is necessary to ensure that line
folding will not change the checksum.




Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA;  7 MAR 85 17:45:09 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656535379002246@MIT-MULTICS.ARPA>; 07 Mar 1985 17:29:39 est
Date:        07 Mar 85 22:16 +0100
From:        Torgny_Tholerus_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Torgny_Tholerus_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA
Cc:          GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Checksum as a replacement for missing Message-ID.
Message-ID:  <94851@QZCOM>
In-Reply-To: <94759@QZCOM>

One problem I can see, is the DATE field.  This field might look
like:
                13 Apr 83 17:43 BST.
or:
                Wed Feb 20 16:07:15 1985

How do I do to find the year field or the month field?  Perhaps
is the best thing to treat the DATE field just like a string,
in the same way as the FROM field is treated.



Received: from CMU-CS-A.ARPA by MIT-MC.ARPA;  8 MAR 85 11:24:12 EST
Date:  8 Mar 85 1011 EST (Friday)
From: Craig.Everhart@CMU-CS-A.ARPA
To: Header-People@MIT-MC.ARPA
Subject: Re: Checksum as a replacement for missing Message-ID.
Sender: RdMail@CMU-CS-A.ARPA
Reply-To: RdMail@CMU-CS-A.ARPA
In-Reply-To: <94851@QZCOM>
Message-Id: <08Mar85.101138.RD00@CMU-CS-A.ARPA>

Why use the From: or Date: fields at all?  The From: field is a popular
candidate for editing by automatic agents; I'm not convinced that Mr. Palme's
algorithm will remove all traces of that editing.  The Date:-field
algorithm was underspecified (year in century, as SMTP would have?  What
is the origin for months?  Any use of time zone information?).

For that matter, I'm not sure that all agents would agree on the concept
of ``printing character'' in the body of the message.

Why not use an algorithm based solely on the body of the message?  It can
ignore characters outside the range [33,126] (decimal, inclusive); obviously
it would only count characters in that range when incrementing the checksum
counter.

It may be less expensive to use something other than multiplication as a basis
for the checksum on many small machines.  Are there suitable algorithms based
on bit rotations or shifts?

And perhaps the whole discussion should be moved into an RFC.


Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA;  8 MAR 85 21:53:54 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656633759076531@MIT-MULTICS.ARPA>; 08 Mar 1985 20:49:19 est
Date:        08 Mar 85 18:44 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA
Cc:          GILT_open_meeting%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Checksum as a replacement for missing Message-ID.
Message-ID:  <95013@QZCOM>
In-Reply-To: <94851@QZCOM>

The reason I choose not to treat the date field as a string,
is that the checksum should not change if the date field is
translated from one format to another, e.g. from the format
in RFC822 to the format in X.400.

This of course requires that the date field is parseable. But
every single message should, when you get it, have a header
in one given standard and thus date fields not belonging to this
standard should not occur.

One problem is the time zone. Since the format of this seems
to be often wrong, I did not include it in the checksum. This
means that if the time is translated to another time zone,
e.g. if the date "25 Feb 85 15:01 EST" is translated by some
agent handling the message into "25 Feb 85 12:01 PST" then the
algorithm will create a different checksum.

Question: Would such translations of dates by message handling
agents be expected to occur?



Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA;  9 MAR 85 15:09:14 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656699596857652@MIT-MULTICS.ARPA>; 09 Mar 1985 15:06:36 est
Date:        09 Mar 85 12:55 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: Checksum as a replacement for missing Message-ID.
Message-ID:  <95136@QZCOM>
In-Reply-To: <08Mar85.101138.RD00@CMU-CS-A.ARPA>

     FROM: William "Chops" Westfield <BillW@SU-SCORE.ARPA>

     Why is it necessary for two hosts trying to create a MESSAGE-
     ID to come up with the same result? I dont understand why
     anyone but the original host would try to create a message
     id...

If the original host always created Message-Id-s, this would be a
better solution. We will however have to accept the fact that some
hosts do not create globally unique Message-ID-s. Neither RFC822
nor X.400 unfortunately require mandatory globally unique Message-
ID-s (IPMessageID-s in X.400 terminology).

Suppose one and the same message gets forwarded, directly or
indirectly, to two different mailing lists, and that a certain
user is a member of both lists. If the intermediate hosts handling
the mailing list created a checksum, this could be used by the
host for the recipient user to stop displaying the same message
twice, or, to tell him that it is the same message which he gets
twice.

Why should the intermediate host add a Message-ID to a message
lacking such an ID? Because the ID is very useful for loop control.
If two mailing lists are members of each other (which has advantages,
but cannot be done with present practices on Arpanet because of the
risk for loops) then if the list maintaining program kept a list
of the ID-s of messages sent via the list (COM does this) then
it could stop re-sending the message when it comes around the
second time.

     FROM: Craig.Everhart@CMU-CS-A.ARPA
     Why use the From: or Date: fields at all? The From: field is
     a popular candidate for editing by automatic agents; I'm not
     convinced that Mr. Palme's algorithm will remove all traces
     of that editing. The Date:-field algorithm was underspecified
     (year in century, as SMTP would have? What is the origin for
     months? Any use of time zone information?).

The goal of course is to find an algorithm with a very very low
probability of getting the same ID for two different messages, but
also with low probability of giving different ID-s for the same
message because of some transformation on the message.

Only using TEXT CONTENT is NOT acceptable. Suppose in a voting
application that two people wrote messages with the only content
being the word "Yes!". Only using TEXT CONTENT would hide the very
important fact of the names of the people who voted "Yes!". Not
using Date/time is also not acceptable, suppose the same person
voted "Yes!" on two different issues, this fact would then be
hidden.

     FROM: Craig.Everhart@CMU-CS-A.ARPA
     It may be less expensive
     multiplication as a basis for the checksum on many small
     machines. Are there suitable algorithms based on bit
     rotations or shifts?

Most of the multiplications in my algorithm (all of those in
processing the body of the message) were by powers of 2
thus can be implemented by shifts.



Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 12 MAR 85 05:11:58 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2656923154852744@MIT-MULTICS.ARPA>; 12 Mar 1985 05:12:34 est
Date:        11 Mar 85 01:57 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header-People@MIT-MC.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: Checksum as a replacement for missing Message-ID.
Message-ID:  <95256@QZCOM>
In-Reply-To: <95136@QZCOM>

A further reason why it is necessary to create a Message-ID for a
message which does not have any: Checksums are necessary in order
to preserve in-reply-to-relations between pairs of messages which
may be transmitted between hosts via different routs.

Example: Host A sends out a message M1 to hosts B and C. at host
B, a reply M2 is written and sent to host B. In order for host B
to be able to recognize that M2 is a reply to M1, A and B must
independently generate the same Message-ID on M1.

Question: Why did I not include the value of the in-reply-to field
in the creation of the checksum. Answer: Because some systems may
allow the addition of an in-reply-to field after the creation of
a message. (At least we do. We sometimes get messages which clearly
are replies to other messages, but which do not have in-reply-to
fields. I sometimes then add an in-reply-to reference to the
incoming message, since the sorting of the message data base through
in-reply-to-relations makes it easier to use.)



Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAR 85  01:26:11 EST
Date: Tue 19 Mar 85 01:26:34-EST
From: Gregbo <Mdc.Gds%MIT-OZ@MIT-MC.ARPA>
Subject: arpa/usenet gatewaying
To: info-nets%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC

Could we hack inews and sendmail so that if there is a user-created
Newsgroups: header that it would forward through the arpa/usenet
gateway and be picked up by inews, to distribute the mail in the
specified newsgroup?  It doesn't sound like too hard a thing to do,
and it would solve the problem of people sending things to info-micro
from ARPA but really want them in net.micro.xxx.

Actually, I should include MMDF, since the primary gatewaying host
runs it, however I don't know MMDF.

typical scenario:

To: info-micro@brl.arpa
Subject: 6809 article
Newsgroups: net.micro.6809

... text ...

when it passes to the gateway, sendmail picks it up, notices that it
has a Newsgroups: line in it (maybe /bin/mail could do this, instead),
and forks inews -h -n <the newsgroup> with the mail as the standard
input.

(For those not in the know, inews is the program which is run that
installs a news article at a site and causes the article to propagate
around the net.  the -h flag indicates that the file contains headers,
which should come from the mail.)

If no one has tried this, I might fool around with the idea, to see if
it has any merit.

--gregbo
gds@mit-xx.arpa
gregbo%houxm.uucp@harvard.arpa
{allegra,cbosgd,ihnp4}!houxm!gregbo
-------

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 21 MAR 85 09:28:59 EST
Received: from NJIT-EIES.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2657693370179793@MIT-MULTICS.ARPA>; 21 Mar 1985 03:09:30 est
Date:       Wed, 20 Mar 85 17:02:56 EST
From:       "J. Gordon Beattie Jr." <2990@NJIT-EIES.MAILNET>
To:         header-people@mit-mc
Subject:    TCP/IP:  How to make it go ?
Message-ID: <M20.24169@NJIT-EIES.MAILNET>

I have a few questions for the TCP/IP jockeys.  I would greatly appreciate
any answers.


1. What link level protocols are typically used under IP ?
2. What link level protocols are used in the ARPANET ?
3. What link level protocols are used in the Defense Data Network ?
4. What upper level protocols are used on the above to handle
   any of the following:

                    1. Host to Host batch file transfers
                    2. User terminal to Host file transfers (or the reverse)
                    3. Interactive user terminal to host transfers
                    4. Mail
                    5. Shared database transfers ?



I am also curious to know how two TCP's arbitrate the size of the total
message sent.  If segmented can it get large ?  If yes then how does it
keep from getting too large for the machine ?   Does any of this matter ?

          Thanks for your assistance and time.
                                                            Gordon Beattie
                                            2990@NJIT-EIES.MAILNET

Received: from USC-ISIF.ARPA by MIT-MC.ARPA; 12 APR 85 21:13:48 EST
Date: 12 Apr 1985 18:07:19 PST
From: POSTEL@USC-ISIF.ARPA
Subject: SMTP for WANG ???
To:   header-people@MIT-MC.ARPA

Return-Path: <Stachour.CSC_RP@HI-MULTICS.ARPA>
Received: FROM HI-MULTICS.ARPA BY USC-ISIF.ARPA WITH TCP ; 12 Apr 85 09:17:54 PST
Posted-Date:  12 Apr 85 11:17 CST
Date:  Fri, 12 Apr 85 11:14 CST
From:  "Paul D. Stachour" <Stachour@HI-MULTICS.ARPA>
Subject:  Info on SMTP interface with WANG
To:  POSTEL@USC-ISIF.ARPA
Message-ID:  <850412171433.023457@HI-MULTICS.ARPA>

  Jon, I've had a query from a fellow Honeyweller who use a WANG OIS.
He'd like to know if there is a SMTP interface available, either for
that or Wang's WPS or VS, which he also has access to.  While he'd
perfer to know about an offically supported one, or plans for same, he'd
like to know about in user-effortt as well.
  Can you give me a pointer, or tell me which mailing-list would be best
for me to send the query to?
  Thanks, ...Paul Stachour
-------

Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 21 May 85 17:49:12 EST
Date: Tue 21 May 85 14:45:59-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: AMES-VMSB and ".decnet" domain
To: Header-People@MIT-MC.ARPA
cc: Postmaster@AMES-VMSB.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052

     Calling the Protocol Police!  See enclosed message header.

     Can't SOMEBODY talk to the AMES people and convince them
that "max.decnet" is not a valid domain name?  According to
Hartman, the AMES mail maintainer insists that "max.decnet" is
the right thing to be sending out.  I have no idea who this
shadowy person is -- I asked Hartman to put me in touch with this
individual back when it was first announced that they were going
to "upgrade" their mailer to one which had the "official"
Internet mailboxes in "<@ames-vmsb.arpa:hartman@max.decnet>"
format.  No luck.  The most I heard was a nasty comment to the
effect that I obviously had not read RFC 821/822.

     Folks, I think it is time to revise the mailer standards
again.  Not change anything (let's have that as an EXPLICIT
instruction for the committee), just to rewrite out the
ambiguities which lead to this sort of lossage.

-- Mark --

Enclosure, for your inspection and amusement:

Return-Path: <@ames-vmsb.arpa:hartman@max.decnet>
Received: from ames-vmsb.arpa.ARPA (AMES-VMSB.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Tue 21 May 85 11:37:42-PDT
Date: 21 May 85 10:00:00 PDT
From: MAX::HARTMAN <hartman@max.decnet>
Subject: --- checksumming ---
To: info-atari <info-atari@su-score>
Reply-To: MAX::HARTMAN <hartman@max.decnet>

[Message text deleted]

			-Richard Hartman
			max.hartman@ames-vmsb
------
-------

Received: from USC-ISIF.ARPA by MIT-MC.ARPA; 21 May 85 19:02:29 EST
Date: 21 May 1985 15:21:58 PDT
From: POSTEL@USC-ISIF.ARPA
Subject: re: strange domains (e.g., "decnet")
To:   header-people@MIT-MC.ARPA
cc:   postmaster@AMES-VMSB.ARPA


All domain names must be registered with the NIC and meet some other
requirements.  The requirements are spelled out in RFC-920.

--jon.
-------

Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 21 May 85 19:10:16 EST
Date: Tue 21 May 85 15:44:15-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  AMES-VMSB and ".decnet" domain
To: ron@BRL.ARPA
cc: Header-People@MIT-MC.ARPA, Postmaster@AMES-VMSB.ARPA
In-Reply-To: Message from "Ron Natalie <ron@BRL.ARPA>" of Tue 21 May 85 15:43:14-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052

Ron -

     You know that, I know that, but try to convince the AMES people
of that!!!

-- Mark --
-------

Received: from BRL by MIT-MC.ARPA; 21 May 85 20:29:32 EST
Date:     Tue, 21 May 85 18:10:39 EDT
From:     Ron Natalie <ron@BRL.ARPA>
To:       Mark Crispin <MRC@SU-SCORE.ARPA>
cc:       Header-People@MIT-MC.ARPA, Postmaster@AMES-VMSB.ARPA
Subject:  Re:  AMES-VMSB and ".decnet" domain

"<@ames-vmsb.arpa:hartman@max.decnet>"

is no more legal than

<hartman@max.decnet>


Received: from Xerox.ARPA by MIT-MC.ARPA; 22 May 85 04:11:18 EST
Received: from Cabernet.MS by ArpaGateway.ms ; 22 MAY 85 01:08:02 PDT
Date: 22 May 85 01:06:43 PDT
From: Murray.pa@Xerox.ARPA
Subject: Domain names
In-reply-to: "MRC@SU-SCORE.ARPA's message of Tue, 21 May 85 14:45:59
 PDT"
To: Header-People@MIT-MC.ARPA
Cc: Murray.pa@Xerox.ARPA

As long as we are screaming about bogus names, I'll remind everybody
that there are lots and lots of systems out there that still think their
name is foo rather than foo.ARPA.

Anybody fixing their code to use domain names had better include some
hackery to default things to .ARPA if nothing better makes sense.



Received: from Xerox.ARPA by MIT-MC.ARPA; 22 May 85 15:46:02 EST
Received: from Cabernet.MS by ArpaGateway.ms ; 22 MAY 85 12:40:19 PDT
Date: 22 May 85 12:40:11 PDT
From: Murray.pa@Xerox.ARPA
Subject: Names with spaces
To: INFO-NETS@MIT-MC.ARPA, Postmaster@MIT-MC.ARPA, MsgGroup@BRL.ARPA,
 HEADER-PEOPLE@MIT-MC.ARPA
Cc: Murray.pa@Xerox.ARPA, Hamilton.OSBUSouth@Xerox.ARPA

A month or so ago, Bruce sent an innocent msg to INFO-NETS that caused a
lot of confusion. It seems as though lots of systems out there crashed
every half-hour or so whenever MC tried to (re)transmit Bruces' msg on
to them. The error message was something like "no closing quote". I
think some systems can't tolerate mismatched quotes in the From field of
the header, and MC managed to drop one.

I think the From line looked like this when it left here:
	From: "Bruce A. Hamilton.OsbuSouth"@Xerox.ARPA
The line that was killing CIT-VAX was:
	From: <Hamilton.OsbuSouth"@Xerox.ARPA>

Can anybody fill me in on the fine print? Is there something special
about the From line, or will any header line containing mismatched
quotes cause the same problem? Any reason why it crashes the system
instead of logging a message and blundering on?

The only victim I've been in contact with is CIT-VAX. I think they are
running a vanilla 4.2BSD. How many other systems got cought by the same
bug? Did your system crash? Is there a reasonable bug fix? Any hope of
fixing MC? ...

Sending mail that crashes systems is high on my list of things not to
do, especially when you can kill many systems with only one message.
Currently, I have a filter installed that rejects any outgoing msg if
the From field needs quoting. Is that good enough? (If you want a test
case, just let me know.)

-----

Part of our mail system makes heavy use of spaces in names. I'm getting
a lot of flak about rejecting all these messages.

We started seriously using quoted names with spaces early this year.
There were various bugs that had to be fixed, both here and at other
sites nearby where we exchange lots of mail. Things calmed down after a
while. Then Brian Reid started complaining. He is the postmaster at a
site that was relaying some of our mail on to the UUCP world. Several of
the next layer of machines didn't know about quotes, and the rejections
were landing in Brian's mailbox. I "solved" that one by translating all
the spaces to underbars in the return-path in the envelope. I did that
because I "knew" that none of our names contained any underbars so I
could make the reverse translation without fear of breaking anything.

Is the space/underbar substitution universal enough that I can do it to
the whole header without fear of mangling some address that really
should have a space in it? I haven't yet managed to convince myself that
I won't provoke a really obscure problem if I just blindly "fix" all the
quoted spaces to/from underbars.

Have all the (flakey) Unix systems out there established a de-facto
addendum to RFCs 821/822 that prohibits quoted strings?

-----

Does/will the X400 world have spaces in names, or will there be spaces
in names by the time they get mapped/translated into RFC 821/822 format?


Received: from SRI-CSL.ARPA by MIT-MC.ARPA; 22 May 85 17:24:07 EST
Date: 22 May 1985 14:11-PDT
Sender: GEOFF@SRI-CSL
Subject: Re: Names with spaces
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To: Murray.pa@XEROX
Cc: INFO-NETS@MIT-MC, Postmaster@MIT-MC, MsgGroup@BRL
Cc: HEADER-PEOPLE@MIT-MC, Hamilton.OSBUSouth@XEROX
Message-ID: <[SRI-CSL]22-May-85 14:11:11.GEOFF>
In-Reply-To: The message of 22 May 85 12:40:11 PDT from Murray.pa@XEROX.ARPA

Hal

Implementing "solutions" like changing spaces to underbars just to
keep people's mailers which can't grok legal protocol from crashing
seems inappropriate to me, at least in the long term.

If quoted spaces are indeed legal to send, well send them for heavens
sakes.  If they crash people's mailers, then those mailers should be
fixed -- plain and simple.  All it takes is one wizard to discern the
fix, post it, and everyone else should follow suit.

Thank goodness its a solid bug you've found, and not one that would
cause peoples mailer's to crash on every 3rd message to come by with a
quoted space when there's a full moon out or something like that.

g

Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA; 22 May 85 19:47:12 EST
Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 22 MAY 1985 19:38:38 EDT
Date: Wed, 22 May 85 16:14 PST
From: Dave Platt <Dave-Platt@LADC>
To: Header-People <Header-People@MIT-MC.ARPA>
Subject: Names with spaces, underscores, quoted names, etc.

We've had a slightly similar experience with our SMTP interface.
By way of introduction:  we (Honeywell's Los Angeles Development
Center) run our own O/S (CP-6) and mail package ("MAIL" - clever, no?)
and speak to the outside world via SMTP over an X.29 link to
an ARPA-node Multics site in Cambridge.  We look to the outside world
like a "local part" of CISL-SERVICE-MULTICS.

From what I've learned, the Multics SMTP software has only a partial
implementation of quoted names... it can accept quoted names in the
"local part" of a simple address, but not in a more complex address
with routing information included.  Eg., <"Dave Platt"@LADC> will work,
but their receiver barfs on <@CISL-SERVICE-MULTICS.ARPA:"Dave Platt"@LADC>.
Their software doesn't crash, it just rejects the address as being
illegal.

For this reason (and because we've been told that many mailers cannot
generate quoted names or handle names that contain blanks) we've gone
to a scheme such as that mentioned earlier - when we send mail outwards,
our mailer converts all embedded blanks into hyphens;  when we receive,
the receiver looks up the name as given by the sender, and if it doesn't
find it then maps hyphens into blanks and tries again.  Most mailers
seem to be able to handle names with hyphens, and we've had generally
good luck with this scheme.

It does seem a shame, though, that so many mailers don't accept a
legal construct.  We've found it much more practical to modify our
own software so that its output is acceptable to the "lowest common
denominator", rather than expecting everybody to handle every
construct permitted by the RFCs... unfortunate, but that seems to be
the way the world is working these days.

Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MC.ARPA; 22 May 85 21:06:13 EST
Received: FROM LADC BY CISL-SERVICE-MULTICS.ARPA WITH dial; 22 MAY 1985 21:02:30 EDT
Date: Wed, 22 May 85 17:56 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
To: Header-People <Header-People@MIT-MC.ARPA>
Subject: And, speaking of bad headers (blush!)

my flying fingers put a bug into our mailer's configuration file;   it
decided that MIT-MC (which uses the ARPA node tables) is the same thing
as MIT-MULTICS (which knows about us of its own free will), so my
previous mailgram had a From: address which isn't usable by anybody
on the net.  Sorry, folks.

Received: from rand-unix.ARPA by MIT-MC.ARPA; 22 May 85 21:36:42 EST
Received: by rand-unix.ARPA; Wed, 22 May 85 18:07:23 pdt
From: Steve Tepper <greep@rand-unix>
Message-Id: <8505230107.AA22510@rand-unix.ARPA>
Date: 22 May 85 18:07:15 PDT (Wed)
To: INFO-NETS@mit-mc, MsgGroup@brl, HEADER-PEOPLE@mit-mc
Subject: Re: Names with spaces

I will seize the current fracas about spaces in names as an opportunity
to give vent to a long-standing gripe, which has to to with network
protocols in general but is a particularly sore point when it comes
to mail.  My complaint is that, given the lack of any network police,
the decision as to who has to change what to make it work with something
else is often more of a political question than a technical one.

Typically the scenario is something like this:  User Foo@FooHost wants to
send mail to Bar@BarHost.  Now it turns out that the person who maintains
the software used at BarHost (who likely doesn't even work there, unless
BarHost is a one-of-a-kind operating system) has decided to "improve" the
mail system in some way which is uncontestably at variance with the
standard, with the result that some mail breaks.  A cleanliness freak
would, justifiedly, state flatly that the burden is on either BarHost or
their software maintainer to get it fixed.  The reality is unfortunately
different.  It may be that Bar@Barhost is Foo's project sponsor, or someone
else of sufficient stature that Foo considers the ability to communicate
electronically with Bar a high-priority matter.  Complaining that the
problem is at BarHost may be morally satisfying but does not get the
message delivered, especially if the person who made the offending change
is obstinate and claims that his "improved" version is so obviously
superior that it is incumbent on the rest of the world to mimic his changes
until they become a de facto standard.  The outcome: some poor soul at
FooHost has to figure out what BarHost's mail server is now willing to
accept and hack up FooHost's mailer to accomodate it, without disrupting
other mail services from FooHost in the process.

I am exerting considerable restraint here by refraining from mentioning
the names of any guilty parties (and all the cases I dealt with were too
far in the past to be of any immediate concern), but I'm sure other people
have also found themselves in the unpleasant situation of being the
person who had to "fix" something to accomodate someone else's non-standard
"improvements".

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 23 May 85 00:38:04 EST
Date:  Thu, 23 May 85 00:18 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Names with spaces
To:  Murray.pa@XEROX.ARPA
cc:  info-nets@MIT-MC.ARPA, MsgGroup@BRL.ARPA, 
     header-people@MIT-MC.ARPA, Hamilton.OSBUSouth@XEROX.ARPA
Message-ID:  <850523041830.813992@MIT-MULTICS.ARPA>


To answer the question that appeared at the end of the original message,
X.400 should not have any problems in this respect.  X.400 messages are
binary data structures, and the protocols between mailer processes are
also binary messages.  There is no text parsing involved.  For instance,
rather than having a mailer daemon transmit Character strings are
encoded as a type word followed by a length byte followed by the
specified number of characters (I am purposely simplifying, leaving out
things like the character set identifier).  No ambiguity is possible
within the protocol (of course, user interfaces are another problem, as
they must translate between this form and printed form).
                                        barmar

Received: from WISCVM.ARPA by MIT-MC.ARPA; 23 May 85 03:00:17 EST
Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 05/23/85 at
  01:57:45 CDT
Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
Received: by WEIZMANN (Mailer X1.20) id 7444; Thu, 23 May 85 09:41:21
  IDT
Date:         Thu, 23 May 85 09:33 IDT
From:           Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
Subject:      Lack of domain name
To:  <greep@rand-unix.arpa> ,
    <header-people@mit-mc.arpa>

Steve,

I couldn't agree with you more.  But when I tried to send a reply to you,
I looked at the the header I received:

> Received: from MIT-MC by wiscvm.arpa on 05/22/85 at 20:51:13 CDT
> Received: from rand-unix.ARPA by MIT-MC.ARPA; 22 May 85 21:36:42 EST
> Received: by rand-unix.ARPA; Wed, 22 May 85 18:07:23 pdt
> From: Steve Tepper <greep@rand-unix>
> Message-Id: <8505230107.AA22510@rand-unix.ARPA>
> Date: 22 May 85 18:07:15 PDT (Wed)
> To: INFO-NETS@mit-mc, MsgGroup@brl, HEADER-PEOPLE@mit-mc
> Subject: Re: Names with spaces

My mailer (and I doubt any mailer), can discern who 'rand-unix' is.  It could
be a node in csnet, it could be a node in mailnet but it happens to be a
node in Arpanet.  I have found very often that nodenames in Bitnet are the
same as nodenames in Arpanet and quite often they are not on the same host.
A fully qualified return address to you is 'greep@rand-unix.arpa'.  I'm
sure mail handlers in other domains other than Arpanet have the same problem
and usually the user either hand massages the 'To:' field or the mail gets
bounced because rand-unix is undefined.

People who live in accelerators shouldn't throw electrons!

Hank

Received: from BRL by MIT-MC.ARPA; 23 May 85 16:15:42 EST
Date:     Thu, 23 May 85 14:18:45 EDT
From:     Ron Natalie <ron@BRL.ARPA>
To:       Steve Tepper <greep@RAND-UNIX.ARPA>
cc:       INFO-NETS@MIT-MC.ARPA, MsgGroup@BRL.ARPA, HEADER-PEOPLE@MIT-MC.ARPA
Subject:  Re:  Names with spaces

AHEM.  Can we please get this discussion down to only one group please.


Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 24 May 85 19:58:51 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2663279796372244@MIT-MULTICS.ARPA>; 24 May 1985 19:56:36 edt
Date:        24 May 85 09:10 +0100
From:        Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Domain names defaulting
Message-ID:  <106044@QZCOM>
In-Reply-To: <105893@QZCOM>

Exactly! And the most important mailers to be fixed are the ones
acting as gateways into other netoworks - compared to postal
addresses we all know that Country is only required when addressing
someone outside current country, and can well be left out while
inside. This simple analogy should hold for E-mail too.




Received: from WISCVM.ARPA by MIT-MC.ARPA 29 May 85 11:25:04 EST
Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 05/29/85 at
  10:05:02 CDT
Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
Received: by WEIZMANN (Mailer X1.20) id 6389; Wed, 29 May 85 17:53:09
  IDT
Date:         Wed, 29 May 85 17:46 IDT
From:           Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
Subject:      Fully qualified nodenames
To:  <header-people@mit-mc.arpa>

For your amusement:

> -----------------------
> Received: from NYU-CMCL2.ARPA by wiscvm.arpa on 05/29/85 at 08:57:34 CDT
> Received: from NYU-CSD2.ARPA (nyu-csd2.arpa.ARPA) by NYU-CMCL2.ARPA; Wed, 29
>   May 85 09:56:57 edt
> Message-Id: <8505291356.AA29206@NYU-CMCL2.ARPA>
> Received: by NYU-CSD2.ARPA; Wed, 29 May 85 09:55:11 edt
> Date: Wed, 29 May 85 09:55:11 edt
> From: xxxxxx@NYU-CSD2
> To: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
> Subject: Re: VMNAMES & fully qualified return paths.
>
>
> I am sorry that I have used VMNAMES from a node which does not supply a
> fully qualified return address. Sorry for inconvenience.
>
>
> However, it might be interesting for you to know that some Bitnet sites
> have mailers capable of recognizing Arpanet (& other) addresses, though
> they are not actually residing at gateway nodes.
> A primary example of that is MAILER@CUNYVM (and, for that matter, MAILER@
> BITNIC). It would be helpful if more Bitnet nodes had this capability.
> It is also very reassuring to know that, as soon as the VMNAMES program
> is "migrated" to Bitnic, all the poor people from Arpanet whose mailers
> don't specify a fully qualified return address will be able to get their
> information painlessly. (Moreover, as Bitnic becomes an Arpanet node in the
> near future, the whole procedure will be simplified considerably).
>
>
> -------------------------
> Date:         Wed, 29 May 85 17:24 IDT
> From:         Henry Nussbacher <vshank@weizmann>
> Subject:      Re: VMNAMES & fully qualified return paths.
> To:           <xxxxxx@NYU-CSD2.ARPA>
> In-Reply-To:  Your message of Wed 29 May 85 09:55:11 edt
>
> I accept your answer but still think NYU is wrong.  What CUNYVM and
> BITNIC do is a crutch and a harmful one at that.  When I send a letter
> from NYC to Cambridge England, I had better put in the country - England,
> otherwise the postman will assume I mean Cambridge, Mass.  Most postmen
> will just make the letter - 'return to sender' and not try to make
> "assumptions" about what country the person meant.
>
> This becomes very painful when a node on Arpanet has the same name as
> a node on Bitnet.  Example: RICE.  It is a valid node in Bitnet and
> a completely different machine and host in Arpanet.  I don't think
> Arpanet and Bitnet care to have their hostnames validated by each other.
>
> Still think NYU-CSD2 is better (and easier) than NYU-CSD2.ARPA?
>
> Hank


There you have it.  Please note that it is not CUNYVM's fault for accepting
unqualified nodenames.  It is just that since one node has the capability
of doing it (and only getting it right 95% of the time - due to duplicates
of nodenames and the constant problem of having to update their tables
to reflect new Arpanet sites), people assume all sites in Bitnet can do
it.  Someone joked before about 'network police'; maybe there should be
some network header police and those nodes that don't conform to standards
be dropped from the Internet Host Table.

Hank

Received: from decwrl.ARPA by MIT-MC.ARPA 30 May 85 11:46:34 EST
Received: by decwrl.ARPA (4.22.01/4.7.34)
	id AA06731; Thu, 30 May 85 08:46:43 pdt
Received: by deccra.hudson (4.12/5.1.GaTech)
	id AA08099; Thu, 30 May 85 10:09:48 edt
Date: Thu, 30 May 85 10:09:48 edt
From: System Manager <deccra!deccra!root@decwrl.ARPA>
Posted-Date: Thu, 30 May 85 10:09:48 edt
Message-Id: <8505301409.AA08099@deccra.hudson>
To: header-people@mit-mc.ARPA
Subject: address change

If you have a ...!maynard!campbell on your mailing list, please
change it to LCampbell@mit-mc (it may have been changed or deleted
already, in which case please ignore this message).  Thanks!

Received: from Xerox.ARPA by MIT-MC.ARPA 30 May 85 15:43:14 EST
Received: from Semillon.ms by ArpaGateway.ms ; 30 MAY 85 12:41:05 PDT
Sender: "Albert C. Hall.osbunorth"@Xerox.ARPA
Date: 30 May 85 12:40:52 PDT (Thursday)
Subject: Header-People and X.400
From: AlHall.osbunorth@Xerox.ARPA
To: Header-People@MIT-MC.Arpa
cc: AlHall.osbunorth@Xerox.ARPA
Message-ID: <850530-124105-1371@Xerox>


Do any of you depend upon the ordering of ARPA headers ?  The answer to
this question would help me decide how much of the "extra" information
of the ARPA header needs to be preserved when the header is parsed into
X.400 Attributes.

For example, I assume that a set of Received: fields should be kept in
order, but does it make a difference to anyone if the entire block was
moved to, say, the end of the ARPA header ?

		Thanks,
		  Al

Received: from USC-ISIF.ARPA by MIT-MC.ARPA 30 May 85 17:08:25 EST
Date: 30 May 1985 14:00:34 PDT
From: POSTEL@USC-ISIF.ARPA
Subject: ARPA-Mail and X.400-Mail
To:   Header-People@MIT-MC.ARPA


Al Hall:

I am not sure i followed your question, but if you mean something like
"Is it ok to send a message via ARPA-mail with a block of "Recieved" lines
at the end of the header instead of the beginning of the header?", then
I'd say no.  One common problem in the world of mail is that each person that
builds a relay or forwarder asssumes that his relay is the one making the
"final" delivery to the end recipient, so it doesn't matter if he bends the
rules a little.

--jon.
-------

Received: from BRL-SEM.ARPA by MIT-MC.ARPA 30 May 85 18:05:13 EST
Date:     Thu, 30 May 85 16:13:06 EDT
From:     Doug Kingston <dpk@BRL.ARPA>
To:       "Albert C. Hall.osbunorth"@xerox.ARPA
cc:       Header-People@mit-mc.ARPA, AlHall.osbunorth@xerox.ARPA
Subject:  Re:  Header-People and X.400

Ordering of Received lines should be preserved.  Although they
are normally dated, having them in order prevents confusion and
protects against bad dates.

					-Doug-

Received: from rand-unix.ARPA by MIT-MC.ARPA  1 Jun 85 02:25:00 EST
Received: by rand-unix.ARPA; Fri, 31 May 85 23:18:23 pdt
From: Steve Tepper <greep@rand-unix>
Message-Id: <8506010618.AA09711@rand-unix.ARPA>
Date: 31 May 85 23:18:16 PDT (Fri)
To: AlHall.osbunorth@xerox.ARPA
Cc: Header-People@mit-mc
Subject: Re: Header-People and X.400
In-Reply-To: Your message of 30 May 85 12:40:52 PDT (Thursday).
	     <850530-124105-1371@Xerox>

Following the general guidelines about being a "strict constructionist"
about what you send but a "liberal" about what you accept, you should
be prepared to accept out-of-order "received" fields from other hosts.
I'm pretty sure I've seen mail come in with "received" fields out of
order (i.e. after other fields, not just out of chronological order
among themselves), so it's a pretty safe bet that you'll get in trouble
if you count on everyone doing the right thing.

Received: from ucla-locus.arpa by MIT-MC.ARPA  1 Jun 85 16:03:28 EST
Date:           Sat, 1 Jun 85 12:45:23 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header-People@MIT-MC.ARPA
Subject:        Re: RFC822/X.400 header transformations
References:     Message of 30 May 85 12:40:52 PDT (Thursday)
                    from "AlHall.osbunorth@Xerox.ARPA"
                    <850530-124105-1371@Xerox>
Message-ID:     <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU>

I believe that anyone who realistically hopes to take an RFC822-style
header, translate it into another form (X.400, internal data structure,
etc.), and then later translate that other form back into the original
RFC822-style header (or a completely equivalent header -- whatever THAT
means!), is taking his life in his hands.

The main problem is that RFC822 is an attempted compromise between a
mail-agent "transmission" standard (i.e., program-oriented) and a user-
agent "presentation" standard (i.e., human-oriented).  In actual prac-
tice, neither need is really fulfilled satisfactorily.

Please understand that I am not criticizing those involved in designing
RFC822 for doing things this way.  When 822 was being put together, the
realities of the ARPANET E-mail world were such that any radical effort
to introduce a totally new "transmission" format along the lines of the
NBS or X.400 standards would have been violently opposed -- or simply
ignored.  (Witness the fact that many sites, even now, continue to dis-
regard the proper RFC822 format of a "Date:" line!)

What I think we really need is an eventual conversion to a fixed-form
"transmission" standard for electronic mail.  The X.400 standard, which
seems to be gaining popularity elsewhere, might be a good choice (though
I admit I haven't thoroughly studied X.400 yet and cannot say for sure
whether it truly meets our community's needs).  Being (or at least try-
ing to be) a realist, however, I understand that a conversion to X.400
is not liable to happen very soon (and, inertia in certain circles being
what it is, may possibly never happen at all).

I would therefore propose as a stopgap measure that the existing RFC822
format be "tightened" by defining a complete, exact mapping between
RFC822 headers and X.400 headers.  Such a definition would specifically
allow any host, anywhere along the line of delivery of a given message
(including relay hosts), to convert any RFC822-style header into the
equivalent X.400 form -- and back again -- without any loss of essential
information.

(1) An exact definition of the semantics of RFC822, and a strict policy
    on what details are and are not important in a header, would enable
    a host (if it wished) to store the header ONLY in an internal form.

    The current philosophy that a relay should not "digest" and later
    "reconstruct" a header is, I feel, symptomatic of the fact that
    there is currently no agreement on precisely what the various parts
    of an RFC822 header really mean.

(2) Another reason to define an exact RFC822<->X.400 mapping is that, in
    the next several years, we might find ourselves obligated (either by
    practicality concerns or decrees from above) to conform to X.400 or
    some other "international" standard.  Witness, for instance, the
    current talk about eventual abandonment of TCP in favor of ISO TP-4
    (see RFC942).

    Defining a detailed correspondence between RFC822 and X.400 -- NOW
    -- would help bring to light any aspects of RFC822 which we have up
    to now considered indispensable, but which are not adequately ad-
    dressed by the X.400 standard.

    One example which comes to mind is the question of time zones in
    date/time strings (X.400 doesn't provide for the commonly used time
    zone abbreviations, allowing instead only the letter "Z" for UTC,
    or a "+/-hhmm" numeric zone specifier for other zones).  What should
    we do about the fact that an X.400 time strings cannot distinguish,
    for instance, between PDT and MST (since both have to be changed to
    the single form "-0700")?
 
    We owe it to ourselves to be fully aware of all such issues now.  We
    might or might not be able to change the character of the eventual
    standard to better suit our tastes and needs, but we certainly are
    not going to be able to have any say if we don't even know where all
    the problem areas are.

Some issues which should probably be addressed when defining the "offi-
cial" correspondence between RFC822 and X.400 headers are the following.
(This is NOT intended to be an all-inclusive list.)

(1) Ordering of lines in a header.

    Line order should certainly be preserved in some cases (e.g., the
    relative order of "Received:" lines should be preserved) -- but I am
    hard pressed to think of a convincing technical reason why the rela-
    tive ordering of such lines as "Date:", "From:", and "Subject:" is
    critical.

    For that matter, I don't see any reason why the placement of the
    block of "Received:" lines in the header (at the beginning, at the
    end, or in the middle) should be important at all from the stand-
    point of a transmission standard.

    In most cases, I suspect we will find that the relative sequence of
    header lines of different types is really completely unimportant.

(2) Date lines.

    I already mentioned the question of representation of time zones in
    X.400.  My other "pet peeve" is that I simply don't understand what
    excuse anyone has for continuing to output date strings that don't
    conform exactly to RFC822.  At the VERY least, no one who generates
    a nonstandard date string format should have any right to complain
    if a relaying site converts such a date string into the standard
    form (or even if the relaying site kicks the whole message back in
    the face of the sending site because of a fatal format error!).

(3) Comments in header lines.

    This, I think, is one of the most difficult aspects of RFC822 to
    deal with.  In theory, comments are supposed to be absolutely and
    completely equivalent to white space.  In actual practice, however,
    "comments" are used to supply full names, portions of full names,
    days of the week, additional host ID information in "Received:"
    lines, and who knows what other kinds of essential data.

    The problem is compounded by the fact that RFC822 allows comments to
    be used virtually anywhere at all in a header line.  This renders
    any serious attempt to parse a header, while retaining all the data
    contained therein (comments included), ludicrously awkward.

    I would strongly advocate that ALL such "semantic" uses of comments
    in RFC822 headers be phased out.  When converting an RFC822 header
    into another form, a receiving or relaying host should be able to
    simply throw away comments, without worrying that something valuable
    (such as the sender's full name) has thereby been lost.

Let me emphasize that I am NOT advocating the introduction of new fea-
tures or constructions not already in RFC822.  I am simply suggesting
the formulation of a "standard" or "canonical" subset of RFC822, into
which any header could safely/legally be mapped without loss of any im-
portant information.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@UCLA-LOCUS.ARPA  -or-  wales@LOCUS.UCLA.EDU
	UUCP:   ...!(ihnp4,ucbvax)!ucla-cs!wales

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA  2 Jun 85 15:33:44 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664041458856405@MIT-MULTICS.ARPA>; 02 Jun 1985 15:30:58 edt
Date:        02 Jun 85 13:56 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Cc:
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     Re: RFC822/X.400 header transformations
Message-ID:  <107311@QZCOM>
In-Reply-To: <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU>

Thank you for your presentation on the problem of RFC822/X.400
header transformation, where you gave lots of valuable ideas.

Here are some additional points to think about in this area:

EXISTING IMPLEMENTATIONS: There are several existing projects
working on such transformation. There is the EAN system, and
there are projects in Germany and the U.K. to make gateways between
EARN/BITNET, which uses RFC822 headers, into X.400. It would
be very valuable if the people behind these projects would produce
a paper describing how they have chosen to map RFC822 to X.400
and why.

COMMENTS IN NAMES: X.400 has in the IPMessageHeading fields for
originator and recipients. The value of each of these fields
has three elements: ORName, freeformName and telephoneNumber.
A good choice may be to map the exact address (addr-spec in
RFC822 terminology) onto the ORName, and map the comment
in the name (phrase in RFC822 terminology) onto the freeformName.

MESSAGE-ID-S: It is very important to ensure that these ID-s
can be transformed in a one-to-one manner, so that the same
ID will come back the same after transformation from RFC822 to
X.400 and back to RFC822 or the other way around. This will not
be simple, since the exact syntax for MESSAGE-ID-S is different.

In X.400, MESSAGE-ID-S are compulsory. Thus, for RFC822 messages
lacking such an idea, one has to be generated. I suggest that
this is done using the algorithm for producing a Message-ID by
a hasked checksum of the originator, the date of writing and
the contents, which I suggested in a message a couple of months
back.

The RFC822 Message-ID corresponds best to the IPMessageID in
X.400. X.400 also has several other kinds of MessageID-s. There
are so-called "event-id"-s, which are of a transitory nature
and need not have any RFC822 translation. There is something
called "UA-content-id", which should probably also be mapped
from the RFC822 Message-ID, although the IPMessageID is more
important.

Robert Babatz and Manfred Bogen at the GMD in Germany have in
a paper entitled "Semantic Relations in Message Handling Systems"
(Their address, if you want a copy, is Scholls Birlinghoven,
D-5205 Sankt Augustin, Germany) have pointed out and clarified
the problems caused by the fact that X.400 provides a new IPMessage
Heading envelope around the old message (including all old envelopes)
when the message is forwarde (by e.g. a mailing list) and clarified
which of these IPMessageId-s (the innermost) really refers to
the content of the message - it is this innermost Id which should
be mapped in most cases to/from RFC822 Message-id-s.



Received: from csnet-relay by MIT-MC.ARPA  2 Jun 85 20:14:40 EST
Received: from buffalo by csnet-relay.csnet id aa11283; 2 Jun 85 20:09 EDT
Received: by gort.SUNYAB (4.12/4.7)
	id AA00958; Sat, 1 Jun 85 20:59:34 edt
Date: Sat, 1 Jun 85 20:59:34 edt
From: John Robert LoVerso <loverso%buffalo.csnet@csnet-relay.arpa>
Word-Of-The-Day: Odin
To: Header-People@mit-mc.ARPA
Subject: Re: Header-People and X.400

> I'm pretty sure I've seen mail come in with "received" fields out of
> order (i.e. after other fields, not just out of chronological order
> among themselves)

Its already happening.  For example, PMDF 4.2v3 (the software distributed
for 4.2 CSNET Phonenet sites) places the "received" line at the END of the
header.

	John


Received: from MIT-XX.ARPA by MIT-MC.ARPA  3 Jun 85 21:55:24 EST
Date: Mon 3 Jun 85 21:55:02-EDT
From: Bard Bloom <BARD@MIT-XX.ARPA>
Subject: Directory
To: header-people@MIT-MC.ARPA


Are there network directories on-line anywhere?
(Reply to BARD@MIT-XX, please.)

Thanks;
   Bard "Obviously a novice" Bloom
-------

Received: from decwrl.ARPA by MIT-MC.ARPA  4 Jun 85 02:42:44 EST
Received: by decwrl.ARPA (4.22.01/4.7.34)
	id AA07318; Mon, 3 Jun 85 23:42:58 pdt
Received: by deccra.hudson (4.12/5.1.GaTech)
	id AA07292; Tue, 4 Jun 85 02:38:33 edt
Date: Tue, 4 Jun 85 02:38:33 edt
From: System Manager <deccra!deccra!root@decwrl.ARPA>
Posted-Date: Tue, 4 Jun 85 02:38:33 edt
Message-Id: <8506040638.AA07292@deccra.hudson>
To: header-people@mit-mc.ARPA
Subject: please remove campbell@maynard.uucp from this list


He is no longer accessible via that path.

	From MAILER-DAEMON@decwrl.UUCP Tue Jun  4 02:32:01 1985
	Received: by deccra.hudson (4.12/5.1.GaTech)
		id AA07246; Tue, 4 Jun 85 02:31:56 edt
	Posted-Date: Sat, 1 Jun 85 20:59:34 edt
	Received: by decwrl.ARPA (4.22.01/4.7.34)
		id AA19551; Mon, 3 Jun 85 03:33:56 pdt
	Date: Sat, 1 Jun 85 20:59:34 edt
	From: MAILER-DAEMON@decwrl.UUCP (Mail Delivery Subsystem)
	Subject: Returned mail: User unknown
	Message-Id: <8506031033.AA19551@decwrl.ARPA>
	To: MAILER-DAEMON@deccra.hudson
	Status: O
	
	   ----- Transcript of session follows -----
	>>> RCPT To:<decwrl!@MIT-MC.ARPA:loverso%buffalo.csnet%csnet-relay>
	<<< 550 Unable to parse address
	550 decwrl!@MIT-MC.ARPA:loverso%buffalo.csnet%csnet-relay.ARPA... User unknown
	
	   ----- Unsent message follows -----
	Received: by decwrl.ARPA (4.22.01/4.7.34)
		id AA19549; Mon, 3 Jun 85 03:33:56 pdt
	Received: by deccra.hudson (4.12/5.1.GaTech)
		id AA02316; Mon, 3 Jun 85 06:04:09 edt
	Date: Sat, 1 Jun 85 20:59:34 edt
	From: Mail Delivery Subsystem <deccra!deccra!MAILER-DAEMON>
	Subject: Returned mail: unknown mailer error 101
	Posted-Date: Sat, 1 Jun 85 20:59:34 edt
	Message-Id: <8506031004.AA02316@deccra.hudson>
	To: %MIT-MC.ARPA:loverso@buffalo.CSNet@decwrl
	
	   ----- Transcript of session follows -----
	unknown flag -L
	unknown flag -adecwrl!@MIT-MC.ARPA:loverso%buffalo.csnet@csnet-relay.arpa
	bad system name: maynard
	uux failed. code 101
	554 maynard!campbell... unknown mailer error 101
	
	   ----- Unsent message follows -----
	Received: by deccra.hudson (4.12/5.1.GaTech)
		id AA02308; Mon, 3 Jun 85 06:04:09 edt
	Posted-Date: Sat, 1 Jun 85 20:59:34 edt
	Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by decwrl.ARPA (4.22.01/4.7.34)
		id AA14193; Sun, 2 Jun 85 17:28:29 pdt
	Message-Id: <8506030028.AA14193@decwrl.ARPA>
	Received: from csnet-relay by MIT-MC.ARPA  2 Jun 85 20:14:40 EST
	Received: from buffalo by csnet-relay.csnet id aa11283; 2 Jun 85 20:09 EDT
	Received: by gort.SUNYAB (4.12/4.7)
		id AA00958; Sat, 1 Jun 85 20:59:34 edt
	Date: Sat, 1 Jun 85 20:59:34 edt
	From: John Robert LoVerso <decwrl!loverso@buffalo.CSNet>
	Word-Of-The-Day: Odin
	To: Header-People@mit-mc.ARPA
	Subject: Re: Header-People and X.400
	
	> I'm pretty sure I've seen mail come in with "received" fields out of
	> order (i.e. after other fields, not just out of chronological order
	> among themselves)
	
	Its already happening.  For example, PMDF 4.2v3 (the software distributed
	for 4.2 CSNET Phonenet sites) places the "received" line at the END of the
	header.
	
		John
	
	
	

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA  4 Jun 85 15:25:18 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2664213453834463@MIT-MULTICS.ARPA>; 04 Jun 1985 15:17:33 edt
Date:        04 Jun 85 18:24 +0100
From:        Paul_Bryant%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 Academic_network_cooperation_group%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Cc:
 COST-11-ter_proposal_for_a_message_project%QZCOM.MAILNET@MIT-MULTICS.ARPA,
 Academic_network_cooperation_group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             academic_network_cooperation@WISC-RSCH.ARPA
Subject:     Re: RFC822/X.400 header transformations
Message-ID:  <107603@QZCOM>
In-Reply-To: <486503123-12850-wales@DIANA.LOCUS.UCLA.EDU>

Without having had time to digest your comment fully I support your
concern and need to define how X400 and RFC822 should interwork.
Some preliminary work along these lines has been done in the UK but the
work would benifit from being international.
I am not so pessamistic as you are on the difficulties as I suspect that
unless you are a purist you should normally be able to get mail
through with a somewhat relaxed attitude to ignoring the curiosities
and keeping the fingers crossed. Certainly the current gateways
between so called RFC822 offerings leave a lot to be desired and it should not
take too much effort to reach that low level although I would certainly
like to see high quality gateways which where not hacked together
on a wet Sunday afternoon.
This should be a topic for the Stockholm meeting.





Received: from WISCVM.ARPA by MIT-MC.ARPA  5 Jun 85 10:03:53 EST
Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 06/05/85 at
  06:51:19 CDT
Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
Received: by WEIZMANN (Mailer X1.20) id 6302; Wed, 05 Jun 85 14:36:25
  GMT
Date:         Wed, 5 Jun 85 14:33 GMT
From:           Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
To:  <header-people@mit-mc.arpa>

I really hate users who send mail with the following format:

user (John Q. Public) @ node

Can anyone please elucidate as to why this format is quite popular
among a number of nodes?  Are they all running the same bad software?
Is this format a forerunner to the current RFC822 format and these
sites don't wish to give it up?

Received: from nrl-aic by MIT-MC.ARPA  6 Jun 85 00:29:55 EST
Date: 5 Jun 1985 23:01:37 EDT (Wed)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Hateful users
To: Henry Nussbacher <vshank%weizmann.BITNET@WISCVM.ARPA>
Cc: Header-People@MIT-MC.ARPA
Message-Id: <486874897/hoey@nrl-aic>
In-Reply-To: Henry Nussbacher's message of Wed, 5 Jun 85 1433 GMT

    Date:         Wed, 5 Jun 85 14:33 GMT
    From: Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
    To: <header-people@mit-mc.arpa>

    I really hate users who send mail with the following format:

    user (John Q. Public) @ node

I, on the other hand, reserve my displeasure for people who send mail
without specifying a subject.  Perhaps we can discuss the technical
aspects despite our mutual animosity.

    Can anyone please elucidate as to why this format is quite popular
    among a number of nodes?

Possibly because it conforms to RFC822.  The popular alternative,
``John Q. Public <user@node>'', while used by quite a few sites, does
not conform.  In RFC822,

     3.4.3.  COMMENTS

        A comment is a set of ASCII characters, which is  enclosed  in
        matching  parentheses  and which is not within a quoted-string
        The comment construct permits message originators to add  text
        which  will  be  useful  for  human readers, but which will be
        ignored by the formal semantics.

seems to allow the form you cite.  My reading of this is supported by
examples such as

     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US

             The "(the  Stilt)" is a comment, which is NOT included in
        the  destination  mailbox  address  handed  to the originating
        system's mailer.  The local-part of the address is the  string
        "Wilt.Chamberlain", with NO space between the first and second
        words.

However, the rules

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec
     route-addr  =  "<" [route] addr-spec ">"
     phrase      =  1*word                       ; Sequence of words
     word        =  atom / quoted-string
     atom        =  1*<any CHAR except specials, SPACE and CTLs>
     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
                 /  "." / "[" / "]"              ;  within a word.

prohibit the alternative from, because a <phrase> may not contain any
"." characters.

Dan Hoey

Received: from BRL-TGR.ARPA by MIT-MC.ARPA  6 Jun 85 01:06:14 EST
Date:     Wed, 5 Jun 85 11:04:27 EDT
From:     Ron Natalie <ron@BRL.ARPA>
To:       Henry Nussbacher <vshank%weizmann.BITNET@WISCVM.ARPA>
cc:       header-people@MIT-MC.ARPA

That address is perfectly valid RFC822.

-Ron

Received: from WISCVM.ARPA by MIT-MC.ARPA  6 Jun 85 02:47:03 EST
Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 06/06/85 at
  01:45:15 CDT
Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA
Received: by WEIZMANN (Mailer X1.20) id 2115; Thu, 06 Jun 85 09:30:05
  GMT
Date:  Thu, 6 Jun 85 09:29 GMT
From:    Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
To:  <header-people@mit-mc.arpa>
Subject:      Sorry

1) I am sorry for not including a Subject field
2) I am sorry for not reading fully the RFC822 standard and understanding
   that user (name) @ node is valid RFC822.
3) I am a bit confused on what you had to say:
   Possibly because it conforms to RFC822.  The popular alternative,
   ``John Q. Public <user@node>'', while used by quite a few sites, does
   not conform.  In RFC822,
Does that mean that my From: field is incorrect?
     A.1.  ADDRESSES

     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>

     A.1.2.  Neuman@BBN-TENEXA

             These two "Alfred Neuman" examples have identical  seman-
        tics, as far as the operation of the local host's mail sending
        (distribution) program (also sometimes  called  its  "mailer")
        and  the remote host's mail protocol server are concerned.  In
        the first example, the  "Alfred  Neuman"  is  ignored  by  the
        mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
        pient.  The second example contains  no  superfluous  informa-
        tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
        pient.

Is the '.' in the John Q. Public that is invalid or is it the '.' within
the '<>' (i.e. .ARPA) that is invalid?

An aside: I now realize how poor a medium electronic mail is.  My comment
of 'I really hate users...' was said with a different tone of voice than
was construed.  I felt like I was sitting around a table and drinking some
beer and talking to friends and saying, 'Don't you just hate it when...'.
I'll be more careful in the future.

Hank

Received: from ucla-locus.arpa by MIT-MC.ARPA  6 Jun 85 18:38:47 EST
Date:           Thu, 6 Jun 85 15:25:21 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header-People@MIT-MC.ARPA
Subject:        Re: "user (John Q. Public) @ node"
References:     Message of Wed, 5 Jun 85 14:33 GMT
                    from "Henry Nussbacher
                        <vshank%weizmann.BITNET@WISCVM.ARPA>"
Message-ID:     <486944721-3999-wales@MEDEA.LOCUS.UCLA.EDU>

As has been noted several times already, an address of the form

		    user (John Q. Public) @ node

is perfectly valid according to the syntax requirements of RFC822.  Any
site whose mail software cannot recognize that the above is equivalent
to the address "user@node" should definitely upgrade their software.

For that matter, of course, an address of the form

		     user@node (John Q. Public)

-- which is apparently the format preferred by "sendmail" -- is also
legal, and completely equivalent in meaning to the first form with the
embedded comment.

However, I have serious objections to the idea of enclosing the full
name in a comment at all.  I would MUCH rather see all sites use the
facility which RFC822 has already provided for representing full names
in addresses -- namely, the prepended phrase:

		    "John Q. Public" <user@node>

(Note that the quotes are required in this particular case ONLY because
the full name in question contains a period.)

If the full name were always represented as a prepended phrase, then it
would be trivial to pick it out of the header.  An RFC822 parser quickly
becomes VERY messy, on the other hand, when you have to hang on to all
the comments until the bitter end -- on the off-chance (or likelihood!)
that one of these may contain the "full name" portion of an address.

I, for one, would vastly prefer to be able to treat comments as abso-
lutely equivalent to white space (as they are supposed to be in RFC822),
and simply toss them out during the lexical-analysis phase of a header-
cruncher.  But it's sheer folly to even think of doing this when so many
sites insist on putting people's full names in comments.

Please understand that what I am taking issue with is NOT the syntactic
legality of an address with a "full-name comment".  Without question,
such an address is "legal" according to RFC822.  What I am objecting to
is the expectation that my (or anyone's) software should have to recog-
nize said "full-name comment" as containing a user's full name.

Actually, I frequently think that comments in headers are more trouble
than they're worth, and that RFC822 might have been better off without
providing for them at all.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@UCLA-LOCUS.ARPA  -or-  wales@LOCUS.UCLA.EDU
	UUCP:   ...!(ihnp4,ucbvax)!ucla-cs!wales

Received: from rand-unix.ARPA by MIT-MC.ARPA  7 Jun 85 00:39:38 EST
Received: from vortex.UUCP by rand-unix.ARPA; Thu, 6 Jun 85 21:30:49 pdt
Date: Thu, 6-Jun-85 20:38:32 PDT
From: vortex!lauren@rand-unix (Lauren Weinstein)
Subject: Re: "user (John Q. Public) @ node"
Message-Id: <8506062038.2663.1.VT1.00C@vortex.UUCP>
To: wales@UCLA-LOCUS.ARPA
Cc: header-people@MC.ARPA
In-Reply-To: Your message of Thu, 6 Jun 85 15:25:21 PDT

I also prefer:

Lauren Weinstein <Lauren@RAND-UNIX>

on the From: line.  However, every damn time I've tried turning
on the #ifdef in my code that enables it, I get flooded with
mail from sites which can only handle the "(  )" comment form.

I finally gave up.

--Lauren--


Received: from Xerox.ARPA by MIT-MC.ARPA 12 Jun 85 21:23:28 EST
Received: from Salvador.ms by ArpaGateway.ms ; 12 JUN 85 18:21:08 PDT
Sender: "Albert C. Hall.osbunorth"@Xerox.ARPA
Date: 12 Jun 85 18:20:46 PDT (Wednesday)
Subject: Re: RFC822/X.400 header transformations
From: AlHall.osbunorth@Xerox.ARPA
To: wales@UCLA-LOCUS.Arpa
cc: Header-People@MIT-MC.Arpa, AlHall.osbunorth@Xerox.ARPA
In-Reply-to: wales%UCLA-LOCUS:ARPA's message of 1 Jun 85 13:14:42 PDT
 (Saturday)
Message-ID: <850612-182108-1114@Xerox>


Rich:

I agree that a fixed-form version of RFC822 would be easier to convert
to and from X.400-style Attributes, but I don't see this as being a good
short-term solution; I doubt that it will be any easier to get people to
adapt to a structured version of RFC822 than it is to get them to format
their dates correctly in the current RFC822.  On the other hand, I would
guess that existing X.400/Arpa gateway implementations take an approach
similar to another point you made: any non-structured information such
as comments are regarded as unimportant and are simply thrown away.

Since I believe comments to be quite valuable in providing context for
often-nonsensical address strings, I would prefer to see the comments,
etc. placed in some secondary part of the message.  This way, the choice
of whether the information is displayed is up to the destination User
Agent, and the information is available to be recovered in the case that
the message passes back into ArpaLand.

		-- Al

Received: from UCI-ICSA by MIT-MC.ARPA 13 Jun 85 04:16:09 EST
To: Header-People@mit-mc
cc: stef@uci-icsa
Subject: Re: RFC822/X.400 header transformations
In-reply-to: Message of 12 Jun 85 18:20:46 PDT () <850612-182108-1114@Xerox>
Date: 12 Jun 85 22:50:05 PDT (Wed)
From: Einar Stefferud <stef@uci-icsa>
Received: from Localhost by UCI-ICSA; 12 Jun 85 22:51:06 PDT (Wed)

It seems to me that a little redundancy might solve some problems here.

How about putting the entire commented address in the FreeFormName
X.400 subfield and the netted-out (comments removed) address in the
ORName subfield, so that no information is lost to the recipient, going
in either direction.  This means that a message going from 822 to
X./400 and back to 8922 will have a new additional field called
"FreeFormName: " but no information will be deliberately tossed.

I find that redundancy is useful for people, though I know that
programmers do not like to find it in parsable address fields.  My
point is that the FreeFormName subfield is there primarily for human
consumption to help recipients relate to an  addressees identity, so
lets put it to its intended purpose.

=====

As for the ordering of header fields in 822, it seems to me that only
the Received fields are defined to lend meaning by their ordering, and
it is well known that having them stacked in reverse order at the top
(last-first) is the most helpful in case of recipient need.  The reason
for this is that Recieved fields are really "postmarks" written onto
the "envelope" (which in 822 is mixed with the other header fields for
lack of a separate place to put them).

So, it should suffice to retain the order for Recieved fields in going
from 822 to X.400.  Going the other way should not be a problem,
because X.400 has a separate place to to carry them and as long as they
are stashed into the 822 headers in order, that should be all that is
needed.

Stef

Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 16:29:29 EST
To: header-people@mit-mc
cc: iglesias@uci-icsa
Subject: Parser for RFC822 headers wanted
Date: 18 Jun 85 13:28:20 PDT (Tue)
From: Mike Iglesias <iglesias@uci-icsa>
Received: from Localhost by UCI-ICSA for iglesias; 18 Jun 85 13:28:45 PDT (Tue)

Does anybody have a parser that parses RFC822 style headers, especially
addresses?  I don't want to reinvent the wheel.  I'd prefer something
that is not written in C, as I don't know C and don't have the time
to learn it.  I'm going to be interfacing a Honeywell CP-6 system to
several other systems/nets (BITNET for example).  I already have
Dave Platt's (Dave-Platt%LADC@CISL) code, but it doesn't do
everything that I need.

Thanks for your help,

Mike Iglesias
University of California, Irvine

Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 16:29:29 EST
To: header-people@mit-mc
cc: iglesias@uci-icsa
Subject: Parser for RFC822 headers wanted
Date: 18 Jun 85 13:28:20 PDT (Tue)
From: Mike Iglesias <iglesias@uci-icsa>
Received: from Localhost by UCI-ICSA for iglesias; 18 Jun 85 13:28:45 PDT (Tue)

Does anybody have a parser that parses RFC822 style headers, especially
addresses?  I don't want to reinvent the wheel.  I'd prefer something
that is not written in C, as I don't know C and don't have the time
to learn it.  I'm going to be interfacing a Honeywell CP-6 system to
several other systems/nets (BITNET for example).  I already have
Dave Platt's (Dave-Platt%LADC@CISL) code, but it doesn't do
everything that I need.

Thanks for your help,

Mike Iglesias
University of California, Irvine

Received: from UCI-ICSA by MIT-MC.ARPA 18 Jun 85 18:40:56 EST
To: header-people@mit-mc
Subject: Parser for RFC822 headers wanted (addendum)
Date: 18 Jun 85 15:39:58 PDT (Tue)
From: Mike Iglesias <iglesias@uci-icsa>
Received: from Localhost by UCI-ICSA; 18 Jun 85 15:40:10 PDT (Tue)

I may have been unclear in my last message.  What I want is a working
parser that I can use as a guide, not one that works on a CP6 system.

Mike Iglesias
University of California, Irvine

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 22 Jun 85 14:51:55 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665767126122366@MIT-MULTICS.ARPA>; 22 Jun 1985 14:52:06 edt
Date:        21 Jun 85 13:42 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Parser for RFC822 headers wanted (addendum)
Message-ID:  <109974@QZCOM>
In-Reply-To: <109733@QZCOM>

A general advice: Do not write a parser which parses the RFC822
standard as written in the RFC822 paper. You will then have to
re-write everything. Write a parser which parses the existing
de-facto-standard, which is in some cases different from RFC822,
and which is very permissive in accepting and trying to understand
all possible reasonable and unreasonable variants of RFC822.

For example, the standard in RFC822 says that the character "@",
if occuring inside a quoted string, is not significant. Do not
believe it. The standard further says that a lot of characters,
including spaces, are legal in mames if you put double-quotes
around them. Do not believe that either. De-facto-standard seems
to be that spaces are translated into under-lines to create legal
RFC822 names, not by embedding in double-quotes as the standard
says.

Further, you will encounter and have to be able to parse name
strings like
mcvax!inria!gipsy!ch@seismo
which is a mixture of UUCP and ARPA notations. The correct RFC-format
should be:
@seismo,@mcvax,@inria,@gipsy:ch@gipsy
but that format is NEVER used in this case.

Finally, you will find that what according to the standard should
be written as e.g.:
@MIT-MULTICS.ARPA,@QZCOM.MAILNET:Jacob_Palme@QZCOM.MAILNET
is very often instead written as:
Jacob_Palme%QZCOM.MAILNET@MIT-MULTICS.ARPA



Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 23 Jun 85 01:43:34 EST
Date: Sun, 23 Jun 85 01:42 EDT
From: don.provan@CMU-CS-A.ARPA
To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)
CC: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    header-people <header-people@MIT-MC.ARPA>,
In-Reply-To: <109974@QZCOM>
Message-Id: <23Jun85.014250.DP0N@CMU-CS-A.ARPA>

Allow me to be the first to shout BULLSH*T very loud in your ear.
Do *NOT*, repeat, do *NOT* write a parser which cannot properly
parse quoted strings, including quoted spaces and at signs.  The
reason there are all these idiotic de facto standards is because
so many people wrote poor parsers.  All parsers, even ones already
running, must be able to handle every example you mention properly.
If they don't they have bugs and should be fixed immediately.

None of the examples you give involving host names should be any business
whatsoever of a parser.  All of them are examples of legal addresses
designed to get accross the maze of networks to anyone who can properly
parse an 822 addresses and allow for replies.  In fact, the two alternates
you suggest aren't legal because of a restriction against non-internet
host names.

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 23 Jun 85 14:10:18 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665850640639152@MIT-MULTICS.ARPA>; 23 Jun 1985 14:04:00 edt
Date:        23 Jun 85 14:25 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Parser for RFC822 headers wanted (addendum)
Message-ID:  <110185@QZCOM>
In-Reply-To: <23Jun85.014250.DP0N@CMU-CS-A.ARPA>

     FROM: don.provan@CMU-CS-A.ARPA

     Allow me to be the first to shout BULLSH*T very loud in your ear.
     Do *NOT*, repeat, do *NOT* write a parser which cannot properly
     parse quoted strings, including quoted spaces and at signs...

     None of the examples you give involving host names should be any business
     whatsoever of a parser....

Well, that depends on the goal of your parser. For my message system,
an important goal of the parser is to be able to identify uniquely
the name of a mailbox, so that occurence of the same mailbox
in several incoming messages can be identified to refer to the
same mailbox. This is important, in order for example to make it
easy for our users to search in the message data base for a message
written by or to a certain external mailbox. And if that is your
goal, then the kind of deep parsing I do is necessary.

Of course, if you only want to do a superficial parsing, not
extracting full information from the header, then a more limited
parsing of the kind you suggest is acceptable.



Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 23 Jun 85 19:17:30 EST
Date: Sun, 23 Jun 85 17:27 EDT
From: don.provan@CMU-CS-A.ARPA
To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)
CC: , Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    header-people <header-people@MIT-MC.ARPA>
In-Reply-To: <110185@QZCOM>
Message-Id: <23Jun85.172707.DP0N@CMU-CS-A.ARPA>

I disagree.  The "external mailbox" in 822 format for you, for example,
is Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA.  Your mailer should
always generate that name in the from field of messages if you wish it
to be used to identify you.  Any attempt by any entity other than your
mail system to parse your address in any way but 822 format is doomed
to failure.  822 is the rule book for the game.  If you try to put
additional rules onto your parser, then no one can make any guarentee
about whether or not you'll be able to identify the sending person.

My point is that we can all go out and spend the rest of lives trying
to cover situation where stupid mail systems on UUCP give route dependent
from IDs, but the best thing to do is fix the stupid senders, not teach
every mail system in the world that this stupid mail system does this and
that stupid mailer does that.

Just because in your mail system, spaces and underlines are equivalent,
don't assume they're equivalent in my mail system.  I'll return the favour
by not assuming that hash marks and spaces are equivalent in your system.

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 16:27:04 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665944679317771@MIT-MULTICS.ARPA>; 24 Jun 1985 16:11:19 edt
Date:        24 Jun 85 17:00 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Parser for RFC822 headers wanted (addendum)
Message-ID:  <110264@QZCOM>
In-Reply-To: <23Jun85.172707.DP0N@CMU-CS-A.ARPA>

When a message written by me is transferred to you via MIT-MULTICS,
then my mailbox name is
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
But a message written by me might also get sent first to some
host on JANET, and then forwarded to you from JANET, and then
you would get my mailbox name as
Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA

If your mail system did not parse the complete address string,
it might have trouble performing commands such as "Find me the
last three messages I got written by the person who wrote
the last message I got".

This is a matter of what your goal is. If your goal is to extract
exactly and only the information defined in the RFC822 syntax,
then you are right. If your goal is to extract all the information
given in the message headers which you can use to help the users
of your mail system, then for some mail systems at least a fuller
analysis is better.

On the matter of underscore=space: I did not want to translate
spaces to underscores. I would much better prefer to send out
my name as
"Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA
or as
"Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA
The reason I am not doing that is that many mail systems are
not able to handle that kind of constructs!



Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 16:27:04 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2665944679317771@MIT-MULTICS.ARPA>; 24 Jun 1985 16:11:19 edt
Date:        24 Jun 85 17:00 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Parser for RFC822 headers wanted (addendum)
Message-ID:  <110264@QZCOM>
In-Reply-To: <23Jun85.172707.DP0N@CMU-CS-A.ARPA>

When a message written by me is transferred to you via MIT-MULTICS,
then my mailbox name is
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
But a message written by me might also get sent first to some
host on JANET, and then forwarded to you from JANET, and then
you would get my mailbox name as
Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA

If your mail system did not parse the complete address string,
it might have trouble performing commands such as "Find me the
last three messages I got written by the person who wrote
the last message I got".

This is a matter of what your goal is. If your goal is to extract
exactly and only the information defined in the RFC822 syntax,
then you are right. If your goal is to extract all the information
given in the message headers which you can use to help the users
of your mail system, then for some mail systems at least a fuller
analysis is better.

On the matter of underscore=space: I did not want to translate
spaces to underscores. I would much better prefer to send out
my name as
"Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA
or as
"Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA
The reason I am not doing that is that many mail systems are
not able to handle that kind of constructs!



Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 24 Jun 85 18:25:59 EST
Date:  Mon, 24 Jun 85 18:24 EDT
From:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject:  Re: Parser for RFC822 headers wanted (addendum)
To:  header-people@MIT-MC.ARPA
Message-ID:  <850624222459.771443@MIT-MULTICS.ARPA>

I agree with Don Provan on this.  No host has any business parsing the
local-part of an address but that host.  To give a concrete example
where this would screw up, consider the character "." in a local-part,
i.e.  the address
          foo.bar @ host
 If host is CSNET-RELAY then this refers to the user foo on the host
bar.CSNET.  However, if host is a Multics or TOPS-20 it means the user
foo.bar.  Also, there is no well-defined precedence for many of the
combinations; for instance, does
          host1!host2!user@host3
 mean
          host3 -> host1 -> host2 -> user
 or
          host1 -> host2 -> host3 -> user
 or
          host1 -> host3 -> host2 -> user
 ?  All three are possible depending on the configuration files at the
host that sent the message and host1 and host3, and there is no way for
anyone else's parser to know which it will be.

Is this a mess?  You bet!  But don't make it messier by writing a parser
that tries to second-guess the rest of the network.
                                        barmar

Received: from ucla-locus.arpa by MIT-MC.ARPA 24 Jun 85 20:19:09 EST
Date:           Mon, 24 Jun 85 17:08:23 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header-People@MIT-MC.ARPA
Subject:        Re: Parser for RFC822 headers wanted (addendum)
In-reply-to:    Message of 24 Jun 85 17:00 +0100
                    from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA"
                    <110264@QZCOM>
Message-ID:     <488506103-12477-wales@DIANA.LOCUS.UCLA.EDU>

Jacob --

Replying to your message:

	When a message written by me is transferred to you via
	MIT-MULTICS, then my mailbox name is

		Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA

	But a message written by me might also get sent first to some
	host on JANET, and then forwarded to you from JANET, and then
	you would get my mailbox name as

		Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA

	If your mail system did not parse the complete address string,
	it might have trouble performing commands such as "Find me the
	last three messages I got written by the person who wrote
	the last message I got".

	This is a matter of what your goal is.  If your goal is to
	extract exactly and only the information defined in the RFC822
	syntax, then you are right.  If your goal is to extract all the
	information given in the message headers which you can use to
	help the users of your mail system, then for some mail systems
	at least a fuller analysis is better.

Two comments:

(1) The use of "%" as a special character, denoting subnetting or
    source-routing ("user%route" format), is of course official in the
    JANET system (JNT Mail Protocol, Revision 1.0, Section 2.2.4).

    RFC822, on the other hand, does not assign any special meaning to
    "%".  Everything to the left of the "@" is, from the RFC822 stand-
    point, a monolithic object called a "local part", the interpretation
    of which is left entirely up to the destination host.

    "%" as a subnetting symbol is, in actual practice, a widespread "de
    facto" convention in the ARPA Internet world.  Although there is
    nothing in RFC822 which demands that it be used in this way and no
    other way, I am not aware of any host which uses "%" in its local
    addressing scheme to mean anything other than subnetting.

    Note that a host can use "%" as a subnetting symbol without any
    other host having to know (or care) what the notation means -- since
    the interpretation of the text to the left of the "@" is completely
    up to the destination host.  All that is required is that all hosts
    be able to pass an address with "%" on to another host without
    mangling it in the process.

    So, you are probably safe in assuming that an address of the form
    "a%b@c" refers to someone named "a", at some location named "b",
    which in turn is reached via "c" -- even though RFC822 doesn't
    officially recognize this convention.  Although some host could in
    theory decide to use "%" in some totally different fashion, in
    actual fact this is quite unlikely to happen.

(2) However, even if you do succeed in analyzing an address still fur-
    ther by recognizing the "de facto" use of the percent sign, you are
    still going to run into a major problem.  Consider the two addresses
    that you cited in your message:

		Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
		Jacob_Palme_QZ%QZCOM%YORK@UCL-CS.ARPA

    On what grounds can I conclude that these two addresses refer to the
    same user?  Maybe there are two "Jacob_Palme_QZ"'s, for all I know.

    Even if I note the "subnetting" structure of each address, and see a
    "QZCOM" mentioned in both places, how am I to know for sure that the
    "QZCOM.MAILNET" reached from MIT-MULTICS.ARPA is the same place as
    the "QZCOM" reached from UCL-CS.ARPA via its subhost "YORK"?

    You might be getting lulled into a false sense of security because
    of the familiarity -- and seeming "inherent uniqueness" -- of enti-
    ties like "Jacob_Palme_QZ" and "QZCOM".  But if you substitute less
    meaningful values such as "John_Doe" and "FOO", respectively, into
    the two different addresses you gave in your message, I think you'll
    see my point.

So, to summarize:  Yes, you can probably get away with treating "%" as
a subnetting symbol -- provided, of course, that you do this only for
your own private computations and don't modify the stuff to the left
of the "@" in any way before using the address to send mail.  However,
unless you can think of a solution to the issue of global uniqueness of
local parts, I hardly see the point of going to the trouble of a compli-
cated analysis of address substructure -- and I think the only really
safe criterion for concluding that two addresses refer to the same per-
son is if they are identical, byte for byte.

This is, of course, a very powerful argument in favor of a globally
unique domain naming scheme which would make this whole set of issues --
multiple route-based addresses, subnetting, and what-not -- completely
irrelevant.  So be it.

	On the matter of underscore=space: I did not want to translate
	spaces to underscores. I would much better prefer to send out
	my name as

		"Jacob Palme QZ"%QZCOM.MAILNET@MIT-MULTICS.ARPA

	or as

		"Jacob Palme QZ%QZCOM.MAILNET"@MIT-MULTICS.ARPA

	The reason I am not doing that is that many mail systems are
	not able to handle that kind of constructs!

Your point is well taken.  It is unfortunate that many mail systems
cannot adequately handle spaces in local parts -- especially since this
problem has been known for several years.  Some places have been using
spaces in addresses for local mail for ages -- but when they used such
addresses in network mail, they got their hands slapped pretty badly
because some "important" sites choked on the spaces and were unable or
unwilling to fix their software to conform to the official specs.

You should, though, be careful in assuming any particular substitution
convention to handle spaces in names.  Unlike the situation with "%" and
subnetting, there simply is no accepted "de facto" convention for spaces
in addresses; some places use underscores, others use periods, and maybe
still other places use still other characters for all I know.

If there were a possibility of establishing a convention, I would prefer
the underscore from an aesthetic point of view.  Others, however, would
no doubt argue just as passionately for the period (which is admittedly
easier to type on most keyboards).  Still others would insist on no sub-
stitutions at all -- in order to pressure those sites which still can't
handle spaces in names to fix their software.  The result is that agre-
ement on a standard in this area is unlikely.

Further, the period is heavily used for subnetting in some circles (some
places say "site.user", while others say "user.site").  Any attempt on
your part to pressure any of these places for some kind of netwide uni-
formity in this area is doomed; again, the format of the "local part" of
an address (to the left of the "@") is completely up to the destination
host, and anyone else who tries to second-guess what is going on there
does so at his own risk.  Of course, it's quite possible that the "sub-
netting" use of the period will gradually decrease in favor of increased
use of subdomains; this will take time, however.

Please understand that I'm not trying to discourage you from putting as
much intelligence as possible in your mail-handling tools.  I'm simply
trying to point out that, given the current far-less-than-ideal situa-
tion, some of the things you propose to do are at best quite difficult.

-- Rich

Received: from BRL-TGR.ARPA by MIT-MC.ARPA 24 Jun 85 23:36:42 EST
Date:     Mon, 24 Jun 85 15:45:29 EDT
From:     Ron Natalie <ron@BRL.ARPA>
To:       Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc:       Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, 
          header-people <header-people@MIT-MC.ARPA>
Subject:  Re:  Parser for RFC822 headers wanted (addendum)

Unfortunately there are two problems here:

	1.  The specification RFC822 form of addresses and its
	    corrections.  RFC822 ain't so bad, but,

	2.  The DOD Internet view of hostname requires the "to the right
	    of the @" domain names to things it knows about, precluding the
	    .UUCP and .MAILNET domains (at least for the time being).  In
	    addition there exists problems with the implementation of the
	    new domain schemes.

-Ron


Received: from lll-tis-b.ARPA by MIT-MC.ARPA 25 Jun 85 01:11:19 EST
Return-Path: <mcb@lll-tis-b>
Received: by lll-tis-b.ARPA; Mon, 24 Jun 85 22:11:37 pdt
Date: Mon, 24 Jun 85 22:11:37 pdt
From: Michael C. Berch <mcb@lll-tis-b>
Message-Id: <8506250511.AA20349@lll-tis-b.ARPA>
To: header-people@mit-mc.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)
References: <7037@styx.UUCP>

Depends what you want to use the local part of the address for.
If your interest is for transport purposes (routing, forwarding
etc.) you'd better stick to the protocol and provide support for whatever
de facto stuff is thrown at your mailer. 
You'd also better not mess around with the local part.
But if your interest is for a user-agent type program or message 
handler (which would deal with queries like "show me the last three 
messages from this correspondent") there are a couple of things you 
can do to make life easier:

1. Adopt the user-host binding as the sole information-bearing part of
   the address, and discard all routing information but retain the
   domain name (even if it's a default, unstated domain).
   Obviously this works best in a flat name space since you need
   not query name servers, etc., to find out the "true" domain
   name of a given host. But it CAN work anywhere.

2. Canonicalize all addresses, e.g. in the form "user@host.domain".
   Thus joe%foo.mailnet@relayhost.arpa and joe%foo.mailnet@other-relay.arpa
   are canonicalized as "joe@foo.mailnet". If you have appropriate
   name tables, you can turn "decnethost::user" into "user@host.whatever"
   and foo!bar!zot!joe into "joe@zot.uucp".

---
Michael C. Berch
mcb@lll-tis-b.ARPA
{akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb

Received: from WISCVM.ARPA by MIT-MC.ARPA 25 Jun 85 11:49:09 EST
Received: from (MAILER)NJECNVM.BITNET by WISCVM.ARPA on 06/25/85 at
  10:48:47 CDT
Return-path: VMSYS3%NJECNVM.BITNET@WISCVM.ARPA
Received: by NJECNVM (Mailer X1.21) id 4581; Tue, 25 Jun 85 11:49:08 EDT
Date:         Tue, 25 Jun 85 11:42 EDT
From:           Ross A. Patterson  <VMSYS3%NJECNVM.BITNET@WISCVM.ARPA>
Subject:      Re: Parser for RFC822, etc.
To:  <Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS>
In-Reply-To:  Your message of 24 Jun 85 17:00 +0100
cc:  <HEADER-PEOPLE@MIT-MC.ARPA>

I suppose others have already spotted this, but I find it rather
humorous that a message sent via HEADER-PEOPLE should be lacking
a "To:" field, as your last two messages were. This is especially
interesting because the subject of both messages was that the
header data should be heavily interpreted, to provide a nicer user
interface. My mail system, for instance, describes these messages
as "Note is of unrecognizale form (xx lines)", since it can't
parse a non-existant "To:" field.

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 25 Jun 85 13:51:46 EST
Received: from NJECNVM(MAILER) by MITVMA (Mailer X1.21) id 2036;
          Tue, 25 Jun 85 11:47:58 EDT
Received: by NJECNVM (Mailer X1.21) id 4581; Tue, 25 Jun 85 11:49:07 EDT
Date:         Tue, 25 Jun 85 11:42 EDT
From:         Ross A. Patterson <VMSYS3@NJECNVM>
Subject:      Re: Parser for RFC822, etc.
To:           <Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS>
In-Reply-To:  Your message of 24 Jun 85 17:00 +0100
cc:           <HEADER-PEOPLE@MIT-MC.ARPA>

I suppose others have already spotted this, but I find it rather
humorous that a message sent via HEADER-PEOPLE should be lacking
a "To:" field, as your last two messages were. This is especially
interesting because the subject of both messages was that the
header data should be heavily interpreted, to provide a nicer user
interface. My mail system, for instance, describes these messages
as "Note is of unrecognizale form (xx lines)", since it can't
parse a non-existant "To:" field.


Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 25 Jun 85 15:08:26 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2666027279988225@MIT-MULTICS.ARPA>; 25 Jun 1985 15:07:59 edt
Date:        25 Jun 85 18:49 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Parser for RFC822 headers wanted (addendum)
Message-ID:  <110579@QZCOM>
In-Reply-To: <488506103-12477-wales@DIANA.LOCUS.UCLA.EDU>

Comment on a message from
wales @ UCLA-LOCUS.ARPA (Rich Wales)

Yes, you are quite right that our way of parsing addresses means
that if two people are called "A" at two different sites, in
different nets, with the same site name "B", then we would wrongly
assume that they are one and the same person.

However, this has, to my knowledge, never happended any time
during the two years we have had connections to JANET and MAILNET
and thereby indirectly to ARPANET, BITNET, CSNET etc. The identification
of two names as referring to the same mailbox even though the
RFC822 name was different (because it contained relative adressing
information using the "!" or "%" convetions) has however worked
correctly many times and been of value to our users.



Received: from UDel-Dewey.ARPA by MIT-MC.ARPA 25 Jun 85 16:34:37 EST
Received: from localhost by UDel-Louie.UDel-Dewey.ARPA id a021510;
          25 Jun 85 16:29 EDT
To: Iglesias@uci-icsa.ARPA
cc: header-people@mit-mc.ARPA
Subject: 822 parsers
Reply-To: header-people@mit-mc.ARPA
Date: 25 Jun 85 16:29:16 EDT (Tue)
Message-ID: <4057.488579356@udel-dewey>
From: Marshall Rose <mrose@UDel-Dewey.ARPA>

Mike - isn't it amazing how when you ask a simple question on the net,
you can get 20 replies which don't answer the question you asked?

[ Header-People pay attention: ] The question was, are there any non-C
822-style address parsers out there, preferably, though not necessarily,
for a CP-6 environment.

As far as the current discussion goes (to throw in my two cents worth):
writing an 822 parser is EASY.  Modifying it to handle the slop which gets
put on the net is a HARD part.  One of two things should be done: either
make the standards so simple that no one could botch it (good luck), or get
some enforcement.  I realize that this isn't popular, but I don't see us making
any progess by policing ourselves.

/mtr

Received: from rand-unix.ARPA by MIT-MC.ARPA 26 Jun 85 03:51:36 EST
Received: by rand-unix.ARPA; Wed, 26 Jun 85 00:50:57 pdt
From: Steve Tepper <greep@rand-unix>
Message-Id: <8506260750.AA25679@rand-unix.ARPA>
Date: 26 Jun 85 00:50:44 PDT (Wed)
To: header-people@mit-mc
Subject: rfc822

Possibly it has been forgotten that rfc822 (originally 733) is as
complicated and bulky as it is mainly because it was an attempt to
codify existing practices into a standard, and there was a wide range
of formats in use.

Received: from UCB-VAX.ARPA by MIT-MC.ARPA 26 Jun 85 19:55:38 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.48)
	id AA06837; Wed, 26 Jun 85 16:50:07 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.36)
	id AA17662; Wed, 26 Jun 85 16:55:30 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.36.1)
	id AA10382; Wed, 26 Jun 85 16:54:04 pdt
Date: Wed, 26 Jun 85 16:54:04 pdt
From: wcwells%ucbopal.CC@Berkeley (William C. Wells)
Message-Id: <8506262354.AA10382@ucbopal.CC.Berkeley.ARPA>
To: Header-People@mit-mc.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)

I am amazed by computer sites that want to continue mixing mail address
formats.

Any site that is connected to more than one type of mail system, needs
to convert addresses a common format as they come in or go out of the
local mail domain.  To not do so will get you in to trouble fast: the
rules for parsing addresses in different mail networks are different
and may be incompatible (eg. a!b@c in UUCP and RFC-822); and duplicate
host names can occur (to name a few problems).

At Berkeley, we operate in local Intermail environment that
has special top-domain names to identify non-Internet mail networks
(such as UUCP and BITNET).

For example the UUCP address: a!b!c!d is converted to b!c!d@a.UUCP
for identification within the Berkeley mail domain. All UUCP addresses
in this local internet format are relative to UCB-VAX, our UUCP gateway.
If a message containing this address is relayed to the DOD internet
then it is changed to a!b!c!d@Berkeley.ARPA.

The flow diagram for message address processing is:

    -----------   ---------   ----------   ---------   --------------
    |UUCP Mail|-->|Mail   |-->|Local   |-->|Mail   |-->|DoD Internet|
    |System   |<--|Gateway|<--|Internet|<--|Gateway|<--|Mail        |
    -----------   ---------   |Mail    |   ---------   --------------
			      ----------

The important thing to remember in using this method is that there
is a separate mail gateway for each external mail system and on
each gateway there are separate rule sets for each direction and
for the originator (From:) and the destination addresses
(To:, Cc:, etc.) for each direction. (4 rule sets for each mail
gateway).

Regards,

Bill Wells

P.S. For those of you that still are confused about "a!b@c":

UUCP mail transport agents always parse on the !
(ie.  "b@c" is the local address at UUCP host a).
Internet mail transport agents always parse on the @
(ie. "a!b" is local address in mail domain c).
You cannot have it both ways in the same local mail domain.
(ie. There is no such thing as an Internet/UUCP mail transport
agent. There can be an Internet/UUCP mail gateway.)

Received: from UCB-VAX.ARPA by MIT-MC.ARPA 26 Jun 85 20:05:03 EST
Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.48)
	id AA06988; Wed, 26 Jun 85 16:59:41 pdt
Received: by ucbarpa.ARPA (4.24/4.46)
	id AA18630; Wed, 26 Jun 85 17:03:48 pdt
Date: Wed, 26 Jun 85 17:03:48 pdt
From: Jordan Hayes <jordan%ucbarpa@Berkeley>
Message-Id: <8506270003.AA18630@ucbarpa.ARPA>
Organization: Computer Systems Research Group
Home-Phone:   (415) 835-8767
Uucp-Path:    ...ucbvax!jordan
To: Header-People@mit-mc.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)

Re: internet/uucp "transport agent"

It certainly is possible, but UUCP has to get out of the stone age and
adopt 822 addressing... Why aren't more people "waving that banner" ??

The "bang" convention is way outdated (I don't think I'll get any
objections on that one) and needs to be scrapped. Why doesn't someone
just put their foot down ??

/jordan

Received: from Cornell.ARPA by MIT-MC.ARPA 25 Jun 85 11:38:57 EST
Date: Tue, 25 Jun 85 11:37:34 EDT
From: bill@Cornell.ARPA (William A. Nesheim)
Message-Id: <8506251537.AA13730@Cornell.ARPA>
Received: by Cornell.ARPA (4.53/4.30)
	id AA13730; Tue, 25 Jun 85 11:37:34 EDT
To: 4bsd-bugs@Berkeley.ARPA, HEADER-PEOPLE@MIT-MC.ARPA, UNIX-WIZARDS@BRL.ARPA
Subject: Spaces in names (in quoted strings)

Index: /usr/src/ucb/Mail 4.2bsd

Description:
While on the subject of blanks in quoted strings, perhaps we all could
start with fixing unix's /usr/ucb/Mail!  I got frustrated recently
with trying to reply to mail from LLL's mfe-net.  Mail would always
split the address at the blank, despite the quotes.

Repeat-by: 
Send mail to someone with a space in their name.

Fix:
a diff follows: (/usr/src/ucb/Mail, 4.2bsd)
RCS file: RCS/names.c,v
retrieving revision 1.1
diff -c -r1.1 names.c
*** /tmp/,RCSt1013587	Tue Jun 25 11:24:16 1985
--- names.c	Wed Jun 19 17:04:57 1985
***************
*** 73,78
  	top = NIL;
  	np = NIL;
  	cp = line;
  	while ((cp = yankword(cp, nbuf)) != NOSTR) {
  		if (np != NIL && equal(nbuf, "at")) {
  			strcpy(abuf, nbuf);

--- 73,80 -----
  	top = NIL;
  	np = NIL;
  	cp = line;
+ 	if(debug) fprintf(stderr,"extract: line = %s, ntype=%d\n",
+ 		line, ntype);
  	while ((cp = yankword(cp, nbuf)) != NOSTR) {
  		if (np != NIL && equal(nbuf, "at")) {
  			strcpy(abuf, nbuf);
***************
*** 157,162
  	register char *cp, *cp2;
  
  	do {
  		for (cp = ap; *cp && any(*cp, " \t,"); cp++)
  			;
  		if (*cp == '(') {

--- 159,165 -----
  	register char *cp, *cp2;
  
  	do {
+ 		/* skip leading blanks & tabs */
  		for (cp = ap; *cp && any(*cp, " \t,"); cp++)
  			;
  		/* remove comments in () */
***************
*** 159,164
  	do {
  		for (cp = ap; *cp && any(*cp, " \t,"); cp++)
  			;
  		if (*cp == '(') {
  			while (*cp && *cp != ')')
  				cp++;

--- 162,168 -----
  		/* skip leading blanks & tabs */
  		for (cp = ap; *cp && any(*cp, " \t,"); cp++)
  			;
+ 		/* remove comments in () */
  		if (*cp == '(') {
  			while (*cp && *cp != ')')
  				cp++;
***************
*** 168,175
  		if (*cp == '\0')
  			return(NOSTR);
  	} while (any(*cp, " \t,("));
! 	for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++)
! 		;
  	*cp2 = '\0';
  	return(cp);
  }

--- 172,190 -----
  		if (*cp == '\0')
  			return(NOSTR);
  	} while (any(*cp, " \t,("));
! 	
! 	/* cp now points to the start of a word. */
! 	for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++) {
! 		if( *cp == '"') { /* found opening quote, look for closing */
! 			*cp2++ = *cp++;
! 			while ( *cp && *cp != '"') *cp2++ = *cp++;
! 			if (*cp == '\0') {
! 				fprintf(stderr,"Unmatched \" in address.\n");
! 				return(NOSTR);
! 			}
! 		}
! 	}
! 			
  	*cp2 = '\0';
  	if (debug) fprintf(stderr,"yankword returns wbuf = %s\n", wbuf);
  	return(cp);
***************
*** 171,176
  	for (cp2 = wbuf; *cp && !any(*cp, " \t,("); *cp2++ = *cp++)
  		;
  	*cp2 = '\0';
  	return(cp);
  }
  

--- 186,192 -----
  	}
  			
  	*cp2 = '\0';
+ 	if (debug) fprintf(stderr,"yankword returns wbuf = %s\n", wbuf);
  	return(cp);
  }
  

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 27 Jun 85 15:02:39 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2666199305148321@MIT-MULTICS.ARPA>; 27 Jun 1985 14:55:05 edt
Date:        27 Jun 85 12:45 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          header-people <header-people@MIT-MC.ARPA>
Subject:     Subject: Is it legal with no "TO:" field in a message?
Message-ID:  <110848@QZCOM>
In-Reply-To: <110640@QZCOM>

I have now investigated why an outgoing message from us did not
contain any "TO:" field? The story is rather long and complex...

In general, our system allows our users freely to link an outgoing
message to any number (0, 1 or more) of "TO:", "CC:" and "BCC:" recipients.
Is this against the standard? Does RFC822 require that there should
at least one "TO:" field?

In this special case, what happened was the following:

>>>>> Here is an outgoing message from me which started it all.

Date:        21 Jun 85 13:42 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Parser for RFC822 headers wanted (addendum)
Message-ID:  <109974@QZCOM>
In-Reply-To: <109733@QZCOM>

>>>>> Here is the reply to the above message from don.provan.
>>>>> Note that don's mailsystem apparently sends the reply
>>>>> with a "TO:" reference to the "REPLY-TO:" of the incoming message,
>>>>> and a "CC:" reference to the "TO:" field of the incoming message.
>>>>> Is this standard practice?
>>>>>
>>>>> Thus, one mailbox occurs twice in the header of the message
>>>>> below, both in the "TO:" and in the "CC:" field.
>>>>> Our message system was not willing to accept the same recipient
>>>>> in both the "TO:" and the "CC:" field, and thus, when the message
>>>>> below was entered into our data base, it only got one link to
>>>>> that mailbox, a "CC:" reference ("TO:" would have been better, I will
>>>>> modify our message system so that if a message has both a
>>>>> "TO:" and a "CC:" reference, the "TO:", and not the "CC:" reference
>>>>> will be entered in our data base!).

Date: Sun, 23 Jun 85 01:42 EDT
From: don.provan@CMU-CS-A.ARPA
To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Re: Parser for RFC822 headers wanted (addendum)
CC: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    header-people <header-people@MIT-MC.ARPA>,
In-Reply-To: <109974@QZCOM>
Message-Id: <23Jun85.014250.DP0N@CMU-CS-A.ARPA>

>>>>> Here is a reply written by me to the above message.
>>>>> If an incoming message has no "REPLY-TO" field, our system
>>>>> copies the "TO:" and "CC:" fields from the commented message
>>>>> to the reply (Unless the writer of the reply gives commands
>>>>> to remove or add recipients). Thus, the outgoing message
>>>>> got to have no "TO:" field.

Date:        23 Jun 85 14:25 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Parser for RFC822 headers wanted (addendum)
Message-ID:  <110185@QZCOM>
In-Reply-To: <23Jun85.014250.DP0N@CMU-CS-A.ARPA>



Received: from nrl-aic by MIT-MC.ARPA.ARPA; 28 Jun 85 05:55:45 EDT
Date: 28 Jun 1985 02:22:20 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Subject: Is it legal with no "TO:" field in a message?
To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc: Header-People@MIT-MC.ARPA, DCrocker@UDEL-HUEY.ARPA,
        "Ross A. Patterson" <VMSYS3%NJECNVM@MIT-MULTICS.ARPA>
Message-Id: <488787741/hoey@nrl-aic>
In-Reply-To: Jacob Palme QZ's message of 27 Jun 85 1245 +0100

    Date:        27 Jun 85 12:45 +0100
    From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
    Reply-To:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA

    ...
    In general, our system allows our users freely to link an outgoing
    message to any number (0, 1 or more) of "TO:", "CC:" and "BCC:"
    recipients.  Is this against the standard? Does RFC822 require that
    there should at least one "TO:" field?

I thought so, but checking the document, I find rather that RFC822
requires only that there be at least one destination address field.
There may in fact be no destination addresses at all provided that
an empty Bcc: field is included, though such a message probably
wouldn't get delivered.

[RFC822, Section 4.1.  SYNTAX]

     fields      =    dates                      ; Creation time,
                      source                     ;  author id & one
                    1*destination                ;  address required
                     *optional-field             ;  others optional

     destination =  "To"          ":" 1#address  ; Primary
                 /  "Resent-To"   ":" 1#address
                 /  "cc"          ":" 1#address  ; Secondary
                 /  "Resent-cc"   ":" 1#address
                 /  "bcc"         ":"  #address  ; Blind carbon
                 /  "Resent-bcc"  ":"  #address

I include a copy to David H. Crocker for verification that this is the
intent of RFC822.

    Date: Tue, 25 Jun 85 11:42 EDT
    From: Ross A. Patterson <VMSYS3@NJECNVM>

    ... I find it rather humorous that a message sent via HEADER-PEOPLE
    should be lacking a "To:" field....  My mail system, for instance,
    describes these messages as "Note is of unrecognizale form (xx lines)",
    since it can't parse a non-existant "To:" field.

So does anyone know how Ross A. Patterson's spurious complaint about
Jacob Palme QZ's syntax got to Header-People with a from field having
invalid syntax (the unquoted . strikes again) and a host name unknown
to the Internet?  Where, oh where, are the Protocol Police when you
need them?  If anyone knows a better way than %'ing through
MIT-MULTICS, please send him a copy of this note so he can know to fix
his mail system's parser.  He might want to spruce up its error
messages while he's at it.

Dan Hoey
Navy Center for Applied Research in Artificial Intelligence
Hoey@NRL-AIC.ARPA

Received: from seismo.ARPA by MIT-MC.ARPA.ARPA; 30 Jun 85 01:58:50 EDT
Return-Path: <cbosgd!cbosgd.ATT.UUCP!mark@seismo>
Received: from cbosgd.UUCP by seismo.ARPA with UUCP; Sun, 30 Jun 85 01:57:36 EDT
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/0.98.UUCP-CS.beta.4-27-85)
	id AA23902; Sun, 30 Jun 85 01:37:00 edt
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA06297; Sun, 30 Jun 85 01:43:55 edt
Date: Sun, 30 Jun 85 01:43:55 edt
From: cbosgd.ATT!mark@seismo (Mark Horton)
Message-Id: <8506300543.AA06297@cbpavo.cbosgd.ATT.UUCP>
To: header-people@mit-mc.arpa
Subject: reordering header lines

I seem to recall someone a while back asking if it bothered anybody
for header liens to be reordered.  The feeling, as I recall, is it
didn't.

I've just come across a case where it may matter.  When one builds a
gateway into MHS, there are separate envelope, header, and body parts
to a message.  I am looking at a proposal suggesting that a TEXT style
message look essentially like this:
	Envelope headers, like Date, From, To, Received, etc
	End-Of-Header:
	Body headers, like Subject, etc
	blank line
	Body

The "End-Of-Header:" line (with a null content) would serve to delimit
the boundary between the envelope and the body.  Obviously, reordering
of such a header would cause problems.

Is there any existing standard for separating the two parts?  If not,
is there any interest in a special header such as this?  Any problems
I'm missing?  (Personally, I might guess that "End-Of-Envelope" might
be a better name.)  Do null header contents bother anyone?

The effect of this on existing software would be that, if reordering is
to be done, it stop before this delimeter, and not touch the stuff beyond.
Presumably the mail transport layer should not look beyond it, but it
probably wouldn't hurt to do so.  It would be nice if Received lines
were added only before such a delimiter.

	Mark

P.S. Are people aware that the BODIES of MHS messages are not plain
text, but are documents with paragraph and indenting information in
them, so they can be reformatted on whatever terminal they are to be
displayed on?  I'm worried about the gateway function from 822 to MHS,
trying to intuit this information.  Is this a solved problem?  Xerox
must have such a gateway - how well does it work?

P.P.S. Would anyone working on 822-MHS gateway issues please drop me a
line, I'd like to find out what's being done so far.

Received: from USC-ISIF.ARPA by MIT-MC.ARPA.ARPA;  1 Jul 85 19:43:33 EDT
Date:  1 Jul 1985 16:40:22 PDT
From: POSTEL@USC-ISIF.ARPA
Subject: reordering header lines
To:   header-people@MIT-MC.ARPA


Mark Horton:

The RECEIVED lines are to be at the begining of the header in most recent
first order.

--jon.
-------

Received: from UCI-ICSA by MIT-MC.ARPA.ARPA;  2 Jul 85 16:04:02 EDT
To: POSTEL@usc-isif.arpa
cc: header-people@mit-mc.arpa, stef@uci-icsa
Subject: Re: reordering header lines
In-reply-to: Jon Postel message of 1 Jul 1985 16:40:22 PDT.
Date: 02 Jul 85 13:01:11 PDT (Tue)
From: Einar Stefferud <stef@uci-icsa>
Received: from Localhost by UCI-ICSA; 02 Jul 85 13:02:03 PDT (Tue)

Hi Jon -- You say: "The RECEIVED lines are to be at the begining of the
header in most recent first order."

I would translate this to mean that in an X.400 <=> 822 Mail Gateway,
the behavior of a "transformer" should be to collect all the 822
Recieved: Header Lines (or their equivalent from an X.400 envelope)
from the original and place them at the beginning of the transformed
message, in exactly the order they were found in the original.

The only logical assumption that I can see is to believe the order
found in the original.  If some prior agent screwed up the order, it
should not be the duty of the "transformer" to reorder as a remedy to
an implied prior error.  This could only introduce gross uncertainty
throughout the net, and serve to prevent tracking down errant Received:
line inserters for repair.

I just want to make the point that the standards for original postmark
inserters must be different than the standards for gateway
transformations on them.

Stef

Received: from UCI-ICSA by MIT-MC.ARPA.ARPA;  2 Jul 85 16:04:02 EDT
To: POSTEL@usc-isif.arpa
cc: header-people@mit-mc.arpa, stef@uci-icsa
Subject: Re: reordering header lines
In-reply-to: Jon Postel message of 1 Jul 1985 16:40:22 PDT.
Date: 02 Jul 85 13:01:11 PDT (Tue)
From: Einar Stefferud <stef@uci-icsa>
Received: from Localhost by UCI-ICSA; 02 Jul 85 13:02:03 PDT (Tue)

Hi Jon -- You say: "The RECEIVED lines are to be at the begining of the
header in most recent first order."

I would translate this to mean that in an X.400 <=> 822 Mail Gateway,
the behavior of a "transformer" should be to collect all the 822
Recieved: Header Lines (or their equivalent from an X.400 envelope)
from the original and place them at the beginning of the transformed
message, in exactly the order they were found in the original.

The only logical assumption that I can see is to believe the order
found in the original.  If some prior agent screwed up the order, it
should not be the duty of the "transformer" to reorder as a remedy to
an implied prior error.  This could only introduce gross uncertainty
throughout the net, and serve to prevent tracking down errant Received:
line inserters for repair.

I just want to make the point that the standards for original postmark
inserters must be different than the standards for gateway
transformations on them.

Stef

Received: from nrl-aic by MIT-MC.ARPA.ARPA;  2 Jul 85 21:56:31 EDT
Date: 2 Jul 1985 21:44:26 EDT (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: reordering header lines
To: Einar Stefferud <stef@uci-icsa>
Cc: Header-People@MIT-MC.ARPA
Message-Id: <489203066/hoey@nrl-aic>
In-Reply-To: Einar Stefferud's message of 02 Jul 85 130111 PDT (Tue)

    Date: 02 Jul 85 13:01:11 PDT (Tue)
    From: Einar Stefferud <stef@uci-icsa>

    ... "The RECEIVED lines are to be at the begining of the
    header in most recent first order."

    I would translate this to mean that in an X.400 <=> 822 Mail Gateway,
    the behavior of a "transformer" should be to collect all the 822
    Recieved: Header Lines (or their equivalent from an X.400 envelope)
    from the original and place them at the beginning of the transformed
    message, in exactly the order they were found in the original.

    ...  If some prior agent screwed up the order, it
    should not be the duty of the "transformer" to reorder as a remedy to
    an implied prior error.  This could only introduce gross uncertainty
    throughout the net, and serve to prevent tracking down errant Received:
    line inserters for repair.

For the reasons stated, I would advocate that the gateway only collect
those ``Received:'' lines that appear at the beginning of the header.
The presence and contents of other ``Received:'' lines, and their
position relative to other header lines, should be provided as an error
message, either inserted as some sort of comment in the header or sent
to the mail system maintainer.

Dan

Received: from UCI-ICSE by MIT-MC.ARPA.ARPA;  4 Jul 85 11:11:45 EDT
To: Dan Hoey <hoey@nrl-aic.arpa>
cc: Einar Stefferud <stef@uci-icse>, Header-People@mit-mc.arpa
Subject: Re: reordering header lines
In-reply-to: Message of 2 Jul 1985 21:44:26 EDT (Tue) <489203066/hoey@nrl-aic>
Date: 03 Jul 85 01:03:59 PDT (Wed)
From: Einar Stefferud <stef@uci-icse>
Received: from Localhost by UCI-ICSE; 03 Jul 85 01:05:05 PDT (Wed)

Please correct me if I am wrong, but I understand that there is a
problem with finding a place in the X.400 "header" part for fields
named "Received" and that they need to be carried in the "envelope"
part, or tossed out during a transformation from 822 to X.400.

Thus, I believe it will be proper to collect all "received" headers, in
the order of appearance in the 822 headers, whether all nicely grouped
at the beginning or not.  Why do you object to collecting them all
together?  I don't understand the problem.

Stef

Received: from nrl-aic by MIT-MC.ARPA.ARPA; 11 Jul 85 10:51:39 EDT
Date: 8 Jul 1985 13:49:20 EDT (Mon)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: reordering header lines
To: Einar Stefferud <stef@uci-icse>
Message-Id: <489692960/hoey@nrl-aic>
In-Reply-To: Einar Stefferud's message of 03 Jul 85 010359 PDT (Wed)
Cc: Header-people@MIT-MC.ARPA

    Date: 03 Jul 85 01:03:59 PDT (Wed)
    From: Einar Stefferud <stef@uci-icse>

    Please correct me if I am wrong, but I understand that there is a
    problem with finding a place in the X.400 "header" part for fields
    named "Received" and that they need to be carried in the "envelope"
    part, or tossed out during a transformation from 822 to X.400.

They can always be stuffed into the body if you're concerned about
them.

    Thus, I believe it will be proper to collect all "received" headers, in
    the order of appearance in the 822 headers, whether all nicely grouped
    at the beginning or not.  Why do you object to collecting them all
    together?  I don't understand the problem.

You were saying that reordering the ``Received:'' lines was not a good
idea, because it loses information that might be useful in tracking
down bugs.  I just pointed out that collecting them together loses
information, too.

The whole point, I guess, is whether you want to be able to debug 822
through the gateway.  If so, you probably have to preserve the entire
header somewhere.  If not, I don't really see why you want to preserve
the ``Received:'' lines at all.

Dan

Received: from UCI-ICSE by MIT-MC.ARPA.ARPA; 11 Jul 85 14:15:53 EDT
To: Dan Hoey <hoey@nrl-aic.arpa>
cc: Einar Stefferud <stef@uci-icse>, Header-people@mit-mc.arpa
Subject: Re: reordering header lines
In-reply-to: Message of 8 Jul 1985 13:49:20 EDT (Mon) <489692960/hoey@nrl-aic>
Date: 11 Jul 85 11:12:08 PDT (Thu)
From: Einar Stefferud <stef@uci-icse>
Received: from Localhost by UCI-ICSE; 11 Jul 85 11:13:09 PDT (Thu)

I think we are splitting hairs.  I don't understand what informatrion
gets lost if we use the following procedure going from 822 => X.400.

   1.  Collect all non-X400 headers, in their order of appearance
   (especially required for "Received" headers) and carry them into an
   appropriate X.400 "EnvelopePart" or "BodyPart".  Perhaps these get 
   split between "EnvelopePart" and some "BodyPart". 

           (How might this lose information?)

   2. Put the rest of the headers in the X.400 header.

I am not trying to be able to debug 822 MTAs from X.400 headers, but I
am trying to assure preservation of potentially useful information for
recipients.

I refuse to believe that we should proceed into 822 => X.400 gateway
operations on the assumption that we do not need this information to
assist X.400 recipients to deciepher what happened to their mail in
certain interesting cases.  We will need the "Received" information
just as much then as we did when "Received" headers were invented in
822land, and as much as we need them now in 822land.

The logical end-argument is to ask why we keep Receivced lines around
if they are not worth preserving at a gateway?  

Why not just eliminate them altogether in 822land too?

Best - Stef

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 19:16:06 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667510475031112@MIT-MULTICS.ARPA>; 12 Jul 1985 19:07:55 edt
Date:        12 Jul 85 15:21 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, "Steve Kille"
              <STEVE@UCL-CS.ARPA>
To:          header-people <header-people@MIT-MC.ARPA>
Cc:          "Steve Kille" <STEVE@UCL-CS.ARPA>
Subject:     Subject: Ambiguity with the REPLY-TO field
Message-ID:  <113307@QZCOM>

RFC822 says that the REPLY-TO field can be used in three different
ways:
(a) Author wants his return mail to some other mailbox somewhere
(b) Author may want additional people to get replies
(c) Replies should be sent to a distribution list

The problem with this is that many mail systems have two commands
for writing replies. The name of these commands are different
in different mail systems, I will here call them "personal reply"
and "group reply". A "personal reply" is only sent to the author
of a message, a "group reply" is sent to a group of people, usually
all the recipients of the commented message.

Now, the first of the three uses of the REPLY-TO field given
above corresponds to "personal reply" while the other two corresponds
to "group reply". Thus, a mail system implementing both the "personal
reply" and the "group reply" command will find it difficult to
know whether the reply-to field is of type (a), (b) or (c).

I have got complaints from some people that COM consistently
produces REPLY-TO fields of type (b) and (c). The complainers
have mail systems, which apparently interprets the REPLY-TO field
to always be of type (a), and thus use this in their "personal
reply" command.

However, I have strong reasons in COM for using the REPLY-TO
field in the (b) and (c) sense. The reason for this is that I
want to distinguish between the case when the author is a member
of a conference to which the message is sent and not. When the
author is a member of such a conference, replies should NOT be
sent personally to the author, but rather to the conference.
But if the author is not a member of the conference, replies
should be sent both to the author and the conference. (The same
principle, of course, would apply to mailing lists.) COM indicates
this by including the author in the REPLY-TO field if he is not
a member of any conference also receiving the message, but otherwise
not including the author in the REPLY-TO field.

Is this wrong?



Received: from ucla-locus.arpa by MIT-MC.ARPA.ARPA; 12 Jul 85 20:19:35 EDT
Date:           Fri, 12 Jul 85 17:15:09 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
                "Steve Kille" <STEVE@UCL-CS.ARPA>
CC:             Header-People@MIT-MC.ARPA
Subject:        Re: Subject: Ambiguity with the REPLY-TO field
In-reply-to:    Message of 12 Jul 85 15:21 +0100
                    from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA"
                    <113307@QZCOM>
Message-ID:     <490061709-13202-wales@DIANA.LOCUS.UCLA.EDU>

Jacob --

I believe that the three "typical uses" of REPLY-TO spelled out in
RFC822 (Section 4.4.3, page 22) are intended as three different motiva-
tions for using the feature -- NOT three different possible semantics.

My understanding of the semantics of the REPLY-TO field is that, if it
is present, it is to be used as a substitute for the FROM field when
composing replies to the message.  That is, if a REPLY-TO field exists
in a header, an automatic "reply" operation should ignore the FROM field
completely, under all circumstances, and use the REPLY-TO data instead.

If the sender of the message needs to use a REPLY-TO field, but also
wants to be one of the recipients of any reply, he must include his own
address in the REPLY-TO field along with the addresses of the other
intended recipients.

I am not 100% sure I understood your description of the criteria used by
COM in deciding whether to include the sender in the REPLY-TO field, so
I am not sure whether COM uses REPLY-TO correctly or not.  If you would
like to try again to explain what COM does with REPLY-TO, I will gladly
try to help you figure out whether its use of REPLY-TO follows the
RFC822 semantics, and if it doesn't, whether there is some alternative
approach that would do what you want.

-- Rich

Received: from CMU-CS-A.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 21:22:33 EDT
Date: Fri, 12 Jul 85 21:20 EDT
From: don.provan@CMU-CS-A.ARPA
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    "Steve Kille" <STEVE@UCL-CS.ARPA>
Subject: Re: Subject: Ambiguity with the REPLY-TO field
CC: header-people <header-people@MIT-MC.ARPA>,
    "Steve Kille" <STEVE@UCL-CS.ARPA>
In-Reply-To: <113307@QZCOM>
Message-Id: <12Jul85.212034.DP0N@CMU-CS-A.ARPA>

One problem here is that there are really three types of replies:
the personal and group replies you mentioned, and then a third one
that might be called a message directed reply or a default reply or a
normal reply.  The first sends the reply to the person who sent the
message, so I'd be tempted to use the From: field for that, although
I believe the From: field need not be legal if there's a Reply-to:
field.  The second sends the reply to everyone who saw the original
message.  The third sends the reply to anyone the sender thought
should see a reply.  The Reply-To: field was provided for this use.

So my feeling is that the people with the "personal reply" command
are trying to do something that isn't supported by the protocol.  If
it's supported at all, they should be replying to the From:  field,
not the Reply-To: field.

Received: from UCI-ICSA by MIT-MC.ARPA.ARPA; 13 Jul 85 03:26:22 EDT
To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.arpa
cc: don.provan@cmu-cs-a.arpa, "Steve Kille" <STEVE@ucl-cs.arpa>, 
    header-people <header-people@mit-mc.arpa>, stef@uci-icsa
Subject: Re: Subject: Ambiguity with the REPLY-TO field
In-reply-to: Msg of 12 Jul 85 21:20 EDT <12Jul85.212034.DP0N@CMU-CS-A.ARPA>
Date: 13 Jul 85 00:19:55 PDT (Sat)
From: Einar Stefferud <stef@uci-icsa>
Received: from Localhost by UCI-ICSA; 13 Jul 85 00:23:06 PDT (Sat)

Rich Wales has it right!  

REPLY-TO is a replacement for FROM (and SENDER), if REPLY-TO exists,
and then "personal reply" should use whatever is in REPLY-TO "as
requested by the originator", no matter what REPLY-TO contains.

Jacob's use to direct replies to whomever he (as the conference chair)
wants replies to go to is technically correct, though perhaps he may be
overusing it.  But this is a social question of good chairmanship.

I would tend to be less demanding of recipients who might very well
want to make personal replies, and find themselves either thwarted, or
bothered by the need to manually edit the address fields of a reply to
achieve their desires.  However, at times I like to force replies to a
whole group by putting the groupname in a REPLY-TO field.

I think it is customary in the Internet for recipients who want to
reply to all addressees to not use the "personal reply" form of the
reply command, and thus they will reply to the whole collection of
REPLY-TO/FROM/SENDER, TO, and CC addressees.  However, I know a number
people who frustrate me continually by (unconciously?) omitting other
addreessees, which forces me to manually relay to them when I am trying
to promote a group discussion.  I wish they would cooperate more.

In a way, Jacob's use suggests that he may not trust recipients to use
the "group reply" when they should.  If a Conference Chair does not
trust recipients, then it may be correct to force the issue on them.
If the Chair does trust them, then they should really be trusted, by
not forcing the issue with such intractable REPLY-TO fields.

Please do not take these comments as personally directed.  As I see it,
we are caught among varying semantic interpretations and social
customs, and it will take us a while to get things sorted out.

Jacob is trying to cope with a blend of Structured Conference services
and Unstructured Internet Mail services to conduct conferences.  I
don't know anyone else who is even trying this, so I am interested in
helping Jacob to understand the Internet side of things (even if I have
to shout from time).  We really do need to be able to accomodate COM
type User Agents in our growing Mail Internet.  The trick is to get
them to behave in concert with other practices in other contexts.

Peace - Stef

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 13 Jul 85 15:26:46 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667583178095756@MIT-MULTICS.ARPA>; 13 Jul 1985 15:19:38 edt
Date:        13 Jul 85 15:27 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          "Rich Wales" <wales@UCLA-LOCUS.ARPA>,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Subject: Ambiguity with the REPLY-TO field
Message-ID:  <113649@QZCOM>
In-Reply-To: <490061709-13202-wales@DIANA.LOCUS.UCLA.EDU>

> FROM: Rich Wales <wales@UCLA-LOCUS.ARPA>

> My understanding of the semantics of the REPLY-TO field is that, if it
> is present, it is to be used as a substitute for the FROM field when
> composing replies to the message.

A message system which has two reply commands, called "personal
reply" and "group reply", would for a message without any REPLY-TO
field use the "FROM" field when the "personal reply" is used, and
would perhaps combine the "FROM", "TO", "CC" and "SENDER" fields
when the "group reply" command is used.

Thus if, as you say, the "REPLY-TO" field is to be used as a
replacement for the "FROM" field, this seems to indicate that
maybe the "REPLY-TO" field is mostly to be used for "personal
reply" commands.

However, the text in RFC822, which says that "REPLY-TO" can be
used when you want answers to be sent to a group, seems to
indicate that the "REPLY-TO" field is to be used also for "group
reply" uses.

> FROM: Rich Wales <wales@UCLA-LOCUS.ARPA>

> I am not 100% sure I understood your description of the criteria used by
> COM in deciding whether to include the sender in the REPLY-TO field.

An example: Suppose we have a mailing list called III@JJJ with
three members:
- AAA@BBB
- CCC@DDD
- EEE@FFF

Suppose a message written by GGG@HHH, who is not a member of the
list, is sent to this mailing list. Then I would make the
following REPLY-TO clause:
REPLY-TO: III@JJJ, GGG@HHH
This would ensure that GGG@HHH would get the replies, even though
GGG@HHH is not a member of the list.

If however, AAA@BBB sends a message to the list, I would create
the following REPLY-TO clause:
REPLY-TO: III@JJJ
AAA@BBB would *not* be included in the REPLY-TO clause, since
AAA@BBB is a member of the mailing list, and will receive the
message via the list. If in this case AAA@BBB was included in the
REPLY-TO clause, AAA@BBB might get two copies of the replies, one
directly and one via the list (an intelligent system might be able
to merge the two copies before displaying them to the user, but
still the two copies would increase transmission cost and would
confuse COM, since COM would not know whether to regard it as a
personal message or a mailing list message - COM allows users to
give different priority to incoming messages belonging to
different mailing lists.



Received: from ucla-locus.arpa by MIT-MC.ARPA.ARPA; 13 Jul 85 16:44:50 EDT
Date:           Sat, 13 Jul 85 13:40:44 PDT
From:           Rich Wales <wales@UCLA-LOCUS.ARPA>
To:             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
CC:             Header-People@MIT-MC.ARPA
Subject:        Re: Subject: Ambiguity with the REPLY-TO field
In-reply-to:    Message of 13 Jul 85 15:27 +0100
                    from "Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA"
                    <113649@QZCOM>
Message-ID:     <490135244-13242-wales@DIANA.LOCUS.UCLA.EDU>

Jacob --

I thought of another way of describing the RFC822 semantics of REPLY-TO
last night, after I sent my reply to your original message.  It may seem
a bit backwards at first, but I think it makes the situation somewhat
clearer than the traditional perspective.

(1) Think of *every* message as *always* having a REPLY-TO field -- at
    least conceptually.

    Consider that RFC822 has provided a short-cut in the interests of
    brevity and non-redundancy in message headers.  Namely, if the
    "Reply-to:" header line contents are identical to the "From:" line
    contents, then the "Reply-to:" line can be (and probably will be)
    omitted from the header when the message is sent.  The receiving
    end, on finding that a message has no "Reply-to:" line in its
    header, will implicitly create a REPLY-TO field by copying the FROM
    field.

    If you assume in this way that *all* messages have REPLY-TO fields,
    the rules for constructing the recipient lists for replies suddenly
    become much simpler and more straightforward.

(2) Automatic replies *always* go to the addresses in the REPLY-TO field
    (which, by the above assumption, always exists in every message).

    The FROM field is *never* considered when addressing a reply.  To be
    sure, the REPLY-TO field may have been implicitly derived from the
    FROM field when the message was originally read and the header was
    parsed -- but once this operation has been done, we simply concen-
    trate on the fact that the message has a REPLY-TO field, forgetting
    completely about where it came from.

(3) You can then distinguish, if you wish to, between "personal" and
    "group" replies in the following way:

    (a) "Personal" replies would go only to the address(es) in the
	REPLY-TO field.

    (b) "Group" replies would go to the address(es) in the REPLY-TO, TO,
	and CC fields.

	It is debatable, by the way, whether a "group" reply should also
	go to the SENDER address(es); Section 4.4.4 (page 22) of RFC822
	states that the SENDER field should never be used automatically
	when replying to a message.  I would suggest that the SENDER
	field be included in the address list of a "group" reply only
	through invocation of a non-default option, if indeed at all.

You expressed some confusion/concern over whether RFC822's semantics of
the REPLY-TO field envision the use of this field in "personal" replies
or in "group" replies.  I think what happened was that RFC822 assumed
that the message *author* -- *not* the recipient -- would make the deci-
sion as to who would receive replies.

At the time (and probably even now), most people were accustomed to mail
systems where the only kind of reply was what you term a "personal"
reply (i.e., to the author of the message and no one else).  The REPLY-
TO field was apparently envisioned as a way to allow the message sender
to specify a wider audience for any replies to his message, without
having to assume that the person at the other end had a mail system
capable of automatically constructing a "group" reply (since most people
didn't have such mail systems anyway).

Hence, RFC822 does not really seem to provide for the kind of distinc-
tion between "personal" and "group" replies which you would like to
make.  Clearly, the issues involved were not fully appreciated, and had
not been thoroughly thought out, when the standard was written.  My
making this observation is not so much an indictment of the people
responsible for RFC822 (who, I think, did a very good job considering
the constraints they were working under) as it is a realization that
our understanding of the possibilities of electronic mail has kept on
expanding.

I think this is a good occasion to renew my suggestion that some person
or group should investigate issues such as these, and make sure that the
various kinds of recipient lists (personal replies, group replies, con-
ferences, etc.) can be adequately represented in X.400 or other appro-
priate international standards.

--
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@UCLA-LOCUS.ARPA  -or-  wales@LOCUS.UCLA.EDU
	UUCP:   ...!(ihnp4,ucbvax)!ucla-cs!wales

Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA.ARPA; 14 Jul 85 16:55:31 EDT
Date: Sun 14 Jul 85 13:53:17-PDT
From: Mark Crispin <Crispin@SUMEX-AIM.ARPA>
Subject: REPLY-TO field
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <12127009593.13.CRISPIN@SUMEX-AIM.ARPA>

As I understand it, REPLY-TO was created for the common office situation
in which some other person (e.g. a secretary) handles the individual's
mail.  The message would be "from" the person, but the secretary would be
the "sender" and possibly also the "reply to".
-------

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA.ARPA; 16 Jul 85 06:43:28 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667811068292437@MIT-MULTICS.ARPA>; 16 Jul 1985 06:37:48 edt
Date:        16 Jul 85 03:15 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          header-people <header-people@MIT-MC.ARPA>,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     > %FROM: Rich Wales <wales@UCLA-LOCUS.ARPA>
Message-ID:  <113894@QZCOM>
In-Reply-To: <490135244-13242-wales@DIANA.LOCUS.UCLA.EDU>

>
> I think this is a good occasion to renew my suggestion that some person
> or group should investigate issues such as these, and make sure that the
> various kinds of recipient lists (personal replies, group replies, con-
> ferences, etc.) can be adequately represented in X.400 or other appro-
> priate international standards.

ISO will maybe do some work in this area. ISO has sent out a vote to
member countries of whether ISO should consider this topic, if positive,
ISO will begin working on it.

There are some other people in Europe working in this area too, to
provide input to ISO, within the European COST-11-ter project.

Unfortunately, few Americans have participated in this work so far.
At the last ISO meeting on the subject, there was no American represen-
tative at all.

Another problem is that CCITT is much more important for future standards
in this area than ISO, and there is an obvious risk that CCITT will
standardize distribution lists in a way which does not understand these
problems. If any of you have any influence on CCITT work, please try
to use it to get CCITT to accept that group communication is more
complex than they may believe, and that they should consider the
work being done in ISO in this area.




Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA 17 Jul 85 14:09:18 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2667923885722126@MIT-MULTICS.ARPA>; 17 Jul 1985 13:58:05 edt
Date:        17 Jul 85 18:14 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people <header-people@MIT-MC.ARPA>
Subject:     Re: Subject: Ambiguity with the REPLY-TO field
Message-ID:  <114355@QZCOM>
In-Reply-To: <8507170110.AA03575@ucbmonet.ARPA>

The solution proposed by kre@ucb-vax.arpa is neat, but I am not
sure that it will work. Many mailing lists distribute to sub-
mailing-lists in many stages, and it will be difficult to arrange
for the personal copy and the list copy to follow the same path
through the hosts with the sub-lists.

Another problem is that users may not always, generally, want
their personal copies to be discarded if the message will reach
them via a bulletin-board.

In COM, where all mailing list messages are read via computer
conferences, we have found it very useful to have a facility
to send a message in exceptional cases both to the conference
and at the same time to a personal mailbox of a member of that
conference. (COM will then normally only show him the message
in his mailbox, not in the conference.) The reason for this is
that he may delay reading the conference if he has much to do,
and our users usually read their personal mailboxes first, so
this is a way of giving priority to certain conference messages
to certain members of those conferences.



