Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.mail.uucp
Subject: Re: cancelling mail messages
Message-ID: <1370@hoptoad.uucp>
Date: Mon, 1-Dec-86 17:26:58 EST
Article-I.D.: hoptoad.1370
Posted: Mon Dec  1 17:26:58 1986
Date-Received: Tue, 2-Dec-86 00:59:55 EST
References: <2718@bu-cs.BU.EDU>
Organization: Nebula Consultants in San Francisco
Lines: 53

I worked with an email system (STSC's Mailbox) from 1972 through about
1980, which allows the canceling of messages.  It was a useful feature.
I have occasionally used root privileges to cancel a message that I
have sent under Unix, before it got out (or got out to all recipients).
I find this a useful feature too, and wish it was easier and more general.

Mostly, the reason users of the Mailbox wanted to cancel a message is
because it contained an error of fact.  E.g. announcing that a meeting
will occur at 1PM when it is actually at 2PM.  Just getting the fixed
message is much cleaner than getting two conflicting messages.
Occasionally one's better sense takes hold after posting an ill-advised
message, and the fewer people who see it, the better.  Both of these
reasons are used in the Usenet, which allows the canceling of articles.

I have not seen the ability to cancel a message abused by system
administrators, though I'm sure it has happened.  When I left STSC in
1976, I sent a message to everyone in the company telling them why I
was leaving.  The management requested that I cancel the message, but
when I disagreed, they did not attempt to override me and cancel it
themselves.

Note that the STSC Mailbox was not a single-system mail system.  It started
that way, but was later enhanced to transfer messages transparently among
multiple machines.  (No hostnames were used; everyone could be reached
on any machine, and their mail would migrate to their home machine,
except for special accounts like root, where the mail would sit on each
machine and not migrate.)  If a message had been transferred to another
system, the cancel would also have to be transferred, and it would
not take effect immediately, of course.  This is still better than
not being able to cancel at all.

Now for the Unix/Internet mail environment.  Many things are different.
My best idea for cancellation in this environment is a convention in
the mail reading software which will cause it to suppress display of
a received message if a cancel message naming it is received.  This
requires no changes to mail propagation software, and even has a useful
effect if the receiving site does not support cancellation, since the
recipient will get and read a little message that says "please cancel my
message XXXXX".

If such a scheme was considered reasonable, and was implemented, then
we could consider stopping cancelled messages while in transit (e.g. in
sendmail queues or uucp queues), or while stored in the user's mailbox
(e.g. delivery of a cancel message could remove a message from
/usr/spool/mail/$USER) rather than waiting for the user to call up a
mail reader which would do the job.  But I think the main benefit of
cancellation (actually, STSC called it "withdrawl") is that *people*
will not see your message, rather than that *machines* will waste less
time moving it around.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
    "I can't think of a better way for the War Dept to spend money than to
  subsidize the education of teenage system hackers by creating the Arpanet."