Re: Cancel Message for Internt Mail

"Anthony E. Greene" <agreene@nemaine.com> Sun, 18 May 1997 01:26 UTC

Received: from cnri by ietf.org id aa18750; 17 May 97 21:26 EDT
Received: from mail.proper.com by CNRI.Reston.VA.US id aa12038; 17 May 97 21:26 EDT
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA12054 for ietf-smtp-bks; Sat, 17 May 1997 16:52:14 -0700 (PDT)
Received: from machias.nemaine.com ([205.139.6.148]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA12050 for <ietf-smtp@imc.org>; Sat, 17 May 1997 16:52:11 -0700 (PDT)
Received: from [147.40.34.248] by machias.nemaine.com (SMTPD32-3.04) id A4FD45017C; Sat, 17 May 1997 19:53:33 -0400
Message-Id: <3.0.1.32.19970515155630.006a0bdc@pop.mindspring.com>
X-Homepage: <http://www.mindspring.com/~aegreene/>
X-Sender: aegreene@pop.mindspring.com
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 15 May 1997 15:56:30 +0200
To: ietf-smtp@imc.org
From: "Anthony E. Greene" <agreene@nemaine.com>
Subject: Re: Cancel Message for Internt Mail
In-Reply-To: <199705121544.LAA11820@black-ice.cc.vt.edu>
References: <Your message of "Mon, 12 May 1997 01:35:07 +0200." <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> <3.0.1.32.19970512013507.006a7028@pop.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-smtp@imc.org
Precedence: bulk

At 11:44 AM 5/12/97 -0400, Valdis.Kletnieks@vt.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@nemaine.com>;
vCard and PGP Key: <http://www.mindspring.com/~aegreene/>
PGP KeyID: pub 1083 0x78CD4329
PGP FAQ: <http://www.pgp.net/pgpnet/pgp-faq/>