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
proposal:
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
message.
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
yet.
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: <http://www.mindspring.com/~aegreene/>
PGP KeyID: pub 1083 0x78CD4329
PGP FAQ: <http://www.pgp.net/pgpnet/pgp-faq/>