Date: 12 May 1983 2217-PDT
From: POSTEL at USC-ISIF
Subject: Errors-To, round 2
To:   header-people at MIT-MC



Here are some remarks in response (and i hope responsive to) the comments
on my suggestion for an "Errors-To:" header field.

The most often mention concern was the appropriate placement of this type
of function in the "envelope" vs in the "message", and the question of the
relationship of this proposed header field and the SMTP MAIL FROM command
(and its resulting Return-Path: field).

Lets look at the existing SMTP mechanism that seems like it might
do the job i suggested for Errors-To.  This is the information passed from
mailer to mailer in the SMTP MAIL FROM command.  This information is recorded
in the delivered message as the Return-Path: field.  This information is 
intended as an audit trail of where the message actually went.  This is
also used by mailers to send error reports back when things go wrong with
message delivery.  So indeed, this SMTP MAIL FROM information could be used to
provide the function of sending error reports to the proper place.

However, we have to decide what the proper implementation of this information
is for the case of a mail exploder like Header-People.  There are two views:
(1) that there are two separate mail transactions - (a) the author sends a
message to the exploder, and (b) the exploder send the message to the list;
and (2) there is one transaction - the author send the message to the list
via the exploder mailer as a relay.

In the first case, we would have in the first transaction a path back to the
author, but in the second transaction a path bact to the exploder (perhaps
even the list maintainer).  In the second case we would have a path back to
the author via the exploder host.

If the implementation were required to be the first case, there might not be
any call for any other mechanism such as the suggested Errors-To.  The
current implementation of the exploder function on MIT-MC is the second case.

I suggest that we seriously consider requiring the two transaction model.
Comments on this?

There is another example for the potential use of Errors-To that might
not be properly handled by using the SMTP MAIL FROM information.

There is an application level service that uses computer mail to interact with
its customers.  That is, there is a program that takes its input from incoming
mail and produces as output outgoing mail.  It would really like to have
reports of delivery errors in its outgoing mail sent to a different mailbox
than its primary input mailbox.

For example, lets call the primary mailbox of the application APPSRV, and the
mailbox for error reports APPERR.  Users of the application send mail to
APPSRV and may in the content of the message give information that causes
the application to try to send mail to an arbitrary mailbox (perhaps one
different from any indicated in the header of the input message).  When the
application sends the message it is appropriate for it to be from APPSRV
and if the mail is delivered sucessfully replies should be sent to APPSRV,
but if something goes wrong it would be best if the error reports went to
APPERR.

It is not at all clear how the application as an ordinary user of the mail
system can influence the error reports to go to a special error reports
mailbox.  Since the SMTP MAIL FROM information is an audit trail, it does
not seem appropriate to fudge the apparent starting point to be APPERR.

We ought, also, to consider the larger world where mail procedures other than
SMTP are used, but do use headers at least similar to the 822 headers.  In
this world there are also mailing lists and the possibility that error reports
should be sent to other than the author of a message.

There were some suggestions that while "Errors-To" was a nice idea, it was
a pretty small one, and there were lots of other factors that should be
considered.  That is, the notion should be generalized.

Fine.  There is room for many proposals for features in the context of the
current mail rules.  One does need to be careful of syntax and parsing though.
Suggestions that have lots of keywords and parameters that can occur in many
combinations don't fit well with the current syntax rules.

It was mention that if Error-To is accepted as the way
to do this, it should be clear that if there is an error and there is no 
Errors-To the report goes to the author (From:).

If my suggestion that the mailing list exploder insert the Errors-To field
in the message is followed, there is a question about what happens if there
is already an Errors-To field?  Does the program inserting an Errors-To have
to search the header to see if there is one already, and (a) not insert its
own if there is, or (b) delete the existing one and replace it with a new one.
Or, does the program just blindly add a new Errors-To?  And if there is an
error and there are multiple Errors-To fields which one is used to report the
error? The first one found?  All this would have to be specified in detail.

For this discussion i would like to focus on the functionality of what i
have suggested, and the issue of doing the job at the SMTP MAIL FROM level
of the Errors-To header field level.

--jon.

-------

Date: 13-May-83 00:02 PDT
From: RICH.GVT@OFFICE-3
Subject: Re: Errors-To ???
To: POSTEL@USC-ISIF
Cc: header-people@MIT-MC
Message-ID: <[OFFICE-3]GVT-RICH-2E7BF>
In-reply-to: EXT-POSTEL-2E6NV

I thought the Return-Path was supposed to fulfill exactly that function; am I 
wrong?
-Rich


Date: Fri 13 May 83 23:57:55-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Errors-To, round 2
To: POSTEL@USC-ISIF.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "POSTEL at USC-ISIF" of Thu 12 May 83 22:17:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     With some greater thought on my part, I am now opposed to
the idea of an Errors-To header line, and greatly supportive of
an SMTP enhancement that implements this functionality.  In other
words, something like:
	MAIL FROM:<jones@foo>
	ERRS TO:<foo-maintainer@foo>
	RCPT TO:<foo-people@foo>
Of course, SMTP senders must be prepared to receive 500 errors
from various SMTP receivers, since nobody presently implements
this.

     It is then up to the SMTP sender to properly specify this.

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

Date: 14 May 83 19:54:59 MDT (Sat)
From: lepreau@utah-cs (Jay Lepreau)
Subject: Re: Errors-To, round 2
Message-Id: <8305150154.AA12556@UTAH-CS.ARPA>
Received: by UTAH-CS.ARPA (3.320.6/3.7.9)
	id AA12556; 14 May 83 19:54:59 MDT (Sat)
To: header-people@mit-mc

A problem with putting Errors-To strictly in the SMTP messages is that
it won't work over non-SMTP channels.  There are a lot of them in
the little-i-internet.

(It turns out that Eric Allman's sendmail has supported an Errors-To
header line for a long time.  And domains, and ....)

Date: Sat 14 May 83 19:30:41-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Errors-To, round 2
To: lepreau@UTAH-CS.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "lepreau@utah-cs (Jay Lepreau)" of Sat 14 May 83 19:54:59-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

My experience as a little-i-internet implementor is that the non-Internet
networks are either going to have totally cooperative individuals who will
go all out to assist internet mailing with Internet, or totally uncooperative
individuals who think they're completely right and the rest of the universe
is wrong.  In some cases, you have both.

What I am trying to say that if the Errors-To functionality is useful enough
for the non-Internet implementors to do something about it, they'll create
some means to send it out of band of the message header, just as I'm
proposing would be done with SMTP.  If not, they won't teach their mailers
to parse Errors-To in the header.

Because of this, I don't think this is a problem.  It is much easier (and
more reliable) for my internet mailer to use the Errors-To information in
a transaction if it received it in the message transport instead of having
to parse a message header.  We on Internet should do things right.  Our
responsibility to internet is not to preclude internet mailing; and in this
our weakest point is that we have no way of having absolute internet addresses
that are acceptable to Internet.

The cleaner and more robust our protocols, the better our arguments for
convincing non-Internet networks to use them.  I know of several DECnets
which are going over to use SMTP layered over DECnet, simply because SMTP
is better.
-------

Received: from Sierra by SCORE with Pup; Sat 14 May 83 20:09:04-PDT
Date: 14 May 1983  20:04 PDT (Sat)
From: David Eppstein <Kronj@Sierra>
To:   Header-People@MIT-MC
Subject: Errors-to:

I think it is better to have a SMTP command for this functionality
than to keep it in the message headers.  This would most likely be
easier for most SMTP-based mail systems to deal with.  Also, it makes
it easier to have multiple error-to recipients.  Suppose mail comes in
to MIT-MC for List@MC and AnotherList@MC.  MC notices that in List@MC
there is a recipient Foo@Score and in AnotherList there is recipient
Bar@Score.  The mailer wants errors for Foo to go to List-Request and
Bar to go to AnotherList-Wizards.  It could accomplish this using
Errors-to: by building two different sets of headers and delivering
the message twice to Score, once for Foo with Errors-to: List-Request
and the other time to Bar.  If error disposition were handled in SMTP
the whole thing might be done in one transaction, as
	...
	ERRS TO:<List-Request@MIT-MC.ARPA>
	RCPT TO:<Foo@SU-SCORE.ARPA>
	ERRS TO:<AnotherList-Wizards@MIT-MC.ARPA>
	RCPT TO:<Bar@SU-SCORE.ARPA>
	...

If there were recipients with no explicit error handler address after
the mailing lists the sending mailer should probably do another ERRS
with the original sender as argument.

Of course, this causes problems for mail forwarding to non-arpa sites.
One possible solution to this would be to also support Errors-to:
header fields.  Presumably SMTP error dispositions would override
anything in the message headers.
					David

Date:     Sat, 14 May 83 12:16:25 CDT
From: David.Chase <rbbb.rice@Rand-Relay>
Return-Path: <rbbb%Rice.Rice@Rand-Relay>
Subject:  Amused, or disgusted??
To: header-people@mit-mc
Message-Id:  <1983.05.14.12.16.25.350.00129@dione.rice>
Via:  Rice; 14 May 83 23:31-PDT

Thought you might be interested:

------------------------------------------------------------------------------
Date: 13 May 83 08:18:46 PDT (Fri)
From: fateman%UCBKIM@Berkeley
Return-Path: <CC.PADGETT@UTEXAS-20>
Received: from UTEXAS-20 by UTEXAS-20; Fri 13 May 83 17:08:06-CDT
Received: from UCBVAX by UTEXAS-20; Fri 13 May 83 10:40:34-CDT
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA05323; 13 May 83 08:18:46 PDT (Fri)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.339/3.28)
	id AA00474; 13 May 83 08:37:35 PDT (Fri)
Received: from UTEXAS-20 by rand-relay.ARPA ; 13 May 83 16:06:20 PDT (Fri)
Subject: Re:  VAX Pictures? ?
Mail-From: CC.PADGETT created at 13-May-83 14:21:44
Return-Path: <fateman%UCBKIM@Berkeley>
Message-Id: <8305131518.5323@UCBKIM.ARPA>
To: CC.PADGETT@UTEXAS-20
Remailed-Date: 13 May 1983 1421-CDT
Remailed-From: Steve Padgett <CC.Padgett@UTEXAS-20>
Remailed-To: info-graphics@UTEXAS-20
Remailed-Date: 13 May 1983 1707-CDT
Remailed-From: Steve Padgett <CC.Padgett@UTEXAS-20>
Remailed-To: info-graphics@UTEXAS-20
Via:  UDel; 13 May 83 21:44-CDT

there are tools of this nature in use at Bell Labs that work with 
UNIX and TROFF.  There are picture-drawing tools at UC Berkeley,
but they produce separate pictures (which have to be pasted in).
------------------------------------------------------------------------------

Date: 15 May 1983 0707-PDT (Sunday)
From: mo@LBL-CSAM
Subject: Re: Errors-To and Sendmail
Return-Path: <mo@LBL-CSAM>
Message-Id: <8305151407.AA05300@LBL-CSAM.ARPA>
Received: by LBL-CSAM.ARPA (3.320/3.21)
	id AA05300; 15 May 83 07:07:24 PDT (Sun)
To: lepreau@utah-cs (Jay Lepreau)
Cc: header-people@mit-mc
In-Reply-To: Your message of 14 May 83 19:54:59 MDT (Sat).
             <8305150154.AA12556@UTAH-CS.ARPA>

Sendmail also tries to implement an automatic Errors-to: facility  
for mailing lists it supports.  It infers a standard destination
from the list title and checks the alias database to see if it is
defined.  If so, error indications regarding list delivery go
to that mailbox.
	-Mike

Date: 15 May 1983 0715-PDT (Sunday)
From: mo@LBL-CSAM
Subject: Re: Errors-To: Against out-of-band Errors-to:
Return-Path: <mo@LBL-CSAM>
Message-Id: <8305151415.AA05339@LBL-CSAM.ARPA>
Received: by LBL-CSAM.ARPA (3.320/3.21)
	id AA05339; 15 May 83 07:15:59 PDT (Sun)
To: Mark Crispin <MRC@SU-SCORE.ARPA>
Cc: header-people@MIT-MC.ARPA
In-Reply-To: Your message of Sat 14 May 83 19:30:41-PDT.
             <8305150239.AA01563@LBL-CSAM.ARPA>

But Mark, putting the Errors-to: information in the header is
one way we can help little-i-internet people do the right thing.

HOWEVER,
If we are going to FINALLY get religion about separation of
Church and State, er, Message and Envelope, then we need to
move a bunch of other stuff also.  Joe Sventek long ago suggested
an ENVELOPE command for SMTP wherein all the header-ish lines
(return-path:, hop-by-hop recieved: lines, other postmarks)
comprising the envelope would go across with the DATA/. subprotocol,
followed by a MESSAGE command for the body.  This would allow 
VERY useful facilities like end-to-end encryption of messages,
including "headers".  This has been a sore spot for a long time -
the current mail system is modelled more on "memos" than on "letters".
In fact, we could keep the current MAIL command for existing format
letters (mixed-mode message/envelope stuff) and add ENVELOPE and
MESSAGE commands (terminated by bare . lines) so people could
evaluate the new model.

	Yours for bigger and better bugs,
	-Mike

Date:     7 Apr 1977 1712-EST
From:     Bob Chansler at CMU-10A
Reply-To: Lord High Executier@CMU-10A
Subject:  Re: Close, but no cigar
To:       BRIAN.REID at CMU-10A
CC:       chansler@CMU-10A
Sender:   BOB.CHANSLER at CMU-10A
Message-ID: [CMU-10A]  7 Apr 1977 17:12:49 Bob Chansler
In-Reply-To: Your message of April 6, 1977
My-Seq-#: 39492094
Yr-Seq-#: 4992488
Class:    A
Subclass: MCMXLVII
Author:   fred
Typist:   fred
Terminal: TTY88
FE-L#:    44
Reason:   Did Godzilla need a reason?
Valid:    Not before 12 Apr 1977 1321Z
Suspend:  After 19 Apr 1977 0000Z
Spelling-errors-this-message:  0
Spelling-errors-to-date:  23
Weather:  Light rain, fog.
Forcast:  Clearing by morning
Psych-evaluation-of-sender:  slightly unstable
Security-level:  Public
Security-sublevel:  0
Authority-to-send:  general
Authority-to-rcv:  general
#-people-in-terminal-room:  12
XGP:      UP-cutter not working
Ht/Wt-sender:  76/205
Machines: M&Ms available but almond machine is empty
M&Ms-Last-Nickel:  17
Remailed-To: John.Zsarnay at CMU-10A
Remailed-From: Peter.Schwarz at CMU-10A
Remailed-Date: Saturday, 22 September 1979 0155-EDT
Origin:  C410PS20 at CMU-10A; 22 Sep 1979 0155-EDT
Remailed-To: Mike.Accetta at CMUA
Remailed-From: John.Zsarnay at CMU-10A (A650JZ04)
Remailed-Date: 22 September 1979 1615-EDT
Origin:  A650JZ04 at CMU-10A; 22 Sep 1979 1616-EDT
Remailed-To: Fil.Alleva at CMU-10A
Remailed-From: Mike Accetta <Mike.Accetta at CMU-10A> (A650MA33)
Remailed-Date: Saturday, 22 September 1979 2004-EDT
Via:     CMU-10A; 22 Sep 1979 2006-EDT
Remailed-To: Ken.Wertz at CMU-10B
Remailed-From: Fil.Alleva at CMU-10B (A650FA33)
Remailed-Date: Monday, 24 September 1979 1023-EDT
Via:     CMU-10B; 24 Sep 1979 1025-EDT
Remailed-To: Don.Provan at CMU-10A
Remailed-From: Krafty Ken Wertz <Ken.Wertz at CMU-10A>
Remailed-Date: Monday, 24 September 1979 1029-EDT
Origin:  C425KW0F at CMU-10A; 24 Sep 1979 1036-EDT
Remailed-To: Carolyn.Councill at CMU-10A
Remailed-From: don.provan at CMU-10A
Remailed-Date: Monday, 24 September 1979 1054-EDT
Origin:  C425DP0N at CMU-10A; 24 Sep 1979 1055-EDT
Remailed-To: Eddie.Caplan @ CMUA
Remailed-From: Carolyn.Councill at CMU-10A (C425CC33)
Remailed-Date: Monday, 24 September 1979 1631-EDT
Origin:  C425CC33 at CMU-10A; 24 Sep 1979 1632-EDT
Remailed-To: lawrence.butcher at CMU-10A
Remailed-From: eddie caplan <EC0F at CMU-10A>
Remailed-Date: 24 September 1979 1634-EDT
Origin:  C425EC0F at CMU-10A; 24 Sep 1979 1635-EDT
Remailed-To: Mike Kazar at CMU-10A, Craig Everhart at CMU-10A
Remailed-From: Lawrence Butcher at CMU-10A (X335LB50)
Remailed-Date: Tuesday, 25 September 1979 1811-EDT
Origin:  X335LB50 at CMU-10A; 25 Sep 1979 1812-EDT
Remailed-To: sipb @ mc
Remailed-From: Mike Kazar <Mike.Kazar at CMU-10A> (C410MK50)
Remailed-Date: Wednesday, 26 September 1979 0009-EDT

I do not understand your concern about the size of message headers.
-------


Date: Sun 15 May 83 10:07:25-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Errors-To: Against out-of-band Errors-to:
To: mo@LBL-CSAM.ARPA
cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "mo@LBL-CSAM" of Sun 15 May 83 07:15:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Not at all, Mike.  If the little-i-internet people want the Errors-To
information, they can enhance their mail transport protocol to allow
it.  The mail relay is quite capable of interchanging from one to
another if it is done in any reasonable fashion.  This could even be
done as an Errors-To: line in a header for some network, but that is
really ugly.
-------

Date: 15 May 1983 1242-PDT
From: ROODE at SRI-NIC (David Roode)
Subject: Errors to revisited
To: header-people at MIT-MC, postel at USC-ISIF
Location:  EJ296    Phone: (415) 859-2774

What a flap!  I hope the needed functionality does not get forgotten
in all the hoopla.  The problem is in sending to a large mailing
list, some people would like the errors returned to them,
and some people want "someone else" to handle them.  The problem
is the volume of errors can be quite large and so it may not
be operationally practicable to count on this "someone else"
so it is a best effort, not a guarantee.

I submit that the specification of an arbitrary place to direct errors
is too powerful.  What if the specified mailbox does not LIKE getting
these errors!  I believe what we need to do is to extend SMTP to provide
for a special type of message known as a "report".  RPRT FROM: would
behave exactly like MAIL FROM: except that all the recipients would
have a transformation applied to them.  The message would go to
whomever is accepting errors for that mailbox, if any, else discard.
Mailers and SMTP servers could use this however they chose.

In the headers, I would propose an option with a fixed set of values.
"Errors-to" would be okay, but perhaps "Msg-status to:" would be
better.  The arguments would be "sender", "recipient-mailer",
or "both."
-------

Date: 15 May 1983 1625-EDT (Sunday)
From: don.provan@CMU-CS-A
To: header-people@MIT-MC
Subject: errors to:
Message-Id: <15May83.162513.DP0N@CMU-CS-A>

i still don't understand how this "errors-to" destination differs from
the "return-path".  the idea of the "return-path" being an audit trail
doesn't jive with anything i read in the RFCs.  the "received" lines
are an audit trail, but nothing seems to indicate that "return-path"
needs to agree with them.  i can't think of a single situation that
someone sending mail to an exploder would want to get an error
report, except if the sender wanted to maintain the exploder.  but if
there is some justification, why not add the information to the
actual MAIL command?  presumably the "from:" is there just for the
syntax "mail from:<foo@bar> errors:<frog@qaz>" or some such.  no need
for a separate command.  (you can add it to the RCPT line if you want
it different for different recepients.)
	but can anyone give me an example where "return-path" isn't correct?
if so, what's the difference between the errors my server should report
to the return-path and the errors it should report to errors-to.  i'm glad
you all agree for the need, but can someone let me in one the secret?

Date: 15 May 1983 1536-PDT
From: ROODE at SRI-NIC (David Roode)
Subject: Re: errors to:
To: don.provan at CMU-CS-A, header-people at MIT-MC
Location:  EJ296    Phone: (415) 859-2774
In-Reply-To: Your message of 15-May-83 1325-PDT

The return path is supposed to be a way to reach the SENDER,
not the person interested in errors, although some might
assume these to be the same thing.  It is supposed
to be a path that can be followed if expansion /interpretation
of the address of the sender fails for whatever reason, and
is defined to be constructed via such a mechanism that classifying
it as an audit trail is not unreasonable.
-------

Date: 15 May 1983 1943-EDT (Sunday)
From: don.provan@CMU-CS-A
To: ROODE@SRI-NIC (David Roode)
Subject: Re: errors to:
CC: header-people@MIT-MC
In-Reply-To: "ROODE@SRI-NIC's message of 15 May 83 17:36-EST"
Message-Id: <15May83.194354.DP0N@CMU-CS-A>

what you say is fine with me, but does not agree with RFC821.
RFC821 specifically says that the return-path is where errors
should be sent.  there's no indication that it needs to have
anything whatsoever to do with the sender.  in fact, there was
one peice of mail that passed through my server that had "mailer"
in this field, even though it was a perfectly normal piece of mail.
are we planning to change the meaning of this, or what?

Date: 15 May 1983 1808-PDT
From: ROODE at SRI-NIC (David Roode)
Subject: Re: errors to:
To: don.provan at CMU-CS-A
cc: header-people at MIT-MC
Location:  EJ296    Phone: (415) 859-2774
In-Reply-To: Your message of 15-May-83 1643-PDT

I think we are both right, but are placing emphasis on different
aspects of 821's definition.  On page 24 of the August 1982
RFC 821, it says, relating to the argument to the "MAIL FROM:"
command, which constitutes the "Return-path" header line:

  The reverse-path consists of an optional list of hosts and
  the SENDER mailbox.  When the list of hosts is present, it
  is a "reverse" source route and indicates that the mail was
  relayed through each host on the list (the first host in the
  list was the most recent relay).  This list is used as a
  source route to return non-delivery notices to the SENDER.
  As each relay host adds itself to the beginning of the list,
  it must use its name as known in the IPCE to which it is
  relaying themail rather than the IPCE from which the mail
  came (if they are different).

This does not allow the return of errors other than to the SENDER
mailbox (I added the capitalization of this word in the quotes
paragraph).  So I see the germane interpretation of this as
being "here is a bullet-proof way to get to the sender" with
a secondary idea of "send errors to the SENDER".  You seem to
see it as "here is the way to return errors" with a secondary
"the routing style of specification makes it bullet proof"
and discount the emphasis that this is the SENDER being refered to.

What I think needs to be addressed is a whole different class of errors,
for which it is not desirable to reach the sender.  Specifically, 
if I send to "mail-wizards" at BBN-UNIX, one class of errors
concerns getting the message to BBN-UNIX, and having it accepted
for processing there, and a second class of errors would be those
that BBN-UNIX encounters in processing some part of the "fan-out"
of "mail-wizards" which are quite different.   I think the first
type consists of functional errors which should always go to the
sender (using reverse path if need be) and the second type
are highly dependent on the context of the remote mailer once
it has received the message, and so the sender may not wish to see
these errors.

Existing mailers have various defacto standards for deriving
"responsible party" addresses for certain other "addresses" so that is
what I have in mind as being the action taken by the remote mailer if
told the sender did not want to see errors, with no particular one of
the defacto standards being preferred.  Perhaps the sender should be
force-fed errors if no other "responsible party" was available.

Regarding the Return path specification of "Mailer" that you have
seen, I would be concerned about that too.  Some of the TOPS-20
mailers do not preserve the reverse path specified to them, and then
reconstruct one based on the sender as specified in the headers.  This
is motivated by the need to not include the return path as a header if
the message is relayed.  The best strategy would be to preserve the
reverse path, but to remove it from the headers on the message when
relaying, while at the same time using it to generate the reverse path
provided to the SMTP server receiving the relayed copy.
-------

Date: 15 May 1983 1825-PDT
From: ROODE at SRI-NIC (David Roode)
Subject: consider this model:
To: Header-people at MIT-MC
Location:  EJ296    Phone: (415) 859-2774

SMTP is neither the envelope nor the message, but rather something else,
the transport protocol.  Multiple message/envelope pairs may
result from one SMTP transaction.  Sure, "errors-to" belongs in the
envelope, but the true envelope of arpanet messages has always
been the headers.  Usually headers have been for the use of the user
agent, but in the "fan-out" situation, the "mailer" is acting precisely
as a cross between a server and a user agent.  If "fan-out" is not
involved, then the use of "errors-to" would be superfluous.
-------

Date: 15 May 1983 2136-EDT (Sunday)
From: don.provan@CMU-CS-A
To: ROODE@SRI-NIC (David Roode)
Subject: Re: errors to:
CC: header-people@MIT-MC
In-Reply-To: "ROODE@SRI-NIC's message of 15 May 83 20:08-EST"
Message-Id: <15May83.213642.DP0N@CMU-CS-A>

but on page 22 it says, "It is possible for the mailbox in
the return path be different from the actual sender's mailbox."
no wonder we don't agree: the RFC contradicts itself.

your example is easily handled by the return-path, since the
mail on the way to the exploder has you in the return-path
and the mail going from the exploder could have a maintanence
account in the return-path.  this makes sense to me because i
see this as two separate transactions, not one that bounces
off the exploder.  i don't see the mail i receive from the
exploder as being from you (although replies will go to you
since your from and reply-to lines are still valid) but rather
i see them as being from the mailing list.

but of course none of this is valid if the return-path is
supposed to be used to route mail back to the originator
(as opposed to the sender in the current transaction).

Date: 15 May 1983 2227-PDT (Sunday)
From: mo@LBL-CSAM
Subject: Re: consider this model:
Return-Path: <mo@LBL-CSAM>
Message-Id: <8305160527.AA11191@LBL-CSAM.ARPA>
Received: by LBL-CSAM.ARPA (3.320/3.21)
	id AA11191; 15 May 83 22:27:04 PDT (Sun)
To: ROODE@SRI-NIC   (David Roode)
Cc: Header-people@MIT-MC
In-Reply-To: Your message of 15 May 1983 1825-PDT.
             <8305160136.AA09742@LBL-CSAM.ARPA>

"the true envelope of arpanet messages has always been the headers"

And that, I submit, is at the core of the problem.  The Post Office
is entirely capable of transferring a letter without access to 
its contents (in fact, its employees go to jail for violating this
proviso - mail implementers, contemplate such a charge!).  The sooner
we start thinking in terms of electronic Mail instead of
electronic Memos the sooner this mess will clear. 

I don't write messages on the outside of envelopes and the Post Office
doesn't have to open my mail to deliver it.  

	-Mike

Date: 16 May 83 01:31:46 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: Re: consider this model:
Message-Id: <8305160830.AA00610@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.339/3.28)
	id AA00610; 16 May 83 01:30:00 PDT (Mon)
To: ROODE@SRI-NIC
Cc: header-people@mit-mc


In reply to:

	Date: 15 May 1983 1825-PDT
	From: ROODE@SRI-NIC   (David Roode)
	Subject: consider this model:
	
	SMTP is neither the envelope nor the message, but rather
	something else, the transport protocol.
	... the true envelope of arpanet messages has always
	been the headers.
	
	
I concur. My "basic message format" is an attempt to better define
the "header envelope".

Bill Wells
topaz.wcwells@BERKELEY.ARPA


Date: 16 May 1983 11:42:42-EST
From: Christopher A Kent <cak@purdue.ARPA>
Reply-to: cak@purdue.ARPA
To: mo@LBL-CSAM
Cc: ROODE@SRI-NIC, Header-people@MIT-MC
Subject: Re: consider this model:
In-reply-to: Your message of 15 May 1983 2227-PDT (Sunday).
             <8305160527.AA11191@LBL-CSAM.ARPA>
Message-ID: <PVax.528.421951358@Purdue>

Hear hear! I'd like to see the separation of envelope and message, too.
I am tired of having to see all the junk in the headers as part of the
text, when I just want to see the what the sender intended.

chris

Date: 16 May 83 17:19:33 EDT  (Mon)
From: mhb5b!smb@Berkeley (Steven M. Bellovin)
Subject: errors-to
Message-Id: <8305162110.AQ09368@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.339/3.28)
	id AQ09368; 16 May 83 14:10:28 PDT (Mon)
To: header-people@mit-mc

If there's an "Errors-To" line, there needs to be a "Remailed-Errors-To"
as well.  That will differentiate between errors in a message being sent
to the exploder, and errors in the message from the exploder.

		--Steve


Date: 16 May 83 16:01:45 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: Re: Errors-To, round 2
Message-Id: <8305162306.AA01440@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.339/3.28)
	id AA01440; 16 May 83 16:06:50 PDT (Mon)
To: MRC@SU-SCORE
Cc: POSTEL@USC-ISIF, header-people@MIT-MC

Mark,

In reply to:

	Date: Fri 13 May 83 23:57:55-PDT
	From: Mark Crispin <MRC@SU-SCORE.ARPA>
	Subject: Re: Errors-To, round 2
	Message-Id: <8305161328.AA02730@UCBVAX.ARPA>
	
	     With some greater thought on my part, I am now opposed to
	the idea of an Errors-To header line, and greatly supportive of
	an SMTP enhancement that implements this functionality.  In
	other words, something like:
		MAIL FROM:<jones@foo>
		ERRS TO:<foo-maintainer@foo>
		RCPT TO:<foo-people@foo>
	Of course, SMTP senders must be prepared to receive 500 errors
	from various SMTP receivers, since nobody presently implements
	this.
	
	     It is then up to the SMTP sender to properly specify this.
	
It may work for SMTP, but the world is not all SMTP. How is the non-SMTP
mail system going to specify this?

Bill Wells
topaz.wcwells@BERKELEY


Date: 16 May 1983 1756-MDT
From: Lepreau@UTAH-20 (Jay Lepreau)
Subject: Re: consider this model:
To: cak@PURDUE
cc: mo@LBL-CSAM, ROODE@SRI-NIC, header-people@MIT-MC
In-Reply-To: Your message of 16-May-83 1042-MDT

Chris, that's no argument-- any decent mail reader can suppress display of
the user's choice of header lines.  To speak to your personal situation, Unix
mailers, in particular, used to lack in this respect, but there are versions
of Mail with that feature and Spence has hacked on Gosling's Emacs rmail
package to do the same.  Given its design, I'm sure MH trivially can suppress
headers also.  You are welocme to have our Mail and rmail.ml.

(If that is not good enough, if you want to have just "what the sender
intended" be displayed, as you stated in your msg, then a new header
could be supported: "Display-these-non-std-headers."  Just what we
always wanted, a header to suppress headers!  I think there are more
important problems, and better solutions to that one....)

Sure, we should move all the envelope info out of the message, but remember
that this is the SIMPLE Mail Transfer Protocol, and I believe explicitly
intended as an interim protocol while the general multi-media super-hot
general case gets worked out.  It was not intended to be "perfect" but to
address (sic) the worst problems while not being too radical a departure from
the past.  Thus its ramifications would not be too difficult to understand,
nor its implementation too difficult.

Of course, it and 822 will be around for years....

Jon, correct me if I'm wrong (although I'm sure others will take the
opportunity as well).
-------

Date: 16 May 1983 1749-PDT
Sender: BILLW at SRI-KL
Subject: Re: Errors-To, round 2
From: BILLW at SRI-KL
To: wcwells%Topaz.CC at BERKELEY
Cc: MRC at SU-SCORE, POSTEL at USC-ISIF, 
Cc: header-people at MIT-MC
Message-ID: <[SRI-KL]16-May-83 17:49:47.BILLW>
In-Reply-To: <8305162306.AA01440@UCBVAX.ARPA>

Sure, the ERRS TO smtp command will only work in a SMTP environment.
However, there is nothing to stop gateway machines from removing
such a command from the envelope (SMTP commands) and putting it
in the message itself as an ERRORS-TO header line or whatever.

There shouldnt be anything stopping each network (as defined by
mail transmission protocols) from using whatever mechanism is
best for ITS own use.  This of course requires a little more
effort on the part of mail gateways, but this is required anyway.
[Eg: Although on the Internet, it is generally considered a bad
 idea to munge the internal headers of a message, this is a
 common practice going to and from the UUCP world]

I think it is relatively clear that in an SMTP environment, it
makes more sense to have this information outside of the message.

Note that just having seperate HEADERS and MESSAGE commands doesnt
necessarilly solve problems because of the extensible nature of
rfc822.  Having a seperate HEADERS section implys that all of the
headers therin should be parseable by any mail receiver, and this
is extremely unlikely (Around here, we even have messages going out
over our local nets that have things like ROUTE: TWX 123456... in them)

BillW

Date: 16 May 1983 1756-PDT
Sender: BILLW at SRI-KL
Subject: Re: consider this model:
From: BILLW at SRI-KL
To: Lepreau at UTAH-20
Cc: cak at PURDUE, mo at LBL-CSAM, ROODE at SRI-NIC, 
Cc: header-people at MIT-MC
Message-ID: <[SRI-KL]16-May-83 17:56:57.BILLW>
In-Reply-To: Your message of 16 May 1983 1756-MDT

HERMES, as an example of a good mail reading program, allows
multiple user defined templates for printing messages (also
for composing messages, dispaying headers, etc).  Thus while
my normal template prints out only relevant fields, I can
print out the message using LONG-PRINT-FORM, and see everything.

BillW

Date: 16 May 1983 1749-PDT
Sender: BILLW at SRI-KL
Subject: Re: Errors-To, round 2
From: BILLW at SRI-KL
To: wcwells%Topaz.CC at BERKELEY
Cc: MRC at SU-SCORE, POSTEL at USC-ISIF, 
Cc: header-people at MIT-MC
Message-ID: <[SRI-KL]16-May-83 17:49:47.BILLW>
In-Reply-To: <8305162306.AA01440@UCBVAX.ARPA>

Sure, the ERRS TO smtp command will only work in a SMTP environment.
However, there is nothing to stop gateway machines from removing
such a command from the envelope (SMTP commands) and putting it
in the message itself as an ERRORS-TO header line or whatever.

There shouldnt be anything stopping each network (as defined by
mail transmission protocols) from using whatever mechanism is
best for ITS own use.  This of course requires a little more
effort on the part of mail gateways, but this is required anyway.
[Eg: Although on the Internet, it is generally considered a bad
 idea to munge the internal headers of a message, this is a
 common practice going to and from the UUCP world]

I think it is relatively clear that in an SMTP environment, it
makes more sense to have this information outside of the message.

Note that just having seperate HEADERS and MESSAGE commands doesnt
necessarilly solve problems because of the extensible nature of
rfc822.  Having a seperate HEADERS section implys that all of the
headers therin should be parseable by any mail receiver, and this
is extremely unlikely (Around here, we even have messages going out
over our local nets that have things like ROUTE: TWX 123456... in them)

BillW

Date: Mon 16 May 83 18:40:51-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Errors-To, round 2
To: wcwells%Topaz.CC@UCB-VAX.ARPA
cc: POSTEL@USC-ISIF.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "wcwells%Topaz.CC@Berkeley" of Mon 16 May 83 16:01:31-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Bill -

     If the non-SMTP people want this functionality, they can implement
it in their transport protocol.  I believe it is just as simple to put
it in the transport protocol as it is to parse a header line, especially
as any reasonable transport protocol has provisions for new options and
ignoring unknown options.

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

Date: 17 May 1983 1038-PDT (Tuesday)
From: eric%UCBARPA@Berkeley (Eric Allman)
Subject: Re: Errors-To, round 2
Message-Id: <28949.31.422041139@ucbarpa>
Received: by UCBARPA.ARPA (3.340/3.28)
	id AA28950; 17 May 83 10:39:02 PDT (Tue)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.339/3.28)
	id AA14623; 17 May 83 10:32:43 PDT (Tue)
Phone: (415) 548-3211
To: header-people@mit-mc
Fcc: mail

Although I agree that the Errors-To: info belongs in the envelope, it is
not at all clear to me that the SMTP exchange represents the envelope.
Perhaps it should, but it most certainly does not.  At least the following
lines in the headers belong in the envelope:

	Received:
	Return-Path:
	Errors-To:
	Resent-Date:
	Resent-Cc:
	Resent-To:
	Resent-Bcc:
	Resent-Message-Id:
	Encrypted:

The NBS standard also defines some others:

	Return-Receipt-To:
	Circulate-To:
	Circulate-Next:
	Posted-Date:
	End-Date:
	Received-Date:
	Recipient-Serial-Number:
	Precedence:

I suppose we could put these all in the SMTP protocol, but this does not
handle the fundamental problem that the SMTP protocol is not extensible.
As such, new envelope fields require a change to untold numbers of
implementations.  Contrast this with the header fields, where new fields
can be added as required.

On the other hand, "wrapping" is not cleanly handled in the headers.  I
consider wrapping one of the fundamental functions of envelopes.  You
create a message, then wrap it in an envelope.  If you want to forward
the message (e.g., send it off to your lawyer), you wrap the old envelope
in a new envelope.  For example, consider the case of a message that has
been redistributed several times.  The header can potentially have several
Resent-*: fields, and since order is specifically insignificant in the
header, it is not in general possible to recreate the wrapping.

I would propose something like the following.  I do not claim that I would
do it this way if I were designing the protocols from scratch.  Header
fields that are in the "envelope" could be preceeded by a special character,
say an "@".  When a message gets wrapped, previous header lines have another
"@" prepended.  This would make it easy for mail readers to strip off
envelope lines.  It is extensible.  It highlights the wrapping.  For
example:
	@Return-Path: <lepreau@utah-cs>
	@Received: by your-host from utah-cs ...
	@@Return-Path: <mo@lbl-csam>
	@@Received: by utah-cs from lbl-csam ...
	@@@Return-Path: <@MIT-MC:eric@Berkeley>
	@@@Received: by MIT-MC from Berkeley ...
	@@@Received: by lbl-csam from MIT-MC ...
	From: <eric@Berkeley>
	Subject: Re: Errors-To:, round 2
	To: header-people@mit-mc
	@@Message-Id: <xyzzy456@Lbl-Csam>
	@@From: <mo@lbl-csam>
	@@To: <lepreau@utah-cs>
	@Message-Id: <querp789@utah-cs>
	@From: lepreau@utah-cs
	@To: you@your-host
	@@@Message-Id: <foobar123@Berkeley>
Ok, it's ugly as sin -- but presumably those lines with "@"s are going
to be stripped off.....

Yours for bigger and better arguments,

eric

Date: 17 May 83 11:46:31 EDT (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Errors-to
Message-Id: <8305171546.AA12081@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA12081; 17 May 83 11:46:31 EDT (Tue)
Received: by UCBVAX.ARPA (3.339/3.28)
	id AA00609; 17 May 83 16:24:56 PDT (Tue)
To: header-people@mit-mc.ARPA

The thing that bothers me about putting the errors-to info
into something other than the headers (e.g. an SMTP command) is that
this is a bottleneck that would tend to get lost.  Some mail systems
don't remember non-header information at all.  UUCP remembers the "to"
address and the text of the message, but nothing else.  Any mail sent
through UUCP would lose the Errors-To unless it were put into the header.
I don't know about MMDF or BITNET but I wouldn't be surprised at a
similar result.  I'm also worried about existing SMTP implementations
being upgraded to support this.  If you put the info in the headers,
even dumb mailers will pass it along.  But if you add a new SMTP command,
it will be lost at the first forwarder that doesn't understand it.

	Mark

Date:     18 May 83 2:27:07 EDT (Wed)
From:     Doug Kingston <dpk@brl-vgr>
To:       Mark Horton <cbosgd!mark@ucb-vax.arpa>
cc:       header-people@mit-mc.arpa
Subject:  Re:  Errors-to

	I have been quiet until now on the subject of Errors-to: but
I think a few of comments are necessary at this time.  I am currently
the primary implementer for the MMDF system and as part of my work
I have implemented a special processor (channel) for handling mailing
lists in an intelligent fashion.  This entails doing address verification
after submission and somehow causing errors to return to the list
maintainer instead of the original sender.  My first implementation
is going to supply an alternate "MAIL FROM:" address to the receiving
host.  The address to be supplied will be the first found from the
following group: a special table entry, <list>-request, original sender,
and finally Postmaster.

	I strongly favor the development of a mechanism for specifying
the address to which returned mail should be sent.

	By "returned mail" I mean mail that is being returned, probably
by an automated system (MMDF, SENDMAIL, MAISER, ...), but possibly by
a local Postmaster because the mail could not be delivered to the intended
recipient.

	There are two problems to be faced.  The first is an immediate
need for an alternate return address that MRC, Eric, myself, and others
can implement now to spare the contributers of a large number of lists the
agony returned messages they can do nothing about.  This first problem
has to be solved in a manner that will work in the existing system without
breaking existing mailers.  For the time being, the alternate MAIL FROM:
is the only option that will produce results.

	The second problem is to develop a more explicit mechanism to
accomplish the same thing.  A method needs to be decided upon, an RFC
written, deadlines set and implementation started.

	From an implementation standpoint I favor passing the Errors-To
information in the SMTP level, which is the same level that you pass
the Sender and the Recipient addresses.  This layer is designed for
easy machine interpretion and is the "proper" layer for this information.
We don't search the header for the recipients, or the Sender, why should
we break the pattern for the error recipient.  In addition, I concur
that I would prefer to keep the mailer out of the header as much as
possible.  Remember, in almost all cases, the Errors-To information
is going to be generated by the mail-system at some foreign host.
This is not to say that I couldn't implement it as a header
line, I will probably be one of the first to implement whatever
standard is chosen.

	I am sensitive to the needs of UUCP and other protocols that
may not be as capable as SMTP at mail transfer.  And don't think that
you can easily change any of these protocols.  Old protocols die hard.
MMDF, SENDMAIL, or any other reasonably intelligent mailer that is
serving as a forwarder for one of these lesser protocols will have
little or no trouble in supplying the Errors-to address in whatever
form the protocol desires.  I suspect that in many cases, we will find
that the other protocol will have no parallel to Errors-To.  The UUCP
community is attempting to become as compatable as possible with the
ARPA mail standards; the same is probably not true of others.

	One other anomaly that needs to be discussed is the use
of a single Errors-To: or per-addressee Errors-To: fields.  Consider
for example....

		I am a mail-list exploding host's mailer.  "Jill" at my
	host sends a letter to "Jack@Hill, Hill-list".  "Hill-list" expands
	to "a@Hill, b@Hill, c@Hill".  I have a address list that looks like
	"Jack@Hill, a@Hill, b@Hill, c@Hill".  The "Hill-list" is maintained by
	DPK@BRL.

Ideally, any error on the address "Jack@Hill" should be sent to original
sender, Jill.  Any errors on "a", "b", or "c" at Hill should be send to
DPK@BRL.  This seems to suggest that a per-address specification is
necessary in our long-term, ?generalized? solution.  I can tell you from
experience that this situation occurs on a regular basis in local mail
networks where you have messages being exchanged between principals
of a project with Cc:'s to local interest lists.  Given that you accept
the need for a "per-addressee" Errors-To address, the consequences of
putting this information in the header are scary.  This reinforces my
initial feelings that the Errors-to should be given as an ?optional?
command in the SMTP exchange.
			       __
			      /  \______
			   __/  \/______)  Returned to Sender...
			         (_)			-Doug-
			   __	 (_)
			     \___(_)


Date:     18 May 83 4:06:01 EDT (Wed)
From:     Doug Kingston <dpk@brl-vgr>
To:       header-people@mit-mc
Subject:  Separation of Envelope and Header

	I also support the separation of the "header" as originally
sent, and the "envelope" portion which contains stuff tacked on a a
later date.  Note that both portions should be available to the recipient.

						-Doug-


Date:     18 May 83 9:24:08-EDT (Wed)
From: Dave Crocker <dcrocker@udel-relay>
Return-Path: <Dcrocker@UDel-Relay>
Subject:  Re:  Separation of Envelope and Header
To: Doug Kingston <dpk@brl>
Cc: header-people@mit-mc

You might consider a modification to the header spec, in order to
use header position to indicate envelope headers, versus content
headers.

In particular, dividing headers into two unordered sets, using
a special field as the dividing line, seems quite easy.  For
example:

To: xxxxxxxxxx.
cc: xxxxxxxxxx
Subject: xxxxxxxxxx.
Date: xxxxxxxxxx
Envelope:
Message-Id: xxxxxxxxxx
Received xxxxxxxxxx
Received xxxxxxxxxx
Return-Path: xxxxxxxxxx
Errors-To: xxxxxxxxxx


so that the 'Envelope' header separates the two sets of
headers.

It is strictly a hack, but should be easy to implement.  It has
the advantage of being transparent to systems that do not know about
the convention, as long as you maintain the convention of keeping
a flat name space for headers in both groups.

Dave

Received: from SCRC-AFGHAN by SCRC-TENEX with CHAOS; Wed 18-May-83 09:21:58-EDT
Date: Wednesday, 18 May 1983, 09:20-EDT
From: Robert W. Kerns <RWK@SCRC-TENEX>
Subject: Re: Errors-To, round 2
To: Eric Allman <eric%UCBARPA@UCB-VAX>
Cc: header-people@mit-mc
In-reply-to: <28949.31.422041139@ucbarpa>

    Date: 17 May 1983 1038-PDT (Tuesday)
    From: eric%UCBARPA@Berkeley (Eric Allman)
    Although I agree that the Errors-To: info belongs in the envelope, it is
    not at all clear to me that the SMTP exchange represents the envelope.
    Perhaps it should, but it most certainly does not.  
It certainly should not represent the envelope.
Have you never pulled an envelope out of the trash to check
the return address, or the postmark?  SMPT represents the
transmission medium.  The truck that carries mail between
offices, if you will.

I don't think the envelope is that well distinguished from the
message header anyway.  Remember, we aren't limitted to modelling
the existing USless postal system.  Historically, the primary
purpose of an envelope has been to protect and conceal.  The
routing information has been on envelopes, since concealing
the text was done by covering it, not by encrypting it or other
"high tech" means.  Often, however, the need has been felt to
duplicate the routing information inside with the text.  Note
the standard business-letter format, in which the so-called
"envelope" information is shifted in possition, but definitely
present.  However, no postmarks, stamps, and other transmission
artifacts are included.

I think it's certainly within our reach to filter, in presentation, only
that header information we want to see, according to the type of header.
Some people would view "In-reply-to:" as a part of the supporting
structure, and not wish to see it.  Others, myself included, view it as
serving to name a specific message being replied to, better than the
subject, and want to see it, as well as having commands which make
use of it.  Is it header, or is it envelope?  Wrong question.

The right question is "do I want to see it, or do I want to not look
at it right now?".  The header consists of pieces of information called
header fields, each one coming from a different place and serving a
different purpose.  It is the TEXT which is enclosed.

Date: 18 May 83 11:46:56 PDT (Wed)
From: wcwells%Topaz.CC@Berkeley
Subject: Re:  Separation of Envelope and Header
Message-Id: <8305181845.AA02651@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.339/3.28)
	id AA02651; 18 May 83 11:45:28 PDT (Wed)
To: Dcrocker@UDel-Relay
Cc: header-people@mit-mc

Dave,

In reply to:

	Date:     18 May 83 9:24:08-EDT (Wed)
	From: Dave Crocker <dcrocker@udel-relay>
	Subject:  Re:  Separation of Envelope and Header
	To: Doug Kingston <dpk@brl>
	Cc: header-people@mit-mc
	
	You might consider a modification to the header spec, in order to
	use header position to indicate envelope headers, versus content
	headers.
	
	In particular, dividing headers into two unordered sets, using
	a special field as the dividing line, seems quite easy.
	
Basic idea is good, but lets put the header envelope ahead of the
message (content) header so we can have multiple envelopes in the
future, if necessary. (That is, I think it is cleaner to
put the message inside the envelope.)  For example:

	Post-ID: xxxxxxxxx
	Posted-Date: xxxxxxxxx
	Posted-From: xxxxxxxxx
	Received xxxxxxxxxx
	Received xxxxxxxxxx
	Return-Path: xxxxxxxxxx
___	Errors-To: xxxxxxxxxx
	Message-Follows:
	Date: xxxxxxxxxx
	From: xxxxxxxxxx
	To: xxxxxxxxxx.
	cc: xxxxxxxxxx
	Subject: xxxxxxxxxx.
	Message-Id: xxxxxxxxxx
	
PS. There is still some confusion about what the function of
"Message-ID" is. Is it a "Postmark" or a message content identification
field? After rereading RFC 822 I think it is suppose to be a content
field (for example, a pointer to a file) rather that a post mark.

Bill Wells, RMC, USNR-R

topaz.wcwells@BERKELEY.ARPA

Computing Services, 297 Evans Hall,
University of California, Berkeley CA 94720


Date: 18 May 1983 14:05:18-EST
From: Christopher A Kent <cak@purdue.ARPA>
Reply-to: cak@purdue.ARPA
To: Dcrocker@UDel-Relay, wcwells%Topaz.CC@Berkeley
Subject: Re:  Separation of Envelope and Header
Cc: header-people@mit-mc

I think I like Eric's idea of "wrapping" headers better. Then we can 
distinguish multiple envelopes easily.

chris

Date: Wed 18 May 83 15:19:51-PDT
From: David Roode <ROODE@SRI-AI.ARPA>
Subject: message envelopes
To: Header-people@MIT-MC.ARPA

Users are often apt to want to see evidence from the message
envelope.  If the entire envelope were encoded in SMTP commands,
then I think a log of all such commands should be associated
with each message received and made available to the user
as easily as headers are now.

Using the header scheme provides this automatically. What has
been missing until now has been an easy way to specify inclusion
or exclusion of all envelope-derived header lines.  Several of the
proposals made recently add that capability. Using this method
would also be more efficient in the user process than are existing
template systems, or other systems based on checking individual
header lines against lists.

The default could be made to exclude the envelope, and the user
could be given a simple command to display the envelope alone
when desired.
-------

Date: 18 May 83 10:04:03 EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: envelope vs headers
Message-Id: <8305181404.AA07738@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA07738; 18 May 83 10:04:03 EDT (Wed)
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA03719; 18 May 83 20:48:43 PDT (Wed)
To: header-people@mit-mc.ARPA

Here's another idea for a distinction - this is off the top of
my head and may not work, but it seems closer to the spirit of
733 and 822 than extending SMTP or using @ signs.

A message looks like
	Envelope
	separator1
	Headers
	separator2
	Body
Envelope and Headers are : style lines like we all know and love.
The separator2 remains a blank line.  We can't use a blank
line for the separator1, much as we'd like to, because of
upward compatibility issues, and ambiguities with rewrapping.
The separator1 has to look like a header line, with a colon.
For example,
	-:
(I'm not sure if this is legal by 822), or possibly
	Containing:

One advantage to this is that mailers can add lines to the front
of the Envelope without having to hunt for separators.  Another
is that a user interface can suppress everything in the envelope
by default.  (I don't know how other mailers suppress lines, but
Mail requires the user to specify a list of header lines to
suppress.  When new envelope-style lines appear, the user sees them.)

Such messages can be rewrapped by adding another separator1 and more
envelope lines.

	Mark

Date: 19 May 83 22:38:59 PDT (Thu)
From: wcwells%Topaz.CC@Berkeley
Subject: message header format
Message-Id: <8305200542.AA03705@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA03705; 19 May 83 22:42:24 PDT (Thu)
To: cak@purdue, eric%ucbarpa@Berkeley
Cc: header-people@mit-mc

In reply to:

	Date: 17 May 1983 1038-PDT (Tuesday)
	From: eric@UCBARPA.BERKELEY (Eric Allman)
	Subject: Re: Errors-To, round 2
	Message-Id: <28949.31.422041139@ucbarpa>

	At least the following lines in the headers belong in the
	envelope:
	
		Received:
		Return-Path:
		Errors-To:
		Resent-Date:
		Resent-Cc:
		Resent-To:
		Resent-Bcc:
		Resent-Message-Id:
		Encrypted:
	
I think we are getting confused here. I can accept the "Received",
"Return-Path", "Errors-To:" and maybe "Encrypted" as part of the
postal heading (postal envelope, if you prefer that term).
But, the "Resent" fields to build a readdressal heading are a user
header fields, not "mail transport/relay" level fields. To quote
RFC 822:

	"Some systems permit mail recipients to forward a message,
	retaining the original headers, by adding some new fields...."

	"... the message is assumed to have been forwarded by an
	original recipient who attached the 'Resent-" field"

I interpret "recipient" to be an individual addressee (reader) of the
original message.

In reply to:
	
	On the other hand, "wrapping" is not cleanly handled in the
	headers.  I consider wrapping one of the fundamental functions
	of envelopes.  You create a message, then wrap it in an
	envelope.  If you want to forward the message (e.g., send it
	off to your lawyer), you wrap the old envelope in a new
	envelope.

I think things will be a lot easier if the readdressed message is
handled as a new message.  That is the "postal envelope" information
of previous transmissions should be removed before it is reposted
to the mail system. Note, that my interpretation, previous "Resent-"
fields would not be stripped off since they are not part of the
postal envelope. Removing the old audit trail information from
the heading will also kept the size of the heading down for
multiple readdressals.

However to be forgiving to users (or mail submission) programs
who do not remove old postal envelope fields, we could prepend a
single ">" (or "@" if you prefer) on the "postal envelope" fields.
Note: multiple prefix characters are not required since the mail
system is only concerned with information needed for the current
transmission of the readdressed message.

If we are going to do the latter, then I prefer using a ">"
prefix to escape the previous "postal envelope" fields,
since we are already using that character to escape the "From"
at the beginning of a line on Unix. For example,
	

		Resent-Date: xxxxxxxx
		Resent-From: lepreau@utah-cs
		Resent-To: you@your-host
		Resent-Message-ID: <querp789@utah-cs>
		Return-Path: <lepreau@utah-cs>
		Received: by your-host from utah-cs ...
		>Return-Path: <mo@lbl-csam>
		>Received: by utah-cs from lbl-csam ...
		Resent-Date: xxxxxxxx
		Resent-From: <mo@lbl-csam>
		Resent-To: <lepreau@utah-cs>
		Resent-Message-ID: <xyzzy456@Lbl-Csam>
		>Return-Path: <@MIT-MC:eric@Berkeley>
		>Received: by MIT-MC from Berkeley ...
		>Received: by lbl-csam from MIT-MC ...
		Date: xxxxxxxxxxxx
		From: <eric@Berkeley>
		Subject: Re: Errors-To:, round 2
		To: header-people@mit-mc
		Message-ID: <foobar123@Berkeley>

My first preference is to delete the old audit trail fields.
For example:

		Resent-Date: xxxxxxxx
		Resent-From: lepreau@utah-cs
		Resent-To: you@your-host
		Resent-Message-ID: <querp789@utah-cs>
		Return-Path: <lepreau@utah-cs>
		Received: by your-host from utah-cs ...
		Resent-Date: xxxxxxxx
		Resent-From: <mo@lbl-csam>
		Resent-To: <lepreau@utah-cs>
		Resent-Message-ID: <xyzzy456@Lbl-Csam>
		Date: xxxxxxxxxxxx
		From: <eric@Berkeley>
		Subject: Re: Errors-To:, round 2
		To: header-people@mit-mc
		Message-ID: <foobar123@Berkeley>

Note, there is only one "Message-ID" field, the message identification
field of the original message. There may be more than one
"Resent-Message-ID", one for each readdressal.

Next question, how to handle the multiple "Resent-" fields.
I will address that issue in a separate message.

Bill Wells
topaz.wcwells@Berkeley.ARPA

Date: 20 May 1983 1018-PDT (Friday)
From: eric%UCBARPA@Berkeley (Eric Allman)
Subject: Re: message header format
Message-Id: <9296.31.422299120@ucbarpa>
Received: by UCBARPA.ARPA (3.340/3.28)
	id AA09297; 20 May 83 10:18:42 PDT (Fri)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29)
	id AA00988; 20 May 83 13:24:49 PDT (Fri)
Phone: (415) 548-3211
To: wcwells%Topaz.CC@Berkeley
Cc: header-people@mit-mc, cak@purdue
In-Reply-To: Your message of 19 May 83 22:38:54 PDT (Thu).
             <8305200541.AA03677@UCBVAX.ARPA>
Fcc: mail

I disagree about stripping the old information out before you resend.
There are several reasons for this.  First, fields such as "message-id"
has semantic meaning.  For example, if I wanted to build a database for
my messages that would maintain some reasonable semantic connections,
I would need those message-id's, both original and resent, to create
the appropriate semantic connections.  Although I know of no system
that does this today, I view it as one of the long-term important
reasons for message-id's.  Second, if you wanted to "send a message
to your lawyer" you would want to have those fields included -- even
the Received: lines, etc.  Your "lawyer" might be your mail system
maintainer, other people on your faculty, or whatever.

Simply putting readdressed messages in a new envelope is not sufficient,
since information in the original header needs to be machine accessible.

Multiple prefix characters ARE required so that you can associate
header fields with the correct reinstantiation of the message.

Using ">" instead of "@" because UNIX already does that is a prime
example of UNIX chauvinism.  It may be that ">" is a more aesthetic
choice, but doing it "because" UNIX does it is gratuitous.

eric

Date: 22 May 83 14:49:42 PDT (Sun)
From: wcwells%Topaz.CC@Berkeley
Subject: Re: message header format
Message-Id: <8305222156.AA08709@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA08709; 22 May 83 14:56:23 PDT (Sun)
To: eric%ucbarpa@Berkeley
Cc: cak@purdue, header-people@mit-mc

Eric,

In reply to:

	Date: 20 May 1983 1018-PDT (Friday)
	From: UCBARPA:eric (Eric Allman)
	Subject: Re: message header format
	Message-Id: <9296.31.422299120@ucbarpa>
	
	I disagree about stripping the old information out before you
	resend.  There are several reasons for this.  First, fields
	such as "message-id" has semantic meaning.  For example, if I
	wanted to build a database for my messages that would maintain
	some reasonable semantic connections, I would need those
	message-id's, both original and resent, to create the
	appropriate semantic connections.  Although I know of no system
	that does this today, I view it as one of the long-term
	important reasons for message-id's.

I did not say to remove "Message-ID" and "Resent-Message-ID"
when resending (readdressing) a previously sent message. They are
"content" information headings. I said: "My first preference is to
delete the old audit trail fields" (ie: "Received" and "Return-Path").
[Take a closer look at my examples.]

	Second, if you wanted to "send a message to your lawyer" you
	would want to have those fields included -- even the Received:
	lines, etc.  Your "lawyer" might be your mail system
	maintainer, other people on your faculty, or whatever.

If I wanted to send all those heading lines to "my lawyer" I would quote
the message in the text of a new message so that "my lawyer" would
receive a copy of the message as I received it. (I think some of the
mailers/mail transport agent programs are messing up the heading
too much as it is.)
	
	Simply putting readdressed messages in a new envelope is not
	sufficient, since information in the original header needs to
	be machine accessible.
	
Which fields and why?  Let's be specific.  With the exception of
previous audit trail information, I will agree that the original
heading (and any previous readdressal header fields) should be sent to
the new addressees.  I still think that the "mail transport system"
should only be concerned with information of the latest readdressal.

Are you intending to send error messages back to the originator of the
original message? If someone goofed in resending one of my messages,
I would prefer to have the error message go back to the resender, not
me.

There is another reason why the readdressed message should be
handled as a new message. -- The message being readdressed might be
very old and the original host and/or originating user mailbox
may no longer exist.

	Multiple prefix characters ARE required so that you can
	associate header fields with the correct reinstantiation
	of the message.
	
That is so only if you retain the very random positioning of header
fields that we have now. There are other methods of keeping these
fields separated.  For example, we could required each sub-part of the
heading to begin with a date field ("Posted-Date", none, one or more
"Resent-Date" and a "Date") with later readdressal sub-parts stacked
ahead of previous ones.

	Using ">" instead of "@" because UNIX already does that is a
	prime example of UNIX chauvinism.  It may be that ">" is a more
	aesthetic choice, but doing it "because" UNIX does it is
	gratuitous.
	
Who cares?  I would just like them to be the same (whatever is used).

Best Regards,

Bill Wells
topaz.wcwells@BERKELEY
	

Date: 22 May 1983 1948-PDT (Sunday)
From: eric%UCBARPA@Berkeley (Eric Allman)
Subject: Re: message header format
Message-Id: <6262.31.422506100@ucbarpa>
Received: by UCBARPA.ARPA (3.342/3.29)
	id AA06263; 22 May 83 19:48:22 PDT (Sun)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29)
	id AA11660; 22 May 83 19:47:35 PDT (Sun)
Phone: (415) 548-3211
To: wcwells%Topaz.CC@Berkeley
Cc: cak@purdue, header-people@mit-mc
In-Reply-To: Your message of 22 May 83 14:49:37 PDT (Sun).
             <8305222155.AA08694@UCBVAX.ARPA>
Fcc: mail

Yes indeed, we CAN come up with lists of header lines that can be
safely deleted.  And we CAN come up with another standard that leaves
header lines position-dependent in the header.  And people who want to
send me a copy of a message that took too long or was misrouted CAN
quote the routing information -- if they remember.  Etc.  But my whole
point is that this kind of garbage is not necessary.  It is upward
compatible with existing mail systems, which can and do rearrange
headers.  It does not require that users remember to quote the right
fields (if they remember to send me the message at all).  It does not
depend on heuristics.  It is extensible.  It leaves the necessary
header and envelope information machine-readable and parsable at all
levels, and makes those levels easily determinable.  It lets mail
readers eliminate the envelope information easily.  Your proposals
seem to be adding more levels of complexity.  We have far too much
of this already.

eric

Date: 22 May 83 20:56:05 PDT (Sun)
From: wcwells%Topaz.CC@Berkeley
Subject: Basic Message Format
Message-Id: <8305230406.AA12603@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA12603; 22 May 83 21:06:39 PDT (Sun)
To: MsgGroup@brl, header-people@mit-mc
Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley


Basic Message Format - 3 - "Postal Heading Syntax"
Version 1 - 22 May 1983


1. Introduction.

This article defines the  syntax  of  header  fields  used  in  the  Postal
Heading.

2. Syntax

POSTED-DATE.

This is the date the message was posted by the originating "electronic post
office".   This  field  is  required  since it defines the beginning of the
Postal Heading.  Syntax is the same as "Date":

        post-date = "Posted-Date" ":" date-time

POSTED-FROM.

This required field contains the identity of  the  originating  "electronic
post  office" which enters the message into a Internet type mail system. It
is suggested that the "()" comment argument of this field contain the  name
and version of the posting program.  Syntax is the same as "From":

        orig-post-office = "Posted-From" ":" mailbox

POST-ID.

This is an optional field that may be added by the originating  "electronic
post office" to identify the message.  Syntax is the same as "Message-ID":

        orig-post-id = "Post-ID" ":" msg-id

POSTMASTER.

This optional  field  contains  the  identity  of  the  Postmaster  at  the
originating  "electronic post office". It is intend for use by sites having
several hosts and only one Postmaster.  Syntax is:

        postmaster = "Postmaster" ":" address

RETURN-PATH.

Defined in RFC 822.

RELAY-TO.

This optional  field  may  be  used  with  a  message  containing  multiple
addresses  to  tell  the  relaying and destination "post offices" that that
they are only required to deliver to the address indicated.  This field  is
not  normally  used  for single addressee message expect to indicate source
routing in the Postal Heading.  If this field contains source routing,  the
source  routing  indicated in this field will be used instead of the source
routing (if any) indicated for the same address  in  the  message  heading.
This  field  may  be  used  by the originating "electronic post office" (as
opposed to the  drafter  and  his  mail  format/submission  program(s))  to
specify source routing for mail systems that require source routing.

Unless otherwise indicated in an outer layer (eg. SMTP, or other envelope),
the  lack  of any "Relay-To" fields indicates to the post office that it is
responsible for relaying the message to all addresses of  the  message.  If
one  or  more  "Relay-To"  fields  is present, then the post office is only
responsible for relaying the message to  the  addresses  indicated  in  the
"Relay-To" field(s).

Syntax is:

        relay-to = "Relay-To" ":" address

DO-NOT-RELAY-TO.

This optional field may be used with a  collective  address  by  the  "post
office"  or  drafter to indicate that the message has already delivered (or
is being delivered by other means) to the indicated address. Syntax of this
field is:

        do-not-relay = "Do-Not-Relay-To" ":" addr-spec

RECEIVED.

Defined in RFC 822.



Comments?

Bill Wells, RMC, USNR-R

topaz.wcwells@BERKELEY.ARPA

Computing Services, 297 Evans Hall,
University of California, Berkeley CA 94720


Date: 22 May 83 20:55:28 PDT (Sun)
From: wcwells%Topaz.CC@Berkeley
Subject: Basic Message Format
Message-Id: <8305230412.AA12691@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA12691; 22 May 83 21:12:03 PDT (Sun)
To: MsgGroup@brl, header-people@mit-mc
Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley


Basic Message Format - 2 - "Heading Components"
Version 2 - 22 May 83

------------------------------------------------------------------------
Changes in this version:

a. "Envelope Heading" and "Envelope Ending" changed to "Postal Heading"
and "Postal Ending" to avoid confusion with all the different
definitions of "envelope" and "message envelope".

b. New header fields have been added for use in the Postal Heading
and Message Heading parts of the message.

c. "Message-ID" is clearly defined as a user application level field
and has been placed in the original message heading. A "Post-ID" field
has been defined for use at the "electronic post office" level.

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

1. Introduction.

RFC 822 is primarily concerned with "message content" header fields.
These header fields are primarily used for obtaining information
from the user (drafter of the message) to (a) permit the message to
be identified by other users (readers of the message); (b) obtain
addressing information to send the message.

This article introduces new header fields for use in the Postal Heading
of a message. The Postal Heading contains fields that are used by
"electronic post offices" to (a) identify the message being
sent, (b) supply relay (source routing) information to relaying
mail systems, and (c) record audit trail information.

In my first article I introduced a Basic Message Structure having
the following parts and sub-parts.

	HEADING		Transmission Heading
			Batch Heading
			Postal Heading
			Message Heading

	TEXT		Message Text (Body of Message)

	ENDING		Message Ending
			Postal Ending
			Batch Ending
			Transmission Ending

The Internet Text Message as currently defined by the "Standard for the
Format of ARPA Internet Text Messages" (RFC 822) has a heading and a
text. No ending is defined.  This article classifies RFC 822 header
fields into two groups, Message Heading and Postal Heading, and adds
additional fields for use in the Postal Heading. No attempt has been
made to define "Batch" or "Transmission" fields since these are more
the concern of the network and transport system being used.

2. Header Fields by Sub-Part and Component.



                        POSTAL HEADING

     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Postal        Postmark             Posted-Date:
     Heading                            Posted-From:
                                        Post-ID:
                                        Postmaster:

                   Return Field         Return-Path:

                   Relay Instructions   Relay-To:
                                        Do-Not-Relay-To:

                   Trace Fields         Received:
     _____________________________________________________



                        MESSAGE HEADING

     SUB-PART      COMPONENT            FIELD
     _____________________________________________________

     Readdressal   Date-Time            Resent-Date:
     Message
     Heading(s)    Originator's         Resent-From:
                   Address              Resent-Sender:
                                        Resent-Reply-To:

                   Originator's         Resent-Message-ID:
                   Message ID.

                   Precedence           Resent-Precedence:

                   Receiver's           Resent-To:
                   Address              Resent-cc:
                                        Resent-bcc:
                                        Resent-Exempt:
     _____________________________________________________

     Original      Date-Time            Date:
     Message
     Heading       Originator's         From:
                   Address              Sender:
                                        Reply-To:

                   Originator's         Message-ID:
                   Message ID.

                   Precedence           Precedence:

                   Receiver's           To:
                   Address              cc:
                                        bcc:
                                        Exempt:

                   Security             Classification:
                   Classification

                   Content              Subject:
                   Information          Keywords:
                                        In-Reply-To:
                                        References:

                   Encryption           Encrypted:
                   Field
     _____________________________________________________

     Heading       Comments             Comments:
     Comments      Field
     _____________________________________________________


Notes:

(a) Fields not defined  in  RFC  822  are:  Posted-Date,  Posted-From,
Post-ID,  Postmaster,  Relay-To,  Do-Not-Relay-To,  Resent-Precedence,
Precedence, Resent-Exempt, Exempt, Classification.  (Syntax of  postal
header  fields  is defined in my next article.) The order of sub-parts
differs from RFC 822 Article 4.1 in that "source" is defined as:

           source = [trace]
                    [resent]
                    originator

(b) Each sub-part of the heading begins with its  corresponding  date-
time  field.  Fields  pertaining  to one sub-part may not be placed in
another sub-part. With the exception  of  the  date-time  field  which
begins  the  sub-part,  the order of fields within the sub-part is not
defined.  However the above order is recommended.

(c) There may be none, one or more "readdressal message heading"  sub-
parts  in  the message heading. If there is more than one "readdressal
message heading" the later ones precede the earlier ones.

(d) "Relay-To" fields may be deleted by relaying  hosts  (MTA's)  when
delivery has been made (or protected) by that host.

(e) Relaying hosts will not make changes to the Message Heading within
an  Internet  mail  system  environment. Gateways to non-Internet mail
systems, may translate header fields into other formats.  However,  if
the  other  mail  system  is  incompatible  with Internet, the message
should be quoted in the text of the other systems message.   The  same
applies  to  incompatible messages being entered into an Internet mail
system.

(f) There may be only one "Date:", "From:",  "Sender:"  and  "Message-
ID:"  field per original message. Relaying hosts may not add or change
the "Message-ID" field.

(g) "Exempt" and "Resent-Exempt" fields are optional user fields  that
may be used with collective addresses to indicate that the drafter (or
user resending the message) does not want the message sent to  one  or
more addressees in the collective address.  Syntax is same as "To":

           exempt = "Exempt" ":" 1#address

           resent-exempt = "Resent-Exempt" ":" 1#address


Comments?

Bill Wells, RMC, USNR-R

topaz.wcwells@BERKELEY.ARPA

Computing Services, 297 Evans Hall,
University of California, Berkeley CA 94720


Date: 22 May 1983 2135-PDT (Sunday)
From: eric%UCBARPA@Berkeley (Eric Allman)
Subject: Re: Basic Message Format
Message-Id: <7070.31.422512549@ucbarpa>
Received: by UCBARPA.ARPA (3.342/3.29)
	id AA07071; 22 May 83 21:35:51 PDT (Sun)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29)
	id AA12954; 22 May 83 21:35:14 PDT (Sun)
Phone: (415) 548-3211
To: wcwells%Topaz.CC@Berkeley
Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley, MsgGroup@brl,
        header-people@mit-mc
In-Reply-To: Your message of 22 May 83 20:56:05 PDT (Sun).
             <8305230406.AA12603@UCBVAX.ARPA>
Fcc: mail

I have been quite interested by almost everything you have posted up
to this point.  Your description of the military message system was
extremely educational and was in my opinion at least somewhat apropos.
However, at this point I find your suggestions heavy on complexity
and low on benefit.  Although I agree that there is a real need, I
don't believe it requires as large a solution as you are proposing.
All computer types should be constantly on guard to insure that their
solutions of today do not become the problems of tomorrow.....

eric

Date: 23 May 83 02:36:01 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: Re: Basic Message Format
Message-Id: <8305230943.AA15251@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA15251; 23 May 83 02:43:57 PDT (Mon)
To: eric%ucbarpa@Berkeley
Cc: MsgGroup@brl, header-people@mit-mc


Eric,


Give me a while to discuss the "why's and wherefores" behind my heading
format, before you shoot the whole thing down. You may even like a few of
the ideas I have put out.

I realize I have put a lot out as once. With all the different terms and
phrases being used to discuss message formats, I felt it was necessary to
define the terms I am using.

Let's look at some of the idea's I have presented an idea at a time
and see if they are worth implimenting.

Best Regards.

Bill Wells
topaz.wcwells@BERKELEY.ARPA

Date:  23 May 1983 18:45 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Re: Basic Message Format
To:  wcwells%Topaz.CC at UCB-VAX
cc:  header-people at MIT-MC
In-Reply-To:  Message of 23 May 1983 05:33 est from wcwells%Topaz.CC

Re advisability of Mr Well's' proposals:
    I find myself in the annoying position of agreeing with *both* of
the last two speakers:  we should take extreme care that we do not add
complexity, since that multiplies difficulty (and probably "powers"
bugs). On the other hand I feel that we should deal with the problem in
as great a depth and breadth as possible, so as not to leave out
anything obvious or design out any required capabilities.
    I will therefore quote an associate's design strategy as a possible
approach:
  (1) Get as broad a list of desires (desired capabilities) as possible.
  (2) Debate the validity and advisability of each.
  (3) Select the most cohesive set as a desired end-point, making sure
that they are not "fuzzy" or have implications in other areas if
possible.
  (4) define a minimal proper subset of these
  (5) propose these as the target desgn, and the spanning set as the
intended aim.
  (5) argue.
  --dave

Date: 23 May 83 21:48:05 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: Basic Message Format
Message-Id: <8305240458.AA00342@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA00342; 23 May 83 21:58:49 PDT (Mon)
To: MsgGroup@brl, header-people@mit-mc
Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley


Date: 23 May 83 21:58:03 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: basic message format discussion
Message-Id: <8305240502.AA00413@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.29)
	id AA00413; 23 May 83 22:02:33 PDT (Mon)
To: header-people@mit-mc


To reduce the number of copies flying around out there, future
"Basic Message Format" messages will be sent only to the MsgGroup
mailing list.

Cheers.

Bill Wells
topaz.wcwells@BERKELEY


Date: 25 May 83 22:14:24 PST (Wed)
From: Stef.UCI@Rand-Relay
Return-Path: <Stef%UCI.UCI@Rand-Relay>
Subject: Re: Errors-To, round 2
To: POSTEL@Usc-Isif
Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay
In-Reply-To: Your message of 12 May 1983 2217-PDT.
Via:  UCI; 25 May 83 22:31-PDT

Having just reviewed all this discussion about Errors-To, round 2, I
have chosen to reply to Jon's original round 2 message to specifically
recall his two views:

"(1) that there are two separate mail transactions - (a) the author
sends a message to the exploder, and (b) the exploder send the message
to the list"; and

"(2) there is one transaction - the author sends the message to the list
via the exploder mailer as a relay."

Jon further explained: "In the first case, we would have in the first
transaction a path back to the author, but in the second transaction a
path bact to the exploder (perhaps even the list maintainer).  In the
second case we would have a path back to the author via the exploder
host."

And then Jon observed: "If the implementation were required to be the
first case, there might not be any call for any other mechanism such as
the suggested Errors-To."

I <Stef%uci@rand-relay> want to sound a loud call for adoption of Jon's
case 1, where the exploder is considered to be a user agent which has
taken posession of the item to be sent to a new list, and thus takes
responsibility for the results of the secondary and subsequent mailing,
just as though it were a new mailing.

We have been using this arangement at UCI since last Fall sometime, and
it works very well for us.  In addition, we are now implementing a
distribution serializer mechanism for our MMDF based ch_bboards channel
which will insert an X-DIST-ID: field with a unique value (if one is
not yet present), conforming to the 822 requirement that non-822 fields
be designated by an "X-" as the initial two field-name characters to
signal its non-822-ishness.  It should not be an 822 or 821 field!!!!!!

Our ch_bboards distributor will first look for the X-DIST-ID: field
because this might not be the "root" distributor for the distribution
net in question.  For example, MsgGroup@BRL is a root distributtor, but
when it gets to UCI-MSGGROUP@UCI it gets distributed again, just as it
gets redistributed by RAND-MSGGROUP@RAND-UNIX, and several other such
cases.  Our distributor will keep a log of reasonably recent items for
checking against new arrivals for whatever reasons.  A recent episode
of interest involved a loop out there in the Internet that sent us 34
copies of one item.  We would like to catch and avoid further
distribution of the extras in such cases.

Also, we simply solve the failed mail returns problem beyond our
distributor by putting a new SENDER: field in it before posting it as a
new item, which I claim it is, in fact.  As a User Agent, our
distributor assumes the right to do anything it wants to do, since it
is not bound the ethics or morality of the sanctity of the seal.

My argument is that these kinds of newsnet or groupmail distributions
must be removed from inside the 822/821 domain of MTAs, and placed in
the UA domain, regardless of what is to be done about any other aspect
of ERROR-TO arrangements for other mail.  This includes the case that
DPK mentions where a group of discussants identified in TO and CC
fields, may also copy a distribution list; Those who get their copy
direct are not effected, buth those who get it through the list are
effected, and properly so.

The fact that we might be using Ineternet and internet mail systems to
distribute group mail of various kinds should not be allowed to muck up
the already complicated problem of failed mail notification processes
and procedures.  Not separating them out can only add to the complexity
of our already over structured and over complex MTA environment.

By the way, our basic UCI ch_bboards software has already been given
over to DPK and CSnet for their use in any way they may wish.  It may
have unfortunately beeen misnamed as a "bboard" tool, but it is in fact
a User Agent distributor system that fits nicely into an MMDF channel
fitting.

You are cheerfully urged to seriously consider using this handy tool.

The X-DIST-ID: inserter is currently in development at UCI and will be
made available as soon as it is available, and after it passes muster
testing at UCI.

Best - Stef

Date: 24-May-83 22:54:33-UT
From: mills@dcn6
Subject: Re: message header formatî
To:   eric%UCBARPA@Berkeley(EricAllman), wcwells%Topaz.CC@Berkeley,
      cak@purdue, header-people@mit-mc

In response to your message sent 22 May 1983 1948-PDT (Sunday)î
hello

-------

Date: 26 May 1983 0600-PDT
From: MILLS at USC-ISID
Subject: Re: message header format
To:   mills at DCN6, eric%UCBARPA at BERKELEY,
To:   wcwells%Topaz.CC at BERKELEY, cak at PURDUE,
To:   header-people at MIT-MC
cc:   MILLS at USC-ISID, Tester at DCN5

In response to the message sent  24-May-83 22:54:33-UT from mills@dcn6

Folks,

Please excuse my previous message, which escaped during testing of our mail
system.

Regards,
Dave
-------

Date: 26 May 1983 0600-PDT
From: MILLS at USC-ISID
Subject: Re: message header format
To:   mills at DCN6, eric%UCBARPA at BERKELEY,
To:   wcwells%Topaz.CC at BERKELEY, cak at PURDUE,
To:   header-people at MIT-MC
cc:   MILLS at USC-ISID, Tester at DCN5

In response to the message sent  24-May-83 22:54:33-UT from mills@dcn6

Folks,

Please excuse my previous message, which escaped during testing of our mail
system.

Regards,
Dave
-------

Date: 26 May 1983 0600-PDT
From: MILLS at USC-ISID
Subject: Re: message header format
To:   mills at DCN6, eric%UCBARPA at BERKELEY,
To:   wcwells%Topaz.CC at BERKELEY, cak at PURDUE,
To:   header-people at MIT-MC
cc:   MILLS at USC-ISID, Tester at DCN5

In response to the message sent  24-May-83 22:54:33-UT from mills@dcn6

Folks,

Please excuse my previous message, which escaped during testing of our mail
system.

Regards,
Dave
-------

Date:     26 May 83 15:23:48 EDT (Thu)
From:     Doug Kingston <dpk@brl-vgr>
To:       Stef.UCI@rand-relay
cc:       POSTEL@usc-isif, header-people@mit-mc, stef.UCI@rand-relay
Subject:  Re:  Errors-To, round 2

	One must be careful about changing the Sender: field of the
message.  This makes it difficult/impossible for a recipient to reply
to the author of a mailing list message.  There appear to be three
classes of addresses for any message.  The original sender, the
recipients, and optionally an error return address if the message has
been redistributed.  At any one time there will be only one original
sender and one error return address.  The original sender should never
change, but the error return address should change whenever the letter
is redistributed.  The recipients do not change, and may be added to?

					Cheers,
						-Doug-


Date: 27 May 83 12:13:58 PST (Fri)
From: Stef.UCI@Rand-Relay
Return-Path: <Stef%UCI.UCI@Rand-Relay>
Subject: Re:  Errors-To, round 2
To: Doug Kingston <dpk@Brl>
Cc: POSTEL@Usc-Isif, header-people@Mit-Mc, stef.UCI@Rand-Relay
Via:  UCI; 27 May 83 14:30-PDT

The key and vital difference between Postel's Case 1 and Postel's Case
2 is that Case 1 clearly and unequivically casts redistribution in a
"User Agent's User" role which frees the distributor from problems with
"The Sanctity of The Seal."

DPK's admonition about changing the sender field falls in this
category.  In Case 1, the redistributed item is in fact a new posting
of material that was taken out of the MTS and is being sent as a new
piece of mail.  If you as a redistributor want to leave the sender
field as it is, that is your privilege, but this will mean that failed
mail beyond your redistribution point will return to the original
sender.  I can well imagine some cases where this will be correct, such
as with small collegial groups at BRL and elsewhere.

But, back to the technical issue, I expect that no matter how you try
to jigger things by creating an ERRORS-TO: field, that you will only
shift the identical argument to focus on the new field.  Whatever you
choose to call it, the Redistribution Agent must be allowed to change
it to divert error returns to some place other than the originator.
This discussion thus can go on forever, with proposals for
ERRORS-TO-PRIME: and ERRORS-TO-PRIME-PRIME: and
...ERRORS-TO-...-PRIME-PRIME:.

In a separate communication, I have been asked how I can claim that our
UCI ch_bboards mechanism can be called a User Agent when it is actually
implemented and installed as a real MMDF channel, which puts it at the
MTS peer level.  My answer to that is that it is the role that it
plays, and claims to play, that matters.  It reposts the message as a
new item with no claim of pristine preservation, and this is what
establishes what is right to do from what is wrong to do.

As implemented, our UCI ch_bboards will allow for the UCI Postmaster to
designate a Group Leader to control the behavior of the X-DIST-ID:
field generator for each Group Address.  This program, named DISTIZE,
will also allow other changes, like insertng a REPLY-TO: <groupname>,
or it could move the contents of a SENDER field into a REPLY-TO field
if it does not yet exist, or what ever.  (I think all this is planned?)
It will cerainly allow me to insert a serial accession number into the
SUBJECT field, such as MSGGROUP#2001.

As I see it, it should be up to each Groupmail Leader to decide things
like this because each group's needs may be different from others. Some
group leaders will do things better than others too, but that is not
our problem!  We must not impose our beliefs and values on them.

This is yet another reason to get redistribution of group mail out from
the clutches of 822/821.  Why should Groupmail Leaders be constrained
by a need to compromise on such issues when it is technically possible,
and even preferrable, to implement on the User Agent basis of Postel's
Case 1.

So, I will agree that when a Groupmail Leader decides to replace or
insert a SENDER field, this will cause major changes in the way things
work for that group.  But, I will further argue that it is not the
right or privilege of us hackers in the Internet to decide these things
for any Groupmail Leader.  It is our job here to enable the widest
possible variety of use for mail systems.

To me this means keeping mail simple and free of as many issues as
possible, which means pushing as many issues as possible out to the
User Agent level.  I for one have no interest in an expanded role for
the MTS!  Shades of the USPS and the Postal Workers Union!  Even they
do not object to independent mailing houses that do what is proposed
here.

In terms of the ISO OSI Model, this means that Groupmail and Newsnet
distribution should be done at a level above the User Agent peer level
by using the services of User Agents, with all the rights and
privileges of a User Agent User.  In this view, the Redistributor is a
peer of both the SENDER and the RECIPIENT.

In many ways, the UUCP Usenet Newsnet is the correct model because it
is cast in this mode, but it suffers from being outside the normal mail
channels.  What I propose thus is that we map the Usenet Newsnet model
over our Internet Mail Transfer System by simply using mail as a
carrier for Groupmail.

And one last note:  I do not mean to cast any aspesions on any of the
systems and mechanisms that we have known, loved, and used so heavily
over the last 5-7 years.  ITS COMSAT was a major advance when it was
invented, and it has been used to great advantage since.  And, it was
great when MMDF acquired a similar capability with its aliasing
facilities.  Likewise for XMAILR.  And, UUCP Newsnet has been a
powerful tool in its own doman.  What I see is that we are getting
smarter from our experience, and it is time now to simply fix some
problems that those inventions did not solve.

Onward!  Stef

Date: 27 May 1983 2032-PDT
From: POSTEL at USC-ISIF
Subject: Errors-To, round 3
To:   Header-People at 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 as 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 send
the message to the mailing 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.

Several people suggested other functions and capabilities
that would be nice but went beyond what i wanted, and sometimes beyond
what is reasonable to do in the current system (still, it would be
nice if ...).  I hope we can keep these in mind in the next time we build
a mail system, or have the chance to significantly change this one.

--jon.
-------

Date: 28 May 83 17:51:41 PDT (Sat)
From: wcwells%Topaz.CC@Berkeley
Subject: Re: Errors-To, round 2
Message-Id: <8305290101.AA08408@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA08408; 28 May 83 18:01:44 PDT (Sat)
To: stef.UCI@Rand-Relay
Cc: header-people@Mit-Mc

Stef,

	Date: 25 May 83 22:14:24 PST (Wed)
	From: Stef.UCI@Rand-Relay
	Subject: Re: Errors-To, round 2
	
	
	.... I <Stef%uci@rand-relay> want to sound a loud call for
	adoption of Jon's case 1, where the exploder is considered to
	be a user agent which has taken posession of the item to be
	sent to a new list, and thus takes responsibility for the
	results of the secondary and subsequent mailing, just as though
	it were a new mailing.
	
Stef, I agree with you on this one.  Life on the network will be
much simplier if we require mailing list "exploders" to generate new
messages with the "exploder" as the originator of the new message(s)
to addressees on their list(s).

One simple method for the "exploder" to use, would be to generate a
new heading and quote the received message in the text (body) of the
new message.  A compromise would be for the "exploder" to pass through
some of the header fields to the new message.  However, if the latter
is done, I think we should define a standard for what fields are
passed through and what fields may not be passed through.

On serialization of messages. In military communications a serialized
message sent to a collective address (eg. group mailing list) is called
a "General Message"; in Amateur Radio communications it is called a
"Bulletin".  Both of these serialized message have serial numbers
assigned by an user agent who is authorized to send messages to the
collective address (eg. the "exploder" of the list maintainer).

At the user level, a military general message is identified by its
title and a number consisting of a serial number and the calendar
year.  I think the Internet identification of mailing list messages
should be consistent with the method currently used by DOD to identify
general message.

Since all messages to a Internet mailing list must go through a "root
exploder" I suggest that we create a message heading field containing
identification of the mailing list and a serial number.  This "general
message designator" would be part of the header of the new message(s)
sent by the "root exploder". The same "general message designator"
would be used for all messages generated from the same root exploder
input message.

I suggest the following header field syntax:

	"General-Message-ID:" genmsg-title " " genmsg-number "/" year

where "genmsg-title" is the title of the general message (for Internet
mailing lists I think we should use the root exploder mailbox
as the title); genmsg-number is a serial number assigned by the
root exploder which is reset to "1" at the beginning of each
calendar year; and "year" is the 4-digit calendar year number.
For example:

	General-Message-ID: header-people@mit-mc.ARPA 153/1983

would be be the 153rd message submitted to "header-people@mit-mc"
in the calendar year 1983.

Adding a general message identifier at the "root exploder" has an
added advantage for user agent programs which are programmed to
handle general messages.  It permits duplicate messages to be
trapped even when they are being received from various message systems.
(I see it as the only way to eliminate the mailing list message that
has been entered into another message system, eg. USENET news, which
I may also guarding for messages.)

I agree that the checking for duplicate general message should be
done at a layer above the mail transport system, but not necessarily
by the user (reader of the message).  I think this is an appropriate
function for the "electronic post office" or "bulletin board"
programs to handle.

However, to get back to error handling, if we implement general message
serialization, at the user agent level we will also need to establish a
method of handling (a) skipped numbers, (b) duplicated numbers, and (c)
requests for retransmission of missed numbers. I think a set of
standard communication service messages would be appropriate. We might
want to even implement another mailbox associated with the root
exploder (eg. header-people-service@mit-mc) that would accept proforma
service message request for retransmission and automatically retransmit
the requested missing number message.  If the skipped number service
message from the root exploder included the last valid number sent and
the next valid number it could be used to handle the end of year number
change over (back to genmsg-number=1).

Regards,

Bill Wells
topaz.wcwells@BERKELEY

PS. I think we disagree on the definition of "user agent". I believe
that most of the header fields in RFC 822 are "user agent" fields.


Date: 28 May 83 18:47:53 PDT (Sat)
From: wcwells%Topaz.CC@Berkeley
Subject: Re:  Errors-To, round 2
Message-Id: <8305290157.AA08831@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA08831; 28 May 83 18:57:30 PDT (Sat)
To: Stef.UCI@Rand-Relay
Cc: header-people@mit-mc

In reply to:

	Date: 27 May 83 12:13:58 PST (Fri)
	From: Stef.UCI@Rand-Relay
	Subject: Re:  Errors-To, round 2
	
	"..... It is our job here to enable the widest
	possible variety of use for mail systems."
	
	"To me this means keeping mail simple and free of as many issues
	as possible, which means pushing as many issues as possible out
	to the User Agent level.  I for one have no interest in an
	expanded role for the MTS!"

Onward indeed! Now I think we are getting somewhere. Lets get those
"electronic post office" and "bulletin board" programs up and working.

One question though, do we want to provide for collective routing
indicators at the mail transport system level, or at a lower level?.
Or put it another way, should broadcast message transmission methods be
used to transmit messages to a large number of hosts to reduce the
number of messages being transmitted on the network?  By broadcasting,
I mean sending serialized messages with no reciept from individual
MTA's. Reliability is maintained by retransmitting the broadcast
message once after a certain time has elapsed, having receiving MTA's
log the last message received, and requesting missed numbers from the
broadcast MTA's.  Broadcasting assumes that at the network level, the
MTA's host is always listening for messages (packets?) sent to "all
hosts". -- Hmmm. That may not be workable.

Since SMTP uses the "receipt method" (all messages are receipted for),
perhaps we need a different message transport system for these types of
messages.

Bill Wells
topaz.wcwells@BERKELEY

Date: 28 May 83 23:43:21 PDT (Sat)
From: wcwells%Topaz.CC@Berkeley
Subject: Separation of the Envelope and Header
Message-Id: <8305290652.AA12977@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA12977; 28 May 83 23:52:26 PDT (Sat)
To: header-people@mit-mc



So far we have discussed separation of "envelope" header fields from
"content" header fields. We have also discussed the need for separation
of multiple resent message header fields. I think we should also
discuss separating audit-trail (trace) fields from non-audit-trail
fields "envelope" part of the heading. I have heard of one message
standard that is kind to the reader and puts the audit-trail information
at the bottom of the message (in a message ending).

I think the basic questions I am asking is: Where in the "envelope" part
of the heading should audit-trail information appear? Should audit-trail
information be separated from other header fields?

I suggest the following order of header fields if each resend of a
message is to be handled as a new message:

	Envelope Header Fields	Postal Envelope Information
				Audit Trail Information

	Content Header Fields	Resent Header Fields (nth resend)
					.
					.
					.
				Resent Header Fields (1st resend)
				Original Content Header Fields

However if we decide to include all previous transmission history
then the following might be more appropriate:

	Resent Heading (nth resend)	Postal Envelope Information (nth resend)
		.			Audit Trail Information (nth resend)
		.			Resent Header Fields (nth resend)
		.
	Resent Heading (1st resend)	Postal Envelope Information (1st resend)
					Audit Trail Information (1st resend)
					Resent Header Fields (1st resend)

	Original Heading		Original Content Header Fields
					Audit Trail Information (original)


Bill Wells
topaz.wcwells@BERKELEY

P.S. Yes I am saying the position of header fields should be significant.
Can anyone give a good reason why header fields should be in a random
order in an Internet message? 


Date: 29 May 83 02:35:18 PDT (Sun)
From: wcwells%Topaz.CC@Berkeley
Subject: Separation of the Envelope and Header
Message-Id: <8305290943.AA14680@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA14680; 29 May 83 02:43:36 PDT (Sun)
To: header-people@mit-mc


Whether or not we opt for a physical separation of "envelope" header
fields from "content" header fields, I think we should have a
functional separation. I would like to suggest that we classify
header fields to whether they are "envelope" or "content" header
fields, then apply the following rules:

	The user (and user level) programs may create "content" header
	fields and may be authorized to create some "envelope" fields.
	The "electronic post offices" may create "envelope" header
	fields, but may not create or change "content" header fields
	except that the "originating electronic post office"
	may expand addresses in "content" header fields to full
	domain names. (This does not prevent "electronic post offices"
	from using information in the "content" header fields.)

"Electronic post office" is my term for programs that function
below the user agent level (editing, filing, submitting to post
office) and the Mail Transport level (eg. SMTP). The "originating
electronic post office", in the case of Internet, is the first post
office type program entering the message into the Internet mail
environment.

To sum up, I think separation of "envelope" and "content"
header fields (and who can change them) needs to be clearly defined.

Bill Wells
topaz.wcwells@BERKELEY


Date: 29-May-83 13:33 PDT
From: RICH.GVT@OFFICE-3
Subject: Re: Errors-To, round 2
To: header-people@Mit-Mc
Message-ID: <[OFFICE-3]GVT-RICH-2I44H>

Let's remember that there can be more than one mailing-list "exploder" involved 
for any given [set of] message[s].  For efficiency purposes, we have the case 
where exploder #1 sends to some individuals and some additional exploders; the 
additional exloders then send to more individuals and possibly even to 
additional exploders, ad infinitum.  When this happens, either we'll be adding 
more levels of encapsulation, or every exploder will have to fiddle with the 
header again to change such fields as Sender, Resent-by, Errors-to, or whatever 
we end up deciding to put in the header to cover the general case of mailing 
list exloders.

-Rich


Date: 29 May 83 01:54:39 PST (Sun)
From: Stef.UCI@Rand-Relay
Return-Path: <Stef%UCI.UCI@Rand-Relay>
Subject: Groupmail distributor rules
To: wcwells%Topaz.CC@Ucb-Vax
Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay
In-Reply-To: Your message of 28 May 83 17:51:46 PDT 
	     <8305290100.AA08390@UCBVAX.ARPA>
Via:  UCI; 29 May 83 2:01-PDT

Hi Bill - Before we charge off and implement a whole bunch of things to
structure the world for group mail exploders, I would like to step back
to see if we need to do much of anything at all ...

As I see it, we should consider establishment of a newsnet-groupmail
RFC to specify some rules for exploders, who should be left to choose
among many alternatives.  These alternatives include simple forwarding
inside a fresh new message with or without digestification, or simple
redistribution (remailing) without any more modification than if the
exploder were any other normal recipient who remailed a message, or
redistribution with partial modification of the header fields.

The only thing I see as mandatory at this point is the X-DIST-ID: field
if one is not yet present in the message before explosion.  But, the
exploder should be free to do lots of things beyond that if it makes
sense for the purposes of a particular mail-group.

Remember, the exploder is operating from the same position as any other
user, but with a license from the originator to further distribute to a
list associated with the groupmail explosion address.  The license is
implied by the fact of the originator's posting of the message to the
groupmail submission address.  The exploder is only constained by the
contract if any that exists between the exploder and the group members.

For example, in military communications a serialized message can be
sent to a group mailing list address as a "General Message"; among
Amateur Radio folks it can be called a "Bulletin".  Any such messages
can have serial numbers assigned by any user agent who is authorized to
send messages to the collective address (eg. the "exploder" or the list
maintainer).  In each case, special fields can be established for the
group, or they can use regular defined fields as they wish, including
insertions into the SUBJECT or inclusion in the X-DIST-ID field.

Checking for duplicate messages should be done at the root exploder and
at subsequent exploders, at a layer above the mail transport system,
although there is certainly no way or reason to prevent any user from
guarding against groupmail duplicates.  I do not think this is an
appropriate function for the MTS to handle, though it does seem right
for a Bulletin Board User Agent program to guard against duplicates.

As I see it, exploders that serialize their distributions will simply
allow recipients to detect missed numbers and to request retransmission
of missed numbers.  I do not think a set of standard communication
service messages will be appropriate.  Perhaps a set of conventions
would be helpful, but I think these should be left to each group to
select.  As with the Military and Amateur Radio groups, they already
have conventions for handling their own business, and I am not prone to
tell them to change, or to attempt to negotiate a common set of
conventions for all groups.

As for your concern that we disagree on the definition of "User Agent"
we agree that most of the header fields in RFC 822 are "User Agent"
fields.  They are generally used to facilitate communication between
peer User Agents.  It is also true however that a few of the 822 fields
can be viewed as "envelope" fields, but I am not entirely sure that
this makes them "non-User-Agent" fields.  I tend to want my User Agent
to have access to the "envolope" fields attached to my received mail.
I see no reason to deny anyone access to the envelopes in which they
receive their mail.  I certainly would not be pleased if the USPS
conficated the envelopes, or obliterated what was written on them.

At this point I might should further clarify my views on MTS/UA/USER
relationships.  I see USERS communicating as peers, by utilizing the
services of a UAs which communicate at a peer level to serve other
USERS.  USERS employ conventions which could well be called a protocol.
They use a common agreed upon language (if they want to communicate),
and they use beginnings, and ending, and put sentences and paragraphs
in between, et al.  And, UAs use the services of the MTS with the
service interfaces defined at Posting and Delivery Slots.

I find it very useful to consider the USERs as just operating at a
level above the UA in the same way as any protocol uses services at the
next lower level of the OSI model.

And, just in case I have piqued your interest as to where the upper
limit might be, I would consider Diplomatic Protocols be the top level.
Diplomatic Protocols are what you use when you cannot even directly
signal to your peer level communicants!

No guarantee that Diplomatic Protocols work though, as recent history
has demonstrated.

Best - Stef




Date: 29 May 83 02:09:41 PST (Sun)
From: Stef.UCI@Rand-Relay
Return-Path: <Stef%UCI.UCI@Rand-Relay>
Subject: Re: Broadcasting and Flood Mail (Errors-To, round 2)
To: wcwells%Topaz.CC@Ucb-Vax
Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay
In-Reply-To: Your message of 28 May 83 18:47:46 PDT (Sat).
             <8305290155.AA08793@UCBVAX.ARPA>
Via:  UCI; 29 May 83 2:11-PDT

Per your question: "Do we want to provide for collective routing
indicators at the mail transport system level, or at a lower level?."

As I understand SMTP (not too perfectly) and XMAILER and MMDF, et al,
there are mechanisms for "bundling" between sites and nodes and all
that.

I think we need to be concerned about such things of course, to allow
for efficient transport carrier operations, but I don't see any need
for setting up special protocols at the MTS level for newsnets or
groupmail.  And, I do not see any need for a special system for "Flood
Mail" such as you described.

I think we can do much better with a web of exploders which each have
been given a list to send to.  Perhaps we can set up a general
broadcast web of this kind, but I am not sure how one might go about
controlling access to it unless it operated with secret addresses for
web nodes, or was programmed to only accept mail from certain
addresses.

There are some interesting ideas to be explored here, but I don't see
much need for trying to establish standards for it now.  I would prefer
to see what we can do with mail as it is now to learn more about what
might be needed next.

Best - Stef

Date: 30 May 83 00:02:27 PDT (Mon)
From: wcwells%Topaz.CC@Berkeley
Subject: Groupmail distributor rules
Message-Id: <8305300711.AA25281@UCBVAX.ARPA>
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA25281; 30 May 83 00:11:41 PDT (Mon)
To: stef.UCI@Rand-Relay
Cc: header-people@mit-mc


As a true user agent, prehaps all an exploder should do is quote the
received message in the text. For example:

	Date: XXXXXX
	From: Exploder-mailbox
	To:   group-list
	Subject: xxxxxxxxxxxxxxx
	Comments: The following message was received from ......
		  at ........

	Date: AAAAAAAA
	From: jkjkjkjkjkj
		etc.

Hmmm - That could make for a lot of header fields in the text.
I think that partial modification of the heading under a standard
set of rules might be the best way to go.

On the X-DIST-ID field. It may be mandatory for your branch of the
distribution tree but not necessarily mine. Let's give different
exploders some leeway.

On serialization at the root exploder.  I do not like insertion
into the subject file (it should be the same as the input message).
I prefer a separate field (such as "General-Message:") so the
serial number can be easily stored separately.

I agree with you on where the checking for duplicates should be done.

On requesting retransmission of missed numbers at the user level ---
A service message with a standard text will permit list maintainers
(and exploder?) to automate the retransmission process.

On "User Agent" fields --- I am not saying that users should not
be able to create "envelope" fields, but rather that there are
some that they should not (eg. audit-trail fields). That is
user creation of "envelope" and lower fields should be controlled.
---- In one military message system I know of, users are permitted
enter transport level signals. (It permits Communications personnel
to take care of lower level transmission problems and special cases
of message transmission. We keep the general user out of trouble by
only telling him about the four or so standard signals he can use.)

On your USER, UA and MTS levels. I am not sure where my "electronic
post-office" fits in.  It is either at the bottom of the UA layer or at
the top of the MTS layer. (I prefer to think of it as at the bottom of
the UA layer since I view the transport agent as an automated circuit
operator.)

Regards,

Bill Wells
topaz.wcwells@BERKELEY


Date: Mon 30 May 83 10:24:39-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: exploders, etc.
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)

     Here's some gasoline for the flames...

     Most of what I've read so far has been of the form of a technical
solution to some of the problems that exploder mailing lists generate.
One should also consider the management aspects of this issue.  Much
mail to exploder lists tends to be in the "junk mail" category.  It is
possible that management may be displeased to have programmer time
invested in engineering better support for junk mail.  In particular,
management may feel that the (well-documented) problems with exploders
are the proper and necessary price to pay for the luxury of having the
facility.
-------

Date: 30 May 83 13:10:40 EDT (Mon)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: BBoards and Usenet
Message-Id: <8305301710.AA17583@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA17583; 30 May 83 13:10:40 EDT (Mon)
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA29507; 30 May 83 10:30:11 PDT (Mon)
To: header-people@mit-mc.ARPA
Cc: stef%uci.uci@Rand-Relay.ARPA

The Usenet standard specifies a format for articles, much like 822.
(In fact, it's a restricted 822, and is 100% compatible.)  This (almost)
makes it practical to use ordinary mail to send news around.  However,
nobody sends news articles as plain ordinary mail, because there is no
Errors-To: field.  It's crazy to send an error message to the person who
posted the note when two sites have a problem with their link.  If this
debate establishes a universal standard solution to this problem, it
might be practical to use mail to transfer news.

As it is, you use whatever means you have available.  (Thus, there is no
821 or SMTP equivalent.)  Typically this means uux, but over the ARPANET,
the message is encapsulated (into a clean envelope, if you like) and sent
as mail.  The other end opens the envelope, throws it away, and processes
the news article.  (The article contains its own RFC 822 style headers,
which are independent of those on the envelope.)  If there is any chance
that the mail system will mung the headers in the wrong way, or muck with
the body of the article, then the envelope strategy will probably continue
to be used.

Another issue is batching.  There is a high volume of news running around
over low bandwidth phone lines.  It turns out to be a real win to batch
20 or so articles into one package and ship them all over at once.  For
performance reasons, it may be a bad idea to change to mail unless mail
gets batched as well.  (But often people expect instant delivery of mail.)

A beauty of Usenet (which, incidently, is not UUCP based - it runs on
lots of non-UUCP machines) is that individual sites can experiment with
news transfer methods without affecting the net.  This is because it isn't
necessary for every machine to talk directly to every other machine; each
machine has only a few (3 or so) direct neighbors to talk to.  So experiments
require the cooperation of only a few sites.  Very few fields need
to be touched in transferring news, and the touching is simple.  So if
Stef wants to establish a new transfer mechanism (within the Usenet standard)
using MMDF, it shouldn't hurt the rest of the net while he experiments,
and there is no need to force everyone to convert.  However, I do urge
him to get a copy of the standard and join Usenet.

	Mark

Date: 30 May 83 13:19:48 EDT (Mon)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Usenet news standard
Message-Id: <8305301719.AA17662@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA17662; 30 May 83 13:19:48 EDT (Mon)
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA29522; 30 May 83 10:30:40 PDT (Mon)
To: header-people@mit-mc.ARPA

There is a standard for Usenet format.  I would be happy to mail it
to this list, if everyone wants (it's 20 pages long) or to Jon for
entry as an RFC.  It's already been discussed at length on Usenet
and adopted by Usenet as the standard.  It corresponds to RFC 822.

	Mark

Date: 30 May 83 12:33:47 PST (Mon)
From: Stef.UCI@Rand-Relay
Return-Path: <Stef%UCI.UCI@Rand-Relay>
Subject: Re: Groupmail distributor rules
To: wcwells%Topaz.CC@Ucb-Vax
Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay
In-Reply-To: Your message of 30 May 83 00:02:33 PDT (Mon).
             <8305300710.AA25259@UCBVAX.ARPA>
Via:  UCI; 30 May 83 13:38-PDT

Hi Bill - Lets first deal with the confusion about what an "electronic
post office" might be.  I see it as being very simply segregated.

If something is a User Agent Function, it is not in the Post Office.

In my model, the Post Office operates the circuits, and is fully
responsible for mail items between the Posting Slot and the Delivery
Slot, just like the USPS.  I strongly favor close funtional
correlations between the USPS and our Electronic Post Office.

This simplifies many decisions about what is right and what is wrong to
do.  If the USPS delivers something to me, it is then mine and I can do
with it whatever is right according to the rules of ownership of that
item.  If it is copyrighted, then I am limited by copyright rules.  If
I am under contract in some way to protect it from disclosure, then I
must do so.  But note that these constaints have nothing to do with
postal service rules, electronic, hydraulic, or paper based.

Next, I do not want to force any exploder to either enclose, or not
enclose, each distribted item down inside the body of a new message.
Digestifiers will want to enclose in such a way that undigestifiers can
unenclose for recipients, all at the User Agent Level.  Some groups
will want single messages enclosed, and other groups will not.  I see
no reason to dictate either way.  But, if items are enclosed, then the
normal User Agent tools for deaing with the items will be hard to use
unless the tools include an unencloser or undigestifier.

MsgGroup items have been archived since 1975 with MSGGROUP#nnnn
insertions in their subject fields.  Long ago, before COMSAT
distribution, I used to manually insert and manually REMAIL each item,
so list recipients would have the numbers to use for citation puposes.
The advanced technology of COMSAT took that away from us because COMSAT
needs to adhere to the rules of the Sanctity of the Seal.  However, as
the MSGRROUP Moderator, I had long before established that my SUBJECT
field insertion was a good thing to do, and the subscribers seemed to
like it, so I have continued to do the insertion for the archives,
after distribution.  I feel that deciding about such things should be
left to the affected groups to reflect their own needs and values.

And last, I don't see any need for your exploder to use my chosen
X-DIST-ID field if you do not want to, but if you then want to
distribute my MsgGroup mail with your distributor, you may have to
forego some useful functionality.  This can be your choice.  It will
only affect you and your distributees.  It cannot effect what I do.  If
my exploder encounters one of your distribution items, it will just
insert an X-DIST-ID anyway, unless one already exists.

I think there is room to negotiate about the name to be used for my
X-DIST-ID function, but I think that my choice is as good as any other.
It is reasonably short and descrtiptive of its purpose.  It is named to
avoid conflicts with future new 822 or 821 fields.  It is not misnamed
as it would be if called NEWSID or GROUPID. Etc, et al ...  In choosing
it, we beat around a number of other choices, but did not find anything
that seems to fit better than X-DIST-ID, so we stuck with it.

If you want to mount a naming contest, that is fine with me.  My entry
is X-DIST-ID.  Until I or someone with greater authority (like the
project programmer) chooses to use something else, our code will
continue to use it.  Democracy may be fun, but explorers get to name
their discoveries.  Arguments to the contrary are OK, but lets not
waste too much time and effort on them.

Best - Stef

Date: 31 May 83 13:42:53 EDT (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Usenet standard text (19 page long message)
Message-Id: <8305311742.AA00585@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA00585; 31 May 83 13:42:53 EDT (Tue)
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA01339; 31 May 83 14:52:35 PDT (Tue)
To: header-people@mit-mc.ARPA

I have received several requests for the text of the Usenet standard,
so I am mailing it to header-people.  Apologies in advance if the long
message breaks any mailers.  The document is formatted for a line printer,
using CR to overstrike.  I hope this won't cause any problems.

Note that this standard has already been discussed on and adopted by Usenet.
Since it is a news standard, not a mail standard, header-people (and msggroup
and namedroppers) was not the appropriate forum.  While there is always room
for a future document which is different from this one, I'd like to mention
that this is NOT a draft, and is not subject to revisions in this version.
In particular, software conforming to this standard has already been released
and is running on many Usenet sites.  Expositional comments (alas, I noticed
some typos in skimming it just now) and ideas for future improvements are
always welcome.

	Mark




                 Standard for Interchange of USENET Messages

                                Mark R. Horton




          1.  Introductionî              Introductionî              Introductionî              Introduction

          This document defines the standard format for  interchange
          of Network News articles among USENET sites.  It describes
          the format for  articles  themselves,  and  gives  partial
          standards for transmission of news.  The news transmission
          is not entirely standardized in order to give a good  deal
          of   flexibility   to   the  individual  hosts  to  choose
          transmission hardware and software, whether to batch news,
          and so on.

          There are five sections to  this  document.   Section  two
          section  defines  the  format.   Section three defines the
          valid control messages.  Section four specifies some valid
          transmission  methods.  Section five describes the overall
          news propagation algorithm.


          2.  Article Formatî              Article Formatî              Article Formatî              Article Format

          The primary consideration in choosing an article format is
          that  it  fit  in with existing tools as well as possible.
          Existing tools include both implementations  of  mail  and
          news.   (The  notesfiles  system  from  the  University ofî                        __________
          Illinois is considered a news implementation.) A  standard
          format for mail messages has existed for many years on the
          ARPANET, and this  format  meets  most  of  the  needs  of
          USENET.    Since   the   ARPANET   format  is  extensible,
          extensions to meet the  additional  needs  of  USENET  are
          easily  made  within the ARPANET standard.  Therefore, the
          rule is adopted that all  USENET  news  articles  must  be
          formatted as valid ARPANET mail messages, according to the
          ARPANET  standard  RFC  822.   This   standard   is   more
          restrictive  than the ARPANET standard, placing additional
          requirements on each article and forbidding use of certain
          ARPANET  features.   However, it should always be possible
          to use a tool expecting an ARPANET message  to  process  a
          news  article.   In  any  situation  where  this  standard
          conflicts with the ARPANET standard,  RFC  822  should  be
          considered correct and this standard in error.

          An example message is included to illustrate the fields.

















                                    - 2 -



               Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
               Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
               Path: cbosgd!mhuxj!mhuxt!eagle!jerry
               From: jerry@eagle.uucp (Jerry Schwarz)
               Newsgroups: net.general
               Subject: Usenet Etiquette -- Please Read
               Message-ID: <642@eagle.UUCP>
               Date: Friday, 19-Nov-82 16:14:55 EST
               Followup-To: net.news
               Expires: Saturday, 1-Jan-83 00:00:00 EST
               Date-Received: Friday, 19-Nov-82 16:59:30 EST
               Organization: Bell Labs, Murray Hill

               The body of the article comes here, after a blank line.

          Here is an example of a message in the old format  (before
          the  existence  of this standard).  It is recommended that
          implementations also accept articles  in  this  format  to
          ease upward conversion.

               From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
               Newsgroups: net.general
               Title: Usenet Etiquette -- Please Read
               Article-I.D.: eagle.642
               Posted: Fri Nov 19 16:14:55 1982
               Received: Fri Nov 19 16:59:30 1982
               Expires: Mon Jan  1 00:00:00 1990

               The body of the article comes here, after a blank line.

          Some news systems transmit news in the ``A'' format, which
          looks like this:

               Aeagle.642
               net.general
               cbosgd!mhuxj!mhuxt!eagle!jerry
               Fri Nov 19 16:14:55 1982
               Usenet Etiquette - Please Read
               The body of the article comes here, with no blank line.

          An article consists of several header lines, followed by a
          blank  line,  followed  by  the  body of the message.  The
          header lines consist of a keyword, a colon, a  blank,  and
          some  additional  information.   This  is  a subset of the
          ARPANET standard, simplified to allow simpler software  to
          handle  it.   The  ``from''  line may optionally include a
          full name, in the format above, or use the  ARPANET  angle
          bracket syntax.  To keep the implementations simple, other
          formats (for example, with part  of  the  machine  address
          after the close parenthesis) are not allowed.  The ARPANET
          convention of continuation header lines (beginning with  a











                                    - 3 -



          blank or tab) is allowed.

          Certain  headers  are  required,   certain   headers   are
          optional.   Any unrecognized headers are allowed, and will
          be passed through unchanged.   The  required  headers  are
          Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
          Subject,  Message-ID,  Path.   The  optional  headers  are
          Followup-To,  Date-Received,  Expires,  Reply-To,  Sender,
          References, Control, Distribution, Organization.

          2.1  Required Headersî               Required Headersî               Required Headersî               Required Headers

          2.1.1  Relay-Version  This header line shows  the  versionî                 _____________
          of  the  program  responsible for the transmission of this
          article over the immediate link, that is, the program that
          is  relaying the article from the next site.  For example,
          suppose site A sends an article to  site  B,  and  site  B
          forwards  the  article  to  site  C.   The  message  being
          transmitted from A to B would have a Relay-Version  header
          identifying  the  program  running  on  A, and the message
          transmitted from B to C would identify the program running
          on  B.  This header can be used to interpret older headers
          in an upward compatible way.  Relay-Version must always be
          the  first  in  a message; thus, all articles meeting this
          standard will begin with an upper case  ``R''.   No  other
          restrictions are placed on the order of header lines.

          The line contains two  fields,  separated  by  semicolons.
          The fields are the version and the full domain name of the
          site.  The version should identify the system program used
          (e.g.,  ``B'')  as  well  as  a version number and version
          date.  For example, the header line might contain

               Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

          This header should not be passed on to  additional  sites.
          A  relay  program,  when  passing  an  article  on, should
          include only its own Relay-Version, not the  Relay-Version
          of  some other site.  (For upward compatibility with older
          software, if a Relay-Version is found in a header which is
          not the first line, it should be assumed to be moved by an
          older version of news and deleted.)

          2.1.2  Posting-Version    This   header   identifies   theî                 _______________
          software  responsible  for  entering this message into the
          network.  It has the same  format  as  Relay-Version.   It
          will  normally  identify  the same site as the Message-ID,
          unless the posting site is serving  as  a  gateway  for  a
          message  that  already  contains a message ID generated by
          mail.  (While it is permissible for a gateway  to  use  an
          externally  generated message ID, the message ID should be











                                    - 4 -



          checked to ensure it conforms to this standard and to  RFC
          822.)

          2.1.3  From  The From line contains the electronic mailingî                 ____
          address  of  the  person who sent the message, in the ARPA
          internet syntax.  It may optionally also contain the  full
          name  of  the person, in parentheses, after the electronic
          address.  The electronic address is the same as the entity
          responsible for originating the article, unless the Sender
          header is present, in which case the From header might not
          be  verified.   Note  that  in  all site and domain names,
          upper  and  lower  case  are  considered  the  same,  thus
          mark@cbosgd.UUCP,  mark@cbosgd.uucp,  and mark@CBosgD.UUcp
          are all equivalent.  User names may or  may  not  be  case
          sensitive,   for   example,   Billy@cbosgd.UUCP  might  be
          different from BillY@cbosgd.UUCP.  Programs  should  avoid
          changing  the case of electronic addresses when forwarding
          news or mail.

          RFC 822 specifies that all text in parentheses  is  to  be
          interpreted as a comment.  It is common in ARPANET mail to
          place the full name of the user in a comment at the end of
          the  From  line.   This  standard  specifies  a more rigid
          syntax.  The full name is not considered a comment, but an
          optional part of the header line.  Either the full name is
          omitted, or it appears in parentheses after the electronic
          address  of  the person posting the article, or it appears
          before an electronic address enclosed in  angle  brackets.
          Thus, the three permissible forms are:

               From: mark@cbosgd.UUCP
               From: mark@cbosgd.UUCP (Mark Horton)
               From: Mark Horton <mark@cbosgd.UUCP>

          Full names may contain any printing ASCII characters  from
          space through tilde, with the exceptions that they may not
          contain parentheses ``(''  or  ``)'',  or  angle  brackets
          ``<''  or ``>''.  Additional restrictions may be placed on
          full names  by  the  mail  standard,  in  particular,  the
          characters  comma  ``,'', colon ``:'', and semicolon ``;''
          are inadvisable in full names.

          2.1.4  Date  The Date line (formerly  ``Posted'')  is  theî                 ____
          date,  in  a  format  that  must be acceptable both to the
          ARPANET and to the getdate routine, that the  article  was
          originally  posted  to  the  network.   This  date remains
          unchanged as the  article  is  propagated  throughout  the
          network.  One format that is acceptable to both is

               Weekday, DD-Mon-YY HH:MM:SS TIMEZONE












                                    - 5 -



          Several examples of  valid  dates  appear  in  the  sample
          article above.  Note in particular that ctime format:

               Wdy Mon DD HH:MM:SS YYYY

          is not acceptable because it is not a valid ARPANET  date.î             ___
          However, since older software still generates this format,
          news implementations are encouraged to accept this  format
          and translate it into an acceptable format.

          The contents of the TIMEZONE field is currently subject to
          revision.   Eventually,  we  hope  to  accept all possible
          worldwide time zone  abbreviations,  including  the  usual
          American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
          the   other   North   American   zones   (Bering   through
          Newfoundland),  European  zones,  Australian zones, and so
          on.  Lacking a complete list at present (and unsure if  an
          unambiguous   list   exists),   authors  of  software  are
          encouraged to keep this code flexible, and  in  particular
          not  to  assume  that  time  zone  names are exactly three
          letters long.   Implementations  are  free  to  edit  this
          field,  keeping  the  time the same, but changing the time
          zone (with an appropriate adjustment  to  the  local  time
          shown) to a known time zone.

          2.1.5  Newsgroups  The  Newsgroups  line  specifies  whichî                 __________
          newsgroup  or newsgroups the article belongs in.  Multiple
          newsgroups  may  be  specified,  separated  by  a   comma.
          Newsgroups  specified  must  all  be the names of existing
          newsgroups, as no new newsgroups will be created by simply
          posting to them.

          Wildcards (e.g., the word ``all'') are never allowed in  a
          Newsgroups  line.  For example, a newsgroup ``net.all'' is
          illegal, although a newsgroup name  ``net.sport.football''
          is permitted.

          If an article is received with a Newsgroups  line  listing
          some  valid newsgroups and some invalid newsgroups, a site
          should  not  remove  invalid  newsgroups  from  the  list.
          Instead,  the  invalid  newsgroups should be ignored.  For
          example,  suppose  site  A  subscribes  to   the   classes
          ``btl.all''  and  ``net.all'', and exchanges news articles
          with site B,  which  subscribes  to  ``net.all''  but  not
          ``btl.all''.    Suppose   A   receives   an  article  with
          ``Newsgroups: net.micro,btl.general''.   This  article  is
          passed  on  to  B because B receives net.micro, but B does
          not receive btl.general.  A must leave the Newsgroup  line
          unchanged.   If  it  were  to  remove ``btl.general'', the
          edited header could  eventually  reenter  the  ``btl.all''
          class,  resulting in an article that is not shown to users











                                    - 6 -



          subscribing  to  ``btl.general''.   Also,  followups  from
          outside ``btl.all'' would not be shown to such users.

          2.1.6  Subject   The  Subject  line  (formerly  ``Title'')î                 _______
          tells  what the article is about.  It should be suggestive
          enough of the contents of the article to enable  a  reader
          to  make  a  decision whether to read the article based on
          the  subject  alone.   If  the  article  is  submitted  in
          response  to another article (e.g., is a ``followup'') the
          default subject should  begin  with  the  four  characters
          ``Re:  ''  and the References line is required.  (The user
          might wish to edit the subject of the  followup,  but  the
          default should begin with ``Re: ''.)

          2.1.7  Message-ID  The Message-ID line gives the article aî                 __________
          unique  identifier.  The same message ID may not be reused
          during the lifetime of any article with the  same  message
          ID.   (It  is recommended that no message ID be reused for
          at least two years.) Message ID's have the syntax

               "<" "string not containing blank or >" ">"

          In order to conform to RFC 822, the Message-ID  must  have
          the format

               "<" "unique" "@" "full domain name" ">"

          where ``full domain name'' is the full name of the host at
          which  the article entered the network, including a domain
          that host is in, and unique  is  any  string  of  printing
          ASCII  characters,  not  including  "<", ">", or "@".  For
          example,  the  "unique"   part   could   be   an   integer
          representing  a  sequence number for articles submitted to
          the network, or a short string derived from the  date  and
          time  the article was created.  For example, valid message
          ID for an article submitted from  site  ucbvax  in  domain
          Berkeley.ARPA   would   be  "<4123@ucbvax.Berkeley.ARPA>".
          Programmers are urged not to make  assumptions  about  the
          content  of  message  ID  fields  from other hosts, but to
          treat them as unknown character strings.  It is not  safe,
          for  example, to assume that a message ID will be under 14
          characters,  nor  that  it  is  unique  in  the  first  14
          characters.

          The angle brackets are considered part of the message  ID.
          Thus,  in  references  to  the  message  ID,  such  as the
          ihave/sendme  and  cancel  control  messages,  the   angle
          brackets  are  included.   White  space  characters (e.g.,
          blank and tab) are not  allowed  in  a  message  ID.   All
          characters  between  the  angle  brackets must be printing
          ASCII characters.











                                    - 7 -



          2.1.8  Path  This line shows the path the article took  toî                 ____
          reach  the  current  system.   When  a system forwards the
          message, it should add its own name to the list of systems
          in  the  Path  line.   The  names  may be separated by any
          punctuation     character     or     characters,      thus
          ``cbosgd!mhuxj!mhuxt'',   ``cbosgd,  mhuxj,  mhuxt'',  and
          ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp''     and      even
          ``teklabs,   zehntel,   sri-unix@cca!decvax''   are  valid
          entries.  (The latter path indicates a message that passed
          through  decvax,  cca,  sri-unix, zehntel, and teklabs, in
          that order.) Additional names should  be  added  from  the
          left,  for  example,  the  most recently added name in the
          third example was ``teklabs''.  Letters,  digits,  periods
          and  hyphens  are  considered  part  of  site names; other
          punctuation, including blanks, are considered separators.

          Normally, the rightmost name  will  be  the  name  of  the
          originating  system.   However,  it is also permissible to
          include an extra entry on the right, which is the name  of
          the  sender.   This is for upward compatibility with older
          system.

          The Path line is not used for replies, and should  not  be
          taken  as  a  mailing address.  It is intended to show the
          route the message  travelled  to  reach  the  local  site.
          There  are  several  uses for this information.  One is to
          monitor USENET routing for performance  reasons.   Another
          is  to  establish  a path to reach new sites.  Perhaps the
          most important is to cut down on redundant USENET  traffic
          by failing to forward a message to a site that is known to
          have already received it.   In  particular,  when  site  A
          sends  an article to site B, the Path line includes ``A'',
          so that site B will not immediately send the article  back
          to  site  A.   The  site  name  each site uses to identify
          itself should be  the  same  as  the  name  by  which  its
          neighbors  know  it,  in  order  to make this optimization
          possible.

          A site adds its own name to the front of a  path  when  it
          receives  a message from another site.  Thus, if a message
          with path A!X!Y!Z is passed from site A to site B, B  will
          add  its own name to the path when it receives the message
          from A, e.g., B!A!X!Y!Z.  If B then passes the message  on
          to  C,  the  message  sent  to  C  will  contain  the path
          B!A!X!Y!Z, and when C receives it, C  will  change  it  to
          C!B!A!X!Y!Z.

          Special upward compatibility note: Since the From, Sender,
          and  Reply-To lines are in internet format, and since many
          USENET  sites  do  not  yet  have   mailers   capable   of
          understanding  internet  format,  it would break the reply











                                    - 8 -



          capability to completely sever the connection between  the
          Path  header  and  the  reply  function.   Thus, sites are
          required to continue to keep the Path line  in  a  working
          reply  format  as much as possible, until January 1, 1984.
          It is recognized that the path is not always a valid reply
          string in older implementations, and no requirement to fix
          this problem is placed on implementations.   However,  the
          existing  convention of placing the site name and an ``!''
          at the front of the path, and of starting  the  path  with
          the  site  name,  an  ``!'',  and the user name, should be
          maintained at least until 1984.

          2.2  Optional Headersî               Optional Headersî               Optional Headersî               Optional Headers

          2.2.1  Reply-To  This line has the same  format  as  From.î                 ________
          If present, mailed replies to the author should be sent to
          the name given here.  Otherwise, replies are mailed to the
          name  on the From line.  (This does not prevent additional
          copies from being sent to recipients named by the replier,
          or  on  To  or  Cc lines.) The full name may be optionally
          given, in parentheses, as in the From line.

          2.2.2  Sender  This field is present only if the submitterî                 ______
          manually enters a From line.  It is intended to record the
          entity responsible  for  submitting  the  article  to  the
          network,  and  should  be  verified by the software at the
          submitting site.

          For example, if John Smith is visiting CCA and  wishes  to
          post  an  article to the network, using friend Sarah Jones
          account, the message might read

               From: smith@ucbvax.uucp (John Smith)
               Sender: jones@cca.arpa (Sarah Jones)

          If a gateway  program  enters  a  mail  message  into  the
          network at site sri-unix, the lines might read

               From: John.Doe@CMU-CS-A.ARPA
               Sender: network@sri-unix.ARPA

          The primary purpose of this field is to be able  to  track
          down  articles to determine how they were entered into the
          network.  The  full  name  may  be  optionally  given,  in
          parentheses, as in the From line.

          2.2.3  Followup-To  This  line  has  the  same  format  asî                 ___________
          Newsgroups.   If  present,  follow-up  articles  are to be
          posted to the newsgroup(s) listed here.  If this  line  is
          not  present,  followups  are  posted  to the newsgroup(s)
          listed in the Newsgroups line, except  that  followups  to











                                    - 9 -



          ``net.general'' should instead go to ``net.followup''.

          2.2.4  Date-Received  This line (formerly ``Received'') isî                 _____________
          in  a  legal  USENET date format.  It records the date and
          time that the article was  first  received  on  the  local
          system.   If  this  line  is  present  in an article being
          transmitted from one host to another, the  receiving  host
          should  ignore  it  and  replace it with the current date.
          Since this field is intended for local use only,  no  site
          is  required  to support it.  However, no site should pass
          this field on to another site unchanged.

          2.2.5  Expires  This line,  if  present,  is  in  a  legalî                 _______
          USENET  date  format.  It specifies a suggested expiration
          date for the article.  If not present, the  local  default
          expiration date is used.

          This field is intended to be used  to  clean  up  articles
          with  a  limited usefulness, or to keep important articles
          around for longer than  usual.   For  example,  a  message
          announcing  an  upcoming  seminar could have an expiration
          date the day after the seminar, since the message  is  not
          useful  after the seminar is over.  Since local sites have
          local  policies  for  expiration  of  news  (depending  on
          available disk space, for instance), users are discouraged
          from providing expiration dates for articles unless  there
          is  a  natural  expiration date associated with the topic.
          System software should  almost  never  provide  a  default
          Expires line.  Leave it out and allow local policies to be
          used unless there is a good reason not to.

          2.2.6  References  This field lists the  message  ID's  ofî                 __________
          any articles prompting the submission of this article.  It
          is required for all follow-up articles, and forbidden when
          a new subject is raised.  Implementations should provide a
          follow-up command, which allows a user to post a follow-up
          article.   This  command  should  generate  a Subject line
          which is the same as the original article, except that  if
          the original subject does not begin with ``Re: '' or ``re:
          '', the four characters ``Re: '' are inserted  before  the
          subject.   If  there is no References line on the original
          header, the References line should contain the message  ID
          of  the  original  article (including the angle brackets).
          If the original article does have a References  line,  the
          followup  article should have a References line containing
          the text of the original References line, a blank, and the
          message ID of the original article.

          The purpose of the References header is to allow  articles
          to  be  grouped  into  conversations by the user interface
          program.  This allows conversations within a newsgroup  to











                                    - 10 -



          be  kept  together,  and  potentially users might shut off
          entire conversations without unsubscribing to a newsgroup.
          User  interfaces  may not make use of this header, but all
          automatically  generated  followups  should  generate  the
          References line for the benefit of systems that do use it,
          and manually generated followups (e.g. typed in well after
          the  original  article  has  been  printed by the machine)
          should be encouraged to include them as well.

          2.2.7  Control  If an article contains a Control line, theî                 _______
          article  is  a control message.  Control messages are used
          for communication among USENET host machines,  not  to  be
          read  by  users.   Control messages are distributed by the
          same newsgroup mechanism as ordinary messages.   The  body
          of the Control header line is the message to the host.

          For  upward  compatibility,  messages   that   match   the
          newsgroup   pattern   ``all.all.ctl''   should   also   be
          interpreted as control messages.  If no Control: header is
          present  on  such  messages,  the  subject  is used as the
          control message.  However, messages on newsgroups matching
          this pattern do not conform to this standard.

          2.2.8  Distribution   This  line  is  used  to  alter  theî                 ____________
          distribution scope of the message.  It has the same format
          as the Newsgroups  line.   User  subscriptions  are  still
          controlled  by  Newsgroups, but the message is sent to all
          systems subscribing to the newsgroups on the  Distribution
          line instead of the Newsgroups line.  Thus, a car for sale
          in New Jersey might have headers including

               Newsgroups: net.auto,net.wanted
               Distribution: nj.all

          so that  it  would  only  go  to  persons  subscribing  to
          net.auto  or  net.wanted within New Jersey.  The intent of
          this header is to further restrict the distribution  of  a
          newsgroup, not to increase it.  A local newsgroup, such as
          nj.crazy-eddie, will probably not be propagated  by  sites
          outside  New  Jersey  that do not show such a newsgroup as
          valid.  Wildcards in newsgroup names in  the  Distribution
          line are allowed.  Followup articles should default to the
          same Distribution line as the original  article,  but  the
          user  can change it to a more limited one, or escalate the
          distribution if it was originally restricted  and  a  more
          widely distributed reply is appropriate.

          2.2.9  Organization  The text of  this  line  is  a  shortî                 ____________
          phrase  describing  the  organization  to which the sender
          belongs, or to which the machine belongs.  The  intent  of
          this  line  is  to  help  identify  the person posting the











                                    - 11 -



          message, since site names are often cryptic enough to make
          it  hard  to  recognize the organization by the electronic
          address.


          3.  Control Messagesî              Control Messagesî              Control Messagesî              Control Messages

          This section lists the control messages currently defined.
          The  body  of  the  Control header is the control message.
          Messages are a sequence of zero or more  words,  separated
          by  white  space  (blanks or tabs).  The first word is the
          name  of  the  control  message,   remaining   words   are
          parameters  to  the  message.  The remainder of the header
          and the body of the message are also potential parameters;
          for  example,  the  From  line might suggest an address to
          which a response is to be mailed.

          Implementors  and  administrators  may  choose  to   allow
          control  messages  to  be automatically carried out, or to
          queue  them  for  manual  processing.   However,  manually
          processed messages should be dealt with promptly.

          3.1  Cancelî               Cancelî               Cancelî               Cancel

               cancel <message ID>

          If an article with the given message ID is present on  the
          local  system,  the  article is cancelled.  This mechanism
          allows a user to cancel an article after the  article  has
          been distributed over the network.

          Only the author of the article or the local super user  is
          allowed  to  use  this  message.  The verified sender of a
          message is the Sender  line,  or  if  no  Sender  line  is
          present, the From line.  The verified sender of the cancel
          message must be the same as  either  the  Sender  or  From
          field  of  the original message.  A verified sender in the
          cancel message is allowed to match an unverified  From  in
          the original message.

          3.2  Ihave/Sendmeî               Ihave/Sendmeî               Ihave/Sendmeî               Ihave/Sendme

               ihave <message ID list> <remotesys>
               sendme <message ID list> <remotesys>

          This message is part  of  the  ``ihave/sendme''  protocol,
          which  allows  one  site  (say ``A'') to tell another site
          (``B'') that a particular message has been received on  A.
          Suppose  that site A receives article ``ucbvax.1234'', and
          wishes to transmit the article to site  B.   A  sends  the
          control  message  ``ihave  ucbvax.1234  A''  to site B (by











                                    - 12 -



          posting it to newsgroup ``to.B'').  B  responds  with  the
          control  message  ``sendme  ucbvax.1234  B'' (on newsgroup
          to.A) if it has not already received  the  article.   Upon
          receiving the Sendme message, A sends the article to B.

          This protocol can be used to cut down on redundant traffic
          between  sites.  It is optional and should be used only if
          the particular situation makes it worthwhile.  Frequently,
          the  outcome  is  that,  since  most original messages are
          short, and since there is a high overhead to start sending
          a  new  message  with  UUCP,  it costs as much to send the
          Ihave as it would cost to send the article itself.

          One possible solution to this overhead problem is to batch
          requests.   Several  message  ID's  may  be  announced  or
          requested in one message.  If no message ID's  are  listed
          in  the control message, the body of the message should be
          scanned for message ID's, one per line.

          3.3  Newgroupî               Newgroupî               Newgroupî               Newgroup

               newgroup <groupname>

          This control message creates a new newsgroup with the name
          given.  Since no articles may be posted or forwarded until
          a newsgroup is created, this message is required before  a
          newsgroup  can  be  used.   The  body  of  the  message is
          expected to be a short paragraph describing  the  intended
          use of the newsgroup.

          3.4  Rmgroupî               Rmgroupî               Rmgroupî               Rmgroup

               rmgroup <groupname>

          This message removes a  newsgroup  with  the  given  name.
          Since  the  newsgroup  is  removed  from every site on the
          network, this  command  should  be  used  carefully  by  a
          responsible administrator.

          3.5  Sendsysî               Sendsysî               Sendsysî               Sendsys

               sendsys (no arguments)

          The  ``sys''  file,  listing  all  neighbors   and   which
          newsgroups  are  sent  to each neighbor, will be mailed to
          the author of the control message (Reply-to,  if  present,
          otherwise  From).   This  information is considered public
          information, and it is  a  requirement  of  membership  in
          USENET  that  this  information  be  provided  on request,
          either automatically in response to this control  message,
          or  manually,  by mailing the requested information to the











                                    - 13 -



          author of the message.  This information is used  to  keep
          the  map  of  USENET  up  to  date, and to determine where
          netnews is sent.

          The format of the file mailed back to the author should be
          the same as that of the ``sys'' file.  This format has one
          line per neighboring site (plus one  line  for  the  local
          site),  containing four colon separated fields.  The first
          field has the site name of the neighbor, the second  field
          has  a newsgroup pattern describing the newsgroups sent to
          the neighbor.  The third and fourth fields are not defined
          by this standard.  A sample response:

               From cbosgd!mark  Sun Mar 27 20:39:37 1983
               Subject: response to your sendsys request
               To: mark@cbosgd.UUCP

               Responding-System: cbosgd.UUCP
               cbosgd:osg,cb,btl,bell,net,fa,to,test
               ucbvax:net,fa,to.ucbvax:L:
               cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
               cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
               sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
               npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
               mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi

          3.6  Senduunameî               Senduunameî               Senduunameî               Senduuname

               senduuname      (no arguments)

          The ``uuname'' program is run, and the output is mailed to
          the  author  of the control message (Reply-to, if present,
          otherwise From).  This program lists all uucp neighbors of
          the  local site.  This information is used to make maps of
          the UUCP network.  The sys file is not  the  same  as  theî                                             ___
          UUCP   L.sys   file.   The  L.sys  file  should  never  beî                                                           _____
          transmitted to another party without the  consent  of  the
          sites whose passwords are listed therein.

          It is optional for a site  to  provide  this  information.
          Some  reply  should  be  made to the author of the control
          message, so that a transmission error won't be blamed.  It
          is  also  permissible for a site to run the uuname program
          (or in some other way determine the  uucp  neighbors)  and
          edit  the output, either automatically or manually, before
          mailing the reply back to the  author.   The  file  should
          contain  one  site  per line, beginning with the uucp site
          name.  Additional information may be  included,  separated
          from the site name by a blank or tab.  The phone number or
          password for the site should NOT be included, as the reply
          is  considered  to  be  in the public domain.  (The uuname











                                    - 14 -



          program will send only the site name and  not  the  entire
          contents  of  the  L.sys  file,  thus,  phone  numbers and
          passwords are not transmitted.)

          The purpose of this message is to  generate  and  maintain
          UUCP mail routing maps.  Thus, connections over which mail
          can be sent using the site!user syntax should be included,
          regardless  of whether the link is actually a UUCP link at
          the physical level.  If a mail router should  use  it,  it
          should   be  included.   Since  all  information  sent  in
          response to this message is optional, sites  are  free  to
          edit  the  list,  deleting secret or private links they do
          not wish to publicise.

          3.7  Versionî               Versionî               Versionî               Version

               version (no arguments)

          The name and version of the software running on the  local
          system  is  to be mailed back to the author of the article
          (Reply-to if present, otherwise From).


          4.  Transmission Methodsî              Transmission Methodsî              Transmission Methodsî              Transmission Methods

          USENET is not a physical network,  but  rather  a  logical
          network  resting  on  top  of  several  existing  physical
          networks.  These networks include, but are not limited to,
          UUCP,  the ARPANET, an Ethernet, the BLICN network, an NSC
          Hyperchannel, and a Berknet.  What is  important  is  that
          two  neighboring systems on USENET have some method to get
          a new article, in the format listed here, from one  system
          to  the other, and once on the receiving system, processed
          by the netnews software on that system.  (On UNIX systems,
          this  usually  means  the ``rnews'' program being run with
          the article on the standard input.)

          It is not  a  requirement  that  USENET  sites  have  mail
          systems  capable  of  understanding the ARPA Internet mail
          syntax, but  it  is  strongly  recommended.   Since  From,
          Reply-To,  and  Sender  lines  use  the  Internet  syntax,
          replies  will  be  difficult  or  impossible  without   an
          internet  mailer.   A  site without an internet mailer can
          attempt to use the Path header line for replies, but  this
          field  is not guaranteed to be a working path for replies.
          In any event,  any  site  generating  or  forwarding  news
          messages must have an internet address that allows them to
          receive mail from sites with internet  mailers,  and  they
          must include their internet address on their From line.













                                    - 15 -



          4.1  Remote Executionî               Remote Executionî               Remote Executionî               Remote Execution

          Some networks permit direct remote command execution.   On
          these  networks,  news  may  be  forwarded by spooling the
          rnews command with the article on the standard input.  For
          example,  if  the remote system is called ``remote'', news
          would be sent over a UUCP link with the  command  ``uux  -
          remote!rnews'',  and on a Berknet, ``net -mremote rnews''.
          It is important that the article be sent  via  a  reliable
          mechansim, normally involving the possibility of spooling,
          rather than direct real-time remote  execution.   This  is
          because,  if the remote system is down, a direct execution
          command  will  fail,  and  the  article  will   never   be
          delivered.   If the article is spooled, it will eventually
          be delivered when both systems are up.

          4.2  Transfer by Mailî               Transfer by Mailî               Transfer by Mailî               Transfer by Mail

          On some systems, direct remote spooled  execution  is  not
          possible.   However, most systems support electronic mail,
          and a news article can be sent as mail.  One  approach  is
          to  send  a  mail  message  which is identical to the news
          message: the mail headers are the news  headers,  and  the
          mail  body  is the news body.  By convention, this mail is
          sent to the user ``newsmail'' on the remote machine.

          One problem with  this  method  is  that  it  may  not  be
          possible to convince the mail system that the From line of
          the message is valid, since the mail message was generated
          by  a program on a system different from the source of the
          news article.  Another  problem  is  that  error  messages
          caused  by  the  mail  transmission  would  be sent to the
          originator of the news article, who has  no  control  over
          news  transmission  between two cooperating hosts and does
          not know who  to  contact.   Transmission  error  messages
          should  be directed to a responsible contact person on the
          sending machine.

          A solution to this problem  is  to  encapsulate  the  news
          article  into a mail message, such that the entire article
          (headers and body) are  part  of  the  body  of  the  mail
          message.  The convention here is that such mail is sent to
          user ``rnews'' on the remote system.  A mail message  body
          is  generated  by prepending the letter ``N'' to each line
          of the news article,  and  then  attaching  whatever  mail
          headers  are convenient to generate.  The N's are attached
          to prevent any special lines  in  the  news  article  from
          interfering  with  mail  transmission,  and to prevent any
          extra lines inserted by the mailer (headers, blank  lines,
          etc.)  from  becoming part of the news article.  A program
          on the  receiving  machine  receives  mail  to  ``rnews'',











                                    - 16 -



          extracting  the  article itself and invoking the ``rnews''
          program.  An example in this format might look like this:

               Date: Monday, 3-Jan-83 08:33:47 MST
               From: news@cbosgd.UUCP
               Subject: network news article
               To: rnews@npois.UUCP

               NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
               NPosting-Version: B 2.9 6/21/82 sask.UUCP
               NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
               NFrom: derek@sask.UUCP (Derek Andrew)
               NNewsgroups: net.test
               NSubject: necessary test
               NMessage-ID: <176@sask.UUCP>
               NDate: Monday, 3-Jan-83 00:59:15 MST
               N
               NThis really is a test.  If anyone out there more than 6
               Nhops away would kindly confirm this note I would
               Nappreciate it.  We suspect that our news postings
               Nare not getting out into the world.
               N


          Using mail solves the spooling problem,  since  mail  must
          always  be  spooled  if  the  destination  host  is  down.
          However, it adds more overhead to the transmission process
          (to  encapsulate  and  extract  the  article) and makes it
          harder for software to give different priorities  to  news
          and mail.

          4.3  Batchingî               Batchingî               Batchingî               Batching

          Since news articles are usually short, and since  a  large
          number  of  messages are often sent between two sites in a
          day, it may make sense to batch  news  articles.   Several
          articles  can  be  combined  into one large article, using
          conventions agreed upon in advance by the two sites.   One
          such  batching  scheme is described here; its use is still
          considered experimental.

          News articles are combined into a script, separated  by  a
          header of the form:

               ##! rnews 1234

          where 1234 is the length, in bytes, of the article.   Each
          such  line  is followed by an article containing the given
          number of bytes.  (The newline at the end of each line  of
          the  article  is counted as one byte, for purposes of this
          count, even if it is stored as CRLF.) For example, a batch











                                    - 17 -



          of articles might look like this:

                #! rnews 374
                Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
                Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                From: jerry@eagle.uucp (Jerry Schwarz)
                Newsgroups: net.general
                Subject: Usenet Etiquette -- Please Read
                Message-ID: <642@eagle.UUCP>
                Date: Friday, 19-Nov-82 16:14:55 EST

                Here is an important message about USENET Etiquette.
                #! rnews 378
                Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
                Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                From: jerry@eagle.uucp (Jerry Schwarz)
                Newsgroups: net.followup
                Subject: Notes on Etiquette article
                Message-ID: <643@eagle.UUCP>
                Date: Friday, 19-Nov-82 17:24:12 EST

                There was something I forgot to mention in the last message.

          Batched news is recognized because the first character  in
          the  message  is ``#''.  The message is then passed to the
          unbatcher for interpretation.


          5.  The News Propagation Algorithmî              The News Propagation Algorithmî              The News Propagation Algorithmî              The News Propagation Algorithm

          This section describes the overall scheme  of  USENET  and
          the algorithm followed by sites in propagating news to the
          entire  network.   Since  all  sites   are   affected   by
          incorrectly  formatted articles and by propagation errors,
          it is important for the method to be standardized.

          USENET is a directed graph.  Each node in the graph  is  a
          host  computer,  each  arc  in the graph is a transmission
          path from one host to another host.  Each arc is  labelled
          with  a  newsgroup  pattern,  specifying  which  newsgroup
          classes are forwarded along  that  link.   Most  arcs  are
          bidirectional,  that  is,  if  site  A  sends  a  class of
          newsgroups to site B, then site B usually sends  the  same
          class  of  newsgroups to site A.  This bidirectionality is
          not, however, required.

          USENET is made up of many subnetworks.  Each subnet has  a
          name,  such  as  ``net''  or  ``btl''.  The special subnet
          ``net'' is defined to be USENET, although the union of all











                                    - 18 -



          subnets may be a superset of USENET (because of sites that
          get local newsgroup classes but do not get net.all).  Each
          subnet  is  a connected graph, that is, a path exists from
          every  node  to  every  other  node  in  the  subnet.   In
          addition,  the  entire graph is (theoretically) connected.
          (In practice, some political  considerations  have  caused
          some sites to be unable to post articles reaching the rest
          of the network.)

          An  article  is  posted  on  one  machine  to  a  list  of
          newsgroups.    That   machine  accepts  it  locally,  then
          forwards it to all its neighbors that are interested in at
          least one of the newsgroups of the message.  (Site A deems
          site  B  to  be  ``interested''  in  a  newsgroup  if  the
          newsgroup  matches  the  pattern  on  the arc from A to B.
          This pattern is stored in a file on the  A  machine.)  The
          sites  receiving  the  incoming article examine it to make
          sure they really want the article, accept it locally,  and
          then  in  turn forward the article to all their interestedî                                                    _____
          neighbors.   This  process  continues  until  the   entire
          network has seen the article.

          An important part of the algorithm is  the  prevention  of
          loops.   The  above  process would cause a message to loop
          along a cycle forever.  In particular, when site  A  sends
          an  article to site B, site B will send it back to site A,
          which will send it to site B, and so on.  One solution  to
          this  is  the history mechanism.  Each site keeps track of
          all articles  it  has  seen  (by  their  message  ID)  and
          whenever an article comes in that it has already seen, the
          incoming article is discarded immediately.  This  solution
          is   sufficient   to   prevent   loops,   but   additional
          optimizations can be made to  avoid  sending  articles  to
          sites that will simply throw them away.

          One optimization is that an article should never  be  sent
          to  a machine listed in the Path line of the header.  When
          a machine name is in the Path line, the message  is  known
          to  have passed through the machine.  Another optimization
          is that, if the article originated on site A, then site  A
          has   already  seen  the  article.   (Origination  can  be
          determined by the Posting-Version line.)

          Thus, if an article is posted to  newsgroup  ``net.misc'',
          it  will match the pattern ``net.all'' (where ``all'' is a
          metasymbol that matches any string), and will be forwarded
          to  all  sites that subscribe to net.all (as determined by
          what their neighbors send them).  These sites make up  the
          ``net''  subnetwork.  An article posted to ``btl.general''
          will reach all sites receiving ``btl.all'', but  will  not
          reach  sites  that do not get ``btl.all''.  In effect, the











                                    - 19 -



          articles  reaches  the  ``btl''  subnetwork.   An  article
          posted  to newsgroups ``net.micro,btl.general'' will reach
          all sites subscribing to either of the two classes.


























































Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@Rand-Relay>
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
Subject: problems with NBS standard
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
To: msggroup@BRL
Cc: header-people@MIT-MC, name-droppers@SRI-NIC
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:26-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------


Date: 8 Jun 1983 0922-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: Scott L. McGregor <MCGREGOR.HP-HULK at RAND-RELAY>, msggroup at BRL
cc: header-people at MIT-MC, name-droppers at SRI-NIC
Subject: Re: problems with NBS standard
Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO>
References: Message from Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay>
              of 8-Jun-83 0348-EDT
In-reply-to: <423854936.28783.hplabs@HP-VENUS>

You seem to imply that the EBCDIC difficulty makes it difficult for
a certain class of user to use NBS.  Yet using clear text makes it
difficult for a much larger class of user:  those who don't speak
English.  I believe that was the primary reason the NBS people
chose the structure they did.  To indulge in a particularly awkward
neologism, the NBS standard is "internationalizable".  It's not
sufficient to dismiss this problem by saying that most computer users
learn English as a second language;  many governments are rightly
requiring that data processing equipment sold in their countries
conform to national language requirements.
   --------

Date: 8 Jun 1983 1138-EDT
Sender: DDEUTSCH@BBNA
Subject: Re: problems with NBS standard
From: DDEUTSCH@BBNA
To: MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC
Cc: name-droppers@SRI-NIC, DDeutsch@BBNA
Message-ID: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH>
In-Reply-To: <423854936.28783.hplabs@HP-VENUS>

If the purpose of the NBS message format standard were to support
messages containing text only, I might agree with you.  However, that
is not the case.

One of the design criteria for the NBS message format standard was
that it should be extensible for multimedia messages.  In order to do
this in a flexible, efficient way, it was necessary to use a binary
encoding scheme instead of a character-encoded scheme.  Thus, data is
interpretted in octets (8-bit bytes) instead of in characters.  

I am surprised to hear you complain that a specialized data transfer
protocol cannot handle general data, and then blame the problem on the
the nature of the data.  The file transfer protocol that you
describe is specialized for the transfer of text.  You could not use
it to move a file containing an executable program; you could not use
it to move a file containing a bitmap image.  Are attempts to exchange
these kinds of data between different systems violations of the ISO
OSI layered architecture?  Of course not.  

Your file transfer protocol implements a small part of the
presentation layer, concerned only with character set translation.
That is fine, as long as you use that protocol only for
character-encoded data.  An OSI purist would say that the problem is
that you have not implemented a complete presentation layer.  I say
that the functionality of computer mail is going beyond purely textual
messages, and that we must use more general data transfer mechanisms
to accomodate the facsimile, voice, bitmaps, etc. that we would like
to include with the text in our messages.

It is easy to print NBS-style messages.  As part of the development of
the standard, a program that translates NBS-style messages to RFC 733
messages was built.  It could handle everything in the NBS standard.
It was fairly simple, and ran very quickly.  So having a computer
translate an NBS-style message to a textual representation before
printing it is quite straightforward.

I am left wondering about your final paragraph (before "About the
author").  There is nothing to lobby about, because the NBS standard
is a standard now.  More puzzling is your comment about "mail systems
that are biased against certain vendors".  Could you explain what you
mean by that?  What is the bias, and which are the vendors?

Debbie Deutsch

Date: Wed 8 Jun 83 12:14:13-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: problems with NBS standard
To: LCAMPBELL@DEC-MARLBORO.ARPA
cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA,
    header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA
In-Reply-To: Message from "Larry Campbell <LCAMPBELL at DEC-MARLBORO>" of Wed 8 Jun 83 06:22:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Larry -

     I have heard the language justification for NBS before, and am
distinctly unimpressed.  Instead of "most computer users learn
English as a second language" it is more accurate to state "English
is the language of computing."  Programming languages which have
any language base at all (that is, excepting things like APL) are
based upon English.  This is the case even in the Soviet Union and
China, which due to western trade restrictions are obliged to build
a lot of their own computing engines.

     Another fallacy to the "internationalizable" argument is the
fact that with networking there is a lot of foreign computer usage;
e.g. a user in Germany accessing a computer in the USA.

     Still another is that most operating systems with international
usage (e.g. TOPS-20) are English-based.  I am skeptical that even
relatively large software vendors such as DEC have the ability to
maintain multiple versions of operating systems, documentation, etc.
for the myriad of human languages.

     I have the sneaky suspicion that this entire argument is to coddle
the French and the Quebecois.  Recent legislation in Quebec and France
has been directed against usage of English or of adding English words
to French (e.g. "le garbage").  The best attitude to take is to ignore
it, not to argue with or bend over backwards to coddle.  If anything,
the attempt to prevent any change or language mingling in French will
ultimately lead to its becoming a dead language.  Latin is an unchanging
language, unaffected by English slang.  There are also no native speakers
of it.

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

Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT
Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT
Received: From Brl-Bmd.ARPA by BRL via smtp;  8 Jun 83 2:52 EDT
Received: From brl-gateway2.ARPA by BRL-BMD via smtp;  8 Jun 83 2:45 EDT
Received: From Rand-Relay.ARPA by BRL via smtp;  8 Jun 83 2:34 EDT
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed)
Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay@SU-Score>
Subject: problems with NBS standard
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
To: msggroup@brl
Cc: header-people@mit-mc, name-droppers@sri-nic
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:25-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------


Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:28:19-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 06:40:10-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:26:18 PDT (Wed)
Date: 8 Jun 1983 0922-EDT
From: Larry Campbell <LCAMPBELL@DEC-MARLBORO@SU-Score>
Subject: Re: problems with NBS standard
To: Scott L. McGregor <MCGREGOR.HP-HULK@RAND-RELAY>, msggroup@BRL
Cc: header-people@MIT-MC, name-droppers@SRI-NIC
Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO>
References: Message from Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay>
              of 8-Jun-83 0348-EDT
In-Reply-To: <423854936.28783.hplabs@HP-VENUS>

You seem to imply that the EBCDIC difficulty makes it difficult for
a certain class of user to use NBS.  Yet using clear text makes it
difficult for a much larger class of user:  those who don't speak
English.  I believe that was the primary reason the NBS people
chose the structure they did.  To indulge in a particularly awkward
neologism, the NBS standard is "internationalizable".  It's not
sufficient to dismiss this problem by saying that most computer users
learn English as a second language;  many governments are rightly
requiring that data processing equipment sold in their countries
conform to national language requirements.
   --------


Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:30:41-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 11:33:44-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:27:11 PDT (Wed)
Date: 8 Jun 1983 1138-EDT
From: DDEUTSCH@BBNA@SU-Score
Subject: Re: problems with NBS standard
Sender: DDEUTSCH@BBNA
To: MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC
Cc: name-droppers@SRI-NIC, DDeutsch@BBNA
Message-Id: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH>
In-Reply-To: <423854936.28783.hplabs@HP-VENUS>

If the purpose of the NBS message format standard were to support
messages containing text only, I might agree with you.  However, that
is not the case.

One of the design criteria for the NBS message format standard was
that it should be extensible for multimedia messages.  In order to do
this in a flexible, efficient way, it was necessary to use a binary
encoding scheme instead of a character-encoded scheme.  Thus, data is
interpretted in octets (8-bit bytes) instead of in characters.  

I am surprised to hear you complain that a specialized data transfer
protocol cannot handle general data, and then blame the problem on the
the nature of the data.  The file transfer protocol that you
describe is specialized for the transfer of text.  You could not use
it to move a file containing an executable program; you could not use
it to move a file containing a bitmap image.  Are attempts to exchange
these kinds of data between different systems violations of the ISO
OSI layered architecture?  Of course not.  

Your file transfer protocol implements a small part of the
presentation layer, concerned only with character set translation.
That is fine, as long as you use that protocol only for
character-encoded data.  An OSI purist would say that the problem is
that you have not implemented a complete presentation layer.  I say
that the functionality of computer mail is going beyond purely textual
messages, and that we must use more general data transfer mechanisms
to accomodate the facsimile, voice, bitmaps, etc. that we would like
to include with the text in our messages.

It is easy to print NBS-style messages.  As part of the development of
the standard, a program that translates NBS-style messages to RFC 733
messages was built.  It could handle everything in the NBS standard.
It was fairly simple, and ran very quickly.  So having a computer
translate an NBS-style message to a textual representation before
printing it is quite straightforward.

I am left wondering about your final paragraph (before "About the
author").  There is nothing to lobby about, because the NBS standard
is a standard now.  More puzzling is your comment about "mail systems
that are biased against certain vendors".  Could you explain what you
mean by that?  What is the bias, and which are the vendors?

Debbie Deutsch


Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:31:48-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 00:07:28-PDT
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:21 PDT (Wed)
Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@Rand-Relay@SU-Score>
Subject: problems with NBS standard
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
To: msggroup@BRL
Cc: header-people@MIT-MC, name-droppers@SRI-NIC
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:26-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------



Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:08:54-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:39:35-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT
Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT
Received: From Brl-Bmd.ARPA by BRL via smtp;  8 Jun 83 2:52 EDT
Received: From brl-gateway2.ARPA by BRL-BMD via smtp;  8 Jun 83 2:45 EDT
Received: From Rand-Relay.ARPA by BRL via smtp;  8 Jun 83 2:34 EDT
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:05:35 PDT (Wed)
Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay@SU-Score>
Subject: problems with NBS standard
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
To: msggroup@brl
Cc: header-people@mit-mc, name-droppers@sri-nic
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:25-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------



Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:09:46-PDT
Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:59:08-PDT
Received: From Brl-Bmd.ARPA by BRL via smtp;  8 Jun 83 9:55 EDT
Received: From brl-gateway2.ARPA by BRL-BMD via smtp;  8 Jun 83 9:25 EDT
Received: From Dec-Marlboro.ARPA by BRL via smtp;  8 Jun 83 9:24 EDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:08:25 PDT (Wed)
Date: 8 Jun 1983 0922-EDT
From: Larry Campbell <LCAMPBELL@dec-marlboro@SU-Score>
Subject: Re: problems with NBS standard
To: Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay>, msggroup@brl
Cc: header-people@mit-mc, name-droppers@sri-nic
Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-M

RefereM
References: Message from Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay>
              of 8-Jun-83 0348-EDT
In-reply-to: <423854936.28783.hplabs@HP-VENUS>

You seem to imply that the EBCDIC difficulty makes it difficult for
a certain class of user to use NBS.  Yet using clear text makes it
difficult for a much larger class of user:  those who don't speak
English.  I believe that was the primary reason the NBS people
chose the structure they did.  To indulge in a particularly awkward
neologism, the NBS standard is "internationalizable".  It's not
sufficient to dismiss this problem by saying that most computer users
learn English as a second language;  many governments are rightly
requiring that data processing equipment sold in their countries
conform to national language requirements.
   --------

Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:11:36-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:10:05-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:04:42 PDT (Wed)
Date: Wed 8 Jun 83 12:14:13-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: problems with NBS standard
To: LCAMPBELL@DEC-MARLBORO.ARPA
Cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA,
        header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA
In-Reply-To: Message from "Larry Campbell <LCAMPBELL at DEC-MARLBORO>" of Wed 8 Jun 83 06:22:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Larry -

     I have heard the language justification for NBS before, and am
distinctly unimpressed.  Instead of "most computer users learn
English as a second language" it is more accurate to state "English
is the language of computing."  Programming languages which have
any language base at all (that is, excepting things like APL) are
based upon English.  This is the case even in the Soviet Union and
China, which due to western trade restrictions are obliged to build
a lot of their own computing engines.

     Another fallacy to the "internationalizable" argument is the
fact that with networking there is a lot of foreign computer usage;
e.g. a user in Germany accessing a computer in the USA.

     Still another is that most operating systems with international
usage (e.g. TOPS-20) are English-based.  I am skeptical that even
relatively large software vendors such as DEC have the ability to
maintain multiple versions of operating systems, documentation, etc.
for the myriad of human languages.

     I have the sneaky suspicion that this entire argument is to coddle
the French and the Quebecois.  Recent legislation in Quebec and France
has been directed against usage of English or of adding English words
to French (e.g. "le garbage").  The best attitude to take is to ignore
it, not to argue with or bend over backwards to coddle.  If anything,
the attempt to prevent any change or language mingling in French will
ultimately lead to its becoming a dead language.  Latin is an unchanging
language, unaffected by English slang.  There are also no native speakers
of it.

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


Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:14:27-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:19:43-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:30:41-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 11:33:44-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:27:11 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:09:31 PDT (Wed)
Date: 8 Jun 1983 1138-EDT
From: DDEUTSCH@BBNA@SU-Score
Subject: Re: problems with NBS standard
Sender: DDEUTSCH@BBNA
To: MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC
Cc: name-droppers@SRI-NIC, DDeutsch@BBNA
Message-Id: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH>
In-Reply-To: <423854936.28783.hplabs@HP-VENUS>

If the purpose of the NBS message format standard were to support
messages containing text only, I might agree with you.  However, that
is not the case.

One of the design criteria for the NBS message format standard was
that it should be extensible for multimedia messages.  In order to do
this in a flexible, efficient way, it was necessary to use a binary
encoding scheme instead of a character-encoded scheme.  Thus, data is
interpretted in octets (8-bit bytes) instead of in characters.  

I am surprised to hear you complain that a specialized data transfer
protocol cannot handle general data, and then blame the problem on the
the nature of the data.  The file transfer protocol that you
describe is specialized for the transfer of text.  You could not use
it to move a file containing an executable program; you could not use
it to move a file containing a bitmap image.  Are attempts to exchange
these kinds of data between different systems violations of the ISO
OSI layered architecture?  Of course not.  

Your file transfer protocol implements a small part of the
presentation layer, concerned only with character set translation.
That is fine, as long as you use that protocol only for
character-encoded data.  An OSI purist would say that the problem is
that you have not implemented a complete presentation layer.  I say
that the functionality of computer mail is going beyond purely textual
messages, and that we must use more general data transfer mechanisms
to accomodate the facsimile, voice, bitmaps, etc. that we would like
to include with the text in our messages.

It is easy to print NBS-style messages.  As part of the development of
the standard, a program that translates NBS-style messages to RFC 733
messages was built.  It could handle everything in the NBS standard.
It was fairly simple, and ran very quickly.  So having a computer
translate an NBS-style message to a textual representation before
printing it is quite straightforward.

I am left wondering about your final paragraph (before "About the
author").  There is nothing to lobby about, because the NBS standard
is a standard now.  More puzzling is your comment about "mail systems
that are biased against certain vendors".  Could you explain what you
mean by that?  What is the bias, and which are the vendors?

Debbie Deutsch



Date: 8 Jun 1983 1412-PDT
Sender: ESTEFFERUD at USC-ECL
Subject: Discussion of NBS reports
From: DDEUTSCH@BBNA,  ESTEFFERUD@USC-ECL
Reply-To: MsgGroup-request at BRL
To: MsgGroup at BRL
Cc: header-people at MIT-MC, Name-Droppers at SRI-NIC
Message-ID: <[USC-ECL] 8-Jun-83 14:12:26.ESTEFFERUD>

To all MsgGroupers, and others ... in Header-People and Name-Droppers:

There has been quite a bit of interest in MsgGroup recently about the
NBS program to develop federal information processing standards for
computer-based message systems.  NBS would like to encourage such
discussion, in the belief that the technical concepts it has developed
may be of interest to the Internet community, and that feedback from
the Internet community will be helpful to NBS.

In order to facilitate this process, NBS is willing to make the
appropriate NBS reports available as RFCs.  The NBS message format
standard is already available from the NIC as RFC 841.  Two additional
NBS reports should be of interest at this time.  One deals with naming
and addressing, and the other is an analysis of the features of
message transfer protocols.  Both already have been published for
public comment.

Contributions are encouraged from all interested parties whether you
are a member of MsgGroup or not.  In order to capture the entire
discussion, it should be conducted in MsgGroup.  The MsgGroup
transcript of the discussion will be kept in an organized archive for
public access and NBS use.

Contributions to the discussion should go to MsgGroup@BRL.  Extra
copies to Header-People and Name-Droppers will not be appreciated by
recipients who are also members of MsgGroup.

Requests to be added to the MsgGroup mailing list should go to
MsgGroup-Request@BRL.

Debbie Deutsch and Einar Stefferud

Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:21:18-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:47:35-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:31:48-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 00:07:28-PDT
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:21 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:11:45 PDT (Wed)
Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@Rand-Relay@SU-Score>
Subject: problems with NBS standard
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
To: msggroup@BRL
Cc: header-people@MIT-MC, name-droppers@SRI-NIC
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:26-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------




Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:23:15-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:01:20-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:28:19-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 06:40:10-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:26:18 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:09:08 PDT (Wed)
Date: 8 Jun 1983 0922-EDT
From: Larry Campbell <LCAMPBELL@DEC-MARLBORO@SU-Score>
Subject: Re: problems with NBS standard
To: Scott L. McGregor <MCGREGOR.HP-HULK@RAND-RELAY>, msggroup@BRL
Cc: header-people@MIT-MC, name-droppers@SRI-NIC
Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO>
References: Message from Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay>
              of 8-Jun-83 0348-EDT
In-Reply-To: <423854936.28783.hplabs@HP-VENUS>

You seem to imply that the EBCDIC difficulty makes it difficult for
a certain class of user to use NBS.  Yet using clear text makes it
difficult for a much larger class of user:  those who don't speak
English.  I believe that was the primary reason the NBS people
chose the structure they did.  To indulge in a particularly awkward
neologism, the NBS standard is "internationalizable".  It's not
sufficient to dismiss this problem by saying that most computer users
learn English as a second language;  many governments are rightly
requiring that data processing equipment sold in their countries
conform to national language requirements.
   --------



Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:40:57-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 15:34:51-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:08:54-PDT
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:39:35-PDT
Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT
Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT
Received: From Brl-Bmd.ARPA by BRL via smtp;  8 Jun 83 2:52 EDT
Received: From brl-gateway2.ARPA by BRL-BMD via smtp;  8 Jun 83 2:45 EDT
Received: From Rand-Relay.ARPA by BRL via smtp;  8 Jun 83 2:34 EDT
Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:05:35 PDT (Wed)
Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:35:22 PDT (Wed)
Date:  7 Jun 1983 1028-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@rand-relay@SU-Score>
Subject: problems with NBS standard
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
To: msggroup@brl
Cc: header-people@mit-mc, name-droppers@sri-nic
Message-Id: <423854936.28783.hplabs@HP-VENUS>
Via:  HP-Labs; 7 Jun 83 23:25-PDT

There has been a flurry of interest in the NBS Specifications for 
message format for computer based message systems.  There have been
many messages touting this standard and telling of wide spread acceptance.
The purpose of this message is to describe a comparison of the NBS
standard with RFC822 that was done here at HP, and reasons are given
why RFC822 was found superior.  The result of this comparison is that
HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed
by our facility in Pinewood England) currently support an outbound RFC822
interface, and will in the future support an inbound RFC822 interface.
While future interfaces to the NBS standard cannot be ruled out, none
is planned at this time.


Many MSGGROUP members have made reference to the complexity of the NBS
standard. The standard is complex for anyone to implement, particularly
if they are interested in supporting the full breadth of the standard.
But, as has been pointed out by others, only a small subset is required.

The real problem with NBS lies elsewhere.  It is purely an implementation
problem. The problem is that NBS relies on bit strings (called octets)
that allows the message server to recognize fields.  RFC822 on the other
hand requires no special bit-strings; all heading handling is done in
clear text.  In an ascii-to-ascii interchange, this is not a problem,
but in an ascii-to-ebcdic environment or ascii-to-printed output environment,
this is disasterous. 

Because of the imbedded bit strings, common ascii-to-ebcdic file transfer
programs cannot be used; the bit-strings would get translated too. So, the
file transfer process must be specialized to deal with the special
requirements of NBS mail.  This is a hardship on the mail developer, and
goes against the spirit of the ISO OSI layered architecture protocol. 
This is particularly a bad implementation problem because there exist many
different ascii-to-ebcdic translation tables that are widely used.

The problem also exists in an ascii-to-text environment.  When I send
mail to someone, I cannot be sure whether they will receive it in hardcopy
or soft.  They may not have an account on a computer system, but may be
served by a printer attached to a remote computer, and their messages
may be delivered by interoffice mail.  Using RFC822, I can send the message
down the line to their printer directly and I don't even have to know if
it is a computer, or if it is a printer or some other output device. NBS
definately requires another computer at the distant site to decode the
bit strings.


I suppose that to some, the above may not seem like weighty concerns.  Many
Ascii worlders would feel little grief in denying contact to the ebcdic
world (a world badly in need of additional communcication from this
community).  Nor would they feel any grief in requiring smarter printers, etc.
(or perhaps of requiring anyone interested in internet mail to have a
computer account), after all, hardware costs are decreasing.  Nor would
they concern themselves with the added burden on mail implementers.

To those of you with these sentiments, I can only suggest that you lobby
harder, because those people who control EDP purse strings in companies
are concerned about additional hardware requirements. They are also 
concerned about mail systems that are biased against certain vendors,
particularly if they happen to own some of this hardware already.
For this reason, HP Pinewood decided to go with RFC822 over NBS as an
initial inter-net standard. 


About the author:
-----------------
Many people seem to want to know additional information about authors
of large messages such as this one.  If you are not one of these people,
no need to read further.

Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data
center. The data center currently supports an IBM3081K running MVS,
an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6
running VM, many HP3000s, and a variety of other computers.  He primarily
supports the MVS machines although he does some work on the HP3000s and
some work on an HP-LABS DEC-20.  One of his current projects is implementing
a mail system on the MVS machines, including interfaces to the mail system
running on the HP3000s, HPMAIL/HPDESKMANAGER.

Scott is the author of several papers on a variety of computer topics, 
including 2 papers presented at ACM SIGDOC conferences and 4 presented at
SAS User Group International conferences.

Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC.
Any similarity between the two is purely coincidental.

Postal address: Scott L. McGregor
                Hewlett-Packard Co.
                Corporate Data Center
                3000 Hanover St. Bldg 20CF
                Palo Alto, CA 94304


--Scott L. McGregor 07 JUN 83
-------




Date: 9 June 1983 15:39 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Loop tracing
To: HEADER-PEOPLE @ MIT-MC

I suspect a forwarding loop exists in Header-People.  This
is a short message to help track it down, if it exists.

KLH@MIT-MC 06/09/83 19:21:58
To: HEADER-PEOPLE at MIT-MC
testing

Date:  9 Jun 1983 1047-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@Rand-Relay>
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
Subject: Re: problems with NBS standard
Received: by HP-VENUS via CHAOSNET; 9 Jun 1983 10:51:46-PDT
To: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC, name-droppers@SRI-NIC,
        MCGREGOR.HP-HULK@Rand-Relay
In-Reply-To: Your message of 8-Jun-83 0838-PDT
Message-Id: <424029107.4147.hplabs@HP-VENUS>
Via:  HP-Labs; 9 Jun 83 19:28-PDT

I see that I have not been clear about the kinds of communication that
I was addressing.  My comments in my previous letter were addressed only
to the subset of possible computer communication that is textual. I 
intended to raise implementations concerns in comparision to RFC822,
a textual standard.  Debbie is entirely correct that NBS addresses a
larger scope, namely multimedia communication.  I agree that it probably
addresses that scope better than RFC822, which never really was intended
to have that scope (according to the RFC822 standard, communications are
limited to ascii characters, 8-bit binaries would not be "legitimate" even
if accepted by a such a mail system).

There is still something to lobby about. Standards have to be implemented.
A standard does not enforce conformity any more than laws against
drunk driving mean that no more people will die on the roads. People
have to follow standards for them to work, just as with traffic laws.
To get standards implemented, they have to be made palatable to implementors,
and in this case, a general purpose translator is needed. This is 
especially true for those machines that might want to translate ascii text
(if it is contained within the message) to ebcdic, as would occur in
transferring text mail from a DEC20 to an IBM370, or vice versa from EBCDIC
to ASCII as would happen sending text mail from an IBM370 to a DEC20.

In response to the question of mail systems biased against certain vendors,
let me say this. If a mail standard is more difficult to implement on
one kind of machine than certain others, I consider it "biased" against
that vendor. This is not neccessarily bad, it may be the best solution
to a bad problem.  The fact is, that IBM uses EBCDIC as its character
standard on its large mainframes while most of the rest of the world
uses ASCII, thus ASCII mail standards are inherently biased against
IBM, because extra effort (i.e. translation) is required to get the
text readable to the IBM user.  What makes an ASCII standard such as
RFC822 palatable to an IBM mail system implementor is the existence of
vendor supported translation programs. Because such translators cannot
be used on NBS text mail, NBS is even more difficult to implement.
If IBM were to release a smarter translator that could handle NBS
mail containing ASCII text, the NBS would be just as acceptable as RFC822.
I think people who are interested in NBS mail to IBM systems should
lobby to make this a reality.

The existence of an NBS to RFC822 translation program for the printing
of text begs the question. RFC822 text can be sent down a tty line to
a device and it is unimportant whether it is intelligent or not. It 
could just be a printer. NBS mail would require an intelligence at the
end of the TTY line capable of running the translator, therefore, 
extra  hardware is required here.  Of course NBS designers recognized
this, it is no suprise; the NBS standard is a standard for communication
between computers, and is not intended to be able to go directly to
printers. RFC822 just has the nice property that it can go directly to a
printer.

Some of the comments about my references to ISO OSI, seem to fall out
of the confusion of my comparison of the use of NBS (a multimedia standard)
with RFC822 (a text standard).  Again, I want to clarify my intent, to
mention implementation problems concerned with the mailing of text. But 
there is another issue which I haven't fully digested yet concerning the
advantage of a multimedia standard over a text standard. The implication
is that because multimedia can include text that the text standard will
become unneccessary.  My first reaction is that the existence of trucks,
which can carry freight or passengers never lead to the abolishment of
cars and motorcycles which can only transport people effectively. Still,
there are some interesting questions raised here, and I will have to
ponder more.

Best wishes to all, and thanks for the comments!

Scott L. McGregor
-------


Date: 10 June 1983 01:35 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Explanation of endless NBS messages
To: HEADER-PEOPLE @ MIT-MC
cc: MsgGroup @ BRL

	I tried to track down the source of the recent stream of
duplicated messages, and it appears that they were falling victim to a
bug somewhere at Stanford.  What made it difficult was the fact that
the original message went to not one but two large mailing lists (it would
have been three, but fortunately the incorrect name "name-droppers"
was used instead of "namedroppers"!)  Enclosed are the two most
informative messages which resulted:
	----------------------------------
Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Thu 9-Jun-83 19:46:08-EDT
Date: Thu, 9 Jun 83 19:48 EDT
From: Mike McMahon <MMcM@SCRC-TENEX>
Subject: Loop tracing
To: KLH@MIT-MC
In-reply-to: The message of 9 Jun 83 15:39-EDT from Ken Harrenstien <KLH at MIT-MC>
Message-ID: <830609194825.2.MMcM@SCRC-TENEX>

I'd be curious to know what you learn.  What I guessed from my mail was
that a host named "diablo" was plugged in where su-shasta should be.
header-people goes to csl.bkr@score, which goes to reid@shasta.  Diablo
probably had a broken piece of mail software (like /etc/delivermail
without setuid root, wasn't the the explanation last year?) which parses
the to: field to find out who to send to, giving it right back to mc.
Like I said, this is entirely guesswork, but confirmed a little bit by
some troubles Jan Walker was having sending to Brian Reid.

	----------------------------------
Date: Thu 9 Jun 83 17:09:39-PDT
From: Bill Nowicki <NOWICKI@SU-SCORE.ARPA>
Subject: Mailing loop
To: klh@MIT-MC.ARPA

For a short period of time yesterday afternoon there was such a loop,
but it was fixed.  Sorry for the inconvenience.
	-- Bill
-------
	----------------------------------

	Considering that this is not the first time this has happened
(ie it can happen again) and that the size of mailing lists has become
rather awesome, perhaps it is time to revive the old ideas for detecting
and killing mail forwarding loops.  I suggest that any such discussion
be confined to Header-People, which is oriented to hairy technical
bull sessions.

--Ken

Date: 10 June 1983 03:46 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Fickle Finger of Fate
To: taft @ PARC-MAXC
cc: HEADER-PEOPLE @ MIT-MC

I got the following message from some PARC mailer.  I have two questions:
	(1) What is the weird ".AG." in my supposed Arpanet address?
	(2) I thought PARC mailers were clever about mailing error
	notes for a list to the maintainers of the list; is this not
	actually true?
--Ken
----------------------------
Subject: Undelivered mail
From: Gamay.ms@PARC-MAXC.ARPA (a Grapevine mail server)
To: KLH@MIT-MC.AG.ARPA
Date: 9 Jun 83 22:42:53 PDT

The message sent by KLH@MIT-MC.AG at  9-Jun-83 22:38:26 PDT could not be
delivered to the following recipients because their names are invalid.

Fung.es

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

Received: from MIT-MC.ARPA by PARC-MAXC.ARPA;  9 JUN 83 22:38:05 PDT
Redistributed: XeroxHeaderPeople^.pa
Date: 10 Jun 83 01:35 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: Explanation of endless NBS messages
To: HEADER-PEOPLE@MIT-MC.ARPA
cc: MsgGroup@BRL.ARPA

	I tried to track down the source of the recent stream of
duplicated messages, and it appears that they were falling victim to a

[KLH: ... I flushed the rest of this text ... ]

Received: from Glacier by Score with Pup; Fri 10 Jun 83 08:18:36-PDT
Date: Friday, 10 Jun 1983 08:18-PDT
To: Ken Harrenstien <KLH at MIT-MC>
Cc: HEADER-PEOPLE at MIT-MC, MsgGroup at BRL
Cc: nowicki at Diablo
Subject: Re: Explanation of endless NBS messages
In-reply-to: Your message of 10 June 1983 01:35 EDT.
From: Brian Reid <reid%Glacier@SU-Score>

The mail loop this time was caused by a new Berkeley 4.1C program that
we had just installed on one of our VAXen (Diablo). It is called
"sendmail", and it is supposed to replace the old "delivermail" that
was indirectly the cause of last year's loop. The loop path was
CSL.Lantz@Score-->lantz@Diablo-->loop. The loop was tracked down and
fixed by Bill Nowicki. I don't know anything about the details of this
loop, or about the "sendmail" program, but the word that I hear in
the halls around here is that sendmail is really complex and
incomprehensible (and therefore terrible) and that it is not at all a
step forward from the old delivermail.

Since it is Berkeley's intention that all Berkeley Unix sites convert
to sendmail soon, and since we had this trouble with it, it might be
worthwhile getting Bill to explain the loop so that other sites, when
installing this new software, do not make the same mistake. Bill seemed
to think that part of the cause was a very dangerous feature of the
program (that got accidentally invoked), which perhaps Berkeley could
be persuaded to remove.

Date: Fri, 10 Jun 83 10:10 PDT
From: Taft.PA@PARC-MAXC.ARPA
Subject: Re: Fickle Finger of Fate
In-reply-to: "KLH@MIT-MC.ARPA's message of 10 Jun 83 03:46 EDT"
To: Ken Harrenstien <KLH@MIT-MC.ARPA>
cc: Taft.PA@PARC-MAXC.ARPA, HEADER-PEOPLE@MIT-MC.ARPA

1. The appearance of ".AG" outside the Xerox Internet is a symptom of
some bug, which I will look for.  It should be stripped off by the mail
translation gateway as the message crosses between the Xerox and ARPA
worlds.

"AG" stands for "ARPA Gateway".  It is the name of a Xerox "registry"
which logically contains the mailboxes for all ARPA recipients.  (You
may think of all of Xerox as a subtree of one node in the ARPA Internet,
namely the host PARC-MAXC; but we think of the entire ARPA Internet as a
subtree of one node in the Xerox Internet, namely the registry AG.  We
call this "mutual encapsulation of name spaces"; I alluded to it a month
or two ago in a message to NameDroppers.)

2. Failure to deliver to a member of a distribution list ordinarily
results in the owner of the list being notified.  However, there are a
few situations in which a delivery failure occurs after the fact that
the recipient name came from a list has been forgotten.  This usually
occurs when a mailbox is destroyed at about the same time as
distribution list expansion is being performed.

And now a remark of my own:

3. I see no reason to bother all the members of HEADER-PEOPLE with a
matter that really concerns only you and me.  The amount of junk that
pours forth from HEADER-PEOPLE and other groups is a real annoyance; and
finding useful information in all this volume of messages is quite
time-consuming.

Yours for less pollution of the distribution lists,

	Ed Taft


Date: 10 Jun 1983 1519-EDT
Sender: DDEUTSCH@BBNA
Subject: Re: problems with NBS standard
From: DDEUTSCH@BBNA
To: MCGREGOR.HP-HULK@RAND-RELAY
Cc: DDEUTSCH@BBNA, msggroup@BRL, header-people@MIT-MC
Message-ID: <[BBNA]10-Jun-83 15:19:55.DDEUTSCH>
In-Reply-To: <424029107.4147.hplabs@HP-VENUS>

Just a few points in response.

The NBS message format standard was published for public review twice
before it became a standard.  Copies were sent out to every vendor of
computer based message systems that NBS could identify, every
person/organization who requested one, other individuals that hadn't
requested copies but NBS thought might be interested, and other
national and international standards organizations working in the
area.  Of all the comments that came back, I can't remember a single
one that said the then proposed standard was too difficult to
implement, and should be discarded.

In fact, the nature of a standard message format (text-based or
otherwise) is that some translation between the transfer-syntax and
internal form almost always takes place.  For example, the system that
I am using now stores my draft message as a list of pointers to
fields.  The pointers are associated with binary numbers that identify
the field names; the fields themselves are stored in various formats,
according to their types (address, date, text, etc.).  So when I tell
my system to send the draft message, it must translate from its
internal form to RFC822; when I tell it to show me the draft message
it must translate from its internal form to a character stream that my
terminal can handle.  My system does that in order to facilitate the
process of composing and editing draft messages.  The designers of
message systems sometimes find it advantageous to store received
messages in a specialized internal format (such as an inverted
database).  So translators are often used to optimize
performance/functionality in various parts of message systems when a
internal format can take advantage of local architecture and
resources.

I am sorry that you must deal with ASCII/EBCDIC translations - the
world would be a (slightly) better place if one character encoding
scheme could be universally agreed upon.  However, any standard issued
by NBS must use ASCII.  First of all, ASCII is the NBS standard
character set.  Having the message format standard allow EBCDIC would
have been inconsistant.  ASCII came to NBS (and the rest of the
country) from ANSI.  (ANSI has a lot of IBM participation, by the
way.)  ASCII is also a subset of IA5, the ISO standard for character
sets.  So, allowing EBCDIC would put NBS in violation of ANSI and ISO
standards.  Can you imagine the hue and cry from all the folks who are
in compliance with ASCII if NBS permitted the use of EBCDIC?

By the way, I have never heard an IBM representative argue against the
use of ASCII and for the use of EBCDIC at a standards meeting.

You can use your favorite vendor-supported translation program on the
contents of any NBS ASCII-String data element.  The rest of the format
would remain the same, no matter which character set was native.

There is a flaw in your trucks vs. cars/motorcycles.  A manufacturer
of motor vehicles would be overjoyed if a given part could be used for
both trucks and cars.  It usually is cheaper to make one kind of
component than two different kinds of components.  The same is true in
the standards world.  It is generally preferable to have a single
general-purpose standard than a number of specialized ones.  That's
the whole idea of having standards in the first place.

Debbie

Date: 10 Jun 1983 1216-PDT
Sender: BILLW at SRI-KL
Subject: Re: Explanation of endless NBS messages
From: BILLW at SRI-KL
To: KLH at MIT-MC
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW>
In-Reply-To: Your message of 10 June 1983 01:35 EDT

I also notice that although the HELO message in SMTP was supposed
to prevent the flaw of accidently sending mail to the wrong host,
no one seems to use it for such.

Comments?
 Bill W

Date: 10 Jun 1983 1216-PDT
Sender: BILLW at SRI-KL
Subject: Re: Explanation of endless NBS messages
From: BILLW at SRI-KL
To: KLH at MIT-MC
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW>
In-Reply-To: Your message of 10 June 1983 01:35 EDT

I also notice that although the HELO message in SMTP was supposed
to prevent the flaw of accidently sending mail to the wrong host,
no one seems to use it for such.

Comments?
 Bill W

Date: 10 Jun 1983 1216-PDT
Sender: BILLW at SRI-KL
Subject: Re: Explanation of endless NBS messages
From: BILLW at SRI-KL
To: KLH at MIT-MC
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW>
In-Reply-To: Your message of 10 June 1983 01:35 EDT

I also notice that although the HELO message in SMTP was supposed
to prevent the flaw of accidently sending mail to the wrong host,
no one seems to use it for such.

Comments?
 Bill W

Received: from SCRC-COLLIE by SCRC-SPANIEL with CHAOS; Fri 10-Jun-83 19:23:06-EDT
Date: Fri, 10 Jun 83 18:11 EDT
From: Mike McMahon <MMcM@SCRC-TENEX>
Subject: Loop detection
To: HEADER-PEOPLE@MIT-MC
Message-ID: <830610181125.5.MMcM@SCRC-TENEX>

It seems to me the correct way to do this is with the Received: header.
Mail servers put in Received, including "for <addresses>".  (I believe
the BNF in 822 doesn't allow for multiple addresses, but it could be
fixed.)  The mailer detects a loop by the presence of two Received
headers, both of which have "by <this-host>" and "for <same-addresses>".
Unfortunately, when mailing lists are expanded at a foreign site, the
list of <addresses> can get very long.

Date: Fri 10 Jun 83 17:36:12-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Loop detection
To: MMcM%SCRC-TENEX@MIT-MC.ARPA
cc: HEADER-PEOPLE@MIT-MC.ARPA
In-Reply-To: Message from "Mike McMahon <MMcM@SCRC-TENEX>" of Fri 10 Jun 83 16:36:35-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

I don't like the idea of using "for <addresses>" in the Received: header,
as this defeats bcc's.

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

Date: 10 Jun 1983 2047-EDT
From: Mike McMahon <MMcM@SCRC-TENEX>
Subject: Re: Loop detection
To: MRC@SU-SCORE
cc: HEADER-PEOPLE@MIT-MC
In-Reply-To: The message of Fri 10 Jun 83 17:36:12-PDT from Mark Crispin <MRC@SU-SCORE.ARPA>

But shouldn't the mail sending program pass the mailer two different pieces
of text, one with a Bcc header for the Bcc recipients and one without for
the other recipients?  Otherwise the Bcc recipients will be mystified when
they get a message with no indication of their name.
-------

Received: from Diablo by Score with Pup; Fri 10 Jun 83 18:32:04-PDT
Date: Fri, 10 Jun 83 18:31 PDT
From: Bill Nowicki <nowicki%Diablo@SU-Score>
Subject: Mail Loop explanation
To: DCrocker@UDel-Relay, KLH@MIT-MC, reid@Glacier
Cc: HEADER-PEOPLE@MIT-MC, MsgGroup@BRL, mailhax

Some people have requested a few more details of our
experience with sendmail and the disaster which caused a
mail loop on Wednesday June 8. First some background:

At Stanford we run 4.1BSD Unix with BBN TCP code, with CMU
packet filtering on 3 Mbit Ethernets connecting about a dozen VAXes (and
many other machines).  We would like to use 4.2 whenever (if ever?) it
finally gets done, so we got a 4.1c beta distribution and were trying
to phase in some of the user programs on that release, like sendmail.
The predecessor of sendmail, delivermail, 
we had customized slightly by changing a few tables and recompiling.
It read the host name by the gethostname() system call, so we could
take the program (or an entire disk pack for that matter) from one
system to another and it would work.  Sendmail contains an SMTP server
as well as the other mail switching and aliasing functions of
delivermail.

Integrating the SMTP server and the aliasing turns out to be a good
idea, but all sorts of other "features" were added to sendmail in the
mean time.  For example, instead of having compile-time tables and
modular code, there are enormous configuration files that are read at
run-time.  You have to specify a "program" to parse your addresses
using an incredibly unfathomable production language.  The host name is
hard-wired into the configuration file, so they are not portable
between machines anymore.  Part of the confusion came from the
distinction between switches entered on the command line, commands in
the configuration file, options which can be given on the command line
OR in the configuration file (with yet another strange syntax), mailer
flags, and configuration file macros.  All five of these are
represented by single character case sensitive identifiers, with
different meanings for the letters in many cases.  A vertiable lesson
in terrible user interfaces.

The specific problem came when we discovered a case in which our
TOPS-20 SMTP mailer would open a connection, send part of a message,
and then simply give up without sending a RESET packet.  The BBN TCP
code had no timeouts, so the connection would stay around forever,
along with the two sendmail processes and the spool files.  I
remembered reading about a timeout feature, and glancing at the manual
found it was the "t" option.  So I ran sendmail with the "t" switch on
the command line.  There were two mistakes: first, the timeout is an
Option, not a Switch, and secondly it is upper case T not lower case
t.  I was silly enough to think that since it gave me no error message
that everything was OK, and went off to our research group meeting.

When I came back after the meeting I looked at the log file and noted
some suspicious behaviour.  What it was doing was sending a copy of
each message to the people listed in the "To:" and "Cc:" fields in the
header, as well as the person given in the RCPT TO:<> command of SMTP.
This resulted in the loop back through our local Ethernet, the Arpanet,
the MIT Chaos Net, as well as several nets at BRL and BBN!  I killed
the server after about an hour, and restarted it with the right options
(although the timeout still does not do anything), but the duplicated
mail took at least two days to stop bouncing through the net.

Morals (some are my personal opinions):  
1. Case sensitivity is a bad idea.  
2. Single letter identifiers are a bad idea.  
3. Multiple notions that are similar are confusing.  
4. Large (multi-domain) mailing lists should have a moderator.  
5. Timeouts should be in SMTP servers and TCP implementations by default.  
6. internet mail systems are fragile things.  
7. "Improved" software with more "features" usually isn't.

	-- Bill

Date: 10 Jun 1983 1837-PDT
From: Henry W. Miller <Miller at SRI-NIC>
Subject: Re: Explanation of endless NBS messages
To: BILLW at SRI-KL, KLH at MIT-MC
cc: HEADER-PEOPLE at MIT-MC, Miller at SRI-NIC
In-Reply-To: Your message of 10-Jun-83 1216-PDT

Bill,
	The way I read the spec, the HELO command merely identifies
the sender to the receiver.

-HWM
-------

Date:           Fri, 10 Jun 83 22:08:23 PDT
From:           Rich Wales <v.wales@UCLA-LOCUS>
To:             Header-People@MIT-MC
Subject:        SMTP and unknown or mismapped host names
In-reply-to:    BILLW@SRI-KL's message of 10 Jun 1983 1216-PDT

BILLW@SRI-KL suggested that Internet hosts examine the info given in
the SMTP HELO command and its reply, in order to verify that the right
two hosts are connected up.  While it is quite possible for two hosts
to get misconnected (owing to changed Internet addresses and out-of-
date host name tables), I am not sure Bill's suggestion would help.

Something that hosts SHOULD do (though a lot of them don't) is check
the entire RCPT address, including the domain, and not simply assume
that the mail is being directed to the right machine.  This is partic-
ularly important when the host on a given Internet address has changed.

(1) Since not everyone has up-to-date host name tables (in some cases,
    this is a gross understatement!!), I think we really have to give
    the other host the benefit of the doubt if it calls itself by a
    name we aren't familiar with.  Perhaps the server can put a mild,
    non-accusatory warning in its reply to the HELO -- something like

	220 PODUNK SMTP Server ready
	helo ucla-locus
	250 PODUNK -- That's odd, I thought your name was UCLA-SECURITY

    or

	220 PODUNK SMTP Server ready
	helo ucla-locus
	250 PODUNK -- By the way, my host name table doesn't list you

    Flames like the following (I have actually seen this one!) --

	220 PODUNK SMTP Server ready
	helo ucla-locus
	250 PODUNK -- You are a charlatan, UCLA-SECURITY

    -- not only seem somewhat too harsh (to me, at least), but they may
    also leave the gurus at the sending site with the lingering suspi-
    cion that the mail was not really handled properly.

(2) A more important concern is what an SMTP server should do if it
    gets a RCPT command specifying a user on an unknown host -- for
    example:

	220 PODUNK SMTP Server ready
	helo ucla-locus
	250 PODUNK
	mail from:<wales@ucla-locus>
	250 OK
	rcpt to:<fred@smalltown>

    Assuming that SMALLTOWN is not an alias name for the host PODUNK,
    then PODUNK should clearly either reject the recipient, or accept
    it and forward the message.
    
    A lot of hosts out there, though, are apparently simply ignoring
    the domain and assuming that the address must be local.  In my ex-
    ample, either the mail would be misdelivered to "fred@PODUNK", or
    else I would be told that there is no local user "fred"!

Comments?

-- Rich

Date: 10 Jun 1983 2003-PDT
From: Scott L. McGregor <MCGREGOR.HP-HULK@Rand-Relay>
Return-Path: <MCGREGOR%HP-HULK.HP-Labs@Rand-Relay>
Subject: Re: problems with NBS standard
Received: by HP-VENUS via CHAOSNET; 10 Jun 1983 20:04:13-PDT
To: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC, MCGREGOR.HP-HULK@Rand-Relay
In-Reply-To: Your message of 10-Jun-83 1219-PDT
Message-Id: <424148654.14765.hplabs@HP-VENUS>
Via:  HP-Labs; 11 Jun 83 4:18-PDT

I have no problem with NBS as a standard, nor do I propose EBCDIC
as a standard.  I only point out that it is harder to implement NBS
for sending text than RFC822 when you are implementing for an IBM
computer using EBCDIC. 

Some mail systems do more layering separating internal format from
presented format. This is nice and gives one more capabilities, but
it is more difficult to implement. Such systems take more time to
develop and may be prone to more bugs.  If one is concerned with
expediency of getting a mail transport up, as HP was, then RFC822
was easier and so was chosen. 

>From some of your comments I can only conclude that NBS is like bad
tasting medicine, It tastes bad at first, but it is good for you in
the long run.  You may be right, but don't be suprised if  the natives
turn to the local witchdoctors for a while, at least until they see
results. I am a bit sorry about that for NBS fans, that seems to be
reality of how implementations go.  I'm sure in a few years this
will all be past history and implementing NBS will be much easier,
particularly if vendors provide implementors with smarter interfaces.

Please don't paint me as an NBS opponent, I'm just one of the wounded.

Scott L. McGregor
-------


Date:     11 Jun 83 7:04:35-EDT (Sat)
From: Larry Layten <llayten@darcom-hq>
Return-Path: <Llayten%Darcom-Hq@Darcom-HQ>
Subject:  Re:  problems with NBS standard
To: DDEUTSCH@Bbna
Cc: MCGREGOR.HP-HULK@Rand-Relay, DDEUTSCH@Bbna, msggroup@Brl,
        header-people@Mit-Mc
Via:  Darcom-HQ; 11 Jun 83 12:40-EDT

So now we have two standards.  One of them has been adopted by the 
DOD/DDN/ARPANET community, and is in operation.  Can someone indicate
what the base of support is for the NBS standard.  If that base is 
not strong enough, maybe changes to the NBS standard wouldn't be too
difficult to implement.

Larry

Date: 11 Jun 1983 16:09-EDT
Sender: DDEUTSCH@BBNA
Subject:  Re:  problems with NBS standard
From: DDEUTSCH@BBNA
To: llayten@DARCOM-HQ
Cc: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY
Cc: msggroup@BRL, header-people@MIT-MC
Message-ID: <[BBNA]11-Jun-83 16:09:21.DDEUTSCH>
In-Reply-To: The message of     11 Jun 83 7:04:35-EDT (Sat) from Larry Layten <llayten@darcom-hq>

The NBS standard is being used in the commercial sector.  When it
was published for review, comments were almost unanimously
favorable.  It just became a standard this January, and will not
come up for review for several years.  A discussion about what
people do and do not like about the standard can be interesting
and informative, but it will not lead to any changes in the
standard in the near future.

The NBS standard was written with full cognizance of RFC 733 (RFC
822 had yet to be written, and isn't fundamentally different).
There was a conscious decision to use a binary encoding instead
of a text-based encoding, for the reasons I have already given
(plus a few others).  The main objection that I have heard in
this discussion is that people don't like binary encoding.  These
people much prefer text-based encoding.  However, that is not the
feeling in the commercial standards arena.

The purpose of NBS standards is to govern procurements of the
federal government.  As Scott has pointed out, a standard isn't
worth the paper it is printed on if nobody implements it.
However, vendors have indicated that the standard is acceptable
to them by their comments made during the review process and by
their explicit announcements that they will support it.  It is
the endorsement of the vendors that is important in approving a
FIPS, and NBS has received that endorsement for its message
format standard.

When the standard comes up for review in a few years, NBS will
again consider what to do.  At that time, if the vendors say that
the standard could not be implemented cost-effectively, or that
there was some serious technical flaw, NBS would probably want to
reconsider the whole matter.  On the other hand, if the vendors
are still happy with the standard, NBS would probably only
consider refinements to the current document.  (Of course, the
other important players are the government agencies that buy from
the vendors.  They were also quite supportive of the standard
when it went out for comment.)

The important contribution that MsgGroup can make is to come up
with ideas that will be helpful during the next review period.
So far, people who have actually implemented the standard have
reported no problems.  If this trend continues, NBS will be
interested in ways of extending the standard where additional
functionality may be warranted, and refining the standard where a
simpler or more powerful mechanism can be substituted for what is
already there.  Of course, if somebody were to implement the
standard and then find a problem with it, NBS would be very
interested indeed!

Debbie

Date: 11 Jun 1983 1443-PDT
Sender: BILLW at SRI-KL
Subject: Re:        SMTP and unknown or mismapped host names
From: BILLW at SRI-KL
To: v.wales at UCLA-LOCUS
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KL]11-Jun-83 14:43:24.BILLW>
In-Reply-To: Your message of           Fri, 10 Jun 83 22:08:23 PDT

Actually, what brought this up was I remember reading last year about
the serious security bug introduced by putting your imp into loopback
mode, in which case people connecting to you would actually be connecting
to themselves (or some such).  SOMEBODY said that "SMTP does contain
a mechanism for making sure you are talking to the host you think you
are talkng to".  Wonderful.  How coe nobody is using it.

BillW

Date: Sat 11 Jun 83 23:36:04-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re:        SMTP and unknown or mismapped host names
To: BILLW@SRI-KL.ARPA
cc: v.wales@UCLA-LOCUS.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "BILLW at SRI-KL" of Sat 11 Jun 83 14:43:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Bill -

     Putting your IMP in loopback mode does not cause a problem with
TCP the way it did with NCP.  TCP is not mirror-reflective the way NCP
was, so it is impossible to connect to a host and get yourself unless
that host actually does a logical loopback in its software.  There is
no good reason for a host to do that, and I've only seen it done once
in all the years I've been on ARPANET.

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

Date: 12 June 1983 0405-EDT
From: Rudy.Nedved@CMU-CS-A
To: BILLW@SRI-KL, Mark Crispin <MRC@SU-SCORE>
Subject: Re: SMTP and unknown or mismapped host names
CC: v.wales@UCLA-LOCUS, Header-People@MIT-MC
In-Reply-To: "Mark Crispin's message of 12 Jun 83 01:36-EST"
Message-Id: <12Jun83.040519.EN0C@CMU-CS-A>

SATNET-ECHO and some other echo sites do a pretty good job of letting
you connect to yourself under TCP. At CMU, we discovered a couple of
bugs when our "surveys" hit one of these IP echoers. My SMTP survey
program ended up checking to make sure that the HELO response was NOT
its own name. I would have liked to check the remote name but many
sites gave out "You are a charlatan", some nickname, some unofficial
name or "Command recieved" instead of the official "that side of the
net" host name.

Nothing bad has happened lately to get us to put the HELO response
checks in yet but I have a feeling we will sometime down the line
when some site swaps addresses (like when NBS-VMS and Wharton changed
IMP ports). It all depends on how slow NIC does table updates and
how often addresses get swapped or re-used.

-Rudy

Date: Sun 12 Jun 83 01:26:15-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: SMTP and unknown or mismapped host names
To: Rudy.Nedved@CMU-CS-A.ARPA
cc: BILLW@SRI-KL.ARPA, v.wales@UCLA-LOCUS.ARPA, Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 12 Jun 83 01:05:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The TOPS-20 SMTP server (both ISI's and mine) outputs the host name
prior to the "You are a charlatan".  In fact, I modeled my response
to the HELO command after ISI's, since it was written by the people
who designed SMTP.

You probably should call the protocol police out on sites which give
completely erroneous responses.

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

Date: 12 Jun 1983 1404-PDT (Sunday)
From: eric%UCBARPA@Berkeley
Subject: mail loop caused by sendmail (166 lines)
Message-Id: <13382.31.424299882@ucbarpa>
Received: by UCBARPA.ARPA (3.344/3.32)
	id AA14066; 12 Jun 83 14:04:45 PDT (Sun)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.31)
	id AA07707; 12 Jun 83 13:59:30 PDT (Sun)
Phone: (415) 548-3211
To: MsgGroup@BRL, Header-People@MIT-MC
Cc: nowicki%Diablo@SU-SCORE
Fcc: mail

As the author of sendmail, the new mail router out of Berkeley, I feel
compelled to respond to the explanation of the mail loop given by Bill
Nowicki a few days ago.  Part of this will be a defense, and part will
be a confession.  I hope that this will be an interesting lesson in
software engineering, if nothing else.  I have had plans to turn this
into a paper for some time, but a preview seems appropriate.

Let's start with confessions.  I agree completely with the criticism
that sendmail is just too big and too baroque.  This results from
several forces.

First, I didn't understand the problem when I started.  Part of this
was because initially I was trying to solve an isolated problem on one
machine at Berkeley; I had no idea that it was going to turn into a
general problem.  Indeed, it was never my "job" to do delivermail or
sendmail -- they were "small" (hah!) spare time projects.  However, the
other side of this was that there was almost nothing published
regarding mail routing at that time.  I suppose MsgGroup et al existed
at that time, but since there does not exist a publicized list of
mailing lists, I did not know about them.  In summary: the Arpanet
community is a difficult community to break into, almost as difficult
as the Unix-Wizards community, with no one willing to talk to you until
you know the ropes, but no way to learn the ropes unless someone will
talk to you.

Second, I was entirely too susceptible to criticism.  All of us have
heard stories of offensive people in the community who are sure that
they have all the right answers and will not listen to anyone.  I
continue to believe that this is a serious problem that has been all
too prevalent.  But I now understand the other extreme to be equally as
bad: the person who puts in anything that anyone suggests ends up with
a monster with a voracious appetite.  I gained enough confidence to
start saying "no", but too late.  I have tried to take out features,
but it proves harder to take features out than to never put them in in
the first place.

Third, I underestimated the complexity of the problem.  I contend that
single-letter identifiers are fine when you have eight or ten
identifiers.  In my early configuration tables this was indeed the
case.  When I had to go to split case I should have realized that
something was wrong, but it was so easy to go to split case and so hard
to go to full words; besides, I had other reasons to stick to single
character identifiers (see below).


Now for some defense.  I will start with the simple rebuttals and then
move on to the more sweeping issues.

It is not the case that configuration tables are not portable.  The
host name is available.

Sendmail is not intended as a "user interface."  My intent was was to
be able to read the configuration file doing a fairly trivial amount of
parsing -- hence the single letter identifiers, etc.  Similarly, the
command line arguments are not required to be highly user-friendly,
because they are for use by gurus (who presumably have a certain level
of intelligence and care) and not by the casual user.

About 50% of the configuration table need not be touched until RFC911
comes out (or whatever the next mail protocol is).  A large amount of
the complexity was put in during the 733 => 822 transition; during that
period it was important to be able to handle either protocol.  The
roughest part of that was route-addr's; production systems seem to be
able to handle left-to-right parsing well, and right-to-left parsing
adequately, but both at once is a real pain.  If the route-addr's had
been in the syntax "user@hostc@hostb@hosta" indicating "route to hosta,
then hostb, then hostc" it would have been unambiguous, closer to 733,
and strictly right-to-left.

Sendmail sits in a difficult position.  Many of the mail servers on the
Arpanet speak only to SMTP-compatible hosts.  Sendmail talks to SMTP,
UUCP, Purdue Net, Berknet (which uses colons [ugh] in addresses),
Phonenet (via MMDF), and can be made to talk to others fairly
trivially.  This adds an untold amount of complexity.  Was this a
mistake?  Perhaps.  My idea was to build a "language" (i.e., the
configuration file) that could be programmed to handle the various
address formats, etc.  I find myself under fire from all sides for
this.  The world is filled with UNIX-egoists who care only about UUCP.
They are exceeded only by the SMTP-egoists who claim to be building an
"Internet" based on only one style of communication.  Yes, sendmail is
complex, because it deals with a complex problem.

(By the way, at one time I considered MMDF to be a competitor.  At this
point I have only the greatest respect for MMDF and it's implementors;
if nothing else comes out of this project, I will have developed a
contact, respect, and even a degree of friendship with Dave Crocker,
Dave Farber, Brendan Reilly, Doug Kingston, and others who have done a
magnificent job with a problem so complex that most people cannot even
comprehend it.)

Strangely enough, one of my recent conclusions is that the obscurity of
the configuration file is an advantage!  Such heresy deserves
explanation.  I have discovered (much to my disappointment) that the
world is full of people who have no concern whatsoever for protocols.
These people are typically called "hackers" and are frequently located
far enough off the beaten path that the protocol police cannot find
them or cannot touch them.  These are people who change Date: lines to
be UNIX-style date lines because it is "more standard," people who
delete Received: lines because they don't like them and don't
understand their importance, people who insist on their "right" to use
user@hosta@hostb even though it clearly violates the protocols, etc.
This one really falls in the "confession" section, because I now
realize that people who are afraid to touch code think nothing of
touching a configuration file.  The bottom line is that it may be
better to leave the configuration somewhat unapproachable than to make
it easy for hackers to make gratuitous changes.

Finally, no system can protect itself from the person who uses it
incorrectly.  It seems bizarre to me that sendmail can be criticized
for functioning correctly.


Today, I would do a number of things differently:

Although I remain convinced of the power of the configuration file, I
would limit the contents.  For example, I would retain the concept of
protocol conversion, but only for the most simple cases, such as
converting domain-based addresses (as used internally) into
Arpanet-based addresses (e.g., I map "user@host.BITNET" into
"user%host.BITNET@Berkeley.ARPA").  The configuration file would map
external addresses into internal (domain-based) addresses, but after
that the parsing would be ad hoc; in particular, the inside-out
route-addr's are just too difficult to parse in a production system
(which I would probably retain).

I would certainly push the absurd cases (e.g., UUCP so-called
"addresses" which are really routes) into another module.

Given that I seem to have more power and respect now than I once did, I
would almost certainly simply outlaw colons in addresses and convert
Berknet to use another syntax.

I would make the configuration files a very different format, but
include a compiler that would generate something that could be read
very quickly.  The compiler could also do a lot of checking.


Morals (some are my personal opinions):

1. Case sensitivity is a bad idea.  2. Single letter identifiers are a
bad idea if you have more than
   about ten of them.  3. Multiple notions that are similar are
confusing, but sometimes
   necessary; there is a difficult balance between exploiting the
   similarities and accentuating the differences.  4. internet mail
systems are fragile things.  5. "Improved" software with more
"features" sometimes is and sometimes
   isn't: the important thing is to realize that every feature has both
   a cost and a benefit.  6. (Corollary 1) One man's feature is another
man's bell or whistle.  7. Both the UNIX and the Arpanet community
could afford to learn
   from the other.  8. Flexibility is a nice thing, but too much
flexibility can backfire.  9. Better loop/duplicate detection is
needed.  Message-Id's should
   be required in all messages at their origination to make this
   feasible.  Message-Id's should probably be in a well-defined format
   to simplify their use, e.g., <date-time.pid@domain>; this would
   allow the database to implement timeouts on the message-id's after
   (say) one week trivially, etc.

eric

Date: 12 Jun 1983 1501-PDT
From: POSTEL at USC-ISIF
Subject: re: SMTP and Unknown Host Names
To:   header-people at MIT-MC


Actually, the notion in the SMTP opening sequence where the host names are
exchanged in the HELO command and reply was to check that the connection
was between the intended hosts.  One early TOPS20 implementation gave a
5xx reply code if it did not believe the host name.  This involved quite
a bit of work - it checked to see if the name given matched the official
name or any of the nicknames for the host on the other end of the 
connection (determined by looking up the host associated with the Internet
Address of the other end of the TCP connection).  Early debugging caused
this to be changed to a 250 response in all cases (though it still complains
in the text of the reply).  This was because several sites did their 
debugging either using a strange host name or using a different internet
address.  Perhaps, if we went back to giving the 5xx reply, sites would pay
more attention to having up to date host tables?

--jon.
-------

Date: 13 Jun 83 09:52:10 PDT (Monday)
From: Curbow.ES@PARC-MAXC.ARPA
Subject: Re: problems with NBS standard
In-reply-to: llayten's message of 11 Jun 83 7:04:35 EDT (Sat)
To: header-people@Mit-Mc.ARPA
cc: curbow.es@PARC-MAXC.ARPA

"If the base is not strong enough..."?

Maybe we can change COBOL into PL/1 if the opposition is not too strong. 

I have to say that it seems to me that the NBS standard is much like COBOL.
It is a reasonable standard, even if it is not perfect.
Up to now everyone has their own protocol. (Remember all the vendor supplied 
languages that were specific to their machines and no way to transport programs
to other systems?) 
 
I applaud NBS for getting something out that everyone can live with.
Give it a chance before you try to change it.

Date: 13 Jun 83 09:52:10 PDT (Monday)
From: Curbow.ES@PARC-MAXC.ARPA
Subject: Re: problems with NBS standard
In-reply-to: llayten's message of 11 Jun 83 7:04:35 EDT (Sat)
To: header-people@Mit-Mc.ARPA
cc: curbow.es@PARC-MAXC.ARPA

"If the base is not strong enough..."?

Maybe we can change COBOL into PL/1 if the opposition is not too strong. 

I have to say that it seems to me that the NBS standard is much like COBOL.
It is a reasonable standard, even if it is not perfect.
Up to now everyone has their own protocol. (Remember all the vendor supplied 
languages that were specific to their machines and no way to transport programs
to other systems?) 
 
I applaud NBS for getting something out that everyone can live with.
Give it a chance before you try to change it.

Date: 16 Jun 1983 1258-PDT
From: KLH at SRI-NIC
Subject: Header-People pollution
To: Taft at PARC-MAXC
cc: header-people at MIT-MC

I agree that it is annoying to paw through the stuff sent by people who
don't know whether to address messages to Header-People or MsgGroup and
consequently send them to both.  The recent mail loop made this worse.

However, I think it is perfectly within the domain of Header-People to
point out interesting bugs that are uncovered in mailers around the network,
especially when header format or transmission protocol errors are involved;
this particular instance looked interesting to me (still does).

I consider Header-People to consist of mail implementors and hackers who
know how things work and have the ability (if not time) to fix them when
they don't work.  Now that RFC 733 and 822 are under the bridge, one
might think of it as a technical gossip ring.  I hope that you don't
feel unfairly singled out; I suspect every implementor on the list has
been in the limelight at some time, since mail mistakes tend to be rather
public.  Certainly I have seen my share of eggs every time an "ITS-format"
header escaped to the network, and that's a minor piffle compared with the
bug that made Header-People a black hole for a couple months!

--Ken
-------

Received: by UCBVAX.ARPA (3.346/3.33)
	id AA23482; 20 Jun 83 12:46:40 PDT (Mon)
Date: 20 Jun 83 15:37:46 EDT (Mon)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: loop detection
Message-Id: <8306201937.AA00975@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA00975; 20 Jun 83 15:37:46 EDT (Mon)
To: header-people@mit-mc

	It seems to me the correct way to do this is with the Received: header.
	Mail servers put in Received, including "for <addresses>".  (I believe
	the BNF in 822 doesn't allow for multiple addresses, but it could be
	fixed.)  The mailer detects a loop by the presence of two Received
	headers, both of which have "by <this-host>" and "for <same-addresses>".
	Unfortunately, when mailing lists are expanded at a foreign site, the
	list of <addresses> can get very long.
	
There are legit ways for a message to go through the same system more than once.
For instance, if I send mail to header-people@mit-mc.arpa, it must go through
	cbosgd (the originating system)
	ucbvax (the mail gateway between UUCP and ARPA)
	mit-mc (the mailing list exploder)
		(at this point, one copy addressed to, say, smb@mhb5b.uucp:)
	ucbvax (the mail gateway between UUCp and ARPA)
	cbosgd (as a forwarder)
	mhb5b  (the destination machine)
I'm sure you can think of convoluted examples with 3 or 4 passes through
the same system.  However, the number of passes tends to be small.

Usenet detects multiple articles and throws the second copy away.  The
duplicates are detected primarily by checking the Message-ID, but also
by not sending an article to a site that it has already gone through.
However, these methods assume (1) a Message-ID is in every message (as
it must be on Usenet), (2) each system remembers every Message-ID that
has been recently received (it keeps a history file), and (3) it never
makes sense to receive the same article on one machine more than once.

This third assumption is not valid for mail, as shown by the example above.
The pair (Message-ID, recipient) could be used in place of the Message-ID;
I suspect this would eliminate loops without causing too many problems.
Of course, the problem of a truncated message followed by the full text
of the same message still must be addressed.

Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Mon 20-Jun-83 19:33:19-EDT
Date: Mon, 20 Jun 83 19:29 EDT
From: Mike McMahon <MMcM@SCRC-TENEX>
Subject: Re: loop detection
To: cbosgd!mark@UCB-VAX
Cc: header-people@MIT-MC
In-reply-to: <8306201937.AA00975@cbosgd.UUCP>
Message-ID: <830620192941.3.MMcM@SCRC-TENEX>

    Date: 20 Jun 83 15:37:46 EDT (Mon)
    From: cbosgd!mark@Berkeley (Mark Horton)

	    It seems to me the correct way to do this is with the Received: header.
	    Mail servers put in Received, including "for <addresses>".  (I believe
	    the BNF in 822 doesn't allow for multiple addresses, but it could be
	    fixed.)  The mailer detects a loop by the presence of two Received
	    headers, both of which have "by <this-host>" and "for <same-addresses>".
	    Unfortunately, when mailing lists are expanded at a foreign site, the
	    list of <addresses> can get very long.
	
    There are legit ways for a message to go through the same system more than once.
    For instance, if I send mail to header-people@mit-mc.arpa, it must go through
	    cbosgd (the originating system)
	    ucbvax (the mail gateway between UUCP and ARPA)
	    mit-mc (the mailing list exploder)
		    (at this point, one copy addressed to, say, smb@mhb5b.uucp:)
	    ucbvax (the mail gateway between UUCp and ARPA)
	    cbosgd (as a forwarder)
	    mhb5b  (the destination machine)
    I'm sure you can think of convoluted examples with 3 or 4 passes through
    the same system.  However, the number of passes tends to be small.
That's what "for" is for.  It is not "legit" for a message to go through
the same system more than once -for the same recipient-.  In your above
example, messages pass through once as "for header-people@mit-mc.arpa"
and once again as "for smb@mhb5b.uucp".

    Usenet detects multiple articles and throws the second copy away.  The
    duplicates are detected primarily by checking the Message-ID, but also
    by not sending an article to a site that it has already gone through.
    However, these methods assume (1) a Message-ID is in every message (as
    it must be on Usenet), (2) each system remembers every Message-ID that
    has been recently received (it keeps a history file), and (3) it never
    makes sense to receive the same article on one machine more than once.
No, Message-ID does not work in the face of remailing.  You would need
to look for remailed-message-id first, which is more error prone in the
face of systems that don't conform to header standards.  For example, those
systems that call remailing redistributing.

And you need a history file, which is either huge, or its lifetime
limited.

Date: 22 June 1983 00:18 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject:  loop detection
To: cbosgd!mark @ UCB-VAX, MMcM @ SCRC-TENEX
cc: HEADER-PEOPLE @ MIT-MC
In-reply-to: Msg of Mon 20 Jun 83 19:29 EDT from Mike McMahon <MMcM at SCRC-TENEX>

Also, sites could start using the SMTP EXPAND command to
eliminate loops and duplicates both as long you're dealing with
directly connected sites.

Date: 22 Jun 1983 0214-PDT
From: Henry W. Miller <Miller at SRI-NIC>
Subject: Re: loop detection
To: EAK at MIT-MC, cbosgd!mark at UCB-VAX
cc: HEADER-PEOPLE at MIT-MC, Miller at SRI-NIC
In-Reply-To: Your message of 22-Jun-83 0018-PDT

	Alas, many SMTP servers do not have EXPN implemented yet...

-HWM
-------

Received: by UCBVAX.ARPA (3.346/3.33)
	id AA16259; 23 Jun 83 12:31:19 PDT (Thu)
Date: 23 Jun 83 15:26:25 EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: problems with NBS standard
Message-Id: <8306231926.AA07210@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA07210; 23 Jun 83 15:26:25 EDT (Thu)
To: OLE@SRI-CSL.ARPA
Cc: header-people@mit-mc.ARPA

Well, I understand wanting to keep your own culture.  However, I'm sure
you're aware that there are some incredibly hairy technical problems
with trying to get a machine to translate natural languages.  If someone
with an appropriate incentive wants to tackle these problems, great.
But I (being an American who only speaks English and has no particular
interest or need to learn other languages, and also having far more to
do than time to do it already) can't afford to spend more of my time
worrying about foreign languages or funny formats that were invented to
make foreign languages easier.

Now that we've flamed a bit, let me make a comment aimed a constructive
solution to the problem.  No, I won't say that everyone should speak
English (although that would certainly be convenient, and seems to be
true of 99.9% of the world's computing population now), rather, I
expect that a gateway translator might be useful.  Here are two such
translators:

(a) Assuming there will be only RFC822 style mail networks: when a message
crosses a boundary between a country whose official language is X and
another country speaking Y (X != Y), a gateway program does a fixed
translation of all the 822 headers from language X into Y, using a
fixed, predefined table.  No attempt is made to translate the text
of the message - that's up to the individuals.

(b) Since the NBS standard is a standard, I assume there will soon be
NBS mail networks around.  There will be gateways to RFC 822 networks.
So the gateway translates from one format to the other.  Then the rest
of the world need only understand their own format.  (This takes care
of the header names, glibly assuming there is a 1-1 mapping between 822
and NBS, and that NBS is extensible, and that the user address syntax
can be reasonably mapped from one to the other format.  I suppose I
should get the NBS standard and read it, in my copious free time.)

Date: 26 June 1983 16:44 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject:  loop detection
To: Miller @ SRI-NIC
cc: HEADER-PEOPLE @ MIT-MC, cbosgd!mark @ UCB-VAX
In-reply-to: Msg of 22 Jun 1983 0214-PDT from Henry W. Miller <Miller at SRI-NIC>

    Date: 22 Jun 1983 0214-PDT
    From: Henry W. Miller <Miller at SRI-NIC>

    	Alas, many SMTP servers do not have EXPN implemented yet...

Yes, but most mail traffic is between local hosts.  E.g. if MIT
or Stanford or SRI implemented EXPN in its senders and receivers
then they would get 80% of the benefit to be had because most of
their mail is from local host to local host.  That's why EXPN is
interesting even though it doesn't solve the loop problem for
hosts that you can't establish a direct connection to.  As a side
benefit, it puts the mail sending burden on the site that sent
the mail, not the site that has the mailing list.

Date: 27 Jun 1983 0211-PDT
From: Henry W. Miller <Miller at SRI-NIC>
Subject: Re: loop detection
To: EAK at MIT-MC
cc: HEADER-PEOPLE at MIT-MC, cbosgd!mark at UCB-VAX, Miller at SRI-NIC
In-Reply-To: Your message of 26-Jun-83 1644-PDT

	EXPN could help preveent looping, or multiple receipieents.
Remember, the NIC talks to EVERYONE!!!  Thhanks for your feedback.

-HWM
-------

Date:     27 Jun 83 10:40:22-EDT (Mon)
From: Dave Crocker <dcrocker@udel-relay>
Return-Path: <Dcrocker@UDel-Relay>
Subject:  NBS / 822
To: Header-People@mit-mc

This is to reinforce Debbie Deutsch's comments and to provide you with
a little history:

RFC733 was primarily intended to codify existing practises, with a "few"
improvements.  In fact, we seriously considered scrapping the free-text
approach and going to some encoded standard, such as Postel's MPM.  It
was decided, however, that the Arpanet world was not yet ready (read that
as "willing") to invest the effort at converting over.  RFC822 was,
again, intended for the short-term, although this time I think we know
that that means several years.

It is certainly true that 822 is easier to implement than the NBS
standard.  For most straight-text mail systems, 822 is probably quite
adequate.  However, as soon as you want more data structuring or
multiple data types, the NBS and MPM approaches are necessary.

Someone would do the world a considerable service by specifying
the translations between 822 and NBS, formally.  As Mark Horton
notes, such mail relaying will occur.  It is probably better
to specify hour the relays should behave, rather than let
each one decide on its own.

Dave

Received: by UCBVAX.ARPA (3.346/3.33)
	id AA26200; 29 Jun 83 17:44:51 PDT (Wed)
Date: 29 Jun 83 14:53:13 EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: time zones
Message-Id: <8306291853.AA20463@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA20463; 29 Jun 83 14:53:13 EDT (Wed)
To: dcrocker@udel.ARPA, postel@isif.ARPA
Cc: header-people@mit-mc.ARPA

Minor correction for the successor to RFC 822:

I am told that UTC is the favored abbreviation for Universal Time,
rather than UT or GMT.  I suppose it would be better to accept
them all, but to generate UTC.

By the way, there are a lot of other time zones whose names seem
to have been deleted from 733 to 822.  Was this deliberate?  I'd
be interested to know the reasons, especially since some of those
time zones include ARPANET hosts, and certainly the internet will
eventually include most of them.  I'm thinking not only of the
far out North American zones (Atlantic, Newfoundland, Yukon,
Alaska/Hawaii), but also of Australian and European zones.  I'm
enclosing the data for reference in the next table:

Letter	Zone name			UTC+x	normal	daylight

N					-1
O					-2
P					-3
	Newfoundland			-3.5	?NST	?NDT
Q	Atlantic			-4	AST	ADT
R	Eastern				-5	EST	EDT
S	Central				-6	CST	CDT
T	Mountain			-7	MST	MDT
U	Pacific				-8	PST	PDT
V	Yukon				-9	?YST	?YDT
W	Alaska-Hawaii			-10	?AHST	?AHDT
X	Bering				-11	?BST	?BDT
Y					-12
M					+12
L					+11
K	Australian Eastern		+10	AEST	AESST (summer time)
	Australian Central		+9.5	ACST	ACSST
I	Japan, Korea			+9	?	?
H	Australian Western		+8	AWST	AWSST
G					+7
F					+6
E					+5
D					+4
C					+3
B	Eastern European		+2	EET	EET DST
A	Middle European			+1	MET	MET DST
Z	Western European		+0	WET	WET DST
	Coordinated Universal Time 	+0	UTC
	(UTC is also known as UT and GMT)

I'm sending a copy of this to header-people in the hope that mail
system maintainers that have written programs to parse dates will
arrange for them to parse these time zones as well as the usual
American four.  For the most part it shouldn't be hard to add them
to existing tables.  I'd also like to make people aware that the
assumption of a 3 letter time zone abbreviation is NOT always valid.
(I have had Australians express frustration at finding code containing
this assumption.)

Also note that the rules for when and whether to go on daylight saving
time vary from country to country.  I'm sure many of your are familiar
with the various arcane rules in the USA (some states or parts of states
don't go at all; the rules were different in 1974 & 1975) - the rest
of the world has just as many funny rules.  Fortunately, this doesn't
normally matter, since you only have to generate dates in your own
time zone.  You must, however, often understand dates containing other
time zones.

I had to do considerable digging and asking around to get this information.
The friendly atlas and encyclopedia weren't much help - they show a map
with hour offsets but no time zone names.  Thus, this table is not as
complete as I would like.  If anyone can fill in any of the blanks, I'd
be grateful.  I also suspect there are more multiple names for certain time
zones, too, at different latitudes.

We are rapidly coming into an age where the whole world sends electronic
mail to each other, and can no longer afford to be ignorant of foreign
time zone conventions.  We do have a provision for hour offsets and single
zone letters in 822, but we don't use these conventions in America, and
we must realize that foreigners don't use them either.

	Mark Horton

Date: Wed, 29 Jun 83 19:00 PDT
From: Taft.PA@PARC-MAXC.ARPA
Subject: Re: time zones
In-reply-to: Mark Horton <8306291853.AA20463@cbosgd.UUCP>
To: header-people@mit-mc.ARPA
cc: Taft.PA@PARC-MAXC.ARPA

This is a fine example of the sort of trouble you get into when user
interface issues are permitted to creep into computer communication
protocols.

The way in which dates and times are presented to humans is subject to
many local conventions and is subject to occasional change.  It's
totally unreasonable that every program in the world should have to
understand the union of all the world's conventions for presenting dates
and times to humans.

Ideally, RFC 822 should specify ONE form for specifying date and time.
I don't care what form it is, so long as its meaning is unambiguous.
RFC 822 is better than 733 in this regard, though there are still many
ways to express a given value of time.  If anything, we should REMOVE
variability from the date and time syntax, not add more.

If we were starting over, it would be best to pick something completely
neutral, not tied to native language, daylight savings time conventions,
military vs. civilian conventions, etc., so as to forestall religious
discussions.  I offer as an example a decimal number which is the number
of seconds since some arbitrary starting date.  Most computers already
use this sort of representation for maintaining their internal calendar
clocks.  The responsibility of converting this to a human-readable date
and time is then shifted to the user interface software where it
belongs.

	Ed Taft


Date: 30 Jun 1983 0223-PDT
From: Henry W. Miller <Miller at SRI-NIC>
Subject: Re: time zones
To: Taft.PA at PARC-MAXC, header-people at MIT-MC
cc: Miller at SRI-NIC
In-Reply-To: Your message of 29-Jun-83 1914-PDT

	Yep, this drove me batty here, while trying to debug the
timeserveer, until, after many blastings from the net, I realzed
that the code was using the wrong format...

-HWM
-------

Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA by Mailnet; 30 Jun 1983 13:02:20 edt
Date: Thu, 30 Jun 83 09:31:50 EDT
From: Gavin_Eadie@UMich-MTS
To: header-people@MIT-MC.ARPA
Message-ID: <206472@UMich-MTS>
Subject: Time Zones

Mark's  presentation  of  time  zone  names from all over the atlas
reminds me of one problem that arose with the 'BST' acronym. In the
UK  it means 'British Summer Time' -- in the frozen wastes it means
'Bering Standard Time'!

              ... Gavin (Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS)

Date: 30 Jun 1983 1016-PDT
From: POSTEL at USC-ISIF
Subject: re: time zones
To:   header-people at MIT-MC


What about the potential confusion between (1) BST and (2) BST?
(1) is obviously British Summer Time, while (2) is obviously Bering Standard
Time.

By the way -- what should be done about the leap second that gets inserted into
time today?

--jon.
-------

Received: from Shasta by Score with Pup; Thu 30 Jun 83 10:54:30-PDT
Received: from decwrl by Shasta with UUCP; Thu, 30 Jun 83 10:56 PDT
Date: Thursday, 30 Jun 1983 10:50-PDT
To: Shasta!"POSTEL@USC-ISIF"
Cc: Shasta!"header-people@MIT-MC"
Subject: re: time zones
In-reply-to: Your message of 30 Jun 1983 1016-PDT.
From: Chris Kent <decwrl!kent%Shasta@SU-Score>
Message-ID: <34.425843432@decwrl>

Clearly, we should all reset our clocks.

Speaking of which, why isn't there a widely-known WWV clock somewhere
on the Internet?

Cheers,
chris


Date:  30 June 1983 15:13 edt
From:  Barry Margolin at MIT-MULTICS
Subject:  Re: time zones
To:  POSTEL at USC-ISIF
cc:  header-people at MIT-MC
In-Reply-To:  Message of 30 June 1983 13:16 edt from POSTEL

    By the way -- what should be done about the leap second that gets inserted into
    time today?

I think this can be ignored, since the accuracy of the operators who set
the time on most computer systems probably averages to about a minute
off.
                                        barmar

Date:     Thu, 30 Jun 83 18:02:02 EDT
From:     Ron Natalie <ron@brl-bmd>
To:       POSTEL@usc-isif
cc:       header-people@mit-mc
Subject:  Re:  time zones

Obviously all mail systems that get letters during the additional
second should queue them for transmission the next day to avoid
confusion.

 o o
\___/


Date: 30 Jun 1983 1717-PDT
From: MILLS at USC-ISID
Subject: re: time zones
To:   POSTEL at USC-ISIF, header-people at MIT-MC
cc:   MILLS at USC-ISID

In response to the message sent  30 Jun 1983 1016-PDT from POSTEL@USC-ISIF

Jon,

I should know better than to jump into this pot:

1. I like Ed Taft's suggestion best: Standard Time is so many seconds past
   a historical epoch (IEN-142), expressed as a decimal integer.

2. If (1) is unacceptable, then the only zone understood anywhere is UT
   (GMT) as per standard time broadcast services in many countries. Local
   zone conversions are optional, but not specified as part of SMTP (or
   RFC-822 for that matter).

3. Our Fuzzball hosts are synchronized to NBS time via radio (WWVB) and generally
   maintain standard time to within a few milliseconds or so. When a leap second
   is inserted by WWVB the apparent time on these hosts will slew to the correct
   value at a rate of about one millisecond per second. User interface routines
   provide the correction factor, so a program can determine the exact time even
   during the slew, although at somewhat reduced accuracy. The right way to do
   this is to have advance notice that the leap will happen and zig when it zags.

Regards,
Dave
-------

Received: from Glacier by Score with Pup; Thu 30 Jun 83 17:45:07-PDT
Date: Thursday, 30 Jun 1983 17:44-PDT
To: Ron Natalie <ron at Brl-bmd>
Cc: header-people at Mit-mc
Subject: Re:  time zones
In-reply-to: Your message of Thu, 30 Jun 83 18:02:02 EDT.
From: Brian Reid <reid%Glacier@SU-Score>

I spent several years in the early 1970's working for various airline
companies doing schedule-planning and reservation systems programming.
One of the things that I noticed while analyzing Delta airlines'
published schedules for that period was that Delta had no planes in the
air during the Daylight/Standard switchover hour, to avoid having to
solve the problem of a plane that takes off on standard time and lands
on daylight savings time, or vice versa. Your idea of requeueing mail
for that extra second sounds like the same principle.


Date: 30 Jun 1983 1738-PDT
From: MILLS at USC-ISID
Subject: NBS time servers
To:   decwrl!kent%Shasta at SU-SCORE
cc:   Header-people at MIT-MC

Chris,

Shame on you for that naughty "to:" field in your message!

IEN-142 time servers synchronized to NBS:

DCN1 (aka LINKABIT) 128.4.0.1 (synchronized to WWVB)
FORD1 (akda FORD) 128.5.0.1 (synchronized to GOES)

Regards,
Dave
-------

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 1 Jul 83 02:31:59 PDT
Via:  Rlgk.AC-UK; to UCL-CS.AC-UK (44b) over Sercnet with NIFTP; 
          1 Jul 83 9:42 BST
From:    Philip Gladstone (on GEC 4090 at Rutherford) <NSIN08@RLGK>
To:      Header-People @ Mit-MC.Arpa
Date:    Fri, 1 Jul 83 09:25 BST
Subject: Time zones
Message-Id: <01 JUL 1983 09:41:03 NSIN08@RLGK>

The long list of time zones produced my Mark Horton does not include the
ones I use:

  +0       GMT             BST   (British Summer Time)

  In Germany
  +1       MEZ             MESZ  (The Z stands for something in German)
  In Switzerland
  +1       CET             CEST  (C is Central)

We have always noted that BST clashes with Bering Standard Time, and so
we were pleased when it was taken out of 822 - so that we could re-use it
by extending the spec rather than disagreeing with it.

The way that the CCITT MHS represents times is as:
      YYMMDDhhmm[+/-hhmm]     where the +/-hhmm  indicates the time difference
from UTC.  This does have the advantage that it is sufficiently unreadable to
force any user interface to redisplay it in a more reasonable format.

     Philip Gladstone



Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Jul 83 15:59:54 EDT
Date: 22 Jul 83 1540 EDT (Friday)
From: Craig.Everhart@CMU-CS-A
To: MILLS@USC-ISID, Header-People@MIT-MC
Subject: Re: time zones
In-Reply-To: "MILLS@USC-ISID's message of 30 Jun 83 19:17-EST"
Message-Id: <22Jul83.154019.CE10@CMU-CS-A>

When an IEN-142 time server returns a number of seconds since some epoch, does
that number account for the leap seconds that have crept into NBS time?
There is an obvious disparity between the actual number of seconds since the
epoch and the number of seconds that there would have been had the Gregorian
calendar been strictly obeyed.  It's too bad that applications want both
values.  Which ones are being returned?

Dave Mills' compromise is excellent for applications bursting the universal
time into local components, without disturbing precise interval-timing
applications by more than 0.1 percent.  But is there a better solution?

		Craig Everhart

Date: 23-Jul-83 05:10:28-UT
From: Mills@dcn6
Subject: Time-server leaps and bounds
To:   Craig.Everhart@CMU-CS-A
cc:   Header-people@MIT-MC

Craig,

I have done a little digging on the leap-second problem. The broadcast
standards on which our network time-distribution system is based provide
time-of-day, day-of-year and certain corrections and offset information. The
NBS broadcast formats are described in "NBS Special Publication 432, Time and
Frequency Dissemination Services (1979)." Essentially equivalent information
is broadcast on LF and HF frequencies and via the GOES satellite. Our receiver
uses the LF broadcasts from Boulder, Colorado.

The broadcasts provide precise timing information along with time-of-day,
day-of-year and certain corrections and offsets. There are two time scales of
interest: UTC, commonly called "atomic time" and UT1, commonly called
"astronomical time." The broadcast time is UTC; however, UT1 corrections up to
a maximum of about one second are encoded in the data stream. When the
correction exceeds this a leap-second is inserted or deleted; however, the
times when such a correction can be incorporated are known in advance and
coordinated throughout the world by the Bureau des Heure. The obvious way to
do this would be with a control bit set in advance in the broadcast data, as
is done already with leap-year and daylight-saving time control bits. I could
find no reference to this in SP 432, although the errata sheet accompanying
the publication does mention such a bit in connection with the LF broadcasts.
I suspect this may be a typo and in fact the bit does not exist.

Now, your question on the civilized IEN-142 time server returning UTC or UT1
is very interesting and provocative. Since UT1, which drives the diddle in the
first place, is determined by observation and the precision necessary to
determine it to the accuracy required has only recently been achieved, it
would seem uninteresting to establish a Network Standard Time based on UT1. I
suspect all existing IEN-142 servers, like ours, simply brute-force the
calculation assuming no corrections were ever made. This results in our losing
about a second a year, on average.

I would propose a gentleman's solution to this dilemma: the servers should be
expected to return UTC as broadcast by NBS, including the leap-second
correction but omitting the UT1 correction. There should be a protocol to ask
more detailed questions about the procedure, such as when the next leap-second
correction will be made and what the current UT1 offset is. It must then be
understood that time intervals measured using UTC samples can be off by
numbers of seconds relative to UT1, depending on when the corrections were
made.

The behavior of our receiver is unknown in the vicinity of a leap-second
event, but I suspect it probably hiccups and loses synchronization
momentarily. That's why we elected to slew the apparent time at a reasonably
sedately clip when a large change is detected. We do in fact have an
interesting local operational problem: occasionaly somebody gets the year
wrong and all our clocks are off by the exact discrepancy. In retrospect, the
NBS format would have been better advised to include the year and advance
leap-second indicator, but forget the leap-year indicator. Another problem is
the determination of time zone without outside reference. In principle, this
can be done from knowledge of longitude, which is readily available from
either LORAN-C or OMEGA radio navigation systems. Navigation receivers for
these systems are definitely off the scale of our budget, at least. Besides,
some countries are positively kinky about time zones, not to mention
daylight-saving time. Therefore, we punt the whole issue and use Universal
Time (UT, nee GMT) EVERYWHERE in our fuzzballs, which are scattered widely on
the globe.

By the way, in principle advance notice of a leap second can be determined
from the BBC time pips, a series of (usually) five beeps broadcast just before
the hour. Either four or six beeps indicate a leap second more or less on the
following hour epoch. BBC receivers are probably cheaper than OMEGA receivers.
I thought you might like that.

Regards,
Dave

-------

Date: 24 Jul 1983 0303-CDT
From: Clive Dawson <CC.Clive@UTEXAS-20>
Subject: Re: Time-server leaps and bounds
To: Mills@DCN6
cc: Header-people@MIT-MC
In-Reply-To: Your message of 23-Jul-83 0027-CDT

Regarding advance notice of leap seconds, you can also tell how close
we are to a leap second by listening to the NBS broadcasts (WWV). 
If you listen for the first ten seconds of each minute, you will note
that some of the seconds are marked by a double instead of a single
click.  I forget the exact details, but basically number of double
clicks tells how far away from a leap second we are.  Depending on
whether the double clicks occur at the beginning or the end of the
ten second period, a leap second will be omitted or added.  Can anybody
elaborate on the scheme?
-------

Date: 24-Jul-83 15:55:46-UT
From: Mills@dcn6
Subject: Re: Time-server leaps and boundsî
To:   CliveDawson<CC.Clive@UTEXAS-20>, Mills@DCN6,
      Header-people@MIT-MC
In-reply-to: Your message of 24 Jul 1983 0303-CDTî

Clive,

The double-ticks are broadcast by NBS HF services, as well as similar services
of many other countries, at the beginning of the minute. The number of doubled
ticks on seconds 1-8 indicate a positive offset of that many tenth-seconds,
while the number of doubled ticks on seconds 9-16 indicate a negative offset in
the same way. Very dumb for computers but good for humans trying to pick the darn
things out of sferics and noise. Apparently, by gentleman's agreement the offset
is not permitted to exceed eight.

This is the same offset broadcast in the digital time code. If the receiver made
this information available the clever program could extrapolate when the next
correction might be; however, only the BIH officially knows exactly when the
correction will be ordered. I will call people at NBS on Monday to see what else
I can discover.

Regards,
Dave

-------

Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 25 Jul 83 03:09:28 PDT
Via:  Rlgk.AC.UK; to UCL-CS.AC.UK (44b) over Sercnet with NIFTP; 
          25 Jul 83 10:42 BST
From:    Philip Gladstone (on GEC 4090 at Rutherford) <NSIN08@RLGK>
To:      Header-People at MIT-MC.ARPA
Date:    Mon, 25 Jul 83 09:57 BST
Subject: Time clocks.
Message-Id: <25 JUL 1983 09:57:21 NSIN08@RLGK>

The Time service in the UK broadcasts a 'leap second on next hour' bit. We 
actually ignore this, and just jump the time by 1 second when it happens.
The time service also broadcasts the 'national time' and its difference from
GMT - this enables us to work out if we are operating summer or winter time.
    
     Philip


Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 25 Jul 83 07:37:28 PDT
Via:  Rlgk.AC.UK; to UCL-CS.AC.UK (44b) over Sercnet with NIFTP; 
          25 Jul 83 15:07 BST
From:    Philip Gladstone (on GEC 4090 at Rutherford) <NSIN08@RLGK>
To:      Header-people at MIT-MC.ARPA
Date:    Mon, 25 Jul 83 15:07 BST
Subject: Time changes
Message-Id: <25 JUL 1983 15:07:31 NSIN08@RLGK>

Since leap seconds can only be inserted or removed on 00:00 1st July and
00:00 31 December, it should be easy to anticipate this occurence by some time.
An interesting document to read which covers this sort of stuff is
Volume VII of Recommendations of the CCIR 1982. ISBN 92-61-01451-8
 
It goes into great (and gory) detail about time. For example, the time
0.4 sec before 00:00:00 1 July when a leap second has been inserted
is   30 June, 23h 59m 60.6s UTC.
 
It also has tables of most time services and their modulation type.
Well worth getting out of your technical library.
 
Miscellaneous bit of information:  The time taken for Radio waves to reach
your receiver from a transmitter is not constant - it can vary noticeably
even over short distances (1 microsecond variation, 10Km between transmitter
and receiver. Timescale of variation is small (seconds))


Date: 25 Jul 1983 1117-PDT
From: MILLS at USC-ISID
Subject: Another stitch in time
To:   Header-people at MIT-MC

Philip,

Thanks for the information on UK broadcast information. I assume that is
on the LF service, not MSF. The NBS broadcast services (except GOES) also
have a summertime bit, but not a leap-second bit. And yes, I do know how
radio propagation effects affects the precision. Your CCIR reference may
clear up some lingering details.

I called NBS and found that, indeed, there is no advance notice of a
leap second in any code they use. I was also told that leap seconds
cannot reliably be forecast from the UT1 offset drift. It looks
like any further progress toward really tight time will have to be made
in another forum. Meanwhile, I suggest we take further correspondence offline
in the interest of good mailmanship.

Regards,
Dave
-------

Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA by Mailnet; 31 Jul 1983 00:14:15 edt
Date: Sat, 30 Jul 83 21:38:58 EDT
From: Gavin_Eadie@UMich-MTS
To: header-people@MIT-MC.ARPA
Message-ID: <216715@UMich-MTS.Mailnet>
Subject: SMTP response codes

Learned Colleagues ... A question:

   The SMTP document contains an indication that new SMTP
   response values should not be invented but, rather, that
   the existing ones be employed as well as possible.

   My mail system allows a user to leave a 'tag' on their
   mailbox which carries a short piece of text which is most
   commonly used to say things like: "I'll be out of town
   till August 5th".

   Local users of the system are shown this when they send
   mail to a 'tagged' mailbox.  The display of the 'tag' is
   the only different action - the 'tag' has no effect on
   the delivery of the message.

   Now, when a message arrives over the net aimed at a box
   with a 'tag' on it, what should I do?  I would like to
   respond to the "RCPT TO:<...>" in some way to indicate
   to any mailer capable of being clever enough that while
   the mail was delivered perfectly, there was a little
   message which the recipient would like the sender to be
   aware of.

   In my innocence I invented a '252' response code with
   the 'tag' text appended.  Some words on page 50 of RFC821
   would indicate that I did a Bad Thing - they say,

      "... should not invent new codes for slightly
       different situations from the ones described ..."

   oh woe!  Well, I could use '250' - but how can I tell that
   the appended text is significant to those that care?  I
   could use '251' - but that looks like it has a semantic
   significance which is quite different from what I want.

   Suggestions?  (Tablets of stone accepted!)

                           Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS

Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.347/3.35)
	id AA08174; Sat, 30 Jul 83 21:54:34 PDT
Received: by UCBARPA.ARPA (3.347/3.37)
	id AA18125; Sat, 30 Jul 83 21:56:19 PDT
From: eric%UCBARPA@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 30 Jul 1983 2156-PDT (Saturday)
Message-Id: <18124.31.428475378@ucbarpa>
To: Gavin_Eadie@UMich-MTS
Cc: header-people@MIT-MC.ARPA
Subject: Re: SMTP response codes
In-Reply-To: Your message of Sat, 30 Jul 83 21:38:58 EDT.
             <216715@UMich-MTS.Mailnet>
Fcc: mail

As 100,000 people will undoubtedly tell you, putting something in the
SMTP transcript will not convey the desired information, since it is
typically not seen by humans unless something went wrong.  The only way
you can really handle this is either to return a failure code (which is
wrong, since the mail was actually delivered) or to compose a new
message back to the sender including the tag (which is correct).

eric allman

Date: Saturday, 30 Jul 1983 23:02-PDT
To: header-people@MIT-MC
Subject: Re: SMTP response codes
In-reply-to: Message from eric%UCBARPA@UCB-VAX (Eric Allman) of
	     30 Jul 1983 2156-PDT (Saturday) <18124.31.428475378@ucbarpa>
From: greep@SU-DSN

While it is true that the user does not normally see the commands and
replies between the mailer and smtp server, there is no reason why a
particular mailer could not show users such a message if they happened to
be logged in when the mail is sent.  It sounds like a good idea to me, and
might be worth adding to the SMTP protocol since there is no way to specify
such a thing now. (Of course mailers would be free to ignore such a
message.)

Your suggestion of having the receiving site send back a message has
the problem of getting into a loop if both sides do this.  A way out
of this might be to use the SEND command instead of MAIL, except that
some hosts (at least last time I checked) treat SENDs as mail anyway.

(Gavin_Eadie: note that UMich-MTS is not in the Arpanet host table.)

Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.347/3.35)
	id AA13648; Sun, 31 Jul 83 11:32:08 PDT
Received: by UCBARPA.ARPA (3.347/3.37)
	id AA21230; Sun, 31 Jul 83 11:33:51 PDT
From: eric%UCBARPA@Berkeley (Eric Allman)
Phone: (415) 548-3211
Date: 31 Jul 1983 1133-PDT (Sunday)
Message-Id: <21229.31.428524428@ucbarpa>
To: greep@SU-DSN
Cc: header-people@MIT-MC
Subject: Re: SMTP response codes
In-Reply-To: Your message of Saturday, 30 Jul 1983 23:02-PDT.
             <8307310614.AA08755@UCBVAX.ARPA>
Fcc: mail

Although I agree that a sender could behave as you suggest, the fact
is that many of them do not at this time -- if he wants to insure
that the sender see the "tag" regardless of the sending system then
something else need be done.  This still doesn't handle the problem
of relayed mail anyhow.

Your point about mail loops is well taken -- I should have mentioned
this problem in my original message.

It is probably not wise to rely on SEND -- RFC821 does not require
that it be implemented at all; a separate reply code is even supplied
(502 Command not implemented) for this purpose.  See section 4.5.1.

eric

Date: 25 Aug 1983 1507-PDT
Sender: ESTEFFERUD at USC-ECL
Subject: Re:        ISI-VAXA's SMTP sender doesn't say HELO
From: ESTEFFERUD at USC-ECL
To: wales at UCLA-LOCUS
Cc: ROGERS at USC-ISIB, Action at USC-ISI
Cc: Bug-MAISER at SU-SCORE, HEDRICK at RUTGERS, MsgGroup at BRL
Cc: header-people at MIT-MC
Message-ID: <[USC-ECL]25-Aug-83 15:07:07.ESTEFFERUD>
In-Reply-To: Your message of           Thu, 25 Aug 83 13:29:48 PDT

Hi Rich - I appreciate your intent in sending your message to
MsgGroup, but I suspect that most of our members are not the right
folks to help you.

I would expect Header-People to be the better forum for oprational
SMPT problems, so I suggest that you shift to that group for future
discussion.

I will redistribute your message to Header-People, in spite of the
large overlap with MsgGroup, with the hope that the discussion will
totally shift to the other list.

I wish you the best in solving the problems!  Stef (MsgGroup
Moderator)

Return-path: <PLILES@USC-ECLB>
Date: 25 Aug 1983 1143-PDT
From: PLILES <PLILES@USC-ECLB>
Subject: Re: dir access vs connect without pw
To: ESTEFFERUD@USC-ECL
cc: action@USC-ECL
In-Reply-To: Your message of 25-Aug-83 1042-PDT
Redistributed-To: header-people at MIT-MC
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 25 Aug 1983

	(John forwarded your message.)

	What you have said about file protections is perfectly right.

							Paul Liles
-------

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Thu 25 Aug 83 14:30:39-PDT
Received: From Ucla-Locus.ARPA by BRL via smtp;  25 Aug 83 16:37 EDT
Date:           Thu, 25 Aug 83 13:29:48 PDT
From:           Rich Wales <wales@ucla-locus>
To:             Craig M. Rogers <ROGERS@usc-isib>
CC:             Action@usc-isi, Bug-MAISER@su-score, HEDRICK@rutgers
CC:             MsgGroup@brl
Subject:        ISI-VAXA's SMTP sender doesn't say HELO
Redistributed-To: header-people at MIT-MC
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 25 Aug 1983

Craig --

Hi.  I am Rich Wales, the UCLA Computer Science Department's mail guru.
I may have mentioned the following to you some time ago, but since the
problem apparently still exists . . . .

There seems to be a bug in the ISI-VAXA SMTP sender program; namely, it
doesn't start each transaction with a HELO command.  The following is a
log of a recent connection between ISI-VAXA and UCLA-LOCUS:

    220 UCLA-LOCUS SMTP Server ready; Thu, 25 Aug 83 10:15:05 PDT
    === mail from:<mueller@ISI-VAXA>
    250 MAIL: OK, even though you forgot to say HELO first
    === rcpt to:<johanna@ucla-locus>
    250 RCPT: OK
    === data
    354 Enter message
    === [13 lines of message text]
    === .
    250 Message accepted
    === quit
    221 UCLA-LOCUS SMTP Server exiting; Thu, 25 Aug 83 10:15:21 PDT

While I admit that RFC821 may not be 100% clear on the issue of whether
the HELO is mandatory (and many SMTP servers, including our own, do not
require the sender to say HELO), there are quite a few SMTP's around
which will reject a MAIL command (with a 503 reply code) unless a HELO
comes first.  Based on tests I ran this morning, here is a partial list
of hosts who appear to insist on being HELO'ed before accepting mail:

    BBNA            BBNG            CMU-CS-C        DEC-MARLBORO
    HI-MULTICS      MIT-MC          MIT-ML          OFFICE-3
    RADC-TOPS20     RUTGERS         SANDIA          SRI-AI
    SU-SCORE        SUMEX-AIM       SRI-KL          SRI-NIC
    USC-ECL         USC-ECLB        USC-ECLC        UTAH-20
    UTEXAS-20       WASHINGTON

Note particularly, by the way, that SRI-NIC is on the above list.

The "fix" to your SMTP sender program to have it send a HELO and gobble
up the "250" reply shouldn't really be too big (if it's more than about
10 lines I would be amazed).

My personal opinion, by the way, is that the other hosts ought to fix
their SMTP's so as not to demand a HELO -- in keeping with the oft-
stated axiom that you should be conservative in what you send out and
liberal in what you accept.  The pragmatic facts of life, however, are
that you can modify your code a lot faster than 22 other people will
modify theirs.

-- Rich Wales <wales@UCLA-LOCUS>

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Thu 25 Aug 83 16:17:26-PDT
Received: From Su-Score.ARPA by BRL via smtp;  25 Aug 83 18:32 EDT
Date: Thu 25 Aug 83 15:27:51-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO
To: wales@UCLA-LOCUS.ARPA
cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, 
    MsgGroup@BRL.ARPA
In-Reply-To: Message from "Rich Wales <wales@UCLA-LOCUS>" of Thu 25 Aug 83 13:36:38-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Redistributed-To: header-people at MIT-MC
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 25 Aug 1983

     Sigh.  Another round in the "lets make our protocols simpler
to accomodate the quick and dirty implementations" battle.

     According to section 3.5 of RFC821, "at the time the
transmission channel is opened there is an exchange" and "the
following...are used in transmission channel opening and
closing...HELO...QUIT".  That implies to me that HELO is not
optional.  I'll conceed that 503 isn't listed as a reply code to
MAIL, but I would consider that a bogosity in the reply codes
list.

     HELO serves a purpose.  That purpose is voided if it isn't
used.  I would rather mandate a change in a single SMTP user
process than force an unknown number of present and future SMTP
server processes to be changed.

     We have a desirable situation now.  Despite the ambiguity in
RFC821, the de facto situation is that HELO is required.  An SMTP
user that doesn't send HELO is going to have a lot of hassle
getting its mail out.  Let's not break a good thing!

     I cannot believe that a straightforward protocol such as
SMTP has gotten corrupted by various short-cut implementations.
Isn't it enough that from time to time we are expected to
tolerate host-less arguments to MAIL and RCPT, or pre-RFC821
syntax for source routing?  In the principle of being "liberal in
what you accept", let's make MAIL optional too.  It should be the
default.  While we're at it, why require RCPT?  We can just
accept DATA and parse the header.

     Another example of the flaw in the "be conservative/be
liberal" argument is in SMTP data flow.  For a shocking number of
hosts, an SMTP transaction will not work in a message of
non-trivial size unless the SMTP user process periodically sets
Push in its segments, completely independently of where Push is
actually required.  A subset of those hosts also fail if you send
segments larger than 50 bytes or so.  The TOPS-20 SMTP user
process used to do all of its TCP transitions in 40 byte Pushed
segments.

     The problem was, that gronked our UK friends at the other
end of SATNET.  Today, it does normal TCP I/O, and reverts into
the Pushed minigram mode if the connection times out (taking more
than 2 minutes to output 1000 bytes) or if the connection dies
unexpectedly.  When it does so it prepends a message (the
infamous "Delivery-Notice" message some of you may have seen)
suggesting that maybe the receiver's TCP ought to be fixed.

     Certain mailers across the Internet have discovered that the
TOPS-20 mailer has the feature of being able to talk to the
broken hosts; Score gets a lot of third-party traffic this way.
Also, every so often an innocent host gets sent to in the
minigram mode (and gets the obnoxious Delivery-Notice).  In a few
weeks it will only do normal TCP I/O, when I cut over to the DEC
TCP/IP interface.  After all, people have had 9 months to get
their TCPs working.

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

Date: 25 Aug 1983 2300-PDT
Sender: ESTEFFERUD at USC-ECL
Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO
From: ESTEFFERUD at USC-ECL
To: MRC at SU-SCORE
Cc: wales at UCLA-LOCUS, ROGERS at USC-ISIB, Action at USC-ISI
Cc: HEDRICK at RUTGERS, header-people at MIT-MC
Message-ID: <[USC-ECL]25-Aug-83 23:00:42.ESTEFFERUD>
In-Reply-To: Your message of Thu 25 Aug 83 15:27:51-PDT

Earlier today I made a dumb error when I redistributed the wrong
message to Header-People in my attempt to shift the discussion from
MsgGroup to Header-People.

I have just redistributed the correct message from Rich Wales, and
also a reply from Mark Crispin, so this discussion can now continue in
Header-People without copying MsgGroup.

Thank you all for your tolerance, and thanks to Mike@brl for pointing
out my error.

Best - Stef (MsgGroup Moderator)

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Fri 26 Aug 83 03:20:00-PDT
Received: From Sri-Nic.ARPA by BRL via smtp;  26 Aug 83 5:57 EDT
Date: Fri 26 Aug 83 02:51:28-PDT
From: Henry W. Miller <Miller@SRI-NIC.ARPA>
Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO
To: MRC@SU-SCORE.ARPA, wales@UCLA-LOCUS.ARPA
cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, 
    MsgGroup@BRL.ARPA, Miller@SRI-NIC.ARPA
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Thu 25 Aug 83 23:18:45-PDT
Redistributed-To: header-people at MIT-MC, miller at SRI-NIC
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 27 Aug 1983

Mark,
	Actually, I think the idea of ttaking RCPT out is a bit extreme...

But seriously, I agree.  The spec is there; it has been "agreed" on.
If they don't want to play ball our way, well, it's our bat and our
ball, and...

-HWM
-------

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Fri 26 Aug 83 08:20:29-PDT
Received: From Hi-Multics.ARPA by BRL via smtp;  26 Aug 83 9:48 EDT
Date:  26 August 1983 08:43 cdt
From:  Stachour.CSCswtec@hi-multics
Subject:  Re: ISI-VAXA's SMTP sender doesn't say HELO
To:  Henry W. Miller <Miller@sri-nic>
cc:  MRC@su-score, wales@ucla-locus, ROGERS@usc-isib, Action@usc-isi, 
     HEDRICK@rutgers, MsgGroup@brl
In-Reply-To:  Message of 26 August 1983 07:28 cdt from Henry W. Miller
Redistributed-To: header-people at MIT-MC
Redistributed-To: Stachour.CSCswtec at HI-MULTICS(Attn: Thanks!)
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 27 Aug 1983

  When I use a mail-system, one of the most common this I do is 'Reply',
 just as I'm doing now.  I expect my mailer to be able to send a response
 to anyone who can send a msg to me (I hope that's not expecting too much).
 IF my mailer does not demand a HELO when recieving via SMTP, then it's
 very easy to get a msg that turns out to be non-replyable automatically,
 and not even a good "RECEIVED" header for me to try and figure it out
 manually.  Yes, I know that a mailer can 'lie' about who it is, and most
 SMTP implementations will accept the 'lie'. However, that at least enables
 me to get a msg back to someone who can disclaim resposibility for the
 orginal send, something not even possible without a HELO.
  In short, I think a mailer NOT sending HELO is not only against the RFC,
 it's not a good way to use a protocol.     ...Paul

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Fri 26 Aug 83 08:39:46-PDT
Received: From Hi-Multics.ARPA by BRL via smtp;  26 Aug 83 10:14 EDT
Date:  26 August 1983 09:13 est
From:  DBrown.TSDC@hi-multics
Subject:  Re:  ISI-VAXA's SMTP sender doesn't say HELO
To:  MsgGroup@brl
Redistributed-To: header-people at MIT-MC
Redistributed-To: DBrown.TSDC at HI-MULTICS(Attn: THANKS!)
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 27 Aug 1983

  I hope the comment about taking your bat and ball was humor...
   Seriously, if a program expects a certain protocol and doesn't need
it, then there's ane error in defining the protocol.  If one *needs* the
protocol but is capable of surviving misuse of it in known special cases
then the best tack is to send lots of messages (in this case mail) to
the person/thing which isn't meeting the spec.
  Or even to this forum....
  --dave

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Fri 26 Aug 83 10:59:37-PDT
Received: From Wisc-Crys.ARPA by BRL via smtp;  26 Aug 83 12:40 EDT
Date: 26 Aug 1983 11:14:56-CDT
From: Marvin Solomon <solomon@uwisc>
Reply-to: solomon@uwisc
To: MsgGroup@brl
Subject:  Re:  ISI-VAXA's SMTP sender doesn't say HELO
Redistributed-To: header-people at MIT-MC
Redistributed-To: solomon at UWISC(Attn: THANKS!)
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 27 Aug 1983

Not requiring the HELO is definitely a violation of spec and should therefore
be strongly discouraged, but what is a server SMTP supposed to do with the
info?  Specifically, what should it do if:
	The name given isn't in the host tables?
	The name is in the host tables, but doesn't correspond to
		the address at the other end of the TCP connection
	A "MAIL FROM:" command is issued during the course of the session
		with a return path that does not indicate the named host
		as the first step?
In general, the various Internet specs are good on indicating what correct
behavior is, but quite weak on telling you what to do in response to
errors.  Obviously, not all possible errors can be anticipated, but 
a few of the more likely ones should be mentioned.

P.S.  Does this discussion belong in MsgGroup or HeaderPeople?  I can never
keep straight the difference.  I have the feeling there is a large overlap
in membership.  In fact the lists may be nearly identical.  If so, perhaps
they should be merged?

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Sat 27 Aug 83 08:36:38-PDT
Received: From Hi-Multics.ARPA by BRL via smtp;  27 Aug 83 11:21 EDT
Date:  27 August 1983 10:17 est
From:  DBrown.TSDC@hi-multics
Subject:  HELO from who?????
To:  MsgGroup@brl
Redistributed-To: header-people at MIT-MC
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 27 Aug 1983

  I would suggest that the smtp server not try to concern itself too
much with validating names/systems, etc.  It is very difficult to get a
server to test your new host-table entry for site bar if you have to
have a correct host-table entry for bar first.
  Besides, I have a system that can (and probably will) talk smtp and
its NOT where i try to have mail sent.  My return address is DBrown.TSDC
@ HI-MULTICS.ARPA but my system is Daves_micro @ tsd1.toronto.honeywell
(an alias for brown at tsd1...).

  Probably the best criteria is to regard smtp as a mail-transfer
mechanism with optional audit trail, and not a mechanism for data-entry
with verification.
  --dave

Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 27 Aug 83 14:08:07 EDT
Date: 27 Aug 83 1412 EDT
From: Rudy.Nedved@CMU-CS-A
To: Header-People@MIT-MC
Subject: HELO, problems & restrictions
Message-Id: <27Aug83.141212.EN0C@CMU-CS-A>

CMU expects mail to be delivered to the correct person or an error
message to be generated within a reasonable amount of time. We always
generate a HELO and are starting to check the responses from HELOs
since we are hitting various problems:

    1) If you send mail to Goonhilly-Echo from a TOPS-20 site the mail
       loops since you effectively are sending mail to yourself. Checking
       for "250 <your name>" handles this problem very effectively.

    2) Sometimes two hosts get their addresses swaps during hardware work
       or when software people are trying to track down bizzarre problems.
       This has not happen at CMU but it did happen a year ago when WHARTON
       and NBS-VMS switched IMP ports. I expect to put that check in a few
       more months.

The protocol seems to indicate that HELO is required and a reliable
mail system should generate and check the response.

A group of people want the "must say HELO first" restriction coded
out and same group of people apparently have not hit certain problems
which will require the HELO being generated. 

Instead of one group coding a restriction out and then another
group coding something neccessary in that satisfies the
restriction later, why doesn't the latter group do the neccessary
coding now?

-Rudy

Date: 28 Aug 83 19:22:58 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: problem in mailing to RU-GREEN
To: EE.GDS%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "Greg Skinner <EE.GDS%MIT-OZ@MIT-MC>" of 27 Aug 83 08:51:00 EDT

The shortest answer to your problem is that your host table is
probably out of date.  RU-GREEN is listed in the NIC host table, and
has been for some time.  We are all awaiting the day when there will
be name servers and these problems will go away.  How about it,
John?

I agree that in general, the HELO command is helpful in resolving
these cases of out of date host tables, as an earlier message from
MRC described.  In this particular case, it wouldn't have helped,
though, because mail from RU-GREEN is relayed by RUTGERS.   So your
HELO would have been from RUTGERS.  If your mailer had been
smart enough to figure out the PATH and reverse it, that would have
solve the problem, but I don't think anybody really does that.
(I won't bother the whole list with a rehash of why analysizing the
path is normally no help, as most of us have been through that
many times.  If you don't know the sorry tale of why paths can't
be used to describe relaying, I'll reply to you directly.)

However I thought you might find it helpful for me to describe
just what is going on with RU-GREEN, since otherwise your
investigations may leave you wondering what we are doing.
In fact RU-GREEN is not on the Arpanet.  It is connected to
RUTGERS by a local network.  When the edict came down that
paths could not be used to describe non-Internet hosts, we
decided that we had to come up with an alternate kludge.  So what
we did is assign RU-GREEN (and its brother, RU-BLUE) an Internet
address.  It is now in the NIC host table.  The addresses are
  RUTGERS:  10.2.0.58
  RU-GREEN: 10.2.1.58
  RU-BLUE:  10.2.2.58
Now the interesting thing about these addresses is that they
differ only in the third octet.  This is the "logical host"
field.  Packets intended for all of these addresses get
delivered to the same place, which is in fact RUTGERS.  RUTGERS
is set up to accept packets for any address of the form
10.2.xxx.58.  Our servers then have to know what is going on.
Our mailer looks at the destination address of your packets
(the IP-level address, not the host name from the mail address).
It initializes itself so it thinks it is that host.  So if
you open a connection to 10.2.1.58 you will get a mailer that
really thinks it is running on RU-GREEN.  All the mail
receiver does is create a file in the mail directory.  This
file contains the place where the mail is to be sent.  Since that
is RU-GREEN, our normal local mail forwarding gets it to the
right place.  The net result is that as far as the sender is
concerned, RU-GREEN might as well be on the Arpanet.  We do
not play such games in the other direction.  Aside from the
fact that we don't have any reason to want to, there would be
administrative problems.  (DCA approves relaying incoming
mail freely, but we have to prevent non-Arpanet hosts from
sending outgoing mail freely.)  So mail from RU-GREEN will
probably have a RETURN-PATH that shows <@RUTGERS:foo@RU-GREEN>.
(There will not be a RECEIVED line for the transfer from
RU-GREEN to RUTGERS, however, as intersystem transfers involve
essentially no processing.  We just move the mail file from
one system to the other by our local equivalent of FTP.)

At the moment, only the mail server knows how to do this kind
of thing.  If you connect to 10.2.1.58 with FTP, you will
get a message like "you have reached a non-working Internet
address at Rutgers University.  Please hang up and dial again."
When the next stage of our networking is completed, we may
install an FTP relay.  We are probably a year away from a
real Internet gateway.  (One of the problems is that DEC does
not support the gateway function in their TCP, and we are
going to let other sites pioneer in that area.)  Again, an
FTP relay would be incoming-only, for administrative reasons.
-------

Return-path: <msggroup-request@BRL>
Received: from BRL by USC-ECL; Mon 29 Aug 83 05:17:38-PDT
Received: From Sri-Nic.ARPA by BRL via smtp;  29 Aug 83 7:26 EDT
Date: Mon 29 Aug 83 02:50:58-PDT
From: Henry W. Miller <Miller@SRI-NIC.ARPA>
Subject: Re:  ISI-VAXA's SMTP sender doesn't say HELO
To: DBrown.TSDC@HI-MULTICS.ARPA, MsgGroup@BRL.ARPA
cc: Miller@SRI-NIC.ARPA
In-Reply-To: Message from "DBrown.TSDC@hi-multics" of Fri 26 Aug 83 09:13:00-PDT
Redistributed-To: header-people at MIT-MC
Redistributed-To: Miller at SRI-NIC(Attn: THANKS!)
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 29 Aug 1983

	Actually, it was intended to be partially humorous, but,
equally as serious.  The protocol is defined, and is accepted by
most rationial beings.

	Sooner or later, we all shall have to conform to the
spec.

-HWM
-------

Date:  30 August 1983 13:11 edt
From:  Greenwald.CSR at MIT-MULTICS
Subject:  Re: problem in mailing to RU-GREEN
To:  Charles Hedrick <HEDRICK at RUTGERS>
cc:  EE.GDS%MIT-OZ at MIT-MC, header-people at MIT-MC, 
     Greenwald at MIT-MULTICS
In-Reply-To:  Message of 28 August 1983 19:28 edt from Charles Hedrick


Re: name servers.

          Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:HEDRICK@RUTGERS.ARPA>
          Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Aug-1983 19:27:47-edt
          Date: 28 Aug 83 19:22:58 EDT
          From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
          Subject: problem in mailing to RU-GREEN
          To: EE.GDS%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC.ARPA
          In-Reply-To: Message from "Greg Skinner <EE.GDS%MIT-OZ@MIT-MC>" of 27 Aug 83 08:51:00 EDT

          The shortest answer to your problem is that your host table is
          probably out of date.  RU-GREEN is listed in the NIC host table, and
          has been for some time.  We are all awaiting the day when there will
          be name servers and these problems will go away.  How about it,
          John?

This seems to come up about once every couple of months. IEN-116 style
name servers exist. They have existed for at least three years. They
still exist. There is software that has been using them for over three
years.

Now IEN-116 name servers might not meet your approval - hell, they don't
meet mine - but they are useable.

Name servers exist on at least the following machines: MIT-XX,
MIT-Multics, MIT-Spooler (18.2.0.128), SRI-NIC, BBNA, HI-Multics,
RADC-Multics, DCN1 (? Maybe not this one, but at least one of Dave
Mills' fuzzballs).

... and more...

          - Mike Greenwald

(For historical reasons some of the Multics name servers might be on
port 14 instead of port 42.  Most of these are UDP based name servers. I
think the one on  the NIC is also TCP based.)

Date: 30 Aug 1983 17:19:28 PDT
From: MILLS@USC-ISID
Subject: Re: problem in mailing to RU-GREEN
To:   Greenwald.CSR@MIT-MULTICS, HEDRICK@RUTGERS
cc:   EE.GDS%MIT-OZ@MIT-MC, header-people@MIT-MC,
cc:   Greenwald@MIT-MULTICS, MILLS@USC-ISID

In response to the message sent   30 August 1983 13:11 edt from Greenwald.CSR@MIT-MULTICS

Mike,

IEN-116 name servers MIT-XX, DCN1, NIC, ISIF, BBNA and BBNG barked when I called
just now, along with PURDUE and a Honeybunch or two, but the latter on the
"wrong" port. DCN1 does the name server do, as well as a mean IEN-142
clock, but is updated by hand only once every fortnight or so. NIC has been
the host of choice and has been very reliable.

Dave
-------

Date: 30 Aug 1983 2037-EDT
From: Greg Skinner <EE.GDS@MIT-OZ>
Subject: Re: problem in mailing to RU-GREEN
To: Greenwald.CSR@MIT-MULTICS
cc: HEDRICK@RUTGERS, header-people@MIT-MC
In-Reply-To: Your message of 30-Aug-83 1311-EDT

ok ... but in my case, the return path was

Return-path: <msggroup-request@BRL>

not

Return-path <@BRL:<person>@rutgers>

or even

Return-path: <@MIT-MC:@BRL:<person>@rutgers>

Now in the case of chaosnet mail transfers, if I send something onto
the arpanet it'll look like

Return-path: <@MIT-MC:EE.GDS@MIT-OZ>

I believe, so there's a chance someone on the arpanet can get
something back to me.  In the above cases, I couldn't get the message
back to RUTGERS even, let alone RU-GREEN.  According to what you're
saying, as long as I can get the reply back to RUTGERS, RUTGERS mail
software can relay it to RU-GREEN.

Seems like BRL is actually remailing the message, not forwarding it,
thereby msggroup-request@BRL is becoming the recipient of the reply
intended for the sender at RUTGERS.

I don't know if this is a bug or not, but it's an interesting problem
especially with distribution-lists, which are the least likely to be
stable in a distributed environment.  Maybe there should be an RFC on
distribution lists?

greg
-------

Date: 30 Aug 83 21:15:10 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: problem in mailing to RU-GREEN
To: EE.GDS%MIT-OZ@MIT-MC.ARPA
cc: Greenwald.CSR@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA
In-Reply-To: Message from "Greg Skinner <EE.GDS%MIT-OZ@MIT-MC>" of 30 Aug 83 20:37:00 EDT

I think it is a matter of taste as to whether the return-path shows
the original author or the mailing list.  The advantage to pretending
that it is a remailing is that error messages (no such user at this
site, ...) go back to the list maintainer instead of the original
sender, who may not be able to do anything about it.  I think that makes
a lot of sense.  However if this is done, there should probably be
something like ORIGINAL-PATH:.
-------

Date:     Tue, 30 Aug 83 21:17:04 EDT
From:     Ron Natalie <ron@brl-vgr>
To:       Greg Skinner <EE.GDS@mit-oz>
cc:       Greenwald.CSR@mit-multics, HEDRICK@rutgers, header-people@mit-mc
Subject:  Re:  problem in mailing to RU-GREEN

Our mailing list processor on the BRL uses something like
MAIL FROM:<@BRL:LIST-REQUEST@BRL> in the SMTP dialog.  The
"MAIL" command is documented in RFC821 as being the route
to send non-delivery notices.  It goes on to say that "in some
types of error reporting messages (for example, undeliverable
mail notifications) the reverse path may be null."

This means that the whole purpose of MAIL FROM is disposition
of error messages relating to non-delivery.  Our list processor
changes this to the LIST-REQUEST address so that the list maintainer
gets the failed mail notices right away (used to be that we had
to wait until someone else called a failure to our attention or
we actually mailed a letter out on the list and had it fail) and
the a submitter to the list not get the typical 3 or 4 mail failures
that happen even on a good day when he submits an item.

-Ron
INFO-MICRO-REQUEST, INFO-CPM-REQUEST, INFO-MUSIC-REQUEST

Date: 30 Aug 1983 2059-EDT
From: Greg Skinner <EE.GDS@MIT-OZ>
Subject: Local-area forwarding
To: hedrick@RUTGERS, greenwald@MIT-MULTICS, header-people@MIT-MC

(That's what I'm going to call it now.)

Just tried it again, replying to a msg from ron@brl-vgr, and again, it
refused brl-vgr as a known host.  OZ is using the 7/28 host tables and
they do, indeed, contain brl-vgr.  (They probably contain RU-GREEN
also, since I believe the same file is on XX.)

Anyway, the curious fact in this case is that the return path was

<Mailer@MIT-OZ>


Comments?  greg
-------

Date:     Tue, 30 Aug 83 22:30:38 EDT
From:     Doug Kingston <dpk@brl-vgr>
To:       Greg Skinner <EE.GDS@mit-oz>
cc:       Greenwald.CSR@mit-multics, HEDRICK@rutgers, header-people@mit-mc
Subject:  Re:  problem in mailing to RU-GREEN

	I can shed some light on the RU-GREEN reply situation as
it relates to the forwarding through BRL.  Msggroup is a large
mailinglist maintained on the BRL host.  In order to efficiently
process the Msggroup mail, the list is processed by our "list-processor"
channel of MMDF.  This channel handles the address-list verification
in the background, but it also changes the return address given to
us via the "MAIL FROM:" SMTP command.  The return address is changed
to contain the Msggroup-Request address in order to route all the
automatic return messages to go to the list maintainer instead of
the list contributers who can do nothing about mailing list problems.
The new return address is only used to change the "MAIL FROM:" command
when we pass the message on to others.  The text of the message and
the header are NOT changed to reflect this new return address.  This
prevents hundreds of annoying messages from being sent to list
contributors and routes most of them to someone in a position to
handle them properly (the -requests mailboxes).

				Cheers,
					-Doug-

Date:  2 September 1983 01:14 edt
From:  Greenwald.CSR at MIT-MULTICS
Subject:  Help!
To:  header-people at MIT-MC

I'm not certain why I am being CC'd on every message to header people
these days (Most of these messages don't seem to be in response to the
neutral little note I sent - which only gently reminded people that name
servers do exist).  My mailbox is being inundated with mail.

I can usually deal with multiple copies of things, but I am about to
take off for a couple of days and multics is fairly strict about quota.
If my mailbox overflows with duplicates, I lose all my legitimate mail.

Please, please, clean me out of your messages before I am swamped.

Sorry to bother everyone about this.
           - Mike Greenwald

Date:  4 September 1983 19:52 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Forwarding or remailing?
To:  Header-People at MIT-MC

  It strikes me that MsgGroup@BRL.ARPA is really remailing messages, to
ensure that the inevitable error messages come to the list maintainer
and not the poor fellow who mailed the message in the first place.
  This raises two questions:
  (1) is that a good thing to do, and
  (2) are we really handling errors properly in smtp.
  At the moment I think accepting a message at the home of a mailing
list (thereby accepting responsability for it) and remailing it with a
different return address is probaly a *good thing*.
  I suspect that the smtp definition really only concerned itself with
what happened when the sender's host failed to transfer the message to
the recipient's host, and not what happends when a host several hops
away (either in another net or after list expansion/remailing) fails.
Not unreasonable, considering that there weren't all that many nets at
the time, but probably undesirable now.
  Any suggestions on what one "should" do in the way of returning an
error letter to the sender? (I'll air my prejudices after a few people
have had a chance to reply).
  --dave
    DBrown.TSDC @ HI-MULTICS.ARPA
    drbrown @ watbun.UUCP
    (decvax!watmath!watbun!drbrown)

Date:     Sun, 4 Sep 83 21:17:13 EDT
From: Farber <farber%udel-eecis1.udeecis@udel-ee>
Return-Path: <farber%Udel-Eecis1@UDel-EE>
Subject:  IEEE Computer Society Mail service
Received: from udel-ee by udel-relay.ARPA ; 4 Sep 83 21:19:45 EDT (Sun)
To: header-people%mit-mc.arpa@udel-ee


The following will appear in the September Computer Magazine of the
IEEE Computer Society.



____________________________________________________________________

COMPMAIL+ Computer communications for today's computer professional
Offered by the IEEE Computer Society.


Using COMPMAIL+ you can:

1. Communicate via electronic mail with your col-
   leagues - one-on-one, or in electronic mail confer-
   ences. Either way, there's no more postal system
   delays, no more "telephone tag."

2. Access Computer Society listings of upcoming con-
   ferences, publications and technical activities.

3. Scan the complete, up-to-the-minute list of Com-
   puter Society Press publications.

4. Speed up your Computer Society publications orders
   and conference registrations by ordering on-line
   and charging to your credit card. On-line
   book orders are shipped in 48 hours; conference
   registrations are processed in 24 hours.

5. Locate your colleagues in the system by accessing 
   a complete on-line directory of all COMPMAIL+
   users.

6. Post your own messages to - and scan - a soci-
   ety-wide electronic bulletin board.

7. Set up your own executive calendar system: sched-
   ule meetings, display your own open time slots, and
   scan colleagues schedules for open time slots.

8. Access state, national, and international newswires.
   Scan the headlines, or do keyword inquiries.

9. Obtain current stock, bond, and commodity quotes.

10. Use the on-line Official Airline Guide to obtain
    current flight schedules and fares.

11. Utilize a wide range of programs in the system
    library (over 200), ranging from finance and statisti-
    cal routines to games.

12. Create your own programs and data files using
    compilers and the database management system
    resident on COMPMAIL+.

And remember: this is just a partial list of the tools and
facilities available through COMPMAIL+ right now. Even
more will be available in the future.

Easy to use

To assure maximum access for all society members,
COMPMAIL+ is available via Telenet, Tymnet, or Uninet.

All you need is a telephone, a modem, and a terminal or
microcomputer capable of communicating via ASCII protocols
over telephone lines. When you log on you'll
see a complete menu of available services, together
with extensive on-line help commands and functions.
There's even a special HELP mailbox in case you run
into a problem, and a SUGGESTION mailbox in case
you think of enchancements that will make the system even
more useful to Computer Society Members.

Low Cost

For most COMPMAIL+ services, the basic rate is an
hourly connect charge that varies by time of day. In addi-
tion, there is a communications charge that varies by
time of day and by the particular network you select
(Telenet, Tymnet or Uninet). The following sample rates
cover basic electronic mail and communications assuming
you access COMPMAIL+ via Telenet:

	Prime Time	(8:00 a.m.* to 6:00 p.m.,	$16/hour
			Monday through Friday)

	Off-Prime	(6:01 p.m. to 9:00 p.m.,	$7/hour
			Monday through Friday;
			and 8:00 a.m. to 9:00 p.m.,
			Saturdays, Sundays, and
			holidays)

	Nighttime	(9:01 p.m. to 7:59 a.m. daily)	$6/hour

	* Times are based on Eastern Time.

If you use the filing capability of the system there is a
small storage charge (40 cents per 2048-byte storage unit
per month). There are surchages for use of some of the
special services such as the OAG and news or stock
quotation systems. Finally, if you use the system for programming
or database applications, there are CPU-time-and-storage charges.
A complete schedule of rates for all services will be sent to
all new subscribers, so you'll know exactly what each service
costs before you use the system.

Best of All ...

* There's no start-up or enrollment charge.

* As a special introductory offer, you'll receive a $30
  credit toward your use of the basic COMPMAIL+ 
  services (items 1 through 7 above).

Date: Mon 5 Sep 83 13:06:58-PDT
From: David Roode <ROODE@SRI-NIC>
Subject: Re: Forwarding or remailing?
To: DBrown.TSDC@HI-MULTICS, Header-People@MIT-MC
In-Reply-To: Message from "DBrown.TSDC at HI-MULTICS" of Sun 4 Sep 83 19:52:00-PDT
Location:  EJ286    Phone: (415) 859-2774

Postel had a proposal some time back to add an "Errors" header to
messages which could direct errors as desired.

Here at the NIC, we habitually send messages to hundreds of people at
a time, and it would be a really useful feature to direct
the errors from each mailing to a special place.

I earnestly urge the establishment of this "errors" header
right away.
-------

Date: Mon, 5 Sep 83 13:40 PDT
From: Taft.PA@PARC-MAXC.ARPA
Subject: Re: Forwarding or remailing?
In-reply-to: "ROODE@SRI-NIC.ARPA's message of Mon, 5 Sep 83 13:06:58
 PDT"
To: Header-People@MIT-MC.ARPA

I think we've beaten this issue to death already.  But let me try to
reiterate.  I also suggest that people re-read carefully the relevant
sections of RFCs 821 (4.1.1: MAIL command) and 822 (4.4: originator
fields).  These protocols already have the needed mechanisms, and there
is no need to invent any more.

Of particular interest is the "sender", identified in the MAIL FROM
field on the envelope (RFC 821) and by the SENDER field in the contents
(RFC 822).  This is the agent responsible for actually causing the
message to be sent (as opposed to the originator of the message), and to
whom transport and delivery failure notifications should be sent.

If a message is redistributed to some list of recipients and it is
deemed desirable for failure notifications to be sent to the maintainer
of the list, that maintainer should be identified as the "sender" when
the message is resubmitted for transport and delivery to the new
recipients.  That is what the "sender" is for; it serves no other
purpose.

The problem with the proposal to add an ERRORS-TO field, aside from its
redundancy, is that it would appear only in the contents (RFC 822
header) and not on the envelope (RFC 821).  It is totally unreasonable
(and a violation of protocol layering) for transport and delivery
mechanisms to have to look at the contents of a message in order to
determine where to send it when a failure occurs.

	Ed Taft


Date: Mon 5 Sep 83 16:06:11-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Forwarding or remailing?
To: Taft.PA@PARC-MAXC.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "Taft.PA@PARC-MAXC.ARPA" of Mon 5 Sep 83 13:53:43-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I am in total and complete agreement with Ed Taft.  Even if
somebody in a moment of foolishness were to define an Errors header
I seriously doubt I would ever implement it in the TOPS-20 mailsystem.
It is bad enough that operational considerations still dictate that
one has to parse the RFC 822 (header) information at the RFC 821
(transport) level, but one can see the gradual obsolescence of that
technique.

     For your enjoyment, the TOPS-20 mailer tries to use whatever
information is available from the transport level.  Failing that,
it parses the header in the order:
	ReSent-From
	Remailed-From	(pre-822 version of ReSent)
	Redistributed-From (ditto)
	Sender
	From
	Reply-To
	Mail-From
A purist may argue that ReSent-Sender should be in the list too as
highest priority.  But, increasingly the header parse code is never
being called for 821 mailing, only on other networks where the tranport
doesn't specify the sender.
-------

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:

	1.  When the BRL mailer alters the RETURN-PATH
	to point to the intermediary, it does not add
	a SENDER: header to the message.

	2.  Crispin points out that he does not consult
	any existing headers when delivering errors for mail
	which has the MAIL FROM:<> command filled in.
	Won't this lead to mismatch between supposedly
	equivalent things?

	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.

	4.  With BRL's current scheme, there is no way for me
	to say "I want to see the error reports."

	5.  With the TOPS-20 mailer's current scheme, there is
	no way to say "I do not wish to see the error reports."

My purpose is not to criticize any mailing system, but rather
to illustrate there are implementation-dependent differences
that ought perhaps to be consistent across implementations.
-------

Date: 5 Sep 83 21:27:28 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: RFC's XXX, YYY, and ZZZ
To: header-people@MIT-MC.ARPA

I trust the moderator will tell me if this is not the right place
to be discussing this topic.  There seem to be at least three
almost indistinguishable mailing lists.

I have read RFC's XXX, YYY, and ZZZ.  In general I am quite impressed
with the amount of work that has gone into them, and the number of
problems they will handle.  I had a few minor editorial comments, which
I have sent directly to Postel.  However I do think there is one 
fairly serious issue.  The formats for requests and responses to
domain servers are essentially binary.  This will be the first time
an Arpanet protocol has been defined that way.  Indeed a number of
us consider that the fact that RFC821/822 define all commands and
headers as text is a significant advantage over the NBS proposal.  I
would like to hear why the designers of RFCZZZ have gone to binary.
I think previous discussions of mail have made the advantages of
text clear:
  - it is easier to handle them in many high level languages
  - it is easier to add new options and arguments, since the command
	structure is free-field rather than fixed.  (NBS has at
	least tried to answer this by allowing for user-defined
	options at every level, but if different vendors have to
	talk to each other, then there will be conflicts among
	their uses of the user-defined codes.  This is far less
	likely when we are dealing with keywords, as the address
	space of English verbs is larger than an octet.)
  - it is easier to debug commands that are given as text, since 
	a human can read them.  You can also put them into log files
	with minimal processing, to allow for later diagnosis.
  - you can pass text through ASCII/EBCDIC converters if necessary.

I can understand that both Arpa and other developers are concerned
about allowing for graphics and digitized voice.  Thus I can
understand that protocols will tend to evolve towards having
certain fields be able to handle arbitrary contents.  I am not
convinced that the domain server is the best place to start this.
(Probably we would like to have digitized voice in the body of
the message before we allow it for host names.  I don't think
our domain servers are likely to be able to parse voice for some
time.)  But even if it were, I think it would be sufficient for
the formats to allow for arbitrary strings of octets, probably with
a short header to indicate what it is.  I don't know how this would
apply to the domain server (as I still think host and user names
should continue to be text), but it wouldn't be hard to dream up
a header that goes at the beginning of a field and says "the following
field is 25 octets of digitized voice":


RFC822:

  from: hedrick@rutgers
  to: postel@isif
  subject: ~D,25:!"#$%678^Ajkl789^CUIOXlkjkjkljlk
  


This assumes that ~D is a special marker indicating a digitized
voice field, in this case 25 octets.

I am sure further thought will elicit less kludegy ways of doing
this, without requiring us to go to NBS or RFCZZZ.
-------

Date: 5 Sep 83 21:41:24 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: PS about digitized voice
To: header-people@MIT-MC.ARPA

I did not mean to imply that I had any very good ideas about digitized
voice.  In fact I do not.  My real view is that I would like to see
it tried our experimentally before we start modifying our productionn
protocols to take it into account.  I was just trying to point out
that it seems just as plausible to believe that we can extend a
protocol like RFC822 to handle voice as one like NBS.  Actually, I
suspect people may find voice and video somewhat less useful than
they expect.  Consumers have rejected the use of voice in home
appliances.  Every review I have seen of hi-tech automobiles has
considered its use in automobiles an annoyance.  It is not clear to
me that I want my terminal talking to me, except in somewhat
specialized circumstances.  Graphics inside messages does seem
useful.  However there we are far more likely to want it in the
middle of a piece of text than to want a whole field of that type
(which is what NBS assumes).
-------

Date: Mon 5 Sep 83 18:19:24-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: senders, originators and relays
To: ROODE@SRI-NIC.ARPA
cc: Header-People@MIT-MC.ARPA
In-Reply-To: Message from "David Roode <ROODE@SRI-NIC>" of Mon 5 Sep 83 17:22:57-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

    From: David Roode <ROODE@SRI-NIC>
    1.  When the BRL mailer alters the RETURN-PATH
    to point to the intermediary, it does not add
    a SENDER: header to the message.
[I don't see anything wrong with that.  BRL is performing the
 service of altering the address where errors go to, by
 deliberate and desirable intent.
There is nothing in the standard that requires that Sender
 equal Return-Path.]

    2.  Crispin points out that he does not consult
    any existing headers when delivering errors for mail
    which has the MAIL FROM:<> command filled in.
    Won't this lead to mismatch between supposedly
    equivalent things?
[The correct behavior would be NEVER to consult existing headers.
 If the Return-Path is null, errors should go into a black hole.
The only reasons the TOPS-20 mailsystem consults headers at all
 are that certain (bogus) SMTP implementations always transmit a
 null return path and that certain non-Internet networks have no
 way of specifying Return-Path in their transmission protocol.
I hope to see an end to those reasons (and of parsing headers at
 the transport level) in the very near future.]

    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.
[I don't see why this is germaine to the topic under discussion
 or to Header-People in general, but I'll answer it anyway.
MM's function of specifying an arbitrary From line is a power
 tool that performs no validity checking.  It was designed in RFC
 733 days when the From line was not required to contain a
 mailbox.  As MM had no way of knowing whether or not the user's
 From was replyable, it generated a Reply-To by default.  In 733
 days this guaranteed a valid message header, unless the user
 also used the power tool to set an arbitrary Reply-To as well.
 822 removed that protection; I'm not sure 822 was an improvement
 in that regard.  But the power tools are still valuable enough
 (especially for experimental electronic mail applications) that
 they remain as they presently are.
However, that isn't relevant to the issue of generating a
 Return-Path, which is always derived from the physical sender of
 the message (not the Sender which can be forged).  If you're
 trying to suggest to me that I implement a functionality to
 generate alternate Return-Path's, sending to Header-People is
 not a good way of doing it.]
    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.
[The Sender should be the physical sender.  It can be forged
 because it is added at message composition level.  That is why
 the mail transport level has its own idea of Sender.  But those
 two ideas are different from Return-Path.  Therefore it is wrong
 to change the Sender.]

    4.  With BRL's current scheme, there is no way for me
    to say "I want to see the error reports."
[You don't have to mail via BRL.  You can get a copy of the
 mailing list and have your system undertake to deliver the
 messages itself.]

    5.  With the TOPS-20 mailer's current scheme, there is
    no way to say "I do not wish to see the error reports."
[Once again, Header-People is not the forum to suggest a new
 functionality in the TOPS-20 mailsystem.]
-------

