Date:  3 AUG 1977 0916-PDT
From: POSTEL at USC-ISIB
Subject: "certified mail"
To:   Header-People at MIT-MC
cc:   postel

oops rfc 644, was written in 1974 (not this year). Also it unfortunately
is not in the online collection of the NIC.
--jon.
-------

Date: 7 AUG 1977 2124-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: I hate to do this to all of you, but the mail must go through....
To: HEADER-PEOPLE at MIT-MC

(Bob, it's a hyphen not an underscore.)
--
From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     2 August 1977 0624-edt
Subject:  what, message-id again, oh no! but yes, here we go...
Message-ID:  [MIT-Multics]1.2.BBBJGjDhXDxZqM
To:       mrc at SU-AI
cc:       header_people at MIT-MC

In reply to the following:

<< Mail from Network host SU-AI (Network_Server.CNet)  08/02/77  0516.7 edt Tue  >>

Date: 2 Aug 1977 0211-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: mail header cruft
To:   Frankston at MIT-MULTICS

Please explain to me how [MIT-Multics].1.2.BBJGjDNmklMXN helps me in reading
my mail.  And my point still is that it is objectionable to get a 10 line
mail header for a 2-line message text.

-------

1. There is no need for me to explain it  -- simply that a
number of people find it useful in constructing message
systems so that you as a member of the community of message
system programmers provide it as a courTesy to those who in
their mysterious wys find it useful. Please excuse my tone,
but I have explained this many times and will do so below.
The point is, however, that anyone system may not use all
the features.

2. One simple use of message-id is to screen out multiple
path messages. I often have a few coies of the same letter
in mailbox and need to screen it.

Multics is shutting down now -- gotta logoff.

Date:  9 AUG 1977 1453-PDT
From: POSTEL at USC-ISIB
Subject: RFC 724 Status
To:   Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX,
To:   Henderson at BBNA
cc:   Header-People at MIT-MC, Postel

The preface of rfc 724 indicates that comments are to be incorporated and
somehow agreed to by 1 september 77. Thus i expect that a revised document
is in the works someplace. I have had some recent inquires about the wisdom
of implemeting something based of rfc 724. To these inquiries i have said
"wait - it is not agreed to yet, there should be a revision comming". If my
model of the state of rfc 724, and of mail format standard is wrong please
let me know.
--jon.
-------

Date:  9 Aug 1977 at 1657-PDT
Subject: Re: RFC 724 Status
From: Dcrocker at Rand-Unix
To: POSTEL at Usc-Isib
cc: Pogran at Mit-Multics, Vittal at Bbn, Dcrocker at Rand-Unix,
cc: Henderson at Bbna, Header-People at Mit-Mc, Postel at Usc-Isib
Message-ID: <[Rand-Unix] 9-Aug-77 16:57:03.Dcrocker>
In-Reply-To: Your Message of  9 AUG 1977 1453-PDT

Jon -- To date we have received only a few comments.  All are
extremely minor, except for the multi-net specification problem
and 724's deviation from NBS date/time form.  Therefore, our plan
is to put a small bit of work in soon, meet in the middle of
September to have a face-to-face blessing ceremony and then to
issue the spec as a "standard", publishing through assorted
mechanisms.

Along with publishing the spec, we will describe an adoption
sequence and, I suspect, a plan for monitoring adoption of the
spec by systems, primarily so that we can keep track of when
sites can expect to generate (rather than simply accept)
724-text.

Also, I expect we will issue a document describing the
relationship between existing system's conventions and those in
724, so that people will have an idea of how much disparity
actually exists and how difficult the changeover should be.

Is this what you had in mind?

With reference to beginning implementation before the final spec
is released, I predict that the spec will differ from 724 only
trivially.

Dave.

Date: 9 Aug 1977 1741-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: RFC 724
To:   DCrocker at USC-ISI, Postel at USC-ISI
CC:   Header-People at MIT-MC   

I appreciate the attitude that all the objections that people have made to
the proposed standards and all the garbage in mail headers is to be so
casally dismissed as "minor".

At SU-AI, work has begun on a mailer which will generate 100 line message
headers for all mail, including such useful information as saying who the
sender is 10 times, the last and next five high and low tides in
San Francisco bay, the phase of the moon, the local weather, SAIL's uptime
in nanoseconds, the latitude and longitude, etc...

-------

Date: 9 Aug 1977 1857-PDT
Sender: GEOFF at SRI-KA
Subject: Re: RFC 724
From: GEOFF at SRI-KA
To: Mrc at SAIL
Cc: DCrocker at USC-ISI, Postel at USC-ISI, 
Cc: Header-People at MIT-MC 
Message-ID: <[SRI-KA] 9-Aug-77 18:57:45.GEOFF>
In-Reply-To: Your message of August 9, 1977  

Don't forget to include the amount of money spent in the Stanford
AI lab PONY vending machine for the current month in the header
too.

Really, I think dismissing all of the cmments recieved as 'minor'
was pretty blecherious too.  I myself would certinaly want to see
any document spread around the network before it became any type
of standard that everyone has to follow.
-------  

Date:     9 Aug 1977 2111-EDT
From:     Brian Reid at CMU-10A
Subject:  Missing feature from ARPAnet mail
To:       Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  9 Aug 1977 21:11:12 Brian Reid
In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin

I just thought of something else that netmail should have.  We need
an option, like the Post Office has, whereby you can request that
obscene mail from certain senders not be delivered.
-------
                             

Date: 10 AUG 1977 1146-PDT
From: POSTEL at USC-ISIB
Subject: Re:  Missing feature from ARPAnet mail
To:   BrianReid at CMU-10A, Header-People at MIT-MC,
To:   DCrocker at USC-ISI, Postel at USC-ISI
cc:   POSTEL

In response to the message sent     9 Aug 1977 2111-EDT from     Brian Reid at CMU-10A

Brian:
it seems that it should be easy to add such a filter to your mail receiving
program. Give a list of senders that you dont want stuff from and have your
receiver file messages from senders on the list in the bit bucket instead
of your mailbox. 
--jon.
-------

Date: 10 Aug 1977 2135-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

	Date:     9 Aug 1977 2111-EDT
	From:     Brian Reid at CMU-10A
	Subject:  Missing feature from ARPAnet mail
	To:       Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI
	Sender:   BRIAN.REID at CMU-10A
	Message-ID: [CMU-10A]  9 Aug 1977 21:11:12 Brian Reid
	In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin
	
	I just thought of something else that netmail should have.  We need
	an option, like the Post Office has, whereby you can request that
	obscene mail from certain senders not be delivered.
	-------

[Perhaps we need something else added to mail headers; the emotional
 maturity quotient of the sender.

 All I am doing is making a plea for simplicity AND more importantly,
 to keep things as they are.

 It seems that the people who like hairy mail headers tend to treat it
 as (1) a personal matter, and (2) the only right thing.  My point has
 never been that the hairy mail header people's opinions are uninportant,
 however, it seems that the people who want hairy mail headers dismiss
 the opinions of those who want to leave things alone as "minor".  No,
 wait, now the term is "obscene".  Gee, how many things that term covers
 now!]

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     10 August 1977 1851-edt
Subject:  obscene mail
Message-ID:  [MIT-Multics]1.2.BBBJGjlDwDjNgd
To:       reid at CMU-10a, dcrocker at USC-ISI
To:       usc-isi at USC-ISI
cc:       header-people at MIT-MC

Multics has such as facility, one can set the access control
list for on'e's mailbox.  But over the net, without
certified mail .......  Perhaps the alternative is something
similar to the federal legislation that (I think) says that
you may somehow declare to the world that you do not want
obscene mail and thus anyone who is so foolish to send you
mail that you personally find offesive is breaking the law.

Of course, this has the side effect of making much of the
dialogue in header-people questionable.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     11 August 1977 0128-edt
Subject:  hairy headers
Message-ID:  [MIT-Multics]1.2.BBBJGjlmDDQgcc
To:       mrc at SU-AI
cc:       header-people at MIT-MC

Mark, you have the hairiest headers in header-people. The
complete contents of the letter you are replying to makes a
moby subject field that is not even parsable as such.

Date:  9 AUG 1977 1453-PDT
From: POSTEL at USC-ISIB
Subject: RFC 724 Status
To:   Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX,
To:   Henderson at BBNA
cc:   Header-People at MIT-MC, Postel

The preface of rfc 724 indicates that comments are to be incorporated and
somehow agreed to by 1 september 77. Thus i expect that a revised document
is in the works someplace. I have had some recent inquires about the wisdom
of implemeting something based of rfc 724. To these inquiries i have said
"wait - it is not agreed to yet, there should be a revision comming". If my
model of the state of rfc 724, and of mail format standard is wrong please
let me know.
--jon.
-------


Date:  9 Aug 1977 at 1657-PDT
Subject: Re: RFC 724 Status
From: Dcrocker at Rand-Unix
To: POSTEL at Usc-Isib
cc: Pogran at Mit-Multics, Vittal at Bbn, Dcrocker at Rand-Unix,
cc: Henderson at Bbna, Header-People at Mit-Mc, Postel at Usc-Isib
Message-ID: <[Rand-Unix] 9-Aug-77 16:57:03.Dcrocker>
In-Reply-To: Your Message of  9 AUG 1977 1453-PDT

Jon -- To date we have received only a few comments.  All are
extremely minor, except for the multi-net specification problem
and 724's deviation from NBS date/time form.  Therefore, our plan
is to put a small bit of work in soon, meet in the middle of
September to have a face-to-face blessing ceremony and then to
issue the spec as a "standard", publishing through assorted
mechanisms.

Along with publishing the spec, we will describe an adoption
sequence and, I suspect, a plan for monitoring adoption of the
spec by systems, primarily so that we can keep track of when
sites can expect to generate (rather than simply accept)
724-text.

Also, I expect we will issue a document describing the
relationship between existing system's conventions and those in
724, so that people will have an idea of how much disparity
actually exists and how difficult the changeover should be.

Is this what you had in mind?

With reference to beginning implementation before the final spec
is released, I predict that the spec will differ from 724 only
trivially.

Dave.

 

Date: 9 Aug 1977 1741-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: RFC 724
To:   DCrocker at USC-ISI, Postel at USC-ISI
CC:   Header-People at MIT-MC   

I appreciate the attitude that all the objections that people have made to
the proposed standards and all the garbage in mail headers is to be so
casally dismissed as "minor".

At SU-AI, work has begun on a mailer which will generate 100 line message
headers for all mail, including such useful information as saying who the
sender is 10 times, the last and next five high and low tides in
San Francisco bay, the phase of the moon, the local weather, SAIL's uptime
in nanoseconds, the latitude and longitude, etc...

-------


Date: 10 AUG 1977 1146-PDT
From: POSTEL at USC-ISIB
Subject: Re:  Missing feature from ARPAnet mail
To:   BrianReid at CMU-10A, Header-People at MIT-MC,
To:   DCrocker at USC-ISI, Postel at USC-ISI
cc:   POSTEL

In response to the message sent     9 Aug 1977 2111-EDT from     Brian Reid at CMU-10A

Brian:
it seems that it should be easy to add such a filter to your mail receiving
program. Give a list of senders that you dont want stuff from and have your
receiver file messages from senders on the list in the bit bucket instead
of your mailbox. 
--jon.
-------


Date: 10 Aug 1977 2135-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

	Date:     9 Aug 1977 2111-EDT
	From:     Brian Reid at CMU-10A
	Subject:  Missing feature from ARPAnet mail
	To:       Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI
	Sender:   BRIAN.REID at CMU-10A
	Message-ID: [CMU-10A]  9 Aug 1977 21:11:12 Brian Reid
	In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin
	
	I just thought of something else that netmail should have.  We need
	an option, like the Post Office has, whereby you can request that
	obscene mail from certain senders not be delivered.
	-------

[Perhaps we need something else added to mail headers; the emotional
 maturity quotient of the sender.

 All I am doing is making a plea for simplicity AND more importantly,
 to keep things as they are.

 It seems that the people who like hairy mail headers tend to treat it
 as (1) a personal matter, and (2) the only right thing.  My point has
 never been that the hairy mail header people's opinions are uninportant,
 however, it seems that the people who want hairy mail headers dismiss
 the opinions of those who want to leave things alone as "minor".  No,
 wait, now the term is "obscene".  Gee, how many things that term covers
 now!]

-------


Date:  9 AUG 1977 1453-PDT
From: POSTEL at USC-ISIB
Subject: RFC 724 Status
To:   Pogran at MIT-MULTICS, Vittal at BBN, DCrocker at RAND-UNIX,
To:   Henderson at BBNA
cc:   Header-People at MIT-MC, Postel

The preface of rfc 724 indicates that comments are to be incorporated and
somehow agreed to by 1 september 77. Thus i expect that a revised document
is in the works someplace. I have had some recent inquires about the wisdom
of implemeting something based of rfc 724. To these inquiries i have said
"wait - it is not agreed to yet, there should be a revision comming". If my
model of the state of rfc 724, and of mail format standard is wrong please
let me know.
--jon.
-------



Date:     11 Aug 1977 1347-EDT
Reply-To: Header-People at MIT-MC
Subject:  Re: Leaving things as they are
To:       MRC at SU-AI (Mark Crispin)
CC:       Header-People@MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A] 11 Aug 1977 13:47:21 Philip Karlton
In-Reply-To: MRC's message of August 10, 1977

The problem with leaving things as they is that different sites have
different conventions concerning the format of items that programs
are currently trying to parse.  (If you want some examples, here are
2:  One site puts no "," at the end of each line of an address list
that is continued on the next line; some sites (programs) insist that
embedded blanks in names should be thrown away and at least one site
uses both first and last names (separated by a space) to disambiguate
addresees for delivery.)

RFC 724 is, at least as far as I understand it, an attempt to make a
standard syntax and semantics for all the things that people are
sticking into their mail headers already.  I think that the authors
have bent over backwards to allow almost all of the things that mail
creating programs are currently doing.  Why else would they choose to
allow both the type of date given in the header of this message and
"slash" dates which are ambiguous if a European is reading the
letter?

I do not know what it is specifically that you object to in RFC 724.
If you had the authority would you just disallow all but a few items
in the header?  DO you not think a standard syntax and semantics for
those items in headers likely to be parsed by programs is desirable?
My apologies; I should not get facetious.  I expect that your answers
to these particular questions are the same as mine.  Do you have some
concrete suggestions for changes to RFC 724?

			Phil Karlton
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     11 August 1977 0128-edt
Subject:  hairy headers
Message-ID:  [MIT-Multics]1.2.BBBJGjlmDDQgcc
To:       mrc at SU-AI
cc:       header-people at MIT-MC

Mark, you have the hairiest headers in header-people. The
complete contents of the letter you are replying to makes a
moby subject field that is not even parsable as such.


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     10 August 1977 1851-edt
Subject:  obscene mail
Message-ID:  [MIT-Multics]1.2.BBBJGjlDwDjNgd
To:       reid at CMU-10a, dcrocker at USC-ISI
To:       usc-isi at USC-ISI
cc:       header-people at MIT-MC

Multics has such as facility, one can set the access control
list for on'e's mailbox.  But over the net, without
certified mail .......  Perhaps the alternative is something
similar to the federal legislation that (I think) says that
you may somehow declare to the world that you do not want
obscene mail and thus anyone who is so foolish to send you
mail that you personally find offesive is breaking the law.

Of course, this has the side effect of making much of the
dialogue in header-people questionable.


Date:     9 Aug 1977 2111-EDT
From:     Brian Reid at CMU-10A
Subject:  Missing feature from ARPAnet mail
To:       Header-People at MIT-MC, DCrocker at USC-ISI, Postel at USC-ISI
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  9 Aug 1977 21:11:12 Brian Reid
In-Reply-To: [SU-AI] 9 Aug 1977 17:41:15 Mark Crispin

I just thought of something else that netmail should have.  We need
an option, like the Post Office has, whereby you can request that
obscene mail from certain senders not be delivered.
-------


Date: 11 AUG 1977 1104-PDT
Sender: DCROCKER at USC-ISI
Subject: Re:  obscene mail
From: DCROCKER at USC-ISI
To: Frankston at MULTICS, postel at ISIB
Cc: reid at CMU-10A, dcrocker, header-people at MIT-MC
Message-ID: <[USC-ISI]11-AUG-77 11:04:00.DCROCKER>
In-Reply-To:  [MIT-Multics]1.2.BBBJGjlDwDjNgd 

I have a file of messages and responses that I send (and
received) last Christmas which you might appreciate.  I will try
to fetch it and send you each a copy.  Keep in mind the Postal
Inspector idea.

Dave.
-------

Date: 11 AUG 1977 1437-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: loops in HEADER-PEOPLE
To: HEADER-PEOPLE at MIT-MC
CC: (BUG MAIL) at MIT-MC

MAIL on MC was horribly backed up today, and while looking through the
queue I discerned an number of messages from 2 days ago making the rounds
again.  I hope that someone will find this loop and kill it, because it
appears to require a fair amount of time to foward mail to HEADER-PEOPLE due to
the large amount of network sending required.  I suspect that the HEADER-PEOPLE
list is largly responsible for the backlog.

(I hope that this one doesn't loop!)

Date: 11 AUG 1977 1550-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Re: RFC 724 Status
To: Dcrocker at RAND-UNIX, POSTEL at USC-ISIB
CC: HEADER-PEOPLE at MIT-MC, Pogran at MIT-MULTICS
CC: Henderson at BBN-TENEXA, Vittal at BBN-TENEX

I just looked over some of the comments on RFC724 that were sent to Header-People
last spring, after seeing Dave Crocker's letter saying that it was planned
to ignore most of the comments.  I think there are two issues here that strongly
affect MIT-{AI ML MC}.  One is that in order to continue services we already
provide, we need a way to include complex structured text in recipient names
we include in outgoing headers.  Other hosts need to be able to send this
complex text back intact, without parsing it, when replying to mail originating
from us.  I expect that other sophisticated mail systems either need such a 
feature now or would like to have features which would require such a thing.
For example, mail sent from Tenex via a distribution list cannot currently
be automatically replied to, because the name of the distribution list is
not in a format which can be sent back to that same site as a recipient name
and cause forwarding through the distribution list.

We currently represent structured text by text enclosed in balanced
parentheses.  RFC724 disallows this by using parentheses for comments,
which is all right, but does not suggest an alternative, such as 
balanced brackets.  Note that the "balanced" part is vital.  Also a quote-the-next
character convention that was standardized would help a great deal.

Related to this is that RFC724 should include a guideline to implementors
saying how to turn a "To:" field into a recipient for replies.  For instance,
should comments be deleted or should they be left in place?  Should sites
be required to accept all "To:" fields that they generate?

The second issue is that I had hoped that RFC724 would provide the necessary
standardization to allow our mailer to successfully parse headers on mail
incoming from the network.  For instance, if we get an error in delivery
of mail, it is currently impossible to inform the author because there is
no way to find out who the author is.  This leads to a lot of unreliability.
The reason we accept this, rather than parsing headers, is that currently
header formats are too variable.

It looks like RFC724, if the final version is essentially the same
as the draft we have already seen, is not going to be much help with this.
The clarification of From, Author, Sent-by, and Reply-to is certainly
helpful.  But RFC724 introduces even more recipient name formats,
and some of the formats it allows are not machine parseable.  Consider
the problems with the comma in
	To: Jonathon Q. Public, Jr. <JQPublic@Site>
which seems to be a proposed replacement for
	To: JQPublic@Site (Jonathon Q. Public, Jr.)
which most (but not all) sites currently parse reasonably.  RFC724 should make
some recommendation about this.

One final complaint about rfc724 which I have, and which I think
is not trivial, is that it does not contain hints to implementors
of the form "the way to do this is this" or "if this situation happens,
you should inform the Sent-by, not the Author".  I have a feeling that
in its present form not everyone would agree on what it means, and the
"724-compatible" mail systems may be just as incompatible as the present ones,
in which case all the work that has gone into RFC724 will have accomplished
very little.

Date:     11 Aug 1977 2003-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: obscene mail
To:       Frankston at MIT-Multics (Robert M. Frankston)
CC:       reid at CMU-10a, dcrocker at USC-ISI usc-isi at USC-ISI,
CC:       header-people at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 11 Aug 1977 20:03:48 Brian Reid
In-Reply-To: [MIT-Multics]1.2.BBBJGjlDwDjNgd

Most of the dialogue in Header-People is already questionable.
-------

Date: 11 Aug 1977 1903-PDT
Sender: GEOFF at SRI-KA
Subject: Re:  Re: obscene mail
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: BRIAN.REID at CMU-10A
Cc: reid at CMU-10A, header-people at MIT-MC
Message-ID: <[SRI-KA]11-Aug-77 19:03:51.GEOFF>
In-Reply-To: [CMU-10A] 11 Aug 1977 20:03:48 Brian Reid

I like the 'Cc: dcrocker at USC-ISI usc-isi at USC-ISI' part the
best.
 of your message.
-------

Date: 12 AUG 1977 1235-PDT
Sender: DCROCKER at USC-ISI
Subject: Response to Moon, et al., Re: RFC 724
From: DCROCKER at USC-ISI
To: Header-People at MIT-MC    
Message-ID: <[USC-ISI]12-AUG-77 12:35:20.DCROCKER>   

David Moon's note was too rational in style and moderate in tone
for me to feel comfortable allowing it to pass unanswered.

My response to Jon Postel's query has been misunderstood by
enough people that I will hereby retract the phrasing of the
sentence that has bothered so many of you and will replace it
with the following:

There have been relatively few comments generated, SINCE RFC724
WAS RELEASED and which introduce NEW material.

Now on to David's substantive criticisms...

Inclusion of random text (e.g., "complex structured text") is
fully supported for the "person's name" part of an address.  That
portion is specified to be a <phrase> in the second alternative
of <mach-addr-item>.  Note that a <phrase> consists of a series
of <word>s and that a <word> may consist of a <quoted-string>.
Now a <quoted string> begins with a double-quote and ends with a
double quote.  In between may be ANY character.  Lexical analysis
is defined in a way which prevents rules from noticing <crlf> but
an implemented parser can avoid this problem.  (The limitation
exists for the convenience of specifying the standard; it turns
out that it is really a false limitation.)  I had originally
thought that the only real limitation was that empty strings
could not be specified, since two adjacent double-quotes are used
to specify a double-quote to be used as data and not as a
delimiter.  Austin Henderson has pointed out that even this
limitation is not present.  The first double-quote is
unambiguously taken as "beginning of string" and the meaning of
the second is determined by the third character.  Since the third
character will not be a double quote (i.e., you must have SOME
separation between strings), the second double-quote is taken to
be the ending delimiter.  Note that double-quote is the only
character that NEEDS an escaping mechanism, within a <quoted-
string>.

Also note that the <quoted-string> facility eliminates the
"Jonathon Q.  Public, Jr."  problem cited by David.  It would be
specifed inside the double quotes, as I have done in the previous
sentence.

With regard to determination of actual "responsible person" (to
avoid calling that person the "author"), the spec is quite
specific.  If a Sender field is present, it must contain an
unambiguous <host-phrase> which will allow the referenced host to
contact the PERSON who sent the note.  If no Sender field is
present, then the From field must satisfy this requirement.  724
uses different text than I just used, but I believe it to be no
less clear.  Note that the syntax of the source-indication field
(Sender or From) is EXTREMELY simple.  Complex syntax is
supported for OTHER address fields.  Sometimes the address list
is a "mach-addr" list, rather than a simple "addr" list.  The
former requires that at least one member of the list be a valid
machine-processable address.

Processing of the "To" field:  The standard is for SYNTAX and
SEMANTICS and cannot reasonably place requirements upon how
implementors choose to USE the standard, as long as what they
generate is valid.  In particular, comments are, by definition,
superfluous to the "processability" of an address and therefore
may be included or not, at the discretion of the creator.  As a
personal observation, I would say that passing a comment on would
be a friendly thing to do, since the comment was presumably
included for a reason.  However the spec is clear that comments
are not to be used in the FTP MAIL or MLFL commands, since that
text is NOT part of the processable address.

I think that the question about the responsibility of hosts to
honor references to addresses they generate ("...required to
accept all 'To:'  fields that they generate") is an excellent
one.  In checking section II.C.1.a, I find that the spec makes no
statement about the absolute responsibility of the generating
host, although there are several statements which fairly strongly
imply that responsibility.  In particular, subsection 2) says
that the <phrase> part of a <mailbox> is "...whatever the
receiving FTP Server allows...".  In the final draft, I'll try to
have us tighten up that loop-hole.

There have been several calls for the inclusion of "hints to
implementors".  We think that this would be entirely
innappropriate for inclusion in the specification of a standard.
It is entirely appropriate for inclusion in papers discussing the
standard.  The role of a spec is to specify.  Explanations in a
spec should only clarify meaning.  E.g., I suspect we had better
clarify parsing of <quoted-strings>.

Hmmm, seem to have finished the list.  Now for another personal
observation.  Standards specifications cannot be taken as light
reading.  RFC 724 contains around 70 bnf rules.  A rule-set that
large must be analyzed VERY carefully, with a great deal of
cross-referencing to the semantics section.  While many of you
have obviously put in a large amount of time and made excellent
observations, suggestions, and criticisms, too often a criticism
is based upon insufficiently careful reading.  Besides the fact
that that is leading to an enormous number of unnecessary
misinterpretations, it means that the proposal is not getting the
kind of critical review that it needs.  It was the absence of
additional (i.e., new) substantive commentary of this sort that I
was saying was lacking.  Prior to the issuance of 724, there was
also a great deal of noise in the discussion, but there was also
a significant number of excellent content reviews.  I believe
that 724 reflects most of the resulting suggestions which we
could resolve.  Since 724 was issued, only the multi-net and the
date/time questions have been newly raised.

Just so that no one will think that I am putting all the
responsibility upon the readers and none upon us, the writers, I
want to make clear that finding out now about the parts of the
spec which simply are not comprehensible is extremely important.
Parsing of <quoted-string> is one example.  One of you tried to
understand the From/Sender/Reply-to stuff and finally broke down,
requesting that we give more examples, etc.  That was extremely
valuable input; I'd like more.

Dave.
-------

Date: 16 Aug 1977 1033-PDT
From: Klh at SRI-KL
Subject: Mental malnutrition - we need meat...
To:   Header-People at MIT-MC

With hours drawing nigh, it seems time for me to contribute something.  
I had collected a number of comments about RFC 724 but never sent them; 
although I will include them eventually, in this message I wish to 
explain the reason behind the reticence.

As people have noted, there is often a lot of superficial arguing and 
proselytizing among Header-People.  However, I don't mind this - at best
it introduces interesting ideas, at worst it's amusing, and always it 
reminds one that something is supposed to be happening.  What upset me 
when RFC 724 came out, invited a "why bother" stance, and has gnawed at 
me since, is the apparent invisibility of CAHCOM.  The message from Dave
Crocker mentioning "extremely minor" comments rekindled my ire, but not 
for the same reason that it did others; what hit me was the bulk of the 
message, into which I read the appearance of arrogance.

Dave is right that the comments specifically addressing RFC 724 after 
its release have been few; anyone looking over the transcripts can see 
that.  What was NOT minor was the total exchange around 724, its draft, 
and what constraints it should or shouldn't have; this, indeed, seems to
be ignored.  Basically, CAHCOM has blundered disappointingly for lack of
*F!E!E!D!B!A!C!K* -- I don't mean feedback from the Header-People, but 
from CAHCOM itself.

   From the time that RFC 724 was released on May 13, to the time I 
   write this, there have been exactly 3 messages from any of the CAHCOM
   people -- all from DCrocker. (Thank you, Dave.)  The first merely 
   mentioned that RFC 730 existed and was sent May 25.  The second was 
   Aug. 2 on "What is a Message?".  The third was the reply to Postel 
   that sparked another flurry of unfiltered mail.  Before that, we had 
   the draft release on Oct 29; the last note I can find from CAHCOM 
   about it is dated 9 Nov from Vittal.  Between then and May 13, 
   nothing.

   This is just the quantitative basis supporting the qualitative 
   impression that CAHCOM people give no explanations for what they do, 
   provide scant acknowledgement of suggestions or comments, don't 
   bother to respond to questions or criticisms, make no arguments 
   comparing their schemes with others, and on this basis have the 
   effrontery to dictate what is and is not to be in our collective 
   mail-world.

   According to the latest news, 724 will not be seen again until it is 
   stamped "official" in September (violators shot at dawn);  nor will 
   the adoption/monitoring scheme see the light before 724 is finalized.
   It is also rather galling that CAHCOM thinks they understand the 
   relationship between "existing system's conventions and those in 724"
   well enough to tell the maintainers of said systems "how difficult 
   the changeover should be".  Isn't that for the maintainers, in 
   Header-People, to figure out?

   By virtue (?) of delay and disinterest, might it be surmised that 
   most CAHCOM people are disqualifying themselves from participation?  
   Hard to tell...

I am getting overly sarcastic perhaps.  What I would have liked (and 
would still like) to see is some more constructive discussion, not 
one-way glass; there were many suggestions made about the draft of 724 
last fall which I thought were very reasonable, which I don't see much 
trace of in 724, and I would like to know why; what is it exactly that 
CAHCOM thinks is wrong with them?  Even the post-724 comments have no 
counterpoint to them; I would have loved to see the replies to Postel's 
724 comments (May 23), and Moon's (May 14), as well as some word about 
ANSI standard dates/zones as described by Rick Gumpertz.  Much of these 
were actually QUESTIONS.  I see neither the answers nor the revised 724 
that incorporates the answers, if any.

But there is hope.  Moon recently sent a message raising some of the 
same issues I had on my list, and DCrocker has replied in exactly the 
way I have been wishing CAHCOM people would (that makes 4).  If this can
be extended retroactively, I would be much more comfortable, much less 
depressed, and some of this bureaucratic blatherousness could be 
dispensed with.  So, here are some procedural desires:

   When a message is clearly asking for some clarification, or making a 
   suggestion for change, it should be replied to in a reasonable time. 
   It is perfectly OK for more than one person to reply to the same 
   things, especially if opinions are somewhat divided; the worst case 
   would be a "you first" deadlock.  Perhaps some one person (Dcrocker? 
   Henderson?) should be responsible for delegating replies.

   The current version of 724 should be generally available, whatever 
   shape it happens to be in.  I would very much like my comments about 
   BNF to be made on the basis of the latest typo fixes, clarifications,
   etc...

   It would be nice if CAHCOM people felt free to take informal surveys;
   e.g. "how many of you really like/dislike this neat hack" or "does 
   anyone really depend on this kludge now" etc...  I don't remember if 
   this was ever done.  If it were something directly tied to 724, the 
   response might be much wider than what currently greets very random 
   "surveys", since on many issues people just let someone else say it 
   for them.

   There may be some feeling that anything not directly connected to 
   SYNTAX, specifically of 724, is out of order.  I disagree; 724 does 
   have more general implications that can bear discussion, whether of 
   semantics or wording or philosophy.  The RFC itself cannot exist on 
   its syntax alone (witness 1st section), why should CAHCOM?

This is it for now -- I have a headache and will try to shove out the 
724-specific stuff in a day or two.  Probably also have some words for a
couple of the auxiliary issues that have been banged around this summer.

-------

Date:     16 Aug 1977 1711-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re: Mental malnutrition - we need meat...
To:       Klh at SRI-KL
CC:       Header-People at MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 16 Aug 1977 17:11:43 Rick Gumpertz
In-Reply-To: Your message of August 16, 1977

I agree with Ken totally.  Much of what I would have criticized RFC
724 for had already been brought up (though perhaps never answered)
and so I did not bring them up again.  This seems to have had the
effect that they just disappeared in some bit bucket.  I would like
to see someone (from the RFC 724 committee) go down all the points
brought up in Header-people discussions (ther aren't all that many
unique topics) and explain WHY things were chosen or dismissed.

I also disagree with the comment that "Hints to implementers" should
not be part of RFC724.  Perhaps they should be in an appendix, with
the notation like that in an appendix to EIA RS-232C, that they are
not part of the official standard.  If they are not part of the
RFC-724 document, however, they are likely to get separated and
misplaced, or worse yet, never produced.  I personally would consider
RFC 724 acceptable for official approval ONLY if such hints are
available.  Where are they now?  Is anyone working on them?


		Rick
-------

DLW@MIT-AI 08/16/77 22:04:21 Re: Following letter from Rick Gumpertz of 16 aug 77
	Let me chime in: I agree that "hints to implementors" should
in some way be appended to RFC724.  I understand why they should not
be part of the text of the official standard; but I think anyone who
requests a copy of RFC724 should somehow ALSO get the "hints" section. 
This will go a long way towards settling disputes about the "right"
way to treat various fields, and also may provide a suitable place to
store semi-official agreements about issues not specifically covered
the standard itself.  I would very much like to see this put in.  -- Dan.


Date: 17 AUG 1977 0122-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

I think people have the unfortunate idea that a "standard"
must be expressed in an abstract mathematical form, the idea being
that anything mathematically abstract must be unambiguous.
This results in a standard which is as hard to comprehend as
a poorly-written math textbook.
What a standard should actually be is whatever is most effective
for conveying the precise meaning intended.  Examples of how a
certain part of a data structure are intended to be used are
an extremely good way to explain what the "meaning" of the contents
of the data structure is.  A mail header standard should not ignore
their usefulness out of a desire to appear to be made out of pure,
incorruptible, platinum mathematics.


Date: 24 Aug 1977 0546-PDT
From: Klh at SRI-KL
Subject: New representation of 724 syntax
To:   Header-People at MC

While crawling over 724 in an attempt to make sure I knew what I was
talking about, I finally decided that part of the whole problem was the
particular representation used.  People have complained that BNF is basically
a pretty horrible way to specify this stuff, but nobody seems to really know
how else to do it.  I don't either, but it seemed that with the application of
a few ideas from a local meta-compiler, things could be improved.  Rather
than just suggest them, I went ahead and did them; header-people in general
and cahcom people in particular can find the overhauled syntax living
in either of two places:
 [MIT-MC]  KLH;NEWSYN >           requires no login
 [SRI-KL] <KLH>NEWSYN.TXT         login as anonymous, pw anything.

   I showed this to several people for comments, and it seems to be a win.
With a better idea of what the syntax is asking for, people can presumably
form more useful opinions about it.  This is NOT a revised syntax, it is
a revised representation of RFC 724, and is not meant to introduce
anything other than a better notation.  Consequently, apart from comments
on its clarity, it needs to be checked by 724's authors for consistency --
but I think it's fairly accurate.
     The actual criticisms/suggestions I have will follow in another message;
whipping NEWSYN up took some time.  Would like to hear from people meanwhile.

--Ken
-------

Date: 25 AUG 1977 1642-PDT
Sender: DCROCKER at USC-ISI
Subject: Pending availability of report on Unix message system
From: DCROCKER at USC-ISI
To: header-people at MIT-MC, [ISI]<MsgGroup>Mailing.List:   
Message-ID: <[USC-ISI]25-AUG-77 16:42:18.DCROCKER>   

In the near future, my Rand report on our Unix-based message
system (called "MS", which is pronounced "mizz") will be
available and I am compiling a list of people who want copies.
If you do, please tell me your U.S.  Postal address.

For those who are not sure, a brief description of the report is
located in [ISIA]<DCrocker>MS.Blurb and is accessible through FTP
using the user name ANONYMOUS and any password.

Dave Crocker.
-------

Date: 26 Aug 1977 1018-PDT
From: BH at SU-AI (Brian Harvey)
Subject: If you're going to have a blarney can I hold your coat?
To:   header-people at MIT-MC    

1. I am now back in California and would like to be added to the
mailing list, please, whoever is in charge.

2. Aside to DCROCKER: Has anyone suggested to you that MS pronounced
mizz as the name for a message system is sexist? (Women as secretaries.)

3. About the verboseness controversy.  We seem to be divided in camps
based on the use we make of the mail facility, as someone or other has
suggested.  (I suspect that the division is roughly based on whether
or not one has a secretary who sends one's mail!)  I would like to suggest
that at least some of the difficulty could be resolved by a bit more
tightness about the conditions under which various fields are used.  In
particular, it would help a lot if the standard outlawed the use of
FROM and SENDER fields which are otherwise identical; the thing that
annoys me the most is seeing
	From: FOO at MIT-MC
	Sender: FOO at MIT-MC
	Author: FOO at MIT-MC
	Originator: FOO at MIT-MC
	Reply-to: FOO at MIT-MC
	Copyright-by: FOO at MIT-MC
and so on.  Perhaps another way to put it would be that there would be
only a few fields which a mail sending program would put in on its own
initiative, and you'd have to ask for the others explicitly.

4. What a message is:  I agree this is an important thing to discuss,
and I'd like to argue for the view that we should think of it as being
ASCII text directed toward a human being, rather than some abstract
message to an abstract entity.  My argument is basically that there is
enough human-to-human traffic that it is worth treating that as a
separate case.  You abstract-entity people, I think, are really reacting
to deficiencies in the file transfer protocol, which ought perhaps to be
more powerful than it is to allow inter-program cooperation.  The scheme
used among the ITS systems to allow a program on one machine to read
files on another machine is a good example of the sort of facility we
need, but this should not be allowed to hair up our notion of mail!

5. Another side comment, about the style of the committee: I suspect
a lot of the heat in this discussion comes from the fact that this is
(I think) the first (proposed) standard which talks about things like
everyone being REQUIRED to conform by such-and-such a date.  Past
standards just sort of sat there, and you could conform to them if
you wanted to.  I can sympathize with the thinking behind this
requirement business, but it raises practical as well as emotional
problems.  SAIL, for example, has much more system programming to be
done than people to do it, and Arpanet protocols are pretty low on the
priority list.  (My opinion, not to be construed as a SAIL policy
statement.)  Nobody is being funded specifically for Arpanet work; it
has to slip into spare moments.  (I have heard a similar remark from
someone at BBN, by the way.)  Consider the "new FTP", which has
certainly not taken over the world.  Given this situation, we must
understand that many implementations will probably be quite minimal,
and when users of such systems get annoyed at all the header text which
should have been filtered out but isn't, it will not be constructive to
argue about whether the blame lies with the standard or the local wizards.

-------

Date: 26 Aug 1977 1703-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: BH's message irt headers or First and 10, Let's do it again
To:   Header-people at MIT-MC    

I hope the people out there are listening, and aren't going to continue to
simply ignore what may well be at least 50% of the ARPAnet community.  Brian's
message presents my major objections to what RFC 724 stands for, and
possibly in a more coherant and constructive way.  I still don't understand
why I get mail with 15-line headers and 2 line messages, especially telling
me that FOO @ FOO-SECURITY sent me the message 4 times.  It seems that the
amount of information gained by all the extra stuff decreases proportionally
with the amount of increase in the header, so while a 3 line header gives
you n bits of information, a 6 line header gives you n+n/2, a 12 line header
gives you n+n/2+n/4, etc...
What are all those fields for anyway?  To ensure that a message isn't forged?
I really don't think that prevents it.

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     27 August 1977 0136-edt
Subject:  Abstractions versus ftp
Message-ID:  [MIT-Multics]1.2.BBBJGlCBzPjcBX
To:       bh at SU-AI
cc:       header-people at MIT-MC

Brian,

I agree with you that there is a basic problem steming from
the shortage of programmers with time to work on ftp or
mailsystems. It is from this observation that some of us
abstract-data-type people wish to work within the context of
the current ftp and mail programs and thus are forced to use
the text of the message to represent the abstractions we
envision in the form of an ASCII string.  As a
compromise this string is readable by people, though ideally
it is processed by your local deabstractor (mail reading
program). As long as we have people who want info in the
headers for the mail reading programs to munch (such as my
plea for message-id's) and others who wish to readmail with
the type (or print) statement on a slow terminal we are going
to have strong feelings about the size of headers.

Date: 28 AUG 1977 2200-PDT
Sender: STEFFERUD at USC-ISI
Subject: Re: Pending availability of report on Unix message system
From: STEFFERUD at USC-ISI
To: DCROCKER
Cc: header-people at MIT-MC, 
Cc: Stef at KA
Message-ID: <[USC-ISI]28-AUG-77 22:00:27.STEFFERUD>
In-Reply-To: <[USC-ISI]25-AUG-77 16:42:18.DCROCKER>    

Hi Dave,

Just to close the loop, please sned my copy to

Einar Stefferud
Network Management Associates, Inc.
17301 Drey Lane
Huntington Beach, CA 92647
-------   

Date:     29 Aug 1977 0140-EDT
From:     Brian Reid at CMU-10A
Reply-To: Header-People at MIT-MC
Subject:  once more, with feeling.
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 29 Aug 1977 01:40:55 Brian Reid
In-Reply-To: MRC's message of August 26, 1977

Louis Armstrong was once asked by a reporter, "What is jazz?" He is
reputed to have answered, "If you gotta ask, you ain't never gonna
understand anyhow."
-------

Date: 29 AUG 1977 1242-PDT
Sender: DCROCKER at USC-ISI
Subject: Social Statistic of Computer-based Human Communication
From: DCROCKER at USC-ISI
To: Header-People at MIT-MC, [ISI]<MsgGroup>Mailing.List:  
Message-ID: <[USC-ISI]29-AUG-77 12:42:58.DCROCKER>   

Last Thrusday evening, at about 5pm Pacific time, I sent a note
to approximately 130 people around the country.  The response
statistics are, to me, a little scary:

Even though I sent the note at the end of the day, I had 7
responses within 90 minutes ((6 west-coasters and one
mid-westerner).  Within 24 hours, I had received 28 responses, or
approximately 20 per cent of the people I polled.

This sort of two-way connectivity is incredible.  Since I know of
no other hard data on the subject, I thought you might like to
have the above available for citing.

Dave.
------- 

From:  Pogran.CompNet at MIT-Multics
Date:  08/29/77 1149-edt
Subject:  A precedent for setting protocol changeover dates
To:  BH at SU-AI
cc:  Header-People at MIT-MC

Brian,

Believe it or not, there IS a precedent in the ARPANET for
establishing a date by which everyone is REQUIRED to conform.
It's New TELNET.  The original "release" of the New TELNET
document, RFC 495, NIC 15371, by Alex McKenzie, dated 1 May 1973,
indicates that by 1 July 1973 all sites should be able to accept,
without generating error responses, the New TELNET control codes
(IAC XXX), and that by 1 January 1974 everyone should have
implemented New TELNET and sites need not support Old TELNET any
longer.

Of course, those dates weren't met.  Some sites still complain
when sent New TELNET controls over an Old TELNET connection;
most likely, some sites still don't implement New TELNET.  The
point is, though, that the CONCEPT of "required" dates of
implementation is not new to 724 -- and the authors of 724, the
rest of CAHCOM, and Steve Walker of ARPA were all well aware of this
when it was first brought up in the context of 724.

Regards,
 Ken

Date:     11 Aug 1977 1347-EDT
Reply-To: Header-People at MIT-MC
Subject:  Re: Leaving things as they are
To:       MRC at SU-AI (Mark Crispin)
CC:       Header-People@MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A] 11 Aug 1977 13:47:21 Philip Karlton
In-Reply-To: MRC's message of August 10, 1977

The problem with leaving things as they is that different sites have
different conventions concerning the format of items that programs
are currently trying to parse.  (If you want some examples, here are
2:  One site puts no "," at the end of each line of an address list
that is continued on the next line; some sites (programs) insist that
embedded blanks in names should be thrown away and at least one site
uses both first and last names (separated by a space) to disambiguate
addresees for delivery.)

RFC 724 is, at least as far as I understand it, an attempt to make a
standard syntax and semantics for all the things that people are
sticking into their mail headers already.  I think that the authors
have bent over backwards to allow almost all of the things that mail
creating programs are currently doing.  Why else would they choose to
allow both the type of date given in the header of this message and
"slash" dates which are ambiguous if a European is reading the
letter?

I do not know what it is specifically that you object to in RFC 724.
If you had the authority would you just disallow all but a few items
in the header?  DO you not think a standard syntax and semantics for
those items in headers likely to be parsed by programs is desirable?
My apologies; I should not get facetious.  I expect that your answers
to these particular questions are the same as mine.  Do you have some
concrete suggestions for changes to RFC 724?

			Phil Karlton
-------



                                

Date: 29 Aug 1977 1500-PDT
From: ME at SU-AI (Martin Frost)
Subject: Slow loop in net mail?
To:   header-people at MIT-MC    

Why is Philip Karlton's message of 11 Aug 77 making the rounds again?

-------

Date: 29 AUG 1977 2114-EDT
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Slow loop?
To: HEADER-PEOPLE at MIT-MC

According to the stats, that odd repeat message from Karlton to MRC
arrived from CMU-A about 17:51:31 today (29 Aug).  As to why and
how, I think the CMU people will have to answer that.

Date:     29 Aug 1977 2131-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: Slow loop?
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 29 Aug 1977 21:31:48 Brian Reid
In-Reply-To: KLH's message of August 29, 1977

As many of you have probably noticed, the CMU mail system has been
having its ups and downs lately.  Philip Karlton asked me to comment
on his message of 11 August, and upon checking my message file, I
found no such message.  We had no way between us of telling whether
it had not ever gone out, or whether it had gone out but just nobody
at CMU received it.  So, I suspect, he shoved it out again.  Sigh.
Sorry about whatever part I had in this mixup.

		yours for a junk-mail-free network,
				Brian
-------

Date: 29 Aug 1977 2158-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Slow loop
To:   Reid at CMU-10A
CC:   Header-People at MIT-MC 

A touch of humor; since CMU apparently was guilty of the previous loop (so
I was told anyway):

Maybe if CMU concentrating on making their mailer WORK they wouldn't be so
fired up on making their headers so hairy.  For example, Brian's last
message told me that he, Brian Reid, sent the message; THREE times.  It also
included the date of sending, TWICE.  I've also noticed that some CMU mail
has no "From:" field.  C'mon, CMU'ers, you can do better than that!

In response to BH's comments earlier; ok, I admit to my everlasting shame that
I am not one of the mandarins with a secretary, and actually type my
mail myself, with my own 10 (or 9 right now) fingers.  So, if we are going to be
hairy, as it seems is going to happen in spite of everything, why don't we
require as part of 724 that we have a list of everybody on the ARPAnet (the
NIC directory is a good start), and whether or not they have a secretary.
Every host will have to have this list, as with the host tables, and maintain
it.  People who are not privileged to have secretaries are not privileged to get
long mail with hairy headers.  THEN EVERYBODY WILL BE HAPPY!

Btw, as the author of ITS user TELNET (a new TELNET protocol program), yes,
indeed many hosts do not implement it, although that situation is not nearly as
bad as with new FTP, which shall stand as a monument to human time-wasting.  Not
that HEADER-PEOPLE is far behind; we're sure to win in the long run.

-------

Date: 30 Aug 1977 at 1529-PDT
Subject: Host reference, in a multi-net environment
From: Dcrocker at Rand-Unix
To: header-people at Mit-Mc
cc: Postel at Isib, Sunshine at Isd, Dcrocker at Rand-Unix
Message-ID: <[Rand-Unix]30-Aug-77 15:29:26.Dcrocker>

     The following represents my current thinking with regards to
referencing specific hosts which are part of a multi-net
environment.  I would appreciate comments.

     Carl Sunshine(1) distinguished between "source" (relative)
and "global" (absolute?) path names.  Relative pathnames will get
the message from the current location to the destination.
However, when the pathname is recorded as data in a message and
the message later migrates around to other places, the context
which explains the pathname is lost.  For example, "go down the
hall and turn left, stopping at the first door on the right" is
great if you start from my office, but terrible if you are in
Boston.

     Since we are expecting hosts to come and go with much
(ir-)regularity and we are specifically not willing to have all
hosts know about all other hosts (that have ever existed???),
then we cannot use simple global names.

     If we could predict a tree (approximately) of networks,
rather than a full and messy network of networks, then we could
use the solution employed by Unix, Multics and others for their
file systems: A pathname which begins at the root node and works
down.  This would uniquely identify hosts, allowing each node to
process that part of the address which is knows about.  (Postel
has pointed out, however, that it doesn't begin to help you
figure out how to actually route the message, since routing
everything according to its absolute path guarantees that you do
not take advantage of any short-cuts in the system; here, I am
concerned with specifying the address in a context-independent
manner, and not with optimally using the address specification.
Unfortunately, the claim is that we will really have full network
structuring.

     Having said that, I will now suggest that we will really
have a more tree-flavored situation, with a top-level of networks
that will be as dominant and continuing as countries, and
therefore will recommend using Jon Postel's suggestion(2).  That
is, I suspect that we will have a relatively few international
networks which represent the root (more like a ring) of the
"tree" and which WILL know about each other (tho not necessarily
know about each other's constituent hosts) and that it is
reasonable to expect the constituents to know what international
net they are part of.  This latter requirement is necessary so
that hosts can take a pathname which references the root network
and do something reasonable with it, like send it to a node which
is the gateway to the international system.

        Specifically, I suggest that when the data of a message
contain a host reference outside of the local net that the FULL
pathname always be used.  Within Postel's scheme, this would
require that the text always begin with "NET" (or "INET", since
we need to distinguish between local nets and larger
international nets).  This is tantamount to requiring that all
mail which goes out of the city must include country, as well as
state, indication.  For the purposes of computer mail, I think
the requirement is reasonable.

        Postel used keywords to indicate the level of
specification.  For mail usage, we need only distinguish between
simple local references and full global paths.  Postel suggests
slash ("/") as the field separator, so it seems reasonable to
merely have a beginning slash indicate root-references quite
easy.  Ergo, my Rand address might be: /Arpa/Rand/Unix-70A.  (And
I apologize profusely for the fact that this coincidentally is
the way Unix does it.) I am not thrilled with the aesthetics of
slash, but it works; most alternative graphic characters might
not be noticed at the beginning of a string.

        The above is mostly intended to stimulate some responses
from y'all.  Please let me know of alternate approaches and/or
minor variations you recommend.


(1) Sunshine, C. Source routine in computer networks.  Computer
Communication Review, Vol. 7 No. 1 1977, pp. 29-33.

(2) Postel, J.  Extensible field addressing.  Arpanet RFC 730.
20 May 1977.

MRC@MIT-AI 08/31/77 02:24:54 Re: Inter-network mail; response to proposal from DCrocker
As the implementor of DIALnet, I would prefer that the inter-network mail
protocol be as simple as possible.  If a hairy protocol results in spite
of my efforts that appears to be more than most DIALnet sites will be
willing to implement (as hair on the level of 724 is), I shall ignore it
and establish a private protocol to be used by DIALnet and cooperating
ARPAnet sites; there are precedents for ignoring the official protocols
and hopefully the message-entity people will be willing to see other's
points of view in this matter.

I would prefer that the official mail protocols do the right thing to begin
with.

Now that I have gotten that off my chest, let me present my suggestion:

Inter-network mail is specified by a pathname which contains the destination
address IN THE OTHER NETWORK'S FORMAT, delimited by parentheses, with
quoting applied in the possible but unlikely case of unbalancedness.  In
the event of multi-network forwarding, cooperation between the networks in
doing this is encouraged.  By this, I mean the following:  take the example
of a message being sent to FOO-SECURITY, which is on the FOOnet.  There are
no connections between the ARPAnet and the FOOnet, but the BARnet is
connected to the ARPAnet at host BAR-AI and to the FOOnet at host FOO-DMS.
The message is to go to user Fred Foobar at FOO-SECURITY, and the FOOnet
uses mail formats of an arrow made of dashes and a greater than sign for
destination.

The pathname is built additively:

1.  FOO-SECURITY --> Fred Foobar				(initial)

2.  (FOO-SECURITY --> Fred Foobar) @ FOOnet

3.  ((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS

4.  (((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS) @ BARnet

5.  ((((FOO-SECURITY --> Fred Foobar) @ FOOnet) @ FOO-DMS) @ BARnet) @ BAR-AI

The last pathname is the ARPAnet pathname.  Each level strips off the
parentheses to derive its next path.  No processing is done to the innter
levels.  And, none of this appears in the message header.

The use of at-signs was to provide some consistency and to establish a
universal convention.  It is quite reasonable that at-signs be used for
each level of the path including the innermost; it is certainly a reasonable
character to use.

The example presented was picked as a hairy example.  In practice, I would
expect that they be much simpler.  The basic idea behind off of this is
that a host gets the path with the CAR being the pathname to which it should
send the message, and the CDR being its own ID.  The pathname, if atomic,
means it should stop there.  If non-atomic, it means further forwarding,
the CAR being the next pathname, the CDR being the destination.  If the
destination is a network rather than a host name, the message is passed next
to the host's own NCP for the other network, whcih then does similar sorts
of processing.

Note that there is no protection offered against a malicious or idiotic
pathname specification.  If a host feels it is in danger of such, it is its
responsibility to protect itself against this.  Any such "protection" should
not prevent normal nesting.


Date:     31 Aug 1977 1434-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re the CAR/CDR addresses
To:       mrc@mit-ai
CC:       Header-People@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 31 Aug 1977 14:34:22 Rick Gumpertz
In-Reply-To: Your message of August 31, 1977

In your example the paths were always left associative.  Therefore, why have
the parens at all??  @ can still be quoted in some manner if necessary.
Thus your example becomes:

FOO-SECURITY --> Fred Foobar @ FOOnet @ FOO-DMS @ BARnet @ BAR-AI

Admittedly this might be a bit more restrictive in how names are constructed,
but really not very much so.

		Rick
-------

Date: 31 Aug 1977 1517-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

Actually, for consistency I would recommend this form, simply assigning
@'s as THE delimiter.

Fred Foobar @ FOO-SECURITY @ FOOnet @ FOO-DMS @ BARnet @ BAR-AI

I selected parentheses, however, since it would be too open to
ambiguities; LISP-type CAR and CDR forms are much easier for programs
to parse and snarf off the information (in my opinion of course).  It
is also my dislike for APL-style thinking; I think the parens make it
better for use faulty humans to parse as well.

My intention is that Fred only sees his actual address, Fred Foobar @
FOO-SECURITY, and not the whole hairy path.  Also I postulated this
example as being quite hairy and unlikely in practise.  What I consider
more likely is something like a message being sent to a DIALnet user
from the nearest ARPAnet site that supports DIALnet as well; this
might mean something like a message going to me at Stanford LOTS looking
like:

((MRC @ SU-LOTS) @ DIALnet) @ SU-AI

This assumes that SU-AI knows SU-LOTS's DIALnet phone number (it will,
of course).  You can add some more smarts; assume SU-AI knows that it
has to use DIALnet to go to LOTS (it will).  The address can be made
even simpler by using:

(MRC @ SU-LOTS) @ SU-AI

and the simpler, the better.

	Peace,
	   Mark

-------

Date:     31 Aug 1977 1821-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: Re the CAR/CDR addresses
To:       RICK.GUMPERTZ at CMU-10A
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 31 Aug 1977 18:21:41 Brian Reid
In-Reply-To: [CMU-10A] 31 Aug 1977 14:34:22 Rick Gumpertz

Just throw quotes around any address that doesn't parse as an
identifier:

FOO-SECURITY-->Fred Foobar @ "Foo\\Net" @ Foo-DMS etc etc etc.

The CAR/CDR notation is at best difficult to read, and it is slightly
surprising to see something so ornate coming from the strongest
proponent of simplified and human-readable headers.

		Brian
-------

Date: 31 Aug 1977 1537-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: To paren or not to paren, that is the question
To:   Header-People at MIT-MC    

The problem with not paren-ing is that you can introduce ambiguities; I called
the notation CAR/CDR ala LISP, but I was also sort of expressing it in
FORTRANese, using @ as an operator.

It is also my intent that humans see little of this; I expect that this does
not show up in the message header.

-------

Date:     31 Aug 1977 2113-EDT
From:     Brian Reid at CMU-10A
Reply-To: Header-People at MIT-MC
Subject:  Parenthesized fields that the user never sees
To:       Header-People@MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 31 Aug 1977 21:13:56 Brian Reid
In-Reply-To: MRC's message of August 31, 1977

I see.
Well, I'll tell you what:
Please take this enchanted place that users will never see and that
is not a message header, and put my Message-ID and Sender and
Reply-to fields in that box.  Then we'll both be happy:  I will get
all of my header fields, and you won't have to look at them.
-------

Date: 31 Aug 1977 2056-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: magic place
To:   Header-People at MIT-MC    

Better yet, limit mail headers to "Date:", "From:", "Subject:", and (only
in the case of multiple recepients) "To:"; and sites that like such hairy
stuff can have their mail server add them on!

I'm sorry, Brian, but I feel that a Date/From specification, especially when
the time is reported to the second (on the sender's computer's time, which of
course has no relation to real time) is enough to uniquely identify a message;
and that your own mail server or reader can add that stuff on!  Since mail
can be forged anyway, I think having a From: field being merely who the sender
alleges to be and where replies should go is enough.

Of course, those people with secretaries want to show off that they have a
secretary, so they want that "information" in the header.  I wonder how the
secretary feels on the subject; perhaps if s/he knew that his/her name
appearing in the header was considered junk by a non-trivial portion of the
ARPAnet community s/he would prefer anonyminity!

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     1 September 1977 0015-edt
Subject:  The umpteenth time.
Message-ID:  [MIT-Multics]1.2.BBBJGlWXmZPcpM
To:       mrc at SU-AI
cc:       header-people at MIT-MC

A second is a very very very very long time.  About a
million operations on your average run of the mill computer
sytem.

Date: 31 Aug 1977 2114-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: seconds
To:   Header-People at MIT-MC    

C'mon, Bob.  A computer may do a million operations a second or whatever,
but we humans can't.  My point stands that the info in the From and Date
fields are enough to uniquely identify a message.

-------

DLW@MIT-AI 09/01/77 00:26:49 Re: Relevancy.
To: MRC@SUAI at MIT-AI, Header-People at MIT-MC
In reply to your suggestion:
    Better yet, limit mail headers to "Date:", "From:", "Subject:", and (only
    in the case of multiple recepients) "To:"; and sites that like such hairy
    stuff can have their mail server add them on!
There are 130 blocks of text which have been sent to the Header-People
mailing list.  You are welcome to read them at your leisure if you want
an explanation of why there must be more fields than these.  There has been
a GREAT deal of discussion already and this suggestion completely ignores
all that has gone before.  The minutes can be found on MIT-MC's KSC directory,
and I, for one, read through all of them before attempting to add my own
comments; if you do the same you will know why more fields are important.


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     1 September 1977 0031-edt
Message-ID:  [MIT-Multics]1.2.BBBJGlWZhdCBLg
To:       dlw at MIT-MC
Cc:       header-people at MIT-MC

Thank you.

PS: One of your ill formated headers just escaped.

Date:     1 Sep 1977 0114-EDT
From:     Brian Reid at CMU-10A
Subject:  Re:
To:	
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  1 Sep 1977 01:14:11 Brian Reid
In-Reply-To: Your message of September 1, 1977

Who is DLW@MIT-AI?
-------
                             

					4613 Filmore St.
					Pittsburgh, PA  15213
					1 September, 1977

					In reply refer to: 0901301B


Mr. Mark Crispin
807 Laurel Ave.
Menlo Park, CA  94025

Dear Mr. Crispin:

I don't have a secretary, and I probably don't ever want one, as I
feel confident that with a video terminal and a good editor (neither
of which I have here with my DECwriter) I can get mail out faster by
typing it in myself, but I still feel that some of the header fields
will benefit me.

For many years, business concerns who care about reliability and
efficiency have used the equivalent of the Message-ID field in their
correspondence.  True, we in the academic world don't need the
precision so vital to business correspondence, for it is not commerce
but flakey ideas that our mail promotes.  Perhaps it is unfortunate
that the explanation in RFC724 of the "Sender:" field used the
secretary example, and perhaps it is unfortunate that early
implementations of 724-like headers (CMU's, for instance) did not
take the trouble to strip out the Sender field when it was equal to
the From field.  But this shouldn't mean that these fields are bad,
only that they are currently being misused.

And just think: even as you can look at my computer mail to you and
find out that it says "Brian Reid" in 3 different places, you can
also look at the "inside address" of this letter to find out where
you live.  O, the world is full of redundancy.



					Sincerely,

					   X (his mark)

					Brian K. Reid

Date: 1 SEP 1977 0257-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: In further reply to your message of 2056-PDT
To: MRC at SU-AI, HEADER-PEOPLE at MIT-MC


about your letter: its subject is "magic place", and yet it does not
address itself to Brian Reid's question, which I will repeat:  Where is this
magic place?  Wherever it is, I want to put Message IDs there.
  I will also take this opportunity to mention that my first message
to header-people proposed a very cheapo implementation of the "magic
place" which would be attained by having mail receivers do a very trivial
header parse.  I still think this was a good idea, what do people think
about adding it to RFC724?

P.S.  Sorry that I let an ITS internal header out.  This happened because
I sent the mail to "HEADER-PEOPLE at MIT-MC" from MIT-AI.  As far as the
MIT-AI mailer was concerned, HEADER-PEOPLE is a simple recipient at an ITS host,
and so the mail should be given an ITS header.  The right way to fix this
would be for MIT-MC to parse the incoming header and fix it up.  This is
yet another example of why it is important for mail headers to be parseable.

P.P.S One reason that the date/time is not sufficient as a Message-ID is that
PROGRAMS can generate and send mail very quickly.  This was mentioned
very early in the Header-People discussion; as I pointed out, you should
read what has gone before and stop wasting everyone's time with repetitions.


Date: 1 Sep 1977 0003-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: magic place
To:   DLW at MIT-AI
CC:   Header-People at MIT-MC   

Dan, you were inattentive to my message.  Perhaps I generated too much text
and obscured my point.  You would have noticed that I mentioned that mail
service programs could do the header parse.

In fact, SAIL's mail server does that; it parses the ARPAnet header as well
as it can and puts a SAIL-style header at the beginning of the mail that it
puts in the mail file, making the ARPAnet headers almost useless (except for
the To:/Cc: lines which sometimes have a good reason to be there).

There is of course the problem of a malicious mail user sending mail with an
unparseable header; apparently to retaliate to an argument for smaller headers
as one reason.  A mail server should be prepared to flush randomness.

In any case, I think that something that the user SEES should not be bloated
by long headers.  I think most sensible people would agree it is silly to
receive a message with a (as once happened to me) 15 line mail header, and
0 (!!) line message text; my correspondent typed the whole body of her message
in a few words in the Subject: line!

If this stuff is included in a "no op" type FTP protocol message which servers
can ignore or use as they see fit, then perhaps everybody would be happy.  I
don't care how much garbage you want to send along with the message, just so
long as I don't have to see anything other than:
	date/time of message
	who sent it (valid arpanet address)
	one line subject
	(optional) other recepients of the message

-------

Date: 1 Sep 1977 0224-PDT
Sender: GEOFF at SRI-KA
Subject: Re: magic place
From: GEOFF at SRI-KA
To: MRC at SAIL
Cc: DLW at MIT-AI, Header-People at MIT-MC   
Message-ID: <[SRI-KA] 1-Sep-77 02:24:32.GEOFF>
In-Reply-To: Your message of September 1, 1977    

Mark, Your points are well taken, but it seems this is the day
and age where we are going to have to live with (many) message
headers to keep 'everyone' happy, and that the filtering of
headers is going to have to be on the readers end with his
message reading program.

HERMES is very well suited for this, since you can set up things
called TEMPLATES and see JUST what you want to see (or don't want
to see) in the order you want to see them.  I personally never
have the MESSAGE-ID and SENDER: fields printed out as a default
when reading my mail, but on occasion I have found it useful to
'see them' when I needed too.

Therefore, no matter how many ill-fated message headers you many
put in your message I am only going to see the ones I am
interested in.

Weither this filtering of message headers belongs in the FTP
protocol or in the users message reading program (like HERMES) is
debatable topic.

The main gripe I have toward for something like HERMES is that it
doesn't let me turn off sending the SENDER and MESSAGEID fields,
so i am sorry that those who don't have header filtering hack
that HERMES has to see them.

[Geoff]
-------    

Date:     1 Sep 1977 1243-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re CAR/CDR
To:       MRC at SU-AI (Mark Crispin)
CC:       Header-People@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A]  1 Sep 1977 12:43:18 Rick Gumpertz
In-Reply-To: Your message of August 31, 1977

But it can't really be that hard to search for the last @ which is not quoted
and split the string there, can it??

		Rick
-------

Date: 1 SEP 1977 1625-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: MRC at MIT-AI, reid at CMU-10A

I am not sure what Brian Reid thought he was going to prove with
his message sent in ordinary letter form.
Perhaps he is saying, "See, you have used bloated headers
all your life in US mail, and never objected, so how dare
you object to them in network mail".
To that, my reply is that US mail is transmitted on paper,
which medium provides much faster random access and much more
text visible at one time than any computer terminal I have ever seen.
There is no reason to expect that information which is marginally
useful on paper will remain at all desirable in a slower medium.

Of course, he might just have been saying, "US mail imposes bloated
headers on you, so why should I be any more considerate?".


                          

Date: 1 SEP 1977 1716-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: header-people at MIT-MC

If you are wondering why you got a message whose header stated that it was
from RMS@MIT-AI to MRC and REID@CMUA:  What happened is that RMS sent
the mail from MIT-AI at 16:25, and it was send off to MRC at MIT-AI
and REID at CMUA.  Then at 16:44, the MIT-MC mailer received the
same message from CMUA addresses to HEADER-PEOPLE.  So either the CMUA
mailer decided that the message was of interest to all of us
and sent it off, or Brian Reid sent it to everyone without any
additional header or warning.


Date:     1 Sep 1977 1720-EDT
From:     Brian Reid at CMU-10A
Subject:  3 guesses
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  1 Sep 1977 17:20:47 Brian Reid

The business world has through several thousand years of written
correspondence managed to evolve a fairly efficient and fairly
uniform scheme for written communication.  There is a very good
reason for every part of a business letter.  Perhaps a bunch of
hackers and graduate students can't see, from their vantage point,
what the utility might be.  And from current usage of the ARPAnet, as
a toy for overprivileged CS students and systems hackers, there
probably isn't a reason.  But while we all sit in our packet-switched
playpen and talk about whether or not graduate students and hackers
need message-id fields on their correspondence, there are people out
there who need networks, either this one or others like it, for real
commercial and military correspondence.  It is to the needs of real
people doing real correspondence, and not just to our own toy needs,
that RFC724 is addressed.

-------

Date:     1 Sep 1977 1724-EDT
From:     Brian Reid at CMU-10A
Subject:  header question
To:       DLW at MIT-AI (Daniel L. Weinreb)
CC:	  Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  1 Sep 1977 17:24:45 Brian Reid
In-Reply-To: Your message of September 1, 1977

Now if we had some tight header standards, we might be able to figure
this out.
Yes, I sent it to Header-People; I don't like private sub-discussions.
-------

Date:     1 Sep 1977 1724-EDT
From:     Brian Reid at CMU-10A
Subject:  header question
To:       DLW at MIT-AI (Daniel L. Weinreb)
CC:	  Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  1 Sep 1977 17:24:45 Brian Reid
In-Reply-To: Your message of September 1, 1977

Now if we had some tight header standards, we might be able to figure
this out.
Yes, I sent it to Header-People; I don't like private sub-discussions.
-------

Date: 1 Sep 1977 1507-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

 01-Sep-77  1436	FTP:    Brian Reid at CMU-10A	 header question    

Now if we had some tight header standards, we might be able to figure
this out.

	[MRC - What utter hypocracy!  You deliberately violate what is
	 considered courtesy under current mail standards, and you say
	 your discourtesy is due to people not being forced to be
	 courteous.]

Yes, I sent it to Header-People; I don't like private sub-discussions.

	[MRC - Yes, we must annoy other people with messages that the
	 message author considered either irrelevant to the whole group,
	 or discourteous to hassle everybody with a special interest
	 message, or had reasons for wanting the message to be off the
	 record.  Thank you, Brian, for showing us how to further stuff
	 our mailboxes with more garbage so that we can show off "see,
	 look how important I am; I get 60K of mail daily" -- all we have
	 to do is be discourteous.]

-------

-------

From:  Pogran.CompNet at MIT-Multics
Date:  09/01/77 1135-edt
Subject:  On "From", "Sender", and secretaries
To:  Header-People at MIT-MC

I'd like to respond to the recent discussion about "From", "Sender",
and secretaries.

In developing those parts of RFC 724, we (the authors) were responding to a need
expressed by some people using the "ARPANET Message Service" in a manner
similar to the "commercial" use described by Brian Reid.  To be sure,
that sort of use isn't very common among the members of Header-People;
systems programmers, graduate students, computer scientists, and
hackers (have I left anyone out?) AREN'T the sort of people, generally,
who would find a use for it, as Brian also points out in his letter
(0901301B).  But, over the LONG TERM, it's quite likely that there
will be a much larger number of commercial and military users of 724-compliant
Message Services who WILL find these features useful than
there will be  systems programmer, graduate student, computer scientist,
and hacker types!  So, we're trying to provide for an eventual broader spectrum
of user types than Header-People constitutes.  Please keep that in mind.

Regards,
 Ken Pogran

Date: 1 Sep 1977 2006-PDT
From: MRC at SU-AI (Brian McCune)
Subject: CMU hacker's habits
To:   Header-People at MIT-MC    

Why is it that CMU hackers, who argue for the most hairy headers, insist upon
sending mail without headers when they want to express irritation at people?
They also forward mail without any header of their own indicating who actually
sent the message on; which I believe can come under the heading of "falseified
(or forged) mail headers".

Thank you, CMU hackers, for providing such outstanding examples of maturity
that more weight is added to my arguments than I could have possibly have done
with all my attempts at exhorting the world towards common sense (or what is
common sense in my opinion).  (My apologies to my friends who are CMU hackers)

-------

Date: 1 Sep 1977 2012-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Mail about CMU hacker's habits
To:   Header-People at MIT-MC, BPM    

I don't know why, but SAIL suddenly confused BPM and me.  I haven't changed
my name or anything.

-------

Date:     2 Sep 1977 0224-EDT
From:     Brian Reid at CMU-10A
Subject:  since it seems to have come to this...
To:       MRC at SAIL
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  2 Sep 1977 02:24:09 Brian Reid

Your mother wears combat boots.
-------

						1 Sept. 1977
Dear Brian [Reid],
   I think the point you made in your business letter was well taken.
However, most informal correspondence is carried out with a minimal
amount of information as to who is writing to whom.  The recipient
knows very well who sent it from the first name signed at the bottom,
and has no need to repeat the address s/he has seen many times
before.  There is no need for all that formality.

			Sincerely,
			      Tovar

P.S.  My apologies to those people whose programs I have confused,
that is, those programs which remove all that verbage which I always
have to see.
 

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     2 September 1977 0252-edt
Subject:  Tovar
Message-ID:  [MIT-Multics]1.2.BBBJGlbLCClfkl
To:       header-people at MIT-MC

Who what or where (or why?) is a Tovar?

Date: 2 Sep 1977 0018-PDT
From: TVR at SU-AI (Tovar)
Subject: It is a free-for-all, isn't it?
To:   Header-people at MIT-MC    


To Frankston:
   Sorry, you type too fast.  My well addressed message was on it's
way.

Message-ID's
   For human written messages, i know of few people that can send more
that one per second and it is rare that more than one per minute are
sent.  Thus, for most purposes, the FROM, TO, DATE and SUBJECT should
be enough to disambiguate.
   Now, it has been suggested that programs which automatically send
messages can generate a large number per second.  I agree that they
can, and they can also put in message-ID, as an optional field. [Hey,
what a neat way of sorting out junk mail!]
   Thus, when a message is recieved, a message-ID is constructed as
the message is received and is replaced by an explicit one if such
is given.

Messages to other nets:
   This one can be handled simply as well.  Just allow anything in
front of '@' preceding the ARPANET sitename.  The recieving site
strips that off and if it is a portal into another net, looks at
it for external host specification and if one is found, hands it,
less the ARPA sitename, to that net's interface program.  Our
responsibility ends there.  We can hope that other nets will have
similar protocols and will find our headers of use to them, but
we shouldn't depend on it. (What is TO: in French, anyway?)
   Here's another can of worms:  What should we do about headers
send from other nets?

Full pathnames?
   How about something like a host list instead.  I doubt if we will
end up with more very many networks with the same name.  The list
consists of names and default short pathname.  Perhaps someone will
even volunteer to make a program to generate minimal travel time
pathnames for each network sites.

So you want all these hairy headers?
   Well, perhaps putting this stuff as part of the FTP sequence for
mailing might not that horrible an idea.  By the way, what ever
happened to the envelope idea that was kicking arould a while
back (while we resurrecting old ghosts).

"What is jass?"
   You have to learn sometime; but a "master" won't tell you.  By
the way, insults will rarely get you anywhere, especially with MRC.
Now come on, kids.  Army boots?


I'm sure everyone's got there guns out by now so enjoy shooting
this all down.

			Tovar
			(TVR @ SU-AI)

-------

From:     Frankston.ECDports (Robert M. Frankston)
Date:     2 September 1977 0325-edt
Subject:  replies to Tovar
Message-ID:  [MIT-Multics]1.2.BBBJGlbMpLfghb
To:       header-people at mit-mc

1. Please note that my secretary is not human.  It is (obviously)
a machine.

2. Wouldn't it simplify the world if there were  a  standard  for
generating  message-id's without having to go through complicated
algorithms that would have to exist in all  reading  and  sending
programs.

3. anyway, how is the sender supposed to know that it is  sending
a  message  for which the id will be ambiguouis and result in the
letter being automatically discarded.  Obviously you consider the
human originated mail to be discardable junk.

4. Agree that pathnames obey principle of parsing the known  part
and just passing the rest on to the next level.

5. Seeing examples of foreign use of programming  languages,  one
can  expect the keywords of the mailsystem to be kept in English.
It is likely that French will be a special case  and  the  French
words may be accepted as alternates (particularly in Quebec).

6. The FTP and envelope  ideas  go  around  and  around  and  are
basically  reasonable.  However, in keeping with the principle of
least change to existing cruft, you can, if you wish consider the
hairy header to be simply part of the ftp or  envelope  protocols
that  leaked  through.   That  is  basically what is meant by the
abstract representation view.  Just because it  is  part  of  the
same ascii string as the rest of the letter does not mean it need
be considered as such.

Date: 2 SEP 1977 0346-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: HEADER-PEOPLE at MIT-MC


as I keep saying, that little suggestion I made about
a trivial header parser would solve this messaged ID
problem.  We are all spending much too much of our
time on this one silly issue about "I want those useful
fields" versus "I don't want to see those ugly
fields", and this trivially solves it.  As far as I can
see it would make everybody happy, and no one has objected
to it as yet.  Maybe putting the stuff into FTP is conceptually
nicer, but you know as well as I that this network has not
even implemented a years-old "new" FTP and the chances
that we can convince every host to put in all this mail
stuff is negligible.


Date: 3 Sep 1977 0942-PDT
From: TVR at SU-AI (Tovar)
Subject: One more time, with feeling
To:   RMF at MIT-MC, Header-people at MIT-MC    

Construction of local message-IDs
   I guess I wasn't clear enough about what I was suggesting.  I was
suggesting that for 98% of message traffic, the message-ID could be
calculated by the recieving site, if desired, from the DATE, the
FROM, the TO, and the SUBJECT entries.  I think that most of us are
capable of creating hashing functions, but if you want, you can concatenate
these fields.
   I'm sorry about that junk mail comment as it was definitely out of place.
However, I think we can avoid discarding non-duplicate messages using the
scheme above (considering the probability of a human sending more than
one message per second to the same people with the same subject).  If anyone
doubts this, they can include the length of the text in their hashing
function.

Yes, but we can write filtering programs at each site to flush headers...
   Are you volunteering?  I ask that because changes to things like the
mail programs are often only done by volunteers.

There are objections
   And I am not the only one.  I have also observed that there are a
few, good men [/women] fighting for the long headers.  But how much
support is there for them?
   I am not suggesting that we abandon all those wonderful fields.  I
agree that they all have uses, some of the time.  I am suggesting that a
minimal set be used as a default with the addition of others as requested.
   Let's not use the full, bloody header for informal communication.

One, small request?
   Could we ask that headers not contain redundant information, like
FROM and SENDER as the same person?

						--- Tovar

-------

Date: 3 Sep 1977 1707-PDT
From: BH at SU-AI (Brian Harvey)
To:   header-people at MIT-MC    

I suggest that the committee issue an official document to the effect that
redundant header entries (e.g., equal From and Sender) and message-id not
be allowed unless explicitly requested by the sending human being, and that
everybody then shut up.  This is getting boring.

By the way, somewhere in there somebody (I forget who) at Multix sent out
a message with a From field not containing his host name, so if I had had
a spiffy automatic reply program it wouldn't have found him.

A sociological aside: no doubt it is partly the thought of all that
important military mail which is causing all this heat.  I certainly
feel that anything I can do to sabotage the U.S. war machine is a
patriotic duty, and I imagine many of the rest of us hackers feel likewise.
Or, how dare those outsider warmongers hair up OUR nice simple mail
protocol for THEIR nefarious correspondence?

Indeed, the argument against putting the header stuff in new FTP commands
cuts both ways since mail readers aren't any easier to modify.  (Harder
in fact since it is much easier for me simply to add a bunch of no-ops
to my FTP server than to write a parser for my mail reader.  But I don't
think anyone would mind seeing those fields in those cases where they
really added some information.

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     3 September 1977 2232-edt
Subject:  Missing "At Multics"
Message-ID:  [MIT-Multics]1.2.BBBJGlgnXNPjjm
To:       header-people at MIT-MC

sorry about that, the local mail sending program attepts to
give a shorter header for local mail, but I changed to a
network destination after the header was composed. So much
for filtering at the source end. I also got Tovar's message
twice, but the redundancy was not caught by my receiver do
to the lack of message id {please don't reply to that
remark, I handle message-id's and would appreciate those
sending mail to me to use it}.  

Date: 3 Sep 1977 1953-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Message ID catching
To:   Header-People at MIT-MC    

Just what do you do to prevent two different pieces of mail getting having a
message flushed because they happen to have the same message ID?

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     3 September 1977 2258-edt
Subject:  message id
Message-ID:  [MIT-Multics]1.2.BBBJGlgpqfCCZL
To:       mrc at SU-AI, mrc at SU-AI
To:       header-people at MIT-MC

It is with deep embarassement that I answer MRC's letter.
The technology exists to generate unique ID's.  Why do you
think that I generate such an ooxious message id!!! It is
better than giving you the number of microseconds since
January 1, 1901 GMT in decimal.  An the host name uniquizes
the ID so that another host won't be able to generate the
same one.    In general a unqiue ID can be generated by
concatenating a generator id with a number guaranteed by
that genearator to be unique. A simple counter is
sufficient.  Uniqueness among generator's is guaranteed by a
central registry, in this case, the arpa-net host table.

Unique id's are a very fundamental concept and all this
hassling about message-id's seems to be generated by a lack
of appreciation of the universailty (and if I may be
permitted a little exageration) the fundamentalness of this
concept!  I want the message id in the header because it is
the basic concept that can be used to manage messages.

Date: 3 Sep 1977 2043-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

RMF ignores totally the problem of malicious hosts, FTP servers, or
other network saboteurs mangling the message ID.  That is why I do
not trust computer programs to censor my mail.

-------

Date:  3 Sep 1977 2059-PDT
From: Su-Ai at SRI-KL
Subject: Message-ID, yet another time
To:   RMF at AI
cc:   Header-people at MC

Why is it not sufficient to use the DATE, FROM, TO, SUBJECT and
a hashing of the message text (i.e. what's after the header) to
determine duplications?

				--- Tovar

P.S. I hope you weren't responsible for Multics' Message-ID as they
are about the most cretinous looking thing i've seen in years!
-------

From:     MRC at SU-AI (Mark Crispin)
Date:     4 September 1776 0118-edt
Subject:   Malicious? Who me?
Message-ID:  [SU-AI]1.2.BBBJGlhFjQbXbH
To:       header-people at MIT-MC

A Sail/ITS person really claiming to care and/or cope with
malicious users.?

So what?

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 0124-edt
Subject:  apologies
Message-ID:  [MIT-Multics]1.2.BBBJGlhGCMzLxk
To:       header-people at MIT-MC

I apologize to those to whom I have just sent some junk mail
and am tempted in the future to use a more restricted list
for such "proof by scenario"s and also apologize for giving
in to temptation and frustration.

Date: 3 Sep 1977 2224-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

[MRC - I did not send this message.  This message is a a clear example of the
 sort of forgery that I am talking about.  Since from the crufty characteristics
 of the header it is obviously from Multics, it is obvious who the child was that
 sent it.]

 03-Sep-77  2219	FTP:    MRC at SU-AI (Mark Crispin)	  Malicious? Who me?    
From:     MRC at SU-AI (Mark Crispin)
Date:     4 September 1776 0118-edt
Subject:   Malicious? Who me?
Message-ID:  [SU-AI]1.2.BBBJGlhFjQbXbH
To:       header-people at MIT-MC

A Sail/ITS person really claiming to care and/or cope with
malicious users.?

So what?

-------

Sender:   Frankston at MIT-Multics (Robert M.Frankston)
Via:      The playground.
Date:     4 September 1977 0131-edt
Subject:  Lesson for today
Message-ID:  [MIT-Multics]1.2.BBBJGlhGWMnHkP
To:       header-people at MIT-MC

All I was trying to show was that your comment on
maliciousness was totally irrelevent (sp?) to the discussion
of message id's.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 0123-edt
To:       header-people at MIT-MC

Letter 3

Date: 3 Sep 1977 2238-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

 03-Sep-77  2223	FTP:    Frankston at MIT-Multics (Robert M. Frankston)	 apologies

I apologize to those to whom I have just sent some junk mail

[MRC - Your apology is NOT accepted.  I think you have adequately
 demonstrated, between you and "Army boots", that you are totally
 intolerant of any opinions other than your own.  Your only point
 is "If I don't get my own way I am going to call the people who
 disagree with me nasty names and send garbage mail and then accuse
 them of doing that to confuse them more."
 I have gotten to the point where I almost do not care any more.
 ARPAnet mail is soon going to be useless and worse than useless,
 and eventually nobody is going to use it.  It is a shame; since
 mailing was once a useful facility.  I guess I'll have to roll
 back to US mail, since my attempt to establish a private mail
 protocol met in evident failure.]

...apologize for giving :n to temptation and frustration.
[MRC - I was on the verge of sending a very nasty reply to one of
 your earlier messages but thought better of it since all you would
 do is send a computer equivalent of giving the finger.  In your
 world, it is perfectly alright to send as many nasty things as you
 want without respect to other's opinions and feelings, but you
 forbid others to have their own thoughts.  This is a classic case
 of bureaucratitis.]

-------

Date: 4 SEP 1977 0144-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

I think the idea that the message ID DEFAULTS
to (STRING-APPEND sender date time hostname)
if there is no message-ID field
is a good one.  Mail senders could omit the
explicit message-ID field when they were sure that
the default one would be unique.  Any program that
was afraid it would send messages so fast that they
would have identical default message IDs could either
determine when that happened and give the nearly simultaneous
messages explicit IDs, or just put explicit IDs in
all messages it sends.  But a human sending mail
will know that the default is good enough, and not put
in an explicit field.

I do not believe that RMF has any legitimate
reason to object to this.  If his mail reader simply
figures out the default message ID when there is no
explicit field, it will provide him with just as much
service with this scheme as it now does with mandatory
message IDs.  And 99% of all messages would cease to have
one field that USUALLY conveys no added information.

In fact, rather than exhorting us all to send message ID
fields, RMF should just implement this feature in his
own mail reader and then he will have the benefit of
message IDs even in messages we continue to send
which lack the field.  I am sure he would obtain much
more satisfaction this way than he will from his exhortations.
RMF can safely implement this on his own because there
is no reason for us to standardize on exactly HOW
the default message ID is built out of the sender, date,
time and host name, as long as a given host always does
it the same way and never loses any of the information,
and never considers an explicit message ID to match an
implicit one.



From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 0123-edt
To:       header-people at MIT-MC

Letter 2

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 0123-edt
Message-ID:  [MIT-Multics]1.2.BBBJGlhFxzGdlN
To:       header-people at MIT-MC

Letter 1

Date: 4 SEP 1977 0405-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

So what do people think of KLH's new formulation of 724 syntax?
Has everyone read it?
I myself think it is a vast improvement over the BNF.


Date: 4 SEP 1977 1202-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Congratulations to Mark and Bob for solving the alleged "header problem"
To: HEADER-PEOPLE at MIT-MC

The problem of large headers consisting of mostly useless information,
followed by 2 lines of useful text, has been replaced by the problem of
mailboxes consisting of large numbers of completely useless messages,
followed by 2 messages of interest.  I hope this isn't going to
be permanent.

Date: 4 SEP 1977 1106-PDT
Sender: DCROCKER at USC-ISI
Subject: Revised 724 syntax representation
From: DCROCKER at USC-ISI
To: Header-People at MIT-MC    
Message-ID: <[USC-ISI] 4-SEP-77 11:06:25.DCROCKER>   

This is not official -- little I ever say is -- but I believe we
will use KLH's suggestion, rather than pure BNF, for the final
form of the mail syntax specification.  Ken, I'd like to
enthusiastically thank you for offering it.  In the early days of
our work, I had been tempted to suggest an improved notation, but
gave in to our reactionary tendency to "keep things simple".  In
general, the public is only familiar (at some level) with bnf,
and not with improved versions of it.  And I do not think that an
augmented bnf solves all the problems.  It is still quite easy to
write convoluted and virtually incomprehensible rules; e.g., with
too much parenthisized nesting.

Also, I believe we should retain the lexical analyzer as distinct
from the main syntax.  The construct appears to be well-
intrenched in the language-processing world (I sampled three
Introduction-to-Compilers books.)  and I believe it makes the
primary syntax much cleaner.

Dave.
-------  

Date:     4 Sep 1977 1455-EDT
From:     PK01 at CMU-10A (Phil Karlton)
Reply-To: Header-People at MIT-MC
Subject:  The last week's mail
To:       Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A]  4 Sep 1977 14:55:38 Philip Karlton

I want to make a couple of comments about all the mail I have
received over the past week.  (Yes, it was quite a shock to have to
actually read all that mail after being camping in the quiet of the
mountains.)

I am another person who likes Ken's new formulation of 724 syntax.

Please, can everyone refrain from name calling for a while?

I must admit that I am one of those people who do not mind the long
headers.  There is information in them sometimes and I have found
that I can ignore the lines I have no interest in.  This is in
preface to my plea for people to please address themselves to the
issue which we should be discussing:  the explicit requirements and
suggestions of 724.  I would like to point out that at least one line
of header can be eliminated from CMU sites when RFC-724 is accepted.
Currently there are mail reading programs (at least I have been told
so) that look only for the "Sender" field and others that only look
for a "From" field.  Both of the mail generating programs here at CMU
generate both of these lines to try to please all the mail reading
programs.  The message-id was added because we were asked to add it.
It just does not take that long to have that line typed out and for a
person to ignore it.  Please do not forget DCrocker's message about
how little 724 really requires.  Are the "short-header" people
advocating removing the optional header lines from all mail?  Do the
"long-header" people want to make message-id's a requirement for all
mail?  Would it be a good idea if 724 gave more hints on when certain
fields would be a good idea or when they should be omitted?  Should
all mail reading programs give the sender the opportunity to edit the
headers at will?  Including allowing the sender to suppress the date
field?  I want to see what people think should be changed about 724
before it is accepted as a network standard.

I have rambled long enough.

                       Phil Karlton
-------

Date: 4 SEP 1977 1505-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

RMF has recently adopted my suggestion of generating
a default message ID from the sender, date-time, and host name
(and also the subject).

I think this means that we have an effective concensus on the issue:
it should be "standard" that, when there is no explicit message-ID
field, there is a default message ID which is composed of the
sender and date fields, in some standard way.
This provides all the utility of explicit message-ID
fields for those who have a use for them, without burdening others.
It should be required that an explicit message ID appear whenever
there is doubt that the default one will serve to identify the
message uniquely.

However, RMF pointed out a problem in that the date-time
in most network mail includes only the minute, not the second.
I agree that a human, even, might accidentally send two
messages within a minute.  Since intra-AIMLMC mail includes
the second, I had assumes wrongly that network mail did too.

This problem could be solved by including the second in the time field.
Of course, to the human reader that would usually be uninteresting
and therefore garbage.  But if we don't include it, then those
who benefit from message IDs have some cause for wanting explicit ones,
and those are an even larger amount of garbage.  I would think that
putting the second in the time is better than having to put in
an explicit message ID.  What do you think?


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 1910-edt
Subject:  correction
Message-ID:  [MIT-Multics]1.2.BBBJGljzdbQPgb
To:       header-people at MIT-MC

Though RMS points out that I have modified my program to
generate a message-id substitute, this was done under
protest and at the risk of losing multiple letters sent
within the same interval. While I won't go so far as to say
that a message-id should be reuired, I do feel that a system
that does not provide them is putting the burden of making
sure that two message don't happen to look similar and
threby be discarded, on the user when the task should be
performed by the system.

I confess to have gotten way off from RFC 724 central
issues, but do give in to temptations to duel.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 1927-edt
Subject:  and on and on
Classification: useless cruft
Message-ID:  [MIT-Multics]1.2.BBBJGlkBcxclFz
To:       header-people at MIT-MC

Oh yeah, I hate to keep reminding people but machines do
compose and send messages on their own, eaisily more than
one a second.  ok now?  {this was in reply to an internal
communication from RMS who refuses to generate message-id's
because he personally doesn't send more than one a second}

RMS@MIT-AI 09/04/77 19:35:34
I am sorry to have to bother all of you with this.
I sent my last message to RMF only because I thought I had
made my point clearly enough in Header-peope already.
But since RMF is still barfing about the fact that programs
can send messages faster than once a second,
I wish to point out once again that THAT is no reason why
a message sent by ME, who can't send more than one message per second,
ought to have a message ID.  Only a message sent by a program
which thinks it might send more than one message per second
needs to have an explicit message ID.


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 2001-edt
Subject:  army boots
Message-ID:  [MIT-Multics]1.2.BBBJGlkDWwGnKz
To:       header-people at MIT-MC

They'd be your messages I lose.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 2001-edt
Subject:  ignore last letter
Message-ID:  [MIT-Multics]1.2.BBBJGlkDZFqgKG
To:       header-people at MIT-MC

It was meant for RMS personally, no need to bother all you
good people with some inhouse cursing.

Date:  4 Sep 1977 1722-PDT
From: Klh at SRI-KL
Subject: Review and Preview
To:   Header-People at MC

   I want to thank Phil for sending that message, since it allows me to 
   cut the length of mine considerably.  I will, however, repeat one key
   sentence: "Please do not forget Dcrocker's message about how little 
   724 really requires".  All his questions are good ones.
   
   And there is one thing I need to add weight to.  I admit to having 
   waxed fanatical myself on occassion, but the recent exchanges have 
   gotten somewhat out of hand; it is time to bring them back.  I ask 
   that people not respond to seemingly provocative or insulting 
   messages, if indeed there is a reason for them, by sending similar 
   ones.  This serves no useful purpose and damages all participants 
   involved, as well as lowering the credibility of Header-People in 
   general to the point where no one will pay serious attention to the 
   genuinely valid points we raise.
   
   In a succeeding message I will include the complete list of 
   Header-People; this seems appropriate for a number of reasons.
   
   To those people who have asked: Yes, I do have a list of specific 724
   comments and suggestions, including the internetwork address ideas.  
   It is almost finished; I hope to send it before Tuesday.
   
   To those who may have lost their pointer to the new syntax: it can be
   found on MIT-MC as "KLH;NEWSYN >" and is slightly different from the 
   original.  For one thing, 724 specifies "Reply-To" whereas I had it 
   as "Reply To".  No one seems to have caught that, but I changed it 
   back; I hope there are no other variances from 724.  Once it is 
   agreed that the representation is correct, we can discuss 
   improvements to the syntax.

--Ken
-------

Date: 4 SEP 1977 2041-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: List of Header-People
To: Header-People at MIT-MC

Here is the complete Header-People mailing list, as inserted from the
file KSC;HEADER PEOPLE on MIT-MC.  The intent in mailing it is not
to distribute copies, but to show exactly what the group's composition
is.  The original purpose when I formed the group was to collect all
people directly involved in actual implementation of mail-related systems, to
encourage quick resolution of inter-site confusions.  I also felt that
such people would have the best ideas of the ease or difficulty of
implementing suggested features, and could truly stand behind any promises
of action.
  Be as that may.  Here's the list:
--------------------
	; This is the HEADER-PEOPLE mailing list, with comments
	; which may or may not be accurate.
(HEADER-MINS @MC)		; Record of messages -> File "KSC;HEADER MINS"
(DM-HEADER-PEOPLE @DM)		; COMSYS/MSGDMS (PDL, JFH, MSB)
(JHAVERTY @BBN-E)		; 'JFH@DM, TIRED OF GETTING MSGS THIRD! HAND"
(KLH @AI)(MOON @MC)(DLW @AI)	; COMSAT
(RMS @AI)(CBFX @MC)		; RMAIL, and that is cbfX dammit, not CBF.
(Postel @ISIB)			; Protocols
(Stefferud @Multics)		; MSGGROUP gateway (actually Stefferud@ISI)
(Farber @ISI)			; CAHCOM chairman (Message Services (sub)Committee)
(Farber @SRI-KL)		; wants two copies
(Henderson @BBN-A)		; HERMES, MSrvComm
(Vittal @BBN-A)			; MSG, MSrvComm
;(French @BBN-A)		; SNDMSG bug fixer
(DCrocker @ISI)			; MSrvComm
(Pogran @Multics)		; Multics mail, MSrvComm
(ME @SAIL) (BH @SAIL)		; SAIL mail
(Geoff @SRI-AI)			; SRI-AI mail, FTP
(AVS @LONDON)			; Illegal mail
(CRD @MC)			; Multics Read_mail
(Bajzek @CMUB)			; CMU mail, FTP
(Gumpertz @CMUA)		; CMU C.mmp
(PK01 @CMUA)			; CMU RDMAIL (Philip Karlton)
(Brian.Reid @CMUA)		; Interested CMU person
(AWH @AMES-67)			; AMES-67 mail
(Greep @RAND-UNIX)		; UNIX mail
(Mike @RAND-UNIX)		; He asked for it!
;(Mark @UCLA-ATS)		;   "  ----- commented out 3/17/77 by dam.  host seems busted.
(tvr @MIT-AI)			;   "  (actually tovar@UCB)
(Haines @LL)			; Lincoln mail, FTP
(Robertson @RUTGERS)		; Mail on Rutgers, Harv, NBS
(JWALKER @BBN-C)		; Interested NBS person
(Steckel @HARV-10)		; HARV contact
(Frankston @MIT-Multics)	; Misc Hacking esp. on Multics
(header-discussion @MIT-Multics)	; For general perusal
(EAKX @MC)			; random observer
;(RICART @DEC-Marlboro)		; NIH, non-Arpanet Tops-10 mail systems.
(NIH @NBS-10)			; Glenn Ricart, non-Arpanet Tops-10 mail systems.
(Feinler @SRI-KL)		; NIC
(MRC @SAIL)			; DIALnet(definitely), CCA(maybe) mail hacker
(GMP @MC)			; Who knows? Someone put him in the wrong list so I moved him here - dam

-----------------
As before, if anyone knows of a site/mail system not represented by these
people, let me know and I will do my best to track down the right person.
--Ken


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 September 1977 2117-edt
Subject:  CRLFs (in Ken's and maybe RFC 724's syntax)
Message-ID:  [MIT-Multics]1.2.BBBJGlkJjZZxDG
To:       header-people at MIT-MC

If one wants to include a US Mail address in a header how
does one achieve the equivalent of a multiple line address.
Some convetion should be established.

This is relevent to internetworking since the US Postal
system is a very large and important network to be connected
to.

Date: 4 Sep 1977 2010-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

I think that having the seconds in network mail is a lesser evil than
the message ID.

I never advocated flushing the extra information when the extra information
really gave more information.  However, when the extra header lines either
gave no extra information, or when the extra information was of marginal
value, I objected.

NO EXTRA INFORMATION:

	Sender: FOO at FOO-SECURITY
	From: FOO at FOO-SECURITY

	Message-ID: (containing just date/time/sender info)

MARGINAL INFORMATION:

	Multics-style unique message ID

	Indication that the mail was a proxy message, ie that it is
	from FOO but BAR really sent it.  Since proxy messages can be
	faked anyway, unless BAR has an active interest in the message
	and isn't just a secretary (or, FOO couldn't get a console and
	borrowed BAR's!!), this is marginal.

The NO EXTRA INFORMATION lines, in my opinion, should not be there.  The
MARGINAL INFORMATION lines, again in my opinion, should be there ONLY if
the mail sender SPECIFICALLY instructs the mailer that they should be there;
so if they really are marginal it was direct human intervention that added
the garbage and not some silly computer program.

				-- Mark

-------

Date:     5 Sep 1977 1253-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  header field names
To:       Header-People@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A]  5 Sep 1977 12:53:42 Rick Gumpertz

Why are there hyphens in Reply-To and such anyway?? Why not use spaces -- the
colon is a fine delimiter!!!

Why bastardize traditional English usage??

		Rick
-------

Date:     5 Sep 1977 1343-EDT
From:     Brian Reid at CMU-10A
Subject:  RMS's comment on message ID's
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  5 Sep 1977 13:43:56 Brian Reid

I don't think that it means much to say, "It [the message id] should be
required whenever there is doubt that the default one will serve to
identify the message uniquely."  Requirements predicated on doubt are
not very enforceable, and if it's not enforceable, it really shouldn't
be a requirement.
-------

Date: 5 SEP 1977 1305-PDT
Sender: DCROCKER at USC-ISI
Subject: Re:  CRLFs (in Ken's and maybe RFC 724's syntax)
From: DCROCKER at USC-ISI
To: Frankston at MIT-MULTICS
Cc: header-people at MIT-MC    
Message-ID: <[USC-ISI] 5-SEP-77 13:05:19.DCROCKER>
In-Reply-To:  [MIT-Multics]1.2.BBBJGlkJjZZxDG 

Comma is the standard replacement character for newline, when
forced to put addresses on a single line.  Dave.
------- 

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     5 September 1977 1645-edt
Subject:  comma as newline.
Message-ID:  [MIT-Multics]1.2.BBBJGlmKzpcGjz
To:       header-people at MIT-MC

By "comma is standard replacement for newline", I take it
that this is a usage standard as opposed to a technical
standard. My porsonal preference is for semi-colon since
comma can be a legitimate component of an address.  For
internetworking an extended quoting convention like used in
some programming languages would be useful.  For example the
"J~" character within a quoted string can take the next
character as a name of a chaacter such as ~n meaning
newline.  If the other net is nonascii (for example, EBDIC
or US Post office) other conventions would be useful such as
~d for a degree sign.  We don't have to resolve that issu
 in detail now, though accepting the concept of such an
escape convention and maybe the designation of a character
would be useful in providing for future expansion. I realize
that an escape character within a quoted string has the
effect of making a quoted string require parsing. The
alternative is to require that such escapes be coutside of
quotes.  This means that a quoted string is not an atomic
unit,but can be concatenated to form an atomic unit.

Just checked the syntax again (KLH's) an noticed that doubling quotes
is permitted in quoted strings.  Perhaps then using ~ is not in violation of the spirit of quoting and allowing ~" might be cleaner than pl1's "".

From:  Pogran.CompNet at MIT-Multics
Date:  09/05/77 1822-edt
Subject:  Re:  Brian's sociological aside
To:  BH at SU-AI
cc:  Header-People at MIT-MC

Brian,

I guess the ARPANET system hacker community has always been a little schizophrenic
with respect to the fact that the money for our system hacking comes
from D. o. D.  But it DOES, and they're going to be unhappy if what is produced
isn't suitable for them.  The "ARPANET Message Service" is of sufficiently high
visibility that it will be pretty damned OBVIOUS if what is produced
isn't suitable for "THEIR nefarious corrspondence".

Maybe we should apply to NSF for money to develop "OUR nice simple mail protocol"?

Meanwhile, it's D. o. D.'s football.

Regards,
 Ken

Date: 6 Sep 1977 0850-PDT
From: TVR at SU-AI (Tovar)
Subject: General comments
To:   Header-people at MIT-MC    

    I think if you look carefully at 724, a short header (i.e. just
FROM and DATE) is quite acceptable and correspond fairly well, except
in subtle details, with what most sites send out as a header.  In
another message, I have included some specific changes to 724 which I
hope will satisfy both the short and long header advocates.

    What I think we are quarreling about is what will be RECOMMENDED
as a DEFAULT header.  It is an implementation decision, that is, what
J. Random User gets when s/he sends you a simple message.

    One of the questions crucial to some of us is how to detect
duplicate messages.  It was generally thought for a while that
Message-ID's were required to do that.  Now, the addition of a field
containing seconds will handle 98% of the mail with a burden of only three
characters instead of a whole line.

    The second question is how to get both a FORMAL and an INFORMAL
header out of the same system.  Now, someone suggested using HERMES
for that purpose, but not all of us are so fortunate, especially
those using 16 bits machines!  Perhaps we could RECOMMEND two forms
of header, a formal header and an informal header.  The user could
choose when the message was send (either by using a switch, being
asked and/or by remembering the preferences of this user from a file
or other form of permanent memory.

    A serious question seems to rearing its ugly head during this
discussion: that is, message authentication.  It appears that at
least twice in the past quarter, a person or person(s) have sent
messages using another name in a personally damaging fashion.  I
think that this is a grave matter.  I would hate to see the message
system burdened with the new authentication technology.  But if
this keeps up, I think we should give it serious consideration.

					    --- Tovar

-------

Date: 6 Sep 1977 0901-PDT
From: TVR at SU-AI (Tovar)
Subject: Specific suggestions for modifying 724.
To:   Header-people at MIT-MC    


I think the following tightening of 724 could make the short header
people happy.  

- - - -

Page 21, 2) Sender: Paragraph 1, replace word 'need' with 'should'.

Page 21, 2) Sender: Paragraph 1, insert following text after first
sentence:

   The intent of this field should be to indicate the person
   actually responsible for sending this message when it is
   not that mentioned in the 'From: ' field; Or to indicate
   who among a jointly authored message had actually sent it.

Page 21, 3) Reply-to:  Append to paragraph 2

   The 'Reply-to' field should not be the same as the 'From: '
   field unless it is to designate a different machine address.

Page 23, a. Message-Id:  Add new paragraph at after first:

   It is hoped that this will only be generated when messages
   would be difficult to distinguish in other manners.  In Appendix
   X, there is an algorithm for generating a message-ID at the
   recieving end for handling rejection of duplicate message.


Appendix X is not written, but would describe two algorithms for
generating a message-ID at the recieving end.  The first algorithm
would describe a method whereby the FROM, SUBJECT, DATE and TO
fields would be concatenated to form a simple message-ID.  The
second algorithm would describe a message for using the same
fields plus a means of checksuming the message to produce a
complicated but very reliable means of detecting duplications.

- - - -

    The effect of these changes would be remove redundancies from the
header and will typically give a four line header.  It does not add
or delete anything meaningful from the header, but it does request
that mail programs should not make headers with fields of no
information value.

			Respectfully,

			   Tovar

-------

Date: 6 SEP 1977 1758-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: HEADER-PEOPLE at MIT-MC

1) Checksumming a message can be a screw when a host changes
the contents of the message.  For example, AIMLMC will probably
change any ^_ character encountered into an ^ and a _.
This is because ^_ is used to separate messages in our mail files.
Other systems may add some extra data to the front of the message
(such as whether it has been read yet) and then gradually mung it.
The checksum of the message might change over time.
I think that rejection of duplicates can work just fine without
any checksumming, so we might as well just forget about it.

2) A message ID can be used for more things than just rejection
of duplicate messages.  For example, it can be used to refer
to a message you are replying to or a previous message you sent.
So we need not just a way to detect duplicate messages with no
explicit message ID fields, but an actual algorithm to construct
a default message ID out of the other fields.

3) Point 2 also argues that the default message ID should not be
so long that one would be ashamed to mention it.  Thus, it should
not include more than the bare minimum of information necessary
to disambiguate messages sent by humans actually typing on their
terminals.  Only the date-time and From should be used.
(I can't remember 724 well enough to remember whether From is
really what I mean.  It should be something that identifies the
sender and ALWAYS contains a host name.  Perhaps it should use
the Sender if there is one, otherwise the From).

4) Does 724 allow the seconds to be included in the time of day?
How should they look?  Without the seconds, the time of day will
not be enough to disambiguate the message.



Date: 6 SEP 1977 1542-PDT
Sender: DCROCKER at USC-ISI
From: DCROCKER at USC-ISI
To: header-people at MIT-MC   
Message-ID: <[USC-ISI] 6-SEP-77 15:42:13.DCROCKER>
In-Reply-To: Your message of SEPTEMBER 6, 1977

The final form of 724 will probably allow (but not require)
seconds and will not provide for sub-seconds.

Dave.
-------  

Date: 6 SEP 1977 2251-EDT
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Warning... next message is moby...
To: HEADER-PEOPLE at MIT-MC

I've decided to send my comments, approx 9 printed pages,
via mail.  I hope this isn't a mistake; for those whom it
is, you can find a separate file on MIT-MC as
   KLH;COMMEN >   (No password necessary)
and can FTP that, ignoring my next message.

Not as early as I had hoped, but at least it's still Tuesday...

Date: 6 SEP 1977 2257-EDT
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Here 'tis.
To: HEADER-PEOPLE at MIT-MC

Lead-in

      In the following paragraphs I will be moving from the very specific 
      to the very general; usually, to each problem, a solution or two 
      will be suggested -- if not, most likely I ran out of think time, 
      since I do try to think about other ways to do things. (One thing 
      that annoys me about some complaints I see is the complete lack of 
      suggested alternatives...).  To summarize, most of my unease with 
      the current 724 lies with addressee syntax and the lack of any 
      compatible way to bring 724 up, in the absence of syntax versions.

      And one other note before embarking.  I am slightly depressed that 
      many of the things I am citing here were cited, in much the same 
      words, in the reactions to the original first-draft 724.  This time,
      it would be nice to have the explanations or replies that we never 
      had to them.

   Trivia

      There are various little things wrong with 724 as it is, much of 
      which others have already pointed out - stuff like typos (zero of 
      more), inconsistent element names (<horizontal-tab> vs <tab>, 
      <date-of-month> vs <day-of-month>), and other less glaring 
      oversights which seem to indicate that even the authors tend to lose
      track of the BNF.  How else can you explain a message-ID in the 
      examples which has neither of the required angle brackets 
      surrounding it?  My hope is that with a better representation (such 
      as previously suggested), these will be lessened.  In any case, all 
      easily fixed.

   Little Stuff

      [L1] Put day-of-week into comment

         I suggest that the day-of-week (Monday, Tues, etc) be flushed as 
         an explicit item, and allowed to exist as a comment if so 
         desired.  It (a) makes the parsing slightly hairier, (b) provides
         more opportunities for error (are mail-readers supposed to check 
         it?), and (c) furnishes no information useful to the machine, 
         since the day-of-week can be trivially determined from the date 
         itself.  Hence that field would never be used except by a human, 
         which is exactly what comments are for... finally, if the reader 
         explicitly wanted to see it, it would certainly be better done by
         parsing the date and deriving it thereby, so as to provide it for
         ALL headers, not just the ones it happens to come with; and if 
         this is done, what good is having it as an explicit field?

      [L2] Date format

         What is the currently proposed revision to this, or is ANSI 
         format excluded, or what?  While parsers should probably continue
         to understand slash-day format, does anyone object to a strong 
         recommendation that it not be used?

      [L3] Recommendations about text

         724 mentions on page 13 that a CR must be followed by either LF 
         or NULL.  This is all right for headers, but not for message 
         text; once the message text starts, I don't think any 
         restrictions whatsoever should be put on the contents.  It is OK 
         to make recommendations here (as for tabs, length of a line, 
         etc), but only that and nothing more.  Incidentally, how long can
         a line be before folding is desirable?  Page 14 doesn't say; how 
         about 71 columns?

      [L4] Improvement to "From"

         It seems to me that the originator hair can be further simplified
         if you specify that it is OK to have multiple addresses in a 
         "From:", and NOT have a "Sender:" field, provided that the FIRST 
         machine address in the "From" indicates the sender.  This lops 
         off one of the most common cases I can think of, and the syntax 
         then becomes:

         originator-fields =

         ("From".    ":" mach-addr *(.",". address) CRLF
         ["Sender".  ":" host-phrase CRLF]   ; Only if not = 1st mach-addr
         ["Reply-To".":" mach-addr *(.",". address) CRLF])
         /
         ("From".     ":" 1#address CRLF     ; Can only use random addr
          "Sender".   ":" host-phrase CRLF   ; if using BOTH other fields
          "Reply-To". ":" mach-addr *(.",". address) CRLF)

         Naturally, it should be recommended that "Sender" be used only 
         when the sender is not in the "From"; and putting the sender's 
         address in other but FIRST place in the "From" would be very bad 
         etiquette, as it would then necessitate an explicit "Sender" 
         field.

      [L5] Bug in addressee syntax?

         It is possible to have a null group, eg "Group: ;" -- shouldn't 
         the definition require at least one address inside the group, or 
         is this deliberate?  If not, #address in the current definition 
         should be changed to 1#address.  My general comments about groups
         are in [A1].

      [L6] Multiples

         There really should be some discussion about the meanings of 
         multiply occurring fields; either there should be a recognized 
         interpretation, or a field should be unique.  For example, 
         "Message ID" should be unique, whereas "To" is cumulative; all 
         the "To"s taken together specify the same thing as a single long 
         "To".  Suggest that the unique fields be "Subject", "Date", 
         "Sender", and "Message-ID".  Or it could be required that long 
         fields always be hacked with continuation lines, rather than 
         breaking them into separate fields, so that (nearly?) everything 
         is unique.

      [L7] Ordering

         While there should not be a required ordering for the fields, 
         there should be some strong recommendations about a preferred 
         order.  For example, it would be good if "Date" and "From" in 
         that order were the first two fields in a header; maintaining 
         some consistency makes life easier for people without hairy 
         programs to shuffle the fields around.  See also the section 
         about DLW's scheme ("Ease of Filtering"), in which fields would 
         be sorted differently.

   Not-so-little stuff

      [N1] Unfolding

         There is a general problem with "unfolding" when you consider a 
         text-line, quoted-string, or msgid.  This is how to deal with the
         leading whitespace on the next line; the CRLF is obviously thrown
         away, but what about the leading spaces?  Do you compress them 
         all into one representative SP, or ignore all but the first 
         character of the whitespace (or the last), or simply slurp them 
         up?  The examples seem to be fond of column justification, which 
         is going to make a quoted string look pretty gross if unfolded 
         without any compression.  I realize that there seems to be a 
         definite algorithm for this, but my confusion engenders the 
         suggestion: make it very clear what the unfolded result should 
         look like when dealing with quoted strings - flushing only the 
         CRLF is OK, except that Dave Crocker made some comments that 
         imply one can, in fact, have quoted CRLF's.  Please explain 
         further?

         Dave Moon has suggested that the best scheme may be to say that 
         all indentation is removed (whether or not in a quoted string) 
         and all CRLF's are retained, then in the syntax CRLF is generally
         to be treated the same as space, except that CRLF ought not be 
         allowed inside addresses (only after the comma, if an address 
         list is folded).

         It would certainly be nice to allow quoted CRLF's, but these need
         to be very distinct from CRLF's starting a field name.  Perhaps 
         with more explanation from the inventors of folding/quoted 
         strings, all will be made clear.

      [N2] Quote character

         R. Frankston and D. Moon have already suggested that some quote 
         character be used for purposes of simplifying some quoting and 
         escape problems.  This seems reasonable, and could certainly be 
         used in conjunction with the quoted-string syntax; not to replace
         it, but augment it.  This would firstly solve the problem of 
         including ")" in a comment (consider the example (Re use of ")" 
         in comments)), as well as that of quoting CRLF's, since it is an 
         extremely simple check and imposes very little on any scanner.  I
         expect there would be more argument about the choice of character
         than the idea of using one; but IS there anyone who dislikes it?

      [N3] Message-ID strings etc

         [N3a]  Canonicality
         One problem with the msgid string is that when you want to 
         compare it to another msgid (checking for identical messages), 
         then what canonical form should you convert it into?  Any sort of
         conversion is going to be a pain; for example, there are several 
         different ways to specify an equivalent host.  I would suggest 
         either that everything between the angle-brackets be treated as a
         quoted string (although maintaining a host-phrase syntax), or 
         doing away with the use of host-phrase in this situation, and 
         specifying something much more rigorous that lends itself to 
         conversion-less scanning.  Either way, a criteria for 
         canonicality is needed.

         [N3b] Forming ID by concatenation
         Recently, people have come up with a fairly specific scheme for 
         avoiding the use of explicit message ID's in most cases.  It is 
         truly remarkable how much of this has been said before; nearly 
         every one of the points in [N3] has been brought up since 
         Stefferud first suggested this idea last October.  Others (RMS, 
         Tovar, Macrak, etc) have had the same ideas independently.  One 
         problem with it is that it IS possible to have different messages
         with identical headers.  In fact, it is possible right now for 
         HERMES msg-ID's to be identical, in spite of including the 
         seconds field.  This is because more than one person on TENEX may
         be using the same login name, and it is well within the realm of 
         possibility that two people, sharing an account, will reply to a 
         message simultaneously.  However, the "From" should distinguish 
         them, and in this sense the scheme Tovar, RMS, etc propose is 
         actually better!  Anyway, I rather suspect that infinitely more 
         messages will be lost from disk crashes than would ever vanish in
         this curious fashion.

         [N3c] Forwarding problems (some of)
         There is a somewhat more obscure problem that rises when one 
         considers the use of ID's to prevent forwarding loops, rather 
         than to eliminate duplicates in a mailbox.  Namely, it is 
         wasteful to compare the whole of an incoming message with 
         previously sent ones, so some ID, however concocted, is 
         necessary; but if the other site(s) MODIFY the header before 
         forwarding the message back, an ID not based on an explicitly 
         preserved message ID could easily NOT be matched, and the loop 
         would continue.  RMF pointed this out in October (10/20/76 
         1049-edt) also.   A "Forwarded-from" (or to, or by, etc) scheme 
         could actually hurt, since it does not prevent duplicates 
         although it can be used to stop a loop, and sticking this field 
         in the header implies that the header is re-generated; parsing 
         and re-writing a header is unlikely to produce exactly the same 
         thing, so that a message ID formed from header fields rather than
         a explicitly furnished one is likely to be different in each site
         it gets crunched through.

         I suggest that more specifics be settled -- for example, what 
         should the format be for a time that includes seconds?   Who will
         be the first to write Appendix X describing two schemes?  And 
         don't we need to haggle a little more on how automatic message 
         forwarding should work? (One interesting observation:  Suppose 
         FOO forwards to BAR which forwards back to FOO.  The message will
         disappear entirely without being sent anyplace.) 

   -----------------------------------------------------------------------
                           ADDRESSES
   -----------------------------------------------------------------------

   General

      The syntax of addresses, as it currently stands, is not really very 
      good; the problem is difficult, but it does seem as if 724's is not 
      the best scheme possible.  Some points follow; I apologize in 
      advance for their somewhat incoherent presentation, as I lacked the 
      time to propose unified and consistent alternatives.

      [A1] Group names

         It's not clear what the intent of group names is.  For all 
         practical purposes they seem to be ignored, in which case they 
         might be put into comments, or expressed by indentation levels.  
         I would like some elaboration on what their intended use is, 
         particularly since they tie up two special characters.

         Might one not, rather than saying
             Group: foo@here, bar@there;

         Use instead:
             (Group:) foo@here, bar@there (;)

         Or another scheme is to use brackets, such as Group<foo, bar> or 
         <Group: foo, bar> or even [group: Group <foo, bar>].  I haven't 
         completely thought out the alternatives, since these would need 
         to be part of a more general scheme which takes care of 
         mach-addr, etc.

      [A2] File pathnames

         The use of "Fcc" seems like a crock; all it is doing is to 
         distinguish between a file which contains messages and a file 
         which contains a list of addresses.  This is much better done 
         with address types, discussed below.  The provision for a list of
         "alternative" filenames doesn't make a whole lot of sense - are 
         all these files assumed to be identical?  If not, why pick only 
         one, presumably at random?  If alternatives appear in a "Fcc", 
         does that mean the message got sent to just one of the files, 
         guess which one?

         Are they serious about retrieving and processing file names??

      [A3] Responsibility for generated addresses

         This was brought up by Dave Moon, but was somewhat limited both 
         originally and in Dave Crocker's reply.  A more appropriate 
         statement would be that "when a program or file specifies a 
         <host-phrase> in which <hostname> refers to the local host (where
         the program is running or the file resides), the <phrase> MUST be
         an valid address at that host, which its FTP server will accept."
         This seems to express the basic idea and still cover all the 
         bases, whether the address is in a "To:" or "From:" or whatever. 
         (except for one qualification Moon adds: Should acceptability 
         mean that the form of the name, rather than the name itself, is 
         OK for the FTP server?  Mailboxes do go away.  Perhaps something 
         like "at that point in time" should be added. Ugh, legalese.)

      [A4] Addressee files

         I think there should be equal mention given to an alternative 
         scheme of mailing to addresses in such files.  724 talks about 
         FTP'ing over the file and then scanning it, but there is another 
         method which is more convenient - give the pathname a type of 
         "indirect file" or "@file", which when specified as a recipient 
         will cause the receiving site to automatically distribute the 
         message to everyone in the file.  Since this type of address will
         not be put in a header unless the generating site is in fact able
         to handle such things, there is no implied requirement to support
         this.

      [A5] Nesting and breaking - avoidance of quoting

         It seems to me that quite a bit of elegance can be gained by 
         adopting a long-ago suggestion of RMS that open-brackets seen in 
         the scan of an atom should gobble everything up to their matching
         close-brackets, with one addition: close-brackets seen which 
         don't match the current level are legal and included in the text.
         (Brackets: [],{},<>.  Not sure about parens.)  This is an 
         interesting form of "quoting", as the brackets themselves are 
         included in the text and are not delimiters, of themselves; most 
         filenames then need no quoting:

            foobar.txt[13,13]   - Tops-10; the "," is safely within 
            brackets.
            foo>bar>whatever    - Multics; the ">"s are ok.
            [foo;bar >]         - common ITS file reference.

         With the addition of a rule that ">", ";" and ":" not cause a 
         break - the actual breaking for mach-addrs and the like would be 
         done by whitespace or a comma - one can also have the very common
         Tenex filenames without pain, as in: <foo>bar.txt;23, which is 
         clearly different from <foo@bar>,<etc@cte> as mach-addrs.  Note 
         that ":" is used in an odd way for :File: and Group: -- these 
         uses might well be done differently.  See [A1] and address types.

      [A6] If you want to know...

         There is an interesting section in the new Arpanet Directory (not
         yet distributed) which lists mailboxes alphabetically.  A 
         programmed search through this data base reveals that currently 
         the only special characters which appear to be used are "." by 
         Multics addresses, and ";", "(", and ")" by UCLA-CCN mailboxes 
         (eg "FOO;BIN(0836)@UCLA-CCN")

      [A7] Parsing an address

         Looking over the rather hairy forms possible, it seems to me that
         if anyone wants to do some people a big favor, an appendix could 
         be added to 724 suggesting the best way to parse addresses.

   Address Types

      I want to suggest, again, that explicit provision be made for giving
      addresses a "type", allowing new types to be created just like new 
      header fields.  This will allow elimination of "Fcc" since that is 
      just a particular type of address.  AND US mail addresses can be 
      processed specifically as such, rather than as random text which 
      merely might be.

      Again, I have not had sufficient time to formulate this as well as 
      it should be.  724 has a hint of "typing" in it by means of double 
      ":"s; that is, ":File: <filename>", which can be generalized to 
      ":"<type>":" <host-phrase> -- this is almost exactly what I 
      suggested before, using ":" instead of "*" -- but I think now that 
      something which uses brackets might be preferable.  (Curly brackets,
      since these are so little used - I just hope not TOO little 
      used...):

         :File: foo>bar>far at Multix
         {File foo>bar>far} at Multix

      By means of the nesting convention suggested in [A5], no special 
      parser will be needed, and addresses would, I think, be somewhat 
      clearer.  For example, the type is clearly associated with the name,
      and the host is comfortably separate.  I am quite strongly against 
      the idea of providing "alternates" in a <path> as 724 suggests, not 
      only because of previously voiced criticisms but because the type is
      not well associated with the alternate host-phrases.  Moreover, 
      again due to the nesting convention, it is very painless to include 
      several things inside the brackets; you might want to include not 
      only the file/rcpt name, but some additional info which depends on 
      the specific type.  Typed names would need to be distinguished from 
      untyped names by virtue of the initial bracket char (here, "{") -- 
      but for purists, "Name" can be the "type" of the latter; "Foo" = 
      "{Name Foo}".

      Whatever scheme is used, the concept of typing in general does need 
      some expostulation in 724.

   Internet addressing

      Basically, I don't think a quick resolution of this issue is at 
      hand, and I would not like the lack of same to hold up 
      implementation of the rest of the standard.  It would be nice if 724
      had everything, but we shouldn't delay it several more months just 
      to make sure that internetwork addressing is correctly handled.

      The reason I am somewhat dubious is that it's simply not clear what 
      should actually happen with such addresses.  Both suggestions, 
      (using "/" and "@") are reasonable enough, but I have a nagging 
      feeling that something is still missing -- allow me to elaborate.  
      It certainly sounds nice and elegant to have a host "pass on" an 
      internet address minus its own particular part of it; but exactly 
      HOW is this to be done?

      Let's assume that something like "Foo at Bar@Bnet@Host" is given to 
      a mail sending program.  Okay, under our current mail transmission 
      scheme, what exactly gets sent to Host?  That is, are we talking to 
      Host's FTP server and sending it a string like "Foo" (where's the 
      address?) or "Foo@Bar@Bnet"?  If so, does that mean an FTP server 
      will have to do address parsing?  One then needs to have quoting, 
      since it is legit to have, say "@" as a character in the actual 
      mailbox name, and so forth -- it might be more general if this is 
      done with address types, such as {Nonlocal <name> <fancy-address>}. 
      Then I wonder which program does the forwarding (the FTP server?) 
      and whether a positive acknowledgement is delayed until the message 
      has actually reached its destination, or sent immediately and the 
      message queued if the other network is down (in which case one needs
      a demon)...

      It just seems as if actually implementing this will require 
      something considerably different from the current scheme -- more 
      like a structured message protocol, in fact.  At which point the 
      precise representation of the address becomes much less important, 
      and we are getting outside of 724.  So I suggest not worrying too 
      much about the issue right now, and just providing for 
      quoted-strings as "hostnames", as well as address types; between 
      those two, we should have quite enough flexibility to adapt to 
      whatever future, post-724 discussion brings.

   -----------------------------------------------------------------------
                           IMPLEMENTATION
   -----------------------------------------------------------------------

   At the risk of appearing excessively negative, I want to ask if 724 is 
   really the right thing; the trouble is that it tries to introduce new 
   features at the same time it solves old problems, and the amount of 
   change may from some viewpoints be excessive for the amount of benefit.
   Here are some possible problems with implementation:

   [I1] Conflict with old schemes

      There are some new features of 724 which will directly conflict with
      old ways of parsing messages, and I am sure that we will see both 
      old and new headers in the same mailbox, which the same mail reader 
      will have to parse, as conversion proceeds.  It may be that most 
      messages will work, but many of them will certainly not, and I have 
      not seen any notes about a scheme to resolve these conflicts.  New 
      FTP and new TELNET at least had different sockets; I, Moon, and JFH 
      jointly argued that we need some way of distinguishing between 
      syntax versions, and some suggestions such as "S:<syntax>" or an FTP
      command XHDR were proposed (references/copies provided if 
      requested), but 724 has no trace of these, or indeed anything else. 
      It would be very helpful to know what the authors had in mind, 
      however dimly.

   [I2] Caution! User interface!

      724 claims that it is not intended to dictate user interfaces.  
      However, on page 26, section h, there is an example which seems to 
      indicate that the user in fact types in quite a bit of the 724 
      syntax; there are other implications lying around which ominously 
      hint at the same thing.  It might be best to just admit that 724 in 
      fact WILL have a large effect on what the user sees and types, 
      although probably not on the set of conceptual commands.  A more 
      subtle example of lossage can be seen in the case of distribution 
      list files; ITS mail might well want to include such filenames in a 
      "To:", but if anyone actually tries to access them they will find 
      something similar to the Header-People list, in a format which 724 
      will violently disagree with.  I am sure this will confuse people, 
      particularly those making up such files, and there is no immediately
      obvious solution since using 724's format would place restrictions 
      on current capabilities.  General bracketed address typing might, 
      however, achieve a sufficiently close resemblance for existing files
      to be converted practically.

   [I3] Ease of filtering

      There has been a considerable amount of bickering about large 
      headers, which WILL in fact occur despite our compression 
      techniques; it seems that a scheme which makes the "extra" stuff 
      easily filterable will be much more acceptable than one which 
      doesn't.  Accordingly I would suggest either or preferably both of 
      two schemes:

         [1] Adopt DLW's suggestion that all fields other than 
         Date/From/Subject/To be grouped together with appropriate 
         delimiters, so that a very simple printing hack can easily ignore
         them.  One possible way of doing this would be to have them at 
         the beginning of the header, and search for the sequence 
         "<crlf>Date" (or <bof>Date)  after which everything would be 
         printed.  The only screw would be a (n illegal) message without a
         date, in which case the scan must be backed up and the message 
         printed completely.

         [2] Adopt RMF's suggestion that field names be identified and 
         discarded/printed individually, BUT ONLY IF something is done to 
         make it very easy to do such semi-parsing.  At the moment, 
         field-name keywords can be separated by whitespace/comments, 
         which is really somewhat unnecessary; I propose that field names 
         be more strictly defined, so that the string between a <crlf> and
         the colon matches a template exactly after case conversion.  The 
         first four characters should also be unique, for even easier 
         identification.  This implies that if a space occurs in a field 
         name (which is fine with me) then there should be only ONE space,
         not several.

      Remember that both of these imply that field names must be EASY to 
      find, and folded lines or quoted CRLF's (if any) EASY to ignore.  I 
      would even recommend that a basic algorithm for doing this be 
      included in a 724 appendix.  This filtering can be done by the FTP 
      server if there is no way to delimit messages in a mail file.  To 
      avoid losing anything that might be important, the ignored text 
      could conceivably be stuck into a "garbage" file parallel to the 
      mail file, which the user can examine if necessary and flush 
      occasionally.

   [I4] One last comment.

      Achieving a consistent syntax would be nice.  But 724 will take a 
      lot of work to fully implement, and will we really be that much 
      better off compared to our current situation?  Would the same time 
      that 724 gobbles be better invested in a true mail protocol on a 
      different socket?  Jack Haverty's RFC 713 proposes a message data 
      transmssion protocol (MSDTP) which a DM hacker brought up in a 
      afternoon's work -- and indeed the basics are pretty simple and 
      fast.  I hesitate to say that 724 should be dumped or trimmed down 
      to introduce NO "new" features not already in use, and time invested
      instead on MSDTP.  Rather, I strongly suggest that items [I1] and 
      [I3] above be given a lot of serious thought; if they can be 
      resolved satisfactorily, I have no qualms about advocating as 
      general a 724 as possible (full speed ahead!), after which those of 
      us who want can continue the investigation into MSDTP-like schemes. 
      Since I think the reassurance of these two points is so valuable to 
      have, I will repeat them:  

         RESOLVE SCHEME/VERSION CONFLICTS (I1)
         MAKE FILTERING EASY AS POSSIBLE  (I3)

-------------
 --Ken

Date: 7 Sep 1977 0130-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

My set of bad ideas, replying to Ken's.

 06-Sep-77  2104	FTP:KLH at MIT-MC (Ken Harrenstien)

[L1] Put day-of-week into comment

	Agreed; although it is somewhat marginal to have it at all.

[L2] Date format

	Suggestion; why not have HUMAN dates rather than computer
	ones?  The Tenex/1050 style dates are oppressive.  I suggest
	that "September 7, 1977" is better than "7-SEP-77".  The
	European-style "7 September, 1977" is alright too, however
	which way should be agreed upon; since this is the US I would
	prefer American-style but the majority should rule on this.
	The simple 9/7/77 which I prefer can't be used, since it would
	confuse European-style hackers (sigh).  In any case, I think
	we shouldn't be stuck with SIXBIT month names!

[L3] Recommendations about text

	I think there should be no restrictions on text other than
	agreement between the parties involved.  724 should only
	make recommendations on what is courteous; for example, lines
	should be limited to 70 characters for people on inferior
	consoles, no ASCII character whose graphic cannot be reasonably
	reproduced on inferior consoles (for example, no grave accents
	or ITS/SAIL extended ASCII, etc.) and so on.  Tabs are a nasty
	problem since Multics likes 10 character tabs and PDP-10's like
	8-character tabs, and I don't know what IBM systems like.  I
	think that if Multics converts their tabs to spaces and incoming
	net mail tabs to 8-space indentations (I think somebody said
	that once upon a time) then it should be alright all around;
	PDP-10's can win without screwing Multics users.
	To summarize, I don't think there should be any restrictions on
	the text but that the message sender should be considerate of
	the message receiver.

[L4] Improvement to "From"

	I agree.  I still think that even with proxy messages the Sender:
	and Reply-To: fields should not be included unless the sender
	specifically says they should be.  This is more an implementation
	manner; but I think it is worthwhile to state that these fields
	don't have to be there.  If FOO's secretary actually typed the
	message, I am not interested unless FOO's secretary is to get a
	copy of the reply.  Similarly, if FOO borrows my console to send
	a message since there are none free, I am not interested in
	getting replies unless I am specifically involved in the message.

[L7] Ordering

	I see nothing wrong with required ordering.  I suggest Date:,
	From:, Subject:, To:, Sender:, Reply-To, Message-ID, (plus whatever
	else there is...).  The general point is that Date:, From:, and
	Subject: should be FIRST.  This is to make mail reading programs
	which print the first n lines (usually up to the subject) of a
	message and then pause (allowing the user to decide whether or not
	to see the rest of the message) to win.  This also makes it easier
	for people who edit the mail headers in mail they keep in their
	mail archives to maintain a consistant format.  The secondary
	point is that the Message-ID, if it MUST be there, should be last
	out of esthetics or something.

[N2] Quote character

	Has this problem actually come up in the real world?  Could I be
	given an example?

[N3] Message-ID strings etc

	I agree with the RMS/Tovar suggestions.  Since I do not trust
	computer programs to delete messages from my mail file without
	my consent, I don't have the problem of duplicate message ID's.
	If somebody really wants to have a program to automatically
	flush messages that appear to be duplicate, Message-ID's don't
	seem to be enough; I would do some text comparison in the body
	of the message.  'nuff said.

[A2] File pathnames

         [Are they serious about retrieving and processing file names??]

	Hope not.

[A6] If you want to know... [refering to . ; ( ) being the only special
			     characters that are currently used]

	I wonder if some of the hairier aspects in 724 will ever be used,
	not because of non-implementation, but because the case never
	comes up?  I hope there is some thought on this.

Internet addressing

	I agree that this should wait until the other networks start
	talking to the ARPAnet and their own folklore is established.
	For networks still in development (such as DIALnet (ta da!)),
	I think it is only fair that they have a chance to have their
	own bad ideas instead of having the ARPAnet dictate its bad
	ideas.
	DIALnet will have short (possibly one-line), very strictly
	formed headers.  The semantics are unknown at the present
	times, as only the Host-Host protocol has been "written" in
	any sense of the word.  However, the current theory is that
	the header (ie, the thing that is actually IN the message)
	will be minimal, and that hairier information will occur in
	the protocol, where it can be processed (or ignored) by the
	mail server.

-------

Date:     7 Sep 1977 1427-EDT
From:     Philip Karlton at CMU-10A
Subject:  Re: Recent suggestions about From and Sender
To:       Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A]  7 Sep 1977 14:27:22 Philip Karlton
In-Reply-To: MRC's message of September 7, 1977

If the user is allowed to edit the From: field then it might become difficult
for the sending program to guarantee that the address is a legitimate network
address.  Is this a real problem??
                     PK
-------

Date:     7 Sep 1977 1434-EDT
Subject:  Re: Long default Message IDs
To:       Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A]  7 Sep 1977 14:34:37 Philip Karlton
In-Reply-To: Stallman's message of September 6, 1977

I agree.  The default IDs should be short enough to normally fit on one line
with a field name.  In addition, the algorithm for generating it should
probably strip leading (and trailing) blanks.

                           PK
-------

Date: 7 Sep 1977 1139-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC    

 07-Sep-77  1133	FTP:    Philip Karlton at CMU-10A	 Re: Recent suggestions about From and Sender 

If the user is allowed to edit the From: field then it might become difficult
for the sending program to guarantee that the address is a legitimate network
address.  Is this a real problem??

[MRC - It seems to me that if a user edits the From: field and loses then
 s/he is to blame for any confusion which results, not the mail subsystems.
 In any case subsystems shouldn't blindly assume that the From: field is
 correct since any number of things could screw it up.]

-------

Date: 7 Sep 1977 1138-PDT
From: BH at SU-AI (Brian Harvey)
To:   header-people at MIT-MC    

Thank you, Tovar.  Thank you, Ken.  If our luck holds, we
seem to have discovered a domain in which Gresham's law
doesn't apply.

I too would like to repeat a previous comment, namely: message IDs
are not useful for the purpose of referring to a message in a reply,
since the (human) sender of the original message never saw the ID
and wouldn't remember it if s/he did.  Even "Subject: Re:" is better
than the ID for that particular purpose.

As for forwarding loops, I would like to know if this has ever been
a problem in the past.  I suspect that a bit of vigilance in the
setting up of forwarding in the first place will do more good than
automated control, but I could be wrong.

-------

Date: 7 SEP 1977 1635-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: Reply to several letters.
To: HEADER-PEOPLE at MIT-MC

In reply to MRC's letter (which was a reply to KLH's long letter):
In choosing that date format it would be desirable to keep the format
easily parsable by programs.  A mail reading program might want to be
able to place messages in order by date, among other things.

A quote character is certainly important.  I am not familiar enough with
the rules of 724 to come up with an examply in which bracketing is insufficient
to serve that purpose, but we should anticipate that there might be one.
An important point to be considered when designing any protocol for the
ARPA net is that a major goal of the net is to allow computers of any differnt
type, useing any kind of strange software conventions (within limits, of course)
to operate fully.

In reply to Philip Karlton's letter, it is important to allow a user
to alter the "From" field since he might be sending mail from a console
at which some one else is logged in.  However, there is no reason that
the mail system would not still append its host name, and check to see if
quoting is needed, etc.

In reply to Brian Harvey's letter, message ID's ARE useful in just the way you
described in the context of an advanced mail system:  I can easily envision
a command to "Fetch the letter I sent out to which he is replying", which 
would certainly want to work be checking the In-reply-to field, and then
looking up that message ID.  One of the primary reasons that message ID's
are useful is in this kind of system; I think this is what Bob Frankston
was referring to when he said that message ID's are a very fundamental
kind of thing.

-- Dan


Date:  8 Sep 1977 (Thursday) 0034-Est
From: NIH at NBS-10
Subject: Suggestion for guaranteeing reciver's unique generation of Msg-ID
To:   Header-People at MIT-MC

As nearly as I can tell the main advantage of message ID's is to allow
automated filing and retrieval of messages in a consistent way.  If
message ID's are sent as part of the header or constructed by the
receiver using a known algorithm, cross-site filing is possible.

In deferrence to the "short header" faction, I can certainly see the
advantages of making the receiver generate an ID if the receiver wants one.
The problem is that it is possible for program-generated messages to
have identical headers though the messages differ.  The proposed suggestions
so far are (1) Count characters and use that too  (2) Calculate
message checksum and use that too  (3) Compare text portion of the message
(only applicable to the duplicate msg problem)  and (4) Allow the sender
to send an ID only in the case that the sender thinks one is needed.

Here is another idea that descended upon me 
while in a strange mood no doubt caused by reading 68 straight
Header-People messages: The mailer knows when a header is about to be
duplicated.  It can refuse to send a new message with identical
header until the date/time clock has been incremented, thereby
making the new header unique.  I doubt that we have need to send
messages on the same subject from the same people to the same
people more often than once a second.  An extremely simple implementation
can be had by making the mailer sleep for one second after
every message sent (probably adequate for most volumes); higher
volume shops can do header comparison and only delay possible
infractions.

As to the length of the generated ID--hopefully we can organize
some convention for ID's so that they can be used like NLS "links".
(This raises all kinds of questions on message filing--I'm not
trying to open that subject; just suggest that there will be
interconnections.)
				. . . Glenn


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     8 September 1977 0142-edt
Subject:  Once more, you've heard it before.
Message-ID:  [MIT-Multics]1.2.BBBJGlzJwklpnX
To:       header-people at MIT-MC

1. A UID generator is the simplest way of generating a UID.
By making it independent of the rest of the header one does
not run into problems of side effects resulting from
variations in the content and form of other fields in
instances and copies of letters.

2. How can a system know that it is generating two messages
that may imply the same message ID if it is not using a
shared UID generator.  In a distributed system in which I am
logged in as Frankston twice and am sending messages from
both instances of myself (I have two hands for typing on two
keyboards and often use them both!!!) then unless the system
goes through the hair of a central database how is it going
to know about the potential conflict and the central
database option may conflict with either access control
requirements or system architecture imposed limitations. Of
course one can append a uniqueinstance ID to differntiaate
the two in case of a potential conflict, but that is silly
since a UID is a UID so why concatentate the insance ID with
anything else when one can do better by generating a new
virgin UID by simply reaching nto the humongous bag of UIDs
and just get a new one.

3. As demonstrated by the Multics message-id, the message ID
so generated is relatively small and therefore simpler to
store and manipulate by a autoated message system.

4. It is a bug in current message systems that they bother
users with message-id's when printing mail. This should be
reported as a bug on the local system and fixed! {I hve been
attempting to do so local and am awaiting improvements}

5. And even from one terminal I can send more than one
message a second.  Trivial example is a mailsystem (such as
RMS's RMAIL) in which I can define single letter macro
commands such as Y for reply yes and N for reply N and give
a quick series of replies.

6. In conclusion.  Message-id's generated by a UID generator
are necessary for advanced mail sytems. Those users willing
to risk loss of their messages by mail systems that
automatically discard duplicates will probably continue to
refuse to send message-id's to each other.  But it is
irresponsable for writers of mail sending programs to
require that the sender be cocerned with ID generation and
potential conflicts.  It should just tag a message with a
UID generated by an independent UID generator.

7. Post script.  I feel that many of the complaints about
UID's so generated are "well they look ugly and my
scheme works almost all the time and fits my needs".  I am
attempting to suggest a scheme that doesn't fail (and least
within its domain of expected usage) and which fits a much
wider set of needs, especially those of advanced message
systems which I hope we are attempting to pave the way for.

OK, now, anyone have anything new to say?


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     8 September 1977 0221-edt
Subject:  In reply to invitation to be executed
Message-ID:  [MIT-Multics]1.2.BBBJGlzMDcWfHL
To:       mrc at SU-AI
cc:       header-people at MIT-MC

So, there are many venerable bugs that will never get fixed.
Try APARing (IBMese for reporting bugs) bugs in your 7094
Fortran II compiler.

Date:  8 SEP 1977 0954-PDT
From: POSTEL at USC-ISIB
Subject: re: message identifiers
To:   header-people at MIT-MC


message identifiers can be useful for referencing messages.  in the nls 
environment the use of unique simple identifies assigned to messages and
documents has been extremely useful. but the key work is "simple". if
identifiers are to be used for refering to messages they must be short, and
easy to communicate, e.g. case distinctions should not be important. nls
uses sequential numbers obtained from a single source. for the larger volume
in the general network one might use "host-year-sequentialnumber". the 
potential for developing message filing and retrieval programs based on the use
of a message identifier should not be forclosed.

--jon.
-------

Date: 8 SEP 1977 1510-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Brief note about forwarding loops
To: HEADER-PEOPLE at MIT-MC

In our system, where we allow (and encourage) users
who are naive about the mail system to specify where their
mail is to be forwarded to, it is not feasible to exercise
"vigilance" over the setting up of forwarding.

Forwarding loops have not been a serious problem, but they
have occurred a number of times.  Typically the message
makes 500 to 1000 trips before someone notices, tying up a lot
of machine time and logging console paper continually logging
in FTP servers (we can tell how many because there seems
to be a bug that puts an extra CRLF on the end each time.)

Date: 8 SEP 1977 1747-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

I can see that there are many systems on which NIH's suggestion
can't be implemented.  But so what?  If there is one that can
and would like to, that should be considered acceptable by the
standards.  The others can do one of the other thins already
suggested.



Date:  8 SEP 1977 2357-PDT
From:  Tovar <TVR @ SU-AI>
Subject:  Oh, God.  Here we go again with Message-ID
To: RMF @ MIT-AI, NIH @ NBS-10, Postel @ USC-ISIB
cc:  Header-people @ MIT-MC
Message-ID: <SU-AI:TVR:8-SEP-77-2250:03.23:Msg-IDs:This-is-so-RMF-won't get-two-copies-of-this-and-also-gee-I-wonder-how-many-programs-use-fixed-length-fields-for-storing-these-things>
-----

    In reply to your message '1.2.BBBJGlkDWwGnK' [in which you
suggested that you might lose a few messages from MIT due to using
the DATE-TO-FROM-SUBJECT instead of message-ID] and '1.2.BBBJGlzJwklpnX'
[further comments and point about two instances of a user]
    Also in reply to NIH and Postel:

    First, I hope you understand that I am not advocated the prohibition
of message-IDs but rather temperance in their use.  Postel's comment
about being handy to reference with is a good one.  But the ones generated
by Multics are unwieldy at best.  Again, both a generated and a
reasonable-appearing unique message-ID would be handy in referring
to past correspondence.  But the ones I've seen so far
are either equivalent to a generated one (i.e. CMU's) or ridiculous
to use (Multics).
    I welcome a better message-ID, but as an option as opposed to something
tacked on every message.

    I asked a couple people to send me mail as fast as they could,
from MIT-AI to MIT-AI, to see how fast humans can generate messages
(with merely nonsensical content). The closest messages from RMS and
were two seconds apart, which required type-ahead and no body at all
to achieve.
    Using SAIL's line-editor to stuff commands at MIT-MC, I sent some
nearly identical one word messages, to check to see if the CPU speed
had anything to do with it.  (I considered that cheating slightly, as
the use of the line editor to send variations on the same message
made them nearly machine generated.  As it was MC couldn't quite keep
up).  In spite of that, I was able only once to get two messages with
time-stamps of only a second apart.  In this same trial (14 messages
total), I got three pairs of two seconds apart.

    As I typed this in, I came up with a much simpler argument: it's
just too hard to type that fast.  Consider a simple message, like the
simple answer, NO.  That would be require ':MAIL TVR NO^C' to send
this on ITS, one of the more terse systems around.  That is 13
characters per second!

    As far as RMF's comment about RMAIL is concerned, two things
can be said.  First, I think that is in the realm of machine-generated
mail and perhaps it should get a message-ID (but read on).  However,
RMAIL cannot switch messages all that fast, nor can a human read and
generate a reasonable response, so the example is a poor one.

    The point about two instances of a user is a good one, although not
exactly in terms which RMF put forth.  The more serious one is that of
two users sharing an account and sending mail to the same person at the
same time.  An obscure case, at that.  Perhaps mail programs could be wary
of this and check for another mail process (by for example, the existence
of a temperary file).  In this case, a message-ID might be generated.

    Another solution might be to put more resolution in the time field,
so that it is only possible for one process to have been running at a
given time.  (Multiple-CPU systems would have to do other mail process
check though).

1.  The addition of seconds to date of systems not having them is
    much nicer than a whole, redundant or unintelligible line.
2.  Programs which rapidly generate messages should use Message-IDs,
3.  Humans need not.  One would have to continuously type 30%
    faster than a Teletype to get even one message per second.
4.  Paranoid, duplicate message flushing programs could simply
    checksum the message if they wanted a fool-proof means of
    detecting duplications.

Date: 9 Sep 1977 0540-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Checksumming the message
To:   Header-People at MIT-MC    

This is the only "safe" way to flush duplicate messages since no message
ID is safe enough; a message could be replied to and sent back and have the
same message ID.  If I used a message flushing program I would not want it
to flush a message with a unique checksum since that means the message is
different in some way and I would want to investigate further to be sure it
is truly redundant.

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     9 September 1977 1216-edt
Subject:  checksumming and them some
Message-ID:  [MIT-Multics]1.2.BBBJGmDnmQpLGF
To:       header-people at MIT-MC

1. It won't work, my two copies of the messages from Tovar
have a different number of lines.

2. A reply will not have the same message ID as the original
letter.

3. All my messages are machine generated.

4. 13 cps is not all that fast to type. (Really!!!!
especially for a secretary or someone who has spent over a
decade on time sharing systems and uses terminal without the
mechanical limitations of a TTY33 for a short burst of typing.


5. Just because RMAIL is slow is no reason to limit your imagination.

Date:     9 Sep 1977 1253-EDT
From:     Brian Reid at CMU-10A
Reply-To: Header-People at MIT-MC
Subject:  Re: Checksumming the message
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  9 Sep 1977 12:53:54 Brian Reid
In-Reply-To: MRC's message of September 9, 1977

For once, I agree with Mark.
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     9 September 1977 1659-edt
Subject:  checksumming
Message-ID:  [MIT-Multics]1.2.BBBJGmFNgFMBkj
To:       reid at CMU-10a
cc:       header-people at MIT-MC

Mark and Brian,

1. Do you intend to include the header when checksumming

2. If so, then you disallow for a program that parses headers
as it reads the mail and regenerates a header when it sends
the mail.

2. I you are still talking about the body, then there are
still possible transformations that occur such as -----'s
that some systems put in letters. Note that some of the
letters I get would be manually forwarded versions of
earlier letters. These may very likely contain cruft like
the ----'s and white space transformations.

RMS@MIT-AI 09/09/77 19:29:41 Re: checksumming

    2. If so, then you disallow for a program that parses headers
    as it reads the mail and regenerates a header when it sends
    the mail.

What sort of a program are you talking about?  What is it doing?
I can only guess that it is either forwarding a message or replying
to one.

If it is replying, then this is irrelevant, since the reply is not
the same message as what it is replying to.

If it is forwarding, then I definitely consider it immoral for
it to alter anything, except perhaps in a standard way such as to
add a Forwarded-via field, which can easily be ignored by anyone
who is checksumming.

However, I think that there is no good reason for anybody to be
interested in checksumming messages.  While maliciousness or
accident can certainly generate confusing messages, who cares
what happens to them?  There is no reason to orient the whole
working of the system around the goal of not losing malicious
messages.



Date: 9 SEP 1977 1941-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: frankston at MIT-MULTICS
CC: header-people at MIT-MC

I don't see why you feel that it makes any difference
whether we can imagine systems on which we can send messages
faster than RMAIL can.

Any reason, no matter how silly or absurd, which nevertheless
guarantees that my messages will be unique without message IDs,
ought to entitle me to leave out message IDs.  Even if it is
just that my computer or my typing is slow.

And if someone else's computer or typing might be faster,
that is relevant only for him.  It can't possible make MY
messages fail to be unique.



Date: 9 SEP 1977 1941-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: frankston at MIT-MULTICS
CC: header-people at MIT-MC

I don't see why you feel that it makes any difference
whether we can imagine systems on which we can send messages
faster than RMAIL can.

Any reason, no matter how silly or absurd, which nevertheless
guarantees that my messages will be unique without message IDs,
ought to entitle me to leave out message IDs.  Even if it is
just that my computer or my typing is slow.

And if someone else's computer or typing might be faster,
that is relevant only for him.  It can't possible make MY
messages fail to be unique.



Date: 9 SEP 1977 1952-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Alternative to 724 proposed
To: header-people at MIT-MC

In RMS;XSYN > on MIT-AI you can find a file describing,
in the language of KLH;NEWSYN >, a complete alternative proposal
to the syntax of RFC 724 (actually, a few things from KLH;NEWSYN
that are not changed are merely cited, not reproduced, so you
should get a copy of NEWSYN for reference, and for comparison).

It also contains a couple of ideas for making formal language
specifications simpler, and a running commentary describing
what effect was desired from each set of changes made
and what the reasons behind it were.


Date: 9 SEP 1977 2307-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

I would like to know whether there is anyone who
has a need for the recipient-group feature of RFC 724.
Is this something actually useful to people I don't know,
or is it something being kept because tenex mailing lists
happen to have them?


Date:     10 Sep 1977 0022-EDT
From:     Brian Reid at CMU-10A
Subject:  Message ID fields
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 10 Sep 1977 00:22:55 Brian Reid

After brooding about message id's for a while, I think that we are
confusing two separate uses of the message-id concept.

Message-id fields generated by the sender of a message are intended
to be used for the bookkeeping purposes of the sender.  Thus, for
example, in commercial offices where correspondence is filed,
outgoing correspondence is often filed under what amounts to a
message-id.  The message-id is included in the output text in order
that the correspondent can refer to a particular letter (the
In-reply-to stuff).  I am heartily in favor of message-id fields like
this.  They are a very useful tool for the organization of mail and
replies.  However, the presence or absence of a message-id field
should be entirely up to the sender.  Requiring one in the message
standard would be ridiculous.

Message-id fields generated by the receiver of a message are an
entirely different animal.  Their uses might be to detect duplicate
messages, or to aid in the classification of messages in the
recipient's message system.  They can in no way substitute for
message-ids generated by the sender.

A program to compare two messages to determine if they are equal is
laughably simple.  Complaints like "my two copies had different
numbers of lines" or "they checksums were different" are just noise.
Of course a mail receiving program can do this comparison.  And when
I said that I agreed with Mark, which I still do, what I meant by
that was that I see the detection of duplicate messages to be the
recipient's job and not the mail protocol's job.  And the message id
has nothing to do with it.

				Brian
-------

Date:     10 Sep 1977 0030-EDT
From:     Brian Reid at CMU-10A
Subject:  Recipient groups
To:       RMS at MIT-AI (Richard M. Stallman)
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 10 Sep 1977 00:30:54 Brian Reid
In-Reply-To: Your message of September 9, 1977

Isn't Header-People a recipient group?
-------

Date: 10 SEP 1977 0037-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: brian.reid at CMU-10A
CC: header-people at MIT-MC

By recipient groups, I mean things of the form
FOO: so-and-so@host, who-else@host;
in To fields - the things that 724 calls "groups".
header-people@ms is simply an address, which happens
to forward to other names.  But that forwarding
is somethign totally outside what RFC 724 or XSYN tries
to talk about.


Date: 10 SEP 1977 0048-EDT
From: MOON at MIT-MC (David A. Moon)
To: HEADER-PEOPLE at MIT-MC

Reply to MRC's question about whether quoting characters are needed
in the real world.

They are used all the time in inter-ITS mail, where many recipient names
are actually file names and often contain funny characters.  This isn't
really relevant to RFC 724 since I doubt that we would use that protocol
for talking to ourselves, but the point is that you certainly need it.

Date: 11 Sep 1977 1016-PDT
From: BH at SU-AI (Brian Harvey)
Subject: An embarrassing confession
To:   header-people at MIT-ML    

It's been a while since I first read 724, and apparently I didn't
read it too carefully, but I've just re-read it, and I find the
following paragraph which indicates to me that 724 already supports
in principle the short-header camp's position on avoiding redundant
information in the header:

     I. Problems with ARPANET Message Standards                    / 5
     B. Issues and Conclusions

          7. Received messages are capable of  being  read  by  humans
             without  a  program having to parse the message (or parts
             of it) before presenting the message to the user; however
             there  is  sufficient  formal  syntax to enable a parsing
             program to modify the appearance and content of  material
             presented  to  users.   Although message-display software
             may   exercise   considerable   control   over    message
             appearance, the degree to which a message's actual format
             is  PLEASANT  for  humans  to  read   is   entirely   the
             responsibility of the message creation program.

This seems to me to be a remarkably statesmanlike presentation of the
idea that, on the one hand, the standard should encourage the development
of clever mail systems, but on the other hand, "If you had as good a mail
reader as HERMES you wouldn't be complaining" is not an acceptable answer
to the request to avoid things like identical From and Sender fields.

-------
(Message manually forwarded by Moon at MIT-MC.  Had been sent to
 Trailer-People at the wrong host.)

Date: 12 Sep 1977 2259-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: 724's support of short headers
To:   Header-People at MIT-MC    

There's this little bug in that though; you have these people who will want
to include every option in a message header just because "it's there".  I
hope that if and when 724 happens that the default will be the minimal header
and the sender will have to specify that the extra header information is
included.  Do others in the pro-724 agree with me on the default being just
Date/From + To/Subject if applicable?

Note to Bob Frankston; I hope Multics' mailer checks for obscenities in the
generated message-ID, especially if it is included in all Multics network
mail!  What would Colonel Russell say if Multics started being (horrors!)
"without redeeming social value"?  [Wow, that would be FUN!]

-------

Date: 13 SEP 1977 0535-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: Header-people at MIT-MC

Now, I don't really care about message ID formats too much, but
there's one strategem that nobody else has proposed yet.  It might
be reasonable to extend the "Date" field into a full postmark; that is,
include the originating location as well as originating time.  Such an
extension would be useful in its own right as a simple way to get the
sending-site name, and all it needs to make itself a message-ID is
a additional, optional uniquizing field.  I can't think of any such
uniquizer which would not fit nicely on the rest of the "Date" line;
Multics for example could even dump the whole of its weirdness there,
if it can't give just enough letters to round off a second.  To
equal a HERMES id, the uniquizer is just the sender name; to equal a
MIT id, just a small nmber; etc.
Date: 13 Sep 1977 (Tuesday) 0223:24-PDT [SRI-KL] 31415

Personally I think a slightly longer line (particularly this field) is
vastly less obnoxious than an extra line which usually coms between the
important fields and the message.  At any rate, this scheme provides
for a explicit uniquizer that doesn7t ned an extra field at all.


From:  Pogran at MIT-Multics
Date:  09/13/77 1129-edt
Subject:  Obscenity-screening
To:  MRC at SU-AI
cc:  Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJGmQnCXPDXm

Mark,

Turns out that the Multics Unique ID generator has always created
all-consonant strings for just that reason!

Ken

Date: 14 SEP 1977 0951-PDT
From: POSTEL at USC-ISIB
Subject: NEWSYN & XSYN
To:   header-people at MIT-MC


the effort that KLH and RMS have made to produce NEWSYN and XSYN requires the
close examination of the proposed standard that is necessary to engage in
reasoned discussions of various features and discrepancies in the draft
document. in particular the items that these proposals suggest could be dropped
should indeed be critically examined since they are either ill formed, or ill
motivated. i also feel that the introduction of type specific specifications
as RMS has made can help to clarify some otherwise fuzzy notions.

--jon.

-------

Date: 14 SEP 1977 0951-PDT
From: POSTEL at USC-ISIB
Subject: NEWSYN & XSYN
To:   header-people at MIT-MC


the effort that KLH and RMS have made to produce NEWSYN and XSYN requires the
close examination of the proposed standard that is necessary to engage in
reasoned discussions of various features and discrepancies in the draft
document. in particular the items that these proposals suggest could be dropped
should indeed be critically examined since they are either ill formed, or ill
motivated. i also feel that the introduction of type specific specifications
as RMS has made can help to clarify some otherwise fuzzy notions.

--jon.

-------

Date: 16 SEP 1977 1054-PDT
Sender: DCROCKER at USC-ISI
From: DCROCKER at USC-ISI
To: rms at MIT-MC
Cc: brian.reid at CMU-10A, header-people at MIT-MC
Message-ID: <[USC-ISI]16-SEP-77 10:54:05.DCROCKER>
In-Reply-To: Your message of SEPTEMBER 10, 1977    

The utility of having group names is in the resulting ability to
send around the entire mailing list, but only print its name to
the user.  Therefore, if header-people, as a single address, did
not exist, but I did have the addressess of its constituents, I
could do

header-people: 3000 addresses...;

and you r display program would only show "header-people:".

This is useful in the case of very temporary groups and groups
which are spontaneously-generated by an individual.  Having a
distribution mechanism like mit/mc...  has is an extremely high
degree of formality, in an organizational sense.  Group names are
useful in less formal situations.

Dave.
-------  

Date:     22 Sep 1977 1050-EDT
From:     Brian Reid at CMU-10A
Subject:  Mail privacy -- an informal survey
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 22 Sep 1977 10:50:02 Brian Reid

I just found out, sort of the hard way, that on MIT's ITS systems
everybody can (and does) read everybody else's mail.  I find that
this is not in keeping with my notion of `proper implementation'.
Here at CMU, for example, mail is as private as the operating system
will allow, which means that only operators can read others' mail,
and they are strongly discouraged from doing so.

I wonder just what the story is out there?  How many sites see mail
as public a la ITS and allow anybody to read others' mail, and how
many want mail to be private and use the operating system's best
privacy features to ensure that.

			Brian
-------

Date: 22 SEP 1977 1245-EDT
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Security, and XSYN
To: HEADER-PEOPLE at MIT-MC, Brian.Reid at CMU-10A

It's not really true that ITS considers mail files to be public; rather,
there is no security whatsoever on the system, and mail files simply
happen to be like all other files.  Other people can give much more
impassioned declarations of why ITS has been and will continue to be
this way, so I will defer to their eloquence if reasons are needed.
   I would of course prefer that my mail not be read by others, and I
can't imagine anyone who would not like this option available.  Very
few people here are habitual snoops, though I suppose that doesn't
help you much.
    -------------
With regard to XSYN; RMS didn7t announce that a slightly different,
tighter version is available (from RMS;XSYN > on MIT-AI as before),
and I like this very much.  Have Dcrocker, pogran, etc noticed that
groups are still compatible with this new addressee syntax, and using
comments serves just as well as delimiting machine addresses with
angle brackets?  If you think about how an address with a phrase AND
a mach-addr needs to be hacked, you'll see that an address with
comments requires the same sort of storage, filtering for FTP, etc.
For example,
      Ken Harrenstien <KLH@MIT-AI>
requires about the same processing as
      KLH at MIT-AI (Ken Harrenstien)
and amounts to a simplification.  I can't think of any very good argument
for the former as opposed to the latter; if someone has one, bring it
up and I will either accept it or rebuke it.  (Note that there is
no requirement that I use my full name in the former; that is, I
could just as easily say "Hungry Coeurl <KLH@MIT-AI>", which is just
as descriptive to my friends (and as confusing to computers as to
human strangers)).
   To get back to groups: they are all right with me, I guess; as I said,
they won't conflict with the basic ideas in XSYN of bracketing and
typing.
  Any news from cahcom?

Date: 22 SEP 1977 1339-EDT
From: MRC at MIT-AI (Mark Crispin)
Subject: Message security
To: Header-People at MIT-MC
CC: WD at SU-AI, RWG at SU-AI, JZS at CCA-TENEX

I am of the opinion that the only "secure" mailbox is an encrypted mailbox.

Trusting the operating system is faulty; system programmers and operators
can evade the restrictions if they so desire.  No protection mechanism can
stand long against an inquisitive wheel.

An incident last July where a message was copied from a protected mailbox
on a Tenex site and was forwarded along to certain parties with many
political reprecussions following underscores this.

There is another problem -- a legitimate receiver forwarding the message
without your consent.  This is perhaps even more serious since no protection
mechanism can help you in this case.

I consider my ITS and SAIL mailboxes to be as secure as my allegedly protected
mailboxes on Tenex, TOPS-10, and Multics sites.  The protection mechanism
just creates a privileged class of people who can spy on mailboxes.  I'm
afraid human nature comes into it; being privileged encourages one to use the
privileges even though before the person had no need for them, and there is
a thin line between use and abuse.  The person who spies on another prior
to linking to see if the other person is at an inconvenient point to get a
link is being courteous--but another person spying to "flip the channels"
is a spy, even though both are doing the same thing!

I don't want to argue about the morality of spying vs. not spying; it's clear
that invasion of privacy will never totally cease.  What you can do is
either put up the equivalent of "no trespassing" signs and hope they are
respected (my usual approach) or find a method that is more powerful than
the spy's for hiding your mail.

Encryption seems to be the only safe thing.  A new algorithm proposed by
Diffe (I think) et al uses the product of two large primes as the encryption
key; however the algorithm is irreversible.  Decryption requires knowing
the factors.  An enhancement suggested by McCarthy which lowers security
only slightly is to have a key phrase be the seed for the prime number
generator (the primes are on the order of 10 to the 60th I believe) so that
instead of a large number can be used.  As far as I know this algorithm
does not have any known method of breaking it, and is much more secure
than the NBS standard.

The beauty of the scheme is that the encryption key is public knowledge!

Then the only worries you have are making sure you are not tapped or other-
wise spied upon when you are decrypting and examining your mail.  How you
do this is up to you and depends on your operating system (one thing nice
about non-protected systems is that spies have a hard time hiding themselves
too!!) and your adversaries and is not a suitable topic for this forum.

I proposed encryption as part of a mail system independant of ARPAnet mail
(using a mail protocol rather than headers, and actual headers being minimal
of course!!), but the people whom I spoke to on this didn't give it the
favorable reaction I had hoped for and eventually I was forced to abandon
the idea.

I envision that DIALnet mail will have two mailing services, one of normal
semi-protected mail, and the other of encrypted mail, probably using keys
between clusters of users and not the network as a whole.


Date: 22 SEP 1977 1205-PDT
Sender: DCROCKER at USC-ISI
Subject: Re:  Mail privacy -- an informal survey
From: DCROCKER at USC-ISI
To: BRIAN.REID at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]22-SEP-77 12:05:54.DCROCKER>
In-Reply-To: [CMU-10A] 22 Sep 1977 10:50:02 Brian Reid  

The original implementation of MS, our Unix message system, had
completely open delivery mailboxes, for a short-term convenience,
but otherwise closes all read/write access to outsiders (i.e.,
other than owner's) for other message folders.  A recent mod will
allow closing the hole at the delivery mailbox.

Dave.
-------   

Date: 22 SEP 1977 1621-EDT
From: JZS at CCA
Subject: Joining the group
To:   Header-People at MIT-MC
cc:   MARS-Filer at CCA

Over the last few weeks, several people in their correspondence to me
have alluded to the "header people" -- but it wasn't until a couple
of days ago that I learned (from Dave Crocker during his last visit here)
that a group, with ARPANET mailbox, really existed.

He mentioned that there was at least a year's worth of interesting
mail regarding various aspects of developing message-handling programs.

I have been developing a message archiving package for CCA's
Datacomputer -- and would like to (1) join the group (2) read the
group's messages, and (3) investigate filing the messages on the
Datacomputer.

Thanks in advance for any information you can offer along these lines.

Joanne Z. Sattley
Sponsored Research Staff
Computer Corporation of America
-------

Date: 22 SEP 1977 1711-EDT
From: KLH at MIT-MC (Ken Harrenstien)
Subject: $ Have added JZS@CCA, pointed at files, etc. $
To: HEADER-PEOPLE at MIT-MC

(Aside to Stef: useful little convention isn't it?)

Date:     22 Sep 1977 1723-EDT
From:     Brian Reid at CMU-10A
Subject:  Filing Header-people on the Datacomputer
To:       JZS at CCA
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 22 Sep 1977 17:23:06 Brian Reid
In-Reply-To: Your message of September 22, 1977

Hmmm.
Read through the Header-people archives before you get any ideas about wanting
to stash them away in some permanent storage spot.
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     22 September 1977 1738-edt
Subject:  Privacy of Mail
Message-ID:  [MIT-Multics]1.2.BBBJGnGDnxxQhh
To:       header-people at MIT-MC

Need I say what Multic's attitude is.

Date:     22 Sep 1977 1736-EDT
From:     Brian Reid at CMU-10A
Subject:  mail privacy
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 22 Sep 1977 17:36:12 Brian Reid

Hmm.
I think that mailboxes differ fundamentally from files in that they
are in a sense the property of the person who sent the message.

The disk files on my account at CMU are not protected, and never will
be.  I put them there, and I understand the various ways that the
masses can read them, if they should be so foolish as to want to.
But my MAILBOX is another story.  The mailbox is protected as a
courtesy to the people who send me mail.

I think that reasonable privacy is an extremely important part of a
message system.  With regard to MRC's remarks, it's true that privacy
is relative; regular mail can be steamed open, for example.  The way
that people use a mail system will change dramatically if they don't
believe that there will be reasonable privacy on the other end.

Diffie's encryption algorithm (as written up in Scientific American a
few months ago) seems ideal in that respect.  A mail delivery program
can use the (public) encryption key to encrypt a user's mail as it
appends it to his mailbox.  This can be purely local-option, and not
at all a part of any message standard.  On the other hand, I find it
very annoying, for example, that I cannot send a message to a person
at an ITS site without feeling that anybody else at that ITS site
will be able to read it.  If the recipient of the mail wants to
unprotect it, or send it around the net, or put it on the bulletin
board, that's the breaks.  But it sure is a pain to have other people
reading X's mail before X sees it, even.

Richelieu once said "Never destroy a letter, and never write one."
Maybe that's the best ploy.

			Brian
-------

Date: 22 Sep 1977 1430-PDT
Sender: GEOFF at SRI-KA
Subject: Re: Security, and XSYN
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: KLH at MIT-MC
Cc: HEADER-PEOPLE at MIT-MC, Brian.Reid at CMU-10A
Message-ID: <[SRI-KA]22-Sep-77 14:30:14.GEOFF>
In-Reply-To: Your message of September 22, 1977

I for one am against the form:

From: Geoff Goodfellow <GEOFF@SRI-KA>

because most systems don't have the personell data base that will
contain all the names of their users, and some systems in fact
may not want that to exist either (although I can't imagine why),
and as far as I know the only systems that do this on a regular
basis are the ITS sites, and SAIL, and the SRI machines have it
optionaly available, so then you are going to end up getting:

From: <GEOFF@SRI-KA>

most of the time for everyone.  I think it is MUCH more easyer
(and looks better too!)  to have it of the form:

From: Geoff at SRI-KA (Geoff Goodfellow)

and have the mail program just flush anything after the host
name, and if you don't have the personell name data it looks much
more pleasing, becuase the person's 'real address' is in the same
place.  I think it is much nicer to stick optional things after
objects, rather than in front of them, because then it doesn7t
change the ordering of things.

[Geoff]
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     22 September 1977 1751-edt
Subject:  filing header people mail
Message-ID:  [MIT-Multics]1.2.BBBJGnGFfJxLPC
To:       jzs at CCA-TENEX, brian.reid at CMU-10a
cc:       header-people at MIT-MC

Actually, it would be very nice to have a standard place to
refer back to old mail. Something a long the lines of a
mailbox-id on CCA that writes to a DFTP-readable  file would
probably be most useful.  A line with the subject and
message-id written to a file also stored would provide a way
of getting at a desired message.

There are also archive files on ITS containing old
header-people mail and a more recent one (last year or so)
on Multics.

Date: 22 Sep 1977 1455-PDT
Sender: GEOFF at SRI-KA
Subject: Re: Message security
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: MRC at MIT-AI
Cc: Header-People at MIT-MC, WD at SU-AI, RWG at SU-AI, 
Cc: JZS at CCA-TENEX
Message-ID: <[SRI-KA]22-Sep-77 14:55:41.GEOFF>
In-Reply-To: Your message of September 22, 1977

You spent the major part of your message saying that encryption
is the only way to send mail to people so that nosy wheels and
flaws of the operting system can't be exploited in snooping in on
your mail.  The best line is "No protection mechanism can stand
long against an inquisitive wheel" I certinly hope you included
your encryption scheme in that list of 'protection mechanisms'.

Even though you maybe able to prevent me from reading your mail
at my convinece, but sooner or later you are going to get around
to printing that mail (to see it yourself!)  and if I am clever
enough I can just have the system set up so that all output you
might generate goes into some file somewhere, including your
de-ciphered message, as well as any keyboard input you may enter.

Basicly, there are a 69 ways to make it harder for me to get at
your mail using the computer, but it is clearly impossible for
you to prevent that 'inquisitive wheel' from doing so.

If you are concerned about bad guys looking in our you mail, you
should do what they have done down at NOSC in San Diego, all
terminals and computers are in a lead room, and you have to have
TOP SECRET clearnce to gain access; but then again, what keeps
the people with top secret clearence from being bad....  You can
certinly take measures to prevent lots of people from gaining
access to 'secure' data, but there isn't a snoballs chance in
hell of keeping that inqiuisitve wheel from it.
-------

Date: 22 Sep 1977 (Thursday) 2202-Est
From: STECKEL at HARV-10
Subject: COMPLEAT SECURITY
To:   HEADER-PEOPLE at MIT-MC

IN REFERENCE TO ENCRYPTION & SECURITY, THE MICROCOMPUTER
CERTAINLY GIVES US THE REMOTE POWER THAT IS NECESSARY TO HIDE
OUR MESSAGES AT HOME.  THE NBS STANDARD (MAY IT WITHER AWAY)
HAS ALREADY BEEN COMMITTED TO SILICON WHICH ONE MIGHT PLUG INTO
ONE'S TERMINAL.  THE TI'S, DIABLO'S ETC. WHICH CONTAIN 8080'S  (MAY
THEY ALSO GO BACK TO PROCESS CONTROL LIKE THEY WERE DESIGNED FOR)
WHICH ARE QUITE SMART ENOUGH TO PROCESS THE ALGORITHM DESCRIBE

Date: 22 Sep 1977 (Thursday) 2211-Est
From: STECKEL at HARV-10
Subject: INCOMPLETE MESSAGE
To:   HEADER-PEOPLE at MIT-MC

...DESCRIBED IN MARTIN GARDNER'S COLUMN.  THE LEAD ROOM CRACK
IS TOO GRANDIOSE; A BATTERY-POWERED MICRO IN A COPPER BOX THE SIZE
OF A BREADBOX IS QUITE SUFFICIENT; THE MESSAGE
COULD BE RECORDED ON CASSETTE OVAR THE PHONE LINE, PLACED INSIDE
DECRYPTED (PROBABLY OVERNIGHT) AND HARD-COPY TAKEN OUT WHEN DONE.
SERVE HOT.  THE DIALNET FOLKS WILL PROBABLY HAVE
SOME WAY TO DO IT SOON...  AND ANY WHEEL WHO WANTS TO SEE MY MAIL
WILL HAVE TO KNOCK ON MY DOOR FOR IT, JUST LIKE ANY OTHER
<INSERT-ARBITRARY-BUGABOO> AGENCY.   HOWEVER, AS LONG
AS I KEEP MAIL ON MY TOPS-10, IT WILL BE THUMBED THROUGH BY
ANYONE WITH THE INCLINATION AND ENOUGH ENERGY TO WALK TO THE
OPERATOR'S CONSOLE.  MEANWHILE, THERE IS SOME CONSOLATION THAT
(ACCORDING TO CONGRESSIONAL HEARINGS BROADCAST OVER A LOCAL STATION)
THE NSA HAS INSUFFICIENT LISTENERS OR COMPUTER POWER TO LISTEN
TO ALL PHONE CALLS SO (ITALICS) THEY HAVE BEEN SPREADING THE RUMOR
THAT THEY (THE NSA) HAVE DONE SO TO DISCO

Date: 22 Sep 1977 (Thursday) 2215-Est
From: STECKEL at HARV-10
Subject: LAST COUPLE OF LINES
To:   HEADER-PEOPLE at MIT-MC

...DISCOURAGE FOREIGN AGENTS FROM USING THE TELEPHONE.
OH WELL, RUMOR OR FACT, THE POSSIBILITY IS AWESOME:
TO ENSURE PRIVACY, TALK ALL THE TIME SO THAT THERE WILL
BE NO WAY FOR ANYONE TO LISTEN; SEND YOURSELF 10 TO THE 10'S
OF MESSAGES AND NO-ONE WILL EVER BE ABLE TO GET ANY
INFORMATION OUT OF THEM.  (CNSIDER THE LAST 1 1/2 OF MINE
IN THAT CLASS IF YOU LIKE)


From:  Pogran at MIT-Multics
Date:  09/23/77 1103-edt
Subject:  Mailbox security and our model of computer-based mail systems
To:  Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJGnHwKZkJdl

Just a few words (paragraphs?) about mailbox security, etc.:

The model that most of us have in our minds for how private our
computer mail should be is that of First Class US Postal Service
mail which is delivered to our (hopefully locked) home mailbox,
and we've been discussing how close our various host systems can
come to treating our computer mailboxes that way.  The positions
range from, "Can't come close at all, because our system has no
file security", to "Comes close; mailboxes are secure on my
system" (but then paranoia strikes: "A wheel can breach mailbox
security if he wants to snoop").  I originally started out
writing a note about mailbox security, but eventually ceased, as
I wasn't saying anything new, other than to note that Saltzer has
pointed out in some paper or other (I'll dig it up if anyone's
interested) that, in the appropriate environment, a system wheel
(whom he calls a "locksmith") can be bonded, just as a real-life
locksmith is bonded, to guarantee, for example, that he will NOT
snoop around your apartment when he picks your lock to let you in
after you lost your key.

What I want to address in this note is the notion that perhaps
our model is wrong; perhaps our model should be that of the
corporate mail room, where mail is only as private as corporate
policy allows it to be.  To illustrate:  I remember reading
somewhere, just a few days ago, that an employee sued his
employer for opening a piece of mail which arrived, via USPS, at
his company address.  It was first class mail, it was marked
"private" on the outside, but the corporate mail room opened it
-- which was corporate policy.  Apparently, the employee claimed
to have suffered some loss due to the fact that his ostensibly
private mail was opened.  The employee lost; the law is that ANY
mail addressed to someone at his business address may be treated
by the business's mail-receiving entity as the business sees fit,
because legally the mail is deemed to be addressed to the
business.

By analogy, then, even if the ARPANET could guarantee to deliver
mail to a host in a secure fashion (which it can't), we have no
right (though we may have the desire) to have our mail kept
private by our host system.  The mail is delivered to the host.

We could envision a system which offers a "secure mailbox
service", with which users could contract, which would
contractually obligate itself to keep received mail secure.
Then, if a system wheel spied on a user's mailbox, the "secure
mailbox service" would be liable for breach of contract.  It
COULD be done, in the context of the ARPANET.  It COULD be done,
with operating systems which exist today.  I suspect that it WILL
be done, when there is a public network on which electronic mail
is a tarriffed service.

To summarize:  We should keep straight in our minds what the
MODEL for computer mail service should be, what is TECHNICALLY
feasible, either today or in the future, what is practiced
ADMINISTRATIVELY today (i.e., Do you trust your local "system
wheel"?), and what can be achieved LEGALLY or via CONTRACTUAL
OBLIGATION.

'Nuff said.

Ken Pogran

Date: 23 Sep 1977 0802-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: How secure is secure?
To:   Header-People at MIT-MC    

I agree with Geoff (Steckel) that the best way is not to decrypt at the
computer, but at the terminal, where presumably the terminal's owner is
the only wheel.  Generating the primes should be done there too to plug
that problem as well.  I don't trust the sanctity of anything unless it
is locked up at home.

-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     23 September 1977 1121-edt
Subject:  cryption
Message-ID:  [MIT-Multics]1.2.BBBJGnHxKnBckf
To:       header-people at MIT-MC

Encryption is not the solution to the world's problems.
While it is useful for communication lines and maybe mass
storage devices, it is difficult to keep data encrypted
while processing it. For example,  one would want to at
least keep the header in clear text so that one's mail
processing program might have access to it.  Also a letter
must be recrypted each time it is passed between domains of
authorization.  If A sends B  3 a letter who decides the
encryption key. If I have to remember more than one
encryption key I must rely on the computer to manage them
and thus ultimately rely on the computer for keeping them
secure.  This is the same problem that occurs on systems
that rely on passwords for each file for security -- you
can't reemember them all so you keep them in a file or
worse, on a piece of paper.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     23 September 1977 1121-edt
Subject:  cryption
Message-ID:  [MIT-Multics]1.2.BBBJGnHxKnBckf
To:       header-people at MIT-MC

Encryption is not the solution to the world's problems.
While it is useful for communication lines and maybe mass
storage devices, it is difficult to keep data encrypted
while processing it. For example,  one would want to at
least keep the header in clear text so that one's mail
processing program might have access to it.  Also a letter
must be recrypted each time it is passed between domains of
authorization.  If A sends B  a letter who decides the
encryption key. If I have to remember more than one
encryption key I must rely on the computer to manage them
and thus ultimately rely on the computer for keeping them
secure.  This is the same problem that occurs on systems
that rely on passwords for each file for security -- you
can't reemember them all so you keep them in a file or
worse, on a piece of paper.

Date:     23 Sep 1977 1151-EDT
From:     Philip Karlton at CMU-10A
Subject:  Re: How secure is secure?
To:       Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A] 23 Sep 1977 11:51:21 Philip Karlton

If people are really going to worry about security then they should
take the time to read some of the procedures used by the military.
Things like who is talking to whom or even the frequency with which
one party sends or receives messages must often be hidden.  The thing
that the military probably does best is deal with information hiding.

I actually do not think this discussion belongs in Header-People and
invite all you Security-People to start a new group somewhere else.

               PK
-------

Date: 23 Sep 1977 1139-PDT
From: BH at SU-AI (Brian Harvey)
Subject: security
To:   header-people at MIT-MC    

The trouble with Brian Reid's notion of security as a courtesy to the sender
is the same as the trouble with message-id's as a courtesy to the receiver:
the decision must be made at the wrong end of the chain.  If there were some
practical way for the sender's computer to secure a message, that'd be nice.
(I just thought of one: put the thing in your own file directory, call up
your corrrespondent on the telephone and tell him your password.)  (Yes I
know, telephones aren't secure.)  I think what we should learn from the
military, actually, is to treat computer mail the way they treat autovon:
their phone books say THE TELEPHONE IS NOT A SECURE MEDIUM in great big
letters and they leave it at that.  Personally I can't understand how
anybody who has ever tried to get any work done on a computer with
security can possibly want any.

-------

Date: 24 Sep 1977 1042-PDT
From: Feinler at SRI-KL
Subject: 'Secure' mail
To:   header-people at MIT-MC
cc:   feinler

I think Ken Pogran pointed out that what most of us are thinking
of in terms of network mail is something as secure as First Class
U.S. Postal Mail, but if one thinks about it U.S. First Class mail
is really secure mostly by agreement and etiquette since it is
certainly physically possible to get at almost anyone's mail
(on my street we don't have locked mailboxes and even if we did
they wouldn't present much of a challenge to someone who was 
really intent on opening them.  

On the other hand there is a very strong sense of agreement that
reading someone else's mail is a pretty rotten thing to do unless
you have that person's permission.  I have often wondered why
that etiquette and agreement breaks down so badly on computers.
Anyway, I feel the same kind of restraints should be applied to
computer mail, if possible, as to hardcopy mail.  If someone tampers
(i.e., reads) my mail I would like to see
some message that 'XYZ has accessed your mail file' if that person
is known.  Otherwise I would like a message saying when was the
last time my mail file was accessed.  Presumably if it is accessed
frequently by someone using my password who is not me, I can note
this and either change the password or set my own kinds of traps
to try to find who it is.  It would be useful to note
from which host the access was made.

This would probably be enough security for most cases.
If someone is found to be a bad offender, drum him out of the
corps by refusing him mail service on all hosts (hmmmm, could
we call this 'arresting' him/her?).

Really secure mail should be a separate issue in my estimation, since
95% of anybody's correspondence (including corporate and military)
doesn't need to be guaranteed secure. The sheer volume of computer
mail traffic means that it would be a drag to monitor very many 
person's messages surreptitiously and my suspicion is that most
people monitoring mail that doesn't belong to them are doing
it on their local host and can be dealt with locally.


(As mail goes, consider this 2 cents worth)

Jake
-------

Date: 24 Sep 1977 (Saturday) 1446-Est
From: STECKEL at HARV-10
Subject: discusive digression
To:   header-people at MIT-MC

Jake Feinler's comments seem to the point.  What we have on the net is
much closer to the "corporate" aspect though.  I received a warning
about 18 months (+ - 10) ago that all net traffic through RAND
was being monitored, especially network mail.  However, I also have
people on my host who strongly believe that they have some sort
of contractual relationship which makes Harvard liable for the security
of their net mail.  Schizophrenic situation, no?

The normal courtesies seem to break down for several reasons, perhaps
most of all that there is nothing either tangible or "personal" about
a bit pattern on a disk surface.  If I'm using this >shared< machine,
I can wander all over it, and I'll share the pieces I want to share...

Anyway, I gotta go read latest update to XSYN of however many days ago.
	Geoff Steckel


Date: 24 Sep 1977 at 1148-PDT
Subject: re: mail security
From: Mike at Rand-Unix
To: Header-People at Mit-Mc
Message-ID: <[Rand-Unix]24-Sep-77 11:48:12.Mike>

I have never assumed that any communication system is secure,
whether it be Network mail, Ma Bell, or the US Postal Service.
All evidence is strongly to the contrary.  When Rand started
spying on netmail on a regular basis as a part of corporate
policy, I thought it was tacky, but I didn't change my mailing
habits much.  [Just a bit more discretion perhaps, which is not a
bad thing in itself.] Thus, the fact that network mail is not
completely secure and probably never will be does not surprise or
dismay me even a little bit.

On the other hand, there is a very large difference between a
corporation inspecting incoming mail on a professional level, and
some random hacker munging around through someone else's files to
see what is going on.  Further, I think that any wheel which is
going to read someone else's mail without permission is not
mature or professional enough to be a wheel on a system where
work is being done.

If your system has some reasonably secure file system, then
protect the mail files and, beyond that, encourage the notion of
respecting the privacy of other people within the community.
Once you get more complicated than this (encryption of every
message, etc.), you may get more security, but only at the cost
of making a mail system expensive and difficult to use.


Mike Wahrman.

Date: 24 Sep 1977 1202-PDT
Sender: GEOFF at SRI-KA
Subject: Re: discusive digression
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: STECKEL at HARV-10
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA]24-Sep-77 12:02:49.GEOFF>
In-Reply-To: Your message of September 24, 1977

The reason why network mail (both in and out) is monitored at the
RAND hosts is because it is corporate policy to open all incoming
mail unless it is marked personnel, and we all know that the
network is not to be used for communications of that nature, and
that was another way of making sure that RAND people were "good
boys" in that respect.

In lieu of an unfortunate incident that happen about a year and a
half ago, they saw the network as a "hole" in their corporation
wide policy, they instantiated the mail spy....
-------

From:  Pogran at MIT-Multics
Date:  09/26/77 1043-edt
Subject:  Responses to Feinler and Wahrman
To:  Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJGnWWbzjLJn

I agree with Mike Wahrman's comments regarding the maturity of
system wheels.

Jake, did you ever stop to think that if a system were capable of
reliably placing a message in your mailbox saying, "So-and-so has
accessed your mailbox", that system is also likely to have the
capability to prevent So-and-so from accessing your mailbox in
the first place?  That is, if the system can guarantee that if
someone accesses your mailbox, that fact will be recorded, and
the accessor's identity will be unforgeably  recorded, then the
system must be capable of guaranteeing that the mailbox cannot be
accessed without that record being made.  If a system can
guarantee that, then it essentially guarantees that its access
constraints cannot be violated.  If this is so, then the system
security design must contain all the essentials for controlling
access to objects in the first place -- and could have been
implemented so as to keep your mailbox as secure as you'd like!

Moral:  If a system can't provide mailbox security, it isn't
going to be able to tell you who's accessed your mailbox, either.

Regards,
 Ken

