Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!Michael.Young@cmu-cs-g From: Michael.Young%cmu-cs-g@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: Mail security Message-ID: <2029@sri-arpa.UUCP> Date: Fri, 10-Jun-83 16:01:40 EDT Article-I.D.: sri-arpa.2029 Posted: Fri Jun 10 16:01:40 1983 Date-Received: Sun, 12-Jun-83 18:28:44 EDT Lines: 50 When I was hacking for the MMDF project (part of the CSNet effort at U of Delaware EE Dept.), I ran into a fairly novel idea for writing to files/pipes/etc. Here goes: When mail is about to be delivered to a given address (user), an attempt is made to find a delivery program. [It should be pointed out that the setuid (receiver) has already been done.] First, the recipient's home directory is searched for a mail-receiving program. [If you don't like the security aspects here, require some special action to "install" a mail-receiving program, and of course assert that the receiver owns it.] If this isn't found, a default delivery program is fired up which writes your mail file. [If you like, you could add other searches for delivery programs, but it's not that necessary.] Some example activities of users' delivery programs are: 1) forwarding to a new address, and/or informing the sender of a temporary or permanent absence, 2) writing a special file, perhaps according to the contents of some header line (like "subject" or "x-filename" or whatever), 3) executing a program of one's choice. [This is what I worked on last summer -- a protected remote execution environment.] 4) Reformatting incoming mail or chopping out useless information, (perhaps the whole thing!) 5) Archiving mail, in case you accidentally delete it later, 6) Adding to bulletin boards or similar message files. The possiblities are endless. Since it's the recipient running it, he can't complain. No system administrator is required to change forwarding address, etc. If you want to allow really wierd things to happen, you could even let the recipient's program get setuid/gid to someone else. Some of the common capabilities could be offered by system programs, which users could link (symbolically, even) to, in case you're worried about zillions of disk blocks being wasted, or "insecure" copies of these things floating around. The only real disadvantage I can see is that incoming mail can end up using lots of cpu time, but even this can be limited. I don't think anyone has adequately dealt with the junk-mail problem anyway, so it wouldn't get me down yet. What do you think of this strategy? I don't see any major holes in it, and it sure was convenient (and fun to hack on, but that's not the object). It seems that making the recipient fully responsible for his mail is only reasonable, and safe. Michael