Re: Cancel Message for Internt Mail

Valdis.Kletnieks@vt.edu Mon, 12 May 1997 16:14 UTC

Received: from cnri by ietf.org id aa08021; 12 May 97 12:14 EDT
Received: from mail.proper.com by CNRI.Reston.VA.US id aa12129; 12 May 97 12:14 EDT
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA26832 for ietf-smtp-bks; Mon, 12 May 1997 08:43:58 -0700 (PDT)
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA26828 for <ietf-smtp@imc.org>; Mon, 12 May 1997 08:43:55 -0700 (PDT)
Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA11820; Mon, 12 May 1997 11:44:24 -0400
Message-Id: <199705121544.LAA11820@black-ice.cc.vt.edu>
To: "Anthony E. Greene" <agreene@nemaine.com>
Cc: ietf-smtp@imc.org
Subject: Re: Cancel Message for Internt Mail
In-Reply-To: Your message of "Mon, 12 May 1997 01:35:07 +0200." <3.0.1.32.19970512013507.006a7028@pop.mindspring.com>
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <3.0.1.32.19970512013507.006a7028@pop.mindspring.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1582152804P"; micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 May 1997 11:44:21 -0400
Sender: owner-ietf-smtp@imc.org
Precedence: bulk

On Mon, 12 May 1997 01:35:07 +0200, you said:
> Does anyone know of a discussion on a retraction function for mail
> analogous to an NNTP cancel message? I have looked through the IMC and IETF
> sites without success. I saw the draft SMTP extension that allows
> supersession and expiration, but that's not quite what I'm looking for. I'd
> like to see a way for the sender to cancel a message before it is read by
> the recipient.
> 
> If there isn't such a proposal on the table is this the place to discuss it?

Yes, this would be the place to discuss it.

No, there's no such proposal as far as I am aware.

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?  If the service
*says* it was cancelled, how cancelled is it *really*?  (Remember that
Oliver North got  strung up because  of system backups  that contained
e-mail memos he thought were deleted).  Is the file *really* erased to
(say) mil-spec  standards  (overwritten  multiple times  with   random
patterns,  and so   on),  or is  it  just logically  erased, and still
scavengable off the disk, or is it still in a file, and just marked as
"purged"?

2)  What if the  recipient  gets his "You  have  new mail" bleep right
away, and goes and reads his mail?  You then have to deal with (a) the
mail was already  read - NOW what do  you do? and  even  worse (b) the
recipient   is in the   process   of reading  it  when  cancelling  is
attempted...

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?

4) Security implications  - what level  of authentication is needed to
cancel  a mailgram?  Note  that this is a serious  issue for the folks
who are doing  EDI over e-mail  - they most   certainly do *NOT*  want
people to  be  able to  cancel  an  EDI-submitted order  that  easily,
outside the EDI scheme.

5) Implications for e-mail based  automatons (Listservs, file servers,
and the  like)  - what  happens if  you   send  in a 'cancel'   for  a
subscription   request?  Especially   if  the   Listserv processed  it
already?  (This is *not* a moot point - I've seen our Listserv receive
a  subscribe, process  it,  and  get the   "you have been  subscribed"
message out all within 2 seconds).

I could probably think of more issues if I  hadn't just arrived at the
office and not ingested my usual requirement of caffeine yet. ;)

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech