Date:  6 Sep 1983 0945-EDT
From: Greg Skinner <Gds@MIT-XX>
Subject: Re: senders, originators and relays
To: ROODE@SRI-NIC
cc: header-people@MIT-MC
In-Reply-To: Your message of 5-Sep-83 2020-EDT


    Return-path: <@MIT-MC:ROODE@SRI-NIC>
    Received: from MIT-MC by MIT-XX; Mon 5 Sep 83 20:15:43-EDT
    Date: Mon 5 Sep 83 17:07:02-PDT
    From: David Roode <ROODE@SRI-NIC>
    Subject: senders, originators and relays
    To: Header-People@MIT-MC
    Location:  EJ286    Phone: (415) 859-2774

    Consider:

    	3.  In the TOPS-20 mailsystem, when you cause
    	a "SENDER:" header to be generated by specifying
    	the contents of the "FROM:" header, automatically,
    	a "REPLY-TO:" header is generated to match the
    	"SENDER:" header.  There needs to be a convenient
    	way to leave this off if the functionality of
    	separating error reports from replies is to be achieved.
    	Also, there is no way to set the SENDER to say
    	"HEADER-PEOPLE-REQUEST@MIT-MC" because it is forced
    	to be the user logged in sending the message.

Well, by using the BABYL library (for tops-20 emacs) you can define
your own header fields, or force the headers to whatever you want them
to be.  Once I wanted to anonymously mail a message to a group of
people, so I made up false From: and Sender: addresses.  The only
problem with that is that the return path becomes NET-ORIGIN which is
probably an "undeliverable, unclaimable mail" box.
-------

Date:  6 Sep 1983 14:39:10 PDT
From: POSTEL@USC-ISIF
Subject: re: forwarding or remailing ?
To:   Header-People@MIT-MC


I agree with Ed Taft.  His statement is clear and to the point.

My view is that mail sent via a mailing list is really two distinct
and separate operations.

1. Author sends the message to a distribution service.

2. The distribution service send the message to the list.

If anything goes wrong in step 1 the author ought to be told.

If anything goes wrong in step 2 the operator of the distribution service
ought to be told.

--jon.
-------

Date:  7 September 1983 08:39 edt
From:  TMPLee.DODCSC at MIT-MULTICS
Subject:  Query: GTE Telenet blk xfr protocol?
To:  Header-People at MIT-MC, Human-Nets at RUTGERS, 
     info-pcnet at MIT-MC, protocols at RUTGERS
cc:  TMPLee.DODCSC at MIT-MULTICS

(list moderators: please feel free to ignore this if you don't think it
fits your list)

Does anyone know the details (i.e., protocol) for doing block transfers
to/from GTE Telenet public dial-up access points?  I'm using a personal
computer as my terminal and getting to an ARPAnet machine via
gte-telenet.  I'd like to be able to store/retrieve and local edit
traffic from the net but to do that I have to have some kind of simple
protocol for transmission of blocks of text to and from GTE Telenet.  I
think they support such a protocol, but have no information about it.
(not asking for a reliable transmission protocol -- lines here are
pretty good -- just one to do speed and buffer matching)

Ted Lee

Received: by YALE-BULLDOG via CHAOS; Tue, 27 Sep 83 22:08:43 EDT
Received: from YALE-RING by YALE-RES via CHAOS; Tue, 27 Sep 83 22:01:02 EDT
Subject: A Random Gripe
Date: Tue, 27 Sep 83 22:01:07 EDT
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: Header-People@MIT-MC.ARPA
cc: Ellis@YALE.ARPA

I figure this is a good a place as any to make this gripe...it is
my understanding that the syntax of addresses prohibits "."s as in
the following context:

    To: Elmer T. Fudd <Fudd@Podunk>

If you want "."s or other "special" characters, you're supposed to
wrap the "phrase" with quotes.  E.g.:

    To: "Elmer T. Fudd" <Fudd@Podunk>

I can't say that I can reconstruct the motivation for this restriction
-- I suspect it has to do with not confusing the "."s with the "."s
in a domain spec -- but in any case, a lot of systems don't follow
the rule and it screws up our mail parser a bit.  It's not a tragic
or major problem, but I thought I would bring it to people's attention,
since a lot of mail systems don't seem to wrap the phrase with quotes,
as it should.

                -- Nat

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 28 Sep 83 01:13:59 PDT
Via:  44a.Ucl-Cs.AC.UK; to 44b.Ucl-Cs.AC.UK  over Inter-UNIX with SMTP; 
          28 Sep 83 9:12 BST
Date:     28 Sep 83 8:39:15 BST (Wed)
From:     The Postmaster <mmdf@ucl-cs> (44a)
To:       mailgroup@ucl-cs, header-people@mit-mc.arpa
Subject:  [Mark Crispin:  "%" routing]
          [The Postmaster:  Re: "%" routing]

The following may be of interest.  The problem arose when UCL-CS mapped
an address like  aaa%bbb@ccc into <@ccc:aaa@bbb>.  SCORE could only
interpret the first form.  Whilst this is incorrect in a pure
DARPA Internet context, note the problems in the UK context.

Steve Kille


----- Forwarded message # 1:

Via:  44b.Ucl-Cs.AC.UK; to 44a.Ucl-Cs.AC.UK  over Inter-UNIX with SMTP;
          27 Sep 83 20:00 BST
Via:  Su-Score.arpa; to 44b.Ucl-Cs.AC.UK  over Satnet with SMTP;
          27 Sep 83 19:56 BST
Date: Tue 27 Sep 83 11:56:07-PDT
From: Mark Crispin <MRC@ARPA.Su-Score>
Subject: "%" routing
To: mmdf@ARPA.Ucl-Cs
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Actually, the use of "%" as an alternative "@" was developed
independently; I confess to not being the first person to ever use
it as such though.

     The important thing, though, is no matter what the semantics
of your local environment you should never make assumptions about
foreign semantics.  At best, you can assume the semantics of entities
in your own local environment; for example, UK hosts may agree to use
"%" as a source route just as non-IP hosts on the Stanford LAN (a 3MB
Ethernet) must also do.  But UK cannot make assumptions about Stanford's
semantics, neither can Stanford do so about UK.

     The failure in your mailer was in not recognizing that the entity
on the right half of the "@" was external to the UK and so it isn't
correct to do any special handling of the left half other than to send
it in "virgin" form.  After all, for all you know "%" could be part of
a user name at a Stanford computer!

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


----- Forwarded message # 2:

Date:     28 Sep 83 8:15:23 BST (Wed)
From:     The Postmaster <mmdf@UK.AC.Ucl-Cs> (44a)
To:       Mark Crispin <MRC@ARPA.Su-Score>
cc:       mmdf@UK.AC.Ucl-Cs
Subject:  Re:  "%" routing

I will not argue about the history of the % route.  I suspect that
you will find that the UK has been using it for a good deal
longer than you think.  (Although I do realise that the
original suggestion came from the other side of the Atlantic).

I do not regard the UK use of "%" as a local decision.  The UK
network is comparable in size to the DARPA Internet, and has
its own mail protocol which happens to be based on RFC 822.
The address syntax is different.  (I will make the next
revision available to the Internet community at some stage).
Note that I am not in favour of the differences. However, they exist.

I agree that I am being a little sloppy not to note which
protocol environment a message comes from and handle it
accordingly.  The differences are subtle, and the effort would
be non trivial.  (There are many reasons why the UK cannot be
treated as a local stub network).  Note a much harder
problem: If your message is relayed to a remote UK site, how can
I tell what to do with the return path generated by such a
site.  The original specification may have been either as a %
route or an 822 route.  I am forced to always guess the latter.

Having said all that, I have no immediate intentions to change
our % handling.  It should be regarded as a peculiarity of
message relaying to the UK.  I would encourage all Internet
sites which use this format to only use it as an alternative
specification of a source route.


Steve

----- End of forwarded messages



Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2611069409372234@MIT-MULTICS.ARPA>; 28 Sep 1983 13:03:29 edt
Date: Wed, 28 Sep 83 11:11:46 EDT
From: "Gavin Eadie"@UMich-MTS.Mailnet
To: Mishkin@MIT-Multics.ARPA,
    header-people@MIT-MC.ARPA
Message-ID: <239238@UMich-MTS.Mailnet>
Subject: A Random Gripe

For what it's worth, I'll add to Nat's plea for quoting names
containing period characters. Our mail system allows names of the
form he described which contain all sorts of strange things:

                     Dr. Ding D'Ong Sr.

We occasionally get incoming mail with names un-delimited and
my RFC822 parser would have to be a lot smarter to deal with all
the illegal possibilities!

Date: Thu 29 Sep 83 17:02:37-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: [Mark Crispin:  "%" routing]
To: mmdf@UCL-CS.ARPA
cc: mailgroup@UCL-CS.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "The Postmaster <mmdf@ucl-cs> (44a)" of Wed 28 Sep 83 08:39:15-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     This is in response to Steve Kille's message regarding
Score's apparently inability to interpret "<@ccc:aaa@bbb>" as
being equivalent to "aaa%bbb@ccc".  In the particular instance of
this which came up, the bbb value was a site on Stanford's LAN in
a naming registry external to Internet (what Steve refers to as a
"local stub network").

     For the lack of an official naming specification for stub
networks, the TOPS-20 mailer has a concept of "relative domains".
A "relative domain" is one which is relative to a single host,
and is distinguished by the presence of a "#" symbol (which Jon
Postel assured me would never be used by a real domain).  Such
"relative domains" are tied to the physical naming registry they
refer to; consequently we have names such as #Pup, #Chaos, and
#DECnet for Pup Ethernet, Chaosnet, and DECnet.  There is no
relative domain name for Internet because the absolute domain
name ARPA exists.

     These relative domain names exist for the convenience of
the TOPS-20 sites which act as mail bridges.  They allow for an
exact determination of what naming registry to look the host up
in.  Otherwise, a priority algorithm must be selected.  For
example, suppose a TOPS-20 site is on ARPANET, a Pup Ethernet,
and a Chaosnet, and each of these networks have a member called
FOO but they all refer to different systems!  FOO.ARPA, FOO.#Pup,
and FOO.#Chaos would each refer to a unique FOO host.  Otherwise,
given the name FOO it would have to guess; the current priority
algorithm is to prefer FOO.ARPA.

     I forget the exact names now, but the address in question
was something like JONES%GSB-How.#Pup@SU-SCORE.ARPA.  This means
"JONES@GSB-How on the Pup Ethernet that SU-SCORE.ARPA is
connected to".  GSB-How is not presently an Internet host and is
not in the Internet host table, which is why the TOPS-20 mailer
(whether at Score or GSB-How) used this address syntax.

     According to both the SMTP and the RFC 822 specifications,
any host name entity must be a valid Internet host name.  As a
result the TOPS-20 mailer goes to great lengths to shield all
external parties to this syntax by hiding it on the left hand
side of the "@" where in theory nothing but the mailer on the
entity identified by the right hand side has the right to parse.

     The UK mailer converted this address to something like
@SU-SCORE.ARPA:JONES@GSB-How.#Pup, which the Score SMTP server
declined to accept.  This is because "GSB-How.#Pup" is not a
valid Internet host name; it isn't until the message goes to the
Score mailer daemon that concepts such as that are understood.

     This is what happened at Score's end.  I don't wish to
finger point so much as state that operationally, the TOPS-20
mailer depends very much upon its present behavior just as the UK
mailer depends upon its behavior.  We have encountered a conflict
between the two and of course the Internet standards are on my
side.

     I don't want to take the simplistic stand of "the UK mailer
is at fault and they should fix their software."  This is clearly
desirable in the long-term, but sometimes various technical and
political considerations make this difficult.  After all, who am
I to criticize when I have my own wars of this nature to fight?
But, what will happen should a site appear which has the "%"
character in its user names?  Literally, the way relaying is done
by the TOPS-20 mailer is to make "%" part of a pseudo-user name
that only at a much lower level is interpreted as an "@".  The
Powers That Be state that Thou Shalt Not Have Non-Internet Names;
I construe this as meaning that I cannot use source routing
because the names I would use are non-Internet.  I do in fact use
source routing when I am dealing with Internet names.

     I look forward to an intelligent non-inflammatory exchange
of messages on this subject.

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

Received: from SCRC-YAMASKA by SCRC-SPANIEL with CHAOS; Fri 30-Sep-83 09:10:48-EDT
Date: Fri, 30 Sep 83 09:11 EDT
From: Charles Hornig <Hornig@SCRC.SCRC>
Subject: Re: [Mark Crispin:  "%" routing]
To: Mark Crispin <MRC@SU-SCORE.ARPA>, mmdf%UCL-CS@MC.ARPA
Cc: mailgroup%UCL-CS@MC.ARPA, header-people@MC.ARPA
In-reply-to: The message of 29 Sep 83 20:02-EDT from Mark Crispin <MRC at SU-SCORE>
Message-ID: <830930091132.3.Hornig@SCRC.SCRC>

As I remember, the "%" convention was adopted for the sole purpose of
making the transition from old NCP-FTP mail to SMTP.  The "%" was chosen
precisely because it was unlikely to have any syntactic meaning in any
existing mailers.  After all, it only had to be interpreted in the
NCP/TCP mail bridges, and then only for non-SMTP mail.  A simple kludge
to cover a simple problem.

Things haven't worked out that way.  Using "%" has become the standard
way of specifying a mail route since we have been forbidden by the
`powers' from using the RFC 822 syntax.  While "%" may have been a good
temporary solution to the NCP mail transition, it was not well thought
out as a permanent routing mechanism.  I think that it is showing its
weaknesses here.  I hope that I will soon be able to be
"@MIT-MC.ARPA:Hornig@SCRC.SCRC" rather than the mess you see in the
header.

				-- Charlie Hornig

Date:  1 October 1983 22:29 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  % redux
To:  Header-People at MIT-MC

  I notice that the traditional "%" kludge is still acceptable to
ARPAnet, even as domain-time draws near (well, at least I hope it draws
near...).
  I also notice a definite similarity between the foo%bar@grud.arpa
notation and the future foo@bar.grud.arpa notation, especially if the
gateways to the domains are the machines currently interpreting the %
and forwarding into their domains.
  I wonder if it is:
  (a) legal, and
  (b) advisable
  to use the % as an arpa-compatable notation to represent dots in the
future domain notation.
  I should like to be able to send mail to

  idallen % watmath @ uucp . ARPA   (without the spaces)

and be able to interpret it as:

  <person> @ <subdomain or machine> . <subdomain> . ARPA

even though it really means

  <person> @ <machine reachable by> . <host machine on> . ARPA

  (Please note that this is subtely but definitely different from the %
used as an explicit router, as in @grud.arpa:foo@bar.something_else)

  What say you all?
  --dave
    drbrown @ watbun.UUCP
    DBrown.TSDC @ HI-MULTICS.ARPA

Received: by YALE-BULLDOG via CHAOS; Sun, 2 Oct 83 11:14:37 EDT
Received: from YALE-RING by YALE-RES via CHAOS; Sun, 2 Oct 83 11:10:54 EDT
Subject: USENET vs. UUCP
Date: Sun, 2 Oct 83 11:10:56 EDT
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
To: header-people@MIT-MC.ARPA

Despite the apparent pessism of some people that "the powers that
be" will ever deign to let the world have domain names of its own,
I think that the day of domains will be on us sooner than we think.

So, before things get completely messed up on one small front...is
there a consensus on whether the DOMAIN of (typically Unix) machines
passing around mail and news via a protocol called UUCP should be
called "USENET" or "UUCP"?  In the present world of unofficial domain
names I have seen both names used.  It seems that the right name is
USENET.  I don't really care which it is, just that a standard name
be chosen.

                -- Nat

Date: Sun 2 Oct 83 17:13:50-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: % redux
To: DBrown.TSDC@HI-MULTICS.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "DBrown.TSDC at HI-MULTICS" of Sat 1 Oct 83 22:29:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

It is my claim that a%b@c should be interpreted now as meaning "user a%b
at host c".  Any interpretation of routing belongs solely to host c.  The
problems the UK is having now with such messages illustrates the sort of
fix you can get into.  In the UK context, "%" is explicitly defined as
meaning routing and there is apparently no means by which it can be an
ordinary character.

The TOPS-20 mailsystem uses "%" only because it has no choice.  It uses
source routing whenever it can, but it was decreed by The Powers That Be
that one cannot have a non-Internet host name in a source route.  Needless
to say that pretty much makes source routes useless except perhaps as
debugging traces.

I would be happy to migrate to domains.  But... there are still hosts which
don't accept ".ARPA" and complain bitterly about mail with the ".ARPA"
domain.  A few sites, e.g. the NIC and ISI, made a local change to the
TOPS-20 mailsystem not to generate ".ARPA" (the distributed version does).
If the NIC and ISI are unwilling to support the standards, what hope is there
for the rest of the world?
-------

From: vortex!lauren at RAND-UNIX
Date: Sunday, 2-Oct-83 23:19:03-PDT
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: UUCP domain
To: HEADER-PEOPLE@MC
CC: decvax!cbosgd!mark

The domain should *definitely* be:

UUCP

"Usenet" is a logical information system of computers exchanging
newsgroup information of various sorts, and is essentially separate
from the mail transport network that lies underneath.  Some
sites which receive Usenet "netnews" newsgroups receive their 
groups via ARPA or other mechanisms, NOT necessarily via UUCP.

On the other hand, all sites running UUCP (that are publicly
connected, of course) can be considered to be part of the
UUCP "domain" for mail exchange.

In other words, UUCP is a transport mechanism and provides a 
physical network (and is rightly a domain) while "Usenet"
is a collections of computers passing certain sorts of information
between themselves, and is not an actual network in the
normal sense of the word.

Unfortunately, the two terms are often used interchangeably in
messages -- a practice that is, admittedly, to be discouraged.

--Lauren--


Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 3 Oct 83 15:36:46 PDT
Via:  UNKNOWN-HOST; (src/csmail/listen); to 44d.Ucl-Cs.AC.UK 
          over Sercnet with NIFTP;  3 Oct 83 20:19 BST
From:    Jonathan Mills (on GEC 4090 at Rutherford) <NSIN24@rlgk>
To:      Header-People <Header-People%mit-mc.arpa@ucl-cs>
Date:    Mon, 3 Oct 83 15:30 BST
Subject: Message-IDs
Message-Id: <03 OCT 1983 15:38:44 NSIN24@RLGK>
Cc:      MsgGroup <MsgGroup%brl.arpa@ucl-cs>

As I seem to get multiple copies of messages from the State's mailing list
i decided to sit down today and write some code that eliminates duplicate
messages.  My code was based on the MESSAGE-ID field contents, and the idea
was that if two MESSAGE-ID fields were the same, I could discard one of
the messages.

However, when I fired up the code, I set it to work on my collection
of HEADER-PEOPLE and MSGGROUP mail, and it said it found 1 duplicate
message.  I then discovered that very few of the states mailers seem to
stamp MESSAGE-ID fields - Is there a good reason for this?  (Actual
figures were that only 25 out of 80 messages had MESSAGE-IDs)


                 Jonathan


Date:     Mon, 3 Oct 83 22:18:29 EDT
From:     Doug Kingston <dpk@brl-vgr>
To:       DBrown.TSDC@hi-multics
cc:       Header-People@mit-mc
Subject:  Re:  % redux

	Either I'm missing something (not likely), or the use of percent (%)
is being blown out of proportion.  The only valid use for % is to the
left of the @ and it is only to be interpreted at the mail destination
specified by the domain address to the right of the @.

In the example:
 		fred%destA@destB.subdom.ARPA
"fred%destA" must not be modified or re-interpreted until given to the
mail destination or mail forwarder specified by "destB.subdom.ARPA".
You cannot assume anything about how the destination host will use
the %.  "fred%destA" must be treated as a local address at destB.subdom.ARPA
until it reaches that destination at which point that host can do anything
it cares to with the address.  Remember, "destB.subdom.ARPA" may not
even specify a host, it may specify only a logical mail destination
which will map to more than one host via the nameserver mechanism.

					Cheers,
						-Doug-

Date: 4 Oct 1983 00:19-PDT
Sender: ESTEFFERUD@USC-ECL
Subject: Re: Message-IDs
From: Einar Stefferud - Mssgroup Moderator <msggroup-Request@BRL>
Reply-To: Msggroup@BRL
To: NSIN24%rlgk@BRL
Cc: Header-People@MIT-MC, MsgGroup@BRL
Message-ID: <[USC-ECL] 4-Oct-83 00:19:30.ESTEFFERUD>
In-Reply-To: <03 OCT 1983 15:38:44 NSIN24@RLGK>

With some fear and trepidation, I want to strongly suggest that this
discussion of whether or not to ID messages should flow in
Header-People only, since this is a relativley operational issue.

The last time I requested this, I discovered an immense inertia among
the contributors who basically ignored my request entirely.

Lets not do that this time.  Thanks - Stef

Date: Tue 4 Oct 83 04:01:36-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Message-ID's
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I have never been convinced of the real utility of Message-ID's.
Several mailsystems which once generated them no longer do so, mostly
because people found them obnoxious.

     It would be totally trivial for the TOPS-20 mailsystem to generate
a Message-ID.  It does not do so, mostly because I have the belief that
the user feeling against Message-ID's is greater than that for them.

     My feeling has always been that Message-ID's are not the panacea
that certain individuals think they are in removing duplicated messages.
Sometimes messages get redistributed with additional comments but without
altering the Message-ID.  I've seen this happen enough to distrust any
software which censors duplicate Message-ID messages, but I'll confess
to an intrinsic distrust of all such "overly intelligent" (from my point
of view) automation.

     I believe that a good pattern-matcher and discriminator would do a
much better job of flushing extra copies of messages than anything which
depends upon Message-ID's.

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

Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Tue 4-Oct-83 08:43:32-EDT
Date: Tue, 4 Oct 83 08:40 EDT
From: Robert W. Kerns <RWK@SCRC-TENEX>
Subject: Message-ID's
To: Mark Crispin <MRC@SU-SCORE>
Cc: Header-People@MIT-MC
In-reply-to: The message of 4 Oct 83 07:01-EDT from Mark Crispin <MRC at SU-SCORE>
Message-ID: <831004084004.9.RWK@SCRC.SCRC>

    Date: Tue 4 Oct 83 04:01:36-PDT
    From: Mark Crispin <MRC@SU-SCORE.ARPA>
	 I have never been convinced of the real utility of Message-ID's.
    Several mailsystems which once generated them no longer do so, mostly
    because people found them obnoxious.
Much less obnoxious than the following two!
    Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
    Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
But I only mention that to make the point that they aren't
very obtrusive, especially given all the other header fields
RFC822 stuffs in.  It is becoming more and more useful for
mail reading programs to filter what headers they actually
show you.  Given this capability, the "obnoxious" aspect is
quite irrelevant.  Granted, it may be ten years before everybody
HAS that capability, but if they're obnoxed by Message Id, they're
surely going to be obnoxed by Recieved: and Via:

	 It would be totally trivial for the TOPS-20 mailsystem to generate
    a Message-ID.  It does not do so, mostly because I have the belief that
    the user feeling against Message-ID's is greater than that for them.

Might I suggest that this may no longer be true?
Admittedly, this is based on a sample of one (me).  I
used to be quite opposed to them, but now my feelings
are much closer to making them mandatory!  (Relax, I
would only argue for that in the context of a redesign
with evelope/text distinctions).

Eliminating of duplicated messages is only one use for
Messages-ID's.  Zmail has a command which tries to delete
duplicated messages based on either the Message-ID if
present, or a combination of Date and From.  I can assure
you that Message-ID is much safer.  But anybody who
redistributes messages with additional comments had better
not expect any response from me, because he's got a 50%
chance or less of my ever noticing that the length on one
message is longer than on the other.

	 I believe that a good pattern-matcher and discriminator would do a
    much better job of flushing extra copies of messages than anything which
    depends upon Message-ID's.

Anything that has the same header fields stands a good
chance to not be read by anyone using a mail reader
that lets you pick and choose messages.  I claim that
comparing Message-ID's is substantially better than
the human mechanism likely to already be in place.
Of course, I have no objection to using a pattern
matcher for final comparison, but I don't think it's
worth the effort.

Date: 4 Oct 1983 1106-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: Mark Crispin <MRC at SU-SCORE>
cc: Header-People at MIT-MC
Subject: Re: Message-ID's
Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11956815040.31.71.26901 at DEC-MARLBORO>
References: Message from Robert W. Kerns <RWK@SCRC-TENEX>
              of 4-Oct-83 0850-EDT
In-reply-to: <831004084004.9.RWK@SCRC.SCRC>

Might I add that at least one mail system (MS) copies the original message-ID
to the (I think) "In-reply-to" field of any replies you generate, and has
a command ("read related-messages") to recursively trace back through
a conversation.  Very handy when you get a reply that says merely "yes",
and have forgotten what the original message was.  Of course, this is
only useful if the people on the other end of your mail conversations are
using a mail system that replicates the message-ID that way, but at DEC,
anyway, everyone on a 20 (well, ALMOST everyone) uses MS.
   --------

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 4 Oct 83 08:52:52 PDT
Via:  44a.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK  over Inter-UNIX with SMTP; 
          4 Oct 83 16:46 BST
Date:     4 Oct 83 16:40:06 BST (Tue)
From:     Steve Kille <steve@ucl-cs> (44a)
To:       Doug Kingston <dpk@brl-vgr.arpa>
cc:       DBrown.TSDC@hi-multics.arpa, Header-People@mit-mc.arpa, mailgroup@ucl-cs
Subject:  Re:  % redux

In the Internet context, Doug is right.  "%" should not be treated as
a synonym for "@" or ".".  I look forward to seeing the RFC 822
convention for source routes being used.

In the UK context, "%" is treated differently.  We have a
different address syntax.  To send a "%" from the UK to the
Internet it must be quoted.  Otherwise, the UK source route
fred%domain1@domain2 should be transformed to the Internet
source route <@domain2:fred@domain1>.

UCL, being in both environments has a problem!  I was using
this as an excuse for behaving sloppily in the Internet
environment.  I have to admit that this won't do.  I will thus
be forced to use different parsers for the two environments.
This will ensure correct behaviour in both environments.

Steve



Date:  8 October 1983 03:58 edt
From:  Frankston.SoftArts at MIT-MULTICS
Subject:  Re: Message-ID's
Sender:  SAI-relay.SoftArts at MIT-MULTICS
Reply-To:  Frankston at MIT-MULTICS (Bob Frankston)
To:  Mark Crispin <MRC at SU-SCORE>, Header-People at MIT-MC
*from:  BOB (Bob Frankston)
Local:  Mark Crispin <MRC@SU-SCORE.ARPA>,Header-People@MIT-MC.ARPA, cc:BOB:sent.po
Original-date:  08 OCT 1983 00:09:48

When half my screen is filled with something like:

     Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:MRC@SU-SCORE.ARPA>
     Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 04-Oct-1983 07:02:39-edt
     Date: Tue 4 Oct 83 04:01:36-PDT
     From: Mark Crispin <MRC@SU-SCORE.ARPA>
     Subject: Message-ID's
     To: Header-People@MIT-MC.ARPA
     Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
     Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

I don't understand why people get upset with a single line of
message-id added.

PS: This is one of the shorter examples of headers.  It seems
    that the mail-related mailing lists seem to have the
    largest and most encrusted mail headers on the network.

Date:  9 October 1983 10:29 edt
From:  Frankston.SoftArts at MIT-MULTICS
Subject:  Re:  Message-ID's
Sender:  SAI-relay.SoftArts at MIT-MULTICS
To:  Brint Cooper <abc at BRL-BMD>, 
     Mark Crispin <MRC at SU-SCORE>, Header-People at MIT-MC

Actually, mail reader doesn't happen strip header fields.  But
if the program did strip them, then it makes it even more
obvious that there is no inconvenience to the user in having
the good old message ID.

PS: If this message doesn't have a message-id when you get it,
    then someone in the middle has stripped it -- I don't know who.


Date:           Sat, 8 Oct 83 15:35:20 PDT
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Multiple recipients/messages in SMTP

***************************************************************
**  This is a request for information and comments directed  **
**  specifically to implementors of SMTP server programs.    **
***************************************************************

RFC821, the SMTP document, states that SMTP servers must be able to
accept at least 100 recipients per message (see Section 4.5.3 on page
43).  It also seems to imply that an SMTP server is supposed to be able
to accept an unlimited number of separate messages in a single connec-
tion with a foreign host (although I can't find any passage which ex-
plicitly demands that this capability must exist).

However, since many sender (mailer) programs currently used in the In-
ternet apparently send only one message per connection and specify only
one recipient per message, I am hesitant to assume that all SMTP server
programs really do handle multiple messages and/or multiple recipients
properly.  I am therefore trying to construct an SMTP sender which can
specify multiple recipients per message and send multiple messages per
connection -- but which will downgrade gracefully to single-recipient
and/or single-message mode when confronted with a "dumb" server.

I designed a "sender" strategy which does not assume that a "dumb" SMTP
server will act in any particularly predictable or coherent way when
presented with multiple recipients per message or multiple messages per
connection.  Basically, if I were to get an error while doing multiple
recipients and/or multiple messages, I would retry the rejected command
in a single-message, single-recipient context before assuming that the
error was permanent.

Perhaps, though, I am being overly pessimistic as to the present state
of SMTP servers.  If I can make a few more assumptions regarding the
way servers act in the face of errors, then I think I can relax my con-
straints considerably.

Therefore, I would like to know how the SMTP servers used by Internet
hosts today rate with respect to the following suggested standards:

==> If a RCPT or DATA is received in an unexpected context (e.g., no
    message transaction in progress, or no valid recipients specified
    before a DATA command), the server will ALWAYS use a 503 reply
    code.

==> If a RCPT is received and the recipient address is acceptable, but
    no more recipients can be handled for this message, the server will
    use either a 400-series reply code (i.e., a reply code whose first
    digit is 4) or a 552 reply code.

==> If a MAIL command is received and the return path is acceptable,
    but the message cannot be handled for some reason (e.g., the server
    can only handle one message per connection), the server will use
    either a 400-series reply code or a 552 reply code.

==> The only reply codes which the server will ever use in response to
    a DATA command are 354 and 503 -- except if a temporary processing
    error arises, in which case a 400-series reply code will be used.

==> The server will use a 500-series reply code at the very end of a
    message transaction (i.e., after the text of the message has been
    transmitted by the sender) ONLY if the message is so unreasonably
    long that it would never be accepted even under ideal conditions.

If the above properties hold for all SMTP servers on the Internet, then
I believe I can safely assume that any MAIL or RCPT command rejected
with a 500-series reply code other than 503 or 552 -- or any message
text rejected with any 500-series reply code (including 552) -- would
never be accepted by the server under any circumstances, and thus need
not be retried later in a single-message/single-recipient scenario.

I would particularly like to know if there are any SMTP servers on the
Internet today which do NOT act as I have described above -- and if
not, specifically how not.  Also, if someone believes that SMTP servers
should not act as I have described above, I would like to hear your
reasons.

Please reply to me directly if possible; I will summarize to the mail-
ing list in a couple of weeks.

-- Rich <wales@UCLA-LOCUS>

Date:     Mon, 10 Oct 83 22:00:04 EDT
From:     Mike Muuss <mike@brl-vgr>
To:       Frankston.SoftArts@mit-multics
cc:       Header-People@mit-mc, abc@brl-vgr
Subject:  Filtering Headers on Display to User

The mail reader used at BRL ("msg") by default removes many of
the more "obnoxious" header fields.  The user can easily tailor
the list of fields to be displayed or removed, and the operation
of the filter may be toggled at any time.  This makes mail reading
a real pleasure.  Especially when on a slower terminal, such as
dialing in from home, or when on travel.

Our default list of fields to filter includes:
via, remailed-from, remailed-to, message*, sender, mail*, article*,
received*, origin*.

(remailed-by is left in, to alert the reader to the extra step in
his receiving the message).  Message* matches message-id.

			-Mike

Date:           Tue, 11 Oct 83 14:57:59 PDT
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        More on multiple recipients/messages in SMTP

I have a couple of additional questions regarding the state of SMTP
servers today.

(1) Does anyone's SMTP server have a limit to the number of recipients
    it will accept per message transaction?  If so:
    (a) What is your server's limit?
    (b) What reply code do you use when rejecting a RCPT command which
	attempts to go beyond the limit of your server?
    (c) Are you reasonably certain that your server will not "break"
	if presented with too many recipients in a transaction?

(2) Same as (1), but this time regarding limits to the number of mes-
    sages which your SMTP server will accept per connection.

(3) Are there any conditions under which your SMTP server will react
    to an error condition by aborting the entire transaction currently
    in progress and reverting to a "waiting for MAIL command" state?

As with my previous inquiry, please respond directly to me if possible
and I will summarize everything to the mailing list in a couple of
weeks.

Thanks.

-- Rich <wales@UCLA-LOCUS>

Date: 08 Oct 83 11:51:43 PDT (Sat)
From: Marshall Rose <mrose.uci@Rand-Relay>
Return-Path: <Mrose%UCI.UCI@Rand-Relay>
Subject: Re: Message-ID's
Reply-To: MRose@UCI
Message-Id: <267.434487103@UCI>
To: Frankston@Mit-Multics
Cc: Mark Crispin <MRC@Su-Score>, Header-People@Mit-Mc
In-Reply-To: Your message of 8 October 1983 03:58 edt.
Via:  UCI; 8 Oct 83 12:00-PDT

Well, I haven't seen a Message-ID, or Received, or ... header since I've
been using Rand's MH.  If I want to search on a pattern in them, however,
I still can.  These fields are useful, providing that I don't have to see
them every time I look at a message, unless I explictly ask for them.
I'd much rather see a push for everyone getting more sophisticated mail
viewing software, than for us to scrutinize every byte in the headers.

Just out of curiosity, how many people out there have the capability to
view selected parts of the message header?  Please reply directly to me,
I don't want to clutter-up this list with a whimsical curiosity.

/mtr

Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  11 Oct 83 4:41 EDT
Date:     Sat, 8 Oct 83 12:53:46 EDT
From:     Brint Cooper (CTAB) <abc@brl-bmd>
To:       Bob Frankston <Frankston@mit-multics>
cc:       Mark Crispin <MRC@su-score>, Header-People@mit-mc
Subject:  Re:  Message-ID's

PS: This is one of the shorter examples of headers.  It seems
    that the mail-related mailing lists seem to have the
    largest and most encrusted mail headers on the network.



I know that this has been asked before, but doesn't your mail
program strip all specified, unwanted header lines from what
it displays to you?  If you have this capability, you don't 
need to care how long the header is;  you won't see it.

Brint

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 12 Oct 83 03:03:38 PDT
Via:  44c.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK  over Inter-UNIX with SMTP; 
          12 Oct 83 10:51 BST
Date:     12 Oct 83 10:37:29 BST (Wed)
From:     Bruce Skingle <skingle@ucl-cs> (44c)
To:       mrose.uci@rand-relay.arpa
cc:       Frankston@mit-multics.arpa, Mark Crispin <MRC@su-score.arpa>, 
          Header-People@mit-mc.arpa
Subject:  Re:  Message-ID's  and mail viewing software

I was very interested to see your message about sophisticated
mail viewing software, as I am about to embark upon a project
to produce a new user interface for  both the mail and news
systems here at UCL.

Presently we are using MSG for mail and READNEWS for news, and
it is my intention to replace both of these with a single
utility. I do  have several ideas for what it should do but I
will be grateful for any suggestions.

Bruce Skingle.



Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 10 Oct 83 14:38:45 EDT
Date: 10 Oct 83 1449 EDT
From: Rudy.Nedved@CMU-CS-A
To: Rich Wales <v.wales@UCLA-LOCUS>
Subject: Re: Multiple recipients/messages in SMTP
CC: Header-People@MIT-MC
In-Reply-To: "Rich Wales's message of 8 Oct 83 17:35-EST"
Message-Id: <10Oct83.144903.EN0C@CMU-CS-A>

Rich,

Please note a problem exists with "application level timeouts" versus
"multiple recipients". Most Unix sites can accept a number of
recipients but delivermail copies the data to each recipient while
the SENDER WAITS.  The result is when a mailing list like SF-Lovers
sends out a large text message and the connected machine has alot of
individuals receiving it...the sender timeouts waiting for the '250
ack' and punts.

The sender retrys later, meanwhile delivermail is busy delivering
mail. Voila, infinite duplicate mail until one of the mail
maintainers sender or receiver fixes it.

Probably using some formula for a timeout that is dependent on the
size of the message and the number of recipients will do the trick.

-Rudy

Received: from EDUCOM by MIT-MULTICS.ARPA with Mailnet id <2612381548701548@MIT-MULTICS.ARPA>; 13 Oct 1983 17:32:28 edt
Date:     10-OCT-1983 17:56 EDT
From:     OBERST@EDUCOM
To:       Header-People@mit-mc.arpa
Subject:  Quoted @ in To: field

From:     MAILNET         9-OCT-1983 19:07
To:       OBERST
Subj:     MAILNET MAIL From:<@MIT-MULTICS.ARPA:"Jacob Palme QZ"@ODEN.MAILNET>

Received: from ODEN.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2612022005559524@MIT-MULTICS.ARPA>; 09 Oct 1983 13:40:05 edt
Date:        09-Oct-83 12:29-+0100
From:        "Jacob Palme QZ"@ODEN.MAILNET
Reply-to:    "Jacob Palme QZ"@ODEN.MAILNET,
             "Mail transfer (between) York (and) QZ COM/POST systems"@
             ODEN.MAILNET
To:          "Mail transfer (between) York (and) QZ COM/POST systems"@
             ODEN.MAILNET, OBERST@EDUCOM.MAILNET
bcc:         "Richard Edmiston CSNET" <EDMISTON@BBN-UNIX.ARPA>
Subject:     "Jacob Palme QZ@ODEN.MAILNET"@MIT-MULTICS.ARPA
Message-ID:  <Text 25995 @ ODEN.MAILNET>

The subject of this message indicates a TO-field in an incoming
message from SU-SCORE which I got via ARPANET-MAILNET.

As I understand it, such a TO-field would indicate a person
with the name "Jacob Palme QZ@ODEN.MAILNET" since the quotation
marks would invalidate the interpretation of "@" as a "at-host"
indication.

However, obviously the person sending this message meant
the "@" to be an at-host indication, even though it was inside
quotation marks.

How shall I handle this?

Follows the RFC-standards, and getting false information in
my data base. NOT POSSIBLE.

Interpret "@" as an "at-host" sign even when it appears inside
quotation marks, in flagrant violation of the RFC-standards,
and get the COM-MAILNET interface working properly. I guess
this is the only reasonable possibillity!!

Should I also interpret "%" in incoming messages from JNT-mail
as an "at-host" indication even when it appears inside quotation
marks??
(Text 25995)------------------------------  (1 comment)


Date:     Thu, 13 Oct 83 20:22:20 EDT
From:     Doug Kingston <dpk@brl-vgr>
To:       Header-People@mit-mc
Subject:  Re: [OBERST%educom: Quoted @ in To: field]

	The letter to Header-People was illegal in and of itself
since "educom" is not a known Internet host and MC should not have
allowed the address onto the Internet to begin with with out munging
the address.  BRL was forced to stick a "BRL.ARPA" on it to make it
appear reasonable.  Someone should fix MIT's mailer as a start.

					-Doug-

Date: Thu 13 Oct 83 19:18:00-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Quoted @ in To: field
To: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "OBERST@EDUCOM" of Mon 10 Oct 83 17:56:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     So far as I understand, what is within a quoted string on the left
half of the @ is strictly for the entity named in the right half of the
@ to interpret.

     Score's software does not generate addresses such as "a@b"@c.  However,
a Score user (or another system relaying through Score) isn't prevented from
doing this.

     Also, if you see an address such as a%b@c, you have no business trying
to parse the "%b" as meaning "at host b" UNLESS you are entity c.  If you
are entity c, then you have total freedom to interpret it as whatever you
like.  a%b could mean "send to a but give user b a raise in salary" for all
anybody other than c should know, or care.

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

Date: Thu 13 Oct 83 19:18:00-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Quoted @ in To: field
To: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "OBERST@EDUCOM" of Mon 10 Oct 83 17:56:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     So far as I understand, what is within a quoted string on the left
half of the @ is strictly for the entity named in the right half of the
@ to interpret.

     Score's software does not generate addresses such as "a@b"@c.  However,
a Score user (or another system relaying through Score) isn't prevented from
doing this.

     Also, if you see an address such as a%b@c, you have no business trying
to parse the "%b" as meaning "at host b" UNLESS you are entity c.  If you
are entity c, then you have total freedom to interpret it as whatever you
like.  a%b could mean "send to a but give user b a raise in salary" for all
anybody other than c should know, or care.

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

Date: Thu 13 Oct 83 19:24:31-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: [OBERST%educom: Quoted @ in To: field]
To: dpk@BRL-VGR.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Doug Kingston <dpk@brl-vgr>" of Thu 13 Oct 83 17:37:19-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Re: "MIT's mailer should mung the header"

No!  Header munging is a horrible idea.  The source of the message should
take responsibility for generating valid headers, without any second-guessing
from various relays.  Too many valid headers have been munged into nonsense
by well-meaning, but incorrect, header munging algorithms.

It is also impossible to debug a problem with an incorrect header if some
host mungs it.  Who can tell which part was done by the originating host, and
which by the munging host?
-------

Date:     Thu, 13 Oct 83 22:43:17 EDT
From:     Doug Kingston <dpk@brl-vgr>
To:       Mark Crispin <MRC@su-score.arpa>
cc:       dpk@brl-vgr.arpa, Header-People@mit-mc.arpa
Subject:  Re:  [OBERST%educom: Quoted @ in To: field]

	I wish I didn't have to mung, but as long as people continue
to generate illegal headers, or we must deal with primative mail systems,
this will be a necessity if mail is to flow.  You can always ask those
involved.  But not very many people appear to be interested in fixing
their mailers.  I expect that munging, as distasteful as it is, will
continue until all hosts have transitioned to RFC822.

					-Doug-

Received: by ucbvax.ARPA (4.12/4.7)
	id AA03659; Thu, 13 Oct 83 20:57:25 PDT
Date: 12 Oct 83 15:51:22 EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Usenet vs UUCP
Message-Id: <8310121951.AA12255@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA12255; 12 Oct 83 15:51:22 EDT (Wed)
To: header-people@mit-mc.ARPA

(I've been out of town for a week, so to remind everyone:)
	So, before things get completely messed up on one small front...is
	there a consensus on whether the DOMAIN of (typically Unix) machines
	passing around mail and news via a protocol called UUCP should be
	called "USENET" or "UUCP"?  In the present world of unofficial domain
	names I have seen both names used.  It seems that the right name is
	USENET.  I don't really care which it is, just that a standard name
	be chosen.
I concur with Lauren.  While many people refer to the UUCP net as Usenet, they
are misusing the term.  Usenet is defined as "all sites getting the network
newsgroup net.announce", or loosely "all sites getting netnews".  UUCP is
defined as "all sites reachable by electronic mail from ucbvax via
the hosta!hostb!...!hostn!user notation".  What is important is that these
two sets of machines are not the same.  There are roughly 600 machines on
Usenet.  There are an estimated 2000 machines on UUCP.  Almost every Usenet
machine is also on UUCP, although many of them are on other networks (including
the ARPANET) as well.

Note that the definition for UUCP given here is a mail definition, e.g. the
primary use of UUCP is for electronic mail.  This defn does not imply that
UUCP is actually used as a transport protocol.  Some systems use some other
LAN instead of UUCP.  (E.g. in the United Kingdom they use something else;
in Bell Labs some sites use RJE links via an IBM host.)  A few systems even
implement the UUCP protocol over some other transport protocol (e.g. over
a TCP connection.)  It seems like the "reachable via !" defn is more useful,
since the primary thing one wants to do is send mail.  The primary use for
a central registry would be a mail routing program.  (The other functions
supported by the raw protocol, namely file transfer and remote execution,
are only supported via direct links - no routing is allowed.  Remote login
is not supported at all by UUCP, making remote login or file transfer gateways
from UUCP into an Internet impossible.)

One concern that has been expressed is that there is a central contact person
for Usenet, and a master list of sites kept up-to-date.  There is no such
person or list for UUCP, and these must exist to be allowed by ARPA as a
top level domain.  It has been suggested that since a domain is intended
to be a registry and not a transport mechanism, it might make sense for
Usenet to be a top level domain instead of UUCP.  My main reason for
disagreeing with this is that if Usenet were the top level domain, it
would be impossible for those other 1400 sites to get mail.  Since domain
overlap is possible, I suppose it might make sense for BOTH Usenet and UUCP
domains to exist.

Since having a top level domain is a moot point right now (there is only one
top level domain, no matter how qualified any other domain might be), it's
really a matter of planning and naming of existing hosts.  There is a
plan being worked on for a central registry of UUCP hosts.  If this plan is
successful, it will make sense for UUCP to become a top level domain, or
at least as high in the tree as the CSNET, ARPA, and X.25 domains are likely
to become.  (I am speculating about X.25 - perhaps there will be a PUBLIC
domain or some other name to describe Tymnet, Telenet, Datapack, etc.)
We expect to determine within about 3 months whether such a UUCP registry
can be funded.  If not, something else will have to be worked out, as I
am convinced there is a strong need for such a registry.

	Mark Horton
	mark@Berkeley.ARPA
	mark@cbosgd.UUCP

Received: by ucbvax.ARPA (4.12/4.7)
	id AA03690; Thu, 13 Oct 83 20:58:45 PDT
Date: 12 Oct 83 16:31:58 EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Message-ID's
Message-Id: <8310122031.AA12563@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA12563; 12 Oct 83 16:31:58 EDT (Wed)
To: header-people@mit-mc.ARPA

	Sometimes messages get redistributed with additional comments but without
	altering the Message-ID.
Doesn't this violate RFC822?  I fail to see why protection of implementations
that violate the standard should be the reason for a policy decision.

For what it's worth, in Usenet, the Message-ID is CRUCIAL.  Without it we would
be flooded with duplicate messages.  (Sometimes we are anyway, but that's because
some program has broken and keeps feeding the message to inews, which keeps
generating a new Message-ID.)  RFC850 requires the Message-ID on all Usenet
(news) messages.

Using the Message-ID to weed out duplicate mail at the transmission level (e.g.
to prevent loops) is harder than with news, since mail is sent to a mailbox
or person, but news is broadcast everywhere.  With news, if you've seen the
article before on this machine, you can toss it.  With mail, you must remember
the (Message-ID, To) pair (the "envelope" sense of "To") and only discard if
the same pair arises, otherwise mailing lists and routed messages can cause
messages to be lost.

I personally would like to see Message-ID be made mandatory.

	Mark

Posted-Date:  13 October 1983 23:52 edt
Acknowledge-To:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Date:  Thursday, 13 October 1983 23:48 edt
From:  "Barry Margolin"@MIT-MULTICS.ARPA
Subject:  Re: Quoted @ in To: field
To:  Header-People@MIT-MC.ARPA
Message-ID:  <831014034818.442753@MIT-MULTICS.ARPA>

Since the @ was quoted, it is part of the local-address portion, and no
one except MIT-MULTICS (the hub of the Mailnet star) should be
interpreting it.  This is the "correct" way to do what everyone's been
doing with % for a long time.  Once it gets to Multics, it will strip
off the quotes and recognize this as a message which should be forwarded
to the Mailnet host, but that is its business, just as recognizing that
"Margolin" means to send it to my mailbox. Please don't try to subvert
this well-defined mechanism by interpreting stuff to the left of the @.
                                        barmar

Posted-Date:  14 October 1983 11:08 edt
Date:  Friday, 14 October 1983 11:05 edt
From:  "Jeffrey I. Schiller"@MIT-MULTICS.ARPA
Subject:  What to do about non-Internet mail hosts.
To:  Mark Crispin <MRC@SU-SCORE.ARPA>
cc:  dpk@BRL-VGR.ARPA, Header-People@MIT-MC.ARPA, Postel@USC-ISI.ARPA, 
     Saltzer@MIT-MULTICS.ARPA, DClark@MIT-MULTICS.ARPA
Message-ID:  <831014150557.162930@MIT-MULTICS.ARPA>

          Lets get back to the original problem here.  MIT-MULTICS is
connected to several different networks.  One of these is the "MAILNET"
network, which is a mail only network based on autocall modems (and X.25
connections).  Hosts on MAILNET can communicate with the ARPANET by routing
their messages through MIT-MULTICS.  MIT-MULTICS has one mailer that uses one
combined host table for all the networks.  It can either send mail directly to
a host that it is directly connected to, or it can send mail to a "forwarding"
host for networks it isn't directly connected to.

          Now the problem is what are we to do with MAILNET (the we here
refers to the whole Internet world).  Well there are several different
solutions and each has its own problems.  As I see it they are:

 1) Implement DOMAINS. I have no idea why this isn't being persued!
    This appears to be the only good solution, furthermore if it is
    eventually done all the work (some mentioned below) to get around
    not having DOMAINS will have been effectively wasted.

 2) Register all the MAILNET hosts with the NIC. I doubt the NIC would
    like this solution, not to mention that currently the NIC host table
    probably shouldn't have non-Internet hosts in it (nor is it clear
    that the format as implemented even supports this).

 3) Have MIT's mailer rape the headers of messages originated on MAILNET.
    This solution really is a hard problem because of the diversity of
    header formats it would have to deal with. I agree with MRC that this
    is a non solution.

 4) Have all the MAILNET subscriber hosts change their mailers so that
    they specify a from field of the form User%MailnetHost@MIT-MULTICS.
    This is hard because of the number of mailers involved, not to
    mention that it is a real kludge.

 5) Have Internet hosts not communicate with non-Internet hosts. This
    seems silly, though I am sure there are people who probably think
    this is what should be done.

          Note that MIT-MULTICS does correctly generate a return path for mail
originated on MAILNET.

          I am a relatively busy person and would rather not waste time
implementing stop-gap solutions. My attitude so far has been a sit and wait
for DOMAINS (or some similar general solution). I am still waiting...

                    -Jeff

Date: Fri 14 Oct 83 12:35:23-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: HELO command in SMTP
To: Header-People@MIT-MC.ARPA, MsgGroup@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I was reading through RFC 821 looking up the TURN command, and
found a definite statement that HELO is required.  On page 27 of 821,
at the top (this is the last set of paragraphs in 4.1.1), it states:
"The first command in a session must be the HELO command."

     If there are still any individuals who think the HELO command is
optional and that the TOPS-20 mailer is wrong for requiring it, this
should settle that.
-------

Received: from USC-ECL by SU-SCORE.ARPA with TCP; Fri 14 Oct 83 14:47:51-PDT
Date: 14 Oct 1983 14:43-PDT
Sender: ESTEFFERUD@USC-ECL
Subject: Re: HELO command in SMTP
From: Einar Stefferud - MsgGroup Moderator <MsgGroup-request@brl>
Reply-To: msggroup-request@BRL
To: MRC@SU-SCORE
Cc: Header-People@MIT-MC, MsgGroup@MIT-MC
Message-ID: <[USC-ECL]14-Oct-83 14:43:28.ESTEFFERUD>
In-Reply-To: The message of Fri 14 Oct 83 12:35:23-PDT from Mark Crispin <MRC@SU-SCORE.ARPA>

OK.  Now lets keep the remaining traffic on ths topic in
Header-People only, Please!  Thanks - Stef

Received: by ucbvax.ARPA (4.12/4.7)
	id AA03740; Fri, 14 Oct 83 13:10:02 PDT
Date: 14 Oct 83 16:06:54 EDT (Fri)
From: ulysses!smb@Berkeley (Steven Bellovin)
Subject: Re:  [OBERST%educom: Quoted @ in To: field]
Message-Id: <8310142006.AA16104@ulysses.UUCP>
Received: by ulysses.UUCP (3.327/3.7)
	id AA16104; 14 Oct 83 16:06:54 EDT (Fri)
To: header-people@mit-mc

There's no way to avoid header-munging, even with 822-compatible
mailers.  Suppose, I, on host foo, send a letter to a mailing list
address on bar.  If foo and bar are in the same domain, my mailer
should quite properly generate 'to: list@bar' and 'from: me@foo'.
But suppose list@bar expands to user1@bar, user2@bletch.arpa?  At
that point, the list expander has to mung my perfectly legal headers
to add domain qualifiers.

Not that I like that -- you should see what the headers on these notes
look like by the time they reach me....

Date:  Friday, 14 October 1983 18:16 edt
From:  Gary M. Palter <Palter@MIT-MULTICS.ARPA>
Subject:  Re: [OBERST%educom: Quoted @ in To: field]
To:  Header-People@MIT-MC.ARPA
In-Reply-To:  Message of 14 October 1983 16:06 edt from "ulysses!smb at UCB-VAX (Steven Bellovin)"
Message-ID:  <831014221627.091947@MIT-MULTICS.ARPA>

If you read RFC822 carefully, you will see that it requires that all
domain names in messages that are actually transferred between systems
be fully qualified.

Date: Fri 14 Oct 83 16:39:37-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  [OBERST%educom: Quoted @ in To: field]
To: ulysses!smb@UCB-VAX.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "ulysses!smb@Berkeley (Steven Bellovin)" of Fri 14 Oct 83 16:06:54-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

So far as I'm concerned the issue about what happens with addresses
getting indirectly expanded outside of a local domain is precisely
the reason why mailsystems should never generate any address short
of the fully specified domain address in headers.

If this simple step is taken, there is no need to mung headers in
the 822 world.
-------

Acknowledge-To:  Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Date:  Saturday, 15 October 1983 00:56 edt
From:  "Barry Margolin"@MIT-MULTICS.ARPA
Subject:  Re: What to do about non-Internet mail hosts.
To:  Schiller@MIT-MULTICS.ARPA
cc:  Header-People@MIT-MC.ARPA
Message-ID:  <831015045655.662311@MIT-MULTICS.ARPA>

     Date:  Friday, 14 October 1983 11:05 edt
     From:  Jeffrey I. Schiller

      1) Implement DOMAINS. I have no idea why this isn't being persued!
         This appears to be the only good solution, furthermore if it is
         eventually done all the work (some mentioned below) to get around
         not having DOMAINS will have been effectively wasted.

There is another whole mailing list devoted to review of domain
implementation: NameDroppers.  Recently three draft RFC's were announced
to this group, one of which is a schedule of a phased switch to domain
style addressing.  The plan described is supposed to be completed in
about a year.  I think these drafts are available as RFC-XXX, RFC-YYY,
and RFC-ZZZ from the NIC.
                                        barmar

Date:  4-Oct-83 10:50 PDT
From: Kirk Kelley  <KIRK.TYM@OFFICE-2>
Subject: Re: Message-ID's
To: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
Cc: Header-People@MIT-MC
Message-ID: <[OFFICE-2]TYM-KIRK-3A8B0>
In-reply-to: <"MS11(2347)+GLXLIB1(1056)" 11956815040.31.71.26901 at DEC-MARLBORO> <831004084004.9.RWK@SCRC.SCRC>
References-to: Message from Robert W. Kerns <RWK@SCRC-TENEX> of 4-Oct-83 
0850-EDT

You will notice that the Augment mail system I'm using also uses the identifier 
field for traceing messages.  It must create its own identifier for stuff coming
from outside mail systems, like RFC-822, even if one already exists.  
Identifiers are used inside Augment mail in these fields among others:

   supersedes

   superseded

   part-of

   parts

   addendum-to

   addenda

   in-reply-to 

   replies

We are not currently attempting to delete duplicate messages but it would be 
nice if we could use identifiers to help do that.

 -- kirk


Date: 5 Oct 1983 0826-PDT
Sender: WMARTIN at OFFICE-3
Subject: Unique identifier for messages
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN>

Wouldn't a good way to uniquely identify messages, given the
problem of changed messages having the Message-ID unchanged, be a
combination of an originally-assigned Message-ID field and the
number of characters in the Text field?  Most duplicate messages
I've seen have different character-counts for the entire message,
because the header has more fields or more data in a field, but
the Text is identical.  Since most message-systems seem to use
the character-count for various purposes, would it be hard to
just count the characters in the Text field alone?  I would think
that it would be safe to program a system to assume duplicates
exist if both the Message-ID and the Text field character-count
were identical.  If there was no Message-ID, of course, such a
message wouldn't be considered as a candidate for being a
duplicate, even if it was.  (I doubt that it would be safe to
consider messages to be duplicates if both had null Message-ID's
and identical Text-field character-counts -- too much margin for
error in that case.)

Will Martin

Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2612524176306174@MIT-MULTICS.ARPA>; 15 Oct 1983 09:09:36 edt
Date: Sat, 15 Oct 83 00:02:16 EDT
From: "Gavin Eadie"@UMich-MTS.Mailnet
To: Header-People@MIT-MC.ARPA
Message-ID: <249874@UMich-MTS.Mailnet>
Subject: Puzzled thoughts from a non-Internetter

This is a message displayed in the MTS (Michigan Terminal System)
conference system FORUM for comment from the various people who are
interested in such things. It follows on from (not coincidentally)
recent discussions in this group.

I implemented an RFC821/822 system recently and, though I would
call myself a skilled and experienced programmer, I feel it is a
small miracle that it works. I based my entire implementation on
the RFCs, my header parser *IS* the grammar taken from 822, the
MTS implementation of SMTP follows 821 slavishly ... The results
of this are two:

  1. The only SMTP code that I communicate with (other than copies
     of my own at other MTS sites) is that at MIT-Multics - which,
     sad to relate, doesn't quite manage to accept:

          RCPT TO:<@MIT-MULTICS:"John Doe"@RPI-MTS>

     and generates many wonderful variations on the headers in 822!
     Assuming that people in this business longer than me had got
     it right wasted lots of my time!

  2. I never heard of the use of "%" till after my implementation
     was complete. Now (as you will read below) I have to decide
     to retrofit it - ugh.

But wait, all this sounds like a complaint -- it is not, I've had
lots of fun sorting this stuff out and appreciate all the help I
had from the MIT folk and people in this group. All I'm trying to
illustrate is how a newcomer sees some of this.

----------

U-M is a member of two mail networks (MAILNET and the 'MTSnet') and
some other MTS sites are contemplating doing the same. This raises
a few technical problems which I'd like to raise for discussion
here between the mail-wizards. We could have this discussion via
$MESSAGE but that means everyone keeps a wasteful archive. FORUM
also helps to organise a single thread discussion.

The mail protocols we use in Mailnet and MTSnet were developed and
are used within the ARPA community. They are called RFC821 and
RFC822 and, unlike most 'standards', were written as attempts to
make a good summary of what everyone was already doing - rather
than as a rulebook.

The MTSnet (composed now of seven MTS installations) could happily
use these protocols within a closed community with no problems. So
could a closed Mailnet community and so, obviously, does the closed
ARPA community. Severe problems arise as soon as mail has to move
between any of these communities.

The protocols include mechanisms for operating across 'community'
borders, but (i) the 'powers that be' within ARPA do not recognise
non-ARPA communities and (ii) few mailers have implemented the new
scheme.

The result is ad hoc mechanisms. There are no formal descriptions
of these - they are strictly folk-lore. As one who is speaking from
experience, implementing an ARPA mailer from only the protocol
descriptions is impossible.

We (the MTS folks) need to resolve this for ourselves. We cannot be
too inventive, since several ad hoc schemes already exist, but we
have to do something because we are moving rapidly towards needing
some solution. The problem arises both as MTSnet communicates with
Mailnet and as Mailnet communicates with ARPA. (It is compounded by
needs for MTSnet to talk with CSnet, BITNET, UUCP, the UK mail net
and (undoubtedly) others.

The most popular ad hoc scheme involves the use of the percent (%)
symbol to indicate explicit routing of mail - this kluge is used
so widely that (i) some people think it is official and (ii) the UK
mail net had adopted it in their standard.

Let me draw one of my famous pictures:

              +------------------+
              |community 'A'     |
              |                  |
              |   +----+         |
              |   |X   |  +------|-----------+
              |   |fred|  |+----+|           |
              |   +----+  ||Y   ||           |
              |           ||joan||  +----+   |
              |           |+----+|  |Z   |   |
              +------------------+  |rich|   |
                          |         +----+   |
                          |                  |
                          |     community 'B'|
                          +------------------+

(((NB: In everything that follows my use of the prime (') is as
   a delimiter in my writing - it is never part of an address.)))

We have three sites in two communities (the site 'Y' is a gateway).
Within the 'A' community 'X' and 'Y' can exchange mail using the
ARPA protocols. They refer to each other as 'X.A' and 'Y.A' (using
their complete formal names) or just as 'X' and 'Y' (since all the
host names in a community are known to the other hosts).

A user at 'X' would send mail to 'joan@Y' or 'joan@Y.A' and when it
arrived it would be from 'fred@X' or 'fred@X.A'. We would see an
analogous process in the 'B' community.

Now consider a message which must travel from 'X' to 'Z'. We assume
that 'Z' is not known to the 'X' mail software (otherwise this is a
silly example) and that the user must explicity tell the 'X' mailer
to get the mail to 'Z' via 'Y'.

One option is to change that assumption by extending the knowledge
of site names so EVERY site in the universe knows the name of EVERY
other one. We reject this as impractical!

The next option is to use the protocol. This may seem obvious, but
remember that virtually nobody does - if they did, a user at 'X'
would send to '@Y.A:rich@Z.B' and it would turn up at 'Z' marked as
being from '@Y.B:fred@Z.A'.

In fact, what we often see is the use of the percent kluge, so the
mail is sent to 'rich%Z.B@Y'. This is the popular solution - it is
actually the formal solution in the UK - so we ought to adopt it.

This need is most urgent for the RPI people - they are members of
Mailnet but not MTSnet so they can get mail to UM (also in Mailnet)
but no further becuase the NETMAIL program doesn't process the '%'
kluge.

As I've written this, I've become more convinced that my only 'out'
is to implement the percent-kluge. I'm posting this here so that
anyone has an change to comment. I'm posting it on the ARPAnet too
so they can see the pickle I'm in.

----------

Due to the fact that my mailer isn't generating names with "%" in
them, I've no idea what the 'From:' field on this will look like
when you read this. I know at least one person who I upset when
every message I send him has to be manually edited before he can
reply ...

I am:                          Gavin_Eadie%UMICH-MTS@MIT-MULTICS

Date: Sat 15 Oct 83 15:01:33-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Puzzled thoughts from a non-Internetter
To: Gavin_Eadie%UMich-MTS@MIT-MULTICS.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from ""Gavin Eadie"@UMich-MTS.Mailnet" of Sat 15 Oct 83 06:32:12-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Hi.  I'm the mailsystem developer for the TOPS-20 operating
system, or at least the developer for the TOPS-20 SMTP software
and one of the more popular mail composition/reading programs.
Maybe I might be able to give you some info.  Much of this is
rather tutorial, so most of the Header-People members probably
ought to ignore the rest of this message unless they're
interested in some internals of the TOPS-20 mailer.

     The SMTP command:
	RCPT TO:<@MIT-MULTICS:"John Doe"@RPI-MTS>
 is syntactically correct and the TOPS-20 mailsystem does accept
it.  However, I should point out that the host name RPI-MTS is
not an Internet host name.  Unless MIT-MULTICS has extended its
SMTP for use outside of Internet (I suspect it has) it would be
quite correct in declining to accept the command on those
grounds.

     There is but one reason why "%" exists, and that is to allow
what we call "small-i internet" mailing -- that is, mail between
Internet and other electronic mail communities.  In the old days
of RFC 733, a syntax called "multiple ats" existed, where you had
addresses such as
	user at host1 at host2

     Unknown to most of the world, it was decided that multiple
ats were not a good idea and the syntax was pulled from the
specification (although it was still in the published RFC 733
specification).  I was one of the people who was caught unaware
by this.  I was forced to look for an alternative.  For a while I
considered SMTP source routing, but to my dismay discovered that
it was invalid to have any host name other than a duly registered
Internet host name in an SMTP path name.  This has the effect of
making source routes totally useless except for debugging traces
(and the Received: header line is much more useful for this
purpose).  I therefore had to stick with "multiple at" syntax,
but hide it within the present confines of RFC 822.  Everything
pointed me towards "%".  For TOPS-20 systems, "%" is quite
attractive as a special character in a mailbox name as it is
guaranteed never to be part of a valid user name (it is a
wildcard character and its use in a user name string when a
wildcard is invalid will cause an invalid system call trap).  The
SU-AI mailsystem had used "%" for "@" in its user interface for a
long time due to its gothic parser, and other software allowed
"%" as an alternate for the benefit of TIP users.  I was vaguely
aware of the UK system, but what I did was really independent of
what the UK had.  The "%" syntax is a "multiple at" syntax hidden
under RFC 822; the UK syntax, while (deceptively) similar, has
several operational differences.

     There are two important things to realize.

     First, the "%" character is "official" only so far as the
small-i internet mail bridge (some people call them "relays") you
are using sets the rules.  If you are using a TOPS-20 system as a
mail bridge, you use "%" to relay through it.  If you're using
MMDF, the magic character is ".".  UUCP uses "!", although in
reverse order.  Apparently Multics uses the same rule as TOPS-20.
If you don't deal with a mail bridge, you have no reason to know
about "%", ".", "!", etc.  If you do, the responsibility for such
knowledge lies with the user.  Some software, such as TOPS-20's
mailsystem, provides the service of registering small-i internet
names so its users can say "user@host" but it will be magically
transmogrified into the appropriate syntax for the appropriate
relay.  For example, the TOPS-20 mailsystem knows that:
	foo@arizona	becomes	 foo.arizona@RAND-RELAY.ARPA
but:	foo@MIT-EECS	becomes  foo%MIT-EECS@MIT-MC.ARPA
 Some people would say the TOPS-20 mailsystem is presumptious in
having this knowledge, but it is specified in a special registry
and not wired into the software.

     This leads me to the second thing to remember: you have no
business trying to pull apart an "%" address unless you are the
mail bridge to the right of the "@".  Under no circumstances does
the TOPS-20 mailsystem ever pull such an address apart; it just
has some clever code to help users put them together.  If you see
an address such as:
	foo%Shasta@SU-SCORE.ARPA
 your mailsystem shouldn't know or care if this is user "foo" at
some machine called "Shasta" known to SU-SCORE.ARPA or if it is
going to Charlie foo%Shasta, our exchange student from Upper
Funnylastnameland.  Your users, on the other hand, may know that
the "%" syntax through SU-SCORE.ARPA enables them to send mail to
sites on Stanford's LAN.

     Until such time as we have domains to validly specify
small-i internet sites within the context of a valid host name in
SMTP, you will have to use some kludge such as (but not
necessarily) "%" to hide your host names inside a valid Internet
host name.

-- Mark --

PS: For your enjoyment, here's a list of the current TOPS-20
mailer automatic transmogrification rules for various mail
bridges.  I've been trying to get a list of the sites for Mailnet
but haven't had much luck:

;  This file defines the sites which can be accessed via a mail
; relay.  Some liberties are taken with the concept of domains
; to make this work; a domain here must be thought of as a top-
; level domain in the Internet sense; in other words, a mail
; registry.
;
;  This file contains text lines of the format:
;DOMAIN <domain>,<character><host>,<relays>
;	or
;HOST <domain>,<primary>,<nicknames>
; where:
;
; <domain>	::= domain name
; <c>		::= character to use in transmogrification
; <host>	::= host to use in transmogrification.  This
;			is text.  It must have any domain names
;			etc. that you want
; <relays>	::= list of relay hosts
; <primary>	::= primary host name, without domain
; <nicknames>	::= list of nicknames
;
;  DOMAIN defines a domain, while HOST defines a host in a
; particular domain.  Transmogrification refers to the necessary
; steps to coerce the given host name into a valid Internet name
; in the actual message header.  As of this writing (3/19/83),
; ARPA is the only valid domain name.  Consequently, an address
; such as MRC@MIT-EECS.MIT-CHAOS must be coerced into something
; like MRC%MIT-EECS@MIT-MC.ARPA.
;
DOMAIN CCnet-Columbia,%COLUMBIA-20.ARPA,COLUMBIA-20,CMU-CS-C
DOMAIN CCnet-CMU,%CMU-CS-C.ARPA,CMU-CS-C,COLUMBIA-20
DOMAIN CSnet-East,.UDEL-RELAY.ARPA,UDEL-RELAY
DOMAIN CSnet-West,.RAND-RELAY.ARPA,RAND-RELAY
DOMAIN MIT-Chaos,%MIT-MC.ARPA,MIT-MC,MIT-XX,MIT-ML
DOMAIN NYU,.NYU.ARPA,NYU
DOMAIN SU-Pup,%SU-SCORE.ARPA,SU-SCORE,SUMEX-AIM
DOMAIN TLnet,%CMU-CS-C.ARPA,CMU-CS-C
;
HOST CCnet-CMU,CMCCTA
HOST CCnet-CMU,CMCCTB
HOST CCnet-CMU,CMCCTC
HOST CCnet-CMU,CMCCTD
HOST CCnet-CMU,CMCCTE
HOST CCnet-CMU,CMCCTF
HOST CCnet-CMU,CMCSC
HOST CCnet-Columbia,CU20A
HOST CCnet-Columbia,CU20B
HOST CCnet-Columbia,CU20C
HOST CCnet-Columbia,CU20D
HOST CCnet-Columbia,CUCS20
HOST CCnet-Columbia,CUTC20
HOST CCnet-CMU,CWR20B
HOST CCnet-CMU,CWRU20
HOST CSnet-East,anad
HOST CSnet-East,bci,ascii-network
HOST CSnet-East,brandeis
HOST CSnet-East,brown
HOST CSnet-East,btl-mh,btlmh,btl-owl,owl,labs,bell-labs,belllabs
HOST CSnet-East,buffalo-cs,bufcs,suny-buf,buffalo
HOST CSnet-East,case,case-western,cwru
HOST CSnet-East,ccp-onyx01,ccp-onyx1,ccp1
HOST CSnet-East,ccp-onyx02,ccp-onyx2,ccp2
HOST CSnet-East,cda-pdp01
HOST CSnet-East,cda-pdp1,cda
HOST CSnet-East,cdrm-onyx01,cdrm-onyx1
HOST CSnet-East,cic-test
HOST CSnet-East,cis-onyx01,cis-onyx1,cis1
HOST CSnet-East,cis-onyx02,cis-onyx2,cis2
HOST CSnet-East,clemson
HOST CSnet-East,cms
HOST CSnet-East,cms-onyx01
HOST CSnet-East,cms-onyx1
HOST CSnet-East,darcom-hq,darcom-dhq,dhq,darcom,hq
HOST CSnet-East,darcom-o2,darcom2
HOST CSnet-East,digital,dec-csnet,dec-crg,dec-hudson
HOST CSnet-East,duke
HOST CSnet-East,gatech,ga-tech,georgia-tech,git,georgia,gatch
HOST CSnet-East,hp-avn,mushroom,hp-avondale
HOST CSnet-East,igw-onyx02,igw-onyx2,igw2
HOST CSnet-East,jhu,hopkins,johns-hopkins
HOST CSnet-East,kentvax,kent,ksu
HOST CSnet-East,mep-onyx01,mep-onyx1,mep1
HOST CSnet-East,micom,micom-onyx,micom1
HOST CSnet-East,northeastern,nuacs
HOST CSnet-East,nsf-cs,nsf,onyx,nsfcs
HOST CSnet-East,penn-state,psuvax1
HOST CSnet-East,pitt,upitt,pittsburgh,u-pitt
HOST CSnet-East,pmdf-test
HOST CSnet-East,princeton,princ,prin,prinu
HOST CSnet-East,psp
HOST CSnet-East,psp-onyx01
HOST CSnet-East,quaker,reilly-pc,philly
HOST CSnet-East,qucis,queens,qu
HOST CSnet-East,rpi,rensselaer,rip,tute
HOST CSnet-East,scarolina,carolina,scar
HOST CSnet-East,suny-sbcs,suny-sb,suny-stony,suny,sb-cs,sbcs,stony-brook
HOST CSnet-East,syr
HOST CSnet-East,udel-cc-relay
HOST CSnet-East,udel-cc-vax1,udccvax1,udel-cc
HOST CSnet-East,udel-cc-vax2,udccvax2,udelccvax2
HOST CSnet-East,udel-ee,eevax,udel-ee-vax,udvax,udel-vax,udee-vax,udel-eecis1
HOST CSnet-East,udel-eecis2
HOST CSnet-East,udel-eecis3,udel-ee70
HOST CSnet-East,umass-boston,umb,umass-boss,um-boston,umboston
HOST CSnet-East,umass-cs,umass,umass-coins
HOST CSnet-East,umass-ece,umass-ecs
HOST CSnet-East,umcp-cs,umcp,umaryland-college-park,umaryland,umaryland-cp,maryland-cp
HOST CSnet-East,umich-ciprnet,umich,umich-cv,umich-cipr,cipr
HOST CSnet-East,unc,dopey,unc-dopey,unc-ch,uncch,chapel-hill
HOST CSnet-East,unc-bashful,bashful
HOST CSnet-East,unc-grumpy,unc-grumpey,grumpy,grumpey
HOST CSnet-East,unc-happy,happy
HOST CSnet-East,unc-sleepy,sleepy
HOST CSnet-East,unh,unh-csvax
HOST CSnet-East,upenn,penn,upenn-cs,upenn-cis,penn-cis,penn-cs
HOST CSnet-East,upenn-750,penn-750,upenn750,penn750
HOST CSnet-East,uwmeecs,uwm-eecs,uwm
HOST CSnet-East,virginia,uvirgin,uva,uva-cs,uvacs,uvirginia
HOST CSnet-East,vlsivax,princeton-vlsi,prin-vlsi
HOST CSnet-East,wang-inst,wang-igs,wang-institute
HOST CSnet-East,xam-onyx01,xam,drxam
HOST CSnet-East,xig-onyx01,xig-onyx1,xig1
HOST CSnet-East,xls-onyx03,xls-onyx3
HOST CSnet-East,xls-plexus01,xls-plexus1,plx1
HOST CSnet-East,xls-unix3,xls-unix03,pdp3,pdp03
HOST CSnet-East,xlslp-onyx01,xls-onyx01,chamb
HOST CSnet-East,xmm-onyx01,xmm,xmm-onyx1
HOST CSnet-East,xos-onyx01,xos-onyx1,xos1
HOST CSnet-West,arizona,az
HOST CSnet-West,atari
HOST CSnet-West,boulder
HOST CSnet-West,ct,ctvax
HOST CSnet-West,depaul
HOST CSnet-West,emory
HOST CSnet-West,hp-hewey,hewey,hp-venus
HOST CSnet-West,hp-hulk,hulk
HOST CSnet-West,hp-labs,hp,hewlett-packard,hplabs,hpvax,hp-vax
HOST CSnet-West,hp-mars
HOST CSnet-West,hp-mercury
HOST CSnet-West,hp-thor,thor
HOST CSnet-West,ibm-sj,ibmsj,ibm-sjrlvm1,ibm,sjrl
HOST CSnet-West,indiana,iuvax,iucs
HOST CSnet-West,kansas-state,kanstate
HOST CSnet-West,nmt,nmtvax,cerebus,newmexicotech,new-mexico-tech
HOST CSnet-West,nwu
HOST CSnet-West,ohio-state,osu-dbs,osu-cis
HOST CSnet-West,oregon-grad,ogcvax,ogc,oregon
HOST CSnet-West,oregon-state,orstcs
HOST CSnet-West,portland
HOST CSnet-West,rice
HOST CSnet-West,tamu,texam
HOST CSnet-West,tektronix,tek,tekcrd
HOST CSnet-West,uabcs,alabama,alabama-cs,uab
HOST CSnet-West,ubc,ubc-ean,ean
HOST CSnet-West,ucf-cs,ucfl-cs,ucf,ucfl,central-florida,florida
HOST CSnet-West,uci-20a
HOST CSnet-West,uci-20b
HOST CSnet-West,uci-750a
HOST CSnet-West,uci-750b
HOST CSnet-West,uci-vax
HOST CSnet-West,uci
HOST CSnet-West,ucsb,ucsbcsl,ucsbcsil
HOST CSnet-West,ucsc,santacruz,ucsccis
HOST CSnet-West,ufl,ufla
HOST CSnet-West,uiowa,iowa
HOST CSnet-West,uiuc,uiucdcs
HOST CSnet-West,ukans,ku,ukan
HOST CSnet-West,umiss,olemiss,
HOST CSnet-West,umn-cs,mn-cs,minn-cs,min,minn,umncsci,umn-csci,uminn,umin,uminn-cs,minncs,mncs
HOST CSnet-West,usc-cse,uscvax
HOST CSnet-West,usl
HOST CSnet-West,utd-cs,utd,dallas,ut-dallas,utexas-dallas
HOST CSnet-West,vanderbilt,vand,vandy,vanderbuilt,vanderbiult,vu
HOST MIT-Chaos,MIT-ALCATOR,ALCVAX,ALCATOR
HOST MIT-Chaos,MIT-CCC,MITCCC,CCC
HOST MIT-Chaos,MIT-CIPG,CIPG
HOST MIT-Chaos,MIT-COG-SCI,MIT-COGS,COGS
HOST MIT-Chaos,MIT-CORWIN,CORWIN
HOST MIT-Chaos,MIT-DEVO,DEVO
HOST MIT-Chaos,MIT-DSPG,DSPG
HOST MIT-Chaos,MIT-EDDIE
HOST MIT-Chaos,MIT-EECS,EE,EECS,MITEE,MIT-EE,MIT-DEEP-THOUGHT,DEEP-THOUGHT
HOST MIT-Chaos,MIT-GOLEM,GOLEM,MIT-TALOS,TALOS
HOST MIT-Chaos,MIT-HEART-OF-GOLD,HEART-OF-GOLD,MIT-HOG,HOG
HOST MIT-Chaos,MIT-HEPHAESTUS,HEPHAESTUS,MIT-VULCAN,VULCAN
HOST MIT-Chaos,MIT-HTJR,HTJR,HTBROKE
HOST MIT-Chaos,MIT-HTVAX,HT,HTVAX,HTUNIX
HOST MIT-Chaos,MIT-MARIE,MARIE,MIT-LNS
HOST MIT-Chaos,MIT-MATH,MATH,MITMATH
HOST MIT-Chaos,MIT-NICK,NICK
HOST MIT-Chaos,MIT-OBERON,OBERON,OBI
HOST MIT-Chaos,MIT-OZ,OZ,PUMPKIN,AI20,MIT-AI20,MIT-AI,AI,MITAI
HOST MIT-Chaos,MIT-PAMELA,PAMELA,MIT-PAM,PAM
HOST MIT-Chaos,MIT-PFC-VAX,PFCVAX,PFC-VAX
HOST MIT-Chaos,MIT-PIERRE,PIERRE
HOST MIT-Chaos,MIT-PREP-VAX,MIT-PREP,PREP
HOST MIT-Chaos,MIT-PYGMALION,PYGMALION,MIT-ROBOTICS
HOST MIT-Chaos,MIT-SPEECH,SPEECH,NSPEECH
HOST MIT-Chaos,SCH-COYOTE,COYOTE
HOST MIT-Chaos,SCH-LOKI,LOKI
HOST MIT-Chaos,SCRC-COMET,COMET
HOST MIT-Chaos,SCRC-CUPID,CUPID
HOST MIT-Chaos,SCRC-TENEX,SCRC
HOST MIT-Chaos,SCRC-VIXEN,VIXEN
HOST NYU,NYU-ACF1,ACF1
HOST NYU,NYU-ACF2,ACF2,NYU-ADA
HOST NYU,NYU-CMCL1,CMCL1
HOST NYU,NYU-CMCL2,CMCL2,NYU-UNIX
HOST SU-Pup,SU-Ardvax,Ardvax
HOST SU-Pup,SU-Carmel,Carmel
HOST SU-Pup,SU-CIT,CIT-750,CIT
HOST SU-Pup,SU-CIT1,CIT1
HOST SU-Pup,SU-CIT2,CIT2
HOST SU-Pup,SU-Fuji,Fuji
HOST SU-Pup,SU-Glacier,Glacier,FTAL,FTAL-Vax
HOST SU-Pup,SU-GSB-HOW,GSB-HOW,HOW
HOST SU-Pup,SU-GSB-WHY,GSB-WHY,WHY
HOST SU-Pup,SU-Helens,Helens
HOST SU-Pup,SU-HNV,Diablo,HNV,SU-HPP-NG-VAX
HOST SU-Pup,SU-ISL,ISL,Tamalpais,Tam,ISL-VAX
HOST SU-Pup,SU-Lassen,Lassen,IFS
HOST SU-Pup,SU-Navajo,Navajo,NA-VAX
HOST SU-Pup,SU-Psych,Psych,Psych-Vax,SU-Tahoma,Tahoma,Turtle-Vax
HOST SU-Pup,SU-Shasta,Shasta
HOST SU-Pup,SU-Sierra,Sierra,SU-EE,EE
HOST SU-Pup,SU-Whitney,Whitney,SU-Robotics
HOST SU-Pup,SUMEX-2020,AIM-2020,Tiny
HOST SU-Pup,SUMEX-VAX,SAFE,SU-SAFE
HOST TLnet,TARTAN
-------

Date:  Sunday, 16 October 1983 14:02 edt
From:  Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller)
Subject:  Re: Puzzled thoughts from a non-Internetter
To:  Mark Crispin <MRC@SU-SCORE.ARPA>
cc:  Header-People@MIT-MC.ARPA, Gavin_Eadie@UMICH-MTS.MAILNET
In-Reply-To:  Message of 15 October 1983 18:01 edt from "Mark Crispin"
Message-ID:  <831016180220.545588@MIT-MULTICS.ARPA>

The Multics mailer works very similarly to the TOPS-20 mailer. We accept
both "%" and "@" characters as user/host separators. A user on Multics
doesn't have to know on what network the host he is communicating with
is connected. For example at the moment Multics isn't on the ChaosNet
here at MIT (this is being worked on, but slowly) so when a user
specifies mail say for MIT-EECS (which is only on the ChaosNet) the mail
system automatically translates this to USER%MIT-EECS at MIT-MC (or
whatever other host is in the host table as the chaos net forwarding
host).

The real problem comes in the from field. Gavin can send mail from his
machine (which is on MAILNET) to any Internet/ChaosNet/Mailnet host
without having to have any knowledge as to what network the host is
actually connected. Because all of his MAILNET mail is routed through
MIT-MULTICS (one of the specifications of MAILNET) MIT-MULTICS arranges
to forward it on. HOWEVER UMich-MTS doesn't know what host is where, and
assumes that ALL HOSTS (Internet and non-Internet alike) know of all
other hosts and thus supplies Gavin_Eadis at UMich-MTS as the return
address. Of course Multics (actually any Multics on the Internet running
with the MIT-MULTICS host table) can deal with this because it knows
about UMich-MTS. Of course not all Internet hosts have this knowledge. I
could supply SCORE for example with the MAILNET host table and then
users on SCORE will be able to reply directly to Gavin.

However there are people out there who don't want to have to worry about
picking up non-Internet host tables, and want the responsibility for the
message header to be placed on the Mail bridge. Of course from my point
of view (the mail bridge maintaner) I would rather not have my mail
system parsing someone elses headers for a message not destined on my
host.

                    -Jeff


Date:     Sun, 16 Oct 83 17:18:07 CDT
From: Paul Milazzo <milazzo.rice@Rand-Relay>
Return-Path: <milazzo%rice.Rice@Rand-Relay>
Subject:  Unofficial Domains
To: Mark Crispin <MRC@su-score>
Cc: Header-People@MIT-MC
Message-Id:  <1983.10.16.17.18.07.050.02609@Rice-vms.rice>
In-Reply-To: Mark Crispin's message of Sat 15 Oct 83 15:01:33-PDT
Via:  Rice; 16 Oct 83 18:02-PDT

Mark,

I strongly sympathize with your implementation of a private domain list
for use by your local mailer, but I have two reservations:

  1) You must insure that the private domain notation never escapes
     your local environment, as it did in the following header:

     > Date: Fri 9 Sep 83 07:42:38-PDT
     > From: Norm Kincl <G.Norm@SU-SCORE>
     > Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 10:43:39-EDT
     > Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 9 Sep 83 08:34:17 PDT (Fri)
     > Subject: CPM/86, TELENET
     > To: Info-Kermit@COLUMBIA-20
     > Reply-To: Kincl@HP-Labs.CSnet-West

  2) Keeping the database current is difficult without outside help.
     For example, your table correctly contains the line:

     HOST CSnet-West,rice

     However, Rice will soon become an Internet site via CSNet/TELENET,
     and you will then be able to speak SMTP directly to my host.  But
     will you do so?  Your host-table update procedure may well include
     a scan of your unofficial domain list for hosts newly registered
     with the NIC, but will everyone to whom you have now distributed
     said list do the same?

     I believe I understand your motivations and I do not mean to
     denigrate your decision to allow the local use of unregistered
     host names and unofficial domains.  After all, the CSNet/MMDF
     software does essentially the same thing for CSNet and ARPANET
     sites.  Still, the CSNet CIC acts as a central naming and name
     distribution authority, something which you do not have.  Simply
     compiling a static list of sites is, as I'm sure you realize, not
     the complete answer.

                                Paul Milazzo <milazzo.rice@rand-relay>
                                Dept. of Mathematical Sciences
                                Rice University, Houston, TX


Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Mon 17-Oct-83 08:55:31-EDT
Date: Mon, 17 Oct 83 08:51 EDT
From: Charles Hornig <Hornig@SCRC-TENEX>
Subject: Re: Puzzled thoughts from a non-Internetter
To: Jeffrey I. Schiller <Schiller@MIT-MULTICS>, Mark Crispin <MRC@SU-SCORE>
Cc: Header-People@MIT-MC, Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS
In-reply-to: <831016180220.545588@MIT-MULTICS.ARPA>
Message-ID: <831017085117.2.Hornig@SCRC.SCRC>

    Date:  Sunday, 16 October 1983 14:02 edt
    From:  Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller)
    The real problem comes in the from field. Gavin can send mail from his
    machine (which is on MAILNET) to any Internet/ChaosNet/Mailnet host
    without having to have any knowledge as to what network the host is
    actually connected. Because all of his MAILNET mail is routed through
    MIT-MULTICS (one of the specifications of MAILNET) MIT-MULTICS arranges
    to forward it on. HOWEVER UMich-MTS doesn't know what host is where, and
    assumes that ALL HOSTS (Internet and non-Internet alike) know of all
    other hosts and thus supplies Gavin_Eadis at UMich-MTS as the return
    address. Of course Multics (actually any Multics on the Internet running
    with the MIT-MULTICS host table) can deal with this because it knows
    about UMich-MTS. Of course not all Internet hosts have this knowledge. I
    could supply SCORE for example with the MAILNET host table and then
    users on SCORE will be able to reply directly to Gavin.

    However there are people out there who don't want to have to worry about
    picking up non-Internet host tables, and want the responsibility for the
    message header to be placed on the Mail bridge. Of course from my point
    of view (the mail bridge maintaner) I would rather not have my mail
    system parsing someone elses headers for a message not destined on my
    host.

Don't forget that ALL of the information needed to reply to a
non-Internet mail address is contained in the Return-path: field.  Just
concatenate it with each address.  If you know better, you can optimize
this, but it will always work.  I don't see why we must wait for the
RFC-YYY system to be fully implemented when we can just fall back on
this.

Date:  Monday, 17 October 1983 12:49 edt
From:  "Barry Margolin"@MIT-MULTICS.ARPA
Subject:  NameDroppers
To:  Header-People@MIT-MC.ARPA
Message-ID:  <831017164901.388836@MIT-MULTICS.ARPA>

I have gotten several messages requesting info about the NAMEDROPPERS
mailing list. I believe that it comes from SRI-NIC, so sending mail to
NAMEDROPPERS-REQUEST at SRI-NIC is the way to get onto the list.
                                        barmar

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 17 Oct 83 12:41:00 EDT
Date: 17 Oct 83 1251 EDT (Monday)
From: don.provan@CMU-CS-A
Subject: Re: Puzzled thoughts from a non-Internetter
CC: header-people@mit-mc
In-Reply-To: <831017085117.2.Hornig@SCRC.SCRC>
Message-Id: <17Oct83.125114.DP0N@CMU-CS-A>

uh-oh.  we're back to the return path again.  the spec claims that there
need be no relation between the return-path and the sender of the message.
it fact, it specifically says that the return-path is where *errors*
should be sent, *not* where replies should be sent.

it's my understanding that if a mailer is following SMTP, it needs to
produce an address that anyone who's legal in the SMTP world can understand.
whether that's 'Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS.ARPA' or
'@MIT-MULTICS.ARPA:Gavin_Eadie@UMICH-MTS.MAILNET' (although this
format is frowned upon by the specs and, from what Mark is saying, is
down right illegal because of the illegal address, although i can't
see why anyone would care what that address is: i always assumed this
format was designed for just such a situation) or
'Gavin_Eadie@UMICH-MTS.MAILNET.MIT-MULTICS.ARPA' (which, from time to
time, has been declared "legal", although i believe current opinion
considers it illegal) doesn't really concern me too much.  they all have
the same basic format: a part anyone should be able to understand, and
a part almost noone will understand.  however, if a mailer *doesn't*
generate a universally understood address (and i wouldn't blame it,
since universally understood addresses get longer in proportion to the
distance from our egocentric network) then some interface is going to
have to hack headers because the mailer just isn't playing SMTP.
	i don't quite know what the point of saying all this was.  i guess
i just want to spew the way i understand it so someone can correct the
parts i misunderstand.
						don

Date: 17 Oct 1983 0813-PDT
Sender: WMARTIN at OFFICE-3
Subject: Message-ID's
Subject: [WMartin at Office-3 (Will Martin): Unique identifier for m...]
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Message-ID: <[OFFICE-3]17-Oct-83 08:13:22.WMARTIN>

I tried sending this message to Header-People almost two weeks
ago; it doesn't seem to have ever gotten there, as I never saw a
remailed copy come back to me.  I have had no response from an
inquiry message about it that I sent to
Header-People-Regquest@MIT-MC, either.  (I am getting H-P mail
from the list OK, as far as I can determine.  If this one never
shows up, the link from here TO MIT-MC must be down.)
	
Begin forwarded message
Date: 5 Oct 1983 0826-PDT
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Subject: Unique identifier for messages
Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN>

Wouldn't a good way to uniquely identify messages, given the
problem of changed messages having the Message-ID unchanged, be a
combination of an originally-assigned Message-ID field and the
number of characters in the Text field?  Most duplicate messages
I've seen have different character-counts for the entire message,
because the header has more fields or more data in a field, but
the Text is identical.  Since most message-systems seem to use
the character-count for various purposes, would it be hard to
just count the characters in the Text field alone?  I would think
that it would be safe to program a system to assume duplicates
exist if both the Message-ID and the Text field character-count
were identical.  If there was no Message-ID, of course, such a
message wouldn't be considered as a candidate for being a
duplicate, even if it was.  (I doubt that it would be safe to
consider messages to be duplicates if both had null Message-ID's
and identical Text-field character-counts -- too much margin for
error in that case.)

Will Martin

          --------------------
End forwarded message
		

Received: from USC-ISIF by MIT-XX; Mon 17 Oct 83 15:43:59-EDT
Date: 17 Oct 1983 12:42:13 PDT
From: POSTEL@USC-ISIF
Subject: Draft Memos on Domains
To:   header-people@MIT-MC


There are three draft memos on the DOMAINS system.  These are in the files

<INTERNET-NOTEBOOK>DOMAINS-XXX.DRAFT
<INTERNET-NOTEBOOK>DOMAINS-YYY.DRAFT
<INTERNET-NOTEBOOK>DOMAINS-ZZZ.DRAFT

on USC-ISIF.

These are public access files and may be copied via FTP.  Please use the
FTP username ANONYMOUS and password GUEST.

The proper forum for discussion of these memos and related topics is the
mailing list NAMEDROPPERS@SRI-NIC.  To get on the list please send a request
to NAMEDROPPERS-REQUEST@SRI-NIC.

--jon.
-------

Date: Mon 17 Oct 83 13:46:54-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Unofficial Domains
To: milazzo.rice@RAND-RELAY.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Paul Milazzo <milazzo.rice@Rand-Relay>" of Mon 17 Oct 83 00:19:03-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Paul -

     I couldn't agree with you more about preventing private
domains from escaping.  They don't in my software.  However,
I can't prevent users from generating a header line which refers
to a private domain -- all I can do is educate them!  In the
example you gave, that Reply-To: line was in fact generated by
the user explicitly using a power tool in the mailsystem that
allows arbitrary text in headers.

     Power tools are useful to evade the normal header generating
mechanisms and are essential with any experimentation, but they
can be abused.  I see no way to protect power tools without
hampering their usefulness.

     Thanks for the note, though; I will tell G.Norm@SU-SCORE not
to stick in "Reply-To: Kincl@HP-Labs.CSnet-West" in his headers.

     Your second point (regarding what happens when Rice goes on
Internet) touches closer to home.  You're right.  The problem was
that at the time we designed private domains, we confused the
functionality of private domains with the functionality to
disable delivery to an entity via a certain transport.  In other
words, consider the case where host FOO is listed in the Internet
registry, but it is known that they aren't *really* on Internet
and so must be mailed to via some other means such as CSnet.  The
DOMAINS.TXT entry would override the Internet lookup.

     Really, it should be the other way around; DOMAINS.TXT
should be treated last and there should be a new mechanism to
disable name lookups.  I guess I ought to fix this.

     Note that this mechanism is layered on top of the official
mechanisms.  There is nothing keeping a user from using the
syntax user.CSnet-host@RAND-RELAY; it's just to allow a user here
to say user@CSnet-host.  Hopefully real domains will come along
soon and get rid of all this cruft.

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

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 18 Oct 83 07:42:25 PDT
Via:  44a.Ucl-Cs.AC.UK; to 44d.Ucl-Cs.AC.UK  over Inter-UNIX with SMTP; 
          18 Oct 83 13:25 BST
Date:     18 Oct 83 10:16:29 BST (Tue)
From:     Steve Kille <steve@ucl-cs> (44a)
To:       header-people@mit-mc.arpa
Subject:  UK Mail Protocol

The JNT Mail Protocol used in the UK Academic Community is being revised
to follow the changes from RFC 733 -> 822.  This protocol uses
messages which are upwards compatible with RFC 822 bar a few
small differences.

The third draft is now available, and as most of you do not run
NIFTP, I will be happy to mail copies to anyone interested.
The final version (expected early next year) will also be
announced over this list.

Any comments are welcome, and should be sent to <mailgroup@ucl-cs>.
This group is concerned with mail service developments in the UK,
and I will be happy to add internet people to the list.

Steve Kille



Date:           Thu, 20 Oct 83 11:01:54 PDT
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Results of SMTP server inquiries

A while ago, I asked for information regarding the state of SMTP server
implementations in the Internet.  My purpose in doing this was to find
out whether it was "safe" to assume that random Internet hosts can han-
dle multiple recipients per message and multiple messages per connec-
tion -- and if this were not a safe assumption, to design a "robust"
SMTP sender (outgoing mailer) which would batch recipients of a single
message and/or messages to a single host where possible, yet would suc-
cessfully "degrade" to accommodate the limitations of SMTP servers with
more limited capabilities.

I received numerous replies; one implementor (Doug Kingston at BRL)
even phoned me so we could discuss the issues at greater length.  My
thanks to all those who did reply to my inquiry.

It appears that most SMTP servers in use on the Internet today imple-
ment RFC821 rather well.  In particular, everyone who replied to me
indicated that their server should be able to handle at least 100
recipients per message, and an unlimited number of messages per con-
nection, under normal circumstances.

Two problem areas did surface and should probably be thought out and
discussed further:

(1) There is sharp disagreement as to what is the best reply code to
    use when the sender tries to specify "too many" RCPT commands for
    a message.  RFC821 calls for the reply code 552 in this situation,
    but since many (maybe even all) mailers will interpret a 552 reply
    code as a permanent rejection of the last-specified recipient, a
    significant number of SMTP servers disregard this portion of RFC821
    and reject excessive recipients with 452 rather than 552.

    Many servers have no explicit limit on the number of recipients,
    but will "bomb" in more-or-less messy ways after a (usually) unrea-
    sonable number of recipients cause virtual memory to fill up.  Most
    of these servers, though, will probably accept preposterously large
    recipient lists before choking.

    I would therefore propose the following practices.  Please note
    that these are my personal opinions and have no official sanction.

    (a) Mailers should attempt to negotiate no more than 100 recipients
	in a single message; longer recipient lists should be handled
	by splitting the transaction in two.  A mailer which holds it-
	self to this limit probably does not have to worry about going
	over a server's limit on the number of recipients, since most
	(if not all) servers seem to be able to take 100 recipients in
	accordance with RFC821 (section 4.5.3, page 43).

    (b) Server implementors should give serious consideration to using
	a 400-series reply code (such as 452), rather than 552, when
	confronted with too many recipients in a single message -- in
	order to insure that the mailer will try the excess recipients
	later rather than permanently rejecting them.

(2) Some hosts may run into problems when presented with lots of trans-
    actions with lots of recipients.  Two syndromes were pointed out to
    me in this regard:

    (a) Some servers (evidently including the Berkeley 4.1c/4.2BSD
	"sendmail"-based system) may take so long to complete the mail-
	delivery process that the mailer may end up incorrectly assum-
	ing the server has met an untimely demise.  Since the mailer
	under such circumstances will try to deliver the message again
	later (and will probably run into the same problem again and
	again), the result will be endless duplication of mail in the
	receivers' mailboxes.

	Note, by the way, that the mailer end cannot reliably "guess"
	how long to wait for delivery to complete based on the number
	of RCPT commands, since the server end may have expanded the
	original recipient list via aliasing.

    (b) Some other servers (such as BBN's system) wait a while for the
	mail-delivery process to finish; then, after 30 seconds or so,
	the server assumes that the mail will eventually be delivered
	and prematurely reports success back to the mailing end.  A
	system whose server behaves in this way can quickly get swamped
	by a host with lots of mail to send; eventually, the receiving
	system may get "file table is full" or other problems and start
	dropping mail on the floor.

    MMDF-based SMTP servers are apparently immune to this difficulty,
    since the server simply stores incoming mail in a spool directory
    and relies on a daemon to deliver it later.  (I suspect the Xerox
    Grapevine system works this way too, though I am not absolutely
    certain.)  This is probably the best way to handle the problem, and
    I personally would urge people to give it serious consideration.

    People running servers such as BBN's might consider extending the
    "wait" time before reporting success prematurely beyond the dis-
    tributed 30 seconds.  It would be good in this regard to know how
    long people's mailers will wait before assuming that the server has
    disappeared.  I would suspect, though, that this "wait" time could
    be extended to at least 60 seconds without problems.

    It would be nice if there were some accepted "intermediate" reply
    code which a server could send back to the mailer periodically --
    something like

	xxx Mail delivery is taking a while; please be patient

    *******************************************************************
    *** This is ONLY an idea (that's one reason I used "xxx" rather ***
    *** than a real numeric code); it isn't part of the standard;   ***
    *** so don't anyone go implement this in their SMTP server and  ***
    *** then say that Rich Wales at UCLA told you to, eh?           ***
    *******************************************************************

    Something like this would get around all the timeout problems.  Un-
    fortunately, RFC821 doesn't provide for such a facility, and I am
    enough of a realist not to hope too strongly for a revision of the
    current standard.

-- Rich <wales@UCLA-LOCUS>

Date:     Thu, 20 Oct 83 15:53:43 EDT
From:     Dave Crocker <dcrocker@udel-relay.arpa>
To:       Gary M. Palter <Palter@mit-multics.arpa>
cc:       Header-People@mit-mc.arpa
Subject:  Re:  [OBERST%educom: Quoted @ in To: field]

I was under the impression that full domain qualification was
only required if the message crossed domain boundaries, but that
partial specification could be retained if the message was sent
between systems in the same domain.  

Don't have the spec in front of me, though.

Dave

Date: Thu 20 Oct 83 13:11:36-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Results of SMTP server inquiries
To: v.wales@UCLA-LOCUS.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Rich Wales <v.wales@UCLA-LOCUS>" of Thu 20 Oct 83 11:24:04-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The TOPS-20 SMTP sender will time out a transaction after waiting 5
minutes for an SMTP reply (including the reply after the end-of-message
signal in a DATA command).  I decline to make that time out interval
longer.  I think it should be shorter, like 1-2 minutes.  That time is
time that other messages waiting to go out are delayed.

Problem is, as Rich says, too many Unix sites run the SMTP server that
makes you wait for each individual copy to be delivered.  At the former
2 minute time out (in NCP days it was 1 minute!), messages simply weren't
getting through to a number of these sites.

I consider that behavior to be rather anti-social of an SMTP server.
After all, by this time there is no way to report the failure of an
individual recipient (e.g. disk allotment exceeded, etc.).  To properly
report the error the SMTP server's system will have to do it in a message
to the Return-Path anyway!  If it gave an error code at the end of the
DATA command, the SMTP sender would have no choice but to assume that the
entire message lost to all recipients and it needs to requeue it.

What MMDF and TOPS-20 does -- that is, queueing the message to a spool
area and have an independent mailer process deliver the message to all
the recipients without delaying the SMTP server -- is the right thing.
Could we see MMDF's SMTP server more widely distributed?
-------

Date: Thu 20 Oct 83 13:20:46-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  [OBERST%educom: Quoted @ in To: field]
To: dcrocker@UDEL-RELAY.ARPA
cc: Palter@MIT-MULTICS.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Dave Crocker <dcrocker@udel-relay.arpa>" of Thu 20 Oct 83 13:04:45-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

I think Dave Crocker is right that "full domain qualification [is]
only required if the message crosse[s] domain boundaries".  That is,
according to RFC 822.  Dave was certainly quite insistant upon this
particular feature going into the spec (I don't have it in front of
me just now either) and I'd be surprised if it slipped out.

This isn't to mean this is a good idea.  Any mailsystem which puts
anything other than absolute domain names in a message header is
guaranteed to have problems.  Let's go back to the host-less header
issue if you don't believe me.
-------

Date: 21 Oct 1983 0705-PDT
Sender: WMARTIN at OFFICE-3
Subject: "Anti-Social behavior" of mailers
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Message-ID: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN>

This is peripheral to the SMTP server discussion, but the comment
about messages to an individual recipient being rejected for such
reasons as "disk allotment exceeded" strikes me as being an example
of an institutionalized anti-social attitude in itself.
(Let me first emphasize that I am not accusing the correspondents
of anything; it was just the use of the particular example that led
me into this train of thought.)

As a message sender, I have nothing at all to do with the
recipient's housekeeping or host administration's practices, yet,
in this case, I am being imposed upon by having my message
rejected because the recipent has reached some arbitrary quota
limitation.  It's like the USPS returning mail because the
addressee's PO Box is crammed full!

The principle to be followed is that "mail is sacred".  If adding
mail to a recipient's receiving message-file causes that person
to be overallocated or exceed some quota, it should be added
nonetheless.  It is the responsibility of the recipient to do
whatever housekeeping is necessary to avoid whatever problems his
system causes by his being overallocated.  I know that this has
some unfortunate side effects.  A malicious sender can cause
trouble by filling up space with garbage messages.  Some systems
have a lot of trouble letting a user clean up his disk area.
(Such as Tenex, when a user is overallocated and the system free
space is below the Free Space Fence limit -- he can't delete and
expunge messages from the message-file because the system doesn't
let the program create the scratch file necessary for the
update.)  But these problems can be tolerated, while arbitrary
rejection of mail back to a sender, which forces the sender to do
something about it, cannot.  That is truly "anti-social", as it
makes what should be an individual internal problem spread its
effects outside that individual's boundaries, on the same host or
across the net(s).

A system administrator has all sorts of local methods to force
disk usage limitation, but exporting hassles to the outside world
shouldn't be one of them.  If my mail to someone is rejected for
this reason, I either have to decide to not send it and forget
it, try sending it later (how many times, and how often, if the
rejections continue?), or try other addresses or paths to the
person behind the address.  Even if this is being done by a
process, not by me personally, it is using resources better
expended on other matters.  I just can't see this as a valid
reason for failing to deliver mail, and I hope that any protocols
or documentation that might imply that this is valid (such as
providing a specific reply code to cover this instance) should be
amended to emphasize how "anti-social" this action is.

Maybe this is a non-issue; I don't recall ever receiving a
message back explicitly stating that delivery was refused because
the recipient was overallocated or the like.  If everybody agrees
with what I have said already, maybe the problem never arises.
If so, I'm glad, and I'll shut up.  (If not, I can always rant
and rave ineffectually over here in the corner...)

Regards, Will Martin

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Oct 83 13:07:21 EDT
Date: 21 Oct 83 1313 EDT
From: Rudy.Nedved@CMU-CS-A
To: WMartin@Office-3 (Will Martin)
Subject: Re: "Anti-Social behavior" of mailers
CC: Header-People@MIT-MC
In-Reply-To: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN>
Message-Id: <21Oct83.131321.EN0C@CMU-CS-A>

CMU Computer Science and Robotics Institutue doesn't implement mail
restrictions at the moment but sometimes it gets very tempting.

CMU Computation Center on the other hand has 3000 students some of which abuse
the mail system just like dorms. They like to have "fun" sending .EXE files and
FORTRAN-77 documents to a friends mail box.  CMU CC had to respond by cutting
the ability off since their other options were ineffective.

CMU CS/RI Operations got dragged into the undergrad education business and we
have noticed abuses. We have had the same problem but because we are a more
serious and smaller organization, we have the ability to say "you will lose
your account and fail the course if you don't stop this abuse" and we can make
it happen.

So....have sympathy with people that restrict mail to the disk space people
have....if you were in their shoes with their budgets, users and politics you
would probably have the same problem.

Rudy Nedved
Research Systems Programmer
Computer Science & Robotics Institute Operations
Carnegie-Mellon University

Date: 21-Oct-83 10:31 PDT
From: Bill Barns  <WWB.TYM@OFFICE-2>
Subject: Re: "Anti-Social behavior" of mailers
To: WMartin@Office-3 (Will Martin)
Cc: Header-People@MIT-MC
Message-ID: <[OFFICE-2]TYM-WWB-3E62A>
In-reply-to: <[OFFICE-3]21-Oct-83 07:05:31.WMARTIN>

The solution actually in force on Office-3 (and I should think in most 
places(?)) is that a 4xx reply code from the remote (receiving) host would cause
the Office-3 SMTP sender to resend to the failing addresses periodically for 
some period of time.  The particular sender which runs on Office-3 retries about
every 5 minutes, and keeps trying forever.

The key here is that a receiver which wants to reject for such reasons as lack 
of disk space should return a 400 series error code.  I'm on travel and don't 
have an SMTP protocol document handy, but I think that is what it says to do.  
400 series codes imply that the receiver program has reason to believe that 
things will work better in the future if the sender will just wait "a while".  
500 series error codes imply a fundamental impossibility.  I hope nobody returns
a 5xx for "over allocation".

I seem to remember reading that the USPS can refuse to deliver mail to people 
who don't comply with certain requirements, such as having the address displayed
clearly and a suitable mail box (mail slot, ...) to put the mail in.  I think 
they retain the mail at the post office for 30 days and after that, all bets are
off.  This is essentially analogous to what happens with a reasonable SMTP 
sender-receiver interaction...  -b


Date: Fri 21 Oct 83 12:15:40-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: "Anti-Social behavior" of mailers
To: WMartin@OFFICE-3.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "WMartin at Office-3 (Will Martin)" of Fri 21 Oct 83 07:05:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Bill -

     I beg to disagree.  Just about every mail system (including the
Postal system!) has a "no more space for additional mail" condition.
In the case of the Postal system, the recipient is considered to be
on vacation and an automatic hold is placed on his mail.  After some
time without being picked up the mail is either returned to sender,
forwarded to the new address, or goes to the dead letter department.

     Some electronic mailsystems even have an explicit limitation on
the number of messages in a user's "in box", especially the various
microcomputer "bulletin board systems" (BBS) using floppy disks for
storage.  All mailsystems have some implicit limitation due to the
size of various data structures and/or address space, but it is
generally quite high.  If nothing else there is a limit on the total
amount of disk space available on the entire system.  The point is,
even without disk allocation enforcement some limit will always
exist.

     The TOPS-20 mailsystem does enforce disk quotas on incoming
messages.  It does not reject the message right away.  Rather, it
holds the message for an interval (3 days as supplied by me) and
retries every 30 minutes or so.  The recipient is also notified that
there is mail in the queues pending because it would exceed his/her
disk quota.  Only messages which would exceed the disk quota are
held.  Normally messages are delivered in the chronological order
they were queued, but an exception is made in this case.  For
example, if a user has 10 free pages (TOPS-20 allocates disk space
in "pages" of 512 36-bit words or 2560 characters) in his/her
allocation and receives three messages of 11, 2, and 7 pages at that
time, the 2 and 7 page messages will be delivered and only the 11
page message will be held.  If after 3 days the message is still
undeliverable it is then returned to the sender; the sender also
receives daily notifications of the problem.

     Considering the proliferation of electronic junk mail, it
shouldn't surprise anyone that most system managers have no
intention of exempting electronic mail from disk quota limitations.
Some systems are run on a "disk quota is your guaranteed maximum
disk charges basis" and its system manager has not intention of
dealing with an irate user upset because junk mail added a hefty
chunk to the user's disk charges.  Other systems just don't have
enough disk space.

     Finally, it should be considered that if a message is held for
3 days before being returned as undeliverable, it is either much too
large for the user's disk quota or the user isn't reading his/her
mail.  In the former case, I stand firm in my unequivocal
condemnation of the user of electronic mail as an FTP and my
contempt for network designers who fantasize that electronic mail is
a perfectly acceptable FTP mechanism.  In the latter case, it isn't
likely the user is going to be reading the mail at all soon anyway,
and the telephone is preferred if the message is really necessary.

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

Date: 21 Oct 1983 1136-PDT
Sender: WMARTIN at OFFICE-3
Subject: More on "anti-social behavior" of mail systems
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Message-ID: <[OFFICE-3]21-Oct-83 11:36:10.WMARTIN>

I've gotten a couple of responses to my H-P msg on mail rejection
for disk overallocation reasons that have forcibly reminded me of
the wide disparity of user communities out there.

I had thought of including some sort of distinction between
computer systems serving undergraduate academic communities and
those serving people (i.e., those who use these resources as
tools to perform work) but did not, as the original message was
long enough as it is.

If you are talking of an actively hostile and inimical user base,
as the academic environment seems to be, both in fable and in
truth, your users are trying to destroy you and each other by
mailing megabytes of garbage, hacking away at any privacy or
protection facilities, and generally behaving like vermin.  That
isn't the environment I am addressing, nor have I any particular
sympathy any more -- I'm too old and tired for such games.  I
just cannot relate to that sort of situation any longer, so I
cannot empathize with those of you who have to work in such a
depressing situation.  My attention is devoted to a
production-oriented world and that is where I aimed my remarks.

I am addressing the working office automation environment and in
particular the transfer of functions from desktop and paper-based
modes to electronic automated tools.  In that situation, I
reiterate my concern -- a message I send to someone should NOT be
returned to me because of the addressee's disk usage situation.
If the entire destination system's disks were crammed full, yes,
it couldn't deliver, but it also couldn't run ANYTHING, so that
is a specious argument.  The automated systems must be at least
as reliable as the old-style systems they replace, in addition to
having all the advantages we know about and I needn't dwell upon.
If the sender does his part (essentially no more than spell the
addressee correctly), he has done all he should be expected to
do.  To return a message (or, worse yet, to just inform him of
non-delivery) because of something that is in no way his fault is
an insult and NOT tolerable.  The only valid return is if the
address cannot be interpreted or no longer exists, and no
forwarding path ever existed.  (Note that this means that
forwarding should last for longer than the USPS one-year standard
-- a table of former user-id's and forwarding paths doesn't eat
up enough space to justify purging after just a year, when the
environment is the normal working organization with ordinary
personnel turnover.)

I suppose I'll have to emphasize the distinction between my
concerns in a production OA environment and their inapplicability
in the undergraduate academic world (what would be a good
shorthand term for this?  -- how about "sandbox"?)  from now
on...  I guess this disparity is probably largely responsible for
the MILNET/ARPANET split, and all the attendant problems THAT is
causing...

Will Martin
USArmy DARCOM ALMSA

Date:     Fri, 21 Oct 83 15:13:22 EDT
From:     Brinton Cooper <abc@brl-bmd>
To:       WMartin@office-3
cc:       Header-People@mit-mc
Subject:  Re:  Anti-Social behavior of mailers.


**********
As a message sender, I have nothing at all to do with the
recipient's housekeeping or host administration's practices, yet,
in this case, I am being imposed upon by having my message
rejected because the recipent has reached some arbitrary quota
limitation.  It's like the USPS returning mail because the
addressee's PO Box is crammed full!

**********

And just what do you think the USPS will do with mail if your letter
carrier finds your PO Box crammed full?

Indeed, what CAN the USPS do but to return mail?

Brint

Date: 21 Oct 1983 1337-PDT
Sender: WMARTIN at OFFICE-3
Subject:  Re:  Anti-Social behavior of mailers.
From: WMartin at Office-3 (Will Martin)
To: abc at BRL-BMD
Cc: header-people at MIT-MC
Message-ID: <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN>
In-Reply-To: Your message of     Fri, 21 Oct 83 15:13:22 EDT

For crying out loud...

The USPS puts a notice in the box (taking back out 1 letter to
make room if necessary) that more mail is waiting and must be
called for at the window.  Then all the extra incoming mail is
bundled up and held in the sorting area.  When the recipient
opens his mailbox and pries out the wadded-up ball of mail that
is in there, he takes the notice to the window during regular
office hours and gets the extra mail.  If this happens often, the
USPS can insist (I believe on pain of cancelling the PO Box) that
the recipient pay for a larger box or drawer which will hold the
usual amount of mail, or arrange for service whereby all mail is
called for instead of being put in a box at all.

Note that the mail is NOT returned to sender; the recipient and
the delivery service are the only ones involved.

I thought that everybody knew this...

The parallels with an automated system are obvious.  If the
system has to have fixed and not-exceedable disk quotas, incoming
mail can be put into a system-level directory and flagged for the
correct recipient mailbox.  Delivery from there to the user could
be automatic or not, depending on local policy.

In a real work environment, if the users need more space than
they are given, it is justification for buying more and bigger
disks; then they can be given what they need or want.  Or they
can be made to justify larger requirements.  (This is a mistake
when implementing new OA systems, as you want to get them hooked
on using the system and make it as easy and rewarding as
possible.  Only after they have used it and come to rely on it
should you start turning the screws on them.)  There are enough
charge-back mechanisms for private or governmental organizations
to make them pay for what they want, if you find that necessary.

Martin

Date: 21 Oct 1983 1337-PDT
Sender: WMARTIN at OFFICE-3
Subject:  Re:  Anti-Social behavior of mailers.
From: WMartin at Office-3 (Will Martin)
To: abc at BRL-BMD
Cc: header-people at MIT-MC
Message-ID: <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN>
In-Reply-To: Your message of     Fri, 21 Oct 83 15:13:22 EDT

For crying out loud...

The USPS puts a notice in the box (taking back out 1 letter to
make room if necessary) that more mail is waiting and must be
called for at the window.  Then all the extra incoming mail is
bundled up and held in the sorting area.  When the recipient
opens his mailbox and pries out the wadded-up ball of mail that
is in there, he takes the notice to the window during regular
office hours and gets the extra mail.  If this happens often, the
USPS can insist (I believe on pain of cancelling the PO Box) that
the recipient pay for a larger box or drawer which will hold the
usual amount of mail, or arrange for service whereby all mail is
called for instead of being put in a box at all.

Note that the mail is NOT returned to sender; the recipient and
the delivery service are the only ones involved.

I thought that everybody knew this...

The parallels with an automated system are obvious.  If the
system has to have fixed and not-exceedable disk quotas, incoming
mail can be put into a system-level directory and flagged for the
correct recipient mailbox.  Delivery from there to the user could
be automatic or not, depending on local policy.

In a real work environment, if the users need more space than
they are given, it is justification for buying more and bigger
disks; then they can be given what they need or want.  Or they
can be made to justify larger requirements.  (This is a mistake
when implementing new OA systems, as you want to get them hooked
on using the system and make it as easy and rewarding as
possible.  Only after they have used it and come to rely on it
should you start turning the screws on them.)  There are enough
charge-back mechanisms for private or governmental organizations
to make them pay for what they want, if you find that necessary.

Martin

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Oct 83 16:28:54 EDT
Date: 21 Oct 83 1638 EDT
From: Rudy.Nedved@CMU-CS-A
To: WMartin@Office-3 (Will Martin)
Subject: Re: More on "anti-social behavior" of mail systems
CC: Header-People@MIT-MC
In-Reply-To: <[OFFICE-3]21-Oct-83 11:36:10.WMARTIN>
Message-Id: <21Oct83.163827.EN0C@CMU-CS-A>

Will,

Okay, ignore the problem of the unprofessional and/or discourteous world (ever
encroaching because of PCs and better internetting capabilities).

The problem with drawing analogies between the ARPANET/MILNET mail system and
any known postal system is the cost is fixed for the former and not accountable
to an individual mail box. If this condition existed in the real world, say
that the goverment financed mail and no one paid postage what do you think
would happen?? I suspect junk mail would be filling up people's mail boxes to
the max and the post office would be going nuts with the load. I can start
imagining regulations similiar to what happen during gas shortages....of course
people could be required to fill out 20 forms in order to send mail...that
"fixes" alot of problems.

Anyhow, that argument is not hitting your "office world" but I can put it in
perspective. What do you do when you want to send a large package?? Do you just
do it?? or is there some limiting factor like a budget item or a boss?? If you
took away that limiting factor, undoubtedly you would have problems.

The disk space restriction is by no means the best way to handle things nor is
the "mail is sacred" philosphy. The best model I know of which would be pretty
hard to implement at the moment is "postage". MCI Mail and TELENET mail all
cost something and when you want to send a letter, you think about those
costs....

-Rudy

Date: 21 Oct 1983 17:30:39 EDT (Friday)
From: Dan Franklin <dan@bbncd>
Subject: Re:  Anti-Social behavior of mailers.
In-Reply-to: Your message of 21 Oct 1983 13:37 PDT
To: WMartin at Office-3 (Will Martin)
Cc: header-people at MIT-MC

You still need flow-control.

Even if there is a spool directory, some provision must be made for its running
out of space because of some runaway mailer which is delivering the same
message over and over again.  In this situation, the receiving host should not
start scrounging for all the space it can find, because that WILL bring the
system to a halt and prevent any work from getting done--an intolerable
situation which is considerably worse to the host's users than the "insult" of
getting mail returned is to you.  The receiver must refuse to accept further
mail which would cause its spool directory to become too large.

But this doesn't mean that the original author of the message (you) should get
the message back.  Rather, the mailer that tried to send the message should now
hold on to it and retry, forever--with a notification to the author that it's
doing so (after some interval), because people expect timely delivery of
electronic mail and should be informed when that's not the case.

Even the sending mailer's spool area could become full.  At that point it would
have to start returning mail to you that it couldn't deliver immediately.  At
some level, this can't be avoided.  It can only be made very unlikely.

    Dan Franklin

Date:     Sat, 22 Oct 83 6:19:49 EDT
From:     Stephen Wolff <steve@brl-bmd>
To:       Will Martin <WMartin@office-3>
cc:       Header-People@mit-mc
Subject:  Re:  More on "anti-social behavior" of mail systems

Dear Will,

It was a mistake for me not to take your first letter on anti-social behaviour
seriously; that error led to my "spontaneous generation of disk space" note for
which I apologize.

I should imagine that something very near to the delivery guarantee that you
desire (even in a system with rigid quotas) can be had rather easily in a nice
mail system such as mmdf that uses an off-line, trusted deliver daemon (local
letter-carrier).  While it would make his job somewhat longer, he COULD check
disk space and, if delivery would put a user over quota, file the message in a
special `pending' file and leave a brief note in the `motu' file (UNIX, sorry)
that is displayed at the next log-in.  Or you could exert some social pressure
with a note in motg: "Mail is pending but cannot be delivered to the following
group members because they are disk hogs: ........"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

"I'm old, but not THAT tired," as the bishop said to the actress.
									-steve
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Date:     Sat, 22 Oct 83 1:50:33 EDT
From:     Mike Muuss <mike@brl-vgr>
To:       Will Martin <WMartin@office-3>
cc:       Header-People@mit-mc
Subject:  Re:  "Anti-Social behavior" of mailers

As a maintainer of large mailing lists, I get between 3 and 200
messages rejected, or warnings returned, because a subscriber
did not have any disk quota left.

It's hard to know how to deal with this in a fully general way,
but overall, disk space is cheap enough these days that I vote
in favor of Will Martin's suggestion to treat mail as sacred.
I vote with my feet -- our mail system works that way.
		-Mike

Date:     Sat, 22 Oct 83 16:02:22 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Will Martin <WMartin@office-3>
cc:       Header-People@mit-mc
Subject:  Re:  "Anti-Social behavior" of mailers

Well, I'll tell you, as maintainer of several large mailing lists
I can say that it does happen.  The DEC-20's are the main cuprits.
You don't know how really disappointing it is to get letters from
remote mailers saying "user so and so is over quota so I haven't
been able to deliver mail to him in over a day, but I will keep
trying for two more days" for every single submission to lists with
as much traffic as INFO-MICRO and INFO-CPM.  I've had to adopt the
rather hard-assed policy of dropping users from the lists as soon
as this starts happeing.  However, two days after the first message
I get another message from the 20 mailer saying "sorry, still can't
deliver to the bastard, I give up."

I used to try to send mail to these sites and tell them (a note to
postmaster, I obviously can't send mail to the user telling them
that they can't recieve mail...it's like Les Nessman on WKRP announcing
that the transmitter blew up and they were no longer on the air during
one of his newscasts).  You know what resulted from this...NOTHING.
A majority of these sites do not respond to mail addressed to POSTMASTER.
I finally broke down and started obtaining the host liasons from the
NIC and contacting them.

-Ron

Date:     Sat, 22 Oct 83 16:06:46 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Rudy.Nedved@cmu-cs-a
cc:       Will Martin <WMartin@office-3>, Header-People@mit-mc
Subject:  Re:  "Anti-Social behavior" of mailers

Then I assert, it would be less grief on my part if the remote
mailer would return a 4XX error immediately rather than queuing
the dumb letter up on the remote site to fail later, so that I
can cancel it on my end.

-Ron

Date:     Sat, 22 Oct 83 16:11:20 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Brinton Cooper <abc@brl-bmd>
cc:       WMartin@office-3, Header-People@mit-mc
Subject:  Re:  Anti-Social behavior of mailers.

But the USPS doesn't return your mail.  They just cram a little
pink slip in your mailbox that tells you that you have more mail
in a sack somewhere.  Typically, you have only 7 days to claim
it however.

-Ron

Date: 22 Oct 1983 2138-EDT
From: Greg Skinner <Uc.Gds at MIT-EECS>
Subject: Re: Computer Science Seminar at BU
To: G.Bostonu=csc126 at UCB-VAX at MIT-ML
cc: msggroup at MIT-OZ, header-people at MIT-MC
Reply-To: ee.gds@oz
In-Reply-To: Your message of 22-Oct-83 1825-EDT

I am very curious.

Why do bitnet addresses have the syntax

<g.site-name=user-name> ?
-------

Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA29422; Sun, 23 Oct 83 14:54:49 pdt
Received: by ucbarpa.ARPA (4.16/4.11)
	id AA02557; Sun, 23 Oct 83 15:03:23 pdt
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 23 Oct 1983 1503-PDT (Sunday)
Message-Id: <2556.31.435794600@ucbarpa>
To: Rich Wales <v.wales@UCLA-LOCUS>
Cc: Header-People@MIT-MC
Subject: Re: Results of SMTP server inquiries
In-Reply-To: Your message of Thu, 20 Oct 83 11:01:54 PDT.
             <8310201820.AA02312@ucbvax.ARPA>
Fcc: mail

Sendmail as distributed on 4.2 does not hold the connection open for
delivery.  It does expand aliases and verify addresses.  In some cases
(e.g., very large lists on a loaded machine) this can take a fairly
long time, but far less than necessary for actual delivery.

Sendmail on 4.1a did have the problem you describe.

eric

Date:     Sun, 23 Oct 83 1:13:49 EDT
From:     Brinton Cooper <abc@brl-bmd>
To:       Ron Natalie <ron@brl-vgr>
cc:       Brinton Cooper <abc@brl-bmd>, WMartin@office-3, Header-People@mit-mc
Subject:  Re:  Anti-Social behavior of mailers.

And after 7 days...?

Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:02:01-edt
Date: Fri 21 Oct 83 15:47:34-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: More on "anti-social behavior" of mail systems
To: WMartin@OFFICE-3.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "WMartin at Office-3 (Will Martin)" of Fri 21 Oct 83 11:36:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Bill -

     There is a very simple way to have a "reliable automated system"
of the sort you crave, with no mail rejections because of disk
allocations.

     The site management should give all the users infinite disk
allocations, or at least infinite "hard" disk allocations.  TOPS-20
supports the concept of separate hard ("working") and soft ("permanent")
disk allocations.

     Be advised that while you may feel "insulted" that your mail got
rejected because the recipient's disk allocation was exceeded, most
systems (e.g. TOPS-20) only do this when the condition is chronic for
3 days.  3 days is a parameter the site management can reconfigure to
whatever value they please.  There is every reason to believe that that
user is not likely to see that message at all soon anyway!

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

Received: from USC-ECL (usc-ecl.ARPA) by ucbvax.ARPA (4.16/4.11)
	id AA07248; Sun, 23 Oct 83 21:13:07 pdt
Date: 23 Oct 1983 21:20-PDT
Sender: ESTEFFERUD@USC-ECL
Subject: RE: COMPUTER SCIENCE SEMINAR AT BU
From: ESTEFFERUD@USC-ECL
Reply-To: MSGGROUP-REQUEST@BRL
To: EE.GDS%OZ@BRL
Cc: G.BOSTONU=CSC126@Berkeley, MSGGROUP@BRL
Cc: HEADER-PEOPLE@MIT-MC
Message-Id: <[USC-ECL]23-Oct-83 21:20:20.ESTEFFERUD>
In-Reply-To: THE MESSAGE OF 22 OCT 1983 2138-EDT FROM GREG SKINNER <UC.GDS%MIT-EECS@BRL.ARPA>

SIGH!  PLEASE RESTRICT REPLIES TO HEADER-PEOPLE ONLY!  STEF


Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:19:52-edt
Date: Sat 22 Oct 83 17:56:10-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:  "Anti-Social behavior" of mailers
To: ron@BRL-VGR.ARPA
cc: WMartin@OFFICE-3.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Ron Natalie <ron@brl-vgr>" of Sat 22 Oct 83 15:29:38-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I see nothing wrong with dropping the culprits from the large
mailing lists.  Anybody who doesn't keep their mailbox available
shouldn't be on those lists.  I actively encourage it; it seems to
be the only way those lists ever get pruned of deadwood.
-------

Received: from SU-SCORE.ARPA by MIT-MULTICS.ARPA TCP; 22-Oct-1983 22:43:22-edt
Date: Sat 22 Oct 83 17:54:13-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: "Anti-Social behavior" of mailers
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     The attitude that mail is sacred is fine in a fantasy world where
nobody pays for their disk usage.  I guess the military lives in that
fantasy world.  I knew some research organizations do.

     Somebody has to pay for the disk space used.  An inactive non-paying
user's account can trivially accumulate tons of junk mail.  Stanford's
Computer Science researchers are willing to pay for large chunks of disk
space needed for their research work.  They aren't willing to pay for large
chunks so that some student helper can store thousands of messages about
the latest in science-fiction novels and movies.

     Some accountability has to exist.  I'll bet that most of the accounts
that get "disk quota exceeded" return mail fall into a peripheral category
of user.  You know the type; some undergraduate who gets an account for a
summer job and proceeds to get on every mailing list on the ARPANET.

     I'm sorry if DARCOM doesn't like this.  But have I got a deal for
DARCOM.  We'll remove the restrictions if DARCOM is willing to pay for the
disk usage of all such users.  We'll be quite happy to take DARCOM's money
to support unimpeded junk mail.  Of course, the GAO may object.  But that
would be DARCOM's worry, wouldn't it?
-------

Date:  Sunday, 23 October 1983 23:00 edt
From:  "Jeffrey I. Schiller"@MIT-MULTICS.ARPA
Subject:  Re: "Anti-Social behavior" of mailers
To:  Mark Crispin <MRC@SU-SCORE.ARPA>
cc:  WMartin@OFFICE-3.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To:  Message of 21 October 1983 15:15 edt from "Mark Crispin"
Message-ID:  <831024030006.385023@MIT-MULTICS.ARPA>

The Multics mailer behave exactly as MRC describes his TOPS-20 mailer
(but silently, ie. when we receive mail for a user overquota it is
silently queued for later delivery). If this mail isn't delivered in 5
days it will then be returned. The way we solve the system disk space
problem (ie. a mailer goes nuts and starts sending tons of crap at us)
is to make sure we have enough disk space around to absorb stuff for as
long as it takes for a staff member here to notice the problem and
remedy it (up to a day).

                    -Jeff

Date: 23 Oct 1983 22:29-PDT
Sender: GEOFF@SRI-CSL
Subject:  Re: "Anti-Social behavior" of mailers
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff@SRI-CSL
To: header-people@MC
Message-ID: <[SRI-CSL]23-Oct-83 22:29:52.GEOFF>

I think the bulk of complaints could be solved if the TOPS-20
mailer (and others) only notified the message sender of its
COMPLETE FAILURE to deliver the message after a certain time
period (along with a copy of the undeliverable message).
Instead, of its current practice of sending nuisance warning
message after nuisance warning message and then eventually the
failure to deliver message.

I only want to be notified on COMPLETE FAILURES of an attempt to
deliver a message, not a day-by-day count down of "n more days to
go before I'll be returning your as yet undelivered message to
you."  --or at least there ought to be a way for the sender to
notify foreign mailers to only tell them of COMPLETE FAILURES and
suppress all the warning crap.

Geoff

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.11)
	id AA06003; Mon, 24 Oct 83 08:32:55 pdt
Received: from ucbjade.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.10/4.6) id AA27967; Mon, 24 Oct 83 08:41:43 PDT
Message-Id: <8310241541.AA18440@ucbjade.CC.Berkeley.ARPA>
Received: from UCBCMSA.BITnet by ucbjade.CC.Berkeley.ARPA
	(4.10/4.6) id AA18440; Mon, 24 Oct 83 08:41:29 PDT
Date: Mon, 24 Oct 83 08:38:48 PDT
From: SPGGGM%UCBCMSA.CC@Berkeley
To: ee.gds@mit-oz.ARPA
Cc: csc126%bostonu.BITNET@Berkeley, header-people@mit-mc.ARPA
Subject: bitnet addresses

Bitnet addresses are currently of two flavors.  The addresses you will see
on this message are the 'new' style.  The addresses of form g.host=user are
artefacts (and, in fact, rather embarrassing).

Greg Minshall

Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA06495; Mon, 24 Oct 83 09:07:58 pdt
Received: by ucbarpa.ARPA (4.16/4.11)
	id AA09909; Mon, 24 Oct 83 09:16:29 pdt
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 24 Oct 1983 0916-PDT (Monday)
Message-Id: <9907.31.435860186@ucbarpa>
To: WMartin@Office-3   (Will Martin)
Cc: header-people@MIT-MC
Subject: Re:  Anti-Social behavior of mailers.
In-Reply-To: Your message of 21 Oct 1983 1337-PDT.
             <[OFFICE-3]21-Oct-83 13:37:53.WMARTIN>
Fcc: mail

A semi-naive user (i.e., someone who views a computer system as a tool that
should work, rather than as a toy to tinker with) wants that tool to work.
If the user is unfamiliar with the system, sending a simple message can be
a major project.  If that message is rejected with the not-so-obvious
message "user allocation quota exceeded: message rejected" or some such
(and the message is not returned!!), some people will never try again --
they will have been converted to subconcious saboteurs.  I'm sure all of
us have met the type at one time or another.

This is especially prevalent in office automation environments.

eric allman

Received: from merlin.ARPA by purdue.ARPA; Mon, 24 Oct 83 11:38:38 EST
From: Christopher A Kent <cak@PURDUE.ARPA>
Message-Id: <8310241638.AA09743@merlin.ARPA>
Received: by merlin.ARPA; Mon, 24 Oct 83 11:38:40 EST
Date: 24 Oct 1983 1138-EST (Monday)
To: eric%ucbarpa@Berkeley.ARPA (Eric Allman)
Cc: header-people@MIT-MC.ARPA, WMartin@Office-3.ARPA   (Will Martin)
Subject: Re:  Anti-Social behavior of mailers.
In-Reply-To: Your message of 24 Oct 1983 0916-PDT (Monday).
             <9907.31.435860186@ucbarpa>

MRC flamed a little while ago about users who use mail as a type of
FTP. I agree that this is, in general, a bad thing. But what we are
going to run into this all over again, and in massive proportions, when
the MILNET mail bridges start enforcing the SMTP only fence. What then?

Cheers,
chris
----------

Date:     Tue, 25 Oct 83 1:05:01 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       ee.gds%oz@brl.arpa
cc:       G.Bostonu=csc126@ucb-vax, msggroup%mit-oz@brl.arpa, header-people@mit-mc
Subject:  Re:  Computer Science Seminar at BU

Bitnet sites don't.  This is a perterbation done by Berkeley
sendmail program which is the most frequently used arpanet to
bitnet gateway.  BITNET addresses are rather bland RFC822 stuff
like:
	FRED@PSUVAX
	BRUCE@UMDB
etc...Within BITNET that address was likely:
	CSC126@BOSTONU.

-Ron

Date:     Tue, 25 Oct 83 1:29:37 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Brinton Cooper <abc@brl-bmd>
cc:       Ron Natalie <ron@brl-vgr>, Brinton Cooper <abc@brl-bmd>, WMartin@office-3, 
          Header-People@mit-mc
Subject:  Re:  Anti-Social behavior of mailers.

Return to sender.  Although as I recall, this may only apply to
non-first class stuff.

-Ron

Date:     Tue, 25 Oct 83 2:00:42 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Mark Crispin <MRC@su-score.arpa>
cc:       ron@brl-vgr.arpa, WMartin@office-3.arpa, Header-People@mit-mc.arpa
Subject:  Re:  "Anti-Social behavior" of mailers

My major complaint is that when dealing with a list of over 200
adresses that handles over 20 pieces of mail a day, it takes very
few people being "anti-social" to blast the REQUEST mailbox all to
hell with failed mail requests.  Currently I am helpless once some
site tells me "couldn't do it in a day" for I know that in two more
days I will get another answer "couldn't do it at all" and I am
helpless to stop it.


Perhaps the solution here is a class a service field?  This would
allow mail to be marked as "junk mail" (or perhaps "bulk mail" is
more appropriate) and have the error processing behave differently.

-Ron

Date: 24 Oct 83 19:46:20 PDT (Mon)
From: Marshall Rose <mrose.uci-750a@Rand-Relay>
Return-Path: <Mrose%uci-750a.UCI@Rand-Relay>
Subject: Re: Anti-Social behavior of mailers.
Message-Id: <267.435897980@uci-750a>
To: Christopher A Kent <cak@Purdue>
Cc: header-people@Mit-Mc, Will Martin <WMartin@Office-3>
In-Reply-To: Your message of 24 Oct 1983 1138-EST (Monday).
	     <8310241638.AA09743@merlin.ARPA>
Via:  UCI; 24 Oct 83 20:21-PDT

    [N.B.: This message classifies as a flame since it takes a position
    somewhat different that those currently being espoused...]

    A couple of points:

    In principle I will agree that using mail services as an ftp
    facility is a bad idea.  As someone who lives primarily in the
    CSnet world, though let me point out that we don't enjoy the type
    of connectivity that you ARPAnetters take for granted.  We spend
    our time living at the end of a 1200-baud phone link, most of us
    connect to an ARPAnet site perhaps two to four times a day in the
    evening and early morning hours.  Some of us are lucky enough to
    have a guest account floating about on a machine with ARPAnet
    access, so we can get to all kinds of information.  UCI is lucky,
    we'll shortly become a member of the ARPA Internet community (but
    over a 9600 baud line, sigh...), but others are not.  The point of
    this is that you really shouldn't try and judge those who are
    connectivity-poor by your standards.  I don't know if you really
    appreciate your high-standard of communications-living.

    Second, do you people really have distribution list stuff delivered
    to your private mailboxes???  Although I read quite a few lists,
    none of it goes to my private mailbox.  It all gets diverted to a
    common, public area, where a single copy is kept.  This area is
    automatically cleaned out on a regular basis.  Not only does this
    save gobs of disk space but it also keeps bulk-rate mail out of my
    private "post-office box".  Since we're running BSD UNIX, we don't
    have disk-quotas, so I don't worry about having mail rejected for
    that reason (it is true we could run out of disk space, but that's
    another story).  I would get very, very upset if my mail got
    returned because of some "administrative nonsense" about disk
    quotas.  Once I log in, I should be responsible for trimming things
    to reach my quota, but until I do so, I DEMAND that my mail not be
    returned unless the disk is full.  My extreme position is due, of
    course, to the fact that I know only IMPORTANT mail gets delivered
    to my private mailbox.

    Awaiting your equally hot rejoinder to my response,

/mtr

    BTW - I'm giving people a few more days on the "Can your UA
    filter-out unwanted headers?" query before I post the summary.

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 25 Oct 83 09:24:00 EDT
Date: 25 Oct 83 0932 EDT
From: Rudy.Nedved@CMU-CS-A
To: Marshall Rose <mrose.uci-750a@Rand-Relay>
Subject: Re: Anti-Social behavior of mailers.
CC: Header-People@MIT-MC
In-Reply-To: <267.435897980@uci-750a>
Message-Id: <25Oct83.093228.EN0C@CMU-CS-A>

In the world of 1200 UUCP/DIALNET links and 9600 IP links, there is also
a world of private and ugly hacks that get mail thru. These ugly transfer
hacks tend to clog up when they try to handle 1MB files since they were
never designed to handle slow delivery processes and systems.

I have a feeling that for every person that uses the system as a file
transfer mechanism, there is a tenuous link between a two machines that
can't handle a large file. Admittedly things are getting better when people
use better hardware links and better software but things can't change
over night.

CMU Computer Science sites are constantly running out of disk space even
though we have disks galore....People are just to lazy to clean up there
disk space and be frugal about it. Hey like laser disks are around the
corner!!! (If you believe that I have this bridge in Pittsburgh to sell
you).

I think a more constructive tack to take with this issue is the discussion
of first class and second class mail. We will probably implement a mechanism
that uses the size of the file to determine its priority since the mail world
is expanding faster then the IP world and we do hit slow mail bridges. The
question remains is it reasonable to expect some pieces of mail to be delivered
to another site in the world within 10 minutes?? I have discovered people
sending out mail to other people saying "Joe called a few minutes ago, he
wants to talk to you before your meeting in an hour."

-Rudy

Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA02389; Tue, 25 Oct 83 08:05:48 pdt
Received: by ucbarpa.ARPA (4.16/4.11)
	id AA25935; Tue, 25 Oct 83 08:14:35 pdt
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 25 Oct 1983 0814-PDT (Tuesday)
Message-Id: <25934.31.435942874@ucbarpa>
To: Christopher A Kent <cak@PURDUE.ARPA>
Cc: header-people@MIT-MC.ARPA, WMartin@Office-3.ARPA   (Will Martin)
Subject: Re:  Anti-Social behavior of mailers.
In-Reply-To: Your message of 24 Oct 1983 1138-EST (Monday).
             <8310241638.AA09743@merlin.ARPA>
Fcc: mail

When mail is easy to use and FTP is hard to use, people will use mail
instead of FTP.  We can go on forever about how this is "the wrong
way to do it" without changing this fundamental point of human nature.

In many cases using Mail as FTP may even be correct -- e.g., when
sending to some process that will consume the data and do something
for you.  The CSNET name server, MARS, and MOSIS are examples of this.

Which still begs the question of how to handle the resulting disk
space problem.  My point is simply that we cannot ignore the issue
in the hopes that we can convince people not to do it.

eric

Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA02757; Tue, 25 Oct 83 08:22:32 pdt
Received: by ucbarpa.ARPA (4.16/4.11)
	id AA26146; Tue, 25 Oct 83 08:31:25 pdt
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 25 Oct 1983 0831-PDT (Tuesday)
Message-Id: <26145.31.435943884@ucbarpa>
To: Ron Natalie <ron@brl-vgr>
Cc: WMartin@office-3.ARPA, Header-People@mit-mc.ARPA,
        Mark Crispin <MRC@su-score.ARPA>
Subject: Re:  "Anti-Social behavior" of mailers
In-Reply-To: Your message of Tue, 25 Oct 83 2:00:42 EDT.
             <8310250631.AA24631@ucbvax.ARPA>
Fcc: mail

If you include a "Precedence: junk" field in the header, sendmail will
throw away error messages rather than return them.  This was intended
to act like USPS "junk mail" service.

eric

Date: Tuesday, 25 Oct 1983 10:45-PDT
From: Steven Tepper <greep@SU-DSN>
To: header-people@MIT-MC
Subject: "Precedence: junk" field

Things like a "precedence" field aren't too useful if only one mail
system knows about them.  Maybe someone should send this, or other
related suggestions, out as an RFC.  Then if there is general agreement
that it's a good idea, there is even some hope of it being implemented
on enough systems to be of some real use.

Date: 25 Oct 1983 2143-EDT
From: Greg Skinner <Gds@MIT-XX>
Subject: Re: Anti-Social behavior of mailers.
To: mrose.uci-750a@RAND-RELAY
cc: header-people@MIT-MC
In-Reply-To: Your message of 24-Oct-83 1946-EDT

It's rather difficult to have public mail-archive files that everyone
can use.  If there isn't enough disk space for everyone to keep theeir
own junk mail, there sure isn't enough space to keep public junk mail.
MIT systems generally keep public bboards around and discourage users
from having distribution lists come to their private mailboxes.

However, some systems just can't (or don't) have public bboards, and
those users who want junkmail have to use their private accounts to
store it.  

Another issue -- if there was a public bboard for every distribution
list in the Internet world, every machine on the Internet would be
dedicated to mail processing and storage, and no other work would get
done.  The demand for certain mailing lists is low (e.g. AI-list would
get lots less attention on one of our Internet vaxen used for
networking or compiler research.  The maintainers wouldn't be too
happy about keeping a public bboard for it -- in fact, probably would
wish people to have their junkmail forwarded to a machine on another
system with more disk space.
-------

Date:     Tue, 25 Oct 83 22:31:18 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Greg Skinner <Gds@mit-xx>
cc:       mrose.uci-750a@rand-relay, header-people@mit-mc
Subject:  Re:  Anti-Social behavior of mailers.

The other advantage to having lower volume junk mail delivered
to a user mailbox is that after he reads it he can delete it unless
of significance to him.  On a public BBOARD it must sit around for
some period of time to allow everyone who may wish to see it to do
so.

-Ron

Received: from ucbarpa.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA05704; Tue, 25 Oct 83 23:13:16 pdt
Received: by ucbarpa.ARPA (4.16/4.11)
	id AA09386; Tue, 25 Oct 83 23:22:04 pdt
From: eric%ucbarpa@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 25 Oct 1983 2322-PDT (Tuesday)
Message-Id: <9385.31.435997321@ucbarpa>
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: Header-People@MIT-MC.ARPA
Subject: Re: Results of SMTP server inquiries
In-Reply-To: Your message of Thu 20 Oct 83 13:11:36-PDT.
             <8310240817.AA00221@ucbvax.ARPA>
Fcc: mail

I find your attitude rather offensive considering that the SMTP protocol
does not specify timeouts.  I agree that the protocol should specify
some sort of timeout, and that real implementations should try to respond
as quickly as possible, and even that real implementations need some
sort of timeout for purely pragmatic reasons -- but two minutes?!?
Sendmail uses a timeout of two hours (yes, hours), on the grounds that
I never want to see a message trashing me for making the (apparently
illegal) timeout too small.

eric

Date: 26 Oct 83 13:29:10 PDT (Wed)
From: Marshall Rose <mrose.uci-750a@Rand-Relay>
Return-Path: <Mrose%uci-750a.UCI@Rand-Relay>
Subject: Re: Anti-Social behavior of mailers.
Message-Id: <267.436048150@uci-750a>
To: Greg Skinner <Gds@Mit-Xx>
Cc: header-people@Mit-Mc
In-Reply-To: Your message of 25 Oct 1983 2143-EDT.
Via:  UCI; 26 Oct 83 19:24-PDT

    I'm not sure I understand what is meant by "enough disk space for
    everyone to keep their own junk mail", and "enough space to keep
    public junk mail".  I don't consider anything sent to my private
    mailbox to be junk (though it does come close at times!), while I
    view everything sent to a public BBoard to be junk mail.  Perhaps
    this is entirely a difference in perspective.  Clearly though, it
    should be cheaper, in terms of disk space, to keep a single copy of
    a discussion group on a system than to replicate that copy several
    times over in various people's mailboxes.

    I wasn't suggesting that we should have copies of every discussion
    group on every system in the Internet:  we have four machines
    locally, each with varying tastes, and they subscribe to different
    discussion groups.  There is some overlap, but we never keep more
    than one copy of a particular message on a system unless a user
    specifically goes out of his/her way to duplicate it for his/her
    own, private purposes.

    It is also true that all systems can not support a public BBoard
    facility.  This is unfortunate.  But then its also true that a lot
    of systems don't support a lot of things that "sophisticated" mail
    users find to be "required", such as templates, good editor
    interfaces, etc., etc.  I've always found it easier to code than to
    complain (no flames please), so it's my position to sigh and say,
    "Well, you could be doing X if you wanted to.  We found that it
    solved a lot of problems, but do what you want with your system."

/mtr

    PS - in a previous message I was't suggesting that CSnet people
    should be using mail for 1MB FTP:s or the like.  I use mail for
    moving things like the smaller RFCs, etc.  If it's something
    "really big", I'll FTP it "closer" to home, put it on tape, and
    then drive over.

Received: by ucbvax.ARPA (4.16/4.13)
	id AA01831; Thu, 27 Oct 83 17:34:42 pdt
Date: 27 Oct 83 19:43:41 EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: Anti-Social behavior of mailers.
Message-Id: <8310272343.AA05796@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA05796; 27 Oct 83 19:43:41 EDT (Thu)
To: Gds@MIT-XX.ARPA
Cc: header-people@mit-mc.ARPA

	Another issue -- if there was a public bboard for every distribution
	list in the Internet world, every machine on the Internet would be
	dedicated to mail processing and storage, and no other work would get
	done.  The demand for certain mailing lists is low (e.g. AI-list would
	get lots less attention on one of our Internet vaxen used for
	networking or compiler research.  The maintainers wouldn't be too
	happy about keeping a public bboard for it -- in fact, probably would
	wish people to have their junkmail forwarded to a machine on another
	system with more disk space.

This is a reasonable guess, coming from a system that does not do this.
But on Usenet, the situation is that every system gets (one copy of)
every article.  (There are exceptions - some systems refuse to accept
certain newsgroups, others are tiny or phone-poor and can only get a
handfull, but almost everybody gets everything.)  We find that by treating
each newsgroup as just another newsgroup (rather than having a list of
200 mailing lists that have to be maintained by a person) that the number
of newsgroups is not really a limiting factor.  The amount of traffic is
the limiting factor.  Not for the machine - when everything uses the same
mechanism, you can find inefficiencies and streamline things - but for the
people.  No person has the time to read everything (not even Lauren) so
we cut down what we don't want to read or don't have time to read.

On cbosgd, we receive about 250 articles per week, with about 5 MB of
text for a week.  We receive each article from two (sometimes 3) different
Usenet neighbors, and the first copy we get is forwarded to 8 other
neighbors.  Of course, things are batched - bulk mail is lower priority
than people mail - this helps a lot.  We also have various schemes to
avoid keeping more than one copy on the disk at any time, so that if a
neighboring machine goes down for a week, we don't fill up the disks
with stuff for them.  cbosgd is a VAX 11/750 running 4.1cBSD, and the
load put on the machine by news is pretty insignificant.  The major cost
is having 10 MB of disk to keep 2 weeks of news around.

I wonder if anyone has any figures on total traffic volume for the set of
ARPANET mailing lists, or at least any estimates?  I also wonder if there
are any comparisons showing how many extra copies sit on machines where
2 or more people get a mailing list, compared to the savings from machines
that only get some subset of the lists?  Anyone know how much human effort
is spent by people other than the master list moderator maintaining sublists?

	Mark Horton
	mark@Berkeley.ARPA

Date:     Thu, 27 Oct 83 22:44:41 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Mark Horton <cbosgd!mark@ucb-vax>
cc:       Gds@mit-xx.arpa, header-people@mit-mc.arpa
Subject:  Re:  Anti-Social behavior of mailers.

You seem to be under the impression that delivering a copy of a bulk
letter to multiple users on a machine induces more network traffic
than delivering one copy to a billboard.  Reasonable SMTP implementations
deliver a single copy to remote site with multiple recipients so that
it only transfers the message body once.

-Ron

Date:  28 October 1983 22:55 edt
From:  Saltzer at MIT-MULTICS
Subject:  Re: What to do about non-Internet mail hosts.
To:  Schiller at MIT-MULTICS
cc:  Mark Crispin <MRC at SU-SCORE>, dpk at BRL-VGR, 
     Header-People at MIT-MC, Postel at USC-ISI, 
     Saltzer at MIT-MULTICS, DClark at MIT-MULTICS
In-Reply-To:  Message of 14 October 1983 11:08 edt from Jeffrey I. Schiller

Jeff, Are you sure that implementing domains completely solves the
problem?  It seems to me that depending on how far out of kilter the
non-ARPA mail is that other hosts will still have trouble with the
reply.  I would have expected that it is inherent in the problem that a
gateway that forwards mail from one system to another has to fabricate
new headers as it goes across, unless it happens to get lucky.
		Jerry

Date: 29 Oct 1983 1055-EDT
From: Greg Skinner <Gds@MIT-XX>
Subject: Re: What to do about non-Internet mail hosts.
To: Saltzer@MIT-MULTICS
cc: header-people@MIT-MC
In-Reply-To: Your message of 28-Oct-83 2255-EDT

Domains actually could be a winning feature as far as reaching distant
hosts on distant nets.  Howerver, it seems that they are providing a
current source of confusion.  Some mailers (on uucp, for example) are
trying to parse the domain field as just another host field, and run
into trouble for replies (Unknown host: ARPA).

As I understand it, domains are supposed to assist in the routing of
messages to appropriate gateways.  Thus, in the case of a host like
MC, which talks to the Arpanet, LCSnet and Chaosnet, the domain field
is pretty useful.  But for non-Internet hosts which have no way of
understanding this information (since they don't have our host tables)
they can't handle the domain field correctly.  From what I gather in
your message, Internet hosts are having equal trouble with knowledge
of unknown domains.  (By the way, I heard that ARPA was the only
recognized domain by the NIC -- what about UUCP, UCI, #Chaos etc. --
maybe unregistered domains cause the confusion.)

It may be a bit much to ask for all mailers to adopt the same mail
parsing, but I think we are rapidly approaching the point where if we
want to be able to get a message from point to point, both points (as
well as any intermediaries) should agree on how the message should be
processed. 

--greg
-------

Date:  Saturday, 29 October 1983 12:34 edt
From:  "Jeffrey I. Schiller"@MIT-MULTICS.ARPA
Subject:  Re: What to do about non-Internet mail hosts.
To:  Saltzer@MIT-MULTICS.ARPA
cc:  Mark Crispin <MRC@SU-SCORE.ARPA>, dpk@BRL-VGR.ARPA, 
     Header-People@MIT-MC.ARPA, Postel@USC-ISI.ARPA, 
     DClark@MIT-MULTICS.ARPA
In-Reply-To:  Message of 28 October 1983 22:55 edt from Saltzer
Message-ID:  <831029163451.279380@MIT-MULTICS.ARPA>

Indeed you are correct. What is needed is for the receiving host to know
about all hosts in all domains. Alas this is what name servers are
supposed to be from. So if a host received a piece of mail for
FOOBAR.MAILNET and MAILNET was a registered domain (say with MIT-MULTICS
as the home of the name server for that domain) then the receiving host
could contact MIT-Multic's domain name server to get the forwarding host
information (or failing that could merely send the mail to MIT-Multics
for forwarding).

                    -Jeff

Date: Sat 29 Oct 83 12:10:30-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: SMTP extension RFC
To: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     This Request for Comments suggests a potential extension to the
SMTP standard (RFC 821).  Should it be accepted, software designers
are encouraged to support these optional extensions in order to gain
the desired functionality.

			BACKGROUND

     Problems have come up with conflicting uses and needs of electronic
mail.  In particular, delivery or allocation considerations often conflict
with a particular purpose electronic mail is put to, including: mailing
lists, urgent messages, ordinary messages, etc.

			PROPOSAL

     RFC 821 is extended to add the CLAS command, for "class of service"
for this message.  CLAS takes at least one required argument, indicating
the class of service.  Future extensions may add subsequent arguments, or
add additional classes of service.  Should "too many arguments" be seen
the excess arguments should be ignored by the SMTP receiver and the
command accepted or rejected based on the SMTP receiver's willingness to
accept the command and argument(s) it does recognize.

     CLAS is an optional command.  An SMTP sender must be willing to
accept a CLAS rejection.  The default class is "CLAS 1", or "first class"
mailing.  The CLAS commands are:

     CLAS 1 - First class mail.  This is a message on the level of a
person-to-person message.  Reasonable efforts should be made to deliver
the message, and inform the sender (via the Return-Path) of any untoward
delays.  First class mail should not be rejected or returned to sender if
it is reasonably possible to deliver the message within technical or
managerial constraints.  In particular, first class mail should not be
rejected because that mailbox has a forwarding address to another mailbox
elsewhere.  Implementations should not reject first class mail based on
allocation constraints without allowing at least a few days for the
problem to clear up.

     CLAS 2 - Second class mail.  This is a message on the level of a
small or other "full participation" mailing list where all members can be
expected to be interested in all the messages.  Second class mail should
be treated as first class mail in most respects, except that only
non-delivery notifications should be made; no delayed delivery notifications
are expected or desired.

     CLAS 3 - Third class or "junk" mail.  This is a message for a large
mailing list or other list in which only some of the messages may be of
interest.  Only non-delivery notifications should be made; return to
sender is discouraged.  Third class mail may be rejected immediately for
forwarded addresses (see the SMTP specification for documentation of
the 551 error) or insufficient allocation (see SMTP for 552).

	** Note: First class mail should never be rejected because of
	   551 or 552 conditions.  It is discouraged to use 551 or 552
	   for second class mail. **

     CLAS 4 - Fourth class or "parcel post" mail.  The message sent is
large, e.g. a file or document being sent via a communication channel
which does not support FTP.  Fourth class mail is nominally treated as
FIRST class mail.  The receiver is strongly discouraged from rejecting
or returning it to sender if it can be "reasonably" delivered.  Fourth
class mail exists to give the receiver warning of the large size of this
message so that the receiver may deliver it separately and concurrantly
with its normal mail delivery processes.

     CLAS P - Priority mail.  This is the same as first class mail, but
the receiver is asked to go to extra effort to deliver this message
provided the receiver offers this service.  For example, some receivers
may allow allocations to be evaded via priority mail, but no receiver is
obligated to do so.  The receiver IS obligated to inform the sender
promptly (e.g. within 30 minutes) of any delays in delivery.  This differs
from first class mail which should not start delay notifications until at
least a day has elapsed.

     CLAS R - Registered mail.  This is the same as priority mail, except
that the receiver is obligated to give positive acknowledgement of
delivery to the destination mailbox.  This differs from positive
acknowledgement of being read by the mailbox's owner, which would be
implemented at the RFC 822 level.

				ERRORS

	500 Command unrecognized
	501 Syntax error
	502 Command not implemented
	503 Bad sequence; must give CLAS before recipients
	503 Bad sequence; only one CLAS allowed for this transaction
	504 CLAS type unknown, continuing to assume CLAS 1

**************************************************************************

     I must apologize for any gothicness in this proposal.  Obviously,
it should be subjected to some modification prior to being adopted.  I
confess that this proposed implementation minimizes the amount of surgery
required to the TOPS-20 mailsystem (in fact, very little would need to
be done to do this), so there are probably some biases that need to be
worked out.
-------

Date: Sat, 29 Oct 83 17:02 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON>
Subject: SMTP extension RFC
To: Mark Crispin <MRC@SU-SCORE>
Cc: Header-People@MIT-MC, Postel@USC-ISIF
In-reply-to: The message of 29 Oct 83 15:10-EDT from Mark Crispin <MRC at SU-SCORE>
Message-ID: <831029170229.5.RWK@SCRC-YUKON>

	 CLAS 3 - Third class or "junk" mail.  This is a message for a large
    mailing list or other list in which only some of the messages may be of
    interest.  Only non-delivery notifications should be made; return to
    sender is discouraged.  Third class mail may be rejected immediately for
    forwarded addresses (see the SMTP specification for documentation of
    the 551 error) or insufficient allocation (see SMTP for 552).

I don't think it is acceptable to not deliver so-called "junk" mail just
because it requires forwarding.  ALL of my mail in this class is
forwarded by MIT-MC.  MIT-MC serves as a central post-office relay
facility in this, rather than as "moved, left forwarding address".  And
the so-called "junk mail", is actually closer to magazines than
advertising flyers.

Indeed, it is not clear from this what "forwarded" means.  Is
"RWK%SCRC-YUKON" at MIT-MC a forwarded address?  How about RWK at
MIT-MC, which is how my address appears on most mailing lists?
Perhaps "forwarded" means simply an address that a mailer says to
forward with a 551 response.  Whatever THAT means; RFC-822 fails to
assert this should be done only when a more direct path exists.
And are user-end programs required to handle this by retransmitting
to the new address?

I'm not sure whether to change the statement of what's acceptable or
the definition of "junk mail".  I just want reliable delivery of
mailing-list mail under ordinary circumstances.

Received: by ucbvax.ARPA (4.16/4.13)
	id AA16443; Sat, 29 Oct 83 19:07:42 pdt
Date: 29 Oct 83 22:05:26 EDT (Sat)
From: ulysses!smb@Berkeley (Steven Bellovin)
Subject: SMTP Extension
Message-Id: <8310300205.AA09044@ulysses.UUCP>
Received: by ulysses.UUCP (3.327/3.7)
	id AA09044; 29 Oct 83 22:05:26 EDT (Sat)
To: Header-People@MIT-MC, MRC@SU-SCORE

Although I see why you want SMTP to know about mail classes, the user
agent may need to know about them as well.  In particular, I'd like my
mail receiver or mail reader to be able to present my first-class mail
first.  Of course, this means that we need an RFC822-type header field
as well.  Any thoughts on how to integrate the two?

			--Steve Bellovin

Date: 29-Oct-83 22:45 PDT
From: RICH.GVT@OFFICE-3
Subject: Re: SMTP extension RFC
To: Header-People@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-3G4Z1>

Integrating CLAS in the "envelope" and a new, matching, header field should be 
trivial.  After all, it is from the user the information must come if other than
the default class is to be used, and the user agent would both insert the Class:
header field and pass the "envelope" information through the delivery slot to 
the User SMTP.

-Rich Zellich


Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 30 Oct 83 02:42:34 EST
Date: 30 Oct 83 0247 EST
From: Rudy.Nedved@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP extension RFC
CC: Header-People@MIT-MC, Postel@USC-ISIF
In-Reply-To: "Mark Crispin's message of 29 Oct 83 14:10-EST"
Message-Id: <30Oct83.024718.EN0C@CMU-CS-A>

Mark,

Hopefully it would not be too much to ask to use keywords instead of
numbers and single characters. I kinda like the future flexibility
that keywords like "FIRST" or "THIRD" present over numbers like "1" and
"3". Maybe only CMU'ers get burned because of our extremely non-homogenous
enviroment with subtle design decisions like this one.

-Rudy

Date: 30 Oct 1983 1132-EST
From: Greg Skinner <Gds@MIT-XX>
Subject: Re: SMTP extension RFC
To: RWK@SCRC-YUKON
cc: MRC@SU-SCORE, Header-People@MIT-MC, Postel@USC-ISIF
In-Reply-To: Your message of 29-Oct-83 1707-EDT

Perhaps instead of having immediate rejection of forwarded addresses,
attempt to forward but do not return to sender if the ultimate
destination is not reached.  This way, for persons on remote nets who
wish to receive mail from large distribution lists, they are not
denied that privilege just because their net won't talk to ours.  This
also cuts down on the failed mail messages including text (which I
find a pain, especially if a host tries for two weeks to forward a
message and complains every day that it can't).

Also, some forwarded messages are not relayed to other hosts -- for
example, my address for MsgGroup (as far as BRL is concerned) is
GDS-MSG@OZ which is forwarded to a mailbox especially for MsgGroup
mail.  I'd be very unhappy if because of class scheduling I couldn't
get any MsgGroup mail anymore.
-------

Date: Sun 30 Oct 83 10:49:30-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: SMTP Extension
To: ulysses!smb@UCB-VAX.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "ulysses!smb@Berkeley (Steven Bellovin)" of Sat 29 Oct 83 22:05:26-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

It strikes me that the presentation layer mail class may not necessarily
be related to the transport layer mail class.  I was, I confess, only
addressing the transport layer issue.

My suggestion would be to define a presentation layer mail class
specification independently, and then consider how the two are best
integrated.  I suspect that their integration is best done as a user
interface within the individual mail systems.
-------

Date: Sun 30 Oct 83 10:56:04-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: SMTP extension RFC
To: Rudy.Nedved@CMU-CS-A.ARPA
cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA
In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 30 Oct 83 02:47:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

I don't object to keywords at all, although there seems to be a tendency
to use 1 or 4 character keywords.  I was trying to follow the flavor of
FTP and friends.  My software would have no problem coping with any form
of keywords, although it would be nice if they were 4 characters so that
word comparisons would work nicely on all systems...
-------

Date: Sun 30 Oct 83 11:03:24-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: SMTP extension RFC
To: Gds@MIT-XX.ARPA
cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA
In-Reply-To: Message from "Greg Skinner <Gds@MIT-XX>" of Sun 30 Oct 83 08:32:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The intention is that a site which wishes to use the 551 error only do
so for third class mail.  A site or implementation which never wants to
use 551 has no obligation to do so.  In other words, I was trying to
add a ban on using 551 for first class mail instead of a requirement
that it be used for third class mail.

Some distinction has to be made between forwardings within the same
network registry and forwardings which exit it, of course.

I doubt the TOPS-20 mailsystem will ever implement 551 errors unless
some site explicitly requests it.
-------

Date: Mon 31 Oct 83 01:04:06-PST
From: David Roode <ROODE%SRI-NIC@SRI-NIC>
Subject: Re: "Anti-Social behavior" of mailers
To: MRC%SU-SCORE@SRI-NIC, Header-People%MIT-MC@SRI-NIC
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Sun 23 Oct 83 21:55:16-PDT
Location:  EJ286    Phone: (415) 859-2774

May I suggest a buffer zone for use by system mail daemons.
I.e., a users quota is n, but the mailer permits him
to accumulate up to 110% of n in disk pages for its writes to
his mail file.  This should circumvent the problem with a
departed user accumulating 1000's of pages of disk storage, 
and yet still permit a measure of flexibility to active users,
avoiding a high proportion of the mail-rejection situations
which are arguably subject to criticism without missing too many
of the justifiable ones.
-------

Date: 31 Oct 83 02:32:20 PST (Mon)
From: Marshall Rose <mrose.uci-750a@Rand-Relay>
Return-Path: <Mrose%uci-750a.UCI@Rand-Relay>
Subject: Summary of Filtering
Message-Id: <267.436444340@uci-750a>
To: header-people@Mit-Mc
Via:  UCI; 31 Oct 83 2:43-PST

    I got a total of 14 responses.  Of the 12 systems mentioned, 8 give
    you full control over which headers you see, 3 give you partial
    control (e.g. verbose v. quiet mode), and 1 gives you no control at
    all.  If anyone wants to see the data, send me (not the list) a
    message.

    Since the sampling size is so small, I conclude that either 1)
    there are only about 20 people reading Header-People, or 2) this
    issue isn't that important.

    Thanks to those who replied.

/mtr

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 31 Oct 83 11:09:11 EST
Date: 31 Oct 83 1120 EST (Monday)
From: don.provan@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP extension RFC
CC: Header-People@MIT-MC, Postel@USC-ISIF,
In-Reply-To: "Mark Crispin's message of 29 Oct 83 14:10-EST"
Message-Id: <31Oct83.112013.DP0N@CMU-CS-A>

rather than add a command, maybe we should consider adding a field
to the mail command.  it already has one: "from".  maybe we could
add a class field.  of course this would probably break every server
there is, since no such extension is allowed according to the specs,
but at least it would make me feel it would be worth the effort to check
to see if the user process really said "from:".  what was the idea
behind that, anyway?  i imagine most servers will take "quack:" instead,
just like mine.  if we aren't going to make use of the label, why
not make it optional?

Date: Mon 31 Oct 83 10:33:44-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: SMTP extension RFC
To: don.provan@CMU-CS-A.ARPA
cc: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA
In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 31 Oct 83 11:20:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The TOPS-20 SMTP server requires "from:" exactly as the spec states.
It also requires the exact syntax as used in the spec, e.g.
"MAIL FROM:<>" not "MAIL  FROM:<>" or "MAIL" or "MAIL FROM: <>".
It also validates the syntax of the paths used, although it does all
the older form of source routing to coddle various Unix systems.
-------

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 31 Oct 83 16:26:54 EST
Date: 31 Oct 83 1417 EST (Monday)
From: don.provan@CMU-CS-A
To: Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP extension RFC
CC: Header-People@MIT-MC, Postel@USC-ISIF
In-Reply-To: "Mark Crispin's message of 31 Oct 83 13:33-EST"
Message-Id: <31Oct83.141749.DP0N@CMU-CS-A>

i think mine just drops it into some handy parse-a-mailbox code,
so it may even take "Mail foo@bar".  it certainly takes
"Mail <foo@bar>".  if the "from:<>" isn't important, why should i look for it?

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13)
	id AA21202; Mon, 31 Oct 83 18:06:29 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.10/4.8) id AA04789; Mon, 31 Oct 83 18:06:21 PST
Date: Mon, 31 Oct 83 18:06:54 PST
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311010206.AA10368@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.10/4.8) id AA10368; Mon, 31 Oct 83 18:06:54 PST
To: Header-People@MIT-MC
Subject: Re: SMTP extension RFC
Cc: MRC@SU-SCORE, Postel@USC-ISIF


In reply to:

   Date: Sat 29 Oct 83 12:10:30-PDT
   From: Mark Crispin <MRC@SU-SCORE.ARPA>
   Subject: SMTP extension RFC
   To: Header-People@MIT-MC.ARPA, Postel@USC-ISIF.ARPA

I do not believe that Mark Crispin's "potential extension" to the SMTP
standard (RFC 821) will be acceptable for MILNET communications as
currently proposed. The first problem is one of nomenclature. The
chose of "CLAS" for "class of service" is likely to be confused with
"classification" for information security "classification" (UNCLAS,
CONFIDENTIAL, SECRET, or TOP SECRET). The second problem, is that there
is more than one issue involved in his "class of service" command:
delivery and receipt of messages (reliability), speed of service
(precedence), and message content.

Reliability of communications is the most important requirement of
operational military communication systems. At the SMTP level, this
means that the transmitting host must know whether the message has been
received (or not) by the receiving host.  Cancelling of message in
route without notification to the originator should be allowed only in
very specific situations. One is when the originator cancels the
message, the another is if the message is self-cancelling.  For
example, weather forecasts might carry an instruction indicating that
the message is to be cancelled at a specific time (the time when next
forcast is issued).  (We may want to discuss how to implement
self-cancelling messages as a separate issue. I would not expect to even
see a SMTP transmission started for a self-cancelling message which had
expired.)

A relaying host may indicate that it is unable to accept traffic
for another host (eg. if it cannot relay to that host), but should
accept messages for itself. If it cannot accept traffic for itself
then it should tell the sending host to "wait and try again";
if the problem is not a temporary one, the receiving host should
set off some local alarms to get a human to solve the problem.
After a certain time (which might vary with the precedence of the
message), the transmitting relay host should notify the originating
host that it is unable to make delivery.

On the issue of speed of service indicators, whatever is adopted by
the Internet community should be compatible with the National Precedence
System used by the US Government.  The National Precedence System
is documented in the U.S. Code of Federal Regulations, Title 47 - 
Telecommunications,  Chapter  2,  Part  213  - Government and Public
Correspondence Telecommunications Precedence System. This system
of Precedence Designators has four designator which are used to
indicate the desired speed of service: FLASH, IMMEDIATE, PRIORITY,
and ROUTINE. The military precedence system, which is likely to
be adopted for MILNET use has one additional designator (ECP):

   Precedence   Abbr.   Speed of Service Objective
			(drafter to reader)
   ______________________________________________________

   ECP            Y     As fast as possible
   FLASH          Z     As fast as possible, < 10 minutes
   IMMEDIATE      O     < 30 minutes
   PRIORITY       P     < 3 hours
   ROUTINE        R     < 6 hours

ECP, FLASH, and IMMEDIATE are usually limited to government use.
For purposes of compatibility I suggest that the precedence
designators PRIORITY and ROUTINE be adopted for Internet use.
For purposes of handling large data files, we may want to add
a LOW precedence (L) with a speed of service objective of less
than 24 hours. Thus, I recommend that the following Precedence
Designators be adopted for Internet use:


   Internet     Abbr.   Speed of Service Objective
   Precedence   	(drafter to reader)
   ______________________________________________________

   PRIORITY       P     < 3 hours
   ROUTINE        R     < 6 hours
   LOW            L     < 24 hours

with ROUTINE being the default precedence if a precedence is not
specified by the originator.

With regard to Mark's proposed command name, I suggest that "PREC" for
"precedence" be used at the SMTP level instead of the name "CLAS".
I suspect we will want to reserve the command name "CLAS" for
"classification" as used on DOD telecommunication systems.

Now to the last issue, content designation.  I do not think that
content should be used as criteria as to whether a message should be
relayed or delivered. However, it may be desirable to to have a content
designator so that an automaticed mail box can determine what the
text of the message is by reading the heading and then spool the
text to a particular program. I would put this type of indicator in
the message heading instead of the SMTP envelope.

As a final comment. Let's try to keep the SMTP procedures simple.

Bill Wells
Computing Services, U. C. Berkeley

Date:  31 October 1983 23:26 est
From:  Kovalcik.Multics at MIT-MULTICS
Subject:  Re: SMTP extension RFC
To:  Mark Crispin <MRC at SU-SCORE>
cc:  Header-People at MIT-MC, Postel at USC-ISIF
In-Reply-To:  Message of 29 October 1983 14:13 est from Mark Crispin

Sigh.  I don't see why class 3 mail should be rejected if it has to be
forwarded elsewhere.  It is very convenient to forward some mail to an
alternate location for reading later when going on vacation and so on.
Or, if I know I am going to be working on site X next week, I should be
able to forward all my mail there and remove the forwarding when I get
back.  Forwarding in the sense of electronic mail is very often easier
than informing the sender.  Don't get caught in the trap of trying to
emulate real mail classes.

Date:     Tue, 1 Nov 83 0:47:41 EST
From:     Ron Natalie <ron@brl-vgr>
To:       header-people@mit-mc, llp@mit-mc
Subject:  REQUEST vs. -POSTMASTER

This is a trivial change and there is no point to it.  The problem
(as previously stated) is not what the maintenance address is called
but convincing people to use it rather than just mailing to the list
address.  Since we already have a de facto standard I see no reason
to change.  Both are at best equally indicative of the function of
the address, but personally I feel that "-REQUEST" is more appropriate.

If the change is made, all the list maintainers would then have to
support both -POSTMASTER and -REQUEST addresses because there would
continue to be a high volume of traffic sent to the "-REQUEST" lists.

Ron Natalie
INFO-MICRO-REQUEST, INFO-CPM-REQUEST, INFO-MUSIC-REQUEST
...@BRL-VGR

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13)
	id AA25614; Mon, 31 Oct 83 22:51:46 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.10/4.8) id AA08971; Mon, 31 Oct 83 22:51:44 PST
Date: Mon, 31 Oct 83 22:52:16 PST
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311010652.AA13900@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.10/4.8) id AA13900; Mon, 31 Oct 83 22:52:16 PST
To: Header-People@MIT-MC
Subject: Re: SMTP extension RFC


Ref:	Proposed Federal Information Processing Standard "Specification
	for message format for computer based message systems",
	National Bureau of Standards, Institute of Computer
	Science and Techmology, September, 1981.

Here is an interesting extract from Section 3.1.7:

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

3.1.7 Message-handling fields

	Message-handling fields describe aspects of how a message is
to be handled or categorized.

Precedence	(optional)

	This field indicates the precedence at which the message was
	posted. Ordinarily, message precedence or priority is a
	service request to a message transfer system.  A message
	originator, however, can include precedence information in a
	message. One example of precedence categories are those used
	by the U.S. Military: "ROUTINE", "PRIORITY", "IMMEDIATE",
	"FLASH OVERRIDE" (actually "FLASH" - wcw), and "EMERGENCY
	COMMAND PRECEDENCE (previously "FLASH OVERRIDE" or "EMERGENCY"
	- wcw).

Message-Class	(optional)

	This field indicates the purpose of a message. For example,
	it might contain values indicating that the message is a
	memorandum or a data-base entry. (Footnote 1)

......
Footnote 1:
	The message format specification is not intended to be used
	as a specification for exchanging data-base records.
	Messages, however, sometimes contain data from or for
	a database.

-----------------------------------------------------------------------
The two (...-wcw) notes are my own.

Bill Wells
UC Berkeley  wcwells@Berkeley.ARPA


Received: by ucbvax.ARPA (4.16/4.13)
	id AA12932; Tue, 1 Nov 83 19:16:32 pst
Date: 1 Nov 83 13:18:27 EST (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: self cancelling messages
Message-Id: <8311011818.AA01899@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA01899; 1 Nov 83 13:18:27 EST (Tue)
To: header-people@mit-mc.ARPA

As long as self cancelling messages have been brought up, I'd like to
mention that the Usenet standard (RFC850) has such a field, for example:
	Expires: Sun, 1-Jan-84 04:06:53 EST
The semantics are the same, but the implementation is different.
Messages are stored on line on each machine until they expire.
A daemon checks every night for expired messages.  An attempt to
use this field to expire hourly weather forecasts failed because
of the once-per-day granularity.  Normally expiration dates are used
to prolong the (normally two week) lifetime of a message, but can be
used to shorten them as well, within the resolution of the expiration
daemon.

However, for mail purposes, since the semantics are identical to what
would be needed for self cancelling mail, I'd like to encourage anyone
who implements it to use the same Expires: <date> header.  This will
probably simplify life in the longrun when mail and news headers are
combined, and will also prevent 850 from suddenly being in violation
of 822.

By the way, please note that your 6 hour requirements for routine mail
are somewhat optimistic for dialup networks.  In a dialup world where
some sites must wait for others to poll them (overnight), it's quite
common to have 24 - 48 hour delivery times, and when something gets
messed up (e.g. a forwarder is down or has a wedged dialup or dialer)
even longer times - a week or two is not all that uncommon over some
flakey links, and I've seen 3 month delays.

Also, as long as we're talking about extending SMTP, I'd like to mention
another feature that might be nice.  SMTP seems well suited to exchanging
mail over dialup phone links - you dial up a machine, log in as SMTP,
say HELO to identify yourself, and transfer mail.  This works great as long
as you have a reliable channel (e.g. TCP or X.25).  But dialups are noisy.
Suppose a DLNK command were added to go into a "standard" (we pick one)
data link layer?  That is, a dialog might go like this:
	HELO FooVax
			response
	DLNK SDLC
			affirmative response
	<at this point both sides start using SDLC>
The DLNK might go before HELO.  The response comes back without the data
link layer, in case it might fail.  (The remote host might not know the
named protocol, for example.)  This would permit hosts to still send mail
if they don't implement DLNK, although it could get noisy.)  I'm not
particularly suggesting SDLC, I don't have any preference.

One final note: I do hope there will be a Class: or Priority: header
field, since the SMTP envelope information will be lost on any message
passing through some other mail system, such as UUCP.  (UUCP should be
able to handle the .ARPA domain, given a smart enough mailer - I have
never seen a UUCP host try to get to host "ARPA".)

	Mark Horton

Received: from SCRC-YAMASKA by SCRC-QUABBIN with CHAOS; Wed 2-Nov-83 08:46:09-EST
Date: Wed, 2 Nov 83 08:46 EST
From: Charles Hornig <Hornig@QUABBIN.SCRC.Symbolics>
Reply-to: CAH@MIT-MC.ARPA
Subject: ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>,
    Mark Crispin <MRC@SU-SCORE.ARPA>, header-people@MIT-MC.ARPA
Cc: bug-Zmail@SCRC.SCRC.Symbolics, Hornig@YUKON.SCRC.Symbolics,
    Hornig@MIT-MULTICS.ARPA, bug-mailer@YUKON.SCRC.Symbolics
In-reply-to: <831101192604.9.RWK@YUKON.SCRC.Symbolics>
Message-ID: <831102084603.1.Hornig@QUABBIN.SCRC.Symbolics>

    Date: Tue, 1 Nov 83 19:26 EST
    From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
	Date: Tue 1 Nov 83 12:55:08-PST
	From: Mark Crispin <MRC@SU-SCORE.ARPA>
	Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
	Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

	So is your header (a non-ARPA domain is not yet valid on Internet).
			---------------

	Return-Path: <Mailer@MIT-XX>
	Received: from MIT-XX by SU-SCORE.ARPA with TCP; Tue 1 Nov 83 12:50:16-PST
	Date: Tue, 1 Nov 83 15:49 EST
	From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
	Subject: Files restored to disk
	To: Operator@MIT-XX.ARPA
	Cc: bug-mail@MIT-XX.ARPA
	In-reply-to: The message of 1 Nov 83 04:07-EST from Operator
	Message-ID: <831101154911.6.RWK@YUKON.SCRC.Symbolics>

	    Date: 1 Nov 1983 0407-EST
	    From: Operator
	     The following files have been restored on MIT-XX:

	    PS:<RWK>LOGIN.CMD.11	31-Oct-83 08:24:56
	    -------
	Your headers are illegal (no host).
	-------
    Excuse me.

    Why is it every time I turn around Zmail sends a different
    header?  This was just "fixed", obviously wrongly.

    I think part of the problem here is that XMAILER is no longer
    involved in sending mail for me, and nobody has taken up the
    task of supplying the routing information.  This is obviously
    unacceptable.

    We can fix Zmail up with the knowledge that's needed, if nobody
    has any better ideas, but I don't know if that's really where it
    should happen.  This is about the fifth time someone has complained.
    Obviously, this one is more embarrassing than most...

This has already been fixed in Zmail (84.44).

The behaviour about which MRC is complaining is due to the insistance by
the Internet community that we not put our host names in mail headers at
all (since they are not on the Internet).  Zmail has been taught to
convert "RWK@Yukon.SCRC.Symbolics" to "RWK%SCRC-Yukon@MIT-MC".

I bet you wouldn't want all your internal mail gatting routed through
MC, though.  If you look carefully, you will see that, as far as Zmail
could tell, the message was not going to the Internet.  It was going
only to Chaosnet hosts (Yukon and XX).  It counts as internal mail.  If
you are going to call the protocol police, complain to the people who
run a mail forwarding gateway at XX without munging headers.

Another example is this very message.  MRC will get a "legal" Internet
message with "%"'s in its addresses.  Everyone else on header-people
will get an illegal one because they get the MIT-internal copy since
header-people is on MIT-MC.

This exchange is why I waited so long to put in the "%" hack.  As you
have seen, it doesn't work much of the time.  You can't tell where the
message might end up.  As long as the Internet won't admit the existance
of our hosts, there's not much we can do.  Do we really have to put up
with this for another year?

Date: 2 November 1983 11:03 EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject:  ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: CAH @ MIT-MC
cc: HEADER-PEOPLE @ MIT-MC, Hornig @ MIT-MULTICS, MRC @ SU-SCORE,
    "bug-mailer@YUKON bug-Zmail" @ SCRC-TENEX, Hornig @ SCRC-YUKON,
    RWK @ SCRC-YUKON
In-reply-to: Msg of Wed 2 Nov 83 08:46 EST from Charles Hornig <Hornig at QUABBIN.SCRC.Symbolics>

    Date: Wed, 2 Nov 83 08:46 EST
    From: Charles Hornig <Hornig@QUABBIN.SCRC.Symbolics>
    To:   "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>,
          Mark Crispin <MRC@SU-SCORE.ARPA>, header-people@MIT-MC.ARPA
    cc:   bug-Zmail@SCRC.SCRC.Symbolics, Hornig@YUKON.SCRC.Symbolics,
          Hornig@MIT-MULTICS.ARPA, bug-mailer@YUKON.SCRC.Symbolics
    ...							    It was going
    only to Chaosnet hosts (Yukon and XX).  It counts as internal mail.  If
    you are going to call the protocol police, complain to the people who
    run a mail forwarding gateway at XX without munging headers.
    Another example is this very message.  MRC will get a "legal" Internet
    message with "%"'s in its addresses.  Everyone else on header-people
    will get an illegal one because they get the MIT-internal copy since
    header-people is on MIT-MC.

Since COMSAT doesn't understand .SCRC.Symbolics (and I bet neither does XX)
this whole argument is spurious.  You should at least convert these things
to legal chaosnet addresses when going outside Symbolics, if you want to
communicate with anybody but other Symbolics hosts.

Date: Wed 2 Nov 83 08:56:42-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: CAH@MIT-MC.ARPA
cc: RWK%SCRC-YUKON@MIT-MC.ARPA, header-people@MIT-MC.ARPA,
    bug-Zmail%SCRC-TENEX@MIT-MC.ARPA, Hornig%SCRC-YUKON@MIT-MC.ARPA,
    Hornig@MIT-MULTICS.ARPA, bug-mailer%SCRC-YUKON@MIT-MC.ARPA
In-Reply-To: Message from "Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>" of Wed 2 Nov 83 05:57:06-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

There is a very simple way around the problem of "internal" vs small-i
internet headers.  That is, never consider any mail bridge host to be
"internal"; always consider it to be small-i internet and require that
it be an absolute (e.g. .ARPA form) address.

Have you read RFC's XXX, YYY, and ZZZ?  If not, please read before you
flame.  Something is being done but it takes time.  I imagine you at
SCRC wouldn't care to receive a message from Helens without having the
slightest idea what a Helens is (it's a host on Stanford's local net
only, no Internet support).  The problem is much more complex than a
HOSTS3 or whatever can solve.

Of course, my "simple" solution doesn't help if a message gets delivered
to a user who forwards his mail across a small-i internet boundary.  But
a user who does that should take responsibility for the possible
consequences of his actions, at least until full domains take over.
-------

Date: Wed, 2 Nov 83 13:33 EST
From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
Subject: Re: ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: CAH@MIT-MC.ARPA, RWK%SCRC-YUKON@MIT-MC.ARPA,
    header-people@MIT-MC.ARPA, bug-Zmail%SCRC-TENEX@MIT-MC.ARPA,
    Hornig%SCRC-YUKON@MIT-MC.ARPA, Hornig@MIT-MULTICS.ARPA,
    bug-mailer%SCRC-YUKON@MIT-MC.ARPA
In-reply-to: The message of 2 Nov 83 11:56-EST from Mark Crispin <MRC at SU-SCORE>
Message-ID: <831102133341.1.RWK@YUKON.SCRC.Symbolics>

    Date: Wed 2 Nov 83 08:56:42-PST
    From: Mark Crispin <MRC@SU-SCORE.ARPA>
    Of course, my "simple" solution doesn't help if a message gets delivered
    to a user who forwards his mail across a small-i internet boundary.  But
    a user who does that should take responsibility for the possible
    consequences of his actions, at least until full domains take over.

It also doesn't help mailing lists.  If I at YUKON send mail to a list
on SCRC which includes a list on MC, the wrong headers result.  If we
avoid placing forwarding entries to mailing lists on non-gateway hosts,
does this avoid the problem?

Received: from SCRC-YAMASKA by SCRC-QUABBIN with CHAOS; Wed 2-Nov-83 14:51:12-EST
Date: Wed, 2 Nov 83 14:51 EST
From: Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>
Subject: Re: ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: RWK%SCRC-YUKON@MIT-MC.ARPA, header-people@MIT-MC.ARPA,
    bug-Zmail%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 2 Nov 83 11:56-EST from Mark Crispin <MRC at SU-SCORE>
Message-ID: <831102145113.5.Hornig@QUABBIN.SCRC.Symbolics>

    Date: Wed 2 Nov 83 08:56:42-PST
    From: Mark Crispin <MRC@SU-SCORE.ARPA>
    Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
    Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

    Have you read RFC's XXX, YYY, and ZZZ?  If not, please read before you
    flame.  Something is being done but it takes time.  I imagine you at
    SCRC wouldn't care to receive a message from Helens without having the
    slightest idea what a Helens is (it's a host on Stanford's local net
    only, no Internet support).  The problem is much more complex than a
    HOSTS3 or whatever can solve.

Yes, I have read them.  That is where the "year" came from.  As I
understand it, non-ARPA domains will not be permitted until late Summer
1984.  I would rather receive a message from Helens with a Return-path
which made it clear that it was from Stanford somewhere than have all my
local mail be routed through MIT-MC because I needed to supply a source
route with %'s.

Date: 2 November 1983 15:39 EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject:  ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files restored to disk]
To: RWK @ SCRC-YUKON
cc: CAH @ MIT-MC, HEADER-PEOPLE @ MIT-MC, Hornig @ MIT-MULTICS,
    MRC @ SU-SCORE, bug-Zmail @ SCRC-TENEX, bug-mailer @ SCRC-YUKON,
    Hornig @ SCRC-YUKON
In-reply-to: Msg of Wed 2 Nov 83 13:33 EST from "Robert W. Kerns" <RWK at YUKON.SCRC.Symbolics>

There is only one way to insure that bad headers never get out and that is
to always make the transformation (in effect adopting the current messy
state of affairs as the local standard as well) and then make local mail
tools recognize the "%locally-known-host@arpanet-gateway" construction and
avoid the unnecessary routing...  This could be made highly reliable if the
hostname space of the arpanet gateway is well understood locally (which can
be done for MC by reading the appropriate host table file).

Date:  Wednesday, 2 November 1983 16:09 est
From:  "Barry Margolin"@MIT-MULTICS.ARPA
Subject:  Re: ["Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>: Files
To:  rwk%scrc-yukon@MIT-MC.ARPA
cc:  mrc@SU-SCORE.ARPA, cah@MIT-MC.ARPA, header-people@MIT-MC.ARPA, 
     bug-zmail%scrc@MIT-MC.ARPA, bug-mailer%scrc-yukon@MIT-MC.ARPA
In-Reply-To:  Message of 2 November 1983 15:55 est from "Barry Margolin"
Message-ID:  <831102210915.478487@MIT-MULTICS.ARPA>

Until domains are fully implemented all over the place, header munging
will have to take place.  Nobody likes it, but that is life.  There is
only one "right" time and place for header munging to take place, and
that is as the mail is crossing from a local network into the internet
(big or little "i").  So, when a piece of mail is being transmitted from
a Symbolics machine or a Stanford machine to a host which is not part of
that local organization the header must be munged to conform to the
Internet standard, which currently admits only one domain.
                                        barmar

Date: 2 Nov 1983 13:19:07-PST (Wednesday)
From: David M. Alpern <Alpern.IBM-SJ@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: What does it mean to be an internet host?
To: header-people@mit-mc
Message-Id: <ALPERN.SJRLVM4@IBM-SJ (2 Nov 1983 13:19:07 4055)>
Via:  IBM-SJ; 2 Nov 83 15:27-PST

I've noticed that MIT-VAX, MIT-OZ, and other machines which do not
seem to accept mail directly from most Arpanet hosts are in the CSNET
host table, and from what I've been told, in the Internet host table.
(There may be other examples, I just happen to deal with these machines.)
 
Is this simply a way of making legal constructs such as xxx@mit-oz@mit-mc,
which "would not be legal" if mit-oz were not in the Internet host table,
at the cost of confusion regarding which machines can actually be contacted?

Date: Wednesday, 2 November 1983, 19:19-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: What does it mean to be an internet host?
To: David M. Alpern <Alpern.IBM-SJ at RAND-RELAY>
Cc: header-people at MIT-MC
In-reply-to: <ALPERN.SJRLVM4@IBM-SJ (2 Nov 1983 13:19:07 4055)>

    Date: 2 Nov 1983 13:19:07-PST (Wednesday)
    From: David M. Alpern <Alpern.IBM-SJ@Rand-Relay>
    Via:  IBM-SJ; 2 Nov 83 15:27-PST

    I've noticed that MIT-VAX, MIT-OZ, and other machines which do not
    seem to accept mail directly from most Arpanet hosts are in the CSNET
    host table, and from what I've been told, in the Internet host table.
    (There may be other examples, I just happen to deal with these machines.)

MIT-VAX recently left the Internet, and is being removed from those
host tables.  MIT-OZ was supposed to be in the Internet host table,
but since they have been unable for the past year to get their TCP/IP
working they were commented out recently.

I do not believe either MIT-VAX or MIT-OZ is in the latest CSNET host
tables.  MIT-MC is listed as an ARPANET site in the latest Internet
and CSNET tables, however, and you can relay mail to OZ or VX through MC. 
 
    Is this simply a way of making legal constructs such as xxx@mit-oz@mit-mc,
    which "would not be legal" if mit-oz were not in the Internet host table,
    at the cost of confusion regarding which machines can actually be contacted?

No, this is just braindamage.

Cheers,
Chris

Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 3-Nov-83 21:05:44-EST
Date: Thu, 3 Nov 83 21:05 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Question about suspected typographical error in RFC 822
To: DCrocker@UDEL-RELAY.ARPA
Cc: Header-People@MC.ARPA

Can you clarify this RFC-822 issue?  I think that in the syntax
on page 27, the definition of mailbox should be

     mailbox     =  addr-spec                    ; simple address
                 /  local-part route-addr        ; name & addr-spec

rather than what is actually in the document, namely

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec

For reference, local-part is defined as

     local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved

For an example of the effect of requiring a phrase there, rather than a
local-part, see the header of this message.  My personal name is
enclosed in double quotes because period is not a legal character in a
phrase.  Is this ruling-out of period intentional or merely a
typographical error in the syntax specification?  I can find no other
interpretation specified for period in the field of a mailbox that
precedes the route-addr.  It sure would be nice not to have to put
those quotes around the name of anyone who has a middle initial.
Thanks for any light you can shed on this matter.

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbvax.ARPA (4.16/4.13)
	id AA27414; Fri, 4 Nov 83 10:34:38 pst
Received: from ucbjade.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.10/4.8) id AA00461; Fri, 4 Nov 83 10:02:16 PST
Message-Id: <8311041751.AA13925@ucbjade.CC.Berkeley.ARPA>
Received: from UCBCMSA.BITnet by ucbjade.CC.Berkeley.ARPA
	(4.10/4.8) id AA13925; Fri, 4 Nov 83 09:51:50 PST
Date: Fri, 04 Nov 83 09:46:44 PST
From: SPGGGM%UCBCMSA.CC@Berkeley
To: Moon%scrc-tenex@mit-mc.ARPA
Cc: DCrocker@Udel-relay.ARPA, header-people@mit-mc.ARPA
Subject: Phrase vs. local-part

In fact, were it legal to use *David T. Moon*, then by the regeneration rules
('Note:' on page 8 of RFC822, section 3.1.4), your name would come out as
*David T.Moon*.  Is THAT what you want?

Greg Minshall

Received: from merlin.ARPA by purdue.ARPA; Sat, 5 Nov 83 15:25:02 EST
From: Christopher A Kent <cak@PURDUE.ARPA>
Message-Id: <8311052024.AA04011@merlin.ARPA>
Received: by merlin.ARPA; Sat, 5 Nov 83 15:24:30 EST
Date:  5 Nov 1983 1524-EST (Saturday)
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: Header-People@MC.ARPA, DCrocker@UDEL-RELAY.ARPA
Subject: Re: Question about suspected typographical error in RFC 822
In-Reply-To: Your message of Thu, 3 Nov 83 21:05 EST.
             <8311040308.AA01013>

Unfortunately, this is not a typo. I've been through this once before.
The real gripe that I have is that the line gets parsed and flagged as
an error, even if you have <> on the line somewhere, which indicates
that the phrase in <> is the address to be used, and the rest of the
line is a comment.

The normal solutions to this are:

	"Christopher A. Kent" <cak@purdue>
	Christopher A Kent <cak@purdue>
	cak@purdue (Christopher A. Kent)

Come to think of it, I'm not sure if the last form is really legal.

Cheers,
chris
----------

Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 5-Nov-83 22:30:15-EST
Date: Sat, 5 Nov 83 22:31 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Question about suspected typographical error in RFC 822
To: DCrocker@UDEL-RELAY.ARPA
Cc: Header-People@MIT-MC.ARPA
References: The message of 3 Nov 83 21:05-EST from "David A. Moon" <Moon at SCRC-TENEX>,
            The message of 4 Nov 83 11:35-EST from Karlton.PA at PARC-MAXC,
            <8311041751.AA13925@ucbjade.CC.Berkeley.ARPA>,
            <8311052024.AA04011@merlin.ARPA>,
            The message of 5 Nov 83 18:21-EST from John R Ellis <Ellis at YALE>

Well, enough people have pointed out to me that local-part is not what I
want.  There were a couple of other replies that I didn't save, so they
are not in the reference list of this message.

Let me rephrase my question.  The basic problem is that phrase is being
parsed into atoms, and periods are not allowed in atoms because atoms
are also used in domain names.  This is simply an incorrect modularity
in the syntax definition, if it is thought of as a program.

If you look at the syntax definition in Appendix D of RFC 822, every use
of phrase is something that should -not- be being parsed into individual
words.  A phrase is simply a piece of text not containing special
characters.  Therefore alter my suggestion to be: replace the definition
in the document

     phrase      =  1*word                       ; Sequence of words

with the suggested replacement

     phrase      =  1*(ptext / quoted-string)
     ptext       =  <any CHAR excluding all the specials
		     other than ".", and excluding CR,
		     but including linear-white-space>

There may or may not be intended a restriction that a phrase
may not consist solely of linear-white-space and that leading
and trailing linear-white-space around a phrase is insignificant.

I also suggest that the present definition of local-part be replaced
with
     local-part  =  phrase
because the contents of the local-part field should not be parsed in
any way by any host other than the one named by the domain name to the
right of the atsign.

I would still like an official answer to my question of whether the
standard was officially intended to expressly forbid people's names
to include middle initials, or whether this was an unintended accidental
result of the syntax definition that should be fixed.

Date: Sun, 6 Nov 83 12:05 PST
From: Taft.PA@PARC-MAXC.ARPA
Subject: Re: Question about suspected typographical error in RFC 822
In-reply-to: "Moon's message of Sat, 5 Nov 83 22:31 EST"
To: Header-People@MIT-MC.ARPA

From a technical standpoint, I am as mystified as you are about the
restricted local-part syntax.  I see no technical reason why a
local-part can't be the same as a phrase.

However, I can assure you that the restriction is not the result of a
typographical error.  There was an administrative decision made long ago
that local-parts should not contain spaces.  I don't know the exact
details; but there were (and probably still are) various mail systems
around the Arpanet that could not cope with recipient names containing
spaces.  When such names started appearing from CMU and other places,
mail systems broke down, and this interfered seriously with the conduct
of some important ARPA contract.  As an expedient, spaces were outlawed
from recipient names, and pressure was brought on CMU to change their
mail system.  The expedient has apparently been perpetuated for all
time.

There is a serious problem with your proposed redefinition of phrase,
which is that it requires context-dependent lexical analysis.  This is
perhaps not bothersome for an ad-hoc scanner; but it causes difficulties
for a real parser, which expects to be given a sequence of tokens that
can be reduced according to the rules in the grammar.  That is, if the
lexical analyzer encounters a "." adjacent to an atom, should it include
the "." in the atom or should it pass it on to the parser as a separate
token?  This can be determined only if the lexical analyzer knows what
rules the parser is considering; and conventional parsers are generally
not set up to provide that information.

A better way to fix the definition of phrase is to permit it to include
anything that looks like a local-part.  That is, change

     phrase      =  1*word                       ; Sequence of words
to:
     phrase      =  1*local-part                 ; Sequence of words and
periods

However, as a practical matter I don't see any pressing need to change
the grammar.  You can include anything you want in a phrase if you quote
it.

It is worth mentioning that there are quite a number of typographical
errors in the body of RFC 822, especially in the examples.  Also, the
complete grammar in Appendix D is horribly ambiguous if used as it
stands.  However, if the grammar is divided into lexical analysis rules
(the ones given in section 3.3) and parsing rules (all the others),
everything works correctly.

	Ed Taft


Received: by YALE-BULLDOG via CHAOS; Sun, 6 Nov 83 20:28:19 EST
Date:    Sun, 6 Nov 83 20:28:50 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Question about suspected typographical error in RFC 822
To:      Taft.PA@PARC-MAXC.ARPA
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Taft.PA@PARC-MAXC.ARPA, Sun, 6 Nov 83 12:05 PST

    A better way to fix the definition of phrase is to permit it to include
    anything that looks like a local-part.  That is, change:

         phrase      =  1*word                       ; Sequence of words
    to:
         phrase      =  1*local-part                 ; Sequence of words and
                                                     ; periods
    ------

This change would not allow periods at the end of a phrase, as in:

    Joe Hacker Ph.D. <JH@Yale>
    B.J. <Herbison@Yale>

The latter example actually occurred here.  A more general solution is:

    phrase = 0*("." / word)       ; Sequence of words OR periods

The problem with this modification is that the grammar is no longer even
close to being LL(1) (i.e. one that can be parsed top-down easily); PHRASE
and LOCAL-PART can derive arbitrarily long equal strings.  I do think
it is LALR(1) (i.e. parseable by bottom-up parser-generators such as YACC).
To make the new language parseable by a non-backtracking recursive descent
parser, one would have to do some extensive contortions to the grammar.
(The current grammar is easily parsed with a recursive-descent parser.)

But there is another annoying implementation issue with any scheme that
allows the "."  token in phrases:  How do you pretty-print the phrase?
For domains, there is a simple rule -- use no spaces.  But there is no
such easy rule for phrases.  Consider these examples:

    I.B.M. System Administrator
    John R. Ellis
    B.J.

People would get pretty peeved if mail services rearranged the spacing
around their periods, just as some now get peeved that they have to quote
periods.

The only possible solution is to preserve the original spacing.  One way
to do that is to tag each lexical token with its character position in
the input stream; when a phrase is parsed, the original input string can
then be extracted and preserved.  As for domains, this formatting rule
would have to be described in the RFC.  Ugh.

I too would like periods in phrases.  But I agree with Ed Taft:  There
is no pressing need at this late stage to go to all that effort for such
little gain.
-------

Received: from merlin.ARPA by purdue.ARPA; Mon, 7 Nov 83 09:02:44 EST
From: Tim Korb <jtk@PURDUE.ARPA>
Message-Id: <8311071402.AA23443@merlin.ARPA>
Received: by merlin.ARPA; Mon, 7 Nov 83 09:02:14 EST
Date:  7 Nov 1983 0902-EST (Monday)
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: Header-People@MIT-MC.ARPA, DCrocker@UDEL-RELAY.ARPA
Subject: Re: Question about suspected typographical error in RFC 822
In-Reply-To: Your message of Sat, 5 Nov 83 22:31 EST.

I asked Dave Crocker about this problem some time ago. Dave told me
that the grammar is restricted in this way to make it context-free, and
hence, easy to parse.

I would argue that the parsing problem is so trivial we should worry
about user convenience and good taste rather than whether or not we'll
be able to use yacc. In any event, that's the way the standard reads.

Tim
----------

Date: 25-Oct-83 17:06:46-UT
From: gross@dcn7
Subject: re: anti-social behavior of mailers
To:   wmartin@office-3
cc:   header-people@mit-mc


      ---
	The principle to be followed is that "mail is sacred".  ...
	    ...       It is the responsibility of the recipient to do
	whatever housekeeping is necessary to avoid whatever problems his
	system causes by his being overallocated.  
      ---

Seems to me that this is a contradiction?!  I fully agree that mail should
be sacred, but what if the 'problems his system causes' are to dump the
mail into the bit bucket?  I suspect that arguments claiming that 'It is 
the responsibility of the recipient ... ' will be non productive.  I
mean, after all, isn't this why we have machines and RFC's for anyway?

Personally, I want to know if my message wasn't delivered to its intended 
recipient.  Saves me drumming my fingers and waiting for an answer. 


Phill Gross


-------

Date:           Mon, 7 Nov 83 12:10:28 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Periods in full names in RFC822

Two comments -- one philosophical, one pragmatic.

(1) I understand the problems involved in parsing entities like

		Richard B. Wales <v.wales@UCLA-LOCUS>

    but I must still cast my vote in favor of making mailbox designa-
    tions such as the above legal as they stand -- even if somewhat
    more involved parsing techniques are required as a result.

    My impression was that RFC822 headers were designed to "look nice"
    as well as to be easily interpretable by programs.  And no matter
    what anyone may say about ease of parsing, the mailbox designation

		"Richard B. Wales" <v.wales@UCLA-LOCUS>

    does NOT look nearly as "nice" as the unquoted version.

(2) One relatively simple way to get around the "prettyprinting" diffi-
    culty would be for your lexical analyzer to flag those tokens in an
    address which are followed by a space.  If you carry these "space
    flags" around until you are ready to output the address again, you
    can use them to preserve the spacing (or lack of spacing) around
    the periods in a full name.
    
    I did just this kind of thing in an ad-hoc address parser I recent-
    ly wrote, but I'm sure it could be done with "lex" and "yacc" too
    (provided you pass a data structure around as the lexical value of
    each token, rather than just a character string).

    -- Rich

Date: 9 Nov 1983 13:22:32-PST (Wednesday)
From: David M. Alpern <Alpern.IBM-SJ@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: Restrictive "i"-internet transfers
To: header-people@mit-mc
Message-Id: <ALPERN.SJRLVM4@IBM-SJ (9 Nov 1983 13:22:32 4081)>
Via:  IBM-SJ; 10 Nov 83 12:35-PST

I've been noticing that "restrictive" gateway functions have been developing
in some organizations for security or resource management purposes.  What I
mean is that there are some network environments in which one user can
address anyone, either within the local network or in some "i"-internet
community, but where some local network users cannot access/be accessed by
users outside the local network.  Let's say that such users not only cannot
send mail outside, but cannot have mail sent to them from outside either.
 
What if someone in this environment, who had the privilege, sent a message
to a group which included restricted-access members of the local network
as well as outside users.  The header could be munged by the gateway to
remove the addresses of the restricted-access local users, but this has
all the problems header munging usually has, and in addition hides the
involvement of the local recipients from the outside recipients.
 
Is there/should there be some means of specifying an address that implies
that it is a "private channel," which might not be available to all recipients?
What would be the best way to handle such a circumstance?
 
- Dave

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 11 Nov 83 00:27:29 EST
Date: 11 Nov 83 0034 EST
From: Rudy.Nedved@CMU-CS-A
To: David M. Alpern <Alpern.IBM-SJ@Rand-Relay>
Subject: Re: Restrictive "i"-internet transfers
CC: header-people@mit-mc
In-Reply-To: <ALPERN.SJRLVM4@IBM-SJ (9 Nov 1983 13:22:32 4081)>
Message-Id: <11Nov83.003407.EN0C@CMU-CS-A>

David,

Thanks for pointing out that problem. It never occured to me that a local
user could send to a non-local user and a local "restricted" user causing
a reply to "all" by the non-local user to be rejected by the mail gateway.

I don't see any solution that I would consider both correct and maintainable.
I will chew on this...and will be happy to hear other solutions and request
that if you get any solutions that are not sent to Header-People that you
send me a copy.

CMU-CS/RI is one such "domain" that has a restricted mail gateway.

-Rudy

Date: 11 Nov 83 11:34 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: Rudy.Nedved@CMU-CS-A.ARPA
Subject: RE: Restrictive "i"-internet transfers
Cc: header-people@MIT-MC.ARPA
Message-ID: <3153F9055.006F0024.1983@CMCL1.NYU-CMCL1.ARPA>
In-Reply-To: <11Nov83.003407.EN0C@CMU-CS-A> 	;
	Message of 11-NOV-1983 02:11 from Rudy.Nedved@CMU-CS-A

Although we have a half restricted domain we allow incomming mail to anyone 
which eliminates the problem as stated.  I haven't been able to formulate a
version of the problem which fails other than in that a user not validated for
the ARPAnet can not reply to mail from an ARPAnet site.

Philosphically mail should be free and the "Can not send to ARPAnet" is mearly
there because of the DCA restrictions.  
 
-------

Date: Fri 11 Nov 83 23:39:58-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: Proposal for Arpa/Uucp mail routing
To: header-people@MIT-MC.ARPA

I would like to bounce this idea off of all of you as a possibility
for extensions to mailers now running SMTP, a service to provide
easier electronic mail access to the UUCP network.  No flames, please.


As many of you are aware, the Bell systems network (a.k.a UUCP and
also called Usenet) is one of (if not the) hardest networks to reach
directly via electronic mail.  Due to their mail transport mechanism,
ful pathnames to UUCP sites must be provided to effect successful
transport.  Knowledge of these pathnames is not commonly known to the
Arpa/Internet community, not because of security reasons but because
the network is in a constant state of change.  Most messages are
required to run through a centralized gateway (e.g ucbvax, sri-unix or
cca) which results in high traffic through those gateways.  In
particular, ucbvax has excessively high traffic, since it is
responsible for forwarding to Berknet and Bitnet sites also.  Finally,
knowledge of a pathname does not necessarily guarantee a successful
mail transfer, as sites may be down along the path, or sites may elect
to receive news only.  This results in complicated returns (which
sometimes fail).  In addition, pathnames tend to be "long", involving
hops across most of the country (sometimes multiple hops) to sites
which are geographically close to the Arpa/Internet sender.

My proposal is to have "local pathnames" of optimized paths to UUCP
sites kept by Arpa/Internet hosts which act as gateways to the UUCP
net.  A registry could be kept of known UUCP gateways and sites which
are geographically close to them, available to Arpa/Internet users,
possibly FTPable from the NIC.  The effect this would have is to
reduce the load of traffic which major Arpa/Uucp gateway hosts
support, and redistribute that traffic over all Arpa/Uucp gateways.
The Arpa/Internet user would only have to address his message to

user%uucp-destination-host@arpa/uucp-gateway

and allow the gateway to relay the message to the destination host via
the shortest path.  The gateway may also choose to try alternate
paths, and would guarantee (as much as is possible) a failed message
reply should the destination host be unreachable.

A further extension, pending the full integration of domains into
Arpa/Internet mail transfer, would be for mail addressed to

user@uucp-destination.UUCP

to be appropriately routed (by the Arpa/Internet) to the most
geographically close Arpa/Uucp gateway (or a suitably close one if the
nearest one is not relaying), from which the gateway could take over
and provide the optimal route to the UUCP destination host.

This idea was motivated by a discussion of "superelastic plastic
Usenet addresses" within the USENET net.mail discussion, a means of
providing optimized intra-uucp mail transfer.  I will share my
thoughts on this with them, also.

Greg Skinner

(Gds@MIT-XX.ARPA, decvax!genrad!mit-eddie!gds, gds$mit-eddie@MIT-MC.ARPA)
-------

Date: Saturday, 12 November 1983, 01:26-EST
From: Christopher C. Stacy <CStacy at MIT-DMS>
Subject: Periods in full names in RFC822
To: Header-People at MIT-DMS


I think Rich Wales is right: if headers are supposed to be read by
humans (as opposed to just presentation programs), the prettier
unquoted syntax for mailbox specs ought to be legal.  

Many users at our site have asked me to send in this comment, to
ensure that the protocol designers understand that the users are
unhappy with the look of the quoted mailbox specs headers.  
(None of the mail readers at our sites have any difficulty with the
less restricted syntax.)


Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 01:46:54 EST
Date:    Sat, 12 Nov 83 01:51:53 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Periods in full names in RFC822
To:      Christopher C Stacy <CStacy@MIT-DMS.ARPA>
Cc:      Header-People@MIT-MC.ARPA

    None of the mail readers at our sites have any difficulty with the
    less restricted syntax.

For the benefit of the rest of us, perhaps you could give a formal
definition of the syntax your programs accept and describe how your
programs actually do the parsing?

None of your mail programs have any difficulty in adhering to the new
standard either, I see:

    Date: Saturday, 12 November 1983, 01:26-EST
    From: Christopher C. Stacy <CStacy at MIT-DMS>
    To: Header-People at MIT-DMS
-------

Date: Sat, 12 Nov 83 02:15:24 EST
From: "Christopher C. Stacy" <CStacy at MIT-MC.ARPA>
To: Header-People at MIT-MC.ARPA
Subject: Periods in full names in RFC822

Well, sigh, here we are in flame-city...

    Date: Sat, 12 Nov 83 01:51:53 EST
    From: John R Ellis <Ellis at YALE.ARPA>
    To:   Christopher C Stacy <CStacy at MIT-DMS.ARPA>
    cc:   Header-People at MIT-MC.ARPA
    Re:   Periods in full names in RFC822

        None of the mail readers at our sites have any difficulty with the
        less restricted syntax.

    For the benefit of the rest of us, perhaps you could give a formal
    definition of the syntax your programs accept and describe how your
    programs actually do the parsing?

I don't know a whit about parsing, but I thought that someone already
figured out how to do this (by having the lexical analyzer flag the
tokens which are followed by a space.)

    None of your mail programs have any difficulty in adhering to the new
    standard either, I see:

        Date: Saturday, 12 November 1983, 01:26-EST
        From: Christopher C. Stacy <CStacy at MIT-DMS>
        To: Header-People at MIT-DMS

That is right, they do not (as you can see from the header on the
message you are reading.)  To make it adhere to the current standard
requires a two-instruction patch in the mailer; I went looking to see
how hard it would be to fix the other day.  This bug has not been
installed, however.

I recognize your name as one of the people who occasionaly sends notes
to some of our users complaining that we are anti-social because you
cannot parse our headers.  But your software apparently really could
parse the headers, since replies do in fact come back to us.

There are at least six completely different mail reading systems in
use at our site, and none of them has any difficulty parsing the less
restricted syntax.  (I did not implement these programs, but some of
the other people on this list did.)  Just exactly which mail systems
are really unable to parse these headers anyway?

Anyway, my point was that if headers are for USER convenience then
they should look pretty.  If we are interested in implementor
convenience, why are we bothering to make them readable by humans at all?
Come on, this can't be THAT big a deal, and it looks SO much nicer.

Chris

From: vortex!lauren at RAND-UNIX
Date: Friday, 11-Nov-83 21:19:13-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: SMTP UUCP extensions
To: HEADER-PEOPLE@MC

The problem is not really a technical one, but is instead a political
problem.  The existing UUCP gateways and paths are not advertised
not only due to pathname complexities but because there are no
authorized gateways!  Any gatewaying which actually takes place is
on an unofficial basis and could theoretically be terminated totally
at any time.  Attempting to include "official" support for 
officially "non-existent" gateways could raise eyebrows among
the "powers-that-be" and could result in a crackdown on those
paths that *do* exist.  Given the current security issues surrounding
DDN, this may well be the wrong time to propose such extensions, as
sensible as such extensions might be from a technical standpoint.

Just an opinion.

--Lauren--


From: vortex!lauren at RAND-UNIX
Date: Friday, 11-Nov-83 21:19:13-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: SMTP UUCP extensions
To: HEADER-PEOPLE@MC

The problem is not really a technical one, but is instead a political
problem.  The existing UUCP gateways and paths are not advertised
not only due to pathname complexities but because there are no
authorized gateways!  Any gatewaying which actually takes place is
on an unofficial basis and could theoretically be terminated totally
at any time.  Attempting to include "official" support for 
officially "non-existent" gateways could raise eyebrows among
the "powers-that-be" and could result in a crackdown on those
paths that *do* exist.  Given the current security issues surrounding
DDN, this may well be the wrong time to propose such extensions, as
sensible as such extensions might be from a technical standpoint.

Just an opinion.

--Lauren--


Date: 12 Nov 83 14:36 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: Header-People@MIT-MC.ARPA
Subject: RE: Periods in full names in RFC822
Message-ID: <316503B24.00400021.1983@CMCL1.NYU-CMCL1.ARPA>
In-Reply-To: <8311120755.AA14832@NYU.ARPA> 	;
	Message of 12-NOV-1983 02:57 from "Christopher C. Stacy" <CStacy@

Do we really have to reopen the User Agent/Mail Presenter arguement again?
 
-------

Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 14:51:22 EST
Date:    Sat, 12 Nov 83 14:58:19 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Periods in full names in RFC822
To:      Christopher C Stacy <CStacy@MIT-MC.ARPA>
Cc:      Header-People@MIT-MC.ARPA

    Anyway, my point was that if headers are for USER convenience then
    they should look pretty.  If we are interested in implementor
    convenience, why are we bothering to make them readable by humans
    at all?  Come on, this can't be THAT big a deal, and it looks SO much
    nicer.

I like periods in fullnames.  But when you propose a change to an existing
standard for which there are already many implementations, one has to
consider for the users' sake the likelihood that the changes will be
incorporated.

The point of a standard is that it allows everyone to communicate with
minimum hassle.  If some programs don't obey the standard, then users
are inconvenienced.  You could have the most flexible syntax possible
(even free-form addresses like US mail) but if many programs didn't accept
it, it would be pretty useless to users, no?

Thus it is important for user convenience to consider current parsing
technology when defining the standard.  Most programmers are familiar
only with the parsing techniques described in texts such as the Dragon
book; there are widely available tools such as YACC based on those
techniques that make parser construction trivial.  If you define a language
that is hard to parse using available tools, many implementors will take
short cuts and parse a subset or write ad hoc parsers that aren't
completely correct (e.g. how many programs correctly parsed the exact
same subset of the old standard?).  If no programs parse exactly the same
subset, then users are inconvenienced.

Most of the old mail programs at MIT and elsewhere use ad hoc parsers.
I had the misfortune once to try and change one written in assembly
language.  The quality of an ad hoc parser is only as good as the
implementor and his funding; MIT happens to have an abundance of good
programmers, but most other institutions do not.  Forcing implementors
to use ad hoc techniques will not only waste scarce resources, but it
will also inconvenience users when the pressured implementors take short
cuts (as they did with the old standard, and as MIT and other institutions
have done with the current standard).

To add in periods, significant modifications would have to be made to
the grammar, practically disallowing top-down parsers (the easiest to
construct correctly without a parser generator).  Extra work would be
required at the tokenizing level to preserve spacing.  These changes would
consume a non-trivial amount of programming time.  Many implementors,
having implemented the current standard and moved on to other projects,
would be tempted to ignore such changes, especially since they produce
such little gain.  Implementors of new systems would not be able to use
simple recursive descent and would be forced to obtain either a parser
generator or use ad hoc techniques.  The probability of most programs
implementing the standard would be reduced.

Is all that effort worth it?  Perhaps if periods were in the current
standard from the beginning; but at this late stage, I think not.  You
and others should have spoken up earlier.
-------

Date:           Sat, 12 Nov 83 18:11:39 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Re: Periods in full names in RFC822

#flame on
    I cannot agree with suggestions that the issue of unquoted periods
    in full names is a minor issue; nor am I willing to docilely accept
    protestations that it is now too late to consider a change.
    
    As for the suggestion that people should have spoken up earlier, I
    think the widespread use (albeit illegal) of full names with un-
    quoted periods is a good indication that large numbers of people
    completely overlooked this fine point in the RFC until now.

    If it had been clear earlier that this restriction was part of the
    standard, I suspect there would have been plenty of complaints long
    ago.

    If the technical issues involved in modifying RFC822 to allow full
    names with periods are not oppressive, I am in favor of making the
    change.
#flame off

So far, the following technical assertions have been made in opposition
to changing RFC822 to allow periods in full names without quoting same:

(1) Either the lexical analysis would become context-dependent, or else
    simple (recursive-descent) parsers could no longer be used.

(2) The spacing around the periods could not be easily reproduced from
    the tokenized and parsed form of the address.

First, the parsing issues.

It is indeed true that if you take the address grammar of RFC822, and
change it only by allowing a "phrase" to consist of any combination of
"word"s (atoms and quoted strings) and periods, the grammar becomes
ambiguous (for bottom-up as well as top-down parsers).  Specifically,
you can't always distinguish between a "phrase" and a "local-part".

My suggestion for getting around this problem is quite simple:  get rid
of the "local-part" token entirely, and use "phrase" in the definition
of "addr-spec" instead of "local-part".

Admittedly, this change does allow some illegal addresses to get by the
parser (in particular, addresses with spaces in the local part), but
these can easily be detected after the address has been parsed via a
very simple ad-hoc examination of the local part.

Here is an unambiguous YACC grammar which should parse addresses where
an unquoted full name could contain periods.  I believe this grammar is
as easy to implement in a top-down parser as the original RFC822 gram-
mar, but I would appreciate verification of this claim from anyone out
there with access to a recursive-descent parser generator.  Hopefully
the YACC notation is clear enough so that even those not familiar with
YACC can understand it.

With the exception of the different "phrase" definition and the use of
"phrase" instead of "local-part" for "addr-spec", this grammar is sup-
posed to be equivalent to that shown on page 27 of RFC822.

	/*
	 * YACC grammar for RFC822 address specification,
	 * expanded to allow unquoted periods in phrases
	 */

	/* these are the terminals produced by the lexer */
	%token	ATOM
	%token	QUOTED_STRING
	%token	DOMAIN_LITERAL

	%%

	address:
	    mailbox
	  | group

	group:
	    phrase ':' ';'
	  | phrase ':' mailbox_list ';'

	mailbox_list:
	    mailbox
	  | mailbox_list ',' mailbox

	mailbox:
	    addr_spec
	  | phrase route_addr

	route_addr:
	    '<' addr_spec '>'
	  | '<' route addr_spec '>'

	route:
	    at_domain_list ':'

	at_domain_list:
	    '@' domain
	  | at_domain_list ',' '@' domain

	addr_spec:
	    phrase '@' domain    /* NOTE CHANGE: "phrase" used here */

	domain:
	    subdomain
	  | domain '.' subdomain

	subdomain:
	    domain_ref
	  | DOMAIN_LITERAL

	domain_ref:
	    ATOM

	phrase:                  /* NOTE CHANGE: periods OK in phrase */
	    phrase_element
	  | phrase phrase_element

	phrase_element:
	    word
	  | '.'

	word:
	    ATOM
	  | QUOTED_STRING

Second, the spacing issues.  As I mentioned in a previous message, this
problem is quite simple to solve.  Simply have the lexer flag each token
which is followed by white space (the amount of white space is unimport-
ant).  When the time comes to "prettyprint" the address, use these flags
to space out the full name properly.

-- Rich <wales@UCLA-LOCUS>

Date: Sat 12 Nov 83 18:54:47-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: more flames
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I'm afraid this suggestion is much too sensible and simple
to merit serious consideration.  After all, it undoubtably
offends the religion of certain individuals.  I will not name
those individuals, but it should be quite obvious who they are.
Here goes:

. remove "." from the definition of "specials"
. add "." to the definition of "ALPHA"
. "local-part" then becomes equivalent to "word"; remove
  "local-part" from the syntax and replace it with "word" every
  place it occurs

     This shouldn't break anyone's parser.  In fact, this is
precisely the sort of rule the TOPS-20 mailsystem (and I suspect
Multics as well) would prefer to think of anyway.

     I fear what I will say next will bring cries of "heresy"
upon me.  I hope I won't be burnt at the stake:

	The only reason why "." is part of the definition
	of "special" that I can discern is to coddle a
	certain mailsystem which uses "." as a routing
	delimiter in the local part.  Unfortunately, that
	mailsystem and the individuals involved are quite
	powerful with regard to the politics of what the
	standard looks like.  They can put anything they
	want into the standard irregardless of what anyone
	else may want.

	The TOPS-20 mailsystem, and various others, use
	an entirely different routing delimiter, "%", even
	though it is not defined as a "special".  We have
	never felt that we needed to have "%" defined as a
	"special", and have done fine without it.

	Why, pray tell, must a character that people do
	want to use as an "ALPHA" be defined as "special",
	considering that the only purpose for it is to
	pre-parse an entity for an entirely different level
	than the RFC 822 level?

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

Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 22:55:37 EST
Date:    Sat, 12 Nov 83 22:57:54 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Periods in full names in RFC822
To:      Rich Wales <v.wales@UCLA-LOCUS.ARPA>
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Rich Wales <v.wales@UCLA-LOCUS.ARPA>, Sat, 12 Nov 83 18:11:39 PST

    If the technical issues involved in modifying RFC822 to allow full
    names with periods are not oppressive, I am in favor of making the
    change.

Good, the discussion is now rationale again:  Figure out the technical
costs of making the change and then decide if the costs are worth it.

I like your suggestion for merging LOCAL-PART and PHRASE and implementing
the "no spaces in local parts" rule as a post-parse semantic restriction.
That grammar would be easily parseable by top-down parsers.

So given those changes, is the effort of changing true parsers worth the
benefit of periods?  It would take me about 6 hours to change our recursive
descent parser, rebuild all of its clients (user interfaces and mail
server), distribute the programs, change documentation, etc.  That's a
non-trivial amount of time for Yale system programmers, though not great.
How many other sites have recently implemented mail systems that are
faithful to RFC 822 and would need to change?

I guess I think that all those implementor-days or half-days hacking in
periods retroactively could better be spent on new projects such as domain
servers that will have much larger impact on mail services.  (Of course,
all the sites that never hacked their old ad hoc parsers in the first
place wouldn't have to change a thing.  But then that's why they didn't
complain about RFC 822 when it was published -- they had no need for the
actual grammar.)

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

A very minor technical point:  A grammar is "ambiguous" if there are
several possible complete parses of an input string.  Just because a
grammar is not LL(1) or LALR(1) does not mean that it is ambiguous.  The
proposed modification of PHRASE to be a sequence of words or periods would
not have resulted in an ambigous grammar, just one that many parsing
methods couldn't handle.
-------

Received: by YALE-BULLDOG via CHAOS; Sat, 12 Nov 83 23:22:09 EST
Date:    Sat, 12 Nov 83 23:26:54 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: more flames
To:      Mark Crispin <MRC@SU-SCORE.ARPA>
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Sat 12 Nov 83 18:54:47-PST

    The only reason why "."  is part of the definition of "special" that
    I can discern is to coddle a certain mailsystem which uses "."  as
    a routing delimiter in the local part.

    ...considering that the only purpose for it [period] is to pre-parse
    an entity for an entirely different level than the RFC 822 level?

Forget LOCAL-PARTs for the moment; "."  also serves as a delimiter of
subdomains.  Are you suggesting that the definition of DOMAIN also be
replaced by WORD?

I find it entirely reasonable that domain syntax is described at the RFC
822 level.  For example, the Yale mail system has a single parser/
mail-address package used by two user interfaces and a mail delivery
daemon.  That package operates essentially at the RFC 822 level, and it
manipulates domains.
-------

Date: Sun 13 Nov 83 11:56:01-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: more flames
To: Ellis@YALE.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "John R Ellis <Ellis@YALE.ARPA>" of Sat 12 Nov 83 20:33:18-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

My belief is that the syntax of domains should not be defined at the
RFC 822 level.  Instead, domain syntax should be defined by the various
domains RFC's.  822 should merely specify the means of obtaining the
domain atom.

If the developers of domain syntax ever decide they want to change the
syntax of domains, e.g. to allow a null top-level domain as has been
suggested, 822 should not get in the way.

It offends my sense of structured programming to parse a domain twice;
first at the 822 level and second in the domain lookup module.
-------

Received: by YALE-BULLDOG via CHAOS; Sun, 13 Nov 83 16:38:49 EST
Date:    Sun, 13 Nov 83 16:45:39 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: What level domain syntax?
To:      Mark Crispin <MRC@SU-SCORE.ARPA>
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Sun 13 Nov 83 11:56:01-PST

    It offends my sense of structured programming to parse a domain twice;
    first at the 822 level and second in the domain lookup module.

If that's the way you engineered your system, I would be offended too.
However, there are better ways of building mail systems than at the string
level encouraged by assembly language programming.

We have a header and address package that parses headers and addresses
into structured objects and performs operations on those objects.  The
package is shared by all components of the mail system:  user interface,
user-information database, and mail daemons.  In any program domains are
parsed exactly once at the time an address is parsed, and thereafter
represented as structured vectors.

One of the operations on an address is "normalize", which puts the address
into cannonical form.  For domains, this currently consists of fully
qualifying the domain and replacing nicknames by official names.  All
the clients of the address package invoke normalize as a matter of course.
For example, the user-information database normalizes addresses and checks
for duplicates when members are added to a mailing list.

The overall advantages of this methodology should be obvious.  Describing
the syntax of domains at the 822 level is entirely appropriate, since
domains are manipulated at the same level as the other parts of addresses.
It is better design to have the parsing and address manipulation
concentrated in one package than scattered throughout the system.

    If the developers of domain syntax ever decide they want to change
    the syntax of domains, e.g. to allow a null top-level domain as has
    been suggested, 822 should not get in the way.

Using this methodology, 822 won't "get in the way," either in defining
the change or in retrofitting the existing address package.  For example,
to add the root domain as a trailing dot, it is trivial to change the
syntax of domain to be:

    DOMAIN = WORD *("." WORD) ["."]

Then the single address parser in the address package is changed to reflect
the new syntax and the operations are changed accordingly.
-------

Date: Sun 13 Nov 83 18:37:27-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: What level domain syntax?
To: Ellis@YALE.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "John R Ellis <Ellis@YALE.ARPA>" of Sun 13 Nov 83 17:55:48-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     John Ellis missed my point.  By insisting that the RFC 822 level
define what the syntax of the right half of the "@" is, RFC 822 is
needlessly limiting itself.  I prefer to think of the left half of the
"@" as a "mailbox" identifier, and the right half as an "address" at
which this mailbox can be found.  Both "mailbox" and "address" are
abstract concepts; today "mailbox" generally means "user ID on a
particular computer" and "address" generally means "the NIC registered
name of a particular computer".

     I believe that these concepts can, and should, be expanded.

     Because of this, I would prefer that 822 not specify anything
about what the structure of the right half of the "@" is.  I would
prefer that to be in an entirely separate module.  It has nothing to
do with string processing or assembly language programming; it is an
attempt to be modular and to use 822 in non-Internet applications
where domains may be inappropriate or irrelevant.

     Given then that some module other than 822 would be enforcing
the correct syntax of domains, there now seems to be no reason to
continue making "." be a special.  It would make a number of existing
users (who detest quotes around their personal names) happy and should
not add any particular difficulties to any YACC-based parser.
-------

Received: by YALE-BULLDOG via CHAOS; Mon, 14 Nov 83 00:27:26 EST
Date:    Mon, 14 Nov 83 00:33:47 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: What level domain syntax?
To:      Mark Crispin <MRC@SU-SCORE.ARPA>
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Mark Crispin <MRC@SU-SCORE.ARPA>, Sun 13 Nov 83 18:37:27-PST

    John Ellis missed my point.

I didn't miss your point.  One of your arguments against 822-specified
domain syntax was that it would require domains to be parsed twice; I
pointed out that was silly.  Your other argument about decoupling the
concept of domain and "address" is much more to the point.
-------

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Nov 83 00:53:30 EST
Date: 14 Nov 83 0105 EST (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz@CMU-CS-A>
To: John R Ellis <Ellis@YALE>
Subject: Re: Periods in full names in RFC822
CC: Header-People@MIT-MC
In-Reply-To: "John R Ellis's message of 12 Nov 83 14:58-EST"
Message-Id: <14Nov83.010516.RG02@CMU-CS-A>

I resent being told we should have spoken up earlier -- we have repeatedly been
stomped on hard when we said anything about spaces and dots in names.  Sigh.

		Rick Gumpertz

Received: by YALE-BULLDOG via CHAOS; Mon, 14 Nov 83 03:58:13 EST
Date:    Mon, 14 Nov 83 04:00:50 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Periods in full names in RFC822
To:      Richard H Gumpertz <Rick.Gumpertz@CMU-CS-A.ARPA>
Cc:      Header-People@MIT-MC.ARPA

    I resent being told we should have spoken up earlier -- we have
    repeatedly been stomped on hard when we said anything about spaces
    and dots in names.  Sigh.

Out of curiosity, I went into the archives to see exactly what had been
said about periods in PHRASE (full names).  RFC 822 was published 15 months
ago.  Here is a summary of messages since then concerning periods in 822
PHRASE:

    18-Oct-82   Chris Kent asks if periods are allowed in full names.
    27-Oct-82   Tim Korb replies that the grammar really does disallow
                periods in full names.  He suggests in passing that periods
                should be allowed "until this issue is resolved."
    27-Oct-82   Dave Crocker replies that A E. Dupont <foo@bar> is indeed
                legal.
    27-Sep-83   Nat Mishkin complains that messages are still being sent
                with unquoted periods in full names.
    28-Sep-83   Gavin Eadie complains about the same thing.
    present uproar

So in 15 months, there was one mild complaint about the actual definition
of PHRASE.  The restriction on periods was immediately clear to those
few sites that had implemented true parsers, but I guess none of them
cared enough to complain.
-------

Date: 5 Oct 1983 0826-PDT
Sender: WMARTIN at OFFICE-3
Subject: Unique identifier for messages
From: WMartin at Office-3 (Will Martin)
To: Header-People at MIT-MC
Message-ID: <[OFFICE-3] 5-Oct-83 08:26:29.WMARTIN>

Wouldn't a good way to uniquely identify messages, given the
problem of changed messages having the Message-ID unchanged, be a
combination of an originally-assigned Message-ID field and the
number of characters in the Text field?  Most duplicate messages
I've seen have different character-counts for the entire message,
because the header has more fields or more data in a field, but
the Text is identical.  Since most message-systems seem to use
the character-count for various purposes, would it be hard to
just count the characters in the Text field alone?  I would think
that it would be safe to program a system to assume duplicates
exist if both the Message-ID and the Text field character-count
were identical.  If there was no Message-ID, of course, such a
message wouldn't be considered as a candidate for being a
duplicate, even if it was.  (I doubt that it would be safe to
consider messages to be duplicates if both had null Message-ID's
and identical Text-field character-counts -- too much margin for
error in that case.)

Will Martin

Received: from merlin.ARPA by purdue.ARPA; Mon, 14 Nov 83 12:16:46 EST
From: Christopher A Kent <cak@PURDUE.ARPA>
Message-Id: <8311141616.AA01310@merlin.ARPA>
Received: by merlin.ARPA; Mon, 14 Nov 83 11:16:37 EST
Date: 14 Nov 1983 1116-EST (Monday)
To: John R Ellis <Ellis@YALE.ARPA>
Cc: Header-People@MIT-MC.ARPA
Subject: Re: Periods in full names in RFC822
In-Reply-To: Your message of Mon, 14 Nov 83 04:00:50 EST.
             <8311140911.AA15881>

Now hold on a sec...

    27-Oct-82   Dave Crocker replies that A E. Dupont <foo@bar> is indeed
                legal.
Maybe I'm just too lazy to dig this out, but should "legal" be
"illegal" here?

Cheers,
chris
----------

Date: 14 Nov 1983 12:25:04 PST
From: POSTEL@USC-ISIF
Subject: re: Periods in Full Names in RFC822
To:   Header-People@MIT-MC


Rick Gumpertz is justified in saying that CMU was stomped on hard about
spaces in names (not dots though), but it must be noted that the complaints
were about spaces in the <local-part> of the mailbox, not the <phrase> now
generally used for a full name.

--jon.
-------

Date: 14 Nov 1983 16:31-PST
Sender: JKREYNOLDS@USC-ISIF
Subject: re: Periods in Full Names in RFC 822
From: JKREYNOLDS@USC-ISIF
To: Header-People@MIT-MC
Message-ID: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS>


In  regards  to  the recent messages on periods in full names in RFC
822, we would like to propose an alternative:  personal names with a
new  construct  that  would  provide alot of variety without so many
periods.  It would be called ntext.  The  following  represents  the
proposed construct:

mailbox = addr-spec / [ntext] route-addr


ntext  =  1*<any  CHAR  except  "<", ">", ",", or CTLs, but allowing
BACKSPACE>


BACKSPACE = <ASCII BACKSPACE>; (10, 8.)

ntext would not only provide users who wish to use their full  names
or  initials (i.e., Joyce K.  Reynolds or J.K.  Reynolds), but would
also allow users with lower case characters in their names  (Juanita
y  Cruz,  Max  de  Trudeau)  or apostrophes in their names (D'Vinet,
d'Vinet).  More complicated names that have slashes through letters,
hats  or  apostrophes  can  also be used within the ntext construct.

For example:  (<BS> = Backspace)


J/<BS>ohansen (a slash would be through the letter o)


^<BS>Cot'<BS>e (a hat would be over the C and  an  accent  would  be
over the letter e)


This new construct provides better options and  flexibility  without
creating major changes.


Joyce Reynolds and Jon Postel






Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Nov 83 23:34:03 EST
Date: 14 Nov 83 2345 EST
From: Rudy.Nedved@CMU-CS-A
To: Stephen Tihor <TIHOR@NYU-CMCL1>
Subject: Re: Restrictive "i"-internet transfers
CC: header-people@MIT-MC
In-Reply-To: <3153F9055.006F0024.1983@CMCL1.NYU-CMCL1.ARPA>
Message-Id: <14Nov83.234503.EN0C@CMU-CS-A>

Umm...there are better reasons to not allow mail between certain entities
and to not say "...mail should be free..."

1) As a taxpayer, I don't like to see non-contributing people use the
   ARPANET for personal gains. ARPANET was a research subject but has
   evolved into an effective "tool". I have benefitted from the quick
   and "personal" flow of mail.

   I fail to see the benefit of some person in UUCP land sending a mining
   proposal to someone in non-CMU-CS/RI land. The proposal is probably
   not bound for the goverment and it is doesn't contribute to CS/RI
   research. Purolator Courier, MCI Mail, GTE TELENET TELEMAIL, UPS,
   Federal Express and good old US Postal system are what people should
   use.

2) I tend to believe in competition creating better enviroments and in
   costs being seen by the users. The cost of using the ARPANET is
   rarely seen by the end-user...he or she never gets charge postage
   for the hardware and the software that is used. Commercial electronic
   mail systems on the other hand charge postage and are used more
   effectively by their users.

3) The ARPANET has at max it seems 50KBD links between IMPs and we have
   recently gone thru a protocol transition and a split which took a
   very large number of man hours, large expenditure of money on hardware
   and a large expenditure of money on support services (ma bell, clerical,
   answering users complaints, etc.) to get the thing working by many
   different organizations. To see Fortran manuals, special character files
   that draw funny pictures on Heathkit 19s, etc. sent thru the mail is
   disheartening.

My apology for the length of the mail message.
-Rudy

Date:           Mon, 14 Nov 83 21:48:18 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Re: "ntext" answer to periods in full names
In-reply-to:    JKREYNOLDS@USC-ISIF's message of 14 Nov 1983 16:31-PST

Joyce and Jon --

Regarding your "ntext" proposal, I believe it has some good points and
some not-so-good points.  My initial feeling is that, in its current
form, it is not quite satisfactory; however, perhaps it can be refined.
Some particulars:

(1) I note with HEARTY APPROVAL that your proposed rule for "mailbox" --

	    mailbox = addr-spec / [ntext] route-addr

    -- would allow a bare "route-addr" (an address enclosed in angle
    brackets) without a preceding "full-name" string.  Whatever form of
    full-name representation we end up with, I think this innovation
    should definitely be included.

(2) I am concerned that your proposed rule for "ntext" --

	    ntext = 1*<any CHAR except "<", ">", ",",
		       or CTLs, but allowing BACKSPACE>

    -- would complicate lexical analysis of an address.  Specifically,
    the lexer would have no way of telling whether a "mailbox" started
    with an "ntext" or an "addr-spec" without performing a potentially
    unbounded lookahead.

(3) You suggest that the "ntext" proposal would allow users to have
    apostrophes and/or uncapitalized words in their names (e.g., "Max
    de Trudeau" or "d'Vinet").  But constructions like these are al-
    ready permitted by RFC822.  The apostrophe (single quote) is not
    designated as a special character and may freely occur in atoms,
    and no recapitalization of the full name is either required or ex-
    pected.

(4) I am somewhat hesitant about the prospect of names with backspaces
    (to implement accents on letters via overstriking).  Most users
    probably read their mail on CRT terminals without any overstriking
    capability, so such effects would be lost on them.  However, this
    part of your proposal would not cause lexing or parsing problems as
    far as I can tell, since the backspace does not currently have any
    special function in an address.

I would be interested in knowing whether you think the proposal I made
last Saturday (12 Nov 83 18:11 PST) -- in which I suggested that the
"phrase" nonterminal be redefined to allow a free mix of atoms, quoted
strings, and periods; that "local-part" be replaced by "phrase" in the
"addr-spec" rule; and that a post-parse scan be used to kick out mal-
formed local parts -- would meet your concerns if the "atom" token were
redefined to allow backspaces.

-- Rich

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA25803; Mon, 14 Nov 83 21:16:16 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA03588; Mon, 14 Nov 83 21:23:23 pst
Date: Mon, 14 Nov 83 21:24:22 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA23673; Mon, 14 Nov 83 21:24:22 pst
To: header-people@mit-mc
Subject: Errors-To Field


Forwarded for your information from USENET News:

	From gnu@sun.UUCP Fri Nov 11 01:38:55 1983
	Newsgroups: net.news,net.mail
	Subject: Fix for Arpanet junk deluges (at gateway)
	Article-ID: net.mail/190

	If the news<->mail gateway would add
		"Errors-To: Unix-Emacs-Request@wherever"
	to the headers of newsitems which are being posted to the
	Arpanet, at least the volume of garbage coming back would be
	returned.  If Sendmail can't deliver a message, and it contains
	an Errors-To line, it gets sent there rather than to the poor
	submitter.  Of course, if the mailer which has trouble is not
	Sendmail, we're out of luck.

	Arpanet folks who maintain redistribution lists (eg, Unix-Emacs)
	are encouraged to add this line to each message you
	redistribute, too.

	And if many mailing lists start using Errors-To:, maybe some of
	the mailers other than sendmail will get modified to use it.
	Then we would all be happier.



Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Nov 83 01:20:03 EST
Date: 15 Nov 83 0132 EST
From: Rudy.Nedved@CMU-CS-A
To: wcwells%ucbopal.CC@UCB-VAX (Bill Wells)
Subject: Re: Errors-To Field
CC: header-people@mit-mc
In-Reply-To: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA>
Message-Id: <15Nov83.013202.EN0C@CMU-CS-A>

Here is my response to James Gosling after he started getting
pressure to put pressure on me to add Errors-To:. It is a highly
undiplomatic message but I am tired and consider the case closed.

Date: 14 Nov 83 2320 EST
From: Rudy.Nedved@CMU-CS-A
To: James Gosling <cmuitca!jag@CMU-CS-H>
Subject: Re: Unix.Emacs errors
In-Reply-To: <437696282/jag@jag>
Message-Id: <14Nov83.232035.EN0C@CMU-CS-A>

I don't know where you picked up the "Errors-To" concept. It is wrong
since most of the mailers on LANs and ARPANET-like enviroments use
the out-of-band information to return mail.

It has been spec'd by the ARPANET community (well an intelligent
majority), that the out-of-band information be changed when a piece
of mail comes to a mailbox that is a "mail exploder". The Return-Path
information is supposed to be a local mailbox like
"Unix-Emacs-Request". The problem at the moment for Unix-Emacs is
that we have not made the change to the TOPS-20 mailer but it is in
the works.

For the time being, I suggest that you send out a test message and
then zap anyone you get grief with and tell them that you will add
them back when they get their mail system up to 99% working status or
we get our mail system to send error messages to a local mail
box...which ever comes first.

-Rudy


Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 15 Nov 83 01:06:29 PST
Date:     15 Nov 83 9:02:13 GMT (Tue)
From:     Steve Kille <steve@ucl-cs> (44a)
To:       jkreynolds@usc-isif.arpa, postel@usc-isif.arpa
cc:       header-people@mit-mc.arpa, robert@ucl-cs, kirstein@ucl-cs
Subject:  Protocol stability

I am a little concerned about the changes proposed to RFC 822.
I think that the changes which you are proposing are an
improvement.  However, the issue is not vastly important.

Since the move from RFC 733 -> 822 occurred, I spent quite some
effort persuading the UK community that they should follow this
change in the interests of compatability.  There was a good deal
of opposition.  If changes such as this occur, it will be
argued (quite reasonably), that it is not worth the effort of
chasing protocols which will disappear under your feet.  There
are many groups outside of the DARPA Internet who use RFC 822
as a Message format, and compatability is of mutual benifit.

I would like to keep RFC 822 as it stands - warts and all.

Steve Kille


Date:  15 November 1983 01:36 pst
From:  Bakin.SSID at HI-MULTICS
Subject:  Re: Restrictive "i"-internet transfers
To:  header-people at MIT-MC
Acknowledge-To:  Bakin.SSID at HI-MULTICS

I would like to pick at a point of Rudy.Nedved's message:

    I tend to believe in competition creating better
    enviroments and in costs being seen by the users.  The
    cost of using the ARPANET is rarely seen by the
    end-user...he or she never gets charge postage for the
    hardware and the software that is used.  Commercial
    electronic mail systems on the other hand charge postage
    and are used more effectively by their users.

While I have never used a commercial service, I doubt that users use a
service more effectively simply because they are charged for it.

Again, I have never used a commercial service, but how many offer FTP,
and telnet besides Mail Service?  How many can be accessed as easily as
the ARPAnet?

More to the point, effectiveness is in the eye of the beholder:
  ::= 1. Having an intended effect. 2. Producing a desired impression;
         striking. 3. Operative; in effect. (This is from my American
         Heritage Dictionary of the English Language, not a great source,
         but it will do.)

I fail to see a mechanism in charging users that creates more effective
use of the net for that user.  It is possible that charging users does
create less traffic, and so the net response may improve for all, but
this does not mean that the traffic that is out there will become more
effective.  Rather, projects who have little money to begin with will
communicate poorly over the net, while those projects with Big Bucks
will not suffer a whit, and will continue to send Fortran manuals, or
human-nets-digest.  This does not seem to create effective use of the
ARPAnet at all!

It doesn't even promote efficient use.

I can understand the motives behind Rudy.Nedved's message, as an
institution which is publicly supported, it is to be hoped that the
ARPAnet is not abused.  Nevertheless, charging users for its use, or the
restriction of internet mail is like cutting off your nose to spite your
face: a dubious method all around.

Jerry Bakin <ucbvax!allegra!4ccvax!jbakin>

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Nov 83 05:25:38 EST
Date: 15 Nov 83 0537 EST
From: Rudy.Nedved@CMU-CS-A
To: Bakin.SSID@HI-MULTICS
Subject: Re: Restrictive "i"-internet transfers
CC: header-people@MIT-MC
In-Reply-To: "Bakin.SSID@HI-MULTICS's message of 15 Nov 83 04:36-EST"
Message-Id: <15Nov83.053741.EN0C@CMU-CS-A>

My comments are based on the following expectation...independent of
who gets hurt...just simple trend watching:

It is my expectation that one of these days gateways connected to the
ARPANET will have to charge for access on some level to pay for the
service. This is based on the ever growing CSNet which has to charge
for the hardware, software and man power made available, increased
knowledge of "private" computer links in public databases and in the
increasing commercial electronic mail systems that would just love to
boast of mail service to the ARPANET world.

-Rudy

Received: from merlin.ARPA by purdue.ARPA; Tue, 15 Nov 83 07:37:49 EST
Received: by merlin.ARPA; Tue, 15 Nov 83 07:37:02 est
Date: 15 Nov 1983 0737-EST (Tuesday)
Return-Path: <@MIT-MC:JKREYNOLDS@USC-ISIF>
Received: from purdue.ARPA (purdue-arthur.ARPA) by merlin.ARPA; Mon, 14 Nov 83 20:19:57 est
Received: from MIT-MC by purdue.ARPA; Mon, 14 Nov 83 20:20:34 EST
Date: 14 Nov 1983 16:31-PST
Sender: JKREYNOLDS@USC-ISIF.ARPA
Subject: re: Periods in Full Names in RFC 822
From: JKREYNOLDS@USC-ISIF.ARPA
To: Header-People@MIT-MC.ARPA
Message-Id: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS>


In  regards  to  the recent messages on periods in full names in RFC
822, we would like to propose an alternative:  personal names with a
new  construct  that  would  provide alot of variety without so many
periods.  It would be called ntext.  The  following  represents  the
proposed construct:

mailbox = addr-spec / [ntext] route-addr


ntext  =  1*<any  CHAR  except  "<", ">", ",", or CTLs, but allowing
BACKSPACE>


BACKSPACE = <ASCII BACKSPACE>; (10, 8.)

ntext would not only provide users who wish to use their full  names
or  initials (i.e., Joyce K.  Reynolds or J.K.  Reynolds), but would
also allow users with lower case characters in their names  (Juanita
y  Cruz,  Max  de  Trudeau)  or apostrophes in their names (D'Vinet,
d'Vinet).  More complicated names that have slashes through letters,
hats  or  apostrophes  can  also be used within the ntext construct.

For example:  (<BS> = Backspace)


J/<BS>ohansen (a slash would be through the letter o)


^<BS>Cot'<BS>e (a hat would be over the C and  an  accent  would  be
over the letter e)


This new construct provides better options and  flexibility  without
creating major changes.


Joyce Reynolds and Jon Postel








Date: Tue, 15 Nov 83 10:25 PST
From: Taft.PA@PARC-MAXC.ARPA
Subject: Re: Periods in Full Names in RFC 822
In-reply-to: <[USC-ISIF]14-Nov-83 16:31:33.JKREYNOLDS>
To: Header-People@MIT-MC.ARPA

Please add my vote in opposition to the "ntext" proposal. Rich Wales has
done a good job of summarizing the technical problems with it. I would
like to add two remarks:

  (1) The proposal involving <BS> and overstriking really amounts to an
extension of the ASCII standard to enable foreign characters to be
encoded. The fact that an ad-hoc encoding happens to "come out right" on
some terminals does not make it a good encoding! And in any event, RFC
822 is not an appropriate place to specify an extension to ASCII.

  (2) I vote for no changes to RFC 822 other than to fix typographical
errors in the specification (of which there are many) and to clarify
matters that are now obscure. No amount of fiddling with the header
syntax is going to make more than a negligible improvement in the
overall standard. RFC 822's fundamental problems derive from the
constraints imposed by the text memo header framework in which it has to
fit. No real improvement will occur until that framework is junked and
replaced by a structured format such as the NBS or CCITT message
standard.

I am dismayed over the amount of smoke and heat generated and brain
cycles wasted in debates about header syntax. Let's declare a moratorium
on twiddles to RFC 822 and move on to more difficult and more
interesting problems such as implementation of the new domain names
standard.

	Ed Taft


Received: by YALE-BULLDOG via CHAOS; Tue, 15 Nov 83 14:16:37 EST
Date:    Tue, 15 Nov 83 14:20:05 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Periods in Full Names in RFC 822
To:      Taft.PA@PARC-MAXC.ARPA
Cc:      Header-People@MIT-MC.ARPA
In-Reply-To: Taft.PA@PARC-MAXC.ARPA, Tue, 15 Nov 83 10:25 PST

    Let's declare a moratorium on twiddles to RFC 822 and move on to more
    difficult and more interesting problems such as implementation of
    the new domain names standard.

Amen.
-------

Date: 15 Nov 83 14:28 EST
From: Stephen Tihor <TIHOR@NYU-CMCL1.ARPA>
To: Taft.PA@PARC-MAXC.ARPA
Subject: RE: Periods in Full Names in RFC 822
Cc: header-people@MIT-MC.ARPA
Message-ID: <3194F8A4B.004C001D.1983@CMCL1.NYU-CMCL1.ARPA>
In-Reply-To: <8311151902.AA15933@NYU.ARPA> 	;
	Message of 15-NOV-1983 14:03 from Taft.PA@PARC-MAXC.ARPA

A minor point perhaps but the use of backspace in the ntext proposal
IS the ANSI/ISO character set specification of the correct way to 
produce the multistruck characters.  A few special CRTs can interpret it 
properly even in the US and more elsewhere, it looks right on paper, and
the order list in the examples will quite properly produce the
usual colpasing of overstuck characters into their nearest non-overstruck
alphabetic.  
 
-------

Date:           Tue, 15 Nov 83 11:57:54 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        Re: Moratorium on twiddles to RFC822

Wait a minute, folks.  I, for one, do NOT consider the original sug-
gestion (namely, modifying RFC822 to allow periods in unquoted full
names) to be a "twiddle".  Just because the Reynolds/Postel "ntext"
proposal had some problems with it as originally presented, let's not
all lose sight of what originally brought up the discussion.

A suggestion has been made (my own proposal of 12 Nov 83) which seems
to allow periods in unquoted full names without doing violence to any
of the lexing/parsing methods reasonably available for handling head-
ers.  I believe that the degree of effort required to implement this,
or a similar, proposal would be small.  Many -- maybe even most -- of
the mail-system implementors were probably not implementing the exact
current standard via a grammar anyway; for most of them, the effort
involved would likely be minimal to nil.

To those in the UK/JNT community who hesitate to have any change, how-
ever minor, in RFC822, let me again state my opinion (which I think is
held by many other people) that I view the admission of periods in un-
quoted full names to be more on the order of a "bug fix" to RFC822 than
a true change.  I dare say that if people had realized earlier that RFC-
822 required the quoting of full names which contained periods, this
issue would have been discussed at length and ironed out long ago.

This issue may not be as important as the distributed domain name serv-
ers, but that doesn't mean it is utterly unimportant.

-- Rich

Date:     Tue, 15 Nov 83 14:28:08 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Rudy.Nedved@cmu-cs-a
cc:       Bakin.SSID@hi-multics, header-people@mit-mc
Subject:  Re:  Restrictive "i"-internet transfers

The charging software for DDN will be ready in 1986 (they claim).
Nobody is sure what the details of charging will be (if any).

-Ron

Date: Tue 15 Nov 83 13:46:35-PST
From: Ken Harrenstien <KLH@SRI-NIC>
Subject: Bug fix to 822
To: Header-people@MIT-MC

As one of the bloodied participants of past header format standard
debates, I agree with those who contend that the illegality of
"John R. Ellis" constitutes a bug, and should be fixed.

Perhaps John R Ellis was not around at the time that RFC733 was being
written.  My personal recollection (which may vary from that of
others) is that 733 absorbed a great deal of energy from many of the
involved parties, and there was a feeling that it marked the end of
things.  When it appeared to Dave Crocker that domains were on the way
and a revision was necessary, he produced 822 with little in the way of
debate.  The politics of ARPAnet protocol standardization are VERY
muddy, but some people certainly felt "stomped on" during 733 (by what
authority is irrelevant) and were either tired or didn't feel like
being stomped on again during 822.

The point is that the treatment of periods is one thing that was
changed from 733 to 822, although there is no obvious reason for
changing anything other than the stuff to the right of the @-sign.  In
fact, in the old 733 you can see examples such as
	Alfred E. Neuman <Neuman at BBN-TENEXA>
In 822 this example became
	Alfred Neuman <Neuman@BBN-TENEXA>
Is this a cop-out, or is it a cop-out?  Who ever heard of Alfred Neuman?

Finally, a word about parsers.  It seems to me that those people who
have implemented snazzy 600-horsepower full-bore parsers with racing
stripes, fur-lined bucket seats, and mag wheels that blast you towards
the uttermost reaches of 822 should be exactly those people who will
find it EASIEST to accomodate any fixes.  The usual trend is that
people with crude parsers complain bitterly about changes that force
them to once again fight intricate tangles of code, whereas the
un-crude exclaim "oh my, what a trivial thing!".  It's strange to find
the roles reversed.

--Ken

P.S.  Whatever the importance or results of the 822-period-bug debate,
it does highlight the need for some clearer agreement (or policy
statement) on the issue of protocol development and modification.
What makes a protocol "official"?  When are changes "authorized"?  Who
decides this, and what voice do network sites have in the process?  Do
people want a real "Protocol Police"?  I don't want to spark a new
discussion topic just now, but someday those questions ought to have
written answers.
-------

Date: Tue 15 Nov 83 13:55:11-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: change RFC 822?
To: Header-People@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     Suppose we consider whether or not 822 should be changed based on
these details:

 . Do we want the typos in 822 corrected?  If so, we'd need a different
   RFC just for typo correction
 . How many implementations correctly quote personal names with imbedded
   periods?
 . How many implementations are dumb, and merely insert whatever string
   the user gives for a personal name?  (I'm afraid MM falls into this
   category)
 . How many implementations get upset at seeing:
	From: J. Random Hacker <Hacker@Some-Host.ARPA>
   Of those, how many implementations determine that "J. Random Hacker"
   should have been quoted and compensate for it?
 . How many implementations have some heuristic (crock) algorithm that
   completely ignores anything outside of angle brackets unless there
   is no angle-bracketed string?  (MM falls into this category)
 . Of the faulty implementations, how many implementors would find
   themselves more willing to upgrade their software if the dot question
   was resolved in the way users seem to want it resolved?

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

Received: by YALE-BULLDOG via CHAOS; Tue, 15 Nov 83 18:33:20 EST
Date:    Tue, 15 Nov 83 18:39:00 EST
From:    John R Ellis <Ellis@YALE.ARPA>
Subject: Re: Bug fix to 822
To:      Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc:      Header-people@MIT-MC.ARPA
In-Reply-To: Ken Harrenstien <KLH@SRI-NIC.ARPA>, Tue 15 Nov 83 13:46:35-PST

    The usual trend is that people with crude parsers complain bitterly
    about changes that force them to once again fight intricate tangles
    of code, whereas the un-crude exclaim "oh my, what a trivial thing!".
    It's strange to find the roles reversed.

This is a distortion.  Ed Taft neatly summarized my main objection:  Now
is not the time to change 822.  No one disputes that Wales' suggested
hack would be "easy" to implement in a true parser (though it would dirty
the formal specification a little).
-------

Date: Tue, 15 Nov 1983 10:32:13 PST
From: David M Alpern <Alpern.IBM-SJ@Rand-Relay>
Return-Path: <ALPERN.SJRLVM4.IBM-SJ@Rand-Relay>
Subject: Restrictive Gateways
To: HEADER-PEOPLE@mit-mc
Via:  IBM-SJ; 15 Nov 83 15:36-PST

I'm sorry to see that my question, of a technical nature, has yielded
so much flaming and NO technical comments.
 
Whether or not those of us who have lived with virtually unlimited network
access want to realize it, restrictive gateways, as I described, already
exist in many environments, some academic and some business.  They are
a reality, regardless of our philosophy as to whether such restrictions
should exist.
 
I would greatly appreciate a TECHNICAL response to my question:  Is there/
should there be a means in the header of specifying to an outside recipient
that he may not be able to contact (via the given address) a local recipient?
Or should the header show nothing special, under the assumption that the
outside recipient will find out for himself if and when he replies?
 
- Dave

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA00277; Wed, 16 Nov 83 00:42:42 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA13030; Tue, 15 Nov 83 22:40:27 pst
Date: Tue, 15 Nov 83 22:40:31 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311160640.AA19790@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA19790; Tue, 15 Nov 83 22:40:31 pst
To: header-people@mit-mc
Subject: Precedence

In reply to:


	Date: 1 November 1983  00:43-PST (Tuesday)
	Sender: TLI@USC-ECLB
	From: Tony Li <Tli@Usc>
	To: Wcwells@BERKELEY
	Subject: Re: SMTP extension RFC

	I'm sort of new at this, but wouldn't using a precedence field
	in the SMTP header be somewhat confusing?  The precedence field
	that you suggest is already present in the internet datagram
	header.  Creating another use for the same precedence scheme in
	the SMTP header would seem to lead to ambiguity when referring
	to the 'precedence field'....

Tony,

I cannot assume that "Internet Protocol (IP) " will be running under
SMTP. I know of at least one case where "IP" is not the protocol being
used under SMTP and there may others.

I am not proposing a new use of precedence, but pointing out that
"precedence" as defined for US Government telecommunications needs to
implimented in "Internet Mail". To be effective precedence must be
used at various levels. To the drafter it may mean the desired speed of
delivery. But for communications personnel and message systems it also
indicates the order in which messages are to be handled.  That is,
higher precedence messages should be transmitted before lower
precedence messages. Within the same precedence, messages are usually
handled on a first-in first-out basis.

The drafter should be able to specific the precedence of an Internet
mail message. One method would be the use of a "Precedence:" field in
the Internet mail message heading.

Within SMTP, indicating the precedence of message(s) to be transmitted
when establishing a SMTP communications link would be useful when a
particular mail relay or network is heavily loaded.  For example, an
overloaded host or gateway (to another network) might respond that it
can accept only PRIORITY and above precedence messages until the
overload condition goes down.

Bill Wells, U C Berkeley
wcwells@Berkeley.ARPA

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA00274; Wed, 16 Nov 83 00:42:28 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA06888; Tue, 15 Nov 83 17:29:34 pst
Date: Tue, 15 Nov 83 15:39:22 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311152339.AA11178@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA11178; Tue, 15 Nov 83 15:39:22 pst
To: header-people@mit-mc
Subject: Re: Errors-To Field
Cc: decvax!decwrl!sun!gnu@Berkeley


The following was submitted as an article to USENET News group net.mail
and is forwarded for information to the Header-People mailing list:

Bill Wells

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

In reply to:

   Path: ucbopal!ucbtopaz!ucbvax!decvax!decwrl!sun!gnu
   From: gnu@sun.UUCP
   Newsgroups: net.news,net.mail
   Subject: Fix for Arpanet junk deluges (at gateway)
   Message-ID: <339@sun.UUCP>
   Date: Fri, 11-Nov-83 01:38:55 PST
   Article-I.D.: sun.339
   Posted: Fri Nov 11 01:38:55 1983
   Date-Received: Fri, 11-Nov-83 21:39:16 PST
   References: drux3.874
   Lines: 13

   If the news<->mail gateway would add
   	"Errors-To: Unix-Emacs-Request@wherever"
   to the headers of newsitems which are being posted to the
   Arpanet, at least the volume of garbage coming back would be
   returned.  If Sendmail can't deliver a message, and it contains
   an Errors-To line, it gets sent there rather than to the poor
   submitter.  Of course, if the mailer which has trouble is not
   Sendmail, we're out of luck.

   Arpanet folks who maintain redistribution lists (eg, Unix-Emacs)
   are encouraged to add this line to each message you
   redistribute, too.

   And if many mailing lists start using Errors-To:, maybe some of
   the mailers other than sendmail will get modified to use it.
   Then we would all be happier.


In May 1983, there was a long discussion on how to handle errors
resulting from messages forwarded by mailing list "address
exploders" on the Headers-People@MIT-MC mailing list.  During this
time the "Errors-to:" header field was suggested by Dr. Jon Postal
of the Information Sciences Institute (Marina del Rey, CA). Dr. Postal
is the author of the "Simple Mail Transfer Protocol" (SMTP) used by
the Unix "sendmail" program.  After many comments concerning the
proposed "Errors-To:" header field and variations thereof, it was
decided that messages sent by a "mail address exploder" should be
a new message.  As far as I know, the "Errors-To:" header field
has never been implimented as a standard Internet mail message
header.  Here is an extract from Dr. Postel's message of 27 May 83:

   Date: 27 May 1983 2032-PDT
   From: POSTEL@USC-ISIF
   Subject: Errors-To, round 3
   To: Header-People@MIT-MC

   Hi.

   Thanks for all your comments. I have been persuaded that the
   functional capability i wanted is best provided (in the context
   of the current system) by the SMTP procedures and requiring
   that sending to a mailing list via a mail exploder be treated
   a two transaction process.

   That is, when a user sends a message to a mail exploder there is
   one transaction when the message travels via SMTP from the user
   to the exploder.  Any errors detected (e.g. misspelling the mailing
   list name) in this stage will go back to the user.  When the mail
   exploder sends the message to the mailling list there is another
   transaction. Any errors detected at this stage (e.g. a mailbox
   on the list does not exist) will go back to the "owner" of the
   mailing list.
   
   ......


I submitted the gnu@sun article to the Headers-People mailing list
and received the following in reply:


   Date: 15 Nov 83 0132 EST
   From: Rudy.Nedved@CMU-CS-A
   To: wcwells@ucbopal (Bill Wells)
   Subject: Re: Errors-To Field
   Cc: header-people@mit-mc
   In-Reply-To: <8311150524.AA23673@ucbopal.CC.Berkeley.ARPA>
   Message-Id: <15Nov83.013202.EN0C@CMU-CS-A>

...... (Header-People have seen it before so I won't repeat
...... it here-WCW)


I hope this clears up why "Errors-to" is not being used on in the
Internet community. Hopefully it will not be too long before
all mail exploders in the Internet community quote the message
sent to the exploder in the text of a new message which is
sent to the mail distribution list.

Bill Wells, U.C. Berkeley
ucbvax!wcwells
wcwells@Berkeley.ARPA


Received: by UCB-VAX.ARPA (4.21/4.15)
	id AA19349; Tue, 15 Nov 83 20:13:11 pst
Date: 15 Nov 83 16:43:47 EST (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Rudy Nedved on mail forwarding
Message-Id: <8311152143.AA20717@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA20717; 15 Nov 83 16:43:47 EST (Tue)
To: header-people@mit-mc.ARPA

re:
	As a taxpayer, I don't like to see non-contributing people use the
	ARPANET for personal gains. ARPANET was a research subject but has
	evolved into an effective "tool". I have benefitted from the quick
	and "personal" flow of mail.
	
	I fail to see the benefit of some person in UUCP land sending a mining
	proposal to someone in non-CMU-CS/RI land.

I resent this.  For your information, UUCP mail is sent over dialup telephone
lines.  These phone calls are usually long distance and cost REAL MONEY
for the site placing the phone call.  Frequently UUCP mail goes over
several hops, resulting in several phone calls.  All the sites along the
way pay for the phone call, even though the message is for the person
who originated the mail.  Yet, each site in UUCP land is willing to pay
for phone calls to forward other people's mail, in return for other sites
being willing to pay for the phone call to send their mail.  In addition,
poor sites (like universities) that cannot afford any phone bills are
often on the UUCP net out of the generousity of some commercial site
polling them frequently.

UUCP is also quite willing to forward mail from people on the ARPANET
(or anywhere else) through the UUCP net, even if the final destination
is on some other network somewhere.  Now you're going to tell me that
the ARPANET is populated by snobs who are unwilling to accept mail that
originated on the UUCP net, at considerable cost to UUCP sites, destined
for ARPANET users?  Even though it doesn't cost you or ARPA ONE RED CENT
additional for this mail to go through your fixed-rate lines?

Tell me, do you have an in-box on your desk in your ARPA-funded office?
Do you only accept paper mail from other ARPA-funded offices in this
in-box?  Do you send back mail from some other source, because you don't
want your ARPA funding to pay for mail that isn't official ARPA mail?
Now, suppose you quit/graduate and move elsewhere in the country.  What
happens when mail is sent to you at your ARPA-funded address?  Do you
expect this mail to be tossed into the trash instead of being forwarded
to your new address?

I'd like to point out that it takes two to use electronic mail - a sender
and a receiver.  To listen to you, if one of them is a sanctified ARPA
funded person (all kneel!) the other one should not be allowed to even
talk to this holy person without having equal status!

Disclaimer: I am talking about personal electronic mail, short, low
volume, and sent (most of the time) over the most reasonable route.
I am NOT advocating shipping of large files over other people's networks
(unless there is no other way to get it there, and the sites along
the way consent) by hiding them in mail - this is just bad manners,
and isn't very reliable either.  (Spool areas tend to fill up.)
Nor am I advocating shipping mail from one UUCP site, to an ARPA
gateway, over the ARPANET, to another ARPA-UUCP gateway, then out
to another UUCP site, at least not on a regular basis.  (Occasionally
mistakes will happen, especially in the case of forwarded mail when
the sender does not know the new address of the addressee.)  However,
if some site is on a network that has only a connection to the ARPANET,
and they want to send mail to UUCP or CSNET, they have little choice but
to go through the ARPANET, and conversely for this same site receiving mail.

I think the primary goal should be universal service.  Let's first make it
possible to get mail from anybody to anybody, then worry about the most
efficient or lowest cost or most politically expedient way to get it there.

	Mark Horton

Date:     Wed, 16 Nov 83 16:24:44 EST
From:     Ron Natalie <ron@brl-vgr>
To:       header-people@mit-mc
Subject:  Re:  Precedence

Despite his work with mail protocols, it's still Postel not Postal.

-Ron

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 16 Nov 83 17:42:44 EST
Date: 16 Nov 83 1753 EST
From: Rudy.Nedved@CMU-CS-A
To: cbosgd!mark@UCB-VAX (Mark Horton)
Subject: Re: Rudy Nedved on mail forwarding
CC: header-people@MIT-MC
In-Reply-To: <8311152143.AA20717@cbosgd.UUCP>
Message-Id: <16Nov83.175318.EN0C@CMU-CS-A>

I knew I blew the example.

I meant someone in UUCP land sending a large document to someone in the
CMU undergraduate land that had nothing to do with the UUCP land or
with ARPANET land. A better example is sending H19 files from a CMU students
account that just got job at some site hanging off of UUCP land.

Anyhow...

I am highly sympathetic with the expense behind UUCP transfers. I feel
people should use the lines more effectively and not send "junk" mail
on them. I suspect that one of the reasons people don't run USENET
software that includes broadcasting of node information is that they arew
afraid there "private" and "expensive" link will be used for purposes
that they can not afford.

I am not an ARPANET snob nor do I prefer ARPANET over other networks. I
just try to do the best for everyone. It is too bad you got bent out of
shape over my poorly written example.

-Rudy

P.S. When I leave I plan to NOT have my mail forwarded. I don't need
     the aggravation from bug reports.

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA00332; Wed, 16 Nov 83 00:45:24 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA11584; Tue, 15 Nov 83 21:12:45 pst
Date: Tue, 15 Nov 83 21:12:48 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311160512.AA18180@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA18180; Tue, 15 Nov 83 21:12:48 pst
To: header-people@mit-mc
Subject: Precedence

This discussion started with the subject line of "SMTP Extension RFC".
With this message I am dividing the discussion into specific topics.
-WCW.

----------


SURPRIZE! The National Precedence System designators are already
specified in the IP Header Format (RFC-791 section 3.1) which has the
following precedence designators:

	111 - Network Control
	110 - Internetwork Control
	101 - CRITIC/ECP
	100 - Flash Override
	011 - FLASH
	010 - IMMEDIATE
	001 - PRIORITY
	000 - ROUTINE

So, that leaves us with:

	a. If, when and how should the precedence designators ECP,
	FLASH, IMMEDIATE, PRIORITY and ROUTINE be implimented at the
	mail transport (SMTP) and user levels? That is to say,
	how does the user specify the precedence of a Internet
	mail message and how should it be handled by SMTP and
	mail gateways.

	b. Should a LOW precedence designator be implimented
	for such things as mailing lists and news articles. 
	(I assume LOW would be mapped to ROUTINE
	in the IP header, since 000 through 111 is used up).


Bill Wells, UC Berkeley
wcwells@Berkeley.ARPA

P.S. Thanks, Tony. I had forgotten that there was a precedence field
in the IP header format.

Date: Thu, 17 Nov 83 01:44 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: Re: Periods in Full Names in RFC 822
To: John R Ellis <Ellis@YALE.ARPA>
Cc: Taft.PA@PARC-MAXC.ARPA, Header-People@MIT-MC.ARPA
In-reply-to: The message of 15 Nov 83 14:20-EST from John R Ellis <Ellis at YALE>
Message-ID: <831117014420.6.RWK@YUKON.SCRC.Symbolics>

    Date:    Tue, 15 Nov 83 14:20:05 EST
    From:    John R Ellis <Ellis@YALE.ARPA>
	Let's declare a moratorium on twiddles to RFC 822 and move on to more
	difficult and more interesting problems such as implementation of
	the new domain names standard.

    Amen.
    -------
Well, yes.  But let's also remember people's reactions to this issue
and not make the same mistake again.  It would have been much easier
to have made the standard more sane in the beginning than to make every
mail-reading program program in the world know how to reformat the
From: field, as was done here.  Next time let's worry more about
human parsers than machine parsers, whenever we ask them both to
parse the same material.

Date: 17 November 1983  01:06-PST (Thursday)
Sender: TLI @ USC-ECLB
From: Tony Li <Tli @ Usc>
To:   Header-people @ mit-mc
Cc:   Wcwells @ berkeley
Subject: Re: Precedence and Errors
Reply-to: Tli @ Usc-Eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


Let me put up some ideas for you to kick around regarding 'Precedence:' and
error handling.  I'm trying to approach this as a top-down design problem,
and so I'm trying to figure out what user services we should be providing
within SMTP.  So, for the user level, we could have:

Precedence: Priority
or	    Personal
or	    Mailing-List
or	    Bulk

The semantics of all of these should be obvious.  If not, then I obviously
haven't done enough thinking about the keywords.  I don't really like the
keyword 'Precedence' but I don't have any better suggestions yet.  I like
the suggestion of 'CLAS' even less.

I think that the mapping of these precedence levels onto the IP Precedence
field is irrelevant.  I get the idea that the precedence field in SMTP
should be exclusively for the use of the mailers, and that the IP Precedence
field is for dealing with packets in general.  How this mapping occurs is up
to the source mailer.

As to error handling, I would like to see the error handling for a
particular message be totally divorced from all other parameters of the
message.  This might result in something like:

Error-messages-on : All-Errors
or		    Fatal-Errors
or		    No-Errors

This is intended to provide a modicum of flexibility without being
impossible to implement.

Cheers,
Tony ;-)

Date: 17 Nov 1983 10:43:58 PST
From: POSTEL@USC-ISIF
Subject: Concerns about Getting it Right Next Time
To:   header-people@MIT-MC


All of you who are concerned about getting the mail specifications
right the next time should be involved in the development of the
international standards for computer mail.  I think the leading
candidate draft standard in the one prepared by a CCITT committee.
Jim White at XEROX seems to be the key player in that work.  There
is already a very substantial document on this proposal and it is
on the verge of the final phases of being declared a standard.

--jon.
-------

Date: 17 Nov 1983 11:00:48 PST
From: POSTEL@USC-ISIF
Subject: re: Concerns About Getting It Right Next Time
To:   header-people@MIT-MC


The draft specification i have seen is called "CCITT Draft Recommendations
on Message Handling" and dated June 1983.  It was assembled by Ian Cunningham
of BNR.

--jon.
-------

Date: Thu, 17 Nov 83 18:31 EST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: re: Concerns About Getting It Right Next Time
To: POSTEL@USC-ISIF.ARPA
Cc: header-people@MC.ARPA
In-reply-to: The message of 17 Nov 83 14:00-EST from POSTEL at USC-ISIF
Message-ID: <831117183128.6.RWK@YUKON.SCRC.Symbolics>

    Date: 17 Nov 1983 11:00:48 PST
    From: POSTEL@USC-ISIF
    The draft specification i have seen is called "CCITT Draft Recommendations
    on Message Handling" and dated June 1983.  It was assembled by Ian Cunningham
    of BNR.

    --jon.
    -------
How does one get a copy of this?

Date: 17 Nov 1983 17:02:17 PST
From: POSTEL@USC-ISIF
Subject: re: Getting It Right Next Time
To:   header-people@MIT-MC


; Accessing NICNAME server at SRI-NIC...

White, James E. (Jim) (JEW)                               White@PARC-MAXC
   Xerox Corporation
   Systems Development Department
   3333 Coyote Hill Road
   Palo Alto, California 94304
   Phone: (415) 494-4760
@
; Accessing NICNAME server at SRI-NIC...

Cunningham, Ian (IC)                               CUNNINGHAM@BBNC
   Bell Northern Research, Ltd.
   P.O. Box 3511, Station C
   Ottawa, Ontario K1Y 4H7
   CANADA
   Phone: (613) 596-4234
@
--jon.
-------

Date: 17 Nov 1983 18:27:26 PST
From: POSTEL@USC-ISIF
Subject: re: Getting It Right Next Time
To:   header-people@MIT-MC

Date: 17 Nov 83 17:58:58 PST (Thursday)
From: White.PA@PARC-MAXC.ARPA
Subject: CCITT Recommendations on Message Handling
To: POSTEL@USC-ISIF.ARPA

Jon,  FYI, the final drafts of the eight CCITT Recommendations on
message handling systems were completed at a meeting in Brighton which
ended 4 November. A one-year approval process within CCITT has already
begun, and the specifications will become standards in October 1984.
Meanwhile, a number of implementations are already well along and will
be communicating with one another before October.

The documents are in reproduction now and will be available about 28
November.  I am willing to make hardcopy sets available to interested
parties who supply me with their mailing address via Arpanet mail.

Regards. /Jim
-------

Date:           Fri, 18 Nov 83 00:39:41 PST
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        No periods in unquoted full names, eh?

Well, I suppose the issue of whether RFC822 should be modified to allow
periods in unquoted full names is now dead due to lack of sufficient
demand that it be changed.  Too bad, I say; hoorah, some others may say.

I wonder now, though:  Assuming that this is the way things are to be,
how are we going to get all those places out there that generate full
names with periods (but no quotes) to fall in line? In case no one's
noticed, there seem to be quite a few such places.  (For that matter,
my own mailer omits the quotes -- though I expect I'll fix that in the
next two or three weeks.)

Even if there aren't any instances of outright rebellion (places which
adamantly refuse to make the change on aesthetic or other grounds), I
would bet -- if I were a betting person, which I'm not -- that lots of
sites will simply not consider it worth the bother to change their mail-
ers.  This must seemingly result in one of the following things happen-
ing at each site which wants to conform to the standard exactly:

(1) Simply reject incoming mail that doesn't conform, with a nasty note
    telling the poor user to go lean on his local wizard to get his mail
    software up to spec.
(2) Make life very difficult for local users who try to reply to mail
    from sites that don't conform.
(3) Implement "permissive" header parsers that will understand and ac-
    cept periods in unquoted full names, following the old maxim of "be
    liberal in what you accept and conservative in what you send out".

I think (hope) that most people will reject option 1 as not doing anyone
any real good.  Hopefully, most people will also consider option 2 too
repressive and user-unfriendly as well.  But on the other hand, if
everyone implements #3, then what was the point in requiring the quotes
in the first place?

This is a dilemma we face every time a question like this comes up, and
I don't propose to have a solution to it.

Then, of course, once we get everyone's "From" lines in conformity with
the standard, we'll have to start working on people's "Date" lines.
Lots more messages go out with invalid "Date" lines than ever have full
names with periods and no quotes.  The biggest offending areas (how does
YOUR mailer rate?) are:

(1) Names of days and months spelled out in full (RFC822 demands that
    three-letter abbreviations be used exclusively).
(2) "1983" as the year (RFC822 allows only 2-digit years).
(3) Time of day as a four-digit number (RFC822 insists that there be a
    colon between the hour and the minute).
(4) Hyphen before the time zone (RFC822 forbids this, though constructs
    like 09:34PST without the space are apparently legal -- see the com-
    ment about white space at the top of page 12).

-- Rich <wales@UCLA-LOCUS>

Date: 18 Nov 83 06:31:01 CST (Fri)
From: solomon@wisc-crys (Marvin Solomon)
Subject: Whats wrong with RFC 822
Message-Id: <8311181231.AA06747@wisc-crys.ARPA>
Received: by wisc-crys.ARPA (3.327/3.7)
	id AA06747; 18 Nov 83 06:31:01 CST (Fri)
To: Header-People@mit-mc

I, for one, couldn't care less whether periods are allowed in full names,
but I still hope we might learn something from this exercise.  I think
the REAL problem RFC 822 is too much freedom.  As I understand the history,
RFC 733 was created to try to bring some semblence of order to a collection
of existing mail programs, and therefore had to allow a variety of syntaxes
to keep everyone interested.  RFC 822 was an attempt to "clean up" 733
with a minimum of changes.  I'm sorry Dave Crocker didn't go further in
cleaning.  For example, there are altogether too many allowed formats
for dates.  As to address syntax, there are 

Date: 18 Nov 83 08:05:45 CST (Fri)
From: solomon@wisc-crys (Marvin Solomon)
Subject: What's wrong with RFC 822
Message-Id: <8311181405.AA07117@wisc-crys.ARPA>
Received: by wisc-crys.ARPA (3.327/3.7)
	id AA07117; 18 Nov 83 08:05:45 CST (Fri)
To: header-people@mit-mc.ARPA

I, for one, couldn't care less whether periods are allowed in full
names, but I think that before dropping this issue, we should try to
learn something from it.  As I understand the history, RFC 733 was
created to bring some order to an informal standard represented by a
collection of existing mailers, and as such had to be rather permissive
to keep everyone happy.  RFC 822 was a modest attempt to clean up 733.
I wish Dave Crocker had gone a bit further in cleaning up.  For
example, there are altogether too many allowed formats for date.  As
for addresses, the REAL problem (as I see it) is that there are too
many ways of including what is essentially a comment.  The syntax of an
address is:

    mailbox     =  addr-spec                    ; simple address
             /  phrase route-addr               ; name & addr-spec
    addr-spec   =  local-part "@" domain        ; global address
    route-addr  =  "<" [route] addr-spec ">"

Unfortunately, a phrase and a local-part are almost identical, so a
top-down parser can't distinguish the two alternatives for mailbox.
You don't have to be an expert in parsing theory to understand the
problem.  If you start to read a mailbox from left to right, you don't
know whether you are reading the beginning of an addr-spec (which is a
very important thing) or a phrase (which is essentially a comment)
until you look unboundedly far to the right and see whether there is a
"<" somewhere.  The solution taken:  Banish a whole host of special
characters from phrases so that local-part and phrase can be treated
the same way and a parser doesn't have to make any decisions until it
sees whether there is a "<" or a "@".  Folding the definitions a bit,
we have

    mailbox = word ("." word)* "@" domain
                / word (word)* "<" stuff ">"

This can be made LL(1) (the formal version of top-down-parsable) by
rephasing it as

    mailbox         = word mailbox-tail
    mailbox-tail    = addr-spec-tail            /  route-addr-tail
    addr-spec-tail  = "." word addr-spec tail   /  "@" domain
    route-addr-tail = word route-addr-tail      /  "<" stuff ">"

A top-down parser has no problem deciding what to do since an addr-spec-tail
must start with a "." or a "@", whereas a route-addr-tail must start with
a word or a "<".

One change suggested in this discussion group was to eliminate the
distinction between phrase and local part altogether, giving

    mailbox              = phrase-or-local-part mailbox-tail
    phrase-or-local-part = word phrase-or-local-part 
                            /  "." phrase-or-local-part 
                            /  EMPTY
    mailbox-tail         = "@" domain   /  "<" stuff ">"

That gets rid of the problem with periods, but still banishes the rest
of "specials" from phrases and doesn't come to grips with the problem that
people want spaces to be significant in phrases but not in local-parts.

I can think of two other ways around the problem that have much to recommend
them.  One is to get rid of this funny kind of comment.  Make the syntax

    mailbox = local-part "@" domain  /  "<" stuff ">"

If you really want your full name somewhere, you can write

    From: (Alfred E. Neumann (the guy from MAD Magazine)) <neumann@SRI-NIC.ARPA>

or even
    
    From: <joe (@$1.98/lb., really a bargain) @ random-host.arpa>

The only problem with this suggestion is that a phrase is a special
kind of comment that is supposed to be left untouched by header mungers
and kept bound to the following route-addr (although, so far as I can
see, the spec doesn't really say that--it's more of a tradition).
Besides, if people were willing to put parentheses around full names,
they wouldn't be complaining about putting quotes around them.

Another attractive alternative is to abolish the "simple" kind of address
and always require angle-brackets:

    mailbox = phrase "<" stuff ">

The big advantage of this proposal is that now phrase can contain any
character except "<" .  Most of the addresses people are sending around
would be allowed as is.  It would also allow things like

    To: Mike O'Dell, Mike O'Brien [and various other mikes &c]
        <shared.mailbox@random-host.arpa>

Unfortunately, some "traditional" addresses become illegal.  The
spector of "upward compatibility" (also known as the "the-sins-of-the-
fathers-shall-be-visited-on-the-children-unto-the-seventh-generation"
phenomenon) rears its ugly head.

In the ideal world, a "mailbox" would be a property list, containing
the domain, a local part, perhaps a full name, and perhaps the
importance ("if you can't deliver to this guy, I won't be too upset")
or other info that pertains to this address rather than the message as
a whole.  I won't even try to suggest a syntax.  I think the NBS
standard does an excellent job by abandoning the silly notion that the
best syntax for machine processing and the best syntax for human
processing are the same.

One final gripe.  It would be very nice if the protocol spec had a
single, formal specification of syntax in a standard notation (such as
regular expressions for lexical syntax and BNF for context-free syntax)
instead of a mixture of BNF, regular expressions, ad-hoc notation, and
vague confusing English discussions about linear-white-space and
folding.  As an exercise, try to determine from RFC 822 exactly where
in the following line spaces may be added

    From:MarvinSolomon<solomon@wisc-crys.arpa>

Date: Friday, 18 November 1983 10:29:25-PST
To: solomon@Wisc-crys (Marvin Solomon)
Cc: header-people@Mit-mc.ARPA
Subject: Re: What's wrong with RFC 822
In-Reply-To: Your message of 18 Nov 83 08:05:45 CST (Fri).
             <8311181405.AA07117@wisc-crys.ARPA>
From: Brian Reid <reid@Glacier>

Right on, Marvin!
My opinion is that what's really wrong with RFC822 is that people
insist on treating it as a presentation standard and not a
transmission standard. I don't think there is any hope for the current
ARPAnet community getting this right; anybody who cares at all whether
the message file proper contains
	From: "Joe Q. Schmoe" <jqs@someplace>
or
	From: Joe Q. Schmoe <jqs@someplace>

is just on a different planet than the one I live on; my mail reading
program edits the headers before it shows them to me so that they look
like whatever I want. Unfortunately, the syntax of 822 messages is so
bizzarre that the mail-reader has a great deal of trouble parsing them
for me before it displays them. 

This is a variation on the sins-of-the-fathers-shall-be-visited
syndrome; back in the dark ages people used to read mail by printing
out the mail file with a "type" command, and so much of RFC822 is still
devoted to solving this non-problem of making the transmission form of
the message look "pretty" enough that people can just print the thing
directly rather than process it first. There is no longer any excuse
for not having a mail reading program smart enough to do this right,
but enough people have such dumb mail reading programs that this ghost
lingers on.

Brian


Date: 18 Nov 83 1430 PST
From: Gerald Neufeld <neufeld.ubc@Rand-Relay>
Return-Path: <neufeld%ubc.ubc@Rand-Relay>
Subject: A CCITT MHS implementation
Message-Id: 287:neufeld@ubc-vision
Received: by ubc-vision.CRNET (3.327/3.14)
	id AA00775; 18 Nov 83 14:30:43 PST (Fri)
To: <header-people@MIT-MC>
Via:  ubc; 18 Nov 83 15:33-PST

A number of people here are working on a CCITT Message Handling
System implementation. The system is currently being developed
on 4.1bsd and 4.1c. The work is well underway. We currently
have a working MTA (Message Transfer Agent) and UA (User Agent).

The current system is based on the June spec mentioned by Jon. 
As soon as we get the final spec from Jim we will be updating
the system based on the modifications made at Brighton.
 
The system uses all the CCITT protocols in the ISO model. Including
X.25, ISO transport class 0, Session (S.62) and the MHS protocols
themselves.

We have also built a gateway between these protocols and ARPA 822.
Hence, messages can pass back and forth between our domain and
CSNET/ARPA. Since CCITT is very open with the addressing 
structure we have adopted the ARPA address structure to facilitate
traffic between our domain and CSNET, ARPA, UUCP etc.
 
The hope is (although as yet not certain) that this system (called
EAN) will be used to interconnect Canadian universities, colleges
and research companies using Datapac (Canada's public X.25 net).
 
- Gerry

University of British Columbia
Dept. of Computer Science

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA13979; Fri, 18 Nov 83 22:53:25 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA12756; Fri, 18 Nov 83 22:53:41 pst
Date: Fri, 18 Nov 83 22:53:50 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311190653.AA00621@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA00621; Fri, 18 Nov 83 22:53:50 pst
To: header-people@mit-mc
Subject: Re: Errors-To Field


   From: wcwells@ucbopal.CC.Berkeley.ARPA (Bill Wells)
   Newsgroups: net.mail
   Subject: Re: Fix to Arpanet junk deluges (at gateway)
   Message-ID: <108@ucbopal.CC.Berkeley.ARPA>
   Date: Fri, 18-Nov-83 22:32:34 PST
   Posted: Fri Nov 18 22:32:34 1983
   Organization: Univ. of Calif., Berkeley CA USA
   Lines: 6

   My apologies to Dr. Jon Postel at the USC Information Science
   Institute. Twice in the same paragraph I miss-spelt his name.
   The correct spelling is POSTEL not POSTAL.

   Bill Wells, U.C. Berkeley


Received: by UCB-VAX.ARPA (4.21/4.15)
	id AA24237; Sat, 19 Nov 83 08:08:12 pst
Date: 19 Nov 83 09:45:04 EST (Sat)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: Rudy Nedved on mail forwarding
Message-Id: <8311191445.AA05064@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA05064; 19 Nov 83 09:45:04 EST (Sat)
To: header-people@mit-mc.ARPA
Cc: Rudy.Nedved@CMU-CS-A.ARPA

Thanks for clearing up the misunderstanding, Rudy.  I guess the point I
wanted to make (in between the flames) was that I am opposed to a whole
network (such as the ARPANET) making a network-wide policy decision that
says they refuse to forward mail (even junk mail) when as a network they
are technically able to do so.  I think this decision should be left up
to the individual sites, since it is those sites that incur the expense
of forwarding.  (Of course, security considerations on a network such as
MILNET are another story, but even they can probalby forward mail if they
wish to.)  It seems that very few UUCP sites refuse to forward mail, in
spite of the expense.

	Mark

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA06598; Sun, 20 Nov 83 02:08:33 pst
Received: from ucbopal.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA29883; Sun, 20 Nov 83 02:08:47 pst
Date: Sun, 20 Nov 83 02:08:53 pst
From: wcwells%ucbopal.CC@Berkeley (Bill Wells)
Message-Id: <8311201008.AA14441@ucbopal.CC.Berkeley.ARPA>
Received: by ucbopal.CC.Berkeley.ARPA
	(4.11/4.8) id AA14441; Sun, 20 Nov 83 02:08:53 pst
To: header-people@mit-mc
Subject: Re: Precedence and Errors


In reply to:

   ------------------------------------------------------------------
   Date: 17 November 1983  01:06-PST (Thursday)
   Sender: TLI@USC-ECLB
   From: Tony Li <Tli@Usc>
   To: Header-people@mit-mc
   Cc: Wcwells@BERKELEY
   Subject: Re: Precedence and Errors
   Reply-To: Tli @ Usc-Eclb
   ------------------------------------------------------------------

I do not think error handling should be based on the content or
type of message.  It would be better to let the sender specify
the type of error handling desired.

Looking at it from the top, down, I also think SMTP needs a command
to pass many different types of transmission and message handling
instructions. (My suggestion for doing this is at the end of this
message.)

Here are my comments and suggestions in detail:

   ------------------------------------------------------------------
   Let me put up some ideas for you to kick around regarding
   'Precedence:' and error handling.  I'm trying to approach this as a
   top-down design problem, and so I'm trying to figure out what user
   services we should be providing within SMTP.  So, for the user
   level, we could have:

   Precedence: Priority
   or	    Personal
   or	    Mailing-List
   or	    Bulk

   The semantics of all of these should be obvious.  If not, then I
   obviously haven't done enough thinking about the keywords.
   ------------------------------------------------------------------
   
I think we should "unbundle" this. I see four separate issues here:

	a. Services provided to users, eg.
	
		(1) Local services for different types
		of messages:

			Narrative messages
			Proforma messages
			Data-pattern messages

		(2) Mail distribution services

			Mailing list distribution
			Network news services
			Computer bulletin board services

	b. Speed of service
	
		(1) Order of message handing based on Precedence
		independent of the content of the message or
		mail service requested.

		(2) Should large routine messages be held until
		network(s) are not heavily loaded?

	c. Error handling based on content or service requested
	   (or the wider issue of Communication Service Actions)

I think we are going to have to leave "Precedence" as it is defined by
the US Govt.  "Precedence" could then be used to handle host and
network loading problems. It would also permit MINIMIZE to be applied
to mail services on the MILNET. (MINIMIZE is a procedure where users
are restricted from sending routine messages when a communications
network (or circuit) is overloaded or expected to be overloaded.)

With regards to:

	Precedence: Priority
	or	    Personal
	or	    Mailing-List
	or	    Bulk

I think the following would be more acceptable to DCA:

	Precedence	Type of message

	ECP		Operational messages
	FLASH
	IMMEDIATE

	PRIORITY	Operational, administrative, and personal messages
	ROUTINE

with non-government and government administrative/research networks
and/or hosts limited to sending ROUTINE and PRIORITY messages.
We could further break down ROUTINE and PRIORITY into:

	Precedence	Size of message

	PRIORITY	Small messages only

	ROUTINE		Small messages
			Large messages (Bulk messages)

but I do not think that speed of service should be based on the size of
a message in addition to precedence in SMTP. However some local
networks that are heavily loaded or have slow transmission channels may
want to do this locally. (The Berknet, a non-packet network at UC
Berkeley holds files larger than 200,000 characters for relay after
midnight.)

I have left out "mailing list" because it just complicates the issue
and I have another solution for ensuring "mailing list" address errors
go back to the mailing list maintainer.  Mailing lists would not be a
problem if the original message is quoted in the text of a new message
(with a new RFC 822 heading) when it is forwarded to the list. Then
errors would go back to the sender of the new message (the list
maintainer), not the sender of the original message. That is to say,
mailing list distribution should be an user agent service, not a mail
transport agent service.

   ------------------------------------------------------------------
   I don't really like the keyword 'Precedence' but I don't have any
   better suggestions yet.  I like the suggestion of 'CLAS' even less.
   ------------------------------------------------------------------

I agree with you that Precedence and CLAS are not good choses.
Is "Message Content" the term you want?

   ------------------------------------------------------------------
   I think that the mapping of these precedence levels onto the IP
   Precedence field is irrelevant.  I get the idea that the precedence
   field in SMTP should be exclusively for the use of the mailers, and
   that the IP Precedence field is for dealing with packets in
   general.  How this mapping occurs is up to the source mailer.
   ------------------------------------------------------------------

If they are exclusive, how does a user request a higher speed of
service?  Are you saying SMTP should have only one precedence? I think
that would defeat the purpose of the Precedence system. Do you expect
a mail program at the user level to pass the precedence directly to
the packet level? I don't (maybe for a single user system, but not
multi-user systems). It is more likely that the user level
program will be putting messages on a SMTP input spool so that
the SMTP mail agent program can handle them in turn.
---- Maybe I am miss-reading you here. Are you saying we don't
need a precedence system at the mail transport level. There are
several reasons why I think we should, the most importantant
being improved speed of service for high precedence messages
when there are heavy message traffic loads.

   ------------------------------------------------------------------
   As to error handling, I would like to see the error handling for a
   particular message be totally divorced from all other parameters of
   the message.  This might result in something like:

   Error-messages-on : All-Errors
   or		    Fatal-Errors
   or		    No-Errors

   This is intended to provide a modicum of flexibility without being
   impossible to implement.
   ------------------------------------------------------------------

Let's make it more flexibility and let the sender specify if error
messages are desired.  That is simple compared to trying to support
different levels of error handling based on the content or size of
a message.

Now, that brings up the problem of not having a generalized procedure
in SMTP for passing transmission instructions or message handling
instructions. Transmission instructions are communication instructions
or advisory information that are of concern to relaying mail transport
agents and may or may not be passed on to the user agent recipient of
the message (cf. format line 4 of a military message). Message handling
instructions are communication instructions or advisory information
that are passed on to the user agent (cf. format line 5 of a military
message).

Here are some examples of transmission instructions and message handling
instructions that are used with military message:

	This message is a suspected duplicate.

	Do not forward this message on non-cryptographic-protected
	circuits.

	This message is being retransmitted in response to
	your request for retransmission.

	This high precedence message was received garbled.
	A good copy has been requested and will be forwarded
	when received.

	This is a book message. Other addresses may be omitted
	from heading when relaying this message to another
	network.

	Cancel this message at _____. (You can stop attempting
	to relay this message after _____.)
	
There are several hundred operating signals that may be used
with military messages as abbreviations for communication
instructions and advisories. I suspect that MILNET users are
going to want to have many of them supported by, or at least
passed on by SMTP. Rather that coming up with a separate SMTP
command for each, let's define a single command, eg.

	INST <sp> <string> <CRLF>

Then define the common set of INST "strings" (and appropriate responses)
that are required or optional for SMTP. Other "strings" should be
permitted and passed on to the recipient of the message unchanged
by relaying SMTP mail transport agents.

For MILNET, I think we will need to define a PREC command for Precedence
(as defined by the US Govt.) and CLAS for information security
classification (as defined by the US Govt.). But those are issues
that should be discussed separately.

Comments?

Bill Wells, U.C. Berkeley
wcwells@Berkeley.ARPA


Date:     Mon, 21 Nov 83 13:35:52 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Mark Horton <cbosgd!mark@ucb-vax>
cc:       header-people@mit-mc.arpa, Rudy.Nedved@cmu-cs-a.arpa
Subject:  Re:  Rudy Nedved on mail forwarding

Let me point out, that despite what ARPANET (and MILNET) has become,
they enjoy some operating benefits that are legally unavailable to
commercial telecommunications and computer services.  This is THE
major reason for the anti-commercial restriction on these nets for
it has always been stated in the first few lines of every ARPANet
policy statement that the net is not to be used to compete with
comparable commercial service.

Second policy is that the network must be used solely for the conduct
of or in support of official U.S. Government business.  This is a
wide area.  All the discussions about things like Apple computers
are in support of the US Gov. because (unfortunately maybe?) the
government has bought a lot of Apple computers.

DCA has left it up to the host administrators at each site to protect
the network with "adequate" access control procedures.  In this case
you are right, let the host administrators determine what level of
interaction he wants to support, but it is not just a question of
what money he is paying for his network service.


-Ron

Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.21/4.15)
	id AA00164; Fri, 25 Nov 83 18:58:08 pst
Received: from ucbtopaz.CC.Berkeley.ARPA by ucbpopuli.CC.Berkeley.ARPA
	(4.11/4.8) id AA12978; Fri, 25 Nov 83 18:58:48 pst
Date: Fri, 25 Nov 83 18:58:46 pst
From: usenet%ucbtopaz.CC@Berkeley (Users' Network)
Message-Id: <8311260258.AA00669@ucbtopaz.CC.Berkeley.ARPA>
Received: by ucbtopaz.CC.Berkeley.ARPA
	(4.11/4.8) id AA00669; Fri, 25 Nov 83 18:58:46 pst
To: header-people@mit-mc
Subject: UUCP Net Information
Cc: consult%ucbtopaz.CC@Berkeley, wcwells%ucbtopaz.CC@Berkeley


It looks like a few people in UUCP net land are trying to make order
out of chaos.  The following from the USENET news group "net.mail" is
forwarded for information.

   
   Path: decvax!harpo!floyd!clyde!ihnp4!inuxc!pur-ee!uiucdcs!
	parsec!kolstad
   From: kolstad@parsec.UUCP
   Newsgroups: net.mail
   Subject: High Quality Routing Database - (nf)
   Message-ID: <4076@uiucdcs.UUCP>
   Date: Tue, 22-Nov-83 19:45:54 PST
   Article-I.D.: uiucdcs.4076
   Posted: Tue Nov 22 19:45:54 1983
   Lines: 25

#N:parsec:37900002:000:1051
parsec!kolstad    Nov 22 14:35:00 1983

Some of us are making the first big pass on our project to collect
accurate routing and site information on the 1600+ sites connected
by the UUCP network (which includes but is not limited to USENET,
the 650+ news network).  

Within the month, all site directors (or root at sites with unknown-to-us
site directors) will receive a mechanically generated form letter with
a cybernetic plea for information.  Response is entirely voluntary.
An accurate database will allow routers to make reasonable decisions
about sending mail and other goodies.

The current plan includes myself (parsec!kolstad) and Scott Bradner
(wjh12!sob) who will be editing the returned form letters into the
database.  This database will then (with high probability) be handed
off to the network database support group for the infinite time consuming
job of maintenance.

The information you recieve for editing will include everything our
database currently knows about your site.  We hope everyone will benefit
by any data you wish to disclose.

Thanks in advance...				Rob

Date:     Tue, 29 Nov 83 7:58:15 EST
From:     R. Bruce Natalie (CTAB) <rbn@brl-vgr>
To:       postel@usc-isif
cc:       header-people@mit-mc, postmaster@hi-multics
Subject:  MULTICS MAIL MESSAGES


Once again I find 72 failed mail messages from some cryptic user
in MULTICS land and once more I get 72 more unidentified flying
letters.  Forwarded message number one is the failed mail message
from MULTICS.  Note the non-compliance with RFC822 as there is no
destination line (in the form of TO, CC, or BCC) and no date.  Note
also the obsolete "at" in the from line.  Other multics sites not on
the ARPANET directly also place illegal host names in their from lines.
The message is sketchy to say the least ("unable to deliver mail") and
it may be amusing to discover that the letter was sent to "EATON.HFED@
HI-MULTICS" which is not easily ascertained by the misplaced "TO" line.

The second forwarded message is a copy of the original letter reflected
back along the return path to the sender.  Note that there is no indication
in that letter as to why it is being delivered to the user.  The RECEIVED
lines at the top are the only indication as to what is going on.  It takes
carefull inspection of these letters to figure out where they are coming
from.  I feel while this is perhaps not an explicitly prohibitted action,
it is not a good idea.

I have communicated with the Multics sites several times with respect to
these problems but nothing has happened.

Looking for a solution...
-Ron

----- Forwarded message # 1:

Received: From Hi-Multics.ARPA by BRL-VGR via smtp;  29 Nov 83 6:57 EST
From: Network_Server.Daemon at HI-MULTICS.ARPA
Subject: Unable to deliver mail from info-micro-request@BRL-VGR.ARPA@BRL-VGR

Message will be returned under separate cover.
To: >udd>HFED>Eaton>Eaton.mbx at HI-MULTICS.ARPA: 

----- Forwarded message # 2:

Received: From Hi-Multics.ARPA by BRL-VGR via smtp;  29 Nov 83 6:57 EST
Received: from BRL-VGR by HI-MULTICS.ARPA TCP; 29-Nov-1983 05:57:45-cst
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  29 Nov 83 6:09 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  29 Nov 83 4:36 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Nov 83 1:10-PST
Date: 27 Nov 83 15:47:17-PST (Sun)
To: info-micro@brl
From: decvax!ittvax!dcdwest!sdcsvax!sdccsu3!brian@ucb-vax
Subject: Re: ss vice ds disks
Article-I.D.: sdccsu3.1327
In-Reply-To: Article <13926@sri-arpa.UUCP>

The reason the index hole is in a different place for SS and DS 8" disks
is so that the drive hardware can report to the controller whether there
is a single sided or double sided disk in the drive.  Since most if not
all of the popular 8" computers retain compatability with IBM 3740
format, this can assist the disk controller software in making a more
intelligent decision.  Some cp/m bios don't even ask what kind of a disk
is in the drive - the make the proper settings based on an identity
sector and the single/double hardware indication (Jade DD is an
example of this).  Sure is convenient!

--
          -Brian Kantor, UC San Diego
          {decvax,ucbvax} !sdcsvax!sdccsu3!brian
          Kantor@Nosc

----- End of forwarded messages

Date:  29 November 1983 09:30 cst
From:  RLee.SysAdmin at HI-MULTICS
Subject:  Re: MULTICS MAIL MESSAGES
To:  R. Bruce Natalie <rbn at BRL-VGR> (CTAB)
cc:  postel at USC-ISIF, header-people at MIT-MC
In-Reply-To:  Message of 29 November 1983 08:12 cst from R. Bruce Natalie

The problem is known to the Multics developers and will be corrected in
the next release.  Until I receive that release, there is not a lot I
can do about the problem.

--Randy Lee (Liaison/Postmaster@HI-Multics.ARPA)

Date:  Tuesday, 29 November 1983 15:16 est
From:  Kovalcik@MIT-MULTICS.ARPA (Rick Kovalcik)
Subject:  Re: MULTICS MAIL MESSAGES
To:  R. Bruce Natalie <rbn@BRL-VGR.ARPA> (CTAB)
cc:  postel@USC-ISIF.ARPA, header-people@MIT-MC.ARPA, 
     postmaster@HI-MULTICS.ARPA, Kovalcik@MIT-MULTICS.ARPA
In-Reply-To:  Message of 29 November 1983 07:58 est from "R. Bruce Natalie"
Message-ID:  <831129201627.544190@MIT-MULTICS.ARPA>

Ron,

I am getting really tired of this.  In a piece of mail sent 10/26/83 to
you and a couple of other people I said:

Various mailers behave in different ways.  The Multics mailer currently
returns failed mail in two parts.  The BRL mailer mungs headers.  I find
the later much more objectionable.  As soon as CISL comes back on the
ARPANET you will see that the CISL mailer is now returning failed mail
in one piece ((and in valid RFC822 format.  I forgot to mention that at
the time.  By now this has all happened.))  Other Multics mailers will
probably pick ((it)) up eventually.  Now if the BRL mailer was only made
to work I would be happy.

(( )) indicate comments by me today, 11/29/83.

As the above demonstrates (I will forward the complete mail if anyone
cares), you have been told that we are fixing the problem (two messages
returned) even though it is a matter of taste.  I neglected to mention
that we were fixing the format of the message at the time. If you really
cared, you could have sent me another message back asking what we were
doing about the format.  Or you could have asked the various sites when
they would be installing the new mailer.  You did not reply.  This leads
me to believe that you are more interested in causing trouble than
fixing problems.

Please start acting in a responsible manner and get off of this
out-to-get-Multics kick.  It is really annoying and a waste of our time.

-Rick Kovalcik, Honeywell, Cambridge, MA, Kovalcik -at MIT-Multics,
617-492-9300, Liaison CISL-SERVICE-MULTICS, part of Postmaster
CISL-SERVICE-MULTICS, HIS-PHOENIX-MULTICS, HIS-BILLERICA-MULTICS

Date:     Wed, 30 Nov 83 15:32:37 EST
From:     Ron Natalie <ron@brl-vgr>
To:       Rick Kovalcik <Kovalcik@mit-multics.arpa>
cc:       Header-People@mit-mc
Subject:  Re:  MULTICS MAIL MESSAGES

I sorry if Rick was offended, but it has been a while since the bugs
were promissed to be fixed and they are still happening.  I also have
been informing individual users when illegal formatted messages have
been coming out and I believe I have also been notifying the corresponding
postmasters.  I am content to wait for the new version but you'll
have to excuse my impatient when my mail reader explodes with 72 illegally
formatted messages (it really is a pain).

With respect to BRL's mailer (which is MMDF), the only thing it is really
guilty of is getting confused by illegal addresses.  I'm not going to argue
the virtues, but am just describing the way it is for the other recipients
of the message as Rick made a passing shot about it.  Since the mailer is
multichannel (the is the first M in MMDF) it can receive mail from a number
of paths (SMTP, PHONENET, UUCP, and others to humerous to mention).  It makes
the rather bad assumption when relaying a message back out on the arpanet that
if a letter was received at BRL with a illegal arpanet address it must be
from some channel that BRL knows how to talk to.  It therefore translates
FOO@UNKNOWN-HOST to FOO%UNKNOWN-HOST@BRL.  Works most of the time but
really gets things messed up if we didn't know how to talk to UNKNOWN-HOST
at all.  Remember, the only think we changed in the headers were the FROM
lines when they illegal to begin with.  The mailer felt a moral obligation
not to retransmit illegal addresses so it made them legal (yes, but incorrect).
Hopefully this whole problem will go away when DOMAINS get nailed down and
people like the MULTICS community, the UUCP Community, the BRL community,
etc...will have defined methods of answering inter-community mail.

I have nothing against MULTICS, we've always stolen some great ideas for
our other operating systems from there.

-Ron

Date:     Wed, 30 Nov 83 16:35:41 EST
From:     Ron Natalie <ron@brl-vgr>
To:       header-people@mit-mc
Subject:  TWO mail points to consider.

I have two problems that have been mentioned before on this list sporadically,
but would like to hear about again and possibly see some proposals for RFC's or
ideas to be incorporated into an RFC on crossnetwork mail relaying.

	1.  When a header is recieved that is in illegal format (according
	    to 822) but deliverable to another site (as the relay can determine
	    who it is addressed to despite the noncompliance with 822), should
	    the relaying host attempt to correct it to make it legal?  The
	    other options is to just forwarded the letter verbatim or to add
	    additional header lines to help ease problems with processing
            the illegal headers.  Or do your sites just drop these letters?
	    (FORMAT CONVERSION)

	2.  Do relaying sites have an obligation to transform the addresses
	    in a header when crossing mail systems boundries to those that
	    are legal on the destination network?  For example, should:

		FROM:  MANNY@BARFNET-HOST
		TO:  	MOE@APRA-HOST

	    relayed through the host BARF-ARPA be changed to something
	    like:

		FROM:  MANNY%BARFNET-HOST@BARF-ARPA
		TO: MOE@ARPA-HOST

	    Or should it just hope that if the user really wanted to
	    get a response from MOE that he either did his from line
	    in ARPANET relative terms or MOE is smart enough to know
	    how to route to BARFNET-HOST.

-Ron

Date: Sun 4 Dec 83 20:24:51-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
Subject: where is btl
To: header-people@MIT-MC.ARPA

Which UUCP host do you arrive at when you send mail to

<uucp-address>.btl@csnet-relay?  (in other words, which uucp node is
btl?)

--greg
...decvax!genrad!mit-eddie!gds (uucp)
gds@mit-xx (arpa)
-------

Date: 8 Dec 1983 15:22-EST
Sender: MOOERS@BBNA
Subject: The groupname "NAME: ;"
From: MOOERS@BBNA
To: header-people@MIT-MC
Cc: DODDS%SCRC-TENEX@MIT-MC, BILLW@SRI-CSL
Cc: Sarvela@SRI-KL, Mooers@BBNA
Message-ID: <[BBNA] 8-Dec-83 15:22:38.MOOERS>

Messages from some groups -- the FORTH interest group is an
example -- have been appearing with a groupname of the form:

		To: Name: ;

On pages 26 and 44, RFC 822 specifies the syntax for "group" as

		group  =  phrase ":" [#mailbox] ";"

and on page 31, RFC 822 gives the example

		name:;

The Hermes message system can handle "name:;" with no problems,
but cannot select on "name: ;".  With the clear documentation in
RFC 822, we did not anticipate that the standard would be
interpreted to produce such a string, with a space between the
":" and ";".

May we respectfully suggest that whoever is producing those
groupnames modify them to conform to "name:;" ?

Thank you for your help.

---Charlotte Mooers
   Hermes staff
   Bolt Beranek and Newman, Inc.

Date: 08 Dec 83 18:59:06 PST (Thu)
From: Marshall Rose <mrose.uci-750a@Rand-Relay>
Return-Path: <Mrose%uci-750a.UCI@Rand-Relay>
Subject: Re: The groupname "NAME: ;"
Message-Id: <267.439786746@uci-750a>
To: MOOERS@Bbna
Cc: header-people@Mit-Mc, DODDS%SCRC-TENEX@Mit-Mc, BILLW@Sri-Csl,
        Sarvela@Sri-Kl
In-Reply-To: Your message of 8 Dec 1983 15:22-EST.
	     <[BBNA] 8-Dec-83 15:22:38.MOOERS>
Via:  UCI; 8 Dec 83 23:12-PST

Well, since UCI is such an offending site, I should respond:

    Perhaps I've mis-read the 822 spec, but it doesn't say that

	name: ;

    is illegal, quite the contrary.  At several points in the standard
    (e.g., "3.4.2 WHITE SPACE") the use of white space is discussed.
    With the exception of forbidding space between "."/"@" and a <word>
    in a structured component, the 822 spec does not prohibit the
    practice of using white space between the ":" and ";".  The problem
    with your interpretation of

		group  =  phrase ":" [#mailbox] ";"

    meaning NO SPACE BETWEEN ":" and ";" is that, one should also
    interpret

		orig-date = "Date" ":" date-time

    as meaning NO SPACE BETWEEN the ":" and the date-time string.  I
    think we can agree that this isn't what the standard means.  [If it
    is, we are all it a LOT of trouble... :-)]

/mtr

