17-Mar-82 22:45:06-PST,6778;000000000001
Date: 2 Mar 82 1130-PST
Sender: EStefferud at ECL
Subject: MSGGROUP#1701  SURVEY [ECL]<MSGGROUP>MSGGROUP#.1651-1700
From: MsgGroup at ECL
Reply-To: EStefferud at ECL
To: MsgGroup at ECL
Redistributed-To: msggroup at MC
Redistributed-By: STEF at DARCOM-KA
Redistributed-Date: 18 Mar 1982

The message file [ECL]<MSGGROUP>MSGGROUP#.1651-1700;1 may be FTPed from
[ECL], or you may request that specific items be redistributed to you.
Send any requests to MSGGROUP@ECL or to EStefferud@ECL.  ECL supports
FTP LOGIN ANONYMOUS with PASSWORD ARPA.

The survey below identifies all the traffic included in this file.

Best - Stef



MSGGROUP#1651  SURVEY [ECL]<MSGGROUP>MSGGROUP#.1601-1650
 6875 chars 22 Oct 1981 2300-PDT From: MsgGroup@ecl To: MsgGroup at ECL

MSGGROUP#1652  Mail systems for CDC, IBM
  330 chars 29 Oct 1981 1259-CST From: david at UTEXAS-11 To: msggroup a

MSGGROUP#1653  Re: Mail systems for CDC, IBM
  896 chars 29 Oct 1981 1158-PST From: STEF at DARCOM-KA To: david at UT

MSGGROUP#1654  Re: Mail systems for CDC, IBM
  664 chars 29 Oct 1981 1232-PST From: Richard Furuta <FURUTA at WASHING

MSGGROUP#1655  Mail systems for CDC, IBM
  700 chars 30 October 1981 08:57-EST From: "Marvin A. Sirbu, Jr." <SIRB

MSGGROUP#1656  DECmail
  789 chars 30 Oct 1981 1859-EST From: Larry Campbell <LCAMPBELL at DEC-

MSGGROUP#1657  evaluation of DECmail (long message)
 4017 chars 6 November 1981  00:47-EST  Friday From: SWERNOFSKY at BBND 

MSGGROUP#1658  Re: Mail systems for CDC, IBM
  724 chars  5 Nov 1981 2239-PST From: Rich Miller <INFOMEDIA at USC-ECL

MSGGROUP#1659  New mailing list
  485 chars      8 Nov 81 8:59:24-EST (Sun) From:      Dave Farber <farb

MSGGROUP#1660  MsgGroup mailing list
  426 chars 10 Nov 1981 0405-PST From: KIRSTEIN at USC-ISI To:   MsgGrou

MSGGROUP#1661  Re:   New mailing list
 1446 chars 10 Nov 1981 0923-PST From: WAUGH at OFFICE-3 To: farber.EE a

MSGGROUP#1662  DOW JONES NEWS/RETRIEVAL SERVICE
  452 chars 12 Nov 1981 0922-PST From:  Goree Waugh To: MSGGROUP at MIT-

MSGGROUP#1663  NBS Draft Message Format Standard
  397 chars 24 November 1981 1508-EST (Tuesday) From: David.Lamb at CMU-

MSGGROUP#1664  Re: NBS Draft Message Format Standard
  683 chars 24 Nov 1981 12:46 PST From: White at PARC-MAXC To: David.Lam

MSGGROUP#1665  Re: NBS Draft Message Format Standard
 1785 chars 25 November 1981 1437-EST (Wednesday) From: David.Lamb at CM

MSGGROUP#1666  Re: NBS Draft Message Format Standard
  833 chars 25 Nov 1981 1311-PST From: STEF at DARCOM-KA To: MsgGroup at

MSGGROUP#1667  re: NBS Draft Message Format Standards
  500 chars 27 Nov 1981 1122-PST From: POSTEL at USC-ISIF To:   msggroup

MSGGROUP#1668  RFC 788 Now Available
 1146 chars 29 Nov 1981 1647-PST From: POSTEL at USC-ISIF To:   "Request

MSGGROUP#1669  RFC 801 Now Available
  948 chars 29 Nov 1981 2354-PST From: POSTEL at USC-ISIF To:   "[ISIF]<

MSGGROUP#1670  RFC 802 Now Available
 1415 chars  2 Dec 1981 2003-PST From: NIC at SRI-NIC To:   "Request-For

MSGGROUP#1671  RFCs 803 and 804 Now Available
 1309 chars 10 Dec 1981 1614-PST From: WESTINE at USC-ISIF To: "[ISIF]<W

MSGGROUP#1672  Computerized Encyclopedia on ArpaNet
  661 chars 17 Dec 1981 2241-EST From: Steve King <KING at AFSC-HQ> To: 

MSGGROUP#1673  Message systems for RSTS/E on PDP-11's
  394 chars 23 Dec 1981 1336-EST From: MOOERS at BBNA To: MsgGroup at MI

MSGGROUP#1674  Western Union gets electronic mail vendor "okay".
 1967 chars 30 Dec 1981 1459-PST From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1675  Postal Service is sued to block electronic mail.
 2044 chars 30 Dec 1981 1615-PST From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1676  JNT Mail Protocol spec available
  511 chars  6 Jan 1982 1307-PST From: UKSAT at USC-ISIE To:   msggroup 

MSGGROUP#1677  TCP Digest & Discussion of Mailer Headers
  706 chars      14 Jan 82 18:12:41-EST (Thu) From:      Michael Muuss <

MSGGROUP#1678  DIGITAL'S "CHARLOTTE" SYSTEM
  609 chars 18 Jan 1982 0551-PST From: GOREE WAUGH  (OFFICE-3) To: MSGGR

MSGGROUP#1679  Call for COMPCON papers
 1760 chars 22 Jan 1982 1349-PST From: jim.fcc-net at udel To: msggroup 

MSGGROUP#1680  Archives
  234 chars  8 February 1982 18:00 est From:  Schauble.Multics at MIT-Mu

MSGGROUP#1681  Re:  Archives
  540 chars 8 Feb 1982 2341-PST From: STEF at DARCOM-KA To: Schauble.Mul

MSGGROUP#1682  RFC 806 Now Available
 1446 chars  9 Feb 1982 1500-PST From:   Postel at USC-ISIF To: "Request

MSGGROUP#1683  RFC 805 Now Available
 1196 chars  9 Feb 1982 1600-PST From:  Postel at USC-ISIF To: "Request-

MSGGROUP#1684  RFC 807 Now Available
 1080 chars  9 Feb 1982 1730-PST From:    Postel at USC-ISIF To:  "Reque

MSGGROUP#1685  NBS draft report now out: "Features of a Message
               Transfer Protocol" 
 1054 chars  9 Feb 1982 2307-CST To: MsgGroup at MIT-ML 

MSGGROUP#1686  uucp messages and blank lines
  477 chars  9 Feb 1982 2126-PST From: Richard Furuta <Furuta at WASHING

MSGGROUP#1687  Recent NBS "RFC" on mail protocols
  521 chars      10 Feb 82 0:47:47-EST (Wed) From:      Dpk at BRL To:  

MSGGROUP#1688  Re:  uucp messages and blank lines
  502 chars      10 Feb 82 0:50:29-EST (Wed) From:      Dpk at BRL To:  

MSGGROUP#1689  Re: Recent NBS "RFC" on mail protocols
  712 chars  9 Feb 1982 2230-PST From: Zellich at OFFICE-3 (Rich Zellich

MSGGROUP#1690  Mailing-List Verification
 1333 chars 10 Feb 1982 0007-CST To: EStefferud at USC-ECL

MSGGROUP#1691  NBS Messaging Documents
 1299 chars 10 February 1982 16:02-EDT From: ALA@MIT-AI To: MsgGroup@MIT

MSGGROUP#1692  Nominee for most amazing message ever seen
 8665 chars 15 Feb 1982 16:19:12-PST From: mo at LBL-UNIX (Mike O'Dell [

MSGGROUP#1693  Re: Nominee for most amazing message ever seen
  742 chars 15 Feb 1982 2338-PST From: Richard Furuta <Furuta at WASHING

MSGGROUP#1694  Re: Nominee for most amazing message ever seen
  704 chars 15 Feb 1982 2353-PST From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1695  Re: Nominee for most amazing message ever seen
  781 chars 16 Feb 1982 0015-PST From: STEF at DARCOM-KA To: Furuta at W

MSGGROUP#1696  Amazing messages, part 2
 1828 chars 16 February 1982 0346-EST (Tuesday) From: Philip L. Lehman <

MSGGROUP#1697  your chain mail
  656 chars  16 February 1982 16:50 est From:  Charles Hornig at MIT-Mul

MSGGROUP#1698  Obnoxious chain mail
 1405 chars 17 February 1982 00:22-EST From: Ed Schwalenberg <ED at MIT-

MSGGROUP#1699  RFC 808 Now Available
 1317 chars  27 Feb 1982 1853-PST From:  Postel at ISIF To:  "Request-fo

MSGGROUP#1700  RFC809 now available
 1027 chars 2 Mar 1982 1026-PST From: WESTINE at USC-ISIF To: "[ISIF]<We

17-Mar-82 22:45:06-PST,1827;000000000001
Mail-from: ARPANET host BRL rcvd at 3-Mar-82 0616-PST
Date:  2 Mar 1982 1124-PST
From: Feinler at SRI-NIC
Subject: MSGGROUP#1702  NETWORK NEWS #11
To:   Netnews-Dist:
cc:   nic
Via:  Sri-Nic; 2 Mar 82 15:02-EDT

=====================================================================
ANEWS-11                                                 DCA Code 252
2 Mar 1982                                           (DCACODE252@ISI)
                                                       (202) 692-6175

                  DoD NETWORK NEWSLETTER

=====================================================================

             TOPIC:  - Misuse of the ARPANET

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

Dear Liaison,

We have received many complaints from users about a chain letter that 
has circulated around the ARPANET since mid February.  Such use of the 
Net is contrary to DoD policy, and those who participate in such or who 
permit it's continued occurrence via facilities under their control do 
so at risk.  Early efforts to stop the circulation of this chain letter 
have been ineffective, and more drastic measures are being considered, 
up to and including the possibility of removing entire facilities from 
the net if appropriate.

Please assist us by informing your users that they must not forward such
messages under any circumstances, and that they risk loss of Net 
privileges by so doing.  Some users already have lost their access to 
the Net because of this matter.

We greatly prefer to see matters of this nature corrected at the 
liaison/host level, but will not hesitate to act if results are not 
forthcoming.

Major Glynn Parker
ARPANET Management Branch
Defense Communications Agency

-------

----- End of forwarded messages

17-Mar-82 22:45:06-PST,1666;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 7-Mar-82 1803-PST
Date:  7 Mar 1982 1739-PST
From: Daul at OFFICE  
Subject: MSGGROUP#1703  Mail Item With Non-Standard "From" Field
To:   MsgGroup at MIT-ML
cc:   daul, barns, kelley, andrews

I just received the following item.  The "From" field is not part of
the current standards(?)  Will it be?  If not, someone should send a
note to this site and tell them some of us cannot answer mail from them.
========================================================================
Mail from BRL rcvd at 7-Mar-82 1501-PST
Date: 7 Mar 1982 17:24:04-EST
From: hail.mit-vax.BRL-BMD
To: human-nets mit-mc at BRL-BMD, works mit-mc at BRL-BMD
Subject: Electronic Newsroom Info Request
Via:  Mit-Mc; 7 Mar 82 17:25-EDT
Via:  Brl-Bmd; 7 Mar 82 17:31-EDT

The Tech, MIT's largest student newspaper, is planning to install an
electronic newsroom/typesetting system this summer.  If we choose to
roll our own, we hope to use a UNIX-like system running on a large
micro, e.g. the 68000.  The system would have to support visual
editing, including typesetting scanning, plus formatting and spooling.
As we are not sure whether we can junk our old typesetters yet, we are
also interested in device independence.  We would appreciate any
information on electronic newsrooms, text editors and formatters,
(device independent) typesetting, local networking, microcomputer
UNIX's, large micros, and anything/everything related.  Please mail any
information, suggestions, or whatnot to TEN@mit-vax (or
 ...!eagle!mit-vax!TEN).  If you want to talk, call Rich $alz at The
Tech, (617) 253-1541. Thanks.



-------

17-Mar-82 22:45:06-PST,630;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 7-Mar-82 1842-PST
Date: 7 Mar 82 21:10:09-EST (Sun)
From: Dpk at BRL
To: Daul at Office-2
cc: MsgGroup at Mit-Ml, daul at Office-2, barns at Office-2, 
    kelley at Office-2, andrews at Office-2
Subject: MSGGROUP#1704  Re:  Mail Item With Non-Standard "From" Field

	This header was the result of a problem with the mailer
at the BRL site from which that article was distributed.  The proble
(problem) has been fixed.  If any further problems are noted that
could have been caused by BRL or BRL-BMD, please report them to
DPK at BRL and carbon copy Gurus@BRL.

					Doug


17-Mar-82 22:45:07-PST,646;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 7-Mar-82 1920-PST
Date: 7 Mar 82 21:58:38-EST (Sun)
From: Michael Muuss <mike@BRL>
To: Daul at Office-2
cc: MsgGroup at Mit-Ml, daul at Office-2, barns at Office-2, 
    kelley at Office-2, andrews at Office-2
Subject: MSGGROUP#1705  Re:  Mail Item With Non-Standard "From" Field

The problem with the MAIL from BRL (the WorkS list, in this case) was
due to a defective version of MMDF being installed.  The problem has
been corrected, and I'll be very upset if it recurs!

For details, please contact DPK@BRL, our "postmaster".

For bug reporting, send to Action@BRL.

	Best,
	 -Mike


17-Mar-82 22:45:07-PST,574;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 7-Mar-82 1900-PST
Date: 7 March 1982  18:32-PST
From: Jonathan Alan Solomon <JSOL at ECLC>
To:   Daul at OFFICE
Cc:   andrews at OFFICE, barns at OFFICE, kelley at OFFICE,
      MsgGroup at MIT-ML
Subject: MSGGROUP#1706  Mail Item With Non-Standard "From" Field

Hi,

The problem arose because of some new MMDF implementation being run at
BRL. I believe the software people at BRL have fixed it. I plan an
administrivia announcement for WorkS which should help explain it for
all who are interested.

Cheers,
--JSol

17-Mar-82 22:45:07-PST,1629;000000000001 
Date:  8-Mar-82 10:43:02 PST
From: Farrell at PARC-MAXC
Subject: MSGGROUP#1707  legal ramifications of electronic mail
To: EStefferud @ USC-ECL
Reply-To: Farrell.pa
cc: BURROUGHS at DEC-MARLBORO, Farrell.pa
Redistributed-To: msggroup at MC
Redistributed-By: STEF at DARCOM-KA
Redistributed-Date: 18 Mar 1982

Two points: could you add me to the group?  and could you suggest an
appropriate disposition for the following message -- is the topic
covered somewhere in your archives (where?), or is it a reasonable thing
to broadcast to the MsgGroup?

Thanks,
Jerry Farrell

-------

Subject: legal ramifications of electronic mail
To: Info-Law @ UCL-ECB
Reply-To: Farrell.pa
cc: BURROUGHS at DEC-MARLBORO, Farrell.pa

I am trying to work up a discussion of problems & remedies in electronic
mail systems, and realize I'm out of my depth with a lot of the legal
ramifications.  For instance, is there any solid decision on whether
including somebody's copyrighted material in a message constitutes an
infringement?  or whether it is possible to libel someone in a message?
can the purveyor of a message system be held liable for a forgery
perpetrated through the system?  What remedies are available to an
organization whose system is being clogged with unwanted message
traffic?

I would appreciate answers to any of those specific questions, but even
more I would appreciate a pointer to persons / groups / publications
which could serve as reasonable authorities in similar questions, or
could provide a tutorial on the general area.

I am already aware of the MsgGroup distribution list.
29-Mar-82 15:57:16-PST,3461;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 23-Mar-82 0609-PST
Date: 18 Mar 1982 0730-PST
Sender: WMARTIN at OFFICE-3
Subject: MSGGROUP#1708  Legal message issues
From: WMartin at Office-3 (Will Martin)
To: msggroup at ECL
Message-ID: <[OFFICE-3]18-Mar-82 07:30:31.WMARTIN>
Fcc: <WMARTIN>MESSAGE.TXT
Redistributed-To: msggroup at MIT-ML
Redistributed-By: WMARTIN at OFFICE-3
Redistributed-Date: 23 Mar 1982

It is appropriate that this topic is being brought up now, as I
have recently reviewed a document from our headquarters (DARCOM)
discussing guidelines for official messages -- that is,
electronic mail which is used INSTEAD of the traditional
"official" methodologies for sending traffic regarding the
conduct of official business -- TWX and USMail.

I recall discussions of this sort of issue back in 1976 when we
first began using electronic mail on the net.  All along, the
avowed purpose of net mail has been as a replacement for
"informal communications"; usually telephone calls.  When a final
decision was made, and funds were allocated or tasking was given,
it may have been worked out over the net via electronic mail, but
it officially came through via a following letter or TWX.  (TWXes
are electronic, but travel over a different network, come through
official communication centers, and have built-in verification
mechanisms.)

We are only now just beginning to transfer some of the "official"
traffic to net electronic mail, and it still does not include
certain exceptions, most notably things requiring an official
signature.  As we move into totally electonic office
environments, of course, this becomes necessary.  Areas worthy of
discussion and suitable for Msggroup include such topics as:

Authentication/verification -- a message obligating funds or
assigning resources must be traceable/auditable back to the
stated originator without too high a chance of it having been
forged or altered en route.  How high a chance can we tolerate?
(After all, USMail letters can be forged right now by someone
stealing or misusing letterheads or printing their own, so I
don't think it is reasonable to state that such forgery MUST be
"impossible" in an electronic environment.  Conversely, though,
it shouldn't be easy, either.  Where is the proper point of
balance?)

Filing -- auditors and organizations all now are oriented toward
backup and historical information via paper copies in a file
drawer under some degree of security protection.  Eventually,
will this same backup authority and reliability be found in
magnetic media?  If not, must we still file paper copies of
important electronic documents?  Would some other media (COM,
non-eraseable storage of some yet-uncommon kind, whatever) be
used instead?

Signature authority -- though this relates to the verification
issue, there are some differences.  How can we prove that a
message verifiably from the "JONES at HOSTA" mailbox is truly
from "Mr.  Sam Jones, Chief of Widget Counting"?  We get into
some of the "public key encryption" sorts of issues here,
probably.  Currently, password protection is the only procedure
restricting anyone else's access into that "JONES" directory.
Can it be sufficient or is some other level necessary?

These issues are different in detail from the ones brought up by
Jerry Farrell, but I think they should be covered in the same
discussion.

Will Martin
USArmy DARCOM ALMSA
29-Mar-82 15:57:16-PST,818;000000000001 
Date: 19 Mar 1982 1659-PST
From: MCFARLAND at USC-ISI
Subject: MSGGROUP#1709  legal ramifications of electronic mail
To:   Farrell.pa at PARC-MAXC, EStefferud at USC-ECL
cc:   BURROUGHS at DEC-MARLBORO, MCFARLAND
Reference:  Re: MSGGROUP#1707
Redistributed-To: msggroup at MIT-ML
Redistributed-By: STEF at DARCOM-KA
Redistributed-Date: 29 Mar 1982

In response to the message sent 8-Mar-82 10:43:02 PST (Monday) from Farrell.pa

I understand that California has some law which states that
the use of someone's electronic mail account, wherein the actual
sender is not the owner of the account or is not the name which
appears in the mailer addresses may constitute forgery. I don't
recall exactly where I heard this or from whom, so I cannot vouch
for its authenticity or accuracy.

Ray
-------

29-Mar-82 15:57:16-PST,1472;000000000001  
Date: 23 March 1982  08:51-PST
From: WANCHO at DARCOM-KA
To: WMartin@OFFICE-3
Cc: WANCHO, MsgGroup@ECL
Subject: MSGGROUP#1710  Signature Verification
Redistributed-To: msggroup at MIT-ML
Redistributed-By: STEF at DARCOM-KA
Redistributed-Date: 29 Mar 1982

Will,

Unfortunately, your comment about password access to a directory in
order to be able to send a msg under that "From:" line is not valid
for TENEX and TOPS-20 systems at the present time.  Mailers on those
systems do not validate the contents of the header in the
[--UNSENT-MAIL--] file.  Thus, one can create any form of header in
such a file and masquerade as anyone from that host using any
available editor.

The ITS systems come a bit closer, using a "CLAIMED FROM:" line as it
enters COMSAT processing.  However, their password system only
protects from outside assault and one can machine hop within the ITS
structure to login as another without asking for a password...and only
on MC can you not send mail without logging in.

Only on the Unix machines (the ones running UDEL's MSG and MMDF as at
BRL) is it not possible that I am aware to do such masquerading,
mainly because the msg program directly invokes the mailer to pass on
the msg.  Again, I wouldn't be surprised if some knowledgeable person
would be able to circumvent that mechanism too.

Overall, it does not appear promising to rely on the From: line of a
msg for authenication at this time...

--Frank
3-May-82 15:49:54-PDT,799;000000000001   
Mail-from: ARPANET site SU-SCORE rcvd at 29-Mar-82 1627-PST
Date: 29 Mar 1982 1627-PST
From: Mark Crispin
Subject: MSGGROUP#1711  re: #1710 Signature verification
Sender: ADMIN.MRC at SU-SCORE
To: MsgGroup at USC-ECL
cc: WMartin at OFFICE-3, Wancho at DARCOM-KA
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

Mail delivered by the SCORE mailer tells the truth in the MAIL-FROM:
line, irregardless of what the FROM: line says.  Of course, for network
mail it cannot do much better than give the originating host; and if the
user unprotects his mail file so that other users can append to it
(circumventing the mailer) there isn't much that can be done about that.
-------
3-May-82 15:49:55-PDT,624;000000000001 
Mail-from: ARPANET site UCLA-SECURITY rcvd at 29-Mar-82 1712-PST
Date: 29 March 1982 1711-PST (Monday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: MSGGROUP#1712  authentication
To: Wancho at ka
CC: Msggroup at ecl

I might add that with the current mail delivery mechanisms, any user may
simply connect directly to socket 3 at some site, and type a whole
message in, complete with totally fake (or NO) header, and have it
delivered directly.  Some sites will prepend a "Network mail from:" line
on the delivered message to tell which SITE generated the message, but
that's about it.

--Lauren--
3-May-82 15:49:55-PDT,1833;000000000001 
Mail-from: ARPANET site OFFICE-3 rcvd at 29-Mar-82 1733-PST
Date: 29 Mar 1982 1734-PST
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: MSGGROUP#1713  Re: Signature Verification
To:   MsgGroup at USC-ECL

Clearly, if we are going to use the message systems for traffic critical
enough to require some form of signature validation, then we need to
insist on two things:

  The User Agent/Message System Agent interface (probably the MAILER.SAV
  program in the Tenex environment) MUST check the "author" of the
  Unsent-Mail file (not what directory it's in, because some directories
  have open write access);

      [I'm not sure this can even be done with all systems - the
       operating system may not record who actually created (or
       last appended to!) any particular file...a lack that would
       have to be remedied in the operating system to give us a
       reliable author-verification capability.]

   and, all receiving MSA's MUST add the information as to what host
   computer a message is received from (which I think most, if not all,
   of the ARPANET hosts do already).

The first check will verify that someone was at least logged in to the
sending directory (or at least that the sender's real directory name is
added to the message), and the second will verify that someone isn't
sending forged mail directly from a low-level FTP connection (or will
it...if strikes me as I write his that I can login to directory XXX,
invoke a low-level FTP connection if I have the right user software
available on my host, and send any text stream I want which will be
duly verified as being from my host, and with whatever Sender name I
want...?  Do we have to completely take low-level protocol access away
from the general user to insure against forgeries?).

-Rich
-------
3-May-82 15:49:55-PDT,955;000000000001
Mail-from: ARPANET site MIT-ML rcvd at 30-Mar-82 0716-PST
Date: 30 March 1982 03:58-EST
From: Steve Kudlak <FFM at MIT-MC>
Subject: MSGGROUP#1714  Re:  #1709 legal ramifications of electronic mail
To: MCFARLAND at USC-ISI
cc: EStefferud at USC-ECL, Farrell.pa at PARC-MAXC,
    MCFARLAND at DARCOM-KA, BURROUGHS at DEC-MARLBORO
Redistributed-To: msggroup at MIT-ML
Redistributed-By: ESTEFFERUD at USC-ECL
Redistributed-Date: 30 Mar 1982

It seems to be to be a moot point since there isn't
anything currently in existance that can make an
electronic signature that  "holds water." I would be
rather bothered if it were considered that one's password
constituted an electronic signature as there are a number
of subtle surreptitious ways of getting around passwords
and I would be mildly bothered to say the least if just
knowing a "secret password" was all that was needed for
a valid electronic signature.

Have fun,
Sends Steve

3-May-82 15:49:55-PDT,1065;000000000001    
Mail-from: ARPANET site UDEL-RELAY rcvd at 30-Mar-82 0412-PST
Date: 30 Mar 82 6:58:25-EST (Tue)
From: Dave Crocker <dcrocker.EE@UDel-Relay>
To:   Wancho at Darcom-Ka
cc:   WMartin at Office-3, Msggroup at Usc-Ecl
Subject: MSGGROUP#1715  Unix MMDF author certification
Via:  UDel-EE; 30 Mar 82 7:00-EST
Via:  UDel; 30 Mar 82 7:10-EDT

The MMDF system that was mentioned is a transport system.  It is
called by a number of user agents, such as an 'msg' emulator.
MMDF takes responsibility for authenticating the From/Sender
fields, according to the rules of RFC733.  (It matches the
mailbox and host strings against the caller's login id and
the known local host name.)

A caller may ask to bypass this mechanism.  If the caller is
trusted, such as the Arpanet FTP server, then the text is
passed, as is.  This permits Arpanet people to spoof signatures.

Otherwise, a field is affixed to the message, indicating that
From/Sender has not been authenticated.  This is primarily
to permit anonymous mail, while NOT permitting spoofing.

Dave

3-May-82 15:49:55-PDT,1601;000000000001   
Mail-from: ARPANET site MIT-MULTICS rcvd at 3-Apr-82 2135-PST
Date:  4 April 1982 00:36 est
From: Frankston.SoftArts at MIT-MULTICS
Subject: MSGGROUP#1716  Re: Legal message issues
Sender:  COMSAT.SoftArts at MIT-MULTICS
Reply-To:  Frankston at MIT-MULTICS (Bob Frankston)
To:  WMartin at OFFICE-3, msggroup at USC-ECL

A fundamental problem with authentication is how much one
trusts the sender's host.  To the extent that a host can be
trusted, it may be possible to have authentication by having a
common encryption key between the receiving host (presumable
trusted) and the sending host.

This problem can be simplified by an authentication service
that is trusted by both parties.  It would also act like a
credit rating service by monitoring the authenticability of its
clients.

The problem is that there are few hosts that can be trusted.

We are, however, heading into a different model in which the
hosts are personal computers which are no more trusted than a
signature stamp in an office -- something which can be trusted
in appropriate cases.  The requirement is that the network that
these machines are connected to be trusted.  Of course,
implicit in this is the use of multiple networks, the least
trustworthy of these determines the trustworthiness of the path.

One last comment, signatures are not all that reliable as a
means of authentication anyway.

Summary: Electronic authentication is necessary whether or not
it is practical.  We might be able to have a verification
process operate to the extent we trust the (electronic)
participants.
3-May-82 15:49:55-PDT,919;000000000001 
Mail-from: ARPANET site BRL-BMD rcvd at 5-Apr-82 0739-PST
Date:  5 Apr 82 10:34:55-EST (Mon)
From: Michael Muuss <mike@BRL-BMD>
To:   WANCHO at Darcom-Ka
cc:   WMartin at Office-3, WANCHO at Darcom-Ka, MsgGroup at Usc-Ecl
Subject: MSGGROUP#1717  Re: #1710 Signature Verification

Any user of a TIP can call up any Host's FTP server on Socket #3,
and type any random text (including a full header) to be mailed
to anybody.  If you have a co-operating host to work from,
it can be made even easier.

Of course, some FTP servers (like those that come with the MMDF package)
do append a "Via:" line to the supplied header, so the really sharp
user might spot something awry, and there would be a little bit
of traceability, but....

At some level it will always be possible to "spoof" mail headers;
I can envision a significantly more secure arrangement, but for now
things are wide open.
					-Mike

3-May-82 15:49:55-PDT,518;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1337-PDT
Date:  3-May-82 13:02:06 PDT (Monday)
From: Hamilton.ES at PARC-MAXC
Subject: MSGGROUP#1718  UNIX date formats
To: MSGGroup@ML
cc: Hamilton.ES

I apologize for the large distribution, but I'm not sure who to
direct this to.  Is anyone working on Berkeley & Bell to get UNIX
date formats to obey RFC733 or whatever other standards are appropriate?
I'm tired of getting all these msgs with ???? instead of a date
in my table of contents.

--Bruce

3-May-82 15:49:55-PDT,896;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1406-PDT
Date:  3 May 1982 1303-PDT
From: POSTEL at USC-ISIF
Subject: MSGGROUP#1719  re: multiple at signs
To:   neves at MIT-MC
cc:   msggroup at MIT-ML


Dave Neves:

Multiple at signs are not allowed in ARPANET mail.  This form was at one
time proposed and is included in RFC733.  However, it was decided some
years ago that it should not be used (see RFC 808).  A new proposal has
been adopted for structured host addresses (see RFC 805).  In fact a
whole new mail system is forthcoming with revised edition of the mail
transmission procedures and the mail header format about to be issued.
The draft of the transmission procedure is available in the file
<INTERNET-NOTEBOOK>SMTP.DRAFT on ISIF.  (you can copy public access
files from ISIF via FTP using the ftp user name ANONYMOUS and password
GUEST).

--jon.
-------

3-May-82 15:49:55-PDT,2029;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1257-PDT
Date:  3 May 1982 15:16:46 EDT Mon
From: neves@mit-vax@mit-mc
To: msggroup@mit-ml
Cc: neves@mit-vax@mit-mc
Subject: MSGGROUP#1720  Multiple atsigns & other networks

I have a couple of questions for this group.  I am not on this
mailing list so forgive me if I have brought up problems that
have come up before and please CC me on any replies.

Problem -- Multiple atsigns in From fields.

Several sites that I know about use multiple atsigns to route mail
through an Arpanet site to another network (like Ether or Chaos net).
Unfortunately several mailers I've encoutered (like some Vax, Tenex,
etc.) do not seem to understand this format.

Question 1.  Is this format an Arpanet standard?
Question 2.  Is this standard written somewhere?  
Question 3.  Is it online on the net somewhere?
Question 4.  Is there a standard for other net things such as finger
servers?  (i.e. some sites don't accept the /W switch)


Problem -- Getting in touch with people

A related problem is getting in touch with people on some network.
Arpanet people are easy with the arpanet directory and the NIC
database.  However now things are getting more difficult with
networks connected to the Arpanet, such as CSNET, UUCP, and local
Ethernets.  It seems as though the only way to contact someone is to
have mail by him and use the reply command in the mail program.  It
is just too difficult to figure out the routing information
otherwise.

Question.  Is there some better way to address mail to people other
than to include all the routing information in the To field?  Not
now, of course, but in theory?  One possibility is to send mail to the
crossover (between network) points and each network would know how to
route that mail to the appropriate site in its own internal network.
(i.e. each network at its cross over point would have the equivalent of
a NIC database)

-- Dave Neves neves@mit-mc or neves@mit-vax@mc (if you can hack it)

3-May-82 15:49:56-PDT,663;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1451-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 3-May-82 1404-PDT
Date:  3 May 1982 14:05-PDT Monday
To: Hamilton.ES at PARC-MAXC
Cc: MSGGroup at MIT-ML
Subject: MSGGROUP#1721  Re: UNIX date formats
In-reply-to: Your message of  3-May-82 13:02:06 PDT (Monday).
From: Steve Hartwell <hartwell@Shasta at Sumex-Aim>

I doubt if anyone on the unix side is interested in truly changing the
ctime(3) format to conform to one of the gazillion acceptable
RFC733 date formats.  However the mailers should be more reasonable.
On both sides.

Let's not forget, there are more unix sites than arpanet sites.

3-May-82 15:49:56-PDT,1013;000000000000 
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1523-PDT
Date:  3 May 1982 1412-PDT
Sender: CERF at USC-ISI
Subject: MSGGROUP#1722  Re: Multiple atsigns & other networks
From: CERF at USC-ISI
To: neves at MIT-MC
Cc: msggroup at MIT-ML
Message-ID: <[USC-ISI] 3-May-82 14:12:54.CERF>
In-Reply-To: Your message of Mon May  3 15:16:46 EDT 1982

The use of source routing in the message headers which
are processed by the mail reading/composition routines
causes considerable trouble in general.  The SMTP strategy
is to use mail domain indicators to handle addresses
which are not understood (i.e for which routes are not
known by source or intermediate mail forwarders). 

These domain indicators qualify mailbox identifiers which
are outside the domain of the source of the mail.

Jon Postel (postel@isif) can provide more documentation
on this subject - and I just noticed he sent a message
about it which I haven't read because I am processing my
mail first in first out - sigh.

Vint

3-May-82 18:09:43-PDT,1560;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1559-PDT
Date:  3 May 1982 1431-PDT
Sender: CERF at USC-ISI
Subject: MSGGROUP#1723  re: multiple at signs
From: CERF at USC-ISI
To: POSTEL at USC-ISIF
Cc: neves at MIT-MC, msggroup at MIT-ML, adams at USC-ISI
Message-ID: <[USC-ISI] 3-May-82 14:31:03.CERF>
In-Reply-To: Your message of  3 May 1982 1303-PDT


For the Record, Jon Postel's note accurately states the 
DARPA position on multiple "@" signs in message headers.

They are not acceptable, nor is the kind of source routing
practiced through the use of such "@" signs.

Vint Cerf
DARPA/IPTO

Forewarded Mail ...
Mail-From: ARPANET host MIT-ML rcvd at 3-May-82 1357-PDT
Date:  3 May 1982 1303-PDT
From: POSTEL at USC-ISIF
To:   neves at MIT-MC
Cc:   msggroup at MIT-ML
Subject: re: multiple at signs


Dave Neves:

Multiple at signs are not allowed in ARPANET mail.  This form was at one
time proposed and is included in RFC733.  However, it was decided some
years ago that it should not be used (see RFC 808).  A new proposal has been
adopted for structured host addresses (see RFC 805).  In fact a whole new
mail system is forthcoming with revised edition of the mail transmission
procedures and the mail header format about to be issued.  The draft of the
transmission procedure is available in the file <INTERNET-NOTEBOOK>SMTP.DRAFT
on ISIF.  (you can copy public access files from ISIF via FTP using the
ftp user name ANONYMOUS and password GUEST).

--jon.
-------


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

3-May-82 18:09:44-PDT,1560;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1643-PDT
Date:  3 May 1982  15:06-PDT Monday
From: Jonathan Alan Solomon <JSOL at ECLC>
To:   Steve Hartwell <hartwell at Shasta at Sumex-Aim>
Cc:   Hamilton.ES at PARC-MAXC, MSGGroup at MIT-ML
Subject: MSGGROUP#1724  UNIX date formats


Well, I think the problem is at Berkeley, and at places which use
Berkeley software. I notice that your mail heading seems to conform
with what my mail system expects ("hartwell at shasta" at SUMEX-AIM is
in itself valid, while Hartwell@shasta@sumex-aim is not), but I cannot
seem to find a standard from Berkeley regarding this.  My first
complaint is that I sometimes do not know who the message is to, e.g.
if someone from UUCP sends me a message, I don't know if it was sent
directly to me, or to me and others as well. Certainly I cannot reply
to the whole group this way. While the "To" field is not specifically
required by RFC733, it has become an accepted practice on the ARPANET
that messages should show in SOME FASHION, who they are for. This way
those who intend to reply to the message know who is interested in
their reply.

I consider the UUCP Berkeley gateway "Anti-social" for not providing a
"To" line, or some similar function; however I agree that it is not 
"illegal" in the context of RFC733. Personally, I don't really care
whether they follow a standard or not, as long as I can manually mail
my reply to all persons involved. The current way leaves me blind,
not knowing who received the message besides me.

--JSol

3-May-82 18:09:44-PDT,500;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1712-PDT
Date:  3 May 1982 15:14-PDT Monday
From: Dave-Yost at RAND-UNIX
To: Steve Hartwell <hartwell@Shasta at SUMEX-AIM>
Cc: Hamilton.ES at PARC-MAXC, MSGGroup at MIT-ML
Subject: MSGGROUP#1725  Re: UNIX date formats
In-reply-to: Your message of Monday,  3 May 1982 14:05-PDT.
Sender: day at RAND-UNIX

We have a subroutine in the Rand Message Handler that
does a ctime and then munges it into RFC733 format.
It's really easy.

--dave

3-May-82 18:09:44-PDT,1926;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1748-PDT
Date:  3 May 1982 1547-PDT
From: Mark Crispin
Subject: MSGGROUP#1726  Re: Multiple atsigns & other networks
Sender: ADMIN.MRC at SU-SCORE
To: neves at MIT-VAX
cc: msggroup at MIT-ML
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 3-May-82 1233-PDT

     The TOPS-20/Tenex mailer XMAILR uses the multiple-at format.
This format was specified in RFC 733 and later removed.  New
mailer implementations should not use this format.  My strategy
for XMAILR is to leave in multiple-at's for FTP-based mail, and
to not use it for SMTP.  This seems to be the path of least
resistance; I am unwilling to put any more work into FTP mail
since FTP mail will cease to exist in less than 7 months.  Domain
addressing (as described in a recent RFC) is much more the right
thing than multiple atsigns.

     The FINGER protocol was invented by agreement between the
ITS systems at MIT and the WAITS system at SU-AI.  WAITS ignores
/W, but it is part of the specification.  Any site which does not
implement /W at least to the point of ignoring it is violating
the protocol.

     Domain addressing is supposed to make the "getting in touch
with people" problem easier, but I am unconvinced that it will
solve it.  I'm afraid that for some time to come it will continue
to be the case that the person's electronic mailbox will have to
be communicated to you in some fashion before you can mail to
her.

     Your routing question is again something that is superceded
by domain addressing, which involves the consultation of name
servers.  The intent of all of this is to benefit people whose
electronic mailboxes move from computer to computer while still
being at the same "site".

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

3-May-82 22:05:39-PDT,893;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1826-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 3-May-82 1623-PDT
Date:  3 May 1982 16:25-PDT
To: CERF at USC-ISI
Cc: POSTEL at USC-ISIF, neves at MIT-MC, msggroup at MIT-ML,
    adams at USC-ISI
Subject: MSGGROUP#1727  Re:  re: multiple at signs
In-reply-to: Your message of 3 May 1982 1431-PDT.
             <[USC-ISI] 3-May-82 14:31:03.CERF>
From: Brian Reid <reid@Shasta at Sumex-Aim>

Those of us whose computers are not connected to the ARPANET will
therefore patriotically refrain from sending network mail until such
time as the Internet stuff works.

[Note: the vast majority of net users (everybody except TENEX sites,
 it seems) do seem to be able to process multiple at signs properly,
 though it often requires the use of quotes. 
 Almost everybody can send mail to "Reid@Shasta" at SUMEX-AIM.]

Brian Reid

3-May-82 22:05:39-PDT,482;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1858-PDT
Date:  3 May 1982 17:08-PDT
To: Hamilton.ES at PARC-MAXC
Cc: MSGGroup at MIT-ML, Hamilton.ES at PARC-MAXC
Subject: MSGGROUP#1728  Re: UNIX date formats
In-reply-to: Your message of  3-May-82 13:02:06 PDT (Monday).
From: greep at SU-DSN

You should be more specific about what system you're getting the
offending messages from.  There is more than one mail system running
under Unix (just as with other systems).

3-May-82 22:05:39-PDT,1653;000000000001 
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 1926-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 3-May-82 1756-PDT
Date:  3 May 1982 17:58-PDT
To: Jonathan, Alan, Solomon, <JSOL at ECLC>
Cc: Hamilton.ES at PARC-MAXC, MSGGroup at MIT-ML
Subject: MSGGROUP#1729  Re: UNIX date formats
In-reply-to: Your message of Monday, 3 May 1982  15:06-PDT.
From: Steve Hartwell <hartwell@Shasta at Sumex-Aim>

Well, hmm, we should let Berkeley off the hook on this one; as a
gateway, it does the `right thing', namely, it does not mess with the
mail contents as the mail passes through (except that sometimes "from"
bylines get consolidated, which is inexcusable).  Mail from unixes
running the Berkeley flavor do generate To: headers (some
implementations only generate the To: if the message was sent to more
than one recipient -- silly but true).  So the essential problem with
the lack of headers originates in the source machine, and most unix
systems use a very primitive form of mailer (for the sake of a name,
/bin/mail) which provides a single from line with no colon, and a
ctime(3) date format.  This is unfortunate but that is the mailer
distributed with the system.

I suspect that the reason that the To: field is optional in rfc733 is
that the sender may not wish the recipients to know who else is getting
the mail.  Ok.

It is not antisocial to not conform to rfc733 if your environment is
outside of the domain that rfc733 addresses.  Most of the unix systems
on the uucp side of Berkeley are just that.  Our mail system on Shasta
lives in both domains, and our mailer adapts from one form to the other
as required.

3-May-82 22:05:39-PDT,1399;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 2120-PDT
Date:  3 May 1982 2058-PDT
Sender: GEOFF at SRI-CSL
Subject: MSGGROUP#1730  Re:  re: multiple at signs
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
Cc: CERF at USC-ISI, POSTEL at USC-ISIF, neves at MIT-MC, 
Cc: msggroup at MIT-ML, adams at USC-ISI
Message-ID: <[SRI-CSL] 3-May-82 20:58:42.GEOFF>
In-Reply-To: Brian Reid's message of Monday,  3 May 1982 16:25-PDT

Both SNDMSG and HERMES (on TENEX at least) will not accept the
construct of

        "Reid@Shasta"@SUMEX-AIM

As far as I'm aware, unless your at MIT on an ITS system or on a
TOPS-20 system which runs software promulgated by MIT or Stanford
(most notably BABYL, MM & XMAILR) your out of luck in being able
to `answer' or otherwise `correspond' with people who live on
hosts which have adopted the (illegal) multi-at-signed
convention.

I receive about one message a month from people on said sites
which I am not able to answer or otherwise get a message to.

I think this situation is down right cretinous and i ask for the
Powers-That-Be to effect corrective action at the earliest
possible moment.

Come on folks, there are other (approved) ways of having mail
routed thru hosts directly connected to the ARPANET.  Places like
RAND, UDEL, BRL, SRI, BBN, UCB and others have done it in the
past or are doing it now.


10-May-82 01:30:01-PDT,1710;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 2226-PDT
Date:  3 May 1982 2155-PDT
Sender: JGOLDBERGER at USC-ISIB
Subject: MSGGROUP#1731  Re:  re: multiple at signs
From: Joel Goldberger
Reply-To: JGOLDBERGER at USC-ISIB
To: Geoff at SRI-CSL
Cc: CERF at USC-ISI, POSTEL at USC-ISIF, neves at MIT-MC, 
Cc: msggroup at MIT-ML, adams at USC-ISI
Message-ID: <[USC-ISIB] 3-May-82 21:55:36.JGOLDBERGER>
In-Reply-To: <[SRI-CSL] 3-May-82 20:58:42.GEOFF>

As of release 4.2.2 of HERMES for both TENEX & TOPS-20 one is able to
specify addresses by "quoting" all but the last @.  The only
constraint is that the host that appears to the right of the last @ be
recognizable by HERMES.  This recognition is done via the GTHST
JSYS if it exists on the machine one is using or by searching the file
<SYSTEM>HSTNAM.TXT ;  This is a nearly direct quote of a msg I
received from Charlotte Mooers on this very topic.  SNDMSG has
apparently never been educated to the point of understanding that ^V
means "Don't look at the next character".  It does still seem to be
the case that even HERMES won't do the quoting for you, so one can't
simply "REPLY" to one of these msgs, but Geoff is wrong that one
cannot communicate with people who have addresses of that form.

I applaud Geoff's appeal, but didn't want his misrepresentation of the
current situation to go uncorrected.

- Joel Goldberger -


P.S. Charlotte concluded her msg to me with this statement:

We do not yet have a directive from ARPA about which changes to
make to handle multiple networks.  We do expect to get one when
the issues are decided, but at the moment, there doesn't seem to
be a clear consensus.

---Charlotte

10-May-82 01:30:01-PDT,1073;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 3-May-82 2336-PDT
Date:  3 May 1982 2313-PDT
Sender: GEOFF at SRI-CSL
Subject: MSGGROUP#1732  Re:  re: multiple at signs
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: JGOLDBERGER at USC-ISIB
Cc: CERF at USC-ISI, POSTEL at USC-ISIF, neves at MIT-MC, 
Cc: msggroup at MIT-ML, adams at USC-ISI
Message-ID: <[SRI-CSL] 3-May-82 23:13:54.GEOFF>
In-Reply-To: <[USC-ISIB] 3-May-82 21:55:36.JGOLDBERGER>

I run 4.2.2 of HERMES, installed 3-jan-82, here on SRI-CSL, and I
cannot (at least on this TENEX), say:

        "Reid@Shasta"@SUMEX-AIM

to my HERMES.  When I do, I get:

        Not a host: shasta"@sumex-aim

printed back to me with

        To: "Reid@

as the next line.

Perhaps things are different on the TOPS-20 version, but at least
with HERMES 4.2.2 here on the SRI-CSl TENEX, it will not work.

Puzzled & still not able to reply-to or send messages to people
on multi-at-signed hosts & still hoping the Powers-That-Be will
rescue us all from this untenable situation.

10-May-82 01:30:02-PDT,1386;000000000001  
Mail-from: ARPANET host MIT-MC rcvd at 4-May-82 0000-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 3-May-82 2336-PDT
Date:  3 May 1982 23:38-PDT
To: Msggroup at MIT-MC
Cc: Cerf at USC-ISI
Subject: MSGGROUP#1733  mail routing
Reply-to: BKR at SU-AI
From: Brian Reid <reid@Shasta at Sumex-Aim>

Unless it can be guaranteed that the symbol tables ("name servers", if
you will) for an internetwork host are always simultaneously up to
date, then there will always exist transient situations in which mail
cannot be routed to a particular recipient except by manually
specifying the path. A consequence of forbidding manual routing in mail
pathnames is that knowledge of network topology must propagate faster
and more reliably, or users must be willing to tolerate more "you can't
get there from here" errors.

The ability to specify manual routings in mail has provided an escape
mechanism that allows me and hundreds of others to send and receive
ARPANET mail: it provided the building block out of which we were able
to kluge together a clumsy but workable mail exchange, thereby getting
us onto the ARPANET about three years sooner than we otherwise would
have.

I therefore don't think it is a crime for certain mailers to have
implemented it, but it is definitely a crime if people don't understand
the technical ramifications of doing it. 

Brian Reid

10-May-82 01:30:02-PDT,1333;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 4-May-82 0015-PDT
Date:  3 May 1982 2354-PDT
From: Mark Crispin
Subject: MSGGROUP#1734  Re:  re: multiple at signs
Sender: ADMIN.MRC at SU-SCORE
To: JGOLDBERGER at USC-ISIB
cc: Geoff at SRI-CSL, CERF at USC-ISI, POSTEL at USC-ISIF, neves at MIT-MC,
    msggroup at MIT-ML, adams at USC-ISI
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 3-May-82 2155-PDT

     Folks, the important thing is that this will all be fixed
with SMTP domain addressing.  Any attempts to fix FTP-based
mailsystems will just prolong the day when we all talk SMTP.  The
important thing is: the decision to not use multiple-at
addressing was not made known to the general community until very
recently (RFC 805 or some number around then).  It is recognized
that multiple-at addressing is wrong, but I see no reason
whatsoever to fix it in FTP-based mailsystems since FTP-based
mailsystems will cease to exist in less than 7 months!

     So can we please stop flaming about this?  The TCP/IP
conversion is too important to endanger it on flaming about whose
(soon to be converted software) is violating what obsolete
protocols.

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

10-May-82 01:30:02-PDT,966;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 4-May-82 1415-PDT
Date:  4 May 1982 1547-EDT
Sender: MOOERS at BBNA
Subject: MSGGROUP#1735  Re: Multiple atsigns & other networks
From: MOOERS at BBNA
To: neves at mit-vax@MIT-MC, JGoldberger at USC-ISIB
Cc: msggroup at MIT-ML, Mooers at BBNA, Geoff at SRI-CSL, 
Cc: Cerf at ISI, Postel at ISIF, Adams at ISI, 
Cc: "Reid at Shasta"@SUMEX-AIM, Dodds at BBNA, Bthomas at BBNG
Message-ID: <[BBNA] 4-May-82 15:47:46.MOOERS>
In-Reply-To: Your message of Mon May  3 15:16:46 EDT 1982

Hermes 4.3.3, which is up as NEWHERMES on BBN and selected other
hosts, can construct replies which result in the formats shown in
the To and Cc fields of this message.  This version also handles
Name.host1.host2.host3 at ARPAHOST.  We fixed things up for the
multiple at's just to tide people over until the new "." format
comes into its own.  This version will be up as regular Hermes
everywhere fairly soon.

---Charlotte

10-May-82 01:30:02-PDT,841;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 4-May-82 2236-PDT
Date:  4 May 82 16:39:31-EDT (Tue)
From:     Michael Muuss <mike@BRL>
To:       Lauren Weinstein <lauren@Ucla-Security>
cc:       BALDWIN at Mit-Xx, Dcrocker at Udel-Relay, Msggroup at Mit-Ml, 
          Gurus at BRL
Subject: MSGGROUP#1736  "User Not Authenticated"

The "User Not Authenticated" message IS comming from MMDF, but
it is OPTIONAL.  Our UUCP <-> MMDF transitions do not generate
any such messages.  UUCP can do as good a job as SERVER FTP
in identifying the source of a message (ie it gets a hint, but
no assurances), so plastering this stupid herald on UUCP
mail seemed pointless.

				-Mike

PS:  Our UUCP gateway conforms to DCA regulations, and will not
permit UUCP traffic onto the ArpaNet.  However, our host sits
on both networks.  (CYA).


10-May-82 01:30:02-PDT,413;000000000001 
Mail-from: ARPANET host MIT-ML rcvd at 4-May-82 1446-PDT
Date:  4 May 1982 1342-PDT
From: POSTEL at USC-ISIF
Subject: MSGGROUP#1737  re: mail routing
To:   msggroup at MIT-ML


Brian Reid:

The new mail procedure (SMTP) does provide for explicit routing information
in the mail commands as a fall back position (such as when the symbol tables
or name servers are not up to date).

--jon.
-------

10-May-82 01:30:02-PDT,906;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 4-May-82 2334-PDT
Date:  4 May 1982 2304-PDT
Sender: GEOFF at SRI-CSL
Subject: MSGGROUP#1738  Re:  "User Not Authenticated"
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: mike at BRL
Cc: lauren at UCLA-SECURITY, BALDWIN at MIT-XX, 
Cc: Dcrocker at UDEL-RELAY, Msggroup at MIT-ML, Gurus at BRL
Message-ID: <[SRI-CSL] 4-May-82 23:04:18.GEOFF>
In-Reply-To: Your message of     4 May 82 16:39:31-EDT (Tue)

What DCA regulation??

I've never heard or seen via any of the usual means (RFC, IEN,
ANEWS letters as sent by the NIC, direct-message, forwarded
message or otherwise) any DCA published regulation about `DCA
gateway conformity regulations'.

So far all i have heard is pure hear say.  Is there something
I've missed, that I should have seen?

Will the `DCA gateway conformity regulation' please make itself
known?

10-May-82 01:30:02-PDT,2956;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 0542-PDT
Date:  5 May 1982 0512-PDT
From: Craig Milo Rogers  <ROGERS at USC-ISIB>
Subject: MSGGROUP#1739  Re:  "User Not Authenticated"
To: Geoff at SRI-CSL, mike at BRL
cc: lauren at UCLA-SECURITY, BALDWIN at MIT-XX, Dcrocker at UDEL-RELAY,
    Msggroup at MIT-ML, Gurus at BRL
In-Reply-To: Your message of 4-May-82 2304-PDT

	There's always this paragraph from the beginning of the ARPANET
Directory:

                         ------------------
ARPANET DIRECTORY					ARPANET INFORMATION
NIC 48000 Nov. 1980
[p. 17]

[Responsibilities of an ARPANET Liaison are: ...]

MONITORING GATEWAY ACCESS - If it is possible to gain access to the
ARPANET from another network (gateway) or from a tributary terminal of a
host via the IMP-host connection, it is the responsibility of that host to
provide software protection which will permit only authorized ARPANET users
to access the network.  These interfaces must be documented by letter to
DCA for approval.  The letter should provide a brief description of the
interface, who uses it, and the software and/or hardware protection
mechanism.  DCA reserves the right to disapprove such gateways.  The liaison
should inform administrators of local or 'foreign' networks, who might wish to
establish gateway connections to the ARPANET, of this procedure, and disallow
any gateway access until it has been approved.
			 -------------------

	Restrictions of this sort pose interesting design questions for
mail forwarding programs.  If one cannot "authenticate" the originator of
a message (from a public network such as UUCP), can "authorization" be
assumed from the contents of other fields of the message (ie, if the
message is directed to an authorized ARPANET user).  In the other direction,
is it valid to forward a message out of the ARPANET into an uncontrolled
distribution environment (thus providing unauthorized individuals "access"
to ARPANET mail)?  The worst case is when the ARPANET is used as a "free"
message switch between "foreign" network users, none of whom is authorized
to use the ARPANET.

	Thus, it is clear that mail forwarders must be able to classify
message traffic (military, ARPANET-authorized, CSNET member, etc.) in order
to be able to route messages properly.  It may be necessary to classify
several times (once at the message source, and once as the message enters
each protection domain), which raises consistency concerns (to avoid routing
loops, for example).  Finally, any databases used by the mail forwarders
which are subject to periodic (automatic) update, may themselves have
restricted distribution.

	All in all, interesting questions.  However, 1 Jan 1983 is rapidly
approaching, and we really ought to be sure that the roof doesn't leak
before we install the wall-to-wall carpet.  Hope I haven't bored anyone
with the obvious.

					Craig Milo Rogers
-------
10-May-82 01:30:02-PDT,1596;000000000001  
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 0853-PDT
Date:  5 May 1982 0821-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1740  Re:  "User Not Authenticated"
From: STEF at DARCOM-KA
To: Geoff at SRI-CSL
Cc: mike at BRL, lauren at UCLA-SECURITY, BALDWIN at MIT-XX, 
Cc: Dcrocker at UDEL-RELAY, Msggroup at MIT-ML, Gurus at BRL
Message-ID: <[DARCOM-KA] 5-May-82 08:21:57.STEF>
In-Reply-To: <[SRI-CSL] 4-May-82 23:04:18.GEOFF>

Hi Geoff - I think the answer to your challenge is the same now as it
was privately, only more so here in public.

I don't recommend forcing this issue into public explication unless you
are prepared to unequivically accept all possble outcomes, including
premature decisions and misunderstanding of the situation.

I thnk the rules have been stated in various places and various ways,
and that we can properly infer what is acceptable and what is not
without going to the top for a specific reading, and a written ruling
from on high.

It is my impression from careful reading of all the signals I can get
(which is either more or less than you have access to) that this is a
purely dumb time to try to force the issue with any of the
administrators who are involved with trying to untangle the problems we
face with the AUTODIN-II decision, et al.

So, I believe that Mike has inferred the correct understanding of the
rules for his site, which is also governed by a need to apply his
resources to the work of Ballistics Research Labs, and no other work
that does not contribute to BRL work in some rational way.

Best - Stef

10-May-82 01:30:02-PDT,1039;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1003-PDT
Date:  5 May 1982 1232-EDT
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: MSGGROUP#1741  Re:  "User Not Authenticated"
To: ROGERS at USC-ISIB, Geoff at SRI-CSL, mike at BRL
cc: lauren at UCLA-SECURITY, BALDWIN at MIT-XX, Dcrocker at UDEL-RELAY,
    Msggroup at MIT-ML, Gurus at BRL, JNC at MIT-XX
In-Reply-To: Your message of 5-May-82 0812-EDT

	It seems to me that the introduction of IP/TCP is making this
almost impossible. Exactly what am I, as the maintainer and liaison
of the MIT packet gateway, supposed to do? Look into every packet as
it goes through to see some sign that it's from an 'authorized' user?
Should MIT use some protocol other than IN internally so that only
'authorized' hosts can use the packet gateway? Are only authorized
hosts allowed to have an IN address? Seems to me 1 Jan 83 is when we
remove all doors, windows and walls and expect the rain to stay out.
I guess this is getting a bit off the topic for MSGGROUP, though.
-------

10-May-82 01:30:03-PDT,636;000000000001   
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1051-PDT
Date:  5 May 1982 1010-PDT
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: MSGGROUP#1742  Re:  "User Not Authenticated"
To: JNC at MIT-XX, ROGERS at USC-ISIB, Geoff at SRI-CSL, mike at BRL
cc: lauren at UCLA-SECURITY, BALDWIN at MIT-XX, Dcrocker at UDEL-RELAY,
    Msggroup at MIT-ML, Gurus at BRL, CSL.LANTZ at SU-SCORE
In-Reply-To: Your message of 5-May-82 0932-PDT

Seems like one possible solution would be source routing?  But how would
your gateways, etc. like to handle those packets?  And indeed, this is off
the topic for MSGGROUP.

Keith
-------

10-May-82 01:30:03-PDT,680;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1152-PDT
Date:  5 May 1982 1152-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1743  Re: [neves@mit-vax: you should fix this guy's mailbox]
From: STEF at DARCOM-KA
To: SWG at MIT-XX
Cc: msggroup-request at MIT-ML
Message-ID: <[DARCOM-KA] 5-May-82 11:52:04.STEF>
In-Reply-To: Your message of  5 May 1982 1418-EDT

Hi - I just did it with th latest list version cbf;msgrou 71.

I hope that we did not interfere with each other in the process.

I just completed my FTP of the file to MC and ML about 3 minutes
before the date/time on this msg.  I will do it again to be sure
mine is the last word.

Cheers - Stef

10-May-82 01:30:03-PDT,1309;000000000001    
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1613-PDT
Date:  5 May 1982 15:39-PDT
From: Dave-Yost at RAND-UNIX
To: Steve Hartwell <hartwell@Shasta at SUMEX-AIM>
Cc: Hamilton.ES at PARC-MAXC, MSGGroup at MIT-ML
Subject: MSGGROUP#1744  Re: UNIX date formats
In-reply-to: Your message of Monday,  3 May 1982 14:05-PDT.
Sender: day at RAND-UNIX

jon postel suggested that I mail the subroutine that
converts unix ctime format to RFC733 format since it
is so simple.  Here it is, along with a main() to exercise it.

#include <stdio.h>
#include <sys/types.h>
#include <time.h>
#include <sys/timeb.h>

main()
{
	time_t now;
	now = time((time_t *)0);
	putdate(now, stdout);
	exit(0);
}

putdate(now, out)
	time_t now;
	register FILE *out;
{
	register char *ct;
	struct timeb tb;
	struct tm *tmp;
	static char *wday[] = {
                "Sun", "Mon", "Tues", "Wednes", "Thurs", "Fri", "Satur" };
	extern struct tm *localtime();
	extern char *timezone();

	ct = ctime(&now);
	ftime(&tb);
	tmp = localtime(&now);

	/*                  XXday, 5    May  1982 15  :06  :30  -PDT */
	fprintf(out, "Date: %sday, %.2s %.3s %.4s %.2s:%.2s:%.2s-%.3s\n",
		wday[tmp->tm_wday],
		&ct[8], &ct[4], &ct[20], &ct[11], &ct[14], &ct[17],
		timezone(tb.timezone, tmp->tm_isdst));
}

10-May-82 01:30:03-PDT,2549;000000000001    
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 1657-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 5-May-82 1625-PDT
Date:  5 May 1982 16:26-PDT
To: MsgGroup at MIT-MC, mmdf at UDel-Relay
Subject: MSGGROUP#1745  automatic nondelivery notification
Reply-to: BKR at SU-AI
From: Brian Reid <reid@Shasta at Sumex-Aim>

More and more mail delivery systems are getting smart enough to issue
return notes like the following one. The Tops-20 mailer won't deliver
mail if the recipient is over his disk quota; telephone dialing mailers
sometimes cannot get through for days. On the last note I sent to
MsgGroup I got several messages like this, including 3 copies of this
message spaced about 5 minutes apart.

For mail like this (a random note to MsgGroup) I frankly don't care
whether or not Cornell has seen it within 2 days, or whether somebody
at Caltech is over his disk quota, but I get duly notified of all of
this from having sent the message. All mail is assumed to be
first-class, and there is no provision for a note like "Postmaster: if
this mail is undeliverable within 5 days, please use it to line your
cat box".

Does anybody have any ideas how to make this kind of a notification service
serve its valuable purpose on "first-class" mail while just plain not
bothering on mail to large distribution lists?

------- Forwarded Message

Mail-from: SU-NET host SUMEX-AIM rcvd at 5-May-82 1416-PDT
Mail-from: ARPANET host UDEL-RELAY rcvd at 5-May-82 1410-PDT
Date:  5 May 82 16:29:33-EDT (Wed)
From:     MEMO SERVICE (MMDF) <mmdf@UDel-Relay@Shasta at Sumex-Aim>
Subject:  Waiting mail
To:       Brian Reid <reid.Shasta@Sumex-Aim>

    After 2 days, your message has not yet been fully delivered.
Mail is not returned until it is in the queue for at least 11 days.

    Delivery attempts are still pending for the following address(es):

	MsgGroup at Cornell

    This usually is due to service interruptions at the receiving
machine.  Less often, there are problems with the communications system.

    Your message begins as follows:

Mail-from: SU-NET host SU-SHASTA rcvd at 3-May-82 2336-PDT
Date:  3 May 1982 23:38-PDT
To: Msggroup at MIT-MC
Cc: Cerf at USC-ISI
Subject: mail routing
Reply-to: BKR at SU-AI
From: Brian Reid <reid@Shasta at Sumex-Aim@Shasta at Sumex-Aim>
Via:  Mit-Mc; 4 May 82 3:09-EDT

Unless it can be guaranteed that the symbol tables ("name servers", if
you will) for an internetwork host are always simultaneously up to
 ...

------- End of Forwarded Message
10-May-82 01:30:03-PDT,617;000000000000  
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1709-PDT
Date:  5 May 1982 1634-PDT
From: Andrew Knutsen <knutsen@SRI-UNIX>
To: Dave-Yost at RAND-UNIX
Cc: Steve Hartwell <hartwell@Shasta@SUMEX-AIM>, Hamilton.ES at PARC-MAXC,
     MSGGroup at MIT-ML
Subject: MSGGROUP#1746  Re: UNIX date formats
In-reply-to: Your message of Wednesday,  5 May 1982 15:39-PDT.
Sender: knutsen at SRI-UNIX

	There are also a few date/time parsers around which
can be used to standardize multiple formats. We have a locally
written one (KLH@KL) which even parses the timezone. Unfortunately,
ctime doesnt produce one...


10-May-82 01:30:03-PDT,819;000000000001
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 1732-PDT
Date:  5 May 1982 1642-PDT
From: Mark Crispin
Subject: MSGGROUP#1747  automatic nondelivery notifications
Sender: ADMIN.MRC at SU-SCORE
To: MsgGroup at MIT-MC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     What we clearly need is a "return receipt requested" or a "no
return receipt desired" option.  One of the functions of my mailsystem
profile is to delete many of these unwanted return receipts unread from
my mail file.  MM allows your profile to be pretty clever about setting
up what kinds of return receipt messages look to be receipts from third
class junk mail and what are ones which look to be interesting.
-------

10-May-82 01:30:04-PDT,1777;000000000001 
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 1813-PDT
Date:  5 May 82 20:09:11-EDT (Wed)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       BKR at Su-Ai
cc:       MsgGroup at Mit-Mc
Subject: MSGGROUP#1748  Re:  automatic nondelivery notification

Being responsible for the system providing you with your example,
I'll make one suggestion which is on my list to implement, and
tell you of another that already is there:

When MMDF gets a large mailing list (many recipients for the same
message -- a grouping that is not possible when receiving mail
from the FTP/NCP Arpanet unless the list is derived from a single
received name) MMDF will disable the two-day warning message and 
will authorize only "short" notices on delivery failure.

"Large" is defined as greater than a constant.  I believe I
currently have it set at about 12 recipients.  No rationale
for the choice.

"Short notices" is defined as citing only the message header
and first few lines of the body, rather than the entire
message.

This distinction based on list size came about after MANY
Unix-Wizards (out of Sri-Unix, running an incarnation of MMDF)
recipients issued heinously vehement criticisms along the
of the same system behavior that you have noted.  The current
behavior is certainly not completely adequate, but at least
tones things down and was trivial to implement.

For the long term, I intend to permit per-address
"switches", so that special behavior can be specified for each
address.  In your current example, the list-heuristic cannot
work because we get only one address.  When the new scheme
is implemented, the address can contain some information
indicating that it should be treated like a list address.

Sound adequate?

Dave


10-May-82 01:30:04-PDT,3254;000000000000    
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 1921-PDT
Date:  5 May 1982 1856-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1749  Re:  automatic nondelivery notification
From: STEF at DARCOM-KA
To: dcrocker at UDEL-RELAY
Cc: BKR at SU-AI, MsgGroup at MIT-MC
Message-ID: <[DARCOM-KA] 5-May-82 18:56:36.STEF>
In-Reply-To: Your message of     5 May 82 20:09:11-EDT (Wed)

More to the point, regarding direct distribution lists such as MsgGroup,
there is a need to be able to direct such notices to the one single
person who cares, namely me, the one who can and should do something
about it with a little list maintenance.

In this last round of required updates which suddenly became visible
with the '82 Spring Blooming of MsgGroup, I have received several
notices from several contributors of items when they got back the
notices.  I appreciate getting them all, even though there is some
redundancy.  Unless they are routed to me, I may not see them, and then
they will lay in wait for yet others in the future.  I think I have
pretty well cleaned out the nest of baddies in this episode, but I
expect it all to happen again next time there is a prolonged hiatus in
MsgGroup activity.

Astute observers will note that the lists which pass though a moderator
do not have this trouble, since the moderated, digestified, and re-
originated mail always attracts all the failure notices.  But, I do not
believe that moderation and digestification is any solution for the
current problem topic.

For the future of MsgGroup, I plan to develop some tools in the MMDF
context which will take possesion of each message and reoriginate it
with the MSGGRUP#nnnn string inserted in the beginning of the subject
field for each.  This will provide several benefits, one of which is
automatic return of failure notices to the MsgGroup sender.  BUT!  Care
must be exercised here to prevent such returns from getting into the
main MsgGroup flow as though they are regular item contributions, or we
will have a very nice mess on our hands.  So, how do we teach Mail
Transfer Services all around the net to send failure notices to
MsgGroup-Request@MIT-ML when it is FROM:  MSGGROUP@MIT-ML?

This problem is not entirely simple to solve.  I am interested in any
ideas that might apply.  Dave Farber tells me the MMDF will soon have a
solution for this problem, but I do not know what it is, and I am not
sure it will do what is needed.  Dave Crocker did not mention it in his
item either, so my confidence is not growing.

So, bottom line:  Yes, the problem is very real, and our mail system
needs a way of dealing with the responsbility question regarding who
should get those failure notices and how we should get them to the place
they belong.

And one more comment:  It is my experience that there exists mail for
which either the sender, or the receiver, or both, do not care about
specific failures to deliver any one item, though they may care about
non-delivery of a whole batch, et al.  I call this kind of mail "Junk
Mail."  In the MsgGroup case, there is only one person who really cares
about each and every one, and that is yours truly.  So, I guess your
junk mail is my gold ...

Cheers - Stef
10-May-82 01:30:04-PDT,402;000000000000  
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 1954-PDT
Date:  5 May 1982 22:09-EDT
From: "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC>
Subject: MSGGROUP#1750  Re:  automatic nondelivery notification
To: STEF at DARCOM-KA
cc: MSGGROUP at MIT-MC

Perhaps what is needed is an "Acknowledge-To" field similar to the
"Reply-To:" field which specifies where to send acknowledgements?

Marvin Sirbu

10-May-82 01:51:46-PDT,6722;000000000001 
Date:  5 May 1982 1900-PDT
From: MsgGroup at ECL
Subject: MSGGROUP#1751  SURVEY of [ECLC]<MSGGROUP>MSGGROUP.1700-1750.1
To: MSGGROUP at MIT-MC
Redistributed-To: msggroup at MIT-ML
Redistributed-By: STEF at DARCOM-KA
Redistributed-Date: 10 May 1982

The message file [ECLC]<MSGGROUP>MSGGROUP.1701-1750.1 may be FTPed from
[ECLC], or you may request that specific items be redistributed to you.
Send any requests to MSGGROUP@ECLC or to EStefferud@ECL.  ECLC supports
FTP LOGIN ANONYMOUS with PASSWORD ARPA.

The survey below identifies all the traffic included in this file.

Best - Stef


MSGGROUP#1701  SURVEY [ECL]<MSGGROUP>MSGGROUP#.1651-1700
 6778 chars 2 Mar 82 1130-PST From: MsgGroup at ECL To: MsgGroup at ECL

MSGGROUP#1702  NETWORK NEWS #11
 1827 chars  2 Mar 1982 1124-PST From: Feinler at SRI-NIC To:   Netnews-

MSGGROUP#1703  Mail Item With Non-Standard "From" Field
 1666 chars  7 Mar 1982 1739-PST From: Daul at OFFICE   To:   MsgGroup a

MSGGROUP#1704  Re:  Mail Item With Non-Standard "From" Field
  630 chars 7 Mar 82 21:10:09-EST (Sun) From: Dpk at BRL To: Daul at Off

MSGGROUP#1705  Re:  Mail Item With Non-Standard "From" Field
  646 chars 7 Mar 82 21:58:38-EST (Sun) From: Michael Muuss <mike@BRL> T

MSGGROUP#1706  Mail Item With Non-Standard "From" Field
  574 chars 7 March 1982  18:32-PST From: Jonathan Alan Solomon <JSOL at

MSGGROUP#1707  legal ramifications of electronic mail
 1629 chars  8-Mar-82 10:43:02 PST From: Farrell at PARC-MAXC To: ESteff

MSGGROUP#1708  Legal message issues
 3461 chars 18 Mar 1982 0730-PST From: WMartin at Office-3 (Will Martin)

MSGGROUP#1709  legal ramifications of electronic mail
  818 chars 19 Mar 1982 1659-PST From: MCFARLAND at USC-ISI To:   Farrel

MSGGROUP#1710  Signature Verification
 1472 chars 23 March 1982  08:51-PST From: WANCHO at DARCOM-KA To: WMart

MSGGROUP#1711  re: #1710 Signature verification
  799 chars 29 Mar 1982 1627-PST From: Mark Crispin To: MsgGroup at USC-

MSGGROUP#1712  authentication
  624 chars 29 March 1982 1711-PST (Monday) From: lauren at UCLA-Securit

MSGGROUP#1713  Re: Signature Verification
 1833 chars 29 Mar 1982 1734-PST From: Zellich at OFFICE-3 (Rich Zellich

MSGGROUP#1714  Re:  #1709 legal ramifications of electronic mail
  955 chars 30 March 1982 03:58-EST From: Steve Kudlak <FFM at MIT-MC> T

MSGGROUP#1715  Unix MMDF author certification
 1065 chars 30 Mar 82 6:58:25-EST (Tue) From: Dave Crocker <dcrocker.EE@

MSGGROUP#1716  Re: Legal message issues
 1601 chars  4 April 1982 00:36 est From: Frankston.SoftArts at MIT-MULT

MSGGROUP#1717  Re: #1710 Signature Verification
  919 chars  5 Apr 82 10:34:55-EST (Mon) From: Michael Muuss <mike@BRL-B

MSGGROUP#1718  UNIX date formats
  518 chars  3-May-82 13:02:06 PDT (Monday) From: Hamilton.ES at PARC-MA

MSGGROUP#1719  re: multiple at signs
  896 chars  3 May 1982 1303-PDT From: POSTEL at USC-ISIF To:   neves at

MSGGROUP#1720  Multiple atsigns & other networks
 2029 chars  3 May 1982 15:16:46 EDT Mon From: neves@mit-vax@mit-mc To: 

MSGGROUP#1721  Re: UNIX date formats
  663 chars  3 May 1982 14:05-PDT Monday From: Steve Hartwell <hartwell@

MSGGROUP#1722  Re: Multiple atsigns & other networks
 1013 chars  3 May 1982 1412-PDT From: CERF at USC-ISI To: neves at MIT-

MSGGROUP#1723  re: multiple at signs
 1560 chars  3 May 1982 1431-PDT From: CERF at USC-ISI To: POSTEL at USC

MSGGROUP#1724  UNIX date formats
 1560 chars  3 May 1982  15:06-PDT Monday From: Jonathan Alan Solomon <J

MSGGROUP#1725  Re: UNIX date formats
  500 chars  3 May 1982 15:14-PDT Monday From: Dave-Yost at RAND-UNIX To

MSGGROUP#1726  Re: Multiple atsigns & other networks
 1926 chars  3 May 1982 1547-PDT From: Mark Crispin To: neves at MIT-VAX

MSGGROUP#1727  Re:  re: multiple at signs
  893 chars  3 May 1982 16:25-PDT From: Brian Reid <reid@Shasta at Sumex

MSGGROUP#1728  Re: UNIX date formats
  482 chars  3 May 1982 17:08-PDT From: greep at SU-DSN To: Hamilton.ES 

MSGGROUP#1729  Re: UNIX date formats
 1653 chars  3 May 1982 17:58-PDT From: Steve Hartwell <hartwell@Shasta 

MSGGROUP#1730  Re:  re: multiple at signs
 1399 chars  3 May 1982 2058-PDT From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1731  Re:  re: multiple at signs
 1710 chars  3 May 1982 2155-PDT From: Joel Goldberger To: Geoff at SRI-

MSGGROUP#1732  Re:  re: multiple at signs
 1073 chars  3 May 1982 2313-PDT From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1733  mail routing
 1386 chars  3 May 1982 23:38-PDT From: Brian Reid <reid@Shasta at Sumex

MSGGROUP#1734  Re:  re: multiple at signs
 1333 chars  3 May 1982 2354-PDT From: Mark Crispin To: JGOLDBERGER at U

MSGGROUP#1735  Re: Multiple atsigns & other networks
  966 chars  4 May 1982 1547-EDT From: MOOERS at BBNA To: neves at mit-v

MSGGROUP#1736  "User Not Authenticated"
  841 chars  4 May 82 16:39:31-EDT (Tue) From:     Michael Muuss <mike@B

MSGGROUP#1737  re: mail routing
  413 chars  4 May 1982 1342-PDT From: POSTEL at USC-ISIF To:   msggroup

MSGGROUP#1738  Re:  "User Not Authenticated"
  906 chars  4 May 1982 2304-PDT From: the tty of Geoffrey S. Goodfellow

MSGGROUP#1739  Re:  "User Not Authenticated"
 2956 chars  5 May 1982 0512-PDT From: Craig Milo Rogers  <ROGERS at USC

MSGGROUP#1740  Re:  "User Not Authenticated"
 1596 chars  5 May 1982 0821-PDT From: STEF at DARCOM-KA To: Geoff at SR

MSGGROUP#1741  Re:  "User Not Authenticated"
 1039 chars  5 May 1982 1232-EDT From: J. Noel Chiappa <JNC at MIT-XX> T

MSGGROUP#1742  Re:  "User Not Authenticated"
  636 chars  5 May 1982 1010-PDT From: Keith A. Lantz <CSL.LANTZ at SU-S

MSGGROUP#1743  Re: [neves@mit-vax: you should fix this guy's mailbox]
  680 chars  5 May 1982 1152-PDT From: STEF at DARCOM-KA To: SWG at MIT-

MSGGROUP#1744  Re: UNIX date formats
 1309 chars  5 May 1982 15:39-PDT From: Dave-Yost at RAND-UNIX To: Steve

MSGGROUP#1745  automatic nondelivery notification
 2549 chars  5 May 1982 16:26-PDT From: Brian Reid <reid@Shasta at Sumex

MSGGROUP#1746  Re: UNIX date formats
  617 chars  5 May 1982 1634-PDT From: Andrew Knutsen <knutsen@SRI-UNIX>

MSGGROUP#1747  automatic nondelivery notifications
  819 chars  5 May 1982 1642-PDT From: Mark Crispin To: MsgGroup at MIT-

MSGGROUP#1748  Re:  automatic nondelivery notification
 1777 chars  5 May 82 20:09:11-EDT (Wed) From:     Dave Crocker <dcrocke

MSGGROUP#1749  Re:  automatic nondelivery notification
 3254 chars  5 May 1982 1856-PDT From: STEF at DARCOM-KA To: dcrocker at

MSGGROUP#1750  Re:  automatic nondelivery notification
  402 chars  5 May 1982 22:09-EDT From: "Marvin A. Sirbu, Jr." <SIRBU at


10-May-82 01:51:46-PDT,1224;000000000000
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 1957-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 5-May-82 1915-PDT
Date:  5 May 1982 19:17-PDT
To: Dave-Yost at RAND-UNIX
Cc: Hamilton.ES at PARC-MAXC, MSGGroup at MIT-ML
Subject: MSGGROUP#1752  Re: UNIX date formats
In-reply-to: Your message of Wednesday,  5 May 1982 15:39-PDT.
From: Steve Hartwell <hartwell@Shasta at Sumex-Aim>

Thank you for the routines, which we have had since the beginning of time.

What I said was that there are 50 gazillion unix sites out there which use
ctime(3) format.  And they probably are not going to convert to arpa format
because FOOMAILR running on Kumquat-20 can't deal with ctime.

Gateways between UUCP and ARPA sites are good things, I agree.  But it is not
a good assumption that the senders will provide the mail format acceptable
at the receiving site.  I feel that this is the responsibility of the
machine acting as the gateway, but this is often not done.  It is not done
at Berkeley, for example.  It is done (partially) on Shasta; incoming UUCP
mail is converted to rfc733 format (though not quite perfect).  Outgoing UUCP
mail is not converted yet because I haven't gotten to it yet, but I plan to.

10-May-82 01:51:46-PDT,1279;000000000000
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 2031-PDT
Date:  5 May 1982  19:34-PDT
From: Jonathan Alan Solomon <JSOL at ECLC>
To:   STEF at DARCOM-KA
Cc:   BKR at SU-AI, dcrocker at UDEL-RELAY, MsgGroup at MIT-MC
Subject: MSGGROUP#1753  automatic nondelivery notification

I remember talking about this very issue with Roger Duffey at MIT.  We
concluded that a mechanism would be required (in the next generation
of mail systems?) which would assign an "owner" to a list.  The owner
would receive all failure attempts for any addresses on the list.
Theoretically; if MIT-ML distributes MSGGROUP, then MIT-ML would be
the only place which needed to know that MSGGROUP was owned by STEF.
In fact, Roger, Chris Stacy, and I discussed a possible modification
to COMSAT (the MIT ITS Mailer) to support mailing message failures
directly to the -REQUEST address, if all lists had this address, it
would be a fairly simple peice of functionality to add to any current
mailing list processor (TOPS-20 XMAILR, UNIX MMDF, or COMSAT).

Doesn't PARC currently have such a mechanism on their in-house mailing
lists? I know my lists have a local-address at XEROX which expands to
the local recipient list for Xerox, and each of these has an Owner.

Cheers,
--JSol

10-May-82 01:51:46-PDT,1112;000000000000
Mail-from: ARPANET host MIT-MC rcvd at 5-May-82 2121-PDT
Mail-from: SU-NET host SU-SHASTA rcvd at 5-May-82 1942-PDT
Date:  5 May 1982 19:44-PDT
To: MsgGroup at MIT-MC
Subject: MSGGROUP#1754  Taft@Parc: notification
Reply-to: BKR at SU-AI
From: Brian Reid <reid@Shasta at Sumex-Aim>


------- Forwarded Message
Mail-from: SU-NET host Sail rcvd at Wed May  5 17:07:08 1982
Date:  5 May 1982 17:05 PDT
From: Taft at PARC-MAXC@Shasta at Sumex-Aim
Subject: Re: automatic nondelivery notification
In-reply-to: reid@Shasta's message of Wednesday,  5 May 1982 16:26-PDT
To: BKR at SU-AI

For whatever it's worth, you might be interested in what the Grapevine system
does.  If delivery to a mailbox fails, and the mailbox was addressed via a
distribution list rather than directly, then the failure notification is sent
to the owner of the list rather than to the originator of the message.  The
idea is to encourage the list's owner to fix the list, rather than having
the mail system endlessly discard messages for defunct mailboxes named in
the list.
	Ed

------- End of Forwarded Message

10-May-82 01:51:46-PDT,852;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 2217-PDT
Date:  6 May 82 0:55:12-EDT (Thu)
From:     Doug Kingston <dpk@BRL>
To:       Craig Milo Rogers <ROGERS@Usc-Isib>
cc:       Geoff at Sri-Csl, mike at Brl, lauren at Ucla-Security, 
          BALDWIN at Mit-Xx, Dcrocker at Udel-Relay, Msggroup at Mit-Ml, 
          Gurus at Brl
Subject: MSGGROUP#1755  Re:  "User Not Authenticated"

	As it stands now, there is no real mechanism for verifying
that a message from ARPA to ARPA is "authentic".  For instance,
around Christmas, someone will send out a message from

	"Santa Clause at North-Pole"

The best that you can say is that your software can tell from where
the message was sent, and then only if you trust what the IMP tells
you.  Much of what we do is built on "I trust your system, and you
trust mine."
					-DPK-


10-May-82 01:51:46-PDT,1705;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 6-May-82 1758-PDT
Date:  6 May 1982 07:50:22-CDT
From: solomon at uwisc
To: MSGGroup@MIT-ML
Subject: MSGGROUP#1756  Re:  UNIX date formats

All this griping about ctime() seems to me to be missing the point.
All ctime() does is apply the library routine asctime() to format
the time.  A different format is easy to produce;  I've included a program
to produce an "ARPAnet-style" time at the end of this message.
All one has to do is replace ctime in all the UNIX mailer software
(/bin/mail, /etc/delivermail, /usr/ucb/mail, etc.).
Of course, the mail software also expects to receive dates in ctime
format, but it has hacks to accept various other formats (for mail
from ARPAnet), so that shouldn't cause any great problem.

But in a larger context, is this sort of bit-twiddling the kind of thing
that should be discussed in this forum?

#include <sys/types.h>
#include <time.h>
#include <stdio.h>

/* produce a ARPA-style date and time like the following:
	Date:  5 May 1982 at 1634-PDT
*/

#define LOCAL (6*60) /* minutes west of Greenwich */
#define SIZE 26 /* maximum size of a date string */
char * month[] = { "Jan","Feb","Mar","Apr","May","Jun","Jul","Aug",
		"Sep","Oct","Nov","Dec" };
char *
cctime(clock)
time_t *clock;
{
	struct tm *localtime(), *now;
	char *timezone();
	static char result[SIZE];

	now = localtime(clock);
	sprintf(result," %2d %s 19%02d at %02d%02d-%s\n",
		now->tm_mday, month[now->tm_mon], now->tm_year,
		now->tm_hour, now->tm_min, timezone(LOCAL,now->tm_isdst));
	return result;
}

main()
{
	time_t time(), curtime;

	curtime = time((time_t *)0);
	printf(cctime(&curtime));
}

10-May-82 01:51:47-PDT,262;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 6-May-82 1827-PDT
Date:  6 May 1982 08:03:13-CDT
From: solomon at uwisc
To: MSGGroup@mit-ml
Subject: MSGGROUP#1757  Date formats

Sorry about my earlier flame.  The level of the discussion has indeed been
raised.

10-May-82 01:51:47-PDT,1111;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 5-May-82 2345-PDT
Date:  5 May 1982 at 2313-PDT
From: Andrew Knutsen <knutsen@SRI-UNIX>
To: Doug Kingston <dpk@BRL>, Craig Milo Rogers <ROGERS@USC-ISIB>,
     Geoff at SRI-CSL, mike at BRL, lauren at UCLA-SECURITY, BALDWIN at
 MIT-XX, Dcrocker at UDEL-RELAY, Msggroup at MIT-ML, Gurus at BRL
Subject: MSGGROUP#1758  Re:  Re:  "User Not Authenticated"
In-reply-to: Your message of     6 May 82 0:55:12-EDT (Thu).
Sender: knutsen at SRI-UNIX

	There are 3 conditions where MMDF will *not* include
this message, if I read the code correctly:

1) the from (sender) address is the user running the program;
2) either the superuser or the mailsystem login is running it;
3) it is able to add a "Via:" line containing a string found
	in a system table.

	Thus it isnt really so much a matter of trusting the
software, as trusting the "person" running it and the system
tables, it seems to me.

	Btw I am testing a program which will allow all returned
mail for a local mailbox to be sent to a single mailbox. It uses
the "rcvmail" mechanism of MMDF.


10-May-82 01:51:47-PDT,1334;000000000001
Mail-from: ARPANET host MIT-MC rcvd at 6-May-82 0826-PDT
Date:  6 May 1982 08:14 cdt
From:  Stachour.CSCswtec at HI-Multics
Subject: MSGGROUP#1759  Re:  automatic nondelivery notification
To:  "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC>
cc:  MSGGROUP at MIT-MC
Acknowledge-To:  Stachour.CSCswtec at HI-Multics
In-Reply-To:  Msg of 05/06/82 04:28 from Marvin A. Sirbu, Jr.

Please note that the Multics Mail System (specifically read_mail/send_mail)
does provide for an "Acknowledge-To" field, which is used by the
Multics mailers to define the address to which the "return reciept"
is to be posted when the message is read.
[An example is found in the header of this message.]
This field's function can obviously be expanded to indicate
where non-delivery notifications, as well as delivery+signing
notifications (that's conceptually what reading a message with
a request that it be acknowledged means),
but I would hate to be notified of the 137 people in the group
who did indeed receive my message sucessfully in order
to know about the two who didn't!
My point is that there needs to be more than a blanket acknowledgment
field to cover all possible acknowledgements.
At a minimum, two variants (sucessful delivery & acceptance by user)
and (failure to delivery sucesfully) are needed.
  ...Paul Stachour

10-May-82 01:51:47-PDT,1300;000000000000
Mail-from: ARPANET host MIT-MC rcvd at 7-May-82 1154-PDT
Date:  7 May 1982 1100-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1760  Re:  automatic nondelivery notification
From: STEF at DARCOM-KA
To: Stachour.CSCswtec at HI-MULTICS
Cc: MSGGROUP at MIT-MC
Message-ID: <[DARCOM-KA] 7-May-82 11:00:56.STEF>
In-Reply-To: Your message of  6 May 1982 08:14 cdt

Thanks Paul, for the opportunity to once again make my soap box speech
about automatic acknowledgments.

There should be (but too often is not) a careful distinction between
"signing" an acknowledgment and then releasing it for delivery to a
sender, and "so called reading" which is really just printing or
displaying on a terminal.  The later does not constitute "reading and
accepting responsibility for acting on the content" since it is not
clear who might have done the printing.  For instance, it might have
been a clerk or a secretary while the addressed recipient is out on
travel, or something.  Or maybe some kind of "rcvmail" process as in
MMDF.

In graphic terms:  If in the paper world, my secretary automatically
notified you, without willful authorization from me, that I had "read"
your mail (signalling acceptance of my responsibility for acting on the
content), I would fire him.

Best - Stef

22-May-82 16:02:08-PDT,473;000000000001
Mail-from: ARPANET host MIT-MC rcvd at 14-May-82 0318-PDT
Date: 14 May 1982 0010-PDT
From: Daul at OFFICE  
Subject: MSGGROUP#1761  Rumor Confirmation 
Subject:                (CCIT new Inter-System Communications Standards)
To:   msggroup at MIT-MC, header-people at MIT-MC
cc:   daul

I have heard a rumor that new standards have been drawn-up/released in
the last 2 or 3 weeks.  Is it true and, if so how can I get further
info?

Thanks,  --Bill
-------

22-May-82 16:02:08-PDT,801;000000000001
Date: 14-May-82  9:00:48 PDT (Friday)
From: white at PARC-MAXC
Subject: MSGGROUP#1762  Re: Rumor Confirmation 
Subject:                (CCIT new Inter-System Communications Standards)
In-reply-to: Daul's message of 14 May 1982 0010-PDT
To: Daul at OFFICE
cc: msggroup at MIT-MC, header-people at MIT-MC, White.pa

Bill, The CCITT rapporteur's group on message handling facilities (i.e.,
electronic mail) maintains a living document that will eventually
become--but is not now--a proposed CCITT recommendation (i.e.,
standard).  Version 3, which reflects the work done at the March meeting
in Melbourne, was indeed completed just a week or two ago. I would be
happy to send a copy to you and to other interested members of MSGGroup,
provided the number of such people is modest.  /Jim

22-May-82 16:02:08-PDT,1793;000000000000
Mail-from: ARPANET host OFFICE-8 rcvd at 22-May-82 1145-PDT
Date: 20 May 1982 1547-PDT
Sender: WESTINE at USC-ISIF
Subject: MSGGROUP#1763  RFCs 810, 811, and 812 now available
From: WESTINE at USC-ISIF
To: "[ISIF]<Westine>Request-for-Comments.List":
Message-ID: <[USC-ISIF]20-May-82 15:47:53.WESTINE>

RFC Announcement

   New RFCs are now available from the Network Information Center in the
   NETINFO directory at SRI-NIC.

   RFC 810:

      Title:   DoD Internet Host Table Specification 
      Author:  E. Feinler, Z. Su & V. White
      Pages :  8

         pathname: [SRI-NIC]<NETINFO>RFC810.TXT

      This memo describes a new host table for use in the ARPA Internet.
      The format of this new table is significantly different than the 
      old table.  Hosts on the ARPANET and on other networks in the 
      internet, as well as gateways, are listed.

   RFC 811:

      Title:   Hostnames Server 
      Author:  K. Harrenstien, V. White, and E. Feinler
      Pages :  4

         pathname: [SRI-NIC]<NETINFO>RFC811.TXT

      This memo describes an interactive server for accessing entries in
      the new host names table, described in RFC 810.

   RFC 812:

      Title:   Nicname/Whois
      Author:  K. Harrenstien, and V. White
      Pages :  3

         pathname: [SRI-NIC]<NETINFO>RFC812.TXT

      This memo describes an interactive server to access the user names
      data base of the ARPANET Directory.

   Public access files may be copied from the NETINFO directory at 
   SRI-NIC via FTP with username ANONYMOUS and password GUEST.

   Requests to be added to or deleted from this distribution list should
   be sent to NIC@SRI-NIC.  Submissions for RFCs should be sent to 
   POSTEL@ISIF.

   --jon.

2-Jun-82 00:17:42-PDT,2812;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 25-May-82 1608-PDT
Date: 25 May 1982 1828-EDT
From: DREIFU at Wharton-10 (Henry Dreifus)
Subject: MSGGROUP#1764  Wharton's access to Arpanet (or rather lack thereof).
To: @T.MAI[10,43] at Wharton-10:

Network community: (Please forward as appropriate).

Through a series of errors and improper management of the network,
Wharton will be off the Arpanet for an indefinite period of time.
I understand that service thus far (for the past month) has been
unacceptable to the Wharton community, however this shall stop, as
of 17:00 5/25/82 Wharton will not have to deal with the problem of
poor service: I.e. no service.

The purpose of this message is many-fold.  First it is to officially
inform you that our host will be down and to notify your liaison
and community who need to use the services at Wharton of this
lack of availablilty. Second, is to point out some of the problems,
and to try and constructively prevent this from happening to another
site, in future situations. Third it is to try and get some proper
lines of command, one thing I still am unable to understand.

Problems thus far:
1. Poor reporting of hosts on the network.
2. Lack of flow through DCA.
3. TSR's are poorly put through, so bad that they do not even
   mention special assemblies, thus create worse situations
   when WRONG equipment is installed.
4. AT&T v. local operating companies, "priviledged business" can
   be more damaging to local companies than letting Long-Lines
   handle an existing, known problem.
5. Poor transmission and reporting of information (such as I doubt
   that most people are aware we were 3/19 for the past 2 weeks,
   not 1/19). (I am not including "THOSE" who did not know even
   of our existence in the first place)
6. Service outages.  We've been on the recieving end of many
   extended down-times from the network, without previous warning.
   We end up calling to find out there is a scheduled "power down"
   of a given network-line/IMP/TAC/whatever 3-letter combination
   abbreviation you care to use.
7. Most communication of changes appears to be verbal. As of yet,
   for this entire situation I have only one piece of written
   notification, a TSR, which is wrong!  

Contacts:
All mailboxes @Wharton-10 are and will be unavailable until we are
back on the network (we have no idea what our new address will be).
All research and needs for our machine will have to be arbitrated
through alternate channels.  Those who need access to our projects
(i.e. FAA database, DBalt, EWAR, etc.) should contact me at
(215) 243-7731 or (215) 243-5872 to arrange alternatives.

Thank you very much, and I hope that others in the future need
not become as frustrated.

Henry Dreifus
Wharton School

2-Jun-82 00:17:43-PDT,1387;000000000001
Mail-from: ARPANET host MIT-MC rcvd at 30-May-82 1841-PDT
Date: 30 May 82 20:49:36-EDT (Sun)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Relay-Sites at UDel-Relay, MsgGroup at Mit-Mc, 
          Header-People at Mit-Mc
cc:       CSNet-Staff at UDel-Relay
Subject: MSGGROUP#1765  XMAILR problem.

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

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

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

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

Dave


2-Jun-82 00:17:43-PDT,891;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 31-May-82 1336-PDT
Date: 31 May 1982 1315-PDT
From: Mark Crispin
Subject: MSGGROUP#1766  XMAILR and timeouts
Sender: ADMIN.MRC at SU-SCORE
To: MsgGroup at MIT-ML
cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I think it's been agreed that we'll change XMAILR, with one note:
It isn't unreasonable for a system manager to feel that his system
mailer should not be tied up for more than 5 minutes delivering a
single copy of a message to a single site, EVEN IF it is merely because
the receiving site is too slow.  Much of the sort of traffic which is
impacted by XMAILR's present behavior are junk mail which isn't even
legitimate usage of ARAPNET anyway.
-------

2-Jun-82 00:17:43-PDT,573;000000000001
Mail-from: ARPANET site MIT-ML rcvd at 31-May-82 1620-PDT
Date: 31 May 1982 15:58-PDT
To: Admin.MRC at SU-SCORE
Cc: MsgGroup at MIT-ML, Header-People at MIT-MC, DCrocker at UDEL-RELAY
Subject: MSGGROUP#1767  Re: XMAILR and timeouts
In-reply-to: Your message of 31 May 1982 1315-PDT.
From: greep at SU-DSN

Obviously, no matter how fast all the systems are, there is some length
of message which will exceed any fixed timeout.  An alternate strategy
would be for the mailer to delay long messages until the system load is
light, or late at night, or whatever.

2-Jun-82 00:17:43-PDT,973;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 0051-PDT
Date:  1 Jun 1982 0032-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1768  Re: XMAILR and timeouts
From: STEF at DARCOM-KA
To: greep at SU-DSN
Cc: Admin.MRC at SU-SCORE, MsgGroup at MIT-ML, 
Cc: Header-People at MIT-MC, DCrocker at UDEL-RELAY
Message-ID: <[DARCOM-KA] 1-Jun-82 00:32:04.STEF>
In-Reply-To: Your message of Monday, 31 May 1982 15:58-PDT

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

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

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

Thanks - Stef

2-Jun-82 00:17:43-PDT,1153;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 0939-PDT
Date:  1 Jun 1982 0916-PDT
Sender: GEOFF at SRI-CSL
Subject: MSGGROUP#1769  Re:  returning failed mail
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: Charles Hornig at MIT-MULTICS
Cc: MsgGroup at MIT-ML
Message-ID: <[SRI-CSL] 1-Jun-82 09:16:22.GEOFF>
In-Reply-To:  <820601131824.270778 at MIT-MULTICS>

He wants it back "each and every time", since, it is the common
practice to then forward or otherwise remail the returned msgs
off to a new address, especially if the cause of the msg getting
returned was an address spelling error.

A nice addition to the "each and every time" method is that on
the first run of processing a queued msg with more than one
address in it, is to wait until the run is complete and then mail
off all the errors (with a copy of the msg header & text) in ONE
msg.  Then, from each time there after, return a separate msg for
each and every error return encountered.  This method saves the
user from getting deluged with many separate error msgs, since ,
you expect most mail is going to go thru with the first run.

2-Jun-82 00:17:44-PDT,1130;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 0649-PDT
Date:  1 Jun 1982 09:18 edt
From:  Charles Hornig at MIT-MULTICS
Subject: MSGGROUP#1770  returning failed mail
Sender:  Hornig.Multics at MIT-MULTICS
To:  MsgGroup at MIT-ML
Message-ID:  <820601131824.270778 at MIT-MULTICS>

I am implementing a new mailer for Multics to support the new mail
protocols.  I have run across the question of when mail which cannot be
delivered should be returned to the sender.  In particular, examine this
scenario:
   UserA at HostA sends mail to UserB at HostB and UserC at HostC
   The mail is queued because both HostB and HostC are down.
   HostB comes up.
   We attempt to send the mail to UserB at HostB and discover that he
      does not exist.
   We send a note the the original sender explaining this.
   HostC comes up.
   We go through the same thing as with HostB.

The original sender wants to get a copy of his mail back at some point
if it cannot be delivered.  The question is, does he want it back every
time it cannot be delivered, just the first time, just the last time, or
some other time?


2-Jun-82 00:17:44-PDT,1485;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1153-PDT
Date:  1 Jun 1982 1112-PDT
Sender: CERF at USC-ISI
Subject: MSGGROUP#1771  Re:  returning failed mail
From: CERF at USC-ISI
To: Geoff at SRI-CSL
Cc: Charles Hornig at MIT-MULTICS, MsgGroup at MIT-ML
Message-ID: <[USC-ISI] 1-Jun-82 11:12:45.CERF>
In-Reply-To: <[SRI-CSL] 1-Jun-82 09:16:22.GEOFF>

The current ARPANET mail is kept by the TOPS-20 mailer until
it has been "successfully" accepted by the next mail receiver
(could be destination or a forwarder). If the TOPS-20 mailer
is not successful in getting the mesage through, it changes
the message name to ]undeliverable...[ and leaves a terse
message in the user's primary message file to this effect.

This works well with one-hop kinds of systems but less easily with
multi-hop systems such as the mailers (eg MsgGroup) and the
special forwarders (e.g. MMDF). Getting back whole copies is
a pain, particuarly when there are many recipients which fail -
witness the mess we got into recently with many MsgGroup addresses
not working very well.  

Do we need a high level end/end acknowledgement scheme which
permits the source to "check off" that the message was received by
the ultimate destinatin addressee?

by the way, would you consider, in the case of MsgGroup, that
a message addressed to MsgGroup would be "checked off" once it
arrived at Msg Group@ML or only after it got to the actual
mailboxes listed in MsgGroup?

Vint Cerf

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

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

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

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

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

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

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

-- Mark --
-------
2-Jun-82 00:17:44-PDT,650;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1457-PDT
Date:  1 Jun 1982 1355-PDT
From: Mark Crispin
Subject: MSGGROUP#1773  returning failed mail
Sender: ADMIN.MRC at SU-SCORE
To: MsgGroup at MIT-ML
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I think it is safest to return it every time you send a rejection.
It is better to try to get more than one failure in the same rejection.
It is quite possible that the user may want to retransmit the message
and not have yesterday's failure to somebody else.
-------

2-Jun-82 00:17:44-PDT,1124;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1602-PDT
Date:  1 Jun 1982 1532-PDT
Sender: CERF at USC-ISI
Subject: MSGGROUP#1774  Re: returning failed mail
From: CERF at USC-ISI
To: Admin.MRC at SU-SCORE
Cc: MsgGroup at MIT-ML
Message-ID: <[USC-ISI] 1-Jun-82 15:32:13.CERF>
In-Reply-To: Your message of  1 Jun 1982 1355-PDT

I don't agree with Mark's view. My primary concern about
returning failed copies has to do with large mailing
list problems. When too many objects return, they can
take up so much space that the system may refuse to
accept them (e.g. over file space limitations on TOPS-20).

I would think a design which only has to hold one copy of
something, but alerts the users to failures would be preferable,
but I admit to not having thought all this out to deeply.
The current system seems to work because copies of every message
are kept until acknowledged by the final (?) destination;
perhaps this won't work for the kinds of forwarding we are now
seeing - but I would hate (do hate) to get many copies of
messages I sent to an exploder, some of which didn't make it.

Vint

2-Jun-82 00:17:44-PDT,1375;000000000001
Mail-from: ARPANET host UDEL-RELAY rcvd at 1-Jun-82 1702-PDT
Date:  1 Jun 82 19:47:54-EDT (Tue)
From:     Dave Crocker <dcrocker@UDel-Relay>
To:       Admin.MRC at Su-Score
cc:       STEF at Darcom-Ka, greep at Su-Dsn, MsgGroup at Mit-Ml, 
          Header-People at Mit-Mc, DCrocker at UDel-Relay
Subject: MSGGROUP#1775  Re:  XMAILR and timeouts

Mark --

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

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

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

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

2-Jun-82 00:17:44-PDT,1514;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1809-PDT
Date:  1 Jun 82 20:39:29-EDT (Tue)
From:     Doug Kingston <dpk@BRL>
To:       CERF at Usc-Isi
cc:       Admin.MRC at Su-Score, MsgGroup at Mit-Ml
Subject: MSGGROUP#1776  Re:  returning failed mail

	There are two types of "returned mail", 1) mailing-list
failures, and 2) direct-mail failures.

	For case 1) the failure notices should go to the list
maintainer.  Unfortunately, there is no specified mechanism to handle
this now, so unless the headers are munged, we (the originators) get the
failure notices and must manually send them to the maintainer.  In this
case, I don't want the return notices at all if they can be sent to the
maintainer.

	For case 2) I want the text every time the mailer sends
something back to me so that I can forward the text on to the proper
address.  If the mailer is smart enough to send me the failures in
batchs, I wouldn't mind.  But, I don't want the mailer to wait until the
message is flushed until it sends me the failure notices.  For example,
consider the case where you send a note to A at siteA and B at siteB.
The first message fails due to a bad address, and the second is requeued
because siteB is down for a long weekend.  I want the failure notice as
soon as the mailer knows that letter is dead, not after the long
weekend.

	So much for my thoughts.  Case 1) needs some collective thought
if someone has not been thinging about it yet.

						Cheers,
							-Doug-


2-Jun-82 00:17:45-PDT,1325;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1930-PDT
Date:  1 Jun 1982 1818-PDT
Sender: STEF at DARCOM-KA
Subject: MSGGROUP#1777  Re: XMAILR and timeouts
From: STEF at DARCOM-KA
To: MsgGroup at MIT-ML, Header-People at MIT-MC
Message-ID: <[DARCOM-KA] 1-Jun-82 18:18:29.STEF>
In-Reply-To: DCrocker message of 1 Jun 82 19:47:54-EDT (Tue)

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

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

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

Swish ===========> Stef

2-Jun-82 00:17:45-PDT,1631;000000000001
Mail-from: ARPANET host MIT-ML rcvd at 1-Jun-82 1947-PDT
Date:  1 Jun 82 18:32:07 PDT (Tuesday)
From: Newman.es at PARC-MAXC
Subject: MSGGROUP#1778  Re: returning failed mail addressed to a mailing list
In-reply-to: dpk's message of 1 Jun 82 20:39:29-EDT (Tue)
To: Doug Kingston <dpk@BRL>
cc: CERF at Usc-Isi, Admin.MRC at Su-Score, MsgGroup at Mit-Ml

In the Xerox Grapevine mail system, every mailing list has associated
with it a list of maintainers, known as the "owners" list.  Whenever you
create a mailing list called "Foo", a pseudo-list called "Owners-Foo" is
automatically generated, consisting of the maintainers of "Foo".

This has two nice properties:

  a) If "Foo" contains an invalid recipient, the mail system
automatically generates a failure message addressed to "Owners-Foo" the
next time anyone tries to send to "Foo".  It does NOT send a failure
message to the poor sender, who doesn't care anyway.

  b) The way to send mail to the maintainers of a list is well
known; thus it is rare for someone to send a message to the entire
list asking to be put on or taken off a list.  That is an exasperatingly
frequent occurrence on the Arpanet!

Also, the knowledge of what recipients are valid is distributed
over a large number of servers, so it is normally possible to detect
invalid direct recipients at the time the message is sent, rather
than having to generate a failure message at some later time. 
For instance, even when the mail server in Palo Alto is down or
unreachable, it is likely that a Los Angeles mail server can detemine
the validity of Palo Alto names.

/Ron
2-Jun-82 00:17:45-PDT,1603;000000000001
Mail-from: ARPANET host BRL rcvd at 1-Jun-82 2349-PDT
Date: 1 Jun 1982 2335-PDT
Sender: STEF at Darcom-Ka
Subject: MSGGROUP#1779  New MsgGroup relay via BRL
From: MsgGroup at Usc-Eclc
Reply-To: MsgGroup at BRL
To: MsgGroup at Mit-Ml
Message-ID: <[DARCOM-KA] 1-Jun-82 23:35:53.STEF>
Via:  Mit-Ml; 2 Jun 82 2:39-EDT

Hi All - This message should be the first to pass through the new
MsgGroup relay point at BRL.  From now on you can send mail directly to
MsgGroup@BRL for automatic direct redistribution.

The old MsgGroup@MIT-ML address will still work, but the MIT list only
holds the MsgGroup@BRL address now.

MsgGroup-Request@BRL works now, as does MsgGroup-Request@MIT-ML.  Both
of these reflect requests for list maintenance to Stef@DARCOM-KA for
service.

Over the summer, I intend to arrange for some new mechanisms to be
attached to the MMDF RCVMAIL hook which will take possession of mail
items arriving for MsgGroup@BRL and re-initiating each item as new mail
FROM:  MsgGroup-Request@BRL so that errors in the list will go to
MsgGroup-Request rather than back to the originator of the item.

For this to work, the RCVMAIL Daemon will have to insert a REPLY-TO:
MsgGroup@BRL field to direct replies back to the group address rather
than directing them to the address list maintainer.

There are some other things I want to do such as insert the
MSGGROUP#nnnn accession numbers automatically into the SUBJECT to aid
with references to prior messages, etc.  Some of these ideas are still
in limbo, but summer is not quite here yet either ...

Best - Stef


17-Jun-82 16:27:11-PDT,3656;000000000001
Mail-from: ARPANET host BRL rcvd at 3-Jun-82 1137-PDT
Date: 2 June 1982 11:02-EDT
From: ALA at Mit-Ai
Subject: MSGGROUP#1780  Handling Error Messages
To: MsgGroup at Mit-Ml
Via:  Mit-Ml; 3 Jun 82 14:13-EDT

Charles:

I believe the answer to your problem is even more complicated that the
senario that you provide. Consider the following case, for example.  I
send mail to you and to MsgGroup. If there are bad addresses in the
MsgGroup mailing list, I want them to go to Stef (who can do something
about it). I don't want those copies returned to me, particularly if
they come back a week later as having timed out while a host was down.
Yet I do want to know if the message failed to get to you (where I may
have incorrectly typed your address or whatever and want to correct it).
Note particularly the conflict of what I want the error message to do!

We see this very kind of problem all the time with the bigger,
non-digestified lists. I can particularly think of when WorkS was not
digestified and messages waited at UDEL for relay elsewhere. Lots of
people complained that they didn't care that the message was waiting for
three days to get delivered and many others just got confused at
negative acknowledgements to indirect recipients.

It is also not clear that it is valid to tell me explicitly who is on
a mailing list by sending me error messages about them. This concept
is probably more true in a secure environment (which certain hosts on
the ARPAnet try to provide, I believe). I know that I, personally, tend
to prefer a low profile in some mailing lists and would prefer that
a random person sending to the list did not know if I was or was not
on it.

This idea is also true on Return-Receipt. If I ask my mailer for a
Return-Receipt, do I get told that a message has gone to MsgGroup, or is
it reported that each individual user got it. If the later, do I somehow
indicate the original address that mail was sent to (who are these
random people I'm getting receipts for? *I* sent mail to MsgGroup not
Joe.User@ISIF). A mail system I use frequently reports the actual
recipients, inevitably confusing me as to why I am getting an
acknowledgement from the wrong place. This problem become particularly
acute in an Internet scheme where we EXPECT redefinition of many
addresses on the way to a destination.

Another concept to consider is whether one should make some (or all) of
this behavior user-specified (with appropriate defaults, of course). I
have recently been involved with a non-ARPAnet electronic mail
standardization process which has been trying to resolve these very
questions (amoung others). In particular, some of the conclusions we
came to were that you needed a non-trivial "envelope" containing who an
error should be returned to (default is sender), lists had to be treated
specially and additional intelligence added to the transport protocols
to deal with them, the mail reader program has to be smart enough to do
something reasonable by default plus handle overriding cases by users
(if appropriate) and, perhaps most importantly, that there are always
cases where the 'correct' answer 90% of the time doesn't work as the
complete answer.

One particular thing I do believe strongly, however, is that how a
particular mail system currently implements solutions to these problems
does not necessarily make it the best solution. Many of the mail systems
on the ARPAnet had their major development in a very different mail
environment than the one that has development in the last couple of
years with the proliferation of lists.

	Best,
	Alyson

17-Jun-82 16:27:12-PDT,1813;000000000001
Mail-from: ARPANET host BRL rcvd at 4-Jun-82 0008-PDT
Date: 4-Jun-82 00:25:10-EDT (Fri)
From: mark at Ucb-C70 (Mark Horton)
Subject: MSGGROUP#1781  Re:  Handling Error Messages
Via: cbosgd.uucp (V3.73 [1/5/82]); 4-Jun-82 00:25:10-EDT (Fri)
To: MsgGroup at Mit-Ml
Via:  Mit-Ml; 4 Jun 82 0:31-EDT

Here's another problem that is tough to handle.  Say I send mail to
unix-wizards@sri-unix.  That mailing list somehow has a tag on it
which says that errors go to root@sri-unix.  One of the entries on
that mailing list is unix-wizards@nprdc.  So a copy of the message is
mailed to that sub-list.  (I could iterate through this a couple more
times but I want to keep the example small.)  Now something goes wrong.
Due to some botch at nprdc (say) there is no mailing list called
unix-wizards there.  So nprdc mails back the message to the sender.
You WANT it to be mailed to someone at nprdc who can fix the problem.
Obviously no mail software is going to do this.  So your second choice
is to mail it to the maintainer of the list on sri-unix.  How is nprdc
supposed to figure out that it should do this?  I suppose you could add
a Error-to: header field, but short of this, there is no way to have
the message sent to nprdc telling it that it should appear to be from
the original sender but to send error messages elsewhere.  And certainly
the original sender can't do anything about it, he doesn't even know
who to complain to!

This is not an idle thought.  Every time I send mail to unix-wizards I
get back 4 or 5 copies with some error message I never wanted to see.
Either some user on some indirect place doesn't exist any more, or some
host is down for 3 days, or something.  I think the above example (I
probably have the hosts wrong) actually happened recently.

	Mark


17-Jun-82 16:27:12-PDT,1583;000000000001
Mail-from: ARPANET host BRL rcvd at 4-Jun-82 1328-PDT
Date: 4 June 1982  12:56-EDT
From: SWERNOFSKY at Bbna
To:   ALA at Mit-Ai
Cc:   MSGGROUP at Mit-Ml, Swernofsky at Bbna
Subject: MSGGROUP#1782  macros and mailing lists
Via:  Mit-Ml; 4 Jun 82 13:51-EDT

Perhaps what is required, when mailing to a large list of people, is to
consider the list as a "pseudo-user" which receives your message and
then sends it to the group of people which it has recorded.  This
implies the following behavior:

1   People who send to "MSGGROUP at MIT-ML" get receipts/errors which
    deal with the success/failure of the send operation to MSGGROUP.
2   The pseudo-user MSGGROUP gets receipts/errors which deal with the
    success/failure of the send operation to individuals in MSGGROUP.

The mailing list maintainer(s) can then examine the error messages which
MSGGROUP gets in its attempts to send.  They modify the list of names
which MSGGROUP points to, while non-maintainers may remain blissfully
unaware of any problems.

It seems to me that there is a fundamental distinction between mailing
"macros", which are simply short names for a long list of people, and
mailing "packages", which are conscious attempts to make the list appear
to be a broadcast facility.  When dealing with large mailing lists at
distant hosts, people and their mailers should (at least by default)
treat the list as being a form of re-sending mechanism.  This allows
them to remain unbothered by details of the list contents; it also does
not require them to snoop.

-- Steve


26-Jun-82 14:30:58-PDT,1993;000000000001
Mail-from: ARPANET site BRL rcvd at 26-Jun-82 1430-PDT
Date: 26 June 1982 1614-EDT (Saturday)
From: Craig.Everhart at Cmu-10a
To: Zellich at Office-3 (Rich Zellich)
Subject: MSGGROUP#1783  Mailing-long-messages discussion--on to MsgGroup.
CC: MsgGroup at Mit-Ml
Reply-To: Rdmail at Cmu-10a
In-Reply-To:  Zellich@OFFICE-3's message of 26 Jun 82 13:26-EST
Message-Id: <26Jun82 161450 RD00@CMU-10A>
Via:  Mit-Ml; 26 Jun 82 16:34-EDT

There's a distinction between temporary-failure and permanent-failure
in the set of reply codes by which the status of sent mail is returned
from the receiving mail server to the sending mail (daemon) process;
at least, this is true in the NCP/TCP world.  A receiving server that
chooses to reject a message being sent on the grounds that it is too
long can choose which class of code to return to the sender.  Should
the receiver's semantics be to discard the partial copy, it can
request that the sender try again later, with a temporary-failure
code.  Should the receiver instead feel that the partial copy of the
mail is good enough, it can tell the sender to regard the mail as
either delivered successfully or permanently-failed to deliver; in
either case the sender will refrain from repeating the delivery
attempt.

There has been some confusion in the NCP-FTP world about what reply
codes are in which set, which only aggravates the problem; there is (I
believe) a pragmatic compromise available (in Brian Harvey's
RFC--691?).  In the TCP-mail world, great attention is given to this
distinction, so there should be no comparable problem.  I don't know
what other network protocols use for this distinction, but it's hard
to imagine that they can live without it.  Perhaps the absence of such
a distinction--or, in its absence, a universal convention--is at the
root of the delivery problems.

Once again, a gateway that translates mail delivery protocols has to
be smart about both protocols.  It's a hard job.


 7-Jul-82 00:52:25-PDT,1748;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 0026-PDT
Date:  6 Jul 1982 2325-PDT
From: Zellich at Office-3 (Rich Zellich)
Subject: MSGGROUP#1784  Mailing-list for "List of lists" update notices
To:   All mailing-lists
cc:   ZELLICH at OFFICE-3
Via:  Office-3; 7 Jul 82 2:30-EDT

For those of you not previously aware of it, I maintain a master list
of ARPANET mailing-lists/digests/discussion groups (currently 756
lines or ~29,000 characters) on OFFICE-3 in file:

   <ALMSA>INTEREST-GROUPS.TXT

   For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS
   login within FTP, with any password.

To keep people up to date on the large number of such lists, I have
established a mailing list for list-of-lists \update notices/.  I do
not propose to send copies of the list itself to the world at large,
but for those ARPANET users who seriously intend to FTP the updated
versions when updated, I will send a brief notice that a new version
is available.  For those counterparts at internet sites who maintain
or redistribute copies for their own networks (DECNet, Xerox, etc.)
and can't reach the master by ARPANET FTP, I will send out the
complete new file.  I do \not/ intend to send file copies to
individual users, either ARPANET or internet; our system is fairly
heavily loaded, and we can't afford it.

There is no particular pattern to the update frequency of INTEREST-
GROUPS.TXT; I will occasionally receive a burst of new mailing-lists or
perhaps a single change of address for a host or mailing-list
coordinator, and then have a long period with no changes.

To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the
mailing-list this message appears in.

Cheers,
Rich
-------

 7-Jul-82 09:52:31-PDT,1924;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 0950-PDT
Date:  7 July 1982 09:54 edt
From:  TMPLee.DODCSC at Mit-Multics
Subject: MSGGROUP#1785  NetMail Security Vulnerability Query
To:  tcp-ip at BRL, MsgGroup at Mit-Ml, Postel at Usc-Isi, 
     Cerf at Usc-Isi
Via:  Mit-Ml; 7 Jul 82 11:54-EDT

When I distributed the most recent issue of the Computer-Security-Forum
I encountered an apparent vulnerability, or weakness, in the way
messages are handled by (at least) some mail handlers.  I would
appreciate it if someone who knows could confirm or deny that this is
indeed a problem, whether it is site specific, and whether the new
regime (TCP-IP) will have eliminated it.

As some of you know, I use the UTexas mailer, since neither the BBN nor
Multics systems that are my home bases have mailers good for large
distribution lists. (mine now is about 120 names of primary
distribution.) Anyway, when it tried delivering the message to one of
the sites (Mitre-Bedford) apparently the Mitre-IMP was in what I am
told is called "loop-back" mode.  thus when Utexas thought it was
connecting to Mitre it was in fact actually connecting back to itself.
Also, apparently, there is no (easy?) way for a host to know this is
happening.  To make the long story shorter, it thus tried sending the
messages intended for Mitre to itself.  Fortunately, none of the
mailbox names (user-id's) at Mitre matched any of those currently
registered at Utexas.  As I understand it, if, however, there happened
to be a user at Utexas with the same name (same mailbox name) as one
whom I was attempting to send the message to at Mitre, the user at
Utexas would have received the message and no-one (except him, if he
were honest) would know that anything had gone wrong.

(I don't know if MsgGroup still lives; in any case, feel free to pass
this on to anyone else who might know, within reason.)

Ted Lee


 7-Jul-82 14:41:59-PDT,707;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 1439-PDT
Date:  7 Jul 1982 1406-PDT
From: MILLS at Usc-Isid
Subject: MSGGROUP#1786  Re: NetMail Security Vulnerability Query
To:   TMPLee.DODCSC at Mit-Multics, tcp-ip at BRL
To:   MsgGroup at Mit-Ml, Postel at Usc-Isi, Cerf at Usc-Isi
cc:   MILLS at USC-ISID
Via:  Mit-Ml; 7 Jul 82 17:08-EDT

In response to the message sent   7 July 1982 09:54 edt from TMPLee.DODCSC@Mit-Multics

Ted,

SMTP has a who-are-you function that will prevent the problem you
describe. The HELO command required in the initial dialog
advertises the sending host name, while the reply to this command
advertises the receiving host name.

Regards,
Dave
-------


 7-Jul-82 14:52:53-PDT,799;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 1448-PDT
Date:  7 Jul 1982 1250-PDT
From: Mark Crispin
Subject: MSGGROUP#1787  Re: NetMail Security Vulnerability Query
Sender: ADMIN.MRC at Su-Score
To: TMPLee.DODCSC at Mit-Multics
cc: tcp-ip at BRL, MsgGroup at Mit-Ml, Postel at Usc-Isi, 
    Cerf at Usc-Isi
Reply-To: Admin.MRC at Su-Score
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 7-Jul-82 0954-PDT
Via:  Mit-Ml; 7 Jul 82 17:13-EDT

The problem is fairly widespread.  There is an informal protocol for
NCP protocol to attack this problem but it isn't widely implemented.
A better solution exists in SMTP mail under TCP/IP, so it will go away
at that time.
-------


 7-Jul-82 15:06:58-PDT,788;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 1502-PDT
Date:  7 July 1982 12:22 edt
From:  Palter at Mit-Multics (Gary M. Palter)
Subject: MSGGROUP#1788  Re: NetMail Security Vulnerability Query
Sender:  Palter.Multics at Mit-Multics
To:  TMPLee.DODCSC at Mit-Multics
cc:  tcp-ip at BRL, MsgGroup at Mit-Ml, Postel at Usc-Isi, 
     Cerf at Usc-Isi
In-Reply-To:  Message of 7 July 1982 09:54 edt from TMPLee.DODCSC
Via:  Mit-Ml; 7 Jul 82 17:15-EDT

In SMTP (the mail protocol for TCP/IP), the receiving site must send a
connection established message.  The first word of this message (after
the 220 reply code) must be the name of the receiving system.  The
sending site would then discover that the receiving site isn't who it
thinks it is and can abort the delivery.


 7-Jul-82 16:02:02-PDT,630;000000000001
Mail-from: ARPANET site BRL rcvd at 7-Jul-82 1559-PDT
Date: 7 July 1982 18:21-EDT
From: Earl A Killian <EAK@Mit-Mc>
Subject: MSGGROUP#1789  NetMail Security Vulnerability Query
To: TMPLee.DODCSC at Mit-Multics
cc: MsgGroup at Mit-Ml, Admin.MRC at Su-Score, Cerf at Usc-Isi, 
    Postel at Usc-Isi, tcp-ip at BRL
Via:  Mit-Ml; 7 Jul 82 18:24-EDT

If you implement the XLBT FTP command in your site's FTP server
and use it in your mailer, then the loopback plug bug goes away
for everything that you mail, regardless of how many other sites
implement it.

I don't remember the RFC number describing XLBT.  Jon?



 8-Jul-82 05:22:12-PDT,646;000000000001
Mail-from: ARPANET site BRL rcvd at 8-Jul-82 0519-PDT
Date:  7 Jul 1982 1530-PDT
From: POSTEL at Usc-Isif
Subject: MSGGROUP#1790  re: Net Mail Security Vulnerability Query
To:   TMPLee.DODCSC at Mit-Multics
cc:   MsgGroup at Mit-Mc, TCP-IP at BRL
Via:  Mit-Mc; 7 Jul 82 19:00-EDT


Earl:

I never heard of "XLBT"! I am sure there was never an RFC about it.  Since
the new Mail procedures are coming with the NCP to TCP transition why fix
any of the old stuff?  Just get the new stuff up ASAP.  Since SMTP has the
current problem solved lets get going on using SMTP.  There is now an SMTP
server up on ISID.

--jon.
-------


 8-Jul-82 06:46:55-PDT,863;000000000001
Mail-from: ARPANET site BRL rcvd at 8-Jul-82 0644-PDT
Date: 8 July 1982 01:20-EDT
From: David A Moon <MOON@Mit-Mc>
Subject: MSGGROUP#1791  NetMail Security Vulnerability Query
To: TMPLee.DODCSC at Mit-Multics
cc: MsgGroup at Mit-Ml, Postel at Usc-Isi, Cerf at Usc-Isi, 
    tcp-ip at BRL
Via:  Mit-Ml; 8 Jul 82 9:00-EDT

The problem with network loopback plugs does not exist in TCP/IP,
since that protocol is not symmetrical the way NCP is.

This problem was fixed locally many years ago, through the XLBT ftp
command which enables verification of what machine an FTP (MAIL) server
is running on.  Any machine whose outgoing mailer and incoming mail server
both implement XLBT cannot be fooled into sending to itself.  I believe there
is an Arpanet RFC about this, although I don't know the number (or the author;
it may or may not be me).


 9-Jul-82 12:26:53-PDT,1940;000000000001
Mail-from: ARPANET site USC-ISIF rcvd at 9-Jul-82 1224-PDT
Return-path: Postel@ISIF
Date:  8 Jul 82 23:15:00 PDT
From:  Postel@USC-ISIF
Subject: MSGGROUP#1792  DRAFT Mail Specifications Available

Two DRAFT RFCs are now available from the Network Information Center in 
the NETINFO directory at SRI-NIC.

This very unusual step of providing these final draft specifications for
review is taken in light of the impact of changes to the computer mail
system on the community.  It is quite likely that these standards will
be used for some substantial time to come.

These documents have already been subject to review by a large number of
interested people.  They represent the consensus of a large number of 
contributors.

Comments on these documents may be directed to their authors 
(DCrocker@UDEL-RELAY and Postel@USC-ISIF).  The appropriate forum for a 
group discussion is MsgGroup (MSGGROUP@BRL).

MAIL FORMAT DRAFT

   Title:   Standard for the Format of  
            ARPA Internet Text Messages
   Author:  D. Crocker
   Pages :  46

      pathname: [SRI-NIC]<NETINFO>MAIL-FORMAT.DRAFT

   This is the final draft of the revised specification for the format 
   of text mail in the ARPA Internet.  This is a significant revision 
   and replacement of RFC 733.

MAIL PROTOCOL DRAFT

   Title:   Simple Mail Transfer Protocol
   Author: J. Postel
   Pages : 66

      pathname: [SRI-NIC]<NETINFO>MAIL-PROTOCOL.DRAFT

   This is the final draft of the revised specification of the protocol 
   for the transfer of mail in the ARPA Internet.  This is a revision 
   and replacement of RFC 788.

Public access files may be copied from the NETINFO directory at SRI-NIC 
via FTP with username ANONYMOUS and password GUEST.

Requests to be added to or deleted from this distribution list should be
sent to NIC@SRI-NIC.  Submissions for RFCs should be sent to 
POSTEL@ISIF.

--jon.

19-Jul-82 20:26:34-PDT,2369;000000000001
Mail-from: ARPANET site USC-ISIF rcvd at 19-Jul-82 2023-PDT
Return-path: Postel@ISIF
Date: 19 Jul 1982 1743-PDT
From: POSTEL at USC-ISIF
Subject: MSGGROUP#1793  RFCs 813-817 Now Available
To:   "Request-For-Comments.List":


New RFCs are now available from the Network Information Center in the 
NETINFO directory at SRI-NIC.

A group of five new RFCs by Dave Clark discuss various aspects of the 
Internet Protocol (IP) and Transmission Control Protocol (TCP) from an 
implementation view point.  These memos are especially aimed at those 
embarking on new implementations of these protocols, but will also be of
interest to others seeking more information about the intended workings 
of the protocols or their assumed implementation setting.

RFC 813:

   Title:   Window and Acknowledgement Strategy in TCP 
   Author:  D. Clark
   Pages :  22

      pathname: [SRI-NIC]<NETINFO>RFC813.TXT

   This memo describes implementation strategies for the flow control 
   mechanism of TCP.

RFC 814:

   Title:   Name, Addresses, Ports, and Routes 
   Author:  D. Clark
   Pages :  14

      pathname: [SRI-NIC]<NETINFO>RFC814.TXT

   This memo describes the relationship of various identifiers in TCP 
   and implementation techniques for keeping track of them.

RFC 815:

   Title:   IP Datagarm Reassembly Algorithms
   Author:  D. Clark
   Pages :  9

      pathname: [SRI-NIC]<NETINFO>RFC815.TXT

   This memo describes an alternative datagram fragment reasssembly 
   technique.

RFC 816:

   Title:   Fault Isolation and Recovery
   Author:  D. Clark
   Pages :  12

      pathname: [SRI-NIC]<NETINFO>RFC816.TXT

   This memo describes features that should be included in IP and TCP 
   implementations to aid in fault isolation and recovery.

RFC 817:

   Title:   Modularity and Efficiency in Protocol Implementation
   Author:  D. Clark
   Pages :  26

      pathname: [SRI-NIC]<NETINFO>RFC816.TXT

   This memo describes techniques to aid in developing efficient IP and 
   TCP implementations.

Public access files may be copied from the NETINFO directory at SRI-NIC 
via FTP with username ANONYMOUS and password GUEST.

Requests to be added to or deleted from this distribution list should be
sent to NIC@SRI-NIC.  Submissions for RFCs should be sent to 
POSTEL@ISIF.

--jon.

17-Aug-82 13:15:22-PDT,4735;000000000001
Mail-from: ARPANET site DARCOM-KA rcvd at 17-Aug-82 1314-PDT
Date: 15 Aug 1982 1404-PDT
From: MsgGroup Moderator - Stefferud <MsgGroup@Usc-Eclc>
Subject: MSGGROUP#1794  NJIT - Preliminary Announcement
To: msggroup.brl-bmd at BRL
Reply-To: MsgGroup.brl-bmd at BRL
Via:  Usc-Eclc; 16 Aug 82 15:19-EDT
Via:  Brl; 16 Aug 82 15:26-EDT
Via:  Brl-Bmd; 16 Aug 82 15:39-EDT

Date: 30 Jul 1982 1224-EDT
Subject: Preliminary Announcement
From: JMCKENDREE at BBNB
To: human-nets-request at MIT-AI
Cc: g.mdp at UTEXAS-20(Attn: Peeler), estefferud at USC-ECL
Message-ID: <[BBNB]30-Jul-82 12:24:37.JMCKENDREE>

I haven't seen a message for several weeks from either HUMAN-NETS or
MSGGROUP.  I suppose this is due to summer schedules and
shorthandedness while the list monitor is on vacation, or something of
the kind.  But I would like to see the following announcement shared
widely.

This is a preliminary announcement of the New Jersey Institute of
Technology Continuing Education Program.  It is of particular interest
because students will not be expected to attend class on campus but
will telecommute via a computer terminal.  A mail response to the
short form at the end of the announcement will assure a person's being
put on the mailing list for NJIT's course catalog with full
description of courses offered (both regular courses and these
computer-mediated seminars).

	
                  CONTINUING EDUCATION PARTICIPATORY SEMINARS
                                      via
                          COMPUTER TELECOMMUNICATIONS

A new kind of seminar taught on your schedule, in your home or at your
workplace, with teachers and experts from all over the country, and
with more personal involvement than any continuing education class you
have ever taken before is now being planned by the New Jersey
Institute of Technology.

These seminars will be taught through computer terminals or
microprocessors connected to a nationwide easy-to-use computerized
conferencing system.  Students will take part in on-line classes, ask
and answer questions, and communicate as often as they need to with
the instructor and other students.  They may do this at any hour of
the day, any day of the week that is convenient for them.

The New Jersey Institute of Technology is proud to introduce this
innovative program planned for 1983.  We expect to offer programs during
three semesters: spring, summer and fall.  More than 20 courses will be
offered in this program relevant to managerial, professional and
technical areas.

Among the topic areas planned are:

PROFESSIONAL WOMEN & THE WORKPLACE                COMPUTERS & SOCIETY
WHAT EVERY MANAGER SHOULD KNOW ABOUT ARBITRATION  THE DELPHI METHOD
MANAGERIAL WRITING                                CREATIVE WRITING
DECISION SUPPORT SYSTEMS                          LOCAL AREA NETWORKS
TECHNOLOGICAL FORECASTING                         COMPUTER LITERACY
MICROPROCESSORS                                   APPLE II PROGRAMMING
PASCAL PROGRAMMING                                TRS-80 PROGRAMMING
HUMAN COMMUNICATION VIA COMPUTER                  OFFICE AUTOMATION

In many subject areas advanced seminars as well as introductory or
survey seminars will be offered.  The catalog of seminars will be
available in November of 1982.  These three month seminars will be
offered for approximately $600 for enrollment in one course and less
than $1000 for two courses.  Special sessions and tailored courses can
be arranged for companies and organizations seeking "in house"
electronic seminars.  If you wish to receive the catalog or seek other
detailed information fill out the form below and return to the New
Jersey Institute of Technology at the address indicated.


REQUEST FOR FURTHER INFORMATION

List in order of preference the first four (4) seminars which are of
interest to you: (1)_________________________

(2)_________________________ (3)_________________________

(4)_________________________ Other preferences_________________________

Your Name____________________________

Title________________________________

Organization_________________________

Business Address_____________________ Home Address_________________________

City__________ State_____ ZIP________ City__________ State_____ ZIP________

Business Phone_______________________ Home Phone___________________________

Age Group (Optional-Please Circle)
20-25,26-30,31-35,36-40,41-45,46-50,51-55,56-60,61-65,65+

Please return entire page to New Jersey Institute of Technology,
Division of Continuing Education.  323 High St., Newark N.J., 07102.
Please pass duplicate copies to interested associates.


-------



16-Aug-82 04:24:47-PDT,1902;000000000001
Mail-from: ARPANET site USC-ISIF rcvd at 16-Aug-82 0419-PDT
Return-path: Postel@ISIF
Date: 15 Aug 82 11:22:33 PST
From: Postel at USC-ISIF
To: "Request-For-Comments.List":;
Subject: MSGGROUP#1795  New RFCs Available - RFC819, RFC821, RFC822
Subject: [SRI-NIC]<NETINFO>RFC819.TXT
Subject: [SRI-NIC]<NETINFO>RFC821.TXT
Subject: [SRI-NIC]<NETINFO>RFC822.TXT

New RFCs are now available from the Network Information Center in the 
NETINFO directory at SRI-NIC.

These are very important new specifications for computer mail procedures
and formats.  It is expected that all mail transmitted in the ARPA 
Internet will conform to these new standards.  A transition period will 
allow an evolution from the current mail practices to these new 
standards. It is expected that the transitions will be completed between
two and four months from now.

RFC 819:

   Title:   The Domain Naming Convention for Internet User Applications 
   Author:  Z. Su and J. Postel
   Pages :  18

      pathname: [SRI-NIC]<NETINFO>RFC819.TXT

   This memo describes the domain naming concept in the context of 
   computer mail and other applications.

RFC 821:

   Title:   Simple Mail Transfer Protocol 
   Author:  J. Postel
   Pages :  68

      pathname: [SRI-NIC]<NETINFO>RFC821.TXT

   This memo specifies the mail protocol.  This replaces RFC 788.

RFC 822:

   Title:   Standard for the Format of ARPA Internet Text Messages
   Author:  D. Crocker
   Pages :  47

      pathname: [SRI-NIC]<NETINFO>RFC822.TXT

   This memo specifies the mail format.  This replaces RFC 733.

Public access files may be copied from the NETINFO directory at SRI-NIC 
via FTP with username ANONYMOUS and password GUEST.

Requests to be added to or deleted from this distribution list should be
sent to NIC@SRI-NIC.  Submissions for RFCs should be sent to 
POSTEL@ISIF.

--jon.

17-Aug-82 13:15:21-PDT,696;000000000001
Mail-from: ARPANET site DARCOM-KA rcvd at 17-Aug-82 1314-PDT
Date: 17 Aug 1982 0751-EDT
Sender: JMCKENDREE at Bbnb
Subject: MSGGROUP#1796  Re: #1794  NJIT - Preliminary Announcement
From: JMCKENDREE at Bbnb
To: MsgGroup.brl-bmd at BRL
Message-ID: <[BBNB]17-Aug-82 07:51:33.JMCKENDREE>
In-Reply-To: Your message of 15 Aug 1982 1404-PDT
Via:  Bbnb; 17 Aug 82 7:54-EDT
Via:  Brl; 17 Aug 82 7:58-EDT
Via:  Brl-Bmd; 17 Aug 82 8:09-EDT

Thanks for taking the time to place my preliminary announcement
of computer-based seminars at NJIT into the MSGGROUP lists.  You
are not Einar Stefferud, though.  Will you be the person to whom
future messages to MSGGROUP should be addressed?



17-Aug-82 13:15:21-PDT,4034;000000000001
Mail-from: ARPANET site DARCOM-KA rcvd at 17-Aug-82 1313-PDT
Date: 17 Aug 1982 1150-PDT
Sender: STEF at Darcom-Ka
Subject: MSGGROUP#1797  Re: #1794  NJIT - Preliminary Announcement
From: Einar Stefferud <MsgGroup@Usc-Eclc>
Reply-To: MsgGroup at BRL
To: JMCKENDREE at Bbnb
Cc: MsgGroup.brl at BRL
Message-ID: <[DARCOM-KA]17-Aug-82 11:50:05.STEF>
In-Reply-To: <[BBNB]17-Aug-82 07:51:33.JMCKENDREE>
Via:  Darcom-Ka; 17 Aug 82 15:03-EDT
Via:  Brl-Bmd; 17 Aug 82 15:38-EDT

Hi Jack -- Perhaps I should explain a bit about what is going on here,
since it may not be obvious, even to the more experienced MsgGroupers.
There have been a number of changes, and at least one glitch has arisen.

In June of this year, I moved the "Archive Base" of MsgGroup from
[ecl]<msggroup> to [eclc]<msggroup>.  This is the transcript of all past
Msggroup discussions are kept in ARPANET FTP accessible files, in TWENEX
MSG file format.  As discussion proceeds, each group message reaching
the [ecl]<msggroup> archives is processed to insert an accession number
and filed in Chronologic order, with 100 messages per file.  We are now
nearing the end of the 17th file with this message.

File names are:  [ECLC]<MSGGROUP>MSGGROUP.nnnn-mmmm.

       Example:  MSGGROUP.1701-1800

Surveys of the transcript files are also available in text files with
corresponding names:

       Example:  SURVEY.1701-1800

I also have kept [ecl]<msggroup> active as a public access directory,
and it holds the most recent 100 - 200 MsgGroup discussion messages.

So much for the archiving operation.

In July of this year, the "RELAY" address for group mail was changed
from MsgGroup@MIT-ML to be MsgGroup@BRL.  The old relay address still
works, because it automatically relays to the BRL address, which is turn
broadcasts it to the group.  A copy is automatically placed in
MsgGroup@ECLC because this address is included in the broadcast list.

You should note that sending a single copy of a contribution to
MsgGroup@ECLC will only place it in the archive repository, from which I
will have to remail it to the group.  Or you can mail a single to copy
to me at one of my many mailboxes, and I will eventually find it and
remail it if it is properly distributable, as your NJIT message was.

Now for the glitch, which caused me to use the very strange looking
MsgGroup.BRL@BRL-BMD address.  It seems that there is a time out
interaction between the ECLC TOPS-20 XMAILR and the BRL UNIX MMDF mail
servers, which prevents sending mail from any TOPS-20 using XMAILR, to
MsgGroup@BRL.  XMAILR likes to quit on a fairly short timeout, which is
adequate in most all cases.  But, at BRL, MMDF likes to veriify the
entire expansion list [216 addresses for MsgGroup] before giving XMAILR
the go-ahead.  It turns out that XMAILR gives up before MMDF completes
verification of the list.

This has all the neat results of your typical deadly embrace.  TOPS-20
XMAILR tries every now and then to deliver the mail to MMDF, for several
days, but of course it will never succeeed .  I think all this is done in
the interests of efficiency, but that is another discussion.

Anyway, my solution is to use "source.routing" address capabilities to
insert an intermediate relay into the path, in order to get another
MMDF on another host, which does not stop to check out the whole MsgGroup
list, to hand it over to MsgGroup@BRL.  MMDF is more tolerant of itself,
and does not thus timeout.  So, Voila, the mail goes through, with only
one extra step in the path.  Very efficiant, I would say!

I expect that you could also send your mail from TOPS-20 XMAILR systems
to MsgGroup@MIT-ML, and it would not then be inhibited by this timeout
interaction problem.

And, one more note:  To contact me with regard to administrative
MsgGroup affairs, you can send mail to the more or less standard
"MsgGroup-Request@BRL" which will be relayed to me.  The same goes for
MsgGroup-Request@MIT-ML, etc.


Enjoy!  Stef


18-Aug-82 01:36:39-PDT,8467;000000000001
Mail-from: ARPANET site SU-SCORE rcvd at 17-Aug-82 1740-PDT
Date: 17 Aug 1982 1741-PDT
From: Mark Crispin
Subject: MSGGROUP#1798  Re: [Einar Stefferud: Re: MSGGROUP#1794  NJ...]
Sender: ADMIN.MRC at SU-SCORE
To: CERF at USC-ISI
cc: postel at USC-ISIF, MsgGroup at USC-ECLC
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 17-Aug-82 1539-PDT
Remailed-date: 18 Aug 1982 0136-PDT
Remailed-from: MsgGroup Moderator - Stefferud <MsgGroup at USC-ECLC>
Remailed-to: msggroup.brl at BRL-BMD

Vint -

     I read Stef's message to MsgGroup with some interest and
concern.  It is neither a glitch nor a religious argument.  It is
something worse, and I would certainly entertain hearing from
anybody who thinks he or she has a suggestion.

     XMAILR does have timeouts.  The timeouts have been made
somewhat more intelligent.  Instead of requiring a message to go
through within a certain timeout period, XMAILR instead requires
a certain minimum datarate.  1000 bytes per minute sticks in my
head (about 17 baud) as being the minimum datarate XMAILR will
tolerate.  There are also other timeouts; for example, a host
which does not support XRCP (multiple recepients in the NCP mail
environment) and has 500 recepients of a 10kbyte message could
tie up XMAILR for quite a while.  When XMAILR discovers this is
happening (I forget the timeout), it requeues the message for the
remaining recepients so that other queued mail will get
processed.

     It's pretty obvious that the purpose of these timeouts is
disaster avoidance.  Mail receipt at less than 16 baud is
certainly unacceptable and the receiver should be fixed.
Similarly, it is silly for the mail delivery process to spend
hours on a single mass mailing request without "taking a break"
to process the other queued mail.

     Other disaster avoidance timeouts have to do with how long
it takes the mail receiver to respond.  On many hosts, it is
quite possible for the mail receiver to crash without any
indication to the mail delivery process that anything happened.
The only symptom is catatonia.  One favorite way of lossage on
TOPS-20 systems that still use the old FTSCTL program is that
there is no FTP server on the link; if you send a ^C down an EXEC
will appear!

     The penalty for failing to impose some form of timeout on
various response waits is having the mail delivery process hang
forever.  XMAILR's timeouts were picked to be very generous;
although now we have encountered some cases where the timeouts
can be legitimately exceeded.  We fixed the very large message
bug by having the timeout enforce a datarate instead of a fixed
limit no matter how large the message was.

     What should be done?  I don't know.  Suppose a single XMAILR
process is the only mail delivery process on the system, even for
local mail.  If ARPA believes that it is reasonable for a mail
delivery process to wait two hours for a SMTP/FTP greeting, or a
response to an address, etc. then every time XMAILR encounters a
real hung mail receiver there will be NO mail delivery to
anywhere for two hours!

     The old Tenex software made only indifferent attempts to
protect itself from losing this way.  Users quickly got in the
habit of running MAILER themselves, or using SNDMSG and watching
while the mail was being delivered.  System programmers would
periodically check up on MAILER and kill/restart it when it got
hung.  A substantial part of XMAILR's philsophy was that a site
shouldn't have to have users running the mailer themselves or 24
hour system programmer coverage to have reliable and expedient
mail service.

     I don't know what the answer is.  My ethics as a programmer
rebel against having software require a systems programmer or
operator to continually track its performance.  If I impose time
limits, then somebody, somewhere, will be able to come up with a
case where my time limits will be reliably exceeded no matter how
generous I make them.  The ultimate timeout is the system's PM
shutdown schedule!

		***** BEGIN FLAMING *****

     Speaking personally and not necessarily tactfully, I feel
that the bug is at BRL.  I believe XMAILR waits 5 minutes for a
greeting and/or an address acceptance.  That is long enough.  If
the BRL mail receiver insists upon validating the address before
accepting mail for it, it should validate as soon as it observes
that "MsgGroup" is in its database of expansion lists.  It is
totally idiotic for the BRL mail receiver to validate the
expansion!  Why is it that software on other systems is expected
to compensate for some system's idiotic behavior?  There are a
lot of bright people in UNIX-land, but it seems that every time I
turn around some UNIX system or other is expecting TOPS-20
software to change to compensate for some bug or misfeature in
UNIX because UNIX "can't be changed."  Isn't it strange that an
assembly-code operating system/utilities can be changed, while a
high-level language (C) coded operating system/utilties can't be?

     Leaving that aside (while the death threats from UNIX sites
all over the network come in), I have never felt that validating
an address at the mail receiver was a good idea.  In some cases,
e.g. relays, such validation becomes difficult, if not
impractical or even impossible.  The worst part, however, is that
such validation has the significant potential to substantially
impair mail transport throughput.

     People believe that mail receiver mailbox validation is a
service rendered to the mail delivery process.  If so it can be
an expensive service.  The mail delivery process has to wait
while the validation is being performed.  Who knows who or what
may be waiting on the mail delivery process?

     Mail receiver validation is also an inessential luxury.
Unless the mail receiver is in itself a mail delivery process,
the mail receiver will be passing the message on to a mail
delivery process.  And that mail delivery process will itself
have to validate the addresses all over again, if only by
attempting to deliver the mail!  And, since there can be skews
between the validation done by the mail receiver and the mail
delivery validation, the mail delivery process has to have some
sort of "return to sender" or error report option to let the
sender know there was a failure!

     Mail receiver validation merely gives a false sense of
security.  It is also flawed that a "soft" delivery failure such
as "user's mailbox quota exceeded, try again later after she's
cleaned out her mailbox" is much harder for a remote mail
delivery process to comprehend than a local one.  Either the mail
receiver validation will ignore this error, or it will reject it
and hope the mail delivery process at the sending end will
somehow comprehend that this is not a "no such mailbox" error.

     Stef's hack of using "MsgGroup.BRL@BRL-BMD" is, at a user's
point of view, a way of implementing the "no mail receiver
validation" model.  BRL-BMD knows it can't validate the address
because it's foreign, so it doesn't try.  Because it responds
"give me the message" with reasonable dispatch, XMAILR can
deliver the traffic to it.  BRL-BMD evidentally doesn't care how
long it takes for traffic to go from BRL-BMD to BRL.  Maybe they
reload the system if the mailer is stuck (don't laugh, some sites
do just that!).  BRL-BMD acts as the mail receiver, while the
mail delivery process between BRL-BMD and BRL is the mail queuer
in my model to the mail delivery process at BRL.

     I'll end my flaming here.  I don't know if I've convinced
anybody or not.  I AM willing to make changes as necesary, but I
feel it is unfair to consider only the needs of a single site or
operating system.  In particular, I feel it is wrong to sabotage
electronic mail to hundreds of systems to make it work better for
one.  Some thought as well needs to be given to performance and
throughput.  The old "performance be damned" attitude just
doesn't hold water any more.  Users are going to get upset when
their mail takes three days to deliver and will become even more
upset when they find out why.

-- Mark --

PS: XMAILR's timeouts can be altered by a site running it.  I do
distribute the source.
-------
18-Aug-82 03:11:29-PDT,1411;000000000001
Mail-from: ARPANET site BRL rcvd at 18-Aug-82 0310-PDT
Date: 18 Aug 1982 0232-PDT
Sender: STEF at Darcom-Ka
Subject: MSGGROUP#1799  Re: [Einar Stefferud: Re: #1794 ...
From: STEF at Darcom-Ka
Reply-To: MsgGroup.BRL at Brl-Bmd
To: Admin.MRC at Su-Score
Cc: MsgGroup at BRL
Message-ID: <[DARCOM-KA]18-Aug-82 02:32:56.STEF>
In-Reply-To: Your message of 17 Aug 1982 1741-PDT
Via:  Darcom-Ka; 18 Aug 82 5:36-EDT

Hi Mark - I did not intend to so strongly suggest that XMAILR is the
sole source of the problem, or suggest that only XMAILR should be
changed to accomodate MMDF in spite of its idiosyncracies.

Please accept my apologies for striking so close to the heart of XMAILR.

Actually, I am told by Doug Kingston, who is the postmaster at BRL, that
a new version of MMDF will indeed handle lists more intelligently, and
will avoid this specific timeout problem.  He also asked that we bear
with the current situation by using the MsgGroup.BRL@BRL-BMD ploy until
he can get it fixed.

I hope this information will help to allay your fears that we have no
sympathy for your postions on these issues.  I appreciate your
thoughtful recapitulation of the whole thing about timeouts.

At this point, it is not clear to me that we need do more than keep on
tuning things as conflicts among our autonomous distributed processes
arise in the future, as surely they will.

Best - Stef

18-Aug-82 12:52:45-PDT,2193;000000000001
Mail-from: ARPANET site USC-ISI rcvd at 18-Aug-82 0648-PDT
Date: 18 Aug 1982 0636-PDT
Sender: CERF at USC-ISI
Subject: MSGGROUP#1800  Re: #1794 ... #1799
From: CERF at USC-ISI
To: Admin.MRC at SU-SCORE
Cc: postel at USC-ISIF, MsgGroup at USC-ECLC
Message-ID: <[USC-ISI]18-Aug-82 06:36:24.CERF>
In-Reply-To: Your message of 17 Aug 1982 1741-PDT
Remailed-date: 18 Aug 1982 1252-PDT
Remailed-from: MsgGroup Moderator - Stefferud <MsgGroup at USC-ECLC>
Remailed-to: msggroup.brl at BRL-BMD

Mark,

I am very sympathetic to several points you make. First, performance is
indeed important. SEcond, we should not have to rely on people
monitoring the mail system to make it work - although I would like to
point out that we do have people monitoring computer complexes and
network operations centers - so it is just barely conceivable that one
might want to find ways to monitor and alarm problems arising in the
electronic mail distribution system. But in principle, I agree that we
should be able to operate the system as a collection of autonomous,
cooperating programs.

I am puzzled by the BRL/UNIX address validation procedure. Could someone
enlighten me as to the type of checking which is occurring? Is it done
on all addresses, regardless of whether the receiver is forwarding on or
receiving locally (Mark's forwarding versus delivery distinction)?  What
is involved in this validation and why does it take so long?

Timeouts in higher level software are needed but dangerous in a
networking environment which has variable service - dangerous in the
sense that absolute timeouts are hard to select. The datarate limits
that Mark mentions (17 baud) seem generous to a fault. In fact, it does
seem attractive to me to consider monitoring such datarate experiences
and reporting this information to some central place (using the BBN Host
MOnitoring Protocol? IEN 197) so we can begin to collect some statistics
about performance of the electronic mail system.

Jack Haverty's questions about running multiple servers seemed a good
one. What problems arise if one attempts to run more than one instance
of a mail receiver or mail sender?

Vint Cerf