Subject: Re: Return Receipt et al

From: Joe Ilacqua <[email-masked]>
Date: Mon, 01 Mar 1993 16:58:23 -0500

<You are confusing a delivery-receipt with a read-receipt
>(Delivery-Receipt-To: vs Read-Receipt-To: header)

	I don't think I'm confused at all. We are talking about the
"Return-Receipt-To:" header (see the Subject: and Mark's message)
which I have never seen implemented to do anything other than delivery
receipt.  I've never seen a read receipt implementation, and I think
that you couldn't do it without mailer cooperation.

->Spike

---

From: Ron Pool <[email-masked]>
Date: Mon, 1 Mar 1993 20:24:24 -0500 (EST)

> that you couldn't do it without mailer cooperation.

We actually had a read-receipt implementation -- it was in an _old_ local
email system that I re-wrote (about 8 years ago) from scratch.  The
re-implemented system also included read-receipt.  We've since switched to
pine and have gladly dropped the read-receipt and delivery-receipt features.

Please note that the biggest complaint about pine from our approx. 750
users has been that it doesn't have read-receipt in it like our old
system.  They've stopped clamoring about that now and seem to be quite
please with pine, excepting those few users who like to open a log file on
the PC when they first go into mail and close it when they leave,
expecting to see a perfectly formatted stream of the text of all messages
read.  Most of these users are happy to put up with this in order to get
the other features of pine like multiple enclosures (our old system had a
single enclosure available -- a homegrown concept then).
--
Ron Pool; Electronic Technology Group; B-15 Wing Hall; Ithaca, NY 14853
Internet: [email-masked]

---

From: "Steven D. Majewski" <[email-masked]>
Date: Mon, 1 Mar 1993 21:10:26 +22306404 (EST)

This subject has been debated in other forums, and I'm aware of 
Mark Crispin's feelings on the matter ( and agree with a lot of
his privacy reservations ) BUT, it still stands that:

 - delivery-receipts AND read-receipts are something a lot of USERS
   want ( and sometimes NEED ) and when you tell them that read-receipts
   don't really do what they might think they do, they will tell you that 
   what they want is for you to make them work better - not to get
   rid of them. ( And they will take whatever limited functionality 
   they currently offer in the mean time. ) 

 - Delivery-receipts AND read-receipts ARE implemented in several systems. 
   ( usually non portable, non standard and proprietary ) 

 - email thru multiple gateways is unreliable enough that even delivery
   receipts are useful. Sometimes 3 days for a bounce message is an 
   unacceptable time to wait for a NACK. And out-of-band phone verification
   is also often out of the question. ( If we could get them on the phone
   then we wouldn't be using email in many cases. Researchers in the former
   Soviet Union, for example, usually tell us to use email because the phone
   system is so poor! ) 

And, I _might_ add (IMHO), that there are business and commercial uses that
will require (read or delivery) receipts. But then many of those uses will
also require sender verification, public-key-encryption and other security
features, form-letter replies, in addition to a more reliable receipt capability. 

But since I've heard there may be enough potential problems just getting MIME 
and PEM to work together, ( and I expect that any internet standard approach
to the above will end up using those two as building blocks ), I'll forgive
you, Mark, if you don't want to waste YOUR time on it. :-) 

BUT: I managed to keep my damn mount shut the last 3 or 4 times this 
topic came up. I weakened this time because it's late AND I want to 
ask: Is there an architectural overview - an Email Reference Model - 
of how responsibilities should be partitioned between the user agent 
and the delivery agent ( and imap and other parts of the mail system ). 
My impression is that OSI terminology has sort of been bolted onto 
current practice, but that there is not really a very clear model. 

But I guess this is getting out of the pine-info mailing list realm. 

===============================================================================
 Steven D. Majewski			University of Virginia 
 [email-masked]			Box 449 Health Sciences Center
 Voice: (804)-982-0831			1300 Jefferson Park Avenue
 FAX:   (804)-982-1616			Charlottesville, VA 22908

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 2 Mar 1993 00:04:38 -0500 (EST)

I think you've got a lot of good points in favor of r-r-r here. Certainly
it's needed for EDI like applications in the future, though I think a lot
of the need for verification now is because users are new and insecure
about e-mail. 

I think the ironic thing about the current r-r-r: is that it's probability of
working is about the same as the message going through so it doesn't get
you very much. For example if you go through a a gateway to FidoNet or
such where the messages is likely to get lost, the r-r-r is also likely to
get lost because it's no longer SMTP and sendmail.

I think the gating issue for Pine is clearly the lack of standards for
this. The idea in Pine is to stick with standards to keep interoperability
and quality as high as possible. There was a mailing list where some
Internet standards folks were hashing some of this out, but I think the
effort sort of petered out, mostly due to technical difficulties making it
work across gateways. 

LL

On Mon, 1 Mar 1993, Steven D. Majewski wrote:

> features, form-letter replies, in addition to a more reliable receipt
capability.  >