Mail security

[Michael.Young%cmu-cs-g at sri-unix.UUCP]

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