Date: 10 June 1980 1251-EDT (Tuesday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
Subject: bogus headers in mail
To:  Header-People at MIT-MC
CC:  Howard.Wactlar at CMU-10A
Message-ID: <10Jun80 125100 RG02@CMU-10A>

Given the stink that has been made about our spaces in names, which are
perfectly legal, why are we still being inflicted with the TENEX
generated addresses of the form
	[Site]<directory>FILNAME:
such as the one I keep getting
	[SRI-KL]<NETINFO>liason-sndmsg.txt:

Isn't it about time that the TENEX sites cleaned up their acts as well?

		Rick

Date: 13 June 1980 1134-EDT (Friday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
Subject: CMU-10a will be down for a week
To:  Feinler at SRI-KL
CC:  MsgGroup at MIT-MC, Header-People at MIT-MC
Message-ID: <13Jun80 113458 RG02@CMU-10A>

CMU-10a will be down for about 10 days starting this evening.  We are
moving the machine to a new room.  If any of you have automatic mail
delivery programs which give up after less than a week you might
consider taking appropriate action.  Our scheduled return to the net is
on Monday, June 23, but that date is somewhat tentative either way.

For urgent mail, many of the CMUA users who have regular dealings with
the network community also have mailboxes on CMU-10B and/or CMU-10D.
You can check by TELNETing to one of those sites and saying (without
any LOGIN needed)
	FINGER <user>
(or by using your local FINGER, if you have one).  In general, all
addresses on the two alternate machines are identical to those on CMUA,
except for the host name, of course.

		Rick Gumpertz

Date: 24 June 1980 1605-EDT (Tuesday)
From: Brian Reid at CMU-10A
Subject: Mail to CMUA lost
To:  BBoards: News at BBN-Unix, BBoard at CMU-10A, BBoard at CMU-10B,
     BBoard at CMU-10D, News at EDN-Unix, *MAC at MIT-MC, News at NPS,
     BBoard at Rand-AI, BBoard at Rutgers, BBoard at DARCOM-KA,
     BBoard at SRI-KL, BBoard at SRI-Unix, BBoard at SU-SCORE,
     BBoard at SU-AI, Bulletins at SUMEX-AIM, BBoard at USC-ISIB,
     BBoard at USC-ISIE, BBoard at USC-ECL, BBoard at Utah-20;,
     Net-Users: MsgGroup at MIT-MC, Header-People at MIT-MC; 
Message-ID: <24Jun80 160504 BR10@CMU-10A>

Essentially all mail delivered to CMUA between June 13 and June 24 was
lost in a head crash today and should be resent if it was important.

Date: 18 SEP 1980 2024-EDT
From: MOON5 at MIT-MC (David A. Moon)
To: HEADER-PEOPLE at MIT-MC

The Header-People mailing list has been broken for a few weeks.  It is
fixed now.  Here is the mail that you didn't see.  (Not very exciting,
it just deals with headers.)

Date: 17 Sep 1980 0012-EDT
From: GEOFF at DEC-2136
To: Header-People at MC
Subject: DEC's MS takes the lead in the meaningful MESSAGE-ID Dept.
Message-ID: [DEC-2136].11665191777.21.8589934664.22967

Move over Multics!
   --------
Date: 17 Sep 1980 1611-EDT
From: GEOFF at DEC-2136
To: Header-People at MC
Subject: DEC's MS MESSAGE-ID's surpass Multics's for obsecurity.
Message-ID: [DEC-2136].11665366441.14.8589934664.1520

Anyone care to take a guess what it all stands for?  
Geoff

Date: 21 Sep 1980 22:12 PDT
From: Stewart at PARC-MAXC
Subject: message addresses
To: Header-People@AI
cc: Stewart

From: web <DSP.DOVE at MIT-SPEECH at MIT-AI>
Do any of you know of a way to get this past a Tenex mailer as a To: address?

	-Larry



Date: 22 Sep 80 09:03-EDT (Mon)
From: Dcrocker at Darcom-HQ
Subject: Re: message addresses
To: Stewart at Parc-Maxc
cc: Header-People at Mit-Ai
Message-ID: <80265.32584.6980 @ Darcom-HQ>
In-Reply-To: Your message of 21 Sep 1980 22:12 PDT

    I don't know how to get it past the user program, so that it
is queued.  However, having it queued under the filename

[---unsent....].dsp^V.dove^V at^V mit-speech@mit-speech

should work.  (Not sure about the @... stuff or the exact
sequence for the unsent-mail portion.)

    For reference, puting the mailbox part (dsp...speech) in
double quotes would be the way to get it past an RFC733 parser,
which no one has a full implementation of...

    (Sorry for all the ellipses, but it's early in my morning and
nothing feels complete.)

Dave (DCrocker @ UDel).

p.s.  are you sure that the mit-ai ftp server will handle

	dsp.dover at mit-speech

      in its MAIL or MLFL command line?



Date: 22 Sep 80 18:29:32-CDT
From: Rich Zellich <ZELLICH at OFFICE-1>
Subject: Re: message addresses
To: Stewart at Parc-Maxc
Cc: Header-People at Mit-Ai, Dave Crocker <DCROCKER at DARCOM-HQ>,
    "DSP.DOVER at MIT-SPEECH" at MIT-AI
In-Reply-To: <80265.32584.6980 @ Darcom-hq>

Dave is right - the indicated sequence works fine.  I wonder what both
the MIT-AI server did with DSP.DOVER AT MIT-SPEECH and, if it was
actually delivered, what the MIT-Speech system made of it because I
didn't send an RFC733-standard message, but merely a 6-character file
containing "test<CR><LF>"....

I don't know how to get it past the Tenex user programs, either, but
you can always put a temporary address in place of the one you want,
tell the program (MSG, HERMES, etc.) to Queue it instead of sending
immediately, and then rename the appropriate [--UNSENT-MAIL--].* file
to the address you really want.

Cheers,
Rich


Date: 22 Sep 1980 1644-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: message addresses
To: Stewart at PARC-MAXC
cc: Header-People at MIT-AI
In-Reply-To: Your message of 22-Sep-80 0603-PDT

Yes, MIT-AI is quite capable of handling an address of the form
	DSP.DOVER@MIT-SPEECH
in its MAIL or MLFL command line.  So it SCORE's FTP server; and
the MM mailsystem is also capable of processing such multiple
host addresses.  We've been sending mail back and forth between
Chaosnet and ARPANET sites using MM/XMAILR for quite a while now.
MM actually doesn't need to be told that MIT-SPEECH has to be
reached via MIT-AI or some other MIT ARPANET site; MM works it
out for itself and lets XMAILR have the option of selecting the
route (XMAILR will pick another host if the first host it tries
is down).

By the way, Dave, where and what is DARCOM-HQ?  It ain't in my
host table.  If it's a nickname, allow me to express my antipathy
towards mailsystems which neglect to convert user-entered nicknames
to official names before sending messages out on the network.

-- Mark --
-------


Date: 22 Sep 1980 1659-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: addition to previous message
To: Header-People at MIT-MC

I should add that DEC's MS mailsystem (a cousin of MM which had a common
ancestor about two years ago) is also capable of handling such addresses
and of comprehending Chaosnet hosts without any routing specification if
the user's site has the multi-network HOSTS2 host table available (see my
RFC circa January '79 for more details of HOSTS2; HOSTS2 is the official
host table at SU-AI, SU-SCORE, and most MIT systems).

I had thought that HERMES would be dumb enough to not be smart enough to
barf on that type of address.  It was certainly the intent in the design
of that format of address that it be legal and presumably other mailsystems
would be capable of handling it if they merely treated "FOO@MIT-SPEECH"
as a literal address to send to MIT-AI's FTP server.  There probably are
bugs in the old Tenex mailer daemon which make this impossible, though.
-------

Date: 22 Sep 1980 1644-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: message addresses
To: Stewart at PARC-MAXC
cc: Header-People at MIT-AI
In-Reply-To: Your message of 22-Sep-80 0603-PDT

Yes, MIT-AI is quite capable of handling an address of the form
	DSP.DOVER@MIT-SPEECH
in its MAIL or MLFL command line.  So it SCORE's FTP server; and
the MM mailsystem is also capable of processing such multiple
host addresses.  We've been sending mail back and forth between
Chaosnet and ARPANET sites using MM/XMAILR for quite a while now.
MM actually doesn't need to be told that MIT-SPEECH has to be
reached via MIT-AI or some other MIT ARPANET site; MM works it
out for itself and lets XMAILR have the option of selecting the
route (XMAILR will pick another host if the first host it tries
is down).

By the way, Dave, where and what is DARCOM-HQ?  It ain't in my
host table.  If it's a nickname, allow me to express my antipathy
towards mailsystems which neglect to convert user-entered nicknames
to official names before sending messages out on the network.

-- Mark --
-------


Date: 23 Sep 80 13:11-EDT (Tue)
From: Dcrocker at UDel
Subject: hostnames & from fields
To: Header-People at Mit-Ai
Message-ID: <80266.47474.9100 @ UDel>

    First of all, let me apologize for the fact that mail has
gone out from this site with host references to Darcom-HQ.  The
apology is not for my/our error, but for the inconvenience.  In
fact, it was intentional and unavoidable.

    We notified Jake Feinler of the synonym, but that takes time
to propogate and we could not wait for everyone's host table to
get updated.  You will note that we are now using the official
hostname.

    Second, UDel-EE has always and only been a synonym and that
didn't bother people, because it was in the host table.  Hence,
Mark's concern is a little misplaced.

Now, the reason for the hassle:

    The machine which calls itself "UDel" and is attached to the
arpanet is a Darcom (army) machine which we have an are using for
some mail-relaying work we are doing for them.  For a period of
time, I had to have our software think of itself as Darcom-HQ, so
that we could get a version of it down to an unattached machine
in Washington.  It will relay through us, so eventually, it will
be passing mail onto the net under the name Darcom-HQ.  This is
identical with the way we have been sending mail out of Rand
under the name UDel-EE, for over 1 1/2 years.

    This morning, I converted our system to think of itself as
UDel.

The official set-up is to become:

    UDel-EE is no longer a synonym for Rand-Unix.

    Host 114(decimal) is UDel, official name.  The official
synonym is to be Darcom-HQ.

    Other synonyms are to be:  UDel-EE, UDEE, and Delaware.

Dave.



Date: 23 Sep 1980 1227-PDT
From: POSTEL at USC-ISIF
Subject: Re: hostnames & from fields
To:   Dcrocker at UDEL, Header-People at MIT-AI
cc:   POSTEL

In response to the message sent  23 Sep 80 13:11-EDT (Tue) from Dcrocker@UDel


Dave:

Host 114 decimal?  I think it is time we started using "new" format
numbers.  Is that host 0 on imp 114, or host 1 on imp 50?

--jon.
-------


Date: 23 Sep 80 16:42-EDT (Tue)
From: Dcrocker at UDel
Subject: Re: hostnames & from fields
To: POSTEL at Usc-Isif
cc: Dcrocker at Usc-Isif, Header-People at Mit-Ai
Message-ID: <80266.60144.8260 @ UDel>
In-Reply-To: Your message of 23 Sep 1980 1227-PDT

The Arpanet Directory show us as 1/50.  I'll assume that is
correct.

Dave.



Date:  27 September 1980 15:14 edt
From:  Sibert at MIT-Multics (W. Olin Sibert)
Subject:  NBS Computer Standards
Sender:  Sibert.Multics at MIT-Multics
To:  header-people at MIT-AI, human-nets at MIT-AI, 
     msggroup at MIT-AI

The following cheerful news is brought to us by the September 29 issue
of Computerworld. Copyright (c) 1980 by CW Communications, Inc.

Following ANSI guidelines: NBS to Give Format Standards Over Four Years

Chicago - The National Bureau of Standards (NBS) will release over the
next four years a series of format standards aimed at improving computer
communications and integration and at aiding electronic mail
transmissions between automated offices.

The MBS-sanctioned standards - five in all - will be voluntarily
developer by the user and vendor community, following American National
Standrads Institute (ANSI) guidelines and processing requirements,
according to James H. Burrows, director of the NBS' Institute for
Computer Science and Technology (ICST). The ICST manages the
governmentwide computer standards program and provides technical
assistance to federal agencies.

At the recent National Symposium on Office Automation, sponsored by the
Data Processing Management Assicoation's Education Foundation (DMPA)
here, Burrows gave a brief outline of each of the proposed protocol
standards. The NBS standards will include:

1) A message interchange format standard, which will allow users of one
system to send and receive messages from a foreign system.

2) A flexible disk format standard to establish common file formatting
and labelling for flexible disks.

3) A text editing directives standard that will establish a common set
of user directives for text editing systems.

4) A text formatting directives standard to provide directives for text
formatting systems.

5) A message processing directives standard establishing a common set of
directives for computer-based message systems.

The latter three standards will provide a minimal level of
functioanllity and help users switch from one text editing, formatting,
or message system to another, Burrows explained.

As a flagship for these five standards, the NBS is planning to release
several guidelines geared to help users plan for, select, and evaluate
computer based office machinery. The first guideline, "requirements
analysis for office automation systems", which Burrows said will be
available in late October or early November, will recommend a process to
measure the benefits of office automation.

Drafts of the requirements analysis guideline have already been
circulated to a number of federal agencies and vendors for comments.

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

It all sounds kinda familiar, doesn't it? Remember NETED? Standard mail
systems, described in an RFC too old for me to remember? Since the
ARPAnet technical community has already been through exactly this same
process, perhaps we should provide some input; presumably Mr. Burrows is
the person to talk to.


Date: 27 Sep 1980 1623-EDT
Sender: DDEUTSCH at BBNA
Subject: Re:  NBS Computer Standards
From: DDEUTSCH at BBNA
To: Sibert at MIT-MULTICS
Cc: header-people at MIT-AI, human-nets at MIT-AI, 
Cc: msggroup at MIT-AI
Message-ID: <[BBNA]27-Sep-80 16:23:12.DDEUTSCH>
In-Reply-To: Your message of  27 September 1980 15:14 edt

I believe that Marvin Sirbu mentioned (at least to MsgGroup) last
spring that NBS was having BBN develop a message format standard.
This is the very same standard as was mentioned in the CW
article.

We have finally made it to the "draft standard" stage.  NBS will
soon be publishing a document for public review.  The lessons
learned on the ARPAnet have not been ignored by either NBS or the
draft standard's authors.

After the public has made its comments and suggestions the draft
standard will be revised into a final version.

Debbie


Date: 29 Sep 1980 0841-EDT
From: POGRAN at BBND
Subject: Re: NBS Computer Standards
To:   Sibert.Multics at MIT-MULTICS, header-people at MIT-AI,
To:   human-nets at MIT-AI, msggroup at MIT-AI
cc:   POGRAN

NBS/ICST has been an ARPANET participant just about as long as anyone else;
I think we can safely assume that they are fully aware of the ARPANET
experience in these areas.  In particular, I think the fact that the
goals, and the phrasing, sounded so familiar to us is an indication that
NBS is aware.  What NBS must now do is LISTEN to all the input they're
soliciting from industry -- and still come up with technically valid
standards, a la ARPANET.

Ken Pogran
-------


Date: Monday, 29 September 1980  11:12-EDT
From: John A. Pershing Jr. <JPERSHING at BBNA>
To: POGRAN at BBND
Cc: Sibert.Multics at MIT-MULTICS, header-people at MIT-AI,
    human-nets at MIT-AI, msggroup at MIT-AI
Subject: NBS Computer Standards

It seems the one lesson to be learned from the ARPA Net (which NBS
apparently hasn't learned) is that there IS such a thing as too many
protocols.  With DOD issuing their "standard" protocol, ANSI issuing
theirs, yet another coming from Europe (CCITT), plus the extant ARPA
Net, ChaosNet, PRNet, PUP, etc., etc., etc., this country needs another
"standard" protocol about as much as I need another hole in my head.

  -jp


Date: 30 Sep 1980 (Tuesday) 0933-EST
From: WATKINS at NBS-10
Subject: The NBS Standards Program in Computer Based Office Systems
To:   Sibert at MIT-MULTIC
cc:   header-people at MIT-AI, human-nets at MIT-AI, msggroup at MIT-AI

As manager of the NBS program in Computer Based Office Systems, I would
be happy to receive any comments either on the general program of
standards planned or any specific product.  It would greatly expedite
things, if comments were directed to me (either via netmail, USPS mail,
or phone) rather than Jim Burrows or any of our contractors.

The success of this standards program, as any, is dependent upon
sound technical inputs from vendors, Government, users, and implementors.

I look forward to hearing from the ARPANET community and certainly their
voice of experience.

Shirley Ward Watkins
(301) 921-3516

National Bureau of Standards
Bldg. 225 B226
Washington, D. C. 20234




Date:  1 Oct 1980 0348-PDT
From: POSTEL at USC-ISIF
Subject: Mail Plans
To:   header-people at MIT-AI


There is a real effort to get the lower level protocols converted
from the old arpanet only set to the new internet set, the most
visible thing right now being the switch from NCPs to TCPs.  In
light of this plans are being made for computer mail service
during and after this transition. RFCs 771 & 772 address some of
the issues and suggest the direction.  your comments are invited.

--jon.

-------


Date: 17 OCT 1980 0645-PDT
From: BHUBER at USC-ECL
Subject: 2741/X.25 Info Request
To:   Header-People at MIT-AI:

Anyone have any technical info regarding support for IBM 2741
protocol devices on X.25 networks, specifically concerning time
response characteristics of signal from ATTENTION/INTERRUPT key?

Thanks, Bud Huber
-------


Date: 18 October 1980 03:38-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: 2741/X.25 Info Request
To: BHUBER at USC-ECL
cc: HEADER-PEOPLE at MIT-MC

    Date: 17 OCT 1980 0645-PDT
    From: BHUBER at USC-ECL

    Anyone have any technical info regarding support for IBM 2741
    protocol devices on X.25 networks, specifically concerning time
    response characteristics of signal from ATTENTION/INTERRUPT key?

I'm just curious what sort of an answer you expect.  Surely you realize
that the protocol definition of an X.25 network does not define any
performance parameters.  Are you asking for metering statistics for
an X.25 network such as Tymshare, Tymnet or Datapac?  (I am not
saying I have such statisticis).  Do you care which one?  Do you
have any reason to believe that a TIP (or whatever they call them)
that has 2741 support would exhibit significantly different transmission
delays from an ASCII terminal on the same node?  Lastly, are you just
trying to ask how long until your keyboard is unlocked?

Date: 30 Jan 1981 2041-PST
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: NBS Draft Report on Message Format Standard
To:   MsgGroup at MIT-ML, Header-People at MIT-MC
cc:   Parsons, Zellich

Anyone who didn't receive a copy of the following report should take
steps to obtain one:
  NBS Report No. ICST/CBOS - 80-2, "Specification of a Draft Message
  Standard"

You can probably get one by writing to the address given for comments:

   National Bureau of Standards (Code CBOS)
   Systems and Network Architecture Division
   Technology Building, Room B218
   Washington, DC  20234
-------

Date:  2 Feb 1981 (Monday) 0950-EST
From: WATKINS at NBS-10
Subject: NBS Draft Report on Message Format Standard
To:   msggroup at MIT-ML, header-people at MIT-MC

Copies of NBS Report NO.  ICST/CBOS - 80-2, "Specification of a Draft
Message Format STandard" may be obtained by sending netmail to
watkins@nbs-10.  Please send your USPS address with your request.

Shirley


Date: Monday, 9 February 1981  20:49-EST
From: JHAVERTY at BBND
To:   WATKINS at NBS-10
Cc:   header-people at MIT-MC, msggroup at MIT-ML
Subject: NBS Draft Report on Message Format Standard

Shirley,

I'd like to receive an official copy of the report:

Jack Haverty
Bolt Beranek and Newman Inc.  
10 Moulton Street
Cambridge, MA 02238

Tnx,
Jack

Date: 12 Mar 1981 1937-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: quotes in Reply-To
To: Header-People at MIT-MC
cc: Woods at PARC-MAXC, LaurelSupport at PARC-MAXC

If a mail program sees a line in the header looking like:
	Reply-To: "Bridge^"@PARC
should it reply to "Bridge^" at PARC, or to Bridge^ at PARC?  MM
assumes the former, and PARC barfs on it.  MM is happy to parse
	Reply-To: Bridge^@PARC
with no hassles, sending to Bridge^ which is what PARC wants to
see.

-- Mark --
-------

Date: 12 Mar 1981 2132-PST
From: Brian K. Reid <CSL.BKR at SU-SCORE>
Subject: Re: quotes in Reply-To
To: Admin.MRC at SU-SCORE, Header-People at MIT-MC
cc: Woods at PARC-MAXC, LaurelSupport at PARC-MAXC
In-Reply-To: Your message of 12-Mar-81 1937-PST

a field of "Bridge^"@Parc should send mail to (Bridge^) and
not ("Bridge^"), i.e. the quotes are to be removed.
-------

Date: 13 Mar 1981 0835-EST
From: WJN at MIT-DMS (Wayne J. Noss)
To: Admin.MRC at SU-SCORE
Cc: Header-People at MIT-MC, Woods at PARC-MAXC, 
    LaurelSupport at PARC-MAXC
In-reply-to: Message of 12 Mar 81 at 1937 PST by Admin.MRC@SU-SCORE
Subject: [Re: quotes in Reply-To]
Message-id: <[MIT-DMS].189825>

Mark,
     I think that Reply-To: "Bridge^"@PARC should mean exactly what it
says--to reply to "Bridge^", quotes and all.  There is no need to
magicize a double quote.  Introducing universal peculiarities to dodge
peculiar behavior at some particular sites is neither necessary nor
desirable.  The protocol should be clear and simple (to the extent
possible), and sites should then find ways to make it work.
				the WJN


Date: 13 Mar 1981 0947-EST
From: PDL at MIT-DMS (P. David Lebling)
To: WJN at MIT-DMS
Cc: Admin.MRC at SU-SCORE, Header-People at MIT-MC, 
    Woods at PARC-MAXC, LaurelSupport at PARC-MAXC
In-reply-to: Message of 13 Mar 81 at 0835 EST by WJN@MIT-DMS
Subject: [Re: [Re: quotes in Reply-To]]
Message-id: <[MIT-DMS].189836>

As it says in RFC733 (on p.11), "The quote character and characters
which delimit syntactic units are not, generally, to be taken as
data which is part of the delimited or quoted unit(s). ... In
particular, the quotation-marks which define a quoted string ...
are NOT part of the quoted-string..."  And later in the same
paragraph:  "Quotation marks which delimit a quoted string ...
should NOT accompany the quoted-string when the string is used with
processes that do not interpret data according to this specification
(e.g., ARPANET FTP mail servers)."

Those who doubt (for some odd reason) that quoted strings are in
the syntax are referred to pp.14-16, where the "BNF" gives (in
compressed form):

address = host-phrase
host-phrase = phrase host-indicator
phrase = 1*word
word = atom / quoted-string

Q.E.D.

	Dave



Date: 13 March 1981 1112-EST (Friday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
To: Mark Crispin <Admin.MRC at SU-SCORE> 
Subject:  Re: quotes in Reply-To
CC: Header-People at MIT-MC, Woods at PARC-MAXC, LaurelSupport at PARC-MAXC
In-Reply-To:  Mark Crispin's message of 12 Mar 81 22:37-EST
Message-Id: <13Mar81 111247 RG02@CMU-10A>

It should put "Bridge^" at PARC in the HEADER but the FTP command line should
read "MLFL Bridge^" when sent over the command connection.

		Rick

Date: 18 Mar 1981 1920-PST
Sender: GEOFF at SRI-CSL
Subject: Illegal header?
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: Header-People at MC
Cc: Wancho at DARCOM-KA
Message-ID: <[SRI-CSL]18-Mar-81 19:20:04.GEOFF>

I'm getting headers occasionally of the form

From: John Q. Luser <LUSER>

with no "@HOST" or "at HOST" after LUSER.  It was my
understanding that the host name always had to be specified, and
that just having <LUSER> and not <LUSER@HOST> is illegal?

The TOPS-20 MM program (and now new program on TENEX, which sent
me such a message tonight) is generating the above style header.

Legal or Illegal?

Date: 18 Mar 1981 1949-PST
From: POSTEL at USC-ISIF
Subject: Re: Illegal header?
To:   Geoff at SRI-CSL, Header-People at MC
cc:   Wancho at DARCOM-KA, POSTEL

In response to the message sent  18 Mar 1981 1920-PST from  Geoff at SRI-CSL


Geoff:

Illegal.

--jon.
-------

Date: 18 Mar 1981 1951-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Re: Illegal header?
To: Geoff at SRI-CSL, Header-People at MIT-MC
cc: Wancho at DARCOM-KA
In-Reply-To: Your message of 18-Mar-81 1920-PST

     MM will generate the "From: John Q. Luser <LUSER>" format
headers if and only if it is explicitly delivering the message to
a local user.  Since MM also runs on non-network systems this
must be legal for non-network mail; and it appears to be a
convention among Tenex/TOPS-20 sites not to include the host name
in local message delivery.

     Some mail reading programs, including MM, have a REMAIL
feature that allows a message to be retransmitted to another
user, preserving the original header of the message.  Usually
information about the origin of the message, such as a
"Remailed-From" line, is appended to the end of the header.  It
is therefore possible that a message with a local From header may
be sent out on the ARPANET by accident.

     It is difficult to detect this happening and even more
difficult to correct it (I guess you have to edit the From line
somehow), especially given that certain people cause their mail
originating programs to generate From lines like
	From: the outhouse of Fred Foobar
and rely upon the Reply-To line to return the necessary
information.

-- Mark --
-------

Date:      18 Mar 81 23:02:49-EST (Wed)
From:      Dave Crocker <dcrocker@udel>
To:        Geoff at sri-unix
cc:        Header-People at mc, Wancho at darcom-ka
Subject:   Re: Illegal header?

To the extent that anybody considers RFC733 the standard, for
such a question, the hostname is absolutely required.

Dave.


Date: 19 March 1981 19:05-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Illegal header?
To: Admin.MRC at SU-SCORE
cc: HEADER-PEOPLE at MIT-MC, Geoff at SRI-CSL, Wancho at DARCOM-KA

The obvious thing to do to MM is to have it use host names if and
only if it is running on a machine with a network.  People that
don't want to see local host names should fix their mail reader,
not send illegal headers.

Date: 20 Mar 1981 0159-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Re:  Illegal header?
To: EAK at MIT-MC
cc: Header-People at MIT-MC
In-Reply-To: Your message of 19-Mar-81 1605-PST

    Date: 19 March 1981 19:05-EST
    From: Earl A. Killian <EAK at MIT-MC>

    The obvious thing to do to MM is to have it use host names if and
    only if it is running on a machine with a network.

     That does nothing whatsoever to solve the problem.  The
message which MM may be REMAILing may not have been generated by
MM in the first place!  As long as ANY mail sender can generate
such a header, the problem will exist, irregardless of whether or
not MM is changed so that it does not send out messages with such
a header.

     I was not aware that RFC 733 presumed to dictate the format
of a message sent from one local user to another without using a
network.  I think it is quite reasonable to assume that a header
looking like:
	From: Fred Foobar <Foobar>
or more commonly
	From: FOOBAR
means local user FOOBAR; SNDMSG will generate the latter format
header.

     As a side note, since Geoff uses Hermes I tested Hermes'
REDISTRIBUTE command, and found that it behaves in the same
manner as MM.  I'd be interested if a REMAILing feature in any
mailsystem knows enough to edit the From:/Reply-To:/whatever line
when necessary (including handling the "From the outhouse" case).
In any case, I think it is inappropriate to single out MM for
criticism.

-- Mark --
-------

Date: 20 Mar 1981 0841-EST
From: POGRAN at BBND
Subject: Re:  Illegal header?
To:   Admin.MRC at SU-SCORE, EAK at MIT-MC
cc:   Header-People at MIT-MC, POGRAN

I'd suggest that the best way out of this situation would be for
a program about to REMAIL a message to parse the existing header
according to 733 standards; if there's anything "illegal" about it,
the remailer should fabricate a complete new header and treat the
old header as part of the text field of the message.  Clumsy and ugly,
to be sure, but it's easier than trying to figure out how
to patch up a header that doesn't QUITE meet 733 specs.

Ken
-------

Date: 20 March 1981 1431-EST (Friday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
To: Pogran at bbnd
Subject:  Bogus headers
CC: Header-People at mit-mc
Message-Id: <20Mar81 143110 RG02@CMU-10A>

Gee, what is that "Pogran" in your CC field?  It has no host!

		Rick

- - - - Begin forwarded message - - - -
Date: 20 Mar 1981 0841-EST
From: POGRAN at BBND
Subject: Re:  Illegal header?
To:   Admin.MRC at SU-SCORE, EAK at MIT-MC
cc:   Header-People at MIT-MC, POGRAN
Via:     MIT-MC; 20 Mar 1981 0855-EST

I'd suggest that the best way out of this situation would be for
a program about to REMAIL a message to parse the existing header
according to 733 standards; if there's anything "illegal" about it,
the remailer should fabricate a complete new header and treat the
old header as part of the text field of the message.  Clumsy and ugly,
to be sure, but it's easier than trying to figure out how
to patch up a header that doesn't QUITE meet 733 specs.

Ken
-------
- - - - End forwarded message - - - -

Date: 20 Mar 1981 1559-EST
From: POGRAN at BBND
Subject: Ain't it awful!
To:   Rick.Gumpertz at CMU-10A
cc:   Header-People at MIT-MC

Just goes to show you how much ANTIQUATED software is used
regularly around the net by well-meaning people.

And how much software ISN'T maintained and kept up-to-date.
Now, back when I was at MIT-Multics . . .

Ken
-------

Date: 23 March 1981 03:41-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Illegal header?
To: Admin.MRC at SU-SCORE
cc: HEADER-PEOPLE at MIT-MC

I wasn't singly out MM for criticism; I was simply suggesting
that by so modifying MM the number of illegal headers in the
world would be reduced.  It is an obvious fix, that is easy as
well.  I don't believe that MM should be held responsible if it
remails an illegal header generated by Hermes; Hermes should be
held responsible for sending the original header.  In general I
think this whole discussion proves that it is a loss to send
hostless addreses even to local recipients.

Date: 23 March 1981 1459-EST (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
To: Earl A. Killian <EAK at MIT-MC> 
Subject:  Re: Illegal header?
CC: HEADER-PEOPLE at MIT-MC
In-Reply-To:  Earl A. Killian's message of 23 Mar 81 03:41-EST
Message-Id: <23Mar81 145900 RG02@CMU-10A>

The solution at CMU is to ALWAYS include a host in the header.  The mail
reading program then suppresses display of the host if it is the same as
the one you are then running on.  This seems to work out quite nicely.

		Rick

RMS@MIT-AI 03/28/81 06:21:48 Re: remailing
To: HEADER-PEOPLE at MIT-MC
There's no need to worry about truly weird From fields
which are accompanied by Reply-to fields, since they don't
get used as addresses.  With that out of the way,
we can consider only From fields really intended to be
used as the address to mail a reply to.

About them, if people want to have no host name mentioned
in mail which is completely local, then any mailer which
has a "remail" feature ought to look through the existing
From field (only if there is no reply-to) and add a host name
to it if appropriate.

Since this only needs to be done for local mail, the parser
can be simplified by assuming that the mail was generated
by one of the mail systems that runs on the local machine.
It needs to test that assumption, of course, but if the
assumption is seen to be false, it is safe to assume that
the mail came from elsewhere, and already has the host name
(or, if it doesn't, it's someone else's fault) so you can
leave it alone.  Perhaps this makes the task simpler.


Date: 7 Apr 81 17:7:13-PDT
From: mclure at Sri-Unix
To: header-people at mc
Subject: odd header

This is an extremely strange header I recently received.
Comments anyone?


DATED    7 Apr 1981 at 1552 Pacific Standard Time
SENT BY jeff (Jeff Schriebman - Consultant/JSC)
SUBJECT Re: Unix V7 on 11/44
SENT TO obrien@RAND-UNIX
COPY TO unix-wizards@SRI-UNIX
ORIG BY obrien at RAND-UNIX
 
        Date:  7 Apr 1981 at 1348-PST
        To: Spencer W Thomas <THOMAS at UTAH-20>
        Cc: unix-wizards at SRI-UNIX
        Subject: Re: Unix V7 on 11/44
        In-reply-to: Your message of  6 Apr 1981 1746-MST.
        From: obrien at RAND-UNIX
        Via:  199.ArpaNet; 7 Apr 81 14:20-PDT
 
I replied to the question of V7 on 11/44's.
	Jeff Schriebman at lll-comp


Date:  8 Apr 1981 at 1028-PST
To: Lauren at UCLA-S (Lauren Weinstein)
Cc: obrien at RAND-UNIX, mclure at SRI-UNIX, header-people at MC
Subject: Re: Schriebman's message
In-reply-to: Your message of 7 Apr 1981 1819-PST (Tuesday).
From: obrien at RAND-UNIX

	That header is not only peculiar, it is misleading.  Despite the
tag "ORIG BY", whatever that means, it was a reply to me from Schriebman
about something.  I've never seen anything like it.

RMS@MIT-AI 06/04/81 22:59:55 Re: Depending on DEC is not an excuse.
To: header-people at MIT-MC
"I have a nice computer company which is going to make all my programs
do just what they ought.  I'm very loyal and I trust them.  I'm going
to do just what they say.  I'm sure if the programs can't send mail to
you, the computer company must have a good reason.  It's your own
fault.  You should have been nice to the nice computer company.  Then
I'm sure you wouldn't have any trouble."


Date:  4 Jun 1981 2238-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: RMS' flame about "depending on DEC"
To: Header-People at MIT-MC

     RMS' message referred to problems a user on one of
Tymshare's Foonlys had in sending a message to an esoteric
address (one of the MIT Chaosnet addresses).  Evidently RMS has
not realized that DEC has nothing whatsoever to do with software
support for Foonly computers.

     In fact, DEC's TOPS-20 mail system, MS, does support MIT
Chaosnet addresses of the form "Foo at MIT-EECS at MIT-AI".

     Perhaps RMS should do some research before he flames.

-- Mark --
-------

Date: 6 June 1981 20:39-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: RMS' flame about "depending on DEC"
To: Admin.MRC at SU-SCORE
cc: HEADER-PEOPLE at MIT-MC

I'm glad you know RMS' message referred to a problem a user on a
Tymshare foonly had.  Frankly, I had thought it referred to a message of
Johnathan Solomon's (sent to MsgGroup) saying that Rutgers could not
support foo@x@y because they had a policy of running only standard DEC
software.  Since I think RMS knows full well about the software support
relative to Foonly's, I'll bet he was replying to Solomon's message, in
which case I woul dhave to say I'm rather in agreement with the tone of
his message.

Perhaps MRC should do some research before he flames.

Date: 8 June 1981 15:57-EDT
From: Mike McMahon <MMcM at MIT-AI>
To: Header-People at MIT-MC

Could someone point me to the revised address BNF that allows
To: Foo:
(no ";")?  This isn't legal in the version in the protocol handbook.
I certainly hope that CRLF isn't significant, since the lexer treats
that as whitespace.


Date:      8 Jun 81 16:09:15-EDT (Mon)
From:      Dave Crocker <dcrocker@udel>
To:        Mike McMahon <MMcM@mit-ai>
cc:        Header-People at Mit-Mc

There is no specification, of the sort that you want.  People usually
say that the document in the protocol handbook (rfc733) is the
standard.  Occasionally, they qualify and say that a subset of it
is the standard.

No one has ever gone and specified exactly what the current REAL
standard is.

Dave


Date:  8 Jun 1981 1515-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: (Response to message)
To:   MMcM at MIT-AI, Header-People at MIT-MC
cc:   ZELLICH

In response to the message sent  8 June 1981 15:57-EDT from MMcM@MIT-AI

Not sure just what the legality of To: Foo: would be - it's NOT
intended as an address, certainly.  What it is is a mechanism for
providing address lists and having the mailsystem use the addresses
following the "Foo:" for actual mailing, but showing only the "Foo:"
in the message header.  Use of such a mechanism implies that you don't
want automatic replies to the Foo list.

Wish I had a copy of 733 here at home so I could recheck to see if that
(Twenex only?) feature is mentioned therein for lists.

-Rich
-------

Date: 8 Jun 1981 1812-PDT (Monday)
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
Subject: (Response to message)
In-reply-to: Your message of  8 Jun 1981 1515-PDT
To: Zellich at OFFICE-3
CC: MMcM at AI,Header-People at MC

The UCLA Unix systems (ATS and SECURITY) have also used the
FOO: convention for local mailing lists for years.

--Lauren--
-------


Date: Wednesday, 10 June 1981, 23:43-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Strange COMSYS headers
To: BUG-ZMAIL at MIT-AI, PDL at MIT-MC, SWG at MIT-MC,
    HEADER-PEOPLE at MC

    Date: 6 Jun 1981 0927-EDT
    Forwarded-to: user-a at MIT-DMS by SWG at MIT-DMS on 8 Jun 81 at 1400 EDT
    From: SWG at MIT-DMS (S. W. Galley)
    To: DEVON at MIT-DMS
    In-reply-to: Message of 05 Jun 81 at 2145 EDT by DEVON@MIT-MC
    Subject: [Re: [RE^3: Dianne]]
    Message-id: <[MIT-DMS].200123>

It would be nice if we could standardize on Forwarded-to:,
Redistributed-To:, etc. fields.  From a program's point of view, having
three fields, Forwarded-to, Forwarded-by, and Forwarded-date is far
simpler to parse, especially since some systems already use this
convention.  However, it certainly is a lot less clutter to put it
all in one header line.

But what does COMSYS do when there are more people forwarded to than
will fit on one line?  I would hope that it still only uses one header
entry, with the usual convention for continued lines, leaving multiple
Forwarded-to entries for multiple forwardings.  I guess this is another
advantage of the COMSYS-style format.

Date: 11 Jun 1981 1012-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: RWK at MIT-MC
Cc: BUG-ZMAIL at MIT-AI, SWG at MIT-MC, HEADER-PEOPLE at MIT-MC
In-reply-to: Message of 10 Jun 81 at 2347 EDT by RWK@MIT-MC
Subject: [Re: Strange COMSYS headers]
Message-id: <[MIT-DMS].200674>

   But what does COMSYS do when there are more people forwarded to than
   will fit on one line?  I would hope that it still only uses one header
   entry, with the usual convention for continued lines, leaving multiple
   Forwarded-to entries for multiple forwardings.

In theory this is precisely what it does.
	Dave



Date:  30 June 1981 23:08 edt
From:  Frankston.SoftArts at MIT-Multics
Subject:  Change of name
Sender:  COMSAT.SoftArts at MIT-Multics
Reply-To:  Frankston at MIT-Multics (Bob Frankston)
To:  header-people at MIT-AI, msggroup at MIT-AI
*from:  BOB (Bob Frankston)
Local:  header-people at mit-ai,cc:msggroup at mit-ai

I am sending this to the entire list instead of just the
"-request" identity.  I'd like to change the current entry for
me on Multics from whatever it is (SALawrence.SoftArts or
sal.sai or maybe Frankston or bob or rmf or ...) to
header-list.SoftArts and msggroup-list.SoftArts as appropriate.

Instead of being
     Frankston at misc.SoftArts at MIT-Multics
I will get the mail via
     header-list.SoftArts at MIT-Multics
which will be examined by a program that will do local
redistribution.

the reason is that the "at .. at" syntax is fine by itself, but
since the information is not preserved in the letter itself,
but only the FTP "envelope" the syntax is only usable by those
who modify their operating systems.  This is not fair and
unnecessary.  We need to add the "envelope-to" field that
contains the same information as the address for FTP.  That is
the field that can be used by mail processing programs.  The
"to:" field and such are only used for mail preparation and
presentation programs.

I realize that "envelope-to" is ugly.  Suggestions?


Date: 28 Aug 1981 1631-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: In-Reply-To field - use Message-Id only, in combination, or what? [collected MsgGroup correspondence]
To:   Header-People at MIT-MC

   1   28 Aug  Larry Campbell <LCAMP Standards vs. practices
   2   28 Aug  To:  LCAMPBELL at DEC Re: Standards vs. practices
   3   Friday  greep at RAND-UNIX    Re: Standards vs. practices
   4   28 Aug  DREIFU at WHARTON-10  Suggestion(s) for RFC999, 
                                     improvement to RFC733
   5   Friday  greep at RAND-UNIX    Re: Suggestion(s) for RFC999, 
                                     improvement to RFC733
   6   28 Aug  the tty of Geoffrey S Re: Standards vs. practices
   7   28 Aug  To:  Geoff at SRI-CSL Re: Standards vs. practices


1 -- ************************
Mail from MIT-ML rcvd at 28-Aug-81 0853-PDT
Date: 28 Aug 1981 1120-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: MsgGroup at MIT-ML
Subject: Standards vs. practices
Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11755753035.20.71.16863 at DEC-MARLBORO>

I am in a quandary over what to do about "Message-ID" and
"In-reply-to" fields.  RFC733 seems to indicate that a mailsystem,
when generating a reply, should copy the contents of the "Message-ID"
field of the message being replied to into the "In-reply-to" field.
This is presumably to make it easy for mailsystems to automatically
locate the original to a reply you've received, or to collect related
sequences of messages together.  However, it appears that very few
mailsystems on the ARPANET actually do this.  Most of them generate
"In-reply-to" fields like:

	In-reply-to: Message from Jobe Blow of 1-Apr-84

I recently added code to a mailsystem I'm hacking to automatically
trace originals to replies.  I needed to include the "Message-ID" of
the original in replies, but didn't want to incompatibly change
the behavior of "In-reply-to" (every time I incompatibly change the
mailsystem, hordes of wildeyed people with weapons invade my office).
So I invented a new field, "Reference", which behaves the way RFC733
says "In-reply-to" ought to.

I don't like this solution.  After much thought, I've decided that the
"right" thing to do is to adhere to the standard, even if this means
an incompatible change.  However, the current de facto interpretation
of "In-reply-to" is also useful; I really appreciate being told the
name of the human who sent the original message whose reply I'm
reading.

It would appear that we need to invent a new header name for just this
purpose.  I thus have two questions:

1) What should the new header name be?  "Re"?  "In-regard-to"?
   etc.  (Or do we need one at all?  Is all this off the wall?)

2) Is it deemed desirable to change the mailsystems that
   violate the standard so that they generate "In-reply-to"
   fields which conform to the spirit of RFC733?
   --------



2 -- ************************
Date: 28 Aug 1981 1034-PDT
From: Zellich
Subject: Re: Standards vs. practices
To:   LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML
cc:   ZELLICH

In response to the message sent 28 Aug 1981 1120-EDT from LCAMPBELL@DEC-MARLBORO

Or perhaps the In-Reply-To field could contain *both* entries;
probably the usual "...message from etc..." first, then the originators
Message-Id.  In whichever order they appeared, they would be separated by
a CRLF and LWSP to make them readable.

EX:
In-Reply-To:  The message from Jobe Blow 1-Apr-81
  <[ORIGHOST]1-Apr-1981 01:01:01 JBLOW>

I don't have a copy of RFC733 here with me, so I don't remember how
explicit it is about the content of the In-Reply-To field; it might
need changing to allow the above.  If we want to change RFC733 to
allow this kind of formating, I think I would prefer the format as
shown, with the copied Message-Id second, since some mailsystems don't
necessarily generate an Id, but the sender and date/time sent should
always be known.

-Rich Z.
-------


3 -- ************************
Mail from MIT-ML rcvd at 28-Aug-81 1425-PDT
Date: Friday, 28 Aug 1981 13:49-PDT
To: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
Cc: MsgGroup at MIT-ML
Subject: Re: Standards vs. practices
In-reply-to: Your message of 28 Aug 1981 1120-EDT.
             <"MS5(1734)+GLXLIB1(1033)" 11755753035.20.71.16863 at DEC-MARLBORO>
From: greep at RAND-UNIX

Since angle brackets are used to indicate text designed mainly for
program (rather than human) use, I thought the idea was that you could
put anything you wanted in the in-reply-to field, with the original
message id inside angle brackets, e.g.
   In-reply-to: Message from foo at bar <314159 at BAR>

RFC 733 says (section IV.B.2, page 22) about the in-reply-to field:
"The contents of this field identify previous correspondence which
this message answers.  Note that if message identifiers are used
in this field, they must use the mach-id specification format."  (The
latter is something of the form "string at host".)



4 -- ************************
Mail from MIT-ML rcvd at 28-Aug-81 1453-PDT
Date: 28 Aug 1981 (Friday) 1734-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Suggestion(s) for RFC999, improvement to RFC733
To:   MsgGroup at MIT-ML

I would tend to think an invisible field [somewhat akin to the 0000000's
in the header of the message] containing the unique identifier should 
be proposed.

Instead of seeing that hacker-created-prime number, a 'user' oriented
In Reply to |Message Header| of |Message Date| be printed. In fact,
almost anything within cognitive reason should be there.

The point of the message is, one should display only the information that
is relevant to a given message. The sender, the reciever(s), the date and
time, and some additional fields, where appropriate.  I do not think the
Message Id is appropriate.  The less one has to dig through a message, the
better.  In fact, one must dig through the context of a message to gleen
its meaning(s). 

Henry Dreifus




5 -- ************************
Mail from MIT-ML rcvd at 28-Aug-81 1526-PDT
Date: Friday, 28 Aug 1981 14:55-PDT
To: DREIFU at WHARTON-10 (Henry Dreifus)
Cc: MsgGroup at MIT-ML
Subject: Re: Suggestion(s) for RFC999, improvement to RFC733
In-reply-to: Your message of 28 Aug 1981 (Friday) 1734-EDT.
From: greep at RAND-UNIX

What do you mean by "invisible" field?  Re "the 0000000's in the header",
what are you talking about?  In general, the mail reading program should
filter out, at the user's discretion, whatever he doesn't want to see.
There is no law saying that the program that displays mail has to show
the whole message exactly as it was transmitted - it should be able to
skip over fields the user isn't interested in, move them to the bottom,
or whatever.



6 -- ************************
Mail from SRI-CSL rcvd at 28-Aug-81 1559-PDT
Date: 28 Aug 1981 1550-PDT
Sender: GEOFF at SRI-CSL
Subject: Re: Standards vs. practices
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: Zellich at OFFICE-3
Cc: LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML
Message-ID: <[SRI-CSL]28-Aug-81 15:50:26.GEOFF>
In-Reply-To: Your message of 28 Aug 1981 1034-PDT

I on the other hand I  either like getting
	
In-Reply-To: Your message of 28 Aug 1981 1034-PDT
  or
In-Reply-To: The message from Zellich at Office-3 at 28 Aug 1981 1034-PDT
  or
In-Reply-To: <[Office-3]28-Aug-81 10:34:00-PDT>

but what I don't like getting is what the RAND-MH and PARC-Laurel
message systems send out which, on the first line give you
the "Your message of.." or "The message from..." AND then on the
second line put the "machine type" Message-Id or even worse, split the
"Machine Type" message id in the middle of the first line onto the second.

In essence: One or the other, but please NOT both!

I also think this topic would be more appropriate for HEADER-PEOPLE,
the list where RFC733 was reviewed.


7 -- ************************
Date: 28 Aug 1981 1628-PDT
From: Zellich
Subject: Re: Standards vs. practices
To:   Geoff at SRI-CSL, Zellich at OFFICE-3
cc:   LCAMPBELL at DEC-MARLBORO, MsgGroup at MIT-ML, ZELLICH

In response to the message sent  28 Aug 1981 1550-PDT from  Geoff at SRI-CSL

I agree with Geoff about the subject being [more] appropriate for
Header-People and have taken the liberty of forwarding the collected
correspondence to date to that list.  It might be a good idea for anyone
concerned with this subject to start sending to Header-People instead
of MsgGroup or at least CCing Header-People (but an awful lot of us
will get two copies of everything, then).
Cheers,
Rich
-------
-------

Date: 29 August 1981 00:16-EDT
From: Mike McMahon <MMCM at MIT-AI>
Subject: In-reply-to fields
To: LCampbell at DEC-MARLBORO
cc: header-people at MIT-MC

The lisp machine mail reader also has some commands for finding originals
from replies.  It understands about 10 different formats of in-reply-to.

Problems like this really won't be satisfactorily solved so long as mail
is transmitted as unstructured text.


Date:      29 Aug 81 15:39:22-EDT (Sat)
From:      Dave Crocker <dcrocker@udel>
To:        Header-People at Mit-Mc
Subject:   In-reply-to contents

[[ would someone with mit-mc write-access change my header-people
address to be dcrocker@udel, rather than dcrocker@rand-unix? thanks.]]

To summarize what a couple of you noted, In-reply-to contents may
be:

	random text

or

	<message-id>

or

	random text <message-id>

where the last form has both kinds of information and is what Geoff
does not like.  (sorry.)  It should also be noted that it is
legal (albeit not entirely well defined) to have the following:

In-reply-to:	random text
In-reply-to:	<message-id>

Personally, I do not see the need for this, since any program that
is going to selectively print In-reply-to contents probably can just
strip the angle-bracketed stuff from the more compact form.

Dave


Date: 29 August 1981 1555-EDT (Saturday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
To: Dave Crocker <dcrocker at udel> 
Subject:  Re: In-reply-to contents
CC: Header-People at MIT-MC
Sender: Rick.Gumpertz at CMU-10A
In-Reply-To:  Dave Crocker's message of 29 Aug 81 14:39-EST
Message-Id: <29Aug81 155521 RG02@CMU-10A>

Should there be some restriction on the random text, such as prohibiting
angle-brackets except for a real message ID??

		Rick

Date: 29 Aug 1981 (Saturday) 1611-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Actually I prefere to see NONE of that at all.
To:   header-people at MIT-MC

Message ID's are not for people, but for compu-tons. When the message
is shorter than the 'header information' I get very turned off.

While you are at it, make Message-Id's uniform (:=standardized).

Hank

Date:      29 Aug 81 17:11:20-EDT (Sat)
From:      Dave Crocker <dcrocker@udel>
To:        Richard H Gumpertz <Rick.Gumpertz@cmu-10a>
To:        Henry Dreifus <DREIFU@wharton-10>
cc:        Header-People at Mit-Mc
Subject:   Re:  In-reply-to contents
Subject:        Actually I prefere to see NONE of that at all.

1.  RFC 733 specifies what characters are legal and in what ways; e.g.,
angle-brackets are <specials> and may only occur in text strings
which are quoted.

2.  The form of message id's IS standardized, but only to the extent
that is reasonable for global action.  A message id is generated
by individual hosts, so that it is up to each host to be able
to use the string it generates.  Hence, Network message-id's
have a part which indicates source host and a part which is the
unique string generated by that host.  What each host considers
appropriate is none of the business of the rest of us.

D/


Date: 29 Aug 1981 1528-PDT
Sender: GEOFF at SRI-CSL
Subject: Re:   In-reply-to contents
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: dcrocker at UDEL
Cc: Header-People at MIT-MC
Message-ID: <[SRI-CSL]29-Aug-81 15:28:53.GEOFF>
In-Reply-To: Your message of      29 Aug 81 15:39:22-EDT (Sat)

The reason why I don't like

        random text <message-id>

is that "random text" and <message-id> more or less contain the
same information (usually being that "random text" is a subset
of what's in <Message-Id>).

I know that Message-Id's and the Date field contain redundant
information, but the message system I use (HERMES) allows me to
suppress the printing of the Message-Id field whenever I look at
messages, so i never see them, and hence only see the information
once.  However, with Rand-MH and PARC-Laurel that put both "random
text" and <message-Id> in the In-Reply-To field, there is
(unnecessary) duplication of information (in my humble opinion), and I
don't see any purpose or reason for this duplication.  Hence, my
request for either "random text" or <Message-Id>, but not both.

Date: 30 August 1981 1145-EDT (Sunday)
From: David Lamb
To: Dave Crocker <dcrocker at udel> 
Subject:  Standardising Message-ID contents
CC: Header-People at Mit-Mc
Reply-To: Rdmail
In-Reply-To:  Dave Crocker's message of 29 Aug 81 16:11-EST
Message-Id: <30Aug81 114503 RD00@CMU-10A>

Like Henry Dreifus, I'd prefer to see the form of <Message ID>'s standardised
to some extent.  The CMU RdMail program has facilities for searching for
messages that answer a particular message, and to which a particular message
is the answer.  At the moment this involves a linear search for messages with
matching In-Reply-To or Message-Id fields.  Anyone who has any need for
these cross-reference searches typically has hundreds of messages in their
message file, so the searches are too slow to be useful.  If message-id's
always included the date of origin in some form, RdMail could do a fast search
since it has a date-of-origin index into the message file.  Even standardising
on "so-and-so's message of date-and-time" would be sufficient here.

Date: 1 Sep 1981 1519-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: Header-people at MIT-MC
Subject: Address change
Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11756845178.19.71.15782 at DEC-MARLBORO>

(Sorry about sending this message to the whole list, but I've
tried everything similar to Header-people-request@MIT-MC without
hitting a valid mailbox name...)

Please change my address, which is currently either LCampbell@SRI-KL
or G.LCampbell@SU-SCORE, to LCampbell@DEC-MARLBORO.
   --------

Date:  1 Sep 1981 1324-PDT
From: Daul at OFFICE  
Subject: Please add my name to this...
To:   header-people at MIT-AI

list.  Thanks,  --Bill
-------


Date:  1 Sep 1981 1349-PDT
From: Feinler at SRI-NIC
Subject: Address changes, etc.
To:   lcampbell at DEC-MARLBORO
cc:   header-people at MIT-MC, nic

These come to the NIC.  NIC@NIC or NIC@SRI-NIC.

Larry, (and others) do you have a copy of the NIC
WHOIS user program which lets you do 'Whois <sp> LASTNAME'
and get a return of name, address, phone and network mailbox?

If you want a copy let me know.  It can run at the system
level or in your own directory if the system doesn't want to
run it.

Anyway, nice to hear from you.

Jake
-------

Date: 08 Sep 1981 0940-PDT
From: Hon Wah Chin <HWC at SU-AI>
To:   header-people at MIT-AI    

Anyone out there know how to strap a Bell 303 from
option Z to option E, so that it would accept external sync from the DTE
for transmission?  It seems TPC might take forever to get this done for us.




Date:  9 Sep 1981 1350-PDT
From: Daul at OFFICE  
Subject: RFC 733
To:   header-people at MIT-AI

Have there been supplements to this RFC?  How can I  get copies?
Thanks,  --Bill (DAUL@OFFICE)
-------


Date:  9 Sep 1981 1618-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: RFC 733
To:   Daul at OFFICE, header-people at MIT-AI
cc:   ZELLICH

In response to the message sent   9 Sep 1981 1350-PDT from Daul@OFFICE  

As far as I know, RFC 733 is *it*.  There are later RFC's (?) and
IEN's (Internet Experiment Notes) dealing with proposed new [inter-]
network mail standards, but nothing updating or amending RFC 733.

You can FTP a formatted copy from [SRI-NIC]<NETINFO>RFC733.TXT - this
file is 38 print pages.  For other related RFC's and IEN's, I recommend
you also FTP <NETINFO>RFC-INDEX.TXT (about 2000+ lines, unformatted) and
<NETINFO>IEN-INDEX.TXT (didn't check the size, but it's a lot smaller).

SRI-NIC supports the ANONYMOUS FTP convention (password ARPA or GUEST).

-Rich Zellich
-------


Date:      9 Sep 81 22:37:42-EDT (Wed)
From:      Dave Crocker <dcrocker@udel>
To:        Daul at Office-2
cc:        header-people at Mit-Ai
Subject:   Re:  RFC 733

rfc733 is part of the arpanet protocol handbook, which has an
NTIS number and may also be aquirable from the Network
Information Center, Jake Feinler (Feinler@sri-nic).  

I also have an online copy I can netmail you, if you wish.

Dave



Date: 10 September 1981 2219-PDT (Thursday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: changing headers
To: MSGGROUP at MC, HEADER-PEOPLE at MC

Hi.  What is the current feeling regarding the local reformatting of
message headers by delivery software BEFORE delivery to destinations?

Example:  Presume there is a "smart" FTP server which, before 
delivering any incoming network mail, reformats the FROM, CC, and DATE
lines to a local standard to simplify later mail handling.

Considering the current state of the various mail handling systems around 
the net, are there currently any problems that could be caused or
increased in severity through this sort of manipulation?  Is there still
any strong reason to maintain the philosophy that received message
headers "should" look the same when received as they did when sent?

Thanks much.

--Lauren--


Date: 11-Sep-81  8:18:33 PDT (Friday)
From: Karlton at PARC-MAXC
Subject: Re: changing headers
In-reply-to: Lauren's message of 10 September 1981 2219-PDT (Thursday)
To: lauren at UCLA-Security (Lauren Weinstein)
cc: MSGGROUP at MC, HEADER-PEOPLE at MC

There is no "philosophy that received messageheaders 'should' look the same
when received as they did when sent." Some mail handling systems tailor the
display of the headers (usually by some sort of user settable profile). I
think that it would be a mistake for any FTP server to throw away some
of the information in a header. There might be something in there that
the user really wants one time in a thousand.

PK

Date: 12 Sep 81 0:29-PDT
From: mclure at SRI-UNIX
To: header-people at mit-mc
Subject: headers without to's

I've noticed a lot of messages coming out of Berkeley's VAX system
which have no "to" address in their header. Is this legal? It's
hard to know whether the message was sent to a distribution list
or me in particular.


RMS@MIT-AI (Sent by RMS0@MIT-AI) 09/12/81 04:46:04
To: HEADER-PEOPLE at MIT-MC
Reformatting messages is a reasonable idea, but isn't it always
better to do it in the user's mail reader program than in the FTP server?
This way 1) it is easy to let different users do it differently,
2) it doesn't have to be irreversible.


Date:      12 Sep 81 9:03:33-EDT (Sat)
From:      Dave Crocker <dcrocker@udel>
To:        mclure at Sri-Unix
cc:        header-people at Mit-Mc
Subject:   Re:  headers without to's

Only From and Date are officially required, on the arpanet.

dave


Date: 15 Sep 1981 1026-PDT
From: Daul at OFFICE  
Subject: ADD THESE NAMES (there is no header-people-request)
To:   header-people at MIT-MC
cc:   daul

Date: 15 Sep 1981 1002-PDT
From: Daul
Subject: Please add two people...
To:   header-people-request at MIT-MC
cc:   daul


Please add:

Andrews@OFFICE      and      clen@OFFICE

Thanks,  Bill
-------
-------

Date: 29 Sep 1981 1726-PDT
From: Daul at OFFICE  
Subject: List Of Currently Used Header Fields For ARPAnet Mail Traffic
To:   header-people at MIT-MC
cc:   daul

Does anyone have a lst (complete or otherwise) of all the header fields used
on/in Arpanet mail?  I have read RFC733, but there are many more types of fields
being used here (Arpaland).  Thanks,  --lliB
-------

Date: Tuesday, 29 Sep 1981 23:39-PDT
To: Daul at OFFICE-2
Cc: header-people at MIT-MC
Subject: Re: List Of Currently Used Header Fields For ARPAnet Mail Traffic
Pizza-type: Nobones
In-reply-to: Your message of 29 Sep 1981 1726-PDT.
From: greep at RAND-UNIX

There is no such thing as a complete list of header fields, since any
arbitrary field may be added as long as it conforms to the syntax rules.
The best you can do is collect a sample of messages and assume they
represent the most common fields.

Date:      2 Oct 81 17:50:57-EDT (Fri)
From:      Dave Crocker <dcrocker@udel>
To:        header-people at Mit-Mc
Subject:   multiple at-signs

I am curious how many mail systems actually can handle the
multiple at-signes (e.g., "foo at bar at blat") that is
legal in RFC733.  I would appreciate reports from people
who know of systems that can and systems that cannot properly
cope.

Dave


Date:  2 Oct 1981 1536-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: multiple at's and at-signs
To: DCrocker at UDEL
cc: Header-People at MIT-MC

     The TOPS-20 MM mailsystem handles such addresses, both in
parsing and generating them.  It is especially sophisticated with
such addresses when the system uses its friend XMAILR as the mail
delivery process.
-------

Date: 2 October 1981 19:59-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  multiple at-signs
To: dcrocker at UDEL
cc: HEADER-PEOPLE at MIT-MC

Babyl's mail reading side can parse and hand FOO@BAH@HUMBUG to
the mail composition side for replying.

On 20X Babyl's mail composer does the right thing; at last it
writes the correct MAILER or XMAILR file.  MAILER on most 20x
sites does the wrong thing the last time I looked, though at BBN
it was fixed to find the host name by scanning backward from the
end for "@" rather than scanning forward from the beginning.  And
XMAILR wins, of course.

The ITS mailer daemon can mail to such addreses if you ask it
nicely enough, though I don't think it gets the header right (I
may be wrong on this).  Unfortunately none of the three mail
composition programs on ITS (MAIL, RMAIL, Babyl) ask the ITS
mailer nicely enough when you give them simply the string
FOO@BAH@HUMBUG.  If you were to type "FOO@BAH"@HUMBUG, they'd all
send the right thing to COMSAT, and you'd at least get the mail
sent.  Anyway, since it's probably not too hard, I may fix
Babyl's ITS mail sending code.  I can't say what will happen with
MAIL and RMAIL.

Date: 2 October 1981 20:00-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  multiple at-signs
To: dcrocker at UDEL
cc: HEADER-PEOPLE at MIT-MC

Also, Multics EMACS can handle multiple atsigns properly.

Date: 2 Oct 1981 2240-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: DCrocker at UDEL, HEADER-PEOPLE at MIT-MC
In-reply-to: Message of 02 Oct 81 at 1959 EDT by EAK@MIT-MC
Subject: Multiple Atsigns
Message-id: <[MIT-DMS].211795>

The MIT-DM and -XX READER program and mailer demon COMSYS handle
multiple atsigns correctly.  They just look for the last atsign
in the address.  I think the headers come out right too.
	Dave



Date: 3 October 1981 03:47-EDT
From: David A. Moon <Moon at MIT-MC>
Subject: multiple at-signs
To: EAK at MIT-MC
cc: HEADER-PEOPLE at MIT-MC, dcrocker at UDEL

These work completely in Comsat and Rmail.  The only place in ITS where
they don't work is in the :MAIL command, which is because it has its own
address parser which is left over from the days before the present mail
system (Comsat).  Some day that address parser will be ripped out and it
will simply supply the string the user typed to the mail system, at
which point multiple @'s will work in the :MAIL command, too.

Multiple @'s are actually used around MIT, for sending mail between
Chaosnet hosts that aren't on the Arpanet and outside-world Arpanet
hosts that don't know there is a Chaosnet.

Date: 3 October 1981 03:55-EDT
From: David A. Moon <Moon at MIT-MC>
Subject: multiple at-signs
To: EAK at MIT-MC
cc: DCROCKER at MIT-MC, HEADER-PEOPLE at MIT-MC

Here's a follow-up to my previous message, just for laughs.  Also
making sure that multiple @'s really work in ZMail.

Mail-from: ARPANET site MIT-ML rcvd at 3-Oct-81 0421-EDT
From: MOON@MIT-MC
Date: 10/03/81 04:17:19
Subject: multiple at-signs

MOON@MIT-MC 10/03/81 04:17:19 Re: multiple at-signs
To: EAK at MIT-MC
CC: HEADER-PEOPLE@MIT-MC@EE@XX@ML@MC at MIT-DMS
CC: dcrocker@UDEL@AI@MC at MIT-ML
Here's another obnoxious message from me about multiple @'s.  The last one
probably looked pretty stupid; it turns out multiple @'s don't work in ZMail
although no doubt they will soon.





Date: 5 Oct 1981 1126-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: dcrocker at UDEL, header-people at MIT-MC
Subject: Re:   multiple at-signs
Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11765715618.28.71.24348 at DEC-MARLBORO>
In-reply-to: Message from      Dave Crocker <dcrocker@udel>
              of 2-Oct-81 1750-EDT

Version 5 of MS (DEC's rather MM-like mailsystem) does handle multiple
atsigns properly.  Unfortunately I've not yet been able to get a copy
of this out to the ARPANET because my DECNET link to our ARPANET machine
has been mostly unusable lately.  As soon as I can I will get a copy
of it to DEC-MARLBORO (via magtape (ugh) if necessary) and anyone interested
in getting a copy should drop me a line...
   --------

Date: 21 October 1981 2135-EDT
From: Craig Everhart at CMU-10A
To: Dave Crocker <dcrocker at udel> 
Subject:  Re: multiple at-signs
CC: header-people at Mit-Mc
In-Reply-To:  Dave Crocker's message of 2 Oct 81 16:50-EST
Message-Id: <21Oct81 213514 CE10@CMU-10A>

On the CMU PDP10s, RdMail can handle any number of "@"s or " at "s.
Unfortunately, the current mail deliverer can't handle more than one "@"
in an address, so the practical limit for local delivery is two "@"s--one
gets stripped off in the queueing process.  This limitation should be
going away soon, I like to think.

Date: 21 Oct 1981 2202-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: New NBS proposed draft standard for Message Formats available
To:   Header-People at MIT-MC
cc:   Feinler at SRI-NIC

Proposed Federal Information Processing Standard "Specification for
Message Format for Computer Based Message Systems", dtd Sep 81 is now
out.  It is also highlighted in the 6 Oct 81 issue of the Federal
Register (Book 1 of 2, pages 49168 & 49169).  The address for
obtaining a copy is given in the F/R as

  Director,
  Institute for Computer Sciences and Technology
  National Bureau of Standards
  Attn: MFCBMS
  Washington, D.C.  20234

This is the result of the comments received on the "preliminary draft"
earlier in the year.

Enjoy,
Rich
-------

Date: Thursday, 29 October 1981  12:43-EST
From: Jan Walker <JWALKER at BBNA>
To:   Editor-People at Score
CC:   Header-people at MC
Subject: mail systems standards

The following message is typical of many that have been arriving
lately via the Editor-People mailing list.  At least, I can only
guess from the contents that they are arriving via editor-people.
They lack any To field, indicating that they have been composed
either in an editor by someone who does not know about message
format standards or by a quite ersatz message system.  In
addition to lacking a To field, they lack the "header" for the
Text field (which is a blank line).

    29-Oct-81 12:09:11-EST,411;000000000001
    Mail-from: SU-SCORE
    Received-Date: 29-Oct-81 1209-EST
    Mail-from: ARPANET site UCB-C70 rcvd at 29-Oct-81 0853-PST
    Date: 28 Oct 1981 21:30:36-PST
    From: decvax!utzoo!xxxxx at Berkeley
    Re: Alto User's Handbook
    Some of us who ARE interested to know that this document is now
    cleared for release would ALSO be interested in having a slightly
    more detailed mailing address than "Sara Dake at Xerox-PARC".


I protest this form of message being sent to a mailing list on
the ARPAnet.  At least some message systems that parse messages
according to the usual standards can't present this message in a
reasonable fashion.  The "text" field gets displayed in the
middle of the headers (because it is parsed as "unrecognized
other field", whose print position happens to be in the middle).
I can't use my mail reader to search for messages of this kind --
with no To: field and no Subj: field, there isn't a whole lot
available to search for.  The only real tip-off is the presence
of ! in the From: field.

I hope that whoever is responsible for the software (if it is a
message system that creates these messages) will find time to
make the messages sent conform to the standards.  (If people are
just creating the messages and "posting" them via an editor, then
they should take a little time out to study the usual conventions
involved in a draft message.)  It would make things more pleasant
for all of us readers.

Thanks.
Jan

Date: 29 Oct 1981 1143-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: Re: mail systems standards
To: JWALKER at BBNA, Editor-People at SU-SCORE
cc: Header-people at MIT-MC
In-Reply-To: Your message of 29-Oct-81 0944-PST

Jan -

     I agree with you completely.  The problem isn't the SCORE software,
since SCORE is just redistributing mail as it is being read.  The
problem is in the UNIX software (you'll notice this all comes from
Berkeley).  I have just as much trouble reading those messages with
MM (my mailsystem) as you do with yours (Hoimes?).

     By the way, do you think you can get your mailsystem fixed to
change nicknames into official names?  This is another of my pet peeves.

-- Mark --
-------

Date: Thursday, 29 October 1981  15:06-EST
From: Jonathan Alan Solomon <JSOL at RUTGERS>
To:   Mark Crispin <Admin.MRC at SU-SCORE>
Cc:   Editor-People at SU-SCORE, Header-people at MIT-MC, JSol at RUTGERS,
      JWALKER at BBNA
Subject: mail systems standards

I have a general complaint about the Beserkeley addresses all by
themselves. Not only do you have those cryptic addresses (which our
mailer insists on putting ^Vs before the !'s in - but that's another
problem with another solution), but you have no guarantee that the
address path the recipient used to send mail to you can be used
to send the reply. I have yet to successfully REPLY to any of the
messages I got from the "uucp" network.

Cheers,
Jsol

Date:      29 Oct 81 14:05:37-EST (Thu)
From:      Dave Crocker <dcrocker@udel>
To:        Jan Walker <JWALKER@bbna>
cc:        Editor-People at Su-Score, Header-people at Mit-Mc
Subject:   Re:  mail systems standards

The "To:" field is not officially required by the Arpanet standard.
The blank line most certainly IS required.

It would appear that the Berkeley relay mechanism is failing
to massage Unix mail into the required Arpanet format.

Dave


Date: 29 Oct 1981 1418-PST
From: J. Q. Johnson <Admin.JQJ at SU-SCORE>
Subject: Re:   Re:  mail systems standards
To: editor-people at SU-SCORE
cc: header-people at MIT-MC
In-Reply-To: Your message of 29-Oct-81 1105-PST

It seems to me that the discussion of mail system standards is not directly
relevant to the EDITOR-PEOPLE discussion of text editors.  Jan's initial
message was, since it related directly to problems with receipt of messages
on the mailing list.  But let's move further discussion of mail headers
off EDITOR-PEOPLE, and confine it to the HEADER-PEOPLE discussion group.

OK, everybody?  Let's get back to technical discussion of editor technology.
-------

Date: 29 Oct 1981 1725-EST
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: mail systems standards
To: JSOL at RUTGERS, Admin.MRC at SU-SCORE
cc: Editor-People at SU-SCORE, Header-people at MIT-MC, JWALKER at BBNA,
    JNC at MIT-XX
In-Reply-To: Your message of 29-Oct-81 1600-EST

	I've got a better one than that. I got some mail from a uucp
site (via Berkeley) with a 'Reply-to:' line. Needless to say, after
I replied to the message, I got back a message 'User or mailbox not
known at this site'.
-------

Date: 29 October 1981 1546-PDT (Thursday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: uucp addresses
To: HEADER-PEOPLE at MC

This is not really Berkeley's fault.  The UUCP network is a bizarre
sort of animal.  There are several hundred computers on it currently
(I *think* -- I'm not even sure, and I'm supposed to be in charge
of the World UUCP Map).  Many of these systems are at various
Bell Labs facilities.  There are two problems:

1) UUCP is a store and forward system of the lowest order -- most
   connections are made at intervals on dialup lines (via autodialers).
   Many sites are "slaves" only -- they never make calls, but are polled
   for traffic by other systems.  Some sites only poll other sites when
   the originating system has traffic, not on a regular basis.

   New sites can (and do) join the network without any formal 
   announcement (in many cases) so that every day it seems someone
   new has popped up.

   All of this makes it very difficult to backtrack paths to other
   than well-known sites.  I can usually do it, but only because I 
   deal with this stuff all the time and have all the info.

2) There have been considerable "gateway" problems between the ARPANET
   and the UUCP net.  For quite a while, Berkeley was providing the
   only such service, and that was dicontinued for quite some time
   for technical reasons.  Now I believe the gateway is back, so
   replies to individuals should again be possible.

It is important to remember that each field in a UUCP address is
a separate computer:

ucla-s!lauren@Berkeley

if used as an address on the Arpanet, would send the message to 
Berkeley via the ARPANET.  Berkeley would then forward the message
to:

ucla-s!lauren

via the UUCP net.  The current convention is that addresses which
combine UUCP and ARPA address in this way take the ARPA hop first.
Normally, the ARPA address would be the gateway (in this case
Berkeley), and the UUCP address would be RELATIVE to Berkeley.

By the way, the UUCP name for Berkeley is ucbvax.
So if you saw a message from:

ucbvax!ihnss!research!bart

(with no ARPA field for some reason), you could reply to:

ihnss!research!bart@Berkeley

Does any of this make sense?  I freely admit that this is a confused
situation, but there are alot of people out there in UUCP-land, and
overall, the network works pretty well in practice.

--Lauren--


Date: 29 Oct 1981 1541-PST
From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: Re: mail systems standards
To: Admin.MRC at SU-SCORE, JWALKER at BBNA, Editor-People at SU-SCORE
cc: Header-people at MIT-MC
In-Reply-To: Your message of 29-Oct-81 1145-PST

These tell-tale exclamation points indicate that "UUCP" is the culprit.
The problem is that there are numerous versions of Unix, each with many
different mail programs. Actually, the forwarding of this mail by
Berkeley is quite suspect, since most of those "UseNet" users are not
Arpa contractors.  I am not arguing for stopping information flow,
but the problem is that these people communicate with autodialers that
call each other up at 2am every morning.  Thus by the time the message
gets to them, and they give their response, it has often gone through
a half dozen phone hops and taken a week.  In the meantime we get
another dozen responses from other scattered about the country because
of the phase problem.  If you think this is bad on editor-people, you should
see unix-wizards!

I think pressure should be brought against Bezerkeley to stop polluting
the mail systems with stuff that does not conform to RFC 733.

	-- Bill
-------

Date: 29 Oct 1981 16:39:12-PST
From: mo at LBL-UNIX (Mike O'Dell [wizard])
To: header-people at mit-mc
Subject: busted headers

At the risk of inviting flames, I suggest mail readers should be
more robust.  Definition of robust:  be conservative in what you
do, but be liberal in what you let others get away with.  In the
case of a mail reader, it should get suspicious when it stops finding
things that look like headers and starts finding things that look
like text, in spite of a possibly missing blank line.

I realize the importance of adherence to standards, but you can't
trust anyone's code but your own, and then only if you are truly brave.
	
	-Mike


Date: 29 Oct 1981 2036-PST
From: Brian K. Reid <CSL.BKR at SU-SCORE>
Subject: Re: busted headers
To: mo at LBL-UNIX, header-people at MIT-MC
In-Reply-To: Your message of 29-Oct-81 1639-PST

Don't be ridiculous. Mail reading programs are a stupid place to do AI.
Mail interchange has to be simple and reliable, and there is an existing
interchange format for it, however flawed. To ignore the standard and
generate crap is both ignorant and vain.
-------

Date: 30 Oct 1981 0118-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: busted headers
To: Header-People at MIT-MC

     I agree with both Mike and Brian on this.  A mail reading
program should be robust enough to not die totally if the
standard is violated.  The program shouldn't execute an illegal
instruction or otherwise crash, nor should it destroy the mail
file, etc.  But Brian is also right in that a mail sending
program should not send crap.  Beserkley's badly formatted UUCP
mail has been annoying me too.

     I can easily come up with an example where an improperly
formatted message will appear to obey the standard to a
moderately sophisticated program (such as MM; other programs will
behave similarly).  Such a program, attempting to parse the
message according to the standard, may find itself doing
something -- to its human user -- totally random in processing
the message, yet perfectly reasonable given the badly formatted
message.  Garbage In, Garbage Out.

-- Mark --
-------

Date: 30 Oct 1981 1042-EST
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: mo at LBL-UNIX, header-people at MIT-MC
Postal-address: "73 Concord St., Maynard, Mass. 01754"
Subject: Re: busted headers
Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11772272127.29.71.10909 at DEC-MARLBORO>
Regarding: Message from mo at LBL-UNIX (Mike O'Dell [wizard])
              of 29-Oct-81 1939-EST

I'm reasonably certain that there aren't any mailsystems that crash
or anything when they try to display Beserkeley's mixed-up messages.
However, my mailsystem (which is probably typical) attempts to display
headers "intelligently".  This may involve a combination of displaying
them in a certain order, omitting certain headers, compressing long
address lists, and so forth.  If an unparsable message arrives,
my mailsystem must instead now display it literally in its entirety.
Just to let me know that it isn't a bug, it also warns me:

	%Incorrectly formatted header for this message, displaying literally

or something like that.  I don't think this means it isn't robust;
but it is still an annoyance, with or without the warning line.
   --------

Date: 30 Oct 1981 1859-EST
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: MsgGroup at MIT-MC, Header-people at MIT-MC
Postal-address: "73 Concord St., Maynard, Mass. 01754"
Subject: DECmail
Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11772362638.19.71.8834 at DEC-MARLBORO>

DEC announced yesterday a product called DECmail, which is DEC's
"long-awaited" (?) entry into the world of commercial electronic
mail.  I would be very interested in hearing what anyone out in
the real world of electronic mail thinks about it (I have my own
opinions, but for the moment I'm witholding them).  I'm especially
interested in hearing of the experiences of anyone who has actually
tried to use it.
   --------

Date: 31 Oct 1981 0406-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: [Communications Satellite <COMSAT at MIT-AI>: Msg of Saturday, 31 October 1981 03:46-EST]
To: HEADER-PEOPLE at MIT-AI

Mail-from: MIT-AI rcvd at 31-Oct-81 0347-EST
Date: 31 October 1981 03:46-EST
From: Communications Satellite <COMSAT at MIT-AI>
Subject: Msg of Saturday, 31 October 1981 03:46-EST
To: JSol at RUTGERS

A copy of your message is being returned, because:
"HEADER-PEOPLE-REQUEST" at MIT-AI is an unknown recipient.
	Message not sent.
 Failed message follows:
-------
Date: 31 Oct 1981 0347-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: add me to the list
To: header-people-request at MIT-AI

if I am not already on the list
-------

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


Date: 31 Oct 1981 07:48:13-PST
From: cbosgd!mark at Berkeley
To: header-people@mc
Subject: please add me to the list

Please add csvax.mark@berkeley and ingvax.eric@berkeley to the list.
Sorry to send to the whole list, but header-people-request came back
with no such addressee.
	Mark Horton


Mail-from: ARPANET site UCB-C70 rcvd at 2-Nov-81 1457-PST
Date: 2 Nov 1981 14:44:52-PST
From: vax135!hocsg!brs at Berkeley
FROM: b.r.schatz
TO: vax135!ucbvax!editor-people@Berkeley
DATE: 11/2/81, 12:00 PM
SUBJECT: mail header standards
being the propagator of a UNIX mail program as well as being linked
into Bell product developments,
I would be very interested in a summary of the ARPA standard and
comparison to the UNIX one.
Remailed-date:  2 Nov 1981 1558-PST
Remailed-from: J. Q. Johnson <Admin.JQJ at U-SCORE
Remailed-to: header-people at IT-MC


Date:  2 Nov 1981 1919-PST
From: J. Q. Johnson <Admin.JQJ at SU-SCORE>
To: header-people at MIT-MC

The EDITOR-PEOPLE mailing list received this message in the mail today,
though I decided that HEADER-PEOPLE was a more appropriate destination.
Note that the header has bad format (no From: field).
                ---------------

Mail-from: ARPANET site UCB-C70 rcvd at 2-Nov-81 1722-PST
Date: Sun Nov  1 15:54:36 1981
Subject:  Problems with Mail Addresses

This is a quick flame to the ARPA people who have had problems
replying to UUCP addresses . . . its no picnic from this end
either.  I have to deal with submitting to a "ucbvax" address
set up just for the purpose of porting through to ARPA when I
want to send mail to a digest.  Those of you (ARPA folk) who
wish to reply to news/mail from UUCP sites can undoubtedly
learn to apply the reverse procedure (having said that, I hope
such a procedure exists).  Don't assume your mail system has
no problems talking with the outside world!!!!

Alan Roberts
(ucbvax!decvax!duke!unc!wolfvax)




-------

Date: Friday, 6 November 1981  00:47-EST
From: SWERNOFSKY at BBND
To:   Larry Campbell <LCAMPBELL at DEC-MARLBORO>
Cc:   Swernofsky at BBND, Header-people at MIT-MC, MsgGroup at MIT-MC,
      HUMAN-NETS at MIT-MC
Subject: evaluation of DECmail (long message)

    From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
    Postal-address: "73 Concord St., Maynard, Mass. 01754"

    DEC announced yesterday a product called DECmail, which is DEC's
    "long-awaited" (?) entry into the world of commercial electronic
    mail.  I would be very interested in hearing what anyone out in the
    real world of electronic mail thinks about it (I have my own
    opinions, but for the moment I'm witholding them).  I'm especially
    interested in hearing of the experiences of anyone who has actually
    tried to use it.

Richard Moore is a good friend of mine and the manager of certain system
operations at Commercial Union, an insurance company with 13 DEC
machines of various flavors.  DECmail is being field-tested at their
facility; they have generated about 50 QARs ("and a lot of sore
fingers") on the subject.  Herewith his opinions on this dinosaur:

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

	I would not have used the word dinosaur.  In fact, I wasn't
intending to give sweeping condemnations of the product.  Just the
facts, that's bad enough.  Decmail is an incomplete product at this
time.  The DEC people we deal with claim that this is only what is 
to be expected from a product in early field test.  However, I think
that DECMAIL's problems go deeper than that.

	DECMAIL is designed to be a part of an office automation package
that DEC is going to released in parts over the next few years.  Its
basic release is going to be frozen after awhile unless you want to
buy the full package, and then it will be updated as the package is
updated.  So if DECMAIL isn't what you want as a generally applicable
EMS by the freeze date, forget it.  

	If you don't wish to try your luck with a part of DEC 
(the office automation group) that may be ambivalent to your general 
system needs, be it known that DECMAIL doesn't seem to pay as much
attention to VMS as to be called ambivalent.  It does not use RMS-11
for the storing of memos (Gee look MA, BACKUP don't work).
It does not use the VMS conventions for the meaning of such special 
control characters as ^O and ^C.  It has a special lock-in editor
which "looks like" EDT, but it isn't.  Instead, the editor that
comes as part of DECMAIL is based on the word-processor that will
be put on the VAX and DECMAIL doesn't allow you to bypass it,
either by asking for the Editor of your choice, OR defining keys.
(the subset of EDT doesn't allow for the defining of keys since
"Sally Secretary might break something" -[that was a DEC spokesman]).
DEC has promised that someday real soon DECMAIL will allow for the
inputing of a non-DECMAIL generated file to be entered into the 
"system".  Right now you can do it by a kluge, but DEC won't admit it
since you will have SYSPRV while you read in the file of your choice.
(someday DEC will learn about turning off Priv.s, when we told them
about the kluge, they promised to remove it for the next release).
The list goes on and on and on.. 

	I am running late.  The fifty QAR's are real QAR's.  As far
as I can tell DECMAIL was not designed top-down.  (that is a guess)
Instead it was designed, bottom up.  The menus are not consistent in
the method that you use to exit them.  The Marketing people quickly
learned that the most obvious way to exit the ditty was to turn off
their terminals.  If you want a piece of EMS that will be usable 
only by a small subset of the system users with any ease at all,
then DECMAIL is for you.  If not, be comforted by the fact that the
internal developers for DEC won't touch it with a ten-foot pole.
They use the freebee MAIL instead.

----------------

Date: 18 Nov 1981 19:15:26-PST
From: chico!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
To: HEADER-PEOPLE@MIT-AI
Subject: mailing list

Please add my name to your mailing list.  Thanx,

		Steve Bellovin





Date: 25 Nov 1981 0957-PST
From: Daul at OFFICE  
Subject: Header Field Order
To:   header-people at MIT-MC

Are the fields required to be in any particular order?  What do the
standards say (ARPA/NBS)?
-------

Date: 25 Nov 1981 1122-PST
From: Feinler at SRI-NIC
Subject: Re: Header Field Order
To:   Daul at OFFICE, header-people at MIT-MC
cc:   FEINLER

In response to the message sent  25 Nov 1981 0957-PST from Daul@OFFICE  

Bill,  Do you have a copy of RFC-733?  This sets the standards
for mail headers.  Also, there will be a new mail protocol which
runs under TCP/IP (which every host on the network must have
in place by Jan. 83) called SMTP.  I only have a draft of it so far...
will get the final soon.  You are welcome to a copy of
the draft which is in <protocols>smtp-11-81.txt on our machine.

These two items should give you some insight.

As you probably know the old ARPANET mail protocol was
kind of an afterthought and is thoroughly mixed up with FTP.
This will not be the case with the new protocols.

Jake
-------

Date: 25 November 1981 1422-EST (Wednesday)
From: David Lamb
To: Daul at OFFICE-2
Subject:  Re: Header Field Order
CC: header-people at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  Daul@OFFICE's message of 25 Nov 81 12:57-EST
Message-Id: <25Nov81 142229 RD00@CMU-10A>

According to RFC733, page 13 (the "NOTE" in the section on General
Syntax of Messages), header fields are not required to be in any order.
It does recommend the order Date, From, Subject, Sender, To, CC, other
fields.  Only Date and From are required (page 14), aside from
requirement of a Sender field under certain circumstances.

Date: 30 Nov 1981 15:36:12-PST
From: chico!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
In-Reply-To: Daul at OFFICE's message of 25 Nov 1981 0957-PST
To: Daul@OFFICE, header-people@MIT-MC
Subject: Re:  Header Field Order

RFC-733 explicitly permits any order for header fields, though
it does give a suggested order.




Date:      14 Jan 82 6:15:59-EST (Thu)
From:      Michael Muuss <mike@brl>
To:        MSGroup at Mit-Ai, Header-People at Mit-Ai
cc:        Stef at Darcom-Ka, Mike at Brl
Subject:   TCP Digest & Discussion of Mailer Headers

As a result of talking about connections between multiple networks,
and mail relay between NCP and TCP style ArpaNet hosts, there has
recently been a fair amount of discussion about MAIL headers,
and proper multiple network naming and addressing schemes.

I would be interested in getting pointers to earlier discussion of
this material, so that the TCP-Digest people don't run open loop
and re-invent the wheel.  Especially if it came out oblong!
				-Mike



Date: 28 Jan 1982 1556-EST
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: [jnc at mit-csr at mit-multics: LSI11 lossage]
To: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC
cc: lwa at MIT-XX

Mail-from: ARPANET site MIT-MULTICS rcvd at 27-Jan-82 2206-EST
Date: 27 Jan 1982 2152-EST (Wednesday)
From: jnc at mit-csr at mit-multics
Reply-to: jnc@mit-xx
Subject: LSI11 lossage
To: acm
CC: ddc,lwa,martin,dt,jnc

	When Dave went to start using the +/-15V on the TST machine, he
had a lot of problems. The -15V was completely dead, and the backplane
wiring for the +15V was broken in several places. I suspect that this
happened when Greg plugged that CTL board in in the wrong place and
blew out a bunch of things. Dave is going to send a message out
describing the things that were broken in more detail. The backplane
contains shorts on the contact side of the etch; i.e. where they are
unreachable, so that backplane may be unfixable. Opinions?
-------

	Well, when I try to say 'REP ALL' to this message in MM, I get
addresses of the form 'DDC at MIT-Multics'. It is my understanding
that you weren't supposed to have local addresses in outside mail;
is this true? If not, who is at fault, MM or the mail sender? Should
the From field not have the 'at MIT-Multics'? Should MM be putting
the whole source on the destination, and not just the last host?
What gives?
-------

Date: 28 Jan 1982 1339-PST
From: Mark Crispin
Subject: Re: [jnc at mit-csr at mit-multics: LSI11 lossage]
Sender: ADMIN.MRC at SU-SCORE
To: JNC at MIT-XX, mmcm at MIT-AI, header-people at MIT-MC
cc: lwa at MIT-XX
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 28-Jan-82 1256-PST

Local addresses should not be allowed outside of a host.  MM takes
great pains not to compose such messages for network mail.  When it
encounters a header such as your example it takes an educated guess
of where the origin is.  It's even more academic than that, because
multiple at addresses are going to be going away very soon anyway.
-------

Date: 28 Jan 1982 1453-PST
From: Daul at OFFICE  
Subject: MM document wanted...
To:   jnc at MIT-XX
cc:   mmcm at MIT-AI, Admin.MRC at SU-SCORE, lwa at MIT-AI,
cc:   header-people at MIT-MC

can someone tell me of a good document on MM or even XMAILER?  Thanks,  Bill
-------

Date: 28 Jan 1982 1513-PST
From: Mark Crispin
Subject: Re: MM document wanted...
Sender: ADMIN.MRC at SU-SCORE
To: Daul at OFFICE-2, jnc at MIT-XX
cc: mmcm at MIT-AI, lwa at MIT-AI, header-people at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 28-Jan-82 1453-PST

The current set of MM documentation is pretty out of date.  My wife is
working on an up to date manual.  What there is can be found online at
SU-SCORE on <DOCUMENTATION>MM.* (the * is a wildcard meaning all files
with first filename MM).  SU-SCORE supports ANONYMOUS FTP login with any
password.

-- Mark --
-------

Date: 28 January 1982 1818-EST
From: David Lamb at CMU-10A
To: J. Noel Chiappa <JNC at MIT-XX> 
Subject:  Re: [jnc at mit-csr at mit-multics: LSI11 lossage]
CC: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC,
    lwa at MIT-XX
Reply-To: Rdmail at CMU-10A
In-Reply-To:  J. Noel Chiappa's message of 28 Jan 82 15:56-EST
Message-Id: <28Jan82 181843 RD00@CMU-10A>

That address is perfectly legal according to RFC733, the ARPAnet header
standard.  However, a lot of mailers don't understand addresses with
multiple "at"s in them.

Date: 28 Jan 1982 1704-PST
From: Mark Crispin
Subject: Re:  Re: [jnc at mit-csr at mit-multics: LSI11 lossage]
Sender: ADMIN.MRC at SU-SCORE
To: Rdmail at CMU-10A, JNC at MIT-XX
cc: mmcm at MIT-AI, header-people at MIT-MC, lwa at MIT-XX
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 28-Jan-82 1518-PST

However, ARPA has decreed that nobody is supposed to use multiple at
addresses.  I found that out earlier this month.  They were in fact
rather angry at MIT and Stanford for generating such addresses.  I
expressed my distaste at this part of the standard being declared
invalid with no general announcement to the ARPANET community.

Apparently this had been decided by the Internet working group some
time ago.  Their reasons were perfectly valid; but their proposed
solution was completely unacceptable for a number of sites.  There
is a new proposal which is actually rather elegant and looks towards
the future, but it hasn't been officially announced yet.
-------

Date: 28 Jan 1982 1728-PST
From: Daul at OFFICE  
Subject: Please remove CLEN@OFFICE-2
To:   header-people at MIT-MC

she has moved to greener pastures.  Thanks,  -Bill
-------

Date: Tuesday,  2 Feb 1982 19:01-PST
To: greep at ISL
Postmark: <Tamalpais:Mailer@SUMEX-AIM@2Feb82 19:01:24>
Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1857-PST
Received: Network mail from host MIT-MC for greep on Thu Jan 28 15:57:49 1982
Date: 28 January 1982 1818-EST
From: David Lamb at CMU-10A
To: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: [jnc at mit-csr at mit-multics: LSI11 lossage]
CC: mmcm at MIT-AI, Admin.MRC at SU-SCORE, header-people at MIT-MC,
    lwa at MIT-XX
Reply-To: Rdmail at CMU-10A
In-Reply-To: J. Noel Chiappa's message of 28 Jan 82 15:56-EST
Message-Id: <28Jan82 181843 RD00@CMU-10A>
Sender: root at ISL

That address is perfectly legal according to RFC733, the ARPAnet header
standard.  However, a lot of mailers don't understand addresses with
multiple "at"s in them.


Date: Tuesday,  2 Feb 1982 19:02-PST
To: greep at ISL
Postmark: <Tamalpais:ADMIN.MRC@SU-SCORE@2Feb82 19:02:28>
Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1900-PST
Received: Network mail from host MIT-MC for greep on Thu Jan 28 15:41:05 1982
Date: 28 Jan 1982 1513-PST
From: Mark Crispin at ISL
Subject: Re: MM document wanted...
Sender: ADMIN.MRC at SU-SCORE
To: Daul at OFFICE-2, jnc at MIT-XX
cc: mmcm at MIT-AI, lwa at MIT-AI, header-people at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 28-Jan-82 1453-PST
Sender: root at ISL

The current set of MM documentation is pretty out of date.  My wife is
working on an up to date manual.  What there is can be found online at
SU-SCORE on <DOCUMENTATION>MM.* (the * is a wildcard meaning all files
with first filename MM).  SU-SCORE supports ANONYMOUS FTP login with any
password.

-- Mark --
-------


Date: Tuesday,  2 Feb 1982 19:26-PST
To: greep at ISL
Postmark: <Tamalpais:ADMIN.MRC@SU-SCORE@2Feb82 19:26:05>
Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1923-PST
Received: Network mail from host MIT-MC for greep on Thu Jan 28 17:20:16 1982
Date: 28 Jan 1982 1704-PST
From: Mark Crispin at ISL
Subject: Re:  Re: [jnc at mit-csr at mit-multics: LSI11 lossage]
Sender: ADMIN.MRC at SU-SCORE
To: Rdmail at CMU-10A, JNC at MIT-XX
cc: mmcm at MIT-AI, header-people at MIT-MC, lwa at MIT-XX
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 28-Jan-82 1518-PST
Sender: root at ISL

However, ARPA has decreed that nobody is supposed to use multiple at
addresses.  I found that out earlier this month.  They were in fact
rather angry at MIT and Stanford for generating such addresses.  I
expressed my distaste at this part of the standard being declared
invalid with no general announcement to the ARPANET community.

Apparently this had been decided by the Internet working group some
time ago.  Their reasons were perfectly valid; but their proposed
solution was completely unacceptable for a number of sites.  There
is a new proposal which is actually rather elegant and looks towards
the future, but it hasn't been officially announced yet.
-------


Date: Tuesday,  2 Feb 1982 19:30-PST
To: greep at ISL
Postmark: <Tamalpais:Daul@OFFICE-2@2Feb82 19:30:14>
Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1927-PST
Received: Network mail from host MIT-MC for greep on Thu Jan 28 17:46:02 1982
Date: 28 Jan 1982 1728-PST
From: Daul at OFFICE
Subject: Please remove CLEN@OFFICE-2
To: header-people at MIT-MC
Sender: root at ISL

she has moved to greener pastures.  Thanks,  -Bill
-------


Date: 3 Feb 1982 1054-EST
From: PDL at MIT-DMS (P. David Lebling)
To: Header-people at MIT-MC
In-reply-to: Message of 03 Feb 82 at 1017 EST
Subject: Ridiculous Header
Message-id: <[MIT-DMS].222392>

Someone seems to be sending a message with this baroque header around
like a hot potato.  I've gotten about 10 copies of it so far.  Is it
considered kosher for a message to have two date fields, two sender
fields, etc.?  This question is independent of the aesthetic considerations,
of course.  I can't even tell who sent it to whom when and why...

   Date: Tuesday,  2 Feb 1982 19:26-PST
   To: greep at ISL
   Postmark: <Tamalpais:ADPSC@USC-ISI@2Feb82 19:26:13>
   Mail-from: ARPANET host RAND-UNIX rcvd at 2-Feb-82 1924-PST
   Received: Network mail from host MIT-ML for rand-msggroup on Fri Jan 22 14:12:36 1982
   Date: 22 Jan 1982 1349-PST
   Sender: ADPSC at USC-ISI
   Subject: Call for COMPCON papers
   From: jim.fcc-net at UDEL
   Reply-To: jim.fcc-net at UDEL
   To: msggroup at MIT-AI, Human-nets at MIT-AI
   Message-ID: <[USC-ISI]22-Jan-82 13:49:13.ADPSC>
   Sender: root at ISL

Comments, anyone?

	Dave



Date: 3 Feb 1982 1225-EST
Sender: MOOERS at BBNA
Subject: Re: Ridiculous Header
From: MOOERS at BBNA
To: PDL at MIT-DMS
Cc: Header-people at MIT-MC, 
Cc: Mooers at BBNA
Message-ID: <[BBNA] 3-Feb-82 12:25:46.MOOERS>
In-Reply-To: <[MIT-DMS].222392>

It is probably intended to be a forwarded message.  Somehow,
the necessary blank line <CRLF><CRLF> between the first
set of header lines and the text was erased.

---Charlotte

Date: Wednesday,  3 Feb 1982 10:13-PST
To: greep at ISL
Postmark: <Tamalpais:reid@Shasta@3Feb82 10:13:50>
Date: Wednesday,  3 Feb 1982 10:13-PST
To: PDL at MIT-DMS (P. David Lebling)
Cc: Header-people at MIT-MC
Subject: Re: Ridiculous Header
In-reply-to: Your message of 3 Feb 1982 1054-EST.
             <[MIT-DMS].222392>
From: Brian Reid <reid at SHASTA>
Sender: root at ISL

As nearly as I can tell, Greep@SU-ISL is sending that message around.
I don't know why. There are some bugs in the incoming mailer at SU-ISL
whose fingerprints are all over that header. He might not even realize
he is doing it.

Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1013-PST
Date: Wednesday,  3 Feb 1982 10:13-PST
To: PDL at MIT-DMS (P. David Lebling)
Cc: Header-people at MIT-MC, Steve Tepper <Greep at SU-ISL>
Subject: Re: Ridiculous Header
In-reply-to: Your message of 3 Feb 1982 1054-EST.
             <[MIT-DMS].222392>
From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

As nearly as I can tell, Greep@SU-ISL is sending that message around.
I don't know why. There are some bugs in the incoming mailer at SU-ISL
whose fingerprints are all over that header. He might not even realize
he is doing it.

Date:  3 Feb 1982 1023-PST
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Ridiculous Header
To:   MOOERS at BBNA, PDL at MIT-DMS
cc:   Header-people at MIT-MC, Mooers at BBNA, ZELLICH

In response to the message sent  3 Feb 1982 1225-EST from MOOERS@BBNA

Besides the odd header format, there were, indeed, several copies of
some messages sent out.  The latter problem was due to a screwed-up
mail distribution system - perhaps the bad formatting of the
forwarded header/message was also due to the broken distributor (although
I feel all the stuff in some of those headers is a little excessive -
I don't feel a strong need to know the senders' US Mail address, etc.).
-Rich
-------

Date: Wednesday,  3 Feb 1982 10:47-PST
To: greep at ISL
Postmark: <Tamalpais:reid@Shasta@3Feb82 10:47:18>
Date: Wednesday,  3 Feb 1982 10:46-PST
To: Header-people at MIT-MC
Cc: PDL at MIT-DMS (P. David Lebling)
Subject: Re: Ridiculous Header
In-reply-to: Your message of Wednesday,  3 Feb 1982 10:13-PST
 Wednesday,  3 Feb 1982 10:13-PST.
From: Brian Reid <reid at SHASTA>
Sender: root at ISL

I think I see what is happening. When a message arrives in Greep's
mailbox at Tamalpais, it is somehow being resubmitted to the Tam mailer
for reparsing and retransmission. The Tamalpais mailer, like many dumb Unix
mailers, works by parsing the message header to figure out who the 
message should be transmitted to. The message as it arrives in that
mailbox will have these fields in it: 
    Postmark: <Tamalpais:reid@Shasta@3Feb82 10:13:50>
    Date: Wednesday,  3 Feb 1982 10:13-PST
    To: PDL at MIT-DMS (P. David Lebling)
    Cc: Header-people at MIT-MC
    Subject: Re: Ridiculous Header
    In-reply-to: Your message of 3 Feb 1982 1054-EST.
                 <[MIT-DMS].222392>
    From: Brian Reid <reid at SHASTA>
Some trying-to-be-clever forwarding system then adds this line
the front:
    To: greep at ISL
and submits it to the Tamalpais mailer for "forwarding". The mailer
there sees a "From:" field in it that does not correspond to the person
who submitted the mail to the mailer, so it adds 
    Sender: root at ISL
at the end of the header and
    Date: Wednesday,  3 Feb 1982 10:13-PST
at the beginning of the header. It then gets re-transmitted to all
of the original recipients in addition to the intended recipient of
"greep at ISL". Since one of those recipients was Header-People at MC,
the message is routed through MC where it acquires this field:
    Via:     MIT-MC; 3 Feb 1982 1324-EST
and ends up in all of our mailboxes looking like that.

Wow.
Brian

Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1047-PST
Date: Wednesday,  3 Feb 1982 10:46-PST
To: Header-people at MIT-MC
Cc: Steve Tepper <greep at SU-ISL>, PDL at MIT-DMS (P. David Lebling)
Subject: Re: Ridiculous Header
In-reply-to: Your message of Wednesday,  3 Feb 1982 10:13-PST
 Wednesday,  3 Feb 1982 10:13-PST.
From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

I think I see what is happening. When a message arrives in Greep's
mailbox at Tamalpais, it is somehow being resubmitted to the Tam mailer
for reparsing and retransmission. The Tamalpais mailer, like many dumb Unix
mailers, works by parsing the message header to figure out who the 
message should be transmitted to. The message as it arrives in that
mailbox will have these fields in it: 
    Postmark: <Tamalpais:reid@Shasta@3Feb82 10:13:50>
    Date: Wednesday,  3 Feb 1982 10:13-PST
    To: PDL at MIT-DMS (P. David Lebling)
    Cc: Header-people at MIT-MC
    Subject: Re: Ridiculous Header
    In-reply-to: Your message of 3 Feb 1982 1054-EST.
                 <[MIT-DMS].222392>
    From: Brian Reid <reid at SHASTA>
Some trying-to-be-clever forwarding system then adds this line
the front:
    To: greep at ISL
and submits it to the Tamalpais mailer for "forwarding". The mailer
there sees a "From:" field in it that does not correspond to the person
who submitted the mail to the mailer, so it adds 
    Sender: root at ISL
at the end of the header and
    Date: Wednesday,  3 Feb 1982 10:13-PST
at the beginning of the header. It then gets re-transmitted to all
of the original recipients in addition to the intended recipient of
"greep at ISL". Since one of those recipients was Header-People at MC,
the message is routed through MC where it acquires this field:
    Via:     MIT-MC; 3 Feb 1982 1324-EST
and ends up in all of our mailboxes looking like that.

Wow.
Brian

Date: Wednesday, 3 February 1982  11:21-PST
From: Jonathan Alan Solomon <JSOL at USC-ECLB>
To:   Zellich at OFFICE-3 (Rich Zellich)
Cc:   Header-people at MIT-MC, MOOERS at BBNA, PDL at MIT-DMS
Subject: Ridiculous Header

Seems that SU-ISL's mailer is sending out return mail to everybody who
sends to it (in the case of some of it the sender was INFO-VAX at
SANDIA, a distribution list). This caused a loop, which I stopped by
forcing all mail for INFO-VAX to be sent to a file, and I redistribute
manually. Since last night, I have about 50 TOPS-20 pages of junk from
SU-ISL, and no real mail for INFO-VAX to send out. Ahh, such is life
on the ARPAnet.

--JSol

Date:  3 Feb 1982 1218-PST
From: Richard Furuta <Furuta at WASHINGTON>
Subject: Re: Ridiculous Header
To: reid at SU-AI, header-people at MIT-MC
cc: Furuta at WASHINGTON

Incidentally, it is not only header-people who are victims of this
mailer.  The other groups I know of include info-vax, msggroup, and
info-terms.  I think I received from ten to twenty old messages
yesterday, courtesy of Tamalpais' mailer.  Indeed, info-vax has gone
to indirect redistribution until the bug is fixed.

Since the messages arriving are around a week old, I suspect that the
problem was related to the Usenet newsgroups in some fashion,
particularly since the info-vax messages' headers contain a field
saying that they are intended for news.info-vax.  Perhaps someone's
computer finally got around to calling up SU-ISL and attempted to
deliver the collection of news and thereby originated the flood of
repeated messages.  Do you suppose it'll all happen again next Tuesday
evening?

			--Rick
-------

Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1956-PST
Date: Wednesday,  3 Feb 1982 19:56-PST
To: Header-People at MIT-MC, Info-VAX at MIT-MC
Cc: Neumann at SRI-KL, Hartwell at ISL, Greep at ISL, Nowicki at Shasta
Subject: the great SU-ISL mail looping mystery solved
Reply-to: Reid at SU-AI
From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

As you all know, there has been a problem recently with mail passing through
SU-ISL littering the airwaves with multiple repeated copies to half of the
Arpanet. The SU-ISL machine is on our local ethernet, so I took the liberty
of poking around in it, and after several hours of tense debuggery I have
tracked down and fixed the cause of the loop. There's a lesson in here
somewhere, but I fear it might just be "never import software; always write
your own".

People on SU-ISL use the Rand mail handler MH, a very nice mail package that
provides good handling and responsible local transport of mail. One of the
things that MH tries very hard to do is to authenticate mail that is being
sent. If a user sends a message that already contains a "From" field, the MH
delivery software checks to make sure that the user is not lying about who
is is, and if the MH delivery program detects fibbing, it adds a "Sender:"
field identifying who it thinks is the real author of the mail.

Unfortunately, the mail transport sections of MH just aren't up to the
quality of the rest of it, so running MH in our ethernet environment
required a better mail delivery agent than its built-in code.

SU-ISL is not on the Arpanet; mail for it is routed through SUMEX and
converted from Arpanet FTP into Xerox Ethernet MTP protocol, where it is
transmitted by Ethernet to SU-ISL. At SU-ISL, a program called MTPserver is
run, which accepts RFC's on the Ethernet for mail delivery, and when it gets
one, attempts delivery of the mail. MTPserver runs the Xerox mail protocols,
and thinks it is dealing with Berkeley mailboxes.

The delivery is actually accomplished by running a program named
"delivermail", which was written at Berkeley and is part of the Berkeley
mail system. The Berkeley mail system is somewhat of an opposite of the Rand
mail system: it has a really primitive (some call it terrible) mail handling
component, but an extremely sophisticated and flexible mail delivery
component. So the Unix systems at Stanford use Berkeley delivery software
regardless of whether they use Berkeley mail handling software.

The Berkeley "delivermail" program discovers that (a) the intended recipient
of the mail is local to ISL, and (b) that the recipient is a user of the MH
mail system and therefore wants his mail delivered in MH format. Deliver
therefore duly forks off to the MH mail program, /etc/mh/mail, charging it
with accomplishing the local delivery of this mail. The mechanism by which
"mail" is told that its job is to deliver incoming net mail rather than send
keyboard-origin mail is that it is run as "root", a privileged userid. This
program "mail" doesn't really know how to deliver mail; in true Unix fashion
it passes the buck off to somebody who does; in this case, the MH delivery
module /etc/mh/deliver, passing it a special option saying "I have been
invoked by privileged users, so don't edit this header at all; this is just
local delivery". Being deeply suspicious and trying to prevent forgery (as
mentioned before), the MH deliver program checks to see if that can be true;
it checks the user id (had better be "root"), and the local host id (had
better be the same).

For incomprehensible reasons, some anonymous person at ISL recently made a
"bug fix" to some piece of MH, recompiled, and reinstalled. Unfortunately,
the correct sources were not on that machine, only the original sources as
distributed from Rand (the updates to interface it to the Berkeley mailer
were off on another machine). So the Rand-original version of "mail" got
suddenly put up on ISL; it never heard of the Berkeley mailer, and in
particular it was not in the mood to invoke privilege when calling the local
delivery program. So there was an intended-use conflict, and the requisite
"this user is privileged" information did not get passed through to the
delivery program.

The delivery program responded to this conflict by saying "you are lying",
and refusing to honor the "just do local delivery" option handed it
(indirectly) by the Berkeley mailer. Because it thought that it had detected
a case of intended mail forgery, it treated the mail as being of local
origin, and therefore needing to be (a) verified and (b) parsed to find out
who the mail is supposed to be sent to. The verification discovered that the
mail had a random "From:" in it, so a "Sender: root at ISL" field was added.
The mail was then parsed to extract a list of recipients, some local and
some network; and a copy of the mail was then sent through normal delivery
channels to all of the recipients mentioned in the mail header. Loop.

I see the following morals in this story:
 * All of the software has compiled-in host names. Bad. A program operating
   in a network environment should determine its host name dynamically.
   Both Berkeley and Rand are equally guilty of this error, but it seems to
   be pretty much the way things are done under Unix, so they were only
   following convention. This made it impossible to distribute binary
   versions of the software from a single master source on one machine.
 * The Rand software is trying to make one program serve two totally
   separate functions, namely local delivery (if privileged) or origination
   delivery (if not privileged). The Swiss Army Knife is one of the few
   examples I have seen of a multi-purpose tool that does each job properly.
   The general Unix philosophy of having a program serve equally well for
   reading from the terminal or from a file or pipe is in a sense
   responsible, because there was (unusuable) information in the fact of
   the mail's having originated from the network and not from a keyboard.
 * The Rand local-origin delivery program parses the mail header to find
   out who the mail should be sent to. It should be getting this information
   "out of band" through some private communication from the mail handling
   program, rather than parsing the file. Doubly true if it can ever
   accidentally fall into this mode, as was happening in this bug.
 * Network programs like these should not communicate information to each
   other by the 1-bit channel of "being in privileged mode" or "not being
   in privileged mode". There are more civilized ways, like options.
   Admittedly this information path was not part of either the Rand system
   or the Berkeley system, but rather of the hack job that made them talk
   to each other.
 * Network programs like these should be written so that their debug modes
   can be activated without killing and restarting the process. All of them
   have a "debug mode" that can be turned on when the program is first run;
   there needs to be a way that it can be turned on and off by sending it
   special functions while it is actually running.

Sorry to bend your ears for so much text, but I figured that the community
should at least learn something from all of this nuisance.

Brian Reid



Date: 3 February 1982 23:39-EST
From: David Eppstein <KRONJ at MIT-MC>
Subject:  legal header?
To: HEADER-PEOPLE at MIT-MC
cc: BUG-BABYL at MIT-MC, Reid at SU-AI

Babyl barfs on the following:

    Reply-to: Reid at SU-AI
    From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

Is this legal?

Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 2204-PST
Date: Wednesday,  3 Feb 1982 22:04-PST
To: David Eppstein <KRONJ at MIT-MC>
Cc: HEADER-PEOPLE at MIT-MC, BUG-BABYL at MIT-MC
Reply-to: Reid at SU-AI
Subject: Re:  legal header?
In-reply-to: Your message of 3 February 1982 23:39-EST.
From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

Of course it's not legal.
I just haven't succeeded in convincing the guy who maintains
the mail gateway program that he should stop munging with
headers. 

Date:  4 Feb 1982 0026-MST
From: Jay Lepreau <Lepreau at UTAH-20>
Subject: Re: the great SU-ISL mail looping mystery solved
Sender: LEPREAU at UTAH-20
To: reid at SU-AI
cc: header-people at MIT-MC
In-Reply-To: Your message of 3-Feb-82 2103-MST

Wonderful loop!  There are two things Berkeley is doing which should help
a bit:
-- Finally, all local info, including host name, will be maintained
somewhere in the environment, not compiled into binaries.  You are right
that this has been a gross failing of Unix.
-- Delivermail is being replaced with something called sendmail, which I'm
told makes poor old delivermail look sick.  It keeps all local info,
including routing, in a file and not in the binaries.  It might even address
some of the other points you raised.
-------

Date:  4 February 1982 1114-EST (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> 
To: David Eppstein <KRONJ at MIT-MC> 
Subject:  Re: legal header?
CC: HEADER-PEOPLE at MIT-MC, BUG-BABYL at MIT-MC, Reid at SU-AI
Sender: Rick.Gumpertz at CMU-10A
In-Reply-To:  David Eppstein's message of 3 Feb 82 23:39-EST
Message-Id: <04Feb82 111436 RG02@CMU-10A>

RdMail at CMU doesn't like Brian's FROM field either.  Perhaps we should appeal
to the ARPANET POLICE, those same people who insisted that CMU put dots instead
of spaces between our first and last names!

		Rick

Date:  3 Feb 1982 1028-PST
From: POSTEL at USC-ISIF
Subject: re: ridiculous header
To:   header-people at MIT-MC


Dave:

i have also received several messages with this ridiculous header, but
with different texts.  The common elements are:

greep@isl
Tamalpais
root@ISL
2-Feb-82 19:26

i suugest that greep should send in an explaination.

--jon.
-------

Mail-from: SU-NET host SU-SHASTA rcvd at 3-Feb-82 1658-PST
Date: Wednesday,  3 Feb 1982 16:57-PST
To: Jonathan Alan Solomon <JSOL at USC-ECLB>
Cc: Steve Tepper <GREEP at RAND-AI>, Guyton at RAND-UNIX,
    header-people at MIT-AI, Mike at RAND-UNIX, MOOERS at BBNA,
    PDL at MIT-DMS, Reid at SU-AI, STEF at DARCOM-KA,
    ZELLICH at OFFICE-3
Subject: Re: Mail looping
In-reply-to: Your message of Wednesday, 3 February 1982  16:03-PST.
From: Brian Reid <reid at Shasta>@Shasta at Sumex-Aim

Three of us (none associated with SU-ISL) are working full time on this
problem. It seems to be some design flaw in the Rand mail handler,
but debugging network software is tricky.


Date:  3 Feb 1982 1552-PST
From: Steve Tepper <GREEP at RAND-AI>
Subject: Mail looping
To: STEF at DARCOM-KA, JSOL at USC-ECLB, PDL at MIT-DMS, ZELLICH at OFFICE-3,
    Reid at SU-AI, MOOERS at BBNA, Mike at RAND-UNIX, Guyton at RAND-UNIX
cc: header-people at MIT-AI, greep at RAND-AI

My apologies for all the inconvenience everyone suffered.  The problem
is at ISL, which is on the Stanford Ethernet and is accessed through
the gateway at Sumex-Aim.  For some reason ISL's mail system seems to
treat incoming mail as mail that should be processed for sending.
The problem is not at Rand-Unix.  It showed up when I tried having
my mail forwarded from Rand-Unix to greep@ISL@Sumex-Aim, which I will
certainly not try again in the near future!

The person responsible for the ISL machine is Steve Hartwell,
who can be reached (I think) as hartwell@shasta@Sumex-Aim.  If that
doesn't work, try CSL.LAB.HARTWELL@SU-Score.
-------


Date: 24 Feb 1982 2301-PST
From: Richard Furuta <Furuta at WASHINGTON>
Subject: [cbosg!harpo!whuxlb!nrf at Berkeley:]
To: header-people at MIT-AI
cc: Furuta at WASHINGTON

Can't someone please convince Berkeley to at least include a To: line in
the messages it sends out onto the net?  I just got this message.  Note
that there is very little in either the header or in the message to
indicate what distribution list it came from (other than the hint
that it was forwarded through MIT-MC).
			--Rick
                ---------------

Mail-from: ARPANET site MIT-MC rcvd at 24-Feb-82 2204-PST
Date: 24 Feb 1982 21:52:57-PST
From: cbosg!harpo!whuxlb!nrf at Berkeley

you should have asked about this when it happened, we solved that problem
years ago!




-------


foo

Date: 6 Apr 1982 2144-EST (Tuesday)
From: lwa at mit-csr
Reply-to: lwa.INP@MIT-Multics
Subject: Common usage in recipient names
To: HEADER-PEOPLE at MIT-MC
CC: lwa.INP at MIT-Multics

What are the common formats for recipient names allowed by various
mail sending and reading programs?  In particular I am interested
in the interpretation of single and double quotes, angle brackets,
and parentheses in determining the mailbox name a message is to be
delivered to given a recipient name.

The reason that I ask is that I am rewriting a mail sender and want
to conform to common usage.  My current program works as follows:
	The only delimiters between recipient names are commas and
	ASCII control characters (includes <CR> and <LF>).
	Within each recipient name:
	 Strings enclosed in angle brackets have precedence over other
	 strings; if the recipient name includes a string enclosed in
	 angle brackets that string is used as the mailbox address.
	 Strings enclosed in parentheses are treated as comments and
	 are ignored, unless the entire parenthesized string is
	 enclosed in double quotes.
	 If the recipient name does not include a string enclosed in
	 angle brackets, the program uses the entire recipient name
	 string as the mailbox.
	 Double quotes allow the inclusion of arbitrary strings (including
	 the normal recipient name delimiters) within the mailbox name.

Does this sound right?  If not, where do the problems lie?  Is there by
any chance a compendium of common practice for mailers, since many
things allowed by RFC733 are discouraged in practice?

Thanks.
					-Larry Allen
-------


Date: 13 Apr 1982 1517-PST
From: Daul at OFFICE  
Subject: RFC-733 query
To:   header-people at MIT-MC
cc:   daul

Is there a restriction on the number of addresses a mail item can be sent
"From"?  Can one have:

From: daul@office,  wdaul@office-2, daul@mit-mc

Feel free to answer only to me at daul@office, if you don't think the
readership is interested.
-------

Date: 15 Apr 1982 2326-PST
From: Daul at OFFICE  
Subject: RFC733 request
To:   header-people at MIT-MC

Date: 13 Apr 1982 1517-PST
From: Daul
Subject: RFC-733 query
To:   header-people at MIT-MC
cc:   daul

Is there a restriction on the number of addresses a mail item can be sent
"From"?  Can one have:

From: daul@office,  wdaul@office-2, daul@mit-mc

Feel free to answer only to me at daul@office, if you don't think the
readership is interested.
-------
My first try at sending this seems to have failed, so..........
...............................................................
-------

Date:  1 May 1982 1159-PDT
From: Daul at OFFICE  
Subject: RFC-733 (multiple header fields)
To:   header-people at MIT-AI
cc:   daul

Is there a restriction on the number of addresses a mail item can be sent
"From"?  Can one have:

From:  daul@office, wdaul@office-2, menlo70!daul@ucb-c70

Thanks,  --Bill  (DAUL at OFFICE)
-------


Date: 11 May 1982 1651-PDT
From: POSTEL at USC-ISIF
Subject: how many messages a day does your computer handle?
To:   header-people at MIT-MC


really!

how many computer mail type messages a day go out from your computer
to other computers, how many come in, and how many are sent between users
internal to your system?

what counts as a message? do all copies of the same text count as one
message, or once for each recipient?

the answer to these questions are desired be people trying to size
some mail handling systems.

--jon.
-------

Date: 14 May 1982 0010-PDT
From: Daul at OFFICE  
Subject: Rumor Confirmation (CCIT new Inter-System Communications Standards)
To:   msggroup at MIT-MC, header-people at MIT-MC
cc:   daul

I have heard a rumor that new standards have been drawn-up/released in
the last 2 or 3 weeks.  Is it true and, if so how can I get further info?
Thanks,  --Bill
-------

Date: 14-May-82  9:00:48 PDT (Friday)
From: white at PARC-MAXC
Subject: Re: Rumor Confirmation (CCIT new Inter-System Communications Standards)
In-reply-to: Daul's message of 14 May 1982 0010-PDT
To: Daul at OFFICE
cc: msggroup at MIT-MC, header-people at MIT-MC, White.pa

Bill,  The CCITT rapporteur's group on message handling facilities (i.e., electronic mail) maintains a living document that will eventually become--but is not now--a proposed CCITT recommendation (i.e., standard).  Version 3, which reflects the work done at the March meeting in Melbourne, was indeed completed just a week or two ago. I would be happy to send a copy to you and to other interested members of MSGGroup, provided the number of such people is modest.  /Jim

Date:     27 May 82 17:48:16-EDT (Thu)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Draft Revision to RFC #733

Greetings.

As most of you are aware, ARPA has directed that RFC #733,
"Standard for the Format of ARPA Network Text Messages" be
modified, to meet the needs of the larger Internet context.
By virtue of your membership in the Header-People mailing
list, I would appreciate your reviewing a draft of the
revised specification.  We are under severe time pressures; if
you can find it in your heart to provide me with feedback
by the end of next week, I will be eternally grateful.

The specification is the result of several meetings and 
considerable discussion.  However, the document is still
subject to change.  Now is the time to voice your suggestions.

The file is located at UDel-Relay.  You can login through
FTP with username anonymous, and any password.  The name
of the file is:  /usa/dcrocker/733/new.ff

If is fully formatted, indented and uses form-feeds.
Underlines are handled by line overprinting (rather than
character backspacing).  The document is 46 paper pages,
under 113K characters, and ends with the Table of Contents.

Thanks.  Dave


Date:     30 May 82 20:49:36-EDT (Sun)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Relay-Sites at UDel-Relay, MsgGroup at Mit-Mc, 
          Header-People at Mit-Mc
cc:       CSNet-Staff at UDel-Relay
Subject:  XMAILR problem.

I apologize for shotgunning this message, but a condition has
arisen that needs to be fixed as quickly as possible.

We happen to have a very slow NCP; it is the Rand Front-End and
commonly gives us about 1 (one) KBaud on a connection.  This is
being worked on, by its author, but currently is a fact of life.
Even with a faster NCP, we would eventually run into the following
problem.

Apparently, the Tops-20 XMAILR Arpanet channel imposes an
absolute 5 minute limit on TOTAL transmission time for
a message.  If the message takes longer, XMAILR aborts the
connection and requeues the message.  One fix, being
tested at USC, is to impose the limit on 1Kbyte chunks
of messages.

As the UDel-Relay machine is servicing more Phonenet sites,
it is getting stung more frequently by this XMAILR behavior.
Like many of Unix sites, our FTP server forwards incompletely
received Arpanet messages -- there was originally dictated
by occasionally misbehaving senders.  Given the current
problem, I am turning that feature off our own FTP server.

Dave


Date: 31 May 1982 14:20-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: Ignore this message, unless...
To: header-people at MIT-MC

you get two copies, in which case let me know.  I'm just
testing a new version of the mailing list.


Date: 31 May 1982 1315-PDT
From: Mark Crispin
Subject: XMAILR and timeouts
Sender: ADMIN.MRC at SU-SCORE
To: MsgGroup at MIT-ML
cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I think it's been agreed that we'll change XMAILR, with one note:
It isn't unreasonable for a system manager to feel that his system
mailer should not be tied up for more than 5 minutes delivering a
single copy of a message to a single site, EVEN IF it is merely because
the receiving site is too slow.  Much of the sort of traffic which is
impacted by XMAILR's present behavior are junk mail which isn't even
legitimate usage of ARAPNET anyway.
-------

Date: Monday, 31 May 1982 15:58-PDT
To: Admin.MRC at SU-SCORE
Cc: MsgGroup at MIT-ML, Header-People at MIT-MC, DCrocker at UDEL-RELAY
Subject: Re: XMAILR and timeouts
In-reply-to: Your message of 31 May 1982 1315-PDT.
From: greep at SU-DSN

Obviously, no matter how fast all the systems are, there is some length
of message which will exceed any fixed timeout.  An alternate strategy
would be for the mailer to delay long messages until the system load is
light, or late at night, or whatever.

Date: 1 Jun 1982 0032-PDT
Sender: STEF at DARCOM-KA
Subject: Re: XMAILR and timeouts
From: STEF at DARCOM-KA
To: greep at SU-DSN
Cc: Admin.MRC at SU-SCORE, MsgGroup at MIT-ML, 
Cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY
Message-ID: <[DARCOM-KA] 1-Jun-82 00:32:04.STEF>
In-Reply-To: Your message of Monday, 31 May 1982 15:58-PDT

In any case, what we now have is a single community with two conflicting
policies which severely impact unwitting users and sites who are not
able to control what happens to them.

The 5 minute XMAILR maximum coupled with a "forward partial copies"
policy in CSNET was deadly.  The new ECL XMAILR policy of a 5 minute
maximum per 1000 bytes looks like a winner.

Can we look forward to its rapid installation in XMAILRS around the net
so as to operationally resolve what is otherwise going to be a long
untenable summer.

Thanks - Stef

Date:  1 Jun 1982 1339-PDT
From: Mark Crispin
Subject: Re: XMAILR and timeouts
Sender: ADMIN.MRC at SU-SCORE
To: STEF at DARCOM-KA
cc: greep at SU-DSN, MsgGroup at MIT-ML, Header-People at MIT-MC,
    DCrocker at UDEL-RELAY
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 1-Jun-82 0032-PDT

     Sorry for the flames, and especially to those of you who
will receive this message four times.  I did have to reply to
Stef's message.

     I suppose you folks are all aware that XMAILR has done this
5 minute timeout for two years or so now.  It isn't that this is
something recent, or for that matter something that suddenly came
up.  I am a bit distressed if not angered by terms like "rapid
installation" to the first patch which comes along.  It smacks of
administratively mandated changes in software which otherwise is
never modified.  The fact is, XMAILR is part of a package
receiving extensive development and maintainence.

     In addition, as a primary maintainer and developer of
XMAILR, I can't help but wonder why a message about the internals
of a particular message delivery process was sent to all of
MsgGroup and Header-People instead of to one of the XMAILR
maintainers.  It smacks of washing dirty laundry in public.
Sometimes public broadcasting of such an issue is necessary if
the maintainers are unresponsive, but in this case I had heard
nothing until it was bannered across the mailing lists.  Among
other things, I never received a copy of the complaint addressed
to me personally.

     Now, as for the proposed changes, ECL's change nominally
fixes that particular problem, but is not in any way a general
solution.  I do not like patchwork or myoptic changes to solve an
individual problem.  The fact is, a more general solution to this
and other related issues has been specified, and will be
implemented in XMAILR in the next few weeks.

     I also wish to point out that the "forward partial copies"
policy in CSNET was, is, and will continue to be a bug until it
is removed.  Under no circumstances will XMAILR remove timeouts
entirely.  I acknowledge that XMAILR's old timeout policy was
inadequate.  As part of the solution we will have a 5 minute per
1000 byte timeout; but I think 33 baud is too slow of a datarate
to be considered "reasonable" and XMAILR in the future may
enforce a minimum of, say, 300 baud throughput.

     CSNET is clearly an important project, but the attitude that
its needs override all other needs is wrong.  Compromises can and
will be made to accomodate CSNET, but at the same time a site
running XMAILR cannot be expected to have its electronic mail
service "go south" for extended periods of time while long
messages are being delivered to a slow mail receiving process on
CSNET.  The problem is heightened by the fact that CSNET does not
recognize the XRCP extension to the FTP mail protocol, so if a
hundred recepients on CSNET are each receiving a message that
takes 10 minutes/copy to deliver, it could take 17 hours to
deliver it!  In a non-multitasking mail delivery model such as
XMAILR's, that can mean that all network mail service (or on
systems like SCORE which use XMAILR exclusively ALL mail service)
is "shut off" for that period of time.  I would therefore like to
ask the maintainers of the CSNET FTP server to extend it to
support XRCP in exchange for a more reasonable timeout policy on
the part of XMAILR (a change which we will make in any case).

-- Mark --
-------

Date:     1 Jun 82 19:47:54-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Admin.MRC at Su-Score
cc:       STEF at Darcom-Ka, greep at Su-Dsn, MsgGroup at Mit-Ml, 
          Header-People at Mit-Mc, DCrocker at UDel-Relay
Subject:  Re:  XMAILR and timeouts

Mark --

None of the relevant software, running on the UDel-Relay
machine, were developed for CSNet.  While CSNet is funding
the machine, CSNet policies and activities are not particularly
relevant to this technical problem.

The FTP server is a derivative of the original Illinois one, 
and most of its copies have demonstrated the forward-partial-copy 
philosophy for six, or so, years.  

Implementing an unofficial ftp command might help, as will the
approaching improvements to the NCP, but they only postpone
the fundamental incompatibility, not remove it.

Sorry about sending the original note to a large distribution
list.  We got stung twice in three days from different sites,
with this problem and I did not have the address of a
person notify.  XMAILR is quite popular & running on many sites, 
so I wanted specifically to make sure they were aware of
the policy.  The problem had occurred a month or so ago, and
the people at Rutgers apparently knew nothing about XMAILR's policy.


Date: 1 Jun 1982 1818-PDT
Sender: STEF at DARCOM-KA
Subject:  Re: XMAILR and timeouts
From: STEF at DARCOM-KA
To: MsgGroup at MIT-ML, Header-People at MIT-MC
Message-ID: <[DARCOM-KA] 1-Jun-82 18:18:29.STEF>
In-Reply-To: DCrocker message of 1 Jun 82 19:47:54-EDT (Tue)

Hi Marc, et al --- I am at quite a loss to know why this conflict of
policies has not caused trouble among us in the net before now, but the
trouble has bitten me twice in the last month and it cost a large amount
of time, and wasted message transmission effort both times.

Is it posible that no one ever sent a long enough message to cause this
repeated attempt behavior from an XMAILER site, where the message was
never going to make it in 5 minutes, and XMAILR was nevr doing to give
up trying?

The problem seems to have been a sleeper, and I agree that it is very
unpleasant to be awakened by such things.  But, I want to protest on my
own behalf that I am mostly just the guy who announced the nature of the
basic policy conflict, and I want to note that I understand the strong
tendency for rudely awakened people to kill the messenger first, and fix
the problem second.  Surely this will not be the last arrow I attract.

Swish ===========> Stef

Date: 2 June 1982 14:53-EDT
From: Ken Harrenstien <KLH at MIT-MC>
Subject: Re-transmitted message (or, why are you seeing this?)
To: HEADER-PEOPLE at MIT-MC

Some people have complained that without warning they are
now seeing a dialogue about XMAILR which they are completely
uninterested in.  What really happened is that their names,
being part of Postel's MTP interest group mailing list,
were added to Header-People so that Dave Crocker could
begin discussion of the latest RFC733 revisions.

Unfortunately, his initial message was sent just before I
tested the new list.  In order to start over from the right place,
I am re-sending that message.  Apologies to those long-time
Header-people members who have already seen it.

	-----
Date:     27 May 82 17:48:16-EDT (Thu)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Draft Revision to RFC #733

Greetings.

As most of you are aware, ARPA has directed that RFC #733,
"Standard for the Format of ARPA Network Text Messages" be
modified, to meet the needs of the larger Internet context.
By virtue of your membership in the Header-People mailing
list, I would appreciate your reviewing a draft of the
revised specification.  We are under severe time pressures; if
you can find it in your heart to provide me with feedback
by the end of next week, I will be eternally grateful.

The specification is the result of several meetings and 
considerable discussion.  However, the document is still
subject to change.  Now is the time to voice your suggestions.

The file is located at UDel-Relay.  You can login through
FTP with username anonymous, and any password.  The name
of the file is:  /usa/dcrocker/733/new.ff

If is fully formatted, indented and uses form-feeds.
Underlines are handled by line overprinting (rather than
character backspacing).  The document is 46 paper pages,
under 113K characters, and ends with the Table of Contents.

Thanks.  Dave


Date: 2 June 1982 14:53-EDT
From: Ken Harrenstien <KLH at MIT-MC>
Subject: Re-transmitted message (or, why are you seeing this?)
To: HEADER-PEOPLE at MIT-MC

Some people have complained that without warning they are
now seeing a dialogue about XMAILR which they are completely
uninterested in.  What really happened is that their names,
being part of Postel's MTP interest group mailing list,
were added to Header-People so that Dave Crocker could
begin discussion of the latest RFC733 revisions.

Unfortunately, his initial message was sent just before I
tested the new list.  In order to start over from the right place,
I am re-sending that message.  Apologies to those long-time
Header-people members who have already seen it.

	-----
Date:     27 May 82 17:48:16-EDT (Thu)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Draft Revision to RFC #733

Greetings.

As most of you are aware, ARPA has directed that RFC #733,
"Standard for the Format of ARPA Network Text Messages" be
modified, to meet the needs of the larger Internet context.
By virtue of your membership in the Header-People mailing
list, I would appreciate your reviewing a draft of the
revised specification.  We are under severe time pressures; if
you can find it in your heart to provide me with feedback
by the end of next week, I will be eternally grateful.

The specification is the result of several meetings and 
considerable discussion.  However, the document is still
subject to change.  Now is the time to voice your suggestions.

The file is located at UDel-Relay.  You can login through
FTP with username anonymous, and any password.  The name
of the file is:  /usa/dcrocker/733/new.ff

If is fully formatted, indented and uses form-feeds.
Underlines are handled by line overprinting (rather than
character backspacing).  The document is 46 paper pages,
under 113K characters, and ends with the Table of Contents.

Thanks.  Dave


Date: 2 June 1982 14:53-EDT
From: Ken Harrenstien <KLH at MIT-MC>
Subject: Re-transmitted message (or, why are you seeing this?)
To: HEADER-PEOPLE at MIT-MC

Some people have complained that without warning they are
now seeing a dialogue about XMAILR which they are completely
uninterested in.  What really happened is that their names,
being part of Postel's MTP interest group mailing list,
were added to Header-People so that Dave Crocker could
begin discussion of the latest RFC733 revisions.

Unfortunately, his initial message was sent just before I
tested the new list.  In order to start over from the right place,
I am re-sending that message.  Apologies to those long-time
Header-people members who have already seen it.

	-----
Date:     27 May 82 17:48:16-EDT (Thu)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Draft Revision to RFC #733

Greetings.

As most of you are aware, ARPA has directed that RFC #733,
"Standard for the Format of ARPA Network Text Messages" be
modified, to meet the needs of the larger Internet context.
By virtue of your membership in the Header-People mailing
list, I would appreciate your reviewing a draft of the
revised specification.  We are under severe time pressures; if
you can find it in your heart to provide me with feedback
by the end of next week, I will be eternally grateful.

The specification is the result of several meetings and 
considerable discussion.  However, the document is still
subject to change.  Now is the time to voice your suggestions.

The file is located at UDel-Relay.  You can login through
FTP with username anonymous, and any password.  The name
of the file is:  /usa/dcrocker/733/new.ff

If is fully formatted, indented and uses form-feeds.
Underlines are handled by line overprinting (rather than
character backspacing).  The document is 46 paper pages,
under 113K characters, and ends with the Table of Contents.

Thanks.  Dave


Date: 4 June 1982 21:39-EDT
From: Jr. Mike McDevitt <M.JR at MIT-MC>
To: HEADER-PEOPLE at MIT-MC

please add me to your mailing list. tks.

Date:     14 Jun 82 11:36:40-EDT (Mon)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  733 revision query

Well, folks, some interesting comments have been coming in.  While
I have opinions about some suggestions, I would like to get your
general reactions to them.  The following is in no particular
order.  Please send your comments/votes directly to me, unless
you think there should be more general discussion by the group.


At-sign vs. Period

    There has been question about the continued use of '@',
instead of just using periods.  At the original discussion
meetings, a couple of groups lobbied very strongly for the
firewall that at-sign provides.  They were concerned about
being able to tell when to change parsing schemes.


From field

    Some people are confused about what is legal in the From
field.  The new spec requires that the From field only contain
addresses, rather than permitting general text (unusable as
a machine address) if there is a Sender field.  The reason for
this is to simplify global field handling.  Currently, you have to
make a full pass through the header before you know whether to
accept a From field which has random text in it.  This way,
the field is required always to have usable text.  Thoughts??


Simplicity:  Machine orientation

    Several votes have been cast for making the standard even
more stringent, such as specifying exactly one acceptable form
for an address, rather than permitting optional and alternative
forms.  This has been specifically requested for date/time format.
If enough of you agree, and few enough complain, I will make
the change of installing the subset format (taken from Postel's
SMTP spec) as the ONLY permitted form.  Another suggestion is
that only '@' be used, discarding the " at " form of <at>.
Whadaya think?

    Some requests for more time zones have been made.  Anyone
feeling strongly about this should send me a complete list of
the time-zone strings (and what they reference) that they want
added.

    Another request is to do away with the line-folding convention.
That is, do not coerce the text to fit within some arbitrary
line size, unless the user does it explicitly.  The suggestion
comes, I feel, from having access to nicely modern systems.
Unfortunately, a large segment of our user population is stuck
with far more simplistic (dumb) systems.  I strongly suggest
we keep the current rigidity.  (To give you some idea of the
problem, a number of sites had trouble with the fact that the
draft of this new spec had underlines and bare carriage-returns.)


Groups & Comments

    The simplification of what constitutes an acceptable address,
down to mailbox & group, seems to be generally acceptable to
people.  There is one suggestion for eliminating groups and another
that SOME sort of extension mechanism be permitted.  I think that
there may be a compatible solution.

    The gist of the argument against group lists is that they
do not have any defined action or semantics associated and
hence are simply comments.  Why not just count them as such?

    There is one case in which the group bracketing  MIGHT
have some special action; it was the original reason for
including them in 733:  If the group list contents are included
with the message, then a display program could choose to display
only the group name and not display the group's addresses.

    On the other hand, I have not seen anybody actually include
the list contents and do not know of any system that selectively
shows addresses versus group names.

    What I would like to propose is two sets of comments.  The
first is parenthetical text, as is currently used, which is
handled as strictly throw-away, at all times.  (This, of course,
is a lie, given that some systems still put the person's
name in a parenthetical string after the mailbox.)  The
second type would be treated by the official syntax as
exactly the same as a parenthetical comment, however superset
parsers would use it to signal to themselves that there is
a private convention that is being invoked.  I will
tentatively suggest braces ( {} ) as the surrounding delimiters.


Context-sensitive dots

    People seem to be having a lot of trouble with the fact that
periods are lexical delimiters throughout the specification.  They
note that the spec REALLY cares only in the domain spec and does
not care in local-part.  My concern is that the lexical analyzer
not be context sensitive, treating dot differently for the two
syntactic situations.  If somebody really wants to fight this
point, then I suggest that they provide me with an alternative
formal syntax.


Content munging

    People generally despise the idea of having a relay go in and
play with the headers.  They believe that the sending system
should make any and all necessary changes.  Unfortunately, this
is not really possible, without requiring that all the sending
systems be rather sophisticated and always have fast access to
large tables.  The Arpanet history is such that I doubt we can
demand this.  Basically, our problem is that we have limited
control over the programmers and organizations which compose
the network.  The more dramatic (traumatic) the change, the
less conformance.


Meta-Field names

    A suggestion was made that there be a meta-convention for
user-defined fields, similar to Remail-*.  I suggest that
we define X-*.  Thoughts?

Dave


Date: 16 June 1982 14:50-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: 733 revision query
To: dcrocker at UDEL-RELAY
cc: HEADER-PEOPLE at MIT-MC

{} syntax extension.  It isn't right to treat this as comments.
The need is for a way to have a structured (more than one token)
address, which can be passed through relays (including the special
case of automatic reply-addressing mail readers) which don't understand
the semantics, but do parse the structured syntax to the extent that
they send the same characters back to the originating host (which does
understand the semantics).  Note that the host name, which everyone
has to understand the semantics of, would be outside the brackets,
where it can be seen without parsing anything inside the brackets.

dots.  I think the present treatment of dots is kludgey, confusing,
and error-prone.  It's really just a result of BNF limitations.
Any implementation would be much better off treating a host address
as a single token, and then splitting it at the dots once it has been
identified (through the parsing process) as a host address.  The alternative
of following the BNF and splitting everything in the header at the
dots, and then gluing back together everything that has been identified
as not a host address, is more likely to cause problems, especially if
this parser is going to be implemented 50 different times and mostly
by people in a hurry.

I would suggest changing the formal syntax not to include the dots as
delimiters, but simply to leave host addresses as an atomic token, and
provide an informal appendix specifying that a host address consists of 1
or more components with dots between them.

header munging.  I agree that host addresses have to be translated by mail
relays; that's the only way that will work.  It seems desirable to minimize
the number of different kludgey formats, in order to make such translation
less error-prone.  I think groups should be eliminated; if for some reason
it is necessary to find out the expansion of a mailing list, SMTP provides
a way to do that.  In the more advanced mail systems, the distinction
between a user and a group is not even meaningful, since many users
have their mail delivered pre-sorted and/or in multiple copies to
short-term and long-term mailboxes.  Certainly both "name <mailbox>" and
"mailbox (name)" need not both exist; I'd rather see the former flushed
since it complicates left-to-right parsing, but it is probably very much
too deeply entrenched by now.

date formats.  Since the mail systems I have any contact with have long
since learned either not to try to parse dates, or to understand literally
dozens of different date formats, I don't care in a practical sense.
Certainly it would be much cleaner to specify a standard date format,
however it's not very important since simple mail systems will not do
anything with the date anyway other than treat it as a character string
to display to the user.

Date: Wednesday, 16 Jun 1982 12:05-PDT
To: Dave Crocker <dcrocker at UDEL-RELAY>
Cc: Header-People at MIT-MC
Subject: Re:  733 revision query
In-reply-to: Your message of     14 Jun 82 11:36:40-EDT (Mon).
From: phyl at RAND-UNIX


Re:  Another suggestion is that only '@' be used, discarding the " at "
	form of <at>.  Whadaya think?

'@' don't work so good with interactive editors (sa MH's prompter),
	so long as it's the tty driver's line-kill.


Phyllis

Date: 16 Jun 1982 16:45:27 EDT (Wednesday)
From: Ken Pogran <pogran at BBN-UNIX>
Subject: Re:  733 revision query
In-Reply-to: Your message of 16 Jun 1982 12:05 PDT
To: phyl at RAND-UNIX
Cc: Dave Crocker <dcrocker at UDEL-RELAY>, Header-People at MIT-MC

Phyllis,

You're missing the (perhaps subtle) point.  At issue is what's
to be allowed in the message headers transmitted between systems.
There needn't be an exact correspondence between that and what a user
types to his local mail-input program.  More and more, mail-input programs
are being written that help a user formulate the header of the message
that he/she is typing in.  Putting the at-sign in the proper place
based on some other sort of input from the user is just one
more example of the help that such a program can provide.

Ken


Date: 16 Jun 1982 17:31:44-CDT
From: solomon at uwisc
To: header-people@mit-mc
Subject: Re: 733 revision

Concerning @ instead of "at":  The only system I know of that uses @ as
line-kill in the terminal driver is UNIX.  Back in the ancient past, it
was rather inconvenient to enter an @ sign (although to the best of my
knowledge, it was always possible).  For all versions distributed in
the last five or six years, however, it has been possible to change the
line kill character, and everybody I know of does so as a matter of
course (usually to ^U or ^X).

As a general principle, it's probably a mistake to hang on to an
anachronism just because you suspect that somebody else might object if
you remove it.  If somebody really objects on his own behalf, let him
speak now or forever hold his peace.

Date:  16 June 1982 20:13 edt
From:  Palter at MIT-MULTICS (Gary M. Palter)
Subject:  Re: 733 revision
Sender:  Palter.Multics at MIT-MULTICS
To:  Header-People at MIT-MC
In-Reply-To:  Message of 16 June 1982 18:31 edt from solomon

As maintainer of the mail system on a machine where @ is still the line
kill character, I vote for removing the " at " construct if it makes
parsing simpler.  (The parser in our mail system has no trouble with
either form and, in fact, does handle multiple @s but...)

Our users rarely have to actually type the at-sign.  The command line
syntax for addresses uses a keyword (-at) and users do not have to type
addresses as they appear in the header.

On the separate subject of {}, let me second Dave Moon's statement that
they should not be considered to be comments but rather are a form of
address whose internals are left to the sending (and perhaps receiving)
site to understand.  My mail system presently uses this format for some
of the possible addresses we support and will be using it more in the
future.

Date:     16 Jun 82 20:14:19-EDT (Wed)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  733' discussion transcript

I have been collecting people's comments about the revised
format proposal and will shortly be summarizing them.  For
those of you who are interested, they are available via
FTP on the UDel-Relay machine, in the file

	/usa/dcrocker/733/notes

in a batched file, with a line of 4 control-A's between messages.
There just under 70 messages.

Login anonymous and any password will permit you to read
the file.

Dave


Date: 17 Jun 1982 08:34:55-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: solomon at uwisc
cc: header-people at mit-mc
Subject: Re: 733 revision
In-reply-to: Your message of 16 Jun 1982 1713-PDT (Wednesday).

I do use @ as my line delete character, and even then, I PLEAD
for the abolition of " at " as a synonym.  I don't mind quoting
the character to use it, and if I get tired of it, is will be just
one more pressure to make me use something a little more standard
(Unix not withstanding).

Back in my Algol68 days, I can remember many discussions on how
to avoid "bold blanks" in tokens. "Bold" characters are used
in creating special words and when the grammar for Algol68 first
appeared, there was no direct exclusion of blanks within bold
character sequences!  This clearly posed typographic problems!
Finally, an add-on semantic rule simply outlawed them.

The point is that the spaces around the " at " are in fact "bold"
and cause a multitude of parsing problems in other places.
I STRONGLY lobby that son-of-733 specify that an internet address
consists a character sequence NOT containing any white space
and NOT containing anything you don't want treated as an ADDRESS.
I specifically mean "From: out behind the barn <up@chuck>"!!!
It is cute, but not that useful.  Besides, as more of us have to do
real intermailing between different message systems (as apposed to
simply mail in the Internet), the fewer special characters we
randomly interpret, the better off we will be.  Who knows,
there might be a mail system out there that specifies forwarding
as
	foo@bar>crap

If you ever want to talk to that, the <crap> currently allowed
makes that very hard.

I realized I am about to be ignited for heresy regarding non-ARPAnet
things. ARPAnet myopia may have been reasonable in the past,
but there are those of use who talked to other networks first
and ARPAnet later.  While it may be close to the centroid,
ARPAnet is not the center of the universe and I am very concerned
that our standards be capable of interoperating with other
standards (who "standards efforts" care as much about us as we do
about them!) with minimal grief.  I am NOT advocating rushing out
and adopting the NBS or X* recommendations; I think 733 is far
superior in many ways.  I am saying that my motivation for these
comments comes from concern about the ever-increasing amount of
bailing wire that must be constructed if I intend to talk to everyone
I can and need to talk to.

Sorry for the soapbox.

	-Mike




Date: 17 Jun 1982 1112-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: 733 revision
To: mo at LBL-UNIX
cc: solomon at UWISC, header-people at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 17-Jun-82 0834-PDT

Next you will be suggesting that we all have 7 digit user numbers
instead of usernames so we can conform with most IBM systems.

I think "From:User@Host" is ugly, certainly has no white space here,
do you object to the space between the "From:" and the "User@Host"?
(I'm being sarcastic)

On a more serious note, As you can see by my header, I like to be
somewhat verbose. I include my US Mail address and Commercial
Telephone number in the off chance that someone will not be able to
figure out how to reply to my message. This is also useful in the case
where a message I send via computer mail finds its way onto some other
medium, and the mechanism for replying to it is lost.

I think it is reasonable to have my personal name in the From field,
or in some other field, e.g. "Full-name:". In the future, although it
is not specifically addressed in this new document, I would hope that
intelligent mail parsers will be able to figure out my mail address
without any dependencies on computers, e.g. why have a From: field
contain anything but my name and place (e.g. From: Jon Solomon at The
University Of Southern California, Engineering Computing Lab). This
leaves method of delivery optional, I could get it in my postal
address or in my computer mailbox.

I think it is really awful to force computer technology down
everybody's throat (theory: If you want computers, you have to live
with credit card numbers and cryptic addressing schemes).

Let Cobol Die! On with more modern languages and ideas.

Cheers,
--JSol
-------

Date: 17 Jun 1982 16:59:30-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Message-ID: <3990.10.393206366.LBL-Unix@LBL-Unix>
To: JSol at USC-ECLC
cc: solomon at UWISC, header-people at MIT-MC, mo at LBL-UNIX
Subject: Re: 733 revision
In-reply-to: Your message of 17 Jun 1982 1121-PDT (Thursday).


As for lots of headers, I don't quarrel with you using them,
but I have a private dislike for them.  There are those who
claim "your mail reader shouldn't show them to you if you don't
want to see them."  Well, how am I supposed to know what I am
missing if it doesn't tell me about them?  Moreover, I believe
that if the author put them on there, they are important enough
to examine, at least in passing.

So, while I really don't enjoy getting messages with headers like:

	Lives-next-door-to:

or

	Last-seen-with:

I will defend your right to include them, and I will dutifully read
them in case they ever say anything I really need to know.  

If someone has a mail reader which can reliably do thematic
analysis of messages (including the headers!), let me know!

	-Mike


Date: 17 Jun 1982 17:00:46-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Message-ID: <4052.10.393206439.LBL-Unix@LBL-Unix>
To: JSol at USC-ECLC
cc: solomon at UWISC, header-people at MIT-MC, mo at LBL-UNIX
Subject: Re: 733 revision
In-reply-to: Your message of 17 Jun 1982 1121-PDT (Thursday).

I don't care about whitespace AROUND addresses, only whitespace
WITHIN addresses.  I consider ALWAYS having to comma-seperate addresses
an intrusion (do you use commas in LISP?).  But this is wildly
picking nits.

I am not advocating making a standard which is the lowest common
denominator of everything else.  That is clearly absurd.  What
I am lobbying against is making any more rules than necessary
to do the job.  This is an example of Occam's Razor.  
If we spell-out the syntax of an Internet address in 733, then
we can't change it without having to know "oh yea, that part
of 733 was upstaged later."  When we complain about people's
programs not doing the right thing, we should keep in mind just
how hard it is to discover the current distributed opinion of
what that is!

The other issue is Internet versus internet.  The first has the
administrative luxury of decision by fiat.  Some group or individual
decides what to do and then everybody else within the Internet
does it that way.  The "internet", on the other hand, is a
global beast consisting of many different networks, most of whom
all have the notion they are the only network in the world,
and their mail systems certainly don't admit the existance of any others!  
Again, I am not advocating the abrogation of any right-of-existance
or compromising any creative or scientific progress.  I am simply
arguing that we should be aware of other worlds and not build
any walls between them a priori.

	-Mike

Date: 17 June 1982 2231-EDT (Thursday)
From: Craig Everhart at CMU-10A
To: mo at LBL-UNIX (Mike O'Dell [system])
Subject:  Re: 733 revision
CC: JSol at USC-ECLC, Header-People at MIT-MC, solomon at UWisc
Reply-To: Rdmail at CMU-10A
In-Reply-To:  <4052.10.393206439.LBL-Unix@LBL-Unix>
Message-Id: <17Jun82 223141 RD00@CMU-10A>

I think it enough of an intrusion that spaces within names are being
decommisioned.

When you try to build protocol-translating gateways (say, a mail forwarder
between Internet and uucp), you're reduced to the common features of both
protocols.  And, too, it's well-understood that the translator has to
understand what it's translating:  it must understand each format and re-cast
the content in the other format.  That's the principal reason why protocol
translation is so hard.  Does that mean that those using only one protocol need
to limit their usage to what would be acceptable under all protocols?  As long
as the bold spaces in `` at '' are representable in the uucp world by replacing
the whole phrase with ``@'', I don't know what the problem is.

Date: 17 Jun 1982 22:54:08-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: smb.unc at UDel-Relay
cc: header-people at mit-mc
Subject: Re: 733 revision
In-reply-to: Your message of 17 Jun 1982 2048-PDT (Thursday).

I agree with you strongly on the importance of things
like full names in headers.  That is why I would like them
elevated to "full" status.  Making the parsing simpler would
improve the likelyhood of a correct implementation, and possibly
promote inclusion of such informative information in headers
by making it easy to add.  Currently, you can use a "Full-name:"
line, of course, but tradition has it in the "From:" field.

	-Mike

Date: Friday, 18 Jun 1982 08:48-PDT
To: mo at LBL-UNIX (Mike O'Dell [system])
Cc: JSol at USC-ECLC, solomon at UWISC, header-people at MIT-MC
Subject: Re: 733 revision
In-reply-to: Your message of 17 Jun 1982 16:59:30-PDT.
             <3990.10.393206366.LBL-Unix@LBL-Unix>
From: obrien at RAND-UNIX

	We do.  Our MH lister (one of several possible options for showing
messages) parses headers according to a user-specified format.  It puts
all the ones you specify where you specify (so you can make it look like
a business letter if you like, with the date at top right), and throws all
the rest down at the bottom of the message, after the body.

	My only objection is that it takes awhile to parse the header.  I
therefore don't use it because it's too slow for me.

Date: 18 Jun 1982 1852-PDT
From: Mark Crispin
Subject: " at " vs. "@"
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     If I was implementing a mailsystem, I would vote for removing
" at ".  Now, I really don't care, but I definitely DO like the idea
of forever laying to rest headers like
	To: Frodo at
	 BAG-END, Bilbo
	 at BAG-END
where newlines are placed in the middle of addresses.  This is terribly
difficult for a parser which tries to parse the header as is without
the benefit of a preprocessor to implode away continuation lines.

     Come to think of it, are continuation lines flushed?  If not, why
not?  Would people find multiple To-lines harder to parser than a
continued To-line?  Consider that to be right you really do have to
allow multiple To-lines, since some mailsystems do generate them.

     I guess since network addresses are published with @ by the NIC,
maybe for consistance we should remove " at ".  It does make parsing
easier.  If we want to make parsing yet easier, how about making all
non-address entities go away from parsed headers like From, To, etc.
In other words, instead of
	From: Mark Crispin <Admin.MRC at SU-SCORE>
have
	From: Admin.MRC@SU-SCORE
	Personal-Name: Mark Crispin
or some other such thing.  We could have a sanctioned list of various
"human" header items.  Of course, doing this will remove pretty much
all of the richness of RFC 733 so that we may end up with a 5 page
document!

-- Mark --
-------

Date: 18 Jun 1982 2007-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: " at " vs. "@"
To:   Header-People at MIT-MC, Admin.MRC at SU-SCORE

The hell with making things easier for the parsers!  The computers are
there to serve us, not the other way around (and I have implemented a
parser, so I know how difficult, or not, it is).
-Rich
-------

Date: 18 Jun 1982 21:42:35-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: obrien at RAND-UNIX
cc: JSol at USC-ECLC, solomon at UWISC, header-people at MIT-MC
Subject: Re: 733 revision
In-reply-to: Your message of 18 Jun 1982 0908-PDT (Friday).

Mike,
By "user-defined" do you mean I can specify pattern
expressions that pick header lines based on content,
or some other thing?  The real issue is that I still
have to a priori decide how to tell something interesting from something
that isn't.  The part that makes sense, however, is placing the
"reject" header lines down at the bottom.  That way, they are there
to see, just unobtrusive.
	-Mike

Date: 18-Jun-82 21:51-PDT
From: KELLEY at OFFICE  
Subject: Parsing RFC 733
To: Header-People at mit-mc
Identifier: OAD-KIRK-11601
Length: 1 page(s)[estimate]
Posted: 18-Jun-82 21:49-PDT
 
As one who recently finished implementing an RFC 733 parser (to 
convert to the Augment Mail system), I'd just like to say we 
found it doable, but non-trivial.

Some complexity was due to distinguishing Arpanet addresses from
intermixed Augment addresses.  I am somewhat chagrined to see 
this debate about changing the very things that I spent so much 
time accommodating.  Some random thoughts:

1) The converter would run a little faster if it did not have to
look for " at " and the code would be somewhat cleaner.  I 
wouldn't mind re-writing that code.  Right now, all " at "s get 
converted to atsign anyway so Augment users never see " at ".  
Furthermore, we automatically generate no " at "s in mail going 
out to the Arpanet (though a user can make it happen).

2) The parser assumes there will be no <at> in the host part.

3) The multi-line field problems are solved quite elegantly by a
recursive descent parser.  I threw out my recursive version, 
however, and gathered fields in a loop because, under time 
pressure, I was too lazy to add dynamic string allocation 
necessary to avoid a potential procedure stack overflow.

4) We assume a field continuation of a multi-line field does NOT
terminate an address.

 -- kirk


Date: 18 Jun 82 22:01-PDT
From: mclure at SRI-UNIX
To: header-people at mit-mc
Subject: annoying headers without To field

I find message headers like the following very annoying.  The text
asks a question of an unamed person, and there's no way of telling
if the message was directed to me, a list, or whomever. The via
field (appended by our mail daemon) would seem to imply that it
is a MIT mailing list of some sort. Is there some reason why the
Berkeley folks allow headers like this one to get out from 
UUCPnet onto the Arpanet?

Date: Fri Jun 18 17:17:03 1982
From: decvax!duke!alr at Berkeley
Via:  Mit-Mc.ArpaNet; 18 Jun 82 21:59-PDT

I have been told that I might be able to get an evaluation by
you of the Mince screen editor for the IBM pc.  My main
interest is in an editor that can handle large (>60K) text
files, do all the necessary buffering, etc, and, perhaps even
allow editing of multiple files.  I currently use vi on UNIX,
and it's ok; I found IBM's spf even better when I was there.
I'd really appreciate any info you're willing to share.
	Arny Rosenberg
	Duke University Computer Science
	duke!alr





Date:  19 June 1982 03:00 edt
From:  Schauble.Multics at MIT-MULTICS
Subject:  David Moon's comments on dates
To:  Header-People at MIT-MC

I agree with his comments about standard date formats. But, I think
that rather than giving up, this all the more reason to establish a
standard date format.

I have an on-line copy of a paper written by one of the Honeywell
people that is a survey of international standards on date formats. I
ti is too long to distribute as a message. Will someone please tell
me where to put it so that those interested can get it via FTP?

Date: 18 Jun 1982 2327-PDT
From: Richard Furuta <Furuta at WASHINGTON>
Subject: [decvax!utzoo!utcsrgv!utcsstat!antoni at Berkeley:]
To: header-people at MIT-MC
cc: furuta at WASHINGTON, mcclure at SRI-UNIX

I second the annoyance over lack of To: fields in Berkeley's mail.
Coincidentally, the following message arrived just before McClure's.
At least the one McClure got was intelligible!

			--Rick

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

Mail-from: ARPANET site MIT-MC rcvd at 18-Jun-82 2248-PDT
Date: Fri Jun 18 08:26:04 1982
From: decvax!utzoo!utcsrgv!utcsstat!antoni at Berkeley

How much is a BLIT & where do you get them? Thanks. Lou.





-------

Date: 19 Jun 1982 07:40:31-CDT
From: solomon at uwisc
To: header-people@mit-mc
Subject: Mailing lists

I sent a comment to the list, somebody replied with an automatic
reply feature of a mailer that added me to the cc list, and now
everyone is continuing the discussion using reply commands that
keep me in the cc list.  At least that's what I suspect happened.
The result is that I'm getting two copies of everything:  one
addressed to header-people and one addressed to me personally.
Please take me off the cc list.

Date: 19 Jun 1982 08:55:59-CDT
From: solomon at uwisc
To: header-people@mit-mc
Subject: Messages to mclure without To fields

Those messages to mclure look to me like they came from USENET.  For
those of you who don't know, USENET is a sort of distibuted billboard
system that runs on top of the uucp "network".  The latter is a very
large (perhaps as many as 1000-host) collection of UNIX sites that
exchange mail over dial-up telephone connections.  To join the
"network" all you have to do is arrange to poll or be polled by some
other uucp member.  The programs for uucp are distributed with UNIX.
All routing is by manually supplied source-route:  an "address" has the
form "site1!site2!...!siten!username", where "site1" is a site you
connect to directly, etc., and "username" is a mailbox on "siten".
(This syntax is considerably complicated by local nets and interfacing
to ARPAnet.) USENET sits on top of uucp.  Articles, classified by
"newsgroup" are distributed by a hot-potato algorithm:  each site sends
copies to all neighbors that run USENET.  Each article carries a unique
id (originating-host.serial-number) to detect duplicates and break
loops.  Some mailing lists are relayed from ARPAnet to USENET by
various hosts.

The point of this rather long-winded discussion is that USENET has a
"reply" command that allows the user to send a message back to the
originator of the message.  For some reason I don't completely
understand, there seem to have been many items in USENET recently that
have "mclure" somewhere in the "From" field and then say somewhere in
the body that they are really from somebody else.  I suspect that
people are replying, carelessly forgetting to specify who they are
really talking to, and using a mailer that doesn't supply a To field.
The reply feature of USENET uses whatever mailer is lying around and
some of the mailers used at UNIX sites (but not the Berkeley mailer)
neglect to add a To field.  "To:" is not required by 733, but perhaps
it should be.

The To field should be supplied by the originator, not the forwarder.
However, given that some mailers forget to supply it, perhaps Berkeley
should add it to messages it relays.  (In uucp, like SMTP, the To field
is merely for comment; the real destination address is sent
separately).

Marvin Solomon
solomon@uwisc

Date:     19 Jun 82 11:21:03 EDT  (Sat)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  "To" fields
To:       Furuta at Washington, mcclure at Sri-Unix
Cc:       HEADER-PEOPLE at Mit-Mc
Via:  UNC; 19 Jun 82 13:03-EDT

I share your annoyance at letters without a "Subject" or "To" line; however,
the current standard explicitly permits this.  Perhaps it shouldn't?


Date: 19 Jun 1982 1041-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Messages to mclure without To fields
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 19-Jun-82 0655-PDT

I also received the messages mclure sent to us, indicating some form
of mailing list at MIT in use. MIT is not the only place which
supports mailing lists but they have the largest number of them.

When I stopped digestifying WorkS, all the USENET messages which
apppeared without TO fields and everyone was up in arms about it.
The technical issue was that RFC733 did not require the TO field, the
political one was that people had a tough time figuring out what the
message was about.

I think it would be technically difficult for Berkeley to construct a
TO field if all it has is one of the recipients, however that is more
than sufficient. I believe that uucp's next generation of mailers will
try to conform to RFC733 standard, including addressing (Mark Horton
will have to comment on this) and hopefully include at least what is
absolutely required to make the message valid. I wish to lobby for a
TO field in the required list of headers.

Jon Solomon <JSol at USC-ECLC>


p.s. I like the header the way I use it, I think it is much nicer than
"JSOL at USC-ECLC (Jon Solomon)". I think that I am more important
than my mailbox and that I should get top billing. This is clearly a
religious issue of the calibre of the UNIX vs VMS debate which moved
from mailing list to mailing list like a hot potato until everybody
stopped flameing about it, nothing was gained from this except to
formally define the two sides. I hardly think RFC733 should deal with
religious issues, only those technical and administrative issues
which everyone agrees on.
-------

Date: 19 Jun 1982 1106-PDT
Sender: CERF at USC-ISI
Subject: Re:  David Moon's comments on dates
From: CERF at USC-ISI
To: Schauble.Multics at MIT-MULTICS
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]19-Jun-82 11:06:57.CERF>
In-Reply-To: Your message of  19 June 1982 03:00 edt

SUGGEST THAT THE NETWORK INFO CENTER COULD BE THE REPOSITORY FOR
FILES TO BE FTP'D FOR GENERAL CONSUMPTION - THIS REGARDING YOUR
PAPER ON INTERNATIONAL DATE STANDARDS.

VINT CERF


FEINLER@SRI-NIC IS A POINT OF CONTACT AT THE NIC.


Date: 19-Jun-82 13:43:13-EDT (Sat)
From: mark@Berkeley (Mark Horton)
Subject: Re: 733 revision
Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 13:43:13-EDT (Sat)
To: mo@LBL-UNIX, smb.unc@UDel-Relay
Cc: header-people@mit-mc

I agree that full names need more attention.  The current variety os
schemes to represent them is a real nightmare for a poor program to
deal with.  Life would be so much simpler if the From line just had
a mailing address that would get back to the sender.  I would prefer
to see Full-name: on a separate line too.  There are so many pieces
of software that have to reply to a message, and all these forms:
	From: user@host
	From: user at host
	From: user@host (Joe Blow)
	From: Joe Blow <user at host>
don't add anything useful, they just make life more complex.

This pretty radical, but the spirit of 733 could be upheld and life
made much simpler if we just used
	From: Joe Blow
	Sender: user@host
	Reply-to: jblow@otherhost
where From was just a human-readable field.  Then each field has exactly
one meaning, and software doesn't have to play the pea-under-the-shells
game.  The problem is that From suddenly changes meaning dramatically,
so we could rename some fields and be much more upward-compatible:
	From: user@host
	Full-name: Joe Blow
	Reply-to: jblow@otherhost
and just get rid of Sender completely.

The problem with this is that the standard allows (...) commenst in
To and Cc lines also.  This feature seems little used (I've seen one
message once that ever used it) and I am less concerned about To and Cc
lines because simple programs that send a message back to the sender
don't have to worry about them.

But, please, can we simplify the From line?

	Mark

Date: 19 June 1982 1657-EDT (Saturday)
From: Craig Everhart at CMU-10A
To: Admin.MRC at SU-SCORE, mark at UCB-C70 (Mark Horton)
Subject:  Re: " at " vs. "@" and 733 revision
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  Mark Crispin\@SU-SCORE's message of 18 Jun 82 20:52-EST,
             mark\@Berkeley's message of 19 Jun 82 12:43-EST
Message-Id: <19Jun82 165722 RD00@CMU-10A>

I agree with Zellich.  Allow `` at '' and comments in name lists and <> forms.
Writing parsers just isn't that hard.  It might have been a little tricky with
the special :INCLUDE: and :POSTAL: atoms; but with the reduced syntax, life is
just not that complicated.  Let the computer work for the user, not the other
way around.

Date: 19-Jun-82 14:11:42-EDT (Sat)
From: mark@Berkeley (Mark Horton)
Subject: Re: " at " vs. "@"
Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 14:11:42-EDT (Sat)
To: Admin.MRC@SU-SCORE, Header-People@MIT-MC, Zellich@OFFICE-3

	From Zellich@OFFICE-3 Sat Jun 19 06:23:36 1982
	Date: 18 Jun 1982 2007-PDT
	From: Zellich at OFFICE-3 (Rich Zellich)
	Subject: Re: " at " vs. "@"
	Via: cbosgd.uucp (V3.73 [1/5/82]); 19-Jun-82 06:23:35-EDT (Sat)
	Mail-From: office-3 received by cbosgd at 19-Jun-82 06:23:34-EDT (Sat)
	To:   Header-People at MIT-MC, Admin.MRC at SU-SCORE
	
	The hell with making things easier for the parsers!  The computers are
	there to serve us, not the other way around (and I have implemented a
	parser, so I know how difficult, or not, it is).
	-Rich
	-------
	
	
	
OK, so we don't have to make things easier for the computers.
But it still might be nice to make things easier for the poor
person who has to \program the computers/!  The old axiom
"Woe be unto he who maintains the mail program" is well known
to everyone on this list.  We'd all like to make our own lives
as simple as possible.

	Mark

Date: 19 Jun 1982 1324-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: 733 revision
To: header-people at MIT-MC
In-Reply-To: Your message of 19-Jun-82 1043-PDT

There is a fundamental problem with the fact that in some cases, FROM
and SENDER are different people, and REPLY-TO is yet a third party.

Also, I see real needs to attach "comment" information to any address
in any field, to be interpreted by the receivers, individually, and
each in their own context.  I think (personally) that this comment
information is best attached with the "address (comment)" format than
the "comment <address>" format.  If we must reduce formats to only
one, I vote for "()".

As for dates, I sure wish there would come to be a way to consistently
sort on all date fields, which strongly suggests that a standard date
format be established.  I certainly vote for adoption of something
reasonable to replace the current anarchy.

Best - Stef
-------

Date:  19 June 1982 20:20 edt
From:  Palter at MIT-MULTICS (Gary M. Palter)
Subject:  Re: 733 revision
Sender:  Palter.Multics at MIT-MULTICS
To:  Header-People at MIT-MC
In-Reply-To:  Message of 19 June 1982 16:24 edt from Stef

Stef is correct.

However, I would vote for the "comment <address>" syntax.  As RFC733
currently stands, anything within parentheses is considered equivalent
to whitespace and it is, therefore, acceptable for a mail reading
program to throw it away.  The first format, however, is actually a
named address where the name is important and should be remembered.

Date: 19 Jun 82 17:48-PDT
From: mclure at SRI-UNIX
To: header-people at mit-mc
Subject: annoying addresses without To fields

Several people have replied that RFC733 allows headers without To fields.
Could one of the RFC733 authors explain what the reason for that was?


Date: 19 June 1982 2123-EDT (Saturday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70 (Mark Horton)
Subject:  Re: " at " vs. "@"
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark\@Berkeley's message of 19 Jun 82 13:11-EST
Message-Id: <19Jun82 212332 RD00@CMU-10A>

Nobody has ever quoted that `axiom' to me, and I see no reason for its
existence.  All it says is that people rely on how their mail system works.
We knew that already.

		Craig Everhart, CMU RdMail maintainer

Date: 19 Jun 1982 1845-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: " at " vs. "@"
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 19-Jun-82 1111-PDT

I don't believe in your axiom ("Woe be unto he who maintains the mail
program"). I maintain a whole lot of mail programs, mailers, and even
get my hands dirty fixing ARPANET wide mail loops (including multi-net
loops in this), and I hardly consider myself overworked by it.

My opinion on the subject of making things easier for the "poor person
who has to program the computer" is that it would probably be a small
amount more work to implement a more intelligent parser and the
benefits of having such a parser (especially when you consider
receiving random mail which doesn't conform to RFC733 or Son-Of-...),
especially when it can parse the non-trivial cases the headers, are
boundless. 

So far this discussion has taken two distinct paths, so I declare this
discussion religious based: One side wants the most features and the
most extensibility (re: User-defined headers), because (they claim) 
the computer age is upon us and computers can do almost everything, 
especially something as (seemingly) trivial as parsing mail headers.
After all (some say), computers are there to remove mundane tasks from
those who use them.

The other side wants the simplest and most straightforward scheme so
that their computer programs need not be modified to handle the
expensive cost, however virtual or actual these costs are (cpu power
may be a financial restriction, addressing space is a physical
restriction, programming time is a virtual restriction).

I doubt very much if we wish to decide the fate of religion in RFC733,
but we do want to make the best quality system (perhaps not the
fanciest, but certainly the most reliable), with the fewest effort on
all our parts.

For this reason, I believe, arguing over what to restrict from RFC733 is
a moot topic. Most if not all ARPANET systems already have programs
written to handle the difficult parsing algorithm already stated forth
in RFC733, anything WE (=> arpanauts) have to change should be
enhancement, not restriction. In most cases, non-arpanet systems can
benefit from the wealth of programs and systems available on the
ARPANET either as an example of how to do it, or as an actual program
(I'm referring to the case of uucp).

In the special case of :INCLUDE:, CMU seems to use it heavily, I
wonder how difficult it would be to have that conform to the standard
List-name: Foo, Bar, Baz ; convention for group naming? I could be
totally missing the point here, but the general idea is can we come up
with a mechanism so they can have their way while not forcing the
parsers to handle a million of different parsing schemes.

Since I am one of those who \program the computers/, let me point out
that it is not that difficult to program a parser, I may not have done
one from scratch before, but I have looked at others and copied, which
in some sense is cheating (I did read several different kinds of
programs to get a general view of parsers and I did contact people who
were knowledgeable about them, so I did not completely cheat). Even so
it took me a total of 2 hours to write a parser equivalent to MM's
mailbox address parser, hardly a herculean task (actually, 2 hours is
a bit long)! I don't think this kind of flameing will get us anywhere.

I would like to hear if the present mailbox addressing scheme is
impossible to implement on your specific machine. Send these replies
to me and I will summarize them and present them in a future message.
Please be specific, if you can't have @ signs because of some
constraint such as your terminal driver throws them away, and changing
the driver so that you get the @signs means breaking the whole system
(or is completely nontrivial in your implementation), I want to know
all the gory details. Be prepared for some comments and questions on
my part, I'm really skeptical as to whether or not it is actually
impossible.

Cheers,
--JSol
(a.k.a. Jon Solomon)
-------

Date: Saturday, 19 Jun 1982 20:42-PDT
To: mclure at SRI-UNIX
Cc: header-people at MIT-MC
Subject: Re: annoying headers without To field
In-reply-to: Your message of 18 Jun 82 22:01-PDT.
From: greep at RAND-UNIX

You could have your server FTP program tell you (eg by adding a
"mail-from:" line to the message) who the message was sent to,
i.e. the argument of the MAIL/MLFL command.  I added this to our
system and have found it very useful.  This is not to disagree
with your complaint about the lack of a "to:" field.

Date:     20 Jun 82 1:50:50-EDT (Sun)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  "To:" optional

To answer McClure's query about the reason for making the "To:"
field option, in RFC733:

If I remember correctly, we were trying to require as little
as possible.  There were cases of anonymous or list (group 
distribution) mail where people might not want to show the
name or contents of the address list.

Personally, I do not have a strong feeling for or against
requiring it.  But I do think that it is worth noting that
its absence causes hassles fairly consitently.

Anyone care to argue AGAINST requiring the "To:" field?

Unless there is a solid case made for maintaining it as
an option, rather than requiring it, I think it would be
best to make it required, in the new specification.

Dave


Date:     20 Jun 82 10:12:39-EDT (Sun)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Date/Time paper

A copy of the mentioned paper on Date & Time is stashed as UDel-Relay,
in the file

	/usa/dcrocker/733/date.time

and can be retrieved via FTP, using login username of anonymous
and any password.

Dave


Date: 20-Jun-82 19:09:49-EDT (Sun)
From: mark@Berkeley (Mark Horton)
Subject: Re: 733 revision
Via: cbosgd.uucp (V3.94 [3/6/82]); 20-Jun-82 19:09:51-EDT (Sun)
To: header-people@mit-mc@Berkeley

	There is a fundamental problem with the fact that in some cases, FROM
	and SENDER are different people, and REPLY-TO is yet a third party.

I can see where a person might be visiting and have someone else send the
mail for them, but does anyone have a real example that really happens where
three electronic addresses that do not appear in the To or Cc lists are
involved?  I always see Reply-To used to indicate that a person has logged
in on some machine other than his home machine, and wants his replies
sent elsewhere.  Is there another legitimate use?

There are a number of simple utilities that need to generate replies to
the senders of messages.  This occurs not only with mail, but with other
software that adopts RFC 733 as a standard format, such as netnews.
Such a program might only be a few dozen lines long, and forcing it to
contain an entire parser for ()'s and <>'s and continuation lines just
to extract the From line seems unnecessary.  While I would prefer to have
the full name of the sender in a separate field, such as Full-Name:,
I could live with a format that looks like
	From: user@host.net (Full Name)
that is, the From line is restricted to one line (no continutations)
and the only comment is in parentheses at the end.  A simple program
could view '(' as a comment-to-the-end-of-the-line character.  This
restriction would apply to the From: line only - I don't care what's
on the To or Cc lines.  Does anyone have a problem with this restriction?

	Mark

Date: Saturday, 19 Jun 1982 23:56-PDT
To: Header-people at MIT-MC
Subject: Parsers for mail headers
From: greep at RAND-UNIX

In writing a header parser I found one of the headaches to be making
sure that I understood the spec correctly and handled all the weird
cases.  In short, the problem of converting the spec into an algorithm
was much more of a task than converting the algorithm into a program.
So how about having the revised spec include an algorithm?  Then
there can be no question about how a particular case is to be handled.
This would require that the algorithm be generated only once, leaving
us implementors with the more straightforward, and less risky, job
of programming it for our particular systems and integrating
it with the rest of the mail system.  This procedure would also aid
in standarization.  I imagine DCrocker can think of some language
to write an algorithm in that is sufficiently rigorous as to be
unambiguous, while being at a high-enough level to be easily readable.

(I would also like to see this sort of thing done for FTP reply
codes and the like, but that doesn't belong on this mailing list.)

Date: 20 Jun 1982 2332-CDT
From: ZELLICH at OFFICE-3
Subject: Using 3 separate addresses; Long From fields
To: Header-People at MIT-MC
In-Reply-To: The message from Mark Horton <mark at Berkeley> 20-Jun-82
 19:09:49-EDT (Sun)
Message-ID: <20-Jun-82 23:29:44-CDT ZELLICH at OFFICE-3>

Yes, we have cases where all 3 fields (Sender, From, and Reply-To) will be used
with 3 separate addresses.  More common though, and due to the rule that if 
From is present that address(es) gets the reply, is the case where the 
secretary sends the messages for his/her boss and the replies are supposed to 
go to the secretary: Sender is the secretary's address, From is the boss's 
address, and because the replies aren't to go to the boss's mailbox, Reply-To 
must be put in with the secretary's mailbox again.

A From field can't be restricted to one line because there may be multiple 
addresses in the field.  Even without verbose address forms without full names,
the field can still exceed a line (I wonder how many mailers properly handle 
this case in a Reply).

Cheers,
Rich


Date: 21 June 1982 0108-EDT (Monday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70 (Mark Horton)
Subject:  Re: 733 revision
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark\@Berkeley's message of 20 Jun 82 18:09-EST
Message-Id: <21Jun82 010827 RD00@CMU-10A>

I generated a piece of mail with three independent name lists about a month
ago; the mail was From someone without a mailbox, its Sender was me, and
replies were to go to a third person (who was also on the To list) because I
was leaving town for a few days and the third person was handling the
arrangements for the mailbox-less person.

I'd also like to cast a vote against the rigid-format From line.  Shouldn't
there be a namelist-parsing package that all such tiny programs can use on
a given system?

		Craig

Date: 21 June 1982 0108-EDT (Monday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70 (Mark Horton)
Subject:  Re: 733 revision
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark\@Berkeley's message of 20 Jun 82 18:09-EST
Message-Id: <21Jun82 010827 RD00@CMU-10A>

I generated a piece of mail with three independent name lists about a month
ago; the mail was From someone without a mailbox, its Sender was me, and
replies were to go to a third person (who was also on the To list) because I
was leaving town for a few days and the third person was handling the
arrangements for the mailbox-less person.

I'd also like to cast a vote against the rigid-format From line.  Shouldn't
there be a namelist-parsing package that all such tiny programs can use on
a given system?

		Craig

Date: 21 June 1982 0108-EDT (Monday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70 (Mark Horton)
Subject:  Re: 733 revision
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark\@Berkeley's message of 20 Jun 82 18:09-EST
Message-Id: <21Jun82 010827 RD00@CMU-10A>

I generated a piece of mail with three independent name lists about a month
ago; the mail was From someone without a mailbox, its Sender was me, and
replies were to go to a third person (who was also on the To list) because I
was leaving town for a few days and the third person was handling the
arrangements for the mailbox-less person.

I'd also like to cast a vote against the rigid-format From line.  Shouldn't
there be a namelist-parsing package that all such tiny programs can use on
a given system?

		Craig

Date: 21 June 1982 0108-EDT (Monday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70 (Mark Horton)
Subject:  Re: 733 revision
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark\@Berkeley's message of 20 Jun 82 18:09-EST
Message-Id: <21Jun82 010827 RD00@CMU-10A>

I generated a piece of mail with three independent name lists about a month
ago; the mail was From someone without a mailbox, its Sender was me, and
replies were to go to a third person (who was also on the To list) because I
was leaving town for a few days and the third person was handling the
arrangements for the mailbox-less person.

I'd also like to cast a vote against the rigid-format From line.  Shouldn't
there be a namelist-parsing package that all such tiny programs can use on
a given system?

		Craig

Date:     21 Jun 82 14:23:45 EDT  (Mon)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re:  "To:" optional
To:       Header-People at Mit-Mc
In-Reply-To: Dave Crocker <dcrocker@UDel-Relay>'s message of 20 Jun 82 1:50:50-EDT (Sun)
Via:  UNC; 21 Jun 82 18:46-EDT

I've seen two cases where RFC733-compatible have mailers generated
letters without "To" fields.  The first is a private mailing -- I can
persuade this mailer to put all addressees in the "bcc" line, with
nothing in the "To" line.  Clearly, one could always generate
"To: (private)" in such a situation, but this is rarely done.  A second
situation is in the copy of a letter sent to "bcc" recipients; in this
case, the field-name can be modified to prevent inadvertent replies to
the publicly-named original recipients.  It isn't clear to me what
should be required under these circumstances.

In any event, if the standard is changed to require a "To" line, I'd
suggest having it require one of "To", "Cc", or "bcc" -- *something* to
show that the mailer considered the problem.  An SMTP-like processor
could be permitted to add a "To" line when handed a letter with no
destination headers, though I'd hesitate to require such.  Perhaps a
different header should be picked, something like "Apparently-To"?


	--Steve Bellovin


Date:     21 Jun 82 16:47:41 EDT  (Mon)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  rfc733 -- simplified syntax
To:       header-people at Mit-Mc
Via:  UNC; 21 Jun 82 18:46-EDT

Several different people have requested a simplified syntax of some
sort for address lists.  I agree in spirit, but I'm not enthralled with
many of the specific suggestions.  So I've compiled a few of my own...

True names:
	I favor 'name <user@host>'; stuff in parentheses is equivalent
	to white space, and harder to preserve across header-transforming
	code.  What should a program do with a (legal) string like this?
	
		(I'm) Joe (the great) at (the lovely) Host (north campus)
	
	I prefer keeping the human-name as part of the address syntax;
	some folks might want to include such in "To" fields, especially
	when starting a discussion among people who may not know each
	other.

	Nor do I feel that this syntax is any more trouble for a simplified
	parser, as Mark Horton suggested; one simply checks for the
	presence of a '<', and ignores everything before it.

'at' vs. '@'
	Not a problem for anything even slightly complex; if the parser
	has any sort of lexical level, the distinction can be hidden
	there.  The major place this is troublesome is for very simple-
	minded programs that just want to compare one address with
	another; even these need some sort of lexical level to deal with
	comments.

Quoting and nesting
	In my opinion, the *real* villains -- most parsers, even the
	moderately complex ones, don't handle nested comments or symbols
	quoted via '\'.  Named lists (especially in the new syntax, where
	they may not be nested, and hence can't be handled by a simple
	recursion) are likely to prove troublesome; the parser has to
	maintain a extra piece of global state; also, the inclusion of
	commas in address lists (for routing info) will break the simpler
	parsers.  A goal, I think, should be to devise a syntax that
	can be interpreted by the sophisticated parsers, but treated
	atomically by simpler ones.  Thus, "{....}" is better than the
	old ":Include: string", because it's easier to ignore; all the
	program has know how to do is treat "{....}" as an atom.

Named address lists
	A real waste of effort.. ..  They're not that hard to ignore (if
	you see a ':', flush the buffer; also, ignore ';' or treat as
	equivalent to ','), but they are troublesome to do anything
	useful with.  If the list contents are shown, the mailer must
	be prepared to handle a structured address list; if they aren't
	shown, the name is really equivalent to an alias expansion that's
	syntactically different from a regular mailbox name.  (I can't
	send mail to 'header-people:; @mit-mc', for example.)  Nor does
	the mail-composer necessarily know which addressees are real
	users, and which are aliases; trying to make that change in the
	delivery layer is messier than appending a domain name.  And how
	do I reply to such a list?


In summary -- use 'name <user@host>' as the basic syntax, though
a simple 'user@host' should be accepted.  Treat all bracketed pairs
("(...)", "[...]", "{...}", maybe even "<...>") as atoms at some level,
but do not allow (or strongly discourage) nesting; quoted characters
inside such constructs should likewise be prohibited.  As much as possible,
'@' and ',' should be treated as firewalls -- always break on them, and
don't try to figure out their context.  And -- for the benefit of all
those little programs Mark Horton mentioned -- provide library routines
on every system to do all this parsing....

		--Steve


Date:     21 Jun 82 19:29:58-EDT (Mon)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Ai
Subject:  [To]:

Steve Bellovin points up an issue that I would like to make
sure is not missed:

I modified a Unix version of the sndmsg program (called 'send')
so that Bcc recipients received messages which did not have
ANY To or CC fields.  This was to subvert receivers' Reply
commands.  The supposition is that a Bcc recipient usually
should not send a reply to other (public) recipients of
the message.

As a consideration, I include the public To and CC fields, with
the field names bracketed.  Therefore, users can see the
contents, but the Reply commands do not.

This seems to be a very useful feature.  Requiring a To field
would subvert its intent.

Dave



Date: 21-Jun-82 23:08:17-EDT (Mon)
From: mark@Berkeley (Mark Horton)
Subject: sender, from, and reply-to
Via: cbosgd.uucp (V3.94 [3/6/82]); 21-Jun-82 23:08:19-EDT (Mon)
To: header-people@mit-mc@Berkeley

I hope you guys aren't getting tired of this...

I asked for examples of the use of all 3 electronic addresses, and
the replies have shown two examples, each of which had
	an electronic address for the sender
	an electronic address to send replies to
	a non-electronic address telling who the mail was sent for.
These examples are both handled by what I proposed earlier.

What I was asking is if anyone has a situation where three ELECTRONIC
addresses are really needed for Sender, From, and Reply-To.  Putting
it another way, what other needs are there besides (1) send to the
sender, (2) send to the reply-to, (3) send to the reply-to plus some
combination of To, Cc, and Bcc?

I think the idea of specifying algorithms is a big win, although I'm
not sure what the set of algorithms needed is.  But I would prefer a
standard that is so simple and unambiguous that the algorithms are
all trivial and obvious.  The current variety of (different) implementations
of reply algorithms shows that RFC 733 is not this simple.

	Mark

Date: 21 Jun 1982 2133-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: sender, from, and reply-to
To:   Header-People at MIT-MC

Not really true that Sender and Reply-To are purely electronic addresses,
and the From is purely a human-name...in our environment, where office
symbols are frequently used for addresses "DRXAL-FD at OFFICE-3", etc., and
mailboxes are shared by multiple people in an organization, it is common
(both for courtesy and for authentication and record-keeping) to incude
both the human name and the electronic address in any address field.  There
are also overriding considerations when you want to force a reply to the
From person, instead of following the Reply-To request, so you need the
electronic address there as well as human name.

There are a helluva lot of combinations, and considering that we're
starting to build message systems for use during the next 10 years, I'd like
to see as much diversity and flexibility as possible allowed.  We'll only
have to program the parsers once (theoretically...), but we'll be using
them for 10 years; that argues for putting up with a complex task up front
to keep from tacking on bits and pieces of improvements forever or just
doing without them.

Cheers,
Rich
-------

Date: 21 Jun 1982 2210-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: [To]:
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 21-Jun-82 1629-PDT

Dave,

I agree with what you are saying, but we might consider defining both
a "To:" and a [To]: field and similar for "cc:" and "[CC]:" requiring
one or both. At the very least I want to know why I am getting a
message, perhaps a better choice would be to have this information
placed in a new "Mail-To:" line? E.g.

Mail-From: .... 
Mail-To: ARPA-MAILING-LIST@MIT-MC

by the program which initially receives or sends the message?
Subsequent forwarding routers could check to be sure this information
exists and puts it in if it is lacking. This is just to answer the
question "why did I get this random message"!

Just an idea,
--Jsol
-------

Date: 21 June 1982  22:21-PDT (Monday)
From: David Eppstein <CSD.Kronj at SU-SCORE>
To:   mark at Berkeley (Mark Horton)
Cc:   Header-People at MIT-MC
Subject: sender, from, and reply-to

Recently my account went away temporarily, and the mail I sent about
the problem had 3 electronic addresses: from my full name and computer
address here, sender the friend whose account I used to send the mail,
and reply-to an alternate net address.  I think this is a true example
of three electronic addresses in one message.

Date: 21 June 1982  22:21-PDT (Monday)
From: David Eppstein <CSD.Kronj at SU-SCORE>
To:   mark at Berkeley (Mark Horton)
Cc:   Header-People at MIT-MC
Subject: sender, from, and reply-to

Recently my account went away temporarily, and the mail I sent about
the problem had 3 electronic addresses: from my full name and computer
address here, sender the friend whose account I used to send the mail,
and reply-to an alternate net address.  I think this is a true example
of three electronic addresses in one message.

Date: 21 June 1982  22:21-PDT (Monday)
From: David Eppstein <CSD.Kronj at SU-SCORE>
To:   mark at Berkeley (Mark Horton)
Cc:   Header-People at MIT-MC
Subject: sender, from, and reply-to

Recently my account went away temporarily, and the mail I sent about
the problem had 3 electronic addresses: from my full name and computer
address here, sender the friend whose account I used to send the mail,
and reply-to an alternate net address.  I think this is a true example
of three electronic addresses in one message.

Date: 21 Jun 1982 2228-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: sender, from, and reply-to
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 21-Jun-82 2008-PDT

[This may seem a bit extreme for purely ARPANET mail, but in WorldNet
(which is closer than you may think), this is a real issue.]

I, Joe, tell my secretary Mary to write a message to you. Mary, who
doesn't have access to the computer mail facility at USC, writes the
message to be sent in a memo to Jim, the computer center clerk
responsible for this. Jim creates a special mailbox called MARY at
USC-ECLC which is in reality a file in Jim's directory (we can do this
now), or a subdirectory of him in the mail forwarding database
(granted this is a bit esoteric, I'm really thinking of a more general
idea which includes something known to US Mail users as "General
Delivery"), so when replies come to it, he can stuff them into Mary's
Campus mailbox. The headers look like this:

From: JOE at USC-ECLC
Sender: JIM at USC-ECLC
Reply-to: MARY at USC-ECLC
To: Mark at Berkeley

You get the message in your mailbox, you reply to it, the headers for
the reply look like this:

From: Mark at Berkeley
To: Mary at USC-ECLC
In-reply-to: JOE's message of 14-JUN-82 02:34:00-PDT

Indeed, the from field specifies the owner of the message, i.e. it is
JOE's message. Mary get's the replies in her mailbox, because Jim is
stuffing them into envelopes.

I know this is a bit esoteric, and if I spent enough time thinking
about it I could come up with a better one, but it does show a
potential use for having both a To field, a Sender field, and a
Reply-To field.

--JSol
-------

Date: 21 Jun 1982 2237-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: an opinion
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423

I wish to argue for having the state of address parsing remain the way
it is. The most important reason I can think of is that I already have
a program which does it. That's also the most selfish reason I can
come up with.

Being a bit less selfish, I don't think there is an operating system
or machine which we are currently hooked up to on our collective
networks which doesn't have a parser which will handle the type of
field currently supported by RFC733. I'm not saying that EVERYBODY's
parsers know about it, but there are public domain (emphasis here)
parsers available for especially UNIX (which is where I seem to hear
most of the complaining coming from) which deal with parsing the from
field on standard ARPANET messages.

I think that we are really wasting much time (and quite a bit of disk
space) arguing over what should NOT be in the document.

Cheers,
--Jsol
-------

Date:     22 Jun 82 6:27:20-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Jon Solomon <JSol@Usc-Eclc>
cc:       Header-People at Mit-Mc
Subject:  Re:  [To]:

Jon --

If we standardize something like [To]:, then someone is going to
write a mail system that knows about it and makes it convenient
to use it for replies.  My whole idea was to avoid this.

Dave


Return-path: @USC-ISID,steve@ucl-cs
Via: USC-ISID ; Tuesday, June 22, 1982 04:05:08-PDT
Date:     22 Jun 82 11:16:37-BST (Tue)
From:     Steve Kille <steve@ucl-cs>
Reply-To: ucl-netwiz at isid
To:       Mark Horton <mark@berkeley>
cc:       header-people at mit-mc
Subject:  Re:  sender, from, and reply-to

Mark,

Another very useful reason for having all three valid is that
mailboxes valid in one context may not be valid in another.
Header munging will solve some cases but not all.  Try replying
to the from field of this message (which works fine in the UK).
The Reply-To: field can be used to point the reply somewhere
else.  The Sender is still useful as an electronic address (if
i had a secretary).

Steve
--------


Date: 22 Jun 1982  8:21:36 EDT (Tuesday)
From: Ken Pogran <pogran at BBN-UNIX>
Subject: Re:  [To]:
In-Reply-to: Your message of     21 Jun 82 19:29:58-EDT (Mon)
To: Dave Crocker <dcrocker at UDel-Relay>
Cc: Header-People at Mit-Ai

Dave,

I find it hard to believe that you of all people have built a mailer
that contains a genuine HACK!  The notion that the mailer itself
should ensure that bcc recipients of a message cannot reply to it strikes
me as a bit strange.  After all, if I receive a message as a bcc recipient,
I ought to realize -- seeing myself on the bcc list -- that the
To: and cc: recipients don't know I've gotten the message, and that
if I reply to it, my knowledge of the message will be revealed to them --
something that the sender of the message didn't want to happen.  But,
I OUGHT TO HAVE THE FREEDOM OF CHOICE to decide whether or not to "blow 
my cover".

Besides, I don't think that a reply distributed to To: and cc: recipients
of the original message, from someone who apparently wasn't on the original
distribution lists, would be all that surprising today.  Many mailers and
mail-reading programs include forwarding and redistribution features that
have the capability of placing messages into the mailboxes of people who
weren't intended recipients.  And THEIR reply might be just as relevant
as the reply from an original recipient (example:  Manager asks subordinate
to respond to a query).

Regards,
 Ken



Date:     22 Jun 82 9:39:32-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Ken Pogran <pogran@Bbn-Unix>
cc:       Header-People at Mit-Ai
Subject:  Re:  [To]:

(Thought this might stir things up, a bit.)

I agree that the Bcc recipient should have the opportunity to
reveal himself.  My concern -- based on painful experience -- was
with the human factors problem of people ACCIDENTALLY revealing
themselves, because their reply command automatically incluced
To and/or CC in the reply message.  The bracketing hack retains
the information, but requires that the recipient exercise extra
effort to use it.  The premise is that Bcc recipients were meant
to be hidden from the rest.

Dave



Date: 22 Jun 1982 07:09:18-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: an opinion
In-reply-to: Your message of 21 Jun 1982 2351-PDT (Monday).

Yes indeedy, there are lots of programs which do SOMETHING to
733 headers.  But the issue in building a standard has to do with
specifying WHAT is supposed to happen.  I have seen NO two mail
munching programs that do the same thing.  Maybe this is fine;
it's what makes horse races.  But as I think Greep pointed out,
the problem is getting things to be precise enough so something
can be widely implemented with some hope of having uniform
semantics (not to mention correctness!).

I am not arguing that the existing 733 fails to be implementatable;
I am suggesting it is being over specific.  Again, ARPAnet myopia
should be avoided.  Twenex sites running MM or Hermes
or whatever else and only seriously connected to the ARPAnet
may not be concerned with the more global issues,  but there
are sites, mine for instance, which talk to 4 completely different
mail systems on 4 diffenent kinds of networks.  Leaving 733 the
way it is is a brilliant finess of the issues.  While it is not
the only work to be done, a really hard problem is how to do
mail and intermailing in a mixed-network environment.  The situation
at my site is that we choose not to finess the question because
there are too many people we couldn't talk to if we did.
If this means that the image of any one mail system suffers some
minor loss of "functionality" or has to forgo some clever "feature"
to widen the world to which the whole system can speak, then
we are willing to make this trade.  I suspect we are not alone
in this position.

I will admit something publicly right now.  The mail system we use
here at LBL has implemented most of the restrictions we have been discussing
out of the need outlined above.  Doom has not cracked nor has the
earth opened up to swallow the non-believers.  For the very same
self-serving reasons JSol cites, unless 733 is changed to make our
life easier, we will not be changing anything very much.

So maybe the sad truth is that beyond getting the "domain" part added
to the addresses, 733 is a moot issue.  People will go on implementing
whatever part of it that serves their purposes and ignoring the
rest of it.  The Purists will complain and the Users will continue
to get their work done.  

And the NBS protocol will eventually swallow us all.

	Flaming out for the last time on this subject,
	-Mike


Date: 22 Jun 1982 07:09:18-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: an opinion
In-reply-to: Your message of 21 Jun 1982 2351-PDT (Monday).

Yes indeedy, there are lots of programs which do SOMETHING to
733 headers.  But the issue in building a standard has to do with
specifying WHAT is supposed to happen.  I have seen NO two mail
munching programs that do the same thing.  Maybe this is fine;
it's what makes horse races.  But as I think Greep pointed out,
the problem is getting things to be precise enough so something
can be widely implemented with some hope of having uniform
semantics (not to mention correctness!).

I am not arguing that the existing 733 fails to be implementatable;
I am suggesting it is being over specific.  Again, ARPAnet myopia
should be avoided.  Twenex sites running MM or Hermes
or whatever else and only seriously connected to the ARPAnet
may not be concerned with the more global issues,  but there
are sites, mine for instance, which talk to 4 completely different
mail systems on 4 diffenent kinds of networks.  Leaving 733 the
way it is is a brilliant finess of the issues.  While it is not
the only work to be done, a really hard problem is how to do
mail and intermailing in a mixed-network environment.  The situation
at my site is that we choose not to finess the question because
there are too many people we couldn't talk to if we did.
If this means that the image of any one mail system suffers some
minor loss of "functionality" or has to forgo some clever "feature"
to widen the world to which the whole system can speak, then
we are willing to make this trade.  I suspect we are not alone
in this position.

I will admit something publicly right now.  The mail system we use
here at LBL has implemented most of the restrictions we have been discussing
out of the need outlined above.  Doom has not cracked nor has the
earth opened up to swallow the non-believers.  For the very same
self-serving reasons JSol cites, unless 733 is changed to make our
life easier, we will not be changing anything very much.

So maybe the sad truth is that beyond getting the "domain" part added
to the addresses, 733 is a moot issue.  People will go on implementing
whatever part of it that serves their purposes and ignoring the
rest of it.  The Purists will complain and the Users will continue
to get their work done.  

And the NBS protocol will eventually swallow us all.

	Flaming out for the last time on this subject,
	-Mike


Date: 22 Jun 1982 09:15:33-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: header-people at mit-ai
Subject: revelation??

Maybe I am dense, but I think I understand what is happening with some
of this discussion.

One group of parties is arguing from what they think the User should
see.

Another group is arguing from what the Programs (below the
reader/composer) should see.

What exactly is 733??  Is it a description of the User interface to a
mail system??  I think not.  It certainly drives the functional
requirements of such programs, but is not one itself.
I see 733 as an interchange specification, which attempts to
define some semantics and syntax for information exchange,
not necessarily its presentation to the user.

Maybe the way to resolve this  address parsing business is to point out
that if users want to read "foo at bar" and type "foo at bar", they
should use a reader/composer can do that for them neatly.  But at the
interchange level, where mail systems speak to mail systems, 733
applies as the canonical form.  Here we could say "addresses are things
not containing whitespace (or commas for the IBM minded)" to make the
job easier at that level.

Supporting this position are the draft mail standards like NBS which
encode the "headers" and variable length property lists in BINARY.
This forces the reader/composer to do "presentation" processing of
headers in general (and addresses specifically), so the syntax is
forced to be stylized, unless the poor user has to type things in in
binary.

	-Mike


Date: 22 Jun 1982 1020-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re:  [To]:
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 22-Jun-82 0639-PDT

If I receive too many messages with a [To]: field I might just write a
mail program which parses that header so I get that freedom of choice
in a convenient fashion. Whether or not this is a "required" or
optional standard header or even if the header is not included in the
"standard". 

The point still remains that I want to know who (or specifically,
WHAT) the message is for, and sometimes the "From" field and text of
message don't give enough information.

--JSol
-------

Date: 22 Jun 1982 1032-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: an opinion
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 22-Jun-82 0709-PDT

I have been a victim of harrassment from people who tell me my headers
are "illegal" and that I should "cease sending garbage network mail or
<someone> will sick the network security agents on me and remove our
network connection until we comply". If you restrict RFC733, I will be
forced to remove from our mailer all remnants of the previous one else
someone will flame at us the same way. I do not wish to have DCA or
DOD come down on us so hard, and while I can see your argument that
you should not be forced to offer these features to your users, it is
indeed sad that I, and others like me, will have to throw away
perfectly good work just to conform to someone's specific bureaucratic
problem.

Incdentally, one of the things I may end up having to write is a
program which (on the fly) converts from RFC733 standard to NBS
standard. I don't see this as overly difficult.

If we finally decide to restrict the "from" field to some stringent
format I will probably have do the same thing to outgoing ARPANET
mail. Our users tend to like the diversity of headers. It still seems
quite a shame to waste all that effort, just because someone else's
mailer can't parse the headers. Not to mention all the effort that
went into implementing this one and helping our users get used to the
format. A non trivial number of them will notice and probably complain
to us about it.

Cheers,
--JSol
-------

Date:     22 Jun 82 14:45:53-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  changes

It has been a busy morning.  I have gone through the transcript,
trying to synthesize people's comments into the next draft of the
format spec.  I think I have been reasonably fair, so that, with
any luck at all, everyone will feel shortchanged.

To reiterate one point:  I personally favor a standard which is
STRICTLY interchange-oriented and which does NOT take cognizance
of nice human-factors items, such as " at " vs. "@".

However...

My mandate was for a restricted delta on the existing standard.
I hope that the multi-media standard will free us of this
very cumbersome historical robe.

To wit:

<space> "at" <space> is retained.

The From field may contain only machine-usable addresses (one or
more) and may NOT contain a group (named list).

The {} bracketing construct will not be added.  I believe that
most of its applications are system-dependent, anyhow, and
thus need not appear in the standard.  I expect some
exceptions, such as Postal addresses, and recommend that they
be served by naming some special Domains. (!)

Postel's restricted date/time format have been adopted, except
that the dash ("-") between time and timezone has been
removed, per many people's requests.  (I had not, previously,
noticed the parsing ambiguity.)

Line-folding is retained.

At least one destination address (To, CC, Bcc) will be required.
To and CC must contain at least one address.  Bcc does not.

Groups are retained, though recursive group specification is
not allowed.  It turns out that several sites really do use
groups in the way we originally intended, displaying the
group name, while hiding the list contents.  If a group list
has no contents, then the terminating semi-colon is optional.

Period (".") remains a universal special character.  I have tried
to make some modifications to the text to guide usage, for
the local-part.

In a route-addr, the route sequence is separated from the
addr by colon (":") rather than comma (",").

<atom> may not contain SPACE.

The "Remail-*" meta construct is renamed "Resent-*".  Several
people commented on the linguistic anomaly of "remail" so I
chose the shortest acceptable alternative.  (I had, originally,
been trying not to favor an existing implementation.  Sorry,
Hermes and the rest...)

Extension-field and User-defined field naming and usage rules
remain the same, except that no Extension-field (i.e., future
standardized field) will have a name beginning with "X-".

Dave

P.S.  I will be out of town, for several days, which should
afford my cpu an opportunity to cool down from your replies.


Date: 22 Jun 1982  8:31:11 EDT (Tuesday)
From: Ken Pogran <pogran at BBN-UNIX>
Subject: Re: sender, from, and reply-to
In-Reply-to: Your message of 21-Jun-82 23:08:17-EDT (Mon)
To: mark at Berkeley, pogran@(Mark@Berkeley, pogran@Horton)@Berkeley
Cc: header-people at mit-mc, @, pogran@Berkeley@Berkeley

    "But I would prefer a standard that is so simple and unambiguous
     that the algorithms are all trivial and obvious."

Mark,

We're trying to provide the framework for an electronic mail system
that's capable of representing a reasonable subset of the patterns of
human communication.  If the standard is so "simple and unambiguous" that
it restricts the patterns of communication, then systems implementing
it won't find much use in the real world; they'll be used only by
died-in-the-wool computerniks like ourselves (heaven forbid!).

I'm not arguing that we need to retain as much freedom as there is today
in the use of From:, Sender:, and Reply-To:; just that we need to have
enough functionality to provide a system that's attractive to people.
It's the USE of the system that needs to be simple and
straightforward, not necessarily the programming task.  After all, isn't
the latter what we get paid for?

Ken


Date:     22 Jun 82 16:55:35-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Address-Fields

Given that we expect to have relay systems that massage headers
(terrible, but currently seems to be necessary), one of the
issues they face is the identification of fields which contain
addresses to massage.

I would like to propose the specification of a field which
lists which fields contain addresses.  It would be used whenever
the message contained "non-standard" address fields.  I.e.,
fields not named in the standard.

A minor, but potentially useful hack.

Thoughts?

Dave


Date: 22 Jun 1982 1506-PDT
From: Mark Crispin
Subject: named address lists
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The purpose of named address lists as most TOPS-20 and Tenex software
implements them is to sabotage a receiver's Reply command intentionally,
e.g. to have
	To: Various People: ;
as the TO-list.  The only "reply" to this message is to its From or
Reply-to.

There is completely different technology for a named address list that
can be replied to, that is, having a mailbox which explodes to the
address list such as VARIOUS-PEOPLE@SU-SCORE.

Both functions are useful.  Both should be kept.  Both have been in
common use for over a decade.

I like the "text <user@host>" syntax and think "@" is somewhat prettier
than " at ", but don't terribly care.

Another thing we could do is just say the hell with changing the spec
radically and just make the necessary modifications for SMTP and domain
addressing.
-------

Date: 22 Jun 1982 1509-PDT
From: Mark Crispin
Subject: 3 electronic addresses
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Since enough software implements it already, I see no reason
for disallowing it.  I'll grant that a number of people use three
electronic addresses for silly stuff like:
	From: the outhouse of Larry Loser
	Sender: LOSER at RANDOM-HOST
	Reply-to: Loser at RANDOM-HOST
and there is some administrative pressure to disallow this sort of
thing, but it all seems too silly to worry about.

     Is there any movement among people to leave the standard
essentially intact?
-------

Date: 22 Jun 1982 1516-PDT
From: Mark Crispin
Subject: ARPANET myopia and TOPS-20
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Mike -

     I think it is unfair to accuse TOPS-20 sites running HERMES
or MM as being [ARPANET] myoptic.  MM and its friends support
several different networks (more than the 4 you quoted).  As the
principle MM maintainer I am quite aware of multiple network (as
opposed to Internet) issues.  The BBN maintainers of HERMES are
likewise composed of a number of bright people.

     Most of the simplifications proposed for RFC 733 were aimed
for those sites (such as small Unix systems) who may not have the
manpower to implement full 733 or who would have problems.  Neither
MM nor HERMES would benefit from those simplifications other than
perhaps making some of the code simpler since both have supported
all of this for some time.

     My comments on simplification were to try to be helpful to
small systems.  I don't need any of those simplifications, having
done the work already.

-- Mark --
-------

Date: 22 Jun 1982 16:05:13-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: dcrocker at UDel-Relay
cc: Header-People at Mit-Mc
Subject: Re: Address-Fields
In-reply-to: Your message of 22 Jun 1982 1421-PDT (Tuesday).

Dave,
The "address-list" is in principle useful, but header munging may
well be done differently for "To:", "From:", and "Reply-to:" fields
(it is in our environment if replies are to have any chance of working).
This means you have to scout around anyway, so while the line might
give you some hints, you may not be able to discover how it is you
should munge "Reply-by-way-of:" if it were to appear in the "Address-lines:"
line.  In fact, it looks like we may be buying a bigger problem:
restrictions on the lines that can appear in the "Address-lines:" line!
	-Mike

Date: 22 Jun 1982 1726-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: sender, from, and reply-to
To: mark at UCB-C70, header-people at MIT-MC
In-Reply-To: Your message of 21-Jun-82 2008-PDT

From: Boss
Sender: Secretary
Reply-to: Staff-Analyst

Is one good example.  To see more, all you need to do is think in the
larger context of complex groups of workers.

Best - Stef
-------

Date: 22 Jun 1982 1725-PDT
Sender: CERF at USC-ISI
Subject: Re:  [To]:
From: CERF at USC-ISI
To: pogran at BBN-UNIX
Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI
Message-ID: <[USC-ISI]22-Jun-82 17:25:48.CERF>
In-Reply-To: Your message of 22 Jun 1982  8:21:36 EDT (Tuesday)

Ken,
I disagree - I've been burned more than once by replying to
a BCC messasge, intending it only to go to the originator ,
but having it show up to everyone.  I think Dave's hack is the
right idea.

Vint


Date: 22 Jun 1982 1800-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re:  [To]:
To: Header-People at MIT-MC
In-Reply-To: Your message of 22-Jun-82 1020-PDT

I would like to isolate the essential issues around TO: and [TO]:

It is clear that Computer mail is more prone to let people err in
replying without intention, to a received BCC copy.  With a paper
memo or letter, this is not an issue because of the lack of automation
in the reply process (maybe).  But, it sure is an issue in Computer Mail!

In an earlier Hack (maybe Dave's), the BCC field was omitted in the
BCC recipient's copy.  Detection of ownership of a BCC copy required
careful inspection, and inference based on lack of any visible trace
of how the message got to the recipient.  This one really bit me once!
So, I complained, and now we have this nice new hack that does pretty
much what I want.  It prevents me from inadvertant errors, but it does 
not prevent me from deliberate disclosure of my having a copy.

This is exactly right in my opinion, but I will no go so far as Dave
does in trying to prevent a deliberate reply through sme kind of
manual over-ride.  To me, it is enough to require the recipient to
take some action which clearly means "Yes, I see that this is an
abnormal/unusual Action, but I am doing it anyway!"  At worst, this
can be done by retyping the "blinded" addresses.  Anyone who creates a
User Agent that fails to distinguish between TO: and [TO]: as we have
defined them here, is not going to win any sales with my clients.

But, now I have a new problem.  (New Systems Always Create New Problems!)

I cannot now scan with a string search on TO: to find a [TO]: unless
someone will kindly modify MM and HERMES, et al.  (anyone for MSG?)

So, I would like to see a standard way to show TO fields that are not
intended for automatic reply, but are expected to be processable.
Then it will be reasonable to enhance User Agents to deal with this
new "standard" case.

I expect that the "custom" of using "[x]" for the alternate form of
"x" is a good one, and one that will work in general for many fields
other than TO and [TO].  BUT!  I do not propose that this be used if a
better form exists!

Is it reasonable to go so far as to include such a "meta" standard?

Best - Stef
-------

Date: 22 Jun 1982 1858-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re:  [To]:
To: ESTEFFERUD at USC-ECL
cc: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 22-Jun-82 1800-PDT

I propose that the blind [to] and [cc] fields be not headere fields
but comments in a new field (original:) which makes it crystal clear
that programs should not be hacked to do this.

On the other hand, it seems reasonable for a mail system to allow you
to reply to a [to]: field but to query the user "Are you sure you wish
to reply to this blind carbon copy?"

--JSol
-------

Date: 22 June 1982 2129-EDT
From: Rudy.Nedved at CMU-10A
To: CERF at USC-ISI
Subject:  Re: [To]:
CC: dcrocker at UDEL-RELAY, Header-People at MIT-AI
In-Reply-To:  <[USC-ISI]22-Jun-82 17:25:48.CERF>
Message-Id: <22Jun82 212907 EN10@CMU-10A>

Vint,

What is the purpose of the hack? It is to make it harder for the mail
responding software to parse the TO: and CC: fields.  After the [To]
hack has been around, software will be available which parses this
field....enabling you to get "burned" again.

What the software should do is see that YOU are on the BCC field of
the message that you are answering and that it should say "Are you
*REALLY* sure you want to send it to the receiver??"

Delicate comments made thru a mail system should not be handle by the
mail header. Wouldn't the same problem occur if your mail file was
unprotected?

-Rudy


Date: 22 Jun 1982 1902-PDT
Sender: CERF at USC-ISI
Subject:  Re: [To]:
From: CERF at USC-ISI
To: Rudy.Nedved at CMU-10A
Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI
Message-ID: <[USC-ISI]22-Jun-82 19:02:31.CERF>
In-Reply-To: <22Jun82 212907 EN10@CMU-10A>

Rudy,
normally I don't like to contemplate systems which "save us
from ourselves" - like some government regulations seem to
attempt. However, I do think we need some protection against
inadvertently sending responses to the wrong parties without
some control.  I won't quibble about the mechanisms used to
help avoid accidental blunders, but believe we need some
way to avoid them. 

Vint


Date: 22 Jun 1982 21:54:55 EDT (Tuesday)
From: Jack Haverty <haverty at BBN-UNIX>
Subject: Re:  [To]:
In-Reply-to: Your message of 22 Jun 1982 17:25 PDT
To: CERF at USC-ISI
Cc: pogran at BBN-UNIX, dcrocker at UDEL-RELAY, Header-People at MIT-AI

My two cents:

Whenever we talk about any particular behavioral characteristic of mail,
like the treatment of bcc in replying, for every person who likes it
to work in the X fashion, there is another for whom Y makes more sense.
My favorite is the convention for what happens when you just say 'answer',
and something decides whether or not to include the cc field, etc.

It is not the business of a mail protocol to define the behavior of mail
systems. The protocol should provide the basis upon which various systems 
can be built, and the user, as customer of mail software, should pick his
favorite.  The protocol must support all of the choices, in the sense that
it is rich enough to convey the information in a lossless fashion, if
we desire to maintain interoperability.

If the Hermes Users' Group, or MM, or MH, or whatever, want to argue about 
what their software should do, that is I think the proper place for the 
arguments.  There is no correct global answer to most of these questions,
it's like trying to define a standard computer, or standard operating
system.  They all run programs, but the best choice depends a lot on
what you expect or need the system to do for you.

Flameout,

Jack



Date:     23 Jun 82 00:12:14 EDT  (Wed)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  [To], larger issues
To:       header-people at Mit-Mc
Via:  UNC; 23 Jun 82 0:30-EDT

Even though I like Dave's mod, I'm preparing to install a different
protective device on our mailer here -- his way doesn't fit in with
its structure, and would cause a fair amount of extra overhead, given
the way it already works.

I plan to have it check the 'To' and 'Cc' lines of the message being replied
to; if your userid doesn't appear, it will warn you.  Note that that
catches replies to mailing lists, bcc copies (boy have I been burned on
that one...), etc., but without requiring any explicit action at all if
you really want to send the reply.

Turning for a moment to some larger issues....  Has anyone compared the
new draft standard with the NBS proposal?  Specifically, does 733' contain
all the information they require/like?  Are there any important elements
of 733' that are hard to represent in NBS, and vice-versa?  It seems certain
that translators are going to have to be written between the two; we
may save ourselves a lot of grief later on by doing some extra checking
now.  (I haven't gotten around to typing up a U.S. Snail letter to
them; if only they were on the net....  (or are they?))



Date: 23 June 1982 01:31-EDT
From: Gail Zacharias <GZ at MIT-MC>
Subject: sender, from, and reply-to
To: mark at UCB-C70
cc: HEADER-PEOPLE at MIT-MC

I don't know whether this is exactly the intended use of the sender field,
but at least on ITS if you send mail from another user's account (i.e. use
his terminal to send a message without logging him out), the logged in
person's name will be placed in the sender field.  This situation is clearly
independent of whether you want the replies to go somewhere else, if so,
you have a case with 3 distinct net addresses involved.

Date: 22 Jun 1982 22:49:40-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: smb.unc at UDel-Relay
cc: header-people at Mit-Mc
Subject: The Proposed NBS Standard
In-reply-to: Your message of 22 Jun 1982 2155-PDT (Tuesday).

I have been looking at the proposed NBS standard in some detail,
especially since at least 4 commercial companies have endorsed it
at an INTERCHANGE standard.  Compared with NBS, 733 appears rather
naive about the political world envisioned for electronic mail
in a corporation (I do not subscribe to supporting "An Evening
in Byzantium", but they didn't ask me).  The headers are coded
as variable length property lists with lengths and "descriptor
codes" in binary.  There are many new kinds of headers like:
"Assigned-for-action-to:" and "Assigned-for-action-on:" (implying
a date), plus many other things I would have never thought about
(nor would ever use).  However, it is interesting reading;  a good
example of design by "thinking of everything you would ever want to do
and putting in a frob".  In deferrence to the designers, it isn't
a bad document, just seems like overkill for the mail environment
we know.  But in the corporate world, maybe things are different;
I don't want to know.  The semantics of the headers are specified
in English, but the standard doesn't attempt to define the fine
semantics of what reader/composers should do with the fields.
(The current discussion of "no single sufficient semantic for
reply" is a good example of open issues.)  

I have a hard copy of the document, but I can't seem to remember
exactly how I got it.

	-Mike


Date: 23 June 1982 0345-EDT
From: Rudy.Nedved at CMU-10A
To: mo at LBL-UNIX (Mike O'Dell [system])
Subject:  Re: The Proposed NBS Standard
CC: header-people at Mit-Mc
In-Reply-To:  mo@LBL-UNIX's message of 23 Jun 82 00:49-EST
Message-Id: <23Jun82 034505 EN0C@CMU-10A>

Isn't the proposed NBS standard RFC806??

-Rudy

Date: 23 Jun 1982 0500-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: NBS Document/personnel available online
To:   smb.unc at UDEL-RELAY
cc:   Header-People at MIT-MC

Yes, at least one good NBS contact, Shirley Watkins, is online at
WATKINS@NBS-VMS.

Also, as Rudy pointed out, RFC806 is the online version of the Sep 81
version of the Proposed Federal Information Processing Standard
"Specification for Message Format for Computer Based Message Systems".
It is 99 pages, formatted, and can be FTPed from host SRI-NIC in file
<NETINFO>RFC806.TXT.  For CSNET users, or any others not having direct
ARPANET access for FTP, a message to NIC@SRI-NIC requesting it should
get you a copy in your mailbox.  ALso, I now have a copy in
my directory and for the next couple of days I will also honor such
requests.

Cheers,
Rich
-------

Date: 23 Jun 1982  8:14:00 EDT (Wednesday)
From: Ken Pogran <pogran at BBN-UNIX>
Subject: Re:  [To]:
In-Reply-to: Your message of 22 Jun 1982 17:25 PDT
To: CERF at USC-ISI
Cc: pogran at BBN-UNIX, dcrocker at UDEL-RELAY, Header-People at MIT-AI

Vint,

Could we compromise on interaction?  I can see your point, but I don't
like the unilateral hack.  So, perhaps, if the mail system recognizes
that you're about to do a dumb thing, it should ask you if you REALLY
want to do it.

But only if you've put the right entry in your profile ...

     Warning:  You are a bcc recipient.
     Reply to to/cc list? (Y/N)

Ken



Date:  23 June 1982 09:08 edt
From:  Charles Hornig at MIT-MULTICS
Subject:  Re:  [To]:
Sender:  Hornig.Multics at MIT-MULTICS
To:  header-people at MIT-MC
In-Reply-To:  Message of 23 June 1982 08:35 edt from Ken Pogran

The Multics mail reading program takes a different approach to replying
that seems to get around some of these problems.  First, you must
explicitly indicate that you want to reply to all the (original)
recipients of a message.  The default is to reply only to the mailbox in
the Reply-to: (or From:) field.  Second, it tells you exactly to whom it
is replying before you start composing your reply.  If there are more
than 2 or 3, it gives the first few and tells you how many others there
are.  This gives you a wonderful opportunity to realize that you don't
want X to receive the reply, and edit him out of the header.  This seems
to me to be a more general solution to the problem of replies.

Date: 23 Jun 1982 0727-PDT
Sender: CERF at USC-ISI
Subject: Re: The Proposed NBS Standard
From: CERF at USC-ISI
To: mo at LBL-UNIX
Cc: smb.unc at UDEL-RELAY, header-people at MIT-MC
Message-ID: <[USC-ISI]23-Jun-82 07:27:17.CERF>
In-Reply-To: Your message of 22 Jun 1982 22:49:40-PDT

Mike,
everyone got one! sent them to a lot of places.
Some of the ideas in the BBN/NBS format are like the ideas Jon Postel
developed in his multimedia message transport format. The NBS
stuff fits more into that area, I think. The revised 733 is not,
in my view, intended to compete at all with the NBS or other multimedia
ideas. It is intended to bring stability and documentation to the
current text-only mail system of which we have so many implementations.

Any substantive comments you might wish to share about the NBS
document would be of real interest to me.

Vint Cerf

Date: 23-Jun-82 10:00:18-EDT (Wed)
From: mark@Berkeley (Mark Horton)
Subject: Re:  [To]:
Via: cbosgd.uucp (V3.94 [3/6/82]); 23-Jun-82 10:00:19-EDT (Wed)
To: header-people@mit-mc@Berkeley

Untrue!  People often put in Reply-to: with the intent that they are
modifying the semantics of the Reply command on the other end.  Thus,
there had better be some universal notion of what "reply" means or this
is meaningless.

In my experience, there are two major uses of reply: (1) reply only to
the person who sent the mail, (2) reply to all people who sent or received
the mail.  These two need to be explicitly defined.  Of course, if a
mail system wants to implement ADDITIONAL options, there is not reason
why they shouldn't.  But these two functions are so common and important
(and confused by all the different special cases and exceptions) that
we need algorithms.

	Mark

Date: Wednesday, 23 Jun 1982 09:21-PDT
To: header-people at MIT-MC
Subject: Re:  [To]:
In-reply-to: Mark Horton's message of 23-Jun-82 10:00:18-EDT (Wed).
From: greep at RAND-UNIX

What we currently have is that messages specify various data in the form of
header fields, to which the receiving programs may attach different
interpretations than those intended by the sending program or user, e.g.
the use of "from" and "sender".  Mark's message suggests (I'm not sure if
this is what he intended) that the header could specify to the receiving
programs how they are expected to handle the message.  For instance the
header could somehow indicate that replies should, by default, go to
certain of the listed addresses but not others.  That is, we are talking
about moving towards transmitting algorithms of a restricted form rather
than just data.  I think this sort of thing would be a step in the right
direction since it would reduce the effects of different interpretations of
headers.

Date: 23 Jun 1982 0941-PDT
Sender: CERF at USC-ISI
Subject: Re:  [To]:
From: CERF at USC-ISI
To: pogran at BBN-UNIX
Cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI
Message-ID: <[USC-ISI]23-Jun-82 09:41:42.CERF>
In-Reply-To: Your message of 23 Jun 1982  8:14:00 EDT (Wednesday)

Ken,
as I've said before, my interest is not so much in the mechanism
as in having some means of protecting against accidental response
to something received as a bcc. Of course, I hope the mechanism selected,
if any, is technically sound and generally acceptable to the implementers.

Vint


Date:     23 Jun 82 13:31:54-EDT (Wed)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  "From" clarification

I seem to have created some confusion, about the status
of acceptable From field contents.  My note, yesterday, did
not make a point of mentioning its relationship with the
Unix/Mark Horton/etc. issues about simplifying contents.

I had focussed solely on the issue of requiring machine-usable
addresses and not on the prohibition of human-name information.

The spec currently permits <mailbox> which permits human
name .

Dave


Date: 23 Jun 1982 1839-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re:  [To]:
To: CERF at USC-ISI, pogran at BBN-UNIX
cc: dcrocker at UDEL-RELAY, Header-People at MIT-AI
In-Reply-To: Your message of 23-Jun-82 0941-PDT

I think we have drifted off from the RFC733 related import of this
issue.  Dave's HACK has established a new user field which is not
defined in 733, though it is not illegal either, under the
"user-defined" rules as I recall.

But, if everyone used this ploy to avoid BCC REPLY problems, would we
not need to recognize [to] in RFC733 so that USER AGENTS couuld all know
what such things mean and be programmed to take meaningful actions
related to the acepted meanings?

It seems to me that the real issues underlying RFC733 are to provide
common understanding of the meaning of transmitted header information,
so as to facilitate communication between UA's on behalf of their
users, who are the primary correspondents in the first place.

Is it not towards common menaing and use of header fields that we are
headed?

Best - Stef
-------


Date: 23 Jun 1982 1115-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: [To]:
To: CERF at USC-ISI
cc: Header-People at MIT-AI, JNC at MIT-XX
In-Reply-To: Your message of 22-Jun-82 2202-EDT

	What you really want is a mail system where 'REPLY ALL' is not the
default, as well as a delay after hitting the 'SEND' button to allow
the poor user to cancel the message.
-------


Date: 24-Jun-82 13:30-PDT
From: ANDREWS at OFFICE  
Subject: RE: [To], larger issues
To: Steve Bellovin <smb.unc@UDel-Relay>
Cc: HEADER-PEOPLE at MIT-MC
Identifier: OAD-DIA-11CA3
Length: 2 page(s)[estimate]
Posted: 24-Jun-82 13:28-PDT
 
Let's here it for Steve Bellovin's suggestion regarding looking 
at the NBS standard.  Several of us at Tymshare are just 
finishing up the new AUGMENT Mail system -- AUGMENT is 
Tymshare's comprehensive office information system, and runs on 
several hosts on ARPANET and TYMNET (some on both nets).  We are
following the proposed NBS message format quite closely.  AND we
convert both to/from RFC733 format now.  We are sitting here 
waiting for you all to get your act together!

All I have to say at this point is: (1) Sheeee! what a volume of
discussion, (2) if you deviate from the NBS standard 
significantly you should have good reasons and lean on NBS about
them, and (3) you have some funny looking fields proposed that 
relate to inter-net kinds of things (return-path, received) that
in my opinion belong in the transfer protocols but NOT in the 
message format.  That is, that info is for message handlers and 
not necessarily people -- sure, mail hackers want to see that 
stuff, but Joe mail reader just wants the To, From, (a few more)
and the body, and the hell with how it got here, as long as he 
can answer it.  I suggest you try to stick to the NBS message 
item fields and build up on information exchange between 
mailers.  Our philosophy is that mailers should not even be able
to read let alone munge the item, and that the item should be 
accompanied by distribution information for it (mailer) to 
twiddlle and pass on -- to other mailers and not to the 
recipient.  Of course when an item is converted to another 
format a "converter" has to translate (possibly) every field etc
and munge addresses so that "answer" functions will work in the 
target mail environment-- but the whole idea behind having a 
format protocol is to avoid that.

While I'm at it let me add that I agree with a recent point 
about a Bcc recipient answering and getting burned-- that is a 
user feature issue, not a RFC733 level issue!  PLEASE don't 
confuse the two.  Along that line I have no use for the Remail-*
fields.  I suggest putting the previous header info in the body 
or in a "user-defined" type field but NOT formalizing it in the 
protocol.  --Don


Date: 24 June 1982 1719-EDT
From: Rudy.Nedved at CMU-10A
To: ANDREWS at OFFICE-2
Subject:  Re: [To], larger issues
CC: HEADER-PEOPLE at MIT-MC
In-Reply-To:  ANDREWS@OFFICE's message of 24 Jun 82 15:30-EST
Message-Id: <24Jun82 171937 EN0C@CMU-10A>

Don,

Us poor 36-bit machines have all our stuff currently encoded into
7-bits....It is going to take a major amount of work (three to five
man years??) to get the mail deliverers and mail readers to
understand 8-bits and any new multi-media standard. I admit that CMU
seems to be gearing up for 8-bit byte everything but most of the mail
system transfers are 7-bit. Therefore, one should look at the new
RFC733 as an interim standard ONLY supporting TEXT and that some new
RFC on multi-media mail will become adopted for ArpaNet (If I remeber
correctly this is mentioned in the NCP to TCP conversion plan RFC as
something to think of for the future).

As for mail-routing information munged into the mail headers: Well,
either you have a mail routing table which is updated auto-magically
(real quick....not every month or year) or you put mail routing
information in the headers.  It seems the decision has already been
made to munge the mail headers.

-Rudy

Date: 24 June 1982 2341-EDT (Thursday)
From: Craig Everhart at CMU-10A
To: Rudy.Nedved at CMU-10A
Subject:  Re: [To], larger issues
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  <24Jun82 171937 EN0C@CMU-10A>
Message-Id: <24Jun82 234145 RD00@CMU-10A>

Andrews' message, if I read it correctly, only suggested that the information
embedded in the Return-Path and Mail-From header lines should be communicated
out-of-band in the mail handling protocol, not stored as part of the
(generally) user-visible mail header text.  I happen to agree with that
philosophy.

However, isn't the Return-Path line supposed to give automatic reply-ers
precisely the information that some on this list were so adamant about finding
unadorned in the From field?

Date: 25 Jun 1982 1123-PDT
Sender: WESTINE at USC-ISIF
Subject: Re: [TO], Larger Issues
From: Postel@isif
To: Rudy.Nedved at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISIF]25-Jun-82 11:23:31.WESTINE>


The "Return-Path" and "Mail-From" lines that get stuck on the
front of the message are really information used by and developed
by the mail transmission procedures, that is, they are part of
the envelope not the contents.  The problem is where to put them,
when the message is delivered.  In many systems a message is just
a file or just a small portion of a file.  Is it that important
to mark the boundary between the envelope and the contents?

--jon.

Date: 25 Jun 1982 11:45 PDT
From: Taft at PARC-MAXC
Subject: RFC 733 as an interchange standard
To: Header-People at MIT-MC
cc: Taft

I would like to add my support to the view that RFC 733 is primarily an
interchange standard as opposed to a user interface standard, and to
advocate that this approach be pushed as far as possible within the limits
imposed by Dave Crocker's mandate.  While I join Dave in hoping that the
multi-media standard will eventually supercede RFC 733, I despair of that
happening any time soon.  We should do the best we can with RFC 733 given
the constraints within which we must work, since (if past history is any
guide) we are unlikely to have another opportunity for a long time.

One way of viewing the current draft specification is as an impure
interchange standard which includes concessions to previous usage for
backward compatibility.  That is, the standard should emphasize its role
as a machine-to-machine protocol; but those aspects of user interface
design that have crept into the protocol and can't be eradicated during
this revision should be clearly labelled as such and their use discouraged
in new implementations.

To pick a trivial example, "@" and "at" are clearly redundant.  But
apparently we have decided that there are so many implementations using
each one that arbitrarily eliminating one of them would have too big an
impact on existing software.  Therefore, the specification should identify
one of them as the "preferred" usage (presumably "@" since it is
syntactically cleaner -- "at" is the only separator which is not a
special).  All software that parses headers must continue to accept either
"@" or "at"; but new implementations that generate headers should be
required to emit only "@", and existing software should be modified to
conform to the preferred usage whenever the opportunity arises.  That way,
at some future time when most of the old software has rotted away, we can
flush "at" altogether.

Various people have objected to this sort of standardization because
"computers should serve people, not the other way around".  But this misses
the point of having an interchange standard.  Your computer should serve
you and my computer should serve me; but my computer shouldn't need a fancy
parser to figure out what your computer said to it.

What confuses the issue is that the interchange protocol is human-readable,
as opposed to a more machine-oriented protocol such as the NBS draft
standard; this causes implementors of mail-handling software to gain the
mistaken impression that what appears on the wire between computers is what
the humans are meant to see.  Actually, we are adopting this human-readable
protocol for backward compatibility, and also to permit the participation
of mail users who have minimal support from user interface software.  But
such use should not be the primary focus of RFC 733, and the convenience of
such use should not even be a consideration.

The draft RFC 733 already has something to say along these lines,
particularly in section 1.1, "Scope", and 1.2, "Communication Framework".
The document needs more emphasis on its role as an interchange standard so
as to forestall religious debates over matters that are really user
interface issues.

	Ed Taft


Date: 25 Jun 1982 14:01 PDT
From: Taft at PARC-MAXC
Subject: Line folding
To: Header-People at MIT-MC
cc: Taft

In line with my position that RFC 733 should be an interchange standard
rather than a user interface standard, I would like to advocate strongly
that we delete from the specification any requirement that the contents of
a message (either header or text) be divided into lines of any particular
fixed length.

Such a requirement is a serious infringement on the ability of user
interface software to control the appearance of messages being presented
to the human user (which is stated as an important property of the
communication framework in section 1.2 of the draft specification).

The specific problem this causes, of course, is that the sender and
recipient of a message may be using terminals with very different
characteristics, particularly a different number of characters per line.
If the mail sending program inserts CRLFs in outgoing messages to conform
to the format of the sender's terminal, the resulting text may be too wide
or too narrow for the recipient's terminal.

It is extremely difficult for the recipient's mail software to reformat
such a message properly, because information has been lost: there is no
syntactic distinction between CRLFs inserted for formatting purposes and
ones that truly represent breaks in the text.  (There is sometimes a
semantic distinction, but one that requires an unreasonably sophisticated
parser to discern.)  On the other hand, if the transmitted version of the
message does NOT contain CRLFs inserted for line folding, both the sending
and receiving mail systems can trivially format the text as appropriate for
their own local terminals.

Note that I am NOT advocating either that the syntax for folding long
headers be removed from the specification or that mail sending programs be
prohibited from folding long lines if they want to.  There are clearly
situations in which the sender wants to convey a specific visual effect to
the recipient; and there is no widely-agreed-upon convention for conveying
such information other than by explicit insertion of CRLFs, spaces, etc.

The specific measures I propose are:

(1) Delete all mention of any specific required or recommended line length
(e.g., the "65 or 72 characters" in section 3.4.7).

(2) The spec should either discourage automatic CRLF insertion in
transmitted messages or remain silent on the issue, particularly with
regard to the text of messages.  (I'm actually not so concerned about the
header -- since the header DOES conform to a well-specified syntax,
reformatting it is not especially hard.)

(3) The spec must disallow mail software from unilaterally imposing any
line length limit on incoming messages -- or, indeed, any restrictions at
all on the content of the text.  Currently there exist FTP mail servers
that will not accept messages containing lines longer than some limit
or containing certain characters such as control-C.

	Ed Taft


Date: 25 Jun 1982 1703-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Unexplored Topic -- Length of Mail Message
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423

This may actually be straying a bit, but I think it deserves at least
some attention.

Some mail handlers impose limits on the size of messages which they
may transport. The impact this has varies from site to site, and has
several different reasons for being. In our case, our mailer imposes a
limit which prohibits large source files or documents from being
transmitted via the network mail system. The reason to do this was
apparently to convince people to use FTP for long files, and mail only
pointers of the file. We also try to prevent one user from tying up
the mail process all day with his message and have timeouts set up to
control this.

In current practice, networks and internetworks can have problems
doing ftp transfer system to system, while mail processing tends to
happen more easily and less expensively. Mailing a message containing
the entire source to the operating system may be of some real value to
me.  Certainly mailing something as small sized as RFC733 should not
pose a problem, yet it does for some systems and sites.

Perhaps this is really something to think about in SMTP, but the issue
of whether or not we should impose a limit, allow this to be a site
independent issue, or require that there be no limit on the size of
mail messages might be a useful topic on Header-People for inclusion
in Son-Of-RFC733.

There are really two issues here: One of them is clearly related to
the protocol which actually transfers the mail (e.g. SMTP), in that it
needs to have some built-in mechanism to control what happens to mail
if the site can't deliver it. We recently fell into a problem like
this trying to send semi-large messages to a site which had a slow
receiver. Our mailer kept timing out, and requeued the message, while
the remote site kept sending the peices of the message (effectively
saying "Here's what I got of it").

The second one is the one which needs to be addressed here, Is "MAIL"
defined to be the transaction of small messages of minimal information
exchange, relying on some other form of processing to handle large
items (e.g. FTP), or should we consider MAIL an independent and
completely self-sufficient form of computer information exchange and
communication? I vote for the latter.

Cheers,
--JSol
-------

Date: 25 June 1982 1753-PDT (Friday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: length of mail messages
To: HEADER-PEOPLE at MC

I'm glad Jon brought this topic into the spotlight.  As he suggests,
we are seeing increasing numbers of cases (particularly when dealing
with multiple networks) where standard mail presents the simplest
(and in many cases the ONLY) means for moving large files.  The provision
of a file pointer with instructions to "use FTP" doesn't do any good
to a user without direct access to the host network.  There are also
situations where, for security reasons, users on ARPANET computers
have access to network mail but *not* to TELNET or FTP.

Some reasonable way to deal with these sorts of situations, which can
only be expected to occur more frequently, is a fairly critical issue.

--Lauren--

Date: 25-Jun-82 14:07:06-EDT (Fri)
From: mark@Berkeley (Mark Horton)
Subject: Return-Path and From and Sender
Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jun-82 14:07:07-EDT (Fri)
To: header-people@mit-mc@Berkeley

Craig Everhart has a good point.  However, I thought it was the Sender
line that had the same information as Return-Path.  Why do we need both?
If the full return path is always a valid thing to mail to to get back
to the sender, and if in fact everything up to the last comma can normally
be ignored, and Return-Path is required on every message, I have no
problem with fancy From lines.  On the other hand, if you're going to
have an algorithm that looks like
	Try Reply-to.
	if that fails, check From, and understand the various syntaxes.
	if that fails, check Return-Path, and (optionally) strip to last comma.
	if that fails, check Sender.
then things are even getting MORE complex.

	Mark

Date: 25 Jun 1982 1958-PDT
Sender: CERF at USC-ISI
Subject: Re: Unexplored Topic -- Length of Mail Message
From: CERF at USC-ISI
To: JSol at USC-ECLC
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]25-Jun-82 19:58:06.CERF>
In-Reply-To: Your message of 25 Jun 1982 1703-PDT

JON,

WE TREAT THE MAIL SYSTEM AS A COLLECTION OF MORE OR LESS
AUTONOMOUS PROGRAMS WHICH RUN MOST OF THE TIME, SERVING OUR NEEDS
AS WE GENERATE OR RECEIVE MESSAGES.  PERHAPS ONE COULD IMAGINE A
SIMILAR COLLECTION OF FILE SERVICE PROCESSES WHICH MIGHT RESPOND
TO REQUESTS FOR FILES OR PART OF FILES.

PRESUMABLY THE PATH THE RETRIEVED FILE TAKES MAY BE A FUNCTION OF
THE SEQUENCE OF SERVERS WHICH ARE NEEDED TO ACHIEVE THE SERVICE.

IT ISN'T OBVIOUS TO ME AT THIS POINT WHETHER WE SHOULD PUT THE
BURDEN OF ALL SUCH SERVICES ON A SINGLE MAIL SYSTEM OR
CONTEMPLATE MANY SUCH SYSTEMS.  ECONOMY SUGGEST THE FORMER BUT
SANITY MAY SUGGEST THE LATTER.

VINT

Date: 26 Jun 1982 0442-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Unexplored Topic -- Length of Mail Message
To: CERF at USC-ISI
cc: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 25-Jun-82 1958-PDT

Ok, I guess I interpret your message as saying that we should not
confuse Mail processing with general File Transfer, but the fact
remains that people who will probably try to use this (e.g. mailing to
a uucp or CSNET host) as a file transfer protocol, which breaks some
of the implementations currently in use.

If a message times out or is somehow incomplete, it seems that half
the servers simply throw the incomplete message away, while the rest
of them try to deliver a part of the message. The real problem comes
when a mail sender expecting the latter meets a server which does the
former. The user process requeues the message (because it expects the
server to throw it away), and the server tries to deliver it, because
it thinks the sender process is going to dequeue it (saying "Oh well,
I tried").  The result is (or was, in our case) one message every half
an hour being sent to the same address. We filled up a disk pack on
both the system we were trying to send to (UCI) and the gateway to
CSNET at UDEL!

While we may not need to deal with this in the ARPANET frame, it is
reasonably cost effective for someone to set up a trivial mail
server/sender processor on their system, one which could use dial up
phone lines to do the actual delivery. In this context a mail system
also doubles as primary file transfer mechanism. A timeout in this
context could be disastrous (especially if server and sender don't
agree with what to do with the message, see above), if not expensive
(in phone bills alone). On the other hand, if you don't time out then
the possibility of a connection hanging could interrupt mail service
for quite some time.

I tend to vote for the timeout issue being a local (i.e. host related)
issue, while the protocol to deal with what to do with a failed
message might be part of SMTP, but couldn't we make some statement of
preference? I would think that the best idea is for the sender to
requeue, and the server should discard, incomplete mail (mail that it
KNOWS is incomplete). Does anyone out there disagree? I'm still
confused as to where this type of statement belongs.

--JSol

-------

Date: 26 Jun 1982 0816-EDT
From: Dan <Tappan at BBNG>
Subject: MAIL as FTP
To: header-people at MIT-MC

A crucial differenct between MAIL and FTP is that FTP
is receiver-controlled, whereas MAIL is sender-controlled:
i.e. you may find it very convenient to mail the entire
source to the monitor, but I may not wish to pay for
the storage when I receive it, and I have no way of
stopping you from sending it other than restricting
the length of incoming messages.

It seems to me that a request/response system would
be better for unattended FTP (where the receiving
server could match up incoming files with outstanding
requests).

I suspect that this discussion is getting out of the
province of header-people (I don't know what list
it's appropriate for, maybe protocals)

Dan
-------

Date: 26 Jun 1982 1126-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: MAIL as FTP discussion - can we move it to MsgGroup?
To:   Header-People at MIT-MC
cc:   Tappan at BBNG

I think Dan is right - this discussion is larger than Header-People's
restricted domain.  I propose moving it to MsgGroup; for those few who may
not be familiar with MsgGroup, the public [OFFICE-3]<ALMSA>INTEREST-GROUPS.TXT
entry for it is enclosed here.

Cheers,
Rich
---

MsgGroup at BRL
  (or at MIT-ML)

   Interest in electronic mail, message formats, message systems, and the 
   sociological implications of the above.

   Archives are kept at USC-ECL in files <MSGGROUP>MSGGROUP.*, where * stands 
   for a range of messages, in blocks of 100 (from 0001 thru 1100) or 50 (from 
   1101 on up) (MSGGROUP.0001-0100, MSGGROUP.0101-0200, MSGGROUP.1101-1150, 
   etc.).  As of 5 May 82, the last file was *.1701-1750.

   All requests to be added to or deleted from this list, problems, questions, 
   etc., should be sent to MsgGroup-Request at BRL (or at MIT-ML).

   Coordinator: EStefferud at USC-ECL/MsgGroup at USC-ECL
-------

Date: 26-Jun-82 14:02:33-EDT (Sat)
From: mark@Berkeley (Mark Horton)
Subject: Re:  Unexplored Topic -- Length of Mail Message
Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jun-82 14:02:34-EDT (Sat)
To: Header-People@MIT-MC@Berkeley

I'm glad Jon brought this up.  I'm not sure I have the answer, but
I certainly will defend to the death the right of a site not to
have to serve as a forwarding service for huge files!  Certainly each
site should have the right to set an upper limit on individual message
size, or on number of bytes or messages per unit of time from a particular
site or user to another particular site or user.  We might also want
to set a lower limit - that is, each site must allow messages of
up to X bytes (unless it disallows the message for some other reason,
of course).

While we're on this topic, let me throw a couple of other thoughts
out into the ring.  First, I think RFC 733 requires all 128 ASCII
characters to be allowed in the message.  I believe that some systems
do strange things to certain non-printing characters, and would like
to see this restricted to printing ASCII plus certain control characters,
for example space, tab, backspace, and the CRLF combination.  It is not
reasonable to assume that a 7 bit binary file will make it through
intact, but the new standard leaves me with the impression that it is
expected to.

Here's another one: what about the famous escape sequence security bug?
(This is the one in the LA times several months ago - the one found at
Berkeley, but that some people have known about for years).  This is
where a security breaker, say joe, knows that sam@isi, who is a wheel,
uses an HP 2645 (say).  So he mails sam a message containing the
escape sequence to load sam's function keys with a string containing
a bad deed, then remotely triggers the function key.  There are lots
of variations - he creates a file with name porno.joke containing
the escape sequence; the subject contains the sequence, he writes a
program to write it on sam's terminal; the sequence can also vary:
it can put the bad deed on the screen and get the terminal to transmit
the screen or line, then erase the evidence, or it can load it into
the function key where it waits for the sam to press the key, etc.
I propose that RFC 733 mail and all mailers adopt the following rule:
all control characters except for a set of a few well defined "harmless"
characters such as above will be deleted from all mail send, received,
or forwarded.  (Not just escape, because some terminals use other
codes.  I don't know what to do about hazeltines with their ~ sequences.)
This has been implemented in netnews for a few months now, and the
only problem was that we had to add backspace to the allowed set.

	Mark

Date: 26 June 1982 1621-EDT (Saturday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70, Craig.Everhart@(Mark@Berkeley, Craig.Everhart@Horton)@Berkeley
Subject:  Bogus characters in mail text
CC: Header-People@MIT-MC, Craig.Everhart@at@Berkeley, Craig.Everhart@UCB-C70@Berkeley
Reply-To: Rdmail at CMU-10A
In-Reply-To:  mark@Berkeley's message of 26 Jun 82 13:02-EST
Message-Id: <26Jun82 162106 RD00@CMU-10A>

I always viewed the defense of terminals against infiltration by random text
a province of the operating system, or perhaps of the mail reader.  The
interchange format that the machines see is not the same as the sequence of
characters that must be transmitted to a person's terminal.

Date: 26 Jun 1982 1450-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: [Craig Everhart at CMU-10A: Bogus characters in mail text]
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423

This is just an example of the sort of lossage we are faced with. Does
anyone really understand how this header got mangled so badly?

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

Date: 26 June 1982 1621-EDT (Saturday)
From: Craig Everhart at CMU-10A
To: mark at UCB-C70, Craig.Everhart@(Mark@Berkeley, Craig.Everhart@Horton)@Berkeley
Subject:  Bogus characters in mail text
CC: Header-People@MIT-MC, Craig.Everhart@at@Berkeley, Craig.Everhart@UCB-C70@Berkeley

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

Hmm, perhaps not everybody got it this mangled, am I the only one
afflicted with this bug?

--JSol
-------

RMS@MIT-AI 06/26/82 18:45:10 Re: protection against mail files with escape sequences.
To: header-people at MIT-MC
The proper solution to this problem, if you care about it,
is to either
1) remove the security from your system, making it a moot point, or
2) have ordinary ASCII mode output on your system (or whatever
mode if used for printing out random files) convert all invisible
characters to visible ones.  (There would be other modes available
for use by programs that really do want to control the display).

Since ITS does both of these things, it is not only useless but
also impossible (without patching the system) to use that trick.

Meanwhile, people frequently mail BUG-EMACS samples of TECO code
which contain control characters and Altmodes ("escapes"), and
it would be a total screw if they could not.  (It doesn't screw
the recipients.  They read their mail with EMACS, and invisible
characters all display as something).

I've been sensitized for a long time to the way that security
measures involve a great deal of imposition on others.
But this is the biggest imposition, on the most people, that I've
ever heard suggested.  Perhaps some of the rest of you were also
grossed out by it.  If so, I'd like to ask you to think of it
when you think about other security measures, both proposed and
already existing.  Perhaps they, too, are screwing people in
ways that you haven't thought about.

ITS's treatment of nonprinting characters was implemented as
a feature -- so you could read files containing them -- not
as a security measure.

Because TECO uses text files containing all 128 ASCII characters,
including stray CR and LF, it would be nice if any string of ASCII
characters can be transmitted in the text of a message.  It doesn'T
matter if some systems can't originate or ultimately receive such
messages, since presumably the places where people find it useful
to do one or the other will arrange that they can.  But any gateways
or forwarders ought to handle them.


Date: 26 Jun 1982 1837-PDT
From: Mark Crispin
Subject: mail files with funny characters
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC, RMS at MIT-AI
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

I think it is a foregone conclusion that the transport protocol is not
the right place to fix the security bugs with terminal control sequences.
It's ridiculous to propose, as RMS does, that just because somebody
suggests an improper solution to a security bug that attempting to have
security (or more accurately privacy) is wrong.  Most people seem to
prefer the luxury of having their electronic mailboxes private and
readable only by them.
-------

Date: 26-Jun-82 18:43:22-EDT (Sat)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: mail as ftp
Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jun-82 18:43:23-EDT (Sat)
To: cbosgd!header-people@mit-mc@Berkeley

I can speak with some experience here because I've seen mail
used as FTP lots of times.  You people on the arpanet have
the luxury of an FTP protocol that can talk between any two
hosts, so it's reasonable for someone who wants a file to just
grab it directly via ftp.  On the other hand, those of us on
dialup networks, such as UUCP (and presumably Phonenet), have
no way to request a file from a site more than one hop away.
The sender can't send it over more than one hop, either.  And
when several networks are involved, it's downright hopeless.
I am at least 4 hops and 3 networks away from the arpanet,
and if I want a file without using mail, I have to log in on
arpanet host ucb-c70, ftp the file to there, then berknet it
to a machine on the UCB ethernet, ethernet it to a machine on
uucp, and then uucp it to my home machine.  (Whew!)  The Berknet
and UUCP hops are spooled, so it isn't even reasonable to wait
around for them in real time.  On the other hand, if I just
have the person who posted the file mail it to me (or even
log in on ucb-c70, ftp it over, and mail it to myself) life is
much more manageable.

People use mail to transfer (text) files because it works, even across network boundaries.  It's not convenient, because the
receiver has to unpackage the file or files.  But it happens all the time.  There is no need to have special provisions for FTP
in any mail standard, as I see it, because it's easy to write a program to receive things automatically and store the contents
in a file.  (Easy if your mail system allows mail to a particular name to be processed automatically by a program - something that
seems to be lacking in many mailers these days.)  Also, unless all the networks involved supported these extra features, it would
be worthless.  Getting UUCP extended for such things is hopeless.

By the way, I hope I made a point with these last paragraphs.  If I have a wide terminal, I could easily generate huge lines.  I suspect
many of you were a bit annoyed by having to read text formatted like that.  The 80 column assumption pervades almost everything we do
(try logging in on one of those personal computer systems at 300 baud with 40 column screen formatting sometime to see what I mean) and
it's essentially impossible to get rid of it.  So let's encourage people to put out reasonably formatted lines, that will look decent
on most screens.  We're not requiring it, just recommending it.

	Mark

Date: 26 Jun 1982 23:47:19 EDT (Saturday)
From: Dan Franklin <dan at BBN-UNIX>
Subject: Re:  Unexplored Topic -- Length of Mail Message
In-Reply-to: Your message of 26-Jun-82 14:02:33-EDT (Sat)
To: mark at Berkeley (Mark Horton)
Cc: header-people at mit-mc

RFC733 is an entirely inappropriate place to address the issue of escape
characters in mail messages which might conceivably cause harm. As RMS
points out, the correct place to solve the problem is in the operating
system, not an internet mail standard! In fact, my impression is that the
only operating system RFC733 impinges upon which provides no way to
display control characters as printing chars on output is standard UNIX.
It is clearly wrong to patch RFC733 in order to get around a UNIX deficiency--
since it is both unnecessarily limiting (for users who use other operating
systems or need to receive special characters for other reasons) and
incomplete (it doesn't solve the problem for local mail, or files I get
you to look at, or off-the-wall terminals that interpret printing characters).

I do agree with Mark that it would be a good idea to include a "least upper
bound" on message size, perhaps 4096 bytes. But this is probably more the
province of the SMTP specification than RFC733.

    Dan Franklin

Date: 27 June 1982 0116-EDT (Sunday)
From: Craig Everhart at CMU-10A
To: Jon Solomon <JSol at USC-ECLC>
Subject:  Re: Bogus characters in mail text
CC: Header-People at MIT-MC
Reply-To: Rdmail at CMU-10A
In-Reply-To:  Jon Solomon@USC-ECLC's message of 26 Jun 82 16:50-EST
Message-Id: <27Jun82 011651 RD00@CMU-10A>

Apparently, everybody's copy got mangled.  The message I was answering was
addressed to "Header-People@MIT-MC@UCB-C70", and I replied to that address
without looking at it carefully.  I tried to stop the mail delivery once I
spotted the delivery to UCB-C70, but I didn't catch it in time.
Here is a copy of the original header:

	Date: 26 June 1982 1621-EDT (Saturday)
	From: Craig Everhart at CMU-10A
	To: mark at UCB-C70 (Mark Horton)
	Subject:  Bogus characters in mail text
	CC: Header-People@MIT-MC at UCB-C70
	Reply-To: Rdmail at CMU-10A
	In-Reply-To:  mark@Berkeley's message of 26 Jun 82 13:02-EST
	Message-Id: <26Jun82 162106 RD00@CMU-10A>

The mailer at UCB-C70 (i.e. Berkeley) received this, munged the header lines
somehow, and redistributed it to MIT-MC.  Apparently the header line munging
might have been appropriate had the mail been delivered from somewhere in
UUCP-land, but was inappropriate as applied to this message from the Arpanet.

While I'm here, I believe Ed Taft's message suggested that the mail readers do
the breaking of words into lines, not the mail senders.  This seems like an
elegant extension of what we all mean by spaces and CRLFs in English (prose,
poetry, and programs) text.  I can only recommend wider usage of this
interchange format.

Date: 27 June 1982 0202-EDT
From: Rudy.Nedved at CMU-10A
To: Header-People at MIT-MC
Subject:  two cents, problems
Message-Id: <27Jun82 020229 EN10@CMU-10A>

My two cents for the record:

    Can't we agree that the new RFC 733 is for sending TEXT and
    nothing else? I fail to understand why anyone would want to
    send escapes, control-c's or any other
    non-printable/non-formatting characters unless they are
    trying to do something fiendish or using the mail system in
    a bizarre and unintended way.

    As for the length of the message: If the file is huge,
    dequeue it until it is feasible to send it.
    People do send long answers or send drafts via the
    mail system.....consider it third class mail and
    let the first class mail get thru.

Anyhow, could someone answer the following questions:

    How does one handle the Return-Path, Sender and From lines
    when a piece of mail goes thru a site which only supports
    FTP/MLFL but the sending site supports both FTP and SMTP? Is
    the sending site suppose to parse the message and munge a
    new sender line?..oops multiple at-signs are illegal...hmmm

    What about high priority messages versus low priority, like
    sending mail about a meeting that will happen in two days?
    If it gets caught on a host that tries for two weeks to send
    mail before sending an error message back to the sender, well
    that burns the sender....he could have called his friend/colleague
    and talk to him/them.

-Rudy

Date: 27 Jun 1982 0000-PDT
From: Richard Furuta <Furuta at WASHINGTON>
Subject: Shuffled headers
To: header-people at MIT-MC
cc: Furuta at WASHINGTON, mark at UCB-C70

I wonder if someone out there in uucp-land might explain to me why it
is that the shuffling of Craig Everhart's message header took place.
Frankly, I have been mystified by the headers produced when using the
"reply" command to respond to uucp mail.  If I remember correctly,
replying to a message from "harpo!groucho!gummo!chico" will generate
responses to "harpo!groucho!gummo!chico", to "groucho!gummo!chico", to
"gummo!chico" and to "chico".  Why?  And why did it take such an
innocent looking header like Craig Everhart's and produce the mangled
mess we all received?

			--Rick
-------

Date: 27 Jun 1982 0514-PDT
Sender: CERF at USC-ISI
Subject: Re: Unexplored Topic -- Length of Mail Message
From: CERF at USC-ISI
To: JSol at USC-ECLC
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]27-Jun-82 05:14:08.CERF>
In-Reply-To: Your message of 26 Jun 1982 0442-PDT

I WILL CHEAT A LITTLE AND COMMENT ON THE MAIL AS FILE TRANSFER,
DESPITE THE FACT THAT IT WILL PROBABLY HAVE MOVED TO MSGGROUP BY
THE TIME THIS RESPONSE REACHES MOST PEOPLE.

WE HAVE HAD THE LUXURY OF A FAIRLY ROBUST AND RELIABLE MAIL
SYSTEM IN THE ARPANET ENVIRONMENT.  THIS BIASES ME TOWARDS THE
VIEW THAT PARTIAL MESSAGES OUGHT TO BE DISCARDED - ARBITRARY
ACTION TO TRUNCATE MESSAGES MAY BE HARD FOR A SENDER TO COPE
WITH, SINCE IT CANNOT NECESSARILY PREDICT WHICH INTERNEDIATE
FORWARDERS WILL HANDLE THE MESSAGES NOR WHAT THEIR LIMITS MIGHT
BE.

I CONFESS, HOWEVER, THAT SINCE I HAVEN'T HAD TO LIVE IN THE
PHONENET/UUCP WORLD (FOR WHICH I AM GRATEFUL), I DON'T APPRECIATE
ALL THE THINGS WHICH EVIDENTLY LEAD THAT WORLD TO TRY TO DELIVER
TRUNCATED MESSAGES.

GENERALLY, I CONSIDER IT A RUDE ACT TO SEND OUT, UNBIDDEN, A
REALLY BIG FILE/MESSAGE (SAY OVER 50000 TO 100000 CHARACTERS).
SOME TIME AGO, A PERSON MAILED TO A SIGNIFICANT LIST A 250000
CHARACTER MESSAGE WHICH CLOGGED THINGS UP PRETTY BADLY.

THE ADVICE AT THAT TIME WAS TO SEND NOTICES SO WE COULD FTP AT
OUR CONVENIENCE.

IN SYSTEMS WHICH HAVE NO DIRECT FTP SYSTEM, THIS STRATEGY ISN'T
AVAILABLE.  HOWEVER, IT DOES SEEM TO ME THAT ONE WANTS AN ANALOG
- EVEN IF ONLY A MAILBOX WHICH CAN RESPOND TO FTP REQUESTS.

HOW THIS WOULD WORK ISN'T CLEAR, SINCE SOME FTP SYSTEM WOULD LIKE
PASSWORD/LOGIN AND ONE REALLY DOESN'T WANT TO LEAVE PASSWORDS
AROUND IN MESSAGES.  PERHAPS A MESSAGE-BASED "FTP" SYSTEM WOULD
ONLY APPLY TO PUBLIC FILES?


VINT CERF

Date: 27 Jun 1982 11:48:50-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: Unexplored Topic -- Length of Mail Message
In-reply-to: Your message of 25 Jun 1982 1715-PDT (Friday).

Yes indeed mail can be BIG!!  If you don't have FTP to some 
random system (again, not ARPAnet, most likely), but DO have
mail, you do a LOT with it, like abuse it into make-do FTP.
It is crass, but it beats not getting the bits there!
This can often be the case with site 2 networks away in
the internet (note small "i").

While this shouldn't impact ARPAnet sites too much, if 733 is
indeed something the larger world might look to for guidance,
I would advocate JSol's position: Mail is another form of
machine-machine communications, complete unto itself.

As an example, the "net.sources" news topic on USENET
routinely posts fixes and entire source listings of quite
complex programs; and this is on a network with 300 or 1200 baud
hop-by-hop links!!  I am not saying this is the ulitimate solution,
or that we should advocate such things, but it does indicate
the tremendous utility of Mail in reducing the isolation of 
sites.

	-Mike

Date: 27 Jun 1982 1333-PDT
From: Mark Crispin
Subject: using mail as FTP
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I am sympathetic to the people outside of ARPANET who aren't
able to FTP files from the ARPANET.  However, I still must disagree
on the issue of whether or not it justifies using mail as an FTP.
This is an issue which is -- and should be -- something which should
be considered by each individual site's management.  Many electronic
mail systems are set up as single channel transmission entities.
Also, there is the issue of who pays for this "FTPing".  In a great
many systems, electronic mail delivery is a service provided by the
system as part of system overhead, under the presumptions that:
 (1) Electronic mail benefits all users of the system.
 (2) It is cheaper overall for electronic mail to be part of system
     overhead.
 (3) Electronic mail's cost to the system are small enough that it
     is acceptable to charge it to overhead.

    But once we leave the fantasy-land that is ARPANET, we have the
problem of who pays for the service.  In a commercial environment,
the cost of electronic mail could be absorbed as part of system
overhead.  That system will just charge a little more, say for connect
time; or perhaps the system sells electronic mail services.  So the
model is still valid.

     The model will break down, though, if electronic mail is used as
an FTP service.  A single-channel mail delivery process can be tied
up for an inordinately long period of time with a long message.  The
data transmission costs of such a message are also significantly
greater than the "typical" message.  Commercial environments would
feel the effects of this first, but even in our research world we
aren't immune to the effects; even if the "only" effect is that mail
is bogged-down for a few hours.

     I don't want to argue about whether or not the model is any good
of what whizz-bang models people can think of to replace this.  The
fact is, this is not an uncommon model.  A number of installations
really do not want to pay hundreds of dollars in data transmission
costs to provide somebody a free file transmission service.  The
advantage of FTP is that the agent who benefits from the transfer is
generally the one that pays for it (or at least is chargable for it).
This is at least one reason I believe we have not yet seen "FTP
spoolers" in general use (they do exist on some other networks, mostly
research fantasy-lands).

     The point to all this is, an installation must have, as its
inalienable perogative, the right to set a maximum limit on the size
of a message.  Anything in the standard relating to this should merely
be recommendations.  I would be happy with wording such as:
	"It is recommended that there be no limit upon the size
	of an electronic mail message.  However, if implementation
	considerations dictate that there be a limit, a minimum of
	***** bytes is recommended."
I think that 20,000 or 50,000 are good numbers to insert there,
reflecting the great majority of electronic mail traffic.

     If this sounds heartless to those who can't get a 250,000 byte
document any other way, I guess it is.  They can either manually
FTP it (in the painful way Mark Horton suggests), or they can get
the document sent by US mail in hardcopy or on tape.  If the document
is large enough, it could very well be cheaper and faster to send it
Federal Express on a tape!

-- Mark --
-------

Date: Sunday, 27 Jun 1982 13:58-PDT
To: Jon Solomon <JSol at USC-ECLC>
Cc: Header-People at MIT-MC
Subject: Re: Unexplored Topic -- Length of Mail Message
In-reply-to: Your message of 25 Jun 1982 1703-PDT.
From: greep at RAND-UNIX

If you want to send a long file via mail and your mailer doesn't let you,
what is so hard about having a program to break it up into smaller files,
putting the sequence numbers in the subject field, and repackaging them
at the other end?  This should be trivial compared with tasks such as
parsing an address like:
  Phil O. (b@man) Dendron <Phil @(more comment)Rand-Unix>

Date: 27 Jun 1982 1509-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Unexplored Topic -- Length of Mail Message
To: greep at RAND-UNIX
cc: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 27-Jun-82 1409-PDT

     Subject: Re: Unexplored Topic -- Length of Mail Message
    In-reply-to: Your message of 25 Jun 1982 1703-PDT.
    From: greep at RAND-UNIX

    If you want to send a long file via mail and your mailer
    doesn't let you, what is so hard about having a program to
    break it up into smaller files, putting the sequence numbers
    in the subject field, and repackaging them at the other end?
    This should be trivial compared with tasks such as parsing an
    address like:
      Phil O. (b@man) Dendron <Phil @(more comment)Rand-Unix>

What is missing is not a method for doing this, but a clear
understanding of what to do if you have to deliver a large message and
it times out while being delivered. We aren't imposing a limit on the
size of a message network wide, and we (pretty much) are going to let
the individual hosts determine what the maximum message will be.

If your mailer won't receive large messages but my mail sender will,
then there has to be some way for my mailer to ask your sender what
the limit is, even if that means sending you the message, and waiting
for an error reply from it saying something like "Sorry, message to
large, please break it up". Currently that is pretty much the only way
for a sender to know that the receiver has choked on the message.

Also, it is not clear that current implementations are doing the right
thing with incomplete messages. I think we all seem to agree that
incomplete messages should be requeued by the sender and not sent on
by the receiver program, not everybody's implementation does this.
Should we REQUIRE that this happen? If so, in which RFC does it
belong? Probably not Son-of-RFC733.

What does perhaps belong there is a header which displays the length
of a message. What do you think of having the sender process calculate
the size of a message and put it in a field? TENEX and TOPS-20 do
this, only it keeps this information separate from the message itself.
I think it is such a good idea, and could help solve some of the
problems with large messages (if coupled with support in SMTP to
permit the sender to ask the receiver what its maximum message size
is).

Any comments?

--Jsol
-------

Date: 27 Jun 1982 1509-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Unexplored Topic -- Length of Mail Message
To: greep at RAND-UNIX
cc: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 27-Jun-82 1409-PDT

     Subject: Re: Unexplored Topic -- Length of Mail Message
    In-reply-to: Your message of 25 Jun 1982 1703-PDT.
    From: greep at RAND-UNIX

    If you want to send a long file via mail and your mailer
    doesn't let you, what is so hard about having a program to
    break it up into smaller files, putting the sequence numbers
    in the subject field, and repackaging them at the other end?
    This should be trivial compared with tasks such as parsing an
    address like:
      Phil O. (b@man) Dendron <Phil @(more comment)Rand-Unix>

What is missing is not a method for doing this, but a clear
understanding of what to do if you have to deliver a large message and
it times out while being delivered. We aren't imposing a limit on the
size of a message network wide, and we (pretty much) are going to let
the individual hosts determine what the maximum message will be.

If your mailer won't receive large messages but my mail sender will,
then there has to be some way for my mailer to ask your sender what
the limit is, even if that means sending you the message, and waiting
for an error reply from it saying something like "Sorry, message to
large, please break it up". Currently that is pretty much the only way
for a sender to know that the receiver has choked on the message.

Also, it is not clear that current implementations are doing the right
thing with incomplete messages. I think we all seem to agree that
incomplete messages should be requeued by the sender and not sent on
by the receiver program, not everybody's implementation does this.
Should we REQUIRE that this happen? If so, in which RFC does it
belong? Probably not Son-of-RFC733.

What does perhaps belong there is a header which displays the length
of a message. What do you think of having the sender process calculate
the size of a message and put it in a field? TENEX and TOPS-20 do
this, only it keeps this information separate from the message itself.
I think it is such a good idea, and could help solve some of the
problems with large messages (if coupled with support in SMTP to
permit the sender to ask the receiver what its maximum message size
is).

Any comments?

--Jsol
-------

Date:     27 Jun 82 17:21:08 EDT  (Sun)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Maximum lengths, robustness
To:       header-people at Mit-Mc
Via:  UNC; 27 Jun 82 18:56-EDT

I agree that some sort of statement on length is needed, though I
also agree that it's really in the province of SMTP.  But I've broken
assorted mail readers on PDP-11s by sending over files >64K bytes,
which is probably an unreasonable thing to do to start with.

The real question for this group, though, is what, if anything, 733'
should contain to alleviate the problem.  It probably shouldn't have a
length field; SMTP should be able to calculate that for itself.  But
it might be reasonable for the header to contain information that would
aid in recovery from problems.  One way this can be done is to *require*
a Message-Id field; that way, a mail receiver that constantly chokes on
the same message can (in principle) detect the fact and finally reject
it (at the SMTP level).  Similarly, such a field could be used by SMTP'
to segment messages.  Finally -- and in a totally different vein -- the
universal presence of such fields would vastly aid more sophisticated
mail systems.

The other field that might be helpful is a "Precedence" field, such as the
one in the proposed NBS standard.  It would allow mail senders and receivers
to transmit high-priority messages first; these are especially useful when
the note you want to send says "hey -- your mail system is locked up trying
to send a 300K file here".  Here, I speak from sad experience; our line
to UDel-Relay was blocked last month when XMAILR kept sending the same
large file fragment through them to us.


Date:     27 Jun 82 19:03:38 EDT  (Sun)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re: Unexplored Topic -- Length of Mail Message
To:       CERF at Usc-Isi
Cc:       header-people at Mit-Mc
In-Reply-To: CERF at USC-ISI's message of 27 Jun 1982 0514-PDT
		<[USC-ISI]27-Jun-82 05:14:08.CERF>
References: Your message of 26 Jun 1982 0442-PDT
Via:  UNC; 27 Jun 82 19:40-EDT

Yes, a message-based FTP can and should be implemented -- but it will
depend on mail to send the files, and thus have to contend with any
length or character set restrictions in the mailer.


Date: 27-Jun-82 22:26:55-EDT (Sun)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: mail as FTP
Via: cbosgd.uucp (V3.94 [3/6/82]); 27-Jun-82 22:26:56-EDT (Sun)
To: cbosgd!header-people@mit-mc@Berkeley

Mark Crispin has misinterpreted what I said, leading me to believe that
I said it wrong and others have misinterpreted me too.

While many people use mail as ftp, simply because it works and nothing
else does, most files transferred are quite small.  These behave much
like ordinary mail, passing through quickly and with no problem.  Very
few sites complain about passing such mail through.

However, some people do on occasion abuse this priviledge by mailing
themselves a huge file.  (The Berkeley gateway was once shut down for
many months because of one company on the east coast apparently mailing
zillions of files from a UNIX machine on UUCP, through Berkeley, onto
the ARPANET and to another machine at the original company on the east
coast!)  Obviously sites have the right to restrict forwarding if they
feel they are being abused.

By the way, it is probably not a good idea to put something in the
standard implying a site is antisocial if it doesn't allow files at
least X bytes through unrestricted.  This just gives an abuser carte
blanche to break up his file into lots of x-1 byte messages.  This is
even worse than one huge message in some ways, since shortest-job-first
queuers will not give it the low priority it deserves.

By the way, we do have an "ftp spooler" in uucp land - the original command
"uucp" (unix to unix copy) spooled a file to be sent to another system.
Everything else has been built up on top of that primitive operation,
which has resulted in some rather strange software!  It works over
dialup lines.  Phone costs aren't the problem (most of uucp is at
Bell Labs, which has access to WATS lines and in general doesn't tend
to be too worried about phone bills) - rather the problem is that
(1) uucp won't copy files over indirect links, (2) uucp does not route
or otherwise make indirect links appear direct, (3) there is no notion
of an "ftp gateway" allowing different nets to transfer files, the way
mail can be sent between networks.

	Mark

Date: 27 Jun 1982 19:10:52-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: smb.unc at UDel-Relay
cc: header-people at Mit-Mc
Subject: Re: Unexplored Topic -- Length of Mail Message
In-reply-to: Your message of 27 Jun 1982 1737-PDT (Sunday).

I second the motion for a mail-based FTP facility (such has
been proposed for the UUCP world to deal with news archives).
While the proposed "precendence" field might not always be honored,
at least sites so concerned could have the information needed
if they wanted to schedule such replies during off hours.
Making the message-id field mandatory is also a good idea.
"Netnews" in the UUCP world has used it to do "hot-potato broadcasts"
for a long time.  It would be a real debugging aid, also.
	-Mike

Date: 28 June 1982 1052-EDT (Monday)
From: David.Lamb at CMU-10A
To: header-people at MIT-MC
Subject:  Re: using mail as FTP and Unexplored Topic -- Length of Mail Message
In-Reply-To:  Mark Crispin@SU-SCORE's message of 27 Jun 82 15:33-EST,
             greep@RAND-UNIX's message of 27 Jun 82 15:58-EST
Message-Id: <28Jun82 105221 DL10@CMU-10A>

Mark Crispin raised the valid point that a site may not wish to pay
the cost (or be able to pay the cost) of mail-as-FTP.  However, given
greep@RAND-UNIX' suggestion of splitting long messages into pieces,
there is no way to avoid this - you can only make it inconvenient,
not impossible, to do so.

It's worthwhile discussing this kind of problem, but any decisions
would more properly belong in whatever succeeds SMTP (Complex Mail
Transfer Protocol, perhaps?) rather than Son-of-RFC733.

Date: 29 Jun 1982 1539-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: CERF at USC-ISI, JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: Unexplored Topic -- Length of Mail Message
Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11835754168.33.71.28963 at DEC-MARLBORO>
Regarding: Message from CERF at USC-ISI of 27-Jun-82 0814-EDT
In-reply-to: <[USC-ISI]27-Jun-82 05:14:08.CERF>

A simple solution to the large message problem would be to have,
as part of the protocol, the sender inform the receiver of the size
of the message BEFORE transmitting it.  This gives the receiver
an opportunity to say "Woops, no, that's way too big", before all
the net traffic and disk space gets spent.  That way it's up to
each receiver;  personal machines might refuse all but the smallest
of messages, while giant mainframes with terabit memories might
accept anything.
   --------

Date: 29 Jun 1982 1304-PDT
From: POSTEL at USC-ISIF
Subject: rfc 733 revision
To:   header-people at MIT-MC


i vote for being able to send very large messages (say up to 250,000
characters), and i vote to allow any of the 128 ascii codes as data
in messages.

--jon.
-------

Date: Tuesday, 29 Jun 1982 13:08-PDT
To: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
Cc: Header-People at MIT-MC
Subject: Re: Unexplored Topic -- Length of Mail Message
In-reply-to: Your message of 29 Jun 1982 1539-EDT.
             <"MS11(2224)+GLXLIB1(1056)" 11835754168.33.71.28963 at DEC-MARLBORO>
From: greep at RAND-UNIX

There is already a mechanism for doing this in FTP (the medium used for
Arpanet mail under NCP) - the ALLO (allocate) command.  Unfortunately some
sites don't handle this command, even to the extent of telling you that
they're ignoring it.  For example, Tenex, which apparently doesn't care
much about talking to anything besides other tenexes, requires logging in
before accepting this command, and then returns a "not implemented" error
message.  It would be possible of course to pass the length as part of
the header, but then the server has to (1) parse the header, and (2) be
able to tell the sending host to stop transmitting if it decides that
the message is too long.

Date: 29 Jun 1982 1346-PDT
From: Mark Crispin
Subject: message size/data
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     In reply to Jon's message:

     I support allowing any of the 128 ASCII codes as data in messages.
It irks the hell out of me that some TOPS-20 FTPSERs consider ASCII 003
as an interrupt command, as well as considering certain other characters
as editing commands.  At one time, XMAILR used MLFL to work around this
problem, but it tickled a bug in the TOPS-20 NCP that nobody wanted to
fix (the truncated large messages problem) so we reverted back to MAIL.
The XMAILR world FTPSERs do allow all 128 ASCII codes in messages.

     XMAILR can/does/will support very large messages (the 250,000
characters Jon proposes), but will have a site-settable limit that can
be smaller than that.  250,000 bytes is larger than some (minimum
service) users' disk quotas!

     Actually, for us 250,000 characters isn't much of a hardship for
incoming mail.  Incoming mail goes through multiple channels (multiple
FTP servers), and local disk access time isn't bad.  The mailer queues
at SCORE are audited enough so that if the message is a clear-cut
loser it will be manually removed.  It's outgoing mail that hurts us,
or incoming mail that we are obligated to relay.  A site ought to have
the perogative to decline to relay a overly-large message, as well as
to prevent its local users from sending messages larger than a certain
size by management policy.
-------

Date:     29 Jun 82 18:25:15-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  More queries

Folks --

I'd like some feedback on a couple more, relatively minor points.
These are further changes that I would like to make to the standard:

Allowing LWSP-chars on the header/body dividing lines.  This is
a common error and it might be best to make it legal.  Specifically,
some user software has put a space or tab on an otherwise empty
line, which serves as the header/body delimiter.  It seems to be
a common enough implementation error that it might be worth
defining it as legal.  The modified syntax would be:

	message = fields (*LWSP-char CRLF *text)

Getting some agreement on a standardized site mailbox name for
the system administrator, so that people can know of at least one
valid address for a site.  I have no personal preference on the
string, as long as it is written into the standard.

In date/time, make seconds optional and prohibit any of the dashes
as dividors.  In the current draft, I took the dash from the
time/timezone delimiter, but not between the date components.  Might
as well clean them up, too.

Make the route sequence field look just like a domain sequence,
with the combination looking like:

	Postel <@udel-relay.usc-isi:postel@usc-isi.arpanet>

where the dots serve the same purpose as the commas, in the
original route spec.  This means that an at-sign introduces
a reference-sequence and the context determines whether it
is a domain or a route.  The resulting syntax would be:

	route = at domain ":"

Removing " at ".  With the other requirements we are imposing,
this is rather minor, but seems rather persistant as an
irritant.  In the scheme of pushing towards being an interchange
standard, rather than heavily human-, and display-, oriented,
this seems reasonable.  It has, rather frequently, been pointed
out that there is nothing to prevent user interface programs
from accepting " at " and converting it.  Note that this sort
of thing is often done, already, for permitting short-form
specification of local addresses.  The user interface then
adds on the local host name.  (For reference, this is a reversal;
I'm giving in to the arguments from Taft, et cie.)

Dave


Date: 29 June 1982 19:55-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Unexplored Topic -- Length of Mail Message
To: LCAMPBELL at DEC-MARLBORO
cc: HEADER-PEOPLE at MIT-MC

This was originally in the SMTP spec, or at least talked about.
It was removed when it was pointed out that the sender might have
to make a pass through to entire message in order to compute it
(i.e. internally not every system stores its messages the same
way they're transmitted).

Nevertheless, I think the functionality is useful enough that it
deserves to be an optional parameter in SMTP.  For example, it
would allow you to reject messages ahead of time that will fail
later due to quota or disk space problems.

Date: 29 Jun 1982 1655-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: More queries
To: dcrocker at UDEL-RELAY
cc: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 29-Jun-82 1525-PDT

re: Allowing LWSP chars on the header/body dividing lines. 

	I am concerned that the standard already considers a LWSP char
to mean that this line is a continuation of the previous header line.
This is a bit ambiguous, because it implies that either we can't
continue the last line of the header, or we have to parse the line and
if there are no characters on it then we know that it is the separator
line. 

Re: Getting some agreement on a standardized site mailbox name for the
	system administrator

I agree. LIASON is my choice of name.

Date/time - I have no opinion on this and am content to go with the
general consensus, however I would suggest if the trend is to
structure such headers, make the structure as simple to handle as
possible. The same argument for dashes applies to " at " in the
mailbox addresses (see below).

Route sequence - I am confused by reading this header, perhaps I'm not
the only one. Do we really need @signs, .'s and :'s all in routine
address? I'm not sure how to parse that route string.

Removing " at ". In the interest of defining an interchange standard,
I'll agree that it should be flushed.

Cheers,
--JSol
-------

Date: 29 June 1982 2013-EDT (Tuesday)
From: Craig Everhart at CMU-10A
To: Header-People at Mit-Mc
Subject:  Re: More queries
Reply-To: Rdmail at CMU-10A
In-Reply-To:  Dave Crocker\@UDel-Relay's message of 29 Jun 82 17:25-EST
Message-Id: <29Jun82 201348 RD00@CMU-10A>

I don't know why you want to remove the hyphen from date formats.  It doesn't
affect me or CMU much either way, as there are only a small number of date
formats we'll put into mail, but we recognize lots of them--many non-standard!

The idea of requiring some mailbox at all sites seems reasonable.  Now, what's
the function of this mailbox?  Is it for when you're trying to find a person
reputed to be at some site, but you don't know the mailbox name?  Or, more
generally, you're not sure how to spell their name?  Or what names the mail
server will accept for that person?  Or is it to complain about, say, mail
sent from a site, or bogus headers, or a bad implementation of protocol X,
or like that?  Ideally, it is all of these things, and is not the name of
a person who is only politically responsible for a site.

Actually, the Arpanet, and possibly the DoD Internet, has had a close relative
of this facility in the NIC database.  Our user Finger program recognizes the
special host "NIC" to mean to consult the Network Information Center's
database, rather than to use the Finger protocol on some matching host.
Regardless of how we get at the protocol, this NIC service has proven to be
valuable in just such circumstances: some other site is causing problems for
a server or a daemon job, and to find out why you need to consult someone at
the remote site.  Finding out what NIC has to say about that site will usuallyu
give you a code for the coordinator or liaison, and finding out what NIC has
to say about that code usually gives a functional machine address of a
responsible person.  I believe the same information is in the Arpanet
personnel handbook.

About LWSP on the blank line between message header and body.  I have seen
more than one mail-generating program have a boundary condition wherein if
a header line is just long enough, the program puts out a CRLF and some white
space, in preparation for more list elements that never come.  Then the
next line to be generated starts a new header line fresh with a new CRLF.
Mail readers I've used have had no trouble with such unaesthetic, but not
ungrammatical, headers; they understand the white space characters between CRLFs
not to indicate end-of-header.  Changing the specification at this point
might well ``break'' as many mail-generating programs as it ``fixes.''

		Craig Everhart

Date: 29 Jun 1982 1742-PDT
From: POSTEL at USC-ISIF
Subject: rfc 733 revision
To:   header-people at MIT-MC


Dave Crocker:

re the route syntax

HUH?  how can one parse the route? if a message is explicitly routed
via ISI.ARPA then FOO.DOD then X.Y.Z (all fully quallified domain
named hosts, then does your proposed string read

  @ISI.ARPA.FOO.DOD.X.Y.Z:

???

--jon.
-------

Date: 29 Jun 1982 1802-PDT
From: POSTEL at USC-ISIF
Subject: rfc 733 revision
To:   header-people at MIT-MC


Dave Crocker:

I think the requirement that the header be separated from the body by
a null (not blank) line should be maintained as is.  This is in the
spirit of keeping things simple, and avoiding unnecessary variations and 
optional behavior.

--jon.
-------

Date: 29 Jun 1982 21:12:27 EDT (Tuesday)
From: Dan Franklin <dan at BBN-UNIX>
Subject: standardized name
To: header-people at mit-mc

Re universal sitename: the word is actually spelled "liaison", not
"liason", and that, I think, is a good reason to choose another name;
there just aren't very many people who can spell it without a dictionary.
(Unless you require the word AND two or three common misspellings...)

Date: 29 Jun 1982 2033-PDT
Sender: GEOFF at SRI-CSL
Subject: Re: standardized name
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: dan at BBN-UNIX
Cc: header-people at MIT-MC
Message-ID: <[SRI-CSL]29-Jun-82 20:33:17.GEOFF>
In-Reply-To: Your message of 29 Jun 1982 21:12:27 EDT (Tuesday)

Abrams' as NBS wrote RFC-763, "Role Mailboxes", on exactly this
topic a number of years ago.  I suggest it as the basis for
`standardized names'.

Date:     29 Jun 82 20:43:44 EDT  (Tue)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re:  Unexplored Topic -- Length of Mail Message
To:       Earl A Killian <EAK@Mit-Mc>, LCAMPBELL at Dec-Marlboro
Cc:       HEADER-PEOPLE at Mit-Mc
In-Reply-To: Earl A. Killian <EAK@MIT-MC>'s message of 29 June 1982 19:55-EDT
Via:  UNC; 30 Jun 82 0:30-EDT

We're getting a bit off the topic here, but....  one way to implement
a size-limit that doesn't require an entire pass over the message first
is for the SMTP server to give some special reply to MAIL (et al)
indicating a quantum size -- after that many lines (or bytes; I'm not
fussy), the sender must stop sending and read a go/nogo decision.  Yes,
that can clog things up while a big file is coming over, but as soon as
a site discovers it can't handle it, it can wash its hands of the whole
matter.


Date: 29 Jun 1982 22:28:38-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: More queries
In-reply-to: Your message of 29 Jun 1982 1729-PDT (Tuesday).

My vote for contact point is "liaison".
	-Mike

Date: Tuesday, 29 Jun 1982 23:00-PDT
To: Admin.MRC at SU-SCORE
Cc: Header-People at MIT-MC
Subject: Re: using mail as FTP
In-reply-to: Your message of 27 Jun 1982 1333-PDT.
From: gaines at RAND-UNIX

It is probably useless to set limits on the size of messages.
Anyone wanting to transmit a large document via mail and faced with
a limit will simply transmit the document in as many small peices
as necessary.

Return-path: @USC-ISID,steve@ucl-cs
Via: USC-ISID ; Wednesday, June 30, 1982 01:52:51-PDT
Date:     30 Jun 82 8:19:36-BST (Wed)
From:     Steve Kille <steve@ucl-cs>
Reply-To: steve%ucl at isid
To:       Dave Crocker <dcrocker@udel-relay>
cc:       Header-People at Mit-Mc, mailgroup at UCL-CS
Subject:  Re:  More queries

Dave,

LSWP between header and body.

Interestingly a group of UK implementors discussed this last
week.  There are problems relating to NIFTP which for some
sites make it tricky to implement the specification as it
stands.  We suggested slackening the UK specification in this
way.  Therefore a definite vote for bringing this into RFC733.

Steve Kille
--------


Date: 30 Jun 1982  8:12:09 EDT (Wednesday)
From: Ken Pogran <pogran at BBN-UNIX>
Subject: Contacting the administrator
To: DCrocker@Udel-Relay
Cc: Header-People@mit-mc

Dave,

Three suggestions come to mind:

HELP      is perhaps a little to obvious, and also doesn't carry the
          connotation of contacting an administrator (as opposed)
          to a consultant)

LIAISON   gets my personal vote.  Except, it's hard to spell.  Also,
          to what extent have nets outside the ARPANET carried over the
          ARPANET concept of a Liaison?

ADMIN     certainly gets the point across.  But it's a little "jargon-ny".

I might also point out that trying to come up with a "standard" mailbox for
contacting the administrator could very well run afoul  of names already
in use at various hosts, possibly for other functions.

Ken


Date: 30 Jun 1982 1027-PDT
From: POSTEL at USC-ISIF
Subject: rfc 763
To:   header-people at MIT-MC


                                                        Marshall Abrams
                                                                    NBS
                                                               7 May 80
Network Working Group
Request for Comments:  763

                         ROLE MAILBOXES

Occasionally it is necessary to send mail to someone on the net who is
known only as the incumbent in an official position.  Often the mail is
undeliverable because of employee turnover.  

We have also had such a problem at NBS and have therefore created MAIL
address synonyms such as SYSTEMS, MANAGEMENT, and LIAISON to ensure that
mail is correctly delivered no matter who the incumbent happens to be.  

I suggest that all systems which permit MAIL address synonyms install
them.  I further suggest that the NIC or the ARPANet management select a
standardized set of synonyms, thus increasing their utility.

    Marshall Abrams


-------

Date: 30 Jun 82 10:52-PDT
From: zsu at SRI-TSC
To: dcrocker at Udel-Relay
CC: Header-People at Mit-Mc, ZSu at SRI-TSC
Subject: Re:  More queries


Dave,

Your discussion of "route sequence" may deserve some attention.  I am
concerned with the impression we are leaving that route-based relative
naming convention as that introduced in the "uucp" mail system is to be
adopted in the Internet Naming Convention.  The appearance of Section 6.2.7
"Explicit Path Specification" in the latest draft version of RFC733 revision
I have (dated June 22, 1982, and I received from its distribution at the
IFIP W.G. 6.5 NA System Group meeting in Boston) is especially disturbing.
In that section you stated, and I quote,

   "At times, a message originator may wish to indicate the path that
    a message should follow.  ...  The <route> portion  ...  specifies
    the sequence of hosts and/or transmission services, that are to be
    traversed.  ... "

In the message I am responding to you stated that

   "Make the route sequence field look just like a domain sequence, ... "

It appears that you may be explicitly advocating relative naming.  A point
should be emphasized here is that what is allowed by the Internet Naming
Convention should be strictly based on absolute (or sometimes referred to
as "anchored") naming.  We all know too well of the pitfalls of relative
naming.

Please correct me if I have misinterpreted your statements on relative
naming.

Also in your message, could you have mixed "relaying" with "route sequencing"?
I believe only relaying is recommended in the SMTP specification.  Relaying
is distinctly different in nature from relative "route sequencing".  The
specification of SMTP relaying, to my knowledge, is for the purpose of
providing interoperation capabilities.  I don't believe source routing is
one of its intentions.

Regards,
Zaw-Sing


Date: 30 Jun 1982 1418-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Standard mailboxes
To: header-people at MIT-MC

A mailbox name that easy to remember, and impossible to misspell, is
<host>@<host> ....

-------

Date:  30 June 1982 15:22 edt
From:  Charles Hornig at MIT-MULTICS
Subject:  Re: Standard mailboxes
Sender:  Hornig.Multics at MIT-MULTICS
To:  header-people at MIT-MC
In-Reply-To:  Message of 30 June 1982 14:18 edt from Dan Tappan

<host>@<host> has its problems too.  MIT-devMultics (for which I am the
liaison) is universally referred to as CISL.  I think that few would
remember to send mail to MIT-devMultics@CISL.

Date: 30 Jun 1982 1709-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Re: Standard mailboxes
To: BILLW at SRI-KL
cc: Tappan at BBNG, header-people at MIT-MC
In-Reply-To: Your message of 30-Jun-82 1451-EDT

Date: 30 Jun 1982 1151-PDT
Sender: BILLW at SRI-KL
Subject: Re: Standard mailboxes
From: BILLW at SRI-KL
To: Tappan at BBNG
Message-ID: <[SRI-KL]30-Jun-82 11:51:03.BILLW>
In-Reply-To: Your message of 30 Jun 1982 1418-EDT

A mailbox name that easy to remember, and impossible to misspell, is
<host>@<host> ....

-------

You mean like AI@AI, or was it MIT-AI@MIT-AI ?

WW

_____

Both.

-------

Date: 30 Jun 1982 1944-CDT
From: ZELLICH at OFFICE-3
Subject: Re: Crocker's "More queries"
To: Header-People at MIT-MC
Message-ID: <30-Jun-82 19:43:48-CDT ZELLICH at OFFICE-3>

Comments on Crocker's "More queries", 29 Jun 82 18:25:15-EDT

   Allowing LWSP in the header/body dividing lines:

      Basically, I'm against it.  It would be replacing a check for a fixed 
      character string with one that would have to allow virtually anything 
      some warped imagination could come up with in the way of LWSP 
      combinations.

   Standardized site mailbox name(s):

      I don't really see what this has to do with the scope of RFC 733, but 
      it's a pretty good idea.  The <host>@<host> suggestion is a good one, and
      the objections for those hosts with multiple names is taken care of by 
      specifying that they should support a synonym (or mail-forwarding, or 
      duplicate mailboxes, or whatever) for each common host-name synonym (\at 
      least/ for the official synonym(s) in the NIC ARPANET host-name table).

   Date/time format:

      I don't really care whether there are dashes in the date or not, and 
      neither does my hosts date-conversion software, but I still don't see why
      the dash was removed from in front of the timezone; that's probably the 
      \one/ place where it's almsot universally used.

   Route sequence field:

      I'm not following the arguments on this one too well, but have one 
      comment:  When parsing addresses, adding the colon as an address element 
      makes it \very/ difficult to distinguish a route-form address from the 
      name of a distribution list with a colon separating the listname from the
      component addresses.  It can be done, I think, but the disambiguation 
      logic gets really nasty - especially if the address form typed by the 
      user isn't using the "<" and ">" delimiters around the address.

   Removing " at ":

      Again, I vote to leave it in.  It looks a heck of a lot better than the 
      "@" in a header, and an awful lot of systems (all?) already handle it.  
      Requiring a mail-display program to reformat the header lines is a real 
      lose on many systems; if I have to implement a filter to display 
      everything in my mail environment, my system response is going to go 
      straight to hell - it's adding another protrayal program on top of the 
      system one that has to be used for the low-level formatting.

For a general argument on not changing anything unnecessarily, let's remember 
that this is a change to the standard that all of \today's/ mail programs live 
by.  When we discuss the multi-media mail standards, we're probably talking 
total replacement of many of our mail programs, and that's another ball game 
entirely; protrayal formats are definitely going to be divorced from internal 
content, etc.

Cheers,
Rich


Date:  1 Jul 1982 0915-PDT
From: MILLS at USC-ISID
Subject: Re: Standard mailboxes
To:   Hornig.Multics at MIT-MULTICS, header-people at MIT-MC
cc:   MILLS

In response to the message sent   30 June 1982 15:22 edt from Hornig.Multics@MIT-MULTICS

Charles,

You seem to imply MIT-devMultics@MIT-devMultics would not be
a mailbox acceptable to you, or that you wouldn't want to use it?
When is a nickname not a nickname?

Regards,
Dave
-------

Date:  1 July 1982 1331-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: MILLS at USC-ISID
Subject:  Re: Standard mailboxes
CC: Header-People at MIT-MC
In-Reply-To:  MILLS@USC-ISID's message of 1 Jul 82 11:15-EST
Message-Id: <01Jul82 133150 RG02@CMU-10A>

What about sites which maintain "unofficial" nicknames for other sites?
Should the mail senders which expand nicknames into full names also
have to expand the user-name if it matches the host name?  For example,
should I be able to send mail to PI@PI or would I have to send it to
CMU-20C@PI (with my mail sender expanding it to CMU-20C@CMU-20C)?

What if I give a numeric host address to my mailer because it is a new
host?

I really think <host>@<host> is a lousy idea.  Besides, it gives
absolutely NO clue as to what the function of that address is.  A name
like General Delivery at CMU-10A or Operations Manager@CMU-10B or
Postmaster@CMUC at least would allow some distinction of mail according
to the type of service that is needed.

By the way, I think Liaison should be reserved for stuff being sent to
the official Arpanet-defined Liaison.

		Rick

Date:  1 Jul 1982 1110-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Standard mailboxes
To: Header-people at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 1-Jul-82 0915-PDT

Standard mailboxes which are official (according to NIC) host names
seems quite reasonable.


-------

Date: Thursday, 1 July 1982, 16:40-EDT
From: Mike McMahon <MMcM at SCRC-TENEX>
Subject: <host>@<host>
To: HEADER-PEOPLE at MIT-MC

For the record, SCRC@SCRC means everyone who works here.  I'd be
surprised if that's unique.

Date:  1 July 1982 1906-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: Jon Solomon <JSol at USC-ECLC>
Subject:  Re: Standard mailboxes
CC: Header-people at MIT-MC
In-Reply-To:  Jon Solomon@USC-ECLC's message of 1 Jul 82 13:10-EST
Message-Id: <01Jul82 190647 RG02@CMU-10A>

OK, quick, what is the official name of the NIC?  I would have to look it up!
I am sure there are many hosts out there which are known to at least some people
only by a nickname.  How about General Delivery and Postmaster as possible
easy-to-remember FIXED names?  Try to make the functionality of the address
intuitive!

		Rick

Date:  1 Jul 1982 1633-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Standard Names
To:   Header-People at MIT-MC

No matter what name(s) we might pick, it is going to conflict with
current usage at one or more sites.  The more logical names, such as
SYSTEM, LIAISON, HELP, ADMIN, etc. are also the ones most likely to
already be in use.  Some of them might not be so easy to change,
either (SYSTEM on the OFFICE-n machines is probably a good example of
this).

On people not knowing the proper host name or official nickname: that
is probably not so much of a problem as might be expected.  A good
guess is that usually you will already have the real name of the host
in front of you in a message or something.  A good example is needing
to contact a site liaison to complain about receiving strange mailer
error messages from it.  Also, doesn't anybody ever use those
beautiful ARPANET Resource Handbooks and ARPANET Directories?  If you
don't have one yourself (and you should, because if you're an ARPANET
user you're supposed to be registered in the NIC database, and if
you're registered you get a personal copy of the Directory), then for
sure your local Liaison has one or more copies.  You've \got/ to know
who your Liaison is, because you didn't get on the ARPANET with a
mailbox all by yourself!

Cheers,
Rich
-------

Date:  1 Jul 1982 1632-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: Standard mailboxes
To: Header-PEOPLE at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 1-Jul-82 1606-PDT

I envisionned using the NIC query program or the whois server to
determine the proper address. Then you would only need to know the
NIC's address and not its official name. I guess the case where you
are reporting problems to them about their machine could be dealt with
by requiring NIC (as a special case) to have entries for all their
nicknames.

I think that expecting this of one host is easier to implement than
requiring it for all hosts on the net. An extension of this could be
to have a server on NIC that programs sending "gripes" to other hosts
could ask about whom to send to, we could keep ACTION, someone else
could use LIAISON, or whatever.

Nit: "General Delivery" contains a space and is therefore (currently)
illegal. General.Delivery (the CMU approach to this) would be "cute"
and would probably not be suitable since you probably wouldn't think
to put the space in as easily as you would have thought of the name in
a pinch. 

Less-of-a-nit: Postmaster is fine, but that implies a restriction in
responsibilities for this address to just include mail for whom you
don't know the network address. I thought we also wanted to deal with
problems like "strange mail error" or if your mail software is
generating illegal headers. I would not have thought to send such
reports to the Postmaster, but rather to the system support group.

I'm not at all sure that one address can deal with both kinds of
problems. 

Cheers,
--JSol

p.s. To Mike McMahon: I have seen other sites do the same thing as
SCRC@SCRC, but typically it is ALL@<Host>, e.g. ALL@BRL.
-------

Date:     1 Jul 82 19:33:40-EDT (Thu)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  Two solid names

The two suggestions that have been made, with no serious objections,
are Postmaster and Liaison.

The latter is subject to misspelling and one concern was that it
be reserved for "Arpanet Liaison" role.


I suggest that both be reserved and equated.

Thoughts?

Dave


Date:  1 Jul 1982 (Thursday) 1953-EDT
From: HAGAN at Wharton-10 (John Hagan)
Subject: My vote for site mail control mailbox
To:   header-people at MIT-MC

I think that Postmaster@<host> is excellent - easy to spell, has a real
meaning, and emulates the real model of "electronic" mail.
--Kid.


Date:  1 July 1982 1954-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: Zellich at OFFICE-3 (Rich Zellich)
Subject:  Re: Standard Names
In-Reply-To:  Zellich@OFFICE-3's message of 1 Jul 82 18:33-EST
Message-Id: <01Jul82 195429 RG02@CMU-10A>
Remailed-To: Header-People at MIT-MC
Remailed-From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Remailed-Date: Thursday,  1 July 1982 1956-EDT

1) Liaisons CHANGE!  I have been here almost 9 years, have served as a liaison
   myself, etc.  Therefore, I should be well informed.  I do not know, however,
   who is the liaison here at the moment.  At best, I could make an educated
   guess.

2) Host names CHANGE!  Often, during this change, old official names become new
   nicknames or vice versa.  Should I have to know which name is official?  No,
   all I should have to know is at least one way to name the host.

3) How many people have an Arpanet directory that:
	a) is available at all terminals that a person might use
	  (e.g., at home and office)
	b) is completely up-to-date
	c) never goes down (e.g., the NIC)
   I certainly do not.

A small set of fixed names beats a large set of changing names for
ease of recall.

		Rick

Date:  1 July 1982 2133-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: Dan Tappan <Tappan at BBNG>
Subject:  Re: Standard mailboxes
CC: Header-People at MIT-MC
In-Reply-To:  Dan Tappan@BBNG's message of 1 Jul 82 19:11-EST
Message-Id: <01Jul82 213357 RG02@CMU-10A>

I was using NIC as an example -- it has changed official host names many times.

		Rick

Date:  1 July 1982 2142-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: Dave Crocker <dcrocker at UDel-Relay>
Subject:  Re: Two solid names
CC: Header-People at Mit-Mc
In-Reply-To:  Dave Crocker@UDel-Relay's message of 1 Jul 82 18:33-EST
Message-Id: <01Jul82 214247 RG02@CMU-10A>

I don't think Postmaster and Liaison should be synonymous!  The former would
be used for quite different functions than the latter.
For example, the latter would deal only with mail-specific problems.
In fact, General Delivery would deal specifically with unknown mailboxes.

Personally, I very much dislike giving up spaces in names -- why must we go
against centuries of usage.  In any case, General-Delivery would certainly seem
consistent with various field-names which use "-".

By the way, should there be a standard capitalization or should all forms,
including poSTmaSTer be accepted?

		Rick

Date: Thursday,  1 Jul 1982 19:25-PDT
To: Dave Crocker <dcrocker at UDEL-RELAY>
Cc: Header-People at MIT-MC
Subject: Re:  Two solid names
In-reply-to: Your message of     1 Jul 82 19:33:40-EDT (Thu).
From: greep at RAND-UNIX

How about using something like the ITS convention of BUG-<function>,
e.g. BUG-MAIL?  This is unlikely to conflict with existing usage.
The symbology does not necessarily imply that you are reporting bugs,
it can also be interpreted as a way of bugging a person about something.

Date:  1 July 1982 2301-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: greep at RAND-UNIX
Subject:  BUG-mumble
CC: Header-People at MIT-MC
In-Reply-To:  greep@RAND-UNIX's message of 1 Jul 82 21:25-EST
Message-Id: <01Jul82 230125 RG02@CMU-10A>

A problem with BUG-mumble is that it opens up a large number of
possible values of mumble.  If I have a problem, which mumble do I
choose?  BUG-FTP?  BUG-MAIL?  BUG-MLFL?  BUG-MAILER?

Another problem is getting names that every host can (and will)
implement.  Too many values for mumble might discourage implementation.
If implemented, BUG-mumble is a winner.  It is just too broad, however,
for expecting everybody to implement -- a program is required rather
than a few simple aliases.  We need a SMALL set of names that can be
universally expected.

		Rick

Date:  2 Jul 1982 0102-PDT
From: Mark Crispin
Subject: standard mailboxes
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I think it's clear that <host>@<host> is horrible.  One name I can
think of in semi-common use is ACTION.  On some systems, a user can mail
to ACTION with a problem and she'll get "action" on the problem.  I suggest
that the following "standard names" be defined:
	LIAISON		(acknowledged are problems in misspellings)
	ACTION
	REMARKS		(a documented mailbox for vanilla TOPS-20)
	HELP
	MANAGER
	OPERATOR
	ACCOUNTS
	SYSOP		(an all-to-common jargon term, sigh!)

     The site would be free to decide upon any meaning for these names
that it wants.  However, any (and all) of these names should in one way
or another be appropriate contact points.  Even if the name is the wrong
thing for the user's request, the person who receives it should know who
to redirect the message to.  An ARPANET liaison should know where to
redirect an account request to even if she isn't the system manager or
otherwise in charge of accounts.  Even an operator should know about that,
and if not should not receive OPERATOR mail.

-- Mark --
-------

Date: 30-Jun-82 11:27:37-EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: standard contact name for system administrator
Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 11:27:38-EDT (Wed)
To: header-people@mit-mc

Note that a system may have several administrators - sometimes all
are "equal", other times they each have different functions.
For example, the USENET contact for each site on USENET has the standard
mailing address "usenet", which is normally USENET contact for each site on USENET has the standard
mailing address "usenet", which is normally forwarded to the right person.
In this case, I'm not sure what you're looking for.  If you want the right
person to report mail problems to, you might mail to "mail" or "mail-contact".
In fact, the word "contact" might be useful by itself, since it's easy
to spell and seems pretty catchy.

Does the existance of such a standard name imply that each site has
to be capable of forwarding mail to such generic names?  I have gotten
complaints from USENET sites that are unable to have mail sent to "usenet"
because that would require creating a new user called "usenet" and
there is no forwarding or aliasing capability.  (This applies to UNIX
systems inside Bell Labs, and a few backward non-BTL systems.  I'm not
too worried about them, since we can always mail to "root", and we have

Date: 30-Jun-82 11:27:37-EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: standard contact name for system administrator
Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 11:27:38-EDT (Wed)
To: header-people@mit-mc

Note that a system may have several administrators - sometimes all
are "equal", other times they each have different functions.
For example, the USENET contact for each site on USENET has the standard
mailing address "usenet", which is normally forwarded to the right person.
In this case, I'm not sure what you're looking for.  If you want the right
person to report mail problems to, you might mail to "mail" or "mail-contact".
In fact, the word "contact" might be useful by itself, since it's easy
to spell and seems pretty catchy.

Does the existance of such a standard name imply that each site has
to be capable of forwarding mail to such generic names?  I have gotten
complaints from USENET sites that are unable to have mail sent to "usenet"
because that would require creating a new user called "usenet" and
there is no forwarding or aliasing capability.  (This applies to UNIX
systems inside Bell Labs, and a few backward non-BTL systems.  I'm not
too worried about them, since we can always mail to "root", and we have
a directory of contact persons similar to the arpanet directory.)
Does this problem apply to any arpanet systems as well?

	Mark

Date: 30-Jun-82 16:15:56-EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: <host>@<host>
Via: cbosgd.uucp (V3.94 [3/6/82]); 30-Jun-82 16:15:57-EDT (Wed)
To: header-people@mit-mc

Sounds good on the surface, but if <host> is d.isi.arpa,
would it be d@d.isi.arpa, d.isi@d.isi.arpa, or d.isi.arpa@d.isi.arpa?
And what about host nicknames?

	Mark

Date:  2 Jul 1982 0918-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Re: standard mailboxes
To: Admin.MRC at SU-SCORE
cc: Header-People at MIT-MC, Tappan at BBNG
In-Reply-To: Your message of 2-Jul-82 0402-EDT

The only way this is going to work is if every site implements
every one of all possible variations on whatever theme
is chosen. Remember, this isn't something someone uses
every day (or every year) an year from now who's
going to be able to remember offhand whether
it was ACTION or HELP or POSTMASTER (or Postmaster).
Either their going to pick one at random, or
they'll look up the name in the Arpanet directory
(in which case they can find the REAL name of
the liaison).

I, personally, don't care what is chosen [I was less
than half serious in suggesting <host>@<host>,
the only advantage of <host>@<host> is that it
cuts the set of contact names to ~2: official
name and nickname, 4 if you include the name change
that happened 3 years ago]
because I don't think the gain from implementing
this will be worth the effort that has gone into arguing
about it so far.

Consider mailing lists. Despite all the effort that
has gone into publicizing <list>-REQUEST as a general
contact name, people still send requests
to the list name (typically the day after a reminder
about <list>-REQUEST has gone out). People are
lazy, if anything they will try to use whatever
the contact name at their own site is.
-------

Date: 2 Jul 1982 1309-EDT
Sender: MOOERS at BBNA
Subject: Re: standard mailboxes -- vote for HELP
From: MOOERS at BBNA
To: Header-people at MIT-MC, Tappan at BBNG
Cc: Mooers at BBNA
Message-ID: <[BBNA] 2-Jul-82 13:09:44.MOOERS>
In-Reply-To: Your message of  2 Jul 1982 0918-EDT

I vote for HELP -- It is short, simple, easy to spell, and people
might guess it, and might even remember it easily.

And it does describe the function that the user is looking for.
I find I can't remember which site is ACTION and which is
HOTLINE.  I probably couldn't spell LIAISON when under stress.  I
have never communicated with a POSTMASTER, and although I have
used GENERAL DELIVERY services, I don't associate them with help.

---Charlotte

Date: 2 Jul 1982 1316-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: Header-People at MIT-MC
Subject: Re:  Two solid names
Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11836514595.22.71.11161 at DEC-MARLBORO>
Regarding: Message from     Dave Crocker <dcrocker@UDel-Relay>
              of 1-Jul-82 1933-EDT

I prefer "Postmaster".  It's easy to remember (and spell), and even
maps onto similar functions in the "real" world.
   --------

Date: Friday,  2 Jul 1982 11:15-PDT
To: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Cc: Header-People at MIT-MC
Subject: Re:  BUG-mumble
In-reply-to: Your message of  1 July 1982 2301-EDT (Thursday).
             <01Jul82 230125 RG02@CMU-10A>
From: greep at RAND-UNIX

I agree that we need a small set of names.  I didn't mean to imply
that the "mumble" in BUG-mumble should be a variable which could
be replaced by anything, rather that having mailbox names start
with a string like "bug-" was likely to reduce conflicts with
sites that already have pre-assigned meanings to names like "system"
which might not correspond to what we intended.

Date: 2 July 1982 17:27-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: role mailboxes
To: HEADER-PEOPLE at MIT-MC

It has been NETWORK-LIAISON here for many years.  The alternate spellings
LIAISON and LIASON are also accepted.  If I remember correctly we did this
as a result of a general agreement that all hosts would do this, although I
may be remembering wrong since apparently no one else did.

Date: 2 July 1982 17:30-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: recent discussion
To: HEADER-PEOPLE at MIT-MC

I have been away for a week, so I have been seeing all of this stuff
in one large dose.  Now I understand why many people are afraid of what
would happen if a US Constitutional Convention were called.  Could we please
leave RFC733 strictly alone except for the addition of host-naming domains?

Date:  3 Jul 1982 2254-PDT
From: MILLS at USC-ISID
Subject: Re: Standard mailboxes
To:   Rick.Gumpertz at CMU-10A
cc:   Header-People at MIT-MC, MILLS

In response to your message sent   1 July 1982 1331-EDT (Thursday)

Rick,

If you advertise a "standard" nickname for an official name registered
with the NCC, I hope you are prepared to accept that name everywhere
in lieu of the registered name.

Regards,
Dave
-------

Date:  5 Jul 1982 2310-PDT
From: MILLS at USC-ISID
Subject: Re: Standard mailboxes
To:   Rick.Gumpertz at CMU-10A
cc:   Header-People at MIT-MC, MILLS

In response to your message sent   5 July 1982 1443-EDT (Monday)

Rick,

The moral is clear: never allow a local nickname to escape in a message
bound outside the local domain. See RFC-799.

Regards,
Dave
-------

Date:  5 July 1982 1443-EDT (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: MILLS at USC-ISID
Subject:  Re: Standard mailboxes
CC: Header-People at MIT-MC, MILLS at USC-ISID
In-Reply-To:  MILLS@USC-ISID's message of 4 Jul 82 00:54-EST
Message-Id: <05Jul82 144309 RG02@CMU-10A>

The problem is that site A might have a local nickname for site B.  A user at
site A might not realize that the name by which he knows B is actually a local
nickname.  For outgoiung mail, the mail sender can automatically translate
because it is sure that the name is in fact a host name.  On the other hand,
translating a name found somewhere other than in a context requiring a hostname
would be rather dangerous.  Hence, NICNAME@NICKNAME might end up as
NICKNAME@OFFICIAL which would then be meaningless to the addressed host.

		Rick

Date:  6 Jul 1982 2320-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Mailing-list for "List of lists" update notices
To:   All mailing-lists:
cc:   ZELLICH

For those of you not previously aware of it, I maintain a master list
of ARPANET mailing-lists/digests/discussion groups (currently 756
lines or ~29,000 characters) on OFFICE-3 in file:

   <ALMSA>INTEREST-GROUPS.TXT

   For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS
   login within FTP, with any password.

To keep people up to date on the large number of such lists, I have
established a mailing list for list-of-lists \update notices/.  I do
not propose to send copies of the list itself to the world at large,
but for those ARPANET users who seriously intend to FTP the updated
versions when updated, I will send a brief notice that a new version
is available.  For those counterparts at internet sites who maintain
or redistribute copies for their own networks (DECNet, Xerox, etc.)
and can't reach the master by ARPANET FTP, I will send out the
complete new file.  I do \not/ intend to send file copies to
individual users, either ARPANET or internet; our system is fairly
heavily loaded, and we can't afford it.

There is no particular pattern to the update frequency of INTEREST-
GROUPS.TXT; I will occasionally receive a burst of new mailing-lists
or perhaps a single change of address for a host or mailing-list
coordinator, and then have a long period with no changes.

To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the
mailing-list this message appears in.

Cheers,
Rich
-------

Redistributed-Date:  7 July 1982 13:57 edt
Redistributed-By:  TMPLee.DODCSC at MIT-MULTICS
Redistributed-To:  header-people at MIT-MC
Date:  7 July 1982 09:53 edt
From:  TMPLee.DODCSC at MIT-MULTICS
Subject:  NetMail Security Vulnerability Query
To:  tcp-ip at BRL, MsgGroup at MIT-ML, Postel at USC-ISI, 
     Cerf at USC-ISI

When I distributed the most recent issue of the Computer-Security-Forum
I encountered an apparent vulnerability, or weakness, in the way
messages are handled by (at least) some mail handlers.  I would
appreciate it if someone who knows could confirm or deny that this is
indeed a problem, whether it is site specific, and whether the new
regime (TCP-IP) will have eliminated it.

As some of you know, I use the UTexas mailer, since neither the BBN nor
Multics systems that are my home bases have mailers good for large
distribution lists. (mine now is about 120 names of primary
distribution.) Anyway, when it tried delivering the message to one of
the sites (Mitre-Bedford) apparently the Mitre-IMP was in what I am told
is called "loop-back" mode.  thus when Utexas thought it was connecting
to Mitre it was in fact actually connecting back to itself.  Also,
apparently, there is no (easy?) way for a host to know this is
happening.  To make the long story shorter, it thus tried sending the
messages intended for Mitre to itself.  Fortunately, none of the mailbox
names (user-id's) at Mitre matched any of those currently registered at
Utexas.  As I understand it, if, however, there happened to be a user at
Utexas with the same name (same mailbox name) as one whom I was
attempting to send the message to at Mitre, the user at Utexas would
have received the message and no-one (except him, if he were honest)
would know that anything had gone wrong.

(I don't know if MsgGroup still lives; in any case, feel free to pass
this on to anyone else who might know, within reason.)

Ted Lee

Date:  8 July 1982 00:15 edt
From:  Frankston.SoftArts at MIT-MULTICS
Subject:  Comments on comments on RFC733
Sender:  COMSAT.SoftArts at MIT-MULTICS
Reply-To:  Frankston at MIT-MULTICS (Bob Frankston)
To:  header-people at MIT-MC
*from:  BOB (Bob Frankston)
Local:  header-people at mit-mc
Original-date:  07 JUL 1982 18:39:40

I've finally managed to at least scan the last month of
header-people comments on the RFC 733.  Unfortunately I don't
have a copy of the NBS standard handy, nor do I have my SMTP
writeup here (though I can skim parts of it at a slow 9600
bps). I will probably revise my comments after I look at them.

I'll start out by discussing very specific issues and then more
general philosophy.

=> To: THE TO FIELD CANNOT BE REQUIRED. I distinguish between
the RFC-733 "To" line and forward path information (see below).
The "To" field is a private communication between me and my
mail sender.  It need not contain any information useful to a
third party?  There is no reason why it cannot contain a name
of a mail relaying service such as "whom-it-may-concern" or
some name like "header-people".  The BCC discussion illustrates
this point very well.  Why then do people insist on keeping it?
A valid reason is to understand the context of the letter?
Often this can be done by looking for magic words like
"HeAdEr-PeoPle".   The answer is not to require some
meaningless "to:" field.  It is to explicitly define fields for
discussion groups that identify the discussion.  I propose
"Forum" for the general area such as "header-people".  For a
specific discussion, a "Discussion" field might be "RFC733
revision 5".

Another valid is reason is to find out it the intended recipient.
A number of parties can share a mailbox (because a mailbox is
identical to a host -- more discussion on that later).  Thus it
become necessary to find out the intended recipient of a letter.
This cannot be solved in the "To" field since a name like
"header-people" simply does not provide that information?  The
answer lies in reexaming the purpose of the header field and the
relationship between it and FTP/SMTP.  My basic premise is that
ALL INFORMATION MUST BE REPRESENTED IN THE TEXT OF THE MESSAGE.
For this purpose we must look at the purpose of the header field.
It is basically a scratchpad for communication.  Some fields are
used by the local mail sender (to:), some by the recipient
(forum:) and some by the mail transport mechanism (FTP/SMTP
destination).

It is easy to justify a feature because it happens to work in
the current environment -- a very simple and homogenous
environment.  Not only does the "to" field work for many of the
current net hosts, but it is a useful feature allowing for some
nice reply mechanisms.  There is some recognition that things
are more complicated and that a recipient cannot always
interpret the to fields.  The ability to associate an host name
with a mailing list file is an attempt to deal with this.
Fundamentally, however, the "to" field, as specified, is as
meaningless to a given recipient as is the free text "from"
field.  There is no way that I can determine if a given letter
came via info-terms, info-trs80, or header-people when they all
appear in the header.  Nor can I determine for which of my
aliases the letter was intended.

One improvement would be to take the forward and reverse path
information of SMTP and place it in the header.  Actually I would
call this portion the "envelope" since it contains information
primarily of interest to the transport mechanism.  But the
information must be in the text portion so that any mailbox can
be a host.

=> What is a host?
Since I have mentioned mailbox==host twice I should elaborate on
it.  When UDEL was added to the network as an off-net host, it
had to cheat.   Unfortunately, it got away with it.  The problem
is that it is kludged up to look like a direct host on the
network.  This was done in conspiracy with the its network host.
The alternative is to have a network host serve as a gateway and
use an extended addressing construct as user@host-a@host-b.
(We'll get to @ @ later).  This must be doable without any
knowledge on the part of host-a.  And it can be done simply by
treating the mailbox as a host.  The receiving FTP server would
process the foward routing information normally and place the
processed result in the mailbox as part of the letter.  Some time
later (or immediately) another program can examine the contents
of the mailbox and forward the letter appropriately.

This has implications on the domain scheme mentioned in the
revision.  It claims that there can be an absolute inertial
reference frame.  Or at least the ability to provide a rooted
tree.  How do I treat this machine sitting on my desk which is
connected to the phone system or a leased line and which can also
transmit information via floppy disk?  It is also not the only
computer on my disk.  I know that RFC-733 mentioned something
about routing, but I could not find any details.

=> Domain/routing syntax I still maintain that routing is
fundamental and any absolute names are a convenience in a local
context.   The syntax of user@host-a@host-b is necessary to
handle the general case.  It does, however suffer from a syntax
problem in that it must be scanned backwards so as not to make
assumptions about the syntax used within host-b's domain.  We
should try to convert to host-b>host-a>user or some such forward
syntax.  (Does SMTP handle this well?)

Part of the problem arises from quoting.  Quoting does not nest
well, though I guess it is possible to employ \" to pass one through.

=> Effective reply
RFC733 should not be in the business of guaranteeing that the
reply command will work well.  It should make suggestions such as
the Reply-To field and the use of a To field to allow for a
simple reply command to work.  If the sender does not cooperate,
it is OK for it to fail.  Remember also that the whole letter is
generally forgeable.  We should attack that problem before we get
to concerned about banning what some might view as anti-social
behavior (the ommission of a To: field).

=> Funny characters in letters
I have two different comments.  The first is that the mail
standard has no business worrying about "funny" characters such
as ESC sequences in letters.  If it causes trouble on a host then
that host damn well better protect itself.  If someone wants to
be malicious then RFC733 is not going to help.

On the other hand, I think that it is wrong to require support
for more than the printing graphics and the format effectors
newline and backspace.  Perhaps a return.  Consenting hosts may
use other characters among themselves but there should be no
requirement that they be supported.  This means that a relay need
not support them.  Next thing will be a request to support the
fork, hook and chair characters in EBCDIC.

If one wants to pass such characters, then they can be encoded
via an escape sequence (not ESC sequence).  For example Multics
uses \ooo where ooo is the octal value of the character.  There
should be a standard convention which can be declared in the
header.  Thus:
     character-set-escape:  backslash-octal

The warning above replies.  The recipient should still survive
funny control characters in the mail stream, though reprimanding
the sending FTP program is valid.

One last comment on character sets.  The standards should not use
CRLF -- that is an artifact of TELNET.  Instead NL (for newline)
should be used for this sequence and declare that within the
Arpanet TELNET protocol is used between the FTP programs.

=> FTP vs mail.
Mail is the fundamental protocol on top of which FTP can be
implemented.  It is only an historical accident that the
implementation of FTP was done first.  It is proper etiquette to
only send short letters to strangers, but among friends there
should be limitation on the files that can be exchanged.   There
is a separate issue about file ACCESS protocols, but that is not
for this discussion.

=> Accounting and accountability
The issue of who should pay for mail is a serious, but is beyond
the scope of RFC-733.  It is proper for a host to refuse a large
file until it negotiates with the sender for proper payment or
permission.  I discussed that in my Master's thesis in 1974 so
will not go into detail here.

It is true that much of the implemetantion of today's mail
systems assume that it is a low cost feature that can be
supported without a serious commitment on the part a host.  To
the extent that this is not true, then a host can and should put
limits on its willingness to accept mail.  A network such as UUCP
might have to resort to only accepting mail from trusted senders
if there is any serious overloading -- even if this overloading
is not malicious.

=> Known names at hosts.
How about "@HOST".  The reasoning stems from the symmetry between
mailboxes and hosts.  For example, if "Crocker at UDEL at
UDEL-Relay" then "UDEL at UDEL-Relay" is also valid.  It can be
interpretted as either a null name and rejected, or a request to
send mail anyone at the host.  Thus if one sends mail to
"Workstation-3 at Frankston at MIT-Multics" it would go to a
designated machine whereas "Frankston at MIT-Multics" would be
to me whereever the mail system thinks it can find me.

=> Optional fields
The standard should specify that a mail presentation program is
allowed to ignore them.  Thus one cannot send the body of a
letter in the "comment:" field without knowing that the recipient
is going to see that field.  Otherwise one must always be
teaching a screen program about new fields to ignore or else be
at the mercy of each new and creative approach to header fields.

=> Message-ID's
I would like to revive them.  I just received (so far) 8
letters telling me about the master list of mailing lists. Each
with a different time stamp.  This makes it very hard to use
heuristics for eliminating duplicates.

================>Why RFC-733
This all brings us to the fundamental question:  What is the
thing that RFC733 specifies.  Judging from what I've said above,
it should first identify the players.  In this case it consists
of mail servers which originate, transfer and present mail.  The
origination program takes information provided in a header in
fields like "to", "cc" and "bcc" and translates it into envelope
fields specify the forwarding path.  It is this forward path that
serves as the means of communication between these mail servers
up to and including the presentation program.  The presentation
program makes use of fields such as "subject", "forum" and
"reply-to" in presenting and acting upon a letter.

Both the origination and destinatation might involve just other
programs instead of human-users.  The LIAISON (or however you
spell it) may very well be a program that determines who is
on-duty at the moment and sends a notification to that the person.

Date: 8 July 1982 20:05-EDT
From: David A. Moon <MOON at MIT-MC>
To: HEADER-PEOPLE at MIT-MC

Please ignore this test message.  Sorry to bother you all.

Date:     9 July 1982 1756-pdt
From:     Earl A. Killian            <Killian at MIT-MULTICS>
Subject:  people names
To:       Header-People at MIT-MC

Let's put spaces back into mailbox names.  Not being able to send mail
to "John Smith @ Host" is horrible.  I hope someday every host supports
such human-oriented addresses.

When RFC 733 first came out, not many people supported this, so there
was a movement to outlaw it, which has apparently succeded.  But in the
mean time my impression is that most mail readers have been fixed, so
the restriction is now obsolete.

Date: 11 Jul 1982 19:31:04-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: Killian at MIT-MULTICS
cc: Header-People at MIT-MC
Subject: Re: people names
In-reply-to: Your message of 9 Jul 1982 1820-PDT (Friday).

The elimination of the blanks and "at" are because the current
consensus leans toward viewing 733 as an INTERCHANGE format,
not a PRESENTATION format.  Your reader/composer can allow or
disallow whatever you wish to see when you read or compose mail.
But when it gets put into the transport layers of the mail
system, it should have been converted to the no-spaces "@"
format.  This is an optimization to make the lower level
software simpler and more robust.  The importance is the distiction
between the levels.  If you want to see/use "foo at bar", please,
be my guest, but do it in the reader/composer.

	-Mike


Date:  11 July 1982 22:53 edt
From:  Barry Margolin at MIT-MULTICS
Subject:  Re: people names
Sender:  Margolin.Multics at MIT-MULTICS
To:  mo at LBL-UNIX (Mike O'Dell [system])
cc:  Killian at MIT-MULTICS, Header-People at MIT-MC
In-Reply-To:  Message of 11 July 1982 22:31 edt from Mike O'Dell [system]

Well, that is a fine excuse for getting rid of the " at ", but doesn't
say much about the embedded blanks in the address.  If my mailing
address on a computer is "Barry Margolin", then there is good reason for
me to want to put "Barry Margolin@MIT-Multics" in the header.
				barmar


Date: 12 July 1982 04:41-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  people names
To: mo at LBL-UNIX
cc: HEADER-PEOPLE at MIT-MC

You seem to have complete misunderstood my complaint: I'm
refering to the ability to have a from field such as

From: Earl Killian at MIT-MC

Date: 12 July 1982 1444-EDT (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: mo at LBL-UNIX (Mike O'Dell [system])
Subject:  Re: people names
CC: Header-People at MIT-MC
In-Reply-To:  mo@LBL-UNIX's message of 11 Jul 82 21:31-EST
Message-Id: <12Jul82 144453 RG02@CMU-10A>

Elimination of " at " does not bother me -- the presentation can indeed be
changed.  Elimination of "Richard H. Gumpertz", however, does bother me.  Why
shouldn't it be legal.  I HATE DOTS, especially Richard.H..Gumpertz because of
the double dots.

		Rick

Date: 15-Jul-82 17:31:36-EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re:  people names
Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 17:31:39-EDT (Thu)
To: header-people@mit-mc

Re: putting spaces in names

While spaces look nice, the problem is not in mail readers but in mail
senders.  If you have a long list of people, currently I can type
	mail joe@site1 ucbvac!sam sally
and it breaks the sites apart at the spaces.  (This fits nicely with
the UNIX convention of pre-parsing your input into white-space separated
words, and I assume it doesn't matter on sites where you are forced to
enter the names to prompts.)  If you allow spaces in names, you are
forced to type a comma, probably followed by a space.  The problems
this causes are:

(1) This breaks existing usage conventions on UNIX systems.  In fact,
    there is no way to upward compatibly implement a scheme allowing
    spaces, forcing a user interface change.  I can promise you that
    the powers that control uucp will never install software that
    requires a sudden, incompatible, change to the user interface.
    (Don't yell at me, I'm not the powers that be.)
(2) This is impossible to implement on UNIX systems if you allow
    more than one space together, or consider tabs and spaces different,
    since the program only sees a list of words.
(3) <comma> <space> is harder to type than <space>.  In fact, <comma>
    is harder to type than <space>.  I think how easy something is to
    type is more important than how sexy it is to read.

    	Mark

Date: Thu 15-Jul-1982 18:41-EDT
From: Stephen Tihor <TIHOR at NYU>
To:   header-people at MIT-MC
Subject: Re: Peoples Names and Unix

Hum.  I am not sure what system you were using but every Unix system I have
used has had a quoting mechanism to pass arbitrary input to a program.
Depending on the shell/CLI in use it is usually something involving one 
or more of `, ', ", or \ .  Is this in fact just a local patch that happens
to have shown up on each system I have happened to use?  If not then
significant spaces can be used albeit those network addresses will be 
more of a pain to reach from some sites than others.  But then I occasionally
have some difficulty with MIT-MULTICS since I have to submit mixed case
usernames and the VMS system that I use as home base forces me to quote
them if I put them on the command line. (Ditto with spaces, commas, quotes,
etc.)

Date: 15 Jul 1982 1848-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re:  people names
To: cbosgd!mark at UCB-C70, header-people at MIT-MC
cc: RWK at SCRC-TENEX
In-Reply-To: Your message of 15-Jul-82 1814-EDT

    Date: 15-Jul-82 17:31:36-EDT (Thu)
    From: cbosgd!mark@Berkeley (Mark Horton)
    Subject: Re:  people names
    Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 17:31:39-EDT (Thu)
    To: header-people@mit-mc

    Re: putting spaces in names

    While spaces look nice, the problem is not in mail readers but in mail
    senders.  If you have a long list of people, currently I can type
	    mail joe@site1 ucbvac!sam sally
    and it breaks the sites apart at the spaces.  (This fits nicely with
    the UNIX convention of pre-parsing your input into white-space separated
    words, and I assume it doesn't matter on sites where you are forced to
    enter the names to prompts.)  

It also causes no problems on systems which take command-line
arguments but which don't screw around with the user's input before
the program gets to see it!

				  If you allow spaces in names, you are
    forced to type a comma, probably followed by a space.  The problems
    this causes are:

    (1) This breaks existing usage conventions on UNIX systems.  In fact,
	there is no way to upward compatibly implement a scheme allowing
	spaces, forcing a user interface change.  I can promise you that
	the powers that control uucp will never install software that
	requires a sudden, incompatible, change to the user interface.
	(Don't yell at me, I'm not the powers that be.)
    (2) This is impossible to implement on UNIX systems if you allow
	more than one space together, or consider tabs and spaces different,
	since the program only sees a list of words.
    (3) <comma> <space> is harder to type than <space>.  In fact, <comma>
	is harder to type than <space>.  I think how easy something is to
	type is more important than how sexy it is to read.

	    Mark

Not even UNIX is as losing as you claim.  While I don't use Unix often
enough to remember how off the top of my head, I do recall that the
shell does have means of quoting arguments to commands.

What bothers me about this the usual unique form of Unix chauvenism
displayed here.  I don't see why everybody should be forced to
accomodate this minor Unix quirk.  If Unix users don't like having to
quote the space in "Robert Kerns", they can put pressure on the Unix
"powers that be" to be a bit less inconvenient.  Say, by punting the
doctrine of "one parser for all".

In the meantime, I trust the rest of us won't be overly inconvenienced
by having to type <comma> instead of <space>, like we've been doing
for years anyway, ever since we learned that lists in English were
separated by commas.
-------

Date: Thursday, 15 Jul 1982 16:31-PDT
To: cbosgd!mark at UCB-C70 (Mark Horton)
Cc: header-people at MIT-MC
Subject: Re:  people names
In-reply-to: Your message of 15-Jul-82 17:31:36-EDT (Thu).
From: greep at RAND-UNIX

This is the same as with any other program on Unix.  The shell always
interprets unquoted spaces as separating arguments, and requires you to
quote a space that is to be part of an argument.  So where is the
inconsistency?  Anyway (as has already been pointed a number of times)
what we are supposed to be discussing is a standard for transmission,
not user interfaces.

Date: 15 July 1982 21:11-EDT
From: Gail Zacharias <GZ at MIT-MC>
Subject:  people names
To: CBOSGD!MARK at UCB-C70
cc: HEADER-PEOPLE at MIT-MC

Gee, if we're gonna forbid spaces for the convenience of Unix users, then we
should forbid all upper/lower case distinctions for the convenience of VMS
users.

Date: 15-Jul-82 22:02:48-EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: spaces in people names
Via: cbosgd.uucp (V3.94 [3/6/82]); 15-Jul-82 22:02:49-EDT (Thu)
To: header-people@mit-mc

Perhaps I can suggest a solution to keep everybody happy:

All systems that accept spaces in their names should also accept
the name if all spaces are turned into dots.  I think this is what
CMU does now.  They can, of course, feel free to turn dots into
spaces internally.

We should agree on some character that systems should interpret as
blank.  We can't use dot because that's significant.  (Although we
might get away with defining dot and blank as equivalent in all places
in the name, interchangeable - anyone know of something this might break?)
Mail composers could accept and translate this character.

Then we have the question of whether blanks are allowed in the
headers themselves.  (As opposed to the thing SMTP utters to get
mail sent.)  As long as there is a character reserved to be a
blank equivalent, I see no problem for UNIX with allowing them
in the header.  Perhaps underscore could be the character?
Or some control character?

WRT PP 2 above, note that the header might ALWAYS say
	From: Mark R. Horton
which mailers would interpret as equivalent to mark.r..horton,
but there is no reason why the header would have to clobbered.
Rather some internal copy of the addressee would be munged for
mapping and comparison, perhaps even the SMTP utterance, but nothing
a human non-guru would ever see.  This would imply that dot=blank
applies on the right of the at sign, too.

	Mark

Date: 16 July 1982 0138-EDT
From: Rudy.Nedved at CMU-10A
To: cbosgd!mark at UCB-C70 (Mark Horton)
Subject:  Re: spaces in people names
CC: header-people at mit-mc
In-Reply-To:  cbosgd!mark@Berkeley's message of 15 Jul 82 21:02-EST
Message-Id: <16Jul82 013845 EN0C@CMU-10A>

That isn't a comprimise. What do you give up?  If I send you mail
with a header like "Mr. Rudy Nedved", your current mailer will still
munge the headers.

I fail to understand why someone can't construct an interface to
delivermail that handles spaces. Why can't you tweak the argument
code so it looks at the last character in each word and sees if it a
comma or not and use that as the seperator. Commands like "mail Rudy
Nedved@CMU-10A, foo@bad" will then start working. [I have to admit I
haven't looked at the delivermail program enough to remember if that
hack is as simple as it seems.]

I can understand the need to reduce the amount of work but for who?
the end user or the programmer? What it seems you want to do is
reduce the work for the programmer. The user will still type spaces
in until he understands that is a no-no under YOUR version of
Unix.

Stop worrying about spaces in names if the mail software is still
being developed for your os. I can understand why someone on an
IBM-360 somewhere would be upset if she had to change code that she
has never seen before to use the new RFC.

-Rudy

Date: 16 Jul 1982 1104-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: cbosgd!mark at UCB-C70, header-people at MIT-MC
Subject: Re: spaces in people names
Message-ID: <"MS11(2224)+GLXLIB1(1056)" 11840160496.30.71.13061 at DEC-MARLBORO>
Regarding: Message from cbosgd!mark@Berkeley (Mark Horton)
              of 15-Jul-82 2202-EDT

What's wrong with just ALLOWING THE SPACES?  You can't just map
dots to spaces, because

	Mark.R..Horton

shouldn't be treated as

	Mark R  Horton

If you just allow the spaces, you don't have to invent all kinds
of crock quoting and mapping rules in order to be able to handle
human names (after all, isn't all this software supposed to benefit
humans?)
   --------

Date: 16 Jul 1982 09:10:58-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: RWK at SCRC-TENEX
cc: cbosgd!mark at UCB-C70, header-people at MIT-MC
Subject: Re:  people names
In-reply-to: Your message of 15 Jul 1982 1618-PDT (Thursday).

The last time I had to "type commas like we have been doing
for years" was 5 years ago when I was doing IBM "systems programming",
but even then, TSO allowed white space as delimiters.  I fully
agree with the need to include the space.  Since I still use @
as  a line-kill character, I don't see anything wrong with either

	foo\ bar@randomhost

or, better,

	"foo bar@randomhost"

---BUT!!

Again, we are missing the point.  The mail reader/composer is what
determines what people can and must type.  The issue is how to deal
with it as an interchange standard, ie, the levels below the
reader/composer.  The important issue is how the blank is processed
in the header lines inside.  Since we already have a quoting convention
in the proposal which looks like my first example, I don't think
we really have a problem.   If you want an address with a comma in it
(no reason to discriminate against them, either) you have to escape
it, so I don't see the problem, unless your lower level parsers
break on whitespace.  Then, the reader/composers must quote embedded
white space.  How does the user type it?  That is an individual matter,
but quoting isn't all that bad if (like me) you detest typing the
commas.  If you don't mind commas, then the reader/composer could
honor whitespace in some way.

But again, this is a reader/composer issue, NOT a 733 transport issue.

	-Mike

Date:     15 Jul 82 21:29:18 EDT  (Thu)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re:  people names
To:        (Mark Horton)cbosgd!mark at Ucb-C70, header-people at Mit-Mc
In-Reply-To: (Mark Horton) cbosgd!mark@Berkeley's message of 15-Jul-82 17:31:36-EDT (Thu)
Via:  UNC; 16 Jul 82 0:23-EDT

As several people have pointed out, UNIX does indeed allow quoting
of spaces or other characters the shell considers odd; one could say:

	mail 'Mark Horton at Berkeley' Mark\ Horton@Berkeley

etc.  What's more of a problem is the vast number of UNIX mailers out
there that don't insert commas in address lists.  I've hacked the one
I'm using now enough to understand 'Steve Bellovin <smb at unc>',
'lauren@ucla-security (Lauren Weinstein)', and lists like 'unc!smb duke!trt',
but there's not a blessed thing I can do to disambiguate a 'To' line like

	To:  host!user First Last@arpa-host

Wrong?  Sure!  But the standard Berkeley UNIX mailer omits the commas if
there are no '@'s in the address list, so I've got to handle it.  (For
reference purposes, my latest uucp database lists over 600 sites -- no
way they're all gonna change.)  UNIX chauvinism?  Perhaps.  But from here --
a non-ARPA site -- it seems that 90% of the ARPAnet is UNIX, TENEX, or ITS,
and I've detected no lack of chauvinism on anyone's part.  And UNIX is
growing very rapidly.  To ask UNIX-based ARPAnet hosts to cut themselves off
from the uucp net doesn't make any sense either -- I can think of at least
half-a-dozen sites that talk to both, and that's without digging out my
antiquated ARPAnet directory.

One other technical note about UNIX:  if the mail-composer passes the
letter on to a delivery system -- as all the better ones do -- the spaces
may still cause trouble, especially if the delivery system is invoked via
two very common subroutines (popen() and system()).  If you add a local
net to the picture, you're really tempting fate.  (Again, I'm not defending
this -- such practices are inadvisable for many other reasons; lot's of
other characters will break the mailer if those techniques are used.  But
I'd hate to count up all the UNIX programs that *do* use them.)


Date:     16 Jul 82 13:30:59-EDT (Fri)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Header-People at Mit-Mc
Subject:  legal spaces

Just for clarification, spaces are legal, as uninterpreted data,
within quoted strings.  A local-part may be a quoted string.

Dave


Date: Fri 16-Jul-1982 16:42-EDT
From: Stephen Tihor <TIHOR at NYU>
To:   header-people at MIT-MC
Subject: Re: People's Names

In-Reply-To: <smb.unc@UDel-Relay>'s message of 16-JUL-1982 14:41

I think that you are overestimating the impact of non-RFC733 mailers on the new
standard.  Granted there will be some work for gateway sites but that is why
gateing is not something that people should do casually. 

Here at NYU we deal with three different mail formats regularly: RFC733, DEC
MAIL, and UUCP mail.  Although conversion is not always completely free it can
be done fairly in a straightforwards way.  We presume that mail comming from a
given mail source will normally be in the standard format for that source and
will need to be converted into the format for its destination.  If some people
insist on using a braindamaged mailer with can not send to people with the
letter H in their names must I change my mailing address? 

As I pointed out earlier under VMS there are some difficulties sending mail to
Multics sites which have case sensitive mailboxs and do not have the
appropriate case-mapping code for the vast majority of cases where a mailbox is
unique regardless of case.  BUT I although I would suggest adding such code to
the multics mail handler I would not argue that it should be forbidden to
differentiate by case even though this would make life easier for many OS which
might want to deal with them.  

I don't really care what characters are legal in mailbox names.  Most systems
either restrict them paiunfully or have a general quoting convention and
thus do not care.  While I would be delighted to see son-of-RFC733 compatible
mailers available on all Unix sites, by definition a mailer on an ARPAnet
Unix system must be ARPAnet mail compatible if it is to be very useful.
Thus you seem to be arguing that we must restrict RFC733 to grandfather
software on non-ARPAnet systems; and with an example of an operating
system for which there will be compatible mailers available.

Date: Friday, 16 July 1982, 21:38-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re:  people names
To: Steve Bellovin <smb.unc at UDel-Relay>
Cc: header-people at MIT-MC
In-reply-to: The message of 15 Jul 82 21:29-EDT from Steve Bellovin <smb.unc at UDel-Relay>

I don't see it as so much of a problem to convert Unix sites to a more
reasonable mailer, once one exists.  Particularly if it is distributed
and supported by the people at Berkeley.  The benefit to the Unix
community in standardizing on mail software is very large, and the cost
is no higher than for any other operating system.  The current software
(everybody's, not just Unix) is inadaquate for the multi-network
environment we are in.  That's the whole point of this discussion!

It is not just the Arpanet sites involved in this, after all, but a
myriad of other local networks which link up to each other in various
ways.  True, many uucp sites will be slow to switch over, for various
good or bad reasons.  They will be able to win most of the time at
first.  Later, as they get more involved in communicating with a wider
variety of members in the inter-network community, there will be a
greater incentive to bring their software up to date.  And if the people
at Berkeley are distributing a package that does the job, I don't think
there will be much problem in most cases.

If anything, the number of Unix sites makes it CHEAPER (per site) to do
the conversion.  Consider the case on ITS.  There are only 4 of them in
the world, and the manpower available to do the conversion is strictly
limited and otherwise occupied.

Date: 16 July 1982 18:46-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  spaces in names				
To: HEADER-PEOPLE at MIT-MC

So far, the only argument for keeping spaces out of user names
has concerned the Unix user interface, and that issue which can
be dealt with easily.  Dave Crocker has pointed out that you can
use quoted strings, which is true, but is not an argument against
allowing it.  Is anyone going to defend the restriction?  If not,
let's punt it.

Date: 16 Jul 1982 19:58:33-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: EAK at MIT-MC
cc: HEADER-PEOPLE at MIT-MC
Subject: Re: spaces in names				
In-reply-to: Your message of 16 Jul 1982 1917-PDT (Friday).

WAIT A MINUTE!!!

Indeed, the largest problem is with some user interface programs,
but the restriction is still important!  What I have been proposing
is that if blanks appear in the address, they MUST be quoted,
either with \ or in a quoted string so the parsing is straightforward.
(This is strictly at the transport level!)
This is NOT the same thing as discarding the restriction!!!
Unless the blanks are constrained, the parsing is very context
sensitive, an issue we have bandered about before. (Note I didn't
say it was impossible, just very hard to get right.)  The restriction
I would favor is flushing the comma separation of addresses,
but I am not adamant about that.  But if you disallow "bold blanks",
the commas become redundant.

	-Mike


Mail-from: SU-NET host SU-SHASTA rcvd at 16-Jul-82 2340-PDT
Date: Friday, 16 Jul 1982 23:39-PDT
To: EAK at MIT-MC
Cc: HEADER-PEOPLE at MIT-MC
Subject: Re:  spaces in names				
In-reply-to: Your message of 16 July 1982 18:46-EDT.
From: Brian Reid <reid@Shasta at Sumex-Aim>

Only the most primitive TTY-oriented mail programs on Unix use the
shell as a user interface. The mail system that I use on my Unix (Rand MH)
uses a display editor (Gosling EMACS) as its front end. I can type
anything I want in a "To" field, and the mail system automatically does
all of the quoting needed to get the names through delivermail. The
whole issue of "we can't allow blanks because crufty old system XYZ
can't cope with them" is stupid and we should stay away from it.

BH@MIT-AI 07/17/82 09:12:43 Re: spaces
To: header-people at MIT-MC
Allow me to join the long line of people pointing out that we are talking
about a standard for transmission of information between two computers,
and not about a user interface standard.  98% of the discussion about
spaces in names has been irrelevant.

I would also like to point out that this cuts both ways.  Suppose you are
a person who wants to be able to type spaces in names at the user level.
You can type to your mail program
	mail Brian Harvey@AI
and your mail program can establish a connection to AI and send down the line
	To: "Brian Harvey"@MIT-AI
or perhaps
	 To: Brian\ Harvey@MIT-AI
or any other quoting convention one wants to adopt.  Your mail program can just
put quotes around all names, whether or not they contain spaces, if it wants.
This allows users to use spaces while not hairing up the inter-system parser
very much.

On the other hand, suppose you are a person who wants spaces in your user
command to separate addresses.  You can type
	mail fred joe "Brian Harvey"@AI
(note how this fits EXACTLY into the existing Unix convention for using quotes
to allow spaces within a token) and your mail program could translate that to
	To: fred@MY-SITE,joe@MY-SITE,Brian Harvey@MIT-AI
if it turns out that spaces are allowed unquoted in the inter-system protocol.

In short, the ONLY relevant question for the inter-system protocol is what is
easy to implement.  Personally, I am worried about the following case:
	To:fred@MY-SITE, Brian Harvey@MIT-AI
Now, if the space between Brian and Harvey is a legal part of a name, what
about the space before Brian?  Probably it was meant not to be part of the
name, but who knows?  If spaces are to be okay within a name it better be
explicit which spaces are meaningful and which aren't.  What about a space
just before the atsign?


Date: 17-Jul-82 11:23:18-EDT (Sat)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: unix allowing quoting
Via: cbosgd.uucp (V3.94 [3/6/82]); 17-Jul-82 11:23:19-EDT (Sat)
To: header-people@mit-mc

It is true that the UNIX shell (not the operating system or any
particular subroutine library) allows quotes.  However, my concern
is that a typical random program does NOT allow quotes - for example,
Mail's m command won't understand such addresses, making it impossible
to send mail to such a person while inside the Mail system.  This
is not an overriding concern, but life will be somewhat harder if
every little program that sends mail has to understand quotes.

I still haven't been convinced that dots and spaces can't be
considered the same.  If I'm writing a system that takes spaces
in names, presumably these names with spaces in them get mapped
into login names or file names somewhere.  There is no reason the
mapping program can't turn all spaces into dots (in an internal buffer),
possibly squash multiple dots into single ones (Mark.R..Horton=>Mark.R.Horton)
and probably map everything into one case (unless it really wants to
consider Horton different from horton or HORTON) and then look up the
resulting string.  Names could be stored in the table with dots.
Of course, even though a human never sees the dots, if the guru thinks
they are ugly, they can always map dots into spaces.

	Mark

Date: 17 Jul 1982 11:49:01-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: cbosgd!mark at Berkeley
cc: header-people at mit-mc
Subject: Re: unix allowing quoting
In-reply-to: Your message of 17 Jul 1982 1047-PDT (Saturday).

Mark,
Once and for all, the blank-to-period mapping is WRONG! I cite
a classic Berzerkelyism as an example.  Berknet (for those of
you who don't know) is an odd little network which strings
machines together on the Berkeley campus, and other places not
fortunate enough to have anything better.  It works fine, but
(one of) its address syntaxes is

	machine.person

If you adopt "pointifying", how do intend to tell, other than by
context sensitive crufty lookups, whether the period is meaingful
or not??  Periods are already overloaded; they don't need to do the
job for blanks too.  

If all this means that someone will have to fix Mail to handle quote
strings in addresses, well, zemzabreaks.  Nothing works forever,
and Berkeley has never show excessive reserve over hacking 
"improvements" before.  It would probably take Kurt about half
an hour.

	-Mike O'Dell

Date: 18 Jul 1982 0733-PDT
Sender: GEOFF at SRI-CSL
Subject: I think these UUCP headers are getting out of hand . . .
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: Header-People at MC
Message-ID: <[SRI-CSL]18-Jul-82 07:33:23.GEOFF>

Notice the following header...  i think it is so long, it is
causing the UCB gateway software to muck up.  When I rcvd the
enclosed message (below), it caused HERMES to blow up with a BCPl
STACK OVERFLOW.  Could the appropriate UCB person please fix?
	
Mail-From: ARPANET host MIT-AI rcvd at 18-Jul-82 0031-PDT
Date: 16 Jul 82 13:19:54-PDT (Fri)
From: menlo70!sri-unix!hplabs!menlo70!sytek!zehntel!teklabs!ucbcad!ARPAVAX.CSVAX.decvax!utzoo!watmath!dmmartindale@BerkeSubject: Re: type certificated lawn chairs
Subject: Re: type certificated lawn chairs
To: aviation@mit-ai
Article-I.D.: watmath.3045
Via:  news.usenet; 17 Jul 82 23:50-PDT

Actually, don't you also need to have a VHF radio on board and be in
communication with ATC to operate a lawnchair at that altitude?
WRT to transponders, wouln't you need some sort of metallic shielding
between yourself and the antenna just for safety?  Also, aren't their rules
covering the dropping of objects from aircraft?  I seem to remember that he
lost a pair of glasses at least and maybe his air rifle.


		

Date: Sat 17-Jul-1982 18:23-EDT
From: Stephen Tihor <TIHOR at NYU>
To:   header-people at MIT-MC
Subject: re: quoting and non 1 case alpha names

I suggest you speak to someone on a Multics system before you pull the
usernames out from under them or insist that they rewrite their mailer because
you don't think you can replace yours.  

As I said earlier I am not sure what people really need arbitrary 7-bit ASCII
mailbox names for but this is not a real problem:  the mail software will be
rewritten to handle it.  DARPA will see to that for BSD Unix and sensible
people elsewhere will follow suit. Some won't.  Since very few people use
Mixed-case/Funny-Character mailboxes right now, it won't be that hard on
those too lazy or sloopy to do it.  (I just can't see defending that level of
laziness or sloppiness with much vehemence.)  But if it is desired that one be 
able to do this then the standard should either say so or say that it isn't
saying so -- and thus warn people to expect anything quoted. 

The important question is will spaces be significant w/o quoting in
son-of-RFC733 mailbox names.  I don't really care.  If someone with a technical
reason ... such as "it makes the syntax ambiguous with the current whitespace
definitions" ... says it is trouble fine.  There should probably be a note
to the effect that any of the characters <Whatever-is-desired> are legal 
in a mailbox name but using any of the characters <Some-Subset-of-that> will
require the name to be quoted or the character to be escaped.  OK?

Date: Monday, 19 Jul 1982 10:32-PDT
To: header-people at MIT-MC
Subject: Re:  people names
In-reply-to: RWK's message of Friday, 16 July 1982, 21:38-EDT.
From: greep at RAND-UNIX

Just for the record, the stuff that comes from Berkeley is not the only
Unix software that talks to Arpanet mail, as a number of messages have
seemed to imply.

Date: Monday, 19 Jul 1982 10:36-PDT
To: mo at LBL-UNIX (Mike O'Dell [system])
Cc: HEADER-PEOPLE at MIT-MC
Subject: Re: spaces in names				
In-reply-to: Your message of 16 Jul 1982 19:58:33-PDT.
From: greep at RAND-UNIX

In regard to your argument about the difficulty of parsing names with
unquoted spaces, I will reiterate my suggestion that the spec include
an algorithm for parsing whatever it claims is legal.  Then all this
trickiness has to be taken into account only once, by the authors of
the spec, and implementors have only to turn the algorithm into code
for their systems.  Does anybody have any comments on this idea?

Date: Mon 19-Jul-1982 22:06-EDT
From: Stephen Tihor <TIHOR at NYU>
To:   header-people at MIT-MC
Subject: Re: Multics and Case Dependance

The question of Case Dependance had already been argued out over the net once
(in Human-Nets as regards variable names as I recall) and I have no desire to
refight it; especially when I am in favor of maximal mixed case support. 
However I am of the faction which considers use of case for disambiguation
dangerous.  Not that it must NOT be done; just that it has many obvious risks
and if one does not NEED to do it, one should not.  Thus if the mail receiver
at MIT-Multics does not map VONFOO@MIT-MULTICS into whichever of "VonFoo" and
"vonFoo" is the actual mailbox it was very poorly designed.  If the system
administrator at MIT-Multics authorized both "VonFoo" and "vonFoo" as legal
username/mailboxes then he/she was also very poorly designed. 

Date:  20 July 1982 00:32 edt
From:  Frankston.SoftArts at MIT-MULTICS
Subject:  re: quoting and non 1 case alpha names
Sender:  COMSAT.SoftArts at MIT-MULTICS
Reply-To:  Frankston at MIT-MULTICS (Bob Frankston)
To:  Stephen Tihor <TIHOR at NYU>, header-people at MIT-MC
*from:  BOB (Bob Frankston)
Local:  Stephen Tihor <TIHOR at NYU>,header-people at MIT-MC
Original-date:  19 JUL 1982 07:56:12

For clarification about Multics mailbox names:

In general, users who get mail from the Arpanet have simple
mailbox aliases that are case insensitive.

The Multics file system is case sensitive and the mapping of a
mailbox name to a filename is straightfoward but might be
ambiguous if case were ignored.  One can argue that the Multics
file system should or should not have been case sensitive, but
it is one thing to require a mailer be modified, it is another
thing to require an operating system be rewritten.

Date: 20-Jul-82 09:39:32-EDT (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: multics and case sensitivities
Via: cbosgd.uucp (V3.94 [3/6/82]); 20-Jul-82 09:39:33-EDT (Tue)
To: header-people@mit-mc

What?  I had always assumed that Multics had some good reason for
insisting that I capitalize mailboxes exactly as it does.
Now you're telling me that it's just because the filesystem supports
mixed case?  Good grief.

The UNIX filesystem supports mixed case too.  And there are zillions
of UNIX sites around.  But you'll notice this problem hasn't come up
on UNIX.  The reason is simple: all UNIX login names are always all
lower case.  Thus, if a mixed or upper case address comes in, it can
be simply mapped to lower case before processing.

Even if Multics logins have mixed case, the problem is easily solved
by having the incoming mail program map the address into one case,
the consult a table of similarly mapped local names.

I got the impression from Bob Frankston's letter that this solution
is already in effect on Multics systems.  So why do we still have
the restriction that case must match exactly?

	Mark

Date:  20 July 1982 11:19 edt
From:  Barry Margolin at MIT-MULTICS
Subject:  Re: multics and case sensitivities
Sender:  Margolin.Multics at MIT-MULTICS
To:  cbosgd!mark at UCB-C70 (Mark Horton)
cc:  header-people at MIT-MC
In-Reply-To:  Message of 20 July 1982 10:48 edt from Mark Horton

The solution that Bob Frankston mentioned is a not-well-advertised
kludge.  It involves asking the system administrator to add you to the
system mail-table (implemented as a link in a special directory).  This
mail-table is only consulted when names without projects (the part after
the dot) come in, and it is checked without case-sensitivity.

It doesn't do us much good to tell us that our System Administrator
shouldn't have assigned both userids "VonFoo" and "vonFoo".  Supposing
that they both exist on the same project (admittedly, an unlikely
occurrence) who should get the mail addressed to
VONFOO.PROJECT@MIT-MULTICS?  In addition, to be fully case-insensitive,
the project name would have to be checked case-insensitively and this
would end up being a severe system bottleneck (there are several hundred
projects on MIT-Multics, and it is not a very large Multics), since the
directory hashing is presumably case-sensitive.

Let me ask you this.  Full upper/lower-case ASCII has been around for a
long time.  Why are your systems still folding everything you type to
uppercase?  Why not just let the programs that want to be
case-insensitive do their own mapping (where the netmail-sender is not
one of these)?  If it is the case that the command processor folds all
the arguments to one case, then just teach your mail-sending program to
prompt for the names without folding.  How many times do we have to keep
saying that we are trying to design an interchange standard here, not a
user interface?.
				barmar

Date: Tue 20-Jul-1982 12:15-EDT
From: Stephen Tihor <TIHOR at NYU>
To:   header-people at MIT-MC
Subject: Mail box names.

Yes I know that "vonFoo" and "VonFoo" in the example were intended to be
distinct users.  And as I said, creating such ambiguous users is bad planning.
I agree that a mailer should not guess with of two near spellings a name 
should be mapped into.  That function should be left to a trusted person or
not attempted at all.  There are several related issues involved with MMDF
and the CSnet 'address server' function and there are security issues involved.
In general I prefer adoption of the fail-safe principle that it is better not
to deliever a message than to misdeliver it where privacy concerns exist.  And
I find remembering exact spelling and cases a pain.  But that does not excuse 
mail senders from allowing full ASCII (or whatever mailbox character set is
permited in son-of-RFC733) nor should it excuse the mail receiver from
trying to map them.

Date: 20 July 1982 20:17-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  spaces in names				
To: mo at LBL-UNIX
cc: HEADER-PEOPLE at MIT-MC

Now you're finally complaining about something of merit.  But
you've given no detail.  What parsing problems?

Date: 20 July 1982 20:24-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: case sensitivity
To: HEADER-PEOPLE at MIT-MC

Since this issue has been discussed so many times in so many
mailing lists, and since many people seem completely and utterly
unable to control their output on this subject, I suggest that
someone create a special mailing list where these people may
flame to their hearts content and leave the rest of us alone.

Date: 21 Jul 1982 08:25:11-PDT
From: lblg!j#j at LBL-UNIX
Mail-From: DECNET host j received by lblg at Wednesday, 21 Jul 82 08:07:22 PDT
Date:     Wednesday, 21 Jul 82 08:05:29 PDT
From:     j (sventek j) @ j
Subject:  Blanks in addresses
To: header-people at mit-mc, @, lblg!lbl-unix at LBL-UNIX, < at lbl-unix, header-people at mit-mc>

It is quite clear from RFC733 and its proposed successor: lists of addresses
in message headers are to be separated by commas.  As such, parsing of blanks
represents no (I repeat, NO) more problems than parsing the letter 'a'.  It
seems that all of this flaming about blanks in addresses is due to the
fact that a large portion of the UNIX faction want ARPA message headers
to conform to UUCP's format, and not vice versa.  Those of us required to
interface to mail systems which differ in internal format and addressing syntax
from canonical RFC733 have been forced to provide gateway software to massage
the messages, as mentioned in the previous entry from NYU.  Since we are
interested in a short-term modification to RFC733 for the ARPA Internet
community, it seems perfectly reasonable to require that messages from
other networks (UUCP included) be gatewayed to and from the Internet.
As such, the messages should be modified to the format which conforms to
RFC733+.   The left to right address structure does not need to be
converted, since everything to the left of the '@' is non-interpreted.
Exactly the same treatment will be necessary to gateway to any other
mail system, be it based upon the NBS standard or any other format which
differs from RFC733+.

As for the user composition utility interface for specifying addresses,
I provide two in our Software Tools Mail System: a clone of sndmsg which
requires that users specify separating commas between addresses, and an
utility named mail which takes the addresses from the command line.  As
such, if the user wishes to embed a blank in the address, s/he must
type

% mail "user at host"

Of course, the address will be properly formatted into the message, with
'@' replacing " at " (as per RFC733+) and commas separating addresses, if
more than one was specified.

I, for one, am considering placing support for blanks in user names
into my delivery system.  I get the impression that CMU did this quite
a while ago, and was forced to eliminate it.  Since we are supposed to
be progressing in this field, and since it seems totally reasonable to
specify an address of the form

Joe Sventek at j.lbl,

it would seem that the more long term decision would be in favor of
permitting blanks in addresses.  If we dodge it this time, it will
surface again later, when there will be even more inertia towards
the modification of the existing mail delivery programs.

Joe Sventek <j at lbl-unix>

Date: 21 Jul 1982 06:55:00-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: EAK at MIT-MC
cc: HEADER-PEOPLE at MIT-MC
Subject: Re: spaces in names				
In-reply-to: Your message of 20 Jul 1982 1725-PDT (Tuesday).

The crux of the issue is "when is whitespace important".  If the
rule is that "whitespace embeded in an atom must be escaped" the
the following are legal:

	"Random User"@SOMEHOST

or

	Random\ User@SOMEHOST

The following is also ILLEGAL (or subject to surprise interpretations):

	Random User@SOMEHOST

They can also be parsed unambiguously.  If, however, the "quoting rule"
is not adopted, how is the following supposed to be parsed?

	"One User"@SOMEHOST, Another User@SOMEHOST

Is the blank after the command and before the "A" part of the mailbox
name??  If you say yes, then all whitespace is treated literally;
we can't allow whitespace in the lists except where it is real.  If you
say "no", how do you have a mailbox name with leading whitespace?  Not
that I am suggesting mailbox names with leading whitespace are good,
but somewhere someone will do it, and the code has to handle all the
cases.  The only solution I can see is to quote the leading whitespace,
so why not be consistant and just require that whitespace embedded in
an atom must be quoted somehow.  Either quoting the whole atom, or
escaping the single character would work, and while I would advocate
only one of the two mechanism (single character quoting is slightly
easier to parse and isn't a real aesthetic problem since this is an
INTERCHANGE standard), but since the rest of the document has both ""
and \ schemes, they should both be allowed.

	-Mike

Date: 21 July 1982 1256-EDT
From: Rudy.Nedved at CMU-10A
To: mo at LBL-UNIX (Mike O'Dell [system])
Subject:  Re: spaces in names
CC: HEADER-PEOPLE at MIT-MC
In-Reply-To:  mo@LBL-UNIX's message of 21 Jul 82 08:55-EST
Message-Id: <21Jul82 125634 EN0C@CMU-10A>

Mike,

I agree that double quotes and the escape character should be allowed
in names and that everyone should accept them. Fine with me but if a
site has white space independent "white pages" name mapping functions
then they should be allow to send out names with any amount of
leading, intervening and trailing white space in a name. At CMU, we
will soon be supporting names like:

	Dr. Raj Reddy
	Krafty Ken Wertz
	Rudy
	TTZ
	Twilight Zone
	The Twilight Zone

which are horizontal white space independent since we look at each
white space delimited token and find the common person. Admittedly
we will be sending out a mailbox specifier like
"<fbfhsd.cmu@CMU-10A>" in our mail so that people like "John Smith"
can still recieve mail if there are three of them.

-Rudy

Date: 21 Jul 1982 10:46:56-PDT
From: ARPAVAX.eric at Berkeley
Mail-From: UCBARPA received by UCBVAX at 21-Jul-82 10:42:42-PDT (Wed)
Date: 21-Jul-82 10:42:57-PDT (Wed)
From: ARPAVAX:eric (Eric Allman)
Subject: Re: spaces in names
Via: ucbarpa.EtherNet (V3.146 [7/20/82]); 21-Jul-82 10:43:00-PDT (Wed)
Via: ucbvax.EtherNet (V3.145 [7/14/82]); 21-Jul-82 10:42:42-PDT (Wed)
Phone: (415) 548-3211
To: EAK@MIT-MC, mo@LBL-UNIX
Cc: HEADER-PEOPLE@MIT-MC

It seems amazing to me that everyone is arguing about the "right" way
to handle spaces in names -- somewhat like arguing the "right" way to
worship the diety of your choice.

"Obviously" spaces should be eliminated -- if you view spaces as being
part of an atom, then you get into the problem of leading spaces.  Not
to mention multiple spaces inside the name.  How about the person who
has the "user name" of space?  I can't wait for "   (Blankety B. Blank)
at MIT-Multics"!  [ed. note: is this two significant spaces followed by
an insignificant space before the left paren, or three significant spaces?]

Equally "obviously" a mailbox name should be a sequence of atoms,
coincidently separated by spaces in some circumstances (or multiple
spaces!), then the problem is "easy" -- or is the debate on how to write
a scanner for Pascal still raging?

But these are not the only issues.  I certainly agree that we should
be moving forward.  But blindly moving forward can be dangerous.  And
besides, what is forward?

For example, the Arpanet community is obviously moving away from NCP
toward TCP.  One approach would be to turn off NCP on January 1, 1988
and turn on TCP.  Using a hardline approach, one can conclude that it
would serve the *******'s right to get cut off if they were unable to
convert in time.  After all, why should they hold us back?  But in a
cooperating research community (we are cooperating, aren't we?) that
kind of approach is not feasible.  We all make compromises for the good
of the whole.  The transition plan is a pain, but it exemplifies the
cooperative attitude.

As for the issue of "what is forward," it seems clear to me [note my
explicit assumption here] that the direction is away from huge mainframes.
MIT and CMU may have PDP-10's, and Berkeley may have VAXes, but many
compromises have been made in the SMTP protocol to permit "fuzzball"
hosts.  Such hosts may be assumed to have limited memory (16 bits,
possibly even shared with the OS) and limited processing capability.
I grant you that parsing a series of atoms is not conceptually difficult,
but when you find yourself down to having 120 bytes to implement it in,
this can look like an impossible task.  In situations like this, it is
not improbable that spaces will be treated as significant characters,
rather than just as token separators.

To the extent possible, we build protocols and standards that scale up
and down conveniently.  Domains, for example, give a fuzzball the
opportunity to punt on everything -- just pass it to someone smarter.
This doesn't restrict what that smarter host can do -- it can try to
know the topology of the entire internet, if it wants.  But sometimes
absolute restrictions are necessary.  Unpleasant, perhaps, but still
necessary.  This may be one of those times.

I can certainly understand Earl Killian's position -- Mike looks pretty
silly, especially in the face of the multiple space example.  But Mike
is injecting a bit of reality into these discussions that cannot be
ignored -- given the opportunity, someone WILL have a mailbox name
consisting of only a space.  Or to put it another way, "if it was so,
it might be; and if it were so, it would be; but as it isn't, it
ain't.  That's [hacker] logic."

My intent here is not to come to any conclusions, but rather to present
the issues as I see them.  Maybe this will help the two factions talk a
little more and scream a little less.

eric

Date: 21 Jul 1982 1151-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: spaces in names				
To: Header-people at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 21-Jul-82 0655-PDT

Spaces could be permitted between tokens in a name, but could be
considered ignored if after a separator (or even just before it).  The
parsing could look for a real character then stop parsing when he got
an @, i.e.

To: Foo@FOOHOST, Jimmy Jones@BARHOST

It's pretty clear how to get Foo, you parse until the @, then you
gobble down FOOHOST until you see the ",". Whats next is a space,
throw it out. Then you see the J in Jimmy. Parse from there until you
get to the @, including the whitespace. Finally gobble down the
BARHOST until you see a newline character. This seems fairly simple,
and also has the benefit of a real world mapping. 

To: D. Johnson, F. Bakeley
Cc: All Staff
Subject: Travel Reimbursement 
.....

This would be a reasonable header for a non network memo, and would be
parsed similarly to the way I described above. 

The same could be said for whitespace which is located after the Jones
but before the @ but since we really seem to want right to left
parsing, I won't go into too much detail about it. Jon
Solomon@USC-ECLC is reasonable, even though Jon Solomon @USC-ECLC
would be better visually (I know, I can make my mailer visualize
it anyway I want).

I don't think this violates the transport protocol issues, while at
the same time allows the feature of a username containing spaces.
Which has the benefit of making computer mail in general more
acceptable to the world (i.e. not just the Arpanet or Internet
community). Down with usernames, up with Personal Names (am I dreaming
again?). 

Cheers,
--JSol
-------

Date:  21 July 1982 17:38 edt
From:  Palter at MIT-MULTICS (Gary M. Palter)
Subject:  Re: spaces in names
Sender:  Palter.Multics at MIT-MULTICS
To:  Header-People at MIT-MC
In-Reply-To:  Message of 21 July 1982 09:55 edt from Mike O'Dell [system]

The current draft standard does not allow:

    John\ Doe@MIT-Multics

as a valid address.  The left part of an address must consist of one or
more words separated by dots.  A word is either an atom or a quoted
string.  An atom can not contain space or any special characters.  The
backslash is a special character.  Thus, you have to say:

    "John Doe"@MIT-Multics

Note that you still have to understand whitespace in the local part of
an address.  The standard states that wherever a delimiter (and "." is a
delimiter in the local-part) may appear, it may be surrounded by
whitespace.  Thefore,

    John . Doe@MIT-Multics

is legal.  Its canonical form is John.Doe which is used mostly when
talking with systems which do not support this protocol.

So you must still allow whitespace in addresses.  However, the
whitespace is now always thrown away.

Date:  21 July 1982 17:51 edt
From:  Frankston.SoftArts at MIT-MULTICS
Subject:  Re: multics and case sensitivities
Sender:  COMSAT.SoftArts at MIT-MULTICS
Reply-To:  Frankston at MIT-MULTICS (Bob Frankston)
To:  cbosgd!mark at UCB-C70, header-people at MIT-MC
*from:  BOB (Bob Frankston)
Local:  cbosgd!mark@Berkeley (Mark Horton),header-people@mit-mc
Original-date:  21 JUL 1982 08:13:24

A Multics user can have a large number of names recognized but
is not forced to do so.

Date: 21 July 1982 19:10-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject:  spaces in names				
To: HEADER-PEOPLE at MIT-MC

How many people have noticed that the four TABs at the end of the
Subject: line in EAK's original message (and this one) has been
repropagated by each person replying to it, or that they were there in
the first place?  I doubt if it has any significance or if anybody
cares - just thought it interesting.  Earl: is this a test of some
sort?

--Frank

Date: 21 Jul 1982 17:01:14-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: Rudy.Nedved at CMU-10A
cc: HEADER-PEOPLE at MIT-MC
Subject: Re: spaces in names
In-reply-to: Your message of 21 Jul 1982 1007-PDT (Wednesday).
             <21Jul82 125634 EN0C@CMU-10A>

But how is my parser supposed to know that at site X blanks are
significant and that at site Y they are not?
	-Mike

Date:      21 Jul 82 16:14:53-PST (Wed)
From:      Stef.uci at UDel-Relay
To:        header-people at Mit-Mc
Subject:   Re:  case sensitivity
Via:  UCI; 21 Jul 82 20:05-EDT

			The Triumph of Technology!


			    Can Implies Shall!	


Or was it:		    cAN iMPLIES sHALL?


Or was it: 			    ...


Date: 21 Jul 1982 17:22:39-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: header-people at mit-mc
Subject: blanks

If we can all agree JSol's algorithm embodies what we mean,
the I, for one, am happy. (As if it matters much!)  

My concerns have centered around the need for a canonical form,
or at least canonical interpretation of address form.  JSol seems to be
implying a canonification scheme where "leading spaces" disappear
while embedded strings of spaces show up as at least one per string.
If you want more bizarre things, quote them.

I am repeating this to see if I understand the meaning of what
is proposed.  Is this right, or have I missed the boat again?
	-Mike


Date: 21 July 1982 2112-EDT
From: Rudy.Nedved at CMU-10A
To: mo at LBL-UNIX (Mike O'Dell [system])
Subject:  Re: spaces in names
CC: HEADER-PEOPLE at MIT-MC
In-Reply-To:  mo@LBL-UNIX's message of 21 Jul 82 19:01-EST
Message-Id: <21Jul82 211258 EN0C@CMU-10A>

Mike,

You must be talking about a bad parser again or the Unix shell?

Can I send mail to "Mike O'Dell"? You can send mail to "Rudy Nedved"
at any of CMU's TOPS-10 and UNIX sites. Can't you write a parser that
uses spaces and at-signs as delimiters instead of dots?

I thought the problem was dealing with ids that have leading or
trailing white space. (I can't believe someone would actually use
such a feature but who knows?) This business with dots is left over
from people unable to write parsers. Gee whiz a second year
undergraduate at CMU can write a parser to do RFC733 in PASCAL!

Why can't we look into the future and say UNIX and C is hot and that
people will implement good mail systems. I know CMU and Standford
will have such systems shortly (sooner the this spec gets released
the better).

Oh, I suppose you send mail to 'Dr\..Raj.Reddy" under your system?

-Rudy

Date: 21 Jul 1982 1856-PDT
Sender: CERF at USC-ISI
Subject:  Re: multics and case sensitivities
From: CERF at USC-ISI
To: Barry Margolin at MIT-MULTICS
Cc: header-people at MIT-MC
Message-ID: <[USC-ISI]21-Jul-82 18:56:12.CERF>
In-Reply-To: Your message of  20 July 1982 11:19 edt

Barry,

it must be frustrating to have had upper/lower distinctions so
long and to find that there is still a large community which
cannot manage them - however, I find myself occasionally using
terminal equipment which is still not upper/lower capable,
and I am pretty sure the military has a lot of that stuff still
around, so we have continued to fold up to upper case only to
accommodate this large installed base. There may be other reasons
as well, which others will be able to articulate, but this certainly
will continue to be aproblem.


Your solution would mke impossible the composition of messages
to Multics users from terminals not easily able to generate
lower case (or which do so very awkwardly, at least).

Vint Cerf

Date: 21 Jul 1982 19:13:07-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: Rudy.Nedved at CMU-10A
cc: HEADER-PEOPLE at MIT-MC
Subject: Re: spaces in names: laboring under bad assumptions
In-reply-to: Your message of 21 Jul 1982 1830-PDT (Wednesday).
             <21Jul82 211258 EN0C@CMU-10A>

No, I was not talking about the period business (I already defended
the position that blanks were good and period-mapping was evil),
nor the difficulty of writing a parser.  The sophomore will also admit
the hard part is the semantics, not the syntax.

However,
I think I finally understand: my august collegue Joe Sventek
was right in his comment; it doesn't matter!
Before you blast, let me explain!!!!

If we ignore where user aliasing is done for a moment, for a mail
router to do its job, it really only needs to look at the RIGHT hand
side of the address, ie, to the right of the at-sign.  If you  have a
mail router which queues messages to different output channels
for network mail-splicing (such as Delivermail, Sendmail, MMDF,
and others), they should be able to tell what to do from the 
right hand side.  If you decide a message needs "local delivery",
then and only then do you need to interpret the left hand side.
If the message isn't local delivery, just present the address
as you got it, cracking on commas.  Simple as "find the at-signs".

If the message IS local delivery, then you implement whatever 
policy about name mapping your local host wants to implement.
If you have white-pages service, wonderful.  If you insists mailbox
names be spelled backwards with opposite case, fine.  But the only
host this should bother is the one which will do "local delivery".
Noone else need see that part anywhere else.

This is complicated slightly if you are doing aliasing, but I don't
think it is much harder.  On our system at least, an alias, or sometimes
known as an "exploding" mailing list, looks like a local address
which is macro expanded lower.  The macro expansion text is arbitrary
addresses, so interpretation is an issue again only for local addresses.

Does this sound reasonable??  

	-Mike

Date: 21 July 1982 22:43-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  blanks
To: mo at LBL-UNIX
cc: HEADER-PEOPLE at MIT-MC

The first thing to recognize is that you can always used a quoted
string for weird things such as " Leading Space Willy".  I was
surprized that you can't use \ in atoms, as Palter points out,
but on close reading of the BNF I find that he's right.  As a
completely separate issue what do people think of changing the
syntax of atom to understand the quoted-pair convention?

My original suggestion is to have a simpler syntax for the common
case of addresses with blanks, not for the weird ones.

There are currently two suggestions on how to do this, if that
is what we decide to do.  One, which Jon Solomon recently
suggested is to have special parsing rules involving leading
spaces and embedded blanks.  The other, suggested by Eric Allman,
is to change the syntax from
	local-part = word *("." word)
to
	local-part = word *(["."] word)
which is how I had always assumed it would be done.  Thus an
address sent as
	John    Q.     Doe
is parsed as 4 tokens and the mailbox name used in SMTP is
constructed from these tokens by rules added to the rules that
already exist for multi-token local-parts (see section 6.2.4).
Presumably, it would come out as the string "John Q. Doe".

Date:  22 July 1982 11:30 edt
From:  Palter at MIT-MULTICS (Gary M. Palter)
Subject:  Re: blanks
Sender:  Palter.Multics at MIT-MULTICS
To:  Header-People at MIT-MC
In-Reply-To:  Message of 21 July 1982 23:05 edt from Earl A. Killian

If you make the definition of local-part be:

     local-part = word *(["."] word)

then, according to the treatment of whitespace in section 3.4.1, the
local-part:

     John   Q.   Public

would have a canonical representation of:

     John Q.Public

I think that we should simply eliminate any special treatment of periods
within local-part and make the definition be:

     local-part = 1*word

with the semantics that leading and trailing whitespace surrounding the
local part is thrown away and all whitespace within the local-part is
compressed to single spaces.

Date: 22 July 1982 1342-EDT (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
To: Header-People at mit-mc
Subject:  SPACES in names
Message-Id: <22Jul82 134218 RG02@CMU-10A>

It occurs to me that ALL communications require delimiters or counts
for variable length fields.  Why should mail be different?  Therefore,
given that this is just a TRANSPORT mechanism, and NOT a user
interface, why not require quoting of ALL names?  That simplifies
parsing considerably -- all user names will be of the form "..."@site.
Just look for the closing quote (skipping over \" if present) to find
the user name.  Of course, these quotes can be hidden from users by the
user interfaces in any manner appropriate to a given system.

		Rick

Date: 22 Jul 1982 1242-PDT
From: Craig Milo Rogers  <ROGERS at USC-ISIB>
Subject: Re: SPACES in names
To: Header-People at MIT-MC
In-Reply-To: <22Jul82 134218 RG02@CMU-10A>

	I second the motion to use quoted strings for <local-part> in
child-of-RFC733.  Similarly, <user> in the current SMTP draft RFC should
be restricted to a quoted string.  Functionality is neither added nor
lost (from the perspective of computer/computer interchange standards)
by imposing these restrictions.  The restricted forms carry the same
information as the previous form, and are simpler to implement.  Furthermore,
it would be clearer in the RFCs how "special situations" (such as spaces
within mailbox names) are handled (they turn out not to be special after
all).  Thus, the implementors might spend more time implementing, and
less time dabating.

	The hard problems have not been eliminated;  they've simply been
pushed into another room.  Mail composition programs will still have to
allow a user to send messages to peculiar mailbox names.  Mail reading
programs will still have to decide how to display mailbox names with
embedded terminal control sequences.  Mail gateways will still have to
transform mail between child-of-RFC733 and other standards in order
to reach certain recipients.  Certainly, people will have trouble
communicating with each other if their mail systems apply sufficiently
divergent transformations between the user representation and the
interchange forms of their mail, such that they can't exchange mailbox
names over the phone.  Restrictions upon the content of mailbox
names would greatly simplify these tasks.  However, such restrictions
can be adopted quite independently of novo-RFC733 and novo-SMTP.  After
all, what's another standard among friends?

					Craig Milo Rogers
-------

Date: 24 Jul 1982 0039-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:]
To: header-people at MIT-AI

I realize the the discussion of the need for a TO field may be passe
by now, but his looks like a classic example for consideration.  I
think it argues quite eloquently for a standard requirement for some
way to identify who might be the intended recipient.

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

Mail-from: ARPANET site BRL rcvd at 23-Jul-82 2035-PDT
Date: 22 Jul 1982 20:23:15-PDT
From: npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70
Via:  Mit-Mc; 23 Jul 82 16:19-EDT
Via:  Brl; 23 Jul 82 16:27-EDT
Via:  Brl-Bmd; 23 Jul 82 16:43-EDT

I'd like a copy of the results, please.     Lynda Feng

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

We are concerned with an interchange standard, indeed, but it is a
COMMUNICATIONS interchange standard.  By the definitions I know, if
there is no meaning transmitted, then there is also no communication,
though bandwidth may have been consumed.

I assume that we are concerned more with genuine communication than
with achieving consumption of bandwidth.  If my assumption is correct,
then we should be less interested in the narrow view that "there is no
technical need for a TO field," and more interested in the view that
"the recipient NEEDS to know to whom the recieved item was addressed."

I believe this is true even when the recipient is a process (agent)
rather than a person.  Indeed, at UCI we just ran into a serious
design problem with some BBoard software because we were trying to
sort mail into files based on the header information rather than the
envelop information.

This suggests two solutions: 

	1.  Require that the envlope's delivery address must be
included in th header fields.  [Addition to 733+]

	2.  Improve our User Agents and Delivery Agents to record what
was on the envelope.  There should be nothing in the standard that
requires that this information be discarded upon delivery!  [733+ as is!]

But, then there must be a requirement somewhere that this informtion
will be preserved till delivery time so the User Agent may decide the
disposition.  There is a suggetion in this that the recipient has some
rights in the data carried in (on) the envelope.

Rather interesting, I'd say ... Stef
-------

Date: 24 Jul 1982 0100-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Whom To?
To: header-people at MIT-AI

I realize the the discussion of the need for a TO field may be passe
by now, but his looks like a classic example for consideration.  I
think it argues quite eloquently for a standard requirement for some
way to identify who might be the intended recipient.

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

Mail-from: ARPANET site BRL rcvd at 23-Jul-82 2035-PDT
Date: 22 Jul 1982 20:23:15-PDT
From: npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70
Via:  Mit-Mc; 23 Jul 82 16:19-EDT
Via:  Brl; 23 Jul 82 16:27-EDT
Via:  Brl-Bmd; 23 Jul 82 16:43-EDT

I'd like a copy of the results, please.     Lynda Feng

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

We are concerned with an interchange standard, indeed, but it is a
COMMUNICATIONS interchange standard.  By the definitions I know, if
there is no meaning transmitted, then there is also no communication,
though bandwidth may have been consumed.

I assume that we are concerned more with genuine communication than
with achieving consumption of bandwidth.  If my assumption is correct,
then we should be less interested in the narrow view that "there is no
technical need for a TO field," and more interested in the view that
"the recipient NEEDS to know to whom the recieved item was addressed."

I believe this is true even when the recipient is a process (agent)
rather than a person.  Indeed, at UCI we just ran into a serious
design problem with some BBoard software because we were trying to
sort mail into files based on the header information rather than the
envelop information.

This suggests two solutions: 

	1.  Require that the envlope's delivery address must be
included in th header fields.  [Addition to 733+]

	2.  Improve our User Agents and Delivery Agents to record what
was on the envelope.  There should be nothing in the standard that
requires that this information be discarded upon delivery!  [733+ as is!]

But, then there must be a requirement somewhere that this informtion
will be preserved till delivery time so the User Agent may decide the
disposition.  There is a suggestion in this that the recipient has
some rights in the data carried in (on) the envelope.

Unfortunately, this is not simple, because aliasing systems can do
many-to-one mapping with distruction of envelope information, just as
occurs now with many group lists being delivered to one mailbox.  In
the narrow technical sense, I know that "it was TO the mailbox where I
found it!"  But, this is not what the recipient needs to know.


Hmm, I feel more like I do today than I ever have! ... Stef
-------

Date:     25 Jul 82 11:55:41-EDT (Sun)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Stef <ESTEFFERUD@Usc-Ecl>
cc:       header-people at Mit-Ai
Subject:  Re:  [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:]

For reference, the recent drafts of the standard have been
requiring at least one "standard" address field.  See the
<destination> rule, in the spec.

Dave



Date: Sunday, 25 Jul 1982 12:34-PDT
To: Stef <ESTEFFERUD at USC-ECL>
Cc: header-people at MIT-AI
Subject: Re: [npois!npoiv!harpo!ihps3!houxi!houxm!houxq!llf at Ucb-C70:]
In-reply-to: Your message of 24 Jul 1982 0039-PDT.
From: gaines at RAND-UNIX

There was an additional problem with the message from Feng: no
"subject" entry in the header.

The general problem is giving people enough information to deal well
with the messages they receive.  But I'm not sure the problem should
be dealt with at the level of standards for message headers.  In the
cases that have been discussed lately, almost all the examples of problems
have come from messages sent to broad lists of recipients.  I suggest that
the redistribution software for discussion groups, BBoards, etc., may
be the right place to impose additional standards, applicable only to their
needs.  For these lists, both some indication of who is message is being
sent to and what the subject of the message is should be required.  The
software that accepts and redistributes such messages could add a field
such as "To: info-cpm", and return a message without a subject field
to the sender.

Since there may be valid situations for sending a message without a
"to" or "subject" field, I would hesitate to require this in all messages.


Date: 25-Jul-82 18:27:39-EDT (Sun)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: to, subject, mailing lists
Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jul-82 18:27:40-EDT (Sun)
To: header-people@mit-mc.arpa

If you're going to differentiate between mass mailings and personal mail,
you might as well do it right and make them totally separate systems.
It is important that it be obvious not only to whom/what the message
was sent, what it is about, but also whether it is mail (e.g. addressed
to a person) or news (e.g. a mass mailing).  The easiest way to do this
is to have separate systems for mail and news.  (Tell me now, how many
of you really think it's a winning feature that all your mass mailing
lists get interspersed with your personal mail?)  If this isn't done,
there should at least be a header that indicates a mass mailing, so a
program can tell the difference without knowing the names of every list
in the world (and all the possible ways of spelling that list that will
work).  USENET has been running as a separate news system for years.
Having mail and news grouped separately goes a long way toward solving
the "Electronic Junk" problem in Denning's article.

	Mark

Date:  18 July 1982 22:13 edt
From:  Barry Margolin at MIT-MULTICS
Subject:  Re: quoting and non 1 case alpha names
Sender:  Margolin.Multics at MIT-MULTICS
To:  Stephen Tihor <TIHOR at NYU>
cc:  header-people at MIT-MC
In-Reply-To:  Message of 18 July 1982 20:14 edt from Stephen Tihor

The problem with mixed case on Multics has nothing to do with our mail
system.  It is in our usernames themselves.  It is quite conceivable
that there would be two users whose names differed only by case, i.e.
"VonFoo" and "vonFoo".  In this case the system distinguishes the users
by their names with respect to case - who should get the mail addressed
to "VONFOO@MIT-MULTICS"?
				barmar

Date: 26 July 1982 01:11-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: personal mail vs mass mailings
To: HEADER-PEOPLE at MIT-MC

    Date: 25-Jul-82 18:27:39-EDT (Sun)
    From: cbosgd!mark@Berkeley (Mark Horton)
    Subject: to, subject, mailing lists
    Via: cbosgd.uucp (V3.94 [3/6/82]); 25-Jul-82 18:27:40-EDT (Sun)
    To: header-people@mit-mc.arpa

    If you're going to differentiate between mass mailings and personal mail,
    you might as well do it right and make them totally separate systems.

Both the ITS and 20X mail systems provide complete flexibility to the recipient of
mail, such that personal mail and mailing-list mail can be delivered to the
same mailbox or to separate mailboxes, as the user prefers.  Different mailing
lists can be delivered to different mailboxes.  Many users have taken advantage
of this capability in the ITS mail system for at least 5 years.

If personal mail and mass mail were delivered by separate systems, it would not
be possible to have flexibility so that the individual recipient of the mail
could decide into how many and what categories his mail should be sorted by the
delivery system.

Anyway, this doesn't have anything to do with mail headers, nor with standards
for intercomputer communication.

Date: 25 Jul 1982 2249-PDT
From: Mark Crispin
Subject: case in names
Sender: ADMIN.MRC at SU-SCORE
To: Header-People at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     The problem with the "vonFoo" vs. "VonFoo" analogy is that the
use of case sensitivity doesn't help enough!  Most people would not
see the difference on first glance; neither would it stick in most
people's minds for long.  This is similar to what I like to call the
"Smith problem"; you want to send an urgent and confidential message
to Joe Smith at FOO-HOST.  The mailer at FOO-HOST recognizes a
mailbox named "Smith", but how do you the sender know that it is the
Smith you want?

     Many sites cop out by letting the first Smith on the system be
Smith, then adding JSmith, DSmith, JASmith, and ultimately JA2Smith!
Don't laugh, something like this really happened at a Stanford site.

     The problem with case sensitivity is that it could give a site
and its users a false sense of uniqueness while at the same time
causing needless inconvenience.  Suppose there is only one "vonFoo".
A case-sensitive mailer would reject VONFOO, VonFoo, Vonfoo, and
vonfoo even though it is obvious to anyone that the intended recepient
was vonFoo.  At the very least VONFOO and vonfoo should always be
recognized.  In the first case you help people on upper-case only
terminals; in the second you support the people who refuse to use
upper case under any circumstances (it is, remember, an accepted if
non-traditional writing style to use lower case exclusively).

     If there is a VonFoo and a vonFoo, it should be treated the same
as if there were two vonFoo's; "vonFoo" should be considered ambiguous
and more data be required.

     I'll confess that "more data be required" will make much more sense
when we have mailbox name servers.
-------

Date: 25 Jul 1982 2256-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: to, subject, mailing lists
To: header-people at MIT-AI
In-Reply-To: Your message of 25-Jul-82 1527-PDT

Hi Mark - Et al ... Regarding institutionalization of junk vs non-junk:

I generally find it awkward to have to use different tools to process
junk mail, which tends to be the result if they are really two
different systems.  I also see no problem with achieving separation
based on use of different addresses for different functions <Roles>.

For myself, I have several different mailboxes which represent my
different roles.  One, NMAX@ECL, is used for groups lists.  (I have
learned not to call it my "junk mailbox" after Jon Postel challenged
my request to have some of his TCP mail sent to NMAX if I was going to
consider it JUNK!)  One person's JUNK MAIL is another's GOLD!

I have another mailbox for my "corporate offices" where I accumulate
more or less official type stuff like invoices and contract messages.

The fact is that there is no rule about "One Person, One Mailbox."

I regard it as a rather adroit use of the mail system to automatically
get my mail sorted by using different mailboxes for different roles,
and in particular to get my "First Class Mail" directed to my primary
mailbox, and other mail directed to lower priority mailboxes.

I like to make a sharp distinction between urgent and important mail.
Important mail can generally wait a bit for processing, but urgent mail
should get through to get priority attention.

I am often surprised by how many netmail users have only one mailbox,
and then complain about having to sift the wheat from the chaff.  The
solution is quite obvious, and it does not require instiutional
separation of all mail into junk/non-junk classes.  I have already
achieved this kind of separation, according to my values, and not
deterimined by what someone else thinks is junk, or not junk.

So, to end this missive, I want to clearly state that I do not think
that the junk/non-junk mail issue belongs in a standards discussion,
and certainly does not belong in a standards document.  The means of
separation are inherent in the whole scheme of things, and nothing
special needs to be done.

Best - Stef
-------

Date: 26 July 1982 0447-EDT
From: Rudy.Nedved at CMU-10A
To: Header-People at MIT-MC
Subject:  spaces/dots in names
Message-Id: <26Jul82 044736 EN0C@CMU-10A>

It seems no one is talking about spaces and periods in names anymore. Does
this mean the specification is as Gary Palter put it:

		local-part = 1*word

meaning names like

		Rudy Nedved@CMU-10A
		"Dr. Raj Reddy"@CMU-10B

work? Or did the RFC decision makers decide otherwise?

-Rudy

Date:     26 Jul 82 6:50:24-EDT (Mon)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Rudy.Nedved at Cmu-10a
cc:       Header-People at Mit-Mc
Subject:  Re:  spaces/dots in names

The new syntax will permit/require:

	"Dr. Raj Reddy"@CMU-10A

and

	Raj.Reddy@CMU-10A

but will not permit:

	Raj Reddy@CMU-10A.

Dave


Date: 26-Jul-82 10:55:33-EDT (Mon)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: to, subject, mailing lists
Via: cbosgd.uucp (V3.94 [3/6/82]); 26-Jul-82 10:55:34-EDT (Mon)
To: header-people@mit-mc.arpa

Now hold on, I never said that different tools had to be used.  All I said
was that there be separate systems.  Perhaps I should have said two
"channels".  There is a movement now to allow the same tools to be used
to read news and mail.  (Right now, the mail tools work with news, but
not all that well.)  However, when you think about it, there really are
some things you want to do differently with news.

At the transmission level, you don't want to send 50 copies of the same
message over one link.  You really want to pass one copy over each link
and let the system on the other end of the link pass it on to its
neighbors.  Also, you don't want to store a separate copy of each message
for each user who subscribes to it - that wastes disk space.  You just
want to store one copy on the system, and give each user some kind of
record of what s/he has already seen.  (This is the fundamental reason
for having separate tools in the first place.  A better solution might
involve "read-only" mailboxes, something I think the Rand MH system has.)
You also want some high level controls of which permit a system to decide
which newsgroups (mailing lists in the arpanet jargon) to accept and which
to forward on to each of its neighbors.

At the user interface level, you find things are similar to, but not quite
the same as, mail.  Posting does not have to go through a mailing list
bottleneck, so news goes out faster, in spite of the 1200 baud dialup
links used on much of USENET.  (It can be argued that the bottleneck has
advantages, such as the ability to insert a moderator.)  You don't have
to (a) hear from the grapevine that a new list exists, (b) figure out
who to ask to put you on the list, (c) wait for this person to add you
to the mailing list, (d) miss out on all the "back-issues" that came out
before you joined; many people on USENET just get "everything except for
certain things they unsubscribe to" and automatically see new stuff.
When replying, there are two common things to do.  (1) send a reply back
to the sender only, (2) post a followup to the entire list.  Mail systems
don't necessarily do either of these well, although most do (1) I don't
know of one that has a command to do (2) without sending two copies to
the original sender and messing up the header enough to cascade the effect.
Also, mass mailings have the property that much is uninteresting, so the
user wants to be able to look at the subject and decide not to bother to
look at it.  (Some mail software can do this decently but most require you
to start reading it and then hit interrupt.)  Finally, there is the issue
of the order you read things in: it's silly to first see "I have a program
that does 'x' if anyone's interested" then "814-555-1234" then "does anyone
have a recipe for cheesecake?" then "what's the phone number for decvax?".
It's important for news to be sorted into a reasonable order - something
that even a separate "mass-mailing" mailbox for each user isn't going to do.

It isn't all that easy for a random person to have several mailboxes.
A typical system will require creating separate logins for each mailbox
(although some won't insist on this) and many administratively won't
let you have more than one login and/or more than one mailbox.  Some
people won't/can't pay for more than one.  To site a couple arcane
examples, Comp Center A uses a person's department number and initials
as their login, e.g. 51423jmc, and forces them to receive mail as such.
Comp Center B lets people choose their login name, but in order to
implement load leveling, moves them around from one filesystem to another
or even from one machine to another, without warning, and makes no
effort to make this transparent.

	Mark

Date:  26 July 1982 11:27 edt
From:  Palter at MIT-MULTICS (Gary M. Palter)
Subject:  Re:  spaces/dots in names
Sender:  Palter.Multics at MIT-MULTICS
To:  Header-People at MIT-MC
In-Reply-To:  Message of 26 July 1982 10:02 edt from Dave Crocker

Someone recently suggested that since we are defining an interchange
standard, we should change the definition of the local-part of an
address to quoted-string.  Additionally, SMTP commands would be changed
to accept only quoted-strings.

I would like to second this suggestion.

Date: 26 July 1982 18:58-EDT
From: Gail Zacharias <GZ at MIT-MC>
Subject:  to, subject, mailing lists
To: cbosgd!mark at UCB-C70
cc: HEADER-PEOPLE at MIT-MC

As I understand it, the distinction you make between mail and "news" is that
the recipients of "news" are unspecified, to-whom-it-may-concern.  (This is not
the same as mailing lists on the arpanet btw).  Basically, you have a mailbox
which is not read-protected, so anybody can peruse the incoming mail.
  I don't see how this has anything to do with the other things you mentioned.
In terms of efficiency, if I send a message to 50 specifically listed
recipients, the mailer should only transfer one copy per site, and there is
some advantage to only storing one copy at the receiving site until the
recipients attempt to read their mail, etc.  In terms of convenience, all the
tools you mentioned for managing mail ("back-issues", i.e. archives, sufficient
flexibility in generation of reply headers, ability to survey just the subjects
of incoming mail, ordering your mail by topic) are applicable to personal mail.
I have most of them in my mail reader and use them all the time.  I'd certainly
hate to have them restricted to just publicly accessible mail.  The only
special thing that news needs is a database of per-user last-read dates; after
that, your regular mail reader should be able to handle all your needs in
reading the stuff.

Date: 27 July 1982 02:33-EDT
From: V. Ellen Golden <ELLEN at MIT-MC>
Subject:  remailed for Stef...
To: HEADER-PEOPLE at MIT-MC

From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: to, subject, mailing lists
To: header-people at MIT-AI
In-Reply-To: Your message of 25-Jul-82 1527-PDT

Hi Mark - Et al ... Regarding institutionalization of junk vs non-junk:

I generally find it awkward to have to use different tools to process
junk mail, which tends to be the result if they are really two
different systems.  I also see no problem with achieving separation
based on use of different addresses for different functions <Roles>.

For myself, I have several different mailboxes which represent my
different roles.  One, NMAX@ECL, is used for groups lists.  (I have
learned not to call it my "junk mailbox" after Jon Postel challenged
my request to have some of his TCP mail sent to NMAX if I was going to
consider it JUNK!)  One person's JUNK MAIL is another's GOLD!

I have another mailbox for my "corporate offices" where I accumulate
more or less official type stuff like invoices and contract messages.

The fact is that there is no rule about "One Person, One Mailbox."

I regard it as a rather adroit use of the mail system to automatically
get my mail sorted by using different mailboxes for different roles,
and in particular to get my "First Class Mail" directed to my primary
mailbox, and other mail directed to lower priority mailboxes.

I like to make a sharp distinction between urgent and important mail.
Important mail can generally wait a bit for processing, but urgent mail
should get through to get priority attention.

I am often surprised by how many netmail users have only one mailbox,
and then complain about having to sift the wheat from the chaff.  The
solution is quite obvious, and it does not require instiutional
separation of all mail into junk/non-junk classes.  I have already
achieved this kind of separation, according to my values, and not
deterimined by what someone else thinks is junk, or not junk.

So, to end this missive, I want to clearly state that I do not think
that the junk/non-junk mail issue belongs in a standards discussion,
and certainly does not belong in a standards document.  The means of
separation are inherent in the whole scheme of things, and nothing
special needs to be done.

Best - Stef
-------

Date:     26 Jul 82 15:14:53 EDT  (Mon)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  mailing lists
To:       header-people at unc
Via:  UNC; 26 Jul 82 19:27-EDT

I don't agree that multiple user-ids or mailbox names is an adequate
substitute for a news or bulletin board system.  Consider:  at the
moment there are 142 USENET 'newsgroups' active on this machine.  About
20 of them are copies of assorted ARPA mailings lists.  There's no way
our system administrator is going to maintain 142 -- or 20, or possibly
even 2 or 3 -- different mailbox names for every user.  Not that using
two different mailboxes is a solution -- it makes it harder for to keep
different lists grouped together -- but maybe I've been spoiled by the
USENET system.  (What I'd really like is a way to group *conversations*,
so I could barely skim all the messages related to, say, spaces in
user-names, but my proposal to make Message-Id mandatory doesn't seem to
have gathered any support.)

What we should be talking about here, though, is what set of facilities
should be defined by the standard that would allow a user's mail-reader
to classify letters.  It doesn't do me any good if USC-ECLB adds a
'Class: junk' line if BRL uses 'Distribution: list' while MIT prefers
'Group: SF-LOVERS'.  I suppose I could always rewrite our mail system to
accept addresses like 'smb/header-people@unc', but that's almost a
cop-out.  Perhaps we should adopt the 'Priority' and 'Class' fields from
the NBS standard.  I'm not suggesting they be made mandatory, just that
we agree on the syntax and semantics of such lines so that folks who
want them can use them.

		--Steve


Date:      26 Jul 82 22:03:48-PST (Mon)
From:      Stef.uci at UDel-Relay
To:        header-people at Mit-Ai
Subject:   Re: separate systems for news and mail
Via:  UCI; 27 Jul 82 5:09-EDT

Hi Mark - et al - Again on the "separate systems for news" question

There is nothing in your long list of difficulties and advantages that
requires, or really even suggests, that a separate system is needed.

But, I will agree that news nets that use the same mail servers as
first class mail uses, should indeed use different procedures for
efficiency, et al.

However, I still see nothing to suggest that this issue has any
relationship to our standards discussion.  There is nothing needed in
733+ to resolve any problems or to help implement the good things you
want to promote.

What I want to press for, is that we should not have separate mail
servers for "news" and "mail" and that we should not have separate User
Agents for handling "news" and "mail."

As for systems where administrators only allow one login per user, I
feel sorry for anyone who is subjected to such dumb administrative
behavior.  Clearly such rules are arbitrary and not technically
required, and therefore, I hope we will not try to remedy such bad
adiministration with glitches in 733+.

Best - Stef



Date: 27 Jul 1982 08:52:59-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: Stef.uci at UDel-Relay
cc: header-people at Mit-Ai
Subject: Re: separate systems for news and mail
In-reply-to: Your message of 27 Jul 1982 0628-PDT (Tuesday).

The REAL problem mentioned in the USENET comments is the need for
a SYSTEM ADMINISTRATOR to create mailboxes.  If there were some way
for a person who is authorized to have an <X>net mailbox to 
create additional mailboxes, the administrator wouldn't have to
get involved.  (I understand the serious implications of this
for a student timesharing system, but since I don't have to deal
with that anymore, I can choose to ignore it.)

	-Mike



Date: 27 Jul 1982 1024-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: mailing lists
To: smb.unc at UDEL-RELAY
cc: header-people at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 26-Jul-82 1514-PDT


People have been known to have 2 or 3 mailboxes, one for All junk mail,
one for all private mail, and one for all random mail (i.e. beyond control
of the person involved).

For example, JSOL@USC-ECLC *could* be a random mail repository, 
JSOL-JUNK@USC-ECLC could be my mailing list repository (except
for those "important messages" which deserve higher status than
JUNK, heh heh); and JON.SOLOMON@USC-ECLC could be my private
mailbox. These names were arbitrary; and in fact do not exist,
but they illustrate the point Stef was saying.

I feel that it is probably again something reasonable to allow
mailers to mail to arbitrary files (given certain conditions,
like either the file is write enabled to the world, or is 
in a magic file maintained by the administrator for security
reasons), but at the same time, voluntary classification of
mail is another reasonable way to do the same thing.

I don't think everyone would voluntarily classify junk
mail as junk.

Cheers,
--JSol
-------

Date:     27 Jul 82 22:57:03 EDT  (Tue)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re: mailing lists
To:       Gail Zacharias <GZ@Mit-Mc>, Jon Solomon <JSol@Usc-Eclc>
Cc:       cbosgd!mark at Ucb-C70, header-people at Mit-Mc
Via:  UNC; 27 Jul 82 23:05-EDT

I think you're missing the point Mark and I are making.  It's not that
a mail-reader can't be used to read 'news' items; of course it can.
In fact, I much prefer the interface my mail reader has to the one provided
by 'netnews', and often use it to read news articles.  The point is that
there are inherent conceptual differences between mail to you as a person,
and mail to you as a member of a large anonymous group.  A good analogy
is the difference between making a phone call (even a conference call),
vs. making a radio broadcast.  (Most participants in this discussion do
seem to feel that there is such a distinction; almost every reply has
gone to a specific individual as well as to the group.  Why does everyone
(including me) do this, considering that it generally means that the
lucky person mentioned by name gets to see it twice?)  Mark and I are
asking for two things:  a method of labelling broadcasts as such, and
a method of distinguishing one station from another.  (Most of the flaming
about the lack of 'To' and 'Subject' fields really boiled down to this
issue:  letters were ending up in your mailbox, and you didn't know why.)

I don't regard multiple mailboxes as a general solution, either.  TO
be sure, it's not hard to design a mailer that lets each user create
an indefinite number of mailboxes.  But that forces each user to know
how to do that.  A header line would allow the mail system to handle it.
It also allows specialized administrative treatment of news items --
storing only one copy (a much different proposition than *receiving*
only one copy), deletion after a few weeks (which you can't do to personal
mail -- and given that we receive over 150 Usenent items a day, we can't
let them build up indefinitely), etc.


Date: 27 Jul 1982 2100-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re: mailing lists
To: Header-People at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 27-Jul-82 2257-PDT

    Most participants in this discussion do seem to feel that
    there is such a distinction; almost every reply has gone to
    a specific individual as well as to the group. Why does
    everyone (including me) do this, considering that it
    generally means that the lucky person mentioned by name gets
    to see it twice?

I don't know about everybody, but I do this out of laziness, since my
mailer defaults to REPLY-TO-ALL mode. ALL means you and of course the
list since my mailer on ECLC can't figure out that you on UCB-C70 are
on a mailing list on MIT-MC.  SMTP is *supposed* to deal with this by
allowing us to expand mailing lists and resolve duplicates, but its
effectiveness remains to be seen (my opinion). There, just to
demonstrate that I *can* be less lazy about replies this one is going
just to the list. I am assuming that all the recipients are on the
list (in the real world this is probably a bad assumption).

Back to RTFC733', If we say that some header line will contain the
address which the mail was sent to, that will only help you figure out
a message whose meaning is lost in the multitudes IF the message was
sent to a mailing list.

If the message was sent directly to you using no list, yet you still
can't figure out why you got it, and posting this information won't
be of help.

Let's say we require a SUBJECT: line, and perhaps a TO line. Note that
the TO line will not help you if you are on the CC list, even the
majority of mail systems which do give you the CC field don't give you
the BCC field which can also get you upset. 


Which leads back to the original question; What sort of information
should be required in a mail message? I claim that none of the schemes
we have yet to come up with solve the WHOLE picture, or answer the
question "Why did I get this" all of the time.  Sooner or later you
are going to have to either ignore the random trash or ask the person
who sent it to you what it was for.

I am willing to bet that if enough people sent "why did I get this"
messages back to the originator of an obviously vague message that
the person will be more specific about his problems the next time he
asks!

Cheers!  --JSol
-------

Date: 27-Jul-82 23:37:36-EDT (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: news vs mail
Via: cbosgd.uucp (V3.94 [3/6/82]); 27-Jul-82 23:37:38-EDT (Tue)
To: header-people@mit-mc.arpa

GZ hits the nail on the head - while there will always be a need for
mailing lists (small groups of people that all know one another) the
mass-mailings of the human-nets/tcp genre all have the property that
nobody has any idea who is on the list, because the lists are so huge.
I also never called them "junk" - my experience is that there IS a lot
of junk out there, but any given person considers about 50% (give or
take some percentage) of the lists to be "junk" and the other 50% to be
"work related", and every person draws the line differently.  The point
is that you treat a newletter from the auto club differently than a
letter from your sister - personal mail is almost always of high enough
priority to be checked for every (say) 10 minutes, but you don't want
to read mass mail more often than (say) once a day.  The creation of
multiple mailboxes per person is also not a simple technical issue -
you have to deal with permissions, forgeries, accounting, and the time
drain on the administrator to create them.  I also admire your claim
that you have mail software that will sort your mail into discussion
order - I have never seen such a mail system, nor an algorithm for
determining what to sort by, and don't believe that such a system will
be widely available on the average machine in the near future, UNLESS
we standardize the headers enough to be able to reliably determine
what's going on!  THIS is the whole point.

In USENET, we deliberately use RFC 733 headers in the hope of using
mail tools on news.  (I firmly believe that one tool should eventually
be able to handle both, at least for a user interface.  But not without
extending the mail system!)  However, it has become necessary to use
some headers that are not in RFC 733.  If arpanet mass mailing lists
could be persuaded to use these (or functionally equivalent) headers,
we could get somewhere.

USENET messages have an Article-I.D.: header (Message-ID: could be used
just as well).  This string is SHORT and consists of a unique string
that identifies the message.  (USENET currently uses host.num, e.g.
cbosgd.123 for the 123'ed message generated on site cbosgd.) It is a
legal file name on UNIX systems, and that property has proved
valuable.  While I can't see preserving this property across ITS and
VMS and TOPS 10 file systems, I feel that Message-ID should be made (1)
mandatory for mass mailings, and (2) short - say limited to 32 printing
characters.  This makes it a manageable key for a person to ask for a
message by ID.  (The USENET article ID is essential to prevent loops
from infinitely propagating articles - we long ago found out that sites
go down, so we have at least two paths to each major node, and send
news along all paths.  Arpanet mailing lists seem to be tree
structured, and if one site goes down, too bad.)

Newsgroups: makes it possible to unambiguously determine (1) that it's
a "mass mailing" (news) message, and (2) which newsgroup it belongs
to.  We have a standard list on USENET, or a standard ARPANET spelling
could be agreed on.  But having to pick through the TO list and
recognize somebody's local alias for human-nets is beyond the
capabilities of any mail system I've seen.  Sample USENET newsgroup
names are net.unix-wizards (the list is properly gatewayed into USENET
at SRI), btl.general (general items only distributed to Bell Labs), and
fa.human-nets (plain old mailing lists are fed into read-only fa "from
arpa" newsgroups).

References: lists the Article-ID of the item being replied to.  Without
this, there is no way to sort by discussion.  (In-reply-to is not the
same thing, both because there is no fixed format, and because if A
replies to B's reply to C, A's References line should reference C's
note, not B's.)  Sorting by Subject won't do it, because people retype
their own subjects all the time.  The mail software should ENCOURAGE
people to use built-in reply/followup commands, rather than compose a
message from scratch.

So, to boil this down, in order to properly support mass mailings, I
propose addition of Newgroups, References, and either Article-ID or
Message-ID, headers to all mass mailings.

	Mark

Date: 28 July 1982 0345-EDT
From: Rudy.Nedved at CMU-10A
To: Header-People at MIT-MC
Subject:  mucho mail and distribution
Message-Id: <28Jul82 034509 EN0C@CMU-10A>

The comment about loops and duplicates hit a nerve.

Some important events to remeber:

There was a "chain letter" a while back on the "network" which
    propagated thru the ARPANET, around UUCP (I heard rumors about
    it), up thru the tangled world of DEC coporate DECNet and local
    MIT, Standford, Berkley and CMU networks.  It took up a large
    amount of "resources" in terms of cpu time, disk space and ftp
    resources.

An extension of the above indicident was someone created a mailing
    list at MIT with all of CMU-10A's users and sent the "letter" to
    it....luckily a local mail wizard shot it down but not before it
    had cdr down half the list.

CMU recently fixed a design flaw in one system and found another
    system punted the mail transfer after the mail was sent but
    before the mail was dequeued.....the failure is message length
    and system load dependent so a noticeable increase in duplicates
    occured during the day.

There was the incident of the SU-ISL mailer cutting loose and
    spraying several mailing lists with mail from "greep@RAND...".

I would like to see some mechanism by which a "fair share" of the
mail relaying and acceptance gets done for each host (assuming the
future has one host per person), a way of reducing duplicates (maybe
an out-of-band message-id) at the end-site and a way of detecting
mail system loops (yes, I know I can always look at my "/usr full,
pausing" unix messages or my "quota or disk space exceeded" tops-10
messages).

I think the "<host name>.<message number>" id is good but not solid
(host names have dots and maybe numbers). Given that SMTP and MTP
currently support the "HELO" host identification, the host name
business is redudant but where does one place the out-of-band message
number? How many times does the number get incremented before an
upper bound is exceeded -- maybe it should be a timestamp instead?
Maybe the <host.id> should only be in the envelope, maybe in both
and maybe only in the out-of-band information?

I must admit my experience with "news" and "bboard" systems is not as
extensive as the uucp people.

My apology for the length of the message.
-Rudy

Date:      28 Jul 82 0:29:50-PST (Wed)
From:      Stef.uci at UDel-Relay
To:        header-people at Mit-Mc
Subject:   Re:  separate systems for news and mail
Via:  UCI; 28 Jul 82 5:00-EDT

Again, the fact that inadequate systems designs force administrators to
manually create mailboxes, with all the bureaucratic drag that this entails,
does not justify separate systems for news and mail.

There is no way I can imagine that we can protect the world from bad 
administration, no matter how good or bad our systems.  So lets not allow
such considerations to warp our mail service designs.

BTW, I am really a mangement consultant, not a hacker.  Cheers - Stef


Date: 28 Jul 1982 0937-PDT
From: Jon Solomon <JSol at USC-ECLC>
Subject: Re:  separate systems for news and mail
To: Header-PEOPLE at MIT-MC
Address: 2817 Orchard Ave., Los Angeles, CA. 90007
Phone: (213) 732-3423
In-Reply-To: Your message of 28-Jul-82 0129-PDT


What I would like to see is a design for a foolproof way for mail
processing to insure that you don't need to ask "Why did I get this
message" or worse "Why did I get this message TWICE (or three times or
...)". As long as my mail reader can filter out the Message-ID field,
I don't mind using that as a starting point. Message-ID:
Asciz-string.number is fine but number.asciz-string is better since
most mail systems will be more interested in the number; and if the
asciz-string is mapped to a host name, it too may contain a dot.

So far nobody has really come up with this. RFC733 does state that you
(Mark) can put anything you wish in the headers, as long as it is
one-word: line-of-text<crlf> (you can of course continue it). My point
is, if we are going to suggest a \mandatory/ header for mail, it
should address the real questions, rather than some subset of them.
It's not all that clear that Message-ID will help in all cases, but it
might be a start.

Cheers,
--JSol
-------

Date: 28-Jul-82 12:39:29-EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: message ids
Via: cbosgd.uucp (V3.94 [3/6/82]); 28-Jul-82 12:39:31-EDT (Wed)
To: header-people@mit-mc.arpa

The important thing about a message ID is that is must be unique
across the world.  To avoid having to get a unique number from one
central server (remember, in the phone dialup world, this may be
impossible, and at best will take at least a minute of real time
to place a phone call) USENET includes the host name - then the
rest only has to be unique for that host.  There is no upper bound
on the number in <host>.<number>, and in practice our numbers don't
grow so fast as to be a problem (we're up to 2466 after one year on
cbosgd), although that's just news, not mail.  I could see 5 or 6
digits if mail was included for a heavily used system, and there's
no reason a host couldn't reset its number every year.

The problem with a timestamp is that it's long and hard to type,
and has lots of special characters in it.

There is no ambiguity with <host>.<number>, since even if the host
has dots and numbers in its name, you just scan from the right for
a dot.  However, this scheme was chosen for convenience, not for
universal suitability, and some other scheme could just as easily
be used.  What really matters is that it be a short, unique string.

I think what Rudy Nedved is suggesting is that it may be worthwhile
to make message-ID's mandatory for all mail.  I have to admit that
it would make catching runaway mail programs a bunch easier.

	Mark

Date:     28 Jul 82 12:34:52 EDT  (Wed)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  YAHF (yet another header field)?
To:       header-people at unc
Via:  UNC; 28 Jul 82 19:34-EDT

Here's a thought tangentially related to the mail-list discussion.
At some point, some day, some folks may be asked to pay (shudder)
real money for their mail traffic.  In point of fact, CSnet is already
planning for it.  Who should pay for TCP-IP Digest?  SF-LOVERS?  A site
may be willing to donate disk space, cycles, and net bandwidth, but draw
the line at dollars.  It would seem that another distinction between
personal mail and list-mail is that the latter is sent primarily for the
benefit of the recipient; the former tends to benefit the sender.  We
may need collect letters!

To be sure, that issue fits in the SMTP protocol.  But SMTP needs to get
the information from someplace else -- the header.  (I see this extending
beyond mailing lists, of course.  If someone asks me for the source of
some program of mine, I'll be much more likely to send it if my site
doesn't have to foot the bill.)

I don't have a good syntax on tap; the best I can come up with is

	Postage: #address | "collect" | "sender"

But that requires reserved words in a position syntactically reserved
for addresses.

Comments?


Date: 28 Jul 1982 21:03:43-PDT
From: lblg!j#j at LBL-UNIX
Subject:  Extra header fields for a variety of uses
To: smb.unc at udel-relay, header-people at mit-mc

Steve,

     I think that it is very important that any information that might
affect delivery, accounting, ... must be transmitted out-of-band from
the text of the message, which includes the message header.  One of the
things that should be possible in any mail system is that the sender
and receiver be able to end-to-end encrypt the message, if an extra
level of security is desired.  If the header cannot be encrypted due
to its importance in routing and delivery, then this option is not
available.  Unfortunately, some of the information in the header may
be sensitive, as was pointed out in one of the early notes in this
discussion by one of the individuals at PARC-MAXC.

    This naturally leads into the discussion of mail delivery systems which
choose to mung message headers to facilitate replies to all recipients of
a message.  I believe quite strongly that NO modifications to the headers
should occur, and that all necessary information needed to facilitate
higher level functions must be carried in the envelope information
accompanying the message.  This is not dissimilar from the options fields
which are required to precede the message in the NBS standard, where the
message (including the header lines) is considered free text, and may be
encrypted, include binary data and be affected by a variety of value-added
features.

     Without a fairly wholesale overhaul, SMTP and RFC733+ do not have
sufficient horsepower built in to be able to handle many of these concerns.
I have not seen the multi-media RFC by Jon Postel to know whether it will
handle all of these necessary features for mail systems in the 80's.
My understanding of the NBS proposals is that many of the more difficult
problems are approached, especially non-textual data, data security via
encryption options, accounting considerations, etc.  This is not necessarily
a plug for those proposals; I am simply saying that others have considered
these problems in a different environment, and that many of these considerations
may best be left until we tackle the multi-media problems, since that
extension will wreak so much havoc that fixing a few more of the current
problems will be easier at that time.

    As a final plug for the abolition of header-munging delivery software,
might I suggest the following solution for the reply-to-all-recipients
problem.  SMTP requires that the "Return-Path:" field from the message
envelope be placed in the message when delivered to a recipient.  Since
all addresses formatted into the message header were relative to the
sender, it seems totally reasonable to send replies along the route
specified in the return-path to the senders machine, which will then
know how to get the message to the address specified in the original
message header.  Although this is not necessarily optimal (more on that
below), it is certainly a workable solution 90% of the time, with the
failures occurring if the connectivity of the net is not constant.

    Playing the devil's advocate, let's assume that the forwarding
delivery software modifies the headers of each message that it handles.
Unless the software includes a lot more AI than any that I have seen,
the typical modifications will be to simply add it's host name to
the end of the domain name as follows

user@host.domain  ==>  user@host.domain.routing_host_name

By so doing (which is equivalent to adding it's host name to the
beginning of the return-path), it is assuming that the
domain1.domain2...domainN structure is a right-to-left route
(which is not an interpretation which is favored by many of the
participants in the SMTP discussions), and gives no more information
than the scheme I suggested above, since any reply will follow
the reverse path of the original message.

   As a final comment in this long-winded diatribe, I would like to
suggest an addition to the SMTP spec which would permit the addition of
value added fields which could accompany the message in the "envelope".
Why not add an ENVL command, which has the same control syntax as the
DATA command (i.e. must be terminated by a .<CRLF> and must employ the
period stuffing protocol at the beginning of lines for transparency).
All additional "header" lines which could impact delivery, accounting, ...
could be stored here, as well as the "Mail-From:" or "Received" timestamps
required by SMTP and RFC733+, respectively.  Then the delivery system
which actually delivers the message to the user's mailbox can exercise
control over display and placement of this additional information in the
message header.  Some systems may wish to make the information available
as associated data with the message, not necessarily including it in the
message itself.

'Nuff said.

Joe Sventek

Date:  29 July 1982 10:55 edt
From:  Charles Hornig at MIT-MULTICS
Subject:  Re: quoting and non 1 case alpha names
Sender:  Hornig.Multics at MIT-MULTICS
To:  header-people at MIT-MC
In-Reply-To:  Message of 18 July 1982 22:13 edt from Barry Margolin

A more interesting example of conflicting usernames would be that of
"TSong" and "Tsong".

Date: 29 Jul 1982 1629-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: quoting and non 1 case alpha names
To: Header-People at MIT-MC

I boil down the top level issues of case folding for mail box names to
the following:

If you want to receive mail in the current environment, where in fact
some systems make it entirely impossible to either display multicase
addresses in multicase <e.g., UPPER ONLY TTY33 or TI700 or ...>, or to
type MultiCase from the keyboard <without using The Rosemary Woods
Technique>, then ...

	You should arrange for your mail delivery service to fold case
	to unicase for your incoming mail.

If, on the other hand you don't want to receive mail from such
handicapped senders, and if you don't mind failure to get mail from
senders who are careless, or otherwise fail to send the address in
precisely the correct case, then ...

	You should arrange for tricky casing requirements.

As I see it, it is up to the receivers to decide these things for
themselves.  If your system administrators, or your system's
implementation will not let you have these choices, then you should
seek a new site on which to establish your mailbox.  If you cannot
change sites, then you better learn to live with what you have, or
lead a revolution.

For myself, I have a great deal of difficulty understanding why anyone
would want to have a tricky case requirement on their address.  My
objective to to comunicate via mail.  Any impediments to communication
are regarded thus to be candidates for removal.

I had a Multics mailbox once, and I demanded that it be set to fold
case, or at least behave as though it folded case.  Had this not been
arranged, I would have simply not used it, ever.

But, to each his own.  I have no objections to some people being silly.

As I have said before:  "Can Implies Shall" is the Triumph of Technology.

I would prefer to think that I am master of my mail domain.  Best - Stef
-------

Date:      29 Jul 82 20:24:01-PST (Thu)
From:      Stef.uci at UDel-Relay
To:        header-people at Mit-Mc
Subject:   Re:  message ids
Via:  UCI; 30 Jul 82 1:55-EDT

If it is genuine unicity that you want, with no troublesme characters,
then how about a <date-time-based-number>.<host-name>.<sender>.

Or some concatenation like that which is a unique but simple number,
followed by site based text and originator text.  I would suggest that
the date-time basis be Greenwich Mean Time, and organized so it will
sort correctly by time with no transformations.  It should carry lower
order time digits to the degree needed to assure unicity for each given
originator of mail.

This suggests that a standard algorithm be established <ala 733+?>.

This could avoid all problems with unpleasant characters by not
allowing them in the standard.  Such a well defined string would also
prove useful for other purposes, though these should not be a factor in
deciding on such a scheme.  It should certainly make for easy
identification of duplicates, etc.

In any case, I see no reason for the ID field standard to allow
unpleasnt characters, or complex construction rules, or nebulous
meaning. 

Best - Stef


Date: 29-Jul-82 16:28:41-EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: news vs mail
Via: cbosgd.uucp (V3.94 [3/6/82]); 29-Jul-82 16:28:43-EDT (Thu)
To: header-people@mit-mc.arpa

Nobody is saying that there aren't lots of similarities between news
and mail.  But they are different, by definition.  A newsgroup is
distinguished from a mailing list by appointment: mailing list x has
gotten to the point where it costs too much to distribute it as a
mailing list, so we make it a newsgroup.

The ARPANET has been spoiled for a long time by having free, high
bandwidth links between the hosts.  This is wonderful, but it's
only available to a select group of DOD contractors.  Those of us
that have to use 1200 baud (or even [gasp] 300 baud) dialup links
to exchange mail and news have to look at the costs.  The whole
point of the new mail standard is to be universal, not only applying
to the arpanet and local ethernets, but also to nets they talk to,
such as CSNET and UUCP (both of which depend heavily on dialups.)

The fact is that distributing high volume mass mailings costs a lot.
Every copy that is sent out takes CPU cycles.  Every copy that is
stored on disk takes up space on a drive that is probably already
nearly full.  (If you have lots of empty disks, you are very
lucky!)  Every phone call that is placed costs money for long
distance.

USENET has a higher volume of news than the ARPANET mass mailing lists.
(17 of the arpa lists - mostly the big highly visible ones - are fed
into USENET newsgroups, and there are 87 USENET groups that do not go
onto the ARPA mailing lists.)  I don't have any figures on the total
ARPANET volume, but July 27's USENET traffic on cbosgd (a slow day)
had 135 items, taking 22.4 minutes to transmit at 1200 baud, amounting
to about 145K characters.  This total is manageable but still puts a
pretty good drain on the system.  The real drain is in the number of
sites a given site sends news to.  A leaf node gets news from one site:
22 minutes of time.  A more central site may feed 5 other sites, for
a total of 110 minutes.  We notice a big difference - leaf sites don't
feel much, if any, drain on the CPU, but central sites do.

On the ARPANET, on the other hand, you have ONE central site that sends
news (as mail) to EVERY SITE.  (This assumes only one copy gets sent
to each site - an optimistic assumption.)  There are probably 100 sites
represented on a typical mailing list.  Result?  Nobody wants an arpanet
mailing list on THEIR site - people have to make special deals and
promises to only send stuff at night, and even then it's a scramble to
find a host.  Only a few hosts are willing, and MIT-MC must spend a
significant fraction of their cycles sending out mail.  The situation is
already getting bad, and this is with no phone bills and high speed links.
When you consider that the ARPANET is growing (especially if you count
the hosts on the internet) and the cost per host grows linearly with
the number of hosts on the ARPANET, and the number of lists is also
growing, it will eventually use up all the bandwidth on the ARPANET.
(I bet already a significant chunk is used.)  When you extrapolate that
to dialup nets, it would be way past the breaking point.

And what do you get for all this extra cost?  Your typical ARPANET user
who gets one of these mailing lists just has it merged in with his
personal mail, and gets interrupted throughout the day by what is often
"junk mail".  (If you're reading this, you're in the elite group of
people who MIGHT know how to get a separate mailbox.  But I'll bet that
at least half the people on this list have only one mailbox into which
everything is fed.)  You get a system where if one arpanet host goes
down, or forbids a mailing list, the whole mailing list grinds to a halt.
You probably have discussions interwoven with each other.  And, every
time you send mail to a big list, you get back 3 or 4 copies of it
from various sites with error messages like "No such user as RANDOM@RHOST"
or "GTJFN: operating system error".

Certainly news can use a lot of existing mail technology!  Many of the
tools and formats are perfect for news.  But mail can gain something
from news technology, too.  Checks to ensure that only one copy of
an article is delivered, preventing 99 copies of the same message from
being sent out, and allowing multiple paths for higher reliability.
Smaller fan-out (each major site feeds 3 or 4 neighbors, which feed
a few local sites), resulting in lower load on the machines.  A better
user interface (I said before what's wrong with mailing lists as a
user interface, so I won't belabor that point).  A central notion of
what newsgroups exist (rather than word of mouth and one person who
is kind enough to keep an unofficial list of the ones he's heard of.)

If mail is such a wonderful user interface, how come so many sites
on the ARPANET have bboards?  USENET is really nothing more than a large,
distributed, subscription bboard.  (By subscription, I mean that each
site can choose which newsgroups are forwarded to it, in case they
can't handle the full load; also, this allows local and regional
newsgroups.)

So what am I saying the header standard should have?  Basically this:

(a) A mandatory Message-ID on every message, to prevent loops.  The format
    should be part of the standard, and it should be short and unique
    across the internet.
(b) A References field, mandatory (or at least strongly encouraged) on
    all replies.  (That is, the reply command should generate this.)
    If the message being replied to has a References field, the
    reply should have the same References field (possibly followed by
    the message ID of the message being replied to), otherwise, a
    References field is generated with the Message-ID of the original
    message.  This is to allow a mail user interface to sort a mailbox
    into a meaningful order.
(c) A Newsgroups line on all mass mailings, inserted at the site where
    the mailing list originates.  This makes it clear (even to a program
    that is trying to sort the input) why that mail was received.
    (A line such as
	To: cbosg!cbosgd!pit
    is perfectly legal right now, and doesn't provide any clue that the
    name is an alias for "post to info-terms", even to a human.  A more
    likely form is:
	To: ihnss!ucbvax!c70:info-terms@Berkeley
    which could be figured out by a human, but not by very many programs.)
    Note that a message can be in more than one newsgroup.  This cuts
    down on transmission overhead and on people having to read it twice.

A typical user interface, being invoked on (say) a mailbox (or a read only
mailbox, if only one copy is kept per system) might want to sort:
	(1) by Newsgroups (to get the main topic), then
	(2) by References (to get the sub-discussion), then
	(3) by Date (to get things in cronological order).

I also encourage sites to increase the fanout of mailing lists (at least
to the extent that current sites permit forwarding of mail), to try to
send only one copy to each site (and develop whatever local tools they
feel are necessary to have read only mailboxes) and to put in some loops
for redundancy.  And some thought needs to be put into creation of a new
group (on USENET, one site administrator creates the group and immediately
all sites get everything in the group).  But this isn't a header-people issue.

Sorry for the length of this.

	Mark

Date: 31 Jul 1982 (Saturday) 1331-EDT
From: HAGAN at Wharton-10 (John Hagan)
Subject: Question about the JSOL algorithm
To:   header-people at MIT-MC

Is:
     John D. Hagan @Wharton
     John     D. Hagan @Wharton
     John D.Hagan @Wharton
 
All the same?  I think they should be since the canonical representation is:

     John D.Hagan@Wharton

If not, or yes for another reason, please explain the parsing algorithm
as it applies to these three cases.
--Kid.



Date: 27 Jul 1982 2155-PDT
From: Stef <ESTEFFERUD at USC-ECL>
Subject: Re: mailing lists
To: header-people at MIT-MC

I believe that we are converging on the idea that whatever mail transfer
system we might employ for moving mail from senders to addressees, there
is a class of mail items which should be handled differently by their
recipients because they are actually newsletters, or "group" mail which
can and should be processed differently in terms of posting to BBoards,
and archived in publicly accessible tertiary files, et al.

I claim that this need for separation can be achieved by mailing these
"news" items to addresses where they will be received by processes that
do things differently.  The separator in this case is a distinctly
different address from personal mail for other folks, though the "news"
mailbox need not look different to an outsider, though making its name
suggestive might be a nice gesture.

I see no problem with installing a relay net that spreads the delivery
load among a "tree" of cascaded sites.  Indeed, we have installed
exactly this arrangement at UCI, with all group lists aliased to a local
list, and with a copy posted on a public BBoard for each group.  Our
local BBoard UA has been created out of a regular mail handler by adding
a BB command that knows how to find the named group's BBoard file.  It
also only allows users to have read access, unless they are on a list of
authorized "BBMasters."

So, within the single system we have now, we are doing what is
suggested, without asking permission, or needing any change to any mail
standards.

However, it would have been much easier to implement if the DELIVER
program had copied the envelope's TO address to some (locally named)
field for our local BBRCV program to find, since we want to divert all
such group mail to a single process when it arrives.

At this point, I want to establish that it is OK for the MSA to hand
over some envelope information at deliver time.  I don't think this
requires any change to 733+.  UNLESS, we are going to set a standard
name, syntax, and semantics for the field that is created at deliver
time to hold the TO information, in which case we might want to require
that the sender correctly place this field in the header.

The more I think about all this, I would be happy to just make sure I
can get it from DELIVER.  As I understand MMDF and its RCVMAIL hook, it
now allows me to capture and record what I want as I want it.  Other
systems should consider enabling such a mechanism.

So, maybe all is well as things are now?  Stef
-------

Date:     31 Jul 82 21:01:13 EDT  (Sat)
From:     Steve Bellovin <smb.unc@UDel-Relay>
Subject:  Re: mailing lists
To:       Stef <ESTEFFERUD@Usc-Ecl>, header-people at Mit-Mc
In-Reply-To: Stef <ESTEFFERUD@USC-ECL>'s message of 27 Jul 1982 2155-PDT
Via:  UNC; 31 Jul 82 22:24-EDT

I *almost* agree with Stef -- but I think that the newsgroup name
should be inserted in the header to aid in situations where a private
group sets up their own distribution list.  The issues are the same,
the need for separation is the same -- but they may not have access
to the system lists.  It also aids individuals at sites without centralized
bulletin boards for mailing lists; indeed, it's my impression that very
few of the mass-mailing lists' recipients are really programs.  Even a
dumb mailer can pick out articles with some unique header.


Date: 31 Jul 1982 2350-PDT
Sender: ESTEFFERUD at USC-ECL
Subject:  Re: mailing lists
From: ESTEFFERUD at USC-ECL
To: header-people at MIT-MC
Message-ID: <[USC-ECL]31-Jul-82 23:50:17.ESTEFFERUD>
In-Reply-To: smb.unc's message of 31 Jul 82 21:01:13 EDT  (Sat)

I will agree with the idea that group lists should insert a self
identifier, but I also think there is a deeper issue in here that
needs attention.  This has to do with where list expansion takes
place.  We have slipped into the habit of expanding lists in the
delivery system, rather than in User Agents outside the delivery
system.  There is a real issue as to whether this is a correct
implementation.  I fear that we are now coming to a point where this
must be decided.

When expansion occurs inside the delivery system (inside MMDF or
XMAILR for example) it seems to be very hard to assign responsibility
for failures of addresses inserted in the expansion process.  The
needed mechanisms for repsonsibility management are simply not there!
And, it requires system wizard privileges to set up aliases because of
the sanctity of the mail, et al.  We do not seem to have any way to
attach information about where failure notices at later stages of
delivery should be returned, without munging the internal header (Read
Internal Letter Head).  And, we all feel some revulsion about such
munging of mail, especially private mail.

But, if expansion is done in a UA outside the delivery system, then it
is not violating anything to insert information about responsibility
to accept notices and deal with failures of addresses it inserts "by
expansion."

For example, I have plans to modify the "relay" procedures for
MsgGroup (assuming it has any life remaining in its old bones) to
actually take possession of each relayed item, and resubmit it, as
having SENDER be MsgGroup-request, and to have REPLY-TO be msgGroup,
so that failures will go to MsgGroup-Request and recipients who reply
will find their replies addressed to MsgGroup.  I need to think about
this some more before doing it to be it will achieve what I want.

I also plan to let local hosts set up local distribution, as has been
done at RAND-MSGGROUP@RAND-UNIX, UCI-MSGGROUP.UCI@UDEL-RELAY, and
others.  This is the beginning of a newsnet distribution system.

I can agree that a general system of this nature would be a good idea
for lots of lists, if not all of them.  My only real concern then is
that we use the regular mail delivery system to effect the results.

At this point, I lean toward the idea of such a newsnet, using User
Agents that are outside the mail system, to do the relaying, by taking
possession of the news items at each expansion point, and deliberately
placing relevant information into the header to leave a visible and
machine processable trace for later recognition by recipients.

If such a newsnet, riding on top of 733+ netmail, needs standards,
then I expect that they belong in a newsnet standard, and that they
are outside the purview of 733+.

Well, this is all the time I will have for this discussion for the
next week or so.

See you then - Stef

