clive@druhi.UUCP (02/21/87)
Really. Isn't this the usual acolytes circling like moths around the flame of the eternal Operating System (and utilities-that-come-attached-to-it)? It's very simple. Of course there could be an 'unmail' command. It would work (in the user's view) like 'cancel' does in netnews. Go out and remove the most recent mailing (if any) from the unmailer, in the receiver's /usr/mail spoolfile. A good implementation would send the removal back, so the unmailer could be sure he got the right one. This seems stupendously easy. All of us, yes, even the initiated, could use it at times. I cross-posted this to wizards, so we can be sure to hear whether there's something inherantly unsanitary about this. Maybe, someone who can put it in distributions, will be interested in providing the feature.... Free Fame. And you get to be the one to decide if it's just an option on the mail command line, like -r.... Your very own user interface.
trent@cit-vax.UUCP (02/22/87)
In article <1690@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >Isn't this the usual acolytes circling like moths around the flame of the >eternal Operating System (and utilities-that-come-attached-to-it)? Actually, it's quite the opposite. (see below) >Go out and remove the most recent mailing (if any) from the unmailer, >in the receiver's /usr/mail spoolfile. A good implementation would send >the removal back, so the unmailer could be sure he got the right one. ARRGGHH! So...you propose to make the mail system *totally* unsecure instead of mostly unsecure? I personally think security sucks, but with mail there is a certain question of privacy. The only reason news's 'cancel' is relatively secure is that very few people know the fairly arcane protocols. If you know them, you can cancel *anybody's* news articles, and post them in *anybody's* name. You can already do the latter with mail, would you like for everybody to be able to do the former as well? I, personally, would prefer that no one be able to affect or read my mail unless they have my password or are root. (it'd be nice if root couldn't, but I can't think of anyway to prevent it) Tell me, how do you prevent someone from simply coming in and 'canceling' someone else's mail, reading the return copy, and resending it? That is, unless you want to rewrite mail to pass along a password or something. (what a hassle, mail's hard enough for novices to use without forcing this kind of shit on them) (and, besides, novices are the ones most likely to screw up) (and, besides, what password do you think novices are going to use? (hint: their login password) Do you think it's a good idea to be broadcasting this to the world?) Look, with U.S. Mail, once your letter leaves your mailbox, or is inserted into a drop box, there is absolutely *no* way to recall it. (legally) The only difference with email is that the postman comes by and empties your mailbox within minutes if not seconds. If you're really paranoid, use the suggestion to send your mail with at(1). The reason that this is the opposite of the acolyte circling the flame problem is: the way mail is implemented now, anyone can write their own mail interface and be relatively assured that they will be able to use it. If you rewrite the protocols to e.g. require passwords for system to system connections, then only acolytes will be able to use the system. -- "Party until it hurts; then, party 'til it don't hurt no more." ../ray\.. (trent@csvax.caltech.edu, rat@caltech.bitnet, ...seismo!cit-vax!trent)
chris@mimsy.UUCP (02/23/87)
In article <1690@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >Of course there could be an 'unmail' command. Certainly. >It would work (in the user's view) like 'cancel' does in netnews. Indubitably. >This seems stupendously easy. Not so---unless, like Usenet, just about anyone, anywhere, could cancel your mail. Making sent mail secure, even across something like the ARPAnet, where physical security is inforced by DARPA, is quite difficult. (It is not now entirely secure: All one can truly tell is that mail `from user@site.edu' came from `site.edu', unless marked otherwise. Not all implementations provide even this much security.) Making revoked mail reasonably secure is even worse. But not impossible. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
clive@druhi.UUCP (02/24/87)
in article <1850@cit-vax.Caltech.Edu>, trent@cit-vax.Caltech.Edu (Ray Trent) says: [...] > Tell me, how do you prevent someone from simply coming in and 'canceling' > someone else's mail, reading the return copy, and resending it? That is, > unless you want to rewrite mail to pass along a password or something. [...] Well, I think you certainly have a point worth looking into, Ray. Let's consider. On a given machine, there will be only one user with a given (usable->first in /etc/passwd) userid. And no (non-root) way to fake one. Also, mail headers contain this information, in the path from which the mail came. Further, we already have server access control, in the current way mail works. It seems to me then, that a simple addition to the server can easily and securely know which pieces of mail, if any, a given (local or remote) requester deserves to cancel. And that no one can beat this, unless they have root (or mail) privileges, and furthermore, on the recipient's machine. It's late, so maybe I'm wrong. What do you think? Clive
josh@hi.UUCP (02/25/87)
In article <1712@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >in article <1850@cit-vax.Caltech.Edu>, trent@cit-vax.Caltech.Edu (Ray Trent) says: >[...] >> Tell me, how do you prevent someone from simply coming in and 'canceling' >> someone else's mail, reading the return copy, and resending it? That is, >> unless you want to rewrite mail to pass along a password or something. >[...] > >Well, I think you certainly have a point worth looking into, Ray. > >Let's consider. On a given machine, there will be only one user with a >given (usable->first in /etc/passwd) userid. And no (non-root) way to >fake one. > >Also, mail headers contain this information, in the path from which the >mail came. > >Further, we already have server access control, in the current way >mail works. > >It seems to me then, that a simple addition to the server can >easily and securely know which pieces of mail, if any, a given >(local or remote) requester deserves to cancel. > >And that no one can beat this, unless they have root (or mail) >privileges, and furthermore, on the recipient's machine. > >It's late, so maybe I'm wrong. What do you think? > > >Clive Well, again... Let's consider. The unpost could be made secure over a ethernet by using a set of rcmd (like rlogin) so that a root on one machine cannot kill any mail sent from a user on a different machine. On the other hand I still can kill any mail sent from the machine I have root on to any other machine. Or is the restriction true at all about the fact that root on one machine cannot remove mail from another machine? How 'bout the following? Person X as a PC. Person Y has a sun. X is system manager on system Z. X see's Y using root to break into other machines and sends mail to the "authorities" on machine W and then goes to lunch (after turning off the PC). Y then waits for the arp table on W to clear the entry for X's PC. THEN, changes his name to the name X's PC uses and clears the letter X sent to the "authorities". He then changes it back to his own name. This gives him time to erase some of the evidence against him. I know this is a bad example because X would walk over to the "authorities" after lunch to see what they thought but it gets the point across. X could also be a sun and Y on a PC since I have been told (but have not seen it done) that it is not to hard to bring down a machine over the ethernet without root. Also, what if the letter goes over UUCP. Now it is easy. If I also talk to the machine via UUCP then I can just change my name, log in to my own account via UUCP and cancel his mail. In all... I think the whole system could be made almost secure but I would not like a clever hacker blowing away my mail. How do I "unpost"? I 'su' and vi(1) his mail file! :-) --Josh Siegel josh@hi.unm@hc.dspo.gov
trent@cit-vax.UUCP (02/25/87)
In article <1712@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >[...] > >Let's consider. On a given machine, there will be only one user with a >given (usable->first in /etc/passwd) userid. And no (non-root) way to >fake one. I'm not sure I know what you are talking about here. I assume you mean that the sender has a passwd on the sending machine. Common practice (and common sense) says that if you are concerned with security on your machine, you don't give out this information to the world. (encrypted or not, there are algorithms that work pretty well to "decode" passwds given lots of CPU time) >Also, mail headers contain this information, in the path from which the >mail came. Again, I'm confused about what you mean. Are you saying that mail headers contain the senders (encrypted) passwd? Guess again. Also, mail headers are among the easiest things for the sender to fake. >Further, we already have server access control, in the current way >mail works. Once again, what do you mean by this? None of the mail servers I've ever hacked on have server access control beyond requiring the accessor be able to connect server's machine. Nor do you really want them to, unless you want to disallow personal mail processing systems. >It seems to me then, that a simple addition to the server can >easily and securely know which pieces of mail, if any, a given >(local or remote) requester deserves to cancel. How does this follow? What is the server supposed to do, ask the machine it's connected to to send part of its /etc/passwd file? Also, what's to prevent people from cancelling mail on the local machine. (to which they have access to /etc/passwd themselves, without having to call up the mail server on the target machine and convince it to send out the passwd of the person who's mail the muncher wants to cancel? :-) >And that no one can beat this, unless they have root (or mail) >privileges, and furthermore, on the recipient's machine. Huh? How does this follow? Ummm, I'm willing to bet that I can find flaws, security leaks, or gross inconveniences in any sytem you can specify for recalling mail. (worse than the current mail system, that is!) Remember, one of the greatest conveniences of the way mail is now is that *any* user can write and use their own mail sending and reading programs without having privileges. (except on fascistly administrated machines) >It's late, so maybe I'm wrong. What do you think? I think you're right about that, at least. :-) ;-) -- "Party until it hurts; then, party 'til it don't hurt no more." ../ray\.. (trent@csvax.caltech.edu, rat@caltech.bitnet, ...seismo!cit-vax!trent)