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. -------