Subject: Re: New SMTP response codes
From: Keith Moore <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 20 May 1997 22:13:58 -0400

just catching up on my mail after a week's vacation...

random thoughts on defining new SMTP response codes:

1. IANA should maintain the list of response codes.

2. The new SMTP document being written by DRUMS should specify the
registration procedure.  (offhand, I'd suggest that the code has to be
defined in a standards-track or experimental RFC with IESG approval)

3. New SMTP codes should probably be defined only when necessary for
the the server to notify the client of a state transition....not just
for new kinds of errors.  RFC 1893 codes, along with the
ENHANCEDSTATUSCODES option, should be used to communicate new kinds of
errors where no new state changes are introduced.

4. There's no problem with defining new SMTP codes if those codes will
only be generated by servers that claim to support a particular ESMTP
option, and only when a client explicitly invokes that option.
Otherwise, there needs to be a really good reason for defining a new
code...like a state change.

Keith

Date: Sat, 17 May 1997 19:25:11 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Reconnect/Retransmission
Cc: "Paul E. Hoffman" <[email-masked]>
Sender: [email-masked]

Discussion with Paul H. about the response codes led to a question about
"when things change", the directive from RFC 821 indicating when a sending
MTA should "try again".

It occurs to me that we give no guidance for reconnection to unavailable
hosts or retries for currently inaccessible mailboxes.

Do we not have enough accumulated wisdom on this to provide at least a
modicum of guidance in 821bis?

d/

--------------------
Dave Crocker                                             +1 408 246 8253
Brandenburg Consulting                              fax: +1 408 249 6205
675 Spruce Dr.                                  [email-masked]
Sunnyvale CA 94086 USA                        http://www.brandenburg.com

Internet Mail Consortium                http://www.imc.org, [email-masked]

Date: Thu, 15 May 1997 15:56:30 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Cancel Message for Internt Mail 
Sender: [email-masked]

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

Date: Thu, 15 May 1997 22:05:20 -0400 (EDT)
From: John C Klensin <[email-masked]>
Subject: Re: RE: New SMTP response codes
To: "Jeff Stephenson (Exchange)" <[email-masked]>
Cc: "Paul E. Hoffman" <[email-masked]>, [email-masked]
Reply-to: John C Klensin <[email-masked]>
Sender: [email-masked]

On Wed, 14 May 1997 09:46:39 -0700 "Jeff Stephenson 
(Exchange)" <[email-masked]> wrote:

> John - would this be appropriate to include in your 821bis draft, or is
> it out of scope?  If it can't go into 821bis, what would be the best way
> to proceed?

I fear that  it is out of scope, but would happily accept 
direction from Chris/Harald/Keith to the contrary.  The 
biggest problem is that we can't make a normative reference 
to the extended code idea from 821bis without creating a 
queuing situation.

     john

From: "Jeff Stephenson (Exchange)" <[email-masked]>
To: "'John C Klensin'" <[email-masked]>, "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked]
Subject: RE: New SMTP response codes
Date: Wed, 14 May 1997 09:46:39 -0700
Sender: [email-masked]

I like this idea.  I've been thinking that it would be useful to have
some response code that says "Here's the basic status of the response -
check the extended errors if you care about more."  It might even be
useful to define 2x9, 3x9, 4x9, and 5x9 responses which give the more
informative category of response but then refer to the extended codes.
This would provide more detailed information to software which looks at
the second digit, as '9' is not a legitimate category under the SMTP
theory of reply codes.

John - would this be appropriate to include in your 821bis draft, or is
it out of scope?  If it can't go into 821bis, what would be the best way
to proceed?

-- jeff 

> -----Original Message-----
> From:	John C Klensin [SMTP:[email-masked]]
> Sent:	Wednesday, May 14, 1997 3:44 AM
> To:	Paul E. Hoffman
> Cc:	[email-masked]
> Subject:	Re: New SMTP response codes
> 
> There is a case to be made for trying the following 
> strategy:
> 
>  * Make up one more set of codes, e.g.,
>     299, 399, 499, 599
>    And give them the definition "extended code of 
>    status/severity (2, 3, 4, 5), see extended reply 
>    code" and a phrase syntax of "n.n.n text".
>  * Make absolutely sure that the definitions and extension 
>    mechanisms of RFC 1893 are adequate.
> 
> --john
> 

Date: Wed, 14 May 1997 07:40:26 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: New SMTP response codes
To: "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> And now for something completely different. I needed a new SMTP response
> code for an SMTP extension I'm writing. However, I could not find any
> central registry of them. This seems to be a bit of a problem, because I
> don't want to choose the same one that some other extension writer has
> chosen.

As John has already pointed out, you really don't need to formally register new
codes in this space. However, John didn't point out that there's another
codespace for response codes, the one defined in RFC1893. You should make sure
that a code exists in this space that works for you, and if it doesn't we need
to get the process going to define whatever additional codes you need.

Any effort at formalizing registration mechanisms needs to be associated
with this new code space, not the old SMTP code space.

Note that RFC2034 specifies the standard way for returning these codes in SMTP.

> (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs
> on the IMC site for "560", the number I chose, and got nothing relevant.)

This, unfortunately, will not fly. You have to pick a code with a second digit
of 5 or less. Anything else may be rejected as syntactically illegal by
deployed servers. And such rejection is entirely in conformance with current
specifications, making this a true nonstarter in any case.

You can use the third digit of the code to give you whatever additional
precision you want.

> This isn't a pressing need, but it could be embarassing if we end up with
> two standards-track SMTP extensions that use the same new error code for
> very different things. Sounds like a job for IANA, but we need to define
> what IANA should do.

This really isn't that big a deal. There's lots of overlap in present usage;
one of the main reasons for defining a new code space was to address this
problem.

				Ned

To: [email-masked]
From: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-eastlake-muse-02.txt
Date: Wed, 14 May 1997 09:40:09 -0400
Sender: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              

       Title     : Mail Ubiquitous Security Extensions (MUSE)              
       Author(s) : D. Eastlake
       Filename  : draft-eastlake-muse-02.txt
       Pages     : 22
       Date      : 05/12/1997

Secure electronic mail can provide authentication of the source of mail and
confidentiality for its contents.  These features are becoming increasingly
important as the Internet grows exponentially and email is increasingly 
used for critical, sensitive, and confidential communications.  In 
addition, authentication can make mail filtering more effective and 
ubiquitous encryption indirectly makes all mail more secure be defeating 
traffic analysis based on distinctions between encrypted and non-encrypted 
mail and defeating bulk searching through insecure mail. 

However, use of secure mail is not widespread due to the problems 
of key distribution and lack of migration to secure mail enabled 
user agents.  This draft proposes partial solutions to these 
two problems by using coarser grained identity to permit 
some authentication and confidentiality without user agent 
change, and secure DNS for key distribution.  These changes 
also support limited host and domain level mail security policies.                      

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-eastlake-muse-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-muse-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-eastlake-muse-02.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-eastlake-muse-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-eastlake-muse-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 14 May 1997 06:44:05 -0400 (EDT)
From: John C Klensin <[email-masked]>
Subject: Re: New SMTP response codes
To: "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked]
Reply-to: John C Klensin <[email-masked]>
Sender: [email-masked]

On Tue, 13 May 1997 17:59:40 -0700 "Paul E. Hoffman" 
<[email-masked]> wrote:

> And now for something completely different. I needed a new SMTP response
> code for an SMTP extension I'm writing. However, I could not find any
> central registry of them. This seems to be a bit of a problem, because I
> don't want to choose the same one that some other extension writer has
> chosen.
>...

Paul,

Unfotunately, we have a number of implementations that 
believe that the only valid codes are those that are in 821 
-- every time a new one has been added, there has been 
trouble.  Conversely, one or two implementations have 
promiscuously implemented all sorts of codes without 
documenting them.  This was a reason why the "be prepared 
to use first digit only" rule went into RFC 1123 (perhaps 
the main reason).

Consequently, much as a code registry would be a good idea 
--and IANA is probably the right place-- you might as well, 
in practice, just make something up and assume that only 
the first digit will be relevant.

There is a case to be made for trying the following 
strategy:

 * Make up one more set of codes, e.g.,
    299, 399, 499, 599
   And give them the definition "extended code of 
   status/severity (2, 3, 4, 5), see extended reply 
   code" and a phrase syntax of "n.n.n text".
 * Make absolutely sure that the definitions and extension 
   mechanisms of RFC 1893 are adequate.

--john

Date: Tue, 13 May 1997 21:06:59 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: "Paul E. Hoffman" <[email-masked]>
Cc: [email-masked]
Subject: Re: New SMTP response codes
Sender: [email-masked]

Paul,

(1) I suggest you grep drafts also.  I belive there are proposed SMTP 
response codes in draft-eastlake-internet-payment-*.txt.

(2) Intelligent allocation based on a balancing of the factor from a 
limited pool is exactly what IANA is best for.  The main problems that 
have arisen are when large amounts of money seem to be involved, which I 
think unlikely for SMTP response codes.

Donald

On Tue, 13 May 1997, Paul E. Hoffman wrote: 

> Date: Tue, 13 May 1997 17:59:40 -0700
> From: Paul E. Hoffman <[email-masked]>
> To: [email-masked]
> Subject: New SMTP response codes
> 
> And now for something completely different. I needed a new SMTP response
> code for an SMTP extension I'm writing. However, I could not find any
> central registry of them. This seems to be a bit of a problem, because I
> don't want to choose the same one that some other extension writer has
> chosen.
> 
> (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs
> on the IMC site for "560", the number I chose, and got nothing relevant.)
> 
> This isn't a pressing need, but it could be embarassing if we end up with
> two standards-track SMTP extensions that use the same new error code for
> very different things. Sounds like a job for IANA, but we need to define
> what IANA should do.
> 
> My straw-man proposal is:
> 
> - Start with a list of all response codes from 821 and all standards-track
> RFCs (I can compile this)
> 
> - Generally treat this like the TCP port number reservation scheme (first
> come, first served)
> 
> - Require that a registrant provide:
> Name
> Email address
> Name of Internet Draft the code is used in
> Date of first use
> 
> Because the response code space is limited, it might eventually fill up and
> someone will have to go through and cull out the response codes that were
> reserved but for which there is no valid Internet Draft or RFC.  However,
> that will hopefully not happen for a decade or two, given that SMTP
> extensions should not be promulgated willy-nilly.
> 
> Thoughts?
> 
> --Paul E. Hoffman, Director
> --Internet Mail Consortium
> 
> 
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Date: Tue, 13 May 1997 17:59:40 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: New SMTP response codes
Sender: [email-masked]

And now for something completely different. I needed a new SMTP response
code for an SMTP extension I'm writing. However, I could not find any
central registry of them. This seems to be a bit of a problem, because I
don't want to choose the same one that some other extension writer has
chosen.

(I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs
on the IMC site for "560", the number I chose, and got nothing relevant.)

This isn't a pressing need, but it could be embarassing if we end up with
two standards-track SMTP extensions that use the same new error code for
very different things. Sounds like a job for IANA, but we need to define
what IANA should do.

My straw-man proposal is:

- Start with a list of all response codes from 821 and all standards-track
RFCs (I can compile this)

- Generally treat this like the TCP port number reservation scheme (first
come, first served)

- Require that a registrant provide:
Name
Email address
Name of Internet Draft the code is used in
Date of first use

Because the response code space is limited, it might eventually fill up and
someone will have to go through and cull out the response codes that were
reserved but for which there is no valid Internet Draft or RFC.  However,
that will hopefully not happen for a decade or two, given that SMTP
extensions should not be promulgated willy-nilly.

Thoughts?

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 13 May 1997 14:05:33 -0700
To: "John W. Noerenberg" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Cancel Message for Internt Mail
Cc: "Anthony E. Greene" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 1:09 PM -0700 5/13/97, John W. Noerenberg wrote:

> Tony, if you have some ideas that can address Valdis' concerns, I'd be very
> interested in hearing more.  I have to be honest and say that I think it is
> highly unlikely you can guarantee the cancel in the distrbuted environment
> of the Internet.  And that is what will be required.
>
> I even think you would be hard pressed to prove that the nntp CANCEL is
> 100% effective.  By that I mean that no one at any site had read a message
> that was also cancelled.

My understanding of NNTP CANCEL is that it is far from guaranteed; but then
that also goes for NNTP in general.  CANCEL messages get lost, messages get
cancelled after they are read, so what?  Also, NNTP specifically says that
sites should not do much authentication on the CANCEL message; certainly
forging one is quite easy.

If there were to be an SMTP CANCEL (maybe RESCIND?) I think it would have
to be modelled on receipts -- strictly advisory, no guarantees to the
sender that anything will happen, up to the receiver how to deal with one.

Date: Tue, 13 May 1997 13:09:59 -0700
To: "Anthony E. Greene" <[email-masked]>
From: "John W. Noerenberg" <[email-masked]>
Subject: Re: Cancel Message for Internt Mail
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 11:44 AM -0400 5/12/1997, [email-masked] wrote:
>***
>*** PGP Signature Status: good
>*** Signer: <[email-masked]>
>*** Signed: 5/12/1997 at 8:44 AM
>*** Verified: 5/13/1997 at 12:57 PM
>***
>
>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 IE=
TF
>> 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:

Tony, if you have some ideas that can address Valdis' concerns, I'd be very
interested in hearing more.  I have to be honest and say that I think it is
highly unlikely you can guarantee the cancel in the distrbuted environment
of the Internet.  And that is what will be required.

I even think you would be hard pressed to prove that the nntp CANCEL is
100% effective.  By that I mean that no one at any site had read a message
that was also cancelled.

john noerenberg
[email-masked]
  --------------------------------------------------------------------
   "We need not to be left alone.  We need to be really
    bothered once in a while."
  -- Ray Bradbury, Farhenheit 451, 1953
  --------------------------------------------------------------------

--PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782
Content-Type: application/pgp-signature

--PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782--

To: "Anthony E. Greene" <[email-masked]>
Cc: [email-masked]
Subject: Re: Cancel Message for Internt Mail 
From: [email-masked]
Date: Mon, 12 May 1997 11:44:21 -0400
Sender: [email-masked]

--==_Exmh_-1582152804P
Content-Type: text/plain; charset=us-ascii

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

--==_Exmh_-1582152804P
Content-Type: application/pgp-signature

--==_Exmh_-1582152804P--

Date: Mon, 12 May 1997 01:35:07 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Cancel Message for Internt Mail
Sender: [email-masked]

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?

--
Anthony E. Greene <[email-masked]>
vCard and PGP Key: <http://www.mindspring.com/~aegreene/>
PGP KeyID: pub 1083 0x78CD4329
PGP FAQ: <http://www.pgp.net/pgpnet/pgp-faq/>