lien@osu-eddie.UUCP (02/15/87)
From: Yao-Nan Lien <lien> It seems to me that a user has no way to withdraw a mail before it is read or forward to othernet. This may be as bad as 'rm *'. I just sent a mail to wrong addressees that makes my face red. Even system people can't help me since they can't do it without reading addressee's mailbox in /usr/spool/mail. Are there anybody on the net having any solution for users or super users? Yao-Nan Lien
henry@garp.UUCP (02/15/87)
lien@osu-eddie.UUCP wrote:
->It seems to me that a user has no way to withdraw a mail before
->it is read or forward to othernet.
->
-> ......
->
->Are there anybody on the net having any solution for users or
->super users?
The solution is for the user (that means you) to be careful. Most of
the mail programs I know about give the user a chance to look over the
message and header before it gets sent out (even Berkeley mail lets
you do this).
If you find this disturbing, compare electronic mail to its "analog"
counterpart--the US Mails. How often can you trot down to your local
post office and say "I've dropped a letter in a box at Marlboro and
Mass Ave but it has the wrong address on it and I want it back,
please?"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Henry Mensch <henry@garp.mit.edu>
{ames,cca,rochester,mit-eddie}!garp!henrybadri@ur-valhalla.UUCP (02/15/87)
In article <716@mit-amt.MEDIA.MIT.EDU> henry@garp.UUCP (Henry Mensch) writes: >lien@osu-eddie.UUCP wrote: >->It seems to me that a user has no way to withdraw a mail before >->it is read or forward to othernet. >-> >The solution is for the user (that means you) to be careful. Most of >the mail programs I know about give the user a chance to look over the >message and header before it gets sent out (even Berkeley mail lets >you do this). > If you have Rick Adams' uucp installed and the mail is going out over uucp, there is a way of deleting mail. A utility named uuq works very well. However I agree with Henry; a user has just got to be more careful while posting mail. There is always some point from which there is no way to retract a message and if a user thinks twice before hitting ^D it will be good for all. Badri Lokanathan -- "Don't blame me for wanting more {) ur-valhalla!badri@rochester.arpa The facts are too hard to ignore //\\ {ames,caip,cmcl2,columbia,cornell, I'm scared to death of poverty ///\\\ harvard,ll-xn,rutgers,seismo, I only want what's best for me."-UB40 /\ topaz}!rochester!ur-valhalla!badri
lien@osu-eddie.UUCP (02/16/87)
>> users should be careful
Yes, it is true that users should be careful. Normally, it will
not cause any problem. The mistake I made is on the following
occasion that I think many people may make the same mistake:
I was discussing something with some of my friends using E-mail.
After several iteration of roud trip mails, one of the mails was
addressed not only us, but also corbon copied to others.
I didn't notice it and used 'r' as usual to reply the mail.
I was not careful enough. But, I know it is hard for me to keep
cool during a hot discussion using a poor terminal through
a noicy telphone line.
In many cases, such mistakes may be more serious than 'rm *'.
I really hope that a user can withdraw the mails he send such
that such mistakes can be cured just like undo in 'vi' or
backup in file systems.
It is difficult to rely on super users since they may not be always
available and they may be too busy to do it.
-- Yao-Nan Lien
--
------------------------------------------------------------
Yao-Nan Lien
Department of Computer and Information Science
Ohio State University
2036, Neil Ave. Mall
Columbus, Ohio 43210-1277
Tel 614 292-5236
CSNet : lien@ohio-state.CSNET
Arpa : lien@ohio-state.arpa
UUCP : {cbosgd, ihnp4}!osu-eddie!lienguy@gorodish.UUCP (02/17/87)
>I really hope that a user can withdraw the mails he send such >that such mistakes can be cured just like undo in 'vi' or >backup in file systems. Well, "undo" in "vi" doesn't go back to the beginning of your session (and definitely doesn't undo the changes made in a previous editing session!), and backup tapes don't hang around forever. Eventually the mail message gets dumped in the recipient's mailbox, and at that point it's just too late. (Even if there were a way to withdraw a mail message from a mailbox, it doesn't do much good if they've already read it.) Mail is very often not queued up for a very long time; mail sent from my workstation usually makes it to the next hop along the way very quickly. Unless the mail routing machine here is loaded, it usually makes it to its final destination pretty quickly. The window in which it would be possible to remove the message from the queue is just too small to make it worthwhile to provide the ability to do so.
ssl@ptsfa.UUCP (02/18/87)
In article <3134@osu-eddie.UUCP> lien@osu-eddie.UUCP (Yao-Nan Lien) writes: >I didn't notice it and used 'r' as usual to reply the mail. Next time, try 'R' instead of 'r'. With the current MAIL setup, there nothing one can do except to see that it's a good lesson to learn from. :-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sam Lok San Francisco {ihnp4,pyramid,qantel}!ptsfa!ssl || To err is human, to really foul things Disclaimer!? WHAT disclaimer? || up requires super-user privilege!
lien@osu-eddie.UUCP (02/18/87)
> It is sent to the destination quickly
There may have no way to withdraw it once it arrives
/usr/spool/mail/name/xxx in current UNIX implementation.
How about a modification in BSD4.x such that the files in
/usr/spool/mail/receiver can also be writable by sender.
By doing this, it may not be too late before it is readed.
This is the point that US mail beat E-mail:
One can alway withdraw a mail from one's own mailbox before
mailman comes. This is usually one night and one morning
( may be one long weekend ).
Yao-Nan Lien
--
------------------------------------------------------------
Yao-Nan Lien
Department of Computer and Information Science
Ohio State University
2036, Neil Ave. Mall
Columbus, Ohio 43210-1277
Tel 614 292-5236
CSNet : lien@ohio-state.CSNET
Arpa : lien@ohio-state.arpa
UUCP : {cbosgd, ihnp4}!osu-eddie!lienecl@mtgzy.UUCP (02/18/87)
In article <3144@osu-eddie.UUCP>, lien@osu-eddie.UUCP writes: > This is the point that US mail beat E-mail: > > One can alway withdraw a mail from one's own mailbox before > mailman comes. This is usually one night and one morning > ( may be one long weekend ). True, but this is analagous to composing a file to send and then setting up an 'at' or a 'cron' job to mail it. Once you drop a letter in a post office drop box (like on a street corner) you *can't* get it back without all sorts of legal hassle, etc. Evelyn C. Leeper (201) 957-2070 UUCP: ihnp4!mtgzy!ecl ARPA: mtgzy!ecl@rutgers.rutgers.edu
guy@gorodish.UUCP (02/19/87)
>How about a modification in BSD4.x such that the files in >/usr/spool/mail/receiver can also be writable by sender. Umm, err... no, thanks. If the mailbox is writable by the sender, what prevents me from doing cat /dev/null >/usr/spool/mail/receiver or ed /usr/spool/mail/receiver and changing some message I *didn't* send to something the sender probably didn't want the receiver to think they sent? >This is the point that US mail beat E-mail: > >One can alway withdraw a mail from one's own mailbox before >mailman comes. This is usually one night and one morning >( may be one long weekend ). But (paper) mail you're sending to somebody else doesn't usually get stuck in your own mailbox; it gets stuck in the mail system's mailbox, and there are usually legal penalties attached to withdrawing mail from them.
sl@van-bc.UUCP (03/04/87)
In article <2420@mtgzy.UUCP> ecl@mtgzy.UUCP writes: >In article <3144@osu-eddie.UUCP>, lien@osu-eddie.UUCP writes: >> This is the point that US mail beat E-mail: >> >> One can alway withdraw a mail from one's own mailbox before >> mailman comes. This is usually one night and one morning >> ( may be one long weekend ). > >True, but this is analagous to composing a file to send and then setting up >an 'at' or a 'cron' job to mail it. Once you drop a letter in a post office >drop box (like on a street corner) you *can't* get it back without all sorts of >legal hassle, etc. > > Evelyn C. Leeper > (201) 957-2070 > UUCP: ihnp4!mtgzy!ecl > ARPA: mtgzy!ecl@rutgers.rutgers.edu In point of fact the CCITT X.400 has almost precisely this capability. If you send a deferred delivery message you can attempt to cancel it. X.400 4.1.2.8 Defferred delivery cancellation This service element aenables an originating UA to instruct the MTS to cancel a previously successfully submitted deferred delivery message. The canellation attmpt may not always succeed. Possible reasons for failure are: deferred delivery time has passed, or the message has already been forwarded within the MTS. (UA - User Agent, MTS - Message Transfer System) There is no equivalent capability for messages submitted for immediate delivery. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532 Todays selection: Perry Mason solves The Case of the Careless Kitten, Erle Stanley Gardner, 1942. The ingredients for murder were: A poisoned kitten; a misssing uncle; a slow-speaking gardener; a prospective bridegrooms accident!