Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!MRC@SU-SCORE.ARPA
From: MRC@SU-SCORE.ARPA (Mark Crispin)
Newsgroups: net.mail.headers
Subject: Re:  user-editable mail headers
Message-ID: <764@hou3c.UUCP>
Date: Sun, 19-Aug-84 13:46:52 EDT
Article-I.D.: hou3c.764
Posted: Sun Aug 19 13:46:52 1984
Date-Received: Tue, 21-Aug-84 00:36:33 EDT
Sender: ka@hou3c.UUCP (Kenneth Almquist)
Lines: 33
To: steve@BRL-BMD.ARPA
Cc: header-people@MIT-MC.ARPA
In-Reply-To: Message from "Stephen Wolff " of Sat 18 Aug 84 19:18:24-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

The TOPS-20 MM mailsystem allows editing the From: line of a message.
This is to support some of the hairier aspects of office automation;
e.g. models where some other person (e.g. a secretary) sends mail for
another.  MM also has the capability to be run in a mode where you
can "become" another user for reading/sending mail, but this needs
access to that user's directory (MM will ask for the user's password
if necessary to obtain that access).

The security problems with forged mail are there to be sure, BUT...
unlike TOPS-10 or Unix, programs on TOPS-20 NEVER run with "temporary"
privileges.  It is therefore impossible to enforce any security at the
level of a program run by users, because any security enforcement done
by such a program can be evaded simply by building one's private copy
of the program without the check.  Even leaving aside the issue of a
patched copy of the program, you must also consider the possibility of
other message composition programs being developed to run concurrantly
on the same system; whether to evade the security check or simply to
experiment with alternative interfaces.

That leaves security enforcement to a privileged agent, that is, the
mailer.  The problem here is that at the present time the TOPS-20
mailer doesn't have the slightest idea what RFC 822 is.  It doesn't
deal at that level; it deals with SMTP.  When RFC 1234 comes out that
completely changes the standards, not only would the message composition
program require changing but also the mailer.  Ugh.

Personally, I believe that security against forged mail is a fantasy.
The best you can do is validate that a message clearly came from such-
and-such a host, or for locally-originated mail, that a message was
composed by a certain user (provided your operating system supports a
"file author" word that unprivileged users can't modify).  In TOPS-20,
this is done via Received: and Mail-From: lines.
-------