[Top] [All Lists]

Re: Cancel Message for Internt Mail

1997-05-17 16:52:14
At 11:44 AM 5/12/97 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
There are a number of severe problems you need to deal with in any such

1) What level of "guarantee" will the service provide?

The cancelling agent (server or client) would delete the message from it's
message store and return a delivery status notification message to the
sender. If the message could not be found or had been read the DSN would
indicate these conditions. If the agent that found and deleted the message
was unable to determine the whether or not the message had been read the
DSN would indicate this also. Of course backups may remain and it's
possible that they would be delivered if a failure occured between
reception of the original and reception of the cancellation. I think this
possiblity could simply be stated in the draft and accepted as is. This is
one of the things that can happen when backup data is used. There would be
no requirement for sanitation of the message store (overwriting, etc). Only
a similar function as would happen if the recipient read and deleted the

2)  What if the  recipient  gets his "You  have  new mail" bleep right
away, and goes and reads his mail?...

The mail client would not attempt deletion on a message that is open or has
been read. A failure DSN would be returned to the sender indicating the
message could not be deleted and may have been read. This is not supposed
to be a perfect mechanism, just a feature that could be used to recover
from an accident (hopefully) before it's too late.

3) Many people  (myself included) do  a lot of programmatic processing
of mail (filtering, filing based on origin/subject, etc) when the mail
is received.   There's  *NO* way that you  will  be able to   get at a
message to cancel it  in this case.  Even if  the message  itself were
removable, there  may  be other    state  information that will    get
changed. For  instance,     my 'procmail' filter   keeps   statistical
information on the number of messages received of different types - if
I receive a message   in "Category 3A" that's  subsequently cancelled,
how does that change the 'received count' for 3A?

If the message has been processed and is not removable then a failure DSN
would be returned to the sender. Otherwise the client could search through
it's folders to find the original message by message-id. This may be a
lengthy process but it should not happen very often.

Your second point is harder. A graceful failure may be the best that can be
achieved without a lot of filter rewriting.

4) Security implications...

The sender would have to be the same and the message id would have to be
specified. This is the biggest weak point I saw when thinking about this.
The only solutions I could come up with involve public key and directory
infrastructures that we don't have yet. Servers which process business
critical transactions could have cancel messages disabled. The real
solution is a security infrastructure. This whole idea may not be practical

5) Implications for e-mail based  automatons...

The sender would get a failure DSN. It may be possible to configure
machines that serve only as listservers to send a help message when a
cancel message is sent to a list address, in addition to the failure DSN.

Anthony E. Greene <agreene(_at_)nemaine(_dot_)com>
vCard and PGP Key: <>
PGP KeyID: pub 1083 0x78CD4329

<Prev in Thread] Current Thread [Next in Thread>